+ Post New Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 61 to 80 of 118
  1. #61
    Advanced Member level 5
    Points: 38,447, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,953
    Helped
    2048 / 2048
    Points
    38,447
    Level
    47

    Re: AXI arvalid signal issue

    No, there was no mistake - the idea was that when the last address in a bust is sent AND accepted by the slave, arvalid should return to 0.
    Start_of_burst and end_of_burst do not need to have a relation to AXI signals. That are just meant to represent external stimulus to initiate/complete an axi transfer.
    Last edited by TrickyDicky; 27th February 2020 at 11:16.


    1 members found this post helpful.

  2. #62
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    when the last address in a bust is sent AND accepted by the slave, arvalid should return to 0.
    However, in my other AXI master (address_generator.v), o_axi_araddr could be of different, unique addresses instead of increment by ONE.
    I do not think I could use burst addressing for my other AXI master.

    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
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    
    wire transaction_is_accepted = (o_axi_arvalid) && (i_axi_arready);
     
    always @(posedge clk)
    begin
        if(reset) o_axi_araddr <= 0;
     
        else o_axi_araddr <= idx_n + idx_r + idx_k; // the DDR address to read data from
    end
     
    // used for generating address (o_axi_araddr) indexes
    reg [C_AXI_ADDR_WIDTH-1:0] idx_n;
    reg [C_AXI_ADDR_WIDTH-1:0] idx_r;
    reg [C_AXI_ADDR_WIDTH-1:0] idx_k;
     
    // no multiply in actual synthesized hardware since 'N', 'n', 'Tn' and TILE_LENGTH are constants
    always @(posedge clk)
    begin
        if(reset) idx_n <= n * TILE_LENGTH * TILE_LENGTH; 
     
        else if ((idx_n < (N * TILE_LENGTH * TILE_LENGTH)) && transaction_is_accepted)
                    idx_n <= idx_n + Tn * TILE_LENGTH * TILE_LENGTH; 
    end
     
    // no multiply in actual synthesized hardware since 'r', 'MAX_J' and 'TILE_LENGTH' are constants
    always @(posedge clk)
    begin
        if(reset) idx_r <= r * TILE_LENGTH;
     
        else if((idx_r < ((r + MAX_J) * TILE_LENGTH)) && transaction_is_accepted) 
                    idx_r <= idx_r + TILE_LENGTH;
    end
     
     
    always @(posedge clk)
    begin
        if(reset) idx_k <= c;
     
        else if((idx_k < (c + MAX_K)) && transaction_is_accepted) 
                    idx_k <= idx_k + 1;
    end



  3. #63
    Super Moderator
    Points: 32,371, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,484
    Helped
    1756 / 1756
    Points
    32,371
    Level
    43

    Re: AXI arvalid signal issue

    Pending transactions means you can send multiple transactions not expecting the return reads to show up before the next transaction is completed. This can also result in out of order transactions, where a long transaction (for a flash device) is started but another transaction to read a register is completed before the data for the 1st read to the flash has even started. Most designs I've seen don't support this and will only handle single transactions.

    The original code from Tricky was correct, where end_of_burst would have ARVALID as part of the gating. Therefore (ARVALID and ARREADY) = '1' is correct as that signals the end of an address transaction. The other AXI signal would be the AxLEN which tells you how long the transfer is, you have to keep track of the running count of the beats in the transfer.

    Code Verilog - [expand]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    
    // ignoring the always stuff
    // this is slave code that does INCR burst operations.
    if (ARVALID && ARREADY)  // ARADDR has an address to be read from, so grab it
      my_addr <= ARADDR;
    else if (RVALID && RREADY)  // data @my_addr is being returned by the slave, so my_addr can be updated
      my_addr <= my_addr + 1;
    end if;
     
    // this is master code that generates addresses in a sequential pattern (non-burst)
    if (ARVALID && ARREADY)  // ARADDR increments every time the address was accepted by the slave
      ARADDR <= ARADDR + 1;
    end if;

    Half the time I can't tell if you are showing master or slave code.


    1 members found this post helpful.

  4. #64
    Advanced Member level 5
    Points: 38,447, Level: 47
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,953
    Helped
    2048 / 2048
    Points
    38,447
    Level
    47

    Re: AXI arvalid signal issue

    @ADS-ee out of order transactions are only supported in axi 3. In axi4 all transactions must be in order. Hence why in axi4 wdata has no wid signal as this is taken from awid


    1 members found this post helpful.

  5. #65
    Super Moderator
    Points: 32,371, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,484
    Helped
    1756 / 1756
    Points
    32,371
    Level
    43

    Re: AXI arvalid signal issue

    Quote Originally Posted by TrickyDicky View Post
    @ADS-ee out of order transactions are only supported in axi 3. In axi4 all transactions must be in order. Hence why in axi4 wdata has no wid signal as this is taken from awid
    Thanks Tricky forgot they changed that between AXI3 & AXI4, haven't had to write code for either interface for over 2 years, been stuck using APB and AHB.



  6. #66
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    @ads-ee : Why would AXI slave need to update my_addr ? I thought it is AXI master duty to update address ?



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

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

    Re: AXI arvalid signal issue

    i think the "my_addr" is for designs that have arlen > 1.



    •   AltAdvertisement

        
       

  8. #68
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    i think the "my_addr" is for designs that have arlen > 1.
    Wait, I do not understand how "my_addr" is needed in the context of arlen > 1



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

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

    Re: AXI arvalid signal issue

    for arlen > 1, rlast isn't always 1.


    1 members found this post helpful.

  10. #70
    Super Moderator
    Points: 32,371, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,484
    Helped
    1756 / 1756
    Points
    32,371
    Level
    43

    Re: AXI arvalid signal issue

    For slaves that support arlen >1 i.e. bursts, the slave must perform address increments, the master only sends the start address of a burst.

    If you make the master do single transfers you lose a lot of the benefit of using AXI4 (non-Lite), which gives you burst capability improving the overall transfer rate and reducing the overhead. If all you need is single transfers and the master will update all the addresses then you might as well only use AXI4-Lite as it is simpler to implement.



  11. #71
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    @ads-ee , @vGoodtimes : My AXI code seems to have satisfied AXI protocol specifications after heeding advice from you guys, but why it still fail in AXI Protocol Checker IP ?

    Bit 59 : AXI_ERRS_RID
    Bit 78 : AXI_AUXM_RCAM_OVERFLOW

    Note: I have two AXI masters, one of them could have made use of burst capability, the other could not though.



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

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

    Re: AXI arvalid signal issue

    you seem to have ignored the advice and re-asked the same question. at least I see the same errors as before.

    you seem to have ignored advice to make each module work independently. I think you are looking for quickfixes and ignoring anything that isn't a 1-line fix.

    the ip checker fails for the same reason it failed before. but I don't think the checker can catch all of the axi errors you have.



  13. #73
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    I think I also found another error with my skid buffer implementation. It should not just buffer RDATA, but also RVALID.

    make each module work independently <-- as in including the skid buffer inside AXI slave module ?

    Note: AXI Protocol Checker IP cannot verify AXI transaction using master or slave alone.



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

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

    Re: AXI arvalid signal issue

    you should try to make a tb that aggressively tests each axi module. not something nice. look at each module and try to break it -- while being axi complient. this means stuff like toggling ready at random. always holding valid at 1. etc... but not things that break the axi spec like toggling valid from 1 to 0 when ready is/was 0.



  15. #75
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    but not things that break the axi spec like toggling valid from 1 to 0 when ready is/was 0.
    The above issue had been solved using the following code segment for AXI slave :

    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

    And just for information, AXI Protocol Checker IP raised the errors for both AXI interfaces even when RREADY and ARREADY signals are asserted high (free-flow AXI bus without any barriers)
    In other words, the AXI code is not AXI-compliant in the simplest test scenario.

    Click image for larger version. 

Name:	cskpTYW.png 
Views:	0 
Size:	109.2 KB 
ID:	157999
    Last edited by promach; 28th February 2020 at 09:44.



  16. #76
    Super Moderator
    Points: 32,371, Level: 43
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,484
    Helped
    1756 / 1756
    Points
    32,371
    Level
    43

    Re: AXI arvalid signal issue

    // 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))
    Your implementation of an AXI slave may behave this way but this is not part of the AXI specification. You should avoid ambiguities in your comments that mix specification and specific implementation details. Something as simple as AXI-2.3.2.1: <some spec info> and the rest of the comment is better than Note: <some spec info>.

    Both ARVALID and ARREADY asserted only indicate that ARADDR has been accepted by the slave and the master no longer needs to hold ARADDR constant and can start another address channel cycle furthermore there is nothing in the spec that requires the slave to assert RVALID once that has occurred (the comment is really about how this slave is always single cycle access, i.e. 1st cycle address, 2nd cycle is read data).



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

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

    Re: AXI arvalid signal issue

    @promach, what is the value of MAXRBURSTS used for the axi checker?



  18. #78
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    MAXRBURSTS is 64 , but AXI Protocol Checker IP gave errors in the first 5 clock cycles ....



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

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

    Re: AXI arvalid signal issue

    what did the sim waveforms look like for the first five cycles?

    - - - Updated - - -

    Quote Originally Posted by ads-ee View Post
    ...there is nothing in the spec that requires the slave to assert RVALID once that has occurred...
    I agree with your comment but this part might be confusing. I think axi does require the slave to eventually assert rvalid after the arvalid&&arready occurence. maybe not 1 cycle later, maybe not 2, but eventually.



  20. #80
    Advanced Member level 3
    Points: 3,963, Level: 14

    Join Date
    Feb 2016
    Posts
    776
    Helped
    1 / 1
    Points
    3,963
    Level
    14

    Re: AXI arvalid signal issue

    @vGoodtimes

    Click image for larger version. 

Name:	qMniHOe.png 
Views:	6 
Size:	114.8 KB 
ID:	157998



    •   AltAdvertisement

        
       

--[[ ]]--