Using the cRio FPGA

[ferret_guy]

can you use the FPGA on the crio to do things? or is it used by some other part of the progam?

[EricH]

If I recall correctly, the FPGA has been off-limits for some time. I don't remember if that restriction was eased for 2012 or not. I know it's used by something for doing something, but I'm not a programmer, so I'm not sure what.

[Kevin Selavko]

What were you planning on using it for?

[Alan Anderson]

The FPGA is responsible for all the analog and digital I/O from the cRIO. It implements the safety features that shut down the robot actuators when the robot is disabled. I wouldn't expect that it'll ever be opened up for team modifications.

[apalrd]

The FPGA does all of the following:

-Creates PWM pulses
-Signals digital outputs, including relays, the RSL, the disable circuit, and the solenoids.
-Reads all inputs raw, including analog, digital, etc.
-Handles I2C and SPI on the digital sidecar
-Handles 4 quadrature encoders
-Handles 8 counters - These do things like 1x or 2x decoded quadrature encoders, single wire encoders, PWM inputs, and gear tooth sensors.
-Manages interrupt timers for digital inputs if required


An FPGA is a very very powerful piece of hardware. It allows you to do a lot of straightforward math very very fast, as everything happens in parallel. For example, I know a guy who programmed an FPGA to generate Mandelbrots, and his FPGA was able to generate 72-bit precision Mandelbrots in approximately three orders of magnitude fewer clock cycles than his 2ghz Pentium M processor (which was running at 32-bit precision). I guess you'd say that, while modern computers are increasing the clock speed to perform more tasks in a fixed amount of time with a single operation processor, FPGA's are increasing the number of operations they do at one time with a comparatively slow clock speed.

If it were available to teams, there are many concerns relating to safety with the disable circuit. While I would personally like to be able to use the FPGA, many people don't think there would be enough use to justify the work of opening it up, including supporting everyone who attempts to use it even if it's out of their expertise.

[Greg McKaskle]

Adding in ...

The executing FPGA is a circuit constructed using a special form of a LabVIEW diagram. The diagram is compiled into VHDL, and then compiled into a bit mask image.

The FPGA sits between the PPC and the modular backplane. All I/O requests on the backplane go through it or originate from it. The FPGA synthesizes as many registers as specified, and the registers hold setpoints and outputs that can be peeked and poked by the C or LV code running on the PPC.

The FPGA can be imaged in a few seconds, and in fact is imaged several times during boot up. The first one reads in all of the calibration values stored in the modules and stores them in RAM. The second no longer needs the circuitry to access those values, and therefore has room for more functionality.

So, what does the second FPGA image do? For analog, it clocks the module values into registers or into a DMA buffer. It can average, oversample, and level trigger based on the value. It implements a scan list to allow for different scan rates on different channels in the module.

For digital, it determines whether a given line should be an in or out. For ins, it can store them in registers, DMA, it can trigger, count, and quad decode them. For outs, it produces PWMs and pulses of various forms.

The FPGA has a crossbar that gates all outputs and that is controlled by a watchdog counter that must be fed in order to keep the gate open. It can also raise interrupts on the PPC.

The FPGA does could do floating point math, but it would take lots of gates, so it uses integers or fixed point numbers everywhere instead. The PPC then scales then scales inputs and outputs to get them to floats. The PPC runs at 40MHz, and the coolest part is that it is a circuit controlled by an oscillator. It is very, very deterministic. Combine this with the one hundred or so different type of modules available, and that is why the RIO products that include cRIO can be used for so many tasks in industry and research.

The FPGA has changed a bit year-to-year, but only for bug fixes and to support the 4-slot chassis. At this point FIRST could change it to support new measurements or control, but it isn't possible for teams to change it and still ensure that the safety features are present and working. Imagine that inspection checklist! There are features underway which allow for templating and partial reconfiguration which may allow it to be opened in future years. If a team has an offseason project, I'm pretty sure you could acquire the tools to do FPGA programming.

Greg McKaskle

[Michael Hill]

There's nothing that's stopping you from using your own FPGA on a separate circuit board. Since you can connect to the digital sidecar or cRIO with SPI or I2C, it should be possible.

[F22Rapture]

Originally Posted by Michael Hill

There's nothing that's stopping you from using your own FPGA on a separate circuit board. Since you can connect to the digital sidecar or cRIO with SPI or I2C, it should be possible.

You can during off-season, but for the competition:

R52

Robots must be controlled via one programmable National Instruments cRIO (Part # cRIO-FRC or cRIO-FRCII) with image version FRC_2012_v43. Other controllers shall not be used

[BigJ]

Originally Posted by F22Rapture

You can during off-season, but for the competition:

R52

I think he was referring to using your own FPGA as a custom circuit, I might be wrong though.

[Michael Hill]

Originally Posted by F22Rapture

You can during off-season, but for the competition:

R52

You can make the argument that an FPGA isn't a controller, but at any rate, you don't necessarily have to use it for control. It could be used in other ways.