Current all-in-one hardware/software development tools tend to work well at the beginning of the project during architectural modeling, but then fizzle out until the real silicon arrives, and joint bringup and test can occur. It would be far better to get good interworking during the entire development process by providing open, flexible tools, since most SoC teams prefer to use "best-in-class" tools from multiple suppliers instead of a one-vendor flow.

This scenario was the driving force behind the development of Tenison EDA's VTOC™, a Verilog/VHDL-to-C translator optimized for the hardware-software co-design issues facing SoC design teams. The tool creates a bit- and cycle-accurate model in C, C++, or SystemC from the RTL HDL source, enabling design teams to perform myriad tasks to improve the speed and quality of any SoC design.

VTOC allows a software group to work closely with an emerging hardware design, with minimal impact on the hardware group delivering that hardware. It does this by allowing a software group to access hardware implementations expressed in familiar HDLs, and import them into a C or C++ test-, system-, and driver-development environment. This overcomes many of the traditional hurdles to the deployment of co-development projects in software engineering groups. The efforts of software and hardware groups remain closely integrated, not only during architectural design, but afterwards during implementation and test. The result is that the software group can develop their half of the project a great deal earlier, speeding up the whole use/improvement cycle for the hardware design.

The Software-Modeling Continuity Gap
Back to top

Figure 1 - Delivering a real SoC requires solutions in many problem areas, but the delivery of working, effective software is easily forgotten, or is left until too late.

A modern SoC development overcomes many technological hurdles by using a multi-disciplinary team. Very often, management attention is focused on tapeout and working silicon, but in practice a return on investment is only provided when both hardware and software are working effectively together in the field. This means that early software involvement, from the design and architecture phase all the way through to final field trial, can lead to a real reduction in time-to-market.

The diagram in Figure 1 above summarizes this situation. Silicon verification, layout, timing closure, and working silicon prototypes are huge challenges, but too often they are viewed by the core development team as the end game rather than as simply an intermediate step.

Software modeling and prototyping are essential in order to overcome this problem. Without software modeling, delays in tapeout and prototype availability can lead directly to delays in the product. With good software modeling, the development of software and hardware can happen in parallel so that the software is ready when the prototypes arrive.

In addition to this, software modeling is important for performance design. Without it, the resulting silicon could be too slow (in terms of delivered throughput) or too fast (i.e., more expensive than it needs to be). In general, such decisions should be made during the architectural phase before any RTL coding is done. In practical situations it may not be possible to be completely accurate in the architectural phase, for example, if the architectural modeling is not cycle-accurate or involves other forms of performance estimation. In such cases, the actual delivered throughput of the system might only be determined when silicon prototypes are available.

Software Is Part of the SoC
Back to top

Figure 2 - A system-modeling strategy should be used that permits continuous involvement of the software team in the overall SoC project.

To overcome this gap in software activity between architectural work and driver work, a software-modeling strategy must be employed that allows software activity to continue from architectural work, allowing system development work to occur before the final hardware is available. The decision on the exact strategy may depend on the detailed requirements of the SoC itself, or on other aspects of the SoC project.

We believe that for many systems the best strategy for this system modeling is to do the work in C, C++, or SystemC, drawing on architectural models and also on RTL-derived models. The advantages of this approach are:

• since the ultimate output of this work is driver software, the activity is likely to be used by the software team rather than the hardware team;

• using C, C++, or SystemC means that they are already more familiar with the tools, languages, and concepts involved;

• the freedom to use RTL-derived models can include third-party IP or legacy IP, or other elements of the system that for any reason have not been represented within the architectural models;

• system test by software engineers requires good overall system performance, at the expense of HDL accuracy if necessary.

This final requirement can push the project in the direction of hardware emulation, or FPGA prototypes. These provide the ultimate in performance, but carry a high cost in terms of flexibility, early availability, debug visibility, and dollar cost per seat.

The founders of Tenison have spent many years delivering complex, working SoCs in a commercial setting. By involving software engineers in the architecture phase, and by helping them to do software-driver work early, we have produced successful hardware/software products. We believe that this sort of challenge will face increasing numbers of silicon development teams over the next decade as software and hardware for new, large-scale devices are increasingly seen as a single deliverable.