Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

General Tips of reading Verilog Code

Status
Not open for further replies.

davyzhu

Advanced Member level 1
Joined
May 23, 2004
Messages
494
Helped
5
Reputation
10
Reaction score
2
Trophy points
1,298
Location
oriental
Activity points
4,436
Hi all,

Is there any general tips of reading Verilog code. I want to collect these tips to accelerate code reading speed.

For example, shall I read the input signal first and trace them until output?
And shall I read from top to bottom or from bottom to top?
And shall I read the 'always' block first?

Any questions and comments are welcome :)

Best regards,
Davy
 

first,you should find out the funtion of module !!
 

Thats right...determine the function of any module first.
In a hierarchical design, look at the top level module and sort out the design, glue logic, memories other blocks/libraries from vendors etc.
Try to create a block level of how the design is implemented
Figure out the datapath and look at those modules first
within a module, determine inputs and outputs
look for state machines and determine the flow
rest of the code will be logic or buffers for the outputs

I cannot generalize more than this. Then it would vary according to what the design is doing
 

can we understand what has been implemented in the code with no detailed functionality given, ?

R\
 

beowulf said:
Thats right...determine the function of any module first.
In a hierarchical design, look at the top level module and sort out the design, glue logic, memories other blocks/libraries from vendors etc.
Try to create a block level of how the design is implemented
Figure out the datapath and look at those modules first
within a module, determine inputs and outputs
look for state machines and determine the flow
rest of the code will be logic or buffers for the outputs

I cannot generalize more than this. Then it would vary according to what the design is doing

Can you tell me what is the glue logic?
 

I think debussy is very helpful to read code.
 

I think you should start out from the design spec, and based on the integration maps if they are available, find out all the IO's and understand their definitions
and basic functionality.

I agree with the above posts, that it should be based on functional units for a complex design, understanding their functionality and interfaces to other functional units. Debussy could be of some helps on tracing signals and interconnects. The
comments within each code file should be also very helpful.

James,
 

Verdi is a very good tool for read verilog code
 

For glue logic :
Chk this general definition :
h**p://en.wikipedia.org/wiki/Glue_logic

There is no exact definition of glue logic. In hardware design (using HDL) we sometimes use 3rd party IP like say some memory cores/logic cores generated by xilinx core generator or maybe some memory model etc. Sometimes our interface may not be exactly compatible with this IP. We design some custom hardware (as mentioned in the definiton above) to make the interface work. This is glue logic, some people call it a wrapper (wrapper has other specfic meanings).

Comments or other definitions from members will also help here.

Beo

Added after 1 minutes:

Heres another definition :
h**p://computing-dictionary.thefreedictionary.com/glue+logic
 

When u review a design, u'd better got the spec including function discription firstly.
Then u could have a overview on the code for design hierarchy.
Make clear the reset strategy.
Make clear the clock domains.
Make clear the dataflow path.
Make clear how the protocol to deal with the data.
And finally study how to CONTROL the dataflow.
 

wangkl - well put , that is very similiar to my adopted strategy

each of those items requires a _seperate_ and _distinct_ study before the exact function can be understood.

I will add that with many designs the documentation is non-existant poor or incorrect - so be careful if you start with that first.

I have found that to quickly gain some understanding tools such as synplify, leonardo, debussy can be very helpful in visualizing and tracing paths through the design.

In some cases where you are still unclear of the function it also helps to setup a (rtl level) simulation and make some observations.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top