Visualizing VHDL

When you write VHDL (or Verilog for that matter), do you visualize a
schematic with wires, gates, flops, latches, muxes, etc., or do you
use some other way of thinking about it?

Kevin

"Kevin Kilzer" wrote:

> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?

I don't know about visualizing (I do a lot of pencil drawings), but you are
describing hardware.  If you loose that focus you are bound to create
monstruous designs that will not perform well at all.  If you are a hardware
guy it is a subconscious thing to simply think in those terms.  I typically
start with the hardware I want to create and simply use HDL to describe it.
You can either rely on inference (which can be dangerous) or explicitly
instantiate what you need.  I tend to favor actually wiring-up what I want
or using inference when I know that the tools won't screw it up.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

On Wed, 08 Oct 2003 05:49:40 GMT, Kevin Kilzer
<kkilzer.remove.this@mindspring.com> wrote:

>When you write VHDL (or Verilog for that matter), do you visualize a
>schematic with wires, gates, flops, latches, muxes, etc., or do you
>use some other way of thinking about it?

I don't think about gates and muxes, because the FPGAs I use have
LUTs.  
So I think about clouds of LUTs and flip flops.  The only significant
thing (for my application) about a cloud of LUTs is the depth, which
determines the delay.

Regards,
Allan.

I always visualise what I want, not how I get there..
there's an old saying.. if you keep looking down you will never see the sky.

Same with FPGA's.. if you keep looking at the gates, you miss the big
picture..  VHDL and Verilog allow you to design high level.  think
concepts.. then thing solutions.. same as designing Top Down Software.

Simon

"Kevin Kilzer" <kkilzer.remove.this@mindspring.com> wrote in message
news:qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com...
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?
>
> Kevin
>

Kevin Kilzer wrote:
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?

Generally, no.  If the function is easily described in gates and
FFs, it seems most concise to describe it as a schematic, and then
either convert it to VHDL or feed it to the XST tools.  For many
things, I find that VHDL leads to endless pages of mind-numbing
text, where a schematic is just a couple of sheets of easily
absorbed signal flow.  One place that it was so obvious to use VHDL
was a set of 48-bit binary to grey code and grey code to binary
translators.  With the for loop, these compacted down to about
5 lines of code, each!  So, these functions became VHDL symbols on
my schematic.

But, you HAVE to keep in mind that what you get, in terms of actual
logic, is not what you specify in a schematic!  The boolean function,
from the inputs and the outputs will match, but anything you do to
control signal timing in the combinatorial structure will disappear.
I needed to delay some signals, and just threw in some extra gates.
Of course, this had no effect on the boolean functions from input
to output, and so were optimized away.  So, finally, I realized I
needed to bring signals off-chip, through an external RC, and back
in to do what I wanted.

If what you are doing is more purely mathematical, such as ALUs,
registers, buses, and calculations being performed, then VHDL
(or the HDL of your choice) may be vastly more organized than
a schematic.

Jon

"Jon Elson" wrote:

> I needed to delay some signals, and just threw in some extra gates.
> Of course, this had no effect on the boolean functions from input
> to output, and so were optimized away.  So, finally, I realized I
> needed to bring signals off-chip, through an external RC, and back
> in to do what I wanted.

Ouch!  This is really, I'll repeat, really bad design practice.  Even if it
worked (and there are way to make it work) you'd be primed and ready to be
victimized by a whole host of variables that can break your delay or make it
problematic at best.

You can't just draw pretty schematics without having a sense of what's in
the chip and how your schematic will be translated.  That's suicide.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

I visualize what I want, then draw a schematic of it.  Then I think to
myself "...self, the design is now done, why bother with that HDL garbage at
all?..."

I've never been able to come up with a compelling reason to go beyond
schematics, once the job is done.  That would be like working for the
Department of Redundancy Department.

An added bonus is that I'm off doing the next job instead of numbing my
brain by turning a perfectly good schematic design into a perfectly useless
text file.




"Kevin Kilzer" <kkilzer.remove.this@mindspring.com> wrote in message
news:qg97ovc5hrf4aii8qe858uljdpg14d5rp9@4ax.com...
> When you write VHDL (or Verilog for that matter), do you visualize a
> schematic with wires, gates, flops, latches, muxes, etc., or do you
> use some other way of thinking about it?
>
> Kevin
>

"Patrick MacGregor" wrote:

>I visualize what I want, then draw a schematic of it.  Then I think to
>myself "...self, the design is now done, why bother with that HDL garbage
at
>all?..."
...
> I've never been able to come up with a compelling reason to go beyond
> schematics, once the job is done.

Proably because you have yet to run into a design that makes you rethink
your position.  Not a putdown at all, just a fact.  Schematics might be
nicer/easier to deal with (particularly if you are old school) for small,
stable, well-defined projects that might not require a lot of future
maintenance.  In most cases these designs are trivial to implement in HDL.
Please, I say this again, don't take this as a putdown, that's not the
intention here.

Believe me when I say that there's absolutely no doubt that HDL's are the
way to go.  You start getting into large million-gate FPGA's with complex
logic and schematics are not even an option.  Some will use schematics to
wire-together top level entities.  That's fine.  That works.  For anything
else it would be just about insanity to attempt to use schematics.

> turning a perfectly good schematic design into a perfectly useless
> text file.

You start doing non-trivial (from an HDL standpoint) designs and it's the
other way around.  A schematic would be perfectly useless.

I'm not thrilled about still using ASCII to design hardware, don't get me
wrong.  But, until someone come up with a better way to do it, it's the best
we got.  Period.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

A properly done hierarchical schematic can be used in large designs just as
effectively as an HDL.  I'll take a well done schematic over sloppy HDL or  a
well done HDL over sloppy schematics any day.  The key to a readable and
reusable design is extensive use of hierarchy.   The HDLs do have some
advantages:
1) it is far easier to make parameterized macros in an HDL than it is with
schematics.  This is important for design reuse.  It can be done with
schematics, but there is more manual intervention for the reuse.  I know, I've
gotten far more reuse in my business than most businesses achieve both with HDLs
and with schematics.
2) Complex simulations are easier with HDLs, as you can write behavioral models
for the interfacing circuits rather easily without having to create a circuit.
3) Design archives are easier to revisit in that the source is viewable in a
standard text editor.  Schematic editors generally need the same tool they were
created by in order to view electronic archives.  Some schematic editors even
change the format of the databases with new releases.  Viewlogic did that two or
three times over the time that I used it.

The fact of the matter is the industry has moved to HDLs, so in order to keep
yourself marketable (no job is forever), you should bite the bullet and learn at
least one HDL.

>

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Martin Euredjian wrote:
> "Jon Elson" wrote:
> 
> 
>>I needed to delay some signals, and just threw in some extra gates.
>>Of course, this had no effect on the boolean functions from input
>>to output, and so were optimized away.  So, finally, I realized I
>>needed to bring signals off-chip, through an external RC, and back
>>in to do what I wanted.
> 
> 
> Ouch!  This is really, I'll repeat, really bad design practice.  Even if it
> worked (and there are way to make it work) you'd be primed and ready to be
> victimized by a whole host of variables that can break your delay or make it
> problematic at best.
> 
> You can't just draw pretty schematics without having a sense of what's in
> the chip and how your schematic will be translated.  That's suicide.
> 
> 

Well, it is working in a production product.  I didn't need much delay,
and it was not critical at all.  The purpose was to make sure that a
register was incremented at the end of a data transfer, and to be sure
the address lines did not change while the strobe line was still in the
active state.  This is on a CPLD which is the only logic component
on a board.  The board does not have a clock, either.  The delay was
implemented with a 5.1K resistor, and the C is the capacitance of the
input pin of the CPLD.  This is on an XC9572 chip.  The next bus cycle
will be at least 500 nS later.

A related product needs a lot more logic, and it has a clock, so I
used a much more proven delay technique on that one.  It uses a
Spartan FPGA.

Jon