cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
escou64
Visitor
Visitor
650 Views
Registered: ‎10-09-2018

Block Memory Generator IP AXI4 Lite

Jump to solution

Hello,

I am currently trying to implement a first AXI Lite master block.

For simulation and debug, I connect my block to a Block Memory Generator IP with AXI4 Lite ports,  but I am facing a "simple" bug that I do not understand.

(The clock is generated by a MMCME2_BASE)

lock.png

 Here is the bug case: I am only using the read port.

I put arvalid to '1' and when the next positive clock edge is rising, arready is at '0': then I consider that my request is not accepted.

But during the next clock cycle, the memory puts rvalid to '1', which locks my communication: rready is locked at '0' because I previously considered my request as not accepted.

unlock.png

Here is the case where rready is fixed to '1' and it seems to correctly work, because no lock is observed.

But the first request is still not normal for me: arready is not set to '1' with arvalid during the first rising edge, so the request must not be accepted...

Is my understanding of the handshake protocol of AXI Lite erroneous ? Or maybe a (un)known bug in the Block Memory Generator ?

For information, I am currently using Vivado 2019.2: can uninstalling and installing Vivado 2020 be a solution ?

Thanks !

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
dgisselq
Scholar
Scholar
615 Views
Registered: ‎05-21-2015

@escou64 ,

From the trace picture you are showing, it doesn't look like you've properly reset the block RAM controller.  Xilinx requires that any AXI device of theirs should receive 16 clock cycles of S_AXI_ARESETN being low (i.e. active) prior to releasing the reset.  VALID is then not allowed on the clock following the reset.  So, try this.

If that doesn't fix your issue, then let me suggest that I've seen a lot of subtle effects associated with how a test bench is written -- i.e. whether control wires are set on the edge of the clock or instead at a particular time or not.  That'd be what I'd check next. but I'd need to see your testbench to check it.

Dan

View solution in original post

Tags (1)
2 Replies
dgisselq
Scholar
Scholar
616 Views
Registered: ‎05-21-2015

@escou64 ,

From the trace picture you are showing, it doesn't look like you've properly reset the block RAM controller.  Xilinx requires that any AXI device of theirs should receive 16 clock cycles of S_AXI_ARESETN being low (i.e. active) prior to releasing the reset.  VALID is then not allowed on the clock following the reset.  So, try this.

If that doesn't fix your issue, then let me suggest that I've seen a lot of subtle effects associated with how a test bench is written -- i.e. whether control wires are set on the edge of the clock or instead at a particular time or not.  That'd be what I'd check next. but I'd need to see your testbench to check it.

Dan

View solution in original post

Tags (1)
escou64
Visitor
Visitor
588 Views
Registered: ‎10-09-2018

Thank you so much for your reply @dgisselq !

After some tests, it seems that the reset is causing my issue here.

Because this reset is also connected to my MMCM block which generates my clock, I think I have to implement a delay-like block to keep the reset for the other blocks until 16 clock cycles have been generated.

 

0 Kudos