Re: gEDA-user: VeriWell now on SourceForge

["Samuel A. Falvo II" <sam.falvo@xxxxxxxxx>]

On 9/27/05, Hagen Sankowski <hsank@xxxxxxxxxxxxxxxxxxxx> wrote:
> First, please let me ask, what's your profession?

Let me answer: you neither need to know this, nor should you care.  I
do not respond well to appeal to authority argumentation unless it is
well justified, which your response tells me it clearly isn't.  Where
are *YOUR* qualifications?  Anybody can call themselves an Engineer. 
Unfortunately, your response leads me to believe that you are every
bit an academic (however scholarly or non-scholarly) as the VHDLians.

> I see a big difference between industrial practise and academic spare time designs. Out of your question I would think you doesn't know the industrial practise, istn't it?

You're probably right, but it doesn't change the fact that most of the
cores on OpenCores.org are in VHDL, *NOT* Verilog.  Also, as VHDL was
an HDL commissioned for the US government (hence it being a proper
subset of Ada) for the purposes of both simulation *and synthesis*, it
follows that OpenCores isn't the only group of people to use this
language.  Finally, most fabless chip companies that resell or
wholesell IP designs appear to be inconsistent on their offering. 
Western Design Center's IP can be purchased in either Verilog or VHDL,
while other companies are Verilog only, and others are VHDL-only.

> Look at Verilog and you'll see it belongs more to real hardware stuff like gates, wires etc. than VHDL. VHDL doesn't know the concept of primitives, isn't it? Look

So what?!  Look at most programs today that are written in C, and it's
patently clear that it is much, much closer to the PDP-11 instruction
set than any Intel architecture has ever provided.  So, why are we all
using C-compiled applications on x86 boxen?  Oh, and PowerPCs and
other RISC processors are even *more* fundamentally different from the
original PDP-11 instruction set still.

According to the sources of documentation I've seen on VHDL, it does
absolutely support the concept of primitives.  Using them is hard
(just as using inline assembly in most C compilers is hard), and by
design.  As you indicate, VHDL is optimized more for high-level (and
thus, so-called "provably correct") design philosophy.  But it was
also designed to support synthesis as well.

>synthesis. But why you want a 2nd simulator? Think you've designed your Chip

If you have to ask this question, then I must ask **YOUR**
qualifications and profession?

The answer is simple: for the same reason we have C, Python, Perl,
Oberon, Modula-2, etc., often times all running or at least available
on the same platform.  No one language is best suited for all possible
problems.  I openly invite you to try and write an operating system in
BASIC.  Now I openly invite you to try and write a signal processing
simulation in machine language.  Yeah, both are possible, in theory. 
It all depends on how much time you want to spend doing it.

I have absolutely *ZERO* desire to re-write processor or VGA
controller core that is *already* on OpenCores, in readily
downloadable format and has already been synthesized and proven in
real-world hardware, but is in VHDL format into a Verilog-equivalent
format JUST because I lack a VHDL compiler.

That just doesn't make a damn bit of sense.

Finally, it also is of great benefit when you're simulating real-world
circuits.  I can download a 6502 VHDL core from OpenCores, a VGA
controller core, and all sorts of other fun stuff, and simulate them. 
But, as you indicate, Verilog is more appropriate for hardware-level
integration and truely custom circuit engineering.  So let's say I
choose Verilog for my own unique hardware.  How do I simulate the
**SYSTEM** consisting of a 6502, a VGA controller, and my own custom
logic, without actually having two cooperating simulators?

Bet you didn't think of that, now did you?  Again, you do not exhibit
a very engineering-like thought process.  Engineers think in terms of
*systems*, the big picture.  Technicians are often the ones primarily
tasked with detail-oriented stuff.

> it? You can't simulate it 'cause your testbench is in VHDL. There's a need now for a Verilog simulator and a verilog testbench. Quite easy, if you've use Verilog from the begining.

First of all, who are you to say I have to start with Verilog from the
beginning?  Who is anyone to say?  Last I checked, my hardware
projects involved parts of all sorts of shapes and sizes, from flat
ceramic slabs called DIPs, to round metallic cans for capacitors, and
plastic cylinders that lie horizontally for resistors, and . . .  The
point is, in the *REAL WORLD*, they work together, and comprise a
circuit that is real-world useful.

Secondly, I've seen plenty of commercial vendors that allowed VHDL
testbenches to exercise Verilog designs, and vice versa.  Just as I
left Hifn, they were beginning to roll out a new verification approach
that relied on "co-synthesis," where everything was compiled down to
raw C interfaces.  So now it truely doesn't matter if you're using
Verilog, VHDL, Hardware-C, or whatever new language happens to roll
out that year.  From the perspective of the synthesis tools, C is the
uniform language of interoperability.

Software is a tool, not a religion.  It's supposed to solve problems,
not create them.

> stuff with an verilog simulator. VHDL looks quite academic with a sophisticated and nearly three-times-slower multi-value signal model. VHDL is used in academic

Who cares how long it takes to simulate?!  Sure, it's an inconvenience
if it's slow, but comparing electric utility bills contributing
towards simulation time against a single VLSI fab run (which can
easily cost upwards of $500K or more), it's a no-brainer which I'd
choose first.

For that matter, looking at fabrication costs for printed circuits
using pre-fabricated components, it's still cheaper to sim than it is
to fab.  But, you wouldn't know this unless you were involved in a
*business* somehow, where pragmatics overrule religion on a daily
basis.

> area and for FPGA only ('cause the FPGA tools support both, VHDL and Verilog). In case of quite huge designs, you go to hell if you want simulate all the gates with VHDL in a short time (Example: to simulate how a 32-bit processor boots the first 5 seconds, you take around 2 week simulation time!)

I don't think you're including the full story here.  Describe the
simulation equipment on which you're running it on.  Are you running
it on a single computer, or on a compute *farm*?

When I worked for Hifn, Inc. as a semiconductor verification
technician, which I'll admit that most of our stuff was done in
Verilog (but not all!), our chips could be simulated quite rapidly, as
we had a simulation farm established.  Had they been written in VHDL,
where it takes 3x as long to sim as you say it does, then we still
would have incredibly fast turn-around times.  There were so many
projects going on at Hifn that the same engineers could just switch to
another project while the first sim was waiting.  Engineer
productivity is up, costs are down, results are still delivered at the
end of the quarter.  It's a fun time for all!  Hifn ended up doing
precisely this because it takes upwards of six months for a fab run to
come back anyway.

Also, the first five seconds of a processor is a veritable *eternity*
for most CPUs I'm aware of.  Therefore, in that two week period, you
literally can exercise *every* piece of functionality for that
processor, post integration.  If it takes you two weeks to verify the
correctness of every major functional unit of the microprocessor,
that's still a hell of a lot faster than waiting 6 bloody months for a
fab run to complete.  And no doubt, half a million dollars cheaper
too.

> opencores for you? The open source hardware doesn't reached the real design engineers! Most design engineers I know would work with Verilog, but all the

Since most of the contributors to OpenCores happens to be commercial
firms, I have to question the very foundation of your arguments.

> academic folks and hobbiest just using VHDL. And so long as designs at

By virtue of the fact that VHDL sims for Linux are far and few between
(and wholesale incomplete relative to commercial implementations), and
virtually non-existant for WIndows without a paid license, this
further leads me to believe your foundations are shaky, if not utterly
undermined.

> opencores.org looks poor (not just because of VHDL) opencores doesn't reach real design engineers.

If you've reviewed any of the designs at OpenCores, you'll realize
that the designs present are as good as, if not overwhelmingly
superior, to most commercial designs.  Compare the OpenRISC 1K
architecture to either MIPS or ARM, and you'll see that it wipes the
floor cleanly with both, especially from an embedded RISC point of
view.  Wishbone bus specification is the most complete and absolutely
the most flexible on-chip bus specification I've ever seen, supporting
everything from shared bus all the way to split input/output,
cross-bar switched fabrics, and everything else in between.  There are
all sorts of support peripheral cores on there as well, ranging from
some pretty simple communications controllers to conveniently powerful
display controllers, storage controllers, SDRAM interface chips that
makes most motherboard chipsets look like the toys they really are,
etc.  Yeah, true, you're not going to see multi-core GPUs running the
latest 3D hardware in them.  Nobody has had a real need for one of
those.  Except for gamers, nobody still does, really.

> My conclusion is, to get engineering folks like me with opencores we need a very good verilog simulator (Icarus is one the way, all the things Icarus does, does it well, and back to the topic, Veriwell knows the old verilog standard only) and very good verilog designs.

Now, please tell me and the rest of this list, where I stated that we
did not need Verilog?  The mere fact that I didn't state any
preferences at all for Verilog blows your entire argument clean out of
the water.  The fact that I prefer Verilog over VHDL only casts the
sheer misunderstanding you have for my position in sharper contrast
still.

Your whole premise was founded on the idea that I abhore Verilog, and
that I was not in support of it, and that I was not familiar with
Icarus.  I taught myself Verilog using Icarus, and love it very much. 
But unlike some other religious zealots who apparently lurk here, I do
not make the mistake of taking a myopic view that there is one and
only one True Hardware Language out there.  There is plenty of room
for many kinds of hardware description languages (Verilog and VHDL are
optimized for synchronous, digital designs; there is yet asynchronous
digital and even analog HDLs that are currently being researched). 
How do we tie these languages into a cohesive system as well?

If you enjoy hand-recompiling hundreds or thousands of lines of VHDL
into its equivalent Verilog by hand, please, by all means, be my
guest.  I, however, have overwhelmingly more important things to do
with my time.

Thank you, and I hope I've made my position more clear to you in
particular, and everyone else in general.  I must admit, I feel deeply
offended at just how badly I was misunderstood, my words twisted, and
my intent used to borderline villify me on this list.

--
Samuel A. Falvo II
Former Semiconductor Verification Technician
Hifn Semiconductors, Inc.
5973 Avenida Encinas
Carlsbad, CA  92008
http://www.hifn.com