New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor platform programming API to better support multiple programmers #428
Comments
Like where? Every board we support so far has a single primary way of programming it, so a single function is sufficient. |
Arty A7 can either use |
Right, I guess that's one of the few exceptions. In general, I'm not a fan of deduplicating code for the sake of it. Suppose we factored out some sort of interface through which we run OpenOCD. Now two things happen:
So there needs to be a more compelling reason to factor out programmer interfaces than "it saves around 5 lines of clear self-contained code per board on average". Right now, the public interface is the Note that this contrasts with our various |
Yes, and the current approach works perfectly fine for that. But I think it is also common for people to program via JTAG or something similar, am I wrong? This is where the current approach fails. When it comes to JTAG or another standard interface, there are multiple ways to do it. This approach would also benefit the current boards with onboard programmers, since you could unify and standardize the interface in one place. You wouldn't need to keep copying the same code between each platform declaration. It also allows you to standardize the interface. In the example above, you can pass |
I think this can be implemented without breaking the current code. We can keep |
This isn't actually specific to JTAG. There's (quite literally) an infinite amount of ways in which you might want to program a board. And nMigen already supports them all! What you do is you use the (public) interface It is not a goal of nMigen or nmigen-boards to support, even in theory, every conceivable way to program a board. The goal is to provide a smooth out of the box experience for people who are just using their board in the primary way the vendor suggests it to be used. Anything more? You have a perfectly good Python interpreter right there.
I consider the current approach an advantage. Take a look at this essay for a more in-depth exploration of my view here.
That doesn't require building a new abstraction. We can add something like nMigen's
That doesn't require building a new abstraction. People can do this just fine right now by doing the same thing |
I wouldn't say it's all that common. I believe most of the time most people use the built-in programmer (which usually uses JTAG, internally routed on the board, at least on the FPGAs that do have JTAG), since that's the most convenient approach. For the rest? Figuring out the right options to pass to the nMigen abstraction would probably take more time (and be more frustrating) than just invoking |
Sometimes there isn't a vendor-suggested (command-line) primary way. If we use E.g. Digilent suggests you use Vivado for Arty (is there a command line programmer for Arty?). I have Mercury use |
I didn't mean to say that
You can use iMPACT via CLI. Atlys does this. If we do support it for Arty, then iMPACT should probably be the default.
This is an interesting edge case. Because, clearly, nmigen-boards can only run a CLI application (or perhaps a batch mode GUI application, though this is already marginal), your programmer seems to be the only one that fits its restrictions. So we can use it in |
All that said, if there really is nothing that a typical nMigen user is likely to find usable, then of course we should leave it out. For example, |
I want to go back to the original issue and better explain my motivations. There are two issues. The main one is that there are several possible ways to configure a board, and nmigen only supports defining one. The other one is that the interface to pass arguments to the programmer is not standardized. I was not clear about this but the duplicated code issue was never about code optimization, it was about the interface, which diverges between boards. To me, having a standard interface for openocd for eg. would be a great step forward. I can use openocd with a wide range of programmers, I need to tell openocd how to do it. My proposal to abstract the programmer was so that we can standardize the interface. We could have openocd add an argument to the build/CLI to receive my config(s). Anyway, it is ultimately your call. I think the abstraction makes sense for standardizing the interface. Even if you decide against it, just being able to declare multiple programming interfaces would be a big big plus for me. |
Where does it currently diverge between boards? That sounds like a bug. |
Sorry, bad wording. I mean in a design sense, there is no enforcement, it is completely defined by the platform. |
So I don't actually see how that would work. I looked at the
Right, so that's one benefit of this change. I think it does not outweigh the drawbacks, which is the need to test every board affected by changes in common code. Going back to your earlier comment...
We can just decide on what to do here. For example, we can decide that on every board with multiple ways to program it,
I very specifically do not want to provide a way to pass arguments in general. For example, I do not want to provide a way to customize the openocd script. If you want to customize things beyond that, use your own programming code. |
I checked and most pass a config for the onboard programmer. We can make that the default config and allow the user to override it if they want to use a different programmer. We basically split the programmer and board specific stuff. The board specific definitions would always be included, but the programmer could be replaced.
Not really, because we don't need to move all devices to this new API. They can still keep their
We can control that in the board/interface definitions we provide, so we can limit it to only necessary configurations. In this case, openocd would only allow you to provide your own config. |
I don't really care about right now. As more time passes and more boards migrate to this common interface, changing this interface will become more and more hazardous and eventually it'll just be effectively frozen because we'll lose the ability to test every board affected by the change.
I don't see any reason to add an inherently leaky abstraction when the current approach works just fine. |
Right now each platform must define a
toolchain_program
function which will know how to program the device. The issue is there are tons of ways of programming a device. I propose that we teach nmigen how to interact with openocd, dfu-util, openFPGAloader, etc. and then have the platforms register their custom information for each of the programming interfaces they want to support.Long-term I am also seeing the possibility of people being able to create plugins to extend the programming interfaces. This would make so that with nmigen being more widely adopted, it did not fall on the upstream to maintain all possible interfaces. It should be fairly straight-forward, but not that relevant right now.
Example taken from
fomu_hacker.py
:I am open to contribute this change. Let me know if it makes sense right now, if you want to wait, if there are other things blocking it, etc. 😁.
The text was updated successfully, but these errors were encountered: