Occasional Contributor
Super Contributor
@rdrr wrote:Please bear in mind that I have very little knowledge about FPGA and I will not even touch it, because I'm responsible of the Linux side of communication.
Hi,
I guess there's someone responsible for FPGA development in the project, so you should discuss with them possible options for RSU and application register interface.
On the FPGA side, you'll surely use MAX 10 dual configuration IP and on-chip flash IP. Everything else depends on FPGA design requirements and preferred processor. Why are you biased towards I2C interface? Because it's used in the RSU reference design or has it already been chosen for processor to FPGA interface of your application? I would rather expect basic UART interface which is natively supported by Linux OS.
I assume that you don't yet use NIOS softprocessor in your application? If so, it's rather odd to implement itfor the sole purpose of performing RSU. Better implement a small low level interface to flash and dual configuration IP in HDL.
There's no specific protocol for RSU, just need to perform a few functions provided by the IP through processor interface. You can e.g. implement a few control registers and access them through processor interface.
Occasional ContributorHi, thanks for the response.
Yes, there is an FPGA team responsible for FPGA development and certainly, they will work on this, however, I'm just curious how this could look like, as we are in the very early stage of the project and somebody just brought this idea up at the meeting and it took my attention as I will probably be responsible for handling this CPU-FPGA communication from the processor side.
I'm not sure why I2C was chosen to handle the communication - in my honest opinion, I2C is not the best choice to handle bulk transfers like bitstream upload, however, I believe there is a solid rationale behind this decision.
Anyway, I'm still not sure how this should work. Let's say that in my contrived scenario where I want to control FPGA as well as update its configuration, I would just create a driver that uses an FPGA reg map like eg. this:
FPGA Register Map: ------------------------------------- | Register Name | Address | ------------------------------------- | CONTROL_REG | 0x00 | | STATUS_REG | 0x01 | | FIRMWARE_VERSION_REG | 0x02 | | ... | ... | -------------------------------------
and then:
- if I want to change the control value then I trigger the write operation over I2C and send: register offset followed by a designed value
- if I want to read the status register then I trigger the read operation over I2C and send: the register that I want to read
How should the update procedure be designed then?
Should I e.g. send a value to a control register that would indicate that I want to perform an update procedure? And then just send a bitstream blob over the interface?
How should I indicate that I finished sending a blob and I'm getting back to a "normal", operational state?
Perhaps there should be a register in FPGA where I could write bitstream size, and then FPGA would know when to stop interpreting data on the bus as bitstream blob?
How should the partial (faulty) update be designed? Like in the scenario that something went wrong and the processor was not able to send the whole blob? How should I inform the FPGA that we're starting to send an update bitstream once again?
