How would you constrain this design? enter image description here

ext_clk and clk_in are asynchronous to each other. clk_div is derived by clk_in with double period.

clk_out may be driven by either clk_in and ext_clk, according to the selector pin of the multiplexer.

This is what I would do:

create_clock -period 42 -waveform {0 21} [get_ports "clk_in"]
create_clock -period 300 -waveform {0 21} [get_ports "ext_clk"]
create_generated_clock -name clk_out -source [get_ports "clk_in"] -divide_by 2 [get_pins "xmux/y"]
create_generated_clock -name clk_out -source [get_ports "ext_clk"] [get_pins "xmux/y"] -add

I am not totally sure this is the proper way to constrain this design. What do you think will be the impact of these constraints to the CTS generation in terms of balancing for the logic clocked by clk_out if it talks, mutually exclusive, with the logic driven by clk_in and ext_clk?

  • \$\begingroup\$ What do you mean by "if it talks...with the logic driven by clk_in and ext_clk"? How are you planning to use clk_out? This sounds very dangerous to me. \$\endgroup\$ – Elliot Alderson Jul 26 '18 at 16:24
  • 1
    \$\begingroup\$ You should check if the clock management blocks/tiles/whatever in your FPGA offer a glitch-free clock multiplexer. \$\endgroup\$ – The Photon Jul 26 '18 at 16:42
  • \$\begingroup\$ clk_out clocks a module which has a set of inputs also dependent to the select pin of the mux. I mean that inputs are driven coherently with the selection of the mux \$\endgroup\$ – camillo_benso Jul 26 '18 at 16:45
  • \$\begingroup\$ This is a bad "gated clock" design, and it can't be constrained. See Dave's answer. \$\endgroup\$ – Ale..chenski Jul 26 '18 at 17:10
  • \$\begingroup\$ Ali that's not a gated clock design, I am not involving any enable nor inhibiting the clock \$\endgroup\$ – camillo_benso Jul 26 '18 at 17:18

If the clocks are asynchronous (to each other), there are no meaningful constraints you can place between them.

You need to create a constraint for clk_out that represents the "worst case" for any of the possible clock inputs, and use that to evaluate the rest of the design.

The rest of the design must also be able to handle the timing violations that will occur when you change the control on the mux.

Note that there are more sophisticated (synchronous) clock switching techniques that can avoid creating "runt pulses", etc. that will make the design of the downstream logic simpler. These are usually built into the FPGA/ASIC vendor's clock management IP. You might want to read up on that.

| improve this answer | |
  • \$\begingroup\$ Thanks Dave, with "worst case" you mean shaping clk_out with the highest frequency that can come from clk_in or ext_clk i guess. The switching technique is not part of the problem at the moment, actually I have already implemented it safely, in order to avoid any case of glitch (that mux is just for representation purposes, it's not really there) \$\endgroup\$ – camillo_benso Jul 26 '18 at 17:22
  • 1
    \$\begingroup\$ I can only comment on what I can see. The quality of the question pretty much dictates the quality of the answers. \$\endgroup\$ – Dave Tweed Jul 26 '18 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.