04-08-2021 09:28 AM
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?
04-08-2021 11:26 AM
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,
04-08-2021 06:37 PM
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?