Use of a Finite State Machine in testbench code 
Author Message
 Use of a Finite State Machine in testbench code

I have a question about the coding method I should use for writing
testbench code that tests my design.
Right now I am trying to test a PCI IP core that I am working on.
Whoever has done testing on a PCI IP core probably knows that to test
target feature of a PCI IP core, the testbench code has to simulate
the behavior of an initiator (bus master).
In my opinion (this is the first time I am writing a testbench code),
PCI initiator behavior can be pretty complex because, for example, the
target may not respond to the access from the initiator (Master-Abort
Termination), or the initiator may or may not insert wait states
during the first data phase (Master Data Latency. SiS chipset is known
to insert wait cycles like this) which is totally legal according to
the PCI Specification.
To make the testing simple, I implemented a "task" in Verilog that
creates a PCI access cycle.
I used a Finite State Machine (FSM) inside the task.
I guess I did it in an FSM because it made my job easier to
handle error situations like when a Master-Abort Termination occurs
(target not responding to initiator's access), I can change a state to
handle Master-Abort Termination from several other states.
However, about a week ago, I read someone's posting at comp.arch.fpga
that it is not a good idea to write testbench in synthesizable form of
HDL.
I also read a book (I will mention the title later) that repeated the
same thing that testbench code should not use an FSM because it takes
more time to implement it than using control flow statements of
Verilog like "for" or "while" loop of Verilog.
Thinking about how I can implement the task that creates a PCI bus
cycle without using an FSM, I thought if Verilog had "goto" statement
like in C language, it would make my job easier.
        So, what I want to ask here will be, can control flow
statements of Verilog like "for" or "while" loop completely replace an
FSM thinking I have been doing since I started writing synthesizable
code in Verilog?
If control flow statements can completely replace an FSM, how would I
handle error conditions (sort of exceptions) that require several
normal states to jump to the state that handles such conditions?
Also, shouldn't "goto" at least be included in Verilog's syntax?
(although the casual use of "goto" should be discouraged like in C
language)
I can post the FSM version of the task testbench code if that will
help.

Regards,

Kevin Brace (don't respond to me directly, respond within the
newsgroup)



Tue, 20 Apr 2004 15:48:08 GMT  
 Use of a Finite State Machine in testbench code

Quote:

> I have a question about the coding method I should use for writing
> testbench code that tests my design.
> Right now I am trying to test a PCI IP core that I am working on.
> Whoever has done testing on a PCI IP core probably knows that to test
> target feature of a PCI IP core, the testbench code has to simulate
> the behavior of an initiator (bus master).
> In my opinion (this is the first time I am writing a testbench code),
> PCI initiator behavior can be pretty complex because, for example, the
> target may not respond to the access from the initiator (Master-Abort
> Termination), or the initiator may or may not insert wait states
> during the first data phase (Master Data Latency. SiS chipset is known
> to insert wait cycles like this) which is totally legal according to
> the PCI Specification.
> To make the testing simple, I implemented a "task" in Verilog that
> creates a PCI access cycle.
> I used a Finite State Machine (FSM) inside the task.
> I guess I did it in an FSM because it made my job easier to
> handle error situations like when a Master-Abort Termination occurs
> (target not responding to initiator's access), I can change a state to
> handle Master-Abort Termination from several other states.

Since the PCI transaction is essentially a state machine, implementing
the test bench as a state machine makes sense!

Quote:
> However, about a week ago, I read someone's posting at comp.arch.fpga
> that it is not a good idea to write testbench in synthesizable form of
> HDL.

The only reason for that is a behavioural description may be simpler and
simulate somewhat faster.  Also, if you stick to the synthesizable
subset of the language, you miss out on a lot of the neat features that
make testbenching easier.  But there's nothing "wrong" with writing
synthesizable RTL code for your testbench (especially if that
synthesizable RTL code is a real chip you've designed and implemented!).

Quote:
> I also read a book (I will mention the title later) that repeated the
> same thing that testbench code should not use an FSM because it takes
> more time to implement it than using control flow statements of
> Verilog like "for" or "while" loop of Verilog.

My opinion: write the test bench in the simplest correct manner.
Writing (and debugging, remember you need to test the test bench) a
complex FSM is more difficult than writing the simpler behavioural
model, so if you don't need to synthesize, don't bother writing
synthesizable code!

Quote:
>         So, what I want to ask here will be, can control flow
> statements of Verilog like "for" or "while" loop completely replace an
> FSM thinking I have been doing since I started writing synthesizable
> code in Verilog?

Sure.  Why not?  I'm not sure what book you referred to above, but you
might want to pick up Janick Bergeron's "Writing Testbenches" book.
It's what really got me to think about writing non-synthesizable testbenches.

Quote:
> If control flow statements can completely replace an FSM, how would I
> handle error conditions (sort of exceptions) that require several
> normal states to jump to the state that handles such conditions?
> Also, shouldn't "goto" at least be included in Verilog's syntax?
> (although the casual use of "goto" should be discouraged like in C
> language)

Handling errors is part of the architecture of the test bench.  The
answer is, unfortunately, "it depends."

--andy



Wed, 21 Apr 2004 00:52:10 GMT  
 Use of a Finite State Machine in testbench code

Quote:

> My opinion: write the test bench in the simplest correct manner.
> Writing (and debugging, remember you need to test the test bench) a
> complex FSM is more difficult than writing the simpler behavioural
> model, so if you don't need to synthesize, don't bother writing
> synthesizable code!

I agree with you. I usually write my testbench in C++ or in
synthesizable verilog.

Lately FPGA's have become cheaper and denser, and it in some
cases it might be worthwhile to build a testbench prototype device.

Let's say that Kevin made a FPGA prototype of his design. It might not
run at 66 MHz, but at 33 MHz. Still this is quite faster than his
verilog simulator. The price of the prototype card is probably less
than a simulator license too.

He could then synthesize his testbench, implement it in the FPGA, and
stick it in a PCI bus together with his prototype DUT. This would also
give him fast, accurate, and cheap host bridge "models" (for the price
of a motherboard).

Petter
--
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com



Wed, 21 Apr 2004 05:15:31 GMT  
 Use of a Finite State Machine in testbench code

Quote:
> Lately FPGA's have become cheaper and denser, and it in some
> cases it might be worthwhile to build a testbench prototype device.

> Let's say that Kevin made a FPGA prototype of his design. It might not
> run at 66 MHz, but at 33 MHz. Still this is quite faster than his
> verilog simulator. The price of the prototype card is probably less
> than a simulator license too.

For an FPGA prototyping, it is most likely that you have to use some FPGA
sepecific macros (DLL, BlockRAM, etc) in your design. So you end up with two
versions of a design. If the design is simple, you do not really gain much
in speed by using a prototype. If the design is complex, you'll probably
have some headache to maintain two versions of your design.

Without a simulator, you lose the visibility into the internal nets of the
design if something goes wrong unless you add extra DFT featutres that may
not needed in the first place.

Jim



Wed, 21 Apr 2004 06:27:04 GMT  
 Use of a Finite State Machine in testbench code

Quote:

> > Lately FPGA's have become cheaper and denser, and it in some
> > cases it might be worthwhile to build a testbench prototype device.

> > Let's say that Kevin made a FPGA prototype of his design. It might not
> > run at 66 MHz, but at 33 MHz. Still this is quite faster than his
> > verilog simulator. The price of the prototype card is probably less
> > than a simulator license too.

> For an FPGA prototyping, it is most likely that you have to use some FPGA
> sepecific macros (DLL, BlockRAM, etc) in your design. So you end up with two
> versions of a design. If the design is simple, you do not really gain much

This is true, but you can make this less painful if you design clean
interfaces and use the least common denominator, which might cause
some less than optimal performance. It depends upon the design and
application.

Quote:
> Without a simulator, you lose the visibility into the internal nets of the
> design if something goes wrong unless you add extra DFT featutres that may
> not needed in the first place.

Some FPGA vendors have some sort of chip scope functionality. I've
used various type of debug buses in the FPGA design.

My point was that in some cases it might be worthwhile to consider
making your testbench synthesizable, in case it is beneficial to
implement it.

Petter
--
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com



Wed, 21 Apr 2004 07:23:27 GMT  
 Use of a Finite State Machine in testbench code


says...

Quote:

>I have a question about the coding method I should use for writing
>testbench code that tests my design.

>Right now I am trying to test a PCI IP core that I am working on.
>Whoever has done testing on a PCI IP core probably knows that to test
>target feature of a PCI IP core, the testbench code has to simulate
>the behavior of an initiator (bus master).

>In my opinion (this is the first time I am writing a testbench code),
>PCI initiator behavior can be pretty complex because, for example, the
>target may not respond to the access from the initiator (Master-Abort
>Termination), or the initiator may or may not insert wait states
>during the first data phase (Master Data Latency. SiS chipset is known
>to insert wait cycles like this) which is totally legal according to
>the PCI Specification.

Something completely unrelated to your questions that follow, but still
could be useful: you can get FREE PCI bus functional models these days.
I remember seeing one on opencores.org. A year back some sales guy from
iModl.com told they were also thinking to offer it for free but not sure
if that really happenned. Just as any free stuff, these may not be
tailor-made for your need, but it may cut down your development time
considerably.

Quote:

>To make the testing simple, I implemented a "task" in Verilog that
>creates a PCI access cycle.

>I used a Finite State Machine (FSM) inside the task.
>I guess I did it in an FSM because it made my job easier to
>handle error situations like when a Master-Abort Termination occurs
>(target not responding to initiator's access), I can change a state to
>handle Master-Abort Termination from several other states.

As other posters have pointed out, PCI master is indeed a
state machine. PCI Spec 2.2 even has an appendix (App B)
that describes various state machines using state diagrams.
If you have not looked into this part of the spec yet,
I highly recommend you do.

Quote:

>However, about a week ago, I read someone's posting at comp.arch.fpga
>that it is not a good idea to write testbench in synthesizable form of
>HDL.

>I also read a book (I will mention the title later) that repeated the
>same thing that testbench code should not use an FSM because it takes
>more time to implement it than using control flow statements of
>Verilog like "for" or "while" loop of Verilog.

First let me make few observations from your above two paragraphs:

1. It appears to me you are little confused about the synthesizability
of a logic and an FSM. An FSM may not necessarily be always
synthesizable.  Although I have not tried myself, I suspect it is
also possible to write a state machine using such constructs such
as "while" and "for" loop (which are, under certain conditions, will
still be synthesizable) and flops. I have seen FSM (which, coincidentally
happened to be of a PCI master!) written solely using assign statement and

readable, it worked.

2. I do not understand why it would take more time to implement
because you are using "synthesizable logic". May be the book intended
to mean (as other posters have noted) that using some of the more
verification-friendly constructs of Verilog could save you time. Also
you do not need to be careful about the synthesizability of
the logic. I would argue this is probably not true, if you
are already conversant in writing synthesizable logic.

Quote:

>Thinking about how I can implement the task that creates a PCI bus
>cycle without using an FSM, I thought if Verilog had "goto" statement
>like in C language, it would make my job easier.

As I mentioned earlier, even though it would not look

it would still be, by definition, a state mahine in such a
hypothetical case.

Quote:
>        So, what I want to ask here will be, can control flow
>statements of Verilog like "for" or "while" loop completely replace an
>FSM thinking I have been doing since I started writing synthesizable
>code in Verilog?

>If control flow statements can completely replace an FSM, how would I
>handle error conditions (sort of exceptions) that require several
>normal states to jump to the state that handles such conditions?
>Also, shouldn't "goto" at least be included in Verilog's syntax?
>(although the casual use of "goto" should be discouraged like in C
>language)
>I can post the FSM version of the task testbench code if that will
>help.

Given everything, my suggestion will be, go ahead if you want to
implement your PCI master testbench using synthesizable logic,
but be aware, it is neither a requirement, nor does it hurt to
know about the other options regardless of whichever way you
want to implement it.

--
=-=-= 100% pure Verilog PLI - go, get it ! =-=-=
 Principles of Verilog PLI -By- Swapnajit Mittra
 Kluwer Academic Publishers. ISBN: 0-7923-8477-6
 http://www.angelfire.com/ca/verilog/



Thu, 22 Apr 2004 03:01:34 GMT  
 Use of a Finite State Machine in testbench code

Quote:

> Something completely unrelated to your questions that follow, but still
> could be useful: you can get FREE PCI bus functional models these days.
> I remember seeing one on opencores.org. A year back some sales guy from
> iModl.com told they were also thinking to offer it for free but not sure
> if that really happenned. Just as any free stuff, these may not be
> tailor-made for your need, but it may cut down your development time
> considerably.

        Part of the reason I am developing a PCI IP core is to learn
Verilog-HDL.
Therefore, I don't want to rely on someone else's testbench code to
complete my work.
I am personally not a fan of opencores.org, so I don't really feel
like using materials from their website.
The reason I am not a fan of opencores.org is because too many of
their projects are nothing more than a vaporware, and several of their
projects looks like they haven't made any progress in a year.
Besides, are there any IP cores that are meaningful at their website?
Although I suppose my definition of "meaningful" depends on the person
(I personally think almost all of their IP cores are useless stuff).
Basically, I have to agree with Jim Turley's opinion about free IP
core projects.

http://www.eetimes.com/story/OEG20010326S0018

Quote:

> As other posters have pointed out, PCI master is indeed a
> state machine. PCI Spec 2.2 even has an appendix (App B)
> that describes various state machines using state diagrams.
> If you have not looked into this part of the spec yet,
> I highly recommend you do.

        Yes, I do own PCI Specification Revision 2.2.
I don't really find PCI Specification's state machine diagrams (for
target and master) to be that helpful.
I derived my own target state machine without really using Appendix
B's target state machine diagram.
I guess the reason I don't really like the one in the specification is
because the description (transition conditions) look too low level
(looks like PALASM or ABEL description).

Quote:
> First let me make few observations from your above two paragraphs:

> 1. It appears to me you are little confused about the synthesizability
> of a logic and an FSM. An FSM may not necessarily be always
> synthesizable.  Although I have not tried myself, I suspect it is
> also possible to write a state machine using such constructs such
> as "while" and "for" loop (which are, under certain conditions, will
> still be synthesizable) and flops.

        What I meant for an FSM is that a construct made out of an

**************************************************************

    case (PCI_State_Reg)

    endcase

end
**************************************************************

I recently order a book called Writing Tesbenches: Functional
Verification of HDL Model by Janick Bergeron (ISBN: 0-7923-7766-4),
and on Page 84, the book said, "Do not use RTL-like code when writing
testbenches."
He explains that using looping statements like "while" or "for"
statement have higher level of abstraction than using a "case"


My problem of using a "while' or "for" statement in an FSM is that in
case of an error (exception) condition like a target not responding to
an initiator's (testbench code) access, without the use of "goto" like
statement in Verilog that branches out of the code, it is hard to
implement such error conditions (especially if an error can happen in
lots of states).
However, if I implement an FSM with a "case" statement inside a
"while" or "forever" loop, such an FSM gives freedom to move around
the code.
I know that too much freedom is not a good thing, and that is the
reason use of "goto" in C language is discouraged.

Quote:
>  I have seen FSM (which, coincidentally
> happened to be of a PCI master!) written solely using assign statement and

> readable, it worked.

        That is the first type of testbench code I wrote when I tested
my design to got my PCI IP core to just to run on real computers.
Yes, the code looked like a huge mess, and I was totally aware that I
will have to learn a lot about testbench writing strategies in order
to verify my PCI IP core efficiently.
I guess that is the reason I purchased Writing Tesbenches: Functional
Verification of HDL Model recently, and this posting is part of the
process of learning efficient methods to test my design.
By the way, the brute force method of testing helped somewhat, and I
got the PCI IP core to work on two different computers even though the
PCI IP core still doesn't meet timings of 33MHz PCI.

Quote:

> 2. I do not understand why it would take more time to implement
> because you are using "synthesizable logic". May be the book intended
> to mean (as other posters have noted) that using some of the more
> verification-friendly constructs of Verilog could save you time. Also
> you do not need to be careful about the synthesizability of
> the logic. I would argue this is probably not true, if you
> are already conversant in writing synthesizable logic.

The book Writing Tesbenches: Functional Verification of HDL Model on
Page 86 shows that behavior testbench code is a lot more simplier than
the synthesizable looking testbench code.
I think the author wants to say that because there is less code to
write for the behavior testbench code compared to the synthesizable
looking testbench code, it takes less time to implement the behavior
testbench code.
In my case, it was easier to implement the initiator FSM in
synthesizable looking testbench code than the behavior testbench code.
Perhaps that is because I have less experience writing code in
behavior testbench code.

Quote:

> As I mentioned earlier, even though it would not look

> it would still be, by definition, a state mahine in such a
> hypothetical case.

        Yes, I guess I now understand that.
I guess my original title of this posting should have been, "Use of an

in testbench code."

Quote:
> Given everything, my suggestion will be, go ahead if you want to
> implement your PCI master testbench using synthesizable logic,
> but be aware, it is neither a requirement, nor does it hurt to
> know about the other options regardless of whichever way you
> want to implement it.

        Although right now I can implement an FSM in a synthesizable
style code faster, I do see that use of a behavior style code is more
efficient, and potentially faster to implement.

Regards,

Kevin Brace (don't respond to me directly, respond within the
newsgroup)



Thu, 22 Apr 2004 11:37:32 GMT  
 Use of a Finite State Machine in testbench code

Quote:

> Lately FPGA's have become cheaper and denser, and it in some
> cases it might be worthwhile to build a testbench prototype device.

> Let's say that Kevin made a FPGA prototype of his design. It might not
> run at 66 MHz, but at 33 MHz. Still this is quite faster than his
> verilog simulator. The price of the prototype card is probably less
> than a simulator license too.

> He could then synthesize his testbench, implement it in the FPGA, and
> stick it in a PCI bus together with his prototype DUT. This would also
> give him fast, accurate, and cheap host bridge "models" (for the price
> of a motherboard).

The only problem here is that you can't see what's inside the chip, and
that's (by definition?) where the problems are!

I find it "safest" to completely (to the best of my ability, including
building models of other things in the system) simulate the design, and
make the "real" PCB, rather than some test bed.

--a



Sat, 24 Apr 2004 02:13:52 GMT  
 Use of a Finite State Machine in testbench code

Quote:


> > Lately FPGA's have become cheaper and denser, and it in some
> > cases it might be worthwhile to build a testbench prototype device.

> > Let's say that Kevin made a FPGA prototype of his design. It might not
> > run at 66 MHz, but at 33 MHz. Still this is quite faster than his
> > verilog simulator. The price of the prototype card is probably less
> > than a simulator license too.

> > He could then synthesize his testbench, implement it in the FPGA, and
> > stick it in a PCI bus together with his prototype DUT. This would also
> > give him fast, accurate, and cheap host bridge "models" (for the price
> > of a motherboard).

> The only problem here is that you can't see what's inside the chip, and
> that's (by definition?) where the problems are!

As I said earlier most of the FPGA vendors provide some kind of
virtual scope technology which gives you some kind of observability.
You can also make some kind of debug bus where you can output state
vectors and other debug information. If you have some unused RAM in
the FPGA you can use this as a trace buffer, etc. These techniques can
of course be cumbersome if you have many clock domains or if your
utilization and congestion is high, etc.

I'm not promoting this as an alternative to simulation, but as an aid
to simulation. Some financially strong organizations will simply spin
an early ASIC or buy a hardware emulator.

Quote:
> I find it "safest" to completely (to the best of my ability, including
> building models of other things in the system) simulate the design, and

It depends. This is usually the best method, but...

In some cases the simulation times are so long. I've been working on
designs where we have been simulation for months. Then you find a bug
and have to start the loop again.

Other times it's hard to get good models, e.g. all the different PCI
host bridges available, deadlock and performance issues. This is
little off topic since it's not related to FSM's in your testbench.

Quote:
> make the "real" PCB, rather than some test bed.

In some cases they can be the same. I've been working on a network
type of design. One node is my DUT, the other node in the system is
the test bench which is generating lots and lots of weird errors and I
would like to know if my DUT can handle all these error situations.

Petter
--
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com



Sat, 24 Apr 2004 04:05:46 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. finite state machines, state cad

2. Finite State Machine and Forth

3. Finite State Machines

4. ESTEREL, Forth and finite state machines

5. finite state machines

6. Finite state machine compiler

7. Finite State Machines

8. OO Finite State Machine Language

9. Finite State Machine inherent support

10. cisco_fsm (finite state machine) free tool: pre-announcement

11. FSMedit - The Finite State Machines Editor - Version 2.0

12. finite-state-machine problems => Synopsys

 

 
Powered by phpBB® Forum Software