Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Community Forums
- :
- Forums
- :
- Vivado RTL Development
- :
- Timing Analysis
- :
- Re: Hold Violations on negedge flops - how to solv...

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

ldm_gk

Observer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-08-2021 09:28 AM

127 Views

Registered:
09-10-2020

Hold Violations on negedge flops - how to solve?

Hi All,

I have Hold violations on the flops, which are driven by a negedge clock (rest flops are driven by the posedge clock). So, the negedge flops, which are driven by the posedge clocks, are receiving the hold violations.

What constraints (probably a multi-cycle path) should be applied to the negedge clock flops?

Thank you!

2 Replies

drjohnsmith

Teacher

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-08-2021 11:26 AM

103 Views

Registered:
07-09-2009

Can I ask , why are you using positive and negative edge flops ?

doing so, tends to half the available set up times available , halving the available clock speed.

can you give us the block diagram of what your trying to do ?

and your example code please,

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

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-08-2021 06:37 PM

51 Views

Registered:
01-23-2009

Are you sure about this?

It is virtually impossible to have a hold violation on a path from a rising edge flip-flop to a falling edge flip-flop.

Let's take the example of a 100MHz clock with a 50/50 duty cycle.

The rule for a setup check is "the capture edge is the edge of the clock at the destination flip-flop that occurs strictly after the launch edge at the source flip-flop". So for our 10ns clock on a path from rising edge to rising edge, the setup launch edge is at time 0 and the setup capture edge is at time 10. This makes sense.

For the hold time check the capture edge is "the active edge at the destination flip-flop that is one period earlier than the setup capture edge" (the rules are a bit more complicated for clocks with different frequencies). So for the same 10ns rising to rising path, the hold capture edge is the one before the hold capture edge; since the setup capture edge is at time 10ns, the hold capture edge is at time 0. This means "a change caused by the edge at the source flip-flop at time 0 must **not** propagate to the capture flip-flop before the capture edge (also at time 0)." In other words the data path delay must be greater than the clock skew (which makes sense).

Now look at the path from rising edge to falling edge. Using the rule for the setup check, the launch edge is the rising edge at time 0 and the capture edge is the falling edge at time 5ns. Again, this makes sense. Now the hold rule above tells us that if the setup capture edge is the edge at 5ns, then the hold capture edge is the clock edge before that - the falling edge at time -5ns (**NEGATIVE 5ns**). Thus the hold check requires that the data change caused by the rising edge at time 0 must arrive strictly after the falling edge at the destination at time -5ns. Unless your clock skew is immense (greater than 5ns), this should be impossible.

So, again, are you sure this is the failure you are seeing?

Avrum