ARM System-Architecture evolution

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 [0, 0] as this is a natural progression from RTL design and the modeling environment is one in which hardware designers in particular feel comfortable.
In this methodology, a system architect has a very good understanding of the partitioning of the design between hardware 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.

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 10-100 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  Demaphores 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 softwaredevelopers.
The speeds of up to 100 kHz which are obtainable at the CC level are usually adequate for low-levelsoftware development and can also be used for larger tasks such as operating system bring-up.

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 [0] – incorporates ARM’s Cycle-Callable Model  Technology together with the latest AMBA AHB Cycle-Level
Interface (AHBCLI) [0] 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.
Transfers between the ARM core model and the AHB bus fabric modeled according to the AHB CLI 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 toRTL-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 [0], 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. 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.

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. 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.

Share on Google Plus

About Unknown

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.