<lethalbit>
hey, we've got a kinda silly question that was derrived from wanting to add a container build backend for nmigen, we noticed there is a `execute_remote_ssh` bit of the BuildPlan, but it's never hooked up anywhwere? it that just due to it not being tested / fully implemented or is there another reason for that?
<whitequark>
it's a public API provided for user code!
<lethalbit>
ah!
<lethalbit>
was hoping to just pass a param to .build
<lethalbit>
lol
<lethalbit>
(Still kinda wanna do the container backend ngl tho)
<lethalbit>
but yeah okay, cool,
<whitequark>
container backend?
<lethalbit>
yeah, so like, we have Vivado and Quartus installed in LXC containers
<lethalbit>
because it just seems more "organized"
<lethalbit>
and doing mount gymastics and all that to invoke the tools from within the container
<lethalbit>
is kidna effort, so we were thinking it would be nice if nmigen could invoke the container, auto-setup the bind mounts
<lethalbit>
and then do the synth and extract the build products then spin down the container
<whitequark>
this sounds potentially very useful
<lethalbit>
yeah
<lethalbit>
we're willing to put in the legwork
<lethalbit>
just not 100% sure how things would fit together within nmigen, hence the digging around in the guts
<lethalbit>
thus resulting in the original question
<lethalbit>
but yeah, if it's interesting enough we're willing to continue with working to implement it
<lethalbit>
this would also make the OpenLANE platform a little more sane because it could just leverage the container backend and not need to shell out to docker
<cr1901>
whitequark: Do you know of anyone (besides me) who has used the ssh backend?
<whitequark>
lethalbit: SGTM
<whitequark>
cr1901: nope, but people don't generally tell us which specific features they use (while the features work well)
<cr1901>
heh
<lethalbit>
awesome, we'll get started on this tomorrow then~
urja has quit [Read error: Connection reset by peer]
urja has joined #nmigen
pftbest has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<_whitenotifier-a>
[nmigen-boards] awygle opened pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JBghP
<_whitenotifier-a>
[nmigen-boards] whitequark commented on pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JB27k
xiretza[m] has joined #nmigen
emeb_mac has joined #nmigen
<mwbrown>
This board I'm porting allows you to select the io standard for two of its connectors via a jumper. Can I omit the `Attr(io_standard)` for these connectors and just specify it when the platform is instantiated, somehow?
<mwbrown>
Actually... come to think of it I'm not seeing the Connector constructor having an attributes specified for it in several of these examples. Might not be an issue after all
<DX-MON>
yeah, Connectors don't normally take an IO standard
<DX-MON>
it's a Pins that does
<mwbrown>
I must have just assumed it did because I'm porting by copying the reference QSF file into a platform .py
<mwbrown>
and they specify IO standard for all pins, including connectors
<DX-MON>
we found something curious in that regard that we're not certain is supposed to be public API, and that is `platform.resources["name", number]` then allows you to go in and modify a resource or pull out attributes from one if used prior to any build calls
<DX-MON>
nMigen requires connectors be used by a resource for them to have an IO standard defined if we understand correctly
<DX-MON>
and it's the resource that defines the standard
<DX-MON>
(Resource objects have 4 public parts to them, their name, what IOs they consume, the attributes those IOs have, and any Clock constraint
<DX-MON>
)
<DX-MON>
er.. sorry, 5 - their number too
<mwbrown>
I'm not looking forward to defining this HSMC connector (that I'm not even gonna use)... in addition to all the pins, pretty much all of them will need aliases for the differential pairs
<mwbrown>
Though, as I am looking at these existing board examples, I have yet to find a board that does both the pin-by-pin definition (where you just define FPGA IOsS) as well as the dictionary method where you give each pin a well-defined name. Is that even an allowed API?
DX-MON is now known as dragonmux
<vup>
I am not exactly sure what you are going for, but you certainly can use the same physical pin for multiple resources, they then just can't be `request`ed simultaneously
someone-else has joined #nmigen
<mwbrown>
vup: basically I can either define the HSMC connector as a regular connector, and not bother naming any of the pins, or
<mwbrown>
I can go through and give each one the name that Intel specifies (like clk_in_0, clk_in_1_p, clk_in_1_n, etc for like 32 data pairs)
<mwbrown>
but the pins are dual-purpose, you're not necessarily constrained to using them in LVDS mode if you just wanted single-ended IO
<mwbrown>
I'm thinking of just doing pin-by-pin and leaving it up to the end-user if they want to overlay the LVDS definitions on top of it
<vup>
yeah, I think it depends on what you are going for
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
bvernoux has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
emeb has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
<_whitenotifier-a>
[nmigen-boards] awygle synchronize pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JBghP
<_whitenotifier-a>
[nmigen-boards] awygle commented on pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JBwlf
<_whitenotifier-a>
[nmigen-boards] whitequark closed pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JBghP
<_whitenotifier-a>
[nmigen/nmigen-boards] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JBw4F
<_whitenotifier-a>
[nmigen/nmigen-boards] awygle 884996f - [breaking-change] Use PinsN for chip select in pmod definitions
<_whitenotifier-a>
[nmigen/nmigen-boards] awygle 84ffc81 - Migrate pmod resources from `extras` to `Attrs`
<_whitenotifier-a>
[nmigen-boards] whitequark commented on pull request #174: Use positive polarity for SPI chip select in PMOD resources - https://git.io/JBw4b
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #nmigen
emeb_mac has joined #nmigen
bvernoux has quit [Read error: Connection reset by peer]
<mwbrown>
protip: if you're having issues with an old USB-Blaster not detecting the jtag chain on newer Ubuntu versions (even with the right udev rules), try symlinking libudev.so.1 -> libudev.so.0
<mwbrown>
apparently jtagd has a silent failure where it just fails to talk to the chain if that lib doesn't exist. Doesn't even bother telling you it couldn't find libudev either