Comments (11)
It would indeed be nice, but I think we should ship something much simpler first.
from amaranth-boards.
For boards with FOSS toolchains it would be nice to check additional properties, like using a valid IOSTANDARD
(existing and for example using a differential standard for differential pins), using non-conflicting IOSTANDARD
s for pins on the same bank, and furthermore check if all the Attrs
are valid.
This opens the question about how to handle boards that have multiple different configurations (like the Atlys
board changing IOSTANDARD
s depending on a constructor argument).
from amaranth-boards.
Such boards should call some kind of function (or use any other mechanism) that would request the nMigen version through importlib_metadata and raise an ImportError if nMigen is too old.
I'm pretty sure this is the wrong solution, but I'm going to suggest it anyway.
You could try to import all board modules catching import errors. If a board import fails with such an import error, replace the board with a class that just generates an exception if someone actually tries to use the board....
I have seen this idea go wrong in so many different ways (which is what makes me think it is the wrong solution), but if there is actually someone who could make it work in a sane and reliably, it would probably be @whitequark...
from amaranth-boards.
If you are going the automated publishing to PyPi route, maybe the idea of just publishing every board into a seperate PyPi package works? That way users only depend directly on the boards they actually want to support (and thus a minimum nmigen version?).
You could also then have a nmigen-boards
meta package which depends on them all for convenience or could even be more super fancy and then also have different meta package "groupings" of nmigen-boards
(like nmigen-boards-vivado
-- any board which works with the Vivado platform) or something....
from amaranth-boards.
I have seen this idea go wrong in so many different ways (which is what makes me think it is the wrong solution), but if there is actually someone who could make it work in a sane and reliably, it would probably be @whitequark...
@mithro Hooking into the board import code path is basically what I want to do, except, as you correctly note, in a sane and reliable way.
If you are going the automated publishing to PyPi route, maybe the idea of just publishing every board into a seperate PyPi package works? That way users only depend directly on the boards they actually want to support (and thus a minimum nmigen version?).
I have of course considered that, but it's a logistical nightmare: it increases the workload required to add a new board several times over, it requires some sort of complicated automatic versioning scheme (because there is no way that can be managed manually), it will annoy our users (especially those who install the full package), it will no doubt expose new and exciting edge cases in the pip dependency resolver, and so on.
Sure, the idea sounds reasonable at first glance, but... even the 4 PyPI packages nmigen is currently split into present a noticeable maintenance burden. YoWASP, which is a dozen packages, is still a greater burden even in spite of me automating every action I could script and have it run reliably. Split nmigen-boards would be nothing short of a total nightmare.
from amaranth-boards.
Actually, I forgot the part where I would have to manually click through checks repository 50 (and growing) PyPI packages if I ever want to add a second maintainer. PyPI doesn't have any sort of organizations or group accounts, so every time I need to do something with YoWASP on Test PyPI after it gets wiped, I get dangerously close to carpal tunnel syndrome.
from amaranth-boards.
I'm guessing what you are really saying is that PyPi doesn't provide a package management API so you have to do all that manually?
from amaranth-boards.
I'm guessing what you are really saying is that PyPi doesn't provide a package management API so you have to do all that manually?
Yes, although there is also the problem that it greatly multiplies the amount of possible package conflicts. (In particular this scheme may not be used until the entire Python ecosystem migrates to the new pip dependency resolver.)
from amaranth-boards.
Hello, since I finally got myself an actual FPGA dev board, a so called "Colorlight i9" with its extended board, which is not bundled yet, I was trying to do yet another one (there are some PRs though)
For this topic, I am thinking that the "amaranth-board" repository is a mix of two things :
- a specific api : ressources and extensions (that for now looks like some other ressources, i have yet to see why it is separate)
- the board definitions
I would separate them. The api part would either be an independant library, or preferably reintegrate amaranth to leverage the release.
The "amaranth_board" would then be only a bunch of definitions of boards, added and updated/fixed on demand (PRs). Since it would not be a set of features, but more a collection of COTS, I would drop any numbering scheme and use a timestamp (like '2022.09.17')
That leaves the "test" (actually just 'blinky'). I see it more like a demo code that helps to verify that the targeted resource is correctly implemented. Thus I would extends this part so that each kind of resource has a typical demo code (some are easy to devise like led and GPIO, others would be more difficult, and except the onboard leds, any other test would require some test rigs that the user would have to build and connect to the board). And then for each board, the main execution would generate each relevant demo gateware, to be uploaded by the user for verification.
from amaranth-boards.
I would separate them. The api part would either be an independant library, or preferably reintegrate amaranth to leverage the release.
Right now these are often updated in lockstep with the boards, which I think is important. This is essentially the "monorepo" approach to updating dependencies. It arguably doesn't scale.
That leaves the "test" (actually just 'blinky'). I see it more like a demo code that helps to verify that the targeted resource is correctly implemented. Thus I would extends this part so that each kind of resource has a typical demo code (some are easy to devise like led and GPIO, others would be more difficult, and except the onboard leds, any other test would require some test rigs that the user would have to build and connect to the board). And then for each board, the main execution would generate each relevant demo gateware, to be uploaded by the user for verification.
It would be very nice to have something like that available. Unfortunately I'm not sure if we'll ever find people who can spend the effort of maintaining such test code for a very wide array of boards.
from amaranth-boards.
I plan to to something for testing my board's GPIOs. A blinky parametrized with the connector name / pin name. When I have something, I will post a PR of this demo for sure.
from amaranth-boards.
Related Issues (20)
- ULX3S IO is screwy HOT 1
- Defining adv7513 resource for a new board with subsignals different from DE10-Nano HOT 2
- Factor out resource "i2s"
- Factor out resource "hdmi"
- Factor out resource "ps2" HOT 2
- Factor out resource "vga" HOT 2
- Add `_n` suffix to names of pins with fixed inverter in resource factories
- Reason for duplication toolchain_program function HOT 6
- Add support for Nandland Go Board HOT 3
- Board testing results HOT 5
- SPIResource mandates active-low chip select
- Nexys4DDR: I/O standard should be different for some switches HOT 2
- Allow to name SplitResources based resources (like LEDResources, ButtonResources...) HOT 5
- Tip-of-tree amaranth not compatible with tip of amaranth-boards HOT 2
- Please add iCESugar.Pro support HOT 2
- CI is broken HOT 5
- Upgrading from nMigen and cannot get amaranth-boards installed HOT 2
- Typo in `orangecrab_r0_2.py`
- How to handle dual-row PMODs? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amaranth-boards.