AXI arvalid signal issue

Status
Not open for further replies.
I'm not sure I follow what the problem is. Basically, when valid and ready are high, a transaction occurs. The document above talks about a theoretical slave missing a transaction. Thay is bad because the master is now out of sync.
 

I think this is the bram controller module in the link. although the version in the link doesn't seem to be the same as the version used for the picture. I think the module is intended to be a temporary replacement for external ram. The coding style prevents it from actually inferring bram. the bram controller in the linked code doesn't support backpressure on rready. A skid buffer would make sense. an external memory controller would likely use a fifo.
 

A skid buffer would make sense
Click to expand...

If that is what you said, then skid buffer article should be what I needed, but I need to confirm why I need 2-entries FIFO instead of just 1-entry FIFO ?

However, pipelining handshaking is more complicated: simply adding a pipeline register to the valid, ready, and data lines will work, but now each transfer take two cycles to start, and two cycles to stop.
Click to expand...

Quoted from the article , why two cycles to start, and two cycles to stop ?

- - - Updated - - -

See this updated waveform which better illustrates the need for skid buffer

Note the highlighted signals i_axi_arready , o_axi_arvalid, and o_axi_rready which are part of the module addr_gen_nn_features which is basically address_generator.v

 

Besides, I still have a bad feeling that my code still have VALID signal depending on READY signal of the same connection interface which is not allowed in **broken link removed**

In the following code segment, arvalid depends on arready

Code Verilog - [expand]
1

else if(!(o_axi_arvalid && !i_axi_arready)) o_axi_arvalid <= (not_yet_the_end_of_neural_network_data);
 
Last edited:

That doesn't look right, any of the valid signals (from the master) should not be using the ready (slave) status to determine if the valid should be asserted.

The de-assertion of valid does look at both ready and valid to determine if the transfer is complete, which can result in valid being de-asserted or if another pending transfer is issued then valid stays asserted.

The code you posted states you can only assert valid when valid is low or ready is high, which does not conform to A3.3.1.
 


I think this does conform. The logic is the same as (!valid ? 1 : ready) == (!valid || (valid && ready)) == (no_transaction || transaction_accepted). It is just optimized a bit.
 

I have added skid buffer to AXI master

However, does AXI slave require skid buffer as well ?

@ads-ee : I have modified the logic for o_axi_arvalid according to your advice.

@vGoodtimes : the old logic does not work whenever RREADY is pulled low , rendering the AXI transaction stalled.
 

Neither. They both show rdata changing and rvalid going from high to low when rready is low.
 

They both show rdata changing and rvalid going from high to low when rready is low.
Click to expand...

What is wrong with this logic sequence ?

Did AXI protocol prohibit this ? Could anyone point me to a specific paragraph in AXI protocol with regards to this ?
 

When asserted, RVALID must remain asserted until the rising clock edge after the master asserts RREADY.
Click to expand...

Do you mean this ?

Does the following AXI waveform follow AXI protocol ?

 
Last edited:

Yes it does wrt RDATA channel. Its not really clear why ARVALID is involved in the waveform as you do not show ARADDR or ADREADY.
 

Its not really clear why ARVALID is involved in the waveform
Click to expand... 

Code Verilog - [expand]
1

o_axi_arvalid <= o_axi_rready;


because o_axi_rready is used for backpressure mechanism

- - - Updated - - -

I have modified logic for o_axi_rvalid accordingly.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

always @(posedge clk)
begin
    if(reset) o_axi_rvalid <= 0;
 
    // AXI specification: A3.3.1 Dependencies between channel handshake signal
    // the VALID signal of the AXI interface sending information must not be dependent on 
    // the READY signal of the AXI interface receiving that information
    // this is to prevent deadlock 
    // since AXI slave could wait for i_axi_arvalid to be true before setting o_axi_arready true.
    // Note: For same interface, VALID cannot depend upon READY, but READY can depends upon VALID
    // Note: Once VALID is asserted, it MUST be kept asserted until READY is asserted.
    //       VALID signal needs to be set (initially) independent of READY signal, 
    //       and then only ever adjusted if !(VALID && !READY)
    // Note: the slave must not wait for the master to assert RREADY before asserting RVALID
    // Note: (!(o_axi_rvalid && !i_axi_rready)) == (!rvalid || rready) 
    //       == (!rvalid || (rvalid && rready)). 
    //       it means "no transaction in progress or transaction accepted"
    // Note: the slave must wait for both ARVALID and ARREADY to be asserted before 
    //       it asserts RVALID to indicate that valid data is available
    else if(!(o_axi_rvalid && !i_axi_rready))
            o_axi_rvalid <= i_axi_arvalid && o_axi_arready; 
end


However, this modification violates AXI protocol : For same interface, VALID cannot depend upon READY , that is o_axi_rvalid should not depend on i_axi_rready
 

Again, whats the problem? we already covered this. No channel VALID may be asserted based on the status of the READY from the same channel. VALID should be asserted as soon as data is available, and should remain asserted until it is acknowledged with READY.
 

looks like the checker overflow issue again. my guess is that you never respond to some reads and over the simulation the number of missed reads exceeds the capabilities of the checker. eg, if you hold arready at 1 then every arvalid is accepted. but you don't have any way to deal with potential backpressure on the rvalid/rready channel.

This is what the skid buffer was intended to do. but you do still need to have logic for arready.
 

As for backpressure, see the logic for o_axi_arvalid

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

always @(posedge clk) 
begin   
    if(reset) o_axi_arvalid <= 0;
 
    // AXI specification: A3.3.1 Dependencies between channel handshake signal
    // the VALID signal of the AXI interface sending information must not be dependent on 
    // the READY signal of the AXI interface receiving that information
    // this is to prevent deadlock 
    // since AXI slave could wait for i_axi_arvalid to be true before setting o_axi_arready true.
    // Note: For same interface, VALID cannot depend upon READY, but READY can depends upon VALID
    // Note: Once VALID is asserted, it MUST be kept asserted until READY is asserted.
    //       VALID signal needs to be set (initially) independent of READY signal, 
    //       and then only ever adjusted if !(VALID && !READY)
    // Note: the master must not wait for the slave to assert ARREADY before asserting ARVALID
    // Note: (!(o_axi_arvalid && !i_axi_arready)) == (!arvalid || arready) 
    //       == (!arvalid || (arvalid && arready)). 
    //       it means "no transaction in progress or transaction accepted"
    // Note: o_axi_rready is used for backpressure mechanism
    else //if(!(o_axi_arvalid && !i_axi_arready))
            o_axi_arvalid <= /*i_axi_arready &&*/ (ddr_address_range_is_valid) && 
                                o_axi_rready;
end
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…