<_whitenotifier-b>
[nmigen] FFY00 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmr8
<d1b2>
<Qyriad> awygle: even accepting fewer arguments than the (abstract) base?
<awygle>
yep. i did `def lower(): pass` even, it didn't even take `self`
<d1b2>
<Qyriad> that is mind boggling
<awygle>
"dynamic typing go brrr" i guess
<awygle>
on the other hand this file also contains a list of lists of classes, so maybe i shouldn't knock it too hard
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrR
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrR
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrR
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrR
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmro
<awygle>
so for a custom decoder on a UserValue i'd want to pass it to the thing i return from lower()'s constructor, right? since that's what'll be printed later
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmro
<awygle>
oh decoder is only on Signal... hm
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrX
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrX
<whitequark>
awygle: only signals go to VCD
<whitequark>
Qyriad: python abstract methods really are quite useles
<whitequark>
they're more for documentation than anything
<whitequark>
well, also for making your life harder due to all the metaclass crap going on
<whitequark>
I'm slowly leaning towards ripping out the use of ABCMeta in favor of just `raise NotImplementedError`
<whitequark>
they're both bad, just in different ways
<whitequark>
the fact that you can't have an abstract property on the class itself without jumping through some absurd hoops is also disconcerting
<d1b2>
<Qyriad> I have historically used raise NotImplementedError, though that's mostly because I only relatively recently learned abstract methods were a thing
<awygle>
whitequark: hm i see how that makes sense. so if i want a decoder for my custom UserValue it should probably be a static method i can pass to a Signal constructor's decoder= kwarg
<d1b2>
<Falteckz> I'm surprised how fast the simulator runs. Only a few seconds to run a second at 16MHz
<whitequark>
falteckz: which one?
<whitequark>
awygle: think so
<whitequark>
which UserValue is that?
<awygle>
my DDR2 opcodes
<FFY00>
abstract methods are not designed for type checking
<FFY00>
in fact, nothing in python is
<FFY00>
for that you should use type annotations and a type checker (hint: mypy)
<awygle>
i asked a question in #python earlier that also gave me a chance to say this but i didn't because of where i was, so - implying anything in python is designed at all
<whitequark>
mypy: not only it is unsound by design, but also requires using strings to forward-declare types
<whitequark>
awygle: i almost concur
<awygle>
i also almost concur
<whitequark>
i would put it as "nothing in python is designed to the point where you can actually rely on it"
<awygle>
like many things i say this is an exaggeration of my true feelings but directionally accurate
<whitequark>
it has tons of features, each of these has had a lot of thought put into it, but not enough thought that you can actually stop caring about accidentally misusing it
<FFY00>
python is not designed for design
<whitequark>
lol yes
<FFY00>
just make it work (tm)
<whitequark>
nmigen does so many things against the grain of python
<whitequark>
for example, pervasive use of isinstance()
<FFY00>
python gives you a way to scale apis very well, since you can basically re-write the whole thing a bunch of times and still keep the same public api
<awygle>
isinstance is the best
<FFY00>
but by doing this, it is more unsafe than c
<whitequark>
python doesn't even let me ensure i can keep changing the internals of my API
<FFY00>
what do you mean?
<whitequark>
what is a breaking change? literally any change to any publicly reachable name
<whitequark>
because people could have depended on it
<whitequark>
i guess you can change the implementation of a function.
<FFY00>
right
<whitequark>
that's it, everything else is potentially breaking to user code
<FFY00>
eh
<FFY00>
_methods are pretty well known to be private api
<FFY00>
people shouldn't be depending on it
<FFY00>
or if they are, they should be aware of what it means
<whitequark>
well, people shouldn't depend on accidental behavior too, but as systems evolve, this happens inevitably
<FFY00>
at least that is public api
<whitequark>
the only things people don't depend on are the things you intentionally break (or otherwise make impossible or very hard to depend on)
<FFY00>
even if unwanted :P
<awygle>
the signature of a decoder function is f(int)->string, right?
<whitequark>
once i finish the documentation, it's going to contain the clause that "if you use anything not expressly documented you're on your own"
<whitequark>
which is actually a major impetus to finish the documentation for me
<whitequark>
make it clear what actually *is* the public API, not only in terms of functions and arguments but also behavior
<awygle>
i wonder what happens if a discord user +1s an IRC user on the bridge
<whitequark>
the docstrings and rst files are the source of truth, code is merely incidental
<FFY00>
> behaviors
<FFY00>
that's the critical part
<whitequark>
sure
<whitequark>
i mean, it's at the very core of nmigen that it doesn't produce a specific Verilog output or even a specific netlist
<whitequark>
it just gives you *some* semantically equivalent netlist for the input you gave it
<whitequark>
like most compilers
<whitequark>
awygle: probably nothing
<whitequark>
and yes, f(int)->string
<awygle>
cool thx
<whitequark>
the string shouldn't be "too weird" or gtkwave will choke on it
<whitequark>
what is "too weird": i don't know, read gtkwave source code
<whitequark>
yes i did just functionally tell you to go fuck yourself, though i am more of a proxy in this situation
<whitequark>
i escape spaces because those just broke too many things
<whitequark>
i'm sure there are other characters i don't escape that will break more things
<awygle>
lol
<awygle>
duly noted
<whitequark>
yes i do find this incredibly depressing why do you ask
<awygle>
god we really need to replace gtkwave
<whitequark>
it doesn't even produce a syntactically valid vcd if you put a string in there
<awygle>
but it has to live at the back of the queue by virtue of being just good enough
<whitequark>
it's "gtkwave vcd"
<whitequark>
as opposed to other standardized and not totally gtkwave specific formats like "fst"
<awygle>
somebody pay me to build a gtkwave replacement plzthx
<whitequark>
for which you can easily find documentation and conformance tests
<whitequark>
and which are absolutely and unapologetically not defined by like five kloc of awful c code
<awygle>
yeah fst is great. i did a rust wrapper for that once
<whitequark>
i'm so sorry
<awygle>
eh it was fine tbh
<awygle>
the implementation definitely contains horrors tho
<whitequark>
ah you wrapped the gtkwave stuff
<awygle>
yeah
<awygle>
... i wrote this decoder function as though the input was a Signal and now i can't remember how to bit_select an integer in python.
<whitequark>
(x >> n) & 1 ?
<awygle>
....yes.
<awygle>
obviously. wow. what a fucky vaporlock.
<whitequark>
lmao
<awygle>
i'm not at my best today wq, i dunno what to tell you lol
<whitequark>
eh it happens
<d1b2>
<Darius> huh I always do mask then shift
<_whitenotifier-b>
[nmigen] cr1901 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmoI
<whitequark>
doesn't matter really; if your mask is variable width you save one left shift
<whitequark>
so it looks a lil cleaner
<awygle>
wow these custom decoders are awesome though
<awygle>
so much easier to read stuff
<d1b2>
<Falteckz> whitequark: "Which one" the nMigen default simulator used in the example. I know not of any other
<whitequark>
awygle: :D
<whitequark>
Falteckz: ok so that one is actually really slow
<whitequark>
i'm working on a much faster one
<awygle>
in fact i've already found a bug
<d1b2>
<Falteckz> whitequark I'm excited for something faster. WASM?
<whitequark>
falteckz: nope, your c++ compiler
<d1b2>
<Darius> wq: oh good, I was worried you would reply with "doing mask then shift will break subtly under some circumstances" and I'd have to change a heap of code
<awygle>
it's also easier imo to shift then mask if you're generating the mask from the number of bits (as i am in this case)
<awygle>
or at least clearer
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmoz
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmow
<awygle>
.... i should stop waiting the prescribed 200uS for imaginary power rails to stabilize in my simulation code
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmow
<whitequark>
yeah
<whitequark>
this hits the glasgow simulated applets pretty badly
<whitequark>
switching to cxxrtl might make simulations there a lot more realistic
<awygle>
look forward to me in a month going "so i figured out my RAM was unreliable because i never changed that 2 microsecond wait from simulation back to a 200 microsecond wait"
<whitequark>
i *hope* that with cxxrtl it'll stop being excruciating
<d1b2>
<Falteckz> whitequark: something like verilator?
<whitequark>
yeah, cxxrtl is similar to verilator, it's just not trying to be a linter at the same time, and isn't tied to verilog
<d1b2>
<Falteckz> Where does this project live currently?
<d1b2>
<Falteckz> Ah ha! I was looking at whitequark/yosys. Oops
<whitequark>
i spent something like 2 months of it and i get around 50% of verilator performance typical case (up to ~100% in some cases)
<whitequark>
on it*
<whitequark>
this is for a few reasons
<whitequark>
partly because i could reuse yosys for all the things that yosys does well, like parsing verilog or transforming netlists
<whitequark>
partly because i am relying on a C++ compiler much more heavily than verilator
<whitequark>
partly because i use an inherently simpler compilation model than verilator which doesn't scale quite as well
<d1b2>
<Falteckz> I might be somewhat alone in this opinion, I don't know. But if it fits well into the nMigen ecosystem and isn't painfully slow ( I don't mind a few sips of tea while I wait ) then I'm happy. I realize Yosys is a bit more vast than that, you've other upstream frontends to care about.
<whitequark>
I'm not really sure what this opinion is about? like what software component
<d1b2>
<Falteckz> You made several points that it's slower than verilator.
<d1b2>
<Falteckz> From this I suggested that the 50% slower speed is no consequence to me personally if it means it just works easy with the toolchain I'm already using
<whitequark>
yeah, it can only simulate a RISC-V CPU at more than half a million instructions per second on a laptop CPU
<whitequark>
instead of about a million or so
<awygle>
honestly wq you shit on pysim a lot (and you have reasons) but it's really excellent in its own right, let alone cxxrtl which is amazing
<whitequark>
awygle: i ... guess
<whitequark>
i mean, the computational core of pysim isn't bad
<whitequark>
the "pyrtl" part
<whitequark>
i'm mostly complaining about the implementation, which was done in a rush and without an especially deep understanding of the domain
<whitequark>
also: i wrote it, i can criticize it :p
<awygle>
yeah i get that. and also, it's so cool that i can hack up a unit test in like, 30 seconds and it just works :p
<whitequark>
true
<whitequark>
i forget how low are the standards of folks doing EDA :p
<whitequark>
for me, "it works" is the lowest possible bar
<awygle>
oh god it's 6pm how did that happen. i should feed myself, probably...
<d1b2>
<Falteckz> My standards are higher for software engineering.
<d1b2>
<Falteckz> But the state of hardware is awful in comparison
<d1b2>
<Falteckz> So yes, nMigen, pysim, all beautiful
<d1b2>
<Falteckz> I can actually pip install an OSS toolchain to build FPGA bitstreams, and I can pip install HDL submodules to strap to the side of my implementation
<d1b2>
<Falteckz> It's all very good
<whitequark>
yup
<d1b2>
<Falteckz> Though I respect your aspirations for "it can be better and I will make it better!!"
<sorear>
extremely terrible idea: simulator platform that generates wasm directly so you can use it with yowasp with a minimum of extra components
<whitequark>
yowasp doesn't export a wasm engine
<whitequark>
it gets worse
<whitequark>
if you want simulation you pretty much have an arbitrary width integer implementation with rich arithmetics, which means you basically need clang.wasm
<whitequark>
i will not ship yowasp-clang.
Degi has quit [Ping timeout: 272 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
<d1b2>
<TiltMeSenpai> I've thought about webasm hosted clang or gcc before... then quickly realized what that entails and pushed those thoughts out of my mind
<sorear>
"minimum of extra components" was meant more or less specifically to exclude shipping 100MB of gcc or clang for wasm
<whitequark>
sorear: the whole point of using cxxrtl is to not reimplement the things gcc/clang do
<whitequark>
sorear: most wasm runtimes are optimized to run the code emitted by clang
<sorear>
I'm assuming that most of the midend optimizations are not really applicable to simulator code (going to loop invariant code motion … what exactly?)
<whitequark>
you need very heavy constant folding and inlining
<whitequark>
especially the latter
<whitequark>
does wasmtime even *have* an inliner?
<whitequark>
i *think* it doesn't?
<whitequark>
also, generating "dumb wasm" is actually hard
<sorear>
conveniently those are the two easiest by far optimizations to include in a code generator
<whitequark>
i'm going to have to do chunk-wise arbitrary width arithmetics myself, because wasm gives me any integers as long as it's i8, i16, i32, i64
<d1b2>
<Falteckz> I assume "i64 all the things" is incorrect
<whitequark>
Falteckz: nothing prevents you from having a 300 bit wide signal
<whitequark>
in practice, in something like a 64-bit CPU, having 65-bit signals is common and normal
<whitequark>
(it's just 64-bit addition with overflow)
<whitequark>
(well, carry)
<d1b2>
<Falteckz> You're right and I'm mortified. But also surprised that compilers support it at all
<whitequark>
compilers don't
<whitequark>
cxxrtl does
<d1b2>
<Falteckz> Because clang does?
<whitequark>
clang doesn't
<whitequark>
well... there's the _ExtInt proposal
<d1b2>
<Falteckz> I see. I misunderstood that. I thought that was something you got out of clang
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmKH
<whitequark>
no, what i got out of clang is different
<whitequark>
i implemented arbitrary width arithmetics in dumb c++
<whitequark>
that is relatively easy to verify but pretty inefficient
<whitequark>
then i relied on clang's many optimizations (loop unrolling, constant propagation and inlining for most part) to turn that into the assembly you'd exepct
<d1b2>
<Falteckz> I see. Implement it and let clang optimise it
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmK7
<whitequark>
yes
<whitequark>
sorear: what i could in theory do is "generate dumb llvm ir"
<whitequark>
which would work if llvm ir actually worked like you'd think it works, which it doesn't
<sorear>
the lack of anything related to carry bits in wasm may be more of a problem
<whitequark>
there are no carry bits in c+++ either
<whitequark>
*c++
<whitequark>
i could, certainly, take cxxrtl and expand it into wasm as a sort of macro
<whitequark>
i don't do it because i specifically would like to avoid that
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmKb
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmKb
<FFY00>
whitequark, is there even a way to pass arguments to toolchain_program?
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6e
<d1b2>
<Falteckz> I wonder if having open tool forge installed on my path could cause issues
<d1b2>
<Falteckz> I really hope not because I didn't do well to make that installation reversable
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6n
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6n
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6n
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6n
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJm6l
<_whitenotifier-b>
[nmigen] whitequark closed issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwM
<whitequark>
FFY00: the problem with factoring toolchain_program out is that you can't build an abstraction over openocd et al that doesn't, over time, turn into a poor replica of openocd's CLI
<whitequark>
and I very specifically do not want that to happen
<whitequark>
sure, there is a minor advantage that the consistency of some names is enforced, but at a massive cost. we can just do the same thing in code review (it would be the easiest part of the review, really) with none of the cost
<FFY00>
because the CLI might change?
<awygle>
i was disappointed to learn this wasn't about the "i have multiple boards plugged in" case tbh
<whitequark>
that's a complete hypothetical
<whitequark>
openocd radically changing its CLI in a way that affects all of the boards equally, that is
<d1b2>
<Falteckz> awygle: Same
<d1b2>
<Falteckz> awygle: Though at first I thought it was some peer programming thing haha
<whitequark>
what *can* happen is openocd changing its script interface in subtle ways that you can't really detect or fix other than by having a real board
<awygle>
i currently have two different people remotely accessing a board in my lab and i live in fear of them accidentally colliding
<whitequark>
and an abstraction gets in the way of debugging and fixing this kind of issue because it's just one more layer you don't care about
<awygle>
although i didn't make that easy on myself because they boards don't have serial numbers
<whitequark>
awygle: yes, *that* we actually should fix
<awygle>
so i'll probably have to use linux magic to restrict boards to user accounts somehow
<whitequark>
and i suspect it might not be easy because... yeah
<whitequark>
the last section specifically deals with serials
<FFY00>
whitequark, the interface as I envisioned would not be an issue for the case of openocd changing its script interface
<FFY00>
only the CLI
<FFY00>
but yeah
<FFY00>
no worries :)
<whitequark>
i think guarding against openocd changing its CLI is completely pointless
<awygle>
i have done that before, but i believe the FTDI parts keep their serial numbers in EEPROM, which this board doesn't have
<whitequark>
if they decide to screw their entire userbase, it is not our job to fix that
<d1b2>
<Falteckz> "It works out well in the small: reusing variables for different purposes is an ever-present source of bugs. It’s less successful elsewhere: although one class might do two things in a rather nasty way, disentangling it isn’t of much benefit when you end up with two nasty classes with a far more complex mess of wiring between them." Heh, your feelings towards pyrtl, whitequark?
<whitequark>
it has a paragraph dealing *specifically* with this issue
<whitequark>
>The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need.
<whitequark>
"what if openocd changes its CLI" is the preemptive guessing in this case
<FFY00>
I'll have a look
<awygle>
that's tef's blog right?
<FFY00>
but I agree with that
<d1b2>
<Falteckz> Heh I'm reading the same post
<FFY00>
abstracting has very real drawbacks
<whitequark>
FFY00: it's entirely possible that some more time passes, it turns out that there *is* a good abstraction there after all, so then we just... change our mind and introduce one
<FFY00>
we should only use it when makes sense
<whitequark>
but for now, i've thought about it and decided it doesn't make sense at this point
<whitequark>
awygle: yep
<FFY00>
okay
<awygle>
i actually almost quoted this post at you earlier about pysim vs cxxsim
<d1b2>
<Falteckz> ^ That was my quote just now
<d1b2>
<Falteckz> Well - no, that was my intent
<d1b2>
<Falteckz> I don't know if it were the same quote
<awygle>
mhm
<whitequark>
awygle: ha, well
<whitequark>
the thing is that i considered just duplicating the entire thing
<whitequark>
in fact that was the original plan
<whitequark>
the problem is that there really is an abstraction lurking somewhere, which i realized after i started writing it
<whitequark>
i mean, i went maybe halfway towards figuring out *what* it is
<whitequark>
pysim is much better now than it was before i started
<whitequark>
so original pysim was one file because i wrote it, figured that it's all super coupled together, and threw it into one module as this amorphous blob. it worked great
<whitequark>
you couldn't use parts in isolation, but they were all internal and easy to delete, so it was all ok
<whitequark>
then cxxsim came, and it turns out that there *are* interfaces along which pysim can and should be split so that some code can be abstracted over it, specifically the coroutine adapter and pyrtl that is used in it
<whitequark>
in general, being able to cosimulate python coroutines with either pyrtl gateware or cxxrtl gateware requires an abstraction
<whitequark>
in other words
<whitequark>
it's not that splitting pysim into pieces feels nice. it's that having both pysim and cxxsim use the same computational core for python coroutines requires splitting pysim into pieces, one of which becomes swappable
<whitequark>
i actually tried (not very hard, but a bit) to design pysim upfront so that parts could be swapped out
<whitequark>
this failed miserably. i had to hunt down all of those parts and rip them out in the recent refactor
<whitequark>
i think literally not a single decision i made at that stage with future-proofing in mind actually stood the test of future
<d1b2>
<Falteckz> "i think literally not a single decision i made at that stage with future-proofing in mind actually stood the test of future"
<d1b2>
<Falteckz> How do I retweet that
<whitequark>
just tweet it with <@whitequark> at front
<whitequark>
or something
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
<awygle>
yeah i chose not to mention it because i assumed you'd considered and rejected it
* whitequark
nods
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel_ has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
<whitequark>
Falteckz: how are you running the tools exactly?
<whitequark>
I'm having trouble reproducing this
<d1b2>
<Falteckz> On Windows in Git bash, with all Python stuff in a venv
<d1b2>
<Falteckz> I'll get a paste of the script I'm calling...
<whitequark>
argh
<whitequark>
so *this* is why it has a `build_sh` file that has \r\n line endings
<whitequark>
do you get a bunch of random errors too?
<whitequark>
ok, so the file actually *does* end on the line 20800
<whitequark>
that's interesting
<d1b2>
<Falteckz> Correct
nurelin has joined #nmigen
<d1b2>
<Falteckz> It actually ends on line 20816 from open forge
<d1b2>
<Falteckz> 20800 for yowasp
<whitequark>
fun bug
<d1b2>
<Falteckz> Alright, so the repro is: You can build with yowasp and then yowasp again, fine. You can build with OTF and then OTF, fine. You can build with yowasp producing a 20800 line top.json and then build with OTF producing a 20816 line top.json, fine. However, if you then build with yowasp, the top.json file bloats and becomes invalid. Building with OTF and then deleting top.json and then building with yowasp does not produce this error. Meaning that the
<d1b2>
presence of top.json and it being generated by OTF is important to the fault.
<whitequark>
yep
<whitequark>
i think wasi-common doesn't truncate files on windows
<d1b2>
<Falteckz> Last test then I guess... I'll make the file smaller
<d1b2>
<Falteckz> Yep, it's bytes not lines. Confirmed.
<d1b2>
<Falteckz> Cool.
<d1b2>
<Falteckz> Makes sense to be honest, OTF has a longer installation path so will make the file somewhat larger
<whitequark>
it's a wasmtime bug i think
<whitequark>
really weird one
peepsalot has quit [Quit: Connection reset by peep]
<d1b2>
<Falteckz> Kinda annoying. I'm going to be selfish and just add shutil.rmtree('build') to my build script.
<whitequark>
i'll report and/or fix it soon
<d1b2>
<Falteckz> I appreciate that. Thanks.
emily has joined #nmigen
jfng has joined #nmigen
<awygle>
not sure if "decoder codepath forces evaluation in unexpected situations" counts as "decoder finds bug" but if it does the decoder bug count is up to 2 already
<awygle>
protip - size your constants if you care about bit widths
peepsalot has joined #nmigen
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
_whitelogger has joined #nmigen
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 272 seconds]
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 246 seconds]
chipmuenk has joined #nmigen
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 258 seconds]
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 258 seconds]
hitomi2504 has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 256 seconds]
Asu has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 256 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #nmigen
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 260 seconds]
Asu has left #nmigen ["Konversation terminated!"]
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 260 seconds]
jeanthom has joined #nmigen
jaseg has quit [Ping timeout: 246 seconds]
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 258 seconds]
jaseg has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 256 seconds]
peepsalot has quit [*.net *.split]
proteus-guy has quit [*.net *.split]
proteus-guy has joined #nmigen
peepsalot has joined #nmigen
<_whitenotifier-b>
[nmigen] Fatsie commented on issue #425: Support for PLL primitives - https://git.io/JJmNl
<_whitenotifier-b>
[nmigen] Fatsie edited a comment on issue #425: Support for PLL primitives - https://git.io/JJmNl
<d1b2>
<Falteckz> Do you think it'd be possible to load, say, a VCD file into a simulation?
<d1b2>
<Falteckz> I was thinking, how do we prove at a system level that something like an I2C implementation they we have written does the job? Then I thought, well it needs to be tested against a known good. Sure I can write my own asserts and so on, but what do I know about the tricky timing and clock edges of I2C? Nothing! So surely I would want some sort of truth to compare against. Then I wondered, what if I had a simulated initiator and I write the I2C target
<d1b2>
and test that my part does what the initiator expects
<d1b2>
<Falteckz> Does that kind of testing exist?
<agg>
yea, it's common to test against a vendor-provided 'model' of e.g. a memory device or perhaps an i2c peripheral
<agg>
usually it would be behavioural (i.e. react to what you send it) rather than a static vcd file that you have to match though
<d1b2>
<Falteckz> I guess I was thinking it wouldn't be reactionary/behavioral and instead would be driving the target and then the targets response is verified. Opposite direction to what you describe. But I can see the merit in behaviors
<_whitenotifier-b>
[nmigen] GuzTech commented on issue #425: Support for PLL primitives - https://git.io/JJmpU
zignig has quit [Remote host closed the connection]
<_whitenotifier-b>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JJmpD
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #425: Support for PLL primitives - https://git.io/JJmpD
<_whitenotifier-b>
[nmigen] GuzTech commented on issue #425: Support for PLL primitives - https://git.io/JJmpd
mithro has quit [Ping timeout: 256 seconds]
<_whitenotifier-b>
[nmigen] GuzTech edited a comment on issue #425: Support for PLL primitives - https://git.io/JJmpd
mithro has joined #nmigen
chipmuenk has joined #nmigen
<jeanthom>
How to do you check for equivalences in nMigen? I'm currently doing Assert(~(stmtA ^ stmtB))
<whitequark>
stmtA == stmtB ?
<jeanthom>
that would work?
<whitequark>
why not?
<whitequark>
Asserts aren't special, they just take a boolean expression
<jeanthom>
I thought that == between to statements wouldn't work but it turned out my spec was faulty
<jeanthom>
Nevermind...
<awygle>
Good morning all
<Lofty>
Morning awygle
<whitequark>
hi awygle
<jeanthom>
hi
<whitequark>
Falteckz: reproduced your bug on wine
<ktemkin>
https://twitter.com/ktemkin/status/1281083448816361473 <-- btw, whitequark: when you have a minute, want to talk over this with me to see if we can make what I'm going to do as reusable for general-nMigen as I currently can?
<FL4SHK>
now having to figure out what to do about the symbol table
<FL4SHK>
disclaimer: I'm building up a multiple-unnamed-scopes symbol table
<FL4SHK>
similar to just doing { ... } in C++
<FL4SHK>
this is for my assembler that I'm implementing like boneless's assembler
<tpw_rules>
FL4SHK: i made a working but not feature complete register allocator for the assembler too
<FL4SHK>
tpw_rules: oh? that's neat
<tpw_rules>
if you were interested in some of those sorts of ideas
<FL4SHK>
I do need to make a register allocator of sorts for one of my projects
<tpw_rules>
i really want to finish it though to at least my ideal. half of it is comments explaining how it works if you would like a link
jeanthom has joined #nmigen
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #nmigen
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
<awygle>
Did you do graph coloring or what?
<awygle>
(tpw_rules)
<tpw_rules>
yeah
<awygle>
cool
<tpw_rules>
there's nothing special about it really. but it was my first time doing that sort of stuff
<awygle>
yeah for sure
<awygle>
i have like half of a reverse linear scan allocator for a JIT i was writing, it's super fun
<tpw_rules>
the big limitations are that it can't spill (questionable how you do that nicely so it doesn't e.g. dump memory accesses in your timing loops) and it doesn't have a conception of the ABI so you have to instance it separately for each function and instruct it to preserve your input and output register assignments
<tpw_rules>
but it's neat. wq had an idea of some sort of turbocharged assembler so you didn't have to step up to C but it still got a lot of the drudge work done. i'm hoping this can eventually find a place in something like that
<tpw_rules>
(no idea if this is in any related to that vision. but that's what inspired it for me)
<awygle>
yeah i'd love to do something like that too honestly