Presentation is loading. Please wait.

Presentation is loading. Please wait.

TM Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobileGT,

Similar presentations


Presentation on theme: "TM Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobileGT,"— Presentation transcript:

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

2 2 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 3 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/ http://opensource.freescale.com/fsl-oss-projects/

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

5 5 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. Arch Spec. Impl. Spec Product Life-cycle Prototype models Random testcase generator Functional testbench Dev Tools: assemblers, compilers, debuggers Bring-up tools: silicon debuggers, etc. Production quality models and dev. tools. Generated Tools ADL Description Product definition, trade-off analysis Pre-silicon verification Post-silicon verification Customer support

6 6 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 7 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; } }; } Instruction Semantics 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. 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. Documentation String Documentation String An Example Register File Declarations: define (regfile=GPR) { """ General purpose registers. """; size = 32; prefix = r; }

8 8 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=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; } } Initial architecture definition: Registers and a sparse register file collection. 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; } } define(arch=B) { define (reg=FOO) {} defmod (regfile=SPR) { define (entry=50) { remove = true; } define (entry=51) { reg = FOO; } } define (core=C) { archs = (A,B); } define (core=C) { archs = (A,B); } Partial architecture modifies the register file, removing one item and overwriting another. Final core definition combines these two architectures 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. 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.

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

10 10 Architecture Team Architecture Team ADL Simulator Assembler/ disassembler Assembler/ disassembler XML Database Architectural Exploration Verification RTL Design Documentation Team Compiler Team Pipeline Model Pipeline Model Performance Analysis

11 11 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 12

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

14 14 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 15 Verification Team ADL Model Testbench ADL Model Architectural Test-case Generator Architectural Test-cases (text) Architectural Test-cases (text) ADL Model DUT Core

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


Download ppt "TM Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C-Ware, the Energy Efficient Solutions logo, Kinetis, mobileGT,"

Similar presentations


Ads by Google