Parallella Community

Andreas made an excellent point about lowering bar to FPGA development.

So I created this thread to flesh out this idea. Please see his .

I am not aware of any fully functional open-source equivalent to the Xilinx tools - obviously that would be the ideal situation, and I believe the only way we will ever build the FPGA bitstream on the Parallella itself. So I'm limiting this to Xilinx. As you may know, under the hood, the Xilinx tools are CLI based. From Xilinx, here is an and here is the . From the tcl console in the Xilinx tools, we can determine what commands are being run. We will be able to extract the process and all parameters used for the Parallella platform.

So, some scripts are called for:
1. A build script which goes off and calls the required tools - we can outdo the UI here by actually rebuilding everything (if needed), I am sick of rebuilds excluding my XPS changes and wondering why my changes are having no effect. This would manage synthesis/implementation/bitstream generation
2. Then there is the matter of making the output usable - so parsing tool output for errors directly, or finding/parsing the logfile the tool generates.

I will search around because I'm sure many people will be doing this already. I expect this may still require downloading/installing the full WebPack (all 18G of it - yuck! My Vivado install is a mere 6G, perhaps they are improving?). Unless there is some sort of lightweight offering, I expect there would be legal issues with chopping it up for redistribution (if such a thing were possible).

As for providing a starting point, the output of (which provides an AXI4Lite peripheral), is what I have then used to go and build up a simple ALU. Beyond that point, the XPS is not needed, and all I do is use planAhead as an overblown editor and build system.

All that is really needed is an editor, some build scripts, and the build environment (CLI tools, probably complete WebPack).

In order to facilitate using different starting projects (7010, 7020, 16-core, 64-core, HDMI, headless), it would be tempting to provide the following:
* provide the AXI IP Core (pre-generated - same between 7010 and 7020 parts I assume)
* provide diffs to apply to the system.mhs to enable M_AXI_GP0 (for headless boards), and create an interconnect interfacing this to the new IP Core, and adding an instance of this core. system.xmp also gets a patch which includes the locked down address range, and path to edk repo. We may need as many as one diff per base project - it really depends on differences in the Processing System part of the FPGA design.
* provide the scripts and instructions on setting up WebPack

Then for Tutorial 2 which will use full AXI4, all that is needed is a PCore for new peripheral, and a different patch set (Processing System set up a little differently for the different AXI interface)

Then the user edits the VHDL/Verilog using editor of choice, reruns the build script, gets presented with errors/success, copies bitstream to parallella, and that is one part of the sandbox.

Copying the bitstream to the Parallella and loading it, then running the test script can be driven from the build script (and I want to do this anyway). I am close to having a python test script for one of my projects, and the copy / configure / run test makes for needless repetition.

Because these interfaces can be interacted with using /dev/mem, I think we should provide:
* A fixed up version of the tool from the tutorial to poke/read the registers by address.
* An example python script (or even a library) to read/write registers by their index.

My interest stops there, but if someone wanted to take this further (too far), they might consider:
* A UI front end for HDMI/web to allow entering/reading values
* A customisable version of the above. For the ALU example, operand textboxes, instruction radio buttons, result textbox, accessing underlying mechanism via the UI framework.

One thing I have left out, because I am a hobby hacker and not an FPGA dev is simulation. And this doesn't really belong in a sandbox for the same reason.

But from the scripts perspective, if we made this part of the Parallella build tools, I wonder if simulation could be integrated into the scripts for those wanting the equivalent of unit tests? While I expect the UI is indispensible for visualising modules to ensure correct behaviour, anyone wanting to verify their various modules still work might benefit from CLI based running of simulation and comparison with required result (I'm assuming this exists).

Not sure if you are aware of FuseSoC, but it could make for an excellent build system for the Parallella FPGA platform:

https://github.com/olofk/fusesoc

It would be fantastic also if we had an AXI<->Wishbone bridge and via this could make use of OpenCores IP in Parallella FPGA systems.

Cheers,

Andrew

I wasn't aware of FuseSoC (ignoring the orpsoc checkout from 2011 I just stumbled over - must have planned on using it when I got my DE0-Dano).

I've found your DE0-Nano writeup, and as I have one in my drawer, I might have a play with the tool with that initially.

Looks like the first step will be making a Parallella project with it - anyone familiar with this tool already?

I've taken a quick look at FuseSOC, which became a rather long look. I think adding support for the Parallella won't be straight forward exactly.

More than just a case of setting up a new project, setting the correct target, and importing all the files.

Issues I think will need to be addressed are:
* It doesn't appear to deal with Global Includes at all. I'm still working through how to add this functionality. I haven't found any trace as of yet as to how the planAhead build passes these into the file. I'm not sure whether I'm just missing come extra required incantation, and can handle this by extending the invocation in fusesoc.

Actually, since the tool stages sources in a temporary folder anyway, adding a concept of global include to the system definition, and having it prepend `include directive for these to all files in the staging folder prior to building should be trivial.

* I don't think FuseSOC understands the platgen tool (for generating the Processing System) yet - so the tool itself may need some extension before we can get a complete build. I don't think they've added support for any SoC based Xilinx FPGA before.

I was going to generate a fork of FuseSOC and share what I'd done in case anyone wants to collaborate, or pick it up if I loose steam - however this would involve adding verilog files copied from parallella-hw into that fork.

I wanted to get an okay, and check there weren't going to be any licensing issues first. fusesoc itself is GPL3 - however I'd be adding the verilog files to fusesoc-cores, which has no LICENSE file. I looked in a few paralella-hw verilog files and saw they are GPL3 anyway - is this the case for all the verilog files for the headless build? If that were the case, and everything is GPL3, then am I right in assuming there are no issues here? Is adding parallella files (which might be hacked to make the tool work initially, before slowly working back to integrating with parallella-hw versions) to a fork of fusesoc-cores okay?

Thanks for that, all valid points.

All that is needing to go into the cores repo is two config files, and all our verilog files (plus the addition of processing system config). Telling fusesoc to use an alternate cores repo is trivial (~/.config/fusesoc/fusesoc.conf). So I'll make a separate repo for the parallella bits which borrows nothing from their repo.

Eventually, as you say, we should use the provider method to fetch from parallella-hw, and the patches directives to apply the project specific parts. At that point, the above repo should be simplified down to just the config files and patches.

I've identified an elegant solution to the global_include issue, and will make changes to fusesoc to support these.

Now to have it pull in and build the Processing System correctly, which will likely take a bit longer. There's a bit of a difference in how planAhead and FuseSOC drive the cli tools, and planAhead doesn't actually tell you every single command it runs - just the main ones. I think I'll get there eventually though.

Yes, the cores (rather than system) aspect of the tool I'm ignoring for now - but that should be a good way to pull in the HDMI core when we get to that.

I haven't thought too much about the best way (from an ease of use perspective) for pulling in the peripherals (AXI peripheral for instance) which the user will then modify to implement their project. Using a provides would seem the logical way to fetch a core you weren't modifting - but if editing locally, having it come directly from a file rather than via a repo seems best (so you don't have to commit for every build). Provides may well already allow this - but we can work that out later.

I want to evaluate the tool and ensure that is good before going down that path - but I think it is important to get plenty of input on what makes it easy.XI core and does a rebuild - probably wants to point to their own fork of the repo

yani,

Great post!

The fusesoc is certainly a powerful platform, but I am not sure it fits in with the concept of a beginner's sandbox? When I think of good sandbox, I think of a "hello world" examples with something like "insert code here". Once a base system is built and all the blocks are built, for beginners there would only be one entry point needed, a stub module instantiated in the design.

module my_sandbox(/*some memory type interface as you suggested*/)
/*insert code here*/
endmodule

Is this too limited?

btw, I agree with your point about the Xilinx tools. Downloading them is painful!! If it's completely scripted, then one could imagine setting up a server somewhere with an interface for accepting remote synthesis jobs.

Wondering if the license terms would allow us to generate bit streams for other people in some way? Unlikely, but I will take a look.

Andreas