Visualizing VHDL

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

I never start writing HDL code until I have visualised the design. I don't 
visualise it in my head - I use a graphics program to draw and save the 
stuff (I use Visio).
Browsing old design documentations, I'd say that a visualisation is a mix
of drawing types:

Data path stuff is drawn as a path - busses are arrows, functions are
circles, registers are rectangles.

Control and interface is a combination of state diagrams and annotated
waveform diagrams (clock cycles, cause/event arrows and various comments).

For managing pipelines, I usually draw (or write with a spreadsheet program)
a two-dimentional table, with time as one dimension (clock cycles) and 
the various pipeline stages as the other dimension.

I almost never visualise a design in schematic form - at the most, I see
registers, muxes and a combinatorial logic "cloud".

Hope this helps.

Assaf Sarfati wrote:
> 
> 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
> 
> I never start writing HDL code until I have visualised the design. I don't
> visualise it in my head - I use a graphics program to draw and save the
> stuff (I use Visio).
> Browsing old design documentations, I'd say that a visualisation is a mix
> of drawing types:
> 
> Data path stuff is drawn as a path - busses are arrows, functions are
> circles, registers are rectangles.
> 
> Control and interface is a combination of state diagrams and annotated
> waveform diagrams (clock cycles, cause/event arrows and various comments).
> 
> For managing pipelines, I usually draw (or write with a spreadsheet program)
> a two-dimentional table, with time as one dimension (clock cycles) and
> the various pipeline stages as the other dimension.
> 
> I almost never visualise a design in schematic form - at the most, I see
> registers, muxes and a combinatorial logic "cloud".
> 
> Hope this helps.

I read all the other posts and this was the solution that is closest to
what I do.  I never think about the coding of the HDL until I have
already done all the planning of my design.  The planning involved
functionaly partioning which is just a drawing with a bunch of boxes
interconnected with arrows for signals.  Then I iteratively break those
boxes down into smaller boxes until I get to the point that I am showing
a fleshed out data path and/or I have the lowest level of my logic with
consists of symbols like registers, adders, muxes and control boxes
(state machines).  At this point my hardware is defined and I can start
to write code which describes this hardware.  

I design FPGAs the same way I design software.  I plan, modularize,
implement and finally test (or simulate in the case of FPGAs).  For
hardware my drawings are often just hand drawn.  If I want to keep them
for documentation, I use Visio.  

But I never code my HDL like I code software.  I use an HDL to describe
the hardware I want compared to software where I code to describe my
solution.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX