cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
351 Views
Registered: ‎12-20-2018

constraints for BUFGMUX with MMCM reconfiguration

Hello everybody,

I have a design that uses a BUFGMUX and two MMCM, those MMCM are dynamically reconfigured many times, both start at 10mhz and could go up to 600mhz , what is the correct way of generating constraints for BUFGMUX output  to make vivado point 600mhz as implementation target?

0 Kudos
4 Replies
Highlighted
Moderator
Moderator
250 Views
Registered: ‎11-04-2010

Re: constraints for BUFGMUX with MMCM reconfiguration

If the MMCM's output clock cannot have the derived 600Mhz clock, you need to create_generated_clock on the output clock pin of MMCM to overridden the original derived one 

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
221 Views
Registered: ‎12-20-2018

Re: constraints for BUFGMUX with MMCM reconfiguration

thank you for the answer, I've trying many variants of create_generated_clock, but can't get one to do what I want

Tags (1)
0 Kudos
Highlighted
Observer
Observer
178 Views
Registered: ‎12-20-2018

Re: constraints for BUFGMUX with MMCM reconfiguration

I was looking at "create generated clock" from "edit timing constrains" and this should also generate mmcm/pll, I don't want this, I already have the 2 mmcm with state machine for dinamic reconfiguration to the requested frequency. actually I'm setting one of the mmcm at 600mhz, the other at 10mhz.  A bufgmux keeps the 600mhz clock off and after some seconds from bitstream loading is reconfigured at 10mhz. when requested both clock are configurable at desired frequency.

I would like to avoid this, to lower effort on implementation causing a lot of timing problems

also tried things like this:

create_generated_clock -period 2 -name CLK -waveform {0.000 1.000} [get_pins IOpins_and_clocks/BUFGMUX_instMAIN/O]

without succes

0 Kudos
Highlighted
Guide
Guide
169 Views
Registered: ‎01-23-2009

Re: constraints for BUFGMUX with MMCM reconfiguration

The easiest thing to do is to set the initial values of the MMCM so that they are running at the highest frequencies - this way the tool will time them by default at the highest frequencies. If the setup checks work at the highest frequencies, then they will work at any lower frequency AS LONG AS you make sure that any paths between clocks are properly handled (manually) to work at all frequencies. Hold time checks are not frequency dependent so (at least within the clock domain) if they pass at any frequency, they will work at all frequencies - again, I am just referring to the setup and hold checks within this domain (synchronous paths) - any clock crossing paths have to be dealt with manually assuming all possible frequency relationships (fast to slow, slow to fast, fast to fast and slow to slow).

If this isn't possible (i.e. you need your bitstream to start at a lower frequency) then, for static timing purposes, you will need to override the clock coming out of the FPGA with the fastest possible clock. This may be able to be done with a create_generated_clock (I have never tried to do this through an MMCM - it probably will work, but there is a chance it won't since there isn't a "normal" propagation path through the MMCM). If it does work, you need to tell us the input frequency in order to construct the command. A create_generated_clock cannot specify a clock period - it can merely specify a relationship between the source clock (which for an MMCM is the input clock on CLKIN) and the generated clock; I will assume the input clock is 100MHz - this means that you need to multiply the clock by 6 to get the 600MHz clock you need

create_generated_clock -name clk600 -source [get_pins <path_to_MMCM>/CLKIN] -multiply_by 6 [get_pins <path_to_MMCM>/CLKOUT0]

If this doesn't work, then you will have to create a primary clock on the output of the MMCM. It is generally very strongly recommended that you don't do this - but if you understand the limitations of this (and it's your only choice) then it will be OK. The main limitations are:

  • The static timing engine will not be able to correctly determine the phase of this primary clock with respect to any other synchronous event in the system. This means:
    • The clock (or any clock derived from it) cannot be used as the reference for a synchronous input or output port
      • The only exception to this would be a source synchronous (clock forwarded) output interface where the clock and data are both sourced from this clock
    • The clock cannot have any synchronous clock domain crossing with any other clock in the system (except to domains that are derived from the primary clock)
      • Any data passing between a domain that is related to this clock and a domain that is not related to this clock would need a proper clock domain crossing circuit

Avrum

0 Kudos