cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hpoetzl
Voyager
Voyager
14,510 Views
Registered: ‎06-24-2013

Vivado not checking MMCM timing?

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,

Herbert

-------------- Yes, I do this for fun!
9 Replies
driesd
Xilinx Employee
Xilinx Employee
14,502 Views
Registered: ‎11-28-2007

Hi Herbert,

 

thanks again for the testcase! Makes advising you so much easier :)

 

the maximum VCO frequency is not 800MHz, but 1200MHz:

screenshot_001.jpg

 

the minimum is indeed 600MHz. Let me check your testcase.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
hpoetzl
Voyager
Voyager
14,491 Views
Registered: ‎06-24-2013

Yes, but the maximum MMCM output frequency is 800MHz :)

Thanks,
Herbert
-------------- Yes, I do this for fun!
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,466 Views
Registered: ‎11-28-2007

Hi Herbert,

 

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.

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
hpoetzl
Voyager
Voyager
14,463 Views
Registered: ‎06-24-2013

Okay, so I take it that this will be resolved in a future version of Vivado.

 

Thanks,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,461 Views
Registered: ‎11-28-2007

Yes! You can count on it. I hope this is still in time for 2014.2 (june). I think this is important enough.

 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos
hpoetzl
Voyager
Voyager
14,456 Views
Registered: ‎06-24-2013

Okay, great!

 

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.

 

Best,

Herbert

 

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?

-------------- Yes, I do this for fun!
0 Kudos
frederi
Xilinx Employee
Xilinx Employee
14,452 Views
Registered: ‎03-29-2013

Hi Herbert,

 

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:

 

PDRC-33#1 Warning
MMCM_adv_ClkFrequency_div_dclk  
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.

 

-Fred

hpoetzl
Voyager
Voyager
14,447 Views
Registered: ‎06-24-2013

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 :)

 

Thanks again,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
14,376 Views
Registered: ‎11-28-2007

Hi Herbert,

 

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:

  • VCO frequency out of range should be ERROR
  • Bitstream generation warnings are labelled as INFO message
  • Add warn_on_violation switch to report_pulse_width to make reporting more consistent.

 

Thanks!

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos