CoreMP7 Product Summary • • • • • • • Verification and Compliance • • Personal Audio (MP3, WMA, and AAC Players) Personal Digital Assistants Wireless Handset Pagers Digital Still Camera Inkjet/Bubble-Jet Printer Monitors Compliant with ARMv4T ISA Compatible with ARM7TDMI-S Core Version • This Datasheet Defines the Functionality for CoreMP7 v1.0. Contents Key Features • • • • • • • • • • • • Introduction ............................................................... 1 Device Utilization ....................................................... 2 General Description ................................................... 3 Programmer’s Model ................................................. 7 AHB Wrapper ........................................................... 12 CoreMP7 Variants ..................................................... 13 Delivery and Deployment ........................................ 14 Bus Functional Model .............................................. 14 AC Parameters .......................................................... 19 Debug ....................................................................... 23 Ordering Information .............................................. 28 List of Changes ......................................................... 28 Datasheet Categories ............................................... 29 FPGA Optimized ARM7™ Family Processor Compatible with ARM7TDMI-S™ 32/16-Bit RISC Architecture (ARMv4T) 32-Bit ARM® Instruction Set 16-Bit Thumb® Instruction Set 32-Bit Unified Bus Interface 3-Stage Pipeline 32-Bit ALU 32-Bit Memory Addressing Range Static Operation EmbeddedICE-RT™ Real-Time Debug Unit JTAG Interface Unit Benefits • • • • Fully Implemented in FPGA Fabric All Microprocessor I/Os Available to User Unified Bus Interface Simplifies SoC Design ARM and Thumb Instruction Sets Can Be Mixed Introduction The CoreMP7 soft IP core is an ARM7 family processor optimized for use in Actel ARM-ready FPGAs and is compatible with the ARM7TDMI-S. Users should refer to the ARM7TDM-S Technical Reference Manual (DDI0234A7TMIS-R4.pdf), published by the ARM Corporation, for detailed information on the ARM7. The ARM7 TRM is available for download from the ARM website at www.arm.com. ARM Supported Families • • ProASIC®3 (M7A3P) Fusion (M7AFS) Synthesis and Simulation Support • • • CoreMP7 is supplied with an Advanced Microcontroller Bus Architecture (AMBA) Advanced High-Performance Bus (AHB) compliant wrapper for inclusion in an AMBA-based processor system such as the one generated by the Actel CoreConsole IP Deployment Platform (IDP). Directly Supported within the Actel Libero® Integrated Design Environment (IDE) Synthesis: Synplify® and Design Compiler® Simulation: Vital-Compliant VHDL Simulators and OVI-Compliant Verilog Simulators July 2007 © 2006 Actel Corporation v 2 .6 1 CoreMP7 ARM7 Family Processor CoreMP7 is a general purpose, 32-bit, ARM7 family microprocessor that offers high performance and low power consumption. The ARM architecture is based on Reduced Instruction Set Computer (RISC) principles. The simplicity of RISC results in a high instruction throughput and fast real-time interrupt response from a small and cost-effective processor core. Pipeline techniques are employed so that all parts of the processing and memory systems can operate continuously. Typically, while one instruction is being executed, its successor is being decoded, and a third instruction is being fetched from memory. The CoreMP7 processor also implements the Thumb instruction set, which makes it ideally suited to high-volume applications with memory restrictions, or applications where code density is an issue. The 16-bit Thumb instruction set approaches twice the density of standard ARM code while retaining most of the ARM performance advantage over a traditional 16-bit processor using 16-bit registers. This is possible because Thumb code operates on the same 32-bit register set as ARM code. Thumb code is able to reduce up to 65% of the code size compared to 32-bit ARM Table 1 • instructions, and offers 160% of the performance of an equivalent ARM processor connected to a 16-bit memory system. Device Utilization CoreMP7 is available with and without debug for use in each ARM-enabled device. These variants (Core only or Core plus debug) are available in CoreConsole and are easily selected from the core configuration menus. The utilization and performance of the variants for each device are shown in Table 1. Core Only This variant of the CoreMP7 is optimized for maximum speed and minimum size and does not include debug. Core Plus Debug This variant of the CoreMP7 is optimized for minimum size and includes debug. CoreMP7 Utilization and Performance Device Variant Performance (MHz) Tiles RAM Block Utilization (%) Core Only 28.12 6,083 4 24.8% Core Plus Debug 21.7 7,931 4 32.3% Core Only 28.08 6,083 4 44.0% Core Plus Debug 20.57 7,931 4 57.4% M7A3P1000 M7AFS600 2 v2.6 CoreMP7 General Description The CoreMP7 processor architecture, core, and functional diagrams are illustrated in the following figures: The CoreMP7 block diagram is shown in Figure 1. The CoreMP7 core is shown in Figure 2 on page 4. The CoreMP7 functional diagram is shown in Figure 3 on page 5. DBGRNG(0) DBGRNG(1) DBGEXT(0) DBGEXT(1) EmbeddedICE-RT Macrocell Scanchain 2 • • • LOCK WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] ADDR[31:0] Coprocessor Interface Signals Scanchain 1 RDATA[31:0] Databus WDATA[31:0] CPU EmbeddedICE-RT TAP Controller DBGTCKEN DBGTMS DBGnTRST DBGTDI DBGTDO Figure 1 • CoreMP7 Top-Level Block Diagram v2.6 3 CoreMP7 PC Bus Address Register Address Incrementer Incrementer Bus ADDR[31:0] Multiplier A Bus ALU Bus Register Bank Instruction Decoder and Control Logic ALU Write Data Register WDATA[31:0] Figure 2 • 4 B Bus Shifter Instruction Pipeline Read Data Register Thumb Instruction Decoder RDATA[31:0] CoreMP7 CPU Block Diagram v2.6 CLK CLKEN CFGBIGEND nIRQ nFIQ nRESET ABORT LOCK WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] DBG Outputs DBG Input CP Control CP Handshake CoreMP7 DBGTCKEN Clock CLK DBGTMS CLKEN DBGTDI Synchronized EmbeddedICE-RT Scan Debug Access Port DBGnTRST Interrupts nIRQ DBGTDO nFIQ DBGnTDOEN nRESET Bus Control ADDR[31:0] CFGBIGEND WDATA[31:0] RDATA[31:0] DMORE Memory Interface ABORT Arbitration CoreARM7 LOCK WRITE SIZE[1:0] DBGINSTRVALID PROT[1:0] TRANS[1:0] DBGRQ DBGBREAK DBGACK CPnTRANS DBGnEXEC CPnOPC Memory Management Interface DBGEXT[1] Debug Figure 3 • DBGEXT[0] CPnMREQ DBGEN CPSEQ DBGRNG[1] CPTBIT DBGRNG[0] CPnl DBGCOMMRX CPA DBGCOMMTX CPB Coprocessor Interface CoreMP7 Functional Diagram The signals of the CoreMP7 are listed in Table 2. Table 2 • Signal Descriptions Name Type Description ABORT Input Memory abort or bus error CFGBIGEND Input Big/Little Endian configuration CLK Input Clock CLKEN Input Clock enable CPA Input Coprocessor absent CPB Input Coprocessor busy DBGBREAK Input EICE breakpoint/watchband indicator DBGEN Input Debug enable DBGEXT[1:0] Input EICE external input 0 Note: The CoreMP7 is available with either the native ARM7 bus interface or with an AHB wrapper. The use of the AHB wrapper changes or transforms some of the signals in Table 2. This is discussed in detail later in this document. v2.6 5 CoreMP7 Table 2 • Signal Descriptions (Continued) Name Type Description DBGnTRST Input Test reset DBGRQ Input Debug request DBGTCKEN Input Test clock enable DBGTDI Input EICE data in DBGTMS Input EICE mode select nFIQ Input Interrupt request nIRQ Input Fast interrupt request nRESET Input Reset RDATA[31:0] Input Read data bus ADDR[31:0] Output Address bus CPnI Output Coprocessor instruction (asserted low) CPnMREQ Output Memory request (asserted low) CPnOPC Output Opcode fetch (asserted low) CPnTRANS Output Memory translate (asserted low) CPSEQ Output Sequential address CPTBIT Output Processor in Thumb mode DBGACK Output Debug acknowledge DBGCOMMRX Output EICE communication channel receive DBGCOMMTX Output EICE communication channel transmit DBGnEXEC Output Executed (asserted low) DBGnTDOEN Output TDO enable (asserted low) DBGRNG[1:0] Output EICE rangeout DBGTDO Output EICE data out DBGINSTRVALID Output ETM Instruction valid indicator DMORE Output Set when next data memory access is followed by a sequential data memory access LOCK Output Locked transaction operation PROT[1:0] Output Indicates code, data, or privilege level SIZE[1:0] Output Memory access width TRANS Output Next transaction type (i, n, s) WDATA[31:0] Output Write data bus WRITE Output Indicates write access Note: The CoreMP7 is available with either the native ARM7 bus interface or with an AHB wrapper. The use of the AHB wrapper changes or transforms some of the signals in Table 2. This is discussed in detail later in this document. 6 v2.6 CoreMP7 Programmer’s Model You must align these as follows: • This section summarizes the programmer’s model of the CoreMP7. Supporting detail is available in the ARM ARM7TDMI-S Technical Reference Manual (available for download at www.arm.com) and the ARM Architecture Reference Manual, which can be purchased at www.amazon.com. • • The CoreMP7 processor implements the ARMv4T architecture and includes both the 32-bit ARM instruction set and the 16-bit Thumb instruction set. Operating Modes The CoreMP7 processor has seven operating modes: • Processor Operating States The CoreMP7 processor has two operating states: • ARM state: 32-bit, word-aligned ARM instructions are executed in this state. • Thumb state: 16-bit, halfword-aligned Thumb instructions are executed in this state. • In Thumb state, the Program Counter (PC) uses bit 1 to select between alternate halfwords. • Note: Transition between ARM and Thumb states does not affect the processor mode or the register contents. • Switching State • You can switch the operating state of the CoreMP7 between ARM state and Thumb state using the BX instruction. This is described fully in the ARM Architecture Reference Manual. Registers The CoreMP7 processor has a total of 37 registers: • • Memory Formats The CoreMP7 processor views memory as a linear collection of bytes, numbered in ascending order from zero: 31 general-purpose 32-bit registers 6 status registers These registers are not all accessible at the same time. The processor state and operating mode determine which registers are available to the programmer. Bytes 0 to 3 hold the first stored word. Bytes 4 to 7 hold the second stored word. Bytes 8 to 11 hold the third stored word. The ARM State Register Set In ARM state, 16 general registers and one or two status registers are accessible at any one time. In privileged modes, mode-specific banked registers become available. Figure 4 on page 8 shows which registers are available in each mode. Although both Little Endian and Big Endian memory formats are supported, it is recommended that you use Little Endian format. The ARM state register set contains 16 directly accessible registers, r0 to r15. An additional register, the Current Program Status Register (CPSR), contains condition code flags, and the current mode bits. Registers r0 to r13 are general-purpose registers used to hold either data or address values. Registers r14 and r15 have special functions as the Link Register and Program Counter. Data Types The CoreMP7 processor supports the following data types: • • • User mode is the usual ARM program execution state, and is used for executing most application programs. Fast interrupt (FIQ) mode supports a data transfer or channel process. Interrupt (IRQ) mode is used for general-purpose interrupt handling. Supervisor mode is a protected mode for the operating system. Abort mode is entered after a data or instruction prefetch abort. System mode is a privileged user mode for the operating system. Undefined mode is entered when an undefined instruction is executed. Modes other than User mode are collectively known as privileged modes. Privileged modes are used to service interrupts or exceptions, or to access protected resources. All exception handling is performed in ARM state. If an exception occurs in Thumb state, the processor reverts to ARM state. The transition back to Thumb state occurs automatically on return. • • • Word quantities must be aligned to four-byte boundaries. Halfword quantities must be aligned to two-byte boundaries. Byte quantities can be placed on any byte boundary. Word (32-bit) Halfword (16-bit) Byte (8-bit) v2.6 7 CoreMP7 Link Register Register 14 is used as the subroutine Link Register (LR). Register 14 (r14) receives a copy of r15 when a Branch with Link (BL) instruction is executed. At all other times, you can treat r14 as a generalpurpose register. The corresponding banked registers—r14_svc, r14_irq, r14_fiq, r14_abt, and r14_und—are similarly used to hold the return values of r15 when interrupts and exceptions arise, or when BL instructions are executed within interrupt or exception routines. Program Counter Register 15 holds the Program Counter (PC). In ARM state, bits [1:0] of r15 are zero. Bits [31:2] contain the PC. In Thumb state, bit [0] is zero. Bits [31:1] contain the PC. In privileged modes, another register, the Saved Program Status Register (SPSR), is accessible. This contains the condition code flags, and the mode bits saved as a result of the exception that caused entry to the current mode. Figure 4 shows the ARM state registers. ARM State General Registers and Program Counter System and User FIQ Supervisor Abort IRQ Undefined r0 r0 r0 r0 r0 r0 r1 r1 r1 r1 r1 r1 r2 r2 r2 r2 r2 r2 r3 r3 r3 r3 r3 r3 r4 r4 r4 r4 r4 r4 r5 r5 r5 r5 r5 r5 r6 r6 r6 r6 r6 r6 r7 r7 r7 r7 r7 r7 r8 r8_fiq r8 r8 r8 r8 r9 r9_fiq r9 r9 r9 r9 r10 r10_fiq r10 r10 r10 r10 r11 r11_fiq r11 r11 r11 r11 r12 r12_fiq r12 r12 r12 r12 r13 r13_fiq r13_svc r13_abt r13_irq r13_und r14 r14_fiq r14_svc r14_abt r14_irq r14_und r15 (PC) r15 (PC) r15 (PC) r15 (PC) r15 (PC) r15 (PC) ARM State Program Status Registers CPSR CPSR CPSR CPSR CPSR CPSR SPSR_fiq SPSR_svc SPSR_abt SPSR_irq SPSR_und = banked register Figure 4 • 8 CoreMP7 Register Organization in the ARM State v2.6 CoreMP7 The Thumb State Register Set The Thumb state register set is a subset of the ARM state set. The programmer has direct access to the following: • • • • • Eight general registers, r0–r7 The PC A Stack Pointer (SP) A Link Register (LR) The CPSR There are banked SPs, LRs, and SPSRs for each privileged mode. The Thumb state register set is shown in Figure 5. Thumb State General Registers and Program Counter System and User FIQ Supervisor Abort IRQ Undefined r0 r0 r0 r0 r0 r0 r1 r1 r1 r1 r1 r1 r2 r2 r2 r2 r2 r2 r3 r3 r3 r3 r3 r3 r4 r4 r4 r4 r4 r4 r5 r5 r5 r5 r5 r5 r6 r6 r6 r6 r6 r6 r7 r7 r7 r7 r7 r7 SP SP_fiq SP_svc SP_abt SP_irq SP_und LR LR_fiq LR_svc LR_abt LR_irq LR_und PC PC PC PC PC PC Thumb State Program Status Registers CPSR CPSR CPSR CPSR CPSR CPSR SPSR_fiq SPSR_svc SPSR_abt SPSR_irq SPSR_und = banked register Figure 5 • CoreMP7 Thumb State Registers v2.6 9 CoreMP7 The Relationship Between ARM State and Thumb State Registers The Thumb state registers relate to the ARM state registers in the following way: • • • • • Thumb state r0–r7 and ARM state r0–r7 are identical. Thumb state CPSR and SPSR, and ARM state CPSR and SPSR are identical. Thumb state SP maps onto ARM state r13. Thumb state LR maps onto ARM state r14. The Thumb state PC maps onto the ARM state PC (r15). These relationships are shown in Figure 6. Stack Pointer (PC) Link Register (LR) Program Counter (PC) ARM State r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 Stack Pointer (r13) Link Register (r14) Program Counter (r15) Current Program Status Register (CPSR) Current Program Status Register (CPSR) Saved Program Status Register (SPSR) Saved Program Status Register (SPSR) Thumb State r0 r1 r2 r3 r4 r5 r6 r7 Figure 6 • Mapping of Thumb State Registers to ARM State Registers Note: Registers r0–r7 are known as the low registers. Registers r8–r15 are known as the high registers. 10 v2.6 CoreMP7 The Program Status Registers The CoreMP7 core contains a CPSR and five SPSRs for exception handlers to use. The program status registers the following: • • • Hold the condition code flags Control the enabling and disabling of interrupts Set the processor operating mode The arrangement of bits is shown in Figure 7. Condition Code Flags Reserved Control Bits 8 31 30 29 28 27 26 25 24 23 N Z C V Overflow Carry or Borrow or Extend Zero Negative or Less Than Figure 7 • 7 6 5 4 3 2 1 0 I F T M4 M3 M2 M1 M0 Mode Bits State Bit FIQ Disable IRQ Disable Program Status Register Format The Condition Code Flags The N, Z, C, and V bits are the condition code flags. You can set these bits by arithmetic and logical operations. The flags can also be set by MSR and LDM instructions. The CoreMP7 processor tests these flags to determine whether to execute an instruction. All instructions can be executed conditionally in ARM state. In Thumb state, only the Branch instruction can be executed conditionally. For more information about conditional execution, see the ARM Architecture Reference Manual. v2.6 11 CoreMP7 AHB Wrapper The AHB wrapper interfaces between the CoreMP7 native ARM7 interface and the AHB bus. The module translates access from the core to AHB accesses when the core is the current master. The external interface signals from the wrapper are described in Table 3. Table 3 • AHB Wrapper External Interface Signal External Master I/F Direction Description HCLK Input Bus clock. This clock times all bus transfers. All signal timings are related to the rising edge of HCLK. HRESETn Input Reset. The bus reset signal is active LOW and is used to reset the system and the bus. This is the only active LOW AHB signal. HREADY Input Transfer done. When HIGH the HREADY signal indicates that a transfer has finished on the bus. This signal can be driven LOW to extend a transfer. HRESP[1:0] Input Transfer response. Indicates an OKAY, ERROR, RETRY, or SPLIT response. HGRANT Input Bus grant. Indicates that the CoreMP7 is currently the highest priority master. Ownership of the address/control signals changes at the end of a transfer when HREADY is HIGH, so a master gains access to the bus when both HREADY and HGRANT are HIGH. HADDR[31:0] Output This is the 32-bit system address bus. HTRANS[1:0] Output Transfer type. Indicates the type of the current transfer. HWRITE Output Transfer direction. When HIGH this signal indicates a write transfer and when LOW a read transfer. HSIZE[2:0] Output Transfer size. Indicates the size of the transfer, which can be byte (8-bit), halfword (16bit), or word (32-bit). HBURST[2:0] Output Burst type. Indicates if the transfer forms part of a burst. The CoreMP7 performs incrementing bursts of type INCR. HPROT[3:0] Output Protection control. These signals indicate if the transfer is an opcode fetch or data access, and if the transfer is a Supervisor mode access or User mode access. HWDATA[31:0] Output 32-bit data from the MASTER. HRDATA[31:0] Input 12 32-bit data written back to the MASTER. v2.6 CoreMP7 CoreMP7 Variants There are two implementations of CoreMP7 (Core Only and Core Plus Debug). The utilization and performance of the variants are shown in Table 1 on page 2. Debug Interface Debug JTAG Signals ARM7TDMI-S Core Debug TAP Controller EmbeddedICE-RT (Debug) Bus Control Signals ARM7 CPU Address Coprocessor Signals Data Figure 8 • ARM7 TDMI-S Core Core Plus Debug No Coprocessor Interface The Core Plus Debug variant is configured with all features of the ARM7TDMI-S. The variant incorporates the full debug functionality of the ARM7TDMI-S and is fully compliant with RealView RVDS, RVDK, and other ARM software debug tools. The coprocessor interface is a rarely used feature in ARM7 family microprocessors and has been removed from CoreMP7 to minimize area. Little Endian Only Most microprocessor-based systems use Little Endian byte ordering. The option of selecting Big Endian has been removed from CoreMP7 to minimize area. Core Only The Core Only variant has the same features as the Core Plus Debug variant except that it does not include the ICE-RT debug block or the TAP controller, which reduces the size of the core. This means that the standard debug tools cannot be used with this variant of CoreMP7. On-Chip RAM Consumed by Register Block To minimize the area, the CoreMP7 variants map the processor register block into on-chip RAM. RAM blocks used to implement CoreMP7 registers are no longer available for use in user designs. No Debug This is the most obvious characteristic of the Core Only variant. To reduce area, the Debug EmbeddedICE-RT macrocell, the EmbeddedICE-RT TAP controller, and the scan logic have been optimized out. This means that standard software debug tools cannot be used when this variant of the CoreMP7 is instantiated. Users can employ the Core Plus Debug variant for development, and when the application has been fully tested and debugged, the Core Only variant can be instantiated to reduce area in the final shipping product. v2.6 13 CoreMP7 Delivery and Deployment and the system memory map presented to the ARM7 by the rest of the hardware. The CoreMP7 is delivered in CoreConsole, and can be instantiated in design projects created in Libero IDE. The files included with CoreMP7 consist of the Bus Functional Model (BFM) files and test wrapper, AHB wrapper, and the A7S secured CDB file. The A7S secured CDB file is instantiated on the user device at programming. This deployment flow is implemented to ensure that the design is kept completely secure at all times, and allows CoreMP7 to be easily used with the standard design flow through the Libero IDE tool suite. This document specifies the following aspects of the ARM7 BFM: During the development of an FPGA-based SoC, a number of stages of testing may be undertaken. This can involve some, or all, of the following approaches: • Hardware simulation, using Verilog or VHDL Software simulation, using a host-based instruction set simulator (ISS) of the SoC's processor Hardware and software co-verification, using a fully functional model of the processor in Verilog, VHDL, or SWIFT form, or using a tool such as Seamless Due to the rapid prototyping capability of FPGAs, however, integration of hardware and software often occurs earlier in the SoC development cycle for FPGA targets than it would for ASIC targets. Therefore, hardware and software co-verification, which can be very slow, is not a critical issue except in the most complex FPGA-based SoCs. The planned availability of ARM-based SoC solutions to Actel FPGA customers necessitates that Actel provide support for the test approaches described above. In particular, there should be an emphasis on providing solutions for hardware simulation and for software simulation. A software simulation solution is already available to customers as part of the proposed ARM package. This package contains the RealView Instruction Set Simulator, which provides ARM7 instruction accurate simulation, as well as powerful features, such as integration with the RealView debugger. Support for hardware simulation is also proposed. The CoreConsole SoC configuration utility provides a means for the developer to stitch together IP blocks using a bus fabric of choice. It generates a system testbench, controlled by a script-driven, bus functional model (BFM) of the ARM7 processor. The ARM7 BFM allows the developer to model low-level bus transactions, which allow verification of connectivity of the various IP blocks 14 Functionality BFM usage flow BFM script language Platforms Supported simulation tools Example BFM use case BFM Usage Flow Bus Functional Model • • • • • • • • v2.6 As the BFM is part of an overall system test strategy, it is helpful to look at the context in which it is used. Figure 9 on page 15 shows the various components within an example system-level testbench that can be generated by CoreConsole. In Figure 9 on page 15, it is assumed that the developer specifies an SoC subsystem by selecting the processor, bus fabric, IP blocks, and memory subsystem in CoreConsole. In this example, the user selects the following: • • • • • ARM7 processor, AMBA AHB bus fabric MAC 10/100 IP core CoreUART IP core External SSRAM and Flash memory As a result of constructing the CoreConsole subsystem, the memory map for the system is created. Based on this information, CoreConsole generates the following outputs, among others: • • • • • Verilog/VHDL model of SoC subsystem Verilog/VHDL models of IP cores Verilog/VHDL model of ARM7 BFM BFM test script System-level skeleton testbench The BFM acts as a pin-for-pin replacement of the ARM7TDMI-S in the SoC subsystem. It initiates bus transactions on the native ARM7 bus, which are cycleaccurate with real bus cycles that the ARM7TDMI-S would produce. It has no knowledge, however, of real ARM7 instructions. At this point, the BFM may be used to run a basic test of the SoC subsystem using the skeleton system testbench. The BFM is fully integrated into the CoreConsole user flow. In particular, if the user has an AHB-based CoreMP7 subsystem, CoreConsole automatically derives the memory map of the user's subsystem. CoreConsole uses this information to generate an overall BFM test script, which includes customized "scriptlets" for each resource attached to the AHB or APB buses. CoreMP7 SoC System Testbench SoC W rapper SoC Subsystem BFM Test Script Memory Controller ARM7 BFM ARM7-AHB Bridge SSRAM BFM Log File CoreUART MAC 10/100 Flash Video Codec UserDefined Tasks and Function Figure 9 • Video Test Stub MAC Test Stub SoC System-Level Testbench Example The developer may edit the SoC Verilog/VHDL to add new design blocks, such as the VideoCodec in the above diagram. The system-level testbench may also be filled out by the developer to include tasks that test any newly added functionality or additional stubs that allow more complex system testing involving the IP cores. The BFM input scripts may also be manually enhanced to allow the user to test access to register locations in newly added logic. In this way, the user can provide stimuli to the system from the inside (via the ARM7 BFM), as well as from the outside (via testbench tasks). Figure 10 shows the design flow into which the BFM fits. User Input Memory Map Definition IP Cores Selection Bus Fabric Selection Actel IP Core Attributes (SPIRIT) Core Console BFM Test Script SoC System Testbench BFM Log File Figure 10 • BFM Flow Diagram v2.6 15 CoreMP7 Functionality This section describes the specific functionality of the ARM7 BFM. The BFM models the ARM7 native bus. Specifically, this models the following bus signals: • ADDR, // address bus • WDATA, // write data bus • RDATA, // read data bus • TRANS, // next transaction type (i, n, or s) • WRITE, // indicates write access memmap • CLKEN, // clock enable This command is used to associate a label, representing a system resource, with a memory map location. The other BFM script commands may perform accesses to locations within this resource by referencing this label and a register offset relative to this base address. BFM Script Language The following script commands are defined for use by the BFM: The BFM also models the following control signals: • CFGBIGEND, // big/little endian configuration • CLK, • nFIQ, // interrupt request • nIRQ, // fast interrupt request • SIZE, // memory access width // clock Syntax memmap resource_name base_address; resource_name CoreConsole v1.1 ARM7 Pin Compatibility The BFM model is pin-for-pin compatible with the ARM7TDMI-S. This allows the model to be dropped into the space that would be occupied by the ARM in the Verilog/VHDL system testbench. ARM7 Bus Cycle Accuracy The bus cycle timings for the ARM7 native bus signals are specified in the ARM7TDMI Technical Reference Manual. The BFM models these bus cycles exactly. Scripting In order to provide a simple and extensible mechanism for providing stimuli to the BFM, a BFM scripting language is defined (see the "BFM Script Language" section). The scripting language can initiate writes to system resources, reads from system resources (with or without checking of expected data), and can wait for events. Self-Checking The BFM gives a pass/fail indication at the end of a test run. This is based on whether any of the expected data read checks failed or not. Endianess The BFM supports both big and little-endian memory configurations. For byte and halfword transfers, it reads and writes data from/to the appropriate data lanes. Interrupt Support The BFM has the ability to wait for either of the two ARM7 interrupt lines to be triggered, before proceeding with the remainder of the test script. 16 Log File Generation The BFM generates output messages to the console of the simulation tool and also generates a plain text log file. v2.6 This is a string containing the user-friendly instance name of the resource being accessed. For BFM scripts generated automatically by CoreConsole, this name corresponds to the instance name of the associated core in the generated subsystem Verilog or VHDL. base_address This is the base address of the resource, in hexadecimal. write This command causes the BFM to perform a write to a specified offset, within the memory map range of a specified system resource. Syntax write width resource_name byte_offset data; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. data This is the data to be written. It is specified as a hexadecimal value. Example write W videoCodec 20 11223344; CoreMP7 read Syntax poll width resource_name byte_offset data_bitmask; This command causes the BFM to perform a read of a specified offset, within the memory map range of a specified system resource. width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. Syntax read width resource_name byte_offset; resource_name This is a string containing the user-friendly instance name of the resource being accessed. width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). bitmask The bitmask is ANDed with the read data and the result is then compared to the bitmask itself. If equal, then all the bits of interest are at their required value and the poll command is complete. If not equal, then the polling continues. byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. Example read W videoCodec 20; wait This command causes the BFM script to stall for a specified number of clock periods. readcheck This command causes the BFM to perform a read of a specified offset, within the memory map range of a specified system resource, and to compare the read value with the expected value provided. Syntax wait num_clock_ticks; num_clock_ticks This is the number of CoreMP7 clock periods, during which the BFM stalls (doesn't initiate any bus transactions). Syntax readcheck width resource_name byte_offset data; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. waitfiq This command causes the BFM to wait until an interrupt event (high to low transition) is seen on the nFIQ pin before proceeding with the execution of the remainder of the script. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). Syntax waitfiq; byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. waitirq This command causes the BFM to wait until an interrupt event (high to low transition) is seen on the nIRQ pin before proceeding with the execution of the remainder of the script. data This is the expected read data. It is specified as a hexadecimal value. Example readcheck W videoCodec 20 11223344; Syntax waitirq; poll Supported Simulation Tools This command continuously reads a specified location until a requested value is obtained. This command allows one or more bits of the read data to be masked out. This allows, for example, poll waiting for a ready bit to be set, while ignoring the values of the other bits in the location being read. BFM is delivered to the user as both a Verilog and VHDL model. v2.6 17 CoreMP7 Timing Shell Table 5 • The BFM incorporates a timing shell, which performs setup/hold checks on inputs and delays outputs by the appropriate amount from the rising clock edge. Resource Memory Map Information Actel IP Core Address Range ssram N 0-3fffff flash N 400000-7fffff Example BFM Use Case uart Y c00000-c0000b This provides an example use case of the ARM7 BFM. The example SoC used in this section is the same as that shown in Figure 9 on page 15. In this system, the developer requires two Actel IP cores: the MAC 10/100 and the CoreUART. mac Y d00000-d00040 videocodec N e00000-e000ff SPIRIT Attributes CoreConsole has access to a database of Actel IP cores and a list of attributes for each core. These attributes are organized according to the SPIRIT specification, in XML. For example, in the case of the CoreUART, the attributes would indicate that there are three registers, as in Table 4. Table 4 • Offset CoreUART Attributes Register Read/Write Width 0 Uart Status Register R Byte 1 Uart Tx data W Byte 2 Uart Rx data R Byte In this example, the user selects an ARM7 as the processor of choice in CoreConsole. The BFM in this specification only relates to ARM7. Bus Fabric Selection The user may select one of a number of bus fabrics in CoreConsole. For example, the user could select AMBA AHB-Lite. However, this selection is irrelevant for the ARM7 BFM, as it is concerned only with generating native ARM7 bus based transactions. Automatic BFM Scriptlet At this point, having run CoreConsole to completion, a BFM scriptlet is available. This would look something like the following: read B uart 0; Based on these attributes, CoreConsole can determine that when generating the BFM script, there are three locations corresponding to the UART that can be accessed. In this case, none of the registers are RW, so there will not be any self-checking that can be performed for the UART. Nevertheless, the bus transactions do take place and the cycles may be viewed in a waveform of the simulator. Memory Map The designer must feed in the memory map of the SoC to CoreConsole. During this stage, the absolute address ranges of the various system resources in the ARM7 memory map are fed in. Also, user-friendly instance names of these resources are fed in. For example, the user could feed the memory map information into CoreConsole that is given in Table 5. Based on the information in Table 5, CoreConsole generates the SoC subsystem corresponding to the Actel IP cores present. It also generates a BFM script, which accesses all the registers in the Actel IP cores. 18 Processor Choice v2.6 write B uart 4 bb; read B uart 8; write B mac 30 11; readcheck B mac 11; Run BFM The developer can run the BFM with the automatic script or edit the script to put in bus transactions to/from any new logic that has been added to the SoC. For example, transactions to/from the registers in the new VideoCodec block could be added. The skeleton system-level testbench, generated by CoreConsole, could also be modified, to add some external resources (e.g., models of SSRAM and Flash) and some high-level tasks. Upon running the system simulation, messages appear in the console window of the simulation tool. CoreMP7 AC Parameters This section gives the AC timing parameters of the CoreMP7 processor. Timing Diagrams Timing diagrams are shown in Figure 11, Figure 12 on page 20, Figure 13 on page 20, Figure 14 on page 21, and Figure 15 on page 21. Data Access Timing CLK TRANS[1:0] TRANS tovtrans tohtrans ADDR[31:0] Addr tovaddr WRITE SIZE[1:0] PROT[1:0] tohaddr Ctrl tohctl tovctl WDATA[31:0] (write data) tovwdata tohwdata CLKEN tisclken tihclken ABORT tisabort tihabort RDATA[31:0] (read data) Data tisrdata tihrdata Figure 11 • Data Access Timing v2.6 19 CoreMP7 Coprocessor Timing The Coprocessor timing is included for completeness although it is expected that the Coprocessor interface is omitted in most deployments of the CoreMP7. CLK CPA CPB tiscpstart tihcpstart CPnl tohcpni tovcpni CPnMREQ CPSEQ CPnOPC CPnTRANS CPTBIT Figure 12 • tovcpcil tohcpcil tovcpcil tohcpcil Coprocessor Timing Exception Timing CLK nFIQ nIRQ tisexc tihexc nRESET tisexc tihexc CFGBIGEND tiscfg tihcfg Figure 13 • 20 Exception Timing v2.6 CoreMP7 Debug Timing CLK DBGRQ tisdbgctl tihdbgctl DBGBREAK tisdbgctl tihdbgctl DBGEXT[1:0] tisdbgctl tihdbgctl DBGACK DBGCOMMTX DBGCOMMRX tovdbgstart tohdbgstart DBGRNG[1:0] tohdbgstart tovdbgstart Figure 14 • Debug Timing Scan Timing CLK DBGTCKEN tslcken tlhocken DBGTMS DBGTDI tslcil tlhocil DBGTDO tovido Figure 15 • tohido Scan Timing v2.6 21 CoreMP7 AC Timing Parameter Definitions Table 6 shows target AC parameters. All figures are expressed as percentages of the CLK period at maximum operating frequency. Note: Where 0% is shown, this indicates the hold time to clock edge plus the maximum clock skew for internal clock buffering. Table 6 • AC Timing Parameters Symbol Parameter Min Max tCYC CLK cycle time 100% – tISCLKEN CLKEN input setup to rising CLK 60% – tIHCLKEN CLKEN input hold from rising CLK – See notes 1, 2 tISABORT ABORT input setup to rising CLK 40% – tIHABORT ABORT input hold from rising CLK – 0% tISRDATA RDATA input setup to rising CLK 10% – tISRST nRESET input setup to rising CLK 90% – tISTRST DBGnTRST input setup to rising CLK 25% tIHRDATA RDATA input hold from rising CLK – See notes 3, 4 tOCPTBIT Rising CLK to CPTBIT valid – 90% tODBG Rising CLK to DBGnEXEC, DBGINSTRVALID valid – 40% tOLOMO Rising CLK to DMORE, LOCK valid – 90% tOVADDR Rising CLK to ADDR valid – 90% tOHADDR ADDR hold time from rising CLK >0% – tOVCTL Rising CLK to control valid – 90% tOHCTL Control hold time from rising CLK >0% – tOVTRANS Rising CLK to transaction type valid – 50% tOHTRANS Transaction type hold time from rising CLK >0% – tOVWDATA Rising CLK to WDATA valid – 40% tOHWDATA WDATA hold time from rising CLK >0% – tISCPSTAT CPA, CPB input setup to rising CLK 20% – tIHCPSTAT CPA, CPB input hold from rising CLK – 0% tOVCPCTL Rising CLK to coprocessor control valid – 80% tOHCPCTL Coprocessor control hold time from rising CLK >0% – tOVCPNI Rising CLK to coprocessor CPnI valid – 40% tOHCPNI Coprocessor CPnI hold time from rising CLK >0% – tISEXC nFIQ, nIRQ, input setup to rising CLK 10% – Notes: 1. tIHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. tIHCLKEN is 1 ns for the Core Only variant in all devices. 3. tIHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. tIHRDATA is 1 ns for Core Only variant in all devices. 22 v2.6 CoreMP7 Table 6 • AC Timing Parameters (Continued) Symbol Parameter Min Max – 0% 10% – – 0% tIHEXC nFIQ, nIRQ, nRESET hold from rising CLK tISCFG CFGBIGEND setup to rising CLK tIHCFG CFGBIGEND hold from rising CLK tISDBGCTL DBGBREAK, DBGEXT, DBGRQ input setup to rising CLK 10% – tISDBGSTAT Debug status inputs setup to rising CLK 10% – tIHDBGSTAT Debug status inputs hold from rising CLK – 0% tOVDBGCTL Rising CLK to debug control valid – 40% tOHDBCTL Debug control hold time from rising CLK >0% – tISTCLKEN DBGTCKEN input setup to rising CLK 60%‘ – tIHTCKEN DBGTCKEN input hold from rising CLK – 0% tISTCTL DBGTDI, DBGTMS input setup to rising CLK 35% – tIHTCTL DBGTDI, DBGTMS input hold from rising CLK – 0% tOVTDO Rising CLK to DBGTDO valid – 20% tOHTDO DBGTDO hold time from rising CLK >0% – tOVDBGSTAT Rising CLK to debug status valid 40% – tOHDBGSTAT Debug status hold time >0% – Notes: 1. tIHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. tIHCLKEN is 1 ns for the Core Only variant in all devices. 3. tIHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. tIHRDATA is 1 ns for Core Only variant in all devices. Debug an instruction set simulator that runs on the debugger host. In each case the debugging environment is the same. The ARM Debug Architecture uses a protocol converter box to allow the debugger to talk via a Joint Test Action Group (JTAG) port directly to the core. In effect, the scan chains in the core that are required for test are re-used for debugging. The advantages of using the JTAG port are: • • The architecture uses the scan chains to insert instructions directly in to the ARM core. The instructions are executed on the core and, depending on the type of instruction that has been inserted, the core or the system state can be examined, saved, or changed. The architecture has the ability to execute instructions at a slow debug speed or to execute instructions at system speed (for example, if access to an external memory was required). • Hardware access required by a system for test is reused for debug. Core state and system state can be examined via the JTAG port. The target system does not have to be running in order to start debug. A monitor program for example requires that some target resources are running in order for the monitor program to run. • The fact that the debugger is actually using the JTAG scan chains to access the core is of no importance to the user, as the front end debugger remains exactly the same. The user could still use the debugger with a monitor program running on the target system or with • • v2.6 Traditional breakpoints and watchpoints are available. On-chip resources can be supplemented. For example, the ARM Debug Architecture uses an on-chip macro-cell to enhance the debugging facilities available. 23 CoreMP7 • A separate UART to communicate with the monitor program is not required. The debugging of the target system requires the following: • • A PC host computer running Windows to run the debugger software An EmbeddedICE Protocol Converter, a separate box which converts the serial interface to signals compatible with the JTAG interface and a target system with a JTAG interface and an ARM Debug Architecture compliant core. Once the system is connected, the debugger can start communicating with the target system via the RVI-ME (which is an EmbeddedICE Interface Converter). The debug extensions consist of several scan chains around the processor core, and some additional signals that are used to control the behavior of the core for debug purposes. The most significant of these additional signals are as follows: BREAKPT: This core signal enables external hardware to halt processor execution for debug purposes. When HIGH during an instruction fetch, the instruction is tagged as breakpointed, and the core stops if this instruction reaches execute. Figure 16 • 24 DBGRQ: This core signal is a level-sensitive input that causes the CPU core to enter debug state when the current instruction has completed. DBGACK: This core signal is an output from the CPU core that goes HIGH when the core is in debug state so that external devices can determine the current state of the core. RealView ICE uses these, and other signals, through the debug interface of the processor core, for example by writing to the control register of the EmbeddedICE logic. For more details, refer to the debug interface section of the ARM datasheet or technical reference manual for your core. JTAG Debug Interface The RVI-ME ICE run control unit is supplied with a short ribbon cable. These both terminate in a 20-way 2.54 mm pitch IDC connector. You can use the cable to mate with a keyed box header on the target. The pinout is shown in Figure 16. VTref 1 2 Vsupply nTRST 3 4 GND TDI 5 6 GND TMS 7 8 GND TCK 9 10 GND RTCK 11 12 GND TDO 13 14 GND nSRST 15 16 GND DBGRQ 17 18 GND DBGACK 19 20 GND JTAG Interface Pinout v2.6 CoreMP7 The signals on the JTAG interface are shown in Table 7. Table 7 • Signal JTAG Signals I/O Description DBGACK – This pin is connected in the RealView ICE run control unit, but is not supported in the current release of the software. It is reserved for compatibility with other equipment to be used as a debug acknowledge signal from the target system. It is recommended that this signal is pulled LOW on the target. DBGRQ – This pin is connected in the RealView ICE run control unit, but is not supported in the current release of the software. It is reserved for compatibility with other equipment to be used as a debug request signal to the target system. This signal is tied LOW. When applicable, RealView ICE uses the core's scanchain 2 to put the core in debug state. It is recommended that this signal is pulled LOW on the target. GND – Ground nSRST Input/ Output Open collector output from RealView ICE to the target system reset. This is also an input to RealView ICE so that a reset initiated on the target can be reported to the debugger. This pin must be pulled HIGH on the target to avoid unintentional resets when there is no connection. nTRST Output Open collector output from RealView ICE to the Reset signal on the target JTAG port. This pin must be pulled HIGH on the target to avoid unintentional resets when there is no connection. RTCK Input Return Test Clock signal from the target JTAG port to RealView ICE. Some targets must synchronize the JTAG inputs to internal clocks. To assist in meeting this requirement, you can use a returned, and retimed, TCK to dynamically control the TCK rate. RealView ICE provides Adaptive Clock Timing that waits for TCK changes to be echoed correctly before making further changes. Targets that do not have to process TCK can simply ground this pin. TCK Output Test Clock signal from RealView ICE to the target JTAG port. It is recommended that this pin is pulled LOW on the target. TDI Output Test Data In signal from RealView ICE to the target JTAG port. It is recommended that this pin is pulled HIGH on the target. TDO Input Test Data Out from the target JTAG port to RealView ICE. It is recommended that this pin is pulled HIGH on the target. TMS Output Test Mode signal from RealView ICE to the target JTAG port. This pin must be pulled HIGH on the target so that the effect of any spurious TCKs when there is no connection is benign. Vsupply Input This pin is not connected in the RealView ICE run control unit. It is reserved for compatibility with other equipment to be used as a power feed from the target system. VTref Input This is the target reference voltage. It indicates that the target has power, and it must be at least 0.628 V. VTref is normally fed from Vdd on the target hardware and might have a series resistor (though this is not recommended). There is a 10 k pull-down resistor on VTref in RealView ICE. v2.6 25 CoreMP7 The EmbeddedICE logic which implements the on-chip debug function in the CoreMP7 debug architecture is described in detail in the ARM7TDMI-S (rev 4) Technical Reference Manual (ARM DDI0234A), published by ARM Limited, and is available via Internet at www.arm.com. The CoreMP7 debug architecture uses a JTAG port as a method of accessing the core. The debug architecture uses EmbeddedICE logic which resides on chip with the CoreMP7 core. The EmbeddedICE has its own scan chain that is used to insert watchpoints and breakpoints for the CoreMP7. The EmbeddedICE logic consists of two real-time watchpoint registers, together with a control and status register. One or both of the watchpoint registers can be programmed to halt the CoreMP7 core. Execution is halted when a match occurs between the values programmed into the EmbeddedICE logic and the values currently appearing on the address bus, databus, and some control signals. Any bit can be masked so that its value does not affect the comparison. Either watchpoint register can be configured as a watchpoint (i.e., on a data access) or a break point (i.e., on an instruction fetch). The watchpoints and breakpoints can be combined such that: • The conditions on both watchpoints must be satisfied before the CoreMP7 is stopped. The CHAIN functionality requires two consecutive conditions to be satisfied before the core is halted. Table 8 • • An example of this would be to set the first breakpoint to trigger on an access to a peripheral and the second to trigger on the code segment that performs the task switching. Therefore the breakpoints trigger the information regarding which task has switched out that will be ready for examination. The watchpoints can be configured such that a range of addresses are enabled for the watchpoints to be active. The RANGE function allows the breakpoints to be combined such that a breakpoint is to occur if an access occurs in the bottom 256 bytes of memory but not in the bottom 32 bytes. The CoreMP7 core has a Debug Communication Channel function in-built. The debug communication channel allows a program running on the target to communicate with the host debugger or another separate host without stopping the program flow or even entering the debug state. The debug communication channel is accessed as coprocessor 14 by the program running on the CoreMP7 core. The debug communication channel allows the JTAG port to be used for sending and receiving data without affecting the normal program flow. The debug communication channel data and control registers are mapped in to addresses in the EmbeddedICE logic. Debug Communication Channel Signals Signal Name Type TMS Input Test Mode Select. The TMS pin selects the next state in the TAP state machine. TCK Input Test Clock. This allows shifting of the data in, on the TMS and TDI pins. It is a positive edge triggered clock with the TMS and TCK signals that define the internal state of the device. TDI Input Test Data In. This is the serial data input for the shift register. TDO Output nTRST Input RTCK Output 26 Description Test Data Output. This is the serial data output from the shift register. Data is shifted out of the device on the negative edge of the TCK signal. Test Reset.The nTRST pin can be used to reset the test logic within the EmbeddedICE logic. Returned Test Clock. Extra signal added to the JTAG port. Required for designs based on COREMP7 processor core. Multi-ICE (development system from ARM) uses this signal to maintain synchronization with targets having slow or widely varying clock frequency. For details, refer to the Multi-ICE System Design Considerations Application Note 72 (ARM DAI 0072A). v2.6 CoreMP7 The EmbeddedICE logic contains 16 registers, as shown in Table 9. The CoreMP7 debug architecture is described in detail in ARM7TDMI-S (rev 4) Technical Reference Manual (ARM DDI0234A), published by ARM Limited, and is available via Internet at www.arm.com. Table 9 • EmbeddedICE Logic Registers Name Width Description Address Debug Control 6 Force debug state, disable interrupts 00000 Debug Status 5 Status of debug 00001 Debug Comms Control Register 32 Debug communication control register 00100 Debug Comms Data Register 32 Debug communication data register 00101 Watchpoint 0 Address Value 32 Holds watchpoint 0 address value 01000 Watchpoint 0 Address Mask 32 Holds watchpoint 0 address mask 01001 Watchpoint 0 Data Value 32 Holds watchpoint 0 data value 01010 Watchpoint 0 Data Mask 32 Holds watchpoint 0 data mask 01011 Watchpoint 0 Control Value 9 Holds watchpoint 0 control value 01100 Watchpoint 0 Control Mask 8 Holds watchpoint 0 control mask 01101 Watchpoint 1 Address Value 32 Holds watchpoint 1 address value 10000 Watchpoint 1 Address Mask 32 Holds watchpoint 1 address mask 10001 Watchpoint 1 Data Value 32 Holds watchpoint 1 data value 10010 Watchpoint 1 Data Mask 32 Holds watchpoint 1 data mask 10011 Watchpoint 1 Control Value 9 Holds watchpoint 1 control value 10100 Watchpoint 1 Control Mask 8 Holds watchpoint 1 control mask 10101 v2.6 27 CoreMP7 Ordering Information All variants of the CoreMP7 soft IP core are included in the CoreConsole IDP. To use CoreMP7, you need to download CoreConsole, which is available for free at: http://www.actel.com/custsup/updates/coreconsole/. You can also request that a CoreConsole CD (which includes CoreMP7) be mailed to you. List of Changes The following table lists critical changes that were made in the current version of the document. Previous Version Changes in Current Version (v 2 .6 ) v2.5 v2.4 v2.3 v2.2 28 Page The "ARM Supported Families" section was updated to remove ProASIC3E (M7A3PE). 1 The "Device Utilization" section was updated. The CoreMP7S variant was renamed to Core Only and the CoreMP7Sd variant was renamed to Core Plus Debug. 2 Table 1 • CoreMP7 Utilization and Performance was updated to remove all devices except M7AFS600 and M7A3P1000 and to change the names of the CoreMP7 variants to Core Only and Core Plus Debug. 2 The "CoreMP7 Variants" section was updated. 13 The "Delivery and Deployment" section was updated. 14 The "BFM Usage Flow" section was updated to clarify creation of the system memory map. 14 Table 1 was updated. 2 Notes were added to Table 6. 22 Table 1 was updated with AFS600 information. 2 The "Bus Functional Model" section was updated. 14 Notes were added to Table 6. 22 The datasheet was updated to include Fusion devices. NA Table 1 was updated. 2 The "CoreMP7 Variants" section was updated. 13 v2.1 Table 1 was updated. 2 v2.0 The "No Coprocessor Interface" section was updated. 13 The "Little Endian Only" section was updated. 13 v2.6 CoreMP7 Datasheet Categories In order to provide the latest information to designers, some datasheets are published before data has been fully characterized. Datasheets are designated as "Product Brief," "Advanced," and "Production." The definitions of these categories are as follows: Product Brief The product brief is a summarized version of an advanced or production datasheet containing general product information. This brief summarizes specific device and family information for unreleased products. Advanced This datasheet version contains initial estimated information based on simulation, other products, devices, or speed grades. This information can be used as estimates, but not for production. Unmarked (production) This datasheet version contains information that is considered to be final. v2.6 29 Actel and the Actel logo are registered trademarks of Actel Corporation. All other trademarks are the property of their owners. www.actel.com Actel Corporation Actel Europe Ltd. Actel Japan www.jp.actel.com Actel Hong Kong www.actel.com.cn 2061 Stierlin Court Mountain View, CA 94043-4655 USA Phone 650.318.4200 Fax 650.318.4600 Dunlop House, Riverside Way Camberley, Surrey GU15 3YL United Kingdom Phone +44 (0) 1276 401 450 Fax +44 (0) 1276 401 490 EXOS Ebisu Bldg. 4F 1-24-14 Ebisu Shibuya-ku Tokyo 150 Japan Phone +81.03.3445.7671 Fax +81.03.3445.7668 Suite 2114, Two Pacific Place 88 Queensway, Admiralty Hong Kong Phone +852 2185 6460 Fax +852 2185 6488 51700060-6/7.07