+ Post New Thread
Page 5 of 8 FirstFirst ... 3 4 5 6 7 ... LastLast
Results 81 to 100 of 149
  1. #81
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    Does AXI protocol require data packet re-transmission in the case of error arising from receiver/destination side ?



    •   AltAdvertisement

        
       

  2. #82
    Advanced Member level 5
    Points: 38,675, Level: 48
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,983
    Helped
    2063 / 2063
    Points
    38,675
    Level
    48

    Re: AXI arvalid signal issue

    What do you mean by error? AXI itself is only a pipe, it doesnt care about what is carried over it. Retransmission might be a master requirement, but has nothing to do with AXI.


    1 members found this post helpful.

  3. #83
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    I have updated the code to use Xilinx own AXI slave in order to minimize the location of bug finding.

    just uncomment `define XILINX 1 in load_data_from_bram.v

    Click image for larger version. 

Name:	VlvnoLT.png 
Views:	1 
Size:	108.9 KB 
ID:	158214



  4. #84
    Advanced Member level 4
    Points: 6,599, Level: 19

    Join Date
    Feb 2015
    Posts
    1,065
    Helped
    304 / 304
    Points
    6,599
    Level
    19

    Re: AXI arvalid signal issue

    is this a question or a request for help/comment?

    I didn't read the entire thing. I did notice "o_axi_wvalid && o_axi_awvalid" appears in an expression and both are outputs. this is not specifically an error, but likely is one. normally, this would be a small fsm -- NOT_WAITING, WAITING_FOR_BOTH, WAITING_FOR_AW, WAITING_FOR_W. the intent is to not make any assumptions about either ready signal. I'm guessing if it works in your design it is because there is an assumption that ready will be true for both channels.


    1 members found this post helpful.

  5. #85
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    "o_axi_wvalid && o_axi_awvalid" appears in an expression and both are outputs. this is not specifically an error, but likely is one.
    I do not quite understand your explanation on the intent is to not make any assumptions about either ready signal with the following code snippet ?

    Code Verilog - [expand]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    
    reg [$clog2(MAX_BURST_LENGTH)-1:0] num_of_write_transactions;
     
    always @(posedge clk) 
    begin   
        if(reset) num_of_write_transactions <= 0;
     
        else if(o_axi_wvalid && o_axi_awvalid)
                num_of_write_transactions <= (o_axi_wlast) ? 1 : num_of_write_transactions + 1;
    end

    - - - Updated - - -

    Or are you suggesting that there are bugs in the following logic for WVALID and AWVALID ?

    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
    41
    
    reg [$clog2(MAX_BURST_LENGTH)-1:0] num_of_write_data_sent;
     
    always @(posedge clk) 
    begin
        if(reset) 
        begin 
            o_axi_wvalid <= 0;
            num_of_write_data_sent <= 0;
        end
     
        else if(!(o_axi_wvalid && !i_axi_wready))
        begin
            o_axi_wvalid <= (o_axi_wlast && write_response_is_ok) ? 
                            0 : (num_of_write_data_sent < o_axi_awlen);
     
            if(write_response_is_ok) num_of_write_data_sent <= num_of_write_data_sent + 1;
        end
    end
     
    wire ddr_write_address_range_is_valid = (o_axi_awaddr < (1 << C_AXI_ADDR_WIDTH));
     
    always @(posedge clk) 
    begin   
        if(reset) o_axi_awvalid <= 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_awvalid to be true before setting o_axi_awready 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 AWREADY before asserting AWVALID
        // Note: (!(o_axi_awvalid && !i_axi_awready)) == (!awvalid || awready) 
        //       == (!awvalid || (awvalid && awready)). 
        //       it means "no transaction in progress or transaction accepted"
        else if(!(o_axi_awvalid && !i_axi_awready))
                o_axi_awvalid <= /*i_axi_awready &&*/ (ddr_write_address_range_is_valid);
    end

    I am still debugging the following waveform

    Click image for larger version. 

Name:	RbHOQHB.png 
Views:	0 
Size:	254.1 KB 
ID:	158215
    Last edited by promach; 9th March 2020 at 04:02.



  6. #86
    Advanced Member level 4
    Points: 6,599, Level: 19

    Join Date
    Feb 2015
    Posts
    1,065
    Helped
    304 / 304
    Points
    6,599
    Level
    19

    Re: AXI arvalid signal issue

    Code:
    // convenient common subexpressions
    assign w_accept = (w_valid && w_ready);
    assign aw_accept = (aw_valid && aw_ready);
    
    // next-value logic also useful for use in the ready logic
    // can be written in other ways to make it more clear.
    // w_accept && !aw_block is the same as w_accept && !aww_accept effectively.
    //                     (retain               set          )    reset
    assign next_w_block <= (w_block || (w_accept && !aw_block)) && !aw_accept;
    assign next_aw_block <= (aw_block || (aw_accept && !w_block)) && !w_accept;
    
    always @(posedge clk) begin
      // boilerplate assigns for the 2-process style logic.
      w_block <= next_w_block;
      aw_block <= next_aw_block;
      
      // these have to be registered by axi spec.  
      // realistically, probably becomes something really simple or really complex.
      // can be moved to another always block that uses next_w_block/next_aw_block.
      w_ready <= !next_w_block && logic_for_w_ready;
      aw_ready <= !next_aw_block && logic_for_aw_ready;
    
      // reset
      if (rst) begin
        w_block <= 1'b0;
        aw_block <= 1'b0;
        w_ready <= 1'b0;
        aw_ready <= 1'b0;
      end
    end
    
    // true when both aw and w accepted.  "aww" sounds cute.  for the read channel,
    // "arr" sounds like a pirate.  although it does mean there is w, aw, and aww
    // prefixes, so typos could be an issue.
    assign aww_accept = (w_accept && aw_accept) // both on same cycle
      || (w_accept && aw_block)  // w on this cycle, aw on some previous cycle
      || (w_block && aw_accept); // aw on this cycle, w on some previous cycle
    
    // these can happen when the logic for the ready signals is not based on the block signals.
    assert(!(w_block && w_accept)); // w accepted after blocking
    assert(!(aw_block && aw_accept)); // aw accepted after blocking
    assert(!(aw_block && w_block)); // invalid state.
    This example is untested, but should be correct. in your code, what would happen if !wready && !awready? if wready and awready both remain low? the concern is that this triggers wvalid and awvalid to remain high. but the logic increments anyways.


    1 members found this post helpful.

  7. #87
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    @vGoodtimes You were writing code snippet for AXI slave in which I am using Xilinx own AXi slave IP, which means I have no control over AXI slave



  8. #88
    Advanced Member level 4
    Points: 6,599, Level: 19

    Join Date
    Feb 2015
    Posts
    1,065
    Helped
    304 / 304
    Points
    6,599
    Level
    19

    Re: AXI arvalid signal issue

    ok, fair. this does change the commentary about the 2 process vs 1 process style. In anycase, you have "o_axi_wvalid && o_axi_awvalid" as a condition. but what happens if i_axi_wready and i_axi_awready are both low?



  9. #89
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    Are you saying that I need to synchronize or make both AW* and W* channels in sync ?



  10. #90
    Advanced Member level 4
    Points: 6,599, Level: 19

    Join Date
    Feb 2015
    Posts
    1,065
    Helped
    304 / 304
    Points
    6,599
    Level
    19

    Re: AXI arvalid signal issue

    axi is a protocol that allows one to consider the correctness of a module based only on that module. When a module is used in only one design it can be tempting to bend the rules.

    let's say you assert wvalid and awvalid. there are four cases for wready,awready. how does your design handle them?


    1 members found this post helpful.

  11. #91
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    Ok, I understand your concern about AWREADY and WREADY signals.

    However, I am facing some X unknown for AXI protocol checker IP (pc_status)

    Click image for larger version. 

Name:	dZLXON7.png 
Views:	0 
Size:	268.1 KB 
ID:	158216



  12. #92
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    For this AXI master coding, how do I guarantee AW* payloads are sent first, followed by W* payloads without violating AXI protocol (a master must not wait for AWREADY to be asserted before driving WVALID) ?

    Code Verilog - [expand]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    
    always @(posedge clk) 
    begin
        if(reset) 
        begin 
            o_axi_wvalid <= 0;
        end
     
        else if(!(o_axi_wvalid && !i_axi_wready))
        begin
            // Note that both o_axi_awsize , o_axi_awlen are of hardware constants, so no multiply hardware
            // since this is for testing, WDATA just uses some values up to the total size of the write address space
            // see [url]https://i.imgur.com/LBO9pQz.png[/url] in which AW* payloads are sent first, followed by W* payloads
            // Note: a master must not wait for AWREADY to be asserted before driving WVALID
            o_axi_wvalid <= (o_axi_wlast) ? 0 : 
                            (o_axi_wdata < (o_axi_awsize*o_axi_awlen)) && o_axi_awvalid; 
        end
    end

    Click image for larger version. 

Name:	LBO9pQz.png 
Views:	0 
Size:	31.7 KB 
ID:	158217



  13. #93
    Advanced Member level 5
    Points: 38,675, Level: 48
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,983
    Helped
    2063 / 2063
    Points
    38,675
    Level
    48

    Re: AXI arvalid signal issue

    Why do you need to guarantee that? thats the Slaves problem by assertion of awready and wready. The Master is allowed to send WDATA before AWADDR.


    1 members found this post helpful.

  14. #94
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    In the pc_status error bit location , is it bit #32 because in the following simulation waveform, BVALID is never asserted high during the time when pc_status error bit #32 is asserted ?

    xClick image for larger version. 

Name:	oVlqJUe.png 
Views:	2 
Size:	249.1 KB 
ID:	158218



  15. #95
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    Ok, I have solved the above pc_status[32] AXI_ERRS_BRESP_WLAST error.

    Now, I have an entirely different pc_status[22] AXI_ERRM_WSTRB issue.

    Write strobes must only be asserted for the correct byte lanes as determined from the: Start Address, Transfer Size and Beat Number.
    What does it mean by The information on the low-order address lines must be consistent with the information on the byte lane strobes. ?




  16. #96
    Super Moderator
    Points: 32,539, Level: 44
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    7,527
    Helped
    1764 / 1764
    Points
    32,539
    Level
    44

    Re: AXI arvalid signal issue

    The byte lanes are fixed at specific addresses so the lower order bits of the address must be consistent with the byte lane being accessed.


    1 members found this post helpful.

  17. #97
    Advanced Member level 5
    Points: 38,675, Level: 48
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,983
    Helped
    2063 / 2063
    Points
    38,675
    Level
    48

    Re: AXI arvalid signal issue

    AWADDR is a byte address, which you have set to 3. Therefore wstrb should be 0x1FFF or 0xFFF8 depending on the byte ordering on your bus


    1 members found this post helpful.

  18. #98
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    Why if AWADDR is set to 3 , then WSTRB should be 0x1FFF or 0xFFF8 ???



  19. #99
    Advanced Member level 3
    Points: 4,170, Level: 15

    Join Date
    Feb 2016
    Posts
    820
    Helped
    1 / 1
    Points
    4,170
    Level
    15

    Re: AXI arvalid signal issue

    I do not quite understand the following burst alignment mechanism




  20. #100
    Advanced Member level 5
    Points: 38,675, Level: 48
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,983
    Helped
    2063 / 2063
    Points
    38,675
    Level
    48

    Re: AXI arvalid signal issue

    AWADDR = 0x03 is not word aligned. With a 128 bit WDATA interface the word address alignment increments in steps of 16. So AWADDR of 0x00, 0x10, 0x20 etc would be word aligned. If you provide an address that is not perfectly word aligned, you then need to set WSTRB to provide correct byte alignment. So if you provided an address that ended with 0x0F, then only 1 byte in WDATA can be valid.

    - - - Updated - - -

    The image you show is such that AWSIZE = 2 (transfers are 4 bytes per beat), but WDATA = 8 bytes. So when doing transfers only 4 bytes can be transfered per beat.
    Usually, you would set AWSIZE to match WDATA width. In your case, AWSIZE should ideally be 4.


    1 members found this post helpful.

--[[ ]]--