FreescaleADL

1. FreescaleADL An Industrial-Strength Architectural Description Language For Programmable Cores Brian Kahne Freescale Semiconductor

2. The Problem • 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.

3. The Solution: FreescaleADL • 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/

4. Why Develop Our Own Language? • 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. Power ISA: Superscalar, out-of-order Power ISA + extensions: Single-issue, in-order • 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 micro-architectures, e.g. out-of-order. • Often combine architecture and micro-architecture descriptions. uArch Complexity Arch Complexity

5. ADL As A Specification Generated Tools Product Life-cycle • A single specification can be used throughout the lifetime of a project. • As opposed to: • Lots of individual special-purpose models and tools. • Each must be individually verified. • This represents a tremendous amount of duplication, both in terms of time and information. Prototype models Product definition, trade-off analysis Dev Tools: assemblers, compilers, debuggers ADL Description Pre-silicon verification Random testcase generator Impl. Spec Arch Spec. Functional testbench Post-silicon verification Arch Spec. Bring-up tools: silicon debuggers, etc. Customer support Production quality models and dev. tools.

6. The ADL Language • ADL is a declarative language for describing the resources contained within a microprocessor core. • 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. • 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++. • 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.

7. The ADL Language An Example Instruction Declaration: define (instr=addi) { “”” The sum (GPR[rA]|0) + SI is placed into GPR[RT]. “””; 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; } else { GPR(RT) = GPR(RA) + b; } }; } Documentation String • 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. Instruction Semantics An Example Register File Declarations: define (regfile=GPR) { """ General purpose registers. """; size = 32; prefix = r; }

8. ADL Modularity Initial architecture definition: Registers and a sparse register file collection. 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(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 (core=C) { archs = (A,B); } 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

9. WB Write_ops()‏ GPR MM Trg.allocate()‏ EX The μADL Language The language: declarative, concise, hides ISA details Define (instr_classsfx) { instructions = ( add, addi ); define (operands) { … }; action = { S_ID: if (Src.can_read()…){ Src.read(); …; } … } } A formal model: Operation state machine and resources addi does not have Src2 Therefore, will be replaced with a dummy operand During template instantiation, compiler will fold out this code. Operands hide differences between instructions: Define (instr_classsfx) { instructions = ( add, addi ); define (operands) { Src1 = GPR(RA); Src2 = GPR(RB); Trg = GPR(RT); }; }

10. Use Case: Development of a New DSP Core Assembler/ disassembler ADL Architecture Team Architectural Exploration Performance Analysis Simulator Compiler Team Pipeline Model XML Database Verification RTL Design Documentation Team

11. Summary And Future Directions • 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).

12. Backup

13. What Is The ADL Project? Architectural Exploration μADL Description Pipeline Description (Pipeline stages, register read/write behavior) ADL Description Programming Model (Registers, MMU, Instructions) Roles For Various Generated Tools Interpreted Functional Simulator Verification Documentation/ Database Cycle-Accurate Simulator Interpreted Functional Simulator Interpreted Functional Simulator Assembler/ Disassembler Documentation (HTML, PDF) Assembler/ Disassembler Software Enablement Cycle-Accurate Simulator XML, Perl Database Documentation/ Database Assembler/ Disassembler Virtual Prototyping Assembler/ Disassembler Trace-cache Fast Functional Simulator Cycle-Accurate Simulator Trace-cache Fast Functional Simulator

14. ADL Model Generation • 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.

15. Use-Case: Verification of a Complex, MP/MT Core DUT Verification Team ADL Model ADL Model ADL Model Core ADL Model Core Core Core Testbench ADL Model Architectural Test-cases (text) Architectural Test-case Generator

16. Future Directions • 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.

17. Summary • 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.