The ADL Language

Report
TM
Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire,
ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobileGT, PowerQUICC,
Processor Expert, QorIQ, Qorivva, StarCore, Symphony and VortiQa are trademarks of
Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. Airfast, BeeKit, BeeStack,
CoreNet, Flexis, Layerscape, MagniV, MXC, Platform in a Package, QorIQ Qonverge,
QUICC Engine, Ready Play, SafeAssure, the SafeAssure logo, SMARTMOS, TurboLink,
Vybrid and Xtrinsic are trademarks of Freescale Semiconductor, Inc. All other product or
service names are the property of their respective owners. The Power Architecture and
Power.org word marks and the Power and Power.org logos and related marks are
trademarks and service marks licensed by Power.org. © 2013 Freescale Semiconductor,
Inc.
•
Freescale develops many different types of cores:
− Microprocessors,
•
DSPs, highly-embedded RISC cores.
A variety of models/tools needed over a project’s life-cycle:
− Early
architectural exploration.
− Assemblers, compilers, documentation
− Verification models
− Virtual platform models for early software development.
•
•
All must be consistent, even as the design changes!
Little need for RTL generation:
− These
•
are highly optimized cores, so RTL will be done by hand.
Need to separate architecture and micro-architecture:
− Same
functional behavior, but the same architecture may have multiple
implementations.
•
Need high-degree of re-use across projects, clean way to handle
minor architectural differences.
2
•
•
Freescale ADL consists of two languages:
−
A language for describing a core's architecture: ADL
−
A language for describing a core’s micro-architecture: μADL
The system is a collection of generators.
−
•
A single description can be used to create a consistent set of tools
A single executable specification may be used for a variety of purposes:
−
Early architectural exploration
−
Verification
−
Software enablement, early sw development.
•
In use since 2007.
• It is an open-source project!
− http://opensource.freescale.com/fsl-oss-projects/
3
Advantages of having a Freescale language:
−
Modifiable in-house.
−
Keeps our IP in a format that we control.
−
Easily interact with external research groups or vendors.
−
Distribute models to customers w/o requiring additional licenses.
Why not use an existing language?
• Most vendor tools developed for modelling
ASPs and DSPs:
• Cannot directly model the many complex
elements of our microprocessors, e.g.
MMUs, closely-coupled caches, etc.
• Difficulty with handling complex microarchitectures, e.g. out-of-order.
• Often combine architecture and microarchitecture descriptions.
uArch Complexity
•
Power ISA:
Superscalar, out-oforder
Power ISA +
extensions:
Single-issue, inorder
Arch Complexity
4
•
•
Generated
Tools
A single specification can be
used throughout the lifetime of
a project.
As opposed to:
− Lots
of individual specialpurpose models and tools.
− Each
must be individually
verified.
− This
represents a tremendous
amount of duplication, both in
terms of time and information.
Prototype
models
ADL
Description
Impl. Spec
Arch Spec.
Dev Tools:
assemblers,
compilers,
debuggers
Product
Life-cycle
Product
definition,
trade-off
analysis
Pre-silicon
verification
Random
testcase
generator
Functional
testbench
Post-silicon
verification
Bring-up tools:
silicon
debuggers, etc.
Customer
support
Arch Spec.
Production
quality
models and
dev. tools.
5
•
ADL is a declarative language for describing the resources contained within
a microprocessor core.
−
−
−
•
Some of the resources we model:
−
−
−
−
−
−
•
Registers and register-files
MMUs
Memory hierarchy: Cache hierarchies and local memories
Exceptions
Instructions
Inter-processor communication facilities
Implementation-specific behaviour is described using blocks of a subset of
C++.
−
−
•
A description can be decomposed into a series of architecture blocks.
These architecture blocks can be combined together to form a core.
Architecture blocks can be re-used across different cores.
Verilog-like bit-vector manipulation provided via a template-based bit-vector class.
Helper functions may be specified directly in the design in order to re-use commonly
performed actions.
External libraries may also be used.
6
An Example Instruction Declaration:
define (instr=addi) {
“””
The sum (GPR[rA]|0) + SI is placed into GPR[RT].
Documentation
String
“””;
fields=(OPCD(14),RT,RA,SI);
syntax = (“%i %f,%f,%f”,RT,RA,SI);
action = {
var b = signExtend(SI,regSize);
if (RA == 0) {
GPR(RT) = b;
Instruction
Semantics
Instruction encoding.
These fields are defined
elsewhere in the description.
•OPCD(14) means that the
OPCD field has a value of 14.
•RT, RA, SI are operand fields.
} else {
GPR(RT) = GPR(RA) + b;
}
};
}
An Example Register File Declarations:
define (regfile=GPR) {
"""
General purpose registers.
""";
size = 32;
prefix = r;
}
7
define (arch=A) {
define (reg=LR) {}
…
define (regfile=SPR) {
size=1024;
define (entry=8) { reg = LR; }
define (entry=9) { reg = CTR; }
define (entry=1) { reg = XER; }
define (entry=50) { reg = HID0; }
define (entry=51) { reg = HID1; }
}
}
define (core=C) {
archs = (A,B);
}
Initial architecture definition:
Registers and a sparse
register file collection.
define(arch=B) {
define (reg=FOO) {}
defmod (regfile=SPR) {
define (entry=50) { remove = true; }
define (entry=51) { reg = FOO; }
}
}
Partial architecture modifies
the register file, removing one
item and overwriting another.
define: Create or overwrite existing entity.
defmod: Modify existing entity, overwriting specified keys.
This allows for fine-grained control of final architecture,
avoiding the confusion of lots of #ifdef’s.
Final core definition
combines these two
architectures
8
EX
Trg.allocate()
MM
GPR
Write_ops()
WB
A formal model:
Operation state machine
and resources
The language:
declarative, concise,
hides ISA details
Define (instr_class sfx) {
instructions = ( add, addi );
define (operands) { … };
action = {
S_ID: if (Src.can_read()…){
Src.read();
…;
}
…
}
}
Operands hide differences
between instructions:
Define (instr_class sfx) {
instructions = ( add, addi );
define (operands) {
Src1 = GPR(RA);
Src2 = GPR(RB);
Trg = GPR(RT);
};
}
9
addi does not have Src2
Therefore, will be
replaced with a dummy
operand
During template
instantiation, compiler will
fold out this code.
Architecture
Team
Assembler/
disassembler
ADL
Compiler Team
Simulator
XML
Database
Verification
RTL Design
Documentation Team
10
Architectural
Exploration
Performance
Analysis
Pipeline
Model
•
•
Summary:
−
Open-source architecture description language.
−
Applied to a variety of projects: Power ISA, DSPs, 16-bit micro-controllers, etc.
−
Applied across a range of phases of various designs’ life-cycles, across a variety of
groups within Freescale
−
Separates the architecture (programmer’s view) and micro-architecture
−
High-level constructs such as translation units and caches for a high-degree of re-use
across a given architecture.
Current and Future Development:
−
Better integration with SystemC and other simulation environments:
−
Parallel simulation:
−

MIT Graphite.

Multi-threaded simulation kernel via Boost threads.
Improvements for dynamic binary translation (FastISS using LLVM).
11
12
ADL Description
μADL Description
Programming Model
(Registers, MMU,
Instructions)
Pipeline Description
(Pipeline stages, register
read/write behavior)
Verification
Interpreted
Functional
Simulator
Cycle-Accurate
Simulator
Interpreted
Functional
Simulator
Documentation
(HTML, PDF)
Assembler/
Disassembler
Trace-cache
Fast Functional
Simulator
Architectural
Exploration
Interpreted
Functional
Simulator
XML, Perl
Database
Assembler/
Disassembler
Roles For
Various
Generated
Tools
Software
Enablement
Virtual
Prototyping
Documentation/
Database
Documentation/
Database
Cycle-Accurate
Simulator
Assembler/
Disassembler
Assembler/
Disassembler
Trace-cache
Fast Functional
Simulator
Cycle-Accurate
Simulator
13
•
ADL can generate different types of models, depending upon
the need:
− Functional:

Interpreted models: Slow, but very useful for verification (can single-step
the design), fast enough for short workloads (arch. explr.). 1-10 MIPS.
 Byte-coded: Faster than interpreted, fully portable C++. 50-80 MIPS.
 Dynamic-binary-translation: Uses LLVM. > 100 MIPS. Currently limited to
Linux.
 Parallel simulation kernel using Boost threads.
− Performance:

Safe-mode: ISS coupled to pipeline model.
•

Functionally correct with approximate timing.
Normal-mode: Transactional ISS tightly coupled to pipeline model.
•
Exposes timing errors as wrong answers, e.g. forgotten forwarding path.
14
DUT
Verification
Team
ADL Model
ADL Model
ADL Model
ADL Model
Testbench
ADL Model
Architectural
Test-case
Generator
Architectural
Test-cases
(text)
15
Core
Core
Core
Core
•
Better integration with SystemC and other simulation environments:
−
−
−
•
Currently, SystemC TLM2 integration is handled on a per-project basis.
Goal is to create a push-button flow for TLM2-compliant models (LT for ADL, AT
for µADL).
Also experimenting with parallel simulation environments:

MIT Graphite.

Multi-threaded simulation kernel via Boost threads (released with ADL 3.4). Future
enhancements include multi-threaded tracing, more efficient memory models.
Improvements for dynamic binary translation:
−
Uses LLVM for translation of basic blocks to native machine code.

−
−
•
Further optimizations for code generation.
Investigate translation at the trace level, in order to reduce branch penalties.
Investigate adding timing to these high-speed models.
Continue expanding ADL to other architectures, based upon Freescale’s
design needs.
16
•
FreescaleADL is an open-source system for describing programmable cores, applied to a
variety of projects including Power ISA cores, DSPs, 16-bit micro-controllers, etc.
•
The fact that the language is open (and we develop it) allows us to add enhancements as
needed as well as makes it easy to integrate into various kinds of simulation environments,
e.g. SystemC, distributed simulation environments, etc.
•
The separation of architecture and micro-architecture descriptions, plus high-level constructs
such as translation units and caches, allows for a high-degree of re-use across a given
architecture.
•
This language and tooling have been successfully applied across many phases of various
designs’ life-cycles, with a high-degree of re-use, e.g. architecture exploration models
enhanced for verification, then adapted for virtual-prototype use.
•
It has been successfully deployed to a number of groups within Freescale: Rather than a
central modeling team, teams in individual business units do the modeling. This allows for
fast turn-around time (they own the model). The central organization supports the
infrastructure and adds enhancements as needed.
17

similar documents