ASIC Specification: how not to suck

I don’t know where bad ASIC specs started, but I suspect it was at the Big Nerd Ranch. ASIC designers would write a document describing their design, and voila, and ASIC Specification was born. Sorry, but when your write a description of your design, you are not telling me what you designed, you’re telling me how to designed it. Nobody really cares about HOW you implement the FizBoo feature. What I care about is whether you implemented FizBoo or not, how to program it, how to turn it off, and what it does.

The dictionary definition for specification is:

“a detailed description of how something should be done, made, etc.”

See, it should not even be called an ASIC Specification, because I don’t care how it’s made! Maybe you do, but I don’t! The ASIC Specification is the wrong thing to write. So let’s describe what kind of documentation I need as an ASIC Verification engineer:

  1. Feature name (FizBoo) and short description (FizBoo scares little kids on halloween night).
  2. How to program the feature, how to turn it off.
  3. What the feature does to the data. If you can’t describe it in terms of a data tansformation, it’s not a feature and I won’t verify it, so why are you doing it?
  4. What the functional interfaces are: am I talking to a PCI-X bus or a T1 interface?
  5. A functional description of the functional interfaces: how do I twiggle the signals on that interface to make it tango baby?

See, I don’t care that you store 20 kilobytes of user data in a sea of flops or an internal RAM. I really don’t. I want to know how to get the data in there, not how you made the address decoder.

Except for one thing: I need to know your corner cases. Like “the data is cached in 32 words of 64 bits before being stored”. I will use this information to craft pieces of data that nicely align on 31 64-bit words. Or 33. Anything that will break your design will be my pleasure to try. But the internal RAM stuff, keep that for the back end squad. And why and how you arrived at the conclusion it was a RAM and not a sea of flops, I don’t really care either.

So how to write the ASIC spec then? First, don’t call it an ASIC spec. Call it a Detailed Feature Guide. The document should be a big “foreach loop”. For each feature, describe items 1 through 3 above. For items 4 and 5, they aren’t really attached to a particular feature, they are more like the boundaries of your system, like going through customs. They are related to a physical, geographical separation between the external world and the bowels of the ASIC. So this should be a separate document: the ASIC External Interfaces document. There are internal interfaces too, but you only need to document them on demand: places where BFMs will be probing/pulling for data, i.e. boundaries between the provinces of the ASIC country. So for the internal interfaces, have a 3rd document, the Internal Interfaces document, generated on demand only! You create this document only if others need to know how to interface with your internal stuff.

And while you are at it, why not engage the verification team early: they are the first customers of the ASIC, long before the software team. So instead of having them dream up a massive verification environment, have them write the Detailed Feature Guide. Of course, you’ll have to talk with them regarding the content, but let them do all typing and the editorial work while you are busy figuring out whether you use a RAM of a sea of flops.

Lastly, you should also engage the software team on all this. So have them write the Programming Guide while the verif team is busy writing the DFG. So what you have is a fully parallel documentation delta force working for you:

  1. Verification team writes the Detail Feature Guide (DFG)
  2. Software team writes the Programming Guide (PG)
  3. Design team writes the Internal Interfaces Guide, only for the interfaces that are needed by the verif team (for BFMs), or the other designers interfacing to your sub-block.
  4. Three documents, three teams, a triangle of power, a delta force at your service. D’oh! I forgot the backend squad! Here it goes:

  5. Design team writes the Internal Description document, for all the things only backend cares about (RAM vs. sea of flops).

And for the External Interfaces document, I don’t really care who writes it, everyone needs to know whether it’s PCI or Utopia, and it’s usually already described somewhere else like in a standard.

At this point you are maybe getting anxious about having your verification team not writing the verification environment document or the verification plan, but they need the feature desription to know what to test, and the designers are usually overloaded towards the first half of a project translating marketing requirements into real world hardware. So have the verif team write the documentation they need. The verif team can develop their code while the designers write the RTL.

And bonus points if you find a way to cross refence external software register names between all 4 documents.

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: