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.

    Advertisements

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s

    %d bloggers like this: