Embedded C

It seems of late all I'm doing at work is embedded C and back-end firmware. At the moment my aim is to get full direct memory access between the embedded Microblaze design and the data FIFOs on the FPGA's fabric logic.

So last time I mentioned we are using an embedded microprocessor on each of our experiment's 12 data acquisition boxes, each connected via Ethernet protocols. As with any computer, it is not all hardware, it is more about the software you write for that software, hence the bazzilion lines of embedded C that will be running on each box.

The above diagram treats the software issue in quite a simplistic manner, believe me things get a little more complex as we delve into them.

Firstly one cannot get large amounts of data from the fabric logic without needing to implement direct-memory access. Normally the CPU is used to set the source address, destination address and perform the moving of data in units of 1 instruction word at a time. Even for an embeddded 32bit RISC architecture the amount of data the FLITES data acquisition boxes handle would preclude this as the CPU would be saturated with repetitive data move transactions. This ultimatly would prevent the CPU from performing any other instruction. Direct memory access circumvents this by using the CPU to define a start address, end address, total data move transaction length, and of course destignation address. The CPU is then free to run other instructions while dedicated DMA hardware pipes the data from one memory location to another.

In the FLITES project the Ethernet standard seemed like the most approprate given the lengths and data rates required. Here we have Ethernet packet creation tasks, which includes the headers for an industry standard packet constrution, and the transmission of that packet. We also need to receive command registers, however luckily these are less common than experimental data packets allowing us to periodically poll the ethernet receive buffers.

Of course no instrument can be deemed scientific if you cannot change the parameters of your experiment. The chaps at Strathclyde for example would like to sweep modulation frequencies or adapt the phase of the system to target specific components in the recovered signal. To do this we have both dedicated firmware and software that is able to accept an updated operating frequency or operating phase and pass this to the front-end firmware signal acquisition chain. To say our system's register map is large is an understatement.

I'll keep you posted with more embedded details as the system progresses.