Designinga PCI Target/Initiator inFPGAs - Prevailing Technology, Inc

E:XILINX

Designing aPCI Target/InitiatorinFPGAs

Bradly Fawcett & Steven Knapp

XilinxInc.2100 Logic DriveSan Jose, CA 95124

1997On-Chip SystemDesign Conference

I:XILINX

Abstract

Intellectual property in theform of reusable cores can beused during high-densityFPGA design to decreasedevelopment times and risks.The use of one such core, theLogiCore™ PCI Interface,accelerates the development ofFPGA-based PCI card designs.This presentation is a casestudy of the design of the PCIinitiator and target interfacesin an XC4013E FPGA.Emphasis is placed on thedesign techniques used toachieve a high-performanceimplementation, the tools andmethodologies used tocomplete the design, and theuse of the core in endapplications.

Authors/Speakers

Current Activities

Bradly Fawcett

Brad Fawcett is currently aManager in the ApplicationsEngineering group at XilinxInc. Among his many duties,Brad is the editor of the XCelljournal, the Xilinx usernewsletter.

Steven Knapp

Steve Knapp holds the title ofVertical Applications Manager.Steve is one of the designers ofthe PCI LogiCore Interface

Authors Background

In his nine years with XilinxInc., Brad Fawcett has held avariety of applicationsengineering, technicalmarketing, and technicaltraining positions. A veteranof 20 years in the industry,Brad has prior designengineering experience withZilog Inc., Amdahl Corp., andBurroughs Corp. He holdsBachelor and Master ofScience degrees in ElectricalEngineering from theUniversity of Illinois.

A veteran of ten years atXilinx, Steve Knapp also hasapplication engineeringexperience at Intel Corp., andholds a Bachelor of Sciencedegree in Material Sciencefrom the MassachusettsInstitute of Technology.

Designing a PCI Target/Initiatorin FPGAs

Slide #1

Designing aPCI Target/Initiator In FPGAs

Xlllnx Inc.

I:XIUNX

With the recent emergence of PCI-compliant FieldProgrammable Gate Arrays (FPGAs), designers ofPCI bus interfaces can now reap the flexibility lindtime-to-market benefits of high-density userprogrammable devices, while avoiding the costs andrisks of custom and semi-custom IC development.With the increased logic capacity of the latestgenerations of FPGAs, a typical application's uniquecontrol logic for the "back-end" device beingconnected to the PCI bus can be integrated with thePCI bus interface on the same FPGA device.However, the perfonnance requirements of the PCIspecification are demanding even for advancedASIC technologies, and require FPGA designsclosely tailored to the device architecture. For thisreason, and since the PCI bus interface portion ofthe design is common to many applications, manyFPGA vendors offer ·pre-designed" modules orsimilar reference designs to their users, asexemplified by the Xilinx LogiCoren , PC1 Interfacefor the XC4000E FPGA family.

Slide #2

Brad Fawcett & Steve Knipp

XlIn.. tnc.2100 LoglcDrtYe

... Jose, CA H124E-mell: pclOdIn.LOOnI

Cun'll'lt AcUvltlea:

Brad Fn<*lll currenUr I ",n-a... 1n the Applications Engln.."ng group lit XIII"xtne. Among hi' mew-duu.., Brad I' the ..norot 1M XC,,, )oumal, the XIII"xu",n...tett,r.

Itevl Knapp ~d. the In'e of yeftll* Applk*kH11 Maneg.,. ltevlle on, of thedMigners of the Pel LOQlCore Interf.ee .

Author.' Backgrounds:

.... hltl nln, yeen with Xlnnx 'nCo,lrMtly Fawe«t tI.. hekl' vtritlty 01 ~pllcatlon.

engln.-fing, t.chnlCIII marketing, and technical training pcMltlonl. A veteran of 20rura In the ku:k,.try, 81W hO'dl B.ch-'o, Ind ....t.r of SCience degNM In Electric"EnglnMt1ng from the UnlV'rlily of IIIlnol•.

Avetenn or ten y..,. lit XI""x. SI... KnIPP.1O tI.. IPpUeaUon englnMring.XJ**'lc.III InMI Corp.. II'Id hold•• B8CMJor of 8cltnc.lHgrH In "Mertal ac"c.from tfM .....-:huMCt.lnatlluteofT8ChnO!ogy.

Slide #3

Designing aPCI Target/Initiator in FPGAs

The PCI LogiCore'" Interface

Agenda

IntroductionHow was It done?How was It tested?How Is it used?User benefitsUser experiences

This presentation will overview some of the issuesinvolved with designing FPGA-based PCI businterfaces and then examine the use of the LogiCorePCI Interface. Readers are assumed to have someknowledge of the PCI bus protocols; completeinfonnation about the PCI bus is available in thePCl Local Bus Specification and several referencebooks (see slides 50 - 52).


Slide #4

PCI Basics

• PCI =f.erlpheral s;tomponent interconnect

• A high-performance bus Interface- 33 MHz or 66 MHz- 32-blt or 64-blt- 5V or 3V

• Uses "reflective-wave" signaling

The Peripheral Component Interconnect (PCI) busdefinition has the admirable goal of providing highthroughput on a well-defined, lightly-loaded buswhile being compatible with today's Iemanufacturing processes.

The PCI bus specification was originally defined byIntel, but is now controlled by an industryconsortium called the PCI Special Interest Group(PCI SIG). The PCI bus has been adopted by nearlyevery major computer company, and also forms thebackbone in many embedded applications.

While PCI comes in several "flavors", mostimplementations today employ a 32-bit, 33 MHz buswith 5VVcc.

The PCI bus is unterminated, operating on theprinciple of reflective wave signaling. The initialoutput signal, therefore, has half amplitude. Ittravels to the end of the non-terminated bus, andgets reflected back towards the source to become afull-amplitude signal. This scheme demands strictcontrol of device drive characteristics. In order toachieve 33 MHz operation, the round-trip delaymust be limited to 10 ns, limiting the physicallength and allowable capacitive loading on the bus.

At the maximum 33 MHz clock rate, the 30 ns clockperiod for a data transfer allocates 11 ns for theoutput driver, 10 ns for the round-trip buspropagation delay, 2 ns for potential clock skew, and7 ns for input set-up time.

Slide #5

PCI Technical Challenges

• 100% compliance required for:- Add-In boards to be plugged Into any system- Systems that accept any PCI board

• "Follow the rules and It will work"

Full compliance is a requirement for any boardintended to be plugged into any PC! system or anysystem intended to accept any PCI-compatibleboards. In other words, full compliance is a must insystems that are to be sold to the generalmarketplace and require inter-operability amongmultiple vendors. However, if the systemenvironment is "closed", such as an embeddedsystem with no add-in capabilities, then, of course,the designer has freedom to deviate from thespecification.

The PCI Special Interest Group (PCI SIG) haspublished the PCl Compliance Checklist of parameters that both system and component suppliers mustadhere to in order to claim compliance. It includes aComponent Electrical Checklist covering areas suchas I/O signaling levels, timing specifications, andbus loading. It is important to review this checklistfor any device that will connect directly to a PCIbus. By responding appropriately to the items inthis checklist, an IC vendor demonstrates that theminimum amount of work required in order to claimcompliance has been completed. Examples of PCIcompliant FPGA devices include the XC3100A,XC4000E, and XC4000EX FPGA families.

However, while meeting the checklist criteria isnecessary, it does not in itself guaranteecompliance. Careful design is required to meet theperformance and signaling requirements of the PCIspecification.

Designing a PCI Target/InitiatorinFPGAs

Slide #6

The PCI LogiCore Interface

The Challenge:Design a 32-blt, 33 MHz PCllnterface

In an FPGA as a Re-Usable Core

Why a PCI core?

- Market demand- DIfficult, t1me-consumlng design

Why an FPGA?- Time to market, no NREs, etc.- Flexibility for spec. changes & Interpretations

- Integration of bus Interface with appllcatlon-

specific logic

As mentioned before, the performance requirementsof the PCI specification are demanding and requireFPGA designs closely tailored to the devicearchitecture. For this reason, and since the PCI businterface portion of the design is co=on to manyapplications, many FPGA vendors offer "predesigned" modules or similar reference designs totheir users, as exemplified by the Xilinx LogiCore™PCI Interface.

The main benefit of cores is the decreaseddevelopment time and effort associated with using apre-designed, proven function. Designers can focustheir efforts on the proprietary portions of thedesign, rather than Ore-inventing" a standardfunction.

FPGA devices are used on PCI cards for many of thesame reasons that FPGAs are chosen for otherelectronic systems: fast time-to-market, low designrisk, no non-recurring ·engineering charges, theconvenience and flexibility of user-progra=ability,and so on. For PCI card designs, the flexibility ofFPGAs can be key to responding to variations in theinterpretation of the PCI specification, or changes tothe specification itself.

Often, FPGAs are chosen over commerciallyavailable chip sets because they provide the abilityto integrate the application's unique "back-end"logic with the PCI bus interface on a single device.

Slide #7

FPGA Device RequirementsPCI SIG electrical compliance checklistSufficient capacity- Integrate PCllnterfeca & -back-endlogic- Include FIFO buffers (on-chip memory)

Sufficient performance- Support burst transfers- Meet set-up and hold time requirements

Appropriate architectural features- Multiple 3-state output enables- On-ehlp bussing

Choices: XC4013E:2PQ208 (Targat)XC4013E·1PQ208 (Initiator)

Many programmable logic devices lack sufficient orappropriate resources for PCI bus interface design.

As mentioned earlier, an IC that connects to the PCIbus must, as a minimum, meet the requirements ofthe PCI SIG's PCI Compliance Checklist.

An FPGA implementation should offer sufficientcapacity to hold both the PCI bus interface and theapplications unique "back-end" logic. The PCI bus isa synchronous bus based on a single master clocksignal; this implies that bus signals should beregistered as they exit and enter bus agents. Thus,PCI interfaces demand an architecture withadequate register space for latching bus signals aswell as generating state machines, pipelines, andother internal logic.

The back-end of a PCI bus interface typicallyconnects the bus to a processor, memory subsystem,embedded controller, or peripheral device. In mostdesigns, a data buffer, such as a FIFO buffer ordual-port memory, resides between the externaldevice and the PCI bus interface logic, decouplingthe speed of the PCI bus from the back-endcontroller, and allowing multiple data words to bequeued to support burst transactions. Thus, on-chipmemory capability is desirable in the FPGA tofacilitate construction of these buffers.

Furthermore, PCI devices must implement a basicset of configuration registers, divided into apredefined, 64-byte header region and a 192-bytedevice-dependent region. FPGA's with on-chip


Slide #7, continued

memory capability can include some or all of theconfiguration bits within the FPGA.

Of course, the device must be capable of meeting theperformance requirements of the POI bus, includingits stringent set-up and hold time requirements.Other, more subtle, performance requirementsresult from the implementation of the bus interfaceprotocols. For example, the IRDY# and TRDY#signals sometimes must respond to a change inFRAME# within one clock cycle. These signal pathsare design-dependent, involving internal logic androuting paths in the FPGA.

Beyond adequate register and memory capacity,other architectural features required for PCIinterface design include JTAG boundary scan logic(a PCI option), the capability of efficientlyimplementing wide address and data busses onchip, and plentiful, flexible output enables for threestate output buffers.

Some FPGA devices have restrictions as to thenumber of different signals that can be used asoutput enables for the device's output buffers.These devices generally are not good candidates forPCI bus interface designs. Since different buscontrol signals must be driven at different times andmost control signals are three-state signals thatmust be driven by three-state buffers, PCI interfacedesigns require significant flexibility in thegeneration of multiple output enable signals.

Taking all these considerations into account, theXC4013E-PQ208 FPGA device was selected as thetarget architecture for the LogiCore PCI Interface.

As with all Xilinx SRAM-based FPGAs, HardWireversions of the XC4000E Series FPGAs areavailable, providing a cost reduction path for highvolume applications that use the LogiCore PCImodule.

Slide # 8

Development System Requirements

• "Hard" macro for guaranteed performance- Schematic based (Vlewdraw)

• Instantlable In HDL

- Floorplanner U- Relatlonally-placed macros (XACTstep)- Guide flies- Timing-driven place & route

• Verification tools- Logic and timing simulation (Vlewslm & VSS)- Static timing analysis (XDelay)- Protocol verification (VIrtualChips)

An often overlooked factor when evaluating FPGAsis the capabilities of their development tools. Sincethe performance requirements of the PCI standardtax the capabilities of most FPGA devices,development tools capable of easily producing highperformance layouts are mandatory. Whileautomated layout tools should be robust, theintricacies of PCI design require that the designerexercise some control over the tools, especially inthe placement and routing of critical paths and theplacement of I/O pins. Thus, some form ofplacement control is needed, and floorplanningsupport is desirable. For FPGA-based designs,timing-driven place and route tools such as XACTPerformance™ from Xilinx can ease the designprocess by allowing the specification of targetperformance requirements for entire paths throughthe design. "Re-entrant" FPGA place and routetools, wherein the placement and routing of aprevious version of a design can guide theimplementation of a new version with minimalchanges, can greatly ease the design process.

The design was entered and tested using ViewlogicSystems schematic entry and simulation tools. Boththe schematics and resulting netlist files areprovided. The module can be instantiated fromwithin an HDL-based design. The design can beused as is or tuned to meet a specific requirement.Placement constraints, XACT-Performance timingconstraints, and a placement guide file guaranteePCI timing requirements. (Verification tools andprocedures will be discussed later.)


Slide #9

LoglCore PCI Interface Module

Fully-Integrated, tested, and validated PCI Interface- 32-blt Interface compliant with version 2.1- Target/Initiator and target-only versions- "Generic" back-end Interface- Customlzable- Verified with VlrtualChlps VHDL PCI simulation

model

• Supports basic PCI functions- Type 0 configuration space- Memory reads and writes- 1/0 reads and writes

The LogiCore PCI Interface is a fully-integrated,tested, and validated schematic-based PCI LocalBus interface module design targeted for theXC4013E FPGA device. Both lnitiatorlI'arget andTarget-only versions are available. This modulardesign can be customized by the user, and supportsthe quick implementation of prototype andproduction PCI applications.

The LogiCore PCI Interface is a complete 32-bit PCIinterface compliant with version 2.1 of the pC!Local Bus Specification. It supports all basic PCIbus functions, including Type 0 configuration spacesupport, I/O reads and writes, and burst-modememory reads and writes.

The LogiCore PCI Interface has been optimized witha floorplanned layout for the XC4013E-2PQ208device, but can be ported to other XC4000E andXC4000EX family FPGAs. (However, all compliancetesting was performed using the XC4013E FPGA.)The full InitiatorlI'arget design occupies less thanone-half of the Configurable Logic Blocks (CLBs) inthe XC4013E device, leaving ample space for theimplementation of the custom. back-end logic. Fullycompliant 33 MHz PCI applications require the -2speed grade for the XC4013E device. EmbeddedPCI applications, terminated busses, and systemsoperating below 33 MHz may be able to use a slowerspeed grade.

Slide #10


The PCI LoglCore Interface

Agenda

IntroducllonHow was It done?How was It tested?How Is It used?User benefitsUser experiences

Designing a PCI Target/InitiatorIn FPGAs

Slide #11

LogiCore PCllnterface Block Diagram

BASEAOOOESSRE<lIllT<R

o

IINm.o.TORSTATE

llAGIlNE~

""".lEV!8.-

TARGETSTATE..... llAGIlNE

The design was constructed m a hierarchical, modularmanner.

The I/O Interface block handles the physical connection tothe PCI bus, including all signaling, input and outputsynchronization, output three-state controls, paritygeneration and checking, and (for initiator designs) requestgrant handshaking for bus mastering. Parity errors detectedon the address lines are flagged by asserting the SERR#signal, and data parity errors are reported using PERR#.

The" Target and Initiator State Machines contain all thecontrol logic for handling bus transactions for target andinitiator agents, respectively. These controllers are highperformance state machines that use one-hot encoding formaximum performance. The states implemented are asubset of the equations defmed in Appendix B of the PCILocal Bus Specification.

The Configuration Logic block holds the ConfigurationSpace Header, the command and status registers used inoperations such as "plug-and-play" initialization. The first64 bytes of a Type 0, version 2.1 Configuration SpaceHeader are provided. Read/write registers are implementedusing flip-flops in the FPGA's configurable logic blocks(CLBs), while read-only registers are implemented as ROMmemory using the CLB's lookup tables, resulting inoptimized packing density and layout.

A simple, general-purpose interface is provided forconnecting to the application's back-end logic, including a32:bit data path and latched address bus. Most of themodule's internal data paths and state machine controlsignals are included in the user interface, providing ampleflexibility for customized user applications.

Slide #12

Meeting Performance Goals

• HDL solution preferred by designers• Current HDLs lack good placement, partitioning

controls• Solution: Specify design In VIEWlogic schematic• Design (netllst) can be Instantiated using HDLs• XACTstep provides additional capabilities

- "Guide" flies to guarantee performance on criticalpaths

- "XACT-Performance" timing-driving place and route- Floorplanner tool for pre-placing structured

elements

The most difficult challenge in the design of theLogiCore PCI Interface was meeting all theperformance requirements while implementing thecomplex functions required of a PCI bus interface.

Ideally, the LogiCore PCI interface would "have beenspecified and implemented from a hardwaredescription language (HDL) like VHDL or Verilog.Most designers building high-density applicationsseem to prefer HDLs over schematics.Unfortunately, today's HDLs lack sufficient controlover partitioning and pre-placement in order toeffectively implement a full-speed PCI design.

Instead, the design team chose the Viewlogicschematic editor and simulator to specify the design.Using the XC4000E library, a designer can partitionand pre-place logic within the device. For designersrequiring HDL entry, the schematic-based netlistcan be instantiated within the an HDL source file.

Careful control of the mapping, placement, androuting of the design was required to meet all theperformance requirements. Fortunately, asmentioned before, the XACTstep FPGA developmentsystem provides the appropriate controls. A "guide"file contains specific layout and routing informationto guarantee some timing-critical 3-state and setuppaths. Timing constraints for the timing-drivenplace & route tools are used to guarantee that allpaths meet the necessary specifications. Thefloorplanner facilitated the pre-placement ofstructured elements such as the internal bidirectional bus and the data registers.


Slide #13

Meeting I/O Performance Goals7 ns setup. 11 ns Clock-to-Output

• Solutlon: XC4000E Input/output flip-flops provideguaranteed PCI-eompllant pln-ta-pln timing

Complication: Input/output flip-flops add onecycle of latency (pIpeline delay)- Some peths cannot tolerate the latency and

stili meet PC! ccmpllance- Complicates target and Initiator state machine

design

One of the most difficult challenges was meeting the7 ns setup and 11 ns clock-to-out times. Thededicated input and output flip-flops in theXC4000E I/O blocks were used extensively.

Determining an FPGA's compliance to the I/Otiming specifications can be difficult, since globalbuffer and interconnect delays as well as logicdelays must be taken into account. For example,most FPGA data sheets specify clock-to-outputtiming for registered outputs relative to the clock atthe output register (which may reside in an I/Oblock or nearby logic block). However, the PClstandard specifies pin-to-pin timing, and the clockto-output valid delay is measured relative to the busclock entering the FPGA device. Thus, the clock-tooutput valid delay in an FPGA typically wouldinclude the delay in inputting the clock signal,bringing it to the FPGA's global clock buffer, routingthe clock to the relevant I/O or logic block, theinternal clock-to-output delay of the register, andthe delay through the output buffer.

Similarly, set-up and hold times for registeredinputs also must be examined carefully in FPGAdesigns. The internally-specified set-up and holdtimes must be adjusted to compensate for the delaysassociated with getting the clock signal through aninput buffer and to the register. This may result innon-zero hold time requirements in some FPGAs.(Tlie XC4000 Series devices include a deliberatedelay in the data path to an input register tocompensate for the clock distribution delay, and,

thus, guarantee set-up and hold times relative tothe clock input pin.)

Using the I/O flip-flops complicates the design inthat it adds a level or two of pipelining. A majorityof pC! applications can tolerate some latency.However, there are a few PCl transactions thatcannot, so the control logic must be constructedaccordingly.


Slide #14

Interface Plpellnlng

Slide #15

State Machine Design

Receive signalfrom PCI bUs toUser Application

Send signal fromUser Acolication

to PCI bus

PCI Bus Clock

...-2 -1 0 +1

;....._....~~: ~:

: SIon" :SIgnal : caplured ;

: presented : aval~e to :; on PCI bus; user :: 'ication :

--~---+.::--.. . Present ; ,

~ Present : t=~~~es: Presented :, Input to ' 'sign..·: reglstered : RegIstered : BP.P!!lsrs on ;: signals : v81ues : PCI bus ;

appear : ;

• Based on PCI Spec., AppendIx B equations

• "One-Hot" state encodingClosely matches XC4000E architecture

- Reduces fan-In, Increases performance

Matchto application- Target with slow DEVSEL# speed- No address stepping- Support "user application"

Predictive decoding

The LogiCore interface pipelines all of the buscontrol signals and the data path.

Arriving signals are captured in an input flip-flopand are available to the user application one cycleafter they appear on the PCI bus. For example,data becomes available on the ADIO[31:0] businternal to the LogiCore module one cycle after itappears on the PCI bus. Signals provided for theuser interface, such as ADDR_VLD andDATA_VLD, signal the user application when validinformation is available on the internal bus.

Most of the outputs connected to the PCI busoriginate from an output flip-flop in order to meetclock-to-out performance requirements. Thus, whenthe user application is sending a combinatorialsignal, the signal must be presented one cycle beforeit is to appear on the bus. If the signal firstoriginates from a register in the user application,then that register's inputs must be presented twocycles before the signal is to appear on the bus.

The signals involved in bus transactions, such asFRAME#, IRDY#, and TRDY#, and the operation ofdata flow pipelines are controlled by state machinesin the bus interface logic. Example state machinesfor controlling bus signaling are provided inAppendix B of the PCI Specification. To complywith PCI bus protocols and performancerequirements, high-performance state machines arerequired. For FPGAs, one-hot-encoded (OHE) statemachines are used (that is, state machines with oneregister per state and minimal decoding logic).These are well-suited for register-rich FPGAarchitectures.

The state machines described in Appendix B of thePCI specifications are "generic". The LogiCore PCIinterface implements a subset of the full equationsmatched to the FPGA implementation. Forexample, the LogiCore interface only supports"slow" DEVSEL# decoding, so some of the equationscan be significantly reduced. Likewise, somefeatures, such as address-stepping, are notimplemented. Some modifications were made tosimplify the user interface, especially in theInitiator state machine.

To boost performance and decrease response time,some portions of the state machine employpredictive encoding.


Slide #16

Problem: PCI-Compliant 100%Burst Transfers

ReceIving deta et 100% burst Is no problem- 7 ns setup time guaranteed using Input flip-flops

Sending data at 100% burst while maintaining 100%compliance Is a problem- Follow PCI trsnsactlon rules (Appendix C, Rule

2c., 16)- Monitor IROY# or TROY# and switch 36 outputs

with 7 ns setup and 11 clock·ta-out- Darn near Impossible with today's programmable

logic- Various "tricks· offer 100% burst but violate full

compliance

The PCI bus protocols encourage burst-orienteddata flows between bus agents, facilitating the useof pipelined data flows within PCI bus interfacelogic. Pipelining techniques are often key tosuccessfully supporting data transfers at themaximum throughput of the bus. While wait statesduring bus transactions are permitted andoccasionally may be necessary, a high frequency ofwait states is counter to the high-performance goalsof the PCI standard.

While the PCI protocols are compatible with datapipelining, there are three exceptions: when aninitiator inserts wait states during a burst readcycle, when a target inserts waits states during aburst write cycle, and the sequence of events thatstarts on the last transfer of a burst. In thesesituations, the IRDY#, TRDY# and FRAME# signalsmust be sensed directly and responded to withintheir 7 ns set-up time on the bus.

The LogiCore PCI interface can receive data at100% burst rates. Data is captured in flip-flops andmade available to the user application.

However, the LogiCore interface does not support100% burst when it is sending data. This is becausethe LogiCore interface strictly adheres to the PCItransaction rules. These rules state that, once datais presented, the agent providing the data cannotchange the data until the transfer is complete. Tosupport 100% burst, an agent would need to presentthe data, monitor the receiving agent's ready line

(IRDY# or TRDY#), and present new data once theother agent has asserted its ready line. Meeting the7 ns setup time on the read line and then sendingthe next data within the 11 ns clock-to-out timing inthe same cycle is nearly impossible with today'sprogrammable logic devices. Without employingany "tricks", the LogiCore interface is limited to 50%of the maximum burst rate when it is providingdata. Most importantly, it does not violate any bustransaction rules.

In some embedded applications, various tricks canbe used to attain 100% burst. However, this meansviolating strict adherence to the PCI specification.

Some of the PCI interface designs being offeredtoday advertise full burst support, but only byassuming that the receiving agent in a bursttransaction never generates a wait state. Therefore,these designs are not fully PCI compatible.

Designing a PCI Target/InitiatorlnFPGAs

Slide #17



IntroductionHow was It done?How was It tested?How is It used?User benefitsUser experiences

Slide #19

PCI Protocol Testing• VirtualChips VHDL bus simulation model using

Synopsys VSS simulator• VIEWslm digital simulator with Xlllnx-created

testbench- Target functional model- VIEWslm command flies that match PCI-6IG

compliance test scenarios- Created extra Target test scenario to test target

tennlnatlons (not covered In PCI-SIG checklist)Cross-checked results between VlrtualChlps andVIEWslm

• Results summarized In "LoglCore PCI ProtocolChecklist (v2.1T

Slide #18

. Design Verification

XUlnx XOelayStatic Timing Analyze,Autometlc ACTiming Verification

VIEWslm Test VectClnlpC! Protocol Test Pelterns

(Simile, to PCl-SIG checklist)

VlrtualChlps'·pC! Tastbench

PCI SIGTastScenarios

The LogiCore PCI Interface has been fully verifiedusing the Synopsys VSS VHDL .and ViewlogicViewSim logic simulators. Protocol compliance wastested according to the PCI Compliance Checklist,Revision 2.0b, published by the PCI-SIG. Both theVirtualChips VHDL PCI bus simulation model andan internally-developed test suite were employed.Several tests were added to test functions notcovered by the PCI-SIG checklist, such as targetagent responses to various termination conditions.The test results are summarized in the XilinxLogiCore PCI Interface Protocol Checklist (v2.1).

The design also was verified via actual FPGA deviceimplementations at multiple "beta site" accounts.

Tools used to verify the operation of the LogiCorePCI interface include simulators and static timinganalyzers.


Slide #20

VIEWslm PCI Protocol Testbench11'Jl,lI'rA1'o' ...~w.. ..~.

· TESTBHCH.l contains anr.'lt~ ~. -axampla user application F"I'I(;la)t',Al -,M.... .....- TMtU....

for performing Initiator -protocol testing rn

· Target function model parforms I ~'t:"unnatural acta" on the bus such '("'''~.t

.. presenting Incorrect parity, etc.

· Simple arbiter ..serts GNTI alter the LoglCoreInterface ..serts REQ,. GNT' asserted for twocycles then de-esserted until next transaction

Users are encouraged to perform a functionalsimulation after selecting the custom options in thePCl LogiCore module and integrating the back-endlogic with the LogiCore module. After running the"place and route" software that determines thephysical implementation of the design in the FPGAdevice, the Xilinx XDelay static timing analyzerand/or a timing simulator should be used to verifyperformance along all critical paths.

A PCl Protocol Testbench for the Viewlogic ViewSimsimulator is provided with the LogiCore module tofacilitate user testing of the completed design. Thetarget functional model (faketarg) has beendesigned to respond according to the scenariosdescribed in the PCl SIG Compliance Checklist.During protocol testing, the target responds in waysthat a "real" target would not, such as forcinginvalid parity. The simple arbiter (fakearb) merelyasserts GNT# after the LogiCore interface asserts itREQ# pin.

The various compliance tests can be .executedindividually. A full test requires about two hours toexecute on a workstation platform.

Slide #21



Agonda

IntroductionHow was it done?How was 1\ tested?How Is It used?User benefitsUser experIences

Designing a pel Target/InitiatorlnFPGAs

Slide #22

Customizing the LogiCore PCI Macro

Slide #23

-",..."... ......""0'''.'' ::::

Back-End User Interface

• Addition of user application's unique back-end logic

• Options for customizing PCI bus Interface

- Implemented by changing schematic symbols

- Main option: target-only or InlUator/target

- Edit Conllgurat,lon Space Header• ReadlwrR. regl.t..... lmpl.m.nted In C~B flip-flop.• Read only regl.lAlra Implemented In ~UT.

- Enable/disable latency timer & plpellnlng. • Only used for burst transactions

............ ~

: .::;::~i··....: ..:::: .:;::::: ..::::

32·blt multiplexed address/databus

32·blt latched address

PCI control/status signals

User controls (e.g., Ready,Terminate, and Interrupt)

State bits of bus control statemachines

The LogiCore pC! Interface provides a foundationPCI bus interface design that can be tailored for thespecific application. Besides adding the uniqueback-end logic for the application, users cancustomize the PCI bus interface itself.

For users of the InitiatorlI'arget version, the firststep in customizing the PCI interface macro is todefine whether the application is a target-only orinitiator/target function. As delivered, the macro isconfigured as an initiator/target interface;configuring the macro to be a target-only interfacerequires changing one symbol on the top levelschematic.

Many of the customization options involve the PCIconfiguration register space. The defaultconfiguration includes two Base Address Registers,a Command Register, a Status Register, anInterrupt Pin and Line Register, and a read-onlymemory space for the Device ID, Vendor ID, ClassCode, and Rev ID registers.

If the application is an initiator/target, and it willnever burst more than two data cycles, than aLatency Timer can be disabled, conserving spaceand simplifying the control logic. Similarly, if theapplication supports only single data transfers, thenthe pipelining logic can be disabled.

Every PCI application requires a PC! bus interfaceplus an interface to the user application (I.e., the"back-end" device being connected to the bus). Theuser connects the LogiCore module to other modulesto complete the design. A general-purpose interfaceprovided in the LogiCore design is used to connectthe application's logic to the PCI bus, allowing theback-end logic to reside in the remainder of theFPGA device. Connections to the user interfaceinclude a 32-bit multiplexed address/data bus (thesame address/data lines that connect to the PCIbus), a 32-bit latched address, several of the PCI buscontrol and status signals (including FRAME#,TRDY#, IRDY#, and CBE[O-3D, user control signals(such as READY, TERMINATE, and INTERRUPT),and several state bits from the bus control statemachines. Thus, if desired, back-end logic canmonitor and control all appropriate bus activity.


Slide #24

Back-End Logic

Slide #25

FIFO Buffers

• Employ readlwrlte registersfor transferring data

Needed to support burst transactions- Between LoglCore Interface & back-end device

Dual-port FIFOs easy to create usingsynchronous, dual-port distributed memoryoption In XC4000ElEX FPGAs

All bus control signals & datapaths are plpellned

Synchronous design techniques recommended- All signals should be registered- Increases performance and facilitates timing

analysis

In the majority of applications, data is transferredto and from read/write registers in the back-endlogic. These registers often are part of a FIFObuffer, but also may be connected to I/O pins orother logic. The figure illustrates a typical dataconnection. A clock enable signal (CLK-ENA) isused to control the capturing of data from the PCIbus (for example, when writing data to a target),and three-state buffers control the routing of databack onto the bus (for example, when reading from atarget).

In order to meet the PCI bus' stringent performancerequirements, the LogiCore interface pipelines allthe bus control signals and the data path.Consequently, some signals must be presented up totwo clock cycles before they appear on the PCI bus.Likewise, arriving signals are captured andavailable to the b~ck-end logic one clock cycle afterthey appear on the PCI bus. Appropriate signalsare included in the LogiCore module's back-endinterface to signal the appearance of valid addressand data information.

It is highly recommended that all signals to or fromthe back-end interface should be registered. Goodsynchronous design techniques can increase systemperformance and simplify timing analysis.

LoglCore macro Incl. a t 6 x 32 readtwrlte FIFO- Used In verification testing

Separate dual-port FIFOs to support bus readsand writes recommended

Typically, PCI designs include a FIFO bufferbetween the LogiCore module and the back-endlogic. This buffer isolates the speed of the PCI busfrom the operation of the back-end logic. Data to betransferred from the back-end device can be queuedin the FIFO in preparation for a burst transfer, anddata to be transferred to the back-end device can beplaced into the FIFO by a burst transaction andsubsequently processed by the back-end logic at itsown rate.

The synchronous, dual-port distributed memorymode of the XC4000E and XC4000EX FPGAarchitectures is ideal for implementing FIFO buffersof any desired length and width. As shipped, theLogiCore PCI Interface includes an example userinterface - a 16 x 32 read/write burst FIFO buffer.(This application helped simplify the PCIcompliance testing using the VirtualChips PCI bussimulation model.) However, the recommendedstructure for most designs is a dual FIFO design,with separate buffers to support bus read and writeoperations. FIFO buffers that are 16 double-wordsdeep fit best in the XC4000ElEX architecture; noperformance or density is gained by making thebuffers shallower. FIFOs deeper than 16 doublewords but less than 33 consume more logic blocksbut do not add delay. FIFOs deeper than 32 doublewords would consume more logic and delay.


Slide #26

LoglCore PCI Design Structure

Most of the LoglCorePCI design In theLC_PClllbrary

Only PCUC_1.1 and .2should be modified

Designer should putuser appllcetlon Inuserapp "wrapper"schematic

Keep all top-levelnames to make guIdefiles work

The LogiCore PCI Interface provides a foundationPCI bus interface design that can be tailored for thespecific application. Besides adding the uniqueback-end logic for the application, users cancustomize the pC! bus interface itself.

The LogiCore module's design structure andmodifiable schematics are shown in the figure. Inmost cases, customization of the interface logicsimply involves replacing particular symbols in theViewlogic schematics with other pre-preparedsymbols, using the schematic editor's 'ChangeComponent' command.

The back-end application logic that is to beintegrated onto the FPGA with the PCI businterface should be placed under the "userapp"hierarchy. This is required to guarantee thatcritical instance names and net names match that ofthe "guide file". This guide file is used to direct theplacement and routing of timing-critical logic, andwas carefully designed to achieve maximumperformance.

Where applicable, logic contained within theschematic is trimmed during the compilationprocess (Le., unused logic is automatically removedfrom the design).

Slide #27

Configuration Space Header

~S:::'"~~,.,.~

D,.'"~D~..~

LoglCore module Implements first 64 bytes ofType 0 CSHSymbols to customize Base Address RegIstersize and modesLoad hex table to specify read-only regIstercontenta endor 10 etc..

The default configuration includes two BaseAddress Registers, a Command Register, a StatusRegister, an Interrupt Pin and Line Register, and aread-only memory space for the Device ID, VendorID, Class Code, and Rev ID registers. All remaininglocations in the CSH return a value of zero duringconfiguration reads, and no operation occurs duringconfiguration writes. If desired, additional locationsin the CSH can be added by the user. Base AddressRegister sizes and modes can be altered by changingsymbols on the schematic. A modifiable tableincluded on the schematic for the read-onlyregisters, such as Device ID, allows users to easilydefme their contents.


Slide #28

3 Steps to a Complete PCI Design

Build the Target-Side Interface- Required In every PCI design

Build the Initiator-Side Interface- Only required In Target/Initiator designs

• Build In Burst Support- Only required If supporting burst transfers- Possibly four separate design steps,

depending on the application:• Targat Raad - Target Write• Initiator Raad - Initiator Write

Completing a PCI bus interface design using theLogiCore PCI Interface module can be broken downinto three main sub-tasks: building the target-sideinterface, building the initiator interface, and,optionally, providing for the support of bursttransfers.

Slide #29

Step 1: Build a Target h,terface

Required In every target &every Initiator design

Configure the Base Address Registers (BARs)

Edit the read-only values In Configuration SpaceHeader (CSH) ROM

Build Intarface to the readlwrlte Target locationsIn the user application

Decide how to force Target Terminationconditions, If required

A target interface is part of every PCI bus interfacedesign, regardless of whether the bus agent is aninitiator/target or target-only interface. Creating atarget interface Using the LogiCore module involvesthe following steps: configuring the Base AddressRegisters, defining the read-only values for theConfiguration Space Header ROM, building theinterface between the PCI module and theapplication's unique back-end logic, and (if required)deciding how to force Target Terminationconditions.


Slide #30

Target Termination Conditions• Target can Initiate various tennlnatlon conditions:

- Normal TennlnlUon: "Evlrythlng WI. perfect"- Tlrg.t R.try: "Com. back later. I cen't respond Just DOW."

Cln only ba ulld on IIret nnlfer cycle.- Tlm,t pllCiOnntct with Data: .., can't complete the transaction,

but I'll give you whet I hev.. Com. back lIter lor the rea!."- Target placonnocl wllhout pIIB: "I gave you everything thet I

cen give you right now. You might try again later."- T.rg.t Abort: "Big troublel You may have tr1ed aomathlng

IlIeg.1 or I'm d88dl"

Uses READY and TERM signals sourced fromback-end logic

The user application can force various targetinitiated tennination conditions. The state of twosignals, TERM and READY, that have their sourcein the user application logic, detennine thetennination condition. A Target Retry conditioninfonns the initiator that it must try the transactionagain later. A Target Disconnect indicates that thetarget is no longer able to continue the transaction(for example, due to a full FIFO buffer during aburst write operation); data mayor may not betransferred on the disconnect cycle. A Target Abortsignals a serious error at the target that preventsthe requested transaction.

Slide #31

Step 2: Build an Initiator Interface

Build the Initiator state machine- Drive the REQUEST and COMPLETE signals- Size and direction of data transfers?- How to handle any target termination

conditions?- How tei arbitrate between Incoming Target

accesses and pending Initiator transactions?Build the Interface to drive the starting addresson ADIO[31 :0)

• Build Interface to the read/write Initiator locationsIn the user application

Creating the initiator portion of a PCI interface alsoinvolves building the appropriate interface betweenthe LogiCore module and the back-end application.Before designing the initiator's control logic, severalaspects of its operation must be defined, includingthe type and speed of data transfers initiated by thisagent, the desired response to the target-generatedtermination conditions described above, and themethod of arbitrating between a pending initiatorrequest and an incoming target transaction.


Slide #32

Step 3: Burst Transfer Support

can be up to four different Interfaces- Read and write directions- Target and Initiator sides

Build address counter and associated control logic

Provide plpellned source data using SRC_EN signal

• Build FIFOs to support the specific application needs

Build COMPLETE logic and transfer control

Performing a single data transfer across the PCI busis the simplest type of transaction. However,because of the overhead of distributed addressdecoding, this wastes valuable bus bandwidth.Achieving high bandwidth requires the use of bursttransactions, where multiple data words aretransferred during each transaction.

Slide #33

Address CountersOnly .tar1fng .dd..... I. bl'Olldca.t during. tranaacUon- BI'OIIdc8llt during the address ph....Iong with the PCI bu.

comm.nd on CBE[3:01Uaar .ppllceUon mu.t keep track of curr.nt .ddress dUrfngburet eppllc.Uon.- R.qulre•• Ioedabl., bln.ry countar larg••nough to cover

de.lred address range.Exampl.: T.rg.t has 4K .ddr.ss .pec•. Needs 1()'blt binarycountar. Low.r two bite are zero (32·blt tran.f....). Upper 20bits can be register (not required If not used In the us.reppllcsUon)

In PCI bus burst transactions, only the startingaddress is broadcast over the bus. Thus, duringburst transfers, the back-end logic must keep trackof the current address. Typically, both target andinitiator control logic must keep a local copy of thecurrent address pointer and increment it after eachtransaction. This counter usually is small; its sizedepends on the target's address block size, asdetermined by the contents of the Base AddressRegisters. If a target agent detects an overflow ofits address space, it should issue a TargetDisconnect, indicating that it is unable to performthe requested operation. The initiator's response toa Target Termination depends on the type oftermination. If the initiator receives a Target Retry,it should simply restart the transaction from thestarting address. However, if a Target Disconnect isdetected, the initiator will have to use the currentcontents of its address pointer to know where to restart the transaction. To complicate manners, thetarget can disconnect with or without data, and theinitiator must increment or freeze the addresspointer accordingly.


Slide #34

Automatic Walt-State Insertion

- · LoglCore receives data atT... _

1000/. burst and sends data attOlMe-,,-

""""' 500/0 burst- ""-- T.... · IROY· or TROY· walt·atatesautomatically Insertlld onburst lrensfsrs whsre theLoglCore Interfaos IsproViding data

.--- T........ · LoglCore InlUator also Inserts.......- """"' IROY· wait-state before de-- "" aS88rUng FRAME- durtng aIADV. n .. __ ~, T...

burst lrenafsr

· AutomaUc wait-states newr8S88rted on slngls datalrenafsra

The maximum theoretical PCI bus bandwidth is 132Mbytes/sec. However, actual system bandwidthvaries tremendously from one platform to another.PCI bus performance is controlled by three keyfactors: aggregate bandwidth, data throughput, andaccess latency.

The ideal PCI burst write transaction requires threeclock cycles for the first transfer (Idle, Address,Data) and one clock cycle for each subsequenttransfer, referred to as a 3-1-1-1 sequence. Theideal write transfer needs four clock cycles for thefirst transfer (Idle, Address, Turn-around, Data)and one clock cycle for subsequent transfers (4-1-11).

The LogiCore PCI Interface requires additionalclock cycles to decode the address (referred to asSLOW decoding in the PCI Specification). Targetburst write transactions do not require any waitstates; thus, the default transfer rate for I/O andMemory Write transactions is 5-1-1-1. Initiatorsadd an extra clock cycle at the end of a transactionto provide reliable disconnection from the bus; thedefault rate for initiator reads is 4-1-1-2.

A wait state is added to each transaction when theLogiCore PCI module is the source of data for aburst transaction (Le., initiator writes and targetreads). These wait states are needed to guaranteecompliance with all the PCI bus operating rules.(See slide 16.) For example, suppose the LogiCorePCI Interface is incorporated in a target agent.

When an initiator reads from that target, theinitiator can de-assert IRDY# before a clock edge toindicate that it is not ready for the next datatransfer (that is, an initiator-generated wait state).The current implementation of the LogiCore macrocannot respond to this within the available 7 ns.Therefore, when the LogiCore PCI target macro isthe source of data in a burst read transaction, italways adds a wait state to each read transaction toallow ample time to check the initiator's IRDY#signal. Hence, the default rate for target I/O andMemory Read transactions is 6-2-2-2. In systemswhere an initiator never generates wait states, thedesign could be modified to support 6-1-1-1 readtransfers. Similarly, the default rate for LogiCoreinitiator burst writes is 3-2-2-2. (Wait states arenever added to single data transfers.)


Slide #35

LoglCore PCI InterfacePerformance

Slide #37

Benefits of Core-Based Design- .... I'CIWrIo-klNIl"Ct"'-d-!i6bW,,"

-"'lofilloNf•• T..... _

-- T.":""_

Ideal transfer rates:

Write: 3-1-1-1

Read: 4-1·1-1

Three or four clocks to 1st dsta &one clock for each burst transfer

• Decreased development time & effort- Allows focus on proprietary portion of design- Access "system expertise" of core's designers

• Decreased development risk. - Predictable functionality and perfonnance

LoglCore module (·2 speed grads):

Initiator Read: 4-1·1·2

Initiator Write: 3-2-2-2

Target Read: &-~2-2

Target Write: 5-1·1-1

Optimization for best device utilization

The chart compares the maximum data transferrates for ideal PCl read and write operations andLogiCore PCl initiator and target transactions.

The bandwidth of the PCl bus is primarilydetermined by the size of the burst transfer.

Slide #36



Introduction

How was it done?How was it tested?How Is It used?

User benefitsUser experiences

The main benefit of cores is the decreaseddevelopment time and effort associated with using apre-designed, proven function. Designers can focustheir efforts on the proprietary portions of theirdesigns, rather than "re-inventing" a standardfunction. Often, for complex functions such as PClinterfaces, utilizing a core allows the user to accessthe "system expertise" of the core's designers; theuser does not have to acquire similar levels ofexpertise on that aspect of the design. Thus, the"make or buy" decision often falls on the side ofpurchasing the core, particularly for standardfunctions that are needed for market acceptance butcontribute little to product differentiation.

Where appropriate, cores should utilize theavailable architectural features of the target FPGA,such as dedicated arithmetic carry logic, internalthree-state buffers, and oncchip memory.


Slide #38

Core-Based Design RequirementsSilicon, Software, Service

Slide #39

But It's Not a Panacea ...

Predictable functionalityand performance

Optimized for bestdevice utilization

• Accessible systemexpertise

Supporting tools andcollateral

&w;'F#iilh.i·i,

PClls difficult, even In ASICs

• Use of LoglCore PCI module requires- Understanding of PCI protocols- Hlgh-perfonnance. pipelined design techniques

• Use of gUide flies, TIMESPECs, 1Io0rplsnner

Selection criteria for choosing a core would include,of course, the functionality and perfonnance of thatcore. These factors, in turn, depend on how well thedesign of the core is optimized for the target devicearchitecture. However, potential users should alsoconsider three other main factors that lead to a·complete" solution: silicon, software, and service.In other words, is the selected device an appropriatetarget for this function, does the developmentsoftware properly support core-based design, andare technical support resources available to assist ifproblems arise?

Core-based designs are most appropriate for highdensity FPGAs with a rich feature set. The FPGAdevelopment environment must support theappropriate design entry, synthesis, and simulationtools needed for the particular core design.

For hard cores, perfonnance infonnation obtainedwith static timing analysis and/or timing simulationshould be supplied. The methodology and tools usedto pre-defme the implementation of the criticalpaths, such as placement and timing constraint filesor guide designs, should be well-understood.

To insure the productivity gains that motivated theuse of a core, extensive documentation andapplication support must be available. Of course,the degree of support required for core integration isoften proportional to the complexity and flexibilityof the core.

However, the use of pre-defined cores should not beconsidered a panacea for the development ofcomplex systems. While potentially saving time andeffort, cores still must be interfaced to other logicand integrated with the overall design flow. Corescan present difficulties with synthesis, simulation,layout, and system verification. Furthennore, thefact that the FPGA vendor supplies or endorses thesupplier of a particular core does not preclude thedesigner from understanding the function of thatcore and ensuring that the appropriate constraintsare applied during the synthesis and physicalimplementation of the design in the FPGA device(Le., when running the 'place and route' tools).


Slide #40



IntroductionHow was It done?How was it tested?How is It used?User benefitsUser experiences

Slide #41

User Experiences

LoglCore PCllnterface already used by> 150designers (as of 9/96)

Examples:- XC6200 co-processor development board- Digital audio broadcast transceiver- High-performance graphics system- Networking sub-system Interface

The LogiCore PCI interface was extensively "betasited" in late 1995 and early 1996. Since itsintroduction, over 150 users have licensed use ofthis module.

Here are four examples of applications that areusing the LogiCore PCI Interface in XC4000 SeriesFPGAs.

Slide #42

Xlllnx XC6200 Co-ProcessorDevelopment Board

XC4013E as PCI Target Interface to memory-mappedXC6200 co-processor

Xilinx is using the LogiCore PCI module in one if itsown products, an evaluation and prototyping boardfor the XC6200 family FPGAs. The XC6200 devicesare FPGAs whose architecture is optimized for useas a coprocessor in high-performance dataprocessing applications. An XC4013E FPGA on theprototyping board provides the interface between aPCI slot in a PC and the XC6200 processor on thisevaluation board.

.Designing a PCI Target/InitiatorinFPGAs

Slide #43

Digital Audio Transceiver

• XC4013E as PCI Target Interlace

-----

Digital Audio System

Engineers at Delco Electronics have designed aDigital Audio Broadcast (DAB) transceiver thatemploys an XC4013E FPGA and the LogiCoremodule to interface between the PCI bus and thetransceiver. Much of the transceiver's logic also isintegrated into the FPGA device.

Slide #44

Digital Audio Transceiver

·We chose Xlllnx modules because they're

fully verified. As a reSUlt, the module worked

the first time, saved US over six months In

development time, and allowed us to focus

our resources on our system design.·

Brian Warren, Senior Design Engineer,

Delco Electronics

In this case, use of the LogiCore PCI moduledelivered on its promise of shortening the designcycle and allowing the designers to focus on theproprietary portions of their design.

Slide #45

High-Performance GraphicsSystem

XC4020E as PCI-PCI bridgeIntegrates bridge and support logicUnsupported use and unsupported deviceImplemented In Xlllnx HardWlre for high-volumeproductionHelped to locate and repair flaw In another PCIASIC

In this design of a high-end graphics controller by aleading electronic game manufacturer, the PCILogiCore module served as a starting point for thedevelopment of a PCI-to-PCI bridge implemented inan XC4020E FPGA.

In this case, the flexibility of the FPGA-basedapproach had an unexpected benefit. When a flawwas discovered in a large ASIC device in the system,designers were able to change the logic in the FPGAto repair the problem, thereby avoiding a redesignof the ASIC device, resulting in a considerablesavings both in terms of expense and developmenttime.

This. design is expected to reach significant volumes.The user plans to convert the XC4020E FPGAdesign to an architecturally-compatible XilinxHardWire device as a cost savings during volumeproduction.


Slide #46

Networking Sub-System Interface

• XC4013E as PCllnltiator plus Interface to networkcommunication device

• Includes Integrated data FIFO

• Embedded PCI application operating at 25 MHz

In this application, the LogiCore PCI interfacereplaced a dedicated pC! chip set and various gluelogic. The application is a PCI interface to anetwork communication device. To boost overallsystem performance, data is burst over the bus infour-word transfers and held within FIFO buffersintegrated on the FPGA with other system gluelogic.

This design also has been converted to a HardWiredevice to reduce costs for high-volumemanufacturing.

Slide #47

Interesting Things We Learned

PCI specification open to Interpretation in someareas- Gaps In PCI SIG compliance checklist

Many available PCllnterfaC8 designs forprogrammable logic are not fully compliant- Ignore walt states from receiving agent during

burst

PCI designs require a lot of technical support- Significant learning curve for designers

Slide #48

Summary

• PCI Interface designs are difficult

• High-performance FPGA designs reqUiref1oorplannlng, timing & placement constraints,and re-entrant place & rome tools .

Use of pre-designed cores accelerates designcycles and reduces design risk- Designer must understand application,

FPGA tool use

PCI-compatible FPGA devices bring the systemintegration, flexibility, and time-to-market benefitsof high-density programmable logic to the PCIdesign community. With careful design, thesedevices can provide the performance, density, androutability to handle complex structures such aspipelined data paths, 32-bit parity generation, andPCI bus control.

The LogiCore PCI Interface provides a high-qualityfoundation design for the development of FPGAbased PCI card solutions. Use of this moduleminimizes the engineering effort required to developa PCI interface, reduces design risk, and allowsdesigners to focus on the important system-levelaspects of the design.

However, the availability of such modules shouldnot be viewed as a panacea. PCI bus interfaces arechallenging in any technology, and especially so inFPGA devices. The degree of difficulty is influencedby the maximum system clock frequency, whether atarget-only or initiator/target is needed, andwhether the application supports burst datatransfers. A 33 MHz, fully-compliantinitiator/target design should only be attempted byexperienced users willing to invest the extra effortto obtain maximum bandwidth.


Slide #49

Tools Used

Vlewloglc schematic editor & simulator

XACTstep development system- FPGA Implementation tools- XOelay static timing analyzer- Hardware debugger

Synopsys VSS simulator

VirtualChips PCI model

Slide #50

Recommended ResourcesAvailable Literature

Slide #51

Recommended ResourcesAvailable Literature· Books

PCI System Architectureby Tom Shanley and Don Anderaon

Mlndshara Pre••2202 Buttercup Dr.Rlchard.on, TX 75082Tol: 214-231·2216

PCI Hardware and Software Architecture & peslgnby Edward Solari and Georgo WIII.o

Annabook.11646 Bornardo Cantar Dr., Sullo 110San Diego, CATol: 800-462·1042

Slide #52

Recommended ResourcesWeb Sites

Xlllnx publications- loglCore PCl M..ter ond S1avo Use(s Guide- loglCore PCllntorface Protocol Compliance Checklist- XC4000 FPGA Sertos Product Specification- Implementing FIFOsln XC4000E Application Noto

PCI -SIG publications- PCllocal Bus Specification- PCI Compliance Checklist- PCI Systom Doslgn Guido

PCI·SIGP.O. Box 14070

Por1land, OR 97124Tel: 1·800-433-51n

Xlllnx WebLINX PCI pages:

LoglCore:http://www.xlllnx.comJloglcore/logicore.htm

General PCI:

http://www.xlllnx.comJapps/pcl.htm

PCI-SIG

http://pclslg.com

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Designinga PCI Target/Initiator inFPGAs - Prevailing Technology, Inc

Documents