VHDL vs. Schematic Capture

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi Y'all :

I have many years of experience with hardware design, software design &
implementation etc (i.e. I'm comfortable with C++, soldering or anything in
between)

I'm using FPGA"s more and more.

So far, I've used schematic capture exclusively. I use Altera's Megawizard,
so I know someone wrote some parameterizable VHDL behind this, but I still
think in hardware terms.

I never learned VHDL, and wonder if it's worth it.

My take has been that I am designing hardware - configuring the LE's and
interconnects and not writing algorithms. This seems to me to be mind-set
that best fits what I'm doing.

I notice that a lot of people here refer to "code" - suggesting they have an
algorithmic mind-set

What am I missing ? What would be some examples of something better done in
VHDL ? Are there examples of stuff that cannot be done in schematic ?

Any comments will be appreciated.

Gary



Re: VHDL vs. Schematic Capture
Hi

Quoted text here. Click to load it

Well, when doing VHDL, you'd better be thinking hardware as well. VHDL
is a language to describe the hardware you want built.

When you code in VHDL, you don't think "algorithm", you think register,
combinatorial logic and you describe that in VHDL.

Note the exception about that is when you code testbench and "code
generation". The first is just a behovioral description of the test
environment and stimulus and don't need to be synthetizable. The latter
is when you write "generic" VHDL code that needs to adapt somewhat to
static option at synthesis time (not unlike the C preprocessor).

The main advantage I see about HDL over schematic capture would be :
  - Vendor independent : I don't think the schematics are interoperable
but I may be mistaken
  - Text edition : To write the vhdl, you can do it every where where
you have a text editor, no need to have the vendor tools
  - Genericity : When you have a complex block that needs different fine
tuning for different application, you can use parameters to change details.

But that's just IMHO ...

    Sylvain

Re: VHDL vs. Schematic Capture

Quoted text here. Click to load it

I too used schematic entry exclusively until the company ran into a larger
project, and we got sent off on VHDL course. Now it's exclusively VHDL, not
because there's any functional difference in my mind, but because I'm lazy.
True, I too refer to the file as 'code', but it's only 'code' or
'behavioural description' until it's been through the synthesis tool, just
as 'schematic' is only a 'drawing of funny looking boxes' until the
synthesis tool breaks it down. Algorithmic mindset, no. For me that somehow
implies sequential execution, and hardware isn't. I'm a C programmer too,
and I tried reading VHDL from a sequential-execution mindset. It didn't
work.

As an example (because I've done this both in schematic and VHDL), consider
a shift/count register typically used for a reciprocal frequency counter. In
schematic I constructed a symbol with a FF that would either count or shift,
and made a schematic with 28 of those symbols. Draw wires, think it over,
did I do it right, okay. If I want to expand the register, I need to draw
more.
When writing VHDL my mindset is still "I need a register, when not gated
open it should be a shift register, when gated open it should be a
synchronous counter. It should be clocked from refclock."

  if rising_edge(refclk) then
    if (gate='1') then
      fcount<=fcount+1;
    else
      if (shiftpip='1') then
        fcount<=fcount(fcount'LEFT-1 downto 0) & '0';
      end if
    end if;
  end if;

Reading it goes like "There are some refclk-risingedge-clocked flipflops,
and there's a gate-controlled multiplexer in front of them. One input has
the output of an adder, the other the left shifted signals, and clock enable
is gate or shiftpip." And it's faster for me to read and convince myself
that it's right.

In my experience, once a schematic reaches the point where you think that
you 'really have a lot of wires on this page, and which ones end up where?'
VHDL entry handles the complexity better.

/Kasper



Re: VHDL vs. Schematic Capture
My two cents are that i like to do breakup up my design in to modules
first and come up with their interfaces and a rough schematic diagram
then the deeper design and implementation is done in HDLs each module
simulated tested etc then i fit them in the original schematic design.
In this way i get a birds eye view of the whole design and the beauty
of the schematic diagrams as well as abstraction of HDLs.


Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it

I draw a block diagram of the major components as well before putting
stylus to papyrus & generating HDL code.

Re: VHDL vs. Schematic Capture

Quoted text here. Click to load it

As many writers have commented you need to know hardware before you code
VHDL -- as certain syntax & grammar of VHDL will infer logic ... Your
extensive background in gate-level design will serve you well in VHDL.

Re: VHDL vs. Schematic Capture
Everything that you do in schematics you can do in VHDL i.e. as complete set
of instantiated components wired as you want. But that is a terrible waste.
Where you really win is something like a state machine where you can
describe fairly complex behaviour in a relatively small number of lines. I
have designed state machines up to 32 thousand states. Yes I did say 32
thousand and that took me about 2 weeks to enter and debug - mostly typing.
Try doing that in schematic and not making a mistake or even fixing
mistakes.

There are lots of other examples where description is quicker and more
reliable than schematic. You are also not ruled from using schematics to
view the design, or even to do critical bits in schematic, or even doing
vhdl netlist form. If you are comfortable with C++ then you will find a lot
similarities in VHDL. VHDL can be written as very abstract code or very
simple staying with a small number of constructs like if/elsif, case etc.
Personally I prefer the simple approach to VHDL but each to their own as the
saying goes.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk


Quoted text here. Click to load it
in
Megawizard,
an
in



Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it

IMHO:

Schematic entry has always been a transitional addition to Programmable
Logic tools, representing a merging of the old and the new. Comparing
Schematic entry to VHDL is like comparing Hotmetal, Frontpage or some
other WYSIWYG website design utility to HTML/XML etc. It is a tool, enjoy.

If you are considering learning VHDL (or Verilog), my advice is a
resounding YES; Do it, learn it.

FPGA's will soon exceed present physical production limitations and we
will have budget giga, tera and even peta gate FPGAs. VHDL makes
designing complex and/or large hardware very easy compared to schematic
entry; however visual descriptions are always easier on the eye.

Now the contentions stuff:

IMHO, IMHO, IMHO: (flame on!)

It is all code. VHDL and Verilog are Hardware Description Languages.
Various 3rd Generation Languages (3GLs) like Pascal, C, Basic etc are
Functional description languages. ALL LANGUAGES are behavioral in
concept; they are supposed to define and/or describe a "system's" behavior.

In development circles the words "code" and "coding" are abbreviations
borrowed from the words "encode" and "encoding". They describe the
process (coding) and results (code) of translating a behavioral design
from the mental landscape into a textual format; At these levels "it is
all code".

Now let us be really outspoken:

Synthesis is not Compilation, although compilation is a form of
synthesis. When comparing the two, people generally consider the
outputs: compilation results in further code, now translated into binary
form. However, compilation is more like synthesis than translation.

Does not the binary result of synthesis define how an FPGA/CPLD/PLD
should react to stimuli. Doesn't a compiled program do the same for a
microprocessor? GIGO, Input, Process, Output. Who cares!! The argument
is a philosophical one and thus one of opinion anyway.

Here is a passing thought:
If ADA never existed, what format would VHDL have. VHDL's designers WERE
influenced. If C never existed, what form would Verilog or SystemC have.
Their designers are influenced. If chicken never existed, what would
everything else taste like!?!

Nme. God Bless.

P.S.

IMHO: We will always have Schematic entry, humans like pictures, CAD,
CAM, UML, SSADM, websites; we love diagrams and images, easier to digest.

Re: VHDL vs. Schematic Capture
Hi Gary,
    Quartus II 4.1 and newer versions have a graphical tool called the RTL
viewer. This tool will be great for you if you want to see how the
VHDL/Verilog/Schematic  you write translates into logic. Our customers and
our own developers and support folks use it extensively to debug their
circuits if they run into a problem, or to understand how logic gets
implemented. There is also a state machine viewer built into the RTL viewer
which will  show you the bubble diagram for your state machines written in
HDL.

The RTL viewer can be used to see the output after the synthesis step is
complete, but prior to Technology mapping into LUT's. There is another tool
called the Technology Map viewer which shows you the result after Technology
Mapping. Both Tools are available under the Tools menu and you can bring
them up after compiling your design. As you are already using Quartus they
are already on your desktop and one button click away.

Hope this helps,
Subroto Datta
Altera Corp.


Quoted text here. Click to load it



Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it

You guys working weekends as well now?

Will Quartus be available in a Linux release soon or has this occured
already. If yes, where, when and how much.......

Nme. God Bless.

Re: VHDL vs. Schematic Capture
Hi Dave,

    Quartus has been available on Linux for the past two years. Red Hat
Version 7.3, 8.0 and Red Hat Enterprise 3.0 are supported with Quartus II
5.0. We will be dropping 7.3 in the next release. These have been tested
with both Opteron and Xeon CPU's. Based on comments from some of the power
Linux users they have had it working on other Linux distributions. This
product will require the purchase of a Linux subscription. You will need to
contact your distributor or the Altera Telsesales group depending on your
location. Check http://www.shopaltera.com/design_software.asp for contact
information.

Hope this helps,
- Subroto Datta
Altera Corp.



Quoted text here. Click to load it



Re: VHDL vs. Schematic Capture
Hi Dave,

Quoted text here. Click to load it

A tool is only as capable as the person using it.  For the same "function",
some can easily create schematics as fast as anyone can code in HDL, if that
schematic person knows what they are doing.  The key is symbol libraries,
and better yet, tested libraries (thank you Philip ;-)...which allows
hierarchical, basically, drag and drop, schematics.  This can be done with
datapaths, as well as state machines, functions etc.  It's as good (or as
poor) as you want it to be, depending on how much work you put into your
libraries.

Of course, it takes time to build up a good library, but not *that* much
time, and the time it saves in the long run can be huge.  People seem to
like to draw gates...why I don't know.  My schematics are like block
diagrams, and alleviate the "need" that people have to turn HDL code into
block diagrams to understand what it does.

I won't contend that if starting from scratch, HDLs will typically have an
edge on time to completion, and the tools today are far better than a decade
ago, but that does not diminish my point.  IF someone had come out with a
library that was publicly available, schematics would have been quite a bit
more popular.

This capability (having a large library of pre-built schematic modules) was
a huge advantage I had for many years being an independant contractor.  I
was able to do designs that met performance goals of speed and resource
utilization, as well as do them very quickly and cost effectively. But,
basically, schematics for FPGAs, at least Xilinx FPGAs, are dead today, IMO.

But, without schematics, I could not have done the designs I did in the
earlier Xilinx series parts (2k, 3k & 4k), as the synthesis tools were
rather poor back then, and required far more work to get the results to come
close to the speeds (and densities) achievable with schematics.  Using an
HDL simply as a netlister is not a very good use of the tool IMO...but now,
that is the only way to get every Hz out, is to instantiate what you need to
using HDL.  Sigh.

There is not a thing wrong with schematics compared to HDLs, and schematics
even have many advantages, but today, they just aren't popular.  HDLs are.
It has not a wit to do with schematics lack of ease or capabilities.

Regards,

Austin



Re: VHDL vs. Schematic Capture

Quoted text here. Click to load it

I agree with that. BTW: Altera / Quartus has still a very good schematic
editor. The only problem (surprise): It is not vendor-independend. If you
have a large schematic design, it would be a huge effort to transfer this to
e.g. Xilinx.

Many people explained correctly that you have to think "hardware" when you
are writing VHDL. Therefore I think, graphic design is even a "higher level
language" then VHDL because the schematics are better human readable in many
cases. For e.g. state-machines and simulation, things are different, of
course.

So a mix of VHDL and schematic design (top-level: schematic, with
sub-modules that may also be in VHDL) would be perfect. Is there any good
tool out there that can convert such a graphic/VHDL-mixture into a
vendor-independent VHDL-design?

Regards,

Thomas

www.entner-electronics.com



Re: VHDL vs. Schematic Capture
Hi Thomas,

Quoted text here. Click to load it

I've been doing exactly that for many years.

Quoted text here. Click to load it

Well, kind of...ViewDraw is capable of doing exactly that, but it is
currently not supported by Xilinx.  You simply set the schematic symbol to
point to, well, pretty much any HDL, even Abel.  Not sure how this flow
works with the new tools though...file formats have changed since I've done
this.

On the issue of vendor independance, my libraries ARE vendor independant.
Only the lowest level elements are vendor depeandant.  Of course, some
elements aren't available in some technologies...so no matter what, you are
still vendor dependant in most designs.  But, I've also never ever ever in
the many dozens of dozens of designs I've done had to convert from one FPGA
vendor to another.  I have converted say, a 4k design to a Spartan (big
deal, their the same ;-), or 2k to 3k...

Regards,

Austin



Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it

There have been many tools in the past. I would guess that 5-10 years
ago, quite a few true schematic programs allowed this. I used one of
them for a number of years. It would output VHDL code and also xnf
files, so that I would simulate in Modelsim and then incorporate the
various bits and pieces during ngdbuild. Another kind of tool was the
HDL graphic tools, which were good for the block diagrams you talk
about, along with generally providing graphical state diagram creation.
I also used one of these in the past.

I prefer the schematic/graphic input tools. I generally find that they
are easier to look back at and figure out what is going on. They are
generally quick and easy to use, especially as mentioned once a library
has been developed.

But I have completely abandoned all the graphical tools for the tedious
process of coding in VHDL directly. In general, industry expects HDLs. I
had a reviewer for a customer complement a design, and then make an
offhand comment about it being done schematically, in a tone that
conveyed his surprise at that.

But really the main reason was that I have seen far too many
schematic/graphical tools come and go. In a previous employment
incarnation, we had to keep around an old Windows 3.1 machine gathering
dust in a corner, just to support the schematics from an old but still
active project. And the schematic package mentioned above that I used
for mixed schematic VHDL designs is now also obsolete, and I am once
again keeping an old schematic program around to support old designs.

Well no more! ;) That is a problem that is far less likely to happen
with HDLs. And while I still consider VHDL tedious, I have come to
appreciate the strengths of doing designs this way. Not least of which
are the many very simple methods available for doing source control.

Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it
Well yes and no. Schematic design and data entry pre-date HDLs. The
place and purpose of schematics is well known. They will always exist.

I do however believe you are flawed in thinking that the time taken to
type multi-layer package/module replications is longer compared with
cut/load/insert and paste, then linking the wires manually. But hey, I
use the Altera MAX/Quartus schematic entry tools; there are better tools
available.

Quoted text here. Click to load it
Again, I think you are comparing HDL starting from scratch with
schematic libraries. You can also have VHDL libraries.

Quoted text here. Click to load it
This is the key area were schematic entry beats HDL entry hands down,
schematic entry is automatically self documenting. However, there are
tools to do this.

Developers I have met can visualise the schematic just from reading the HDL.

Quoted text here. Click to load it
k....

today, IMO.
You prefered schematics, others have HDLs. Like I said to Gary who
started the thread: Diagramatic description, design and management will
always have a place with humanity, we prefer pictures. New methods and
new tools have their place, but they don't always make old methods and
old tools redundant.

I am reminded of a comedian who told a story of a visit to the
Opticians. After putting on his new varifocals he found it very
difficult press lift buttons, walk off/on street edges, judge the
distance from cars etc. Eventually he got to a phone booth and called
his wife at home. He describing the disturbing events, his fear and
desperation and begged her to pick him up. Down the phone she snapped:
"Stupid! Take off your new glasses and come home!"

Quoted text here. Click to load it
FPGA/CPLD/PLDs will always implement binary constructions to provide the
desired application function(s).

Quoted text here. Click to load it
IMHO: HDLs will become hidden within purely diagramatic design tools,
much the same way software development is about module reuse and
UML/SSADM diagramatic tools now. Not the case back when I started.

Quoted text here. Click to load it

Re: VHDL vs. Schematic Capture
Hi Dave,

Quoted text here. Click to load it
"function",
Quoted text here. Click to load it
that
libraries,
with
as

I'm not sure what you could be saying "no" to, they are simply statements of
fact.

Quoted text here. Click to load it

No thinking involved, so no possible flaw in it ;-)  I speak from nearly two
decades of direct experience with FPGAs, and three decades of direct
experience with ASICs.  I know exactly what it takes to use both
methodologies, as well as a combination of both.  Also, pins aren't "linked"
entirely manually.  And, hooking wires is typically quite a bit faster than
typing things in.  I have not found this issue to be a significant part of
the process, on either end.

Quoted text here. Click to load it

No, not at all.

Quoted text here. Click to load it

Of course, I have plenty of them, but the time savings is far less
significant, than it is for schematic libraries.  Especialy for elements
such as muxes/counters/registers/IO, things that are multi-bit, that in HDLs
are one liners.  People who draw FPGA/ASIC schematics without such libraries
surely will take longer to implement the same than than someone will using
HDLs.

Quoted text here. Click to load it
into

I would disagree.  To repeat my self again, the tools are only as capable as
the person using them.  I have not seen many schematics drawn that well,
IMO.  The same goes with commenting HDL code, I see little of it actually
commented well...but if someone is skilled at communicating in this regard,
s/he can do a stupendous job.  I include ASCII block diagrams and timing
diagrams in my HDL.  It helps me remember what it is I was trying to do,
much less anyone else!

Quoted text here. Click to load it
HDL.

To me, that's kind of a "so what".  I can certainly visualize the dataflow
of HDL code, as I believe any good coder would be able to, but what good is
that excpt for the immediate point in time?  It doesn't help anyone else,
and doesn't help me the next time I go to look at it.  A block diagram of
some kind, at least for the datapath, I believe is far more useful.

Quoted text here. Click to load it
an
decade
a
bit

?

Quoted text here. Click to load it
was
I

Actually, no.  I prefer the tool that gets the job done in the least amount
of time, including making it work...which means making timing, and making
the design fit.  HDLs were not capable of getting the job done.  Now, they
are far more capable (for varied reasons), and therefore useful.  Not only
are the synthesizers better but IMO the biggest bonus to HDLs is that FPGAs
are larger and faster.  The same thing happened to high level software
programming languages and CPUs/memory/disk drives.  People don't need to be
as skilled, in general, these days as they used to have to be to get a
majority of the FPGA jobs done.  This is a good thing for the industry IMO.

Quoted text here. Click to load it

Of course.

come
an
now,
need to

I don't see how that relates to my comment...

Quoted text here. Click to load it
schematics
are.

Possibly, but one of the arguments is that makes them tool specific and
non-portable.  This is an arguement that has been around for decades.

Regards,

Austin



Re: VHDL vs. Schematic Capture
Quoted text here. Click to load it

Gary, are you still listening? Like I said before:
"If you are considering learning VHDL (or Verilog), my advice is a
resounding YES; Do it, learn it."

Austin, Austin.....

More than two decades working with programmable logic and you are NOT
READY to suggest that learning VHDL or Verilog would enhance the skill
set of a schematic designer!

Tell the truth, you want to be the only one with multiple skills don't
you!! ;-)

I whole heartedly encourage Gary to "code in HDL"; he already uses
schematic entry and doesn't require any encouragement maintaining that
skill.

Re: VHDL vs. Schematic Capture
Hi Dave...

Quoted text here. Click to load it

You're putting words in my mouth that I didn't say or even remotely hint at!

Of course someone working with programmable logic should, these days, learn
an HDL.  I never said differently, nor even addressed that issue.

Quoted text here. Click to load it

I would too...but that isn't what I was commenting on, now was it? ;-)

Regards,

Austin



Re: VHDL vs. Schematic Capture



Quoted text here. Click to load it
I also like schematics for "random" logic, such as a bus controller/decoder.

But, there's some stuff that is just so much more concise in VHDL.  One
example
is a Gray-binary or binary-Gray code converter.  In schematic, it is a
string
of FFs and XORs.  In VHDL, it is a parameterizable one-line statement, with
the parameter being the # of bits.  (I may be exaggerating the
concise-ness just
a little, but both of these functions were completely coded in 4-6 lines.)
These were 48-bit converters for time codes.

I also did an experiment just to stretch my VHDL writing skills and coded up
a do-nothing box that (pseudo)randomly changed bits in a 10 x 10 array,
and simultaneously
refreshed a 10 x 10 grid of LEDs, like a raster scan.  Each of those
bits was a
VHDL function, and each raster line looped through 10 bits, then the
line looped
through 10 iterations.  I compared (mentally) what this would look like
in the most
concise hierarchical schematic, and the superiority of the HDL was
pretty convincing.

Jon


Site Timeline