Developing an FPGA sandbox

[yanidubin]

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.

[yanidubin]

Regarding FuseSOC / building, FuseSOC won't be the sandbox, but the "make" backend. Granted, it provides more than is really needed here - but getting something like this in place for the Parallella could pay dividends for those working outside the sandbox who want to add cores, and such (especially if as Andrew has said, we get an AXI-Wishbone bridge). So I think it is a fair approach. If I really struggle to get it working, I'll fall back on make / my own tcl scripts. But I don't think I'm miles away from getting it working.

I wondered about a build server myself - once the build backend is working, this would certainly be possible technically. The results/errors will be presented much the same way (build transcript from localhost, or from build server). I can see hacking VHDL/Verilog on the Parallella itself, and firing a job off to your build server and getting a bitstream back 5 minutes later could be very cool. Or you could hack on your PC (then you have the option of building locally with WebPack installed, or using a server). Anyone who has their own build farm can of course set up the tools/jobs so that they can build on one machine, and hack on another.

I would have thought so long as you're not using any non-free licenses on the build server, this might be okay? (since you're not leaking ticket-clippable value to the masses) - but I haven't seen the licensing, and IANAL. Since a non-partitioned Xilinx build is essentially a clean (non-incremental) build, there is little slowdown in starting with a fresh checkout of each project each time, and cleaning once done.

One thing I keep forgetting is that some people use Windows. I think something fairly basic like make calling xtclsh, or a bat file calling xtclsh wouldn't be too bad, but I am not 100% sure about FuseSOC. Version 4 of the user guide states it should not be assumed it works under Windows - but I have disregarded this as being to do with gcc cross compiling/debugging, since FuseSOC does more than just FPGA - none of which is relevant here. FuseSOC is written in Python, and the bits we need are hopefully all available. There are just things like installing git in order to pull in the source code - unless we just bundle it in (the git tool, or the code)

Andrew - you asked about diffs - I had thought of this also, but discarded it since asking someone to edit a diff is a bit weird. But thinking more about it, taking a boilerplate file with users program and applying that to the repo is easy. Either this file comes verbatim from what the user has edited (but ensure the module interface hasn't been touched since that might break the build), or they don't even see that, and we slap a header/footer on the file before building it.

NOTE - investigation into FuseSOC has stalled for a bit now my Porcupine has arrived. I'll aim to archive what I have so far before I go back to work on Monday. I'll be providing on interfacing the Parallella to daughterboards and the like.

[9600]

[yanidubin]

I have made some progress on the FuseSOC port - this and further updates can be found in its own discussion .

That way this thread can be for continuing the discussion on the Sandbox idea - FuseSOC is just one possible behind-the-scenes build system it might use.

[cmcconnell]

Is all this current work going to be incompatible with future developments from Adapteva (i.e. Vivado support) ?

I'm a bit confused about the overall development plan.

[yanidubin]

Hi Colin,

I gather you are referring to the idea of using patches being an issue when the reference files change? Thanks for raising that - you are rightly confused, I clearly haven't given this aspect enough thought.

For general projects (ignoring the sandbox for now), which use FuseSOC as the build tool, then this will indeed be an issue where you apply patches to upstream sources (parallella-hw). However, I expect we can work with Adapteva to limit the effect of this, for instance through how they use branches / tags in the parallella-hw repo. For the ISE->Vivado move, I expect this would be done as a matter of course anyway, so people can move to the new tool at their leisure. Perhaps they won't use branches/tags, and simply different project folders? Either way would protect you from changes (you would not need to move to the new toolchain, your projects would continue to build, etc) - but when you were good and ready to pull in the changes, then yes, your patches would no longer be directly useable.

How unusable would they be? I don't have a clear picture of how uncleanly the patches would apply as a result of the changes to the underlying code to move to Vivado - and it will depend on which files you've actually patched. The more carried away you got, the more pain. Probably, I will provide a set of standard patches, in line with the sort of things I've been writing tutorials for (in fact, each will be come alongside an explanation of what we're changing and why) - so things like adding an AXI4Lite, andAXI4 peripheral, enabling/routing peripheral X. Where you've used these instead of rolling your own, you could expect those patches in parallella-cores would be maintained as it is updated for the new workflow (FuseSOC supporting Vivado will not work straight out of the box - we need to port it, unless some other project does it first) - so the patches for the Vivado branch would need to be regenerated accordingly.

To be honest, I think the problem exists to the same extent if you just clone and own the parallella-hw files in your projects. You would just build your projects with the old toolchain, unless you wanted to go rewrite it based on the new files (because you wanted to migrate for some specific reason). What will that process look like? You are going to be manually diffing your changes vs parallella-hw, and hoping the diff might apply cleanly without you manually hacking code. If it doesn't, you can't simply use your modified file - if it changed upstream, there was probably a good reason it had to. So you have, the exact same issue.

Coming back to the sandbox (keeping things as dead simple as possible for the hacker), things could become much more robust to change, depending how we do it. Say for example you are presented with a single file to write (maybe based on some example code). If this is a module which externally interfaces to an AXI4Lite peripheral (and possibly GPIO interface) - which you don't necessarily see/edit, just the ports you have available as interfaces to your code. Provided the code in the file itself doesn't become invalidated by toolchain changes, if the behind-the-scenes toolchain and nuts and bolts verilog code changes, your project will still work when you update the sandbox. If you used a build server, you'd be good to go. If you have your own installation, then yes, you would need to install Vivado of course, and switch to the Vivado branch of parallella-cores (which would in turn pull from the correct branch of parallella-hw and parallella-sandbox, if this is not just part of parallella-cores).

There are still questions around managing repository versions - for example, if we just pull from master HEAD, we're likely to break peoples workflow when a breaking change comes in we didn't anticipate. It might be we need to use a staging branch (or a staging fork of the repo) to carefully manage what comes in and when, from upstream, so it can be tested and won't break existing projects. This keeps parallella-cores/fusesoc in step with upstream (parallella-hw). I guess people's projects pull from a specific branch based on their toolchain? It might be as simple as using the [provider] section to fetch from a particular branch. And you migrate this when you migrate your project to use a new branch (because you are ready).

I'm not sure what shape other breaking upstream changes might take - any suggestions I should consider?

The thought occurs that maybe all you were asking is, "how do we prevent our cheese being moved?" That part is quite manageable - and has to be managed - so will be now that you've pointed it out. So that has been answered. Perhaps I over-answered your question to some extent with speculation of what migration might look like - in summary it would be when you were good and ready, and I don't think this approach makes you any more vulnerable in terms of upstream changes.

[cmcconnell]

Hi Yani,

You're crediting me with way more knowledge and understanding than I actually possess.

I've yet to do anything FPGA-related (just glanced at a few tutorials, etc.). I don't know what is involved in the transition from ISE to Vivado, other than that it is apparently fraught with difficulties. Given what Fred said here - viewtopic.php?f=51&t=1225&p=10811&hilit=vivado#p10259, I've been assuming that once the move has been made, compatibility with ISE will be gone. (If we want to add our own logic to an up-to-date Parallella design, we will need to use Vivado.)

It was more Adapteva's development plan than your own that I was referring to. If the switch to Vivado is imminent, then it would seem to make sense to wait for it before doing anything that would need to be re-done afterwards. That's certainly the view I was initially taking - I can keep myself busy for the time being, purely looking at the Epiphany side of things, and hopefully then only need to jump through one set of Xilinx hoops, as far as setting up and then learning to use their tools is concerned.

So the fact that you've not been advised to delay any of your activities - tutorials, FuseSOC build system, sandbox - suggests that Vivado is either still a long way away, or it's not such a major issue for the things you are working on as it is for the Parallella design as a whole.

And if a simplified build tool / sandbox can smooth the transition from ISE to Vivado, then I might not be able to resist diving in sooner than would otherwise be the case.

[yanidubin]

Hi Colin,

Okay, my bad - so getting familiar with the ISE UI might be ill advised just now, if Vivado is substantially different. I think the visual tutorials I've put up are fairly close to the level of detail for someone who has never driven the tool before (hopefully not far off it), and wants to learn just enough to build/modify a project. There are always the images to look at if the test is ambiguous, etc, so hopefully there won't be too much need to go looking too deep. But digging down into the simulator / schematic browsing tools (which are optional) might be premature if these will change with Vivado.

Based on the actual changes (diffing the source code), my changes are very small - it is (so far) entirely reconfiguration of the system, rather than actually implementing anything interesting in VHDL - just a framework to enable people to write their own projects, or maybe pull in their non-SoC type projects and interface them with the Arm. So I don't find the prospect of merging the code itself with updated sources a daunting prospect.

Although you make a valid point in that my visual tutorials will be obsolete (except for anyone who wants to remain on ISE). So at that point, I could make a Vivado version, or just stick with the a FuseSOC based workflow.

I wouldn't expect the Sandbox itself to be ready before Vivado - but we'll see how that progresses. But once I am happy with the build process, I will write a tutorial on building your own project from a base project, compiling with FuseSOC without using the UI tools at all (still need to be installed, but invoked from the command line). But this is limited to Linux for now - ideally someone else might contribute the Windross side of things.

[cmcconnell]

[aolofsson]

Colin,

Vivado is not hard to use, the lengthy transition time has to do with limited resources. (progress is being made...and there will be a delivery soon...sorry no date..)

If you want to play around with FPGA design using Vivado, you certainly don't need Adapteva and I would recommend moving ahead independently.

Andreas