- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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?
Enlace copiado
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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.
Thanks.
Eng Wei
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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.
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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.
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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
- Marcar como nuevo
- Favorito
- Suscribir
- Silenciar
- Suscribirse a un feed RSS
- Resaltar
- Imprimir
- Informe de contenido inapropiado
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
- Suscribirse a un feed RSS
- Marcar tema como nuevo
- Marcar tema como leído
- Flotar este Tema para el usuario actual
- Favorito
- Suscribir
- Página de impresión sencilla