<d1b2>
<edbordin> is your use-case mainly about making use of a more powerful remote build server?
<d1b2>
<edbordin> anyway, looks like it will be handy 🙂 I've been enjoying VS Code's remote dev extensions lately but the ssh plugin does leave your working copy living on the remote filesystem which probably isn't always ideal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
<ktemkin>
I use vscode's remote dev extensions on my build machine plus usbip, and it's been pretty decent for FPGA stuffs
<cr1901_modern>
My use case is "I don't want to install Vivado on my laptop"
<d1b2>
<edbordin> ktemkin ooh neat, so you can plug a board in at your desk and the remote machine can talk to it?
<ktemkin>
yep
<ktemkin>
it's not perfect, but it's been good enough for a lot of what I'm doing
<d1b2>
<edbordin> I've been meaning to try usbip out with wsl, but tbh the setup sounds involved enough that I probably wouldn't want to recommend it to anyone as a "quick start" route
<d1b2>
<edbordin> (mainly because it involves a kernel rebuild)
<cr1901_modern>
https://github.com/cezanne/usbip-win This looks like A LOT of work. I'd rather access my build artifacts over SMB (in the Vivado case)
<d1b2>
<edbordin> yeah this is why I haven't tried it
<d1b2>
<edbordin> wish they'd just implement hyper-v passthough
<ktemkin>
I don't use Windows; so usbip's a lot more reasonable
<ktemkin>
well, not for FPGA dev, anyways
<ktemkin>
IIRC there are things with nice hardware implementations of USB/IP that are essentially "remote hubs"
<d1b2>
<edbordin> just looking and sadly there's a PR to add usbip in the stock wsl2 kernel but they didn't resolve the CLA (nvidia employee asking microsoft for a different variant of agreement)
<d1b2>
<edbordin> maybe I should try doing that independently...it's probably going to look very similar if it's the output of menuconfig
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
jeanthom has joined #nmigen
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
chipmuenk has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
Asu has joined #nmigen
trabucayre has quit [Ping timeout: 256 seconds]
Sarayan has joined #nmigen
* Sarayan
waves
trabucayre has joined #nmigen
jeanthom has joined #nmigen
<lkcl>
DaKnig, yes, it's absolutely huge. that's exactly what i wanted you to see. that tells you everything you need to know: that those "very few lines" get turned into an absolutely enormous number of gates, and supports what whitequark advised you to do.
<lkcl>
the important thing is, though: you can actually see it for yourself, what happens.
chipmuenk has quit [Remote host closed the connection]
<lkcl>
now if you try whitequark's suggestion (use intermediate signals) you should see a drastic reduction in size.
<lkcl>
basically what is happening is: each time you use an AST expression in a loop (including an Array), that AST is **copied** and inserted directly into the yosys output.
<lkcl>
if you have a 100x loop it will create literally 100 copies of the same gates
<vup>
shouldn't yosys be able to optimize it to be the same as using intermediate signals if the result is actually equivalent?
<lkcl>
yosys *might* be able to optimise those copies out but it is unlikely.
<hell__>
O_o
<jeanthom>
freduce?
<hell__>
reminds me of -funroll-loops
<lkcl>
vup: i've found that in many cases yosys simply can't do it
<lkcl>
and yet in others (the PriorityPicker i wrote) it does an absolutely amazingly stunning job
<jeanthom>
agg, yes I should be able to do so, but it doesn't make any sense using .p since you can't use .n
<agg>
but you specifically want to assign the BB to the positive side, right?
<jeanthom>
yep
<jeanthom>
actually I don't want to
<jeanthom>
I have to
<agg>
what's wrong with using .p then, or rather what would you prefer to do?
<jeanthom>
have .io
<agg>
but which side should it refer to? BB might only need the p side but you might be doing something different entirely
<jeanthom>
well basically renaming .p into .io and ditching .n because it shouldn't be there
<agg>
the idea with dir=- is you get the raw physical pins, without it inserting a differential driver or anything for you, so you need to be able to get at both the p and n pins
<jeanthom>
AFAIK when your SSTL135D_I you can assign anything to the negative side of your diff pair
<jeanthom>
s/your/your pin is configured as/
<jeanthom>
the differential driver is handled by nextpnr
<jeanthom>
s/you can/you can't/
<agg>
sure, but you could have a platform file with a diffpairs resource that did not specify the SSTL135D_I attribute and you want to access both p and n pins in your nmigen logic, right? potentially on a totally different platform to ecp5
<agg>
I guess I see dir=- as "don't do anything to the pins, just connect them right into my top module", so I wouldn't want nmigen to remove the n half of a diffpair
<jeanthom>
If there are some FPGA that allow fiddling with both P/N sides then sure we should have .p and .n attributes.
<DaKnig>
arty z7 board allows you to fiddle with both P/N
<DaKnig>
you have to config the logic levels on the FPGA side
<agg>
ice40 doesn't even have differential drivers, so you'd deliberately assign .n to ~.p
<DaKnig>
so you use 0v as the negative?
<jeanthom>
DaKnig, yep
<DaKnig>
how do you get enough difference in voltage?
<DaKnig>
for HDMI for example
<DaKnig>
ah silly question you dont mess with HDMI on such small FPGAs usually
<agg>
for something like LVDS you can use external resistor dividers to generate LVDS levels from 0v/+V on the fpga pins
<whitequark>
jeanthom: agg is correct, that facility is generic over all kinds of FPGAs
<agg>
but yes probably not at hdmi speeds
<DaKnig>
somebody used a spartan 6 fpga to drive HDMI so
<DaKnig>
everything is possible :)
<agg>
hah, i am sure
<daveshah>
You can drive HDMI from an iCE40
<DaKnig>
250MHz is not that much, when you have serdes
<agg>
daveshah: i should have known :p
<DaKnig>
deveshah but how do you get enough differential voltage for that then?
<jeanthom>
whitequark, ok so I should beg for .io but use .p then
<daveshah>
It's pseudo differential - each side is going between +3.3V and 0V
<daveshah>
So you have a differential swing of ±3.3V
<_whitenotifier-b>
[nmigen] jeanthom edited issue #456: Cannot get raw IOs from a diff pair group - https://git.io/JJ2FG
<_whitenotifier-b>
[nmigen] jeanthom edited issue #456: Negative side of diff pair is exposed on ECP5 - https://git.io/JJ2FG
<whitequark>
jeanthom: ah yes, this one is easy to fix
mwk has quit [Read error: Connection reset by peer]
mwk has joined #nmigen
mwk has quit [Read error: Connection reset by peer]
mwk has joined #nmigen
_whitelogger has joined #nmigen
<_whitenotifier-b>
[nmigen] jeanthom opened pull request #457: nmigen.build.res: Ensure all pins are available in a DiffPairs - https://git.io/JJ2xn
<_whitenotifier-b>
[nmigen] jeanthom commented on pull request #457: nmigen.build.res: Ensure all pins are available in a DiffPairs - https://git.io/JJ2xg
Sarayan has quit [Ping timeout: 272 seconds]
<_whitenotifier-b>
[nmigen] whitequark commented on issue #427: Add support for Assert in simulation - https://git.io/JJ2p6
<jeanthom>
oh I'm noticing that you can set the xdr of things that do not exist
chipmuenk has joined #nmigen
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to uniform-diff-ports [+0/-0/±9] https://git.io/JJaUw
<_whitenotifier-b>
[nmigen/nmigen] whitequark 83e5aa7 - build,vendor: never carry around parts of differential signals.
<_whitenotifier-b>
[nmigen] whitequark opened issue #458: Decouple pin direction overrides, XDRs, etc from request() - https://git.io/JJaUr
<_whitenotifier-b>
[nmigen] whitequark commented on issue #413: Per-pin direction control for platform defined IOs - https://git.io/JJaUK
<_whitenotifier-b>
[nmigen] whitequark closed issue #413: Per-pin direction control for platform defined IOs - https://git.io/JfhbD
<_whitenotifier-b>
[nmigen] whitequark edited issue #458: Decouple pin direction overrides, XDRs, etc from request() - https://git.io/JJaUr
<_whitenotifier-b>
[nmigen] whitequark opened pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaUi
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to uniform-diff-ports [+0/-0/±9] https://git.io/JJaII
<_whitenotifier-b>
[nmigen/nmigen] whitequark de9c1a1 - build,vendor: never carry around parts of differential signals.
<_whitenotifier-b>
[nmigen] whitequark synchronize pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaUi
<_whitenotifier-b>
[nmigen] whitequark commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaIY
<_whitenotifier-b>
[nmigen] jeanthom commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaIw
<_whitenotifier-b>
[nmigen] jeanthom edited a comment on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaIw
<_whitenotifier-b>
[nmigen] whitequark commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaLR
proteus-guy has quit [Ping timeout: 260 seconds]
<_whitenotifier-b>
[nmigen] jeanthom closed pull request #457: nmigen.build.res: Ensure all pins are available in a DiffPairs - https://git.io/JJ2xn
<_whitenotifier-b>
[nmigen] jeanthom commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaLA
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to uniform-diff-ports [+0/-0/±10] https://git.io/JJatB
<_whitenotifier-b>
[nmigen/nmigen] whitequark ba3729e - build,vendor: never carry around parts of differential signals.
<_whitenotifier-b>
[nmigen] whitequark synchronize pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaUi
proteus-guy has joined #nmigen
emeb has joined #nmigen
Asuu has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to xilinx-bufgctrl [+0/-0/±2] https://git.io/JJaqy
<_whitenotifier-b>
[nmigen/nmigen] whitequark 0ad7f88 - vendor.xilinx_{7series,ultrascale}: use BUFGCTRL rather than BUFGCE.
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to xilinx-bufgctrl [+0/-0/±2] https://git.io/JJaqH
<_whitenotifier-b>
[nmigen/nmigen] whitequark 6b6475d - vendor.xilinx_{7series,ultrascale}: use BUFGCTRL rather than BUFGCE.
<_whitenotifier-b>
[nmigen] whitequark opened pull request #460: vendor.xilinx_{7series,ultrascale}: use BUFGCTRL rather than BUFGCE - https://git.io/JJaq7
<_whitenotifier-b>
[nmigen] whitequark commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJaqd
proteus-guy has quit [Ping timeout: 260 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 256 seconds]
tannewt has joined #nmigen
<tannewt>
hey, I'm looking at the nmigen csr class and could use some help understanding WishboneCSRBridge and csr.Multiplexer
<cr1901_modern>
CSR is Configuration and Status Bus. It comes from omigen, and is a simpler bus than wishbone for writing/reading I/O registers.
<tannewt>
my goal is to change the way peripherals are designed so they can be used from python to interact with it as well
<cr1901_modern>
However, all the CPUs nmigen knows about use the wishbone bus, so WishboneCSRBridge converts
<tannewt>
is that why it's 8 bits wide as well? I'm not understanding why granularity is 8 in the lambda soc example
<cr1901_modern>
yea CSR is 8 bits
<cr1901_modern>
IIRC to do a 32-bit write, for hardware simplicity, you write to addr, addr+4, addr+8 and then addr+12
<cr1901_modern>
I _think_
<tannewt>
doesn't the 8 bit width make a wishbone read take 4 cycles?
<cr1901_modern>
Yup!
<cr1901_modern>
wq wants to get rid of it last I checked
<tannewt>
ah, and do 32 bits directly?
<tannewt>
I think that's whats hanging me up a bit. I expected to see one decoder straight to <=32 bit registers
<cr1901_modern>
Well nothing prevents 4 8 bit regs existing in Wishbone at different addresses. But that gets into the topic of granularity vs width in the WB spec and I don't remember offhand how it works
<cr1901_modern>
Well nothing prevents 4 8 bit regs existing in Wishbone at sequential addresses in a 32-bit bus*
<whitequark>
cr1901_modern: uh, that's not really correct
<tannewt>
right. I come from 32bit mcus, so my gut is to just make everything 32 bit
<whitequark>
the CSR bus isn't strictly speaking from omigen (we went through a few design iterations in nmigen-soc), and i do not plan to get rid of it
<cr1901_modern>
I could've sworn you said you wanted to put all CSR bus regs on the WB bus directly
<whitequark>
well, there's a high chance you're accessing csrs from some kind of CPU
<whitequark>
and since their addresses or widths can easily vary from gateware build to another, you don't want to just hardcode all of that
<tannewt>
my plan was to fix the csr address within the peripherals range
<tannewt>
so that the driver is the same whenever the peripheral is encountered
<whitequark>
then you can't parameterize the peripheral in a way that changes the number of CSRs, for example
<tannewt>
I'm ok with that
<whitequark>
i'm not, so nmigen-soc's design is flexible enough to accomodate it
<tannewt>
I'm more interested in the system around a peripheral
<whitequark>
what kind of system?
<tannewt>
the cpu, bus structure and other peripherals
<tannewt>
ok, so to map a peripherals registers I'd do WishboneCSRBridge to a csr.multiplexer to individual csr.Elements right?
<whitequark>
yeah
<whitequark>
fields within elements aren't merged yet (IIRC there was some proposal but other things were higher priority)
<agg>
would you have one csr.multiplexer shared by all peripherals or one per peripheral?
<tannewt>
field meaning an individual bit?
<tannewt>
I think it's one csr.mux per peripheral in my mind
<tannewt>
though I wonder if you can share that logic if you have multiple copies of the same peripheral
proteus-guy has joined #nmigen
<whitequark>
bit or several bits
<tannewt>
that wouldn't change the bus structure right? just the memorymap and generated files right?
<tannewt>
wow, I need to eat breakfast. get my brain going :-)
<whitequark>
indeed
<tannewt>
kk, thanks! great work with nmigen
<whitequark>
thank you as well
<d1b2>
<mubes> @tannewt @Hedge has done some work on exporting a bsp/SDK for migen that should easily go across to nmigen. The great thing about doing that is that you can just export an entire description of a soc, and it's bitfile, then import and use it in your design.
jeanthom has quit [Ping timeout: 260 seconds]
<cr1901_modern>
>I don't understand what you're saying
<cr1901_modern>
Is there cutoff for supported Vivado versions?
<cr1901_modern>
It's not important (as I'm sure you guessed by now)
<DaKnig>
you can probably configure it easily for whatever version you are using
<cr1901_modern>
I'm doing a test right now, b/c mine is quite out of date (17.04)
<DaKnig>
we have people here with much older versions :)
<cr1901_modern>
B/c I cloned the git repo in December 2018 and forgot to update it.
<awygle>
cr1901_modern: i think you were attributing my position to wq, earlier. jfyi
<cr1901_modern>
Well at least I'm not _completely_ losing it
<d1b2>
<emeb> Help - what's the proper pip3 incantation to ensure I've got the latest nmigen? When I do "pip3 install --user 'git+https://github.com/nmigen/nmigen.git#egg=nmigen'" sometimes it pulls in V0.2, and sometimes it pulls in V0.1 and I'm obviously doing something dumb here.
<whitequark>
emeb: that's weird. can you post the full output of pip?
<whitequark>
it should pull v0.3 either way
<d1b2>
<emeb> lol - just did it again and it pulled in V0.3. Fortunately I've got my logs so here's what happened -> https://pastebin.com/g2PjHbxV
<DaKnig>
should use --upgrade I think
chipmuenk has quit [Ping timeout: 244 seconds]
<whitequark>
yeah that sounds right
chipmuenk1 has joined #nmigen
<d1b2>
<emeb> Hmm... so it seems that the first time I uninstalled V0.2 there was a V0.1 lurking behind it that took over.
<whitequark>
yep
<whitequark>
i think that's why pip --upgrade is useful...
<d1b2>
<emeb> OK - that makes sense. Thx!
<cr1901_modern>
>it should pull v0.3 either way
<cr1901_modern>
FWIW, I don't see a v0.3 tag on the GH repo
<d1b2>
<emeb> Takes a while to fully understand all the the info that spews out when one does a pip.
chipmuenk1 is now known as chipmuenk
<whitequark>
cr1901_modern: yes indeed
<whitequark>
it's a 0.3.dev version
<cr1901_modern>
Okay, so it looks like the way versioneer works is that: if there's no tags, it's a 0.1.dev version. If there's a 0.1 tag, subsequent commits are 0.2.dev, if there's a 0.2 tag, subsequent commits are 0.3.dev, etc
<cr1901_modern>
Not versioneer
<cr1901_modern>
I meant setuptools_scm*
<whitequark>
yeah, i set it up that way
<cr1901_modern>
Meaning: "do a git fetch of your tags once in a while, otherwise you'll get fun versions like: 0.1.dev+960 :)
<whitequark>
argh, you're right
proteus-guy has quit [Ping timeout: 260 seconds]
<cr1901_modern>
DaKnig: Just FYI, with Vivado 17.04.1 and the most recent commit of nmigen, I get this: http://ix.io/2sNK
<cr1901_modern>
You may wish to check your old versions
<_whitenotifier-b>
[nmigen] whitequark closed pull request #460: vendor.xilinx_{7series,ultrascale}: use BUFGCTRL rather than BUFGCE - https://git.io/JJaq7
<FL4SHK>
My interests are mainly computers and video games
<FL4SHK>
though I like composing music also
<cr1901_modern>
whitequark: paramiko works. Did you see my comments about .bashrc yesterday?
<whitequark>
cr1901_modern: yeah
<whitequark>
let me think about it
<whitequark>
cr1901_modern: so what's wrong with using .bash_profile or .profile?
<cr1901_modern>
I don't see anything wrong w/ them, other than "I tend to put env vars in .bashrc unless prompted". Nothing insurmountable.
<whitequark>
i think the whole point of having .bash_profile is to get the behavior you want here
<d1b2>
<Hedge> @mubes yeah, we still need to figure out how to treat SDK going forward
<cr1901_modern>
okay then. Let me rework what I have
<d1b2>
<mubes> @Hedge yeah, I'm leaving it to the experts, but it 'feels' to me like it's an essential step in getting these socs adopted.
<d1b2>
<tannewt> @mubes @Hedge that is one thing I'm interested in. I like the idea of being able to treat an fpga design as a hard mcu
<d1b2>
<Hedge> yeah, I think the current point of contention is that most of the libs that we were putting in the SDK needed to be migrated away from migen in the first place
<d1b2>
<mubes> ...otherwise you need a build environment for a whole ecosystem you don't really understand as a softie.
<d1b2>
<Hedge> but I think there is still value in having migen or nmigen export all necessary headers
<tannewt>
💯
<d1b2>
<Hedge> I haven't played with nmigen much yet, so I don't know if it does that already or not
<whitequark>
not yet, but it's planned once we get nmigen-soc off the ground and going nicely
<d1b2>
<mubes> Yes, but ideally just headers and source, not lib stuff!
<whitequark>
what kind of libs are you talking about?
<d1b2>
<mubes> Driving for a while...I'll pick this up later
<tannewt>
I'm working to build an api on nmigen that uses the python objects api to define the hardware api (aka registers)
<whitequark>
tannewt: note: some kind of DSL for building registers and such is planned upstream
<whitequark>
it's just not done yet
<tannewt>
why a dsl? I'm planning on using data descriptors
<whitequark>
that's still a DSL in some sese
<whitequark>
*sense
<whitequark>
data descriptors are handy but they don't handle parameterizability all that well
<whitequark>
wait, i think i misunderstood you
<whitequark>
where's `StaticHalfWord` and such defined?
<tannewt>
they are stubs atm. I think I forgot to add them to git
<tannewt>
they are stubs but the idea is that they will have `__get__` and `__set__` to make them data descriptors
<whitequark>
interesting
<tannewt>
and then depending on what type of bus is passed into the peripheral it'll either return the csr.Element to use in elaborate or actually just mutate the value
<tannewt>
so it could be a driver as well
<tannewt>
you'd just pass in a memory_window that reads from the cpu's memory or it could work over usb to wishbone for example
<tannewt>
they are complex from the inside but simple from the outside
<whitequark>
I was actually thinking in a similar vein, but through a different approach, type annotations
<tannewt>
ya, type annotations would be good too
<whitequark>
anyway i'll definitely have to keep this in mind because while i knew about data descriptors, it never occurred to me to use them in a way like this
<whitequark>
thanks for the pointer
<awygle>
i find myself adrift in another sea of "what is the intended use case" :(
<awygle>
every time we talk about nmigen-soc i feel dumb lol
<tannewt>
np! I'll keep plugging away at it. I'm having fun imagining the hardware/software hybrid
<tannewt>
someone has already made a circuitpython class for raw memory reads so we'd be able to use the classes in cp on a soft cpu
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<tannewt>
awygle:
<tannewt>
oops, I always do that
<tannewt>
I work for adafruit so the main use case is more neopixels :-)
<awygle>
heh :)
<whitequark>
cr1901_modern: just cheded and by default, normal `git pull` does pull in tags
<whitequark>
*checked
<whitequark>
so if you ended up without tags you might be doing something weird?
<awygle>
i don't understand the value of what seems to me to be a third layer of abstraction? now we have "register data descriptor"->"CSR"->"wishbone", and i was already doubting the usefulness of the "CSR" stage
<tannewt>
but seriously, a soft soc running circuitpython and neopixel peripherals would be awesome
<agg>
memory-mapped neopixels, amazing
<awygle>
is this just for simulation?
<tannewt>
agg: gets it :-)
<agg>
awygle: run the python on the soft cpu inside the fpga
<whitequark>
awygle: i'm not sure exactly what tannewt wants, but my purposes for this kind of shenanigans is to make it convenient to define peripheral interfaces
<cr1901_modern>
I do "git pull origin master", if that makes a difference. Anyways, not sure
<whitequark>
it's one of the major missing parts in nmigen-soc
<whitequark>
sure, you can request a csr.Element, and then you're stuck implementing the actual behavior yourself
<awygle>
didn't we spend like two hours on tuesday talking about that though?
<whitequark>
can you be more specific?
<tannewt>
it is interesting to think that the way you define the registers is also how you use them from python
<tannewt>
I got sphinx building on my repo too. to see what the docs look like
<whitequark>
awygle: oh sorry, this time i meant the interface you're actually interacting with from your CPU (or more like the generated BSP directly interacts with it, and you interact with the BSP)
<awygle>
(also a heads up that i'm not having a particularly good brain day so if i start sounding like a petulent child, let me know and i'll shut up and come back tomorrow)
<whitequark>
we don't have anything like a DSL that can be turned into SVD
<awygle>
whitequark: i kind of thought that was the purpose of the MemoryMap stuff
<whitequark>
awygle: memory map is a good start!
<whitequark>
we're still missing something that lets you define actual fields, enumerations, associated constants, stuff like that
<tannewt>
my plan for fields was to have a second data descriptor for the field and have the same address as the full register
<awygle>
so by "fields" you mean "these three bits of this register map to these eight semantic meanings, and these other two bits map to these other four semantic meanings"?
<tannewt>
data descriptors don't work for objects so maybe they'd just be a read only instance variable
<whitequark>
awygle: more or less
chipmuenk has quit [Quit: chipmuenk]
<awygle>
doesn't the CSR infrastructure let you define a 3-bit register and a 2-bit register?
<whitequark>
yes but they won't be atomically updated then
<whitequark>
or read
<awygle>
mm, ok
<awygle>
so the CSRs define atomic groupings of arbitrary dimension, but there's no way to define the objects they're grouping.
<whitequark>
basically.
<tannewt>
awygle: how are you wanting to use peripherals? (you said without a cpu)
<_whitenotifier-b>
[nmigen] jfng commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJa8H
<_whitenotifier-b>
[nmigen] whitequark closed issue #456: Negative side of diff pair is exposed on ECP5 - https://git.io/JJ2FG
<_whitenotifier-b>
[nmigen] whitequark commented on pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJa85
<_whitenotifier-b>
[nmigen] whitequark closed pull request #459: build,vendor: never carry around parts of differential signals - https://git.io/JJaUi
<awygle>
tannewt: for example, imagine a network card with PCIe on one end and GigE on the other end. i just want to move bits from one end to the other with the necessary transformations
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJa8b
<_whitenotifier-b>
[nmigen/nmigen] whitequark 467c013 - Deploying to gh-pages from @ d964ba9cc45490b141c8c4c4c3d8add1a26a739d 🚀
<awygle>
that's what most of the things i'd use an FPGA for look like
<tannewt>
so it's more about how you connect peripherals together?
<awygle>
even if i have a soft CPU it's mostly going to be used to initialize and/or configure that datapath rather than being central to the design
<awygle>
at the same time i know a lot of people care about circuitpython and/or linux on soft cores so i certainly don't want to minimize that use case, i'm just not really familiar with it
<cr1901_modern>
whitequark: Mind looking over this and giving feedback based on comments? And perhaps trying it out on your machine?
<tannewt>
I think the data descriptors will help you still because it'll make the peripheral api clearer and easier to document
<cr1901_modern>
Oh right. There's no sanitizing input yet
<cr1901_modern>
^Besides that
<whitequark>
cr1901_modern: that seems heavily incomplete? everything's hardcoded
<whitequark>
why aren't you using SSHClient?
<cr1901_modern>
If I use SSHClient, the default logic will immediately fail with "permission denied: public key". And I need access to the underlying transport to change where to look for it
<cr1901_modern>
(and I have to connect before SSHClient returns a valid transport object)
<whitequark>
why will it immediately fail?
<whitequark>
right, because your $HOME isn't set correctly or something
<cr1901_modern>
Fine, I'll symlink the keys *grumbles*
<whitequark>
i mean, the problem with that code is that it does both too much and too little
<whitequark>
too much, because it doesn't use the high-level wrappers paramiko has. too little, because it wouldn't e.g. pick up my ecdsa key
<whitequark>
i'm quite sure i want to have as little ssh-related logic in nmigen as possible at all
<whitequark>
cr1901_modern: also, can't you pass key_filename= to SSHClient.connect()?
<cr1901_modern>
Anyways besides that, nothing should prevent me from using SSHClient
<whitequark>
using SSHClient should improve this significantly
<whitequark>
a few more things
<cr1901_modern>
Yes, I agree. I'll symlink my keys and work around this for now
<whitequark>
no, you definitely should *not* mirror local file layout
<whitequark>
the whole point of nmigen producing self-contained build folders with no particular guarantees on where they'll live is to avoid those kinds of issues
<whitequark>
the build inputs should probably be placed in the temporary directory on the host, like it happens with local builds, at least by default
<cr1901_modern>
so on the remote, place the build.zip inside the remote build dir a la "zip bomb"?
<whitequark>
why even bother with the zip?
<cr1901_modern>
Because it's one xfer :P
<whitequark>
mhm, well, that's true
<whitequark>
but then you have to rely on unzip existing
DaKnig has quit [Remote host closed the connection]
<cr1901_modern>
Indeed. And execute_remote will be a method of BuildPlan
<cr1901_modern>
so it'll know which files to xfer
DaKnig has joined #nmigen
<cr1901_modern>
(via the self.files member)
<cr1901_modern>
Is sending the build files to the remote w/ deterministic timestamp important?
<whitequark>
nope, we don't do this locally either
<cr1901_modern>
Ack. Anything else before I start adding this to the actual nmigen classes? Any problems w/ my proposed env vars (the ssh_dir can be dummied out for now)?
<whitequark>
there shouldn't be any environment variables checked at all in build.run
<whitequark>
oh, i said this earlier: "the build inputs should probably be placed in the temporary directory on the host, like it happens with local builds, at least by default"
<whitequark>
that was nonsense. we don't do that for local builds, i was thinking of a tool i wrote earlier which did
<whitequark>
for local builds we put them in "./build"
<whitequark>
for remote builds i think it's fine to always require a directory to be specified
<cr1901_modern>
alright, I won't have the concept of a "root directory" for remote builds then. You'll pass it to execute_remote.
<whitequark>
yeah
<cr1901_modern>
do you want username, server, port input args then (Note: paramiko _does_ understand OpenSSH config files- Idk if SSHClient leverages then)?
<emeb>
heh - CIC filter ported to nmigen from verilog. code is much more compact. nmigen does "generate" much more cleanly than verilog.
<emeb>
(note - integrators were pipelined in verilog, but not in nmigen)
<whitequark>
cr1901_modern: something like `def execute_remote_ssh(connect_to):`, where `connect_to` is passed straight to `SSHClient.connect` seems fine
<whitequark>
plus maybe a fallback, so that if it's an ssh:// URI or a stringified URI it's enough to say .execute_remote_ssh("ssh://foo@bar")
<whitequark>
hrm, i'm not sure if there are usable ssh:// URIs
<whitequark>
cr1901_modern: ah yes and i'd definitely like you to not use unzip
<whitequark>
you can enable pipelining in paramiko, which should speed transfers up
<tannewt>
has there been any thoughts to using an external build system like ninja? I'm wondering if it could help with only building changed resources
<whitequark>
there isn't much point in it because FPGA workflows generally don't involve separate compilation
<whitequark>
so either you changed nothing (easy to detect) or you changed something and you now have to rebuild ~everything
<tannewt>
I was wondering about that. I did run into it when running on mac where I had to give security permission for every binary it called
<tannewt>
it rebuilt everything even though I hadn't changed anything
<whitequark>
it = what?
<d1b2>
<mubes> Back. My point about migen libs was to not include them in any 'sdk' ... Just the header files and accessor functions. That 'micro-lib' is great for the bios, but very limited for any other use.....it should be an active decision to use it, not a default.
<whitequark>
mubes: oh yeah, agreed
<whitequark>
nmigen-soc wouldn't even have a bios
<tannewt>
it = rebuilding everything when I didn't need to
<whitequark>
not its responsibility
<whitequark>
tannewt: i mean, what was rebuilding everything?
<tannewt>
actually, I think that was the litex example for orangecrab
<d1b2>
<mubes> Hmm....a bit of thin code to spin up the ram and load an image is pretty handy....
<tannewt>
not nmigen
<tannewt>
I don't like the bios either. I'm used to arm's default reset handler
<tannewt>
building the bios means another build system
<tannewt>
(lambdasoc's uses kconfig as well)
<whitequark>
yeah
<cr1901_modern>
>hrm, i'm not sure if there are usable ssh:// URIs
<cr1901_modern>
AFAICT, they don't include port
<cr1901_modern>
ack on "no unzip"
<d1b2>
<mubes> Somewhere something that knows the config of the chip has to set things like delay params and pin setup for the ram/flash.
<tannewt>
I'm used to mcus where flash and ram is baked in
<whitequark>
it's possible to emit that code in a header or source without letting it rule the entire flow
<cr1901_modern>
if we pass it straight to connect, shouldn't it be: def execute_remote_ssh(self, directory, hostname, **connect_to):?
<cr1901_modern>
"directory" not being part of SSHClient.connect()
<whitequark>
why do you need hostname with that signature?
<cr1901_modern>
it's a required arg to connect
<cr1901_modern>
thought you might want it handled differently since it's not optional
<whitequark>
right, ok
<d1b2>
<mubes> Agreed....but it ends up being a bios even if we don't call it one...I guess 'bootstrap code' is more appropriate, which is generally the way arm does it....but it means you've got to provide documentation about how do set it up, which is self documented by code.
<cr1901_modern>
and bikeshed... "**kwargs", or "**connect_to"?
<d1b2>
<mubes> (but personally, I'd be very happy with no code beyond documented accessors and config....opens the door to other languages like rust)
<whitequark>
cr1901_modern: so for the most part i didn't want to use **kwargs for this because, well, what if both paramiko and we add a conflicting argument in the future?
<whitequark>
mubes: nmigen-soc will definitely support rust and c in the bsp generator
<cr1901_modern>
so should it be an array of args we pass to paramiko?
<whitequark>
no, a dict, passed as connect(**connect_to)
<cr1901_modern>
yes, sorry
<cr1901_modern>
I meant dict()
<d1b2>
<mubes> Happy
<whitequark>
yeah, i think so
<whitequark>
it's not an ideal design
<whitequark>
but it seems good enough
<cr1901_modern>
whitequark: So the reason I wanted to mirror the build directory locally was because a user might need to debug after the remote build is finished. However, I understand your reasoning why not to mirror the build dir.
<cr1901_modern>
If someone is doing remote builds and wants to debug, is the correct solution to run execute_local(run_script=False) or archive?
<whitequark>
cr1901_modern: oh, I think I misunderstood what you did there exactly
<whitequark>
cr1901_modern: if your build breaks remotely, why wouldn't you log into the remote machine to debug it?
<cr1901_modern>
B/c headless
<whitequark>
uh... you have ssh?
<whitequark>
the whole thing is built around ssh, no?
<cr1901_modern>
I don't want to debug with vi :P
<cr1901_modern>
that's it
<cr1901_modern>
no other reason than that
<whitequark>
okay, let me see if i understand your proposal correctly there
<whitequark>
you first extract everything locally, then copy the same files to the remote machine
<whitequark>
but you don't bring back anything other than the explicit build products? i.e. bitstream
<cr1901_modern>
correct
<whitequark>
isn't that capability superfluous because you can always run the build locally if you wanted that?
<cr1901_modern>
I don't have Vivado installed on this machine and I'm not in a position to do so right now.
<whitequark>
sorry, bad phrasing
<whitequark>
since the only thing that this feature provides is the build inputs at the local machine, isn't it just duplicating local builds (with run_script=False)?
<whitequark>
sure, you can't run vivado locally, but since you don't bring build products back, you can't inspect them locally either way
<whitequark>
you can't inspect the build outputs*
<whitequark>
bring all build products*
DaKnig is now known as DaKnig
<cr1901_modern>
yes, that's correct
<cr1901_modern>
ooooh, right
<cr1901_modern>
yea, you're correct. Uhh, I had a bit of a judgment lapse there
<cr1901_modern>
under the assumption that the only really valuable thing to debug what's fed into the toolchain. Which is completely untrue
<cr1901_modern>
that the only really valuable thing to debug _is_* what's fed into the toolchain
<cr1901_modern>
Yea, we can go without in that case. You need to ssh into the server to debug- that's fine
<whitequark>
or use sftp:// in your favorite file manager
<whitequark>
which is nicer than either of those choices
<cr1901_modern>
that too.
<cr1901_modern>
If ppl want the remote build products, they can use RemoteBuildProducts.get(). Which is what each toolchain_program does anyway.
<cr1901_modern>
via extract*
<whitequark>
yeah
<whitequark>
this is another reason why the build has to be in a non-temporary directory btw
<whitequark>
if it was temporary, it'd have to be deleted, and the answer to "when" turns nasty quickly
<whitequark>
it's better for everyone to just not go there
<cr1901_modern>
A user should be fine with using a single user-specified directory for all remote builds if they so choose
<cr1901_modern>
Previous build is only "deleted" when they start a new remote build in the same dest directory
<cr1901_modern>
(which is just like local builds I think)
<whitequark>
yeah
<whitequark>
i guess another way to look at it is, it's always possible to wrap an explicit directory API into something that makes a temporary one
<whitequark>
but not the other way around
* cr1901_modern
nods
DaKnig has quit [Remote host closed the connection]
<cr1901_modern>
and re: not deleting build dir contents (local _or_ remote) between reusing a build dir... I assume someone would've complained by now if that logic was broken
DaKnig has joined #nmigen
DaKnig is now known as DaKnig
<whitequark>
i've seen it borderline failing a few times
<whitequark>
usually by stuffing build trees from two different vendor toolchains into one build dir
<cr1901_modern>
haha... yea prob shouldn't do that period
Asu has quit [Remote host closed the connection]
<cr1901_modern>
whitequark: Oh right, one other thing... paramiko should be optional, correct?
<cr1901_modern>
If so, how should this be gated within nmigen?
<whitequark>
import it in the function
<_whitenotifier-b>
[nmigen] rroohhh commented on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJazy
<_whitenotifier-b>
[nmigen] rroohhh edited a comment on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJazy
<_whitenotifier-b>
[nmigen] rroohhh edited a comment on issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJazy
<_whitenotifier-b>
[nmigen] whitequark reopened issue #438: wrong type of buffer primitive used in series 7 - https://git.io/JJcU4
<DaKnig>
I wont be able to test in the next few days
<DaKnig>
sry
<DaKnig>
wq
<vup>
wow vivado 2017.4 missing SIM_DEVICE is really annoying
<vup>
I guess one could add version specific workarounds in the tcl build script
<DaKnig>
how would I make a PLL in nmigen? the only thing I did so far is use the gui to create a pll unit... but those "IPs" are in some weird format, arent they
<Lofty>
You kinda have to Instance it
<DaKnig>
any examples for 7series boards?
<DaKnig>
unrelated, are there any HDMI testbenches in nmigen?
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
<_whitenotifier-b>
[nmigen] cr1901 opened pull request #461: SSH Client Support via Paramiko - https://git.io/JJarq