Asic With Ankit
Member
Dear Readers,
Debugging is not free!!
Looks very true statement for ASIC Engineers especially who are contributing/working on Verification. Any test bench must be planned and test bench supports debug is no exception!
Debugging large test benches has changed recently. The test benches are becoming larger and complex than they used to be. In addition to these test benches are now using object oriented constructs, class based libraries, methodologies for verification components. Each of these features adds to the pain of debugging the test benches.
There are couple of major things which should be well take care while architecting the test bench to reduce the pain of Debugging activities (nobody can reduce this activity/phase completely)
1. Well organizased layered architecture of designing test bench.
Test bench should be desinged with debug in mind ! While defining test bench architecture, engineers should make sure each functionalities/features and cover points, How to cover and organize? Transaction based architecture is really useful to maintain, debug and organize the testbenches, specially when the test benches are really comlex. Layered architecture is one of the major architectural strategy which helps engineers during their debugging phase.
2. Naming conventions, directory structure, Class names, class members variables
Engineers are usually not paying attention on these type of such small small things but are very important! Naming conventiaons, directories and class and members names will not affect your functinality or feature during your verification activity but they will surely help you to reduce your debugging burden!!
Naming conventions help eliminate mistakes by being consistent and simple to understand. Finding things becomes easy. For example finding all the i2c_scoreboard factory creation calls in test bench is easy with grep, we can simply do a grep given below given command:
grep -r i2c_scoreboard *.sv
These things are really helpful to engineers when they starts working on the already designed test bench. There are many product based companies who are keep using their designed test bench from years !! In this case what happens is, when new engineers starts working on these types of compex test bench, they will feel more conform while debugging if the conventions and such things are followed. Otherwise to understand these type of minor things consumes engineers most of time which is pain for organization!!
3. Selecting methodologies while architecting the environment
Methodogolies are performing major part during the debugging phase. All the methodologies have their specially feature and abilities to help designing and debugging the environments / test benches. UVM/VMM/OVM and other methodologies reporting system (messaging) have many abilities including verbosity control, message IDs filtering and hierarchical property setting.
There are many messaging features in methodologise like dynamic message controlling. Sometime certain debuggin should start after many clocks or after some condition is reached. Once condition reached we want to change the verbosity level, we can do this using the methodology feature, For example : In UVM :
repeate (100000) @ (posedge clk);
i2c_agent_h.set_report_verbosity_hier(....);
This way we can set the verbosity level when we want to avoid generating large log files and to make debug easy, This way there are hundreds of other feature which helps in debugging, please refer methodology reference manual for further details.
Keeping these things in mind if we design test bench, we will surely be saving our deugging time!
-ASIC With Ankit
<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>
Debugging is not free!!
Looks very true statement for ASIC Engineers especially who are contributing/working on Verification. Any test bench must be planned and test bench supports debug is no exception!
Debugging large test benches has changed recently. The test benches are becoming larger and complex than they used to be. In addition to these test benches are now using object oriented constructs, class based libraries, methodologies for verification components. Each of these features adds to the pain of debugging the test benches.
There are couple of major things which should be well take care while architecting the test bench to reduce the pain of Debugging activities (nobody can reduce this activity/phase completely)
1. Well organizased layered architecture of designing test bench.
Test bench should be desinged with debug in mind ! While defining test bench architecture, engineers should make sure each functionalities/features and cover points, How to cover and organize? Transaction based architecture is really useful to maintain, debug and organize the testbenches, specially when the test benches are really comlex. Layered architecture is one of the major architectural strategy which helps engineers during their debugging phase.
2. Naming conventions, directory structure, Class names, class members variables
Engineers are usually not paying attention on these type of such small small things but are very important! Naming conventiaons, directories and class and members names will not affect your functinality or feature during your verification activity but they will surely help you to reduce your debugging burden!!
Naming conventions help eliminate mistakes by being consistent and simple to understand. Finding things becomes easy. For example finding all the i2c_scoreboard factory creation calls in test bench is easy with grep, we can simply do a grep given below given command:
grep -r i2c_scoreboard *.sv
These things are really helpful to engineers when they starts working on the already designed test bench. There are many product based companies who are keep using their designed test bench from years !! In this case what happens is, when new engineers starts working on these types of compex test bench, they will feel more conform while debugging if the conventions and such things are followed. Otherwise to understand these type of minor things consumes engineers most of time which is pain for organization!!
3. Selecting methodologies while architecting the environment
Methodogolies are performing major part during the debugging phase. All the methodologies have their specially feature and abilities to help designing and debugging the environments / test benches. UVM/VMM/OVM and other methodologies reporting system (messaging) have many abilities including verbosity control, message IDs filtering and hierarchical property setting.
There are many messaging features in methodologise like dynamic message controlling. Sometime certain debuggin should start after many clocks or after some condition is reached. Once condition reached we want to change the verbosity level, we can do this using the methodology feature, For example : In UVM :
repeate (100000) @ (posedge clk);
i2c_agent_h.set_report_verbosity_hier(....);
This way we can set the verbosity level when we want to avoid generating large log files and to make debug easy, This way there are hundreds of other feature which helps in debugging, please refer methodology reference manual for further details.
Keeping these things in mind if we design test bench, we will surely be saving our deugging time!
-ASIC With Ankit
<script src="//platform.linkedin.com/in.js" type="text/javascript"></script>
<script type="IN/Share" data-counter="right"></script>
Last edited by a moderator:
