mithro
commented
6 years ago Firstly, thanks for the huge amount of feedback!
It is going to take me a while to digest this, but there are a couple of quick things;
- We "inherited" the name platform/target from Migen/MiSoC -- there is a history about why boards ended up being a bad name.
- Florent uses the "single repo per board" approach, you can see for example the netv2-soc (for the old board) and the nexys_video-soc. I'll explain later why I think this bad idea.
I think it's a great idea to split the buildenv from the firmwares.
The problem now, though, is that I have to have files in the platform, target, and firmware directories specific to a given application, which isn't very git-friendly. Ideally, I'd have a toolchain that I can point to/sync with a single origin for upstream patches, and then a sub-dir with my design that I can likewise sync with a single origin.
First, I'd suggest maybe renaming "platform" to "board". While NeTV might be a "platform", really, the design files are board-specific, so as NeTV evolves as a "platform" really I think what is in these files are signal-to-pin mappings which are fundamentally board-specific (and if you want to add a twist, part-specific e.g. for platforms that take a single board design but offer different FPGA densities with a common footprint).
"Target" is okay as a name, but maybe "soc" or "application" is more descriptive. But "Target" at least has a history in cross-compilation as thing, but again the analogy isn't quite right in my mind.
Then I think creating a discipline where you have one repo for "board" and one for "application" is good, so you get in the habit of realizing that applications can be ported to different boards so long as the signal names are consistent despite pinout changes. It calls out the fact that boards and apps are in fact distinct, unlike the Vivado flow which tends to blend .UCF with verilog in an intimate fashion.
Then the question is how do application-specific firmware changes interact with the directory structure. I would advocate that there should be a core firmware that's unchanging, with callbacks that are searched for and included in the "application" directory. This allows a "kernel" of sort to be maintained while "drivers" stay specific to the applications.
One trouble point is if you have two boards but e.g. signal polarities are swapped between boards but you want to port an application between the two. In this case even a simple polarity swap would require a "new" application because the boards are just pin mappings. Two options to solve this are either to (1) add a record to the pinouts that include the option to flip polarities or (2) add some hook to the python files that describe a board that allow you to somehow glom a remapping layer between common application cores and different board variants.
(2) is more general and powerful but perhaps more annoying to deal with. (1) addresses the most immediate practical issue which is that signal polarities change all the time between boards, especially because the simplest level shifters are in fact inverters and you'd like to be able to just use an inverter to shift voltage levels and not burn an extra part to make a buffer instead simply because the build system can't handle a polarity inversion.