Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16886 Discusiones

Change clock propagation through multiplexers

Fromhell777
Principiante
2.521 Vistas

When reading though the Quartus documentation I noticed that when a mux is present on the clock network both clocks are propagated through and kept related.

The proposed solution is to use the "create_generated_clock" statement in the SDC file on the mux output for both input clocks.

For example when you have two input clocks that you want to have in the same clock group like this:

                   ______
clk_a -----|          |
                   | mux |----- output
clk_b -----|_____|

create_clock -name clock_a -period 10 [get_ports clk_a]
create_clock -name clock_b -period 10 [get_ports clk_b]
create_generated_clock -name clock_a_mux -source [get_ports clk_a] \
	[get_pins clk_mux|mux_out]
create_generated_clock -name clock_b_mux -source [get_ports clk_b] \
	[get_pins clk_mux|mux_out] -add
set_clock_groups -exclusive -group {clock_a clock_a_mux clock_b clock_b_mux}

set_false_path -from [get_clocks "clock_a_mux"] \
-to [get_clocks "clock_b_mux"]
set_false_path -from [get_clocks "clock_b_mux"] \
-to [get_clocks "clock_a_mux"]

 

But is it possible to have this as the default behavior with a setting?

When you have a couple of muxes after each other in the design the amount of constraints really explodes.

It is almost impossible to go over all these cases in a large design.

When this behavior could be changed this would simplify the constraint process.

If Quartus was also smart enough to analyze if clocks after muxes could be related or not, this would also simplify a lot of things.

For example when you have 2 muxes, both with the clk_a and clk_b as input.
And these 2 muxes have the same selector. Quartus could detect that clock_a_mux0 can never be active at the same time as clock_b_mux1.

This saves the user from incorporating all these cases in their constraints.

Does Quartus do this kind of analysis?

0 kudos
7 Respuestas
EngWei_O_Intel
Empleados
2.493 Vistas

Hi there

The constraint for clock are for the purpose of timing analysis. It would be user preference to construct how the clocks behave. Different users might code differently on the clock network and usage. You may refer to some link below for better arrangement of your design constraints. 

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_timequest_cookbook.pdf

https://www.intel.com/content/www/us/en/programmable/support/support-resources/design-examples/design-software/timinganalyzer/clocking/tq-clock-groups.html

 

Thanks.

Eng Wei

 

Fromhell777
Principiante
2.487 Vistas

It's just strange that this is the default behaviour of Quartus since you almost never want this to happen.
It is only in very rare cases so I would think that there maybe was a setting for this.

But independent from the different user preference, I would expect Quartus to do some kind of analysis to know which clocks can be active at the same time. Or at least some simple checks. That could already solve many unnecessary timing fixes in the design.

P.S.: I do not see how your references can simplify my example case. If so, please explain to me

EngWei_O_Intel
Empleados
2.450 Vistas

Hi there

The link I was sharing consist Clock Multiplexer Constraints and other constraints example that you can use. On the tools side, there is no automation for this at this point of time. 

 

Thanks.

Eng Wei

 

 

skyjuice
Empleados
2.434 Vistas

Think of it this way - I have 2 inputs to a mux (clkA and clkB), and you're right only one clock will be selected. Let's assume for a specific scenario, clkA is selected and somewhere in the the downstream logic, it will need to perform a transfer to clkB and this will need to be timing-analyzed. 

If the tool where to cut all clkA <--> clkB paths, then the mentioned path will be affected, which is not what we want.

Fromhell777
Principiante
2.430 Vistas

So you are confirming that these needlessly complex constraints need to be constructed to describe this almost standard expected behaviour?

I' m not saying that the case with one mux is complex but the complexity increase exponentially when you have more muxes in a row. I needed to define almost 20 extra generated_clocks for just 4 muxes in a certain clock tree. On top of that I needed to analyse very carefully how to set the false_paths for each of these clocks individually.

EngWei_O_Intel
Empleados
2.411 Vistas

There are many variables (such as selector's variable, launch register clock and latch register clock relationship and etc) to be considered for timing analysis. If constraints doesn't exist, unnecessary timing report details might got generated. 

 

Eng Wei

EngWei_O_Intel
Empleados
2.365 Vistas

Hi there

 

I am transitioning this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

 

Eng Wei

Responder