+ Post New Thread
Page 8 of 8 FirstFirst ... 6 7 8
Results 141 to 149 of 149
  1. #141
    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

    Waiting for BRESP simply wasts potential time on the interface. Imagine some high speed interface (say 25G ethernet). Waiting a couple hundred clocks for a BRESP could lose you a few packets.
    This is based on the assumption that AXI master does not need sequential data processing in the case of BRESP returns NACK.

    What if the mentioned AXI master is a CPU or any other sequential computation units ?
    Even 1 single missing calculation or wrong operand value fed into the CPU would result in incorrect final output answer.



  2. #142
    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

    That is no longer an AXI question. Thats a Design question.



  3. #143
    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

    How do I eliminate pc_status error bit 32 in the AXI slave code ?

    Click image for larger version. 

Name:	AXI_pc_status_error_A.png 
Views:	5 
Size:	214.9 KB 
ID:	159098

    By the way, there is another pc_status error bit 80.
    I have already tried to increase MAXWBURSTS parameter as suggested in the description column, but it is still not eliminated.



  4. #144
    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

    you probably have some dropped/duplicated transactions. Over time, the queue will fail and things based on the queue will fail.



  5. #145
    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

    you probably have some dropped/duplicated transactions.
    How is this related to pc_status error bits 32 or 80 ?



    •   AltAdvertisement

        
       

  6. #146
    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

    looking at the diagram again, it looks like there is a few cycles of latency between when something happens and when something changes in that status. it looks like the value changes a total of three times. I can't see the first value, but it is probably all 0's. the next value looks like bit 80 is set. the final value has both set.

    I notice that awready is asserted while awvalid is 'X'. Perhaps this error condition results in an issue with the simulation aspects of this checker.


    1 members found this post helpful.

  7. #147
    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

    If I assert reset at t = 0 instead of few clock cycles later, then all pc_status error bits are cleared (no AXI violations).

    Something is still not correct because hardware reset signal is not designed to be asserted at t = 0



  8. #148
    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, I'd look at fixing the reset situation. perhaps assert reset for a longer amount of time and remove the reset not on a clock edge of either direction.



  9. #149
    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

    the problem is not about the duration of reset signal, instead it is about how the AXI slave axi_awready signal responds to delayed reset signal

    The assertion of axi_awready as well as axi_arready together with the unknown X nature of axi_awvalid as well as axi_arvalid before reset is asserted at t = 25ns might have just triggered the AXI protocol violation bits in pc_status signal

    Code Verilog - [expand]
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    
    clk = 0;
    //reset = 0;
     
    //@(posedge clk);
    //@(posedge clk);
    //@(posedge clk);
     
    reset = 1;
     
    @(posedge clk);
    @(posedge clk);
     
    reset = 0;
    Last edited by promach; 5th May 2020 at 07:49.



--[[ ]]--