<_whitenotifier-b>
[nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYZB
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
<_whitenotifier-b>
[nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYWU
<_whitenotifier-b>
[nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYWG
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
<_whitenotifier-b>
[nmigen] programmerjake edited a comment on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYWG
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
<whitequark>
tpw_rules: yeah it's related
<whitequark>
i just haven't really had the time to work on something except for nmigen for months
<_whitenotifier-b>
[nmigen] whitequark commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYlM
<tpw_rules>
i mean i'm not expecting or waiting for an implementation from you
<whitequark>
tpw_rules: i kinda wanted a regalloc from the start
gregdavill_ has joined #nmigen
gregdavill has quit [Read error: Connection reset by peer]
<awygle>
would the regalloc be mandatory, opt in, or opt out?
<whitequark>
this installs the python bits, which was actually the least annoying part of the process
<trabucayre>
I need to document this...
<trabucayre>
It's near impossible to build this toolchain in only one try
<whitequark>
yep
<whitequark>
trabucayre: anyway, lemme know when you update it and i'll mention it as something less painful and actually working
<whitequark>
less painful than conda
<trabucayre>
Ok!
<trabucayre>
First I need to fix issues, second document and third avoid conda in build time...
<whitequark>
sounds great!
<trabucayre>
I've spent my last weekend to build a toolchain!
<trabucayre>
to find howto build to be more precise
jeanthom has joined #nmigen
_whitelogger has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 246 seconds]
<trabucayre>
whitequark: script failure is no only my fault, with symbiflow-arch-defs repository hash used last week the build is success, with the current HEAD the build fail
<whitequark>
right
<whitequark>
maybe checkout a specific commit?
<trabucayre>
I'll try first with the good commit to have a script working. After that, I'll trying to fix script with HEAD
<trabucayre>
but It's usually better to use a specific commit instead of branch
jeanthom has quit [Remote host closed the connection]
Ekho has quit [Ping timeout: 244 seconds]
Ekho has joined #nmigen
<lkcl_>
trabucayre, whitequark: my friend phil asked a friendly ISP to set the MTU to 500 and they actually did it (gosh).
<lkcl_>
he told me that one of the reasons why ISPs set MTUs so large is so that they can "win" the "speed wars" by reducing UDP/TCP packet overhead... sigh
<lkcl_>
trabucayre: i'm on a mobile 3G/LTE connection, using three mobile. it's... ok. better than 128k/s ADSL. if you're in the UK, smarty are doing a deal: unlimited data for GBP 20/month. they're a 3rd party ISP on Hutchinson Lab's network.
<lkcl_>
of course if you're _really_ out in the middle of nowhere, 3G/LTE might not work :) to compensate for that, we got a high gain antenna for the 3G/LTE hotspot and it does well. except when it rains :)
<trabucayre>
lkcl_: thanks but I live in France and I'm quite near the middle of nowhere :)
<lkcl_>
whitequark: i successfully built nextpnr-ecp5 (and its dependency) without GUI, python *or* boost, and it was successful, worked, and is one heeelll of a lot smaller.
<trabucayre>
Usually to sent big files I use my laboratory connection :)
<lkcl_>
trabucayre: :) ah, then if you get any kind of mobile phone signal _at all_, try a Hong-Kong-based PokeFI. they are international roaming yet only charge USD $3 per gigabyte and they *don't* steal your money after only one month. we have two, for emergencies.
<lkcl_>
trabucayre: directional antennae to the lab? Mikrotic's equipment can do 50 km :)
<lkcl_>
you got line of sight to the lab? teehee
<whitequark>
lkcl_: pretty sure you can't build nextpnr without boost
* lkcl_
double-checking the config.log on the builds, 1 sec
<whitequark>
the actual code is less than a megabyte iirc
<lkcl_>
whitequark: i investigated the vcd symbols issue that jacob raised. nmigen is actually outputting zeros into the vcd file, which is legally and correctly formatted
<whitequark>
sure. can you produce an MCVE?
<whitequark>
I've checked some of the designs I use to test (Minerva mostly) and they're ok
<whitequark>
so it's some combination of what nmigen does and what you're doing
<lkcl_>
interestingly, where (from alan's commit, 303ea18) the vcd file will contain Enum names / string info, there's not even those enum names. i checked a diff
<lkcl_>
whitequark: oof. that's a lot of work. the DIV unit is... massive for a reason. i'll see if there's a smaller example to start from, that would be far less work.
<whitequark>
you could also bisect nmigen
<lkcl_>
give me some time to check some of the other code and some of the examples we have (ones that also do pipelining)
<whitequark>
i don't think there are any breaking changes between 303ea18 and current master
<lkcl_>
i did (manually).
<whitequark>
i'm not sure why jacob wasn't able to bisect it
<whitequark>
oh. which commit is the issue, then?
<lkcl_>
i found that the commit immediately before alan's one broke things, the one with pysim.back. after 10 minutes i stopped the simulation, it was just locked up 100% CPU
<lkcl_>
then the one that got things "working" again (simulation-wise, not vcd wise) was back.pysim: only extract signal names if VCD is requested.
<lkcl_>
6d417568ad6
<lkcl_>
give me a mo to check if there's any simpler examples that also have (validly-written) zeros in the vcd file
<whitequark>
lkcl_: ahhh i see
<lkcl_>
ehn. odd/obtuse. the multiply pipeline works perfectly fine.
<whitequark>
right so i think i can give you a patch you can apply on top of 2606ee33a that fixes it
<whitequark>
i know what the "lockup" is (it's not a lockup, i just pessimized it by a very high constant factor)
<TD-Linux>
I noticed that litex has a wishbown down/upconverter
<TD-Linux>
would it be acceptable to port that to nmigen-soc
<lkcl_>
hmm it's actually really tricky to create a MCVE, here, because this is pipelines. each stage's input and output data format critically define the relationships to the previous and next stages... *and* to the "manager" of the pipeline.
<whitequark>
Lofty: yep
<whitequark>
TD-Linux: there's already a PR
<TD-Linux>
ah thanks. I guess I can review it
<TD-Linux>
and maybe add the downconverter if the original author doesn't want to
<lkcl_>
whitequark: btw, we have a POWER9 simulator of the div instructions (in python of course). the nmigen HDL simulation *still gives correct values* compared to the python-based POWER9 ISA simulator, even when the vcd file's output is incorrect.
<whitequark>
sure
<lkcl_>
TD-Linux: we'd appreciate it (and be interested).
<lkcl_>
whitequark: i just wanted to emphasise that, that it appears only to be the output to the vcd file, rather than the alternative error: "actual nmigen Simulation producing zeros" which it definitely isn't. strangely, glancing through the (17,000!!!) vcd signals, _some_ signals are non-zero.
<lkcl_>
ack
<lkcl_>
ah that's pretty simple :)
<whitequark>
yes, which is why i overlooked it
<whitequark>
it causes minerva VCDs to blow up 20x
<whitequark>
so what happens there is instead of placing the traces for a signal on every hierarchy level where the signal is used,
<whitequark>
it places the traces for every signal on every hierarchy level
<whitequark>
so if you have a heavily hierarchical design the constant factor will be extremely high
<whitequark>
worse, until recently pyvcd did not have aliases
<whitequark>
so if a signal was used in 20 modules, i would actually have to dump it 20 times
<whitequark>
speaking of which
<lkcl_>
urk
<lkcl_>
yeah we're looking at 872k vcd files for running a single instruction.
<lkcl_>
the MUL pipeline, running 100 simulated instructions, is 1.7 mbytes.
<lkcl_>
it looks like that was it - give me a moment to check a more complex operation
<lkcl_>
whitequark: yeah that's good.
<lkcl_>
yeah it's a 5-level-deep class hierarchy for the DIV pipeline. that's not even embedded in a core: it's the *pipeline* unit test!
<lkcl_>
GPUs are... yeah :)
<_whitenotifier-b>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JJY2D
<_whitenotifier-b>
[nmigen/nmigen] whitequark 0a90aa1 - sim.pysim: use VCD aliases to reduce space and time overhead.
<whitequark>
this should make VCD dumps somewhat faster and a lot smaller
<_whitenotifier-b>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJY2y
<_whitenotifier-b>
[nmigen/nmigen] whitequark 9ed648a - Deploying to gh-pages from @ 0a90aa1b1709fcfce48751c345b4b466ac09fc1e 🚀
<lkcl_>
whitequark: interestingly, div_simulator.vcd increased in size. 1.1mb (up from 872k)
<lkcl_>
but, i had to use master (not 2606ee33a) so it's not a fair comparison
<whitequark>
increased in size between what and what?
<lkcl_>
ahh against HEAD-1, yes absolutely. HEAD-1 (previous commit) was 1.5mb
<whitequark>
ah yep
<whitequark>
so i think there actually were some signals that weren't dumped before at all
<TD-Linux>
oh nice the author of that pr also made a ao68000 nmigen-soc wrapper
<TD-Linux>
time to compare mine and see what I did wrong
<lkcl_>
but the vcd file from 2606ee33a was only... ah yes most likely
<lkcl_>
TD-Linux: oh! that'll be Staf Verhaegen, am i right? :)
<TD-Linux>
yes. in a rare turn of events I've met him irl but don't know what his irc handle is
<lkcl_>
Staf's doing a retro-controller project and also he's acting as the bridge between Foundries and Libre/Open Silicon projects
<lkcl_>
he signs NDAs so that you don't have to
<whitequark>
Staf made a pretty significant contribution to nMigen's architecture through our discussions of better ASIC support
<lkcl_>
he's working with Jean-Paul from Sorbonne University on a version of nsxlib and some Cell Libraries (including GPIO pads) so that you can create a *full chip layout*, then give him the scripts to run it, and he will substitute the "real" Foundry Cell Libraries
<whitequark>
well, none of the ideas we worked out are implemented yet, but he provided some major insights that will come in useful
<lkcl_>
whitequark: yeah he's extremely knowledgeable. as a community in general we're damn lucky to have him
<lkcl_>
he worked in the silicon industry and got fed up of the NDAs, the duplication that comes from that, and the artificially-high cost of silicon as a result
<lkcl_>
fantastic
* lkcl_
still hasn't had that coffee. kettle boiled 10 mins ago though :)
<lkcl_>
Staf will be doing the "final completion phase" for us of the Oct 2020 tape-out. as it's funded by NLNet, and is only 180nm, it doesn't "matter" so much, acting more of a test case for the entire concept, more than anything
<lkcl_>
he's already done one test ASIC back in... april (testing the Libre Cell Libraries)
<whitequark>
we have no established convention for this
<agg>
"danger pins"
<agg>
Sort of want the platform definition to hardcode them to output 0 or 1 and not allow reassignment, wonder if you could have a special pin type or something
<TD-Linux>
either that or a flag to prevent you from acquiring the subsignal
<TD-Linux>
without api changes I think Pins/PinsN, dir="o" plus a scary name would be ok
lkcl__ has joined #nmigen
<DaKnig>
what does the F in nMigen FHDL stand for?
<awygle>
there's already a board definition file for the arty z7
<awygle>
so all you need to do is, in your nmigen script, from nmigen_boards.arty_z7 include ArtyZ7Platform
<FL4SHK>
that's what I mentioned earlier
<FL4SHK>
DaKnig is here at the behest of me
<awygle>
then instantiate it with platform = ArtyZ7Platform(top_module)
<awygle>
and build it with platform.build()
<DaKnig>
aweygle thanks.
<whitequark>
DaKnig: "FHDL" as a whole is a legacy name we should just get rid of to reduce confusion
<whitequark>
technically "F" means "Fragment" but it's no longer important
<DaKnig>
I see
<cr1901_modern>
Back when nmigen was new, I tried writing down notes between the differences of an "omigen" fragment and "nmigen" fragment. Well, that didn't happen. And probably won't happen now :(.
<FL4SHK>
so I've decided to make an AST of sorts in my assembler
<FL4SHK>
...but only for expressions
gregdavill_ has joined #nmigen
<FL4SHK>
expressions can only be integers
<FL4SHK>
32-bit ones, to be specific
<FL4SHK>
any use of an immediate value produces either a 32-bit immediate or a smaller one
<FL4SHK>
32-bit immediates end up getting encoded into a `pre` instruction containing the top bits and then the actual instruction
<FL4SHK>
so `pre; add` for example would allow add immediate to use a 32-bit immediate
<FL4SHK>
`pre` is an actual instruction that exists
<whitequark>
my preference would be to keep improving nmigen-stdio and nmigen-soc to the point where litex would be much "thinner"
<whitequark>
nmigen-soc specifically considers e.g. building linux out of scope
<whitequark>
so litex (or something like it) would *always* have a place in the nmigen ecosystem
<whitequark>
but i'm hoping we don't duplicate basic cores
<whitequark>
right now my focus is on docs and then on streams, which are foundational for any kind of SoC or really any serious FPGA project
<mithro>
What is in nmigen-stdio?
<whitequark>
right now? a slightly broken UART
<whitequark>
what should be? all sorts of I/O that *isn't* inherently tied to SoC buses
<whitequark>
so there is a separate UART, Ethernet, SPI etc cores that just use streams (similar to AXI4 Stream)
<whitequark>
and then in nmigen-soc there are wrappers that expose them to a SoC
<whitequark>
my thoughts are that SoCs are fun, but building things without needing a SoC can be far more powerful
<whitequark>
so the split is ideal
<whitequark>
of course some things can't really be split
<awygle>
what would be an example of such?
<whitequark>
I was thinking of memory controllers, but the more I consider it, the more I wonder if it's a failure of imagination
<awygle>
(also don't forget cxxsim when enumerating your focuses :)
<awygle>
yeah i was thinking about that too, i think i can imagine e.g. a DDR2 controller where much of it is in nmigen-stdio
<whitequark>
cxxsim is nearly done
<whitequark>
there's maybe a day or two of work left?
<whitequark>
i'm just having like... a weekend
<whitequark>
first in a long time
<mithro>
whitequark: Is there a split between "interfaces for IO / connection" and cores that use those interfaces at all?
<mithro>
whitequark: I was wondering if there was a way we could merge litex-boards and nmigen-boards -- I like a lot of how nmigen-boards works better....