Go Down

Topic: Interface between micro and FPGA (Read 821 times) previous topic - next topic


Jul 28, 2018, 08:06 pm Last Edit: Jul 28, 2018, 08:17 pm by philippe_at_sysemb
Hi everybody

I read the document : www.arduino.cc/en/Tutorial/VidorHDL

and I think that interface between the FPGA and the microcontroller may become a problem very quickly.

Some of us are more interested in the software side and others by the FPGA.
And we can not for the moment imagine what will be developed on both sides, and the communications constraints that will be linked to it.

Since it is not possible to reprogram the FPGA IOs dynamically, it will be the microcontroller's job to adapt.

There is so much way to exchange information, that it seems to me dangerous to freeze meaning of all these signals too quickly

A communication using a define protocol and few HW lines (I2C/SPI) during boot could be a solution ??

Update : I just remembered that both programs were normally linked with downloading process. So perhaps not a so big problem.


Hi Philippe,
i think i understand you think the interface between FPGA and SAM is not yet defined and is left to the application.

while it's certainly true that you can implement whatever you want if you don't like what we did, there is a foundation we provide and is based on the jtag interface.

if you check this (https://github.com/vidor-libraries/VidorFPGA/tree/master/ip/JTAG_BRIDGE) you will see we implemented a jtag to avalon/wishbone interface.
with this interface along with the software on the sam side you can issue register writes and reads but we went past this in order to make things a bit more interesting and rather than implementing drivers for IP blocks on the ARM side we have a soft core running on the FPGA that is actually exposing a remote procedure call (RPC) interface so that you have fixed APIs on the arduino side and anything you like on the FPGA side.
the RPC interface works through a mailbox where SAM basically writes the number of the function to call along with its parameters and when FPGA is done it writes in the mailbox the return value. both sides have a pin to issue an interrupt to let the other party know there's a message.

bottom line is that on the SAM side you will see APIs that are mostly identical to the ones you are already familiar with (for example gfx is using the same APIs of adafruit library) and SAM will just post the call and wait for response, potentially being free of doing other stuff in the meantime (not right now as calls are blocking).

of course you're free to implement whatever other mechanism you prefer, eventually using the pins in common between FPGA and SAM but it would be much much better if you follow the path we outlined.


Hi Dario,

thanks a lot for the information.
I now understand better how the FPGA code is structured.

I find that the way you have implemented the interface is interesting to simplify the SAM side, even if you have to use a softcore to do that ( Do you use the NIOS II/e softcore ?).

For now and because it's my first arduino experience, I'm trying to understand how the libraries and code are designed.
I still don't succeed in making "VideoDrawLogo" work (Arduino IDE 1.8.5 & SAM beta board 1.6.22 & last github libraries) so I persevere  :)



Hi Philippe,
yes, we're currently using NIOS for the internal sw processing, however it could be any processor as we are trying to keep as much as possible agnostic and programming with high level abstractions.
what issues do you have with the logo sketch? are you having issues uploading code like others or anything else?



Will we be able to recompile/synthesize the FPGA project with the NIOS processor with the free version of Quartus?


quartus lite does not include a license for NIOS however you should be able to compile a time limited version with it.
we're working with intel to improve this but right now you need a quartus standard license to compile a full image.
note that using the web tool we're working on you won't need an intel license as we'll be taking care of that, so in any case you may want to wait before purchasing a license.

note finally that although our designs use a nios to implement drivers on the FPGA itself, using JTAG bridge you can directly map IP blocks registers and run drivers on the SAM side. it will be slower but still be feasible.


Dario,  really, you need a NIOS license to compile the "full" supported Arduino core?  Anyway you could change this decision now?  (before maybe the community makes it for you ? )

There really are quite a number of free soft-cores out there.  The OR1K, ZipCPU, picocpu, etc, etc, all open source.  If all you are doing is putting peripheral on the Wishbone bus and the NIOS is only a Wishbone Master, this really shouldn't be a problem.

But, I did really think that their was a "free" NIOS.....  I seemed to remember three varieties, one being the "free" one.

And I DO NOT do web editor-based programming, as "The Server is Currently Undergoing Maintenance" is the most common thing I see when I try to do my online stuff at 3-4am.



Hi Ken,
Yes, there's a free nios version and we're going to release the code based in that however right now, in order to improve performance, we're using the f variant which has cache and requires a license.be sure we'll release everything shortly but as i mentioned we first have to make sure everything is a bit more polished.

Go Up