04-24-2014 07:25 AM
When testing the new Vivado 2014.1 suite, I discovered that Vivado (not just the latest version) seems to ignore part/speed-grade specific timing constraints (at least for MMCM).
In this simple example, two MMCMs in a xc7z010clg400-1 part pass synthesis and implementation without a single error or warning, despite the fact, that the first one configures a VCO frequency below 600MHz, and the second one a clock output above 800MHz, which both are, according to ds187, out of spec.
Maybe I'm missing the obvious and I somehow have to enable additional checks so as usual, any input on topic is appreciated!
Thanks in advance,
04-24-2014 07:48 AM
thanks again for the testcase! Makes advising you so much easier :)
the maximum VCO frequency is not 800MHz, but 1200MHz:
the minimum is indeed 600MHz. Let me check your testcase.
04-24-2014 02:13 PM
thank you for reporting this!
I've taken a look at the reports and there are several CRs that I will file. Not all parameters are correct and it's not stopping the generation of a bitstream, which should.
04-24-2014 02:28 PM
Yes! You can count on it. I hope this is still in time for 2014.2 (june). I think this is important enough.
04-24-2014 04:34 PM
Btw, I added a BUFR and BUFG (example code attached), which both have maximum frequencies below the generated ones, and the design still synthesizes and implements without warning, so it's not just the MMCM, I presume most device limits are ignored.
Anyway, thanks for picking this up.
PS: any idea why the WEB interface doesn't allow VHDL files (as .vhd) to be attached, claiming that the contents does not match the filetype?
04-24-2014 05:57 PM
Pulse width violations (min period, max period, min high pulse width, min low pulse width, clock pins skew) are not performed by synthesis or implementation. They are only performed by:
1) The official timing signoff command: report_timing_summary
2) The interactive debug/analysis command: report_pulse_width
The log file and reports of your testcase prove it:
| Command : report_pulse_width -significant_digits 3 -all_violators
Check Type Corner Lib Pin Reference Pin Required Actual Slack Location Pin
Min Period n/a MMCME2_ADV/CLKOUT0 n/a 1.249 1.143 -0.106 MMCME2_ADV_X0Y0 mmcm_inst1/CLKOUT0
Regarding Warning and Error messages when such violation is found: it is true that Vivado never issued a specific message about these violations in non-project flow until 2014.1. In 2014.1, the report_timing_summary and report_timing commands have an additional switch: -warn_on_violation. It needs to be explicitely called by the user, else the only way to find out about the violation is by actually reading the slack numbers reported.
Important note: the project mode DOES issue a critical warning at the end of implementation.
Regarding the VCO problem: it is reported by report_drc (which is also run by default in project-mode). You can all the default DRCs by just calling report_drc with no option, or be more specific about bitstream generation rules by calling it as follow:
report_drc -ruledeck bitstream_checks
In the case of your design, you would have seen the following message:
The computed value 587.500 MHz (CLKIN1_PERIOD, net clk_125_IBUF) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X0Y1 falls outside the operating range of the MMCM VCO frequency for this device (600 - 1200 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please adjust either the input period CLKINx_PERIOD (8.000000), multiplication factor CLKFBOUT_MULT_F (47.000000) or the division factor DIVCLK_DIVIDE (10), in order to achieve a VCO frequency within the rated operating range for this device.
Related violations: <none>
Last important point: timing violations are not treated as an error for bitstream generation, because they are not destructive for the device. They will only cause malfunction in HW. It is the user responsibility to review timing signoff and bitstream generation messages before programming the device. Again, if you pay attention to the write_bitstream log, it does mention 3 warnings to be reviewed with report_drc:
Running DRC as a precondition to command write_bitstream
INFO: [Drc 23-27] Running DRC with 2 threads
INFO: [Vivado 12-3199] DRC finished with 0 Errors, 3 Warnings
INFO: [Vivado 12-3200] Please refer to the DRC report (report_drc) for more information.
Conclusion: there is no bug here.
Vivado provides 2 main use models:
1) Project mode: the tool will run all recommended checks and flag the issues more clearly, especially in the GUI.
2) Non-project mode: the user is in charge of following the recommended flow and reports, which are documented in UG949 (UltraFast Methodology), as well as in the various User Guides.
I hope this helps clarifying the issues you flagged.
Thanks for sharing your feedback.
04-24-2014 06:21 PM
Thanks a lot for the detailed explanation! Truly appreciated!
I will immediately add the report_drc to my build scripts.
I was just a little confused by "The design met the timing requirement" when it clearly didn't.
Now everything is clear and I'm prefectly fine being in charge of the flow :)
04-30-2014 01:52 AM
I want to thank you again for reporting this problem!
Your testcase also made it easy for me to file the CRs.
I filed 3: