Embedded hardware and software design tools often work under the assumption that designers will have full visibility into the implementation of IP they are using and that this IP is always complete and available when they begin their design. We will describe here how models are providing a solution to these problems, and additionally how models provide added value such as delivering early virtual prototypes for software development and greater flexibility to include the IP into design tools.
System level design and modeling
IP companies have heralded a new age in platform-based design for a number of years ever since semiconductor integration capacity reached the point where entire systems could theoretically be integrated into a single die. So why haven’t we seen a huge explosion in platform-based design? The key is the scope of the platform: only now are platforms being defined which include a wide assortment of elements from System-Level Design (SLD): the RTL hardware definition, bus architecture, power management strategy, device drivers, OS ports, and application software. To be successful, however, a platform will need more than this; an essential element for enabling differentiation will prove to be an advanced systems modeling and verification environment. Developers require a variety of views of the entire platform from RTL, system models, software development models, and real hardware development boards. Each view of the platform reflects the same system architecture, and designers can use test software in any of the higher-level views, providing a high degree of confidence in the design prior to tape out. This provides a valuable environment in which to investigate system bandwidth and performance requirements. System views must be extendible, allowing designers to exploit the advantages of a Well supported, pre-verified base platform of hardware and software IP, whilst differentiating their own application with their own IP. Specifically, each design task has specific requirements on methodologies and IP customers will want to make extensions to the IP during each stage of their own design. For example:
At the system-level, availability of software becomes critical and it is no longer reasonable for the software team to wait for a prototype system. Coverification can move the integraTion schedule forward to the point where RTL is available, but this still delays the software integration to a point where much of the hardware design is complete. System and software designers would still be lacking a common environment. Consider instead a design flow where the system is first specified using System C [0], then partitioned into hardware and software blocks and handed to the respective teams. This executable specification is a key enabler for both teams. The software engineer not only has a platform for the development of his software, he has a C++ based simulation environment he can easily utilize.
System-Level abstraction
In defining any new system, the levels of confidence in the implementation between a formal specification and the final silicon and software image, are often described using different levels of abstraction. We define five levels of system abstraction to cover different representations of a complete system, increasing in detail from a functional description of a system through to a description from which hardware can be produced. The set of system-level abstractions that we use share many similarities with those described in a technical submission to the OSCI [0]. The different levels of abstraction are depicted in the figure below:
The RT level of abstraction for the platform design is depicted in green, and constitutes the hardware implementation level. Languages used at this level are typically VHDL and Verilog. Above the RT level, the (loosely termed) transaction levels’ of soft-prototyping are shown. At these levels of abstraction, we envisage that model extensibility will be provided through implementation of interfaces into a common open standard language, primarily SystemC. The platform models themselves may be provided in a separate modeling-specific format (not SystemC) that is more efficient for internal-core simulation, but
which can be readily interfaced to the SystemC simulation kernel. In the abstract system-modeling environment, three abstractions must be supported:
Programmer’s View (PV) –
a bit true behavior of the system as seen by the programmer. In some cases, this behavior can not be absolute (it depends upon subtle timings that the program may not rely on). It is then the IP vendor’s choice whether to provide pessimistic, optimistic, random, typical or
a combination of models in these circumstances. Communication is point-to-point and based on a common, highly efficient transport mechanism. This modeling abstraction will execute in the 10- 100MHz range, sufficient for full system emulation and software development.
Programmer’s View with Timing –
a timing approximate extension of the PV model of the system in which a datum or block-data request is completed (returned data or time-out/error) in single transactions, and time is indicated as ‘time-passed’ rather than events-per-clock-tick. In all other ways, the model is identical to the PV. Communication between timing models is at a Cycle-Callable (CC) level of abstraction. This modeling abstraction will execute in the 1-5 MHz range to provide good approximations of system performance for benchmarking and design exploration.
Cycle-Callable (CC) –
a cycle accurate translation from register-transfer level to transfer-level transactions. The simulation speed of the communication is gained through the efficient handling of abstract types and assembling of atomic (non-interruptible) action sequences into address/data transfers. This abstraction uses clock-based execution semantics, and can be is directly mapped into RT signals. Data is transferred by “polling”, not by reactive function calls. This modeling abstraction will execute in the 10-100 kHz range, sufficient for system validation.
Finally, the Algorithmic Level (AL) is a functional representation of the system which has yet to be committed to a particular architecture. A number of Languages are used at this level of abstraction often dependent upon the application domain, for example MatLab, UML, SDL, etc
System-level modeling methodologies
No one true methodology will apply to all systems, though the levels of abstraction presented do hold true for the different possible representations of a system. At which level(s) of abstraction a system will be represented will depend on greatly on the level of confidence a system architect has in their architecture
and whether they need to explore new architectural possibilities for a particular algorithm.
Next:ARM System_ Architecture evolution
0 comments:
Post a Comment
Thanks for your Valuable comment