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.Statistics: Posted by yanidubin — Sat Oct 04, 2014 12:41 pm
]]>