How to solve Hold Time Violation

Hi Friends,

I dont know How to solve the Hold time violation, can you help me

Error:

I saw in online for solution to fix hold Time violation,
they mentioned two method

1.By Adding delay
or
2.Decreasing the certain cells in the data path

can you explain me how to add delay, where to add delay?

This seems to be in continuation to the question you asked yesterday...
You can add some buffers in the data path (between source and destination flop) so that the data gets pushed ahead thereby solving the hold time violation at the source flop...

abu9022 said:

I dont know How to solve the Hold time violation, can you help me

Error:

Code:

"NangateOpenCellLibrary_slow_conditional.v", 1614: Timing violation in \TBLEON.TB.P0.LEON0.MCORE0.PROC0.IU0.IU1 .iu2.\ex_reg[RS1DATA][2]
    $hold( posedge CK:594, posedge D:594, limit: 1 );

I saw in online for solution to fix hold Time violation,
they mentioned two method

1.By Adding delay
or
2.Decreasing the certain cells in the data path

can you explain me how to add delay, where to add delay?

Click to expand...

- Solution 1 is something that cannot be reliably implemented in an FPGA
- Solution 2 makes no sense

The proper solution in an FPGA is to never used clocks that are generated from logic or flip flops. Only use clocks that come from an input clock pin or the output of a PLL inside the FPGA. Nothing else.

If you examine the design further, I strongly suspect that you'll find that the clock signal at the flip flop that is reporting the hold time violation violates the rule stated in the previous paragraph. Fix that and you'll fix the hold time violation. Hold time violations are precisely the reason why you never want to generate internal clocks and use them to clock anything.

Kevin Jennings

MMmmh, this looks to be more of the same type of problem. I really suggest you read that PDF I linked to in your other thread. It will help you in meeting timing, and how to properly constrain your design.

And particular to your LEON case, it will help you interpret the constraints the LEON code is generating for you. And hopefully it will also help you in noticing any lacking constraints. That sort of thing.

I still contend that there is a inherent design problem here.


means that the clock CK positive edge is occurring at the exact same time as the rising edge of D (data). As everything given is out of context, we don't know if the OP is running a SDF timing simulation or a functional gate level simulation.

Regardless the fact remains that the data and clock are both switching at the exact same time, which is makes me highly suspicious that this is a functional gate level simulation (no timing) and there is a design problem (possibly a logic generated clock of some sort as K-J mentioned). It's highly improbable that you would have this situation in a full SDF simulation as most libraries would be defined using ps resolutions.