Algorithmic state machine chart editors - do they exist ?!?

[asparnique]

Hi,

I've tried searching on google for ASM chart editors (freeware prefereably)
to no avail ... Just doesn't seem to exist. One commercial version flowHDLŽ
is probably out of the scope but this is not availabale as a demo version as
far as I know ?!? (although it is possible to obtain for educational
purposes apparently).

Has anybody or can anybody suggest some robust & inexpensive ASM chart
editors that will help with the the design of ASM charts for state-machine
design (and possibly simulation) ?? A dedicated editor is preferable, rather
than a typical drawing package...

Many thanks in advance, M

 

[asparnique]

Hi,

Mainly for documentation and initial design of the ASM for an existing
embedded application.
Regards, M

"gabor" <gabor@alacron.com> wrote in message
news:b459a7aa-9779-482a-82f1-34945e985b5f@d7g2000vbs.googlegroups.com...
On Jan 2, 10:04 am, "asparnique" <asparni...@gmail.com> wrote:

Hi,

I've tried searching on google for ASM chart editors (freeware
prefereably)
to no avail ... Just doesn't seem to exist. One commercial version
flowHDLŽ
is probably out of the scope but this is not availabale as a demo version
as
far as I know ?!? (although it is possible to obtain for educational
purposes apparently).

Has anybody or can anybody suggest some robust & inexpensive ASM chart
editors that will help with the the design of ASM charts for state-machine
design (and possibly simulation) ?? A dedicated editor is preferable,
rather
than a typical drawing package...

Many thanks in advance, M

I haven't used such a thing in some time, but I remember that
ViewLogic (now part of Mentor) had a state machine editor, and
Xilinx had something called StateCAD for state diagram logic
design entry. I don't remember either of these working very
well, which is why I don't use them anymore. Are you trying
to design your logic with this editor, or do you just need
it to document your existing logic?

Regards,
Gabor

 

[gabor]

On Jan 2, 10:04 am, "asparnique" <asparni...@gmail.com> wrote:

Hi,

I've tried searching on google for ASM chart editors (freeware prefereably)
to no avail ... Just doesn't seem to exist. One commercial version flowHDLŽ
is probably out of the scope but this is not availabale as a demo version as
far as I know ?!? (although it is possible to obtain for educational
purposes apparently).

Has anybody or can anybody suggest some robust & inexpensive ASM chart
editors that will help with the the design of ASM charts for state-machine
design (and possibly simulation) ?? A dedicated editor is preferable, rather
than a typical drawing package...

Many thanks in advance, M

I haven't used such a thing in some time, but I remember that
ViewLogic (now part of Mentor) had a state machine editor, and
Xilinx had something called StateCAD for state diagram logic
design entry. I don't remember either of these working very
well, which is why I don't use them anymore. Are you trying
to design your logic with this editor, or do you just need
it to document your existing logic?

Regards,
Gabor

 

[Mike Treseler]

asparnique wrote:

I've tried searching on google for ASM chart editors (freeware prefereably)
to no avail ... Just doesn't seem to exist.

True.

ASM charts are a type of graphical pseudo code used
before verilog simulators were available, usually like this:

http://www.youtube.com/watch?v=Arncvqu_jOQ

ASM charts are still used for academic purposes,
but have been overtaken by verilog and vhdl
for simulation and synthesis.

Today's synthesis tools draw schematics
and state diagrams for me, from the source code.

-- Mike Treseler

 

[Jonathan Bromley]

On Sat, 02 Jan 2010 18:18:24 -0800, Mike Treseler wrote:

ASM charts are a type of graphical pseudo code

For many digital designers, ASMs are almost synonymous with
Prosser and Winkel's still-excellent book on digital design.

ASM charts are still used for academic purposes,
but have been overtaken by verilog and vhdl
for simulation and synthesis.

I hate to rain on your parade, Mike, but I think we need
to be very careful indeed when suggesting that textual
design entry languages are a step forward from diagrammatic
approaches. In this as in so many other things, we in the
digital design community are lagging a couple of decades
behind the software folk; they embraced programming
languages wholeheartedly in the 60s and 70s, but later
began to discover that requirements capture and design
review were often better served by some kind of diagram
notation. The consequent blossoming of diagram notations
has infected much of the software world and appears both
in kindergarten stuff and in the very largest
mission-critical software projects.

Many of the early attempts at diagrammatic languages in
software were pretty pathetic, and had me and many other
electronics folk rolling around in amusement at their
paucity of expressiveness and their ambiguity. Nowadays,
though, the Unified Modeling Language (UML) has gone a long
way to making such things useful and precise, and there are
many production-quality commercial tools that help you to
capture requirements and generate prototype implementations
almost entirely using UML diagrams.

The fact that implementations can be machine-generated from
UML, just as digital implementations can be generated from
state diagrams, clearly shows that there is a very strong
(maybe even isomorphic) relationship between a sufficiently
rich diagram notation and a programming language. The
truly interesting questions, then, are the human ones.
Which form is easier to edit and maintain? Which has
the clearest relationship to the original requirements
specification? Which form is more useful for debug and
design review?

For my money, and (I suspect) for Mike, text entry wins
handsomely when working at the level of typical RTL designs.
I don't plan on shifting back to diagrams any time soon.
But that doesn't work for everyone, and it doesn't work for
every class of problem. I have already complained, in
public, about how difficult it is to represent pipelined
behaviour in a clear and understandable way using RTL code;
the reason, in that example, is that RTL code rather nicely
describes the behaviour of a design on a single clock tick,
but it is not so easy to see how it describes the life cycle
of a piece of information as it flows through a pipeline,
nor how the processing of information is distributed across
the stages of a pipeline. That's just one example of a
situation where I would probably draw some pictures, at
least in the early stages of design capture.

Having said all of that, I totally agree with Mike that
ASM charts (specifically) are pretty much useless today;
everything they say is said at least as clearly by well-
written RTL code.

Just my personal $0.02 as always,
--
Jonathan Bromley

 

[Mike Treseler]

Jonathan Bromley wrote:

I hate to rain on your parade, Mike, but I think we need
to be very careful indeed when suggesting that textual
design entry languages are a step forward from diagrammatic
approaches.

My intent was to activate an interesting discussion
in this fading newsgroup, so you have brought
more parade than rain

... The consequent blossoming of diagram notations
has infected much of the software world and appears both
in kindergarten stuff and in the very largest
mission-critical software projects.

This makes sense for a project that can afford
an architect/reviewer and more than one developer.
I would assume that ASIC projects are in
this category. I have yet to see an FPGA
project so organized. This is probably
because an FPGA image can be incomplete
yet still useful.

...

The truly interesting questions, then, are the human ones.
Which form is easier to edit and maintain? Which has
the clearest relationship to the original requirements
specification? Which form is more useful for debug and
design review?

A *useful* graphical tool would have to include
source control, and output perfect code.
If I have to edit the code, the tool is
out of the control loop.

When I do discuss a design with other developers
in person, we always mark up boxes and arrows
on a white board, talk, listen and watch
for non-verbal cues. The diagram is important
but the communication of ideas that don't
quite quite fit into any text-based
language is the main event.

If a *useful* UML tool could capture this information,
I would buy one,

For my money, and (I suspect) for Mike, text entry wins
handsomely when working at the level of typical RTL designs.
I don't plan on shifting back to diagrams any time soon.

At the moment, RTL is good enough, and the top
review question is, "How long will it take?"

I have already complained, in
public, about how difficult it is to represent pipelined
behaviour in a clear and understandable way using RTL code;
the reason, in that example, is that RTL code rather nicely
describes the behaviour of a design on a single clock tick,
but it is not so easy to see how it describes the life cycle
of a piece of information as it flows through a pipeline,
nor how the processing of information is distributed across
the stages of a pipeline.

Yes, I think that was last year, about this time,
and yes, you pretty much stumped the group.
I have no better solution this year.
I need trial and error synthesis to
optimize tics per pipeline and I need modelsim
to line up the strobes. This is the stuff
that is hard to describe.

That's just one example of a
situation where I would probably draw some pictures, at
least in the early stages of design capture.

Every year I fill a computation notebook
with such sketches.

Having said all of that, I totally agree with Mike that
ASM charts (specifically) are pretty much useless today;
everything they say is said at least as clearly by well-
written RTL code.

Ahh. Some sunshine after all.

Thanks for the posting.


-- Mike Treseler

 

[evilkidder@googlemail.com]

But that doesn't work for everyone, and it doesn't work for
every class of problem.  I have already complained, in
public, about how difficult it is to represent pipelined
behaviour in a clear and understandable way using RTL code;
the reason, in that example, is that RTL code rather nicely
describes the behaviour of a design on a single clock tick,
but it is not so easy to see how it describes the life cycle
of a piece of information as it flows through a pipeline,
nor how the processing of information is distributed across
the stages of a pipeline.  That's just one example of a
situation where I would probably draw some pictures, at
least in the early stages of design capture.

Perhaps this paper would be of interest to you;

http://tiny.cc/eAsAv

Andy.

 

[Jonathan Bromley]

On Tue, 5 Jan 2010 10:03:50 -0800 (PST), evilkidder wrote:

Perhaps this paper would be of interest to you;
http://tiny.cc/eAsAv

Certainly is. Thanks for the pointer.

At first glance it looks very similar to the kinds of
things that Synopsys Behavioral Compiler was doing
back in 1999 or so, but I need to look more closely
at the theory - at least someone has *tried*. The
paper also has a ton of references that will be
good to follow. Thanks again.
--
Jonathan Bromley

 

[Mike Treseler]

evilkidder@googlemail.com wrote:

Perhaps this paper would be of interest to you;
http://tiny.cc/eAsAv

Yes, interesting. Thanks for the posting.

I recently made a sim model for
a framer tx interface. The testbench
for this model was similar in style
to the module "diffeq" in the referenced
paper, with variable assignments, multiple
synchronous waits, and output assignments.
I find this style very easy to write and read.

When the fpga side of the interface didn't
work as expected on the bench, I ended up converting
some of the testbench procedures to synthesis code
to drive a real, repeating, constant packet.
This is something I had never done before.

This worked fine, and the problem
turned out to be a framer register setting...
But anyway...

While I was converting the delay based
procedural testbench thread to a
synchronous enumeration register,
the thought occurred to me, that this
felt like some kind of inversion function
that might be automated with appropriate constraints.

As Jonathan mentioned, synopsys behavioral compiler,
did propose to allow one to sprinkle multiple synchronous
waits around in a single process block,
but this never caught on for some reason.

Since it's been 10 years, it might be time for someone to try again.

-- Mike Treseler

 

[HT-Lab]

Not sure if anybody has already mentioned that Mentor's HDL Designer has a
graphical ASM entry method.

Hans
www.ht-lab.com


"asparnique" <asparnique@gmail.com> wrote in message
news:4b3f6adc$0$12655$426a74cc@news.free.fr...

Hi,

Mainly for documentation and initial design of the ASM for an existing
embedded application.
Regards, M

"gabor" <gabor@alacron.com> wrote in message
news:b459a7aa-9779-482a-82f1-34945e985b5f@d7g2000vbs.googlegroups.com...
On Jan 2, 10:04 am, "asparnique" <asparni...@gmail.com> wrote:
Hi,

I've tried searching on google for ASM chart editors (freeware prefereably)
to no avail ... Just doesn't seem to exist. One commercial version flowHDLŽ
is probably out of the scope but this is not availabale as a demo version as
far as I know ?!? (although it is possible to obtain for educational
purposes apparently).

Has anybody or can anybody suggest some robust & inexpensive ASM chart
editors that will help with the the design of ASM charts for state-machine
design (and possibly simulation) ?? A dedicated editor is preferable, rather
than a typical drawing package...

Many thanks in advance, M

I haven't used such a thing in some time, but I remember that
ViewLogic (now part of Mentor) had a state machine editor, and
Xilinx had something called StateCAD for state diagram logic
design entry. I don't remember either of these working very
well, which is why I don't use them anymore. Are you trying
to design your logic with this editor, or do you just need
it to document your existing logic?

Regards,
Gabor

 

[Jonathan Bromley]

On Tue, 05 Jan 2010 23:08:31 -0800, Mike Treseler wrote:

sprinkle multiple synchronous
waits around in a single process block,
but this never caught on for some reason.

Since it's been 10 years, it might be time for someone to try again.

I think you'll find that most of the big-name synthesis
tools *do* support multiple synchronous waits in a
process (thereby creating an implicit state machine);
but they can do so only in a fairly limited set of
circumstances.

For RTL designers, implicit state machines have
always been a two-edged sword. You gain simplicity
of description of a step-by-step procedural flow;
but it then becomes very difficult to describe any
action that should take place on *every* clock.
For example, given this:

always begin
@(posedge clock) do_action_A;
@(posedge clock) do_action_B;
@(posedge clock) do_action_C;
end

how do I code a reset (either synchronous or
asynchronous)? In Verilog there are hacks you
can do with "disable" and "wait" to express
resets, but it's very ugly and inexpressive.

And then you need to find some way to describe
pipelining. Synopsys BC allowed you to use a
whole range of constraints (synthesis directives
in party dress) to control pipelining, I/O timing,
resets and all the other zoo of area vs. latency
vs. throughput tradeoffs; the Verilog code was
largely relegated to describing the algorithmic
behavior. It certainly worked, and there were
some impressive scheduling algorithms behind it,
but the resulting design descriptions made little
sense to me.

Handel-C was one interesting shot at solving these
problems, but it too had some awkward limitations
and didn't always yield the most lucid design
descriptions. I suspect that it's just a tricky
problem that will never have a single solution that
satisfies everyone's needs, but I'm happy to keep
looking and waiting.....
--
Jonathan Bromley

 

[John_H]

On Jan 2, 10:20 am, gabor <ga...@alacron.com> wrote:

I haven't used such a thing in some time, but I remember that
ViewLogic (now part of Mentor) had a state machine editor, and
Xilinx had something called StateCAD for state diagram logic
design entry.  I don't remember either of these working very
well, which is why I don't use them anymore.  Are you trying
to design your logic with this editor, or do you just need
it to document your existing logic?

Regards,
Gabor

StateCAD was what I had my eyes on when it was a stand-alone package
before Xilinx bought it in 2000. The StateCAD form of design entry
was available in the 10.1 Xilinx tool suite *for Windows only* and was
removed by 11.1 according to a quick search of Xilinx.com. If you
have access to the Xilinx 10.1 tools on a Windows machine, you might
get a flavor of what you've lost but don't expect to find it in the
new Xilinx tool suites going forward.

 

[Andrew FPGA]

Yes, I think that was last year, about this time,
and yes, you pretty much stumped the group.
I have no better solution this year.
I need trial and error synthesis to
optimize tics per pipeline and I need modelsim
to line up the strobes. This is the stuff
that is hard to describe.

Register retiming anyone? Write a clean, algorithmic,
HDL description using variables, that executes in one tic.
Keep adding registers to the outputs until
synthesis/PAR meets timing.

 

[evilkidder@googlemail.com]

On Jan 6, 2:38 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Tue, 05 Jan 2010 23:08:31 -0800, Mike Treseler wrote:
[...] sprinkle multiple synchronous
waits around in a single process block,
but this never caught on for some reason.

Since it's been 10 years, it might be time for someone to try again.

I think you'll find that most of the big-name synthesis
tools *do* support multiple synchronous waits in a
process (thereby creating an implicit state machine);
but they can do so only in a fairly limited set of
circumstances.

For RTL designers, implicit state machines have
always been a two-edged sword.  You gain simplicity
of description of a step-by-step procedural flow;
but it then becomes very difficult to describe any
action that should take place on *every* clock.
For example, given this:

  always begin
    @(posedge clock) do_action_A;
    @(posedge clock) do_action_B;
    @(posedge clock) do_action_C;
  end

how do I code a reset (either synchronous or
asynchronous)?  In Verilog there are hacks you
can do with "disable" and "wait" to express
resets, but it's very ugly and inexpressive.

The scheme described in the paper gets round this particular issue by
associating the clock and reset with the declaration of the register.
I used the same scheme for hdfs;

http://code.google.com/p/hdfs/wiki/HdfsHdlComparison

And then you need to find some way to describe
pipelining.  Synopsys BC allowed you to use a
whole range of constraints (synthesis directives
in party dress) to control pipelining, I/O timing,
resets and all the other zoo of area vs. latency
vs. throughput tradeoffs; the Verilog code was
largely relegated to describing the algorithmic
behavior.  It certainly worked, and there were
some impressive scheduling algorithms behind it,
but the resulting design descriptions made little
sense to me.

I don't think the scheme described in the paper is all that similar to
Synposys BC (though I have never seen it myself). Converting the
sequential description to a statemachine appears at first glance
fairly trivial; not much more than a compilers notion of a 'basic
block' except the programmer controls them via 'wait' statements
instead of the control code (ie if/while/case etc). I can see how the
logic could expand quite considerably to deal with corner cases which
could require some careful management though (for example how to deal
with loop constructs which don't terminate in a 'wait' statement).
Still, it shouldn't need any scheduling calculations to take place.

Pipelining is a different beast altogether, and I am not convinced
that the scheme as described solves all problems with this style of
description, though the examples they provide do suggest it's at least
useful.

Handel-C was one interesting shot at solving these
problems, but it too had some awkward limitations
and didn't always yield the most lucid design
descriptions.  I suspect that it's just a tricky
problem that will never have a single solution that
satisfies everyone's needs, but I'm happy to keep
looking and waiting.....

Handel-C, Synposys BC and all those other behavoural C-based compilers
seem to me to be a different idea altogether. I must admit I'm all
for them gaining traction, not least if it brings the ridiculous
prices in range of us mere mortals.

It doesn't seem that hard to provide something along the lines of this
paper. I can see for certain heavily control oriented designs it
being a simpler design description. I am tempted ...

Andy