--- Quote Start ---
For your collection, you've found how to get it's contents, but you could also do:
query_collection -report -all $regs
--- Quote End ---
Nice :)
--- Quote Start ---
Is d driven by an input or a register? Let's say it's a register for the more complex case...
--- Quote End ---
The current application is as described in the response to Frank.
--- Quote Start ---
I imagine most of the time, users wouldn't constrain this at all.
--- Quote End ---
Sorry, my original post didn't really make this point clear; I want to constrain the toggle register in the sense that I want to tell TimeQuest to ignore that particular timing path. I have ensured that the pulse is clean and of sufficient length to meet any particular requirements of the register. In this particular application, the pulse will be generated either in a 6MHz domain, or 50 to 100MHz domain.
--- Quote Start ---
I tend to stay away from embedding constraints in the HDL. There are some very good uses for it. Heck, Altera does it in things like the DCFIFO, which is a great way to use it rather than having people add an .sdc for each FIFO and all the problems when they forget it. I find TimeQuest's way of embedding constraints to be clunky to say the least, and just not standard practice. It's easy to miss that these constraints are occuring. I know people that would strongly argue for embedding them, and I think it's perfectly valid and there are many good points, I've just stayed away from it.
--- Quote End ---
I also prefer explicit inclusion of constraints. TimeQuest would generate a warning on this particular component, since it would find an unconstrained clock, so if the user forgets the .sdc file, they'll get reminded.
As I comment to Frank, I think in this particular case, the synchronizer should be modified to be one in which both input and output clocks are used, and that way the normal asynchronous constraint between the JTAG clock and core clock will cut this timing path for me.
However, I'm curious as to the TimeQuest syntax needed to eliminate the clock warning generated by the scheme I first proposed. I'll look at the TimeQuest command you comment on;
--- Quote Start ---
... You're right in that you would cut its timing from the clk, which could be done with false path of set_clock_groups ...
--- Quote End ---
Thanks!
Cheers,
Dave
Honored Contributor
