27/12/12

RTL Verilog

RTL Verilog
Remember this?

Now w e are going to look at the principles of RTL coding for synthesis tools. Most commercially available synthesis tools expect to be given a design description in RTL form. RTL is an acronym for register transfer level . This implies that your Verilog code describes how data is transformed as it is passed from register to register. The transforming of the data is performed by the combinational logic that exists betw een the registers. Don't w orry! RTL code also applies to pure combinational logic - you don't have to use registers. To show you w hat w e mean by RTL code, let's consider a simple example. m o d u l eA O I( i n p u tA ,B ,C ,D ,o u t p u tF ) ; a s s i g nF=~ ( ( A&B )|( C&D ) ) ; e n d m o d u l e Yes! The AOI gate that w e have used as an example so far has actually been w ritten in RTL form. This means that continuous assignments are a valid w ay of describing designs for input to RTL synthesis tools. What other code techniques can w e use? How about: m o d u l eM U X 2( i n p u tS E L ,A ,B ,o u t p u tF ) ; i n p u tS E L ,A ,B ; o u t p u tF ; I N VG 1( S E L ,S E L B ) ; A O IG 2( S E L B ,A ,S E L ,B ,F B ) ; I N VG 3( . A ( F B ) ,. F ( F ) ) ; e n d m o d u l e Module instances are also examples of synthesizable RTL statements. How ever, one of the reasons to use synthesis technology is to be able to describe the design at a higher level of abstraction than using a collection of module instances or low -level binary operators in a continuous assignment. We w ould like to be able to describe what the design does and leave the consideration of how the design is implemented up to the synthesis tool. This is a first step (and a pretty big conceptual one) on the road to high-level design. We are going to use a feature of the Verilog language that allow s us to specify the functionality of a design (the what') that can be interpreted by a synthesis tool.

Always blocks
Alw ays blocks are akin to the initial blocks that you have met already in Test Benches. Initial blocks are procedural blocks that contain sequential statements. Initial blocks execute just once. Alw ays blocks on the other hand are always available for execution. This means that the statements inside an alw ays block are executed up until the closing e n dkeyw ord:
www.doulos.com/knowhow/verilog_designers_guide/rtl_verilog/ 1/4

27/12/12

RTL Verilog

a l w a y s b e g i n / /s t a t e m e n t s e n d But then they can be executed again! This means that a w ay of controlling execution through an alw ays block is required. In describing synthesizable designs, a sensitivity list is often used to control execution (w e shall see other approaches later). a l w a y s@ ( s e n s i t i v i t y l i s t ) b e g i n / /s t a t e m e n t s e n d The sensitivity list consists of one or more signals. When at least one of these signals changes, the alw ays block executes through to the end keyw ord as before. Except that now , the sensitivity list prevents the alw ays block from executing again until another change occurs on a signal in the sensitivity list. The statements inside the alw ays block describe the functionality of the design (or a part of it). Let's reconsider the AOI gate: a l w a y s@ ( s e n s i t i v i t y l i s t ) b e g i n F=~ ( ( a&b )|( c&d ) ) ; e n d Instead of a continuous assignment, w e now have a procedural assignment to describe the functionality of the AOI gate. Notice that the sensitivity list isn't valid Verilog code. We need to create a meaningful sensitivity list. How do w e decide w hen to execute the alw ays block? Perhaps a better question is w hat do w e need to do in order to have Fchange value. Answ er: Fcan only change w hen at least one of a ,b ,c or dchanges. After all, these are the four inputs to the AOI gate. That's our sensitivity list: a l w a y s@ ( ao rbo rco rd ) b e g i n F=~ ( ( a&b )|( c&d ) ) ; e n d Verilog-2001 introduced additional syntax for describing sensitivity lists. a l w a y s@ ( a ,b ,c ,d )

a l w a y s@ ( * )

a l w a y s@ * In the first of these, w e have simply replaced the w ord or w ith a comma. The other tw o are equivalent and create an implicit sensitivity list that contains all the signals w hose values are read in the statements of the alw ays block. In this example @* or @(*) are equivalent to @(a,b,c,d). When describing combinational logic, it is important to make sure that sensitivity lists are complete; this syntax helps to ensure that this is holds. Now for the MUX_2 design. In the above code snippet, w e simply replaced the continuous assignment w ith an equivalent alw ays block. We can do the same w ith the module instances in the MUX_2 design - strip aw ay each instance and replace it w ith the equivalent alw ays block. a l w a y s@ ( s e l ) b e g i n s e l b=~ s e l ; e n d a l w a y s@ ( ao rs e lo rbo rs e l b ) b e g i n f b=~ ( ( a&s e l )|( b&s e l b ) ) ; e n d a l w a y s@ ( f b ) b e g i n f=~ f b ; e n d
www.doulos.com/knowhow/verilog_designers_guide/rtl_verilog/ 2/4

27/12/12

RTL Verilog

But w e can do better than this. Let's merge the three alw ays blocks together remembering that in the process (a pun for the VHDL'ers amongst you!) the sensitivity list of the resulting one alw ays block contains only those signals that cause F to change value. a l w a y s@ ( s e lo rao rb ) b e g i n s e l b=~ s e l ; f b=~ ( ( a&s e l )|( b&s e l b ) ) ; f=~ f b ; e n d When w riting RTL code, think functionality, think inputs is a useful aide memoire in terms of bridging the gap betw een concept and code. Well, w e have already taken care of the inputs as the sensitivity list now consists of only the MUX_2 input ports. For the functionality, lets get conceptual. If sel is a logic 1, a is routed through to the f output. On the other hand if sel is a logic 0, b is routed through to the f output. Rather than think about routing one of the inputs through to the output let's think about the output getting one of the inputs, and let's w rite the text on separate lines depending upon w hether w e are making a decision or performing an action (sometimes referred to as pseudo-code): i fs e li sl o g i c1 fg e t sa o t h e r w i s e fg e t sb This can be translated into Verilog code: i f( s e l= =1 ) f=a ; e l s e f=b ; Now before w e go any further, w e'll just take this code snippet a line at a time. i f( s e l= =1 ) The Verilog language allow s for many different kinds of sequential statement. The procedural assignment is one you have already come across not only on this page but also in test benches (assignments to S E L , Aand Bin the stimulus initial block, if you remember). Here's another: the if statement. Actually this line is part of the if-else statement that is the entire code snippet. if is a Verilog keyw ord. After the if keyw ord you have a conditional expression, in this case ( s e l= =1 )- does sel have the value logic 1? If so... f=a ; fgets the value on the ainput. Or in Verilog jargon, a procedural assignment. But w hat if sel is not logic 1? e l s e Otherw ise (assume sel is logic 0 - more on this assumption later)... f=b ; fgets the value on the b input. So, as it turns out, w e have described the funcionality of the MUX_2 design using a single procedural statement, the if-else statement. In each branch of this if-else statement, there is an additional procedural statement, either assigning a to f, or b to f, depending upon the value of sel. But w e have to remember that this procedural statement lives inside an alw ays block, so... a l w a y s@ ( s e lo rao rb ) b e g i n i f( s e l= =1 ) f=a ; e l s e f=b ; e n d This now enables us to describe a design using a list of continuous assignments, a hierarchy of designs or an alw ays block. Compare the 3 approaches for yourself:
www.doulos.com/knowhow/verilog_designers_guide/rtl_verilog/ 3/4

27/12/12

RTL Verilog

/ /c o n t i n u o u sa s s i g n m e n t s a s s i g ns e l b=~ s e l ; a s s i g nf b=~ ( ( a&s e l )|( b&s e l b ) ) ; a s s i g nf=~ f b

/ /ah i e r a r c h yo fd e s i g n s I N VG 1( S E L ,S E L B ) ; A O IG 2( S E L B ,A ,S E L ,B ,F B ) ; I N VG 3( . A ( F B ) ,. F ( F ) ) ;

/ /a l w a y sb l o c k a l w a y s@ ( s e lo rao rb ) b e g i n i f( s e l= =1 ) f=a ; e l s e f=b ; e n d And of course you can mix'n'match coding styles if you w ish. On a simple design, such as a MUX_2 it is perhaps not apparent how succinct the use of alw ays blocks is in general compared to module instances and continuous assignments. But you can readily appreciate that the use of just one alw ays block in this design is enabling us to describe the design in terms of its functionality w ithout regard to the implementation. You can describe w hat you w ant w ithout having to w orry about how you are going to implement the design (because you don't have to - that's the synthesis tool's job!). Go on! Read the MUX_2 design into your synthesis tool and have a play. Prev Next Copyright 2005-2012 Doulos. All rights reserved.

4/4