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.