Wow, time goes by so fast. I just noticed that this blog celebrates its first birthday! Exactly one year ago it went “on the air”.
If you liked the posts, found them helpful or just have some nice things to say - just comment on this post.
Thanks,
Nir
Due to a long and severe sickness I was unable to update the blog for such a long time.
I promise to catch up soon, with more interesting posts - hold on…
For those who don’t read through the comments. Harry the ASIC guy commented on the last post about an FSM design environment from Paul Zimmer. You can find more details here.
Everybody is talking low power design now. I try to give some tips here and there on this blog - mainly from the digital design or RTL point of view.
This book (google books link): Low-Power CMOS Circuits: Technology, Logic Design and CAD Tools By Christian Piguet has really something for everyone. Whether you are an analog designer, digital designer, architect or even a CAD guy - read it. It is heavy on examples, which immediately gets my points.
I found the low-power RTL chapter very informative and it even covers some of the stuff I addressed in this blog.
Check it out, it is worth your time!
Here is a cool site that a colleague sent me - link here.
Scroll down and browse through the chapters. You can interactively play with different arithmetic operators and their implementations using the applets in the site. I found the special purpose adders to be especially interesting.
Here is a useful checklist you should use when doing your ECOs.
Correct your bug in RTL, run simulations for the specific test cases and some your general golden tests. See if you corrected the problem and more important didn’t destroy any correct behavior.
Using your spare cells and/or rewiring, implement the bug fix directly in the synthesis verilog netlist. Remember you do not re-synthesize the entire design, you are patching it locally.
Using your favorite or available formal verification tool, run an equivalence check to see if the code you corrected really translates to the netlist you patched. Putting it simply - the formal verification tool runs through the entire state space and tries to look for an input vector that will create 2 different states in the RTL code and the synthesis netlist. If the two designs are equivalent you are sure that your RTL simulations would also have the same result (logically speaking) as the synthesis netlist.
You will now have to patch your layout netlist as well. Notice that this netlist is very different than the synthesis netlist. It usually has extra buffers inserted for edge shaping or hold violation correction or maybe even totally differently logically optimized.
This is the real thing, a change here has to take into account the actual position of the cells, the actuall names etc. Try to work with the layout expert in close proximity. Make sure you know and understand the floorplan as well - it is very common to connect a logic gate which is on the other side of the chip just because it is logically correct, but in reality it will violate timing requirements.
This is to make sure the changes you made in the layout netlist are logically equivalent to the synthesis. Some tools and company internal flows enable a direct comparison of the layout netlist to the RTL. In many it is not so and one has to go through the synthesis netlist change as well
Let the layout guys do their magic. As a designer you are usually not involved in this step.
However, depending on your timing closure requirements, run STA on the layout netlist to see if everything is still ok. This step might be the most crucial since even a very small change might create huge timing violations and you would have to redo your work.
Gate level simulations are also recommended, depending on your application and internal flow.
What are spare cells and why the heck do we need them?
Spare cells are basically elements embedded in the design which are not driving anything. The idea is that maybe they will enable an easy (metal) fix without the need of a full redesign.
Sometimes not everything works after tape-out, a counter might not be reseted correctly, a control signal needs to be additionally blocked when another signal is high etc. These kind of problems could be solved easily if “only I would have another AND gate here…”
Spare cells aim to give a chance of solving those kind of problems. Generally, the layout guys try to embed in the free spaces of the floor-plan some cells which are not driving anything. There is almost always free space around, and adding more cells doesn’t cost us in power (maybe in leakage in newer technologies), area (this space is anyhow there) or design time (the processes is 99% automatic).
Having spare cells might mean that we are able to fix a design for a few 10K dollars (sometimes less) rather than a few 100K.
So which spare cells should we use? It is always a good idea to have a few free memory elements, so I would recommend on a few flip-flops. Even a number as low as 100 FF in a 50K FF design is usually ok. Remember, you are not trying to build a new block, but rather to have a cheap possibility for a solution by rewiring some gates and FFs.
What gates should we through in? If you remember some basic boolean algebra, you know that NANDs and NORs can create any boolean function! This means that integrating only NANDs or NORs as spare cells would be sufficient. Usually, both NANDs and NORs are thrown in for more flexibility. 3 input, or even better 4 input NANDs and NORs should be used.
A small trick is tying the inputs of all NANDs to a logical “1″ and all inputs of the NORs to a logical “0″. This way if you decide to use only 2 of the 4 inputs the other inputs do not affect the output (check it yourself), this in turn means less layout work when tying and untying the inputs of those spare cells.
The integration of spare cells is usually done after the synthesis step and in the verilog netlist basically looks like an instantiation of library cells. This should not done before, since the synthesis tool will just optimize all those cells away as they drive nothing. The layout guy has to somehow by feeling (or black magic) spread the spare cells around in an even way.
I believe that when an ECO (Engineering Change Order) is needed and a metal-fix is considered - this is where our real work as digital designers start. I consider ECOs, and in turn the use of spare cells to solve or patch a problem, as the epitome our usage of skills, experience, knowledge and creativity!
More on ECOs will be written in the future…
After a somewhat long pause here is the uArch template as promised.
As usual for any important document, it must have an owner, version control etc. Not much need to be explained here.
This is were order starts to give us some advantage. Every interface signal should be listed here, with its width, whether it is an input or output (regardless of the naming convention you use), description of what it is about and don’t forget the comments.
I usually like to add information on signals which I know will come handy for other designers, for example - if a system clock is gated low, or the amount of pulses a certain signal should expect for normal operation. The list can be endless, but remember to fill in information which is helpful to the designers interfacing to you. Here is a template for the signal list table.
Here, you want to describe what the block is supposed to do - e.g. this block controls a dual port RAM blah blah, or this is an FSM which controls this and that… The idea here is to give enough information for people to recognize the functionality in a glance.
This is the heart of it all. If you don’t put enough effort here than forget about this ever being useful. Try to have a detailed diagram (not code!) of how your block is structures - same style that you see here on this blog. You don’t necessarily have to draw every wire, but you should employ a qualitative approach.
Special care should be taken to describe in detail the critical path within the block, special interface signals (say if a signal is delivered on the falling edge for a normally rising edge design, the circuitry should be shown)
It is a good habit to have all interface signals present on your drawings. I also recommend to have each flop present on the drawing. This is especially useful for data path designs. This is not as much work as would seem, usually if you do calculations on a wide bus you just need to draw a single flop (again qualitative approach).
This is becoming more and more important the more large the block becomes and the more complex the functionality is. Take your time and describe “rules” (e.g. 2 cycles after signal A goes down, signal B should also go down.
You can go to much detail here, but try to extract the essence of the block and describe the rules for their correct behavior.
If you got someone writing formal verification rules or assertions for you, she/he will kiss your toes for writing this section.
All the important stuff that didn’t go in the upper 5 sections should go here.
This post will be a bit different. I will try to tell you about my philosophy on how to approach a design, hopefully I am able to convince you why I believe it is right, and why I believe this approach makes one a much better designer (at least it worked for me).
So if you are looking for special circuits, cool tricks or design tips, you won’t find them in this post.
Back in the 1990s, when I started in ASIC digital design, I used to get a task, think about it a bit and then wanted immediately to rush, code and synthesize the thing. My boss back then practically forced me to write a micro-architecture document. This in essence meant to give a precise visual description of all pipeline stages, inputs, outputs and a rough idea on the logic in between (one need not draw each gate in an adder for example).
I hated it big time. I thought it was so obvious and trivial. Why the heck do I need to have a list describing all inputs and outputs? it’s anyways in the code. Why do I need to have a detailed drawing of the block with pipeline stages, arithmetic operations etc? it is also in the code. Well I was wrong, very wrong.
Only when working on a large project you understand how much the time invested in writing a micro-architecture document pays off. Doesn’t matter how proficient you are in VHDL or Verilog, it is not easy understanding what you did 3 months ago, it is easier looking at a diagram and getting the general idea in a blink. uArch also helps aligning different designers within a big project. It will help you optimize your design, because you will see all pipeline stages and you will get an overview on the block. you will see where it is possible to add more logic and where it must be cut. If you are experienced enough, you could often detect the critical path before even synthesizing your code.
This is the main reason why you see mostly diagrams on this blog and not code. HDL code is a way to describe what we want to achieve, some people confuse it with the goal itself. In my humble opinion it is extremely important to make this distinction.
Bottom line - most will think it is time spent for nothing. From my own personal experience, you will actually design your blocks faster like that, with less bugs and other people could actually understand what you did. Try it.
On the next post I will give a rough template on how I think a uArch document should look like and what it should contain.
It is extremely rare in our industry that totally new approaches for Logic circuit design are taken. I don’t know the exact reasons and I really don’t want to get into the “fight” between tool vendors and engineers.
Null Convention Logic, is a totally different approach to circuit design. It is asynchronous in its heart (I guess half of the readers of this post just dropped now).
It is not new and being currently pushed by its developers in Theseus Research.
They published a book, which I really recommend reading. It is not very practical with the current mainstream tools and flows but it is a very interesting reading that will open your eyes to new approaches in logic design.
You can get a good introduction to the book’s content by reading this paper. It is fairly technical and would need a few good hours to digest and grasp the meaning behind, especially given the fact that it is so much different than what we are used to - forget about AND, OR and NOT gates…
Book link here.
You are currently browsing the archives for the General category.
