State machines – a practical perspective

Hi friends, until now, we have learned how to write the RTL. We have also learned that RTL is the building block of digital system design. A well-written verilog code represents the complete system. We can also say that the verilog code represents the state machine of the system. But what is a state machine? As per the definition, a state machine consists of a set of states, a start state, an input and a transfer function that maps inputs and current state to next state. State machine designing is the heart of digital system design. All digital systems are state machines. We have learned how to write the RTL with the example of a clock as a system. In this post, we will discuss the state machines from a different perspective and try to build out understanding by representing our own clock as a state machine.

As we just discussed, each digital system is a state machine. It has an initial state, gets some inputs, moves to other states and provides some outputs. For example, consider a processor. Initially, it is in reset state. When reset is asserted, it comes out of reset state into stop/run state as described by a set of inputs defining mode of operation. It also fetches instructions from cache/RAM. This state can be termed as instruction fetching state. It goes into interrupted state upon receiving a request from a peripheral. In all these states, the processor also produces some outputs representing its states.

What corresponds a state in a digital design?  Each design is composed of a set of registers whose value is updated on every clock edge. Each edge corresponds to a state. The inputs/outpus and logic gates between registers ensure that the design state is updated every time a clock edge is encountered. All the registers have setup and hold checks that have to be met in order to ensure that the data is transferred appropriately between registers and right data is captured at every clock edge. Figure 1 below shows the state map for a design consisting of all positive edge-triggered registers. As is obvious, all the registers values are updated at each positive clock edge, hence, we say that the state machine updated its state at each positive clock edge.  In other words, we can say that at each clock edge, the state machine makes decisions based upon its inputs and present state and moves to next state.

Figure 1: Each clock edge corresponds to a state.

Digital clock as a state machine: We just discussed a simple example of a processor as a state machine. Now, let us discuss our own clock as a state machine. Repeating here the definition of a state machine, a state machine consists of a set of states, a start state, an input and a transfer function that maps inputs and current state to next state. Figure 1 below shows the block diagram of our digital clock. As is shown, it consists of

i)                    An up counter

ii)                   Different sets of registers (hour registers, minute registers and seconds registers)

iii)                 A group of adders and

iv)                 A control FSM.

Let us explore different aspects of our digital clock state machine.

State: A particular configuration of the different registers and control FSM represents a state of our state machine. The different states may be:

i)                    RESET state

ii)                   RUNNING state

iii)                 STOP state

Start State: The start state of our machine is either 00:00:00 (when the clock goes into RESET state) or REF_TIME (when REF_TIME input is provided).

Inputs: The inputs to our digital clock state machine are:

i)                    RESET and other control signals

ii)                   REF_TIME

Transfer function: The transfer function here is the condition that updates the state of our state machine. In other words, if RESET is asserted, output goes to zero, otherwise it increments by 1 second.

Outputs: The output here is the time that is displayed on the screen of the digital clock.

Figure 2: Digital clock block digram

Now, let us proceed towards getting the state diagram for our digital clock state machine, which is as shown below in figure 2. We can consider it as a state machine consisting of three states.

1. RESET state: When RESET input is asserted, the time goes to 00:00:00. As long as RESET input remains asserted, the state machine remains into RESET state.
2. RUN state: This is the normal state of our digital clock state machine. The output is the current time; i.e. current state of registers.
3. REF_IN state: When REF_IN input changes, the clock state machine output changes and becomes equal to REF_IN input applied. And the very next cycle, it returns to RUN state.

Figure 3: State machine corresponding to digital clock

Thus, in this post, we have discussed about how a state machine should be looked upon from a practical perspective and illustrated the same by considering a digital clock as a state machine. Stay tuned and learn with fun.

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).