Greetings from the Monastary

This will prove how much of a geek I truly am.

Early in my career, I used to think of myself of a "Priest of Technology". That is, I would supplicate with the technology gods and deliver their revelations to the common man.

It was during a meeting with a customer, specifically Apple, that I realized how very wrong I was. The people at Apple were the technology priests. They were the ones who brought technology to the masses. I designed IC's for a living. The masses didn't really know or care about what I did.

It was then I realized that I lived a cloistered existence away from mankind. I supplicated with the technology gods, not to deliver the revelation to the common man, but to deliver it to the priests, who would then deliver it to the common man. I was not a priest. I was a monk.

So, greetings from the monastery.

I Don't Know What You Do - It Must Be Easy

Not long ago, I had the opportunity to entertain an analog designer from another organization. He would be coming to our office for training on digital design techniques. He would spend the morning with me for me to train him how to do the front end standard cell flow.

My first reaction was one of deep indignation. How was I to train him to do something that I have spent the last 20+ years learning how to do, in about four hours. When I calmed down, I decided we could at least do an overview of how a typical flow takes place.

So, in a short four hours, I discussed hardware descriptor languages, simulation, structured design techniques, synthesis, test insertion, logic equivalence, static timing analysis, automatic test pattern generation, back annotation, and probably some other stuff. By the time I got through, he said, "I didn't realize there was so much to this."

This event called to mind an idea that I have mulled over for years - We tend to marginalize the jobs of people we know little about. Some examples:

1. How many times have I said something like, "It's just software. It must be easy."
2. I once worked for a company that had a peer review system. It was a two tiered system. One tier for those who worked closely with you. The other for those who were acquainted with your work. The votes for those acquainted with my work always tended be much more "average."
3. The concept in modern business practice of the generic "resource."

A disturbing trend during the current economic downturn seems to be to lay-off the experts because they cost so much. I think this shows corporate America's marginal view of the expert.

'Nuff said.

Comfort Zone

I am convinced that one of the major impediments to improvement in the industry is inertia.

Engineers are like much of the rest of the population. The tend to want to stay where they are comfortable. A couple of examples:

I worked for a company in the early 90's that was a full custom house. It became obvious that the time to market requirements would not support that style of design, and so the organization transitioned to standard cell methodology. There was resistance from many in the organization that thought, "This will never work." The leaders who were pushing this new philosophy were demonized in the trenches. Many engineers were drug kicking and screaming into a new design paradigm. Ultimately, the result was a successful product line which could be modified and retargeted much faster than a full custom design.

More recently I was in an organization that built a DDR interface. The design team custom built a bit lane. I suggested that they could save a lot of time if they use an automatic place and route tool to connect the bit lanes. The response was that the would lay it out by hand. Why -- Because they knew how to do it that way. The result: The part taped out. But it took much longer on that interface than necessary. Additionally, the learning that could have taken place in that exercise has been postponed. So, the next time the team works on a similar interface, all the barriers to improved productivity will still be in place. The sort of thinking that took place on that device could ultimately drive that organization into oblivion. Oh, by the way, that part taped out in 2007.

So, in general, processes do not improve unless they have to. Some reasons why they might have to:

1. It just doesn't work. People don't do the same things at 45 nm that they used to do at 0.5 micron, because the same things just don't work. An aspect of this is the existence of constantly changing requirements. One of the big drivers in the past has been time to market. Speed and power have also been big drivers. After all, necessity is the mother of invention.


2. Obsolescence. Tools have morphed over the years. I cannot do the same things I did 15 years ago, because the tools have changed. For instance, Design Compiler does not support dc_shell scripts. They have moved to tcl. There was a cry that went out from the design community when this happened, because much of what they were doing became obsolete. But in one way, Synopsys did the industry a great favor, because it forced the industry to revisit how they did things.


3. Visionary. There is a balance between getting products out the door and trying out new things -- between the grindstone and the ivory palace. An organization needs someone who sees the big picture and pushes the design teams out of their comfort zone. Since I have mostly been a grindstone kind of guy in my career, sometimes the visionary types really irritate me. But the truth is, we need them.
   

The real trick in all this is to find the balance between reuse and innovation.

The Big Green Button

The Holy Grail of EDA has been the ability to go directly from an abstracted version of the design (such as RTL or System C) to the physical implementation, that is GDSII.

The result is that many players in the chip design business are hawking their own canned methodologies or flows. The idea is that you can take a fairly junior engineer, put him in front of the terminal, and tell him to push the "Big Green Button". It reads in the RTL and in just a few hours the completed physical design pops out the other end.


There are two main problems with this idea. The first is that very few designs are "typical". There tend to be issues that are specific to any particular design that require unique attention. Therefore, it is very difficult to construct the tool that will handle all cases.

If this was the only problem, it would be OK for the tools team on any given project to spend an inordinate amount of time solving it. But the second big issue deals with the fact that the effort to create the Big Green Button actually makes using the tools more difficult. Specifically, the "environment" generally abstracts the user from the tools he is using. Now the poor soul trying to implement the design needs to not only know what he wants the tools to do, but he needs to know how to make the environment make the tool do what he wants it to do.

What do I mean? Let's talk about something simple like trying to read the RTL into the synthesis tool. If you were driving the tools, you would know that the tcl command read_verilog does a pretty good job of reading Verilog into Design Compiler. One company I worked with did not want you to touch the scripts; therefore you needed to call a perl script to run the tcl to read the Verilog. Not a big deal, but it is a level of unnecessary abstraction.


I worked on another project, building an environment, and the process of reading in a Verilog file called a pointer that pointed to a pointer, ad nauseam. By the time the process was over, there were 13 levels of indirection to get to the Verilog file. It may have made sense to the developer, but it was a little difficult for the user to understand what was going on.


This brings us to fact that tools vendors tend to document their tools pretty well. The environment development team seldom does. As a result, not only is your job more difficult, there is no easy way to find out what needs to be done.

In my opinion, a good tool flow is a directory structure, a set of scripts, and a method to reliably rerun the scripts. It should allow the designer to be able to experiment with a myriad of strategies to complete the required tasks. The tool flow should not abstract the designer from the tools themselves.

Maybe some day, the tools will be so sophisticated that they will not require much human intervention. They are not there yet.

Exceptions Should Not Be the Rule

As technology has expanded, creating increasingly more complex designs, design flows have remained relatively static. We have been doing the RTL, synthesis, place and route, flow for 15 or so years. There are little tweaks to the process that come along, such as physical synthesis, but radical wholesale changes to the flow have been quite rare.

For instance, one of the Holy Grails of design, that remains elusive, is a higher level of abstraction. There are tools out there that exist, such as System C, but as far as I can tell, their use is limited, and their acceptance is dubious.

What has changed is capacity. The first standard cell designs that I worked on were in the 100K gate range. Now we are looking at 10's of millions of gates.

What is my point? Simply this: as complexity and capacity increases, the ability to handle oddities decreases. This is simply because as the capacity for design size increases, our capacity to handle oddities does not, because they must be addressed individually.

Sure, there are ways to do anything. You can throw in asynchronous logic, or cross coupled gates, or latches, etc. You can put false paths and multicycle paths into your timing analysis. But every time you do something strange, it requires specific consideration. It also has a ripple effect. It affects timing, test, synthesis, and layout.

There is a word used in this business for oddities. They are called exceptions. The implication is that they are "exceptional," that is, out of the ordinary. These exceptions should continue to remain out of the ordinary.

Don't get me wrong. I am not saying, "Don't do anything exceptional!" I once worked for a company that decided they would not do anything unusual. They produced a design that was single clock, single edge, synthesized design, with no exceptions. That was one of the most insipid devices of my career.

At the same time, your exceptions should not be the rule. I once consulted for a company doing static timing analysis. The "exception" file for their device was over ten thousand lines long. It grew to over twenty thousand. We spent a lot more time handling the exceptions than the rest of the design. The number of exceptions also meant that no one really had a good grasp of the situation.

In general, tools do not like exceptions. Whether you want to admit it or not, our design process is largely tools dependent.

So what am I suggesting:

1. Understand clean structured synchronous design. This should be your goal. By the way, if your testability tools like it, it is probably OK.
2. If you are tempted to do something flaky, think again. Be creative. Many times there is a better way to get done what you need to get done.
3. Isolate the exceptions. Put clean boundaries around them. Limit the impact to the logic around it.
4. There are times when you need to have an exception. Limit their number and influence. Understand them. Document them. Make sure everyone on the project knows about them. If there are too many to keep up with, there are probably too many.

Test is not an Afterthought

This may not seem like an important subject to many designers. It is precisely because of this attitude that it is such an important subject. It seems important to me because almost invariably, every project that I work on is cursed at some point by some big brouhaha that boils up around the subject of test.

When I began in this business, test was an afterthought. If you cared at all about fault coverage, you fault graded a part. This consisted of writing a bazillion test vectors and running a bazillion simulations to find out what was tested and what wasn't. It took man years to test parts of any great complexity.

As part complexity increased, all of the sudden, you had to write hundreds of bazillions of vectors and run hundreds of bazillions of simulations. Then DFT entered the scene. Instead of having to invest all of that time and effort, all you had to do was to let the tools do it for you. The problem with this was that it greatly influenced the design practice.

In 1988, I went to work for a large company that built microprocessors. Those were fun times, because anything went. You could cross couple gates. Tri-state buses went everywhere. We had dynamic logic. The design style at that time was to have non-overlapping clocks and use latches.

Sometime about then, a team decided that they would start using this neat new scan methodology stuff. They utilized the same practices they always had, but they also added a slave latch to all of the functional latches to create scan flip-flops, and chained them all together. The result was a scannable design. The difficulty was that much of the design was not controllable, so the scan coverage on that device was about 6%.

Things have improved greatly over the years. Design teams use structured design styles. We understand testability a lot better. But we still get stuck with test issues at the end of the project.

I think there are at least two reasons for this:

1. Test touches everything. It typically touches every register in the device. It affects how you generate your clocks. It affects reset. It affects I/O. There are additional timing constraints and analysis that are devoted to testability.
2. Everyone assumes it is easy. Nothing in this business is easy. If it was, they would have hired a monkey. It is especially not easy if you don't think early about it.

So what do you do about it? Here's my short list of test stuff:

1. Start early. Hire someone who knows what they are doing. At least make someone on the team responsible for test - from the beginning.
2. Define it in the specification. How are you going to multiplex clocks? How many scan chains? How do you control test modes? What is happening to reset during test? What fault models are you going to use? What is your coverage target? How are you testing macros, such as RAM's or register files? Is there embedded IP?
3. Keep an eye on test during the design. If you have a goal of 98% coverage and the tools tell you a block is a 63% coverage, you need to understand why?
4. Treat the test signals with respect. Scan mode is a high fanout net. It probably needs special attention, like clock tree synthesis. Look at the test signals at the top of the design as early as possible.
5. Don't wait until the day you are supposed to tape out to look at test timing. And, don't wait until after you have tape released to run the ATPG tool.
6. Treat your DFT engineer with respect. Remember, it only looks easy. And besides, if he gets ticked off and leaves, you will have to do it.

So, test is a necessary evil, unless you want to write bazillions of functional vectors. DFT actually saves time. But you should think about it - early.

Clocks are your friend

I once went to help a design team with their Static Timing Analysis of a chip. When I got there, one of the questions they asked was, "Could you write a script to tell us which clock domains talk to which other clock domains?" At that point it was all that I could do to keep from running from the building.

Why is that? Because, clocks are at the heart of digital design. If you don't understand the clocks, you don't understand the design. A good design team should be able to tell the guy doing the STA exactly which clock domains cross, exactly which signals cross those boundaries, and exactly what design practices have been utilized to make sure that the clock crossings are handled correctly. They should also have thought about how they are going to time those interfaces. Oh well, I guess teams that have their act together don't usually call in the consultants.

What are some suggestions?

Write a Specification

I have talked about this in the past. The point is still valid. You should have a good specification. One of the most important parts of the specification is the clock section. All domains and all crossings should be documented and detailed.

Limit Domains

I have worked with chips that have had about 50 different clock domains. I have worked with chips that have one. Let me assure you the chips with one are a lot easier to work with. I also have to confess that chips with a single clock domain are of limited interest in the market place.

I sometimes think that architects do not go into the design with the concept of limiting the clocking complexity. If you have to have multiple frequencies, limit transitions. Can the transitions all be handled at the periphery of the chip, that is the I/O? Can the core run at a single frequency?

Synchronous Domains

When you have separate domains, can they be treated synchronously? Can you limit the domain crossings so that one is a multiple of the other, so that they can be timed synchronously?

Even if you don't have asynchronous domains, can you pretend? What do I mean? For instance, if you have one domain with a period of 2.0 ns and another domain of 2.27 ns., can you time them at 2.0 and 2.2 ns. The reason for this consideration is that the static timing analysis tool will expand the clocks until they synch. If you use 2.0 and 2.27, the clocks will expand about 200 periods and give up trying. The result is that your static timing will be more compute intensive. If you use 2.0 and 2.2, the clocks will sync after 22 ns, which is a lot less compute intensive. You do need to make sure that this relationship does not mask errors. That is, the closest these clocks will be is 200 ps. In tral life, they are truly asynchronous. Does that allow some signal to sneak through unnoticed? This is unlikely, especially if you have any clock uncertainty. But, you should be aware.

Limit False Paths

Just for the record, I hate false paths. I know that they are necessary sometimes, but there are a couple of issues to be careful of.

First of all, do not use false paths liberally, such as setting a false path from one clock domain to another. Why? Because this habit can mask problems. For instance, you have a data bus that crosses from clock A to clock B. You have created an elaborate FIFO scheme to assure that there is no clock boundary issue with the data bus. You set a false path between the domains. But, you forgot about a control signal that is sent across the boundary. You will never see a problem in STA. Depending on your verification environment, you may not see a problem in functional testing. A better solution would be to set false path for the data bus specifically. If there are no other clock crossings, it will work. If there are some you forgot about, they will get flagged.

Another issue with false paths is that if the constraints are used for synthesis or placement, you could end up with a registers that talk to each other at far ends of the chip. It might be better to use a multicycle path, or specify placement boundary to assure that a reasonable placement takes place.

Your Friend

In my experience, teams that understand their clocking, have their acts together. Those that do not understand, do not have their acts together.

Ultimately the clocks should be your friend. You should get to know them.