Dear Readers,
As we all know debugging is not an easy task and requires lots of attentions and effort to figure out the issues! Well, it is not at free of cost! (Debugging is not free!) This is true for both Design as well as Verification engineers.
Why the verification or design code becomes complex to handle at end of the day? What could be potential reason for this?
As we all know debugging is not an easy task and requires lots of attentions and effort to figure out the issues! Well, it is not at free of cost! (Debugging is not free!) This is true for both Design as well as Verification engineers.
ASIC/FPGAs are becoming more and more complex day by day and because of that RTL design and Verification environments are becoming super complex! Usually engineers start writing a code with good understanding in mind from defined specification or standards. With the complexity and sometime way of writing code makes design code / verification environment complex and difficult to handle. When debugging comes in picture, sometime discussion makes debugging easy. Thinking of possible scenarios, causes and problem solving ideas varies engineers to engineers! When you stuck with debugging some issue and you don’t get any clue, don’t spend huge amount of time debugging the same issue because “debugging is not free”, instead try discussing the scenario with your team mates, you would mostly get the hint or clue to identify and fix the issues. Obviously your colleague should be supportive in nature :). This is one of the potential places where TEAM work comes in picture!
Why the verification or design code becomes complex to handle at end of the day? What could be potential reason for this?
- Written code for Design/Verification itself is complex (because of thousands of functionalities, sometime because of way of writing)
- Engineers who have developed the design/verification environment start from scratch and leave the organization (Potential reason for now a day). In this case engineers leave with their all learning, concepts, tricks, algorithms and actual flow!
- When you don’t prepare architecture specification (top level as well as micro level). In this case you have to always rely on people who have been working on from years! This creates a solid dependencies for company, if those person leave because of any reason, it becomes very tough to maintain the design and verification environment for somebody who is new.
Customers always in hurry and wants their product ready and bug free! Critical situation comes when customer comes with their problem or with some new requirement support in design and you don’t have experienced person who have worked on this product. In this case engineers might face sleepless nights and will have to put lots and lots of efforts (because, they are not well aware of the design) to fulfill the requirement. Same requirements would have been fulfill with less amount of effort and as per expectation from client if engineers who have worked on this product are working!!
How could we avoid this type of pains?
- By making a habit of writing architectural documents with details. There could be different types of documents like top level architectural spec (which is useful for presentation), Micro level architectural documents (useful for engineers who are currently working and who will work in future as reference). Same is applicable for verification engineers for the architecture of verification environments.
- By not creating dependencies at certain level on any engineers and making sure that engineers keeps documenting changes/implementation done by them.
- By scheduling presentation/discussion on architecture and flow understanding for TEAM so that engineers working on the same product/protocol will gets understanding on flow.
- By following the standard verification methodology to reduce the pain of handing environment at certain extend since most of the methodology are user friendly and have many controls to handle complex environments.
Same blog post has been published on EDACafe blog portal, to access the same click here.
Happy Reading,
No comments:
Post a Comment