a mARTIAN dIARY

I was finally able to update A Sneak Peek Into The Wonderful World Of Voltage Regulator with all the images that were so conspicuously absent from it.

The popularity of this post ( most hits than any other post I think) can probably be put down to abundance of technical terms like 317 and 78XX in the article which are Googl’ed everyday.

The post was originally taken from my old website and I had lost all my images during that transition. Recently I was able to recover these images from my old hard-drive and do justice to the post

This is the season that people are scrambling for Main projects for their B-Tech and I had written some posts about how to go about selecting your final year project (So you want to do a VLSI Project Part I, Part II and Part III) I have got tremendous response for those posts but, I have found that lots of people are finding it hard to make the transition from a computer programming language background to coding using HDL(when I say HDL I am talking about Verilog and VHDL since these are the HDL’s I know about, so some of my generalizations may not hold good for other HDL’s and thus any such mistakes are due to my ignorance and any comments are welcome. But the point is that this post is aimed at college level projects and for them HDL should have the same meaning as I do). So here are some tips to do that.

As you would find in most text books ( For Verilog I would recommend Samir Palnitkar’s Verilog HDL- A Guide To Digital Design and synthesis ), the different level of abstractions are behavioral, data-flow gate level and switch level. Enough has be written about them and I would recommend reading about them (LINK) Generally most code you write would be a combination of behavioral and data-flow styles of coding. What an abstraction provides is a different way to describe the hardware, which will be useful depending on the context.

It is very important to understand the philosophy/History behind HDL’s to use them. This is that there are two major motivations behind most HDL’s the two motivations are -:
1. To describe Hardware
2. To describe Hardware stimulus

This is a very simplistic view, but one I feel, that should be adopted initially. The basic problem with this is that, most people think only about the 1st motivation and assume that the synthesizer is some magic wand which will be able to construct hardware for any code we write. While this might be true in the future since we are moving more and more to algorithmic/behavioral level description of the hardware with higher level synthesis tools, with current Verilog and VHDL its not the case. Hence there is part of the language that is non-synthesizable What this means is that the some code that you write may not be automatically converted into equivalent hardware by the synthesizer. There are two reasons this

You are using the so called non synthesizable constructs in the language. To give a simple example, to model external stimulus or to model real behavior we can use “wait” command which is a delay command. But if we try to synthesize it, it will either give a error or a warning. It will give an error for a stimulus block since stimulus is a sequence of signals and their timing information and hence do not have any hardware equivalent and if we are using the wait to model delays within a module, the module will the synthesized and the delays ignored.

To understand this better lets see an example. Assume that you are writing a code that interfaces with an external EEPROM. Now once you write the code of your module you need to prove that it will work once we burn it on to a FPGA. To do this we move on to a phase known as “simulation” where the description we made of the hardware is used to model the behavior of our device. Now this will result in a Zero-Delay or Ideal simulation as all the constructs we use will happen instantaneously (but they will still be controlled by a generated clock and a sense of time will be there but the output of ,say, a inferred AND gate will be propagated instantaneously without accounting for the actual propagation delay in hardware) in the simulation where as when hardware works in FPGA, the delays will be present. Also since you need to interface to the EEPROM, you need to have a “Model” of the EEPROM to test your design against. This HDL model, which will be provided by the EEPROM vendor, will not contain the functional definition of the EEPROM but will be a behavioral model specified using actual observed delays (it can be best-case, worst-case or average delays depending on the model) so that it can be simulated. So here in this example, the module/block you write will be (should be) synthesizable where as the EEPROM will be a non-synthesisable model just for simulation. Also there will be a “test-bench” which will ensure that the correct connections between the modules are done and also any other external stimulus the two blocks requires are provided, for example your module might be controlled by a micro controller whose signals will be simulated by a micro-controller model within your test bench which will be a striped down model to give the control signals for your module. I hope this example makes the use of both styles of coding clear.

You are writing code that does not make sense from a hardware point of view. One common error is a doubly clocked flop or signals with multiple drivers.For example if you write code like

always @ (posedge clk or negedge clk)

it will throw an error while synthesizing. Why? From a C view this is fine since you are asking the always block to be activated at either of two events. But think of it from the hardware perspective
Consider the following code

always @ (posedge clk or negedge rst)
begin
if ( rst==0)
D<=1′=b0;
else
D <= Q ;
end

seeing this code a hardware engineer should see a simple D flip flop and not an if statement. Taking this analogy back to the earlier code you will see that you are asking the synthesizer to infer a doubly clocked flop which is not possible in hardware.

Another important problem that confronts a new HDL coder is called the “Synthesis-Simulation mismatch”. What this essentially means is that unless certain rules are maintained, the simulator will interpret and model what you write in a different way than what the actual generated hardware will behave like. This can lead to two cases, one in which the Simulation will work and actual hardware wont and vice versa. Both are dangerous since in the fist case your hardware wont work and in the second case you wont go to the hardware level as your simulation fails. This is generally due to small issues like leaving out signals from the sensitivity list etc. Instead of re inventing the wheel, I would suggest you read the paper [1] for a better understanding of this phenomenon

It is always encouraged that you have a very good understanding of how the simulator and synthesis process works to help eliminate errors. While should be the aim in the long run, adherence to some basic rules would help weed out most issues.

1. Always think about get an image of the hardware that you want to produce in your mind and then code it. Though it might seem really hard to do this the idea is not to think of all the hardware at once but to split the design into blocks of combinational logic followed by flops (Sequential design lends itself to this)

2. Always try to separate the combinational block and sequential blocks into different always/process blocks. This helps in debugging errors later and also simplifies coding

3. When modeling sequential logic, use non-blocking assignments. For reasons for 3-10 see [2]

4. When modeling latches, use non-blocking assignments.

5. When modeling combinational logic with an always block, use blocking assignments

6. When modeling both sequential and combinational logic within the same always block, use non-blocking assignments.

7. Do not mix blocking and non-blocking assignments in the same always block.

8. Do not make assignments to the same variable from more than one always block.

9. Use $strobe to display values that have been assigned using non-blocking assignments

10. Do not make assignments using #0 delays.

11. If you are having to use #1 delays read this Verilog Non-blocking Assignments With Delays, Myths & Mysteries

12. Use asynchronous resets wherever possible ( Being a DFT engineer I should not say this as it complicates DFT ). Read [3] To understand more.

13. If you are using state machines in your design read State Machine Coding Styles for Synthesis.

14. Try to avoid Dangling wires Due to misspelling (very common!) or unused signals, there might be dangling wires in the design. The synthesis tool might optimize these wires away.

15. Specify all conditions explicitly for ‘case’ Statement or “if else” Statements – To avoid problems with inferred latches

16. Understand the differences between ‘case’ vs. ‘if – else’ Statements – In general, case statements would translate to parallel muxes in hardware. Meanwhile, the use of if – else statements results in priority-based hardware, which can slow down the overall implementation of the design. Thus, only use if – else statement when priority-based hardware is required. Otherwise, use case statements to avoid possible inefficient implementation of the design.

17. When using an always statement to implement combinational logic, the sensitivity list has to include all signals that appear on the right hand side of the assignments inside the. This is to avoid synthesis simulation mismatches.

     

Finally but a very important time saver can be to try and get hold of a good Linting tool so that a lot of these errors and others are caught before going to the FPGA stage.

I hope that this was helpful and more comments/tips/questions are welcome.

References
[1] RTL Coding Styles That Yield Simulation and Synthesis Mismatches (SunBust Design)
[2] Non-blocking Assignments in Verilog Synthesis, Coding Styles That Kill!(SunBurst Design)
[3] Synchronous Resets? Asynchronous Resets?I am so confused!How will I ever know which to use?(SunBurst Design)

Was thinking of putting up all the links that I use together at a common place so that it would be useful to others too. It lives out of the blog chronology so that I can keep on updating…

Do let me know if you guys think other links should be added.

It can be found @ eEDA Engineer’s Survival Kit

Continuing from part I and part II

VLSI (FPGA) Project Topic Selection / List 

Like I promised earlier I am putting up some of the FPGA related projects which I feel can be taken up at college level.

I shall split them into 3 different types depending on infrastructure that’s required. Why I am doing this is because most of these projects would lend themselves to be coded pretty easily (comparatively) but it’s the infrastructure that required to get them working and SHOW that they are working on hardware that might become the stumbling block.

Simple Arithmetic

• Parity prediction in adders
• Protocol converters (eg:Manchester to UART)
• Multiplier
• 4 bit Processors
• CRC Generator
• Reed-Solomon Decoder

Since they are all Simple arithmetic  blocks , once coded they can be easily demonstrated in hardware using input switches and output LED’s that are present in most FPGA kits. Also the thing that should be kept in mind to keep their scale low (like a 4 bit word length for a processor rather than 8 bit) so that proving them on hardware is possible. If the scale increases it would be a bit hard to prove them on hardware since the pins of the FPGA are limited .You might have to think of innovative interfacing solutions like parallel to serial conversion inside the FPGA and reverse once outside using MSI shift-register chips etc

Protocols

• I2C (Master or Slave operation)
• SPI (Master or Slave operation)
• I2S
• JTAG
• UART

Here again the coding will not be an issue (not to take it lightly, but harder things are ahead) the stumbling block can be validation of the logic on FPGA. Since we need to be able to show that your chip is able to work seamlessly with the standard you would have to interface it with another device that operates in the protocol and prove that they can communicate. So along with the work on the HDL design you would have start working on the validation environment. Also interfacing, clocking etc would be harder. Also a logical oscilloscope can be very useful while debugging on hardware and access to one is an important criterion to select these kinds of projects

Application Based

• Image Watermarking on FPGA
• Traffic Signal
• Industrial Safely System
• Your Brilliant idea

In some ways, these are the safest projects to take. Here what you do is take a real life problem and solve it using electronics. You define the context of the pins and digital logic. Like a pin going high can indicate the activation of a safety latch to prevent a nuclear reactor from explosion Only difference between an ordinary electronic project and VLSI would be that the core logic that solves the practical problem would be implemented in FPGA. The actual logic to be implemented in the FPGA can be as simple as a string of ring counters or complex state machines depending on the problem that you are trying to solve AND how you propose to solve it. Also since the main idea is to (unleash your creativity and) get familiarized with FPGA flow and FPGA’s don’t lend into small form factors – a lot of packaging (“product-worthiness”)  related issues are sorted ,which would have arisen if the project had been done using components like micro-controllers and discrete components. (In the VIVA you can say that you are using the FPGA as a prototype and can go into mass production of smaller ASIC’S once the practicality is proved on FPGA )

As you can see my main aim was not to provide a comprehensive list of projects, which I feel is something that should be left to your imagination, but try to classify the projects based on the difficulties and infrastructure required so that you can make a informed decision which choosing the topic. I hope that this was helpful and please do leave a comment to share your experiences.

Continuing from part I

Project Considerations

Like I mentioned earlier a VLSI project is different for the different considerations that you must put in first as opposed to another “ordinary” project. If you do a FPGA based project, you are eliminating some of the issues existing with other type of VLSI projects like aligning with the foundry timing but still there are other important points. Here are some of the considerations that I feel must be well thought off before venturing into a VLSI project.

Facilities, Faculty and Tools

VLSI is a relatively new domain and hence this is one consideration that must go in earlier that other. Ask some questions to yourself

Who would be responsible for providing me with the FPGA Hardware?
In case its to be done your self, it can be a costly affair as a FPGA kit can cost over 30-40k Rs factor that in
In case it’s the college authorities, make sure that the FPGA kit is already available and also that’s its working properly. Most importantly check that someone knows know to use it at least in a rudimental fashion because otherwise you could end up spending a substantial time learning how to use the FPGA rather than doing the “actual” project. It is true that you would have to allocate sometime for learning the FPGA and to program it but it should only take up a reasonable amount of your total project time.

Who would be responsible for the software?
Like I said there would be two parts to the project. One is to be done at the software level (Major Part) and other at the hardware level. The software for the same can be very costly if you go for full fledged versions. In any case select the software to be used pretty early in the cycle and also try to go for software which has been used by someone you know so that there would be a quick resolution point for issues. Also Take at look at some of the free software that I have mentioned later.

Why not an External Agency?
In case you taking the help of a external agency ,  a training center or project center or going in for internship somewhere [Places I know that offer VLSI internships include ISRO, CEERI Pilani, IIT’s and IISc etc but you need to initiate the process very early ].  (for want of facilities or tools or faculty) Please make sure that you understand first itself what your level of involvement  in the whole project would be. It might do you good to have a completely working project done and delivered by them as far as marks as concerned by it wont do you any good once you come to the industry and you are expected to know certain stuff on account of you having done such a project already

Topic Selection

Another important thing to consider is the topic or the core of the project. Here people tend to be a bit extravagant with their choices. Understand that you are going into a new domain, learn a new language, learn new tools and then finally implement them. In case some part of this is already done, well you can go ahead and take “harder” projects but try not to bite too much than you can chew.

Personally I would recommend a “phased” approach. In this approach you take up a base issue say I2C. Then you look at the minimal features that need to be implemented, for example 7 bit addressing and just master mode or slave mode operation. This is what you should commit to the college also. Then if you are successful in doing this within your time frame you can go ahead and implement the advanced features. I will list some topics for consideration and my opinion on them later. (See part III)

Some Free tools and Links – :  (http://www.cs.iitm.ernet.in/~noorse/new/resources.html)

IRSIM Switch level Simulator
IRSIM is a tool for simulating digital circuits. It is a "switch-level" simulator; that is, it treats transistors as ideal switches. Extracted capacitance and lumped resistance values are used to make the switch a little bit more realistic than the ideal, using the RC time constants to predict the relative timing of events.

Netgen (Layout vs. Schematic)
Netgen is a tool for comparing netlists, a process known as LVS, which stands for "Layout vs. Schematic". This is an important step in the integrated circuit design flow, ensuring that the geometry that has been laid out matches the expected circuit. Very small circuits can bypass this step by confirming circuit operation through extraction and simulation. Very large digital circuits are usually generated by tools from high-level descriptions, using compilers that ensure the correct layout geometry. The greatest need for LVS is in large analog or mixed-signal circuits that cannot be simulated in reasonable time. Even for small circuits, LVS can be done much faster than simulation, and provides feedback that makes it easier to find an error than does a simulation.

Digital Standard Cells
This is an excellent source for LEF and GDS standard cells. The cells are all compatible with the MOSIS SCMOS rules for the various processes available through MOSIS (mostly TSMC and AMI, 0.18um to 0.5um).

VIS (Verification Interacting with Synthesis)
Verilog compiler (vl2mv) and logic verification. VIS (Verification Interacting with Synthesis) is a system for formal verification, synthesis, and simulation of finite state systems.

Logic optimization using SIS
This tool takes the BLIF format description and creates a reasonably good netlist representation using a set of standard cells described in the "genlib" format. SIS will do synthesis of both synchronous and asynchronous sequential circuits.

Verilog Compiler (Iverilog)
Icarus Verilog is a Verilog simulation and synthesis tool. Iverilog. (Latest)

Verilog Compiler (Iverilog) for Windows
Icarus Verilog is a Verilog simulation and synthesis tool

GTKWave (Electronic waveform viewer)
GTKWave is a digital waveform viewer useful for examining the output of various digital simulators (like Icarus Verilog, for example). It can read VCD, EVCD, LXT, and Synopsis output formats. It was built using the GTK+ toolkit.

Language Selection/Learning

This is another important decision to be made. Some of the important languages that you can use are Verilog, VHDL, SystemC, System Verilog etc.

For a normal engineering student with background in C there is a important distinction to be understood between coding in C and other software languages and HDL’s.  At one level most people emphasize that there is no concept of time in C and a different connect of parallelism. As far I see it even thought this is a correct way of stating the difference there is to be understood in a different way. This is something very important which will explain in another post.

As far as section is concerned SystemC and System Verilog have a lot of features which make it beneficial for verification so if you plan to place a lot of emphasis on verification and simulating (which you ideally should be but may not work within given timeframe). And of the two I think System Verilog is the language of the future.

As far as VHDL and verilog is concerned. Both are fine, but I have a bias towards verilog (even though I did my academic project in VHDL) mainly because I feel it is easier to learn that VHDL. VHDL in a sense is very structured which has a lot of uses when it’s a huge project, but in the structure it’s easier for a newbie to get lost.

Another Important point which is not stressed at the college level (at least mine) was the power that a scripting language can provide. If your working on Unix Shell it self would be enough and TCL is a good choice in Windows environment (and Unix too). If some of the tasks can be automated, a lot of time can be saved and also final presentations can be given that “professional” touch. But you have to objectively plan whether usage of a new language would save time or waste it ???

Project Planning

As is often said (but not done enough) Prior Planning Prevents Poor Performance. Planning is a very important phase of any project let alone one such as this. Also try to factor in as many risks as possible. End of the day remember that even seasoned managers get planning wrong but still the project goes ok. Just remember that it’s a facilitator than the deliverable. Some of the phases that must be considered include

1. Ramp-Up VLSI Basics/Coding – Must be done as soon as possible and should reach a reasonable level of comfort here by writing smaller projects
2. Ramp-Up Hardware – Must be done as soon as you get your hands on the hardware. Try to implement smaller things like counter etc and see the LED’s blinking
3. Design Phase – Try to visualize the whole project to be split into parts that can be independently coded and tested. Not all parts may be possible but as a general rule try to visualize the hardware before writing it. A study of designing writing good state machines (if required) is good. 
4. Coding Phase – This is some of the phases that can be sped up. Try to the capabilities of the tool to maximum. For example some tools might write out and give simple structures like FIFO etc. Unless the project is too simple and there are just FIFO’s and simpler stuff try to use the tool for the same. Make sure you understand all the code the tool generates except for maybe some macros etc.
5. Verification – All individual modules should be verified by subjecting it to simple test-cases. Ideally as soon as you start coding you project, someone else (other than the coder) should start on a test bench to test the code that is being written. Ideally both should not communicate with each other how they are implementing their work and should take all information from the specifications document detailing the specification. The idea is that if the person developing the testing environment and test cases come s to know of the intricacies design, he might get subconsciously biased and a true verification might not take place. How much of this is actually possible is something should be decided based on different constants that are on a academic project.
6. Some level of automation using scripting languages, if pre-planned can save a lot of time

Documentation

I know from a personal perspective that documentation can be a pain in the wrong place. But if you have a rough document where you pen down your experiences, it can be very helpful while making a final formal document. It has other uses like being helpful for other team members and also for your juniors.

Some Other Ideas

Also if you are really interested some other ideas include

1. Study Group – In case more than one team is doing different VLSI projects, a study group within the college would be very beneficial for all the teams. It might help not to  re-invent the wheel , so to speak , if there is proper communication between the teams both at the learning phase and also at the implementation phase
2. Another thing that can make things interesting is to start up a blog to document your experiences. This is true for any kind of project though. It is generally very common outside India I believe. It can help other doing similar work to discover you and ask for help or help you out. We had done something simlar, but our laziness got the better of us FreeCan

I hope this is helpful in your endeavor and do let me know of your experiences- successes and un-successes (there are not nothing as failure as long as you learn a few new thing….which I am sure you will) and don’t hesitate to contact me for any help you think I can provide

Continue reading Part III