cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
529 Views
Registered: ‎04-04-2020

Post Implementation Simulation - BRAM data out one cycle earlier in Vivado 2019.2

Jump to solution

Behaviour, Post-Synthesis (both functional and timing) and Post-Implementation (functional) simulation proves that data comes out in next cycle after latching the address. However, Post-Implementation (timing) simulation shows the the data come out as soon as the address is latched. Did I do something wrong or it is a bug in the simulator? 

capture_post_implementation_functional.PNG
capture_post_implementation_timing.PNG
capture_post_synthesis_timing.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
257 Views
Registered: ‎04-04-2020
Now I know why post-implementation timing is not working. It is because I happened to use one controller to drive address stroke to a few BRAMs which causes some BRAMs received address strokes incorrectly due to the routing delays. Assigning dedicated controller for each BRAM solves the issue.

View solution in original post

0 Kudos
8 Replies
Highlighted
Voyager
Voyager
507 Views
Registered: ‎06-20-2012

Simulation is correct.
Data change on the clock rising edge when CED = '1'.
CED starts one cycle later in post-implementation timing maybe due to a delay in a synchronous reset.

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
Highlighted
Visitor
Visitor
478 Views
Registered: ‎04-04-2020
I understand the data appears at the rising edge but the data should be from the address of the previous rising edge.
in synthesis simulation:
clk >address >data
01 >addr000 > 0000 (initial resets value)
02 >addr001 > cc5392b3 (data from addr000)
02 >addr002 > ac596640 (data from addr001)

However in post-implementation simulation
clk >address >data
01 >addr000 > cc5392b3 (data from addr000)
02 >addr001 > ac596640 (data from addr001)
02 >addr002 > ab75e7c2 (data from addr002)

that is strange!
0 Kudos
Highlighted
Voyager
Voyager
472 Views
Registered: ‎06-20-2012

I don't agree.

In the funcional simulation the first clock rising edge with CED=1 is at 140.100 ns and ADDR=0.

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
Highlighted
Adventurer
Adventurer
459 Views
Registered: ‎04-04-2018

It is looks in your simulations, you are observing the clock at it's source. It also looks like there may be a delay in the clock getting to RAM. Therefore the rising edge is getting there slightly after the address changes. 

Steve Markgraf - Distinguished FPGA Design & Support Engineer E5-E
www.designlinxhs.com
0 Kudos
Highlighted
Visitor
Visitor
360 Views
Registered: ‎04-04-2020

I assume it is the post-implementation timing simulation issue. In one of my testings on 18k BRAM, DOUTBDOUT[15:0] is one clock ahead of DOUTADOUT[15:0] despite there is only one common clock going into 18k BRAM. It does not make sense at all. I attached the implemented schematic in this post. 

capture_implementation_schematic.PNG
0 Kudos
Highlighted
Voyager
Voyager
347 Views
Registered: ‎06-20-2012

If you have found a bug, post a project that shows it.

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos
Highlighted
Visitor
Visitor
258 Views
Registered: ‎04-04-2020
Now I know why post-implementation timing is not working. It is because I happened to use one controller to drive address stroke to a few BRAMs which causes some BRAMs received address strokes incorrectly due to the routing delays. Assigning dedicated controller for each BRAM solves the issue.

View solution in original post

0 Kudos
Highlighted
Voyager
Voyager
236 Views
Registered: ‎06-20-2012

Next time check the timing with "report_timing" before simulate.

== If this was helpful, please feel free to give Kudos, and close if it answers your question ==
0 Kudos