+ Post New Thread
Page 2 of 7 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 128
  1. #21
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    However I still do not see how a skid buffer will solve this issue

    and why would AXI slave require skid buffer as well ?

    Note the first and the last highlighted signals in the waveform screenshot below:

    Click image for larger version. 

Name:	VtLXuAW.png 
Views:	1 
Size:	442.3 KB 
ID:	157944



  2. #22
    Advanced Member level 5
    Points: 38,501, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,962
    Helped
    2051 / 2051
    Points
    38,501
    Level
    47

    Re: AXI arvalid signal issue

    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.



  3. #23
    Advanced Member level 4
    Points: 6,489, Level: 19

    Join Date
    Feb 2015
    Posts
    1,053
    Helped
    299 / 299
    Points
    6,489
    Level
    19

    Re: AXI arvalid signal issue

    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.



  4. #24
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    A skid buffer would make sense
    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.
    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

    Click image for larger version. 

Name:	JZuzlqN.png 
Views:	0 
Size:	456.2 KB 
ID:	158220



  5. #25
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    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 section A3.3.1 of AXI protocol

    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 by promach; 18th February 2020 at 08:33.



  6. #26
    Super Moderator
    Points: 32,411, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,493
    Helped
    1758 / 1758
    Points
    32,411
    Level
    43

    Re: AXI arvalid signal issue

    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.



  7. #27
    Advanced Member level 4
    Points: 6,489, Level: 19

    Join Date
    Feb 2015
    Posts
    1,053
    Helped
    299 / 299
    Points
    6,489
    Level
    19

    Re: AXI arvalid signal issue

    Quote Originally Posted by ads-ee View Post
    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.



  8. #28
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    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.



  9. #29
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    I have just corrected skid buffer implementation which should have been 2-entries FIFO

    See if you guys could find anything wrong with this skid buffer implementation



    •   AltAdvertisement

        
       

  10. #30
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    Which waveform follows AXI spec ?

    Click image for larger version. 

Name:	WDvUJ6w.png 
Views:	0 
Size:	77.4 KB 
ID:	158221

    xClick image for larger version. 

Name:	w0l8l2O.png 
Views:	0 
Size:	77.1 KB 
ID:	158222



  11. #31
    Advanced Member level 5
    Points: 38,501, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,962
    Helped
    2051 / 2051
    Points
    38,501
    Level
    47

    Re: AXI arvalid signal issue

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



  12. #32
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    They both show rdata changing and rvalid going from high to low when rready is low.
    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 ?



  13. #33
    Advanced Member level 5
    Points: 38,501, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,962
    Helped
    2051 / 2051
    Points
    38,501
    Level
    47

    Re: AXI arvalid signal issue




  14. #34
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    When asserted, RVALID must remain asserted until the rising clock edge after the master asserts RREADY.
    Do you mean this ?

    Does the following AXI waveform follow AXI protocol ?

    Click image for larger version. 

Name:	SQ0ucA4.png 
Views:	0 
Size:	77.4 KB 
ID:	158223
    Last edited by promach; 24th February 2020 at 10:27.



  15. #35
    Advanced Member level 5
    Points: 38,501, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,962
    Helped
    2051 / 2051
    Points
    38,501
    Level
    47

    Re: AXI arvalid signal issue

    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.



  16. #36
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    Its not really clear why ARVALID is involved in the waveform
    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



  17. #37
    Advanced Member level 5
    Points: 38,501, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,962
    Helped
    2051 / 2051
    Points
    38,501
    Level
    47

    Re: AXI arvalid signal issue

    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.



  18. #38
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue




  19. #39
    Advanced Member level 4
    Points: 6,489, Level: 19

    Join Date
    Feb 2015
    Posts
    1,053
    Helped
    299 / 299
    Points
    6,489
    Level
    19

    Re: AXI arvalid signal issue

    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.



  20. #40
    Advanced Member level 3
    Points: 3,998, Level: 14

    Join Date
    Feb 2016
    Posts
    784
    Helped
    1 / 1
    Points
    3,998
    Level
    14

    Re: AXI arvalid signal issue

    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



--[[ ]]--