cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
silverace99work
Adventurer
Adventurer
1,536 Views
Registered: ‎03-04-2018

register control logic getting split across multiple blocks in synthesis + timing issue

Jump to solution

Hi, let me preface this by saying that I am new to synthesis....I'm sure I need to go take some courses on it but I'd appreciate what help or advice I can get in the immediate term.

 

In my design, I have a flop counter called "cycle_count". It is triggered by the signal "wr_en_prev". 'cycle_count' runs on a clock that is 6x what 'wr_en_prev' runs on. Both clocks are coming out of the same generic clock IP provided with Vivado.

 

I ended up with a timing violation in synthesis. The first thing I noticed in schematic is that one of the 'cycle_count' LUTs (see below image) got moved to the 'rx_buf' block even though in my code the counter is in the 'tx_buf' block, then routes back to the tx_buf block (path highlighted in blue). Is that normal? Seems odd to me.

 

htv_schem.jpg

 

Second, I ended up with a timing violation on this path. However I'm not sure how to interpret the report:
hold_time_violation.jpg

 

Under the "Path(ns)" columns I see a lot of negative values. What does that mean in relation to a positive value? I'm having trouble concluding what the report is telling me.

 

Thanks for your help!

0 Kudos
1 Solution

Accepted Solutions
hemangd
Moderator
Moderator
1,760 Views
Registered: ‎03-16-2017

Hi @silverace99work,

 

Yes, timing has been passed after implementation because router has done its job well. There may be hold violations while synthesis phase but router has resolve it.

 

Post-synthesis timing report cannot be relied on for timing closure analysis, as  accurate net delays are not available at post synthesis stage.As the hold time violation is very small, it will most probably get fixed during P&R .

 

Regards,

hemangd

 

- If your query has been answered and you are satisfied with it, you can close this thread by marking as accepted solution so community remains healthy.

 

 

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.

View solution in original post

0 Kudos
6 Replies
maps-mpls
Mentor
Mentor
1,494 Views
Registered: ‎06-20-2017

You should take a course on static timing analysis and xilinx design constraints.

 

In the meantime, can you show the source clock path in the path report and/or the schematic?    Are both clocks coming from the same MMCM or PLL?  Or are they traceable to different oscillators?

*** Destination: Rapid design and development cycles ***
0 Kudos
silverace99work
Adventurer
Adventurer
1,426 Views
Registered: ‎03-04-2018

@maps-mpls thanks for the reply. Both clocks are coming off the same MMCM.

 

 

This is the source clock path report:

source_clockpath.png

 

 

For good measure, here is the schematic view for the clock path:

source_clockpath_schem.jpg

0 Kudos
hemangd
Moderator
Moderator
1,401 Views
Registered: ‎03-16-2017

Hi @silverace99work,

 

For timing issue:

 

You have posted timing report after synthesis. I will recommend you to check timing summary after implementation stage once it gets completed. 

 

Run implementation and to check timing violations by running report_timing_summary in tcl console and check. Attach that report herein to evaluate if there are violations. 

 

Regards,

hemangd 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
avrumw
Guide
Guide
1,398 Views
Registered: ‎01-23-2009

The first thing I noticed in schematic is that one of the 'cycle_count' LUTs (see below image) got moved to the 'rx_buf' block even though in my code the counter is in the 'tx_buf' block

 

If you want your design to stay where it is suppose to be then you need to change the synthesis option "-flatten_hierarchy" to "none" instead of the default, which is "rebuilt".

 

As for your timing, you need to post the complete path - the path summary, the source delay the datapath delay and the destination delay. Without this, it is really hard to help you.

 

BUT - this looks like this might be a hold time violation - admittedly a pretty large one (but that may be expected between two different clocks)... Hold time violations are only fixed during the routing phase of implementation - small hold time violations (<100ps) after synthesis can be ignored (although at 0.5ns I would want to verify that the path looks correct...)

 

Avrum

silverace99work
Adventurer
Adventurer
1,374 Views
Registered: ‎03-04-2018

@hemangd As you suggested I went on to run Implementation and....it passed? O_o

 

 

I had assumed that failures in synthesis would imply failure in implementation but I guess that is not the case? I do have some high severity warnings about unconstrained pins for max delay, but no failures.

impl timing sum.jpg
0 Kudos
hemangd
Moderator
Moderator
1,761 Views
Registered: ‎03-16-2017

Hi @silverace99work,

 

Yes, timing has been passed after implementation because router has done its job well. There may be hold violations while synthesis phase but router has resolve it.

 

Post-synthesis timing report cannot be relied on for timing closure analysis, as  accurate net delays are not available at post synthesis stage.As the hold time violation is very small, it will most probably get fixed during P&R .

 

Regards,

hemangd

 

- If your query has been answered and you are satisfied with it, you can close this thread by marking as accepted solution so community remains healthy.

 

 

 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.

View solution in original post

0 Kudos