Design automation has gone through three majorphases-computer-aided design (CAD), computer-aided engineering(CAE), and electronic-design automation (EDA)-and is about to entera fourth phase, system-design automation (SDA). Each phase isassociated with a fundamental technology or enablingtechnology.
Figure 1: Design-automation tools provide a means oftranslating a system design from one abstraction level to a lower,more detailed level. Currently evolving system-design automation(SDA) tools enable a designer to go from system specification to anRTL of the system.
The EDA and CAE markets are currently converging to produce asingle unified design flow from RTL to final silicon. This is dueto the crossover in primary timing delay from gate to interconnectthat drives logic-synthesis tools to incorporate placement in theircalculations. This change will yield two basic design flows:
- From system level through RTL (the SDA tools)
- From RTL to silicon (the EDA tools).
We will focus here on the system-to-RTL flow.
What is a System?
With the emergence of system-level integration orsystem-on-a-chip (SoC), the basic chip-based system increases incomplexity.
Figure 2: Today's complex SOC-based system is comprisedof processing cores, memory, user-defined logic, interfaces to theoutside world, and buses connecting the silicon cores.
The variety of design choices and system architectures availablehas multiplied. Designers now have questions such as:
- Which processor(s)? Are these processors on-chip, off-chip, orboth?
- Which bus(es)? How fast do should the bus(es) be?
- How much on-chip versus off-chip memory should be used? What isthe split between on- and off-chip?
- How much of a previous design can be reused?
- What parts of the design can be purchased as siliconintellectual property (IP)? Where is the focus for productdifferentiation?
- How should this system be designed for specification changesand derivative products?
- What is the hardware/software partitioning? What can be done insoftware; what must be done in hardware? Will this partitioningchange in future iterations?
Answers to these questions can be found in a system-designmethodology that incorporates an architecture-explorationprocess.
The Starting Point
The goal is clear-designers need software ready for optimizationand targeted to a specific operating system and/or processor.Designers also need an RTL hardware description optimized for theRTL-to-silicon flow. To achieve both, they need to begin with agood specification with the following characteristics:
- Implementation Independent
The specification should be technology (hardware or software)independent. The implementation flow should be able to take thespecification to either hardware or software without sacrificingquality of results.
- Formal and Executable
The specification should be in an unambiguous format that isdefined and understood by a wide audience. Standard languages, suchas the Specification and Description Language (SDL) or C, have theadvantage of being open, defined, supported, and executable.Simulating the specification not only removes ambiguity and allowssystem models to be exercised, but it also makes top-downrefinement and testbench development possible. Having aspecification in an open standard also means that more toolssupporting the language may be created, which protects thespecification investment.
The specification should support the idea of multiple processors(either hardware or software functions) working in sequence or inparallel.
- Abstract Communication In a heterogeneous mix of functionsworking sequentially or in parallel, data transmission betweenprocesses must be independent of the processes themselves. Thisabstract communication concept allows a freedom of implementationchoice from free-running shared memory-style communication, throughshared buses to dedicated handshake. Such choices duringimplementation have a profound effect on system performance andcost. Defining these choices at the specification phase severelyrestricts the implementation space and may introduce unforeseendeadlocks for the implied system architecture.
Whether such a specification language exists is the subject ofmany debates. Candidates for such a language include SDL, UML, andC++ with extensions. Regardless of the final choice, tool supportfor such languages will naturally evolve via the definition of thesubset a tool can support.
Figure 3: EDA tools face the challenge of effectivelyimplementing desired results with the user's choice ofdesign-description language.
The design problem is further complicated because hardware andsoftware designs usually require different description languagesand tools.
This situation is also further complicated because for effectivesystem-design automation, you need to consider the subset forhardware and software.
Figure 4: The goal is to produce the besthardware/software architecture from a single specification. To dothis, you must maximize the overlap of the hardware and softwaredesign subsets.
The Design Flow
The system synthesis tool should be able to:
- Read the entire specification. This enables the tool toimplement communication synthesis for the pre-partitioned softwareand hardware.
- Optimize the HW/SW trade-off for the subset of the design thatis not already partitioned (the technology-independentsubset).
- Target any processor and other hardware choices that constrainthe architecture implementation. That is, if a particular businterface and processor have already been selected then the toolshould be able to optimize the surrounding architecture to thatinterface and processor.
- Pass through the flow pieces of software or hardware that havealready been optimized and are to be treated as IP blocks. Such acapability is essential for reuse and derivative-productdevelopment.
Figure 5: System synthesis flow. An architectureexploration system examines hardware/software tradeoffs to meetsystem-design specifications.
The key to a successful tool is its ability to take various inputlanguages, transform and optimize the design, and finally write outthe result in the same languages and the appropriate lower-levelformats. Such a tool architecture worked extremely well for logicsynthesis and the same will be true for system synthesis. Adoptionrates within the design methodology will be dependent upon thetransformations and not on any proprietary language lock.
Figure 6: The goal of system synthesis is to takehigh-level design specifications and create RTL designrepresentations from system-level (behavioral) specifications.
Methodology: System-Level Modeling
This is the creation of the executable specification. Forexample, the system-level tools for SDL are already mature and usedextensively in the telecommunications market segment for softwareand system specification. Systems described in SDL consist of manyprocesses, running simultaneously, which communicate with eachother via signals. An extended finite state machine describes eachprocess. The state machines are labeled “extended” since variablesand timers can also be defined in processes. SDL has a rich grammarthat describes behavior and is unambiguous. Tools are available forsimulating SDL systems and for validating formal characteristicssuch as deadlock avoidance.
Figure 7: The design flow for system design automation.The goal of system design is to go from a functional specificationto desired hardware and software. This design flow is comprised ofvarious modeling, analysis, synthesis, partitioning, and HW/SWtargeting tasks.
The stages of the architecture exploration process are explainedin the rest of this section.
Architecture generation involves taking the system specificationthrough to a hardware and software partitioned design. The keytechnologies are:
- Design Hierarchy Manipulation
Figure 8: Design Hierarchy Manipulation involvesfunctional decomposition and virtual processor allocation, or thesplitting and merging of concurrent functional units.
- Hardware and Software Partitioning
Assigning and checking functional units against either a hardwareor software implementation. For example, if a unit is to beimplemented in hardware, does it contain any floating-pointarithmetic? If so, is there a mapping to silicon IP to handle thisoperation? If not, then is hardware synthesis possible withoutfurther manual refinement?
- Communication Synthesis
This task is the mapping of the abstract communication channelsonto realizable protocols. Protocols can vary from simplehandshakes, FIFO, and shared memory to standard bus mappings. Thesynthesis involves both software and hardware generation to realizethe protocols.
For hardware, traditional behavioral synthesis will not work due tothe restrictive input coding style. To support a much more flexiblesubset of the input language, especially for good quality hardwareand software, you need an alternative scheduling based on controlpaths rather than data paths. Such scheduling removes the need forallocation and datapath optimization, which are in the domain oftraditional RTL logic synthesizers.
- Code Generation
Code generation to any of the supported output formats should beavailable after any stage of the system-synthesis process. Althoughthe route from RTL to final layout should be fully automated, it'sessential that human-understandable code be produced to allow forlast-minute changes and to provide multiple entry points into thedesign flow. A good design methodology should allow you tounderstand original design intent throughout the design flow. Thismethodology allows simulation and verification at any stage duringthe architecture-exploration process.
You will need to assess a generated architecture against systemperformance goals. The design flow as shown in Figure 9 separatesthe verification process from the performance-analysis phase. Thisassessment is similar to embedded static verification in logicsynthesis where a static-timing analysis gives sufficient feedbackto assess design performance without the need for detailedgate-level simulation after every synthesis.
Figure 9: Architecture generation and analysis checksyour generated architecture against the system-performance goals.These tasks verify that the final system will meet your targetspecifications.
During architecture generation, you need to assess the followingperformance metrics:
- Power consumption
- Bottlenecks and bus congestion
- Software run-time analysis
- Overall system response and throughput
- Memory utilization
- The frequency of bus contentions and re-tries
- Data latency
- Processor loading.
This step is the cycle-accurate simulation of the system usinginstruction-set simulators, processor models, and HDL simulators.In addition, SW/HW co-verfication is also the final verificationyou use to check that a generated architecture meets thespecifications of your cycle-accuracy specification. From thisco-verification, you can verify subsequent automated steps throughsoftware and hardware optimization. Several co-verificationsolutions are available in the marketplace.
Automated Design Flow
It is at the system level that products gain their vitaldifferentiation to win in the market. An automated design flowenables designers to quickly develop architectures within theframework of standard languages and tools. Such a flow offers thebest opportunity to deliver on-time product differentiation. Anautomated design flow relies on the enabling technology of systemsynthesis. The introduction of this design flow must complimentexisting design practices and automate manual tasks, notnecessarily creating a wholesale methodology change. Only when thetools prove they can deliver better results than current manualprocesses should they then trigger widespread adoption. A number ofcompanies are advocating such a methodology; few are able todeliver the critical enabling technology.
About the Author