Verilog/RTL for Beginners: Stage 1

Hi friends, we all know how easier it is for anyone to ask you to deliver a SYNTHESIZABLE RTL based on any C/MATLAB etc. and you are stuck with a dilemma in guessing where to begin with. So in this post we will be laying down some fundamentals along with examples that may help you in getting it done right and easy. We have divided this tutorial into a set of stages each of which targets a specific aspect of RTL coding/design. These stages start from black box to detailed architecture level models as well extended but not limited to synthesizable RTL as well as gate level designs.

Our of the examples will include:

·         Basic digital designs: Adders, ALU, Comparators, Counters, Multipliers etc.

·         Memory Models      : ROMs, RAMs, 2-port memories, single port memories.

·         FSM Designs             : Mealy, Moore, One-hot.

·         Processor design     : RISC, CISC.

·         ASIC Cores                : FFT processors, DWT processors, FIRs Filters, Convolutors, Image/video codecs.

Stage 1 : Black Box and Block Diagrams

Before starting with examples and coding methods, let us first define the basic steps that you should take for implementing your code especially if you’re a novice.

1. Get the Black Box:     

Break the code as black box entity that takes something as an input and outputs something.

Example:

      Suppose you want to make a digital clock. Then it can simply be treated as a black box that simply outputs the time with some control (for adjusting time) and reference signal (a digital oscillator clock) as inputs. 

     2. Pen is Mightier than Code: 

The next step is to get the hang of the functionality that this black box is supposed to do. Take the function itself that the code is meant for and use it on a very simple test case but rather than using the code use a pen and paper solve it instead. This is the only way you will understand the code and identify your true problem statement

Example:

Consider the same clock problem as above. How will you write the same function as the clock on a paper? Simple:

·         Consider the current time as A (hours : minutes : seconds)

·         Write three variables HR=0 MIN= 0 and SEC= 0.

·         Now keep checking your reference watch/clock and after each second/tick (take 5 if you can’t write quick: P ) add 1 (or 5 if you followed the previous advice)  to SEC.

·         Now by doing so a point will come when after adding SEC = 60, at this instance add 1 to MIN and change SEC=0.

·         Do the same for HR when MIN=60.

·         For getting the output time simply add the reference time A to the calculated time HR:MIN:SEC ( be careful while adding time it’s not 0-100 but 0-60)

·         And there you go the clock is working on paper.

     3. Break the Black Box:  

                        

So far you should have got a hang on things regarding what and how the function is supposed to do things. The next step is to break this functionality into smaller and simpler groups and the best way to this is to take inspiration from your own rough work. Refer to the paper on which you solved the problem itself and identify each type of secondary function you had to do/use in order to write stuff on that paper. This helps you in creating solutions for multiple simpler problems instead of a complex one. But enough said, this is a statement we’ve all heard people say but what they ever tell us about is how to do it exactly. So here’s what you have to do.

Example:

The first thing that you will notice on the paper is the very first column titled tick. This column is simply used to track the number of ticks that have occurred after reference time A. In digital domain you can simply realize this by using a synchronous up-counter operating at 1Hz clock frequency (every 1second the counter increments by 1).

 So there you have the very first sub-block of your system i.e. an up-counter block A. Leave the counter specifications like size and reset limits for now, we shall discuss this at a later stage.

The next 3 columns show 3 internal variables that you use for keeping track of time count. In digital domain variables can simply be realized by using registers as they can be loaded as well as read. In addition, each of these variables is always incremented by 1 and resets to 0 when its value reaches 60 (except for HR which may be limited to 12/24).

Thus they can be modeled using three registered variables along with an adder (adds +1) which is the second sub-block inside the black box name block B.

The 5^th column A is simply a reference variable and it never changes, so you can simply use it as a direct input. The last variable is simply an added version of previous 4 columns and hence can be realized using simple adders as a block C. And this completes the breaking of the black box as follows:

     4. Link the Blocks: 

                       

After identifying the key sub-blocks of your concerned design/code/function the next step is to link the logical exchange of info amongst these blocks as well as the external world. To do so identify the dependency of each block and simply use arrows to denote those dependencies. This will help us in understanding the inputs and outputs of each of these sub-blocks and thus understand the actual flow of information.

Example:

Let us start with block A. It is an up-counter and an up-counter primarily depends on the reference clock that keeps on triggering it. Thus block A only has a dependency on external reference clock signal.

Block B has three registers which are either added one or reset to zero. The addition however is driven by certain conditions from both the counter values as well as register values themselves. Thus the dependency of adder unit inside block B is only the register outputs while the registers have three dependencies, first from the output of adders, the second from the up-counter and the third from the other register like HR is dependent on MIN, MIN is dependent on SEC and SEC is dependent on up-counter. 

Block C is rather a much simpler block that only adds the three registers of block B to input reference time. Thus it only has a dependency on input reference time and three block B registers. The important thing about this block though is that the output of this block is in fact the output result itself.

     5. The Missing Link:        

At this point you should have more or less identified all the major data processing requirements of your design. However, the key entity missing in these links is the control and synchronization block. This is the block that decides the what, when and how the data flows across all these connection links shown above so that the desired functionality is obtained.

The concept of a Finite state machine or FSM is one of the most commonly used techniques to model this control block. The key idea behind FSM is that at any moment each section the design will be doing some work. However, this work will always be of repetitive nature and sequence of work performed will also be of finite order like a counting sequence with limited upper value which goes like 1,2,3,…9,1,2,3,..8, 9, 1 & so on.

We will discuss the concept of FSM in more details later but for now let us assume that this FSM block is the main control unit that synchronizes each and every block of your design. The inputs to this block will be the output of each block and/or input that is required for determining the next sequence of action and the outputs are function enabling signals like a memory chip-select or reset signal. The FSM is also similar to a counter and hence this will also use a reference clock for its operation. 

And there you have it folks, from black box to top level block diagram for your RTL right from the scratch. 

Scripting in VLSI industry/a VLSI engineer’s life

Need of scripting in a VLSI engineer’s life

Programming in general, and scripting in particular, is deeply associated with a VLSI engineer’s life. Right from automating repetitive tasks to interfacing with design tools, a VLSI engineer needs scripting and programming to perform his job efficiently and effectively. Scripting forms a very important part of a VLSI engineer’s life.

As everybody knows, VLSI stands for Very Large Scale Integrated Circuits. VLSI involves integrated circuits involving millions of transistors. Handling such large numbers of transistors is beyond human intervention. Specialized EDA (Electronic Design Automation) tools exist for every stage of design right from concept to fabrication. These tools are equipped with special algorithms to deliver optimized results. Thus, programming lies in the heart of EDA (Electronic Design Automation) tools. However, the core of EDA tools is built on assembly and/or high level languages such as system C. Moreover, graphical user interface (GUI) of design tools is generally very memory intensive and demands user attention. However, these tasks are often pre-defined. As an example, for the physical design flow of chip design cycle, the steps involved are generally placement, clock-tree-synthesis, routing etc. Also, all these steps are categorized into a number of smaller sub-steps, often pre-defined. All these tasks, if performed through GUI, require a lot of user intervention and time. Also, the engineer has to perform repetitive actions. EDA tools also offer text based interface in addition to GUI interface, and each step/sub-step can also be performed by some commands and switches. The sequences of commands to be run can be scripted and run so as to save time and effort.

Also, the job of a VLSI engineer is not to carry out the design flow alone. Each new design is equipped with new set of challenges never encountered before. The debug requires a great deal of analysis skills and time. In addition, different settings for a command yield different results. So, there are a number of experiments to be performed with different settings as the same settings may yield better results for one design, but not for another. Surely, these different experiments cannot be performed manually by a single user. On the contrary, commands can be written in the form of a script and can be run on the same initial database yielding different final databases. The user can, then, devote his attention to the more important task of analyzing the results. Another advantage of scripting the tasks is that the tool does not have to get struck waiting for user input after it has completed its task. Rather, it can get the next command to be executed from the script itself resulting in faster execution.

Another reason why scripting is preferred is because human work is error prone.  A single error can destroy the whole effort. Scripting the task reduces the probability of error by a huge amount.

Other than interfacing with tool also, there are a lot of non-technical repetitive tasks that the user has to perform. These include day-to-day disk cleanup, monitoring the jobs, preparing summaries of results etc. As these tasks are of repetitive nature, these can also be automated and can save a lot of manual effort.

                                       

Difference between scripting and HDL

A very common confusion that many of us have is over the differentiation between various programming languages being used by electronic designers. On one side we have C, C++, PERL, Python and on the other we have VHDL, VERILOG and SPICE. In order to understand the use case and relevance of these languages, we must first understand why these are there in the first place.

• Programming Languages: Let us first consider basic coding languages like C and C++. These languages are the most basic means through which all general purpose computers and systems interact, mostly because of dependencies on the operating system. These languages basically provide us with data structures processing which compatible with the OS.  For VLSI designers, these  are useful mostly in developing software applications, or even design tool software itself. These languages are, thus, more like tools made for software designers instead and often have a very complex but powerful code for even simple applications. The limitations of these languages are only dependent on the type of hardware that is supported. All the other languages are in fact an abstraction of these languages themselves.

• Tool Languages: TCL, PERL and shell based various languages come under the banner of tool languages. These languages are generally termed as interpreters (translators). They work the code line by line making it easier to write and debug at the same time. These languages simply provide us with a common set of data processing codes in the form of one-liners or functions. The main reason why these languages became popular is that since all industrial EDA tools run on the open source linux/unix environment (much cheaper and less resource intensive than windows), the user found having tools and  utilities with similar command line interface as OS makes it much easier to handle. These languages were thus used primarily to process the command line user interface data as well provide user to process the text based tool results.

•  HDL Languages: HDL or hardware description language as the name suggests is a way of describing our design tools and the designers about the physical nature of our hardware. These languages provide a common platform for representing physical or logical blocks in a design. While SPICE level languages go down to the basics of textual representation of circuit schematics, higher abstract languages like Verilog describe the register and logical type hardware structures like the behavior and signal relation structure of a counter or memory.

In short, if we compare the making and designing of an industrial chip as making a Pizza, then:

• HDL is the recipe describing the physical and logical process of making,

• Tool language is the manual and user controls on the Oven, and

• The cook is the programming language synchronizing both the recipe and the tools

Figure 1 : Baking a chip!

Different scripting languages used

As is the case with programming languages, the scripting languages are also of two types; i.e., interpreted and compiled. The commonly used scripting languages used are TCSH, TCL and PERL.

• TCSH: TCSH is a language particularly compatible with unix operating systems. The unix based jobs can be automated with the help of TCSH interpreter

• TCL: TCL stands for Tool Command Language. Most of the EDA tools are TCL based. So, the tool related scripts can be written in TCL.

• PERL: PERL is a very powerful language and provides a lot of pre-built libraries for a range of tasks. Even XLS data parsing can be done using PERL. From simple useful scripts to powerful utilities can be created using PERL with not much of effort.

Thus, we have discussed how scripting languages have penetrated a VLSI engineer’s life. Without these, there will be chaos all around. It is due to scripting and scripting languages only that VLSI industry survives today. We cannot even imagine VLSI industry without scripting.

Recommended for reading

• Automated macro-model extraction using spice netlist
• This paper discusses the techiniques to automatically extract the design in formats like CPF, UPF etc so as to verfiy the correctness of the digital models assumed in the SoC implementatoin flow.

• Challenges in hierarchical timing closure using various timing models
• The challenges involved in using various timing models for timing closure and physical implementation are discussed in this paper.

• Modeling non-linearity in Timing analysis
• There are various non-linearities involved in the behaviour of digital circuits in SoC design. Efficient modeling of these non-linearities in a linear and calculation efficient model is discussed in this paper.
• Timing friendly clock gating/divider cell for waveform shaping
• Design of a multi-functional cell for using any of the 50 % divided/gated/bypassed/puch-through clock is discussed in this paper.

• Enhanced timing closure using latches 
• This paper discusses how we can utilize timing properties of latches to achieve timing closure in an efficient way. It also discusses the pre-requisites for using latches in a timing path.

• Physical aware timing ECOs - Challenges and Solutions
• The importance of being location aware while finding timing ECOs is discussed in this paper and guides the timing engineer about the same.

• I/O interfaces - An STA perspective
• The SoC interactions have been discussed with an angle of timing in this paper.

• Post-CTS clock path timing and automation in physical design flow
• This paper discusses, from various angles, various innovative techniques of automation that can be employed in physical design flow.

• Pre-CTS clock path timing and automation in physical design flow
• This paper discusses various innovative techniques of automation and scripting techniques that can be employed in physical design flow.

• Modelling skew requirements for interfacing signals in an SoC
• There are various protocols involved in modern day SoCs that enable communication accross SoCs. The modeling of timing requirements of these protocol signals is discussed in this paper.

• Timing challenges for SoC integration of ADC
• This paper discusses various timing and other backend challenges involved while integrating ADC or any other analog/hard macro into SoC.

• Using multi-bit flops to achieve better SoC design efficiency
• Usage of custom cells (other than basic logic gates) such as multi-bit flops to achieve optimum design efficiency is the prime focus of this paper.

• Low power, high density clock gate
• This paper discusses an approach to a power and area efficient design through a low power clock gating scheme for clock power improvement that reduces power dissipation by deactivating the clock signal to an inactive value (for clock gating cell) when clock is supposed to be gated (for Soc).