Modeling, Simulating and Prototyping Circuits for M•CORE Based Systems

Autor: iMarketing.es – Consultoría informática y de gestión, servicios tecnológicos y de outsourcing

Nueva economía, internet y tecnología

02-2005

Descargar Original

Overview

Rapid development of embedded applications in short time frames has generated a market for reusable micro-RISC architectures. These cores are being offered in two forms, custom gate level macrocells and fully synthesizable RTL models. Custom gate level macrocells are ideal for lower power and smaller die size but are not easily retargetable to different fabrication technologies without a new cell library. Synthesizable RTL models are ideal for rapid deployment to different fabrication sites and provide a rapid prototyping path using FPGAs but have larger die size, consume more power and may not work at the same speeds as custom macrocells. In both cases there is a list of important items to the bill of materials which comprise a complete product development cycle when designing with a reusable micro-RISC core.

Design teams who need a popular microcontroller architecture which fits their price, power, performance and support requirements will be looking for a complete solution to their product development plan. This includes access to libraries of special peripherals circuits and device drivers, well defined bus interfaces, a well supported suite of software and hardware co-simulation tools and rapid prototyping capability using FPGAs.

The focus of this paper is to describe the M·CORE M210S fully synthesizable core architecture, its design methodology and development tools which support rapid prototyping for wireless, consumer and automotive applications. An architectural overview of the M210S will include the programmers model, a hardware local bus interface and a peripheral bus interface standard. Emphasis will be placed on tools which assist in transitioning from a hardware description language (HDL) modeling environment to a rapid prototyping platform using FPGAs.

M·CORE Architecture

Let's start with an overview of the M·CORE architecture and how to design with it. Motorola's M·CORE architecture is designed specifically for sophisticated, yet low power, applications. It's a fully static CMOS core that packs about 80,000 transistors in a 2.2-mm2 square of silicon. The architecture implements logic within portions of the core execution and control blocks to minimze power and reduce EMI by gating clocks to those blocks only when active. In addition to providing mechanisms to power down the processor and system logic, there is focus on minimizing dynamic power consumption when the system is active.

M·CORE is a streamlined execution engine that provides many of the same performance enhancements as mainstream RISC architectures. It is implemented with a fixed 16-bit instruction length and 32-bit internal data path which meets the computational precision requirments of newer advanced products with the cost and power advantages previously available only with 16-bit architectures. Thus, increased code density accomplishes the goal of minimizing the overhead of memory system energy consumption.

The Instruction Fetch, Instruction Decode/Register file Read, Execute, and Register Writeback stages of the pipeline operate in an overlapped fashion, allowing single clock instruction execution for most instructions.

Figure 1 - M•CORE Architecture [1]

The execution unit consists of a 32-bit Arithmetic/Logic Unit (ALU), a 32-bit Barrel shifter (Shifter), Find-First-One unit (FF1), result feed-forward hardware, and miscellaneous sup- port hardware for multiplication, division, and multiple register loads and stores as illustrated in Figure 1. Arithmetic and Logical operations are executed in a single cycle with the exception of multiply, which is implemented with a 2-bit per clock, overlapped- scan, modified Booth algorithm with early-out capability to reduce execution time for operations with small multiplier values, and the divide instructions, which also have data dependent timing. A Find-First-One unit operates in a single clock cycle.

The Program Counter Unit has a PC incrementer and a dedicated Branch Address Adder to minimize delays during change of flow operations. Branch target addresses are calculated in parallel with branch instruction decode, with a single pipeline bubble for taken branches and jumps, resulting in an execution time of two clocks. Conditional branches which are not taken execute in a single clock.

Memory load and store operations are provided for byte, halfword, and word (32-bit) data with automatic zero extension of byte and halfword load data These instructions can execute in two clock cycles. Load and store multiple register instructions allow low overhead context save and restore operations; these instructions can execute in (N+1) clock cycles, where N is the numbers of registers to transfer.

A single Condition Code/Carry (C) bit is provided for condition testing and for use in implementing arithmetic and logical operations greater than 32-bits. Typically, the C bit is set only by explicit test/comparison operations, not as a side-effect of normal instruction operation. Exceptions to this rule occur for specialized operations where it is desirable to combine condition setting with actual computation.

M·CORE Programmer Model

The M210S programming model is defined separately for two privilege modes: supervisor and user. Certain operations are not available in user mode. Programs access registers based on the indicated mode. User programs can only access registers specific to the user mode; system software executing in the supervisor mode can access all registers, using the control registers to perform supervisory functions. User programs are thus restricted from accessing privileged information, and the operating system performs management and service tasks for the user programs by coordinating their activities.

The instruction set is tailored to support high-level languages and is optimized for those instructions most commonly executed. A standard set of arithmetic and logical instructions is provided as well as instruction support for bit operations, byte extraction, data movement, control flow modification, and a small set of conditionally executed instructions which can be useful in eliminating short conditional branches.

Most instructions execute in either mode, but some instructions that have important system effects are privileged and can only execute in the supervisor mode. For instance, user programs cannot execute the stop, doze, or wait instructions. To prevent a user program from entering the supervisor mode except in a controlled manner, instructions that can alter the S-bit in the program status register (PSR) are privileged. The trap #n instructions provide controlled access to operating system services for user programs. Access to special control registers is also precluded in user mode.

When the S-bit in the PSR is set, the processor executes instructions in the supervisor mode. Bus cycles associated with an instruction indicate either supervisor or user access depending on the mode.

The processor utilizes the user programming model when it is in normal user mode processing. During exception processing, the processor changes from user to supervisor mode. Exception processing saves the current value of the PSR in the EPSR or FPSR shadow control register and then sets the S bit in the PSR, forcing the processor into the supervisor mode. To return to the previous operating mode, a system routine may execute the rte (Return from Exception) or rfi (Return from Fast Interrupt) instructions as appropriate, causing the instruction pipeline to be flushed and refilled from the appropriate address space

The Programmer's model registers depicted in Figure 2 provide operand storage and control. The registers are partitioned into two levels of privilege: user and supervisor. The user programming model consists of 16 general-purpose 32-bit registers, the 32-bit Program Counter (PC) and the Condition/Carry (C) bit. The C bit is implemented as bit 0 of the PSR. This is the only portion of the PSR accessible by the user. The supervisor programming model consists of an additional 16 general-purpose 32-bit registers (the alternate file), as well as a set of status/control registers, and scratch registers. By convention, register R15 serves as the Link register for subroutine calls, and register R0 is typically used as the current Stack Pointer.

Figure 2 – M•CORE Programmer Model Registers

Access to the alternate file is made available via a control bit in the PSR, access to the status/control/scratch registers is made available via the Move from Control register(MFCR) and Move to Control register (MTCR) instructions. When the alternate file is selected via the AF bit in the PSR, general purpose operands are accessed from it; when the AF bit is cleared, operands are accessed from the normal file. This alternate file is provided to allow very low overhead context switching capability for real-time event handling

Data Organization in Registers and Memory

The operand data formats supported by the integer unit are standard twos- complement data formats. The operand size for each instruction is either explicitly encoded in the instruction (load/store instructions) or implicitly defined by the instruction operation (index operations, byte extraction). Typically, instructions operate on all 32 bits of the source operand(s) and generate a 32-bit result.

Memory is viewed from a Big-Endian byte ordering perspective. The most significant byte (byte 0) of word 0 is located at address 0. Bits are numbered within a word starting with bit 31 as the most significant bit.

Operand Addressing Capabilities

The M210 accesses all memory operands through load and store instructions, transferring data between the general purpose registers and memory. Register + 4-bit scaled displacement addressing mode is used for the Load and Store instructions to address byte, halfword, or word (32bit) data.

Load and Store Multiple instructions are defined which allow a subset of the 16 GPRs to be transferred to/from a base address pointed to by Register R0 (The default stack pointer by convention). Load and Store Register quadrant instructions utilize register indirect addressing to transfer a register quadrant to/from memory.

Execution of load/store multiple instructions will create a burst of back to back writes of the registers to memory. Figure 3 illustrates the byte lane arrangement of data in registers and which memory locations these bytes reside with respect to the data type.

Figure 3 - Data Organization in Registers and Memory

M·CORE Local Bus Interface

The M·CORE Local Bus interface (MLB) consists of a full 32 bit address bus, 32 bit data bus and transfer control signals for connecting to different speed memories and peripherals easily as illustrated in Figure 4. Bus arbitration signals are made available for multi-master hookups with address and data tri-state indicators with transfer request, busy, abort and termination signals available for bus monitoring and control.

Emulation support signals complement an IEEE 1149.1 JTAG port for in-circuit control of the target system with visibility to internal registers and memory. Global status and control registers have a direct connection to two 32 bit parallel ports for debugging or kernal process awareness. A key feature of the M210 architecture is its ability to service interrupts. Interrupt handlers are easily accessable with vectored addresses or autovectoring.

Figure 4 – M•CORE Interface Signals

For power sensitive applications there are power management pins which may be used to turn off circuits when the processor is in the stop, wait or doze modes. When exiting these states the processor will assert the wakeup pin so that external circuits may be enabled.

Bus loading is a concern for all processor interfaces including the MLB. Care should be taken to evaluate the capacitive loading when designing interfaces for zero wait states. The maximum capacitive loading for the MLB is 50pf therefore care should be taken when designing memory and peripheral blocks.

Designing with the M210S Architecture

The M210S is the first of a family of synthesizable M·CORE architectures. The objective is to provide a well defined set of deliverables to enable designers to rapidly develop embedded applications. These deliverables include a full set of documentation, logic design data bases, design for test patterns and scripts, models and functional verification tools.

These tools are complemented by a well defined architectural design methodology for creating the proper mix and match of memory and peripherals for a custom microcontroller. Two versions of the M210 core development kit will be made available, a unified design system hard macro cell version and a fully synthesizable version. Figure 5 illustrates a typical hookup to the M210S local bus. High speed zero wait state accesses to resident memory is accomplished by direct connection to the MLB using the appropriate address decoding and transfer control signals. Also any bus arbitration , power management and emulation control would be solved at the MLB interface.

Figure 5 - Typical M210 Microcontroller Architecture

Interfacing the M210 to Memory and Peripherals

The M·CORE architecture uses a standard bus bridge to connect its MLB to a set of peripherals. This bus bridge is called the Intellectual Property (IP) Bus and is illustrated in Figure 6. Based on unprecedented customer demand, Motorola Semiconductor Products Sector is making its vast libraries of Intellectual Property available to select market partners through Motorola's Technology Transfer Program (MTTP). This will allow Motorola's partners to create silicon solutions for specific business opportunities while allowing Motorola to maintain its market-focused strategy.

The goal of the IP Bus is to provide a unified peripheral interface to different Motorola embedded cores such as the 68000, Power PC, Star12, and M·CORE. This allows different levels of reuse of a portfolio of thousands of peripherals. The IP Bus allows easy connection to Motorola and ARM AMBA peripherals.

The architecture is set up with a bridge which connects to these perihperals through a gasket. An individual gasket is needed for each core. In summary, the design methodology allows for the selection of a strategic synthesizable core connection to a unified perhiperal bus. This capability enables a wide offering of off-the-shelf proven technology for rapid system integration.

The introduction of the IP Bus standard also makes available peripheral device drivers which have been debugged. This permits designers to rapidly model systems with existing software so that hardware and software tradeoffs may be studied.

Figure 6 - Intellectual Property Bus Specification

Hardware-Software Co-Design

Once a system is defined at an architectural level, the hardware/software co-design begins. Software design teams will need a simulation environment for writing drivers and interfaces to kernals. Hardware designers will need software to facilitate subsystem verification as well as functionality at the product level. The ideal situation is to provide a full software simulation environment which permits source level debugging with familiar tools and complete HDL simulation prior to prototyping or silicon spins. This requires tools which permit multiple simulator engines to run simultaneously and pass synchronization and data messages to each other.

Summit Design Inc. makes this powerful capability available through their Virtual-CPUTM (V-CPU) product. This powerful system permits software programs running on a Software Development Systems (SDS) SingleStepTM instruction simulator to execute programs and communicate with a bus functional model in the verilog RTL simulation environment. This permits developers to examine registers and memory easily during simulation runs. At the same time, developers are able to bring up waveform windows to examine bus interaction with peripheral circuits. Validation of circuits becomes easier since software programs can precondition specific test cases easier than generating unique test benches. Figure 7 illustrates a dual simulator environment where two debuggers interact with different graphical user interfaces to provide visibility to both the software functions in C and/or assembly language as well as the hardware components written in verilog.

Figure 7 - V-CPU Co-Verification Environment [2]

This tool provides an excellant functional verification or behavioral analysis platform. The software simulator performs 1-2 million instructions per second when executing out of designated internal memory. Once hardware/software tradeoffs have been performed the next logical step is to produce a hardware prototype.

A key goal in the design phase will be to try to reuse as much of the verification suites created during RTL definition as illustrated in Figure 8. This requires a verification plan which reuses the verilog test bench at gate level and post place and route simulations if a prototype is being synthesized into an FPGA.

A series of pin monitors for MLB activity as well as peripheral pin activity are being offered as part of the M210S development environment. These monitors reside in a verilog test bench and generate output files of pin activity as well as software history. They are ideal for evaluating program behavior and may be used to generate regression reference points at the RTL level. These reference files may then be compared to simulation output at the gate level as well as the post place and route

Figure 8 - Verification Suite Reuse in FPGA Design Process

The use of FPGA's for the implementation of Intellectual Property has exploded. With synthesis based design replacing schematic based design, there are many benefits of using FPGAs to bring soft designs to a hard reality. Schematic based designs target a limited number of hardware architectures whereas RTL based designs are able to target the majority of digital hardware architectures. Intellectual property providers such as Motorola have turned to FPGA technology to realize many of these benefits.

Synthesizable cores can be easily retargeted from custom standard cell designs to FPGA's. The M·CORE M210S has been ported to a 300K gate Xilinx VertixTM device.

During the port it was realized that the register file was better fit into RAM based cells on the Vertix device to achieve higher gate count optimization.

Once the M·CORE M210S has been ported into a popular FPGA device, advanced and high speed prototyping can begin. These prototypes can be thoroughly evaluated and increase the quality of the design yet reduce time to market. An additional benefit of the hard implementation allows these prototyping systems to be used to develop real time embedded software applications. This is a big advantage over simulation based software design in that software development is exponentially acellerated. Software design and debug can be performed simultaneous with the design of the final target hardware application. There are several examples of these prototypes of which two will be described.

Motorola's M210S Evaluation System

The M·CORE M210S evaluation system is a rapid prototyping system designed around FPGAs and intended for use in intellectual property creation and debug. This evaluation system consists of three boards, a microcontroller/memory board, an peripheral prototyping board and a special circuit interface board. They communicate via a well defined board interface bus, thus allowing a complete system to be developed.

Microcontroller and Memory Platform

The main board which emulates the M210S core is called the microController plus Memory Board (CMB). The M210S core, MMC2102DV, is synthesized into a Xilinx Vertix device on the CMB. The Xilinx Vertix device is then interfaced to an Altera 10K CPLD. Since these FPGAs are RAM based, the CMB includes configuration Flash devices for each Xilinx and Altera device. These Flash devices are used to store the gate files which load the FPGA upon power up. The board also includes a DUART for serial communication between the core and an external host or target. The external Flash and RAM on the board are used for application program storage and variables respectively.

The Altera CPLD is used to implement other modules such as synthesized peripherals. Its primary use is the implementation of an external integration module. The M·CORE architecture integration module (MIM) is synthesized into the Altera CPLD or the CPLD can act as a simple pass through enabling the M·CORE architecture MLB to be seen by the second or third components of the system, i.e. the MMCFPGA01. The MIM acts as the interface to external logic. It provides the address, data, control, chip selects, and DRAM control needed to interface to external devices. This integration module also includes the peripheral bus interface. The peripheral bus interface implemented in the MIM is the IP Bus.

Peripheral Prototyping Platform

The second component of the M210S evaluation system is an FPGA board or MMCFPGA01. This board is used for additional peripheral emulation. Two FPGA boards may be power stacked to increase gate count available for multiple peripheral designs. Peripheral synthesis technology is slightly ahead of core synthesis. This is due to the previous gate size limits of FPGA's relative to the current gate count of micro-RISC based cores such as the M·CORE architecture. The user may choose from Motorola peripherals, third party intellectual property providers, or design and integrate their own. Some examples of peripherals include Ethernet, Firewire, USB, IRDA, and synchronous DRAM control, as well as simple timers and serial modules. The peripheral examples listed are supported by the IP Bus standard.

Circuit Prototyping Platform

The third board known as the Platform Board or PFB is used for prototyping special circuits, logic analyer interfaces, additional memory and LCD displays. The M210S evaluation system may operate with or without the platform board. The platform board is popular with RTOS vendors who need large RAM blocks to port and develop applications on new architectures. It also includes a large amount of prototype area for through hole and surface mount packages to customize each system. The LCD display allows demos, status, and diagnostic output for verification teams.

The benefit of synthesis of peripherals has been around for awhile. The M·CORE processor FPGA market development kit was produced about a year ago for use in integrating synthesized peripherals with the M·CORE architecture. The FPGA market development kit consists of the MMCFPGA01 board interfacing to an M·CORE processor board, the MMC2001CMB. The FPGA market development kit ships with the complete Altera tool chain including synthesis, place and route, as well as system software for programming external and FPGA flash.

Motorola's low cost talk about radios were first prototyped on this FPGA kit in that timeframe. The FPGA market development kit was based on the same Altera 10K device found implementing peripherals on the M·CORE M210S evaluation system. The MMCFPGA01 board was re-used as a building block of the M·CORE M210S evaluation system. The same peripherals implemented in the FPGA market development kit can be reused in the new system with the synthesized core.

System Level Interface Connector

These systems are connected together through a Motorola development tools interconnect standard known as Modular All Purpose Interface or MAPI as illustrated in Figure 9. The MAPI standard can provide interconnect of the M·CORE architecture local bus or MLB or any number of integration modules currently available. These synthesizable integration modules consists of the external bus interface unit, interface to busrt RAM and Flash, and controllers for external Synchronous Dynamic Random Access Memory.

In addition the MAPI standard allows stacking of FPGA market development boards increasing the amount of peripherals allowed. The M210 is debugged through a OnCETM port. An Enhanced Background Debug Interface (EBDI) is used to connect the target system to the host. This debug tool provides a JTAG controller implemented in an FPGA memory mapped to a CPU32 based microcontroller. The microcontroller receives debugger commands from the host and translates them into messages the JTAG controller passes to the OnCE debug port.

Increased emphasis on better debugging tools is being addressed by providing new features to on-chip debug blocks. A new real-time debug block is being added to the next generation M·CORE architecture. This debug block, code named Nexus, is based on a proposed industry standard developed by a consortium of over 20 companies.

The implementation of NEXUS and increased functionality of JTAG based debug ports will assist design engineers in verifying and debugging their embedded applications.

FPGA prototyping methodology is being used to chec out the debug port enhancements in hard implementations before actual standard cell silicon is manufactured. This saves time and money required to do silicon re-spins. This same methodology is applied to the debug of core interfaces to new peripherals.

Figure 9 - M210S Rapid Prototyping System Building Blocks [3];

AppNet, Inc. ProteusTM System

The second system making use of FPGA's for the realization of Intellectual Property is the Proteus system from AppNet, Inc..[4] The Proteus system is a rapid prototyping system built around FPGAs which easily support the M·CORE architecture. The Proteus system allows complex systems to be implemented by providing as many as twenty sites for FPGA's, CPU, analog, custom, or other hard implementations.

The Proteus system has prototyped a pre-silicon version of a new M·CORE microcontroller, code named SIKA, which uses the M210S, on-chip memory, an IP Bus gasket and a set of IP Bus compliant peripherals. In this implementation the M210S core is instantiated into one an FPGA site with a Xilinx Vertix device. Other sites contain peripherals or sections of periherals that make up the SIKA device These sections of peripherals include discrete analog sections such as phase lock loop or analog to digital converters. With systems such as these, developers can write and debug code executing instructions in the 10 to 20 Mhz range. This again is an order of magnitude greater than software development on simulators and it allows actual connection into the final target application. There is also a lower cost four site replica Proteus system used by customers who only need to add one or two simple peripherals. The Proteus replica system emulates a SIKA device with a one site expansion for simple peripheral(s)

The Proteus system is modular and composed of several boards. The software included allows for quick compilation, partitioning, and debug of RTL based FPGA designs. The Logic Board (LB) holds the raw gates used in the design of intellectual property. The Mezzanine Board (MB) connects the LB gates to implement the design. The Clock Mezzanine board (CM) implements the clocking scheme of the design. The CM supports a wide range of clocking strategies including internally and externally generated , and gated clocks. The CM also provides programmable delay buffers to support clock skew adjustment.

Figure 10 AppNet, Inc. Proteus Rapid Prototyping Environment

The primary I/O Buffer Board (BB) interfaces the Proteus system to a target system. The Incremental Mezzanine board (MM) supports quick ECO's to the system. Simple and complex logic changes are supported through the MM. Since the system is FPGA based it can be re-used for future designs. An example of the four site system emulating SIKA is shown in Figure 10.

The software runs on a laptop or a host connected to a network. The network connection allows for separate software developer and lab workstations. The intellectual property modules are shown plugged into sites. The memory modules include Flash, SRAM, or DRAM. The embedded processor ICE shown in the diagram is the M•CORE EBDI discussed above. There are also external logical analyzer connectors for analysis and or scopes.

Rapid Prototyping Limitations

Some of the disadvantages of these rapid prototyping systems are listed here. Performance is the major limitation. With micro risc cores running 100+ Mhz, the FPGA's cannot keep up. The M·CORE M210S has a performance limitation around 25Mhz when synthesized into a FPGA. Metal options of the FPGA cores can easily double the performance, but that reduces the flexibility of the system. The increased power consumption is the second disadvantage. The intelligent clock gating schemes used to decrease run current in the standard cell designs cannot be fully implemented in the FPGA. The relative cost of the FPGA proves to be a big disadvantage with the Xilinx V1000 costing over $3000. Operating voltages in the one volt range needed for wireless applications cannot be emulated with this system configuration.

Conclusion

Te exponential rate of new product introductions has made it necessary to reuse designs whenever possible. This has lead to the introduction of reusable licensed microcontroller cores. The licensing of cores has made it a necessity to produce synthesizeable cores. This new methodology permits delaying the choice of target fabrication technology till the end of the design cycle. Synthesizeable cores allow this type of methodology by allowing the design process to target different fabrication houses by switching out libraries. The proliferation of synthesizeable cores generates the need for tools to verify the integration of the core and peripherals. The increase in gate count in the FPGA's, along with tools to support partitioning of the modules, make systems described above ideal in enabling quick to market integration of silicon systems.

Motorola recognizes the tremendous growth rate of consumer, automotive and wireless markets and is making its advanced M·CORE micro-RISC architecture available through a core licensing program which addresses the complete product life cycle including software, peripheral libraries, design methodology and fabrication. Full details may be obtained at the Motorola M·CORE website www.mot.com/sps/mcore.

References

[1] Architectural Brief, M·CORE microRISC Engine, M·CORE 1/D, Motorola Inc., 1999
[2] Summit-Design Product Info, website,
http://www.summit-
design.com/products/verification/vcpu_whitepaper_mcore.html
[3] Motorola M·CORE website, http://www.mot.com/sps/mcore
[4] AppNet, Inc. website, http://www.appnetinc.com

M·CORE and OnCE are trademarks of Motorola. All other trademarks are proprietary to their respective owners.

Nota: Es probable que en esta página web no aparezcan todos los elementos del presente documento.  Para tenerlo completo y en su formato original recomendamos descargarlo desde el menú en la parte superior

iMarketing.es – Consultoría informática y de gestión, servicios tecnológicos y de outsourcing

www.imarketing.es/articulos

Otros artículos que te van a interesar