PHD Designers Guide - Imperial College London€¦ · PIPEFlow Bus Routing The LBC looks after all the PIPE routing. This is all done in a transparent manner and as a PHD designer,

SONIC Board – PIPE Hardware Designers Guide

Version 2.00

Simon Haynes

Imperial College

Contact: [email protected]

Document HistoryVersion Date By NotesDraft 1.00 30/10/98 Simon

HaynesCreated

Draft 1.01 2/11/98 SimonHaynes

Add YUV FormatAdded SRAM Image format description.


Minor corrections.


Yet more minor corrections


Changed PIPEFlow Instructions

2.00 09/07 SimonHaynes

Major overhaul, reflecting changes in PIPEFlow bus andcorrections. Title changed from VHD Designers guide toPIPE Hardware Designers Guide.

Contents1. Introduction...................................................................................................... 1

Who’s this document for? .................................................................................... 1What’s in this document? ..................................................................................... 1Overview of the SONIC Concept......................................................................... 1The four stages of PHD design............................................................................. 1Terminology ........................................................................................................ 2

2. Overview Of the SONIC Board ........................................................................ 3Plug In Processing Elements (PIPEs) ................................................................... 3PCI Bus............................................................................................................... 3Serial Digital Interface (SDI) ............................................................................... 3PIPE Bus ............................................................................................................. 3PIPEFlow Buses .................................................................................................. 4PIPE Control Signals ........................................................................................... 4Local Bus Controller (LBC)................................................................................. 4Key Points ........................................................................................................... 4

3. Plug-In Processing Elements (PIPEs)................................................................ 6The PIPE Engine (PE) ......................................................................................... 6The PIPE Router (PR) ........................................................................................ 6The PM ............................................................................................................... 7Key Points ........................................................................................................... 7

4. Using the SONIC board for Software Acceleration ........................................... 8Software model for software acceleration............................................................. 8Different Modes of usage..................................................................................... 9PIPEFlow Method ............................................................................................. 11

5. Using SONIC as a Real-time Processor .......................................................... 15Software Model ................................................................................................. 15

6. The PIPE Engine (PE) .................................................................................... 17PIPE Bus ........................................................................................................... 17PIPEFlow Buses ................................................................................................ 17PM interface ...................................................................................................... 18CL & CR Ports .................................................................................................. 18PM Chip Select Signal (CSM)............................................................................ 18PE Chip Select Signal (CS) ................................................................................ 18Interrupt Signal (INT)........................................................................................ 18Key Points ......................................................................................................... 18

7. Combining PIPEs to form MEGA-PIPEs ........................................................ 19Key Points ......................................................................................................... 19

8. PM Details ..................................................................................................... 20PM connections ................................................................................................. 20Function Tables ................................................................................................. 20Timing Diagrams ............................................................................................... 20PM and the PR .................................................................................................. 21Interface Design – MEMORY_INTERFACE_10K70 ........................................ 21Key Points ......................................................................................................... 23

9. PIPE Bus Protocol ......................................................................................... 24Single Transaction Mode ................................................................................... 25

Burst Mode Transfer.......................................................................................... 26Key Points ......................................................................................................... 27

10. PIPEFlow Bus Protocol .............................................................................. 28PIPEFlow Bus data format................................................................................. 28Signals used by the PIPEFlow Bus..................................................................... 30PIPEFlow bus timing diagrams .......................................................................... 31Example using the PIPEFlow Bus – An image colour inverter ............................ 31Key Points ......................................................................................................... 32

11. PM Image Format ....................................................................................... 34Total Image Size................................................................................................ 34Key Points ......................................................................................................... 34

12. PE Registers................................................................................................ 35An example register file for the PE..................................................................... 35Key Points ......................................................................................................... 37

13. How to use the PIPE Hardware Design (PHD) with SONIC........................ 38Generating the include (.inc) files ....................................................................... 38Locking The Pins for the Design ........................................................................ 38Choosing the Correct Device ............................................................................. 39Compiler Options............................................................................................... 40Compilation ....................................................................................................... 40Conversion From .sof File to .rbf File................................................................. 41Key Points ......................................................................................................... 42

14. Example PHD - Filter .................................................................................. 43Method of Operation ......................................................................................... 43Hardware Design ............................................................................................... 43

15. Futher Reading............................................................................................ 44PIPEFlow information ....................................................................................... 44PHD design examples ........................................................................................ 44PHD design tutorial ........................................................................................... 45PR information .................................................................................................. 45

16. PE Pin Allocations....................................................................................... 46

SONIC PHD Designers Guide Simon Haynes, Imperial College 1

1. Introduction

Who’s this document for?This document is for someone creating a PHD (PIPE Hardware Deisgn) for SONIC. It is expectedthat the designer has a reasonable understanding of AHDL (Altera Hardware Description Language).Some knowledge of FPGAs would also be extremely helpful!

What’s in this document?This document explains the architecture of the SONIC board and the Plug-In Processing Elements(PIPEs) and how they relate to PHDs. The document concentrates only the details of the SONICboard necessary for the PHD. The different ways that SONIC can be used are discussed – the relativebenefits and drawbacks examined. The different buses and protocols used by SONIC are explained,and example AHDL code is given to that uses these protocols.

Overview of the SONIC ConceptSONIC is a PCI plug-in board for a PC, designed to process video images. SONIC containsreconfigurable hardware (FPGAs); hardware whose functionality can be altered by changing theconfiguration. How the hardware is configured determines how the images are processed. To makeSONIC process the image in a particular way, it is necessary to design the appropriate hardware to dothe task (rather than writing a program to do the processing, a circuit is designed) – this is the PIPEHardware Design (PHD).

The PC controls SONIC; it configures the hardware and sends and receives parameter data. Theimages processed by SONIC can come either from the PC (images stored on the hard disk, forexample), or externally from an SDI input. Similarly the processed images can be retrieved by the PC,or sent out over the SDI output.

The four stages of PHD designSo what do you actually have to do to design a PHD? There are five stages:

1. Decide the best way to use SONIC for the taskSONIC is very flexible; most tasks can be mapped to the SONIC architecture in many ways. UsingSONIC in the most effective way may simplify the design process and give better performance.

2. Design a ‘circuit’ to implement the taskThe next stage is to design a ‘circuit’ to implement the task. It is best to try to split the design intolots of logical blocks (Memory interface, register file etc.) – many times existing blocks can be used,saving time and heart ache.

3. Write the AHDLHaving designed the circuit, you must now write the AHDL file(s) that will implement it.

4. Test the DesignNext, you need to use MAXPlusII to check that the design behaves as you expect.


5. Compile the design.When the design works probably, you must compile the AHDL file(s) to a single file (an rbf file) thatwill be used by the PC to configure the PIPEs.

TerminologyThroughout this document the follow terms and abbreviations are used:

PIPE Plug-In Processing Element, one of the eight plug in modules in the SONIC board

PE PIPE Engine, the FLEX10K70 on each PIPE which is responsible for theprocessing power of the PIPE

PR PIPE Router, the FLEX10K20 on each PIPE which controls the routing

PM PIPE Memory - 4Mbytes organised as 32 bits by 1M

PIPE Bus 32 bit Address/Data multiplexed global bus largely used for burst transfer of images

PIPEFlowBus

16 bit bus which pass images in ‘raster-scan’ fashion between adjacent PIPES.

Task One single image processing task which normally occupies one PIPE (This could bean operation like filtering, or rotation, for example)

PHD PIPE Hardware Design. This is the design which the designer generates, to describethe task

MEGA-PIPE When two or more PIPEs are joined in a PHD to form a more powerful MEGA-PIPE

RBF Raw Binary Format – A type of file that MAXPlusII can generate, that is used toconfigure the PEs

PC Personal Computer

PCI Peripheral Component Interconnect – A bus found on most PCs

SDI Serial Digital Interface – A digital video format supported by professionalbroadcast equipment


2. Overview Of the SONIC BoardThe SONIC board is designed to process (video) images using reconfigurable hardware. The imagesare processed by ‘tasks’. Each particular task is described by a PIPE Hardware Design (PHD). ThePHD contains the information needed to configure the hardware to perform that task.

LBC (Local BusController)

PIPE 0 PIPE 1 PIPE 2 PIPE 3 PIPE 4 PIPE 5 PIPE 6 PIPE 7

PCI Bus

PIPE Bus - 32bit Address/Data

Configuration Control, PIPE Select, and Interrupt Signals

PIPEFlow B

PIPE Flow buses are shaded - 16 bitswide+3 control signals

SDI In

PIPEFlow A

SDI Out

Figure 1 - Overview of the SONIC Board

Figure 1 gives an overview of the SONIC Board. The board consists of the following parts:

Plug In Processing Elements (PIPEs)There are 8 PIPEs on the SONIC board, which plug into the 200 pin DIMM sockets. The PIPEsprocess the images. They are described in detail in Section 3.

PCI BusThe PCI bus connects SONIC to the host PC. Any data going to or from the host PC will use the PCIbus.

Serial Digital Interface (SDI)The SONIC board also has a Serial Digital Interface (SDI) input and output that image data can betransferred to/from. The format of the SDI data is very similar to the PIPEFlow data stream thatSONIC uses described in section 10.

PIPE BusThe PIPE bus is a global 32bit Multiplexed Address + 4 Control Signals Data bus. It is designed for:


Fast Image Transfer - It will allow bursting to/from the PCI bus at the maximum burst rate(133Mbytes/sec) from/to the PIPE Memory.

PIPE Register Access - Any run-time information required by the PIPE can be transferred usingthe PIPE bus. PIPE Status information can also be read.

PR Switching - Controlling where the PR routes the PIPEFlow data.

PIPEFlow BusesThe PIPEFlow buses are 16 bits in width with 3 single bit control signals. They are designed forpipelined operation of the SONIC board. Data is sent on these buses using a simple ‘raster-scan’protocol. The PIPEFlow data can be routed from a number of sources, or automatically generatedfrom an image stored in the memory on a PIPE. PIPEFlow buses A & B can be used to transferimages from any PIPE (or LBC) to any number of other PIPEs (or LBC) (for example, PIPE 0 couldsend image data to PIPEs 1,2,3 & 5 using the PIPEFlow A bus)

PIPE Control SignalsEach PIPE has a number of unique control signals coming to/from it. These are:

PIPE Select Signals - Used to indicate which PIPE and device on the PIPE the PIPE Bus isaddressing.

Configuration - Used by the LBC to configure the PIPEs;

Local Bus Controller (LBC)This is responsible for interfacing the SONIC board to the external world. The LBC performs threetasks:

PHD Download The LBC will download the PHD to the appropriate PIPE to configure it..

Image Transfer All image transferral is handled by the LBC. The images can come over the PCI busor to/from the SDI. All this is invisible to the PHD designer.

PIPEFlow Bus Routing The LBC looks after all the PIPE routing. This is all done in a transparentmanner and as a PHD designer, you need not concern yourself with where the PIPEFlow data is beingrouted.

Key Points• The SONIC Board is a reconfigurable platform for processing (video) images.• Operations on images are called tasks. (Such as filtering, rotation etc.) .• Each task is described in a PIPE Hardware Design (PHD).• The SONIC Board interfaces to the PC via the PCI bus with a Local Bus Controller (LBC).• There are 8 Plug-In Processing Elements (PIPEs) which are reconfigured to process the images.


• The PIPE Bus is a global bus that connects the LBC to all the PIPEs.• The PIPEFlow Buses allow pipelined operation of the PIPEs.• The SDI can be used to transfer images to/from the PIPE.


3. Plug-In Processing Elements (PIPEs)

"It is quite a three-pipe problem, and I beg that you won't speak to me for fifty minutes."- (Sherlock Holmes, The Red-Headed League)

The PIPEs are the core element of the SONIC architecture, they perform the actual processing of theimages. The PIPE Engine (PE) of the PIPEs are configured by the rbf file created by the PHD. Figure2 shows an overview of the PIPE.

PIPE Router(PR)

Flex 10K20

PIPE Engine(PE)

Flex 10K70PIPE

Memory(PM)

4MBSRAM

PIPEFlowLeft

PIPEFlowRight

PIPEFlow A PIPEFlow B

PIPE Bus

PIPEFlowIn

PIPEFlowOut

PR SelectPM Select

Configuration

Configuration

PM SelectPE Select

Figure 2 - Overview of the PIPE

The PIPE Engine (PE)The PE is responsible for the processing of the image. On the current PIPEs, a FLEX10K70 is used toimplement the PE. It is for this device (and only this device) that the PHD designer must designhardware. The PE is described in detail in section 6.

The PIPE Router (PR)The PR is implemented on a FLEX10K20 device, the configuration of which is pre-designed toimplement all the required functions of the PR. The LBC controls the PR, and the PHD cannot use, oraffect the PR (well generally, anyway!). The PR routes the PIPEFlow In & Out Buses to the PE. ThePR can get the data for the PIPEFlow In bus from a number of places:


PM - The PR has the capability of automatically generating the PIPEFlow data froman image held in the PM. This can only be done if the PM is not used by the PEin the PHD.

PIPEFlow Left - PIPEFlow data comes from the previous PIPE.

PIPEFlow A - PIPEFlow data comes from the LBC or any other PIPE.

PIPEFlow B - PIPEFlow data comes from the LBC or any other PIPE

The PR can also rout the data on the PIPEFlow Out bus to a number of places:

PM - The PR has the capability of automatically storing the PIPEFlow data as animage held in the PM. This can only be done if the PM is not used by the PE inthe PHD.

PIPEFlow Right - The PIPEFlow out data is always routed to the next PIPE (it is actuallyhardwired this way), by the PIPEFlow Right bus.

PIPEFlow A - The PIPEFlow out data is routed to bus ‘A’ for access by the LBC or anyother PIPE. Only one PIPE at a time can drive the PIPEFlow A bus.

PIPEFlow B - The PIPEFlow out data is routed to bus ‘B’ for access by the LBC or any otherPIPE. Only one PIPE at a time can drive the PIPEFlow B bus.

The PIPEFlow buses are explained in detail in section 9.

The PR is also responsible for performing the burst transfers over the PIPE Bus, when an image istransferred to or from the PM. Since the PR handles the transfer of images in and out of the PM, nodesign effort is required by the PHD designer for such tasks.

The PMEach PIPE has 4Mbytes of SRAM organised as 32bits by 1M (giving 20 bit address). This can beused for image storage and manipulation. The PHD designer can use the PM in any way desired, or ifit not required, the system can use the PM for image storage. The PM is described in detail in section8.

Key Points• The PIPE consists of a PIPE data router (PR), 4Mbytes of SRAM (PM), and PIPE Processing

Engine (PE).• The PHD designer must design the hardware for the PE.• The PR is pre-designed, and cannot be control or altered by the PHD.• The PR handles the storing and retrieval of images from the PM, and the routing of the PIPEFlow

buses.


4. Using the SONIC board for Software Acceleration

The objective when SONIC is used for software acceleration is to process the images stored on thePC (considerably) faster than the PC alone can. The images are transferred to and from the PC usingthe PCI bus. Any control data required is also send by the PC over the PCI bus.

Software model for software accelerationFor software acceleration, SONIC uses the software architecture shown in Figure 3:

VHDVHD

Sonic Board

Device Driver

SONIC DLLVHDVHDPHDSTD

SONIC API

Application

SoftwareTask

Description

PIPEHardware

Design

Configuration Data

Image Data

Control Data

Key

Figure 3 - Software architecture for software acceleration

Each task should have a (PIPE Hardware Design) PHD, and a software equivalent implementation(which is used when SONIC is not present, or busy). The software equivalent implementation is alsogood for testing the completed PHD.

The application interfaces with the SONIC API. The SONIC API is responsible for whether the taskswill be implemented in hardware or whether the software equivalent will be used. This will depend onwhether the SONIC board is present or not, amongst other factors.

The application could be a Plug-In for a commercial application such as Paint Shop Pro, or could bewritten specially for the particular task.

Figure 4 shows a processing flow chart of SONIC used as a software accelerator:


PHD H/W Configuration

Image Transfer

Begin Message to API

Processing

Image Retrieval

End Message from API

HardwareReconfiguration

Application


Image Transfer to SONIC

Begin Message to SONIC

SONIC API

End Message from SONIC

Processing

Image Transfer from SONIC

SoftwareImplementation

Finished

Figure 4 – Flowchart for software acceleration

Configuration of the PIPEsThe PIPEs are configured by the SONIC API, using the configuration file for the PHD. The precisetime when the PIPE is configured is dependent upon the application and the SONIC API.

Configuring each PIPEs is relatively expensive in terms of time (≈0.2s), therefore when ever possiblethe PIPEs are configured in advance.

In some applications, the tasks are known a-priori to the image data being available (for example, onlyone task is performed, or the user has to specify the task in advance). In this case the configurationdata can be transferred to the appropriate PIPE well in advance of the data. If this is done, there is noextra delay associated with configuration when the task is performed.

In some situations, it is possible to maintain a ‘cache’ of PHDs on the SONIC board. For example,eight different PHDs could be held on the SONIC board. If the required task is already on the board,no time penalty is incurred, and the image data is simply sent to the correct PIPE. If there are noappropriately configured PIPEs on SONIC, the correct PHD configuration file must be downloadfirst.

Passing Control Data to the PIPEControl data, such as the message to begin processing, or parameters for the task are normallycommunicated to the PIPEs using registers (implemented in the PE by the PHD), which are accessedusing the PIPE Bus. These registers can also be used by the PIPE to return status information (such asthe PE has finished processing the image, for example). PE registers are described in section 12.

Different Modes of usageThere are two different ways that PHDs can be used to accelerate software: direct access mode andPIPEFlow mode. These are explained in detail below:


Direct access modeThis is conceptually the simplest mode in which the PIPEs can be used. The flow of operation isshown in Figure 5.

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image Transferred from the host PC to PIPE2’sPM by the PR, using burst mode on PCI BUS

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image processed by PIPE2. The PE directlyaccesses the PM. When finished the PE sets aregister that indicates that processing is finished.

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image Transferred from PIPE2’s PM to the hostPC by the PR using burst mode on PCI BUS.

Figure 5 - Direct Access Mode

Using direct access mode, each PIPE is capable of independent operation; in fact, it is impossible topipeline multiple PIPEs using a ‘dataflow’ model with direct access mode. A consequence of this isthat each PIPE must transfer the image through the LBC, which can generate a bottleneck. However,the SONIC architecture does allow the ‘broadcasting’ of images to multiple PMs at the same time.

The direct access mode is suitable if you never want to process data generated by another PIPE; onlyever from the PM.

Since configuration time for the PEs is a considerable factor (≈.2s per PE), one way the SONIC boardcan be used is to download a number of PHD to different PIPEs. When a particular task is required,the image can then be sent to the appropriate PIPE for execution without needing to wait for the PEto be configured.


Sometimes the ‘direct access’ mode of operation is the only way to accomplish a task (when randomaccessing of the PM is required, for example).

PIPEFlow MethodThe PIPEFlow method takes advantage of the PIPEFlow buses, and therefore allows the SONICboard to be used in a more efficient manner, especially where the PHD is combined with other PHDs.Another advantage is that PHDs using the PIPEFlow method will also work when SONIC is used inas a real-time image processor (described later).

The PIPEFlow method differs from the direct access method in the way that the PE obtains the imagedata. Using the direct access mode, the PE gets the image data directly from the PM; when using thePIPEFlow method, the data is provided by the PR through the PIPEFlow In bus. Processed dataleaves the PE via the PIPEFlow Out bus. More information about the PIPEFlow protocol can befound in section 10. The advantages using the PIPEFlow mode are:

• The PE design can often be greatly simplified.• The image data can come from many different sources: the PM of the PIPE, a previous PIPE or

the LBC – in all cases the PE design is identical.• The designs will also work with the real-time mode of operation.

An example of a single PIPE using the PIPEFlow mode of operation is shown in Figure 6.


LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image Transferred from the host PC to PIPE2’s PM by thePR, using burst mode on PCI BUS.

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image processed by PIPE2; the PR automaticallygenerates the PIPEFlow data routing it to the PE.Processed PIPEFlow data is stored in the PIPE’s PM.When finished, the PR flags an internal register.

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image Transferred from PIPE 2’s PM to the host PC bythe PR, using burst mode on PCI BUS.

Figure 6 - Using PIPEFlow Mode With Single Task

It can be seen that, provided the PE doesn’t privately use the PM, it is possible for the image to begenerated from, and returned to the same PM. This is easily accomplished, since the availablebandwidth to the PM is exactly twice that of the PIPEFlow buses.

In the example shown in Figure 6, there would appear to be no performance benefits derived fromusing the PIPEFlow method compared with the direct access mode, since the image still needs to betransferred to and from the LBC.

The benefits comes when multiple tasks are to be performed sequentially on an image, as can be seenin Figure 7:


LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image Transferred from the hostPC to PIPE2’s PM by the PR,using burst mode on PCI BUS

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image processed by the chain ofPIPEs. The PR of the last PIPEsroutes the data to the PM. WhenPIPE 7 finishes, PIPE 7’s PR flagsan internal register.

LBC

PE

PR

PM

PE

PR

PM

PE

PR

PM

PE

PRP

M

PE

PR

PM

PE

PR

PM

PE

PR

PM

PCI Bus

Image transferred from PIPE7 toHost PC by the PR using burstmode on PCI BUS.

Figure 7 - Using PIPEFlow Mode with 6 Tasks

Although only two transfers are required through the LBC, we can see that six tasks have beenperformed.

The reason for this saving is that the PHDs can be pipelined together, using the PIPEFlow buses. Thiscan be done because all the required tasks have been designed by the PHD Designer to take advantageof the PIPEFlow mode. When the PHD is designed, the designer need not know where in thePIPEFlow path the PHD will be (or indeed, whether it will be used as part of a chain at all).

PHDs can use the PM for their own private requirements, if desired. In the example shown in Figure7, the fourth PIPE in the chain is using the PM privately. Of course, if the PE uses the PM the PM cannot be used by the PR for sourcing/sinking PIPEFlow data. In this example, this is not important sincethe PIPE is in the middle of a PIPEFlow chain.

Had the same PHDs been designed for direct access mode, then 12 transfers would have beenrequired through the LBC, considerably slowing the entire design down.

Key Points• Before processing can begin, the PIPE(s) must be configured.• Configuring the PIPEs takes a relatively long time. (0.2 s)• When ever possible the PIPEs should be configured in advance.• PIPEs can obtain their data locally from the PM, or through the PIPEFlow Bus.• The most efficient way to use the SONIC board is to use the PIPEFlow Buses.


• PHDs that use the PIPEFlow method will also work in the real-time mode.• PHD can privately use the PMs if desired.


5. Using SONIC as a Real-time ProcessorWhen SONIC is used as a real-time processor, the image data comes from the SDI input (in thePIPEFlow format), are processed by SONIC, and then sent out through the SDI output. The objectivehere is to design PHDs that will work in real time. The PC can use the PCI bus to send parameters tothe PIPEs, optionally receiving status and image data back.

Software ModelFor real-time operation, SONIC uses the software model shown in Figure 8:

Sonic Board

Device Driver

SONIC DLLVHDVHDPHD

SONIC API

Application

PIPEHardware

Design

Configuration Data

Image Data

Control Data

Key

SDI OutSDI In

Figure 8 - Software model for real-time operation

When used for real-time operation, the image data is transferred using SDI In and SDI out. The PCIbus is used (a) to configure the appropriate PIPEs with the PHDs and (b) for transfer of anyparameters required. The PCI bus can also be used to read status information from SONIC. Ofcourse, the images (or a sub-sampled version) could be also transferred to the PC over the PCI bus.

Figure 9 shows the flowchart when SONIC is used for real-time operation. The application configuresthe PIPEs, then SONIC processes the image stream autonomously. The PC can transfer parameters(using the PIPE bus) to SONIC to alter how the images are processed (sending filter coefficients, forexample). The PC can also use the PIPE bus to get status information (or even images) from thePIPEs.



Idle/User Input HardwareReconfiguration

Application


SONIC API

Processing

Finished

Figure 9 – Flowchart for SONIC as a real-time processor

Figure 10 demonstrates how the PIPEFlow bus are used with to process the data, which is transferredusing the SDI ports.

LBC

PE

PR

PM

PE

PR

PM

PE

PRP

M

PE

PR

PM

PE

PR

PM

PE

PR

PM

SDIIn

SDIOut

PCI BUS

Image data is generated onthe PIPEFlow bus from theSDI In by the LBC. Thedata is then passed alongthe chain of PIPEs and theresulting PIPEFlow datarouted by the LBC to SDIOut.

Figure 10 - Processing using PIPEFlow data transfers

The PHDs are designed in the exactly the same way as the PHDs that use the PIPEFlow bus forsoftware acceleration (described in section 4). In this case any PIPE may use the PM, since the PM isnever used by the PR.

Key Points• Before processing can begin, the PIPE(s) must be configured.• Once configured, SONIC operates autonomously.• PIPEs obtain their data trough the PIPEFlow bus.• The PCI bus can be used to transfer parameters and read information from SONIC.• PHD can privately use the PMs if desired.• All routing of the PIPFlow buses is handled by the PR (no design effort by the PHD designer is

required).


6. The PIPE Engine (PE)The PIPEs are the core of the SONIC architecture; the PEs are the core of the PIPEs. Theconfiguration of the PE determines the function of the PHD. A block diagram of the PIPE Engine(PE) is shown in Figure 11.

FLEX 10K70

PIPE EngineAddress (19:0)

WRITEPIPE Bus

PFIN[15..0]

CSM

M_NS

M_NW

Data (31:0)

Write

Chip Select

PM

AS

STALL

AD[31..0]{

CS

CLK

GC

LK2

GCLK1

TERM

CR[21:0]CL[21..0]

ADDRESS[19..0]

DATA[31..0]

GC

LK2_O

UT

PFIN_EN

DL

PFIN_EN

DS

PFIN_IN

ST

PFOU

T[15..0]

PFOU

T_END

LPFO

UT_EN

DS

PFOU

T_INST

{ {

PIPEFlow In PIPEFlow Out

INT

PM Chip SelectPE Chip Select

Interrupt (To LBC)33Mhz Clock

Figure 11 - Overview of the PIPE Engine

The PIPE Engine (PE) is the main processing element of the SONIC board. The configuration file ofthe PHD configures the PE. In order to operate correctly the design must strictly adhere to a numberof rules regarding the interfaces.

PIPE BusThe protocol for the PIPE Bus is described in section 9. The PIPE bus is used for transferring imagesto and from the PM (using the PR), and for accessing any registers implemented in the PE. Theimplementation of register files in the PE is discussed in section 12.

PIPEFlow BusesThe PIPEFlow Buses are used to transfer the image data in a ‘raster scan line’ fashion. Section 10contains the protocol for the PIPEFlow Buses.


PM interfaceThe PM provides the main storage capability of the PIPE. It can either be used privately by the PE (inwhich case it can’t be used to generate or store PIPEFlow data, or by the PR to store images. Thespecification and timing information for the PM can be found in section 8 along with the details of apre-designed interface for the PM.

CL & CR PortsThe ‘CL’ & ‘CR’ ports should only be used when two or more PIPEs are combined together to forma ‘MEGA-PIPE’. MEGA-PIPEs are used when a large task is required that can’t be fitted in a singlePIPE, or sensibly partitioned into many PIPEs. Section 7 discusses MEGA-PIPEs.

PM Chip Select Signal (CSM)This signal is used to indicate that the PR is about to access the PM. All the PM connections to thePE should immediately be tri-stated by the PE when this signal is HIGH – this is the responsibility ofthe PHD designer. See section 8 for more information.

PE Chip Select Signal (CS)The CS signal is high when the PIPE bus is addressing the PE of this. See section 9 for moreinformation.

Interrupt Signal (INT)INT should be forced high to cause a PCI interrupt. This is not currently supported – signalling to thePC should be done using registers implemented in the PE.

Key Points• The Processing Engine (PE) performs the image processing.• The PHD contains the configuration information for the PE.• Careful attention should be paid to the PIPEBus and Memory interfaces to avoid bus contention.


7. Combining PIPEs to form MEGA-PIPEsWhen a task will not fit in a single PIPE, and can not be sensibly partitioned across multiple PIPEsusing the PIPEFlow buses, two or more PIPEs can be combined together to form a MEGA-PIPE –shown in Figure 12.

PM (4Mbytes)

FLEX 10K20

PIPE Router

FLEX 10K70

PIPE Engine

PM (4Mbytes)

Data (31:0)

Address (19:0)

Configuration ControlCSM

INT

Configuration ControlCSPRCSM

PIPE FlowLeft

PIPE Bus(31:0)

PIPE FlowIn

PIPE FlowOut

CLK

CS

CLK FLEX 10K20

PIPE Router

FLEX 10K70

PIPE Engine

Data (31:0)

Address (19:0)

Configuration ControlCSM

INT

Configuration ControlCSPRCSM

PIPE FlowRight

PIPE FlowB

PIPE FlowIn

PIPE FlowOut

CLK

CS

CLK

Connect (21:0)CR[21..0] CL[21..0]

PIPE FlowA

PIPE FlowA

PIPE FlowB

Figure 12 - Combining two PIPEs to form a MEGA-PIPE

Sometimes a task will not fit in a single PIPE. If this is the case then the task should be split intoseveral sub-tasks, which can be designed separately, if possible (for example, 2D Filtering cansometimes be implemented as 2 1-D Filters with a corner-turning operation in-between). When adesign cannot be sensibly partitioned then two, or more PIPEs can be combined together to form aMEGA-PIPE. In this case the designer is free to use the ‘CR & ‘CL’ buses for any purpose (this busis shown as Connect (21:0) in Figure 12). The PIPEFlow buses can still be utilised, and the designedis free to use any format for the PIPEFlow signals.

Key Points• PIPEs can be combined together to form MEGA-PIPEs.• When using MEGA-PIPES the CL, and CR buses are available.• MEGA-PIPEs should only be used if the task can’t be sensibly split into sub-tasks using the

PIPEFlow bus.


8. PM DetailsThis section gives the specification for the PIPE Memory (PM), and a pre-designed block designed toimplement an interface to the PM. The PM consists of 4MB of SRAM can be used as private memoryby the PHD, if it is not used the PR can use the PM for image storage.

PM connections

PE (10K70) PMADDRESS[19..0]

DATA[31..0]

M_NW

M_NS

Address

Data

Write

Select

Figure 13 - Connection of the PE to the PM

The PM is arranged as 32Bits x 1 048 576, giving a 20 bit address, ADDRESS[19..0].

Function TablesThe following two tables give the operation of the SRAM, as defined by the data sheet:

M_NS M_NW Mode DATA[31..0] IccH X Non Selection High-Impedance Stand By

L L Write Din Active

L H Read Dout Active

CSM M_NW M_NS DATA[31..0] ADDRESS[19..0]L X X X X

H Z Z Z Z

X - Don’t careZ - High impedance

Timing DiagramsFigure 14, Figure 15 and Figure 16 show the timing diagrams for the SRAM that is used on thePIPES (taken from the data sheet for the SRAM). If you want to directly access the PM, then youmust ensure that you meet these timing requirements for correct operation. The pre-designed memory


interface generates these signals for you, and it therefore suggested that you use this whereverpossible.

Previous Data Valid Unknown Data ValidDATA[31..0]

ADDRESS[19..0]

>12ns

>3ns<12ns

>3ns

Figure 14 - Read Cycle: M_NW=H, M_NS=L

DATA[31..0] Data ValidUnknown

M_NS

<0ns<12ns

>12ns

<6ns

Figure 15 - Read Cycle: M_NW=H

ADDRESS[19..0]

>12ns

M_NS

M_NW

DATA[31..0] Data Stable

>10ns

>10ns

>6ns >0ns>0ns

>0ns

>6ns

>1ns

Figure 16 - Write Cycle (M_NS Control Mode) - Grey = Don't Care

PM and the PRThe PM is also connected to the PR. This is for image transfers over the PIPE Bus. When ever theCSM (PM Select) signal is HIGH M_NS, M_NW, DATA[31..0], & ADDRESS[19..0] must betristated. (This is because the PR is trying to access the memory) – this is the responsibility of thePHD designer.

Interface Design – MEMORY_INTERFACE_10K70This is a standard block designed to interface with the PM on the PIPE. It provides a synchronousinterface to the SRAM for the PHD designer. The block diagram for the memory interface is shown inFigure 17. The blocks had two types of connections: those preceded by a m_ are external connectionsto the PM (or tristates in the main design file). The remainder are synchronous user inputs andoutputs.


SRAM Interface

writeadd[]

sel_memdata_in[]

data_out[]data_valid

start

m_data_in[] m_data_out[]

m_tri_datam_tri_rest

m_nsm_nw

m_add[]

external connectionsuser connections

Figure 17 - Memory Interface Block Diagram

The external connections (m_ signals) of this block must be connected in the top most design block asfollows:

m_ns = TRI(LCELL(mem.m_ns), LCELL(mem.m_tri_rest));m_nw = TRI(LCELL(LCELL(mem.m_nw)), mem.m_tri_rest);FOR i IN 0 TO 31 GENERATE

data[i] = TRI(LCELL(LCELL(mem.m_data_out[i])), LCELL(mem.m_tri_data));END GENERATE;FOR i IN 0 TO 19 GENERATE

address[i] = TRI(LCELL(mem.m_add[i]), mem.m_tri_rest);END GENERATE;

The LCELLs are required in order to give the correct asynchronous behaviour.

When connected as described above, Figure 18 shows the timing diagram for the memory interfaceblock. There is a 3 cycle delay for reads (Data 1 is ready 3 clock cycles after Address 1 is presented),and a 2 cycle delay for data writes. Reads and Writes can be interleaved in any fashion with one reador write occuring per clock .

Because of the asynchronous signals, this design only works correctly when clocked at 33Mhz.

clk

sel_mem

start

write

ad[19..0]

data_in[31..0]

M_NS

ADDRESS[19..0]

M_NW

DATA[31..0]

data_out[31..0]

Address 1 Address 2 Address 3 Address 4 Address 5

Data 3 Data 5

Address 6

Data 6

PR RequestingMemory

(sel_mem HIGH)Don't Start Read Cycle Read Cycle Write Cycle Read Cycle Write Cycle Write Cycle

data_valid

Data 1 Data 2 Data 4

Address 1 Address 2 Address 3 Address 4 Address 5

Data 1 Data 2 Data 3 Data 4 Data 5

Read Cycle Write CycleRead Cycle Read Cycle Write CycleTri-Stated Tri-Stated Tri-Stated Tri-Stated

Figure 18 - Timing diagram for the MEMORY_INTERFACE_10K70.TDF File


In order to use the block it isn’t necessary to fully understand its operation, just treat it as a black box.This block (MEMORY_INTERFACE.10K70.TDF) can be downloaded from the SONIC web site.

Key Points• Use M_NS to control the write cycles.• If the PM is not being used M_NS, M_NW, DATA[31..0], & ADDRESS[19..0] should all be

tristated.• When ever CSM goes high, M_NS, M_NW, DATA[31..0], & ADDRESS[19..0] must be

tristated. (This is because the PR is trying to access the memory).• A pre-designed block (MEMORY_INTERFACE.10K70.TDF) is available that can be used by the

PHD designer to give the SRAM a synchronous interface.


9. PIPE Bus ProtocolThe PIPE Bus forms the backbone of the SONIC architecture; responsible for fast image and PIPEregister accesses. The PIPE Bus can be totally ignored by a particular PHD (Tristating the appropriatepins), if it not required.

The PIPE Bus is a synchronous 32bit multiplexed address/data bus, with burst mode support.

The PIPE Bus has two modes of operation:

Single Transaction Mode - The simplest mode, designed for register access. Only one address isaccessed at a time, so there is no need for address calculation.

Burst Mode - Burst mode is primarily designed to enable the PIPE bus to operate atthe maximum PCI Burst rate of 133Mbytes/ sec. Address Calculationis required, as only the initial address is given.

When using image the image transfer functions in the SONIC API, burst mode is used. The registeraccess functions automatically use single transaction mode.

The PIPE Bus consists of the signals shown in Table 1:

Element Direction(w.r.t PIPE)

Purpose

CLK Input 33Mhz Clock

PIPE_PE_SEL Input High to select this PIPE’s PE

PIPE_BUS_AS Input High when PIPE_BUS_AD[31..0] represents the startaddress

PIPE_BUS_WRITE Input High when data is being written to the PIPE.

PIPE_BUS_TERM Input High when the current data should be the last.

PIPE_BUS_AD[31..0] Bi-directional 32 bit Address/Data

PIPE_BUS_STALL Output,Tristatable

Driven high to stall the current transaction. Low innormal operation when the PIPE is selected(PIPE_PE_SEL is high). Should be left tri-stated whenthe current PIPEs PE is not selected

Table 1 - PIPE Bus Signals

All inputs and outputs should be registered. The first thing that should be done is to clock all thesesignals into a register. When driving the PIPE bus, all the signals should come straight from a register


through the tri-state and not through any other logic. This measure is designed to ensure the signalsare stable as long as possible on the PIPE Bus.

Single Transaction ModeSingle transaction allows for one 32 bit Dword of data to be transferred per address cycle. There is anaddress cycle immediately followed by a data cycle. This is the suggested mode for register access,since these generally occur relatively infrequently, and tend not to be consecutively addressed. TheSONIC API register functions automatically use single transaction mode.

It is possible to stall the data cycle indefinitely by driving the STALL signal high. It is not possible tostall the address cycle.

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address DataAddress

Cycle Data Valid BusReleased

Figure 19 - Single Transaction Mode - Read from PIPE

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

AddressAddress

CycleBus

ReleasedStall

Requested Data Valid

Data

Figure 20 - Single Transaction Mode - Read from PIPE with a stall cycle

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address DataAddress

Cycle Data Cycle BusReleased

Figure 21 - Single Transaction Mode - Write to PIPE


CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address DataAddress

CycleBus

ReleasedStall

Requested Data Held

Figure 22 - Single Transaction Mode - Write to PIPE with stall

Burst Mode TransferBurst Mode Transfer is an extension to the Single Transaction Mode that allows for high speed bursttransfers at 133Mbytes/sec using the PIPE Bus. This is used by the SONIC API image transferralfunctions.

There is a single address cycle, followed by a, possibly, infinite number of data cycles. TERM isdriven high when the final data cycles is in progress.

The bus may be stalled in any data cycle by driving the STALL signal high. It is not possible to stallthe address cycle.

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address Data 1 Data X-1Data 2 Data XAddress

Cycle Last CycleFirst DataCycle

BusReleased

Figure 23 - Burst Mode - Read from PIPE

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address Data 1 Data 2 Data XAddress

Cycle Data Valid StallRequested Data Valid Last Cycle Bus

Released

Figure 24 - Burst Mode - Read from PIPE with a stall cycle


CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address Data 1 Data X-1Data 2 Data XAddress

Cycle Last CycleFirst DataCycle

BusReleased

Figure 25 - Burst Mode - Write to PIPE

CLK

CS

AS

WRITE

STALL

AD[31..0]

TERM

Address Data 1 Data 2 Data X...........Address

CycleFirst Data

CycleStall

Requested Data Held Last Cycle BusReleased

Figure 26 - Burst Mode - Write to PIPE with stall

An example register file that uses the PIPE Bus is given in section 12.

Key Points• There are two possible transfer modes, burst mode and single transaction mode.• Single transaction is the simplest (and slowest) and is best suited to registers.• Burst mode matches the maximum PCI burst rate (133Mbytes/s) and is used for image transfer by

the PR.• All PIPE Bus outputs should be registered, to maximise stable signal time.• Whenever CS is low, all PIPE Bus Outputs should be tristated, as other PIPEs may be using the

PIPE bus.


10. PIPEFlow Bus ProtocolThe PIPEFlow bus is a synchronous, time multiplexed 16bit data + 3 control bits bus. Its purpose is totransfer image data in a ‘raster scan’ fashion. This data could represent RGB or YCrCb imageinformation, although only RGB is currently supported. The stream consists of a header, containingdata format information, followed by the image data. Two signals, ends & endl give information aboutthe current location in the image. The SDI data also uses this format.

Header R,GData

B, αData

........ R,GData

B, αData

Stream Header

16 bit Data

Figure 27 - PIPEFlow Data stream

PIPEFlow Bus data formatThe PIPEFlow Bus Data is raster scan as shown in Figure 28, Figure 29 & Figure 30. There are twomajor modes of operation – horizontal raster scan (Figure 28), and vertical raster scan (Figure 29).The PR can be programmed to generate PIPEFlow data from an image in the PM using any of thesemodes.

........

Image Width

Image H

eight

ENDL= HIGH,ENDS = LOW

R,G,B & alpha at each pixel

ENDL= HIGH,ENDS = HIGH

Figure 28 - Horizontal Raster Scan Data (STRIP=0)


........

Image Width

Image H

eight



Figure 29 - Vertical Raster Scan Data (STRIP=0)

Figure 30 shows a more sophisticated mode of access called ‘stripped’ access. This mode works in asimilar way to the previously described modes, but at each ‘normal’ location a strip of pixels is read –as opposed to one. For horizontal raster mode, this will be a vertical strip of pixels; for vertical rasterscan mode a horizontal strip of pixels. This mode is suitable for simple implementation of 2-D FIRfilters and some other block algorithms. It can also be used to increase the number of clocks per pixel:if only the first pixel of the strip is considered, a strip of 0 gives 1 pixel every 2 clocks cycles; a stripof 1, 1 pixel every 4 clock cycles.

........

Image Width

Image H

eight


R,G,B & alpha at each pixel


STR

IP

ENDL= LOW,ENDS = HIGH

Figure 30 - Horizontal Raster Scan Data (STRIP=2)


Signals used by the PIPEFlow BusFigure 31 shows the PIPEFlow Bus connections between the PR and PE:

PR PE

PFIN_ENDLPFIN_ENDSPFIN_INST

PFIN[15..0]

PFOUT_ENDLPFOUT_ENDSPFOUT_INST

PFOUT[15..0]

Figure 31 - PIPEF Signals between the PE and PR

Name Purpose Direction (w.r.t. PE)CLK 33Mhz Clock In

PFIN_INST High during the image header phase In

PFIN_ENDS High at the end of each ‘strip’ In

PFIN_ENDL High at the end of each line In

PFIN_DATA[15..0] 16 bit Data or Info. In

Name Purpose Direction (w.r.t. PE)CLK 33Mhz Clock In

PFOUT_INST High during the image header phase Out

PFOUT_ENDS High at the end of each strip (when data iswritten)

Out

PFOUT_ENDL High at the end of each line (advance line) Out

PFOUT_DATA[15..0] 16 bit Data or Info. Out


PIPEFlow bus timing diagramsCLK

PIPEF_INST

PIPEF_ENDS

PIPEF_ENDL

PIPEF_DATA[15..0] Format Width Height R,G B,α R,G B,α R,G B,α R,G B,α R,G B,α R,G B,α

End Pixel ofLine 0 Last Pixel

Figure 32 - Timing Diagram for PIPEFlow Bus (WIDTH=3, HEIGHT=2,STRIP=0)

CLK

PIPEF_INST

PIPEF_ENDS

PIPEF_ENDL

Format Width Height R,G B,α R,G B,α R,G B,α R,G B,α R,G B,α R,G B,α

End of firststrip

R,G B,α R,G B,α

Last PixelEnd of FirstLine

Figure 33 - Timing Diagram for PIPEFlow Bus (WIDTH=2, HEIGHT=2, STRIP=1)

Example using the PIPEFlow Bus – An image colour inverterTo demonstrate just how easy it can be to use the PIPEFlow bus, here is an example that takes animage and inverts the colours. This is done by using the following equations for each pixel:

αα =′−=′−=′−=′

BBGGRR

255255255

A register (red_green) is used to indicate which cycle the data is in (red/green or blue/alpha). When inthe blue/alpha phase only the blue colour value is inverted; the alpha is left unchanged. If there is aninstruction (inst=HIGH) then the data is passed straight through without inversion.

%PE_INVERT - .tdf file implementing an example colour inverter Written : 12/07/98 Version : 0 Tested : Author : Simon Haynes Notes – inverts the colours of an image:

R’=(255-R)G’=(255-G)B’=(255-B)

Alpha is left unchanged, as is the inform ation header.%

SUBDESIGN pe_invert(

--PIPEFlow INpfin_inst : INPUT;pfin_endl : INPUT;pfin_ends : INPUT;pfin[15..0] : INPUT;

--PIPEFlow OUTpfout_inst : OUTPUT;


pfout_endl : OUTPUT;pfout_ends : OUTPUT;pfout[15..0] : OUTPUT;

%Clk %clk : INPUT;

)

VARIABLE

h_pfin_inst : dff; --Registered pfin_inst signalh_pfin_endl : dff; --Registered pfin_endl signalh_pfin_ends : dff; --Registered pfin_ends signalh_pfin[15..0] : dff; --Registered pfin data

p_pfout_inst : dff; --pre-registered pfout_inst signalp_pfout_endl : dff; --pre-registered pfout_endl signalp_pfout_ends : dff; --pre-registered pfout_ends signalp_pfout[15..0] : dff; --pre-registered pfout data

red_green : dff; --High when we are in the red/green cycle

BEGIN--Register the incoming PIPEFlow bus

h_pfin_inst.clk=clk; h_pfin_inst=dfin_inst;h_pfin_endl.clk=clk; h_pfin_end=dfin_endl;h_pfin_ends.clk=clk; h_pfin_ends=dfin_ends;h_pfin[].clk=clk; h_pfin[]=dfin[];

--Set the red/green cyclered_green.clk=clk; red_green=pfin_inst # !red_green;

--Output register clocksp_pfout_inst.clk=clk;p_pfout_ends.clk=clk;p_pfout.endl.clk=clk;p_pfout[].clk=clk;

--Output register valuesp_pfout_inst=h_pfin_inst;p_pfout_endl=h_pfout_endl;p_pfout_ends=h_pfout_ends;

--Only invert green not alpha, and pass data straight through if it is an instruction--(inst=HIGH)

p_pfout[7..0]=(255-h_pfin[7..0]) & !(!red_green # h_pfin_inst) # h_pfin[7..0] & (!red_green # h_ pfin_inst);p_pfout[15..8] = (255-h_pfin[15..8]) & !h_pfin_inst # h_pfin[15..8] & h_pfin_inst;

--Set the block outputs;pfout_inst=p_pfout_inst;pfout_ends=p_pfout_ends;pfout_endl=p_pfout_endl;pfout[]=p_pfout[];

END;

Code 1 – PE_INVERT.TDF File

Key Points• PIPEFlow Bus consists of image data in a ‘raster-scan’ format.• The data represents RGBα image information.• Horizontal and vertical raster scans are supported.


• ‘Stripped’ accessing of the data is also possible.• The PR can be programmed to generate PIPEFlow data, from an image stored in the PM, using

any of these modes.


11. PM Image FormatThe image is held in the PM in a particular format described below:

Width

Heightx

y

Figure 34 - Pixel location in image

The information for pixel at location (x,y) in the image is given by:

8 bit RGBα

Total Image SizeThe image must fit within the total SRAM memory space (1048576 locations).

It is permissible to store more than one image in the memory, if there is space. In this case, the nextimage will start immediately adjacent to the preceding image. For example, the first image could bethe source image, and the second image the destination.

Key Points• The images are stored in the PMs in this particular format.• The PHD designed only needs to know about this format, if they access the PM directly.• Images are stored as 8 bit RGBα.• Multiple images can be stored in the SRAM, space permitting.

Bits Stored Data(Width*y+x)[7..0] R[8..0](Width*y+x)[[15..0] G[8..0](Width*y+x)[[23..16] B[8..0](Width*y+x)[[31..24] α[8..0]


12. PE RegistersThe PE can implement any number of registers that the PHD might require. The registers are accessedusing the PIPE Bus. They can be read and/or written. They can occupy any address from 0000 - FFFFHex.

Registers typically hold control data, such as parameters for the task like coefficients for filters, imagesize etc. They can also be used to return useful information to the host PC, such as number of linesprocessed, and whether the image has been completely processed.

An example register file for the PEThe design of the PE_REG.TDF block is shown in Figure 35. This register file uses the singletransaction mode of the PIPE bus, which simplifies the design. The basic idea is simple: The addressregister is enabled during an address cycle (AS=HIGH, CS=HIGH) storing the address. The addressis then compared to the address of the test_a and test_b register, and if it is equal, the chip is selected(CS=HIGH) and we are writing to the register (WRITE=HIGH) we enable the test_a or test_bregister. The value on the PIPE bus is then written into the register on the next cycle. The PIPE busout data is only actually put on the PIPE bus during a read cycle. (Tristating must be handled by theoverall top level design)

Write Enable

Write Enable

Address=0& Chip Select& Write?

Address Cycle& Chip Select? Address

Test ARegister

AddressRegister

PIPE Bus Data In

Test BRegister

Address=1& Chip Select& Write? Write Enable

PIPE Bus Data Out

Address=0?

Address=1?

Test A

Test B

Figure 35 - PE_ REG Block Diagram

Extending this register file could be done by enabling different registers with different addresses.

%PE_REG - .tdf file implementing an example register file with 1 8 bit register, and one32 bit register. Written : 10/05/98 Version : 0 Tested :


Author : Simon Haynes Notes – This design implements a register file containing two registers – test_a (8bit)

and test_b (32 bit)%

--Define the addresses of all the registers we useCONSTANT REGISTER_TEST_A = 0;CONSTANT REGISTER_TEST_B = 1;

SUBDESIGN pe_reg(

%PIPE Bus Inputs%ad_in[31..0]: INPUT;cs : INPUT; --High when the PE is selectedwrite : INPUT; --High when the PE is being written toas : INPUT; --High in the address cycle (ad_in[]= the address)

%PIPE Bus Outputs%ad_out[31..0] : OUTPUT;

%Test Value Outputs%test_a[7..0] : OUTPUT;test_b[31..0] : OUTPUT;

%Clk %clk : INPUT;

)

VARIABLE

reg_test_a[7..0] : dffe; --Register for the 8 bit ‘test a’ valuereg_test_b[31..0] : dffe;--Register for the 32 bit ‘test b’ valueaddress[15..0] : dffe; --Register to hold the current address

BEGIN--Register the address when an address cycle is in progress

address[].clk=clk; --Clock input to the registeraddress[].ena=as & cs; --Enable the register during an address cycle (as=HIGH)address[]=ad_in[15..0];

--Clocks for the test registersreg_test_a[].clk=clk;reg_test_b[].clk=clk;

--Enable - we must enable the register that the value should be written to--We only enable the register if we are writing to this chip, and the address is--correct reg_test_a[].ena = (address[]==REGISTER_TEST_A) & write & cs;

reg_test_b[].ena = (address[]==REGISTER_TEST_B) & write & cs;

--Write Data Routingreg_test_a[] = ad_in[7..0];reg_test_b[] = ad_in[31..0];

--Select Read Dataad_out[7..0] = reg_test_a[] & (address[]==REGISTER_TEST_A) # reg_test_b[7..0] & (a ddress[]==REGISTER_TEST_B);ad_out[31..8] = reg_test_b[31..8];

--‘Test’ Outputs from the register file to the top level designtest_a[]=reg_test_a[];test_b[]=reg_test_b[]

END;

Code 2 - PE_REG.TDF File

The code which handles the tri-stating of the PIPE Bus is placed in the top level design. During a readcycle (h_write=LOW and h_cs=HIGH) the output data is put on the bus. (h_write, and h_cs are thewrite, and cs signals delayed by a single cycle, to avoid bus contention)


--This is the PIPE bus, it is tristated unless we read from this chipFOR i IN 0 TO 31 GENERATE

ad[i]=TRI(p_ad_out[i],!h_write & h_cs);END GENERATE;

Code 3 – Top level design code for PE_REG.TDF File

Key Points• The PE can implement registers.• The PIPE Bus is used for all register accesses.• The Address range for the registers is 0000 - FFFF hex (16bits) given by AD[15..0]• Registers are typically used for storage of control data (such as the coefficients of an FIR filter)• The PHD designer is free to implement as many, or few registers as required by the design.


13. How to use the PIPE Hardware Design (PHD) with SONICThe PHD design consists of a number of AHDL files that will (hopefully!) implement the requiredtask. The next task is to generate a file that the SONIC API can use to configure the PIPE(s). TheSONIC API requires a RBF (Raw Binary Format) file for each PE. This is generated using MaxPlusIIas follows:

Generating the include (.inc) filesIf your design contains ‘sub-designs’, you will need to generate .inc files for each sub-design, beforeany of the blocks can be used in the top level design. This is done by selecting the appropriate .tdf fileby clicking in it, and using the menu command:

File→ Project→ Set Project to Current File

The .inc file can then be generated using the memory command:

File→ Generate Default Include File

Once done, we are ready to compile the complete project.

Locking The Pins for the DesignIn order that all the pins in the design (the PIPE bus etc.) are placed on the correct physical pins onthe device, it is necessary to tell the MaxPlusII compiler which pins to use. This is done using the .acffile. The .acf file contains all the compile options for the particular design. Only the .acf file for thetop-level design is important, since this is what will be compiled.

The extract from a .acf file is shown below:

CHIP pe_exampleBEGIN

DEVICE = EPF10K70RC240-3;|clk : INPUT_PIN = 91;|int : OUTPUT_PIN = 153;|clkb : INPUT_PIN = 211;|clkb_out : OUTPUT_PIN = 38;|pll_fbin : BIDIR_PIN = 43;|pll_clk1 : BIDIR_PIN = 30;|m_ns : BIDIR_PIN = 194;...

The DEVICE statement instructs the compiler which device to target. The other statements lock thesignals to the correct pins.

The easiest way to ensure that all the pins are locked to the correct physical device pins, is to simplycopy an existing .acf file (this can be downloaded from the SONIC web site). This can be done at thestart of the project. All that needs to be done then is to ensure that the same pin names are used inyour top-level design.


Choosing the Correct DeviceThe next step is to target the correct device. The PE is a 10K70RC240-3. This can be done using thedevice selection dialog box shown in Figure 36. This is brought up by using the following menucommand:

Assign→ Device

Figure 36 - Device Selection Dialog Box

If you have copied the .acf file from an existing project, this is probably already set up correctly.


Compiler OptionsThe MaxPlusII compiler contains a bewildering number of options, which affect how your design iscompiled. The details of all of these options is beyond the scope of this tutorial, but can be found inthe MaxPlus documentation. The Global Project Logic Sytesis dialog is shown in Figure 37. Thisdialog box can be brought up using the following menu command:

Assign→ Global Project Logic Options

Figure 37 - Logic Options Dialog Box

About the most important option is the style setting. Most probably, you will want to use the ‘FAST’setting. This uses the 10K carry chain logic (amongst other things) which gives improved designspeed and generally smaller designs. If your design doesn’t quite fit – or is just too slow, it can beworth fiddling around with all the different options to see if the changes improve the situation (takingoff automatic fast I/O or using automatic register packing, for example)

CompilationThe next stage is to generate the .sof (SRAM Object File) for the project. Use the following menucommand to enter the compiler:

MAX+Plus II→ Compiler

Then select full compilation (as opposed to functional simulation) by using:

Processing→ Timing SNF Extractor


Simulation can be done using the functional compilation, which is considerably faster than waiting forthe design to be fully placed and routed:

Processing→ Functional SNF Extractor

Hit the Start button, and wait for the compiler to finish (hopefully) with out any errors.

Conversion From .sof File to .rbf FileThe SONIC platform requires the configuration data in .rbf format (the files are more compact thisway). This conversion is simply done using the SRAM Object File Converter.

Select the programmer using the following menu command:

MAX+Plus II→ Programmer

Then bring up the dialog by using the following menu option:

File→ Convert SRAM Object Files…

This should bring up the dialog box shown in Figure 38.

Figure 38 - Dialog Box used to generate the .rbf file

Select the correct .sof file (top level name + .sof). Then click the ‘Add’ button. Ensure that thecorrect device is displayed (EPF10K70RC240-3). Select “.rbf (Sequential)” File Format and thenenter the file name. Click on OK to generate the file.


Key Points• The PIPE Hardware Design (PHD) consists of the AHDL file(s) required for the PE.• The AHDL files(s) must be compiled to a .rbf file for each PE.• The signals for the PEs must be locked to the correct pins, using the .acf file.• You must use the FLEX10K70RC240-3 device.


14. Example PHD - FilterTo help clarify the PHD design process, the following section looks at designing a filter.

Method of OperationThis filter is designed to take raster-scan data in 8 bit R,G,B format (ignoring the α channel). Thefilter coefficients are held in the register file. It generates an interrupt every time it completes a frame.Sufficient lines of pixels are stored in the SRAM to enable access to the previous lines of image data.Processed data is passed out in 8 bit R,G,B format.

Hardware DesignFigure 39 shows the outline block diagram for the hardware to implement the filter. This would becomplied for the Altera FLEX 10K70 and included in the PHD.

RegisterFilePIPE_BUS

Interrupt

PIPEFlowController

PIPEF_IN

PIPEF_OUT

FilterCoefficients

Filter

SRAMInterface(Line Store) SRAM

ControllerState Machine

InstructionDecoder

Figure 39 - Block diagram for hardware design of filter

The hardware design consists of the follow elements:

Register FileAccessed through the global PIPE Bus, this holds the coefficients for the filter, and the interruptstatus.

PIPEFlow ControllerThis handles the PIPEFlow bus interface. It checks that the data is valid and stalls the controller statemachine, if necessary.

Instruction DecoderThis looks at the PIPEFlow data stream, and resets the filter state-machine on the new frameinstruction, and signals to the controller state machine when a new line is encountered.

SRAM interfaceThis implements a line-store for the filter, so that previous lines of pixels can be held, and recalled.

FilterThis performs the multiplications and additions to give the correct result, which is passed on to thePIPEFlow controller.


15. Futher ReadingThe following is suggested reading for particular aspects of the PHD design process. The files may bedownloaded from the SONIC web site (http://infoeng.ee.ic.ac.uk/Sonic/).

PIPEFlow informationhttp://infoeng.ee.ic.ac.uk/Sonic/Private/PIPEFlow_Buses.pdf

PHD design examplesThis design performs a 19 tap, symmetrical 1-D convolution on an image using the PIPEFlow data.This can be used as the basis for a 2-D separable filter by passing the image through the filter row-wise, and then column-wise. This can be used for effects such as Blurring or Anti-aliasing.

Documentation: http://infoeng.ee.ic.ac.uk/Sonic/Private/1D_FIR.pdfDesign files: http://infoeng.ee.ic.ac.uk/Sonic/Private/1D_FIR.zip

This design performs a 3x3 convolution of the image held in SRAM, using the PIPEFlow data streamgenerated by the PR. Possible applications of this include: Blurring, Edge detection (high passfiltering), Embossing effects, & Gaussian filtering.

Documentation: http://infoeng.ee.ic.ac.uk/Sonic/Private/2D_FIR.pdfDesign files: http://infoeng.ee.ic.ac.uk/Sonic/Private/2D_FIR.zip

The function of this design is to convert PIPEFlow image data. The block can be used for thefollowing purposes: Conversion to/from 8bit YCrCb to RGB format, Gamma correction of the data,Conversion to Black & White, Arbitrary channel mapping - The four R,G,B,a channels can beindependently mapped to any desired function.

Documentation: http://infoeng.ee.ic.ac.uk/Sonic/Private/Convert.pdfDesign files: http://infoeng.ee.ic.ac.uk/Sonic/Private/Convert.zip

The function of this design is to perform a 2-D transform on an image held in the SRAM of a PIPE. Itis possible to specify both the destination and source regions for the transform, this means that it ispossible to reduce the processing time required for transforms where only small potions of thedestination image are being affected. It is also possible to specify a series of transforms (up to 32) at atime to be carried out . This enables effects such as image smashing, or tiling to be achieved. TheBlock can also be used to combine together PIPEFlow data with the resultant image using the alphachannel. The source image is held in the lower part of the SRAM, and the resultant image is thengenerated in the upper part of the SRAM (8000h) Possible effects include: Rotation, Shearing,Scaling, & Tiling.

Documentation: http://infoeng.ee.ic.ac.uk/Sonic/Private/Transform.pdfDesign files: http://infoeng.ee.ic.ac.uk/Sonic/Private/Transform.zip


PHD design tutorialThe purpose of this document is to guide someone through the process of designing a new hardware‘plug-in’ for the SONIC board. This document goes through, in some detail, the design of a plug-inwhich merges two images together.

Documentation: http://infoeng.ee.ic.ac.uk/Sonic/Private/Merge.pdfDesign files: http://infoeng.ee.ic.ac.uk/Sonic/Private/Merge.zip

PR informationhttp://infoeng.ee.ic.ac.uk/Sonic/Private/PR_Registers.pdf


16. PE Pin AllocationsThe following PE pins are used by the PIPE. In order to work correctly all the signals must be lockedto the appropriate pins on the 10K70 device, as shown in Table 2.

Signal Pin Purpose Signal Pin PurposeAD0 127 PIPE Bus Data/Address ADDRESS1 35AD1 14 ADDRESS2 41AD2 129 ADDRESS3 144AD3 13 ADDRESS4 39AD4 15 ADDRESS5 139AD5 168 ADDRESS6 151AD6 167 ADDRESS7 88AD7 134 ADDRESS8 207AD8 166 ADDRESS9 23AD9 169 ADDRESS10 218AD10 159 ADDRESS11 146AD11 158 ADDRESS12 80AD12 157 ADDRESS13 147AD13 156 ADDRESS14 142AD14 28 ADDRESS15 143AD15 26 ADDRESS16 149AD16 25 ADDRESS17 141AD17 29 ADDRESS18 138AD18 190 ADDRESS19 18AD19 108 DATA0 173 SRAM dataAD20 187 DATA1 174AD21 111 DATA2 172AD22 110 DATA3 208AD23 182 DATA4 181AD24 117 DATA5 97AD25 184 DATA6 201AD26 164 DATA7 171AD27 185 DATA8 175AD28 186 DATA9 8AD29 199 DATA10 116AD30 161 DATA11 9AD31 188 DATA12 148STALL 105 PIPE Control DATA13 119TERM 212 DATA14 99WRITE 106 DATA15 6AS 210 DATA16 183CS 92 PE Select DATA17 209CSM 90 Memory Select DATA18 101PFIN0 217 PIPEFlow Bus (IN) DATA19 204PFIN1 219 DATA20 196PFIN2 83 DATA21 103PFIN3 203 DATA22 100PFIN4 206 DATA23 94PFIN5 71 DATA24 95PFIN6 131 DATA25 107PFIN7 50 DATA26 7PFIN8 21 DATA27 193PFIN9 163 DATA28 195PFIN10 126 DATA29 98PFIN11 51 DATA30 113PFIN12 56 DATA31 11PFIN13 132 CR0 31 Connect Right BusPFIN14 133 CR1 238PFIN15 49 CR2 17PFIN_ENDL 46 CR3 63PFIN_INST 48 CR4 67PFIN_ENDS 20 CR5 33PFOUT0 53 PIPEFlow Bus (OUT) CR6 78PFOUT1 54 CR7 45PFOUT2 55 CR8 36


PFOUT3 136 CR9 44PFOUT4 137 CR10 237PFOUT5 84 CR11 68PFOUT6 72 CR12 235PFOUT7 213 CR13 40PFOUT8 19 CR14 12PFOUT9 162 CR15 70PFOUT10 82 CR16 223PFOUT11 81 CR17 79PFOUT12 128 CR18 222PFOUT13 200 CR19 34PFOUT14 202 CR20 221PFOUT15 86 CR21 234PFOUT_ENDL 214 CL0 115 Connect Left BusPFOUT_INST 215 CL1 191PFOUT_ENDS 24 CL2 73CLK (GCLK1) 91 PLL Connections CL3 74GCLK2 211 CL4 228GCLK2_OUT 38 CL5 233PLL_OUT 30 CL6 231PLL_FB 43 CL7 227PIPE_INT 153 Interrupt Pin CL8 109M_NW 152 SRAM Write CL9 230M_NS 194 SRAM Select CL10 229ADDRESS0 154 SRAM Address CL11 226

CL12 76CL13 75CL14 225CL15 118CL16 192CL17 114CL18 87CL19 102CL20 220CL21 120

Table 2 - Pins for the PE (10K70)

Documents

PHD Designers Guide - Imperial College London€¦ · PIPEFlow Bus Routing The LBC looks after all the PIPE routing. This is all done in a transparent manner and as a PHD designer,