Archive for November, 2007

h1

Spare Cells

November 26, 2007

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…

Advertisements
h1

Send Your Problem

November 13, 2007

Being the generous person that I am 🙂 I decided to open a new section in this blog called “Send Your Problem” or SYP.

If you have a design problem of any sort, that you think would interest others, or just that you need help with – send it over – yes, you heard it right. I will try to do the best I can to pick up the most difficult/interesting problems and post them with some solutions (hopefully).

I have limited time, and I really do it on my own spare time so be patient if it takes me time to answer. I will of course, try to address all questions, at least by email.

h1

Micro-Architecture Template

November 13, 2007

After a somewhat long pause here is the uArch template as promised.

  • Part 1 – Block name, Owner, Version control
  • As usual for any important document, it must have an owner, version control etc. Not much need to be explained here.

  • Part 2 – Interface signal list
  • 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.

    signal_list.png

  • Part 3 – Overview
  • 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.

  • Part 4 – Detailed Functional description of key circuitry with drawings
  • 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).

  • Part 5 – Verification – list of assertions, formal verification rules, etc.
  • 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.

  • Part 6 – Comments
  • All the important stuff that didn’t go in the upper 5 sections should go here.