IC configuration approach - Hardware vs. software

[jars121]

Hi all,

The design I'm working on incorporates both an SoC and an FPGA (Artix UltraScale+). The FPGA interfaces with several high-speed ICs (primarily ADCs), which offer parallel interfaces for reading data out of the IC. They also offer serial (SPI-compatible) interfaces for configuring the device. For example, output data rate, channel gain, decimation, etc. on the ADCs.

Take the AD7606C-16 ADC for example. It offers a 16-bit parallel interface for reading 16-bits of channel conversion data at a time, which is perfectly suited to an FPGA. Analog Device provide an HDL reference design for this exact purpose. However, Analog Devices provides a C driver for ADC configuration via the serial interface. This seems to be common practise for the Analog Devices ADCs; they don't seem to provide a similar reference for configuring their devices via serial link in HDL.

With that said, I'm tossing up how best to go about interfacing with these devices. Ideally everything would be managed in HDL within the FPGA itself, but given they provide the configuration driver in C code suggests that perhaps this isn't the 'usual' approach?

So, as far as I see it, these are my options:

• Do it all in HDL, write the serial logic (using an off-the-shelf SPI IP) myself and stop whining.
• Implement a MicroBlaze softcore with SPI interfaces within the FPGA and use the provided C code drivers.
• Use the SoC to configure all the FPGA-interfacing ICs and use the provided C code drivers.

I'd prefer to use option one, and don't think it would be that difficult given that I've got a C driver to use as reference.

What have others done in this scenario?

[ataradov]

Do you really need an IP for SPI? It is a trivial shift register.

If you don't need the CPU for anything else, then do it in the hardware.

[SiliconWizard]

Using a soft core just to implement SPI looks pretty uh, odd.
(I would understand if you're like a software guy, many tend to throw as many layers and dependencies as they can to even just kill a fly, these days, but if you're a hardware guy, just don't do that. )

[jars121]

Do you really need an IP for SPI? It is a trivial shift register.

If you don't need the CPU for anything else, then do it in the hardware.

I don't need the CPU for anything else, it would just be to make use of the available C drivers.

Using a soft core just to implement SPI looks pretty uh, odd.
(I would understand if you're like a software guy, many tend to throw as many layers and dependencies as they can to even just kill a fly, these days, but if you're a hardware guy, just don't do that. )

You've caught me. I am a software guy, trying to make the leap into the hardware space. I suppose an SPI shift register is as easy as they come, so I should just commit to it.

[ataradov]

From a very quick look at the datasheet, it appears that there is a way to configure the registers in parallel mode using typical SRAM-like RD/WR/CS signals.

Plus this device has trivial number of registers, I don't understand what do you need the C code for. It would be more work to read it compared to just reading the datasheet and configuring the values manually.

This is one of the easiest things you will have to do in FPGA world, you need to get used to making stuff like this in the hardware if you want to work with FPGAs.

[jars121]

From a very quick look at the datasheet, it appears that there is a way to configure the registers in parallel mode using typical SRAM-like RD/WR/CS signals.

Plus this device has trivial number of registers, I don't understand what do you need the C code for. It would be more work to read it compared to just reading the datasheet and configuring the values manually.

This is one of the easiest things you will have to do in FPGA world, you need to get used to making stuff like this in the hardware if you want to work with FPGAs.

I can totally appreciate that.

I have 5+ different ICs to configure, all of which have provided C drivers, so configuring the entire board with software via a CPU would be trivial. However, I understand that the hardware method is the proper way to approach this, and will be a good learning opportunity as well.

[ataradov]

I think you are overestimating how trivial it is. Setting up the CPU and corresponding buses and peripherals and then porting that C code would take a chunk of time and effort. And all that for code that would run once? It is 100% not worth it.

[jars121]

I think you are overestimating how trivial it is. Setting up the CPU and corresponding buses and peripherals and then porting that C code would take a chunk of time and effort. And all that for code that would run once? It is 100% not worth it.

Sorry, I meant trivial assuming the CPU was already available (as in the case where configuration was handled by the SoC).

Configuration of the devices can occur during runtime (as well as at startup), but I take your point.

[glenenglish]

Option 3.
You are going to have a micro anyway (Microblaze)  (as Artix Ultrascale+ is a Fabric only device - no SOC on Artix Ultrascale+.)

SPI ports are cheap on the microblaze (AXI)
but you dont even need to do that, just bit bang it, its only for configuration...

and if you have multiple ADCs, just run different CS to them all IF you need to talk to them individually. suggest single reset so al the state machines reset sim.

make sure you put some R in series with the SPI ctl lines, otherwise you'll inject a current pulse into the ADC ground / leadframe every time there is a data line edge....

Glen
(Xilinx Alliance Partner)

[jars121]

Thanks Glen, I appreciate your input as always!

The SoC is an external processor in this case, which interfaces with the Artix via PCIe. I would only be implementing Microblaze for the purpose of using the C drivers via SPI. If I instead configure the devices in hardware (as suggested above), I won't need the Microblaze at all.

I've had a bit more of a read through some of the datasheets, and as Alex pointed out, it looks to be relatively simple to configure the devices using their parallel interfaces, which means I don't have to worry about the separate serial link. I can read conversion data and write configuration data using the one interface in hardware.

[pcprogrammer]

Like others advised, read the datasheets.

The AD7606C-16 does not allow both interfaces to be used simultaneously.



You have to select one via the !par/sel pin. For this IC you have to see if the default options are suited for your case. If so no configuration is needed and you can use the hardware mode. Other wise the software mode is needed. When you plan to use it with a parallel connection to the FPGA, also use that one for the configuration.

For your other IC's try to find in the datasheets how they are configured if needed, and what the register settings need to be. Throw the C examples provided by the manufacturers out of the window, and trust on your own instincts if they are up to the job of course.

[jars121]

I was aware of needing to switch between the two interfaces, that was going to be accommodated in the solution if I went down the serial configuration path

Unfortunately the default options aren't suitable, nor are the options available by setting the configuration pins in 'hardware' mode.

As such, software mode is required to set the registers, and I'm happy to proceed with doing so via the parallel interface

[laugensalm]

It's almost never a bad idea to drop a compact CPU even into the smallest design - as long as you have the resources. My favourite is the ZPU architecture, due to its optimum code density, little LUT usage and GCC support. The reasons for a CPU are manifold, one of them the fact that one can connect via GDB and a JTAG proxy to download code and debug during development or simply manipulate peripheral registers.
With increasing complexity where data needs to be moved around or streamed, this pays off in terms of debug time and even FPGA resources.
But, you might want to rely on an existing setup. I've rolled my own many years ago anyway, since I couldn't find a portable and multi target suitable solution in VHDL (opensource result: https://github.com/hackfin/MaSoCist). Linux folks will recognize the kconfig flavour, just this time for a SoC instead of a kernel, plus the configureable usual suspect cores (SPI, UART, etc.). The entire SoC spins as GHDL simulation in the accompanying Docker container, so it's easy to start from there - for folks with SW background at least. What's missing is the platform specific stuff (JTAG primitives, etc.) and all hardware target specifics, so I would not endorse to use this for your final implementation, but it might help creating a dry dock prototype which you can integrate in your existing setup.
This is also to avoid opensource issues related to the GHDL simulator when distributing simulations.

[Someone]

It's almost never a bad idea to drop a compact CPU even into the smallest design - as long as you have the resources.

The OP says this is a PCIe peripheral, there is a heavy CPU system at the other end of the bus so little reason to put an expensive and time consuming softcore in as well. With so much address space available simple peripherals driven by the host are an obvious solution.

[xvr]

You can feed C driver(s) to HLS in Vivado and get pure RTL implementation of driver.
On the other hand, if all you have to do is to write sequence of registers to set of external IC you can implement all of this in one RTL sequensor, that will take this series from dedicated BRAM and spread it over all required IC. In this approach you can easily tune initialization series - they will be only BRAM contents, no RTL modifications will be needed.

[asmi]

CPU cores are actually quite often used inside some components where most people don't really expect and considered them "pure hardware". For example, most DDR3+ memory controllers contain a CPU core to handle initialization and read/write leveling, also most "hard" DMA controllers contain a CPU core to orchestrate DMA "Data Mover" hardware modules. So there is nothing inherently wrong with using softcore. It's always a balancing act.

[ejeffrey]

That's because the internal configuration process is often fairly even for a "dumb" device like dram.  If you have to do anything that looks like calibration or self test, a small processor core makes tons of sense.  If you just need to write a fixed set of register settings to a SPI configuration interface of an ADC, a simple shift register is going to be far less work and have many fewer opportunities for bugs to creep in.

It's great that you can easily instance soft CPUs.  But even if there are tools to help out, there are tons more steps and connections to make for even the simplest CPU.

And pretty much the only reason to use a SPI IP is if you need to talk to it from a CPU, since the IPs typically have a register interface with already working drivers.  If you are controlling SPI directly from RTL, the IP register interface will just get in your way.

[ataradov]

Something like PicoBlaze  could be a compromise for the cases where hard-coding logic gets hard, but using full blown MCU is an overkill. It is essentially a lightweight programmable state machine, whichis easy enough to instantiate and use.

[asmi]

Minimal configurations of Microblaze and Microblaze V MCUs don't really take that much resources, from my memory it's about 700 LUTs/400 FFs and a couple of BRAMs (which you can pre-program with your application code), so the crossover point at which pure hardware solution will actually take more resources than a softcore is not as far as many think.

[SiliconWizard]

Well this ADC (like most ADCs) just have a few config registers and if your configuration is fixed in your system, writing a simple state machine that will write a hard-coded config to all registers is very straightforward in HDL.
If you need something more elaborate, with configuration that could change dynamically, maybe a soft core could be justified.
OTOH, unless the direct implementation in HDL was very tough and convoluted, using a soft core + firmware for this will add system complexity and new sources of bugs.
Your call.

[pcprogrammer]

About the ADC and the digital interface, I think that selecting between serial and parallel can only be done on power up or with a full reset, so no on the fly switching between the two.

See the section about reset functionality on page 32 of the datasheet.

[jars121]

Well this ADC (like most ADCs) just have a few config registers and if your configuration is fixed in your system, writing a simple state machine that will write a hard-coded config to all registers is very straightforward in HDL.
If you need something more elaborate, with configuration that could change dynamically, maybe a soft core could be justified.
OTOH, unless the direct implementation in HDL was very tough and convoluted, using a soft core + firmware for this will add system complexity and new sources of bugs.
Your call.

Configuration will be changing dynamically, which is another reason I initially considered a software approach. However, for the reasons listed above, and pcprogrammer's datasheet reference below, I still think it's worth pursuing a HDL solution over the parallel interface.

About the ADC and the digital interface, I think that selecting between serial and parallel can only be done on power up or with a full reset, so no on the fly switching between the two.

See the section about reset functionality on page 32 of the datasheet.

Thanks for pointing that out. I think this again points to a parallel-only solution being preferred.

[PCB.Wiz]

...
So, as far as I see it, these are my options:

• Do it all in HDL, write the serial logic (using an off-the-shelf SPI IP) myself and stop whining.
• Implement a MicroBlaze softcore with SPI interfaces within the FPGA and use the provided C code drivers.

There is an option between 1 and 2, I see someone has done a Pi PICO PIO in HDL, but I could not find a LUT count.
That gives a tiny core that can manage delays and loading and simply looping.

Or you may be able to do a simple State machine ROM table copy, with upper bit tags for Loop count and delay settings.
That allows init code changes by simple change of the table contents.

[SiliconWizard]

Well this ADC (like most ADCs) just have a few config registers and if your configuration is fixed in your system, writing a simple state machine that will write a hard-coded config to all registers is very straightforward in HDL.
If you need something more elaborate, with configuration that could change dynamically, maybe a soft core could be justified.
OTOH, unless the direct implementation in HDL was very tough and convoluted, using a soft core + firmware for this will add system complexity and new sources of bugs.
Your call.

Configuration will be changing dynamically, which is another reason I initially considered a software approach. However, for the reasons listed above, and pcprogrammer's datasheet reference below, I still think it's worth pursuing a HDL solution over the parallel interface.

Yes. You can't use both interfaces after a reset, so it's one or the other. So if you need to use the parallel interface to stream ADC samples, then you'll have to use the parallel interface for configuration.
But that should still not be too hard to implement in HDL even if changes dynamically. Just a few FSMs.