( ESNUG 291 Item 12 ) ---------------------------------------------- [5/27/98]
Subject: ( ESNUG 289 #4 ) Escalade vs. Summit and Mentor Renoir vs. Speed
> Generally, experienced VHDL users are not very receptive to the use of
> graphical tools, except perhaps for doing complex state machine design.
> Most will concede that it is a lot easier to share information if it
> graphical than textual. Personally. I am for whatever one feels to be
> the most effective. I advocate a mixed approach, with **overall**
> productivity (which includes documentation and reuse) being the objective.
> I consider HDLs as a means to an end, not an end in themselves. The ability
> to easily switch between graphics and text or between languages is IMHO
> the goal.
>
> - John Vincent
> Eastman Kodak Company Rochester, New York
From: Premysl Vaclavik <tnepva@neuroth.co.at>
John,
I tried several times to use graphical entry for a state machine, test
bench and behavioral description of an analog-digital environment but my
efficiency was very poor. I spent simply more time to have it really
readable on the graphical level and to get what I really wanted. I tried
to summarize some points why I do not like this approach:
- unlike VHDL or VERILOG, graphical entry is sw vendor dependend
(Try to port graphical database)
- graphical entry can not use full VHDL capability (I wrote my "last"
VERILOG 4 years ago, so i can not discuss it)
- graphic is human readable only up to certain level of complexity.
(HDL code is more compact)
- instead of HDL i have to learn also available constructs and GUI of
graphical entry tool to get HDL code again.
- synthesizer uses HDL code, not graphic. Why to add more steps to
HDL code - synthesis cycle ?
- graphical description MUST BE complete.
There are always used simplified block/SM/circuit diagramms to highlite
and better understand design concept. These were no more readable if
they had to contain ALL details.(I know, this is problem to keep
consistency between a HDL and simplified graphical objects)
- It increases seat/designer costs without increasing a productivity.
Vendor marketing told us to use graphical entry because of documentation,
but if we are quite restrictive, we can keep our VHDL also readable and good
documented. It is strange, that specification/data sheet entry for a chip
design with some kind of formal checks is out of a sw vendors' scope.
- Premysl Vaclavik
Neuroth
---- ---- ---- ---- ---- ---- ----
From: tboydsto@su102s.ess.harris.com (Ted Boydston)
John,
Well, well, well. Sounds like another religous war is about to start.
Another emacs vs vi, VHDL vs Verilog, NT vs Unix. Well, let me throw my
hat in...
First, let me state that I have actually USED one of these tools (Summit
VisualHDL to be exact). And when I mean used, I don't mean "I sat down
and tried to draw a schematic/state-machine, got frustrated, and decided
that the whole tool was not worth it!" Nope, what I mean is our ASIC team
did a multi-bus "traffic-cop" type chip consisting of 170K gates COMPLETELY
in VisualHDL. Let me give you my minuses and pluses on the process.
Minuses:
* - Hated it when I first started, thought it was too cumbersome (sound
familiar)
* - Logic table entry is poor....Summit should take a lesson from Excel.
* - State Machine entry has some limitations, but can be easily overcome.
* - Flowchart editor sometimes produced code that was incorrect when the
flowchart shared pieces of code.
* - Some features were obviously designed by software engineers without
the input of hardware folk. I will not list them, but can tell you
that any hardware person could figure out what I'm talking about.
* - Links to external simulators are limited right now. We use VSS, and
I had to write Perl scripts to manage the process. Summit will be
including VSS and other simulators in future releases. Current support
includes VisualHDL's simulator, QuickVHDL, V-System, and Vantage.
* - It has a scripting language based on Scheme--YACK!!! That's all I
need is to learn a scripting language that only one tool is ever going
to use. Come on guys, how about TCL (smaller YACK), or better yet
Perl (big cheer!)
Pluses:
* - Forces designers into a team environment managed by version control.
The version control feature is implemented in RCS. If the user
wishes, they may use their own version control, including ClearCase.
* - Allows efficient top-down design of code graphically.
* - Allows complex state machines to be represented hierarchialy. This is
a cool feature in that Summit allows any state to be linked to another
state machine. The code then can be generated in the hierarchial
format you drew or flattened for speed. Flowcharts can also be
represented hierarchialy.
* - State machines, with a click of a button, may be represented grey,
one-hot, one-cold, or enumerated. You may, of course, create your
own encoding.
* - Your code is your document. This is a great plus. Now you can print
out your design from VisualHDL and take it to a review without
re-drawing it so others can understand it.
* - Allows more efficient reuse. Once a designer creates a component,
another designer can simply instantiate it into their design from the
library. Although designers can say they can do this with textual
entry, with VisualHDL, the designer has an instant picture (along with
a description) of exactly what the component does.
* - Team design is easier with Visual. The task leader can easily add
signals to your design by simply attaching them at the top level and
updating your design. These new signals then appear in your design
automatically.
* - Ah, yes, no more screwing around with VHDL port maps. This is a
god-send. In the pre-VisualHDL days, we had scripts which would try
to automate the connecting of port-maps, but you always had to go in
and clean up. Now you just draw your schematic and your done.
* - Cool testbenches using VHDL generics can be created with ease. This
plus leads back to the re-use issues. In VisualHDL, generics become a
breeze and most testbench elements can become fully configurable to
most situations.
* - Can easily integrate complex models. Our testbench used Souce Models,
Smart Models, and Hardware Models. As stated before, I wrote scripts
that managed the link between VisualHDL and VSS.
* - Summit's built in simulator allows cause-and-effect analysis. When
you click on an edge on a sim waveform it takes you to the diagram/code
that caused the event. Its great for diagnosing state machine
contention, because it highlights what state your in when the problem
occured.
* - Greatly eases the creation of behavioral code through the use of
flowcharts. Linked with the cause-and-effect simulation capability,
I was able to create behavioral models quickly and with a minimal
amount of code. (Behavioral, in this case, means coding through
loops and waits).
I know, I know, there will be the text-based nay-sayers out their. To them
I say, try it for a complete design cycle, then judge. I myself was one of
those nay-sayers and thought that the tool was awful, till I discovered what
benefits I was really gaining.
Overall, I believe the pluses did out-weight the minuses by good margin. I
hope that other designers have the opportunity I did to try VisualHDL (or
some other GUI-based entry) and get past the initial distain, because I
believe you will come to enjoy using the tool.
- Ted Boydston
Harris Government Aerospace Systems Division
|
|
