Dear Zrna team. I found your project while googling whether anybody was using FPAAs in the context of analog music synthesis. Your project seems like a match. I am thinking about ordering a ZRNA FPAA board, however, I would like to know whether it is possible to get more “low level” than what you describe in your quick start documents. In particular, I am thinking about applying evolutionary algorithms to the FPAA configuration, that is, randomly creating configurations, measuring the system’s output against a desired output given certain test parameters, then combining promising configurations etc. For this to work efficiently, I cannot work on the Python level, but need to generate AN231E04 (and test, recombine) configurations directly on the MC. So far it looks like your firmware is closed source, but maybe you could offer deeper level of access?
There are some specific technical, business and legal reasons for the firmware remaining closed source for right now that are out of my control.
Let’s talk about your specific requirements. We certainly can prepare a version of the toolchain that is accessible from another language. It might be possible to prepare a specific version of the firmware API that you can use directly in a way that still satisfies the constraints I mention above.
To clarify, all of the configuration generation happens directly on the MCU already. The Python layer (or any protocol buffer host) is just sending messages to the device. It’s possible to send the board API calls through its other serial interfaces. You could control the board from another embedded host for example. How low latency does your system need to be?
It sounds like in the ideal case you want to be able to deploy your own custom firmware on our hardware alongside the stock firmware. This is certainly technically possible, but there’s some complexity we’d need to work through.
Feel free to message me directly, and we can talk through some of the details.
Thank you, yes, both approaches seem to be valid options.
It is hard for me to give any latency requirements at the current stage, but the aim would be clearly to cut down any “high level” compilation time to zero, that is, ideally I would work with the bitstream going on to the FPAA directly - that is how I did it with Xilinx FPGAs many years ago. I wouldn’t even have to reverse engineer the FPAA configuration (creating legal issues), as long as the (quasi random) bitstream would actually reprogram all cells of the FPAA and not create any destructive states. Not sure how this approach fits into the legal and technical realities of the AN231E04?
Alternatively, as you say, I could work on the level of the MCU’s message API. I probably wouldn’t need need a higher level programming API for that, and I am sure the communication protocol is either public or can be inferred from the existing APIs. Approximately how long would a full reconfiguration of all FPAA cell currently take using the existing firmware, not counting any latency by the messaging system?
Another issue I am still pondering about is that currently available FPAAs, including the one used in ZRNA, seem extremely limited in comparison to their FPGA counterparts when it comes to cell/base function count. In the very end, FPGAs are built from analog components as well. Back in the day, I (ab)used a Xilinx XC6200 FPGA as an analog device, feeding and reading voltages between the logic levels. So generally, FPGAs would be seem to be a powerful (and cheaper) alternative, but I am unsure modern FPGAs would give me enough headroom to do that (due to their high digital bias).
A third possibility would be to place a couple of analog components on a board, and connect them by a state of the art integrated switch matrix. As you seem to be professionally interested in analog computing, I would be interested in your thoughts on those two alternatives to FPAAs.
If I recall correctly, the theoretical lower bound on reconfiguration latency for the AN231E04 is something like two
ACLK cycles, its master analog clock. That’s running at 16MHz. Then there is latency associated with actually getting the data across the SPI channel; it is clocked at 25Mhz.
The length of the configuration stream varies depending on how much of the chip needs to be reconfigured. The absolute worst case is about 2kb. How expensive it is to compute the configuration stream also depends on what you’re doing. Adjusting a gain is usually cheaper than adjusting a filter corner frequency for example. The MCU on the current hardware runs at 100Mhz.
The configuration engine in my firmware is currently at a level where it’s fast enough for most audio applications, but there’s room for optimization. We can bring it way down toward that ACLK + SPI limit if we get clever about optimizing the configuration calculation for the particular application.
More about the engine: it’s able to access and manipulate all of the chip resources. You’re not losing anything relative to other methods; the abstraction level is similar. The device is very different from an FPGA though. There’s sort of a fundamental level of abstraction enforced by the chip design. Going far below the level presented currently at the API level is not trivial with the current amount of information available.
By the way, the FPAA will simply reject an invalid configuration and assert an error flag. My understanding is that there isn’t any risk of destroying the chip just by sending a particular configuration, but I don’t have access to all of the internal details.
IFL genetic algorithms. They were a major focus of my college work and have been thinking about applying them to an FPAA the way they’ve been applied to FPGAs. I’m really excited about this project!