What are some common HDL coding mistakes that can cause synthesis or verification errors in ASIC design?

The most common HDL mistake is not to run your code through linting tools. Many times you have bus width mismatch which can cause synthesis and simulation bugs. Another example would be floating inputs, which usually get tied to logic 0 during synthesis. Linting tools will detect many more potential problems with your code which will prevent synthesis and simulation bugs.

This is true for control signals but I would not do this for data path only flip-flops. Internal data busses inside an ASIC can be very wide, 1024 bits and larger in multiple hierarchies of the design. Resetting all of these bits results in a huge reset tree. If the control logic doesn't rely on a data FF, there is no harm having an unknown value until the data flow sets the FF to a known value.

Assertions in simulation increase the observability of the internal behavior, making debug more efficient. Assertions can be read by formal analysis tools, which use mathematical methods to either prove that each assertion can never be violated or find a counterexample showing how the assertion can fail. This allows an easy transition from assertions in simulation to more comprehensive verification. The same set of assertions can be reused in dynamic simulation and can provide functional coverage as well. The use of directed testing, static formal verification, constrained random TBs, assertions, code & functional coverage, power aware verification and performance validation enable fast and efficient execution towards a bug free design.

One aspect that I believe is crucial to highlight in the context of ASIC design is the potential for power bugs in RTL design. I've often seen cases where RTL coding appears functionally correct but leads to excessive power consumption during implementation. To avoid this, RTL designers can consider a few strategies: Clock Gating: Implement careful clock gating to reduce unnecessary toggling of registers, especially during idle states. Data Path Optimization: Analyze your data paths for redundant operations or unnecessary bit flips, and optimize them to reduce power-hungry transitions. Static Analysis Tools: Employ static analysis tools that can identify potential power issues early in the design process.

Although it’s not often discussed, I’ve seen many problems in design occur or be discovered at a later stage due to the following: 1. Lack of state diagrams in FSM Design: State diagrams are essential before implementing FSM designs to prevent hidden issues that can affect both synthesis and verification, some of which aren’t caught by linting tools. 2. Non-automated Register Map Management: Digital designs often include large register maps, which grow as the design progresses. Automating register updates minimizes human error, ensuring consistent and accurate implementations.

Sign extension for signed variables and specifying or casting a variable if it is signed properly. This will seemingly pass for simple testbenches which do not cover corner cases but can be fatal based on the computation. I recommend to always include a bench that tests max and min cases of the variables being used for the computation.

But width mismatches between the left and right side of assignments for buses. This may not easily be caught unless an extensive testbench that covers corner cases is written and sometimes not at all based on functionality. This should be checked during coding and lint must be run.