LabVIEW FPGA Programming Best Practices

8/16/2019 LabVIEW FPGA Programming Best Practices

http://slidepdf.com/reader/full/labview-fpga-programming-best-practices 1/29

1ni.com



ni.com

LabVIEW FPG Programming Best Practices

Presented by:

Zach Hawkins, Software Developer, Averna

CLA, CPI



3ni.com

Agenda• About Averna• Things to Keep in Mind• Structure

• Project Organization, Reuse and Portability• Style

• Naming Conventions and Designs• No Pink in a Case

• Standardization• Synchronization and Multi-FPGA Systems

• Summary• Q&A

3



Averna at a Glance

Custom test solutions, turnkey ATEand build-to-print services

Test Engineering Solutions

Special on-site technical or consultingexpertise for client project teams

Professional Services

Test-system and logistics supportfor far-flung operations

Global Support

SubstantialTestStandVisual BaAutomatio

Over 65architects

and in

IndustryGP

optics/and multi

4

Tools to accelerate your DOCSIS,RF and multimedia device testing

Test Instruments

300Employees

5Locations

30+R&D Staff

1250

CompletedProjects



Our Industries

AEROSPACE& DEFENSE

AUTOMOTIVE &TRANSPORTATION

CONSUMERELECTRONICS

LIFESCIENCES IN

Multi-industry expertise allows us to leverage best practices tohelp all customers improve product quality, get to market sooner,

and maximize ROI.

5



6ni.com

Things to Keep in Mind• If the code “fits” onto the FPGA, it fits!

• Know that ~70% means it’s full • You may need to optimize later if/when new features are added

• We don’t believe in complexity for the sake of complexity • We almost exclusively use the SCTL

• Some targets have IO nodes that will prevent using them inside SCTLs• NI has a course for this: “High Throughput LabVIEW FPGA”

• Remember that the determinism of hardware is your friendo Well, most of the time…

6



7ni.com

Structure: Project Organization• Setup for test-benching

• Two high-level testing categorieso On-chip testingo Off-chip testing

• Requirements• FPGA code• Host code• Shared code• Testing code

7



8ni.com

Structure: Project Organization• Reuse and portability

• How can we write FPGA code that can just be “dropped” into a newproject?

• What if the code has configuration items?o Use the Register Bus!

8



9ni.com

Style: Naming Conventions & Project Organization• “<Module>_FPGA”

• <Module>.vi• CreateResources.vi (Register Bus optional)• Registers.vi (Register Bus optional)

• “<Module>_Host” • API VIs

• “<Module>_Shared” • Resources.ctl (Register Bus optional)

• “FPGA_<Test/Module/Main>” • “Model_<Module/Algorithm>” • “Test_<TestName>”

9



10ni.com

Style: Designs – State Machine• Makes code easier to read and follow

• Have you ever tried to implement a state machine in pure logic? We have…

• Normally, we would put all the logic in the case structure• On an FPGA, additional enable chain logic is added to know which state is active

• Think of it more as a “State Controller” •

Only state control logic is necessary• Use handshaking to control logic that gets placed outside the case structure

• Remember that each new case can cause a new MUX to be added inthe HW implementation

10



11ni.com

Style: Designs – “State Controller”

11



12ni.com

Ever Seen Something Like This Before?

• Solved with the Register Bus!

12



13ni.com

Style: Designs – Register Bus• Controls and indicators get implemented as MMRAs

o Can become costly/cumbersome

• Configuration data will come down from the host on a single DMAchannel

• Think of it as a “Pipe” for both controls and indicators o

Put whatever you want on it!

13



14ni.com

Style: Before Using the Register Bus

14



15ni.com

Style: After Using the Register Bus

15



16ni.com

Style: Designs – Register Bus• Pros

• Saves space on large applications• Allows for better code modularity and portability

• Cons• A little more code to write• May be slower to read back large data sets or data larger than 32 bits

wideo Solved for special cases by adding additional DMA FIFOs

16



17ni.com

Style: Designs – Basic Elements• Don’t try to reinvent the wheel

• There are some basicoperations that NI provides

• If you install an instrumentdesign library…

17



18ni.com

Style: Designs – Counters• NI Decrement

• Useful for a terminal count

• NI Increment• Zero isn’t really a valid number, except on the first set

o But as programmers, we often like base-zero!

• A Different Increment• Supports reset and increment on the same cycle• Commands tell what to do on the next cycle

18



19ni.com

Style: Designs – NI Increment & Decrement

19



20ni.com

Style: Designs – A Different Increment

20



21ni.com

Style: Designs – Accessing Memory Items• Size of memory items: What gets implemented regardless of what you

set, etc.• 36 bit port width for BRAM• If you’re using a 64-bit data type, you’re using 2 BRAMs• Think about it as a box … how much stuff can you put in the box be

it’s full ?

• Use Base-2 addressing• Easier logic but it can be wasteful . . . or is it?

21



22ni.com

Style: No Pink in a Case• Using the case structure causes additional underlying logic that we

might not want (and don’t have control over) • Fanout

• Exceptions: Items without handshaking interfaces

• Memory writes

• Registers.vi of the Register Bus

22



23ni.com

Style: Avoid Costly/Unnecessary Operations• Many operations on FPGA that are “free”

• Example: Shift/scale by power of 2• Many other operations are dependent on the width of the data type

• Use only the bits that you need (FXP)• Unnecessarily large data types propagate through the chain

• How would the operation be performed with hardware logic?• No unnecessary math on the FPGA• Example of a width-dependent operation:

• Greater/less than or equal too Determinism normally allows you to simply use “equal to”!

23



24ni.com

Standardization: Synchronization• How will data flow in your system?

• How does the system respond when data isn’t flowing?

• What tells modules to “start”?

• How are modules reset?

24



25ni.com

Standardization: Feedback Nodes & Reset• Three options:

• Uninitialized

• Initialize on Compile or Load

• Initialize on First Call

o Additional code is added to return the register to the default value when aReset command is sent (RESET = FANOUT!)

25



26ni.com

Standardization: Multi-FPGA Systems• Do the FPGAs need to be synchronized?

• What kind of synchronization?• Data-driven synchronization

o P2P FIFOs

• Hardware synchronizationo Clockso Triggers

26



27ni.com

Summary• Set up the project with testing in mind

• Agree on standard naming conventions• Think of state machines as “state controllers”

• Use the Register Bus to modularize designs and preserve space

• Don’t reinvent the wheel!

•

Make accessing memory simple with Base-2 addressing• No pink in a case (with some exceptions)

• Develop to a standardized strategy for synchronization (or lack of!)

27



28ni.com

Thank You!

Questions?

Zach Hawkins

Software Developer, Averna

CLA, [email protected]

28

mailto:[email protected]

mailto:[email protected]



29ni.com

LabVIEW FPGA Programming Best Practices

Documents

Transcript of LabVIEW FPGA Programming Best Practices