Principles of Top-Down Mixed-Signal Design
Principles of Top-Down Design
This reduces the number of flaws that creep into a design because of miscommunica- tion. The formal nature of the communication also allows designers to be located at dif- ferent sites and still be effective.
Following a top-down design methodology also reduces the impact of changes that come late in the design cycle. If, for whatever reason, the circuit needs to be partially redesigned, the infrastructure put in place as part of the methodology allows the change to be made quickly. The models can be updated and impact on the rest of system can be quickly evaluated. The simulation plan and the infrastructure for mixed-level simula- tions is already be available and can be quickly applied to verify any changes.
An effective top-down design process follows a set of basic principles.
A shared design representation is used for the entire length of the project that allows the design be simulated by all members of the design team and in which all types of descriptions (behavioral, circuit, layout) can be co-simulated.
During the design process each change to the design is verified in the context of the entire, previously verified, design as dictated by the verification plan.
A design process that includes careful verification planning where risks are identi- fied up-front and simulation and modeling plans are developed that act to mitigate the risks.
A design process that involves multiple passes, starting with high level abstractions and refining as the detail becomes available. In effect, running through the entire process very quickly at the beginning with rough estimates and guesses to get a bet- ter understanding and better estimates, and then refining the design as the process progresses.
To the degree possible, specifications and plans should be manifested as executable models and scripts, things that are used in the design process on a daily basis, rather than as written documents.
A Shared Design Representation
In the primitive top-down design process commonly used today, the system designers use a different design representation than the circuit designers. For example, the system designers might use a spreadsheet, Matlab, Simulink, SPW, or SystemView while the circuit designers would use Verilog, VHDL, or SPICE. This causes a myriad of prob- lems, perhaps the most important being that they are using different tools to explore the design that make it difficult for them to share what they learn during the design process. As mentioned before, this leads to communication problems and eventually to design errors that are generally not caught until first silicon.
If instead a common simulatable design representation is used, such as Verilog-AMS or VHDL-AMS, then the system engineers can build an architectural-level description of the design constructed from behavioral models of each of the blocks that can be evalu- ated by each of the circuit designers. In effect, the circuit designers start by receiving an executable example of what they are expected to design. If they have trouble meeting their assigned specifications, they can go back to the system engineers with simulations that show how the system is affected by the shortfall. Since both types of engineers are working in a familiar environment, communication is enhanced and potential resolu- tions can be explored together. The ready availability of behavioral models of the blocks that act as executable examples greatly reduces the need for onerous specifications that
12 of 31
The Designer’s Guide Community