Hold time violations and clock distribution

Question

Hello all,

I am working on designing a zero-operand stack machine in an Altera FPGA using the Flex EPF10k70Rc240-4 together with a custom memory simulator that includes a variable clock, which I've specified in Quartus Timing settings as having fMax of 440kHz, which is accurate for this clock. I'm using Quartus II 9.0 web edition.

I have some major questions about timing issues, which I hope someone can help shed some light on for me. This is my first project using VHDL and an FPGA, so I'm coming from a beginner's perspective here.

I'm getting the "Warning: Can't achieve minimum setup and hold requirement clock along 115 path(s)" warning when I compile. I've researched as much as I can in the Quartus II help as well as on the Altera forums and tried everything I can to fix the timing errors, but I must still be missing something--or the problem is simply inherent to my design, in which case I'm also not sure how to go about fixing it.

Some more information on the specific problem: I activated the "Design Assistant" under Assignments->Settings->Design Assistant, and checked off all the boxes, hoping to get some insight into the timing (and any other) problems. Indeed, it gave me the following helpful warnings:

critical warning: (high) rule c105: clock signal should be a global signal. (value defined:25). found 1 node(s) related to this rule.

critical warning: node "clock"

critical warning: (high) rule d101: data bits are not synchronized when transferred between asynchronous clock domains. found 116 asynchronous clock domain interface structure(s) related to this rule.

critical warning: (high) rule d103: data bits are not correctly synchronized when transferred between asynchronous clock domains. found 42 asynchronous clock domain interface structure(s) related to this rule.

warning: (medium) rule d102: multiple data bits that are transferred across asynchronous clock domains are synchronized, but not all bits may be aligned in the receiving clock domain. found 4 asynchronous clock domain interface structure(s) related to this rule.

As the first warning suggests (as well as a number of related Quartus Help pages), my clock signal seems to have a huge fanout since I have many different entities in my project, and this seems to be leading to massive clock skew and the corresponding timing problems. I wasn't sure how to make the clock a "global signal", but I followed some of the Quartus help guides and in the Assignment Editor, I made a new setting for the clock, where I set the "Auto Global Clock" option to "On". Quartus suggested that this should solve the problem. Unfortunately, that actually had no effect at all, so I tried option B--manually making the clock a "global signal" in my main package, taking the explicit port mapping of "clock" out of all of my entities and port maps throughout the project, and referring to the new "global signal" throughout (there is information on this on page 248 of Peter Ashenden's 'Designer's Guide to VHDL', which I followed). This was another option that the Quartus Help had suggested. Unfortunately, when I finally made all those changes, Quartus gave me the error:

error (10808): vhdl error at vds.vhd(112): unsupported reference to global signal or variable clock

I looked further into this on the web and in the Altera forums, and it appears that global signals are actually not supported for synthesis (despite the fact that Quartus itself suggested I make the clock a global signal....). Huh.

As far as I can understand, then, it seems that what I'm left with is a clock with a huge number of fanouts that essentially renders the project asynchronous since the clock signal is arriving at different places at different times--and no obvious way to resolve it. I may be misinterpreting the problem, of course (which is hopefully the case, and hopefully the solution is easier than redesigning / scrapping the whole project).

I've attached the entire project as a Quartus archive (.qar) file, as well as attaching a few of the main .vhd files separately for those who aren't running Quartus right on their desktops at the moment (ST0.vhd is the main project file; TOP_LEVEL.vhd describes the top level of the datapath; VDS describes the virtual data stack logic...). Apologies for lack of comments in the files--I've redone the design so many times that I got lazy about commenting the last time around. I'll fix it when I have a working design...

Any insights would be GREATLY appreciated, and many thanks in advance.

Robert

altera_forum · Answer

To begin with I doubt you can get 440MHz in any altera device except for tiny logic portions.

FPGA clock rules are well established:

use minimum number of base clocks. All clock inputs must be connected to dedicated clock pins. Use PLLs to make internally derived clocks, if you have to use logic instead(gated clock) then use clock mux and connect it back to global tree. Otherwise do not use gated clocks.

When crossing clock domains use fifo or equivalent logic to transfer data and apply two stage or more synchroniser.

Setup violation is caused by too fast clock while hold violation is caused by clock delay(gated clk).

altera_forum · Answer

Thanks very much for the reply! The variable clock is 440 KILOhertz--yeah, my design definitely could not take 440MHz, on an Altera FPGA or otherwise. In fact, the reason I'm using the slower clock and not the 25.125 MHz clock on board the Altera FPGA is to keep speeds slower at first to test the design.

That clock is directly connected from a pin on my connected memory board--I do not use any derived or gated clocks in the design, which is why I'm confused about why the clock signal is being distributed unevenly, and why I (unsuccessfully) tried to specify it as a global signal.

So I'm still perplexed as to why there is such serious clock skew that results in so many hold violations, and why Quartus does not seem to be distributing the clock--which is coming directly from a dedicated pin--evenly to all entities.

altera_forum · Answer

oop... 440KHz makes sense and should be dead easy..apologies

If your clk is connected to clock pin then that means it is global and you should not worry about fanout.

Make sure it is not gated inside the logic. It should only be coded as edge at top of every clked process. No other signal should be used for edge triggering as it implies a clk.

You say you got one clk but quartus talks about clk domains

It is likely you have several internal clks , if so either remove them or use need to use small fifos across domains or use clk enable approach

altera_forum · Answer

Aha! Thank you, that was quite helpful. I was indeed using the on-board 25 MHz Altera clock to debounce the pushbuttons on the Altera board, which I was using to display debugging information on the FPGA's 7-segment display. I was running the rest of the project on the slower variable clock, which also gives me the option to single-step, which is very helpful for debugging the project.

Now, something strange has come of this. If I put the ENTIRE project on the on-board 25 MHz Altera clock and disable and don't use the off-board variable clock, it compiles without errors. Wonderful! The problem is that I would *really* like to have the project running on the 440 KHz clock for general debugging purposes and so I can single-step through clock cycles.

Now, again, the whole project works when I put it all on the 25 MHz on-board clock. But when I put everything on the 440 KHz clock, I get 2 critical warnings:

critical warning: (high) rule c105: clock signal should be a global signal. (value defined:25). found 1 node(s) related to this rule.

critical warning: node "clock"

and

critical warning: timing requirements for slow timing model timing analysis were not met.

as well as

warning: can't achieve minimum setup and hold requirement clock along 185 path(s). see report window for details.

The only difference here is that I'm port mapping the off-board 440 KHz clock instead of the on-board 25 MHz clock.

It seems, from the first Critical Warning, that it is not recognizing the 440 KHz clock signal (which that warning is referring to) as a global signal and is therefore not distributing it evenly. As I noted in my first message, I tried to set this clock as a "Global Signal" and "Auto Global Clock -> On" in the Assignment Editor, but was given a corresponding error message by Quartus that I couldn't do that:

warning: ignored global signal assignment for i/o pin "clock" because it is user assigned to a non-global pin location.So I'm still confused about why the off-board 440 KHz clock is causing the problems it is, and how to resolve it so that I can use it. It really is very important for debugging purposes.

Thank you VERY much for your help and time so far--I really do appreciate it.

Robert

altera_forum · Answer

It looks like your 440KHz is connected to user io and not dedicated clk pin.

Option 1: programming the 25MHz to give 440KHz at source.

option2: keep things same and use 440 signal as clk enable. this requires connecting it to any clk enable in your project(anding) or creating clk enable statement after every edge statement.

option3: divide 25MHz internally to 440 then make the division output global.

accepting global may not be supported in your device. Flex devices are I believe too old and phased out.

Forum Discussion

Hold time violations and clock distribution

9 Replies

Recent Discussions

[Agilex 7F] How to setup my EMIF IPs for the toolkit?

Realistic values for set_max_skew

Failing IO buffer

Fitter stalls on "Advanced Physical Optimization" on Windows 10

IOPLL related clock constraints