MAX V - Reliability in design issues

You have an combinationally generated clock, which is likely to fail due to glitches even if there are no domain crossing signals between i_clock and SAWTOOTH_CLOCK domain.

SAWTOOTH_CLOCK <= '1' when ( cont_reg < 3 ) else '0';

At this point I stopped checking for possible additional design issues. I guess, the design never passed timing analysis?

Hello,

I ran a timing analysis using TimeQuest and generated a SDC file using TimeQuest analyser wizard. It seems that many time constraints are not fulfilled. Moreover, when I open my wizard generated SDC file, I read comments like:

“# Automatically calculate clock uncertainty to jitter and other effects.

# derive_clock_uncertainty

# Not supported for family MAX V”

The problem here seems to be the generation of the 12.5 MHz clock from a 100 MHz input clock. I would have done this using a PLL on a FPGA but I cannot do that on a CPLD. Is there a way to properly create a generated clock with VHDL or should I think of another approach to build this block?

Thank you in advance for your comments.

Fabe

SDC file:

# Clock constraints

create_clock -name "clk" -period 10.000ns [get_ports {clk}]

create_generated_clock -name clk_sawtooth -source [get_ports {clk}] -divide_by 8 [get_registers {Sawtoothx:inst|cont_reg[2]}]

# Automatically constrain PLL and other generated clocks

derive_pll_clocks -create_base_clocks

# Automatically calculate clock uncertainty to jitter and other effects.

# derive_clock_uncertainty

# Not supported for family MAX V

# tsu/th constraints

set_input_delay -clock "clk" -max 0.5ns [get_ports {reset}]

set_input_delay -clock "clk" -min 0.125ns [get_ports {reset}]

# tco constraints

set_output_delay -clock "clk" -max 0.25ns [get_ports {CS}]

set_output_delay -clock "clk" -max 0.25ns [get_ports {DOUT}]

set_output_delay -clock "clk" -max 0.25ns [get_ports {SCLK}]

# tpd constraints

set_max_delay 0.125ns -from [get_ports {reset}] -to [get_ports {CS}]

set_max_delay 0.125ns -from [get_ports {reset}] -to [get_ports {DOUT}]

set_max_delay 0.125ns -from [get_ports {reset}] -to [get_ports {SCLK}]

Ok, thanks FvM and dsl for your suggestions :)

Created a separate COMPONENT triggered by the 100 MHz clock to create my 12_5MHz clock and instanciated in "Sawtoothx" entity. It seems to work better. I will try an "enable" signal if I see some other issues.

--- Quote Start ---

Created a separate COMPONENT triggered by the 100 MHz clock to create my 12_5MHz clock and instanciated in "Sawtoothx" entity. It seems to work better. I will try an "enable" signal if I see some other issues.

--- Quote End ---

A component doesn't change anything. At least SAWTOOTH_CLOCK must be registered. (It might be that the combinational expression for SAWTOOTH_CLOCK maps to a single FF output. In this case, it would be glitch-free without being explicitely registered)

You have several domain crossing signals with i_clock as launching and SAWTOOTH_CLOCK as latching clock which likely causes timing violations, e.g. current_state.

I guess there's no substantial reason for this clock topology. Using SAWTOOTH_CLOCK respectively a new signal that is active for one i_clock cycle as a clock enable is however the straightforward way to get rid of domain crossing problems.

Or don't register any internal signals under i_clock control.

Hello,

Taking into account your suggestions with clock enable signal, I made some modifications (Attachment). Would the functioning be more robust now and would the synthesiser would synthetize this properly without glitches?

Thank you in advance for your comments.