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.

How to understand a project through code reading

Status
Not open for further replies.

verylsi

Full Member level 2
Full Member level 2
Joined
Mar 12, 2012
Messages
123
Helped
16
Reputation
32
Reaction score
16
Trophy points
1,308
Activity points
2,130
Hello every1

I am in kind of situation where I have to understand a project in say 1 month, all I have is - set of codes.. around 10 blocks and around 50 VHDL codes with lots of FIFOs Dual port ram , packages involved, not to mention few components are missing making it even more difficult because I cannot run it on simulator.

I am in need of a desperate suggestion from the experts - how to approach in such situation.
 
Last edited:

1. Find as much documentation as you can (that includes comments)
2. Speak to the origional designer.
3. Look at the rtl schematics.
4. Scratch your head.
5. Draw stuff.

Apart from that, try not to take on these projects in the first place.
 

Draw its Architecture ( by using entity and portmap components)
Try to learn in top to bottom approach.
 

1. Find as much documentation as you can (that includes comments)
probably none as the code isn't even complete, probably means there's no source control system in place either.
2. Speak to the origional designer.
probably got laid off due to 1.
3. Look at the rtl schematics.
probably lack of one contributed to 1 (incomplete code)
4. Scratch your head.
don't make yourself go bald doing this. ;-)
5. Draw stuff.
This is what I would start with. But I wouldn't necessarily draw it according to the top-top-bottom approach as shahulakthar suggests. There is probably a good reason why you have incomplete code and I'd look carefully at the way the design is broken up into modules.

Your best bet is to try and look over the types of blocks you have and how they are interconnected so you get an idea of the structure of the design. Look at the RAMs/FIFOs and see where they are in the design what blocks they interface between. I usually get a feel for the overall dataflow of the design through code inspection then start drawing a schematic of the design using counters/memory/math_ops/control(fsm)/etc based on my understanding of the dataflow. After that you should have a pretty good idea how the design works. Along the way I usually start adding comments to the code that aren't like your typical comments you'll usually find in peoples code you inherit e.g: Comment found in code - // the address counter .... my replacement: // generates addresss to the yada yada when the enable is returned from the sequencer during write commands from the uC and reads from the processing FSM, arbitration is handled by...etc.

Apart from that, try not to take on these projects in the first place.
:) Nice idea but fails in practice ;-)
 
  • Like
Reactions: verylsi

    verylsi

    Points: 2
    Helpful Answer Positive Rating
Thanks Tricky, Shahulakhtar and ads_ee,

Yes I have absolutely no documents and absolutely no help from the designer and the comments are so obvious which is of no help either.
But I really like the suggestion of drawing stuffs the way ads_ee mentioned...
 

Thanks Tricky, Shahulakhtar and ads_ee,

Yes I have absolutely no documents and absolutely no help from the designer and the comments are so obvious which is of no help either.
But I really like the suggestion of drawing stuffs the way ads_ee mentioned...

Take it from me it will help you a lot. I've been in your shoes more often than I care to remember. I've gotten very adept at creating a block diagram of a design from nothing but the code. It sucks having to do it, but think of having that in your arsenal of skills :) Just don't forget to write comments in the code when you finally figure out what each chunk of code really does. It might be beneficial to delete all the former designer's comments from the code as they may be misleading (people are notoriously bad at updating comments when they change code, I try very hard to always update them).

The worst type of RTL is the kind where after looking it over for days on end you finally realize the designer had there head mounted somewhere south of their waist ;-). I hope you're more fortunate than that.

Good luck with your project from hell. ;-)

As Commander Jason Nesmith would say: Never give up, never surrender!

Regards,
-alan
 
  • Like
Reactions: verylsi

    verylsi

    Points: 2
    Helpful Answer Positive Rating
I hate those who don`t write comments; I hate writing comments...haha
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top