( Post 56 Item 1 ) -----------------------------------------------------------------
From: toddc@hwcae.az.honeywell.com (Todd Carpenter)
For what it is worth, this is in response to Post 52 Item # 1:
(From: mccrohan@e5sb.osdhw.syr.ge.com (mccrohan d. 7647))
I've been writing tons of VHDL for Synopsys based synthesis. I'd like
to respond to some of the issues raised here. For some background, the
chip(s) I'm involved with tend to be more speed constrained than area
constrained, and have a requirement of being highly testable. We also
have not used much of the FSM capabilities, primarily due to the
increased user workload...
For of all, many of the questions did seem rather strange, considering
the questioner had experience with Verilog. Both VHDL and Verilog are
(despite the religious zealots' claims) languages with basically
equivalent expressive capabilities. I saw few VHDL specific questions.
If you can do it with one language, there is a darn good chance I could
get the other language to do the same thing. And even make it
synthesize. With that in mind, you can do it the same way you did it in
Verilog, except now you have the added benefit of the plethora of tools
available for VHDL...
> 1) How useful is the FSM Compiler if you are using VHDL (as opposed to
> state tables) as a front end. It appears that you have to go through
> the regular compile/optimize process first...
Yes, you do. But, I've only played with FSMs, and am quite sure others
out there can be much more helpful.
> 2) There appears to be a lot of subtle points to writing state machine
> descriptions in VHDL, particularly if you are after a really well-behaved
> design (i.e., all unused states transition back to the reset state, or you
> want Johnson counters instead of the normal, glitchy variety.
Hey, same as in Verilog. No reason it should be different. The OTHERS
=> clause in CASE statements is particularily handy, though.
> 3) We are using the IEEE MVL9 system
Good. Don't use anything else. Abuse any new project heads that agree
to start with anything but this. Translators to make your old
simulations interact are not that difficult. But new things *should* be
the IEEE 1164, since all new packages and tools will be coming out to
support this standard, not the old logic systems. Bit will always be
supported, and is fast if you have a trivial design, but you'll find
"uninitialized" is a very valuable state to have for debugging larger
designs .
> instead of bit, or Synopsys's MVL7.
Bit is fine. Synopsys only really groks 0,1,X, and is actually kinda
restricted on the X states: plays havoc with simulation test vectors.
Not that I have any good ideas on how to fix this, though.
The 7 state is a complete waste of time from the old ZyCad daze. Ignore
it.
> Unfortunately, all of Synopsys's documents use bit.
As far as documentation goes, you can pretty much do a global
substitution of IEEE1164 for MVL7. You probably won't use the obscure
IEEE values on the synthesizeable portion of the design, anyways.
> 4) As our models will be used in higher-level simulations (i.e., board
> and sub-system) we want fidelity, in addition to synthesizability. In other
> words, the models must intelligently propagate unknowns...
unknown, uninitialized, or don't care? You have your choice now.
Most good logic packages will handle unknown propagation as you would
wish. Bringing that to a slightly higher level, say a mux structure
with a CASE statement, is pretty easy. An unknown on a data line will
prop an unknown only if that line is selected. An unknown on the select
line will prop an unknown.
But you have to ask yourself "Why are we doing this?" Especially since
unknown propagation in the high level design is darn near guaranteed to
NOT match your gate level design, unless you are designing your "high"
level code with too much gate level detail in it. Why? Because
Synopsys does a wonderful job of logic optimization (once it understands
the logic, which is the trick). What you thought might propagate an
unknown in a particular fashion might never happen in the gate level
design. E.g., an OR gate with one high input will never pass unknown.
Likewise, an AND with any input low will not pass unknown. When you are
working with a high level FSM, you might (hopefully wouldn't even care)
have visibility into the gates.
> 5) What kinds of code (other than the examples in the documentation) will
> result in Synopsys generating really ill-behaved logic. Gated-clocks,
> decoded flop outputs feed back to the set or reset inputs, delay dependent
> logic, etc.
Yep. Anything you wouldn't want to normally do in a nice sequential,
testable, synchronous design, you do NOT want to give to Synopsys. If
you do, you'll end up with headaches, and hours of tweaking. I have
noticed that the good old fashioned way of picking nice big cells from
the libraries, and making use of all the asynchronous p/resets and
alternate inputs just isn't worth is. Just remember "synchronous
design" and you'll be all right. Hmmm, waitaminute, I remember it was
more like "anally retentive synchronous design," but you get the idea.
In summary, you shouldn't find VHDL a _whole_ heck of a lot different.
Sure, the syntax and some of the semantics are different. But good
design techniques in one language will be the same in the other. The
Synopsys VHDL language intrepretor still has gaping holes, but they can
be worked around.
|
|
