Honored ContributorThis might be a stupid question but I'm dealing with another persons design right now.
If I put a non clock signal to the clock input of a flip flop to store a value of an edge triggered event is Quartus II and TimeQuest always going to see that signal as a clock? Thanks.
Honored ContributorYes. But you can tell TimeQuest to treat it as a false path. You can also just specify some really slow irrelevant clock constraint for the clock. Or you can just ignore the warning completely.
JakeHonored ContributorIf you can avoid it - just dont do it.
use a clock enable instead, then you wont need to worry about false paths or silly timing constraints.Honored ContributorClocks will trickle through logic, but if you have a ripple clock, i.e. the output of a register drives the clock of another register, the clock won't go through that. A create_generated_clock needs to be applied to that register. Note that running Report Unconstrained Paths in the TimeQuest will identify this ripple clock as an unconstrained clock, so you don't have to know them all beforehand(considering it's someone else's design).
Honored ContributorThanks for the responses. I saw the signals in the Unconstrained Paths in TimeQuest. I didn't want to declare them as clocks since they weren't. I also tried adding a the clock to the flip flop with a clock enable and the old clocking signal to an asynchronous load. I then grounded the clock enable so that it would never load on the clock signal. In the RTL viewer the output of the register is just going to ALOAD but TimeQuest and Quartus are still calling it a clock. I'll try using create_generated_clock to the register.
The person I'm working with wants to store a count value every time a certain event happens so that the count value can be read out externally. I'm supposed checking the timing on his design for him and learning TimeQuest but he's using a bunch of latches in his design. Everything I read says latches are bad for timing and I try to tell him but he doesn't listen and I don't know verlog well enough to show him a better way. Am I crazy or should he be using registers instead of latches?Honored ContributorAsk him why he's using a latch? Note that latches are not built into the silicon, and hence are built out of fedback LUTs or with asynchronous control signals on the registers, i.e. complex structures that take more area, have worse performance, and are harder to timing analyze. Now, there are occasionally cases where a latch is necessary, but 99% of the time I see them they really want a register, or a latch is inferred by mistake because the user didn't define what a combinatorial node gets under a certain condition, and HDL dictates it "keeps its old value", i.e. a latch. And when I say 99% of the time, I'm lowballing my estimate.
