Open Access
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
ARM PrimeXsysTM Wireless Platform
Detailed White Paper
Written by
Ian Thornton
1
Requirements of Next Generation Wireless Products
Today’s 2G-phone is only required to handle voice calls and send simple text messages. The 2.5/3G
mobile phone of the future will not only be required to carry voice and text messages, but also to
provide many other applications and services. These application requirements will include:




Wireless Internet Device (WID) functionality with email, mobile Internet, M-commerce, utilizing
functions such as location services and secure data transfer;
PDA functionality with a consumer-OS (Symbian OS, Windows CE, Linux, etc.) and its associated
programs (PIDs, calculator and so on)
High performance functions such as audio player, videophone, mobile games console.
Other applications: Java™ apps, 3rd party software (pre-loaded or downloaded), even user-written
applications.
A step change in functionality is therefore required to meet these new requirements while at the same
time enabling accelerated time-to-market and low cost.
2
Next Generation SoCs for Wireless Products
With this step change in functionality, semiconductor manufacturers, OEMs and other organizations
tackling complex systems integration are facing significant new challenges. It is unlikely that any
single organization will be able to originate all of the IP required to create the SoC.
In addition, implementing the hardware part of the SoC alone is not sufficient – software must be
considered too. These increasingly complex SoCs must be integrated with complex operating systems
to enable high functionality application software to be run.
2.1
Integrating Hardware IP
Complex systems are differentiated with advanced (or 'star') IP. Typical examples include blocks that
accelerate high performance functions, such as video and graphics, and advanced standards-based IP
such as USB and Bluetooth. Over time, today’s star IP will eventually become commodity parts. This
has already happened with blocks such as the UART and the real-time clock, which are commonly
available in standard IP libraries. These commodity blocks do not differentiate complex systems.
Companies will achieve competitive advantage by integrating the best available IP for the application.
They need to focus on developing their own star IP, but consider buying-in any IP that they do not
already have in-house, or do not have the resource or expertise to develop.
Therefore, SoC designs will inevitably contain hardware IP from multiple sources. This means that the
system integration and validation processes must be capable of managing the difficult task of IP
integration from diverse sources. Procured IP may have been developed in different organizations with
different tools, methodologies and design styles. Integration of this IP can be more challenging when
the original developer is not within the same company or available ‘down the corridor’.
08/03/16
Page: 1 of 21
Open Access
2.2
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Supplying Software with the Hardware
Often, the porting of the operating system and application software commences only with the
availability of first silicon. This serial development process has two consequences:


There is a danger that the 'problem' of OS porting can be deferred until the end of the value chain,
ultimately becoming the responsibility of the OEM.
Because OS-porting is very time-consuming there is a significant time-to-market delay with this
serial development process.
Companies that are able to offer the OS and application software coincident with the silicon create a
significant advantage in meeting time-to-market goals and providing a higher quality system
implementation.
Porting and supporting operating systems on a new platform requires significant expert resource. OS
vendors want to dedicate their resources to improving the functionality and quality of their product.
They will not provide resources for porting their operating systems to many different platforms.
With the growing complexity of single-chip systems, the expectation from OEMs is that ‘SoC
development’ now means tackling both hardware and software. Supplying a chip without at least
integrated operating systems will result in a product that is not competitive in terms of functionality or
time-to-market.
3
The Response of the ARM Partnership
Competitive advantage can be created when companies within a supply chain work in partnership to
address specific industry issues. In the past, ARM and the partnership has achieved this by establishing
new standards, for example:



Instruction Set Architecture - ARM has just announced v6 of the ISA;
MMUs - Enabling the current set of consumer OS's (Windows CE, Symbian OS, etc.)
AMBA™ bus - to easily connect up peripherals to a common on-chip bus standard
All of these solutions have become standards within the partnership as a result of the close cooperation
and development between ARM and its partners.
For 2.5/3G phones and PDAs, some companies are already developing their own solutions to meet the
new wireless functionality requirements. A proliferation of incompatible wireless platforms is
undesirable for the industry as a whole, since the third-party support necessary to make a complex
platform solution a success is much more difficult to achieve. Many OEMs prefer to adopt solutions
that offer choice of silicon implementation, have a clear future roadmap and demonstrate market
momentum.
Working in partnership, ARM has identified the minimum set of building blocks that is required to
develop a platform with the basic set of requirements to:




Provide the non-differentiating functionality, pre-integrated and pre-validated;
Run an operating system;
Run application software;
Allow partners to focus on differentiating the final solution where it actually makes a difference.
The platform will also need to solve the integration of third-party IP onto the base platform.
08/03/16
Page: 2 of 21
Open Access
4
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Overview Of the ARM PrimeXsys Wireless Platform
The PrimeXsys Wireless Platform has three key components:
Standard SoC Platform Kernel
Traditionally, ARM has been known for licensing standard RISC cores. ARM is now moving beyond
licensing just the core, to defining and licensing a standard SoC platform. The hardware element of the
SoC platform is a set of pre-designed and pre-verified building blocks, which will support an
appropriate OS and selected application software.
Tool Support and Validation Methodology
ARM partners will be able to differentiate their designs by building on the PWP platform where
additional functionality or superior performance can be achieved. ARM will be providing the best
possible tool support and state of the art validation methodology. Extendable testbenches will be
supplied that will enable integration, system and software validation. These testbenches are also
flexible enough to be used in a variety of implementation flow/tools environment.
OS-Ports
All 2.5/3G mobile phones will have an OS-port on which will run all the application software. This is
a crucial part of the mobile device. ARM will ensure that ports of all the leading operating systems are
available as part of the PWP platform. The OS will be pre-ported so that it works on the customer’s
silicon “out-of-the-box”.
There are other significant benefits that ARM bring to the PWP platform:
ARM’s Extending IP
For many years, ARM has been successfully providing PrimeCell™ Peripherals to silicon companies
for SoC development. These PrimeCell Peripherals will be provided as peripherals ready to be added
onto the PWP platform.
ARM also provides standards-based application software such as MP3 and AAC codecs. These will be
provided working with the OS-ports on the PWP platform.
3rd Party Extending IP
With such a diverse range of functionality having to be supported on a 2.5/3G mobile phone, and with
so many new start-ups writing innovative software, it is unlikely that any one silicon manufacturer will
be able to develop all the IP themselves. ARM will therefore:
 Work with leading third-party IP providers to ensure that their software and hardware is optimised
for use on the PWP platform;
 Provide a developers’ program to allow easy access to some of the PWP platform deliverables to
enable the third parties to port their IP to the PWP platform.
Future
ARM is not only improving and extending the PWP platform to better meet the needs of developers,
but also working with partners, OEMs, OS and tool vendors, and IP developers to ensure a
convergence of effort around the PWP platform. This will result in more integrated hardware, software
and tools solutions and help reduce time to market even when developing complex devices.
The following sections examine each of these areas in more detail.
08/03/16
Page: 3 of 21
ARM PrimeXsys Wireless Platform
Detailed White Paper
Open Access
5
Revision 4.0
Standard SoC Platform
This is the PWP platform’s standard SoC Platform.
Trace Port
Analyser
SDRAM
Bank 0
SDRAM
Bank 2
SDRAM
Bank 1
SDRAM
Bank 3
ETM
MOVE
SRAM
Static
Memory
Interface
SDRAM
Controller
ARM926
CPU
ROM
Flash
LCD Display
Vectored
Interrupt
Control
Color
LCD
DMA
M
M
S
ARM I AHB
ARM D AHB
Application
Specific IP
LCD AHB
DMA 1 AHB (Periph)
DMA 2 AHB (Memory)
EXPANSION AHB
DMA APB
Core APB
WATCHDOG
AHB/
APB
TIMERS
AHB/
APB
SSP
DMA APB
Extensions
GPIO (x4)
GPIO
x4
SYSTEM
CONTROL
RTC
UART
SIM Card
Clk/Reset
Generator
32 GPIO
lines
32KHz
CLK
Xtal Osc
PLL
Xtal Osc
The Standard SoC Platform consists of an ARM926EJ-S core and selected peripheral components
integrated together by an AMBA™ Multi-layer AHB system interface with provision for expansion.
08/03/16
Page: 4 of 21
Open Access
5.1
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
ARM926EJ-S™ Core and Related Components
The ARM926EJ-S™ core combines the industry-leading performance and very low power of the ARM
Jazelle™ technology, with support for virtual memory addressing, which is required by many of the
leading operating systems. In addition, the ARM926EJ-S is a synthesizable core, which means it is
portable to any silicon manufacturing process with an associated cell library, ensuring that it is
compatible with the broadest range of present and future silicon processes.
The ARM926EJ-S core also incorporates independently configurable instruction and data caches and
instruction and data Tightly Coupled Memories (TCMs), allowing cache and TCM memory sizes to be
altered to suit specific applications, without the need to alter the CPU core.
The PWP platform also includes the MOVE™ co-processor as standard. The MOVE co-processor can
be used by video encoders for MPEG-4, WMV, etc. It performs multiple sum-of-absolute-difference
calculations in a single cycle. This function is heavily used in video encoders and it can reduce the
processing required by over 50%.
ARM recommends the use of ETM™ (Embedded Trace Macrocell) for debugging software on the
ARM core. The ETM monitors the ARM core buses and passes compressed information via the trace
port to the MultiTrace™ trace port analyzer. The analyzer is an external hardware device that stores
the information from the trace port, for example a logic analyzer or a low-cost collection unit. The
debug tools retrieve data from the analyzer, reconstruct an historical view of the processor's activity
including data accesses, as well as configuring the macrocell via the JTAG port. User-definable filters
allow users to limit the amount of information captured in search of a bug, reducing upload time from
the MultiTrace unit.
5.2
Peripheral Components
The area containing the peripheral components can be sub-divided into three zones: Core and DMA
APBs, System Bus Peripherals and the Rest of the ASIC. The PWP contains the basic functionality
required to get an OS to boot and several well-established peripherals that are unlikely to change
significantly in the future. The PWP also provides the OS with graphical and memory interfaces.
Displays and memory are very likely to change over the next few years. It is therefore expected that
some of these peripherals will be subject to change. The rest of the ASIC still leaves ARM’s partners
with significant opportunity for differentiation.
5.2.1 Core APB
The Core APB contains the PrimeCell Peripheral IP blocks that are needed for the basic functions of
the OS. These peripherals do not add any differentiation in the final system.
 Four Timers
 Watchdog
 Real Time Clock
 32-bits of GPIO (used for buttons, I2C, etc.)
 System Controller for power management
5.2.2 DMA APB
These peripherals can be accessed by the DMA controller for efficient data transfer. These are all
established standards and are required in any 2.5/3G phone or PDA.
 UART
 Synchronous Serial Port
 SIM card interface
08/03/16
Page: 5 of 21
Open Access
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
5.2.3 System Bus Peripherals
These higher-level PrimeCell Peripherals enable the operating system to support external memory
systems and a graphical output, as required by basic PDAs. As memory and LCD displays develop, the
system integrator can upgrade these peripherals as required, though this will increase the OS porting
cost as the device drivers will have to be modified and integrated.





Four Port SDRAM controller
Static Memory Interface (for Flash, SRAM, ROM etc)
LCD Controller
Two Master Port DMA Engine
Vectored Interrupt Controller
5.2.4 Rest-Of-The-ASIC
This is the complete system, for which some examples are shown in appendix A and appendix B. This
functionality is not included in the PWP platform, but is shown to illustrate how the PWP platform can
be expanded.
5.3
ARM926EJ-S Bus Interfaces
The ARM926EJ-S has separate bus interfaces for Instruction and Data. Bringing these two ports out to
the bus removes an unnecessary bottleneck, and improves the system performance.
Bringing these two ports out separately has a number of benefits in an AMBA Multi-Layer AHB
system. It allows simultaneous access for Instruction line-fetches, and Data operation, provided that
they are to different memories in the system. Even if both are trying to access the SDRAM controller
in the system, the extra information available to the SDRAM controller will allow it to do a better job
of hiding the access latency, improving the system performance.
08/03/16
Page: 6 of 21
Open Access
5.4
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
System Architecture
The system has been designed around an AMBA Multi-layer AHB backbone. This provides a large
amount of bandwidth in the system, and prevents the bus from being a bottleneck. This also means that
the SDRAM bandwidth can be exploited by other masters in the system whilst the core is performing
accesses to peripherals, or to static memory.
In the PWP system the following layers are provided:






ARM I AHB. Mastered by the ARM926EJ-S I port, used for instruction fetches. As it is only
used for instructions it can only access the SDRAM controller, the Static Memory controller and
the expansion port.
ARM D AHB. Mastered by the ARM926EJ-S D port, used for Data accesses, and writebacks
from the Cache. As this is for data, it is connected to the peripheral buses and the VIC, as well as
the external memories and expansion port. It is also connected to the DMA slave port which is
used to program the DMA and to the SDRAM configuration port (used for programming which
devices are attached, data widths, latencies, etc.)
LCD AHB. Mastered by the LCD controller this is used for LCD refresh data. Like the ARM I
AHB it is only connected to the SDRAM controller, the Static Memory controller and the
expansion port.
DMA 1 AHB. Mastered by one of the DMA Controller Master ports, this is connected to the
peripheral buses and the expansion port. The DMA controller can be programmed to read and
write to either port - so each device only needs a single connection to the DMA controller.
DMA 2 AHB. Mastered by the other DMA Controller Master port this bus is connected to the
external memories and to the expansion port.
Expansion AHB. This bus has no master on the PWP platform, but is provided for expansion.
This means that an AHB master connected to this port can have high-bandwidth access the
SDRAM and other devices on the PWP platform.
Additional Expansion AHB buses can be added by the partner if required.
The peripherals in the system are grouped onto two APB buses. This reduces the number of
peripherals exposed to bus activity whenever a single peripheral is accessed.
08/03/16
Page: 7 of 21
Open Access
5.5
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Expansion options
The design of the ARM PWP standard SoC platform is a key factor in enabling expansion and
customization of the ASIC.
Each of the internal buses is accessible from the periphery of the platform, enabling other bus masters
or high-bandwidth peripherals to be connected directly to the device.
Bus slaves can be connected to any layer which may require access to them. Bus masters can connect
to the expansion bus to allow them access to the SDRAM or other peripherals. For lower bandwidth
peripherals the two APB ports are accessible, enabling additional APB peripherals to be connected as
required.
Appendices A and B show example systems based around the PrimeXsys Wireless Platform.
5.6
Size and Speed
This table shows the size in gate count of each of the blocks within the PWP platform. It then totals
them to give an estimate of the total size of the PWP.
Peripheral
kGates
ARM926EJ-S *
230k
MOVE **
13k
Medium ETM
37k
SDRAM Controller
55k
Static Memory Interface
13k
Multi-layer AHB
8k
CLCD ***
24k
DMA Controller
82k
VIC
13k
GPIO (1.6k x 4)
6k
UART
9k
SSP
8k
SIM Card
12k
RTC
3k
Timers
6k
Watchdog
2k
System Controller
2k
Total
523k
* Excludes caches and TCM which are variable.
** Includes 64 bytes of working RAM (implemented as registers)
*** Excludes palette RAM and FIFO implemented as D-types
Assuming approximately 60kgates equates to 1mm2 for the TSMC 0.18um process (using the Libra
VISA cell library): 523k gates becomes 8.7 mm2.
The ARM926EJ-S and MOVE co-processor on a 0.18u process should achieve frequencies exceeding
200MHz. The bus and peripherals should achieve frequencies exceeding 100MHz.
08/03/16
Page: 8 of 21
Open Access
6
6.1
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Tools Support and Validation Methodology
Overview
Supplying a standard SoC Platform brings familiar problems to be solved. For example, how does
ARM:
1. Prove to developers that the PWP platform has been validated?
2. Improve the quality of release and therefore reduce the amount of support and maintenance
required leading to reduced time to market?
3. Provide an extendable environment for full system integration and validation?
ARM has addressed these problems by developing a methodology that consists of complementary
testbenches. These can be run on the standard SoC platform immediately on delivery, and can be
extended by the developer to test, exercise and functionally characterize the subsequent system design.
This methodology consists of:
 AMBA Compliance Testbench for demonstrating that individual RTL blocks are consistent with
the AMBA specification
 Extendable Integration Validation Testbench for ensuring that the system has been ‘wired-up’
correctly
 Extendable Subsystem Validation Testbench for ensuring that the system behaves as expected
 Extendable Software Development Model for integrating device drivers, OS-ports and application
software with models of the hardware
 Extendable IP Development Board for testing on real silicon.
All of these testbenches are extendable to allow customers to add in their own IP and their own tests.
With this methodology and its roadmap, ARM is putting a stake in the ground and is giving a clear
direction of the future. ARM will be working with the partnership and leading tools vendors to create
future validation methodology convergence to reduce the transaction cost of integrating and validating
IP from multiple sources.
6.2
AMBA Compliance Testbench (ACT™)
The AMBA Compliance Testbench (ACT) is designed to test individual AHB Master or Slave ports
and AHB devices. It will produce a coverage report for each port tested. A facility has been provided
for driving the port directly from a vector stimulus file (active mode), or for ‘snooping’ a port that is
connected into the system (passive mode).
For multi-port devices, a testbench is required to drive the other master/slave ports of the device while
the port under test is being observed. One port at a time can be fully checked for AMBA compliance
whilst the other ports are checked for protocol compliance.
Although possible, the ACT is not designed for attaching to every peripheral in the PWP platform
simultaneously and ‘running in the background’. This is because the nature of the testing is very
processor intensive and consumes large quantities of memory whilst performing temporal checking on
port signals.
ACT performance compares with ‘logging’ each set of signals on a device during a simulation session.
Again, although possible, it would therefore be unwise to simultaneously log every signal in a design
for each simulation run.
ARM recommends that every RTL block attached to AMBA bus in the system is initially tested on
ACT.
08/03/16
Page: 9 of 21
Open Access
6.3
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Integration Validation Testbench
The Integration Validation Testbench is a simple, but powerful tool that tests to ensure that the PWP
platform and any additional IP have been integrated together properly. This will include testing:
 Register maps
 Address map
 All blocks are correctly connected onto the AMBA buses
 Interblock connections are correct
 All peripherals are correctly connected to the outside world.
The model is re-useable and extendable so developers can add on their additional IP and ensure that not
only is the PWP platform still working, but also that their own IP has been integrated successfully.
6.3.1 Testing with a Bus Functional Model
The integration validation testbench is based around the PWP RTL and initially it is tested using two
bus functional models (BFMs) to simulate the ARM926EJ-S core. The advantage of testing with BFMs
first rather than a DSM of the ARM926EJ-S is that the BFM testing is faster and it removes the need to
run through the processor boot sequence before operations can start.
The expansion bus connections are also tested using BFMs and the vector sets running on these and the
core BFMs can be extended to more accurately reflect the traffic and access patterns in the customer’s
extension IP.
6.3.2 Testing with a Design Simulation Model
In the test suite the BFMs are replaced with the ARM926EJ-S DSM. This configuration will run real
software on real RTL and will prove that the core has been successful integrated and can be booted on
the extended system. The vector sequences which were run on the BFM models are regenerated as C
function calls to ensure consistency. The integration of the ARM926EJ-S core with the PWP RTL
framework is validated through the boot sequence. Additional code running in conjunction with the
boundary scan test blocks and trace monitor components verify correct integration of ICE and ETM.
08/03/16
Page: 10 of 21
Open Access
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
6.3.3 Testing Device Driver Initialisation
The DSM and RTL framework is also used to verify that the peripheral device drivers are correctly
integrated into the platform. By extending the boot sequence to include driver initialisation a level of
consistency between the implemented RTL and the Software Development Model (SDM) is gained.
Most of the software tests run on the DSM can also be run on the Software Development Model
(SDM). The SDM is described in more detail in section 4.6. It can also be extended by the developers
to look and behave the same as the RTL.
Boot Code
Register Integrity
IRQ Foldback
Peripheral Connect
Driver Initialisation
Device Driver Functionality
Integration TestBench
with DSM





(see note 1)
Software Development
Model



(see note 2)


Notes:
1. The DSM running at an RTL abstraction level on a typical simulator system has a performance of
less than 100 cycles per second. It is too slow to efficiently test the full device driver functionality.
The SDM is a better tool for doing this as it runs at 1-10MHz.
2. Peripheral connection software has no meaning in the abstracted SDM. Future versions of the
SDM will allow this testing.
These test that the SDM is consistent with the RTL. Developers can now demonstrate the two views of
the ASIC are the same and so the testing can be split. Hardware engineers can validate that the RTL is
correctly integrated into the wider system environment (see section 4.4). Software engineers can start
developing and porting device drivers, Operating Systems and application software (see section 4.6).
ARM recommends that developers designing time-critical device drivers replace the DSM with a
Design Development Model (DDM) of the ARM926EJ-S. The DDM is a product available from
ARM’s EDA partners and is not supplied directly by ARM. These provide faster cycle accurate
simulations necessary for the purpose of validating critical driver performance. For more information
on ARM’s EDA partnership go to www.arm.com.
6.3.4 Integration Validation Testbench Deliverables
The Integration Validation Testbench and all of its tests can be replayed by the developer “out-of-thebox” on a standard RTL simulation platform. This gives a good assurance of the quality of the
deliverables. The developer can then immediately get to work adding in their additional IP models.
Even when additional IP has been added, all of the PWP platform tests will still work, the developer
will just need to add in tests for their own IP. The PWP platform includes:
 RTL of the PWP, BFM and all the testbenches, external models and trickboxes
 Source code for all the software used, including test vectors, device drivers and test co-ordinators
 Scripts and tools for generating test vectors and test sequences (including the test vectors and
sequences used for validating the PWP platform itself).
The ARM926EJ-S DSM comes with the deliverables sent to all ARM926EJ-S licensees. An RTL
simulator is also required.
08/03/16
Page: 11 of 21
ARM PrimeXsys Wireless Platform
Detailed White Paper
Open Access
6.4
Revision 4.0
Subsystem Validation Testbench
The Subsystem Validation Testbench is more complex than the Integration Validation Testbench and it
ensures that the PWP platform (and any additional IP) interacts correctly with its environment.
Denali
Memory
Model
Denali
Memory
Model
VIC
External
Model
LCD
External
Model
SDRAM
Controller
Static
Memory
Interface
Vectored
Interrupt
Control
Color
LCD
DMA
External
Model
DMA
S
BFM Driver
and System
Test Vectors
DMA APB
AHB
Slave
Peripheral
Model
M
M
BFM Driver
and System
Test Vectors
ARM I AHB
ARM D AHB
LCD AHB
DMA 1 AHB (Periph)
DMA 2 AHB (Memory)
EXPANSION AHB
Core APB
WATCHDOG
TIMERS
AHB/
APB
AHB/
APB
SSP
AHB
Master
Perpheral
Model
ADK APB
Peripheral
Models
GPIO (x4)
GPIO
x4
GPIO
External
Model x4
RTC
SYSTEM
CONTROL
UART
SIM Card
System Clock
/Reset
External
Model
UART
External
Model
SCard
External
Model
EXTERNAL
MODEL TEST
SCENARIO
MANAGER
Each peripheral is connected to an external model (known as an external verification component xVC)
of the device it would be attached to in a 2.5/3G-phone. For example, the SIM Card Interface
(SCARD) is connected to an external model of a SIM Card. This external model has been
independently written and has been tested against SIM Cards and other models of SIM Cards.
Although exact behaviour cannot be guaranteed, it will be sufficient for these tests. The xVC not only
simulates ‘good’ behaviour but also emulates fault conditions – for example a SIM Card removal
during operation.
Each xVC, including the Core and extension BFMs, encapsulates a series of actions and callbacks. An
action can be very simple, for example write to peripheral register, or complex, such as randomly burst
traffic onto the APB bus for 200 cycles when the processor takes an interrupt. The actions and
callbacks can include any arbitrary interaction between xVCs or between the xVCs and the PWP
platform model
All detail regarding behaviour is captured inside the xVC container. Each xVC interacts with the
External Test Scenario Manager (ESM) through a defined API. It is therefore only required to
sequence and resolve all of the test events and callbacks and record the subsequent actions by the
system under test. The ESM can cause simultaneous events and can cause actions from both the core
side and peripheral side, this is referred to as a scenario.
The ESM encapsulates four additional objects: the test coverage monitor, the subsystem coverage
monitor, the subsystem annotation block and the AMBA protocol block.
08/03/16
Page: 12 of 21
Open Access
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
The Test Coverage Monitor checks that all the specified scenarios to be tested have been run. This
monitor is very useful when extending the Subsystem Validation Testbench. The developer can
reorder and add in extra tests to the scenarios database, and the coverage tool will identify if any tests
or device features have been accidentally missed out. This feature is essential for regression testing the
extended PWP platform. The monitor is extensible to include the new scenarios added by the
developer. The monitor gives an indication for each simulation run of what black box functional
scenarios were exercised upon the PWP platform and its extensions
The Subsystem Coverage Monitor analyses the state of the PWP platform whilst a set of test scenarios
is being run. This is used to ensure that an extended platform is exercised to cover a defined set of
possible device states inside the PWP platform. It gives a measurable way of determining whether an
extended test scenario was checked with a variety of possible internal PWP platform states in an
unambiguous manner.
The Subsystem Annotation Block captures useful information regarding the state of the PWP platform.
Its purpose is to provide frontline debug support during integration. It encapsulates detailed knowledge
from the PWP platform architects regarding possible usage problems which may arise in the
integration. For example an annotation point may be attached to the interrupt controller and report
when 3 or more interrupts become active within a 50 microsecond window.
The AMBA Protocol block is identical to the one used within the ACT product and identifies any bus
protocol violation on the expansion bus interfaces
6.4.1 Example: SIM Card Interface
The SIM Card Interface can be tested by the scenario manager driving the BFM to write some data to
it. The scenario manager will then record whether this data was successfully received by the SCARD
External Model. Equally, the scenario manager can cause the SCARD External Model to simulate the
insertion of SIM Card and then record that the SIM Card Interface behaved in a correct manner.
The ESM can then cause a simultaneous attempt to write data to the SIM Card just as the card is
removed. How the SIM Card Interface coped with these events will also be record for later analysis.
6.4.2 Testbench Design
The testbench, including the external models and the scenario manager are all implemented in Verisity
Specman ‘e’. Using an object-oriented approach means that the all models are re-useable and
extensible so developers can add on their additional IP. Developers can then ensure that not only is the
PWP platform still working, but also their own IP has been integrated successfully. Developers can
also modify the test scenarios to test scenarios not covered in the basic testbench, or to enable the
testing of additional IP.
Use of the delivered AMBA protocol, device coverage and annotation blocks is possible in any
testbench environment as ISpecman packaged deliverables. However, any customer extensions written
in ‘e’ require that the developer must have the appropriate licenses from Verisity.
08/03/16
Page: 13 of 21
Open Access
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
6.4.3 Adding Additional IP
The Subsystem Validation Testbench has not been designed merely for standalone testing. It has been
designed so that developers can extend it. Not only can developers add in additional RTL to the
subsystem, but they can also add in additional external models to test the new system.
There is a defined API between the external models and the ESM. This enables developers to either:
 Write a new external model in ‘e’
 Wrap legacy RTL models in ‘e’ to give them the correct API
 Integrate legacy C-models – It is recommended that developers first seek advice from ARM about
the compatibility of legacy tools when running C-models alongside ‘e’ models.
Adding additional IP to the PWP platform is going to result in a new and more complex system.
Inevitably there are going to be problems to overcome, but ARM has made the debugging of these
problems easier by providing the test coverage monitor and the best possible presentation of data from
the monitor and External Scenario Manager.
6.5
The Future of the Subsystem Validation Testbench
In the first version of the PWP platform, the Subsystem Validation Testbench contains a BFM. ARM
is currently developing a version which will contain an Instruction Set Simulator (ISS). This will allow
real software to be run and debugged on the testbench. It will still be running at RTL speeds (i.e. less
than 500 cycles per second), but will be suitable for device driver initialisation. This more advanced
Subsystem Validation Testbench will be first shipped with the PWP platform in Q2-2002.
The next challenge is to speed-up the testbench by also including a C-model of the RTL. This model
will be cycle count accurate and will model the behaviour of the RTL at the transaction level. This will
run at more than 200,000 cycles per second and could be used for debugging device drivers and ensure
that the OS-port is correctly ported. It is still too slow for software development, which is why ARM
will continue to support the ARMulator™ model and development boards. For example, ARM
estimates that Symbian OS would take approximately one hour to boot on this testbench. This faster
Subsystem Validation Testbench will be first shipped with the PWP platform in Q4-2002.
ARM is also in discussions with the leading tools vendors to ensure that the PWP platform is supported
and integrated to their co-validation, emulation and implementation tool chains.
08/03/16
Page: 14 of 21
Open Access
6.6
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
Software Development Model
The SDM is built around the ARMulator model simulating an ARM926EJ-S and PWP platform subsystem. All of the peripherals including AHB masters and slaves and the APB peripherals have been
modeled in C. The SDM will run on either on a Windows NT or UNIX workstation.
-
The model of the LCD will use the workstation’s screen
The model of the Touchscreen will use the workstation’s mouse
The UART will write to and read from a files, keyboard/Xwindow or network socket.
The multi-layer fabric and the DMA will be modeled at a cycle count level: there will be a small
difference (10%) in the cycle count due to the modelling technology employed.
The SDM will be used for:
- Writing device drivers
- Porting the operating systems (Symbian OS, Windows CE and Linux)
- Porting and developing application software, including Java applications
- Characterising the performance of the software on the ARM926EJ-S and the PWP platform. This
is especially useful when trying to determine how much cache, TCM and on chip memory is
required.
The SDM interfaces to ARM's GUI debuggers, allowing source level OS kernel debugging where this
is supported. At the time of writing, this is available for Symbian OS development.
6.7
IP Development Board
ARM is planning to have an IP Development Board based around ARM926EJ-S and PWP platform
silicon. The development of this board has not been confirmed because ARM is still in negotiation
with the SiP who will be providing the ASICs.
The ASIC will contain the entire PWP platform and a few additional peripherals to make a
development platform. The AHB expansion layer will be brought out to FPGA via bridges. This will
allow extension hardware IP development. The OS-ports available for the PWP platform will work on
this ASIC.
The ARM926EJ-S will run at 200MHz. The AHB peripherals will run at 100MHz. The FPGA will
run at 20MHz. This will allow to real-time (or close to real-time) simulation of software and hardware
IP.
This development board will include serial link connects to allow for other development boards to be
plugged into it. For example, a baseband processor on another development board could communicate
with the PWP platform via a high-speed serial link.
08/03/16
Page: 15 of 21
Open Access
7
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
OS-Ports
The PrimeXsys Wireless Platform will come with OS-ports as standard.
SymbianOS
WinCE
Linux
PalmOS
Version
6.1
4.0
2.4.x
TBA
Available on PWP
Q3-2001
Q4-2001
Q4-2001
TBA
The PWP customer will be supplied with everything needed to make the OS-Port aware of their
differentiating IP:
 Device drivers will be delivered as source code from ARM;
 Access to kernel source will be provided by the OS-vendor;
 Tools for working on the OS-port are provided by the OS-vendor and ARM;
 Build instructions and technical documentation will be provided by OS-vendor and ARM.
ARM is working with the OS vendors to provide tool interfaces to ARMulator™.
7.1
OS Vendors
OS Vendors have placed some restrictions on how ARM can deliver the OS ports.

For ARM to deliver the Symbian OS port to the customer, the customer must first be a member of
Symbian’s Semiconductor Program.

For ARM to deliver the Windows CE port to the customer, the customer must first join the
Windows Consortium. This consortium is administrated by ARM and pays Microsoft an annual
fee to keep the Windows CE tool chain available for the ARM instruction set.

Linux does not have a single OS Vendor to negotiate and ARM is working with leading Linux
providers. Each provider may have a different business model.

The plans for Palm OS will be announced when it is clear when Palm intend to release their
porting kit.
7.2
Maintaining the OS-Port
The maintenance fee includes supplying the customer with new upgrades of the OS when available.
The PWP platform will continue to be maintained against the latest available versions of these OS’s.
The latest version will be supplied to the customer as part of the S&M. Customers licensing PWPv1
will receive Symbian OS ER6.1. When ER6.2 becomes available, it will be supplied to the customer
(and 6.3 and 7.0. etc). As long as the customer continues to pay support and maintenance ARM will
keep the OS-ports updated.
08/03/16
Page: 16 of 21
ARM PrimeXsys Wireless Platform
Detailed White Paper
Open Access
Revision 4.0
ARM’s Extending IP
8
8.1
Application Software
The PWP platform's operating system ports contain all of the standard PIM and connectivity
applications supplied as standard with a Symbian OS DFRD or Windows CE product.
Symbian OS Quartz DFRD
 Agenda
 Calculator
 Connect
 Contacts
 Jotter
 To do
 Web browser
Windows CE Pocket PC
 Internet Explorer
 Pocket Excel
 Pocket Outlook
 Pocket Word
 Reader
 Windows Media Player
Embedded Linux ports will usually come from a Linux support company. Each company will have a
different set of application software available.
8.2
ARM’s Audio Software
The following audio and voice codec software is available from ARM for the PWP platform.
ARM Optimised
Audio Codec Summary
CODEC
Availability
MP3 Decode XP
NOW
MPEG-AAC (TNS)
NOW
MS-WMA
NOW via MS
MP3 Encode
NOW
AAC Encode (TNS)
4Q01
ADPCM
NOW
G.723.1
TBA
Clock Freq in
MHz
ARM926
16
15 (16)
23
32
< 33 (< 50)
<5
45
Memory Footprint,
no DRM, (kB)
ROM
RAM
29
22
39
22
75
26
63
38
~64
~27
<1
3.5
123
20
SNR cf to
Ref Codec
dB
87
~100
~90
-
All figures are for zero-wait memory.
All measurements are for peak MHz.
8.3
Jazelle Technology Enabling Kit (JTEK)
The ARM926EJ-S core incorporates the Jazelle instructions for Java acceleration. This is
complemented by the Jazelle Support Code that manages the interface between the core hardware, the
virtual machine and the operating system.
The Jazelle Technology Enabling Kit (JTEK™) comprises all necessary support code source,
documentation and tools that are required to integrate Jazelle technology into a virtual machine and
operating system. JTEK is available for pJava, KVM and CVM and can be integrated into all the OS’s
supported by the PWP platform. Symbian OS v6.2 already includes the Jazelle VM as standard. This
will be ported to the PWP platform when available. Windows CE will not support Java as standard
because Microsoft is instead developing its rival .NET technology. However, Jazelle VM can still be
integrated into Windows CE. The same is true for Linux.
For more information about ARM’s Jazelle Java acceleration, please see www.arm.com.
08/03/16
Page: 17 of 21
Open Access
8.4
ARM PrimeXsys Wireless Platform
Detailed White Paper
Revision 4.0
MOVE Technology
ARM MOVE technology components are available for the PWP and are targeted for MPEG-4 and
other video coding schemes for wireless devices. MOVE combines memory- and power-efficient
software and hardware components that enable video encoding and decoding up to twice the speed of
existing codecs.
8.5
PrimeCell® Peripherals
Many of ARM’s PrimeCell Peripherals are included in the PWP platform as standard. Additional
PrimeCell Peripherals are also available for the PWP platform:
Description
UART
Similar to 16C550
Includes software device driver
Advanced Audio Codec Interface (AACI)
Supporting AC'97
Includes software device driver
SD-Card Interface
Includes physical layer device driver
Security software stack also available
Multimedia Card Interface
Includes physical layer device driver
9
AMBA bus type
APB
Gate count
8.9k
APB
4.5k
APB
13.5k
APB
12.9k
Third Party Partnership Program
Future mobile devices have higher functionality requirements than ever before. It is unlikely that any
single company will be able to provide all the IP (and supporting infrastructure) to meet these
requirements. It is therefore vital that 3rd-party IP (software and hardware) is made available for
customers of the PWP platform. ARM is already seeing handset manufacturers demand that their
silicon providers guarantee that certain 3rd party software will work on the ASIC.
ARM will assist semiconductor manufactures with a 3 rd party partnership program for the PWP
platform. As part of this program ARM will help developers to ensure the following:
Hardware IP Criteria:
 AMBA bus-compatible
 Suitable for inclusion into a PWP platform-based ASIC
 Device driver meets the software IP criteria (see below)
 Can be successfully run on the PWP IP Development Board
 Has been measured for a required set of characteristics:
 Bus bandwidth
 Power consumption
 Gate count
Software IP Criteria:
 Is ported to at least one of the OS that come with the PWP platform
 Must work on the IP Development Board (and therefore the PWP platform-based ASIC) ‘out-ofthe-box’
 Has been measured for a required set of characteristics:
 Performance (MHz)
 RAM/ROM size
 Bus bandwidth
 Power consumption
08/03/16
Page: 18 of 21
ARM PrimeXsys Wireless Platform
Open Access
Detailed White Paper
10 PrimeXsys Wireless Platform Roadmap
Revision 4.0
When creating a new standard, two things need to be achieved:
1. Acceptance by most of the major players, in this case including semiconductor companies, OEMs,
software developers, system houses, content providers, etc.
2. Stability of the standard. If it is continuing to change then there is no standard for everyone to aim
for and develop with. Any changes that are made, need to be at least backwards compatible.
ARM can therefore only add, and not take away.
The detail of the PWP platform roadmap will largely depend on OEM and semiconductor manufacturer
demand. ARM has to maintain the balance between supplying enough IP to provide a standard SoC
platform, but still maintaining space for the semiconductor manufacturer to provide their
differentiation. As IP becomes standard on all 2.5/3G mobile phones, it is likely that it will be
absorbed into the PrimeXsys Wireless Platform. The next PWP platform may contain USB, whilst a
future version could possibly support Bluetooth™.
The roadmap today is as follows:
Date
September 2001
March 2002
September 2002
Version
PWP v1.0
PWP v1.1
PWP v1.2
September 2002
PWP v2.0
Description
Targeted at 2.5/3G phones with videophone capability
With the same IP set as v1.0 but with additional validation support
Similar to above but with 3D graphics acceleration for supporting
sophisticated games (as found on today’s wired PCs and games
consoles)
Based around the first ARM core with the v6 architecture – a powerful
(but low-power) processor designed specifically for 2.5/3G mobile
phones
To complement the main roadmap, ARM and its 3 rd party partners will also be launching application
software and hardware IP that will “drop into” the PWP platform. This will include:
 All the major consumer operating systems;
 All the major third-party software companies.
ARM is also working with content providers to ensure that this application software is supported with
all the best content.
11 More Information
More Information on ARM and the PrimeXsys Wireless Platform can be found on the ARM’s website
(http://www.arm.com). This paper was written by Ian Thornton, product manager for the PrimeXsys
Wireless Platform.
Ian Thornton
Product Manager
ARM Ltd
110 Fulbourn Road , Cambridge.
CB1 9NJ England
Tel: +44 1223 400 796
Fax: +44 1223 400 410
Ian.Thornton@arm.com
08/03/16
Page: 19 of 21
ARM PrimeXsys Wireless Platform
Open Access
Detailed White Paper
12 Appendix A – GPRS phone
Trace Port
Analyser
SDRAM
Bank 0
SDRAM
Bank 2
SDRAM
Bank 1
SDRAM
Bank 3
ETM
MOVE
SRAM
Static
Memory
Interface
SDRAM
Controller
ARM926
CPU
ROM
Flash
Revision 4.0
LCD Display
Vectored
Interrupt
Control
Color
LCD
DMA
M
M
S
Boot
ROM
ARM I AHB
ARM D AHB
Shared
On-Chip
SRAM
LCD AHB
DMA 1 AHB (Periph)
DMA 2 AHB (Memory)
EXPANSION AHB
DMA APB
Core APB
WATCHDOG
AHB/
APB
TIMERS
GPIO (x4)
GPIO
x4
SYSTEM
CONTROL
RTC
AHB/
APB
UART
SSP
Digital
Baseband
System
Radio
Peripherals
HS Serial
I/F
SIM Card
Clk/Reset
Generator
32 GPIO
lines
32KHz
CLK
Xtal Osc
Keyboard
I/F
PLL
Xtal Osc
RS232
08/03/16
Page: 20 of 21
SIM
Card
Keyboard
USB
Interface
USB Connection
to PC
UARTs
UARTs
UARTs
ARM PrimeXsys Wireless Platform
Open Access
Detailed White Paper
13 Appendix B – Videophone
Trace Port
Analyser
SDRAM
Bank 0
SDRAM
Bank 2
SDRAM
Bank 1
SDRAM
Bank 3
SRAM
ROM
Flash
Revision 4.0
LCD Display
PC Cards
ETM
MOVE
Static
Memory
Interface
SDRAM
Controller
ARM926
CPU
Vectored
Interrupt
Control
Color
LCD
DMA
M
M
S
PCMCIA
Host
ARM I AHB
ARM D AHB
LCD AHB
SRAM
Buffer
DMA 1 AHB (Periph)
DMA 2 AHB (Memory)
EXPANSION AHB
DMA APB
Core APB
WATCHDOG
AHB/
APB
TIMERS
AHB/
APB
MPEG-4
Engine
Colour
Convert
SSP
Camera
Interface
Camera
GPIO (x4)
GPIO
x4
SYSTEM
CONTROL
RTC
UART
32 GPIO
lines
Xtal Osc
USB
Interface
Transceiver
Clk/Reset
Generator
32KHz
CLK
SIM Card
PLL
Xtal Osc
USB Connection
to PC
08/03/16
Page: 21 of 21
Camera
Control