Large block visualization

[Verictor]

Hi,

Is there a way to vision how a very large block written in Verilog is
connected? It is kind of a schematic tool but Synopsys' GUI tools
don't meet my requirement because it is very hard to trace connection
in that way. For example, it is not possible to trace a state machine
coding in this way.

I may have used a wrong approach in digging into the schematic. Anyone
has experience in understanding a barely documented design?

Thanks

 

[gabor]

On May 21, 11:55 am, Verictor <stehu...@gmail.com> wrote:

Hi,

Is there a way to vision how a very large block written in Verilog is
connected? It is kind of a schematic tool but Synopsys' GUI tools
don't meet my requirement because it is very hard to trace connection
in that way. For example, it is not possible to trace a state machine
coding in this way.

I may have used a wrong approach in digging into the schematic. Anyone
has experience in understanding a barely documented design?

Thanks

I think anybody who has taken over a project has experience in
*trying* to understand a barely documented design. In my
experience it's most important to understand the design requirements,
because if your intent is to fix someone else's broken Verilog
code you're generally better off re-writing the sections where
the code is hard to understand.

There's a pretty good book called "Debugging Rules" (O.K. this
is a plug, a friend of mine wrote it), and in this case the
rule of thumb is "Understand the system." Going through code
from the bottom up is generally a bad way to understand the
system. If you know what the design is intended to do, but
can't figure out how some lower level code works (or should work
if it's broken), at least you have an idea of what to do if
you decide to re-write that module.

Sorry I don't have any silver bullets for you, and I feel your
pain

Regards,
Gabor

 

[Mike Treseler]

Verictor wrote:

Is there a way to vision how a very large block written in Verilog is
connected? It is kind of a schematic tool but Synopsys' GUI tools
don't meet my requirement because it is very hard to trace connection
in that way. For example, it is not possible to trace a state machine
coding in this way.

The quartus rtl viewer does a good job of this.
See the "object" examples here:
http://home.comcast.net/~mike_treseler/
for an example.

It is not free, but worth the price in my opinion.

-- Mike Treseler

 

[Larry Lapides]

One technique one of our customers has used is to write
properties/assertions which should describe the functional behavior of
the design. When a property is proven correct, it becomes part of the
spec for that design. This is an iterative process, and takes some
time, but it has worked.

Larry Lapides
larry@averant.com



gabor wrote:

On May 21, 11:55 am, Verictor <stehu...@gmail.com> wrote:

Hi,

Is there a way to vision how a very large block written in Verilog is
connected? It is kind of a schematic tool but Synopsys' GUI tools
don't meet my requirement because it is very hard to trace connection
in that way. For example, it is not possible to trace a state machine
coding in this way.

I may have used a wrong approach in digging into the schematic. Anyone
has experience in understanding a barely documented design?

Thanks



I think anybody who has taken over a project has experience in
*trying* to understand a barely documented design. In my
experience it's most important to understand the design requirements,
because if your intent is to fix someone else's broken Verilog
code you're generally better off re-writing the sections where
the code is hard to understand.

There's a pretty good book called "Debugging Rules" (O.K. this
is a plug, a friend of mine wrote it), and in this case the
rule of thumb is "Understand the system." Going through code
from the bottom up is generally a bad way to understand the
system. If you know what the design is intended to do, but
can't figure out how some lower level code works (or should work
if it's broken), at least you have an idea of what to do if
you decide to re-write that module.

Sorry I don't have any silver bullets for you, and I feel your
pain

Regards,
Gabor

 

[Mike Treseler]

Larry Lapides wrote:

One technique one of our customers has used is to write
properties/assertions which should describe the functional behavior of
the design. When a property is proven correct, it becomes part of the
spec for that design. This is an iterative process, and takes some
time, but it has worked.

I'm sure it has, but simulation
testbenches and assertions are the egg.
Until I start to "Understand the system"
I don't have a chicken.

-- Mike Treseler