ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
<whitequark> agg: uh... why are you wrapping SB_IO rather than using
<whitequark> is there something i don't already expose?
<zkms> i want to test some nMigen code i've written (that ingests data from a Memory and outputs processed data to an other Memory); how would i get started with that?
<whitequark> zkms: take a look at examples/basic/
<whitequark> that shows how to use nmigen's simulator
<whitequark> at least, if you'd like to test it via simulation; we also have formal verification working, though it's somewhat less convenient to use at the moment
Guest30583 has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
thinknok has joined #nmigen
futarisIRCcloud has joined #nmigen
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 5 commits to master [+10/-0/±10]
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 6195290 - Initial commit.
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 213dc74 - Update wasmtime.
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark ae13399 - Modernize build and run process.
<_whitenotifier-c> [nmigen/nmigen-yosys] ... and 2 more commits.
thinknok has quit [Quit: Leaving]
thinknok has joined #nmigen
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 9710044 - Release test packages from `master`, production packages from `release`.
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark created branch release
Asu has joined #nmigen
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to release [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 5e47a63 - Fix importlib_metadata polyfill dependency to be used on Python 3.7.
thinknok has quit [Read error: Connection reset by peer]
thinknok has joined #nmigen
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 5e47a63 - Fix importlib_metadata polyfill dependency to be used on Python 3.7.
thinknok has quit [Quit: Leaving]
thinknok has joined #nmigen
thinknok has quit [Read error: Connection reset by peer]
<_whitenotifier-c> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-c> [nmigen/nmigen] whitequark 702e41b - vendor.xilinx_{7series,ultrascale}: don't use `write_verilog -decimal`.
<MadHacker> whitequark: I'm @james_a_craig on twitter with the raspberry pi. Can talk here if it's easier if you want.
<whitequark> MadHacker: atm there is no support for ARM32
<MadHacker> In wasmtime? Fair enough.
<whitequark> there *is* support for ARM64 in wasmtime, though not in wasmtime-py
<MadHacker> The pi is a fairly realistic platform for ice40 work, but I'd not touch it for anything fatter. The Novena would be my other ARM platform I'd like it to work on, and it is ARM32 too.
<MadHacker> Only the Pi 4 is 64-bit, the previous ones are 32.
<MadHacker> I'm OK with "sorry you'll have to build your own yosys" here BTW, just nice-to-have. :)
<whitequark> yeah, ice40 is already a bit of a stretch on <=Pi3
<whitequark> I use it and I do not enjoy it at all
<MadHacker> Yep.
<ZirconiumX> Heh, I still need to better figure out the hardware limitations of a Pi 4 in terms of bandwidth...
<MadHacker> I made this thing for the novena because I didn't like no OSS toolchain for the Spartan 6, but it's still not joyous building on the novena. Better than the Pi tho.
<MadHacker> ZirconiumX: The GPIO is surprisingly fast.
<MadHacker> I've managed to toggle a bitstream out on an older pi at 40MHz for driving big LED panels.
<ZirconiumX> Sure, but I wouldn't try sourcing power for disks from a Pi's GPIO
<Sarayan> Whitequark, why are you on xkcd?
<MadHacker> ZirconiumX: The fastest way to get stuff in and out of a Pi 4 is USB3.
<ZirconiumX> Yeah, I have two disks hooked up to an externally-powered USB3 hub
<ZirconiumX> But I'm *pretty sure* it's bandwidth starved by the hub
<MadHacker> That would be surprising. It's a single PCIe lane on the broadcom, so that'd be your upper limit on bandwidth.
<whitequark> Sarayan: huh?
<MadHacker> Today's xkcd is about language designers.
<whitequark> oh
<ZirconiumX> MadHacker: I know RAID1 isn't speed-optimal, but reads are the same speed with two disks as one
<MadHacker> OK, but what speed *is* that? If it's 133MB/sec then you're not going to get any faster.
<ZirconiumX> ...about that
<MadHacker> Yeah, so you're bus limited by PCIe.
<ZirconiumX> Okay, fair enough
<whitequark> 1 Gbps?
<MadHacker> Yeah, which I think is right for one lane one way on PCIe.
<whitequark> nope
<MadHacker> No?
<ZirconiumX> Depends on the PCIe gen
<whitequark> the slowest PCIe link is 2.5 GT/s
<MadHacker> Gen 1 in context.
<MadHacker> I thought 2.5 was the bidirectional-and-including-8b10b overhead number
<MadHacker> But very not expert here.
<whitequark> you're halfway right
<whitequark> it does include 8b10b (the PLL frequency is 100 MHz * 25)
<whitequark> but it's 2 Gbps in each direction simultaneously
<whitequark> I suspect the rest is USB overhead
<MadHacker> OK, so he's hoping to see 250MB, but is getting half that. USB 3 is faster than that, so something somewhere is not ideal.
<ZirconiumX> they
<MadHacker> USB overhead's pretty bad but I didn't think it was 100%.
<MadHacker> Sorry ZirconiumX.
<MadHacker> I'll use the right pronouns next time.
<ZirconiumX> Thank you
<whitequark> it could be a lot of different things
<whitequark> I *suspect* it could be a scheduling issue but I might very well be wrong
<ZirconiumX> I mean, equally there's read widths at play
<ZirconiumX> ~50 MiB/s 1MB random reads from fio
<MadHacker> ZirconiumX: You could try repeated reads from the same place on disk, so reading out of cache on one disk instead of splitting it up.
<MadHacker> Presumably that would guarantee running the disk end of the system as fast as is possible.
<whitequark> wait
<ZirconiumX> ~107MiB/s 1MB sequential reads from fio
<whitequark> isn't 133 MB/s a normal amount of sequential reads from a disk?
<whitequark> like, spinning rust
<MadHacker> Seems reasonable tending fast.
<ZirconiumX> The thing to note is this is basically the same as a single disk
<ZirconiumX> read: IOPS=99, BW=100MiB/s (105MB/s)(29.3GiB/300002msec)
<MadHacker> <-- seems to be relevant. I gather there's some USB3 storage quirks.
<MadHacker> Actually, that said, you're not running THAT slow, so presumably not that. :(
<whitequark> can you check the bandwidth on a different machine with faster USB?
<whitequark> well
<whitequark> on a desktop or something
<MadHacker> A little googlage suggests 350MB/s is reasonable on the pi 4.
<MadHacker> I should have the dongles here to test actually.
<ZirconiumX> Even though my laptop has USB3, it's running Windows, and the Pi is Linux
<ZirconiumX> I'm gonna try plugging the disks in directly to the Pi's hub
<MadHacker> Just rummaging for a spare SSD here.
<ZirconiumX> And hope I don't overload the power supply >.>
<_whitenotifier-c> [nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±3]
<_whitenotifier-c> [nmigen/nmigen] whitequark 7238e58 - double-quote Tcl values rather than brace-quoting.
<_whitenotifier-c> [nmigen/nmigen] whitequark 43b1ed1 - don't use `write_verilog -decimal`.
<whitequark> ZirconiumX: cr1901_modern: could you check if the above two commits break and/or fix your designs?
<MadHacker> ZirconiumX: Timing buffered disk reads: 1094 MB in 3.00 seconds = 364.24 MB/sec
<MadHacker> On an off-brand "SUNBOW" SSD via a USB3 dongle thingy.
<MadHacker> (which is interesting, since that's >250, so presumably Pi USB3 is PCIe gen 2 or better...)
<ZirconiumX> I have spinning rust, rather than an SSD, but still
<ZirconiumX> I don't have much in the way of Intel-specific stuff
<ZirconiumX> But I'll see if blinky still blinks
<whitequark> blinky still builds, I can confirm that
<whitequark> something with a PLL would be more useful to test
<ZirconiumX> Hmm...
<ZirconiumX> Yeah, I don't have anything there
<ZirconiumX> MadHacker: the Pi 4 is apparently Gen 2
<ZirconiumX> Rather than Gen 1
<whitequark> you can have 2.5 GT/s Gen 2 devices
<whitequark> but it's unlikely that's what you're dealing with
<whitequark> you can use `lspci -vvv` to check LnkSta field for your specific device
<MadHacker> Getting more than that bandwidth out of it just now, so it's 5 or higher I guess.
<whitequark> and LnkCap
<MadHacker> LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
<MadHacker> LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM not supported, Exit Latency L0s <2us, L1 <16us
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1]
<MadHacker> ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark 8796ace - Add support for [skip ci] tag in commit messages.
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-yosys] whitequark be1f1b3 - Lower Python version requirement to 3.5.
<ZirconiumX> ...Yeah, oddly that doesn't appear at all on my Pi
<ZirconiumX> Ah, has to run as root
<ZirconiumX> Yep, 5GT/s
<ZirconiumX> ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
<ZirconiumX> ...PCIe has surprises?
<MadHacker> No, it's Surprise-, it *doesn't* have surprises. :D
<whitequark> lol
<whitequark> I think it's "surprise removal"
<whitequark> aka hot unplug
<whitequark> so it's more that PCIe insists *you* don't make surprises for it
<MadHacker> Oh, everything supports hot unplug, whether it knows it or not. :D
<MadHacker> For varying values of "support" :)
<whitequark> well, it supports hot unplug, it just doesn't necessarily support doing it safely
<whitequark> the problem here is mostly on the OS side, actually
<whitequark> and to a lesser degree the simple matter of power sequencing
<MadHacker> Was about to say. Some CMOS latchup risk in there.
<whitequark> or a risk of shorting your +12V rail to ground
<whitequark> if you tilt the device in the slot
<hell__> I think the hardware has to support surprise removal
<MadHacker> I think you mean unexpected free welder.
<daveshah> Put the hot into hotplug
<whitequark> lol
<hell__> lol
<whitequark> in practice you can just tear the card out of the slot like a brute if you're confident in your ability to keep it perpendicular *and* in the ability of your OS to not panic or hang in that case
<whitequark> i've done it
<MadHacker> Can confirm: I do this regularly.
<whitequark> it even works with PCI
<MadHacker> Also with ISA.
<whitequark> lol ISA
<hell__> some weird PCIe thing: trying to enable ASPM on a BCM5751 NIC made coreboot hang sometimes. out of desperation, I tried pulling out the NIC from its PCIe slot
<hell__> somehow, that unfroze the machine
<MadHacker> Can't be told to wait by a card that ain't there.
<hell__> the weird thing is that it looked like a hardware lockup (not software waiting for something), as it would not always stop at the same point
<whitequark> that's probably because it was
<hell__> hm
<hell__> in the end I just blacklisted it from ASPM by PCI ID
<_whitenotifier-c> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-boards] whitequark 36ee98d - Update .gitignore.
<_whitenotifier-c> [nmigen/nmigen-soc] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen-soc] whitequark e72f950 - Update .gitignore.
<_whitenotifier-c> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-c> [nmigen/nmigen] whitequark eaf33fb - Update .gitignore.
<cr1901_modern> whitequark: I don't recall anything being broken for me in the most recent nmigen. Can you refresh my memory?
<whitequark> probably not so recent then
<whitequark> since you couldn't build any design with quartus for a few weeks
<cr1901_modern> Ahhh. I don't have quartus installed atm, so I wouldn't be able to check anyway.
<ZirconiumX> I could, if I had a design to test with
<awygle> morning all
<ZirconiumX> Morning
<whitequark> hi awygle
<ZirconiumX> Is there a guide to how to get Python to detect things as "packages"?
<ZirconiumX> Since it's difficult to structure things in a way that both VS Code (which thinks it's a package) and system Python (which thinks it isn't) are happy with
<ZirconiumX> ...Does this involve manipulation of PYTHONPATH?
<whitequark> yeah
zkms has quit [Quit: zkms]
zkms has joined #nmigen
zkms has quit [Quit: uguu]
zkms has joined #nmigen
zkms has quit [Client Quit]
smkz has joined #nmigen
<Sarayan> whitequark: I've written a as-small-as-resonably possible utf-8 library that does all NF plus case and stuff if you ever need it
<Sarayan> it's c++ but not much so, easily convertible to C
<Sarayan> or to anything else, it's the data structures and the composition algorithm that are important
<felix_> on that exostivlabs device: cheaper alternative that also doesn't eat away valuable gigabit transceivers would be to use a mini/micro hdmi connector connected to normal differential i/os; 4 fast lanes from the target (probably 1 clock, 3 data) to the host and 1 slower (would have used 1/4th of the speed of the other direction) lane from the host to the target. wanted to implement that some years ago, but that
<felix_> project already died long before i started my new job...
<whitequark> oh, nice idea
<felix_> the return track wuold be over the HEAC pair and there ist still space for an i2c bus
<felix_> and by running the host -> target link at 1/4th of the speed, signal recovery is easy
<daveshah> Yeah, that would be really cool
<daveshah> I think the advantage of transceivers is for boards that already exist and don't have a HDMI connector suitably wired, but do have a spare SFP or whatever
<hell__> felix_: oh, that's a pretty good idea
<felix_> i usually ran out of transceivers before i ran out of gpios
<daveshah> Definitely the usual way, particularly with ECP5
<felix_> but yeah, designing the protocol that it can work on different physical interfaces would be good
<daveshah> Yep, being able to scale from UART to QSFP28 would be great
<awygle> so, ethernet?
<whitequark> azonenberg intensifies
<whitequark> I totally agree tho
<Sarayan> there is only one protocol and its name is pcie
<felix_> ugh, ethernet over serial /o\ /me remembers that one project he gave up on. debugging lwip on a system without proper debug interface is neither easy nor fun
<whitequark> felix_: this is how i ended up writing smoltcp
<whitequark> 100% memory safe tcp/ip
<felix_> hehe. i've seen smoltcp, but haven't used it yet
<hell__> memory-safe?
<whitequark> no UB
<hell__> oh, nice
<whitequark> (assuming no rustc bugs)
<whitequark> (which i've ironically managed to hit, though the one i did was inconsequential in practice)
<hell__> wow
Asu has quit [Ping timeout: 260 seconds]
Asuu has joined #nmigen
<awygle> i have been doing udp over serial
<awygle> is not so bad
<awygle> would like to see a nice drop-in tcp core but i don't think people usually do that kind of thing in gateware
<awygle> maybe i'll switch to smoltcp once i have a cpu up on this thing
<whitequark> azonenberg does
<whitequark> and in fact i am going to
<whitequark> that's the end goal for the work that starts with streams and continues with gateware parsers/emitters for pcie
<awygle> Interesting
<awygle> I look forward to learning more Someday
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
<tpw_rules> ZirconiumX: do you still need python package tips?
<ZirconiumX> Sure, can't hurt
<tpw_rules> this is more a "this is what i do" instead of a good idea but a) obv all the folders have to have of at least zero bytes to be a legal package. and b) if you have a really simple ( e.g. under "Basic Use") then you can just cd into the directory, do pip install -e ., and it gets installed as a global package that points right there so you can keep editing
<tpw_rules> it but you can also do import my_stuff from anywhere
<tpw_rules> you can also set PYTHONPATH to the directory with the (though it doesn't have to actually exist in this case) to get the same effect as (b) but then you have to futz around with environment variables
smkz has quit [Quit: smkz]
smkz has joined #nmigen
Guest30583 has quit [Quit: Nettalk6 -]
Asuu has quit [Remote host closed the connection]
hell__ has quit [Quit: CPU triple-faulted.]
hell__ has joined #nmigen