The performance requirements of computing systems have been growing rapidly, year on year. Demand is further increased by the many new performance-demanding applications that are emerging across multiple market segments, such as machine learning (ML), computational photography and autonomous driving.
To deliver against high-performance requirements, systems-on-a-chip (SoCs) increasingly employ a large number of components, including multiple processors, accelerators and I/O devices. This significantly increases the complexity and the risks and costs of designing an SoC, making right-first-time development more important than ever.
The design and verification of a modern SoC often extends across different teams, vendors and environments. Performance simulations, RTL-based or transaction level, using FPGAs or the final SoC, need to be consistent so that the results can be correctly correlated. A common and concise abstraction to express the performance and traffic characteristics of an interface is required.
Simulation of such complex systems typically requires accurate models of the different components, in order to understand the interaction between them. That is, however, a difficult task and can result in long simulation times, before meaningful results can be obtained. We need a simpler and faster simulation mechanism that is, at the same time, predictable and adaptive.
To address the challenges described above, we have developed a new synthetic traffic framework, the AMBA Adaptive Traffic Profiles (AMBA ATP). It is capable of modelling systems' masters and slaves high-level memory access behaviour in a concise, simple, and portable way.
You can download the AMBA ATP Specification below.
[CTAToken URL = "https://pages.arm.com/amba_adaptive_traffic_profiles_specifications.html" target="_blank" text="Download AMBA ATP Specification" class ="green"]
AMBA ATP is a framework designed to generate synthetic stimuli in a simple way: it’s complex enough to provide interesting and useful stimulus to other system components, simple enough to generate traffic quickly, and easy enough to reason about and analyse.
ATP complements AMBA, which is widely adopted as the standard for on-chip communication. AMBA specifications provide interface standards, enabling design reuse and an ecosystem of compatible and interoperable solutions. The AMBA ATP specification is meant for hardware and software engineers needing to design or debug systems and modules that are compatible with AMBA specifications.
AMBA ATP uses a simple input definition, as shown in the example below, consisting of only a small number of parameters. This simple definition means that the traffic profile definition can be easily shared across teams and companies.
A traffic profile is essentially a definition of the transaction characteristics for an interface. It can be thought of as a specification of the dynamic characteristics of an interface and includes information on both the types of transactions and the timing characteristics.
Traffic profiles can be utilized throughout the SoC design cycle, from system analysis all the way down to silicon evaluation, with the benefit of a consistent set of stimuli which moves vertically as the design progresses towards production.
A typical AMBA ATP deployment is composed by an execution engine - capable of parsing and interpreting an AMBA ATP description. The environments may also include the ability to collect statistics and measurements on a simulated platform, where part or all masters and slave are modelled via AMBA ATP profiles.
One of the AMBA ATP foundations is the ATP FIFO: it reproduces the traffic elasticity of the modelled device interface by means of a constant fill/drain rate buffer, out of which memory access requests are generated according to simple FIFO occupancy rules, and based on the FIFO type (READ/WRITE).
If there is enough data in the FIFO buffer to generate a write request, send one.
If there is enough space in the FIFO buffer to accommodate a read response, send a read request.
By varying the basic parameters of the FIFO – the FIFO depth, the fill/drain rate, and the maximum number of outstanding transactions – it is possible to closely model a large number of different components that are typically found in an SoC. A construct as simple as the FIFO can become powerfully expressive when combined in series and parallel groups. As with simple harmonics in signal theory, it is possible to combine multiple elementary FIFO elements to compose complex patterns representative of the most diverse workloads and devices.
Hi, thanks for your questions.
The input definition in the blog is shown as an example only, and not linked to any particular implementation.
At the moment, we are only providing the specifications. However we expect some tools will be announced soon by our ecosystem partners.
Is the input definition format written in python ?
What tools are provided by ARM to support this spec and input definition in a simulation environment?
Please clarify what ARM provides beyond the spec.
Thanks