ARMV4T

COREMP7 ACTEL | Alldatasheet

Document overview

• Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
• PDF pages: 30

Technical content

July 2007 v2.6 1 © 2006 Actel Corporation CoreMP7 Product Summary

• Personal Audio (MP3, WM A, and AAC Players)  Personal Digital Assistants  Wireless Handset  Pagers  Digital Still Camera  Inkjet/Bubble-Jet Printer  Monitors Key Features  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 ARM Supported Families P r o A S I C®3 (M7A3P)  Fusion (M7AFS) Synthesis and Simulation Support  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 Verification and Compliance  Compliant with ARMv4T ISA  Compatible with ARM7TDMI-S Core Version  This Datasheet Defines the Functionality for CoreMP7 v1.0. 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 (DDI0234A- 7TMIS-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. 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).

Contents

2 v2.6 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 co re. Pipeline techniques are employed so that all parts of the processing and memory systems can operate continuously. Typically, while one instruction is being execut ed, its successor is being decoded, and a third instruction is being fetched from memory. The CoreMP7 processo r 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 co de while retaining most of the ARM performance advant age 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 si ze compared to 32-bit ARM 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 co re configuration menus. The utilization and performance of the variants for each device are shown in Table 1. Core Only This variant of the CoreM P7 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. Table 1 • CoreMP7 Utilization and Performance Device Variant Performance (MHz) Tiles RAM Block Utilization (%) M7A3P1000 Core Only 28.12 6,083 4 24.8% Core Plus Debug 21.7 7,931 4 32.3% M7AFS600 Core Only 28.08 6,083 4 44.0% Core Plus Debug 20.57 7,931 4 57.4%

v2.6 3 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. Figure 1  CoreMP7 Top-Level Block Diagram DBGTMS DBGnTRST DBGTDI DBGTDO DBGRNG(0) DBGRNG(1) DBGEXT(0) DBGEXT(1) WDATA[31:0] RDATA[31:0] CPU DBGTCKEN LOCK WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] ADDR[31:0] Scanchain 1 Databus Coprocessor Interface Signals EmbeddedICE-RT Macrocell EmbeddedICE-RT TAP Controller Scanchain 2

4 v2.6 Figure 2  CoreMP7 CPU Block Diagram 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 Instruction Decoder and Control LogicShifter ALU Register Bank Multiplier Address Register Write Data Register Instruction Pipeline Read Data Register Thumb Instruction Decoder ADDR[31:0] WDATA[31:0] RDATA[31:0] Address Incrementer ALU Bus A Bus B Bus PC Bus Incrementer Bus

v2.6 5 The signals of the CoreMP7 are listed in Table 2. Figure 3  CoreMP7 Functional Diagram CLK Clock Interrupts Bus Control Arbitration Debug CLKEN nIRQ nFIQ nRESET CFGBIGEND DMORE LOCK DBGINSTRVALID DBGRQ DBGBREAK DBGACK DBGnEXEC DBGEXT[1] DBGEXT[0] DBGEN DBGRNG[1] DBGRNG[0] DBGCOMMRX DBGCOMMTX DBGTCKEN DBGTMS DBGTDI DBGnTRST DBGTDO DBGnTDOEN ADDR[31:0] WDATA[31:0] RDATA[31:0] ABORT WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] CPnTRANS CPnOPC CPnMREQ CPSEQ CPTBIT CPnl CPA CPB Synchronized EmbeddedICE-RT Scan Debug Access Port Memory Interface Memory Management Interface Coprocessor Interface CoreARM7 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.

6 v2.6 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 tra nslate (asserted low) CPSEQ Output Sequential address CPTBIT Output Proce ssor in Thumb mode DBGACK Output Debug acknowledge DBGCOMMRX Output EICE communication channel receive DBGCOMMTX Output EICE communication channel transmit DBGnEXEC Output Execut ed (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 Memo ry access width TRANS Output Next transaction type (i, n, s) WDATA[31:0] Output Write data bus WRITE Output Indicates write access Table 2  Signal Descriptions (Continued) Name Type Description 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 7 Programmer’s Model This section summarizes th e 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 includ es both the 32-bit ARM instruction set and the 16-bit Thumb instruction set. 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 AR M and Thumb states does not affect the processor mode or the register contents. Switching State You can switch the operat ing state of the CoreMP7 between ARM state and Th umb state using the BX instruction. This is described fully in the ARM Architecture Reference Manual. 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. Memory Formats The CoreMP7 processor vi ews memory as a linear collection of bytes, numbered in ascending order from zero:  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. Although both Little Endian and Big Endian memory formats are supported, it is recommended that you use Little Endian format. Data Types The CoreMP7 processor supports the following data types:  Word (32-bit)  Halfword (16-bit)  Byte (8-bit) You must align these as follows:  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. Operating Modes The CoreMP7 processor has seven operating modes:  User mode is the usual ARM program execution state, and is used for ex ecuting 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. Registers The CoreMP7 processor has a total of 37 registers:  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. 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. The ARM state register set co ntains 16 directly accessible registers, r0 to r15. An additional register, the Current Program Status Register (CPSR), contains condition code flags, and the current mode bi ts. 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.

v2.6 9 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 T h e P C  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.Figure 5  CoreMP7 Thumb State Registers Thumb State General Registers and Program Counter Thumb State Program Status Registers SP LR PC SP_fiq LR_fiq PC SP_svc LR_svc PC SP_abt LR_abt PC SP_irq LR_irq PC SP_und LR_und PC = banked register CPSR CPSR SPSR_fiq CPSR SPSR_svc CPSR SPSR_abt CPSR SPSR_irq CPSR SPSR_und System and User FIQ Supervisor Abort IRQ Undefined

10 v2.6 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. Note: Registers r0–r7 are known as the low registers. Registers r8–r15 are known as the high registers. Figure 6  Mapping of Thumb State Registers to ARM State Registers Thumb State r10 r11 r12 Stack Pointer (r13) Link Register (r14) Program Counter (r15) Current Program Status Register (CPSR) Saved Program Status Register (SPSR) Stack Pointer (PC) Link Register (LR) Program Counter (PC) Current Program Status Register (CPSR) Saved Program Status Register (SPSR) ARM State

v2.6 11 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 di sabling of interrupts  Set the processor operating mode The arrangement of bits is shown in Figure 7. The Condition Code Flags The N, Z, C, and V bits are the condition code flags. You can set these bits by arithmet ic 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 cond itionally in ARM state. In Thumb stat e, only the Branch instruction can be executed conditionally. For more informat ion about conditional execution, see the ARM Architecture Reference Manual. Figure 7  Program Status Register Format Condition Code Flags Reserved Control Bits Overflow Zero Negative or Less Than Mode Bits State Bit FIQ Disable IRQ Disable 31 30 29 28 NZCV 27 26 25 24 23 876543210 I F T M 4M 3M 2M 1M 0 Carry or Borrow or Extend

12 v2.6 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 curr ent 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 ti mes all bus transfers. All signal timings are related to the rising edge of HCLK. HRESETn Input Reset. The bus reset si gnal 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. Indicate s that the CoreMP7 is currentl y 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 th e 32-bit system address bus. HTRANS[1:0] Output Transfer type. Indica tes the type of the current transfer. HWRITE Output Transfer direction. When HIGH this signal indicate s 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 (16- bit), or word (32-bit). HBURST[2:0] Output Burst type. Indicates if the tra nsfer forms part of a burst. The CoreMP7 performs incrementing bursts of type INCR. HPROT[3:0] Output Protection control. These signals i ndicate 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 32-bit data written back to the MASTER.

v2.6 13 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. Core Plus Debug The Core Plus Debug varian t 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. Core Only The Core Only variant has th e 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 m eans that the standard debug tools cannot be used with this variant of CoreMP7. No Debug This is the most obvious char acteristic 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. No Coprocessor Interface 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. 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. Figure 8  ARM7 TDMI-S Core ARM7 CPU Coprocessor Signals Data Address Bus Control Signals Debug Interface Debug JTAG Signals ARM7TDMI-S Core Debug EmbeddedICE-RT (Debug) TAP Controller

14 v2.6 Delivery and Deployment 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. Bus Functional Model 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 prototyp ing 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 necessit ates 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, su ch as integration with the RealView debugger. Support for hardware simulation is also proposed. The CoreConsole SoC configuratio n 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-leve l bus transactions, which allow verification of connectivity of the various IP blocks and the system memory map presented to the ARM7 by the rest of the hardware. This document specifies the following aspects of the ARM7 BFM:  Functionality  BFM usage flow  BFM script language P l a t f o r m s  Supported simulation tools  Example BFM use case BFM Usage Flow As the BFM is part of an over all 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-fo r-pin replacement of the ARM7TDMI-S in the SoC su bsystem. It initiates bus transactions on the native ARM7 bus, which are cycle- accurate 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 "s criptlets" for each resource attached to the AHB or APB buses.

16 v2.6 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: CoreConsole v1.1 ARM7 Pin Compatibility The BFM model is pin-for-pin compatible with the ARM7TDMI-S. This allows th e model to be dropped into the space that would be o ccupied 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 wa it for either of the two ARM7 interrupt lines to be triggered, before proceeding with the remainder of the test script. Log File Generation The BFM generates output me ssages to the console of the simulation tool and also generates a plain text log file. BFM Script Language The following script commands are defined for use by the BFM: memmap 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. Syntax memmap resource_name base_address; resource_name 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 BF M 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 e numerated 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 ba se of the resource, in bytes. It is specified as a hexadecimal value. data This is the data to be writ ten. It is specified as a hexadecimal value. Example write W videoCodec 20 11223344;  ADDR, // address bus  WDATA, // write data bus  RDATA, // read data bus  TRANS, // next transaction type (i, n, or s)  WRITE, // indicates write access  CLKEN, // clock enable The BFM also models the following control signals:  CFGBIGEND, // big/little endian configuration  CLK, // clock  nFIQ, // interrupt request  nIRQ, // fast interrupt request  SIZE, // memory access width

v2.6 17 read This command causes the BF M to perform a read of a specified offset, within the memory map range of a specified system resource. Syntax read width resource_name byte_offset; 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. Example read W videoCodec 20; readcheck This command causes the BF M 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 readcheck 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 expected read data. It is specified as a hexadecimal value. Example readcheck W videoCodec 20 11223344; poll 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. Syntax poll width resource_name byte_offset data_bitmask; width This takes on the e numerated 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. byte_offset This is the offset from the ba se of the resource, in bytes. It is specified as a hexadecimal value. bitmask The bitmask is ANDed with the read data and the result is then compared to the bitm ask 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. wait This command causes the BFM script to stall for a specified number of clock periods. Syntax wait num_clock_ticks; num_clock_ticks This is the number of Co reMP7 clock periods, during which the BFM stalls (doesn't initiate any bus transactions). 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. Syntax waitfiq; 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. Syntax waitirq; Supported Simulation Tools BFM is delivered to the user as both a Verilog and VHDL model.

18 v2.6 Timing Shell 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. Example BFM Use Case This provides an example use case of the ARM7 BFM. The example SoC used in this se ction 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. 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 SP IRIT specification, in XML. For example, in the case of the CoreUART, the attributes would indicate that there are three registers, as in Table 4. 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 se lf-checking that can be performed for the UART. Nevertheless, the bus transactions do take place an d 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 st age, 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. Processor Choice 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; 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. Table 4  CoreUART Attributes Offset Register Read/Write Width

0 Uart Status Register R Byte

1 Uart Tx data W Byte

2 Uart Rx data R Byte

Table 5  Memory Map Information Resource Actel IP Core Address Range ssram N 0-3fffff flash N 400000-7fffff uart Y c00000-c0000b mac Y d00000-d00040 videocodec N e00000-e000ff

22 v2.6 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 cl ock edge plus the maximum cl ock 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. t IHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. t IHCLKEN is 1 ns for the Core Only variant in all devices. 3. t IHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. t IHRDATA is 1 ns for Core Only variant in all devices.

v2.6 23 Debug 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 architecture uses th e 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). 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 debu gger remains exactly the same. The user could still use the debugger with a monitor program running on the target system or with an instruction set simulator that runs on the debugger host. In each case the debugging environment is the same. The advantages of using the JTAG port are:  Hardware access required by a system for test is re- used for debug.  Core state and system st ate 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.  Traditional breakpoints and watchpoints are available.  On-chip resources can be supplemented.  For example, the ARM De bug Architecture uses an on-chip macro-cell to enhance the debugging facilities available. tIHEXC nFIQ, nIRQ, nRESET hold from rising CLK –0 % tISCFG CFGBIGEND setup to rising CLK 10% – tIHCFG CFGBIGEND hold from rising CLK –0 % 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% – Table 6  AC Timing Parameters (Continued) Symbol Parameter Min Max Notes: 1. t IHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. t IHCLKEN is 1 ns for the Core Only variant in all devices. 3. t IHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. t IHRDATA is 1 ns for Core Only variant in all devices.

v2.6 25 The signals on the JTAG interface are shown in Table 7. Table 7  JTAG Signals Signal 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. Th is 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 JT AG 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 Real View 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 th e 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 Re alView 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 IC E 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 indica tes 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.

26 v2.6 The EmbeddedICE logic whic h 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 arch itecture uses a JTAG port as a method of accessing the co re. The debug architecture uses EmbeddedICE logic which resides on chip with the CoreMP7 core. The EmbeddedIC E has its own scan chain that is used to insert wa tchpoints and breakpoints for the CoreMP7. The EmbeddedICE logic consists of two real-time watchpoint register s, 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 watc hpoints 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. 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 ou t 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. Table 8  Debug Communication Channel Signals Signal Name Type Description 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 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. nTRST Input Test Reset.The nTRST pin can be used to reset the test logic within the EmbeddedICE logic. RTCK Output 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 varyin g clock frequency. For details, refer to the Multi-ICE System Design Considerations Application Note 72 (ARM DAI 0072A).

v2.6 27 The EmbeddedICE logic contains 16 registers, as shown in Table 9. The CoreMP7 debug archit ecture 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

28 v2.6

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 (v2.6) Page v2.5 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. 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. 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 v2.4 Table 1 was updated. 2 Notes were added to Table 6. 22 v2.3 Table 1 was updated with AFS600 information. 2 The "Bus Functional Model" section was updated. 14 Notes were added to Table 6. 22 v2.2 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 29 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.

51700060-6/7.07 Actel Corporation

2061 Stierlin Court

Mountain View, CA 94043-4655 USA Phone 650.318.4200 Fax 650.318.4600 Actel Europe Ltd. Dunlop House, Riverside Way Camberley, Surrey GU15 3YL United Kingdom Phone +44 (0) 1276 401 450 Fax +44 (0) 1276 401 490 Actel Japan www.jp.actel.com EXOS Ebisu Bldg. 4F 1-24-14 Ebisu Shibuya-ku Tokyo 150 Japan Phone +81.03.3445.7671 Fax +81.03.3445.7668 Actel Hong Kong www.actel.com.cn Suite 2114, Two Pacific Place

88 Queensway, Admiralty

www.actel.com Actel and the Actel logo are registered trademarks of Actel Corporation. All other trademarks are the property of their owners.