Micro-Architecture Template

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.

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.