#SYNPLIFY PRO CLOCK CONSTRAINT MANUAL#
#SYNPLIFY PRO CLOCK CONSTRAINT PRO#

I cant remember but I think it was warning that it didn't do the clock conversion because I didn't explicitly say it was a clock, thus the warning. So I think what it did was infer a generated clock, then complained because I was making it guess while asking it to convert clocks (default option was on). Gated clocks get converted to something similar where the gating is applied to CE instead of CLK, and CLK just gets the master clock.Д«ut it can't do this conversion if it isn't sure what is a clock. The point seems to be to keep the clock edges as in sync as possible with the master clock to avoid problems. Apparently it's better to have all FFs clocked by the master clock, then to get slower clocks on some of them you drive the CE (clock enable) pin on the FFs with a derived clock.

#SYNPLIFY PRO CLOCK CONSTRAINT PRO#

Part of the reason this matters for Synplify Pro is that it will do gated clock conversion and generated clock conversion to optimize for the clock tree routing on an FPGA. In this specific trivial case it doesn't really matter, but I got a warning message complaining that synthesis had inferred a generated clock and that I should explicitly declare it.

Timing requirements can still fail on FPGAs can't they? I'm a bit stumped on this particular issue though because I just don't have enough experience to know what will best help avoid problems in more complex designs.Д®dit: specifying that the slow clock is a derived clock with an extremely long period doesn't work because the 'clock' is so slow that it exceeds the maximum clock period for timing analysis. This trivial design will work regardless, but right now I'm more concerned with figuring out how the synthesis tools work in as much detail as possible and tinkering with a simple design to see how the output changes. Should I be trying to use the output of the 'slow clock' module directly or should I run the master clock to the led counter module and then gate it with the slow clock? Should I set the clock frequency at all in the HDL or should I leave that out and only set it in synthesis options? Or do I need to set it in the HDL and manually match it up with synthesis options?ДЇor things like clocks driving counters that then output a 'clock', what's the proper way to set constraints? Do I configure it as a false path, a multi cycle path, or what?

#SYNPLIFY PRO CLOCK CONSTRAINT MANUAL#

I can read the manual and set constraints here but it's not very clear what the best practices are for clock constraints. Now the important part: when I synthesize this with Synplify pro it correctly detects the primary clock but then detects the 'slow clock' module as a clock and gets the timing wrong. That output then goes to a blinky led module that counts up infinitely and reveals the state of the 8 bit counter on some LEDs. That clock then connects to a module that increments a counter and flips an output register every 100000 cycles.

What I did was instantiate the internal oscillator block (OSCH) for the MachXO3 and defparam'd the frequency to the minimum of 2.08 in Verilog. I'm fiddling with the options using a trivial blinky led design using two counters and 8 LEDs. Right now I'm trying to get a handle on the best way to set clock speed and timing constraints, specifically using Synplify Pro.

Synplify pro clock constraint