Hello, Well, the title might not be very exact. I have programmed big states machines in VHDL with quartus 4.1sp2. They all have an asynchronous reset, and i have leds to see what's going on for debug purpose. When i'm in the reset state, i must have a pattern on my leds. BUT, the bigger my state machine got, the stranger the behaviour. If I remove some access to the leds later in my state machine (not in the reset, but in a true state), all my leds are off during my reset, or sometimes only some are off, given the operation I add or remove IN COMPLETLY OTHER STATES, or even in others modules. I have really no idea of what is going on. My design is not yet very big (900 LE) and there are no really speed constraint on it. Could someone please explain me what I can do so wrong ? Best regards, and happy new year Nick
Quartus and Cyclone programming problem
Started by ●December 30, 2004
Reply by ●December 30, 20042004-12-30
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
Reply by ●December 31, 20042004-12-31
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 <= reset;
oadr <= "00000000000000000000000";
odat <= "00000000000000000000000000000000";
osel <= "1100";
counter <= 0;
oled1 <= '0'; -- light up when at 0
oled2 <= '0';
ELSIF clk'event AND clk = '1' THEN
-- here is the state machine
I came to the point of changing something in the state machine made
the led don't light up
Since the reset is asynchronous, it shouldn't be a clock related
problem, could it ?
Best regards, and thank you for your answer
Nick
On 30 Dec 2004 15:26:36 -0800, "Mike Treseler"
<mike_treseler@comcast.net> wrote:
>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
Reply by ●January 1, 20052005-01-01
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
Reply by ●January 1, 20052005-01-01
>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.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. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
Reply by ●January 2, 20052005-01-02
On Sat, 01 Jan 2005 20:03:24 -0600, hmurray@suespammers.org (Hal Murray) wrote:>>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. > >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)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
Reply by ●January 2, 20052005-01-02
>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?By the way, the Wishcode interconnection system http://www.opencores.org/projects.cgi/web/wishbone/wishbone requires an async reset, unless I get it completly wrong. I try to stick to this specification to get adaptable and easy to use modules Nick
Reply by ●January 2, 20052005-01-02
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.
"Nick" <char-DONTBUGME-les@YY.iiedotcnam.france> wrote in message
news:7vh8t0p2gkjg44904vfo6hppufeeu7t227@4ax.com...
> Hello,
>
> Well, the title might not be very exact. I have programmed big states
> machines in VHDL with quartus 4.1sp2. They all have an asynchronous
> reset, and i have leds to see what's going on for debug purpose. When
> i'm in the reset state, i must have a pattern on my leds.
>
> BUT, the bigger my state machine got, the stranger the behaviour. If I
> remove some access to the leds later in my state machine (not in the
> reset, but in a true state), all my leds are off during my reset, or
> sometimes only some are off, given the operation I add or remove IN
> COMPLETLY OTHER STATES, or even in others modules.
>
> I have really no idea of what is going on. My design is not yet very
> big (900 LE) and there are no really speed constraint on it.
>
>
> Could someone please explain me what I can do so wrong ?
>
>
> Best regards, and happy new year
>
> Nick
Reply by ●January 6, 20052005-01-06
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] "Nick" <char-DONTBUGME-les@YY.iiedotcnam.france> wrote in message news:nkeft0p16he6k60fb2fnae6tood9gh3tt2@4ax.com...> On Sat, 01 Jan 2005 20:03:24 -0600, hmurray@suespammers.org (Hal > Murray) wrote: > > >>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. > > > >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) > > > 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
Reply by ●January 7, 20052005-01-07
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 On Thu, 6 Jan 2005 00:31:08 -0500, "Vaughn Betz" <no_spam@altera.com> wrote:>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] > >"Nick" <char-DONTBUGME-les@YY.iiedotcnam.france> wrote in message >news:nkeft0p16he6k60fb2fnae6tood9gh3tt2@4ax.com... >> On Sat, 01 Jan 2005 20:03:24 -0600, hmurray@suespammers.org (Hal >> Murray) wrote: >> >> >>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. >> > >> >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) >> >> >> 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 >
