Blog

Thoughts on IC development, EDA, and hardware design languages.

EDA Tool Developer Series: Identifying Asynchronous Resets in Verilog and SystemVerilog

Posted by: Brad Quinton | Posted on: November 25th, 2014 | 4 Comments

Share on LinkedIn30Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

Welcome to Invionics’ EDA Tool Developer Series. In this series we will discuss ideas, challenges and implementation details around building your own EDA tools. Today we will start with the problem of identifying asynchronous resets in Verilog and SystemVerilog RTL.

The ability to correctly identify asynchronous resets is critical for a number of reasons, but one of the most important is for correct discovery of clock domains. Clock domain identification is at the core of many custom EDA tools, from partitioning to linting and re-timing. We will cover much of these applications in future posts, but for now let’s focus on asynchronous resets. The fundamental challenge of identifying an asynchronous reset at the RTL level is that of distinguishing them from the clock. Consider the following Verilog code:

always@(posedge clk or negedge rstb)
if (~rstb)
q <= 0;
else
q <= d;

Because ‘rstb’ is an asynchrous reset it appears in the sensitivity list of the process along with ‘clk’, so simply parsing the process and grabbing the signals that appear in the sensitivity list is not sufficient. How do we know know which is the clock and which is the reset?

The temptation, of course, is to try to use some kind of heuristic around the naming conventions… writing that clever Perl regular expression that will find variants of ‘clk’, ‘clock’ and ‘ck’, and distinguish them from variants of ‘rst’, ‘rstb’, ‘reset’, ‘rst_n’, etc. But, of course, as anyone who has deployed widely used EDA tools will tell you, that never works. There will always be at least one clever designer that uses a naming convention like ‘clka_rstb’, resulting in a never-ending regular expression augmentation battle!

The real answer is to use a full fledged Verilog or SystemVerilog parser, like the Invio Platform, identify the statements that are a part of the process body, and then analyze the inputs to these statements. From this you can use the far more robust heuristic that states if a signal appears in the sensitivity list and as an input to a statement in the process body, it is an asynchronous reset:

always@(posedge clk or negedge rstb)
if (rstb)
q <= 0;
else
q <= d;

Here is how this would look using Invio’s Python API:

statement_inputs = all_inputs(get_statements(process))
for signal in get_signals(process.sensitivity_list):
if signal in statement_inputs:
print "Async Reset Found: {0}".format(signal.full_name)

Of course, it is possible to go further and create an even more robust heuristic, by, for example, identifying that the asynchronous reset signal appears in the conditional expression of a conditional statement. This is certainly not difficult with Invio, but we will dive into that to another day.

To see this asynchronous reset identification process in a large flip-flop discovery context, please check out our Invio tutorial 5 Minutes To Flop Detection.

As always, we look forward to hearing your comments and questions on this or post or on building EDA tools in general. Please leave a comment below, and be sure to follow us on Linkedin to keep up to date on all of our posts.

4-Ways-to-Build-Best-in-Class

Share on LinkedIn30Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

Comments (4)


  1. Naveen Kumar - Reply
    November 26, 2014

    Hi Brad,

    This post is very useful when someone want to know how tools will do code parsing/identification.

    Hoping to see more such post.

    • Brad Quinton - Reply
      November 26, 2014

      Thanks Naveen. We really appreciate the feedback. We expect to post a new entry in the “EDA Tool Developer Series” about every two weeks… alternating with our SystemVerilog posts. To keep track, please follow us on Linkedin.

  2. Naveen Kumar - Reply
    November 26, 2014

    Hi Brad,
    I have gone through “5-minutes to flop detection” page thoroughly now. I see a problem with “Step Two” mentioned there.

    It is written as:
    “By definition in Invio, the outputs are signals on the right-hand side of the assignment statements within the processes ”

    I think it should be “left-hand side”.

    • Brad Quinton - Reply
      November 26, 2014

      You are right Naveen. Great catch! I have now corrected the the tutorial. You will see new text in italics.

      Thanks!

Leave a Comment