Porting FuseSOC to the Parallella

[yanidubin]

I am bringing the discussion on porting FuseSOC/OrpSOC to the Parallella into its own thread. The discussion began .

I'm not working on this all that actively, and may put it down for some time. So if anyone else is interested in picking this up (or just trying it out), I wanted to put all my comments about challenges and progress in one place. Plus if any discussion springs up around this, I wanted to separate it from the Sandbox idea (which this may be a vehicle for, if it eventuates).

[yanidubin]

So I picked this up again and progressed things to the point I can start from an empty build folder, invoke FuseSOC, and get a parallella.bit file. I haven't been brave enough to load it into my Parallella yet.

The level of hackery required was fairly high unfortunately. When I say hackery, I mean I'm feeding it a pair of tcl scripts to inject into the build script the tool itself generates. These run off and copy/exec other commands in the background. While I have modified the tool to understand new concepts, there is a line between giving it too many gruesome details - versus things that will be reusable (for other Zynq-based systems).

Some of will be be mitigated by extending FuseSOC - in particular teaching its ISE backend about platgen, and also generated src files (sources which get pulled into a build which were not copied from any source repo - but an intermediary process). That will eliminate one of the extra scripts.

But there is another side to this which I have really struggled with. When xtclsh invokes XST, it generates its own .xst script. It does not allow me to specify one. If I put a script in place first, it overwrites it. I can't seem to find any reference to this behaviour by searching / reading the manual - much less a way to inhibit it. So my workaround is to run a throw-away synthesis (with the auto-gen script), then do a real synthesis by invoking XST with a .xst script I pass in, before proceeding to Translate, map, par, and so forth. If xtclsh has run synthesis (even though I've since run another one over the top), it will not force this step to be repeated.

I can't help but think maybe one of the other methods of building from the CLI (such as XFLOW) might provide a workflow requiring less hackery than xtclsh. No reason I couldn't look into this, but I wanted to keep the changes to the FuseSOC tool itself minimal until I really know what I'm doing. So far I believe I have succeeded at this - there is just a bit of hackery in the form of custom scripts in parallella-cores (which is where they should be), and the changes to fusesoc are quite clean.

But I have something which works (at the cost of maybe 30-60s of extra synthesis run) - which is certainly a start, and I have made this available on github.

Next steps will be generating the .bit.bin, cleaning up the scripts a little, revising the layout of the compilation folders, and then looking at whether it is easy to pull in the sources from parallella-hw. Then I will look at pulling in the HDMI core - since this is what FuseSOC is built for!

Then it will be time to take a step back and work out how exactly fusesoc fits into the notion of projects. In the first instance, I want to build several configurations (with/without HDMI, 7010/7020), but none of these really constitutes a new system, as such - just a different configuration. But that is just the parallella-hw base projects. Ideally I would like to build on top of this, so develop a project which adds some new peripheral, and then be able to fairly easily select what project I wish to build, and have it built for any/all of the configurations.

Also, I might look at overhauling the backend and using something other than xtclsh.

The repositories are at:

(refer to this README.md first)

At present, a fusesoc build parallella will build the parallella_7020_headless project. Again, it has not been proven on target.

[yanidubin]

Now tested on target - the output loads, and I can still communicate with the Epiphany.

Instructions on building this are now available . That is the list of instructions / current progress which I will try to keep up to date. Once things settle down, a README in the repo will presumably suffice.

If anyone is familiar with bitstream formats / deltas between bitstreams, there are some open questions at the end of that post. This might be useful when it comes time to validate the build output against the likes of planAhead (if such a thing is possible).

[yanidubin]

We now fetch all files from parallella-hw. The only files in parallella-cores besised the fusesoc config are a custom .xst script, and two additional .tcl scripts, injected into the xtclsh build.

30/37 files were simple - we use the core provides section as it was designed to be used.

However I ran into limitations with the 7 system files, so had to implement a bit of a hack to get by for now.

The issue is twofold:
* There is a distinction between system/core - only system can have ISE specific files ([ise] section), but only core can have a [provider] section. But I want most of the system files to be provided - which was a no go.
* core also expects to have all files provided, or no files provided - but not both. Because I have some scripts of my own in parallella-core which are part of system, there is a conflict there also.

So my hack was twofold:
* Core fetches system files from *core* provider.
* Fetching from provider also allows copying from the parallella-cores folder

The hack is not that great, but not hugely ugly either. It will never make it upstream, but it provides (pun intended) a way forward.

It does display 7 warnings at the beginning saying the system files are not found - but it still gets them okay, and the build succeeds. I expect it will be easy to resolve this.

Needs a bit of clean up, but time for bed - so I've checked in my changes to both repos.

[9600]

Very cool indeed

With regards hacking FuseSOC to support Parallella, architecture decisions and upstreaming, have you contacted the developers? I'm guessing that since there doesn't appear to be a FuseSOC list or group, that it would be the OpenRISC list.

Cheers,

Andrew

[yanidubin]

Yes, good point. Actually, Olof posted a on my blog post, and is keen to merge stuff back - which is great. So this is already in motion - we'll see how best to architect things so we can merge it back in. I have a little cleaning up to do first

[9600]

Nice The OpenRISC folks are great and super helpful.

Cheers,

Andrew

[Len]

Thanks, this discussion (with sandbox and the Blog posts) is giving me a lot of information to think about. I plan on getting the A/D and hopefully a couple of D/A outputs talking to the 16 cores and need to come up to speed on FPGA, AXI and all the neat stuff to enable making that work. I suspect eventually Vivado will be the way to go so we can use some of the canned designs for the Zync. For now I am working on understanding FPGA and the build process. Got my Porcupine a couple of days ago. Thanks again.