Develop the Preliminary Design
The role of the complex electronics engineer during the preliminary design phase (also called the conceptual or architectural phase) is to come up with a high-level design that meets the requirements. At this level, the design engineer has to keep a systems point of view, because the complex electronics interfaces with other elements of the system. It's also common that the functions to be performed are still fluid, and the allocation to software, complex electronics, and other electronic elements may change.
The architectural (high-level) design converts the requirements into functions to be performed and the interfaces between those functional blocks. There is often a certain amount of trade-off during this phase, as various requirements or goals come into conflict. The design engineer needs to be aware when design decisions for the complex electronics affect other elements of the system, especially by imposing constraints on those elements.
The initial high-level design may be made using functional block diagrams, design and architecture descriptions, or sketches. As the design is solidified, it is usually implemented in a hardware description language (HDL), such as VHDL, Verilog, or SystemC. At this stage of development, the complex electronics is defined as black boxes, with specified behavior and interfaces. The specific details are added later in the design life cycle.
During the preliminary design phase, the architecture of the chip is defined, verified and documented. The architecture is defined down to the level of basic blocks that implement all intended functions. In addition, the interfaces and interactions between the blocks are specified. Important decisions for the implementation of the chip are made at this phase, including the selection of COTS, third-party, or re-used IP (Intellectual Property) modules or cores.
This section covers:
Design Description
The design description (architecture) is the preliminary design document. The design description should show a clear relationship between the requirements (specification) and the design. A traceability table is one way to accomplish this.
The document provides an overview description of the functions the complex electronics will perform, and includes:
- An introduction to the architecture
- Partitioning of the design into blocks, with supporting rationale
- Interactions between the blocks
- Internal protocols and data formats
- Interfaces and protocols to external devices
- Memory mapping
- Detailed functionality (e.g. finite state machines)
- Fault/error handling
The high-level design needs to address the following areas, in addition to meeting the requirements:
- Constraints related to safety, including prevention of design errors
- Handling of functional, component, over-stress, reliability and robustness defects
- Constraints the design imposes on other system elements, such as software
- Reliability
- Maintenance
- Test features – what needs to be included to make sure the device is testable
Create HDL Models
Most modern designs are implemented in a hardware description language (HDL). HDLs are any languages that are used for formal description of electronic circuits. These languages can describe the operation, design, and simulation tests of the circuit. HDLs can show several aspects of the design, including the temporal behavior and spatial structure. The two primary hardware description languages are VHDL and Verilog.
Using an HDL, the designer creates a model of the complex electronics that includes the functions (behavior) and blocks of the architectural design. Later in the design phase, the HDL model will be synthesized (essentially compiled) by the tool suite into lower-level models. HDL models can be used to simulate the behavior of the complex electronics through execution in a test bench (described below) or simulation tool. Simulation allows for early verification of critical functions, though timing behavior is usually not verified at this phase of design.
HDL models have two aspects, behavioral and structural. A behavioral specification defines the behavior of a digital system (module) using traditional programming language constructs (e. g., ifs, assignment statements). This description of a complex electronic device divides the device (chip) into several functional blocks that are interconnected. HDL is used to describe the behavior of each block. Functional blocks can be a finite state machine, a set of registers and transfer functions, or even a set of other interconnected functional blocks.
A structural specification describes the digital system (module) as a hierarchical interconnection of sub-modules. The components at the bottom of the hierarchy are either primitives or are specified behaviorally. It is in the structural specification that individual inputs and outputs are defined.
Hardware description languages can be used to describe complex electronics at many different levels of abstraction. An abstraction is a simplified representation of something that is potentially quite complex. It is often not necessary to know the exact details of how something works, is represented or is implemented, because we can still make use of it in its simplified form.
The levels of abstraction for a complex electronic device are:
- System or Behavioral
- Algorithm
- Register-Transfer Level (RTL)
- Gate
Preliminary (architectural) design goes down through the algorithm level. At this level, there is no concept of timing in the description of the complex electronics behavior. A pure algorithm consists of a set of instructions that are executed in sequence to perform some task. A pure algorithm has neither a clock nor detailed delays. Some aspects of timing can be inferred from the partial ordering of operations within the algorithm. The algorithmic level of abstraction is similar to software programming ("While ready, do task A and task B, then do task C"). Because of the lack of timing information, this level is not synthesizable (able to be mapped to hardware).
The RTL level models are created during the detailed design phase, and will be described there.
Test Benches
A Test Bench is a HDL design you create which can load your circuit, apply stimulus to its inputs (including defining multiple clocks) and check the outputs for correctness. Because it is a program you write, you have control over how your circuit is built and simulated. In addition to the above capabilities, a test bench can provide behavioral or structural models for everything on the PC board. In this way, it enables you to simulate the entire system including your complex electronics design(s) as well as external bus interfaces, external memories, etc. An engineer can design the test benches to automatically check important data conditions and to report any errors to a command window.
Comprehensive, up-front verification is critical to the success of a design project, and test benches should be created as you start to design your device. A HDL test bench/simulator can become your primary design development tool. When simulation is used right at the start of the project, you will have a much easier time with synthesis, and you will spend far less time re-running time-intensive processes, such as place-and-route tools and other synthesis-related software.
Test benches can be quite simple, applying a sequence of inputs to the circuit over time. They can also be quite complex, perhaps even reading test data from a disk file and writing test results to the screen and to a report file. A comprehensive test bench can, in fact, be more complex and lengthy (and take longer to develop) than the circuit being tested.
Depending on your needs (and whether timing information related to your target device technology is available), you may develop one or more test benches to:
- Verify the design functionally (with no delays).
- Check your assumptions about timing relationships (using estimates or unit delays).
- Simulate with annotated post-route timing information so you can verify that your circuit will operate in-system at speed.
A typical VHDL or Verilog test bench is composed of three main elements:
- Stimulus Generator - drives the unit under test with certain signal conditions (correct and incorrect values, minimum and maximum delays, fault conditions, etc.)
- Unit Under Test - represents the device undergoing test or verification
- Verifier - automatically checks and reports any errors encountered during the simulation run. Compares model responses with the expected results.
Coding Standards
A coding standard is important when more than one person will ever have to use the source code. The big danger is that when the person who wrote the original code leaves or moves on to another project, no one will understand how it works if the code ever has to change. Even the original designer is likely to forget it in several months.
One can easily write individual lines of understandable HDL code that collectively become extremely difficult to follow. A good coding standard will help alleviate this by providing guidelines for hierarchical structures and component instantiations. For instance, many books use various types of flip-flops as examples to model component instantiations (mostly because these are already understood by the readers). However, in practice, it's generally poor coding style to instantiate logic by mapping each register to various kinds of flip-flops. This can lead to longer, more obfuscating logic that does not take advantage of the ability to write in VHDL and Verilog at a higher level.
The important factors in a HDL coding standard are:
- Consistent and defined style
- Guidelines on writing understandable code
- Commenting guidelines
- Information to capture in comments at each level
- Naming convention (for consistency)
Design Verification
Once the preliminary design and HDL model are complete, the designer usually performs some level of verification using simulation. A test bench allows for software simulation of the complex electronics, and testing of the behavior of the design under various inputs. Software simulation is a very common verification and test tool for complex electronics. Other approaches to design verification include:
- Hardware accelerated simulation uses special purpose hardware to accelerate circuit functions, allowing long simulations to be run in a short period of time.
- Emulation uses electronic components to emulate the circuit behavior (e.g., using FPGAs to verify an ASIC design).
- Rapid prototyping creates a physical model (prototype) of actual hardware.
- Formal verification, using model checking to verify properties relative to a model (formal specification) and/or theorem proving, which proves theorems regarding properties of the mode.
While simulation is a very useful tool, it requires careful planning to generate appropriate inputs (stimuli) for the complex electronics to ensure that the design is thoroughly tested. Simulation does not take the place of in-circuit testing, but can be used to perform low-level verifications of design properties. Simulation can also be used to explore the design's responses under various error or fault conditions.
Maintenance and Maintainability
If the device will potentially need to be maintained (including reprogramming updates), this issue should be considered early in the design of the complex electronics and its supporting circuitry. Some areas to consider are:
- Will the device architecture allow for the types of enhancements that can be foreseen?
- Does the design specification provide the information that an engineer would need to understand how the product works?
- Is the HDL code readable?
- Are comments liberal and informative?
- Is the necessary physical infrastructure in place to allow reprogramming?
- Is access to the reprogramming port, if one is used, available when the system is installed?
Preliminary design review
This review is not the project Preliminary Design Review (PDR), but a review and evaluation of the complex electronic preliminary design. The should be reviewed by a variety of people. Each person will bring a viewpoint to the review that can identify gaps or errors in the design, provide best practices for design elements, and ensure that all requirements are implemented in the design. The preliminary design review can be a formal review (such as part of the project Preliminary or Critical Design Review), an informal review, or the result of many individual reviews.
Details on Design Reviews can be found in the Techniques section.
|
