altera sopc design with arm - 國立臺灣大學r93088/dip/2004_08_sopc.pdftools such as altera’s...

1

Altera SoPC design with ARM

Altera SoPC design with ARM

CIC 周育德Tel : (03) 5773693 ext 148

Email : [email protected]

2 National Chip Implementation Center Copyright ©2004,Steven Chou ,All rights reserved

Agenda

General DescriptionARM-Based Excalibur SolutionStripe ArchitecturePLD ArchitectureMegaWizard SettingSoftware Build SettingConfiguration Methods

– Boot from Flash– Boot from External

Excalibur Utilities


Agenda

Excalibur System Verification– Bus Functional Simulation– Full Stripe Simulation– Embedded Stripe Simulation

EPXA1 development boardExercise


General Description


Embedded Processor

The system functionality is partitioned into HW, SW, and the Interface.SW part runs on programmable processors (embedded processors).HW part runs on IP blocks or custom designed HW blocks.

MemoryVideo RAM

I/O

Processorcore

DSPcore

SharedMemory

HW

IP

I/OIP

A/D&

D/A

Memory HW

Bridge

IP

MemoryHW


Introduction

What is an Embedded Processor?– A programmable processor ‘embedded’ into an embedded system (on a

chip).– An embedded processor can be a general purpose processor, DSP,

microcontroller, or a processor optimized to a specific application.– Programming self-contained computers

End-user, application developer, system integrator, and component manufacturer are all separated.

– Programming embedded processorsMost software is provided by system integrator.


Taxonomy

Domain of Target Applications– General-purpose processors

ARM, MIPS, PowerPC, etc. – Domain-specific processors

DSPs such as TMS320x (TI), ADSP-TS0xx (Analog Devices), Saturn (Adelante), SH3-DSP (Hitachi), Carmel (Infineon), ST100 (STMicro), ...Microcontrollers such as M68x05 (Motorola), 8051 (Intel), ...Network processors such as IXP (Intel), PayloadPlus (Lucent), ...

– Application-specific processorsConfiguration (ISA) is optimized to a specific application (configurable processor).Xtensa (Tensilica), ARCtangent (ARC), Jazz (Improv), ...


Taxonomy

– Tradeoffs due to architectural choiceN. Dutt and K. Choi, “Configurable processors for embedded computing,”Computer, Jan. 2003

dedicatedhardware

domain-specific

processor

configurableprocessor

reconfigurablehardware

general-purpose

processor

perf

/pow

er

flexibility


Taxonomy

Architecture– Single-issue RISC architecture

ARM, SH3-DSP, Xtensa, ARCtangent– Super scalar architecture

MIPS, PowerPC– VLIW architecture

TMS320C6x, ADSP-TS0xx, Saturn, Jazz– ST100 and Carmel provide instruction sets that support all these

architectural features in one processor.ST100: 16, 32, 128-bit instruction formatsCarmel: 24, 48, 144-bit instruction formats


Taxonomy

Configurability– Fixed processors

8051, ARM, MIPS, PowerPC, SH3-DSP, TMS320x, Saturn, Carmel, and ST100Hard cores with fixed layouts or soft cores with synthesizable HDL descriptionsInstruction sets are fixed and are not supposed to be configured for application specific optimization. Coprocessors can accompany fixed processor cores to improve the overall system performance. The coprocessors can be synthesized for specific applications as in HP PICO project.


Taxonomy

– Fixed processor cores with reconfigurable logicExcalibur (Altera), Virtex II Pro (Xilinx), E5 and A7 (Triscend), QuickMIPS(Quicklogic), RCP (Chameleon), and FPSLIC (Atmel). RCP has an ARC configurable processor embedded in it, but it is a pre-configured one. MorphoSys (Morpho Technologies) has a fixed processor core integrated with a reconfigurable block. The reconfigurable block consists of large grains of processing elements.

– Fixed processor cores given as soft coresMicroBlaze (Xilinx)Need to be synthesized to be programmed on a reconfigurable logic. Limited configuration can be done on peripherals and bus interfaces but the instruction set is fixed.


Taxonomy

– Configurable processorsInstruction set architectures are configured according to the application. Sometimes called ASIPs (Application Specific Instruction set Processors)Xtensa, ARCtangent, and Jazz provide basic cores and instruction sets. They can be configured or extended for the target application. NIOS (Altera) is a configurable processor that can be programmed on a reconfigurable logic. However, only five opcodes can be used for user customizable instructions.LISATek (merged to CoWare) and Target Compiler Technologies do not provide basic cores but start from scratch. From an architecture description in a specific ADL (Architecture Description Language: LISA, nML), they generate a compiler, a simulator, and a synthesizable HDL.


ARM-Based Excalibur Solution


ARM-Based Excalibur Solution

WatchdogTimer

Phase-Locked

Loop (PLL)

AHB 1-2Bridge

Dual-Port SRAM

SDRAMController

Single--Port SRAM

ARM922T Processor

Interrupt Controller

AHB1

AHB2

SDRAM SRAMFlash

ConfigurationLogic Master

Reset Module Timer

UARTExpansion

Bus Interface (EBI)

ROM

Excalibur Hard Processor

External Devices

IP

PLD-to-Stripe Bridge

Programmable Logic Master

Peripheral

ProgrammableLogic SlavePeripheral

Stripe-to-PLD

Bridge

ProgrammableLogic SlavePeripheral

Programmable Logic Module

Programmable Logic

Module

Programmable Logic


Embedded Stripe Components

ARM922T 32-Bit RISC Processor– 200-MHz Bus Performance

Embedded Memory– Single-Port SRAM to 256 Kbytes– Dual-Port SRAM to 128 Kbytes

SDRAM ControllerExpansion Bus InterfaceMulti-Layer AMBA AHB Bus ArchitectureEmbedded Bridges between Stripe & PLDEmbedded Peripherals

– UART– Timer– Watchdog Timer– Interrupt Controller


The Embedded Processor

Combines– 200-MHz ARM922T™ Processor– Up to 3.3 Mbits of Memory– Up to 1M Gates of Programmable

Logic

PLD Area for Customer Design

ARM922TCore

Single-PortRAM

Dual-PortRAM


Stripe & PLD Architecture

PLL

Timer

UART

InterruptControllerWatchdog

Timer

JTAG

128 Kbytes SRAM64 Kbytes DPRAM



DPRAM

EPXA1

EPXA4

EPXA10

TraceModule

ARM922T

SRAM SRAM SRAM

DPRAM DPRAM

ExternalMemory

InterfacesProcessor & Interfaces I-CACHE D-CACHE

ARM 8 Kbytes 8 Kbytes

LEs 4,160ESB (Bytes) 6.5K

LEs 16,400ESB (Bytes) 26K

LEs 38,400ESB (Bytes) 40K

EmbeddedStripe

PLD

LE:Logic Element ESB:Embedded System Block


Excalibur System Introduction

The Excalibur™ devices achieve a new level of system integration from the inclusion of an embedded processor system within a field programmable gate array (FPGA).

An Excalibur-based system contains three sections:– The digital logic design of the FPGA– The embedded software application running on the processor– The parameterization and instantiation of the embedded processor stripe

On power-up, Excalibur devices can either be viewed as an embedded processor within an FPGA, or as an FPGA within an embedded processor.


Excalibur System Introduction

As an embedded processor, – The development tool flow facilitates the creation and downloading of a

single system file containing both the configuration of the FPGA logic and the embedded software, in an appropriate format for storing in an external flash memory device. In this mode, the embedded stripe parameters are integrated into the boot section of the embedded software application.

As an FPGA, – The development tool flow facilitates the creation of a single system file

containing all three sections. The file formats provided are standard FPGA configurations file to be stored in an external configuration device, such as an EPC2 serial EPROM.


FPGA Logic Design

The development of digital logic for the programmable logic section of the devices follows the same flow as any other design for an Altera®APEX™ device. The FPGA designs are provided in either VHDL or Verilog hardware descriptions languages (HDL). The creation of this HDL can be through tools such as Altera’s SOPC Builder, provided by third parties in the form of IP cores, or created by the user in a text editor. The HDL must be synthesized into a form that can be placed and routed by the Quartus® II development tools. Typically, the Altera Quartus II development tools are used in conjunction hardware simulation tools from Altera or a third party partner. A variety of simulation models are provided, which can be used to model the device behavior at varying levels of detail.


Embedded Software Design

The development of embedded software for the embedded processor section follows the same flow as any other embedded software design for an ARM processor. Altera provides GNUPro compilation and debug tools for embedded software development with Quartus II software subscriptions.

Another Popular Tool ADS (ARM Design Suite) compilation and debug tools.

With the use of SOPC Builder, a graphical user interface based system design tool, all necessarry header and configuration files are generated automatically.


Parameterization and Instantiation of the Embedded Processor Stripe

The Altera MegaWizard Plug-in Manager (a graphical user interface utility) provides the designers the ability to set the operational parameters for the embedded processor. The MegaWizard Plug-In outputs a system build descriptor file (.sbd), which describes the set-up of the device, including the following characteristics:

– Device booting—from an external flash device or an external FPGA configuration device

– Processor endian-ness– Device memory map– Use of the bridges between the stripe and the PLD– configuration of integrated peripherals (timers, UART, SDRAM, EBI)– Peripheral input-voltage levels– Peripheral output configurations– Frequency of operation (settings for the PLLs) for the processor and the

SDRAM controller



In addition to parameterization of the embedded stripe, the MegaWizardPlug-In produces files used in the FPGA logic design and verification, as well as instantiating simulation models for the hardware and software cosimulation.The files produced are the following:

– .v or .vhd files containing instantiations of the embedded processor and dual-port RAM blocks and header files, as follows:

for Verilog files, module instance containing stripe structural code, plus an include filefor VHDL files, entity instance containing stripe structural code, plus .vhd package,

plus additional template component declaration (VHDL 1987 only)– A ‘C’ language header file, containing definitions of the memory map– an assembly language header file, containing definitions of the memory map– A block symbol file, needed for instantiation in a Quartus II software Block

Design FileWhenever the MegaWizard Plug-In updates the .sbd file, it automatically recreates these files.


MegaWizard Plug-In Process

National Chip Implementation Center Copyright©2004,Steven Chou ,All rights reserved

Booting from Flash flow

Altera provides a bootloader for use when booting from external flash memory. The bootloader initializes the device registers according to the MegaWizardPlug-In output, including setting up the memory map of the device; and then loads the software into RAM. It resets the watchdog timer and finally sets the endian-ness of the processor, before passing control to the user’s code.

SOPCBuildder(optional)


.h.c.ccc

.h.c.ccc.h.h.v or .vhd

Stripedeclaration

.v or .vhdStripe

declaration

HDLTemplateHDL

TemplateSystemBuild

Descriptor(.sbd)

SystemBuild

Descriptor(.sbd)

Intel.hex

Intel.hex

.v or .vhdChip design


SoftwareDesign EntrySoftware

Design Entry

Software BuildEnvironment


Hardware Design EntryHardware

Design Entry

.edf.edf

Synthesis(after satisfactory

simulation)


simulation)

.sbi.sbi

FitterFitter

.o.o

MakeProgFileMakeProgFile

Linker and convertObject file to .hex


LoaderLibrary

LoaderLibrary

.hexout.hexout

Excalibur MegaWizard

Plug-in


Plug-in

25


Booting from an External flow

The sequence of tool use for configuration from an external configuration device, via passive configuration schemes.



.h.c.ccc


Stripedeclaration

.v or .vhdStripe

declaration

HDLTemplateHDL

TemplateSystemBuild

Descriptor(.sbd)

SystemBuild

Descriptor(.sbd)

Intel.hex

Intel.hex




Design Entry




Design Entry

.edf.edf


simulation)


simulation)

.psof.psof

FitterFitter

.pof

.sof.pof.sof



Plug-in


Plug-in

26


隨堂筆記


Stripe Architecture


Outline

Embedded ProcessorBus ArchitectureOn-Chip SRAMSDRAM ControllerExpansion Bus InterfaceEmbedded Peripheral Memory MapUARTTimer Watch Dog TimerInterrupt ControllerClockConfiguration LogicReset & Mode ControlIEEE Std.1149.1(JTAG) SupportI/O Features


Embedded Processor


ARM922T Processor

Based on ARM922™ (ARM920™ Derivative) & Incorporating ARM9TDMI™High-Speed Cache (8-KB Instruction + 8-KB Data) Memory Management Unit (MMU) Facilitates Implementation of Real-Time Operating Systems (RTOSs)Advanced Built-In System Debugging Features

– Debugging Module (next slice)– Embedded Trace Module (ETM) (next slice)

32-bit ARM & 16-bit Thumb Instruction Set SupportImplemented using a five stage pipeline

– fetch;decode;execute;memory;write stages200-MHz, 0.18-µ Process at TSMC


ARM922T Internal Organization

ARM9TDMI Processor Core

(+ Embedded ICE Interface)

AMBA Bus

Interface

Data MMU

Instruction Cache (8KB)

Embedded Trace

Module

Data Cache (8KB)

Write BackPage

AddressTAGRAM

Write Data

Buffer

JTAG AHB

C13IVA[31:0]

C13DVA[31:0]

IMVA[31:0]

DMVA[31:0]

ID[31:0]

DD[31:0]

Instruction MMU

IPA[31:0]

DPA[31:0]

WBPA[31:0]


Debug Support

The embedded in-circuit emulator (ICE) logic to provides breakpoint and watchpoint registers that are capable of halting the processor in response to specific events for software debug support.

EmbeddedICE Access to the embeddedICE registers is via JTAG scan chains.

The embeddedICE logic also contains a communication unit, which allows software running on the embedded processor to communicatewith a host via JTAG.

The embedded processor accesses these registers through MRC and MCR instructions to coprocessor CP14.

To manage communications between the embedded processor and the control register status bits effectively, COMMRX and COMMTX are routed from CP14 to the interrupt controller and to the PLD as INT_COMMRX and INT_COMMTX, respectively.


Trace Support

In EPXA10 and EPXA4 devices, the ARM9 Embedded Trace Macrocell(ETM9) provides additional capabilities for observing embedded stripe operations in real-time and at full operational bus speeds.

The ETM9 monitors the address, data and control signals and reports compressed information off-chip to the trace port interface.

The ETM9 used in EPXA10 and EPXA4 devices

The ETM9 can be enabled and disabled, and the trace port width is determined by PORTSIZE. The maximum size of the trace port is 16bits. When the debug session starts, the debug tools control ETMEN and PORTSIZE by programming the ETM control register.


ETM Connections


Bus Architecture


Bus Architecture Diagram

Embedded Stripe

WatchdogTimer

PLL

AHB 1-2Bridge

Dual-Port SRAM

SDRAMController

Single-Port SRAM

32-Bit RISC Processor


AHB1

AHB2

SDRAM SRAM

ConfigurationLogic Master

Reset Module Timer

UARTEBI

ROMFlash

PLD-to-Stripe Bridge

Stripe-to-PLD Bridge


What Is AMBA?

Advanced Microcontroller Bus Architecture (AMBA)– Open Specification that Defines On-Chip Communications Standards for

High-Performance Embedded Systems

Developed by ARM Limited in Conjunction with Others – Goal: Standardize the Way the ARM Bus Is Used

November 1993: First Specification Called Embedded Module Bus (EMB)September 1995: AMBA Rev C – Added Tri-State Turnaround for All SignalsApril 1997: AMBA Rev D – Minor Changes to Reset & Arbitration SchemeMay 1999: AMBA Rev 2.0 – Added AHB & Changed APB Rising Clock Edge Scheme


AMBA High-Performance Bus

AHB– 200-MHz Clock Rate– 32-Bit Wide Pipelined Data Bus

Burst Transfers: One Cycle per Data WordNon-Tri-State Implementation

– Multi-Master with Distributed Address DecodingSingle-Cycle Bus Master Handover

– Split Transaction ExtensionsAllows Full Bus Bandwidth in Multi-Master Bus

Multi-Layer Bus Architecture – Embedded Stripe– Connecting Embedded Stripe & Programmable Logic Peripherals


AMBA High-Performance Bus

The embedded stripe supports all AMBA AHB protocols, including the following:

– Incremental bursts of 4,8,16 and unspecified length– Wrapping bursts of length 4, 8 and 16– Early burst termination– SPLIT response on AHB2 (EBI only)– Locked transfers


AHB1

The embedded processor is the sole bus master on AHB1.

The only bus master on AHB1 is the embedded processor. Processorspecific slaves, such as the interrupt controller, are local to AHB1.

Embedded stripe memory resources such as the on-chip SRAM are also local to AHB1, which allows the embedded processor fast access to the memory.

Any transaction which, after decoding, is not intended for a peripheral on AHB1 is then routed to the AHB1-2 bridge. The AHB1-2 bridge is a slave on AHB1, which gives the embedded processor access to AHB2.


AHB1

The address decoder routes transactions addressed to the following slave peripherals on AHB1:

– SDRAM memory controller– On-chip SRAM, both single- and dual-port– Interrupt controller– Watchdog timer

These resources have configurable base addresses, set by on-chip registers located in the mode control module on AHB2. Bus transactions that are not recognized by the address decoder as being for AHB1resources are sent to the AHB1-2 bridge.


AHB1 Architecture

SDRAMControllerSDRAM

Controller

AHB1-2Bridge

AHB1-2Bridge

Interrupt ControllerInterrupt Controller

Watchdog TimerWatchdog Timer

Single Port SRAMSingle Port SRAM

Dual Port SRAMDual Port SRAM



Embedded Processor

Embedded Processor

AddressDecoder

AddressDecoder

To SDR /DDRSDRAM

To AHB2

From Interrupt Source

HSEL [7:0]

From AHB2

From AHB2

From AHB2 & PLD

From AHB2 & PLD

43


AHB2

The AHB2 has three masters:– AHB1-2 bridge– Configuration logic (the configuration logic exists as both a bus master and

slave)– PLD-to-stripe bridge

A priority arbitration scheme grants access to the AHB2 bus masters.

AHB2 has several local slaves, such as the embedded stripe memory resources, the UART, and the stripe-to-PLD bridge.


AHB2

The address decoder routes transactions addressed to the following devices:

– SDRAM memory controller– EBI, including the flash memory interface– On-chip SRAM, both single- and dual-port– UART– Embedded stripe bridges– Timer– Reset/mode control– Configuration logic (slave port)– Stripe-to-PLD bridge

All AHB2 resources have configurable base addresses which are set by on-chip registers located within the reset and mode control Module.


SDRAMControllerSDRAM

Controller

EBIEBI

UARTUART

Clock Generator(s)

Clock Generator(s)

TimerTimer

Reset / Mode Control

Reset / Mode Control

Configuration Slave

Configuration Slave

Stripe to PLD Bridge

Stripe to PLD Bridge





AHB 1-2 BridgeAHB 1-2 Bridge

PLD to Stripe Bridge

PLD to Stripe Bridge

ConfigurationMaster

ConfigurationMaster

AddressDecoder

AddressDecoder

From external PROM or JTAG

FromPLD

From AHB1Embedded Processor

ArbiterArbiter

HSEL [11:0]

AHB2 Architecture

46

To SDR /DDRSDRAM

To Flash

To Flash

To Flash

To PLD Configuration Register

To PLD

From AHB1

From AHB1

From AHB1 & PLD

From AHB1 & PLD


Embedded Stripe Bridge

There are three AHB bridges in the embedded stripe:– AHB1-2– PLD-to-stripe– Stripe-to-PLD

AHB1-2 Bridge– Provide the sole master on AHB1 access to AHB2

Stripe-to-PLD Bridge– AMBA AHB Bus into Programmable Logic – Access to Programmable Logic Peripherals

PLD-to-Stripe Bridge– AMBA AHB Bus into Embedded Stripe– Access to AHB2

Embedded Stripe Peripherals & MemoriesSDRAMEBI


AHB1-2 Bridge

Provide the sole master on AHB1 access to AHB2No synchronization logic is required in the AHB1-2 bridge


Stripe-to-PLD / PLD-to-Stripe Bridge

The PLD-to-stripe and stripe-to-PLD bridges provide the interface between the PLD and the embedded processor stripe. They provide AHB master and slave interfaces to the PLD. The embedded stripe bridges are functionally similar, with minor differences in the decoding scheme and bus structure. Following the block diagram highlights the access ports of the bridges.


Major Function Block AHB Bridge


Read / Write Transaction

For a read or a write transaction, the AHB slave interface passes the address and control information from the initiating master, plus a transaction processing request, to the AHB master interface.

The AHB master interface then synchronizes the transaction to its clock domain. The AHB slave interface inserts wait states if the AHB master interface is not granted access to the destination bus.

When it is granted the bus, the AHB master presents the transaction to the slave on the destination bus, which accepts the transaction and issues a response according to the AHB protocol.


Read / Write Transaction

The AHB master interface passes back the response from the slave to the AHB slave interface, which resynchronizes the response to its clock domain and sends an acknowledgement indicating that the bridge is ready to process another transaction.

The initiating master on the originating bus then samples the response from the AHB slave interface and responds accordingly.


Write Posting

Master starts a write transfer to a slave on the other side of the bridgeThe bridge captures and acknowledges up to 8 beats of dataA transfer longer than 8 beats will incur wait statesAs soon as all the data is in the bridge the Master is free to do something elseBridge is responsible for completing the write transfer to the slaveFor bursts longer than 8 the bridge will accept a new beat from the master for each one written to the slaveBridge accepts new transfers only when the posted write has completedPosting normally on


Read Prefetching

To increase bridge throughput, the embedded stripe bridges support read prefetching.

Read pre-fetching occurs in situations where the AHB master interface cannot determine the exact amount of data in a burst (i.e., an unspecified length burst is under way).

The AHB master interface continues to fill the read buffer until it is full, anticipating that the data will be needed.

When a new transaction begins, the data is no longer valid.


Read / Write Buffers

Read pre-fetch and write-posting buffers in all bridges are eight entries deep, where the size of an entry is either byte, half-word or word, depending on the transaction.

There is also one location for address and control information in the write buffer and one for slave response information in the read buffer.


PLD-to-stripe Bridge Signals


PLD-to-stripe Bridge Signals

The AHB slave interface is the standard AHB interface specified in the AMBA Specification, with exception of SLAVE_HSIZE[1..0].

SLAVE_HSIZE, on the embedded stripe, is only a 2-bit signal instead of 3-bit signal.

In addition, SLAVE_HSELREG is a chip-select pin which, when asserted, allows PLD masters to access the PLD-to-stripe bridge status register and the PLD-to-stripe bridge address status register.


Stripe-to-PLD Bridge Signals


Stripe-to-PLD Bridge Signals

The stripe-to-PLD bridge master interface is the standard AHB interface specified in the AMBA Specification, with the exception of MASTER_HSIZE.

As with the slave interface, MASTER_HSIZE is a 2-bit signal instead of a 3-bit signal.


On-Chip SRAM


On-Chip SRAM Structure


Single-Port SRAM

There are two blocks of single-port SRAM. Both are accessible to the AHB masters (AHB1 and AHB2) via an arbitrated interface within memory.

Each block is independently arbitrated, allowing one block to beaccessed by one bus master while the other block is accessed by the other bus master.


Single-Port SRAM

Synchronous RAMTwo Independently Addressable Blocks32, 128, or 256 Kbytes Byte AddressableBig- or Little-Endian TransfersAccessible by AHB Bus Masters


Single-Port SRAM

SRAM Block Size


Dual-Port SRAM

EPXA4 and EPXA10 devices also have two blocks of dual-port SRAM (DPSRAM), and EPXA1 devices have one.

The dual-port SRAM is accessible to the PLD and can be configured for access by the AHB masters.

The outputs of the dual-port memories can be registered if appropriately configured.

It is possible to build deeper and wider memories by using both dual-ports and multiplexing the data outputs within the stripe, although this capability is not supported on EPXA1 devices.


Dual-Port SRAM

Dual-Port Synchronous Memory– 32, 64, or 128 Kbytes, Depending on Device– Two Blocks per Device

Each Block Can Be Configured as Two Sub-Blocks – PLD Access via Port A – Embedded Stripe Access via Port B

Addressable from AHB1 or AHB2Option to Dedicate Port B to PLD

Various Widths & DepthsConfigured during PLD Configuration

PLD

Register

Dual-PortSRAM


Dual-Port SRAM Block


Dual-Port SRAM x8 Mode

DPRAM0 Shown, Similar for DPRAM1

32K

64K

DPR

AM

0D

PRA

M0

2 x 32K x 8

PLD

PLD

32K

64K

1 x 64K x 8

PLD

DPR

AM

0


Dual-Port SRAM x16 Modes

DPRAM0 Shown, Similar for DPRAM1

DPRAM0

DPRAM0

2 x 16K x 16

32K

64K

16K

PLD

PLD

1 x 32K x 16

64K

32K

PLD

DPR

AM

0


Dual-Port SRAM x32, x64 Mode

2 x 16K x 32 1 x 16K x 64

64K

32K32K

64K

16K 16K

DPRAM1 DPRAM0

DPRAM1 PLD

PLD PLDDPRAM0


SDRAM Controller


SDRAM Controller

Translates AHB Bus Transaction to SDRAM Control SignalsRuns Asynchronously to AHB1 or AHB2Transfers Byte, Half-Word & WordSupports Up to 512 Mbytes in Two Blocks 16-bit or 32-bit SDR or DDR SDRAM can be connectd

– PC100/133 Single Data Rate (SDR)– PC200/266 Double Data Rate (DDR)

All external signals are capable of interfacing with signals of 3.3-V LVTTL or 2.5-V SSTL-2 class II (15.2 mA). The mode is determined using the IOCR_SDRAM register (see page 168), with LVTTL as the default.


SDRAM Controller

SDRAM Controller Block Diagram


SDRAM Controller


Expansion Bus Interface



Interface to External Devices– Rate-Adaptation between Flash Memories or Memory-Mapped Peripherals &

AHB2 Bus Masters

Four Chip Selects – Each Address Space Can Be Configured to Operate in 8- or 16-Bit Mode

– Asynchronous or Synchronous Operation

– Bus Timing & Interface Signals Programmable

Supports Split Bus Transactions – Prevents Stalling Other AHB2 Bus Masters

The base address and size of each block can be set in the memory map registers



EBI consists of two interfaces, the AHB2 slave interface and the EBI interface, which communicate with each other by means of the transaction FIFO buffer and the read-return FIFO buffer.

The AHB2 slave interface receives transactions from masters on the AHB2 bus, which it posts to the transaction FIFO buffer.

The EBI interface decodes the transactions and drives the appropriate signals from the memory interface based on the settings in the control registers. For read transactions, the EBI interface posts read data to the read-return FIFO buffer.


AHB2 Slave Interface

The AHB2 interface consists of the AHB slave interface and the control and status registers.

The AHB slave interface decodes bus transactions from the AHB2 bus masters and provides a response based on the settings for the EBI block that has been targeted for the transaction.

The EBI block settings are maintained in the control registers.


EBI Interface

The EBI interface translates AHB transactions to memory accessesbased on the settings of the control registers.

The EBI interface consists of the timer and the EBI transaction sequencer, which are used in conjunction for EBI interface flexibility.


EBI MegaWizard Setting


UART


Embedded Peripheral Memory Map

Configurable to User RequirementsWhen the device is booting in boot-from-flash mode, the initial mapping presents EBI0 at base address 0H with 32 Kbytes of addressable space. The mapping is enabled after reset and can subsequently be changed or disabled.

Memory Map Control Registers Accessed via AHB2– Minimum Size Is 16 Kbytes


UART

The universal asynchronous receiver transmitter module (UART) performs serial-to-parallel conversion on data characters received from a peripheral device or modem, and parallel-to-serial conversion on data characters received from the embedded processor.

The UART operates in FIFO mode, with the FIFO buffers having a depth of 16 bytes. The CPU can read the status of the UART at any time during operation. The UART reports status information,includingthe type and condition of the transfer being performed,and any error conditions.


UART

The UART has the following features:– 5 to 8 data bits– 1 or 2 stop bits– Even, odd, stick, or no parity– 75 to 230,400 baud rate– 16-byte transmit FIFO buffer– 16-byte receive FIFO buffer– Programmable baud generator divides any input clock by 2 to 65535 and

generates the 16 × baud clock– Transmit FIFO buffer interrupt for empty indication and transmitter idle

indication– False-start bit detection– Internal diagnostic capabilities

Loop-back control for communications-link fault isolationBreak insertion and detection in loop-back mode

– Modem communication support


UART

UART Block Diagram


UART

UART Signals


UART

Following Diagram shows the data format when an 8-bit word with parity has been selected.

– BAUDRATE = CLK_AHB2/(divisor × 16) bits/sec– BITTIME = 1/BAUDRATE

UART Data Formats


Timer / Watchdog Timer


Timer

The timer is a dual-channel timer, with the following features:– 32-bit clock pre-scaler– 32-bit timer register– Three operating modes, selectable under register control:

Free-running interrupt (heartbeat)Software controlled start/stop (interval timer) with interrupt on limitOne-shot interrupt after programmable delay


Timer Channel Block Diagram


Watchdog Timer

The watchdog timer is a one-shot timer, which protects the system against software failure, or against severe hardware failures (such as lock-ups), due to power-supply problems, for example. It resets the entire chip when it expires and should be regularly reset by software to maintain normal operationFeatures of the watchdog timer include the following:

– 32-bit register interface– Timeouts of up to 30 seconds with a 33-MHz clock– Independent hardware, software, and bad reload triggers– Protection from accidental disabling by software



Interrupt controller provides a simple, but flexible, software interface to the interrupt system.

The input sources are as follows:– 10 interrupts from modules within the stripe– 1 external pin– 6 from the PLD stripe interface as an interrupt bus (INT_PLD).

Operating Modes– As six individual interrupts (the default mode)– As a single interrupt request, using a six-bit priority value– As a single interrupt request, using a five-bit priority value together with

one individual interrupt


Interrupt Signals


Six Individual Interrupts Mode


Six Individual Interrupts Mode

The six individual interrupts mode is the default mode at system reset.

It is typically used when six or fewer interrupts from the PLD are required.

Each PLD interrupt signal has its own mask bit in INT_MASK_SET; setting its corresponding mask bit in this register enables it to interrupt the embedded processor.

In addition, each PLD interrupt signal has its own mask bit in INT_MASK_CLEAR; setting its corresponding mask bit in this register disables it from interrupting the processor.


Six-Bit Priority Value Mode


Six-Bit Priority Value Mode

When more than six interrupt sources are required from the PLD, six-bit priority value mode can be used. In this mode, up to 63 interrupts can be encoded by user logic in the PLD. The INT_PLD[5:0] signals are interpreted as a six-bit encoded interrupt priority with either of the following values:

– 0—no interrupt from the PLD– Non-zero value—a requesting interrupt with priority ranging from 1 to 63.

You must implement your own interrupt controller in the PLD, because the following bits and registers have no effect in this mode:

– Bits P5 to P0 of INT_MASK_SET/INT_MASK_CLEAR– Bits P5 to P0 of INT_SOURCE_STATUS– Bits P5 to P0 of INT_REQUEST_STATUS– INT_PRIORITY_PLD5 to INT_PRIORITY_PLD0


Five-Bit Priority Value + Individual Interrupt Mode


Five-Bit Priority Value + Individual Interrupt Mode

In the five-bit priority value plus individual interrupt mode, INT_PLD[5] toINT_PLD[1] are treated as the most-significant bits of a six-bit encoded interrupt priority and INT_PLD[0] is treated as an individual interrupt.

The least-significant bit is always 0, with either of the following values:– 0—no interrupt from the PLD– Non-zero even value—a requesting interrupt with priority range between 2

and 62.

Users must implement their own interrupt controller in the PLD, because the following bits and registers have no effect in this mode:

– Bits P5 to P1 of INT_MASK_SET/INT_MASK_CLEAR– Bits P5 to P1 of INT_SOURCE_STATUS– Bits P5 to P1 of INT_REQUEST_STATUS– INT_PRIORITY_PLD5 to INT_PRIORITY_PLD1


Clock


Internal Clock Domain

Excalibur family has a number of internal clock domains.


EPXA10 Clock FrequencyVersus Speed Grade


Clock

External Reference– The clock input pin is 2.5/3.3-V LVTTL. It feeds two PLLs, PLL1 and PLL2,

that synthesize the internal clocks required.PLLs– Similar tp APEX PLLs.– The PLLs provide ClockBoost frequency multiplication only.– PLL1 provides the embedded processor clock, CLK_AHB1, and the

peripheral bus clock, CLK_AHB2. – PLL2 provides the clocks for the SDRAM controller.


Clock

– PLL ConfigurationParameters M, N, and K are used to program the PLL operating frequencies, using control registers (CLK_PLLy_NCNT, CLK_PLLy_MCNT and CLK_PLLy_KCNTrespectively).

The following equations show the calculations for programming a PLL:fVCO = CLK_REF × M/Nwhere the device parameter settings given follow.

Finally:PLLOUT = fVCO/Kwhere fVCO ranges from 160 MHz to 600 MHz.


Clock

Up to six clocks can be used for the interfaces between the embedded stripe and the PLD:

– Stripe-to-PLD bridge—MASTER_HCLK– PLD-to-stripe bridge—SLAVE_HCLK– Dual-port SRAM—up to four clocks

The clocks can be derived from any of the following APEX clock sources. Selectable inversion is available for each clock:

– Global clocks—up to four– Fast external clocks—up to four– Fast internal clocks—up to four– Internal local routing—user definable


Multiple Clock Domain

SDRAM Domain (133 MHz)

Processor Cache& MMU

DPRAM

Debug & Trace

Brid

geAHB1

PLL 2SDRAM

ControllerB

ridge

AHB2

BusExpansion

CommController

AHB

DSPFunction

Brid

ge

UART Timer

LCD

Processor Domain

AHB2 Domain

Typical Logic Domains(X MHz)

UART

USB

Oth

er B

us

PLL 1

APEX PLLs

Multiply or Divide

DSPFunction

SRAM

Four PLLs in EPXA4& EPXA10

Two PLLs in EPXA1

PLD

-to-S

trip

eB

ridge

Strip

e-to

-PLD

Brid

ge

AHB

DPRAM Interface


Configuration Logic


Configuration Logic

The configuration logic is responsible for transferring configuration data to the PLD array and setting up the system so that the embedded processor can boot. It has 2 features:

– Set up registers and on-chip SRAM as part of the configuration bitstream– Configure or reconfigure the PLD via the embedded processor’s

configuration-logic slave port

There are two configuration methods available to configure the device and make code available at the boot address. The processor always boots from address 0H. The two configuration methods are as follows:

– Boot from flash– Boot from an external source


Configuration Logic

The external pins BOOT_FLASH, MSEL1 and MSEL2 are used to enable the various configuration schemes used for booting the device.


Boot from Flash (1)

In this mode, the processor accesses the bootcode from either 8- or 16-bit flash connected to EBI0. The bottom 32 Kbytes of EBI0 are mapped at address 0H in boot-from-flash mode.

The registers are mapped to their default addresses, based at 7FFFC000H. Remaining devices are not mapped, and interrupts are disabled.

The Altera-provided Excalibur bootloader or a customer bootloader can be used to start up the system, make the necessary mappings, andread the PLD configuration data into the device.


Boot from Flash (2)

PLD Configuration– The Quartus II software should be used to generate PLD configuration data

in slave-port binary file (.sbi) format, which is used to configure the PLD from the embedded processor in bootfrom-flash mode. The .sbi is combined with the embedded register contents and the bootcode to form a HEX file that can be programmed into flash memory.


Boot from External (1)

When BOOT_FLASH is low, the device can either be configured by an external configuration source such as a configuration device, or via JTAG.

In boot-from-external mode, the embedded processor is held in reset while the PLD and the stripe are being configured. In passive serial or passive parallel modes, the standard APEX20KE configuration pins are used to configure the device. For JTAG configuration, the PLD TAP controller JTAG pins are used. The PLD array is configured using one of the following configuration schemes:

– Passive serial (PS)—Same as the APEX family– Passive parallel synchronous (PPS)—Same as the APEX family– Passive parallel asynchronous (PPA)—Same as the APEX family– JTAG—The Quartus II software provides the appropriate SRAM object file

(.sof)


Boot from External (2)

The configuration logic master configures the memory map, appropriate stripe memory, and the PLD. The configuration bitstream contains register writes to enable writable memory, such as on-chip SRAM, at address 0, and to write code into it. The register writes are followed by PLD configuration data. When the data transfer is complete, the bitstream writes to the boot control register, BOOT_CR to release the embedded processor from reset.

PLD Configuration– SRAM object files (.sof), raw binary files (.rbf), tabular text files (.ttf) or intel-

format .hexout formats produced by the Quartus II software are acceptable for PLD configuration. In addition, programmer output files (.pof) produced by the Quartus II software can be used to program external configuration devices connected to this interface.


Reset & Mode Control


Reset Types

The devices can be reset from many sources. The reset controller logic determines the cause of the reset, synchronizes it as necessary, and resets the appropriate logic blocks.

There are various types of reset, as follows:– Power-on reset

Embedded processor trace portReset status register, RESET_SREmbedded JTAG controller

– Warm resetEmbedded processor trace portReset status register, RESET_SREmbedded JTAG controllerEmbedded configuration logic


Reset Types

– JTAG resetThe JTAG input TRST resets the JTAG controller in the PLD.

– Configuration/reconfigurationAwarm reset clears the contents of the PLD, in addition to re-bootingthe stripe. If BOOT_FLASH is false, a warm reset also asserts nSTATUSto request reconfiguration. If BOOT_FLASH is true, a warm resetasserts nCONFIG to request reconfiguration.

– Processor resetIn boot-from-flash modes, the processor is held in reset for the duration of a warm reset.In other modes, the processor is additionally held in reset while the configuration is loaded. It is released when the PLD enters user mode.


Reset Source

Resets can originate from several sources:– PLD power-on reset– Resets from external sources

Configuration pin nCONFIGExternal reset pin nRESET (bidirectional open drain pin, supplying reset output to configuration or flash devices)External power-on reset nPOR

– Resets from internal sourcesWatchdog timer resetJTAG moduleConfiguration error


Reset Sequence


IEEE Std.1149.1(JTAG) Support


IEEE Std.1149.1(JTAG) Support

Various features are provided to facilitate debugging soft logic and running code, including the following:

– PLD JTAG TAP controller– Embedded processor JTAG TAP controller– SignalTap logic analyzer module

The Excalibur family provides JTAG BST circuitry that complies with the IEEE Std. 1149.1-1990 specification. The Excalibur devices contain two JTAG TAP controllers, one for the PLD JTAG boundary scan chain and one for the embedded processor.


JTAG Modes

There are two JTAG configurations:– Serial-JTAG mode

In serial-JTAG mode, the PLD TAP controller is followed in series by the embedded processor TAP controller. Both TAP controllers are accessible from the same physical port.

– Parallel-JTAG mode In parallel-JTAG mode, the PLD TAP controller and processor TAPcontroller are connected to separate ports. The PLD TAP controller is connected to the TMS, TDO, TDI, TCK, and TRST pins, and the processor TAP controller is connected to the PROC_TMS, PROC_TDO, PROC_TDI, PROC_TCK, and PROC_TRST pins.


Serial / Parallel JTAG Modes

Serial JTAG Mode Parallel-JTAG Mode

JSELECT = 0 JSELECT = 1


PLD JTAG Tap Controller

PLD TAP controller allows boundary scan testing of the physical pins on the device and downloading of configuration data.

The JTAG port can also be used to monitor the logic operation of the device with the SignalTap embedded logic analyzer.

The Excalibur family can be configured through the PLD JTAG portusing the Quartus II software. The device can be in serial or parallel JTAG mode. The device can also be configured with hardware usingeither Jam Files (.jam) or Jam byte-code files (.jbc).


SignalTap Embedded Logic Analyzer

The PLD section includes enhancements to support the SignalTapembedded logic analyzer.

By including this circuitry, the Excalibur family provides the ability to monitor design operation over a period of time through the IEEE Std. 1149.1 (JTAG) circuitry; A designer can analyze internal logic at speed without bringing internal signals to the I/O pins.

This feature is particularly important for advanced packages such as FineLine BGA packages, because it can be difficult to add a connection to a pin during the debugging process after a board is designed and manufactured.


Embedded Processor TAP Controller

The ARM processor TAP controller instruction register length is 4 bits. Refer to the ARM922T Technical Reference Manual for a list of JTAGinstructions and scan chains supported by this TAP controller.


I/O Features


I/O Features

The family of Excalibur embedded processor PLDs maintains all of the existing APEX 20KE I/O features on the PLD I/O.

As with APEX 20KE devices, high-speed LVDS is supported on only –1 and –2 speed-grade devices. Devices that are –3 speed-grade support only low-speed ×1-mode LVDS.


I/O Control

Four banks of pins can be used directly by the embedded stripe. In EPXA10 devices, the pin banks are selectable for use by either the stripe or the PLD. In EPXA4 and EPXA1 devices, the pin banks arededicated to the embedded stripe. The banks are as follows:

– SDRAM interface– EBI (including miscellaneous signals)– UART– Trace port

The stripe selects whether each bank is controlled by the stripe or thecPLD. When the stripe controls the bank, it can select the following I/O standard properties for it:

– Output control (open drain, slow/fast slew rate, enable PCI diode, enable JTAG debug)

– Input mode (2.5/3.3-V LVTTL, 1.8-V LVTTL, SSTL-3/GTL+, VREF)


I/O Control

Separate power banks are supplied to the following peripherals:– SDRAM interface—With additional VCCIO pins and VREF supply, enables

SSTL-2 operation and allows the other embedded logic I/O to interface to a different I/O standard

– EBI– UART– Trace port

SDRAM Controller– The SDRAM controller supports SDR SDRAM and DDR SDRAM,– which require two different IO standards to be supported:

LVTTL for SDRAMSSTL-2 for DDR SDRAM


隨堂筆記


Introduction to Altera & Altera Devices


The Programmable FPGA Solutions

Devices Continued– Excalibur™

Devices– ACEX ® Devices– FLEX® Devices– MAX® Devices

Devices– Stratix™ Devices– Cyclone™ Devices– APEX™ Devices– Mercury™ Devices

Intellectual Property (IP)– Signal Processing– Communications– Embedded Processors

Tools– Quartus® II Software– MAX+PLUS® II

Software


Introduction to Altera FPGA Devices

Programmable Logic Families– High & Medium Density FPGAs

Stratix, APEX II, APEX 20K, & FLEX 10K

– Low-Cost FPGAsCyclone & ACEX 1K

– FPGAs With Clock Data RecoveryStratix GXMercury

– CPLDsMAX 7000 & MAX 3000

– Embedded Processor SolutionsNiosTM, ExcaliburTM

– Configuration DevicesEPC


APEX Device Family Overview


APEX 20K Family Overview

Industry’s first MultiCore Architecture– Look-up table (LUT) logic– Product-term logic– Embedded memory

Fabricated on SRAM Process– 2.5-V, 0.25/0.22-Micron Process– 1.8-V, 0.18-Micron Process

Advanced Programmable Element MatriX (APEX)


MultiCore™ Architecture

MultiCore Makes Million-Gate PLD Design PossibleFacilitates Efficient IP Integration

– Look-up Table Core– Product-Term Core– Memory Core

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory

LUT

P-Term

Memory


Enhanced FastTrack Interconnect

4-Level FastTrack Interconnect Continuous Routing– Fast, Predictable Timing

MegaLABInterconnect

LocalInterconnect

Row Interconnect

ESBMegaLAB™

MegaLAB

ColumnInterconnect


APEX 20K Device Features

Features

EP20K30E EP20K60E EP20K100EEP20K100

EP20K160E EP20K200EEP20K200

EP20K300E EP20K400EEP20K400

EP20K600E EP20K1000E EP20K1500E

Typical Gates 30,000 60,000 100,000 160,000 200,000 300,000 400,000 600,000 1,000,000 1,500,000

MaximumSystem Gates 112,704 161,792 262,912 404,480 525,824 728,064 1,051,648 1,537,024 1,771,520 2,391,552

Logic Elements 1,200 2,560 4,160 6,400 8,320 11,520 16,640 24,320 38,400 51,840

Maximum RAMBits 24,576 32,768 53,248 81,920 106,496 147,456 212,992 311,296 327,680 442,368

MaximumMacrocells 192 256 416 640 832 1,152 1,664 2,432 2,560 3,456

Maximum UserI/O 128 204 252 316 382 408 502 624 680 808

All Devices Have JTAG BST Circuitry(IEEE Std. 1149.1-1990 Compliant)


Comparison of APEX 20K & APEX 20KE

MultiCore System Integration

Feature APEX 20K Devices APEX 20KE Devices

Full support

Hot-socketing support Full support Full support

SignalTap logic analysis Full support

64-Bit 66-Mhz PCI Full Compliance Full Compliance

MultiVolt I/O2.5-V or 3.3-V VccioVccio selected for device

1.8-V, 2.5-V, or 3.3-V VccioVccio selected block-by-block

ClockLock supportClock delay reduction2x and 4x clock multiplication

Clock delay reductionN/(m x k) clock multiplicationDrive ClockLock output off-chipLVDS support

Dedicated clock and input pins Six Eight

Full support

Full support


Comparison of APEX 20K & APEX 20KE

I/O Standard Support

Feature

5.0-V Tolerant Inputs3.3-V PCI5.0-V PCILVCMOSLVTTL

APEX 20K Devices APEX 20KE Devices

3.3-V PCI3.3-V AGPCTTGTL+HSTL (Class I)SSTL2 & SSTL3LVCMOSLVDS

Memory support Dual-port RAMFIFORAMROM

CAMDual-port RAMFIFORAMROM


APEX 20K and APEX 20KE Architecture & Features


Architecture & Features

Dedicated Inputs, Dedicated ClocksMegaLAB, LAB (Logic Array Block)Logic Element (LE)

– Register Packing– Carry Chain– Cascade Chain

Embedded System Block (ESB)FastTrack Interconnect™IO Element (IOE)


APEX 20K Device Block Diagram

EP20K400/E and larger– Smaller devices have 2 columns

Row

MegaLAB

I/O

I/O I/OMegaLAB

I/O

MegaLAB

I/O

MegaLAB

I/O

Row

MegaLAB MegaLAB MegaLAB MegaLAB

Row

MegaLAB MegaLAB MegaLAB MegaLAB

I/O

I/O

I/O I/O I/O I/O

I/O

I/O

...... ... ...

Colum

n

Colum

n

Colum

n

Colum

n


APEX 20K MegaLAB

Logic Element (LE)– 4-Input LUT– D Flipflop– Carry & Cascade Chains

Logic Array Block (LAB)– 10 LEs

MegaLAB– n LABS

10 (EP20K30E)16 (EP20K60E - EP20K600E)24 (EP20K1000E and larger)

– 1 Embedded System Block (ESB)

MegaLAB

Embedded

SystemBlock(ESB)

LAB

n

LAB

1

LAB

2

LE

LE

LE

LE

LE

LE

LE

LE

LE

LE

MegaLAB Interconnect


Dedicated Inputs, Clocks

4 Dedicated Inputs Drive 4 Global Control Nets that Can Drive– Any LE Control Signal (Clock, Clock Enable, Syn Clear, Syn Load, Clear)– Four Nets of the “Peripheral Control Bus”

(Clock, Clock Enable, Clear, Output Enable)– Data– Any Combination of Above

4 Global Control Nets Can Also Be Driven by Internal Logic2 (APEX 20KE has 4) Dedicated Clocks Drive 2 Global Clock Nets that Can Drive

– LE Clock Signals– IOE Clock Signals– Data– Any Combination of Above– Cannot Serve as Any Other Control Signal


LAB Control Signal Generation

Note (1): APEX 20KE devices have four dedicated clocksNote (2): LABCLR1 and LABCLR2 signals also control asynchronous preset for LEs within the LABNote (3): SYNCCLR signal can be generated by the local interconnect or global signals

LABCLR1 (2)

LABCLR2 (2)

LABCLKENA1

LABCLK1

SYNCLOADor LABCLKEN2

Global Signals

Dedicated Clocks

LocalInterconnect

LocalInterconnect

LocalInterconnect

LocalInterconnect

//

42 or 4 (1)


APEX 20K Logic Element

Look-UpTable(LUT)

CarryChain

CascadeChain

Carry-In Cascade-In

data1data2data3data4

labclr1

Clock & Clock EnableSelect

labclk1labclk2

Carry-Out Cascade-Out

PRN

CLRN

To FastTrackInterconnect,

MegaLAB Interconnect,or Local Interconnect

D Q

Chip-Wide

Reset

ENA

Packing Register Select

labclr2

labclkena1labclkena2

AsynchronousClear/Preset/Load Logic

SynchronousLoad & Clear

Logic

LAB-wideSynchronous

Clear

LAB-wideSynchronous

Load


Carry/Cascade Chain Construction

Function’s Carry/Cascade Chain Can Begin in Any LE of a LAB– Carry Chain Counter Starting at LE1 could be Faster, because Register

feedback multiplexer is available on LE1 of each LAB

Runs Downward through LEs of a LABAt End of LAB, Continues to Top of Second-Next LAB in Same RowStops at ESB

ESB ESB...


Embedded System Block


Embedded System Block

Enhanced Embedded Structure

LAB

16

LAB

1

LAB

2

EmbeddedSystemBlock(ESB)

LELE

LE

LELE

LELELELE

LE

MegaLAB InterconnectProduct Term

RAM

ROM

CAM (APEX 20KE)


ESB Embedded RAM Features

Variable Width– 2,048 Bits per ESB– Easily Combined to Build Wider/Deeper Memories

Dual-Port– Independent Read/Write– Synchronous/Asynchronous

2,048 X 11,024 X 2512 X 4256 X 8128 X 16


Creating Wider Memories

Example: Wide Memory Block Created by Combining ESBs in Parallel

128 X 16

128 X 16

128 X 32

256 X 8

256 X 8

256 X 16


LPM Implemented in ESB

LPM Functions can Take Advantage of these Modes Depending on theParameters Set

– e.g. Dual-port RAM


Product Term vs LUT Implementations

Designs Suited for Product-Term Implementation– Control Logic

Complex State MachinesAddress Decoding

Designs Suited for LUT Implementation– Registered-Data-Path Functions– Math Functions– Digital Signal Processing


Product-Term Logic in ESB

The ESB Can be Configured to Act as a Block of Macrocells on an ESB-by-ESB basisWhen in Product-Term Mode, Each ESB is Configured as 16 Macrocells


Integrated Product Term Performance

In the Past, Integration of Product Term and LUT Based Functions required a Two-Chip Solution

APEX Allows for an Integrated Product-Term Logic which Improves System Performance


ESB as CAM (APEX 20KE)


Content Addressable Memory (CAM)

Looks up Data in Memory & Outputs AddressCAM Accelerates Fast Search Applications

– Functions as a Parallel Comparator– Order of Magnitude Faster than RAM (Serial)

Address

Match FlagCAMCAMData


Discrete CAMs

Advantage: Larger– Size Ranges From 256x64 to 128Kx288

Disadvantage: Slower– Discrete CAM May Be Up to 5x Slower– May Require Multiple Accesses to Read Data


APEX 20KE ESB as CAM Features

CAM in ESB Provides for Faster System Performance– No Off-chip Delay– Significantly Less On-chip Delay

ESB CAM Implementations:– Single Match Mode– Multiple Match Mode– Fast Multiple Match Mode

Each ESB Can Be Used With Up to a 32x32 CAM– Additional Supporting Logic Required– For Larger CAM Functions, ESBs can be Cascaded


CAM User Interface

ALTCAM Megafunction– Set Parameters Using MegaWizard


APEX 20K/E I/O Features

MultiVolt Support Hot Socketing Support

– Refer to Operating Requirements for Altera Devices Data SheetPull-up on I/O pins Before and During ConfigurationIndividual Tri-State ControlPin-by-Pin Programmable Slew Rate ControlPin-by-Pin Selectable 3.3-V PCI ClampI/O RegistersProgrammable Initial State for RegistersProgrammable Delay Elements


APEX 20K IOE vs. APEX 20KE IOE

Open-drain Operation– APEX 20K - Open-drain emulation– APEX 20KE - True open-drain output

Faster Clock-to-Output for open-drain signals

Programmable Delays to Internal Logic– APEX 20K - 2 modes (OFF and ON)– APEX 20KE - 4 modes (OFF and 3 levels of delay)

Column IOE Interconnect– APEX 20K - Column IOE signals route to column interconnect– APEX 20KE - Column IOE signals route to column and FastRow

interconnect


Altera MultiVolt™ Circuitry

MultiVoltTM Circuitry Separates Power & Ground for Device Core & I/OAllows APEX 20K/E Device to Bridge between Systems of Different VoltagesSee AN 107: Using Altera Devices in Multi-Voltage Systems

APEX 20K APEX 20KEVCCINT 2.5V 1.8VVCCIO 2.5V, 3.3V 1.8V, 2.5V, 3.3V


APEX 20KE I/O Blocks

Note (1) The LVDS input and output blocks support all of the IO standards and can be used as input, output, or bidirectional pins at 3.3-V, 2.5-V, and 1.8-V.


APEX 20K PLL Features

Altera’s Next-Generation PLL – ClockLock™ Synchronization Circuitry– ClockBoost™ Multiplication Circuitry (1X, 2X & 4X)

Can Use Any Combination of Two ClockBoost Outputs SimultaneouslyEither Signal Can Drive Any LE, IOE, or ESB

– Extended Frequency Range– Can Use PLL Output to Clock Negative Edge Triggered Flip-Flops

ClockLock/ClockBoost

ClockLock/ClockBoost

gclk1

gclk0

PLLclk1

clk0


APEX 20KE PLL Features

Multiple PLLs– 2 or 4 Depending on Device Size

Advanced ClockBoost Circuitry– Supports Variable Multiplication

1.5 MHz <= fIN <= 160 MHz1.5 MHz <= fOUT <= 200 MHz

ClockShift Circuitry– Time Delay Adjustment Up to One Period– 90/180/270 Degrees Shifting

Drive PLL Output Off-Chip with or without Feedback


隨堂筆記



The Altera MegaWizard Plug-in Manager (a graphical user interface utility) provides the designers the ability to set the operational parameters for the embedded processor. The MegaWizard Plug-In outputs a system build descriptor file (.sbd), which describes the set-up of the device, including the following characteristics:

– Device booting—from an external flash device or an external FPGA configuration device

– Processor endian-ness– Device memory map– Use of the bridges between the stripe and the PLD– configuration of integrated peripherals (timers, UART, SDRAM, EBI)– Peripheral input-voltage levels– Peripheral output configurations– Frequency of operation (settings for the PLLs) for the processor and the

SDRAM controller



In addition to parameterization of the embedded stripe, the MegaWizardPlug-In produces files used in the FPGA logic design and verification, as well as instantiating simulation models for the hardware and software cosimulation.The files produced are the following:

– .v or .vhd files containing instantiations of the embedded processor and dual-port RAM blocks and header files, as follows:

for Verilog files, module instance containing stripe structural code, plus an include filefor VHDL files, entity instance containing stripe structural code, plus .vhd package, plus additional template component declaration (VHDL 1987 only)

– A ‘C’ language header file, containing definitions of the memory map– an assembly language header file, containing definitions of the memory map– A block symbol file, needed for instantiation in a Quartus II software Block

Design FileWhenever the MegaWizard Plug-In updates the .sbd file, it automatically recreates these files.


MegaWizard Plug-In Process


The Excalibur MegaWizard (page1/5)

You can selectively enable various stripe peripherals here.

Choose how you want to reset the processor here.

If none of these options are checked the process will need to be configured in passive serial mode.



Turn off or on the stripe bridges.



Set the reference clock frequency for the CPU.

Set the desired AHB1 frequency, the max is 200MHz for C1 devices. AHB2 will automatically be ½ the AHB1 frequency.

Set the desired SDRAM frequency. The max is 266MHz for DDR on C1 devices (133MHz for SDR).

Indicate here the configuration device you are using if any.



Set the base address of the CPUs registers here.



Set the base address of the SRAM blocks here.



Set the base address for the dual-port RAM blocks.

You can treat the two blocks as independent or you can combine them.

Each block is configurable to different widths.



Combining the DPRAMs leaves the following size options.



Enable the EBI interface here. You can have up to 4 different memories on the EBI bus.



Enable or disable read pre-fetching. Don’t enable this if reads have a side effect on youperipherals.

Set the base address of the PLD interfaces.The pld-to-stripe bridge can support up to 4 regions in the PLD. Each region must be a multiple of 16K.


Software Build Settings


Set Toolset Directory

Select General Settings (Project Menu)Go To Toolset Directories Tab and Settings Passed to Third-Party Software Toolset: ADS Standard Tools

– Select ADS Standard Tools

– Browse to<ADS_Install Dir>\bin

– Click Open

Click OK


Software Build Settings

Software Build Setting– ARM922T Architecture– ARM Development Suite

(ADS) Standard Tools– Little Endian Byte Order– Hexadecimal(Intel)

Format– hello.hex

(Software Image)– Programming Files

Flash Memory ConfigurationMerges SBI with HEX


C++ Compiler Tab

C/C++ Compiler Tab– Optimization Level: Low– Goal: Minimize Size– Preprocessor definitions:

DEBUG– Additional include

directories: .,..\common

– Generate Debug Info

Click OK


Assembler Tab

Assembler Tab– Preprocessor definitions: Null– Additional include directories: .– Generate debug info– Keep local symbol in

symbol table

Click OK


Linker Tab

Linker Tab– Symple– Entry: 0x0– Read-Only Base: 0x0– Read/Write Base:

0x20000– Command Line Options

Specify Entry Point

Click OK


Compile Software Code

Processing Menu Start Software Build– Generates Getting_Started_Example_flash.hex

Getting_Started_Example.sbi Getting_Started_Example.hex

Application Application CodeCode

PLD ImagePLD Image

Flash Flash Programming Programming

FileFile

Getting_Started_Example_flash.hex


Device Configuration


Configuration Methods

Flash Memory Configuration– Processor Centric– Possible for Multiple PLD Images

Passive Configuration– PLD-Centric– Passive Serial– Passive Parallel– JTAG


Configuration Files

System Build Descriptor - SBD– Text File with Information of the Stripe Registers, PLL etc– Used by Quartus II and for Generation .h files for software

SOF / POF / RBF / HEXOUT – Quartus II Files– Complete Configuration Files– PSOF + SBD + HEX

PSOF– Partial SOF file, only PLD Configuration (Intermediate file)

SBI – Complete PLD Configuration File for FLASH Programming– No HEX file, No Register Configuration Data

HEX– Application Image in Intel Hex Records


Booting from Flash flow

Altera provides a bootloader for use when booting from external flash memory. The bootloader initializes the device registers according to the MegaWizardPlug-In output, including setting up the memory map of the device; and then loads the software into RAM. It resets the watchdog timer and finally sets the endian-ness of the processor, before passing control to the user’s code.



.h.c.ccc


Stripedeclaration

.v or .vhdStripe

declaration

HDLTemplateHDL

TemplateSystemBuild

Descriptor(.sbd)

SystemBuild

Descriptor(.sbd)

Intel.hex

Intel.hex




Design Entry




Design Entry

.edf.edf


simulation)


simulation)

.sbi.sbi

FitterFitter

.o.o




LoaderLibrary

LoaderLibrary

.hexout.hexout


Plug-in


Plug-in

199


Boot-from-Flash Configuration

Processor Boots from External Flash & Configures Embedded Stripe & Programmable LogicFlash Programming Can Be Done Using JTAG

8- or 16-BitFlash

Memory

Programmable Logic

ARM-Based Excalibur Device

Configuration Unit

EBI SRAM

EmbeddedStripe

Config-uration

Port

Embe

dded

JTA

G P

ortProcessor

Config RegistersConfig RegistersConfiguration Registers



When a device is configured using the Altera flash bootloader, the required output at the end of a successful design compilation is an Intel .hex file.To run a hardware compilation and produce a .hex file for configuring a device from flash memory, proceed as follows :

– 1. Run the Excalibur MegaWizard Plug-In to configure the embedded logic.

– 2. Create an Intel .hex file for the software image using either the compiler/linker provided with the Quartus II software in software mode or a preferred utility.

If the .hex file does not contain an entry point, it is assumed to be the first address in the .hex file.

The ARM FromElf utility does not specify an entry point in the .hex file, even if it is non-zero, so the first address is always used.



– 3. Use the Quartus II software to compile the design, generating a slave binary image (.sbi) file.

– 4. Use the MakeProgFile command-line utility to merge the .hex file, the .sbd file, and the .sbi PLD image into an object file.

– 5. Use the GNUPro linker arm-elf-ld, or the ADS linker armlink, to link the object file produced by MakeProgFile, with the boot library boot.a, to produce an executable and linkable format (.elf) file.

– 6. Use the GNUPro tool arm-elf-objcopy, or the ADS tool fromelf to create a .hex programming file.



Steps 4 through 6 can be accomplished in one of the following ways:

– Using the excalibur-build utility from the SOPC SDK Shell.Excalibur-build calls the compiler tools and utilities required to produce the final FLASH programming file

– Using the software builder in the Quartus II software and selecting the flash configuration option

– Using a custom makefile, which is called from the Quartus II software command line after the build


8-bit/16-bit FLASH

EBI

Excalibur ARM Processor

The intel .HEX programming file is generated by a combined effort of Quartus II and external softwares

– The .HEX component is made by Quartus II in Software Mode or by external software tool

– The .SBI component is made by Quartus II in Hardware mode– The .SBD component is made by the Excalibur MegaWizard

Quartus II User H/W DesignOther IP

Quartus IIOR

Industry StandardCompiler/Linker/

Relocator

User S/WDesignLibrariesRTOS

intel .HEX

.HEX

.SBI

=

+

.SBD+

Configuration File in Flash


EBI/Flash Interface in Boot-From-Flash Configuration

BOOT_FLASH

MSEL0

MSEL1

EBI_WEn

EBI_CSn[0]

EBI_OEn

EBI_OEn

EBI_ADDR[(16 OR 8):1]

EBI_DATA[7:0]

WE#

CE#

OE#

OE#

A15-A0

DQ15-DQ0

8-bit/16-bit FLASH

EBI


Boot_Flash MSEL1 MSEL0 Mode1 0 0 Boot From 16bit Flash1 0 1 Boot From 16bit Flash, 1.8V1 1 0 Boot From 8bit Flash1 1 1 Boot From 8bit Flash, 1.8V

Connecting the EBI to external Flash


Excalibur Flash Programmer

Programs Flash via JTAGDownloads Application to Processor

– Interrogates Flash– Reads Data from JTAG– Programs Flash on EBI0

Supports Industry Standard Flash– Intel & AMD– Flash with Common Flash Interface (CFI) Query Table


Boot-from-FLASH Reconfiguration

PLD


Configuration Unit

EBI SRAM

StandardCell

ConfigPort Em

bedd

edJT

AG

Por

t

SDRAM

EEPROM

FLASH

PLD can be configured/reconfigured by the embedded processor at any time after it is booted

– Read/write config registers thru user instructions (e.g. assembly code)– Multiple PLD images can be stored in external memory device(s) (e.g.

SDRAM, EEPROM, Flash)

Processor

Config RegistersConfig RegistersConfig Registers


Remote Reconfiguration (1/2)

Processor


ConfigurationUnit

EBISDRAM

SRAM

PLD

StandardCell

ConfigPort Em

bedd

edJT

AG

Por

t

MAC + PHY ASSP

Ethernet

Data is uploaded from Ethernet to the SDRAM thru MAC+PHY ASSPThen Reconfigure the PLD as in the Processor-centric reconfiguration mode


Remote Reconfiguration (2/2)Remote Reconfiguration (2/2)

Processor


ConfigurationUnit

EBI

FLASH

SRAM

PLD

StandardCell

ConfigPort Em

bedd

edJT

AG

Por

t

Ethernet

10/100Ethernet MACPHY

The MAC core is Instantiated in the Original PLD ArrayReprogram the Flash with the Remotely Sent Config FileWarm Reset (e.g. time out by a watchdog) and Reconfigure the Whole device thru Boot-From-Flash

BOOT_FLASH=1

MSEL0

MSEL1


Booting from an External flow

The sequence of tool use for configuration from an external configuration device, via passive configuration schemes.



.h.c.ccc


Stripedeclaration

.v or .vhdStripe

declaration

HDLTemplateHDL

TemplateSystemBuild

Descriptor(.sbd)

SystemBuild

Descriptor(.sbd)

Intel.hex

Intel.hex




Design Entry




Design Entry

.edf.edf


simulation)


simulation)

.psof.psof

FitterFitter

.pof

.sof.pof.sof



Plug-in


Plug-in

210


Booting from external Configuration

Configuration Unit Loads Embedded SRAM & Programmable Logic while Processor Is Held in ResetPassive Serial/Passive Parallel Is Supported Same as APEX 20KE Devices

Programmable Logic

ARM-Based Excalibur Device

Configuration Unit

EBI SRAM

Standard Cell

Config-uration

Port

Embe

dded

JTA

G P

ortProcessor

Serial/ParallelPLD

ConfiguratorJTAG/Programmers

OR

Down-load

Cable


Booting from external Configuration

When a device is configured using a passive-serial or passive-parallel configuration scheme, the required output at the end of a successful hardware compilation is one or more of the following file types.

– .pof– .sof– .rbf– .ttf– .hexout


How to create a programming file of the hardware design?

The following steps explain how to create a programming file of the hardware design.

– 1. Run the Excalibur MegaWizard Plug-in to configure the embedded logic.

– 2. Create and synthesize the RTL, using either the Quartus II software or third-party hardware development tools.

– 3. Specify a software image (in Intel .hex format) to be merged into the programming file at the fitting stage.

The Quartus II software always produces a .pof and a .sof file.Optionally, .rbf, .ttf, and .hexout files are also produced.


How to generate a configuration file for the software design?

The following steps explain how to generate a configuration file for the software design.

– 1. Create an Intel .hex file for the software image using either the compiler/linker provided with the Quartus II software in software mode, or a preferred utility.

If the .hex file does not specify an entry point, it is assumed to be the first address in the .hex file.

– 2. Use the Quartus II MakeProgFile command-line utility to merge the .hex file, the .sbd file, and the partial SRAM object file (.psof) PLD image into the appropriate types of programming file.


Serial / ParallelPLD

Configurator

DowloadCable


ConfigPort

OR

Quartus II User H/W DesignOther IP

Quartus IIOR

Industry StandardCompiler/Linker/

Relocator

User S/WDesignLibrariesRTOS

.SOF

.POF/

.RBF/.TTF/

.HEXOUT

.SOF.POF/.RBF/.TTF/

.HEXOUT

.HEX

.PSOF

=

+

.SBD+

Configuration Files in PLD-centric Mode


PLD-Centric Configuration Interface

ConfigPort

Excalibur ARM

Processor

BOOT_FLASHMSEL0MSEL1TSTNSCNnSTATUSCONDONEDCLKnCEnCEOINITDONERDYnBSYnCSCSnWSnRSDATA0DATA[7..1]CLKUSRnCONFIG

Boot_Flash MSEL1 MSEL0 Mode0 0 0 Peripheral Serial0 1 0 Peripheral Parallel Synchronous0 1 1 Peripheral Parallel

Asynchronous

Serial / ParallelPLD

Configurator


Excalibur Device Utilities


Introduction

We will descriptions and usage guidelines for the Excalibur device utilities:

– excalibur-build– makeprogfile– exc_ flash_programmer– jtagconfig– Memimagedecoder

The excalibur-build utiliy is installedn with the GNU Tools and Excalibur Component—the other utilities are installed automatically when you install the Quartus II software.


Excalibur-build

The excalibur-build utility is a simple alternative to a makefile and provide a quick method of building applications for the Excalibur device. The use of makefiles is fully supported for complex applications. The excalibur-build utility invokes the tools need to compile, assemble and link source code targeted to the Excalibur Device. It insures the standard C libraries and standard Excalibur Libraries are linked with the user source code and the associated “include” paths are available. Most programs will compile with no command line options; reasonable defaults are assumed. Excalibur-build produces a file with the base name of the last source file on the command line and the suffix _flash.hex. The file is ready for downloading to flash on EBI0 on the target board. Source files are listed on the command line following the options. If only one source file is specified, excalibur-build searches the current directory for files with the same base name and underscore extensions.


Excalibur-build

Usage : The excalibur-build utility has the following syntax– excalibur-build [options] <sourcefiles.[c]>


Makeprogfile

The makeprogfile utility is a command line utility that merges the hardware logic image with the software application to generate a boot data file, serial programming files, or simulation model initialization files.Usage :

– [-h/--help] Displays help message– [-v/--version] Displays version of makeprogfile– {passive programming file options} <project>.sbd [<filename>.psof]

[<file>.hex ]– {flash programming file options} <project>.sbd [<filename>.sbi]

[<file>.hex]– {simulation init file options} <project>.sbd [<file>.hex]


Makeprogfile

Passive programming file options are:– -e/--serial-eprom <EPC2/EPC4/EPC8/EP16>– [-s/--sof <filename>.sof] Generates .SOF file– [-p/--pof <filename>.pof] Generates .POF file(s)– [-r/--rbf <filename>.rbf] Generates .RBF file– [-t/--ttf <filename>.ttf] Generates .TTF file– [-x/--hexout <filename> .hexout]Generates .HEXOUT file– [-a/--hexout-addr <address>] Specifies start address for .HEXOUT


Makeprogfile

Flash programming file options are:– -b/--bootdata <filename>.o– -nc/--no-compression Suppress the compression of preload dat

Simulation initialization file options are:– -m/--model-init <basename> Base name of model initialization files


Exc_flash_programmer

The exc_ flash_programmer utility is a stand-alone command line utility for programming flash connected to the expansion bus interface of the EPXA devices.

The utility uses the ByteBlaster download cable via the JTAG interface. Flash programmer supports 16-bit flash devices, which are compatible with either the Intel 28FXX0C3 (primary OEM command set 0003) orthe AMD AM29DL32XD (primary OEM command set 0002) advanced boot-block families.


Exc_flash_programmer

Usage : exc_flash_programmer {options} <hexfile.hex>

The following options are available:

– -a All the blocks are erased. The application quits after executing this command

– -c <cable name> Selects which JTAG cable to use– -n <n> Selects device number (for chains with two or more Excalibur

devices)– -e <n> Sets which EBI block to use– -p Programs the flash from the input file– -v Verifies contents of flash with input file– -f Fast mode. Each used block is erased without compare. Old data is

deleted (This option is especially appropriate forthe EPXA1 device.)– -r <256 byte aligned hex read size> Reads flash contents into file– -t <64-bit protection code> Sets 64-bit protection code– -g Starts processor after successful programming– -o <64K aligned offset> Offset is subtracted from every input hex address– -h Help


Jtagconfig

The JTAG configuration utility, jtagconfig, allows you configure the JTAG server on the host machine. It can also detect a JTAG chain and setup the download hardware configuration.

Usage : The following options are available:– --version Displays version of jtagconfig– --enum Enumerates devices present in the JTAG chain attached to the

hardware. Names of devices are indicated for known devices.– --add <type> <port> Tells the JTAG server that the specified hardware

type is attached to the specified port. USB devices are auto-detected and therefore do not need to be added using the jtagconfig utility.

– --remove <id> Removes the hardware specified by the ID number.– --help Displays help message


Memimagedecoder

Memimagedecoder is a command line utility that retrieves the Excalibur embedded processor stripe initialization data from an SRAM object file (.sof), and boot data from the boot data file <project name>_bootdata.o respectively. Memimagedecoder then displays the data in readable format to allow the code to be examined.Usage:

– memimagedecoder [-h/--help/] Displays help message– memimagedecoder[-v/--version] Displays the version of memimagedecoder

– memimagedecoder <filename> .sof [output-option]

Load Excalibur stripe initialization data from an SOF and output the data in a readable format.

– memimagedecoder <filename>o [output-option]

Load Excalibur stripe initialization data from a bootdata object file and output the data in a readable format.

The following output option is available. When the output option is not specified, all the data interpreted from the input file is displayed in the command window.

– -o/--output filename Output file


Excalibur System Verification


Introduction

Altera provides users of Excalibur systems with multilayered simulation environment that can be used to extensively verify system-on-a-programmable-chip (SOPC) designs, as follows:

– First, the AMBA™ AHB-based peripherals can be verified using the Bus Functional Model (BFM).

After verifying the functionality of the peripherals, the next stage in verifying an SOPC design is to test the integrity of the complete system, using either of the following models:

– The Excalibur stripe simulator (ESS)—which is a fast, functionally-accurate model of the Excalibur embedded stripe.

– The full stripe simulation model—which allows you to perform cycle-accurate simulations of the Excalibur embedded processor and the other components of the embedded stripe.


Bus Functional Simulation


Bus Functional Model

BFM, ESS and Full Stripe Model can all be used to verify AHB peripherals.

– The BFM is fastest at verifying an AHB peripheral as it does not model the processor.

– The BFM models both pld-to-stripe and stripe-to-pld transactions

– The Excalibur bus functional model emulates the behavior of the AMBA high-performance bus (AHB) masters and slaves. It allows you to quickly perform AHB master and slave peripheral verification (essentially an AHB testbench).


Bus Functional Model : Master / Slave Port

Models AHB Master Bus Transactions


Master Port

mastercommands.dat

slavememory.cfg.dat

Logic Slave PeripheralControl Signal

AddressData


Slave Port

mastercommands.dat

slavememory.cfg.dat

slavememory.<bank#>.dat

Logic Master PeripheralControl Signal

AddressData



– The bus functional model can either be run with a stand-alone third-party tool, such as the ModelSim simulation tool, or as part of the QuartusIIsoftware. Its behavior is the same irrespective of environment.

– To simulate the stripe-to-PLD interface file, user must specify a file of bus command transactions. For a PLD-to-stripe interface file, you must specify an initialization file for memory locations, and a control file for details of the behavior of each memory block.


Bus Functional Model Process


Stripe-to-PLD Transactions

The bus functional model interprets read and write transactions supplied in a control file. Transaction specifications can include wrapping and incremental burst operations, busy and idle transactions. The maximum number of transactions is fixed, but varies according to the simulator used.


PLD-to-Stripe Memory Specification

The PLD-to-stripe input consists of a configuration file and a variable number of memory initialization files, as follows:

– The configuration file contains memory mapping information, such as the number, size, and access delays for each memory bank

– Each memory initialization file specifies the initial contents of a particular memory bank. The number of memory initialization files is determined by the configuration information.


Stripe-to-PLD Emulator

Although the bus read and write operations are initiated by the bus functional model, to the PLD they appear to be AHB-protocol bus transactions originating at the stripe-to-PLD interface.During simulation, the bus functional model interprets the read and write operations in its transaction table and applies them to the PLD. It interprets the given signals accurately as transactions, determining full details and the success of each transaction. Bus events are triggered by the rising edge on the bus interface clocks.


PLD-to-Stripe Emulator

The first access to a memory bank in any burst, whether read or write, can incur a number of wait states. The number of wait states to insert is specified in the memory initialization files. Memory access delays are specified in units of wait states for each memory bank. Different values may be supplied for each bank, as well as for initial and subsequent reads and writes.


Using the Bus Functional Model with Third-Party Simulators

User can use the bus functional model to support third-party simulation of the bus interfaces using VHDL and Verilog HDL models.

The bus functional model is shipped as clear-text Verilog HDL and VHDL, which should be complied in the third-party simulation tool.

MegaWizard Plug-In generated stripe instance:

<Instance name>

lpm_instance:alt_exc_stripe

Bus_func_model:alt_exc_upcore Bidir(in VHDL only)


Using the Bus Functional Model with Third-Party Simulators

The MegaWizard Plug-In-generated .v or .vhd file instantiates alt_exc_stripe, which is the embedded stripe instance.

The bus functional model wrapper files link to the alt_exc_upcoremodule, which is the bus functional model instance.


BFM Wrapper

<MegaWizard wrapper>.vhd/.valt_exc_stripe

This wrapper file is generated whenever you configure an Excalibur ARM stripe in the MegaWizard.

alt_exc_stripe.vhd / .v

alt_exc_stripe_arch_bfm.vhd

alt_exc_upcore

These files are wrapper files that connect the BFM to your Excalibur ARM stripe instance.

altera_mf.vhd / .valtera_mf_components.vhd

The altera_mf files define the BFM (alt_exc_upcore)


HDL Bus Functional Model Hierarchy

Verilog

VHDL


Using Bus Functional Modelwith the Quartus II Software

Use the bus functional model to simulate the bus interfaces from within the Quartus II simulator.For simulations run natively in the the Quartus II software, the PLD-to stripe model does not simulate the presence of memory banks.

These transactions are recorded in a log file and read transactions always return zeros.



The filenames expected by the bus functional model depend on whether it is being used as part of a third-party tool or from within the Quartus II software.For use with third-party tools, bus functional model filenames are asfollows:

– mastercommands.dat—Bus control input file for the master port– slavememory.cfg.dat —Input file containing configuration details for all

memory banks – slavememory.n.dat—Input file containing memory bank initialization data,

where n is a number between 0 and 5, referring to the appropriate memorybank

– output.dat—Output log file containing details of the transactions effected



When used from within the Quartus II software, the bus functional model expects filenames to be constructed from a root and a suffix. You can specify the file to use by choosing Simulator Settings (Processing menu) and then selecting the Options tab, as shown the side.



The file suffixes are listed below:– <root>.mbus_in—Bus control input file for the stripe-to-PLD interface

– <root>.mbus_out—Output log of transactions on the stripe-to-PLD interface

– <root>.sbus_in—Input file containing configuration details for all memory banks. (This is not available in the Quartus II software)

– <root>.sbus_out—Output log of transactions on the PLD-to-stripe interface


Stimulus Command file

Bus Transactor Translates input.dat to mastercommands.datinput.dat Format

WRITE ( START, SIZE, LENGTH, DATAVALUE, [ , DATAVALUE …] ); READ ( START, SIZE, LENGTH);IDLE ( CYCLES );

Example


mastercommands.dat


Pre-Synthesis Simulation

Quartus IISoftware

Design

input.dat

mastercommands.dat

stimulus.doslavememory.cfg.dat

(Slavememory.<bank#>.dat)

Output

ModelSimTool

exc_bus_translate.exe

Altera_mf.vAlt_exc_stripe_bfm.v

Design.v

# MASTER: trans=[ 1] addr=[00000004] WRITE data=[00000005] expected=[00000005] WORD OKAY

# MASTER: trans=[ 3] addr=[00000004] READ data=[00000000] expected=[00000000] WORD OKAY


Post-Synthesis Simulation

Quartus IISoftware

Designexc_bus_translate.exe

mastercommands.dat

stimulus.doslavememory.cfg.dat

(slavememory.<bank#>.dat)

ModelSimTool

apex20ke_atoms.v<design>.vo

<design>..sdoalt_exc_stripe_bfm.v

Third-Party

SynthesisTool

DesignEDIF

Input File(.edf)

input.dat

Output# MASTER: trans=[ 1] addr=[00000004] WRITE data=[00000005] expected=[00000005] WORD OKAY

# MASTER: trans=[ 3] addr=[00000004] READ data=[00000000] expected=[00000000] WORD OKAY


The BFM Simulation Process

1. Provide the BFM with stimulus– Write stimulus commands into a file (“input.dat”)– BFM Stimulus command format

WRITE( START, SIZE, LENGTH, DATAVALUE, [ , DATAVALUE …] ); READ ( START, SIZE, LENGTH);IDLE ( CYCLES );

2. Translate the “input.dat” file– BFM expects an input called mastercommands.dat– Translate input.dat to mastercommands.dat using exc_bus_translate utility– exc_bus_translate is included in the Quartus bin directory

3. Create the slavememory.cfg.dat file– The slavememory.cfg.dat file configures the memory space viewable to the PLD

through the PLD-to-stripe bridge


The BFM Simulation Process

4. Initialize the stripe memory banks if you are using the PLD-to-stripe bridge– If you turned on any memory regions in the slavememory.cfg.dat file you should

initialise their contents.– Up to 6 banks of memory are supported. If used they are initialised through

files called slavememory.<bank number>.dat

5. Place the following files in your simulation directory– mastercommands.dat– slavememory.cfg.dat– slavememory.<bank number>.dat (if used)

6. Then compile your testbench, design and BFM models.


Full stripe simulation


Full stripe simulation model

Full stripe simulation model provides a system-level verificationenvironment for Excalibur designs.

It is used to monitor the interaction between user software code running on the ARM922T™ processor, interacting with any of the peripherals implemented on the stripe, and any logic designed on the PLD side of the Excalibur device.

All of the stripe peripherals are modelled by the full stripe simulation model, including the on-chip SRAM and dual-port SRAM (DPRAM).

The model is very powerful, because users can monitor many of the internal signals of the stripe and view their relation to other signals in the design in a fully cycle-accurate manner.


Full stripe simulation model

The model makes the following stripe nodes visible to users during simulation:

– ARM922T internal registers– Embedded stripe registers– AHB1 bus signals– AHB2 bus and arbitration signals– Bridge signals– Interrupt signals

As with the ESS, this model is used to simulate hardware and software running simultaneously and interacting with each other.


Excalibur System

SDRAMModel

Excalibur Stripe

Programmable Logic

Stripe-to-PLD (Master Port)

EBI Port

SDRAM Port

Master

Slave

PLD-to-Stripe (Slave Port)

ROMModel


Verification

Full Stripe / ESS Model Verification


Full Stripe Simulation Flow


Full Stripe Simulation Process

Step1– Excalibur systems are designed and configured using the Excalibur

MegaWizard® Plug-In Manager. The MegaWizard Plug-In allows you to configure the Excalibur embedded stripe; it generates a VHDL or VerilogHDL wrapper file that instantiates a configured alt_exc_stripe entity.

Step2– After you have configured the stripe using the Excalibur MegaWizard Plug-In,

you connect the stripe wrapper to your top-level design. The stripe wrapper instantiates the alt_exc_stripe entity that is defined in the full stripe model (alt_exc_stripe.v or alt_exc_stripe.vhd).

Step3– Software code for the full stripe model can be stored in either external

memory models or in model initialization files (MIFs), which are used to initialize the on-chip memory of the Excalibur device.


Full Stripe Wrapper


This wrapper file is generated whenever you configure an Excalibur ARM stripe in the MegaWizard.

alt_exc_stripe.vhd / .v

This file defines the full stripe model.


Model Initialization Files

The full stripe simulation model can run software code directly from the on-chip SRAM or DPRAM by using the MIFs.

The Full Stripe Model requires that you provide it with 5 Model Initialization Files (MIF) [not to be confused with Memory Initialization Files]

– memory.SRAM0– memory.SRAM1– memory.REGS– memory.DPRAM0– memory.DPRAM1



If simulate code running from on-chip memory in conjunction with the full stripe model, it is important to include the MIFs listed at the following table in the current simulation directory:



The DPRAM0 and DPRAM1 files can be used to intialize the DPRAM for use by logic in the PLD.

– The format of the MIF file is described in the QII 4.0 on-line help.

– Example MIF file:

0/EA00002A; 1/EA000006; 2/EA000009; 3/EA00001B; 4/EA00001E; 5/EA000001; 6/EA000014; 7/EA00001F; 8/EAFFFFFE; 9/E92D5FFF; A/EB000778; B/E8BD5FFF; C/E25EF004; D/E92D5FFF; E/E25E0004; F/E5900000;


Model Initialisation Files

The MIF files are generated every time you compile your softwareproject using the Software Builder in Quartus.

If you are not using the Software Builder to build your C/C++/ASM project, then you can use the makeprogfile utility to generate the 5 MIF files.

– you need the .SBD file for your project as well as the .hex file (containing your software image) from your software development tools.

– To generate MIF files using the utility as follow

makeprogfile -m memory <file name>.sbd <file name>.hex


Running software image from an External ROM

Software images to be simulated running on the full stripe model can be stored in an external ROM model instead of MIFs. Although running designs out of a ROM model is slower than running from SRAM using a MIF, it provides a more realistic model of the system.

To simulate a software image running out of ROM,user must connect a ROM model containing the software image to the top-level design. The Quartus II Software Builder can be used to generate a hex file to initialize the ROM.


Creating the ROM initialization filewith the software builder

The ROM initialization file is named rom_image.txt in the example shown in side Figure.

The hex file is converted from the .elf file created by the software compiler.

Fromelf utility is shown below:

fromelf -c -vhx <software image name>.elf -output <ROM initialization file name>


Compilation Order for RTLSimulations

Designs can be simulated using the full stripe model after the MIF or ROM initialization files have been generated. The compilation order for RTL simulations is listed below:

1. alt_exc_stripe.vhd2. <stripe wrapper filename>.vhd3. <any user logic modules>.vhd4. <rom model filename>.vhd (optional)5. <top-level filename>.vhd6. <testbench filename>.vhd

Verilog designs require the same files as listed above (*.v)


Compilation Order for Timing Simulations

The following compilation order is used for timing simulations:

1. apex20ke_atoms.vhd2. apex20ke_components.vhd3. apex20ke_stripe.vhd4. <stripe wrapper filename >.vhd5. <any user logic modules >.vhd6. <rom model filename>.vhd (optional)7. <top-level filename>.vhd8. < testbench filename >.vhd

Verilog designs require the same files as listed above (*.v)


ESS Simulation


Excalibur Stripe Simulator

The Excalibur Stripe Simulator (ESS) is a fast stripe simulationmodel developed specifically to facilitate the integration of software and hardware in Excalibur devices. ESS can execute more than 500,000 ARM instructions per second on a high-performance PC, with high visibility of the internal processor and stripe registers, PLD-to-stripe and stripe-to-PLD bus transactions.ESS emulates the key functional behavior of the embedded stripe, which allows you to run operating system applications.

Provide SW/HW co-verification environment• SW debug capabilities• HDL simulation environment

Provide functionality to simulate complex systems Fast SW executionFast HDL simulation


Can be used in 3 ways:

The ESS can be used in the following 3 ways:– Software Simulation

The ESS can connect to a debugger and be used as an ISS– Hardware Simulation

You can use the ESS to model the stripe within an HDL simulator.– Hardware/Software Co-simulation

You can connect the ESS to a debugger and simultaneously simulate your logic design in ModelSim with the debugger and the logic simulator interacting.


ESS Functionality

ESS provides the following functionality:– A functionally-accurate model of the ARM 922T™ processor– Models the watchdog timer, timer, and interrupt controller– Embedded UART modeled as a character stream device– Models the interface to the PLD through the stripe-to-PLD bridge, PLD-to-

stripe bridge, and the PLD application interface– Mechanism to load a flash memory image connected to EBI0 (booting from

flash memory)– Fast mechanism to initialize on-chip SRAM and stripe registers– Interface to appropriate software debuggers according to the platform used

(PC / Solaris)– Instantiation within a Verilog HDL or VHDL design


Memory Initialization

There are two means of initializing ESS:– Booting from flash memory

To simulate booting from flash memory, you need to generate a flash memory image. The image is an Intel hex format file, which can be identical to that required to program the flash memory on the EPXA development board.

– Fast initialization of the stripe memory imageFast initialization of the stripe memory image allows you to initialize stripe registers and on-chip SRAM without having to simulate running the boot code. This is consistent with the cycle-accurate full stripe model. Five initialization files are used. They share a common filename prefix and use specific extensions, as below


Software SimulationUsing ESS as an Instruction Set Simulator

To use ESS, users must always select a memory image. Because theprocessor subsystem always starts execution at address 0x0, you can provide either a flash memory image in Intel hex format or a set of memory initialization files

To debug a program using AXD, ensure that you have generated theappropriate memory image file and debug symbol file, using the ADS toolkit to provide debug control.



Configuring AXD to Use the ESS TargetTo configure AXD to use ESS as the target simulator, proceed as follows:

– 1. Start the AXD software by doing one of the following:– From the Windows Start menu, choose Programs>ARM Developer Suite>AXD Debugger.From the Quartus II software, change to software mode and choose Launch Debugger (Processing menu). Ensure that the ARM software toolset is selected: choose General Settings (Project menu) and click the Toolset Directories tab.At the command line prompt, type AXD↵. Ensure that the AXD path is listed in your PATH environment variable.



– 2. In the AXD software, select ESS as the target simulator, as follows:a. Choose Configure Target (Options menu) to display the Choose Target window.b. If the target dll ESS-RDI.dll does not appear in the list of target environments, click Add and open the file ESS-RDI.dll in the path $QESS_ROOTDIR/bin directory.c. Highlight the ESS-RDI.dll target by clicking on it.

Note: When you select the ESS target environment, you must configure it and specify a memory initialization file before you can proceed with AXD debugging.



– 3. Configure the simulator target: click Configure to display the ESS Options window for the Altera RDI.

a. Click the Standard Options tab to modify the memory initialization settings;



b. Click the Stripe Options tab to override the default ESS settings.c. Enable the UART by turning on Use UART in the Stripe Options tab.d. Click the Advanced Options tab to modify the UART settings.



Optionally, you can use the advanced options to:– Connect to a terminal emulator which is not automatically launched by ESS– Launch a different terminal emulator (select Launch other)

For example, to launch a version of HyperTerminal, which allows connection over TCP/IP, you type the following text in the Launch other text box:

<path>/hypertrm.exe /t 127.0.0.1:9001Connect over a non-default port if port 9001 is already used on your machine (select Specify port and enter the portnumber)



– 4. Click OK to close the Choose Target window. Check that the AXD RDI log (System Output Monitor window) displays the following banner:

ARM-Based Excalibur Fast Stripe Model (ESS) - Version 2.2Copyright (c) Altera Corporation 2002. All rights reserved.

– 5. You can optionally load the source code debug symbols from an executable and linkable format (ELF) file: select Load Debug Symbols (File menu) and choose the file containing the debug symbols associated with the ARM program source code. Typically, you would select files with extensions .elf and .axf, which are both ELF format. The debug symbols are generated by the ADS tools during the software compilation or assembly.


Hardware SimulationUsing ESS in a Third Party Logic Simulator

ESS can be instantiated within a Verilog HDL or VHDL design using alt_exc_stripe from the LPM, and simulated in a third party simulation tool.Using ESS in a Third Party Logic SimulatorTo use the ModelSim simulation tool to perform a pre-routing functional simulation of a Verilog HDL or VHDL design for Excalibur devices using ESS, proceed as follows:

– 1. Start the ModelSim simulation tool.

– 2. Click on Create a Project and specify the project’s home directory and a project name.

– 3. Click OK.

– 4. Add the following line to the modelsim.ini file, or to the <project name>.mpfModelSim project file, under the VSIM section following the Veriuser comments line:

Veriuser = $QESS_ROOTDIR/bin/libess_sspli.soThis provides the path to load objects for Verilog HDL PLI applications dynamically.



– 5. Specify the ESS-specific parameters by creating the file ess_options.txtin the simulation directory and specifying a line for each required parameter in the format:

ESS_PARAMETER = ESS_VALUE

– 6. To create a new work library:a. Choose Create a New Library (Design menu).b. Under Create, select a new library and a logical mapping to it.c. In the Library Name box, type the library name; for example, work.d. Click OK.



– 7. Compile the design files:a. Choose Compile (Design menu).

For VHDL designs, ensure that the ESS source files, ess_hdl.vhd and alt_exc_stripe_ess.vhd, are compiled using the VHDL 93 syntax by performing the following steps:

– I. In the Compile HDL Source Files window, select Default Options. Ensure that the Compiler Options window is displayed.

– II. In the VHDL page, turn on Use 1993 Language Syntax.– III. Click OK to modify either the ModelSim project file (.mpf) or modelsim.ini.

b. Select$QESS_ROOTDIR/eda/sim_lib/excalibur/ess_hdl/ess_hdl.v (or.vhd) and click Compile.

c. Choose Compile (Design menu).



d. Select$QESS_ROOTDIR/eda/sim_lib/excalibur/lpm/alt_exc_stripe_ess.v (or .vhd) and click Compile.

e. Choose Compile (Design menu).

f. Select the Verilog HDL or VHDL design file(s), and the test bench file (if you are using a test bench) and click Compile.

The ESS HDL files required for Verilog HDL and VHDL designs are listed in thefollowing Table.



– 8. Load your design:a. Choose Load New Design (Design menu).b. Select your top-level design file or test bench file, and click Load.

– 9. Simulate the design files:a. Ensure that the memory initialization files are in the simulation directory, and that stimulus is provided for the signals nPOR and CLK_REF.b. Select Run-All (Run menu) to run the simulation.



Simulation timeExcalibur DesignsFull stripe model Fast stripe model

Board diagnostics /Hello world

25 hrs 7 seconds

DPRAM 20 mins 9 secondsMultimaster_ahb 5 mins 5 secondsVxWorks boot 15 days * 3 mins


Hardware/Software Co-simulationUsing Software Debugger in Logic Simulator

ESS can be instantiated within a Verilog HDL or VHDL design using alt_exc_stripe from the LPM. In addition, by setting the USE_SW_DEBUGGER parameter, you can connect a softwardebugger to the simulation, to control code execution on the processor subsystem.Setting Up ModelSim

– 1. Start the ModelSim simulation tool.– 2. Choose Create a Project (Design menu) and specify the project’s home directory

and a project name.– 3. Click OK.– 4. Add the following line to the modelsim.ini file, or to the <project name>.mpf

ModelSim project file, under the VSIM section after theVeriuser comments line:

Veriuser = $QESS_ROOTDIR/bin/libess_sspli.so

This provides the path to load objects for Verilog HDL PLI applications dynamically.



– 5. Specify the ESS-specific parameters by creating the file ess_options.txt in the simulation directory and specifying a line for each required parameter in the format:

ESS_PARAMETER = ESS_VALUE

– 6. Run the Altera debugger initialization macro alteradebugger.do, which is located in $QESS_ROOTDIR/eda/sim_lib/excalibur/ess_hdl, by choosing Execute Macros (Macro menu). This allows communication between the software debugger and Modelsim.

– 7. Compile the appropriate Altera-provided libraries, user design files and test bench.

– 8. Load your design:a. Choose Load New Design (Design menu).b. Select your top-level design file or test bench file, and click Load.



– 9. Begin running the simulation:a. Ensure that the memory initialization files are in the simulation directory, and that stimulus is provided for signals nPOR and CLK_REF.b. Choose Run –All (Run menu). Check that the following text is displayed in the ModelSim window:

# Info: Waiting for connection from Software Debugger ...# Break at alt_exc_stripe_ess.v line <line number>

c. The simulation waits for a connection from a SW debugger from port 9998.



Connecting AXD to ESS in ModelSim– 1. Start the AXD software.– 2. In AXD, select ESS as the target simulator.

a. Select Configure Target (Options menu) to display a Choose Target window.b. If the target dll ESS-RDI.dll does not appear in the list of target environments, click Add and open the file ESS-RDI.dll in the path $QESS_ROOTDIR/bin directory.c. Highlight the ESS-RDI.dll target by clicking on it.

– 3. In AXD, configure the simulator target:a. Click Configure to display the ESS Options window.b. Click the Standard Options tab to set up the simulator.



c. Turn on Connect to logic simulator.d. Check that the other options in the ESS Options window are not selectable, because the parameters have already been selected in the logic simulation environment.e. Click OK.



– 4. Now you can connect to ESS in a logic simulation environment. Click OK in the Choose Target window.

– 5. Check that Logic Simulator connection successful is displayed in the AXD RDI window. AXD is now connected to ESS started in the ModelSimsimulation tool.

– 6. In AXD, load source code debug symbols (optional): choose Load Debug Symbols (File menu) and choose the file containing the debug symbols associated with the ARM program source code.

– 7. In AXD, insert appropriate software breakpoints, data watch points as required.

– 8. In AXD, start simulation by selecting Go (Execute menu) or by single-stepping through instructions or higher level code.

– 9. To disconnect AXD from the ModelSim environment, in the ModelSimwindow, choose Restart (Run menu).



Stripe Simulation ModelStripe Simulation ModelStripe Simulation ModelSoftware Debugger

Logic Waveforms


ESS Wrapper


This wrapper file is generated whenever you configure an Excalibur ARM stripe in the MegaWizard.alt_exc_stripe_ess

.vhd / .v

alt_exc_upcore This is a wrapper file that connects the ESS to your Excalibur ARM stripe instance.

ess_hdl.vhd / .v

This file defines the ESS (alt_exc_upcore)


Technical Support:

CIC technical support: – Phone : 03-5773693 ext 885* – E-mail : [email protected]

mailto:[email protected]

altera sopc design with arm - 國立臺灣大學r93088/dip/2004_08_sopc.pdftools such as altera’s...

Documents