New Contributor
Regular ContributorYour project file references a timing constraint file (andromeda.sdc) but you don't include it.
Do your designs compile AND MEET TIMING under both versions of Quartus?
How much slack is there in the worst case timing path(s)?
Are your clocks correctly constrained?
New ContributorHi ak6dn,
Thanks for your response.
I can't provide the .sdc as it was written by a contracted 3rd party and there may be some intellectual property issues. The compilation reports said all timing constraints were met for both versions.
I've attached the sta reports if you want to look at them, but here is a worst-case summary from the sta report:
Slow 1200mv 100C model
Slow 1200mv -40C model
Fast 1200mv -40C model
I would have thought if timing constraints were met in both cases, it would work with either version of Quartus. Also, all inputs and outputs between the SPI/QSPI module and top level ports are registered.
One thing I noticed, in the .sdc file, the QSPI ports all have set_false_path and there's a note from the 3rd party who wrote it, that this was done since all inputs are synchronized with 2x registers to the 100MHz clock (which I've confirmed in the source code).
Some extra background is the original standard SPI version of the code was developed by 3rd party FPGA experts. Then I modified the SPI to have a QSPI read mode as well. Both versions work when compiled with v15.1.0, but don't work when compiled with v17.0.2.
Thanks for your help.
Regular ContributorSeveral comments:
SET_FALSE_PATH is going to remove any timing constraints on those paths from the referenced clock. So you won't know of those paths are failing as they aren't checked. Be careful with using that directive.
Do both SPI and QSPI modes fail in the v17 compiled version? Or just QSPI?
The timing values in the reports for v15 vs v17 are pretty close, so it looks like nothing is wildly off.
Which generated clock is the SPI logic working off?
New ContributorIf I use TimeQuest and do a "Report Path" with -from and -to for all the SPI input and output ports at the toplevel, this is what I get:
For v15.1.0:
-from
-to
For v17.0.2:
-from
-to
From the timing reports of the paths, the slack seems like it's not too bad for the 10ns clock period. I don't quite get why even though the SET_FALSE_PATH for those ports listed above are in the sdc, I can still get the timing reports of the paths. I need to learn how to do timing constraints properly still. I'm guessing it's not constrained, but resulted in the numbers above? Those are only the paths -from or -to the toplevel ports and the SPI module pins I believe. I can't seem to get proper reports for the paths -from / -to the pins in the SPI module itself.
Both SPI and QSPI modes fail with v17.0.2. When it fails, the DSP reads back bad data intermittently, whereas with v15.1.0 the data read back is always correct.
The SPI module is clocked from PLL[0] which is the 100MHz clock.
Does it make sense that the original 3rd party used SET_FALSE_PATH because they are using 2x synchronizers on the inputs clocked to the internal 100MHz system clock and not using the external SPI CLK as a clock in the FPGA?
The note in the .sdc states
# False paths, since the design treats the SPI inputs
# by the internal fast system clock (no use of SPI_CLK as a clock)
Regular ContributorHi,
Since you have a timing clean report, the design should work as designed. You may check with the designer whether the false path constraint is applied to the intended path.
Thanks.
Best regards,
KhaiY
