UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
7,765 Views
Registered: ‎06-28-2008

ISIM lost one state when simulating a three-process FSM

Jump to solution

Hello,everybody!

ISE 12.4 , ISE simulator.

 

Last week I wrote a three-process FSM verilog code and simulated it .

 I found the state was lost using ISIM .

My code is below---

 

......// other code

 

reg [3:0] CS;// current state

reg [3:0] NS;// next state

parameter IDLE = 4'd0,

S1=4'd1,

S2=4'd2,

S3=4'd3;

 

// 1st process fsm

always @(posedge clk)

if (rst)

CS <= IDLE;

else

CS <= NS;

 

// 2nd  process fsm

always @(CS or iq_dout_valid or flag)

begin

NS = 4'bx;

 

case(CS)

IDLE:begin

NS = S1;

end

S1:begin

if(iq_dout_valid)

NS = S2;

else

NS = S1;

 

S2:begin

if(flag)

NS = S3;

else

NS = S2;

end

 

S3:begin

NS = IDLE;

end

end

endcase

end

 

// 3 rd process fsm

always @(posedge clk)

if (rst)

begin

lxdata <= 0;

flag <= 0;

end

else

begin

case(NS)

IDLE:begin

lxdata <= 0;

flag <= 0;

end

S1:begin

lxdata <= 0;

flag <= 0;

end

S2:begin

lxdata <= iq_dout[15:8];

flag <= 1'b1;

end

S3:begin

lxdata <= iq_dout[7:0];

flag <= 0;

end

endcase

 

end

 

......// other code

 

initial

begin

clk = 0;

 rst = 1;

iq_dout = 0;

iq_dout_valid = 0;

 

#100 rst = 0;

#100 iq_dout = 14'h AB12;  // correct

    iq_dout_valid = 1;

#40 iq_dout_valid = 0;

 

#110 iq_dout = 14'h AA55; // wrong

    iq_dout_valid = 1;

#40 iq_dout_valid = 0;

end

 

always #10 clk = !clk;

endmodule

 

Using ISIM, when iq_dout = 14'h AB12,the result is  correct.

And I got the NS state from IDLE-S1-S2-S3-IDLE...

 

when iq_dout = 14'h AA55,the result is  wrong.

And I got the NS state from IDLE-S1-S3-IDLE...

S2 is lost !!!

The iq_dout timing is also wrong because the non-blocking assignment should get the result at the next clock,not the current clock, as we know.

 

Then I used Modelsim 6.4 to simulate it again, all of the results are correct. No state was lost.

 

I think maybe the ISIM can not recognize the style of three-process FSM or the algorithm of the simulator updates the NS immediately without considering the clock!!!

I do not know.

Can anyone help me ???

 

 

process

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
10,081 Views
Registered: ‎08-14-2007

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

As you said, it's the racing condition in the testbench that cause the problem.

But I think maybe the blocking assignment code of the 2nd fsm is the key , not the testbench. It's blocking assignment so it will update the output immediately when the condition meets.

No.  Blocking assignments are entirely appropriate for a combinatorial process.  However in a

synchronous system, the inputs to the combinatorial process should be stable long enough

before each clock edge to meet setup time at the combinatorial outputs.  In this case, there

is only the module input "iq_dout_valid" (driven by the test bench) which did not come from

a non-blocking assign in a clocked process.  So yes, the outputs of the combinatorial

process (#2) will depend on the input timing, but this doesn't really change the overall

design behavior when the input setup tim is met, because the outputs of the combinatorial

process are only used internally within clocked processes.  Now if any of the combinatorial

outputs left the module, I'd say that was a problem.

 

 CS = S1, then iq_dout_valid = 1, at that time , as the 2nd fsm running, NS= S2 immediately. At the same time , the clock posedge is coming, because NS=S2, so flag = 1 immediately , then as the 3rd fsm running , flag = 1 updates at the time due to non-blocking assignment in behaviorial simulation. So when flag = 1,as the 2nd fsm running, NS= S3 immediately again.Therefore the short S2 is lost.

Yes, this is the race condition.  In the real world, your state machine needs some amount of setup and

hold time.  The race condition in the test bench violates this.  In behavioral simulation, setup and hold

times are zero, but there are simulation "delta" delays that affect the order of computation.  The blocking

assigns in your module code really make no difference as long as the test bench uses non-blocking

assigns so that the synchronous input  iq_dout_valid is guaranteed to be sampled only after the

clock event by all processes.  The race condition sort of models the case of asynchronous inputs

to a state machine that cause problems because of different arrival times to different flip-flops.  In

the behavioral simulation case, the different arrival times to different processes cause the same issues.

If you did a post P&R timing simulation, then there's a good chance that the design would work

(if its hold time requirement was zero or negative), but if it didn't work you'd see a hold time error

from the flip-flop model.

 

Last but by no means least, is thestyle of 3-process fsm reliable and recommendable??? I used to write 1-process fsm only, all my code is non-blocking assignments. And another engineer recommended the 3-process fsm style. As he said ,the 2nd fsm describes the state transition clearly, the 3rd one describes the output only, the non-blocking assignment in the 3rd fsm can prevent unstable output.

There is a history to this style of state machine coding that goes back to deficiencies in early

synthesis tools.  The general consensus with modern tools is that you can write state machines

any way you like, but most people find the single process style easier to understand and debug

and less fraught with unintended consequences.  This does not make a well-debugged 3-process

state machine any less reliable, though.  In the end the hardware you generate will look the same.

the devil is in getting it to work in the first place and being able to maintain it in the long run.  Any

style that is easier for you and your colleagues to understand is the best style.  My personal view

is that having a single process with outputs assigned next to the state transition logic makes

it easier to follow the flow.  But some people have been using other styles for many years and

might have a different opinion.

 

Regards,

Gabor

-- Gabor
8 Replies
Teacher rcingham
Teacher
7,762 Views
Registered: ‎09-09-2010

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution
A penny to a pound says somebody will tell you to stop using 3-process FSMs...
(As I don't use Verilog I can't offer detailed help.)

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Instructor
Instructor
7,758 Views
Registered: ‎08-14-2007

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

If I had to guess, I'd say the problem is in the test bench.  Your clock is defined to change

state every 10 ns starting at 0 from time 0.  So on every odd multiple of 10 ns there is a rising

clock edge.  Then your stimulus is always running on an even multiple of 10 ns until

this line:

 

#110 iq_dout = 14'h AA55; // wrong

which causes iq_dout and iq_dout_valid to change exactly at the rising clock edge.  Furthermore

since the clock is toggled in a different process and both processes use a blocking assign

statement, this is actually a race condition, meaning you don't know for sure whether the clock

or iq_dout and iq_dout_valid will toggle first.

 

When you are preparing test benches for synchronous signals, it's usually safer to perform your

test bench timing using the clock like:

 

initial begin

  #200 ; // wait some time

  // Note the non-blocking assign here.  It makes sure that the stimulus

  // is seen only on the following clock edge by the UUT:

  @ (posedge clk) stimulus <= some_value; // then wait for a clock edge

  repeat (10) // wait some cycles

  @ (posedge clk) ;

  stimulus <= some_other_value;  // Again a non-blocking assign

  @ (posedge clk) ;

  stimulus <= #1 some_other_value;  // Again a non-blocking assign with 1 ns hold time added

  . . .

end

 

In your case, where there is only a single clock and you used a simple period of 20 ns,

it is also easy to just make all of your #delays a multiple of the clock period.  But as

you move on to more complex designs you should get used to using the clock itself

to time the stimulus.  That also makes it much easier to change your frequency without

rewriting the entire testbench.

 

HTH,

Gabor

-- Gabor
Instructor
Instructor
7,754 Views
Registered: ‎08-14-2007

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

@rcingham wrote:
A penny to a pound says somebody will tell you to stop using 3-process FSMs...
(As I don't use Verilog I can't offer detailed help.)

Oh, yeah - I almost forgot.  Ditch the 3-process FSM.  It's harder to read, and it leads to

all kinds of unexpected problems like latches and simulation/synthesis mis-match.  You should

get used to a single (clocked) process FSM.

 

-- Gabor

-- Gabor
Teacher eteam00
Teacher
7,751 Views
Registered: ‎07-21-2009

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

In 2nd (of 3) FSM processes

  • state S1 has a begin without a matching end
  • state s3 has an extra end

Did you happen to lose state S2, by any chance?

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Instructor
Instructor
7,745 Views
Registered: ‎08-14-2007

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

@eteam00 wrote:

In 2nd (of 3) FSM processes

  • state S1 has a begin without a matching end
  • state s3 has an extra end

Did you happen to lose state S2, by any chance?

 

-- Bob Elkind


What surprises me is that S2: in this context would not create an error at compile time,

since it is inside a begin/end block and not at the case level.  Perhaps it happened when the code

was edited for posting?  Also the fact that the test bench almost worked in ISIM and worked

in ModelSim seems to point to this being a difference between code posted here and the

code actually simulated.  Finally, after re-reading the original post I'm willing to bet a quality

beer on the problem being the race condition I mentioned - that can also explain the difference

in outcome between the two simulators.

 

Regards,

Gabor

-- Gabor
0 Kudos
Explorer
Explorer
7,735 Views
Registered: ‎06-28-2008

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

Sorry, I just made a mistake when I posted the code, losing the "begin end"thing in the 2nd fsm, but my code is correct when I simulated it otherwise the simulator would report an error. And I will accept your testbench style.Thanks.

 

As you said, it's the racing condition in the testbench that cause the problem.

But I think maybe the blocking assignment code of the 2nd fsm is the key , not the testbench. It's blocking assignment so it will update the output immediately when the condition meets.

 

 CS = S1, then iq_dout_valid = 1, at that time , as the 2nd fsm running, NS= S2 immediately. At the same time , the clock posedge is coming, because NS=S2, so flag = 1 immediately , then as the 3rd fsm running , flag = 1 updates at the time due to non-blocking assignment in behaviorial simulation. So when flag = 1,as the 2nd fsm running, NS= S3 immediately again.Therefore the short S2 is lost.

 

 In fact, the S2 state should hold at least one clock as usual. But,when I changed the testbench and simulated it in Isim, it will change from one clock to 1/2 clock (like AB12 testbench ) and even zero(like AA55 testbench) gradually. Although the code is like software at first glance, but it describes a hardware thing so the sequence of the action of the circuit is important. I think if the code is correct , different simulators should give the same result.Maybe different algorithms decides the result.

 

Last but by no means least, is thestyle of 3-process fsm reliable and recommendable??? I used to write 1-process fsm only, all my code is non-blocking assignments. And another engineer recommended the 3-process fsm style. As he said ,the 2nd fsm describes the state transition clearly, the 3rd one describes the output only, the non-blocking assignment in the 3rd fsm can prevent unstable output.

 

In addition, several weeks ago I have lent the manual of a RTL coding check tool-- LEDA of SYNOPSYS,Inc. I remember that it said the tool can recognize 1-process,2-process and 3-process fsm but I have not read the relevant chapters.

 

If the code is correct, then the circuit is stable.Otherwise,it will not work.

 

 Which one should I choose ? 1-process or 3-process???

 

0 Kudos
Teacher eteam00
Teacher
7,731 Views
Registered: ‎07-21-2009

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

Last but by no means least, is thestyle of 3-process fsm reliable and recommendable??? I used to write 1-process fsm only, all my code is non-blocking assignments. And another engineer recommended the 3-process fsm style. As he said ,the 2nd fsm describes the state transition clearly, the 3rd one describes the output only, the non-blocking assignment in the 3rd fsm can prevent unstable output.

 

Old designer proverb:

A man with but one trouser pocket knows where to find his car keys.  A man with 3 trouser pockets is never sure.

 

I just made this up, it seemed to be appropriate and useful.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Instructor
Instructor
10,082 Views
Registered: ‎08-14-2007

Re: ISIM lost one state when simulating a three-process FSM

Jump to solution

As you said, it's the racing condition in the testbench that cause the problem.

But I think maybe the blocking assignment code of the 2nd fsm is the key , not the testbench. It's blocking assignment so it will update the output immediately when the condition meets.

No.  Blocking assignments are entirely appropriate for a combinatorial process.  However in a

synchronous system, the inputs to the combinatorial process should be stable long enough

before each clock edge to meet setup time at the combinatorial outputs.  In this case, there

is only the module input "iq_dout_valid" (driven by the test bench) which did not come from

a non-blocking assign in a clocked process.  So yes, the outputs of the combinatorial

process (#2) will depend on the input timing, but this doesn't really change the overall

design behavior when the input setup tim is met, because the outputs of the combinatorial

process are only used internally within clocked processes.  Now if any of the combinatorial

outputs left the module, I'd say that was a problem.

 

 CS = S1, then iq_dout_valid = 1, at that time , as the 2nd fsm running, NS= S2 immediately. At the same time , the clock posedge is coming, because NS=S2, so flag = 1 immediately , then as the 3rd fsm running , flag = 1 updates at the time due to non-blocking assignment in behaviorial simulation. So when flag = 1,as the 2nd fsm running, NS= S3 immediately again.Therefore the short S2 is lost.

Yes, this is the race condition.  In the real world, your state machine needs some amount of setup and

hold time.  The race condition in the test bench violates this.  In behavioral simulation, setup and hold

times are zero, but there are simulation "delta" delays that affect the order of computation.  The blocking

assigns in your module code really make no difference as long as the test bench uses non-blocking

assigns so that the synchronous input  iq_dout_valid is guaranteed to be sampled only after the

clock event by all processes.  The race condition sort of models the case of asynchronous inputs

to a state machine that cause problems because of different arrival times to different flip-flops.  In

the behavioral simulation case, the different arrival times to different processes cause the same issues.

If you did a post P&R timing simulation, then there's a good chance that the design would work

(if its hold time requirement was zero or negative), but if it didn't work you'd see a hold time error

from the flip-flop model.

 

Last but by no means least, is thestyle of 3-process fsm reliable and recommendable??? I used to write 1-process fsm only, all my code is non-blocking assignments. And another engineer recommended the 3-process fsm style. As he said ,the 2nd fsm describes the state transition clearly, the 3rd one describes the output only, the non-blocking assignment in the 3rd fsm can prevent unstable output.

There is a history to this style of state machine coding that goes back to deficiencies in early

synthesis tools.  The general consensus with modern tools is that you can write state machines

any way you like, but most people find the single process style easier to understand and debug

and less fraught with unintended consequences.  This does not make a well-debugged 3-process

state machine any less reliable, though.  In the end the hardware you generate will look the same.

the devil is in getting it to work in the first place and being able to maintain it in the long run.  Any

style that is easier for you and your colleagues to understand is the best style.  My personal view

is that having a single process with outputs assigned next to the state transition logic makes

it easier to follow the flow.  But some people have been using other styles for many years and

might have a different opinion.

 

Regards,

Gabor

-- Gabor