Using both edges of a clock

--- Quote Start ---

The Technology Map Viewer should show correctly, how the inversion is implemented. As far as I remember, previous FPGA families didn't have a local clock inversion.

To understand the reason for timing violations, you can check what's between the registers.

--- Quote End ---

Thanks guys. The hold time optimization settings were all checked using timing optimization advisor...

Here are two screen shots I took for the hold time violations I got in the latest compilation. Now the problem actually shifted to the rising edge of the clk (clk_7m). The timing report is also attached in the zip file.

Any clue from here?

--- Quote Start ---

Thanks guys. The hold time optimization settings were all checked using timing optimization advisor...

Here are two screen shots I took for the hold time violations I got in the latest compilation. Now the problem actually shifted to the rising edge of the clk (clk_7m). The timing report is also attached in the zip file.

Any clue from here?

--- Quote End ---

Hi

How does the clock paths looklike ?

Why are the launch and latch edge identical and where does the large clock skew (0.8 ns) comes from ? Is the clk7m defined as global ?

Kind regards

GPK

--- Quote Start ---

Hi

How does the clock paths looklike ?

Why are the launch and latch edge identical and where does the large clock skew (0.8 ns) comes from ? Is the clk7m defined as global ?

Kind regards

GPK

--- Quote End ---

The clk_7m is a generated clock but defined as a global signal.

Clock skew? could you please point me to where you find it?

launch and latch on the same edge? correct me if I am wrong but, I thought it's the way the timequest timing analyzer present the waveform. The source sends new data at the launch clock edge, at the same edge the receiver latches the old data from the last clock cycle. In the screenshot I posted it seem that the data arrived at the receiver end too soon. But why is the real clock delay is so much shorter than the expected clock delay?

--- Quote Start ---

The clk_7m is a generated clock but defined as a global signal.

Clock skew? could you please point me to where you find it?

launch and latch on the same edge? correct me if I am wrong but, I thought it's the way the timequest timing analyzer present the waveform. The source sends new data at the launch clock edge, at the same edge the receiver latches the old data from the last clock cycle. In the screenshot I posted it seem that the data arrived at the receiver end too soon. But why is the real clock delay is so much shorter than the expected clock delay?

--- Quote End ---

Hi,

clock skew means that you have different delays for the clock path to the launch and latch register. When the clock is distributed over a global net and the registers are placed in the same area of the FPGA the delay should be the same.

I have posted a timing diagramm where you can see what I would expect.

Kind regards

GPK

--- Quote Start ---

Forgot attachment? :D

--- Quote End ---

Hi,

no idea what happend ???:confused:

--- Quote Start ---

Hi,

no idea what happend ???:confused:

--- Quote End ---

I see what you meant now.

1. In your screenshot, the launch edge is sperated from the latching edge even they are the same clock.

2. In your screenshot, the clock delays for the two edges are the same, while the clock delays in my screenshot have a difference of 0.775ns.

And I think you are right that the 0.775ns skew is the cause of the hold time violation. But, does anyone know where I should look for the cause of the skew?

BTW, my screenshot is in post# 12 up there and pletz's screenshot is in post# 17.

Appreciated!

Hua

--- Quote Start ---

I see what you meant now.

1. In your screenshot, the launch edge is sperated from the latching edge even they are the same clock.

--- Quote End ---

I think pletz is mixing up setup with hold relationship.

--- Quote Start ---

2. In your screenshot, the clock delays for the two edges are the same, while the clock delays in my screenshot have a difference of 0.775ns.

--- Quote End ---

That's exactly the problem, your clock skew is too big.

It would be useful to see a TimeQuest report with the clock path for both registers. Is this an external clock? How it is constrained?

Double check the clock is global. But this doesn't seem to be the problem, because even with non-global routing the skew shouldn't be that big for LABs that are almost adjacent.

You have lots of warning about unconstrained clocks. Not sure if this has any relation to the problem, but it might be worth to check them.

Thanks for the hint, vjAlter. In the current compilation the timing issue went away. But I will check the timing report with clock path in it next time when it comes up.

And yes, the clock is global. And yes, I don't think those unconstrainted clocks have any thing to do with the data path we are talking about.

You guys are awesome!