Hi Andreas,
I think something quite close to what you describe would be possible. After all, once you have the interface, you have a set of registers, and so you can develop VHDL code to interact with them. Adding a sub-module to the AXI peripheral which contains only the "do stuff", *might* be helpful in abstracting out the bus interactions.
So I'm going to veer off the FuseSOC questions for a moment (will reply to that separately), because this is worth trying to get some clarity on before going too far. I don't have a clear idea of what a beginner project might look like, and what interfaces it should have, and that is worth establishing.
If we want to make it as easy as possible then I think this should mean someone should be able to take what they know of classic FPGA projects (simple combinatorial and sequential logic examples you'd find in a textbook or general VHDL/Verilog introduction), or, having no experience with FPGA, use this as a platform to go through these informative tutorials. Sort of as an alternative to a standalone FPGA board. Is this what you have in mind?
While there is no problem implementing any of these things in and of themselves, the question is how to make it cool / real for someone starting out. In particular, how does someone interact with it? I can think of two (not mutually exclusive) approaches here.
1) Real interfaces: You provide a daughter card which presents an interface like an eval board with buttons/LEDs/LCD, and so forth - and once the bitstream is loaded, you can interact with it that way. I use daughter card in the loosest sense of the term - rather than connecting directly to the Parallella, it may make more sense to make this a plugin module (cabled, for instance) to either the GPIO_PEC or the Porcupine. This keeps the module cheap. If they get a Porcupine, well this is more expensive, but versatile/reusable for their other projects. Or, since I gather these things already exist for other boards (Arduino shields, Beaglebone Capes, Papilio Wings, etc), it may be that providing adapters to some of these might enable people to interact more meaningfully with both their FPGA projects, and whatever other Linux apps they write also? This side of things doesn't require AXI at all.
Regardless of whether you do a daughter card / adapter, or simply provide the Porcupine, the Sandbox image just needs to route the GPIO pins to the sandbox interface within the FPGA rather than to the PS - and yes, we could just MUX this to remap as required.
2) Virtual interfaces: You could write an app/library which sits on the Arm side and monitors the registers - sort of providing the real world interface, and allowing an easy/interactive way to set bits, and watch bits change - replacing the buttons/LEDs, in effect. You could provide an internal UART so they can communicate with their module this way. So providing something like the above, but making it virtual. You could hide the registers (or some of them) entirely, and the Arm side provides an array of LEDs, and an array of BUTTONs - which are actually just mapped to bits in some of the reserved registers.
How you choose to expose them from there is an open question. But it might start with a python library which allows you to push buttons, and look at whether an LED is lit up. You can build a UI on top of this easily, available via a web interface, or HDMI, which lets you click the buttons and see the LEDs.
If you automate the build/copy/program cycle, the editor / UI could be presented side by side on a PC with WebPack installed. If the build server approach pans out (will discuss this in my next post), you could be doing these on the Parallella itself running as a desktop.
I will need to think more on this - and the more input from people with a better understanding of sandboxes, and the aspiring FPGA hacker the better.
We should also think about how easy it would be to tie this in with existing instructional examples. I am not sure that a similar sandbox type approach exists for FPGA - perhaps there is something we can learn there. But being able to send people to a list of examples they can work through might make things easier. However I suspect most material is "tainted" with aspects of the board/device itself, as well as having phyisical IO pints (so includes where you setup pins in constraints file, debounce button inputs, and likely describes how to use the tool itself rather than just focusing on the VHDL and going no further than the port of the Sandbox module) - and at that point they are not so helpful. If you're onto something new with this, then we'd need to work out how to source instructional examples.
I'd like to know if Hamster has any insights to offer here?
Regards,
Yani.