Once the design team has decided how to partition the system into hardware and software, the two resulting teams move in separate directions to accomplish their tasks. The hardware team members take the system specification and, based on their choice of processor(s), begin to implement the hardware for the rest of the design. This part of the design is typically entered in VHDL or Verilog, at either the behavioral or RT level. Then, it is synthesized and verified with event- and/or cycle-based HDL simulators.
The latter part of the design cycle, hardware verification, has been complicated by the advent of million-plus-gate designs. In these complex designs, the verification phase can take more than 50% of the total design time. As a result, designers may now spend more time writing HDL code to test their design than it took to create the design itself.
Software designers also start by working from the system specification. Their design environment, however, begins from a processor-centric view. They typically use an instruction-set simulator (ISS) for the target processor to test their software drivers and applications.
However, software designers do not have an accurate model for anything other than the target processor. So, when they need to test software that interacts with hardware that is not part of the processor (for example, peripherals, hard drives, etc.), they create stub programs in C that emulate a hardware response to the software. While this provides fast performance, it's at the expense of accuracy. The real hardware often responds very differently than the stub code for a particular device. Unfortunately, this inaccuracy usually does not show up until integration time, and can result in either a significant rewrite of software or even worse—a respin of the hardware or ASIC if the software cannot be fixed in the target system.
Mutual Needs
This division between hardware and software designers usually means that both sides have something that the other side wants. The software team has a C test bench that will accurately test the processor and the surrounding system. The hardware team has a virtual implementation of hardware that the software people can use in the place of a stub code or physical prototype for verifying their software drivers and applications. Tools are available today that bridge the gap between the two environments.
Synopsys' Eagle Technology Group, for instance, has developed a set of tools that enables the software and hardware design teams to begin integration of the hardware and software before a physical prototype is available. This allows the software development process to become a parallel task to hardware development.
Siemens Public Communication Networks used this methodology to verify a 5.5-million-gate telecommunications switch system with 24 RISC cores running the software. As part of its methodology, Siemens incorporated the interface between the Eagle tools and Synopsys' Cyclone VHDL cycle-based simulator.
With HW/SW coverification tools, hardware designers can take advantage of the code that software designers develop for verification so they can debug the hardware with real software, and not just an HDL test bench that imitates the actual software.
Software designers benefit because they can now develop software drivers and applications while testing them against the HDL description of the hardware. This process is more accurate than software stub programs developed by hand. All of this can be done without a physical prototype, allowing integration to begin much earlier in the design cycle. If a problem is found, changes can still be made in either the hardware or software because the hardware design is not yet set in silicon.
To bridge the gap between the hardware and software tools, coverification tools provide a model of the processor that coexists in both the hardware and software environments. Because phases of the design require different trade-offs between accuracy and performance, three different models exist.
The first type, a Link-model, provides the fastest possible coverification speed while still allowing full-visibility into the software execution process. The ISS-model, as its name implies, uses the software developers' ISS model and marries it to a bus-functional model (BFM) in the HDL code. This solution enables both software and hardware teams to debug the complete design from either perspective.
The final type is a TAP-model, which uses the actual processor to execute the software. It provides unmatched accuracy in a coverification environment. With three models, the designer has the flexibility to choose which one to use at any point during the development/verification process, depending on the current task, whether it's ASIC verification, software development, or system integration.
A Competitive Advantage
As the marketplace demands for smaller, faster, and cheaper systems escalate, the need for highly integrated systems and systems-on-chips will soar. Without concurrent HW/SW design and verification, tight time-to-market windows will be missed. Project costs will also dramatically increase due to lengthening design cycles, misunderstood specifications, and expensive ASIC respins. Those willing to invest in HW/SW codesign tools and methodologies will have a significant competitive advantage, often seeing their products on the market while the competition is still waiting for the prototype.
Once the design team has decided how to partition the system into hardware and software, the two resulting teams move in separate directions to accomplish their tasks. The hardware team members take the system specification and, based on their choice of processor(s), begin to implement the hardware for the rest of the design. This part of the design is typically entered in VHDL or Verilog, at either the behavioral or RT level. Then, it is synthesized and verified with event- and/or cycle-based HDL simulators.
The latter part of the design cycle, hardware verification, has been complicated by the advent of million-plus-gate designs. In these complex designs, the verification phase can take more than 50% of the total design time. As a result, designers may now spend more time writing HDL code to test their design than it took to create the design itself.
Software designers also start by working from the system specification. Their design environment, however, begins from a processor-centric view. They typically use an instruction-set simulator (ISS) for the target processor to test their software drivers and applications.
However, software designers do not have an accurate model for anything other than the target processor. So, when they need to test software that interacts with hardware that is not part of the processor (for example, peripherals, hard drives, etc.), they create stub programs in C that emulate a hardware response to the software. While this provides fast performance, it's at the expense of accuracy. The real hardware often responds very differently than the stub code for a particular device. Unfortunately, this inaccuracy usually does not show up until integration time, and can result in either a significant rewrite of software or even worse—a respin of the hardware or ASIC if the software cannot be fixed in the target system.
Mutual Needs
This division between hardware and software designers usually means that both sides have something that the other side wants. The software team has a C test bench that will accurately test the processor and the surrounding system. The hardware team has a virtual implementation of hardware that the software people can use in the place of a stub code or physical prototype for verifying their software drivers and applications. Tools are available today that bridge the gap between the two environments.
Synopsys' Eagle Technology Group, for instance, has developed a set of tools that enables the software and hardware design teams to begin integration of the hardware and software before a physical prototype is available. This allows the software development process to become a parallel task to hardware development.
Siemens Public Communication Networks used this methodology to verify a 5.5-million-gate telecommunications switch system with 24 RISC cores running the software. As part of its methodology, Siemens incorporated the interface between the Eagle tools and Synopsys' Cyclone VHDL cycle-based simulator.
With HW/SW coverification tools, hardware designers can take advantage of the code that software designers develop for verification so they can debug the hardware with real software, and not just an HDL test bench that imitates the actual software.
Software designers benefit because they can now develop software drivers and applications while testing them against the HDL description of the hardware. This process is more accurate than software stub programs developed by hand. All of this can be done without a physical prototype, allowing integration to begin much earlier in the design cycle. If a problem is found, changes can still be made in either the hardware or software because the hardware design is not yet set in silicon.
To bridge the gap between the hardware and software tools, coverification tools provide a model of the processor that coexists in both the hardware and software environments. Because phases of the design require different trade-offs between accuracy and performance, three different models exist.
The first type, a Link-model, provides the fastest possible coverification speed while still allowing full-visibility into the software execution process. The ISS-model, as its name implies, uses the software developers' ISS model and marries it to a bus-functional model (BFM) in the HDL code. This solution enables both software and hardware teams to debug the complete design from either perspective.
The final type is a TAP-model, which uses the actual processor to execute the software. It provides unmatched accuracy in a coverification environment. With three models, the designer has the flexibility to choose which one to use at any point during the development/verification process, depending on the current task, whether it's ASIC verification, software development, or system integration.
A Competitive Advantage
As the marketplace demands for smaller, faster, and cheaper systems escalate, the need for highly integrated systems and systems-on-chips will soar. Without concurrent HW/SW design and verification, tight time-to-market windows will be missed. Project costs will also dramatically increase due to lengthening design cycles, misunderstood specifications, and expensive ASIC respins. Those willing to invest in HW/SW codesign tools and methodologies will have a significant competitive advantage, often seeing their products on the market while the competition is still waiting for the prototype.