Blog

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

SystemVerilog Insights: Do always_latch and always_ff provide any real value?

Posted by: Trent McClements | Posted on: February 11th, 2015 | 5 Comments

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

On the surface they seem like fantastic extensions to the language, enabling designers to more explicitly state their design and guide verification and synthesis in a meaningful way. Gone are the days of inferring intent! We can now state and create what we want. But digging into the LRM, we can see that always_latch and always_ff may not provide the value you were expecting…

As a follow-on to our previous post on always_comb, it makes sense to start with the SystemVerilog always_latch process. And, as it turns out, the always_latch process is, in my opinion, one of the great disappointments of the SystemVerilog LRM. Similar to how always_comb does not prevent latches from being created, always_latch does not require a latch be created! In fact, the SystemVerilog LRM says that always_comb and always_latch are exactly the same except that the SystemVerilog parser should warn when always_latch does not represent latched logic and always_comb should warn when combinational logic is not represented (i.e. when a latch is inferred). Note the “should” and “warn” — nothing prevents your SystemVerilog parser from merrily compiling away without a whisper when your always_latch procedure creates simple combination logic. With such a weak specification, one really has to wonder why always_comb and always_latch were even added to the language.

Now lets look at always_ff. Unfortunately, and in keeping with the always_comb and always_latch disappointments, the SystemVerilog LRM states that SystemVerilog parsers, or any other EDA software, should only warn if an always_ff procedure does not infer sequential logic. Again a bit disappointing if the designer put the effort into using the always_ff syntax, that there is not stronger enforcement of design intent.

The SystemVerilog LRM does restrict some behavior in the always_ff. Similar to always_comb and always_latch, always_ff processes cannot have blocking timing controls. For example, the following bit of RTL is illegal because of the timing control:

always_ff @(posedge clk or posedge rst)
#10 ff_out <= rst ? 1'b0 : ff_in;

always_ff also present restrictions on the number of event controls allowed. Interestingly, in relation of our previous post on sensitivity lists, each always_ff process must have one and only one event control statement. So, one cannot do the following in an always_ff process:

always_ff @(posedge clk or posedge rst) begin
ff_out <= rst ? 1'b0 : ff_in;
@ (posedge ff_in) ff_trig <= rst ? 1'b0 : 1'b1;
end

Further, and again similar to always_comb and always_latch, any signal on the left-hand side of an assignment within an always_ff procedure cannot be assigned to in any other process. This includes variables within called functions. Certainly a reasonable restriction.

Wearing my RTL designer’s hat, I have to say that these minor restrictions coupled with the weak language around flag inference errors don’t live up to my expectations. When I first heard about these new language constructs I had high hopes but now I can’t see them changing the way I code. In fact, I doubt I will ever use them other than as a fancy way to inline comment my intent.

Do you use always_comb, always_latch or always_ff? Have I missed something that they bring to the table for hardware designers and verifiers? I’d love to hear about it in the comments below!

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

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

Comments (5)


  1. Marty Deneroff - Reply
    February 12, 2015

    As far as I’m concerned, the warning is fine and meets the need, although I agree an error would be preferable. The main gain is that you can state your intent and be notified that the code you wrote doesn’t perform that intent. Whether it is a warning or an error is not a big deal.

    • Trent McClements - Reply
      February 12, 2015

      Hi Marty,

      I agree that a warning is a good thing and that an error is be better. It’s interesting though, that the SystemVerilog LRM does not require a warning but just suggests that the parser present one. When I first heard about always_latch and always_ff I figured the construct would be much more stringent than that! Anyway, it seems a bit like a missed opportunity in the language to me.

  2. Guilherme Coraucci - Reply
    February 20, 2015

    Yeah, I agree with Trent. This is kind of a disappointment. Honestly, I always thought that such warnings by the compiler would be a must, and not a mere suggestion. I have read the LRM many times now but I really did not pay attention on the words “should” and “warn”. As my eyes were reading it as “should”, my mind was taking that as a “must”. Funny thing.

    • Trent McClements - Reply
      February 20, 2015

      Hi Guilherme,

      Thanks for your comment. It is tough to write specifications, especially one as extensive as the SystemVerilog spec, I think for that very reason — peoples eyes often read one thing and their brain interprets it to be another! Thankfully, as was mentioned in Marty’s comment, all tools seem to recognize the importance of the warnings and display them to us designers. Still, there is always room for improvement and I think with HDL languages a bit over-constrained is often more helpful than a bit under-constrained!

  3. Pingback: EDA Tool Developers Series - What The Flop? ... Part 1 - Invionics

Leave a Comment