FPGA+RT Architecture and Design Decisions

[David-Baratheon]

Hi guys.

I have a question specifically relating to the sbRIO-9651 that I am working on, but would also be interested in more general answers if all RT and FPGA devices work the same.

My first question relates to the architecture of the hardware. Is the RT and FPGA in parallel or in series? So does the signal go Windows PC -> RT -> FPGA or would it go PC->RT and PC ->FPGA?

My second question is, what is the purpose of having both RT and FPGA, and how do you decide which one you wish to use? If you wish to use both, why is that?

[Norbert_B]

All three run in parallel.

Win: User-friendly, nice graphics, huge file sizes possible, very robust against weird implementation

RT: Deterministic (if implemented properly!), in many cases (slightly) faster than Win, still "slow", more robust than Win (if implemented properly!), strict implementation rules (or you give up deterministm and robustness!)

FPGA: Deterministic, way faster than RT, limited datatypes and size of application, very strict implementation rules (or easily busting FGPA size or getting compilation errors)

Selecting an sbRIO usually is done because developer wants to use both FPGA and RT. Did you choose sbRIO on your own? Or was it the decision of someone else?

Norbert

[David-Baratheon]

It just happened to be what we had lying around at the office. For now this is just a project for personal development.

We have some projects coming up that involve NI embedded systems though so if you think sbRIO is a bad choice then that would certainly be useful knowledge.

I have learned a bit about the detailed design and implementation, but still don't know too much about the top level stuff like why to choose certain embedded devices, how the architecture is structured and why I would make certain design decisions like which hardware to use and whether to use RT or FPGA etc.

So what are the sorts of situations that you might decide to use FPGA, or RT? Are there situations you would use both in tandem?

[Norbert_B]

I think you should look into this invehicle datalogger reference architecture.

While it is outdated and some things are done slightly different nowadays, it still has one of the best documentation about the question you have (at least to my knowledge). So please read through the documents attached to this architecture.

I hope this can answer your question, otherwise, please post your (new) question here!

Norbert

[nathand]

---

David-Baratheon wrote:

So what are the sorts of situations that you might decide to use FPGA, or RT? Are there situations you would use both in tandem?

---

I can give you a couple of examples from my work, which have almost always used both the RT and FPGA in parallel:

- control of a small-scale chemical reactor. We used a cRIO for this, because we wanted a small, integrated, rugged package. The FPGA acted as a flexible IO unit. It generated PWM signals that drove injectors to control the amount of fuel and other reactants entering the system, acquired analog inputs (temperatures, flow rates), ran some high-speed PID loops, and communicated with CAN devices. An earlier version of the same control system used a PXI chassis and dedicated cards for CAN, counters, thermocouples etc with no FPGA, but the cRIO was much smaller. The RT layer handled higher-level control. For example, we had a complicated startup sequence where certain parts of the reactor would start up once other parts had hit their target temperatures. That sort of logic is difficult to squeeze onto an FPGA, and doesn't need to run at FPGA loop rates. Also, we modified that sequence frequently, and waiting for an FPGA recompile each time would have been time-consuming. The RT also handled communication with a separate PC application that displayed operating conditions to the user, and allowed the user to make certain adjustments. We wanted the control running on RT, rather than a Windows sytem, for reliability.

- control of an inkjet printhead, using a single-board RIO. The FPGA read an encoder signal, loaded patterns to the inkjet head, and triggered it to fire based on the encoder count. This needed to be high-speed and accurate every time. The RT code provided a TCP interface so that a client could download an image (in one of several formats), and it transferred that image to the FPGA through a DMA FIFO. In this project, unlike the one described above, nearly all the logic was in the FPGA because of the tight timing requirements, and the RT code was minimal.