[SOLVED] post route result coming early

[dipin]

Hi k-j

Post the same waveforms from the original post showing that you delayed in_data by more than 2.1ns relative to clk. Post another showing that reset has been delayed by more than 1.428 ns after clk.

I have checked that here is the waveform


here reset is delayed by 2 ns and input is delayed by 3 ns.

but in the waveform now out put is delaying ...

previously output is coming in just before the 10th clockcycle. but now its just before the 11th clockcycle.

So I see the following:
IN_WIDTH: 31
OUT_WIDTH: 31/2 = 15
IN_CAL: 31/4 =7
N: 4*(7+1) = 32
Q: 16

10 is not equal to 16, so what was your point with that code snippet? It certainly doesn't prove you designed a 10 stage pipeline. It only proves you don't know how to tell us how many pipeline stages your design has.

i cant split up the bits in my design. my pipeline is baised on my no of clockcycle to perfom the operation.in each clockcycle input is given to next set of registers.so for ten clockcycle there are 10 parallel set of registers which perform same operations.

so can i post the code here.will you check it.

thanks & regards

 

[K-J]

Hi k-j


I have checked that here is the waveform
View attachment 113102

here reset is delayed by 2 ns and input is delayed by 3 ns.

but in the waveform now out put is delaying ...

previously output is coming in just before the 10th clockcycle. but now its just before the 11th clockcycle.

- The output is delayed by one clock cycle now that your testbench is no longer violating timing requirements of your design
- So you now have 10 clock cycle delay from in_data to out_data just like you said you wanted.

Kevin Jennings

 

[ads-ee]

- The output is delayed by one clock cycle now that your testbench is no longer violating timing requirements of your design
- So you now have 10 clock cycle delay from in_data to out_data just like you said you wanted.

Kevin Jennings

Violating timing requirements? In a post route UNIT DELAY simulation? I highly doubt the OP even knows how to run a SDF simulation, given they don't even know how to add a clock constraint to their UCF file. I'm pretty sure the OP would have been crying about all the warnings if they had "timing violation" messages from the Vital or Specparm statements in their primitive models (or maybe they've been getting them and haven't said anything).

I still contend that the problem is/was an issue with delta delays and I suspect an inadequate understanding of what they are observing in the simulation waveform.

The fact that they have to keep asking if they should post their code/testbench is really ridiculous. If they had posted it in their very first post they would have had their answer way before now. The OP has no clue how to debug something or how to provide what is needed to debug their problem.

Kevin, save your fingers and give up, I already have. I don't want to see you fall down this rabbit hole. ;-)

 

[dipin]

hi,
thanks to k-j , ads-ee and sharath666.
actually i found my problem.after getting that above waveform, i found that my output buffer had a delay of 4ns and my clock tree had a delay of 2ns . so this is the justification for the delay in the output .

and sorry for the inconvenience caused.

actually my problem is this

I still contend that the problem is/was an issue with delta delays and I suspect an inadequate understanding of what they are observing in the simulation waveform.

thanks & regards