how to read and understand long written VHDL code?

[walala]

Dear all,

Reading and understanding the code written by other people is common work
for programmers... I am quite familiar with C and I like to use MS Visual C
debugger to trace the dynamic execution of the program and hence understand
the code more quickly, in addition to statically reading the code...

For VHDL, I did not find similar method for reading and understanding code.
VHDL code are block by block and no sequence between the blocks... Modelsim
can simulate it but that's not quite similar to MS Visual C debugger... no
relationship and data flow can be traced... is there any step-by-step
debugging in Modelsim?

Anyrate, in general, is there any general hints on how to understand and
read code more quickly for VHDL?

Thanks a lot,

-Walala

 

[jussi l]

There are some programs that generate RTL level netlist based on the VHDL
description. Typically, you will need to simulate and see the signals.
That's why I personally like using Active-HDL because it allows you to
change testvectors manually (i.e. no testbench needed). Finally, I think you
have to know some background for the design. Say, it's a code for FFT, you
need to know how FFT works.

Just some thoughs, generally it's a pain in the butt
juza

Reading and understanding the code written by other people is common work
for programmers... I am quite familiar with C and I like to use MS Visual
C
debugger to trace the dynamic execution of the program and hence
understand
the code more quickly, in addition to statically reading the code...

For VHDL, I did not find similar method for reading and understanding
code.
VHDL code are block by block and no sequence between the blocks...
Modelsim
can simulate it but that's not quite similar to MS Visual C debugger... no
relationship and data flow can be traced... is there any step-by-step
debugging in Modelsim?

Anyrate, in general, is there any general hints on how to understand and
read code more quickly for VHDL?

Thanks a lot,

-Walala

 

[Jonathan Bromley]

"walala" <mizhael@yahoo.com> wrote in message
news:bimojv$21s$1@mozo.cc.purdue.edu...

Dear all,

Reading and understanding the code written by other people is common work
for programmers... I am quite familiar with C and I like to use MS Visual
C
debugger to trace the dynamic execution of the program and hence
understand
the code more quickly, in addition to statically reading the code...

For VHDL, I did not find similar method for reading and understanding
code.
VHDL code are block by block and no sequence between the blocks...
Modelsim
can simulate it but that's not quite similar to MS Visual C debugger... no
relationship and data flow can be traced... is there any step-by-step
debugging in Modelsim?

Two things: (1) Find out about ModelSim's "dataflow" window - it helps
to understand the relationship between signals and processes; (2) ModelSim
has a fine single-step and breakpoint facility; the only problem is that
execution jumps around from process to process (of course) and ModelSim's
debugger is not very clever about helping you with that problem.

Anyrate, in general, is there any general hints on how to understand and
read code more quickly for VHDL?

Practice, extrasensory perception, and an arm-lock on the original
author are all useful in my experience

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Uncle Noah]

I see a mistake lurking here. It is usual for programmers to compare
VHDL with common programming languages. Which is wrong.

In VHDL you get to describe hardware. Connectivity and functionality.
Programming notions like modular programming den't have meaning when
writing synthesizable VHDL. (However encryption of deliverable code
has!)

The best chances to comprehend other people's work is when they
followed specific guidelines in writing the code. Like signal naming
conventions etc.

There exist some documents on the web that discuss teamwork and coding
for readability. Tools for formal checking and equivalence checking
could be used in some way if they were not still in their infancy.

Regards
Uncle "The G.B. Man" Noah

 

[VhdlCohen]

The best chances to comprehend other people's work is when they
followed specific guidelines in writing the code. Like signal naming
conventions etc.

There exist some documents on the web that discuss teamwork and coding
for readability. Tools for formal checking and equivalence checking
could be used in some way if they were not still in their infancy.

You'll find that tools are now maturing in the field pf formal verification.

Assertion-Based Verification (ABV) with PSL is getting acceptance in the
industry
because it really helps in the design documentation, definition, and
verification (including dynamic (thru simulation) and static (thru formal
verification tools).
Many tools now support PSL for VHDL and Verilog.
If the design in question were documented with PSL, it would have been a lot
easier to understand the code and to verify the model.
Ben
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

 

[Mike Treseler]

walala wrote:

Anyrate, in general, is there any general hints on how to understand and
read code more quickly for VHDL?

It helps to write and sim some synth code of your own,
before you read much by others.
Design styles vary widely and it takes a
while to get a grip on multiple processes running
simultaneously in zero time, whatever the style.

There are several reasons why you might invest time reading code.
Some cases have a poor return on investment.

Maybe you want to:

[] Learn the VHDL language.

In this case, consider a textbook with good
example "snippets" rather than a detailed design.


[] Instance a "known-good" entity into your project

If an entity has been used before, does what you
want, and has a testbench, you might forgo much
detailed reading of the code and focus on the
rest of the design.

[] Small modification of a "known-good" entity.

This requires detailed reading and simulation of
the signals under change. You have to trade off
the modification time with wrapping the changes
around the entity as is.

[] Learn the author's approach a class of design problems

Seeing examples of the same class of problem
you are solving may be worthwhile in the
brainstorming stage. But at some point, you
have to get down to business and write a
well documented source, in your own style
that solves your problem exactly.


-- Mike Treseler

 

[Marcus Harnisch]

nkavv@skiathos.physics.auth.gr (Uncle Noah) writes:

In VHDL you get to describe hardware. Connectivity and functionality.
Programming notions like modular programming den't have meaning when
writing synthesizable VHDL. (However encryption of deliverable code
has!)

I disagree. The major benefit of VHDL compared to "the other HDL" are
its abstract, high-level constructs. Not only for writing testbenches
but also to describe real hardware. What you seem to propose is
writing VHDL in a style that doesn't take advantage of all that.

It is these features that (can) make VHDL code very easy to read and
understand. You can, of course, write unreadable code in any language
-- even in Perl :^)

Best regards,
Marcus