FPGA timing constraints
cgracey
Posts: 14,152
in Propeller 2
I'm having a devil of a time getting these compiles done.
I added some timing constraints to make sure that the data was settling after the clock for the DAC outputs. That works. Meanwhile, the crazy optimizer sees these paths, which it construes as being very late, and can't get around to optimizing what matters.
Does anybody know about SDC constraints and what I need to do to make this work?
I added some timing constraints to make sure that the data was settling after the clock for the DAC outputs. That works. Meanwhile, the crazy optimizer sees these paths, which it construes as being very late, and can't get around to optimizing what matters.
Does anybody know about SDC constraints and what I need to do to make this work?
Comments
Just a thought could it be that the free version of the tools have some limitations ? (I read somewhere that you were using the free version, that the paid one didn't offer anything more).
I found this video which helps, though it's from Xilinx, not Altera:
I set up the output delays to what has been working, and then set those to false paths to get the optimizer out of the picture:
# setup derive_pll_clocks -use_tan_name create_clock -period "20 ns" -name {clock_50} {clock_50} create_clock -period "10 ns" -name {clkbuf} {clkbuf} set_false_path -from [get_keepers {*clkcfgi*}] -to [get_keepers {*clkcfg*}] set_false_path -to [get_ports dac_*] set_false_path -to [get_ports dac0_clk] set_false_path -to [get_ports dac1_clk] set_output_delay -clock clkbuf -max -rise 4 [get_ports dac_*] set_output_delay -clock clkbuf -max -fall 4 [get_ports dac_*] set_output_delay -clock clkbuf -min -rise 4 [get_ports dac_*] set_output_delay -clock clkbuf -min -fall 4 [get_ports dac_*] set_output_delay -clock clkbuf -max -rise 1 [get_ports dac0_clk] set_output_delay -clock clkbuf -max -fall 1 [get_ports dac0_clk] set_output_delay -clock clkbuf -min -rise 1 [get_ports dac0_clk] set_output_delay -clock clkbuf -min -fall 1 [get_ports dac0_clk] set_output_delay -clock clkbuf -max -rise 1 [get_ports dac1_clk] set_output_delay -clock clkbuf -max -fall 1 [get_ports dac1_clk] set_output_delay -clock clkbuf -min -rise 1 [get_ports dac1_clk] set_output_delay -clock clkbuf -min -fall 1 [get_ports dac1_clk]This, I think (as it seems to work), ensures that the output data to the DACs change 3ns after the clock changes, providing Tcycle - 3ns of setup time. This may all just be wrong-headed, though. We'll see what the result does. It's one hour into a two-hour compile and I'm going to sleep.
If anyone suspects flakiness at 120MHz, do a 'SETCLK #$7F' to drop down to 60MHz and see if things behave differently. The Fmax for 16 cogs is coming in at around 82MHz. So, we are overclocking by ~46%. The Fmax, of course, assumes high temp, low voltage, and worst process, which all amounts to SLOW expectations. The lighter 4-cog compiles are getting Fmax values of ~94MHz, which means we are only overclocking by ~28% in those cases.
None of the recent changes really inspired me to update.
Was going to wait until changes actually stopped...
If you have a working SETCLK feature, perhaps on the next build consider a change to default choice ?
* default to 60MHz, and allow users to increase to 120MHz -or-
* default to RC osc value, (20MHz min now?) and go up from there
* If there is a PLL+Divider in FPGA, start from 240MHz and support /2,/3,/4... as values, which will add 80MHz to 120M & 60M, and allow same-as-before operation.
One risk of starting at 120MHz, is if someone's system is flaky, it may not run far enough to change SETCLK....
I was thinking the same thing. Just before I read your message, I had changed things to start up at 60MHz, with a 'SETCLK #$FF' needed to get to 120MHz.
And it's exactly 10 clocks per USB bit period.
looking forward to taking V19 for a test drive.
Fa=120M*0x1999/2^16 = 11998901.37 or 91.5ppm low (USB FS can tolerate 2500ppm)
actual effect is to sometimes divide by 11, but mostly divide by 10
To find how frequently those /11 appear :
K = 1093 Ff = 1/(((K-1)*10/120M+1*11/120M)/K) = 11998902.2
K = 1092 Ff = 1/(((K-1)*10/120M+1*11/120M)/K) = 11998901.2
1-Ff/Fa = 13.973ppb difference (because it is not exactly every 1092 USB bits)
1092/12M = 91us (appx) frame for repeat of the 8.33' ns jitter error in the ideal 83.33' ns period
or around once every 136 bytes of data.
It's much better than 80MHz, even if nominally outside the jitter number I found earlier.
The 1ms frame rate, should be free of this effect, by using a wait framed to a precise 120000 SysCLKS, and systems that lock RC osc to USB, do so using the Frame-rate.
A sampled USB system should not care, and a PLL based one, should be ok with a 1:1092 impulse.