MAX V - Reliability in design issues

[Altera_Forum]

 Hello,  I am having trouble to develop a consistent/reliable program on a CPLD MAXV reference 5M2210ZF256C5. I am using the free version of Quartus v13.1.3 64Bits. The input clock of the system is 100MHz.    I have used different programming inputs to program different blocks into my CPLD: Verilog HDL, VHDL and schematic. As the amount of blocks started to increase, I noticed some strange behaving of my CPLD. Time to time, I change some parameter of the design into some block and I have another block not working on the same way or at all. For example, I am using a block to store the serial number of the CPLD program which I increment for every revision and just changing the serial number has some impact somewhere else on the design. I tried to work on the different blocks and optimize their speed as much as possible but I still find the same type of issues. Do you think that such issues could be solved out by buying the licensed version of Quartus and use the “LogicLock™ incremental design capability” of Quartus?    I have attached a vhdl code that I would like you to check. As described above, this block works properly time to time depending of the serial number affected to another block. I just cannot get that! The serial number is defined using an LPM_CONSTANT plugin and depending of the value of the constant, the vhdl code attached works on a different way even if the serial number LPM_CONSTANT plugin is not connected at all to the block below!    Your help is greatly appreciated.   Thanks,  Fabe

[Altera_Forum]

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?

[Altera_Forum]

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}]

[Altera_Forum]

Generate an 'enable' signal that is active every 8th clock and use it to qualify all the logic that needs to run at 12.5MHz

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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.

[Altera_Forum]

I didn't the design in depth but the clocking looks good now.

[Altera_Forum]

Ok, thanks for your comment FvM.