Quartus and Cyclone programming problem

Sounds like a logic race. Maybe you don't have a clock input. Maybe you have a clock, but some inputs are not synchronizied to it. Consider posting your code.

-- Mike Treseler

I do not have the code for the week end but it begins like this

PROCESS (clk, rst) BEGIN IF rst = '0' THEN -- asynchronous reset (active low) state Maybe you have a clock, but

Nick, I have seen startup issues with state machines as well. Using synch state machines and asynch resets. Using Quartus 4 spX. A couple thoughts from what I read on Altera's website and just trying stuff. Make sure your state machine is using one-hot encoding, and define all states. This may solve random startup issue. If not try using a 3rd party tool like leonardo. (I think this ultimately fixed our issue.

- Rich

Async resets are evil. They are, well, asynchronous. Using a one-hot state machine doesn't solve the problem. It might reduce the probability (size of window), maybe even enough so you won't see it easily. Are you running a few lab tests or do you need a solid system?

This gets discussed here frequently. The usual context is the global reset signal that the hardware provides. It's slow enough so that even if it is synchronous at the pins, it's probably several clocks of prop time on high speed systems. (and hence logically asynchronous)

The usual advice is to make your own local synchronous reset signal that is derived from the global reset signal and use that to reset a state machine (or a clump of local logic).

You can also design your system so that an async reset will be good enough. The trick is to make sure that any signal that will cause a state change (out of the reset state) doesn't happen until a while after the reset goes away. (That "a while" has to cover the skew in the reset signal.)

Even if you had a fast global reset signal, it won't solve the problem if you have more than one clock.

Well, basically for my test I use a switch for the reset, if it's at 1 the state machine should start, if it's at 0 the state machine should reset. I would really like to have a fairly long reset that I can control for my tests. And my clock is only 32 MHz As long as the design isn't too big it works. And after a certain amount of complexity it doesn't anymore

Thank you for your answer, I shall try using Leonardo, and i'll keep you informed.

Happy new year to you all

Nick

By the way, the Wishcode interconnection system

I try to stick to this specification to get adaptable and easy to use modules

Nick

Hi Nick,

The timing analyzer in Quartus II 4.2 has the ability to perform Recovery and Removal Analysis. Here is the excerpt on the definition of the Recovery/Removal analysis from the Online Help: "Reports the results of setup checks for paths that have an asynchronous clear, preset, or load signal. This report could alert you to a condition in which an active clock edge occurs too soon after the asynchronous input goes inactive, thus rendering the data uncertain. When you turn on the Enable Recovery/Removal analysis option, the Timing Analyzer determines the minimum amount of time required between an asynchronous control signal going inactive and the next active clock edge, compares this to your design, and reports the results as slack following timing analysis."

To turn on the Enable Recovery/Removal analysis option, use the Assignments (Menu)->Timing Settings->More Settings->Enable Clock Recovery/Removal Analysis and turn it on.

Hope this helps.

- Subroto Datta Altera Corp.

Hi Nick,

It sounds like your reset is sometimes close to a clock edge, and hence skew on it leads to some of your flops coming out of reset one cycle (or more) before others. That leads to a bad reset, where the ones that come out of reset early grab a bad next-state value based on a circuit state where some FFs are still being held in reset, and some aren't.

You should use Quartus' recovery and removal timing analysis feature to check that the reset will bring all flops out of reset in the same clock cycle, well away from an active clock edge.

A good way to ensure that happens:

- If all your logic is +ve edge-triggered, register your async reset signal with a series pair of -ve edge triggered FFs. This avoids metastability, and creates a synchronized reset that now changes well away from active clock edges. Quartus will automatically route this reset signal on a global network to minimize its skew. Its still best to run a recovery and removal analysis though, since this is a timing constraint, and in my opinion you should always check all your static timing constraints.

Hope this is helpful, Vaughn Betz Altera v b e t z (at) altera.com [remove spaces and use proper @ to reach me]

Hello, and thank you all for your answers

In my design i had 3 modules, each driven by the same clock and reset, all on the rising edge of the clock, processing states machines. I did change the clock of one of the module to have it on the falling edge (it was the middle module of the design) and it worked. Switching to Quartus 4.2 helped as well.

Regards Nick