Principles of Top-Down Design
Principles of Top-Down Mixed-Signal Design
describe the desired behavior of each block, specifications that were often poorly writ- ten and that frequently go unread.
Every Change is Verified
In a primitive top-down design methodology, the architectural description of the system is usually thoroughly verified using simulation. However, the design is then re-created at the circuit level during the implementation phase and this version of the design is never checked against the original architectural description. This discontinuity is where many of the errors creep in that are not found until first silicon. In effect, the verification that was done in the architectural phase is not leveraged during the implementation phase, and verification in the implementation phase is generally not as effective because it is very slow and so cannot be as comprehensive. In addition, the test benches used during the architectural design phase often cannot be reused during the implementation phase, and are generally difficult to re-create.
It is important instead to use a common simulatable representation for the design that allows both the system-level and circuit-level descriptions of the various blocks to be co-simulated, as is possible with languages such as Verilog-AMS or VHDL-AMS. This capability is referred to as mixed-level simulation [15,24]. With it, individual blocks or small sets of individual blocks can be represented at the transistor- or even layout-level and be co-simulated with the rest of the system, which is described with high-level behavioral models. While these simulations are often considerably slower than simula- tions where every block is described at the high-level, they are also considerably faster than simulations where every block is described at the transistor level. And they allow the individual blocks to be verified in a known-good representation of the entire system. In effect, the system simulations are leveraged to provide an extensively verified test bench for the individual blocks.
Consider a simple example. It is not uncommon for a system to fail at first silicon because of a miscommunication over the polarity of a digital signal, such as a clock, enable, or reset line. Such errors cannot survive in the high-level description of the sys- tem because of the extensive testing that occurs at this level. They also cannot survive during mixed-level simulation because the individual block, where the error is presumed to be, is co-simulated with shared models for which the polarity of the signal has already been verified. They can, however, survive in either a bottom-up or primitive top- down design process because the test benches for the individual blocks are created by the corresponding block designers. Any misunderstanding of the required interface for the block will be reflected both in the implementation of the block and in its test bench, and so will not be caught until first silicon.
4.3 Verification Planning
Generally users of bottom-up or primitive top-down design methodologies find that the errors detected at first silicon are a result of rather mundane mistakes that occur at the interfaces between the various blocks. These errors are generally caused by communica- tion breakdowns and would have been easy to find with simulation had anyone thought to look for them. The fact is that the focus of verification efforts in these methodologies is on guaranteeing the performance of the individual blocks, and not on identifying the problems that result when the blocks are interconnected. Some effort is generally spent on trying to verify the system as a whole, but it comes late in the process when the sys-
The Designer’s Guide Community
13 of 31