RTL DEBUG
RTL debugging is nothing but finding the bugs in the RTL design and fix it.The
bugs might arise because of multiple reasons like incorrect syntax which gives
rise to syntax errors and most of the time the compiler is smart enough to
notify about these errors.
Other set of errors are functional and logical errors which might arise because
of:-
Inference of latches in the RTL design because of incomplete case/if..else
statement which gives rise to race condition which in turn gives rise to
erroneous results.
Not proper usage of Verilog full case and parallel case and not using if else
and case statement properly because if else generates priority encoder while
case infers mux.
Address and Data mismatch and it is not generating as per the spec(may get
solved using walking zero and ones pattern)
Incomplete sensitivity list which gives rise to synthesis and simulation
mismatch.
Instantiation or stitching up of the signals at the intermediate blocks or top
level.
Floating or unconnected signals(can get caught up during lint).
Problems in reset strategy and clock not getting generated.
Problems in state transitions.
Proper logic is not implemented in any particular block of design.So the above
mentioned points are some of the scenarios but ideally not a complete
list.There might be uncountable number of bugs which might exist and are not
mentioned above but the main question is how to catch those bugs.
One method is just by writing some sanity test cases,log report and waveform
level debug.
But to catch most of the errors you first must need to create a Test Plan,write
some directed and random test cases and also some corner case
scenarios,generate code coverage and functional coverage reports and also to
write assertions.
The main intention behind this is that the intended input should match the
expected output.
Debugging is an art and takes years of experience where there will be always
scope to improve. This is true whether you are debugging RTL or some
Verification code or other software.
The techniques also vary based on whether you are debugging a failure on a full
chip RTL model or a smaller block level RTL model.
The first step when you see a failure is to isolate the failure to a smaller
unit or a logical block. This especially important if the failure is on a
large/higher level RTL model. This can involve simplification of failing test
or reduction of test scenarios. You can also use monitor/logging to track what
kind of events happen during simulation and where things go wrong.
Once you isolate failure to a smaller logical block, then use a waveform
debugger to analyze wave forms/signals and their behavior as per the RTL logic.
Most of modern waveform debuggers provides several features like tracking the
logical cone or source code tracking which makes it easier to track down to the
line of code which is buggy.
At every stage of RTL development and RTL verification, debugging speed of the
engineers determines the success of RTL tape-out on time.
Popular debugging strategies are as follows:
Debug from log files - Verbosity of log is the key.
Debug from wave form dump - Signal level back tracing is the central aspect.
Debug from validation - Mostly used for system level issues which are difficult
to create or run in simulation.
Most engineers start with Debug from log and try to get as many clues as
possible before going for Waves Debug. Back trace the issue from the top module
till the lower level module by making use of various flags/registers/control
signal’s status.But there are some experts in every product line, be it IP or
VIP, who Debug the issue by their expertise in use-cases and deep exposure to
the product. Their help is must when some one is clueless about the issue even
after examining logs and waves.And it’s always recommended to keep record of
extremely difficult debug issues for future projects.
