ARM System-Level Modeling. Platform constructed from welltested

Transcription

1 ARM System-Level Modeling Jon Connell Version 1.0, June 25, 2003 Abstract 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, preverified 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: Unit Testing Integration Testing System Validation System Modeling & Software Development Platform Methodology Platform constructed from welltested Star IP Bus Functional Models are used to demonstrate that the platform RTL is wired up correctly Coverification with processor models and RTL runs real software for firmware validation SystemC models of the platform execute at high-speed with transaction accuracy to post and test application software Extension possibilities Standard interfaces such as AMBA and uitron ensure extensions work with platform Additional IP can be added to the platform RTL Additional hardware IP can be added to the RTL and new drivers validated Additional models can be added and ported to the OS for OS porting and software development 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 Copyright ARM Ltd All Rights Reserved. Page 1 of 8

2 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 SystemC [1], 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 [2]. The different levels of abstraction are depicted in the figure below: UML, SDL, MatLab Algorithmic Level (AL) Foundation: Function Function-calls Functional Programmer s View (PV) Foundation: Memory Map Bus generic Architectural SystemC Programmer s View + Timing (PVT) Foundation: Timed Protocol Bus architecture Timing approx. Cycle Callable (CC) Foundation: Clock Edge Word transfers Cycle-accurate VHDL, Verilog RT Level (RT) Foundation: Implementation Signal/Bit Cycle-accurate 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 MHz 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) Copyright ARM Ltd All Rights Reserved. Page 2 of 8

3 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 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. Architecture evolution For a system in which the architecture is well know, but for which implementation details such as the performance of different bus topologies are not well understood, an approach such as that depicted below applies. There has been much industry focus in this area [3, 4] as this is a natural progression from RTL design and the modeling environment is one in which hardware designers in particular feel comfortable. Software Implementation Micro-architectural Design Cycle Level (CC) Hardware Implementation System Verification RT Level (RT) Physical Design In this methodology, a system architect has a very good understanding of the partitioning of the design betweenhardware and software and is able to begin investigation into the performance of the system at the CC level of abstraction. Algorithmic design tools may or may not be used to capture the specification in a formal manner and this often. However, since AL is by definition an architecturally uncommitted description of a system and therefore outside the scope of a discussion of system-level design with IP we will not be describing the use of such algorithmic design tools in this paper. Copyright ARM Ltd All Rights Reserved. Page 3 of 8

4 Micro-architectural design Modeling a system at the CC level, allows designers to model the detail of a micro-architecture in a more efficient manner by abstracting signal-level detail into individual transactions. Speeds of khz for a complete system simulation are readily achievable using the abstraction technique in a suitable modeling language such as SystemC. CC provides a cycle-by-cycle mapping from one bus transfer cycle to its representation in a complete bus protocol. Speed increases are achieved by a combination of high-value IP models written to simulate efficiently in such environments and the reduction of a number of signal events in a protocol-cycle to a single-cycle operation. The communications fabric is modeled by three components: a hierarchical channel model that manages state of component connectivity, an arbiter that receives requests and allocates the shared channel based upon the priority of the requester (master), and a decoder that resolves addressing into specific block connections (transfers from/to). The arbiter and decoder, though distributed in hardware, are expected to be modeled through use of monolithic SystemC blocks (single interface to each). Masters in such a system might be processor models or memory controllers, whilst slaves might be peripherals such as a UART. Masters are clocked models that create data structures representing bus transactions; masters pass these structures to the bus fabric. Slaves are clocked models that are invoked by the bus fabric and are given the bus transaction data structures to operate upon. A critical part of this methodology is the ability to migrate to RTL design and retain a verification infrastructure for the complete system. The introduction of RTL models is achieved using adapters to the CC interfaces of the SystemC models. Since there is a known mapping between AHB transactions in the SystemC world and the signals of a physical AHB, such adapters can be generic and guarantee the correct operation of the device. Software implementation A principal advantage of creating the micro-architectural design is the ability to us this as a prototype for firmware and middleware development. Typically this is the realm of instruction-set simulation (ISS), but complex devices that have timing critical interactions between hardware and software are poorly captured using ISS technology. Whilst modern ISSs typically include simple infrastructure for modeling of peripheral devices, they operate at the PV level of abstraction and therefore do not include true systemlevel information. One alternative to using ISS technology is prototyping of systems using FPGAs and FPGA-based multiboard prototyping tools is becoming increasingly popular as the complexity of hardware and software increase. These tools allow high-speed execution of software on real hardware, often allowing the interfacing of physical devices such as networks that provide true physical data. Using hardware debug and trace tools, software developers can gain excellent debug visibility into the software running on a target. Debug tools need to be aware of the underlying OS and provide information about OS-level primitives such as threads and semaphores if they are to provide sufficient debug infrastructure for an application software developer looking to debug complex OS-dependent software. However, the fundamental drawbacks of such prototyping systems are that they are expensive to deploy to a large number of software developers and arrive late in the development cycle when the hardware implementation is largely fixed. Modeling a system at the CC level is then a good compromise to address the drawbacks of traditional software development tools in the context of system-level design: The tools used to explore and design the micro-architecture of the hardware system provide an early prototype on which to execute complete system software. As a software model, the virtual prototype can be deployed to a large number of software developers. The speeds of up to 100 khz which are obtainable at the CC level are usually adequate for low-level software development and can also be used for larger tasks such as operating system bring-up. Copyright ARM Ltd All Rights Reserved. Page 4 of 8

5 IP models To deliver speeds of up to 100 khz for a full system simulation, high quality IP models are a vital ingredient. ARM has over a decade of experience in the area of cycle-accurate modeling and has been delivering cycle-based models into EDA products over five years. With the industry adoption of SystemC as the de facto standard for system-level modeling, it is now possible for IP providers to deliver standard models to designers to use with multiple EDA tools. This enables designers to combine best-in-class models with best-in-class tools. The ARM Micro-architectural SystemC model shown below a part of ARM s RealView Model Library [5] incorporates ARM s Cycle-Callable Model technology together with the latest AMBA AHB Cycle- Level Interface (AHBCLI) [6] and ARM s RealView Debugger. The AHBCLI allows the user to model complete AHB systems at the CC level whilst ensuring a high degree of fidelity to the AHB protocol. Clock RealView Debugger ARM Core Model Coprocessor Interface Cache MMU/PU Simulation and Debug Services VFP Tracer ARM Micro-architectural SystemC Model AHBCLI Bus Fabric AHB Master AMBA APB Subsystem Transfers between the ARM core model and the AHB bus fabric modeled according to the AHBCLI are fully cycle-accurate and both the bus fabric and the ARM core are clocked by a common system clock. The mapping from AHB CLI transfers to pins permits direct connection of RTL-SC (RTL in SystemC) models or co-simulation with Hardware Description Language (HDL) models or gate level models. This approach provides for: Validation of SystemC models cycle-by-cycle against the RTL, which is necessary for a top-down design methodology. This also supports bottom-up system-creation supported by automated HDL- >SystemC model extraction. Ability to mix various levels of models. For instance to refine a system level model of a new block to RTL-SC while maintaining high-level and fast models of the remainder of the system. This is critical in unit-substitution validation methods. Familiarity for existing ARM and AMBA users as the interface resolution is easily map-able to real HW implementation. Architecture exploration and development For a system in which the architecture is not known, there needs to be an environment in which architecture exploration can occur. This is a relatively new area for the industry [7], though it is clear already that SystemC is by far the best candidate for modeling systems at high levels of abstraction. The focus of the system exploration in SystemC is for the systems architect to understand the function of the system, the potential hardware/software partitions and what the performance implications of various architectural decisions are. Copyright ARM Ltd All Rights Reserved. Page 5 of 8

6 Algorithmic design tools are a much more fundamental part of this type of design exploration and will be used to develop algorithms and define the function of a new system or product. However, since AL is by definition an architecturally uncommitted description of a system and therefore outside the scope of a discussion of system-level design with IP we will not be describing the use of such algorithmic design tools in this paper. Consider then the design flow depicted below in which a system architect partitions a system s function into hardware and software components. In this approach, we have also excluded performance modeling of operating systems and software and have chosen instead to enter directly into software implementation. Software modeling is still in its infancy, though the focus of SystemC 3.0 is to include support for abstract software and OS modeling and as such interest will grow as standard interfaces and tools become available. System Function Algorithmic Level (AL) Software Implementation Hardware Architecture Model Programmer s View (PV) Virtual System Prototype System Performance Model Programmer s View + Timing (PVT) Hardware Implementation System Verification RT Level (RT) Physical Design Virtual system prototype The first deliverable of the design process depicted above is a virtual system prototype which completely models the function of the system and provides a programmer s view of the hardware to a software application. To achieve this, the entire hardware function of the device is modeled at the PV level. A critical element of block design is interface design how the components in the system being will communicate with other components in a given system. In the context of PV system modeling, a system is merely a collection of IP components and the only concern of the designer at this level of abstraction is what is being communicated and not when (though obviously ordering is important). In order to ensure that only the function of the system and not timing critical data is included in this virtual prototype, knowledge about the timing response of individual devices in the system should not be replied upon by the software programmer. Copyright ARM Ltd All Rights Reserved. Page 6 of 8

7 A Master module may make itself sensitive to the system clock, or indeed any other event in the system, but the designer should be aware that no notion of time will be accurately maintained. Therefore, having triggered a process, it is assumed that a significant chunk of work will be performed. The PV level provides an indication of the designer s desired granularity size in approximate number of cycles. A PV model should do its best to adhere to this granularity, without suffering any significant cost in calculating the number of cycles that have passed. For slaves, the expectation is that the transport function will return immediately, with the structure containing any returned data. It is not expected that slaves would make themselves sensitive to any events, or indeed generate any events. Since the hardware architecture is functionally complete in the context of the system, it may be used together with a model of the system s environment (such as a virtual display panel) to create a system prototype for software development. The software implementation can then be verified in a full system context and can also proceed in parallel to the benchmarking and implementation activity in the hardware space. The confidence of the architect that software and hardware are coming together to meet their functional requirements is thus greatly increased. System performance model In addition to verifying the function of a new architecture, an architect will certainly need to understand what the performance of the architecture is likely to be when implemented. A novel, new technique is beginning to emerge whereby a functional model is annotated with timing information to provide performance data for individual components in the system. When this information is collated by allowing the individual timing models to communicate, an overall system performance may be determined. The PVT methodology used to develop the system performance model exploits the fact that timing models are an extension of the functional prototype modeled using PV primitives. The timing does not therefore interfere with the PV model or its functionality. Such a system performance model is functionally correct by construction. PVT therefore adds nothing about what information is being communicated, it only provides additional information about when that data is communicated. A concrete example of the difference between PV and PVT might be to look at AMBA protocols. The PV interface abstraction views AHB-Lite as comprises of address, data, protection information, burst length. The timing protocol of AHB-Lite is described by the HREADY signal. In the AXI protocol, however, although the programmer s view of the system is unchanged, the timing of the interface is more complex and introduces additional timing to describe the protocol (AREADY, AVALID, RREADY, RVALID, WREADY, WVALID, BREADY, BVALID). More complex timing modules may have elements which are sensitive to clock edges or other events in the system. The means by which these timing and their functional counterparts will communicate is totally left to the IP implementer for each component. It is likely that this communication will inform the timing module of the transports that have taken place over the component s interfaces, and the important changes in internal state associated with them. This level of modeling will then provide a mechanism by which timing modules themselves can synchronize with each other, and the system clock. This is similar to the inputs and outputs of a cycle callable model, with the exception that no data is passed. In a CC model, data is passed at a given time (this is discussed in more detail below). In a PVT model, the data has already been passed by the PV model, and it is the time at which the data is passed that is left to the timing modules inputs and outputs. It is expected that the modeling paradigm for the timing part of PVT is identical to the CC level. IP models As with CC models, high quality IP models are also required to ensure that the performance targets of PV and PVT are obtained. The point-to-point transport protocol of the PV level of abstraction together with high-speed models currently delivers speeds of around 1 MHz. This is typically sufficient for most software development, though applications software often needs much higher speeds. New classes of model are required for this, though they have yet to appear in an industry-accepted SystemC environment. Copyright ARM Ltd All Rights Reserved. Page 7 of 8

8 The ARM Architectural SystemC model shown below in an example system a part of ARM s RealView Model Library incorporates ARM s ISS technology with efficient point-to-point interfaces. Standardization of interface definitions for PV is currently in progress within the TLM Working Group of OSCI. APB Subsystem DMA ARM Core Model Coprocessor Interface Cache MMU/PU VFP Tracer APB AHB Simulation and Debug Services Memory Interface Memory RealView Debugger ARM Architectural SystemC Model Transfers between models in the system are point-to-point. The memory interface of the ARM core model will transfer transactions via a SystemC port to an interface on the target bus system directly. When a transaction is sent from the DMA controller to via a single transport function memory, the controller will block until the memory returns the data. More information More information on ARM and the RealView Model Library can be found on the ARM website, and from local ARM offices. References 1. Thorsten Grötker, Stan Liao, Grant Martin and Stuart Swan, System Design with SystemC, Kluwer Academic Publishers Group, ISBN: Open SystemC Initiative, 3. Wander O. Cesário, et al. Multiprocessor SoC Platforms: A Component-Based Approach, IEEE Design & Test of Computers, pp , Vol. 19, No. 6, Jon Connell, Capturing design intent and evaluating performance with SystemC, Embedded Systems West Proceedings, Class 201, ARM, RealView Model Library, 6. ARM, AMBA AHB Cycle-Level Interface Specification, 7. Filip Thoen Prototyping Technologies for Early Embedded Software Development, Information Quarterly, pp , Vol. 1, No. 1, Copyright ARM Ltd All Rights Reserved. Page 8 of 8