Using both edges of a clock

[Altera_Forum]

Hi there, 

 We have some old design modules from way back and being used in several products. The design is messy and doesn't have any documentation, making it quite time-consuming to rewrite and/or debug them. Sometimes we got hold time violations in the design and it is the most likely because the design uses both edges of clocks.   My questions are:  How does QII implement a design like this? Does QII automatically invert the clock and put both clocks (the one and the inverted one) on global networks? If it doesn't, is there an easy way to constraint the design?  Thanks, Hua

[Altera_Forum]

--- Quote Start ---  Hi there,  We have some old design modules from way back and being used in several products. The design is messy and doesn't have any documentation, making it quite time-consuming to rewrite and/or debug them. Sometimes we got hold time violations in the design and it is the most likely because the design uses both edges of clocks.   My questions are:  How does QII implement a design like this? Does QII automatically invert the clock and put both clocks (the one and the inverted one) on global networks? If it doesn't, is there an easy way to constraint the design?  Thanks, Hua  --- Quote End ---    Hi,  how large and how many hold time violation do have in your design ?  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  Does QII automatically invert the clock and put both clocks (the one and the inverted one) on global networks?  --- Quote End ---  It always did with my designs. Even the classic timing analyzer is able to handle this situation correctly.

[Altera_Forum]

Using both edge of the clock should normally not produce hold violations (unless you mean setup violations). 

 The most common cause of hold violations is clock skew produced by a derived, gated or buffered clock.  I never tried to manually invert a clock, because usually is not needed (see below). If for some reason the timing analyzer considers the inverted clock as a buffered non-inverted clock, it might report fake hold violations.  There is no need to invert and route and inverted clock. All the registers in the device have a programable clock inversion. You only specify the usage of the opposite edge by using the corresponding HDL construct, such as negedge in Verilog.

[Altera_Forum]

--- Quote Start ---  Hi,  how large and how many hold time violation do have in your design ?  Kind regards  GPK  --- Quote End ---    The design module is quite small and when I have hold time violations I usually have one or two.  Thanks, Hua

[Altera_Forum]

Thanks vjAlter. 

   --- Quote Start ---   If for some reason the timing analyzer considers the inverted clock as a buffered non-inverted clock, it might report fake hold violations.   --- Quote End ---    How do I find out if that's the case? The failed data path is actually between two registers clocked by the inverted clock.     --- Quote Start ---    There is no need to invert and route and inverted clock. All the registers in the device have a programable clock inversion. You only specify the usage of the opposite edge by using the corresponding HDL construct, such as negedge in Verilog.  --- Quote End ---    It's an VHDL design. Are you suggesting that if I use something like "if clk'event and clk='0' then", QII should aumatically invert the clock locally in a LE? The design is actually written in that way....

[Altera_Forum]

--- Quote Start ---  How do I find out if that's the case? The failed data path is actually between two registers clocked by the inverted clock.   --- Quote End ---    It shouldn't happen in that case. I was thinking, since you mentioned it was a messy old design, that the clock was being manually inverted, or that some clock was being gated or derived. But this would affect only transfers from the original to the derived clock, not between two registers using the same clock.  There are a couple of fitter settings to optimize hold timing. But it might be better to check before, the timing analyzer reports. You might want to post relevant portions of the report here.    --- Quote Start ---  It's an VHDL design. Are you suggesting that if I use something like "if clk'event and clk='0' then", QII should aumatically invert the clock locally in a LE? The design is actually written in that way....  --- Quote End ---    Yes. To be more precise, the inversion is performed at LAB level.

[Altera_Forum]

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.

[Altera_Forum]

--- Quote Start ---  As far as I remember, previous FPGA families didn't have a local clock inversion.  --- Quote End ---    At the very least, Apex and Flex families had LAB level clock programmable inversion.

[Altera_Forum]

--- Quote Start ---  The design module is quite small and when I have hold time violations I usually have one or two.  Thanks, Hua  --- Quote End ---    make a try with : Setting -> Fitter Settings -> Optimize hold timing -> All paths  Of course you should look for the root cause of the hold time violations.  Kind regards  GPK

[Altera_Forum]

--- Quote Start ---  make a try with : Setting -> Fitter Settings -> Optimize hold timing -> All paths  Of course you should look for the root cause of the hold time violations.  Kind regards  GPK  --- Quote End ---    Thanks GPK, I did have that checked in the setting.  Hua

[Altera_Forum]

--- 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?

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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?

[Altera_Forum]

--- 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

[Altera_Forum]

Forgot attachment? :D

[Altera_Forum]

--- Quote Start ---  Forgot attachment? :D  --- Quote End ---    Hi,  no idea what happend ???:confused:

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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.

[Altera_Forum]

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!

[Altera_Forum]

I got the hold time violation again in a compilation today. Here is the timing report with the clock paths. Can we tell why there is a large skew from the clock paths?