Hold time violations and clock distribution

[Altera_Forum]

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]

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]

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]

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]

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]

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.

[Altera_Forum]

Thank you again for your reply, Kaz.  

 I would like to use the off-board clock directly, since it allows me to single-step through my programs' operation.  So ideally I'd like to go with option 2 that you listed there--but I'm not quite sure what you mean I should do in option 2. The project only compiles if I run everything off of the 25MHz clock, and will not compile if I run everything off of the slower clock. If I try to use both clocks for different purposes (which seems like a bad idea...), I get all sorts of warnings about crossing clock domains, etc.  Sorry it's taking me some time to understand, and thanks for your patience.

[Altera_Forum]

Option 4: Insert a LCELL primitive in between the signal coming from the pin and the signal that is actually used in your design. 

 clk_lc : LCELL port map ( in => clock_from_pin, out => clock );  (Hope my VHDL isn't too bad)  Quartus will then be able to promote "clock" to a global signal.  http://quartushelp.altera.com/9.1/mergedprojects/hdl/prim/prim_file_lcell.htm

[Altera_Forum]

@rbugalho: 

 Thank you SO much. That is exactly what I was looking for--just a way to distribute the off-board clock globally throughout the design in order to eliminate the timing skew caused by distributing that clock as a non-global.   Your suggestion worked, and helped me resolve a week's worth of debugging efforts, so thanks again very much.   One final quick question--when I did route the off-board clock through the LCELL buffer, all the timing warnings went away, but I did get one new warning, coming from Design Assistant:  critical warning: (high) rule a103: design should not contain delay chains. found 1 delay chains.  As far as I can tell, having a delay chain on the global clock shouldn't actually be a problem since the slightly delayed clock will simply be distributed equally throughout the rest of the design, correct? If I'm missing something here, please let me know.  Again, thanks a whole lot for your help.  Robert

[Altera_Forum]

Hello,  

you are very welcome. Glad your problem has been solved.  You are correct: going through the LCELL will add a bit of delay but then it will be distributed equally.  The warning is actually about something else.  Sometimes, people attempt to use chains of LCELLs to delay signals, which isn't a good idea -- those delays are quite dependent on process, temperature, voltage, etc.  Since this isn't what you're trying to do and you don't care about the delay, it's not an issue for you.