Arbiters

Fixed-Priority 4-Request Arbiter — L1 Upgrade — L2 Upgrade

Fixed-priority 4-request arbiter with mask, hold, grant-lock, and credit/almost-full.

Open in IDE Category

About this block

Simulate it in the Verilog IDE

Mediumverilogsimsyn

Fixed-Priority 4-Request Arbiter — L1 Upgrade — L2 Upgrade is a Verilog reference block in the Arbiters catalog. Round-robin, fixed-priority, and grant-based resource arbiters. Marked Medium: more state or a wider datapath, still one workspace in the IDE.

This IP implements a fixed-priority arbiter for four request lines. It supports request masking, state holding, grant locking, and credit-based almost-full detection. It is designed for L1 and L2 upgrade scenarios where deterministic latency and resource efficiency are critical.

This arbiter provides robust priority management with advanced features including:

Fixed Priority: Priority 0 is highest, Priority 3 is lowest.
Masking: Individual request lines can be disabled via the mask port.
Hold Functionality: The hold signal freezes the current grant state, preventing state changes during critical operations.
Grant Lock: The grant_lock_en signal allows the current grant to be maintained until explicitly released or pending requests drop to zero.
Credit-Based Almost-Full: Monitors pending request counts against a configurable threshold to prevent buffer overflow.

The design is fully synchronous, resettable, and verified against eight key test scenarios covering basic arbitration, masking, hold, lock, empty requests, and reset behavior.

Choose Open in IDE. RTL Studio loads the packaged workspace for Fixed-Priority 4-Request Arbiter — L1 Upgrade — L2 Upgrade.
Read the Verilog module in the editor. The catalog line for this block: Fixed-priority 4-request arbiter with mask, hold, grant-lock, and credit/almost-full.
Run the packaged testbench with the in-browser Verilator simulator, then open the VCD in the waveform viewer.
Run Yosys in the same IDE for a generic netlist. Sky130 liberty mapping is a separate Pro library option.

RTL Studio is the Verilog simulator and IDE around this block: Slang lint, Verilator, VCD waveforms, and Yosys, in the browser. Simulation guide · Yosys guide.

Features

Priority Encoding: Selects the highest priority valid request. Priority 0 is highest, Priority 3 is lowest.
Request Masking: Allows individual request lines to be ignored by the arbiter via the mask port.
State Hold: Prevents state transitions when hold is asserted, freezing the current grant.
Grant Lock: Maintains the current grant until grant_lock_en is deasserted or no pending requests remain.
Almost Full Detection: Triggers when pending requests exceed a configurable credit threshold.

Ports

Port Name	Direction	Width	Description
`clk`	Input	1	Clock input
`rst_n`	Input	1	Active-low reset
`req`	Input	4	Request signals [3:0]
`mask`	Input	4	Mask signals [3:0]; 1=ignore, 0=enable
`hold`	Input	1	Hold current grant; freezes state machine
`grant_lock_en`	Input	1	Enable grant lock; holds current grant
`credit`	Input	4	Credit threshold [3:0] for almost-full detection
`almost_full_en`	Input	1	Enable almost full logic
`grant`	Output	1	Grant signal; high if any request is granted
`grant_id`	Output	2	Granted request ID [1:0]
`almost_full`	Output	1	Almost full status; high if pending >= credit

Architecture

The design uses a registered state machine to manage arbitration. Combinational logic determines the next grant ID based on priority, masking, and control signals. A pending request register tracks active requests for credit counting.

### State Machine Logic

Hold Priority: If hold is asserted, the state machine retains the current grant, grant_id, and lock_state.
Lock Priority: If not holding, and lock_state is active, the state machine retains the current grant until grant_lock_en is deasserted or pending_req is zero.
Arbitration: If neither hold nor lock is active, the highest priority valid request is selected.
Pending Count: The pending_req register is updated based on valid requests. A request is considered "pending" until it is granted.

Verification

The testbench covers eight key scenarios to ensure correct operation under various input conditions.

Test Case	Description	Result
TC1	Basic priority arbitration	PASS
TC2	Masking	PASS
TC3	Hold functionality	PASS
TC4	Grant Lock	PASS
TC5	Grant Lock Release	PASS
TC6	Almost Full	PASS
TC7	No Requests	PASS
TC8	Reset	PASS

### Expected Simulation Output

After running the simulation, the Log panel should show:

TC1 PASS - Basic priority
TC2 PASS - Masking
TC3 PASS - Hold
TC4 PASS - Grant Lock
TC5 PASS - Grant Lock Release
TC6 PASS - Almost Full
TC7 PASS - No Requests
TC8 PASS - Reset

More in Arbiters

All Arbiters blocks