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

EDA Tool Developer Series: What The Flop? … Part 2

Posted by: Trent McClements | Posted on: April 6th, 2015 | 3 Comments

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

Following on from our introductory discussion about flop detection in EDA tools, we’ll look at the patterns that define a flip-flop, starting with a look at sensitivity lists. As we discussed in the last post, these patterns are not part of the VHDL, Verilog or SystemVerilog LRMs. They are conventional standards that the industry has evolved towards over time. To be an effective EDA developer, IC designer or verification engineer, it is important to understand how and why…

From the ten-thousand foot view of things, one can consider synthesis as a static analysis problem. The synthesizer must infer the behavior of your design without simulating it! So the problem is that of using specific coding constructs to enable inference of dynamic behaviour. Of course, for the arbitrary case, this is no simple problem and thus convention has evolved in the industry to enable reasonable solutions. Straying too far from the beaten path often, but not always (depending on tool vendor implementation), leads to trouble!

Implied in the statement that sensitivity lists are a starting point for flop inference is the fact that processes, or always blocks in SystemVerilog, are required for describing a flip-flop. This is pretty obvious — clearly, continuous assignments (SystemVerilog “assign” statements) don’t make for good sequential logic descriptions! Following from that, most people in the industry would agree that a process’ sensitivity list (and the ‘posedge’ or ‘negedge’ keywords) are good flop indicators. What many people don’t realize, and we discussed in this blog post on sensitivity lists, is that in SystemVerilog the “always” block doesn’t have sensitivity lists. Rather, as per the SystemVerilog LRM, sensitivity lists are associated to statements. As such, there arise three conditions regarding sensitivity lists and assignment statements within always processes that are requirements for flop inference.

The first condition is that all assignments only have one associated sensitivity list. My guess is that most designers don’t even realize that you can associated multiple sensitivity lists to a single assignment as it seems quite unnatural from a design perspective. Regardless, it is perfectly legal in the SystemVerilog LRM to do the following:

always @(posedge clk) begin
@(posedge clk) begin
q <= 1'b0;
q <= d;

What the above code has done is associate multiple sensitivity lists to the “q <= 1′b0;” assignment (OK, technically there are sequential timing requirements on this assignment but you can abstract it to a multiple sensitivity list association concept). Clearly, this code would create a strange logical structure that shouldn’t map to a flip-flop. However, it is interesting to note that a SystemVerilog parser will not flag this construct as illegal (though a synthesis tool will likely do so).

The second condition regarding sensitivity lists is that all assignments in a process must have the same sensitivity list. Again, this may seem an obvious restriction once made apparent, and many designers may not even realize that such a construct is even possible, or if so would never consider coding in this fashion. However, for completeness let’s examine what such a construct would look like.

always begin
@(posedge clk) q <= d;
@(negedge clkb) qb <= d;

In the above code you can see that the statements assigning to the signals q and qb have different sensitivity lists. Within the always block this is perfectly legal but can give rise to ambiguity when it comes to synthesis. Is the intent that qb be sensitive to both clk and clkb? Maybe, but it’s generally not clear so convention dictates that this will not synthesize to flip-flops.

Another example of this requirement is the following code:

always begin
@(posedge clk) q <= d;
#3 qb <= d;

The delay on the qb signal assignment creates a different sensitivity list for this assignment. qb inherits the sensitivity list of q but adds a delay, thus creating a different association for itself. Some synthesis tools might ignore the delay and some may not. There is no clear industry convention in this regard.

The third condition surrounding sensitivity lists is in regards to the level versus edge sensitivity. For flip-flop inference all events within a sensitivity list must be edge sensitive. So, for instance, you couldn’t expect the following to synthesize to a flop:

always @(posedge clk or rstb)
if (~rstb) q <= 1'b0;
else q <= d;

That pretty much covers the requirements surrounding sensitivity lists and flip-flop inference. In the coming weeks we’ll look at other conditions that convention has dictated define a flop and then we’ll do a survey of some EDA tools to see how well the do or don’t filter on these conventions. Are FPGA tools more flexible in what they accept versus an ASIC tool? What about RAMs and latches? How are they different? Subscribe to our blog or check back in the coming weeks to find out!


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

Comments (3)

  1. Cliff Cummings - Reply
    April 8, 2015

    It should be noted that all four examples in this blog are exceptionally poor coding styles. I called Invionics to discuss this and they agree that all four styles shown here should be discouraged. It sounds like a future blog will demonstrate proper coding styles and that this blog served as a warning to tool developers that you may see poor coding styles of this nature that need to be handled by the tools.

    Regards – Cliff Cummings

    • Trent McClements - Reply
      April 8, 2015

      Hi Cliff,

      It’s true, these code examples/styles are not to be encouraged for synthesizable RTL and that certainly wasn’t the intention of the blog post! If you are an ASIC or FPGA designer then you should not use these methods when trying to infer flipflops. However, as an EDA developer you have to be prepared to see structures such as these as input RTL to your tool or flow. Usually, these code structures are not done intentionally but rather are the result of a typo or a simple bug. Your tool has to recognize these structures for what they are and are not!

  2. Selena - Reply
    September 12, 2015

    Yes, I’d say that’s very reasonable. Good work for a 0.3 resaele. Although, I’m a verif guy, not a designer. I’m not sure all the designers on my team would take the time to pick something like this up on their own, but I’ll bet I could guide them through it initially and they would run with it.One thing that would help would be to have the basic steps that I got from the first video (when to run which perl script, when to run make, which file to create so that make will run my simulator, etc.) would have been more accessible if they were written down. I had to do a lot of pause and rewind on the video.Also, maybe for a future resaele, basic tar-file courtesy is to have it so when I untar the tar file, it creates one and only one directory, with everything else inside of that.Otherwise, good work at hiding a lot of complexity from me. Once I had generated the files it was pretty easy to create the interface, wire it up, and insert some test code in the correct place in the * file

Leave a Comment