Clock Domain Crossing Design – 3 Part Series

Thank you for all your interest in my last post on Dual-Clock Asynchronous FIFO in SystemVerilog! I decided to continue the theme of clock domain crossing (CDC) design techniques, and look at several other methods for passing control signals and data between asynchronous clock domains. This is perfect timing because I’m just about to create … Read more

Dual-Clock Asynchronous FIFO in SystemVerilog

Apology for the lack of updates, but I have been on a rather long vacation to Asia and am slowly getting back into the rhythm of work and blogging. One of my first tasks after returning to work was to check over the RTL of an asynchronous FIFO in Verilog. What better way to relearn … Read more

One-hot State Machine in SystemVerilog – Reverse Case Statement

Finite state machine (FSM) is one of the first topics taught in any digital design course, yet coding one is not as easy as first meets the eye. There are Moore and Mealy state machines, encoded and one-hot state encoding, one or two or three always block coding styles. Recently I was reviewing a coworker’s … Read more

SystemVerilog always_comb, always_ff. New and Improved.

Verilog engineers will be familiar with using Verilog always to code recurring procedures like sequential logic (if not, refer to my article Verilog Always Block for RTL Modeling), and most will have used always @(*) to code combinational logic. SystemVerilog defines four forms of always procedures: always, always_comb, always_ff, always_latch. What do the three new … Read more

SystemVerilog Unique And Priority – How Do I Use Them?

Improperly coded Verilog case statements can frequently cause unintended synthesis optimizations or unintended latches. These problems, if not caught in pre-silicon simulations or gate level simulations, can easily lead to a non-functional chip. The new SystemVerilog unique and priority keywords are designed to address these coding traps. In this article, we will take a closer … Read more

Verilog twins: case, casez, casex. Which Should I Use?

The Verilog case statement is a convenient structure to code various logic like decoders, encoders, onehot state machines. Verilog defines three versions of the case statement: case, casez, casex. Not only is it easy to confuse them, but there are subtleties between them that can trip up even experienced coders. In this article I will … Read more

SystemVerilog and Verilog X Optimism – Hardware-like X Propagation with Xprop

In part 2 of this series, SystemVerilog and Verilog X Optimism – What About X Pessimism?, I discussed several coding styles that help to reduce the risk of missing design bugs due to Verilog X optimism. In part 3, we will take a look at how proprietary simulator features help avoid the problem by smartly … Read more

SystemVerilog and Verilog X Optimism – What About X Pessimism?

In my previous post about SystemVerilog and Verilog X Optimism – You May Not Be Simulating What You Think, I discussed what is Verilog X optimism, and some coding styles that are prone to Verilog X optimism bugs. So how do you avoid potential bugs that Verilog X optimism can introduce? One technique that has … Read more

SystemVerilog and Verilog X Optimism – You May Not Be Simulating What You Think

Verilog and SystemVerilog define 4 different logic values for modeling hardware: 1, 0, X, and Z. 1 and 0 are obviously real logic levels that can exist in silicon. Z and X, however, are modeling abstractions: Z represents a high-impedance (an un-driven or tri-stated signal) state, while X represents an unknown or indeterminate logic value. X’s … Read more