<jeanthom>
this is simulation code, not synthesizable at all
<jeanthom>
I was thinking about simulating this in pysim
<whitequark>
aha so I have two approaches
<whitequark>
approach 1 is to rewrite it as a pysim process
<whitequark>
approach 2 is to use Assert()s
<whitequark>
the latter should suffice for violations but not just random debug info
<whitequark>
right now pysim doesn't accept Assert()s but that's fixable
<_whitenotifier-b>
[nmigen] GuzTech commented on pull request #426: [WIP] Initial implementation of ECP5 PLL instantiation - https://git.io/JJmI3
<jeanthom>
I like the Assert approach
<whitequark>
okay, can you open an issue for Assert support in pysim?
<zignig>
tinyprog -b
<zignig>
sorry , wrong window.
<_whitenotifier-b>
[nmigen] jeanthom opened issue #427: Add support for Assert in pysim - https://git.io/JJmIV
Asuu has joined #nmigen
Asu has quit [Ping timeout: 246 seconds]
<jeanthom>
whitequark, hacked Assert support in pysim, thanks for the advice o/ I'm considering implementing a Log statement now but that would require having a patched nMigen just for running the test suite which is a pain in the neck
<jeanthom>
You don't want to have something equivalent to LiteX's Display because that wouldn't work in cxxsim?
<whitequark>
jeanthom: it could work in cxxsim and it might even work in yosys
<whitequark>
so here's the thing
<whitequark>
if yosys accepts it upstream, no objection to having it
<whitequark>
if yosys does *not* accept it upstream, we live without it
<whitequark>
what's needed is a $display cell, similar to $assert
<daveshah>
That seems pretty reasonable to me
<whitequark>
having a $display cell?
<daveshah>
Yeah
<whitequark>
alright, i'll bring it up on the next meeting
<daveshah>
Dealing with multiple parameters could be a bit tricky
<daveshah>
It would probably have to have $mem style concatenated ports for the varargs
<whitequark>
that's kind of annoying but not that terrible
<jeanthom>
that would be a pretty useful feature
<whitequark>
hm alright
<_whitenotifier-b>
[YoWASP/nextpnr] whitequark pushed 2 commits to release [+2/-1/±2] https://git.io/JJmt4
<_whitenotifier-b>
[YoWASP/nextpnr] whitequark 1c16237 - [skip ci] Add an auto-updater.
<whitequark>
adding the YOSYS= NEXTPNR_ICE40= ICEPACK= whatever environment variables manually is obnoxious
<whitequark>
there's a few possible options
<whitequark>
- installing (optionally, in a different package) launcher scripts without the yowasp- prefix
<whitequark>
this has the problem that it works fine in virtualenv, but not so much elsewhere
<whitequark>
since it would shadow your system yosys and this can cause problems
<whitequark>
it is hard to make a package installable *only* in virtualenv too, and this will likely raise questions
<whitequark>
further, you can't install scripts conditionally, eg if some other package is installed
<whitequark>
that's not how setuptools extras work
<whitequark>
- adding something like `yowasp-run` that spawns a subshell with the environment variables set
<whitequark>
- adding something like `yowasp-env` that can be used as `eval $(yowasp-env)` to set the variables in the shell
<whitequark>
- both
<whitequark>
opinions?
<daveshah>
The yowasp-run option seems tempting
<daveshah>
Perhaps, it could also set up yosys and nextpnr-* commands un prefixed as well as the env vars
<daveshah>
So it could support other existing build systems too
<whitequark>
that would be really challenging to do in a portable way
<whitequark>
so far i was able to rely on knowledge built into setuptools
<whitequark>
actually
<whitequark>
does windows even have something like `source`?
<whitequark>
guess not...
<daveshah>
The way I was thinking about implementing that was a folder containing the scripts that call the yowasp commands
<daveshah>
that would be included in the PATH
<daveshah>
but idk about Windows scripting
<whitequark>
yes but... where do you put it? how do you generate it? etc
<whitequark>
what do you do when you upgrade
<whitequark>
so many questions i really don't want to even consider
<whitequark>
even on linux
<whitequark>
what happens when something does $(which yosys) and captures the path?
<whitequark>
eg cmake
<whitequark>
if we're to support that, it can't be a temporary folder, so i need to find a location to put a persistent folder on all OSes
<whitequark>
you can (and probably should) install yowasp in virtualenv, so the folder would have to be somewhere inside the virtualenv
<agg>
as a convenience could nmigen try to autodetect yowasp prefixed binaries if unprefixed executables aren't found?
<whitequark>
but on the other hand, if you install yowasp system-wide for some reason, it *can't* be in the python root
<whitequark>
agg: i don't like the idea of privileging my own build of yosys in nmigen
<agg>
or even prefer the yowasp ones over the unprefixed ones since they're sure to be the right version and only exist if someone specifically installed them (ideally into the venv)
<whitequark>
it's not inherently better than any other yosys packaging solution
<whitequark>
in fact they can be worse
<agg>
your default without specifying env vars is to privilege the unprefixed ones, right?
<whitequark>
for example if you are using the quicklogic toolchain
<agg>
if those can't be found, but the yowasp prefixed ones do exist on the path, good chance that's what someone wants, and if it's not, they can still set the env vars the same as now?
<whitequark>
agg: well, yes, i'm privileging the ones that upstream builds install
<whitequark>
why should yowasp be preferred over open-tool-forge
<whitequark>
?
<agg>
because it exists on the user's path
<whitequark>
the latter can also exist on the user's path
<whitequark>
PRU can exist on the user's path
<whitequark>
not only this is weird from the perspective of nmigen being toolchain-agnostic, but it also makes things harder to debug
<whitequark>
suppose you have yowasp-yosys but not yowasp-nextpnr
<whitequark>
you pick yowasp-yosys and system nextpnr
<whitequark>
then everything breaks because yosys and nextpnr evolve in lockstep
<whitequark>
well, not lockstep exactly, but there's no long-term compatibility
<agg>
seems like it could be a worthwhile tradeoff for most users to be able to get nmigen working with just some pip installs and without having to write a load of environment variables every time they run python
<whitequark>
yes, which is why i've asked the question above in the first place...
<whitequark>
but putting this logic into nmigen itself creates far more problems than it solves, which is why i don't even consider it an option
<agg>
it seems like the yowasp-yosys and system-nextpnr issue could be avoided: don't you already check for compatible versions?
<whitequark>
no
<whitequark>
i do not check anything about yowasp-yosys
<whitequark>
well
<agg>
so, it's just as hard to debug as if I've upgraded yosys recently and haven't installed a new nextpnr recently?
<jeanthom>
whitequark, what about a TOOLCHAIN_PREFIX in a similar fashion to what you have in the compiler world?
<agg>
which seems about as likely as installing yowasp-yosys and not yowasp-nextpnr, perhaps
<jeanthom>
with YoWASP it would be filled with "yowasp-"
<agg>
specifying one prefix is certainly easier than writing out all the different env vars
<whitequark>
agg: have you actually read my proposal above?
<agg>
I did, I agree it's obnoxious, I agree that installing without prefix could be troublesome
<agg>
I was suggesting a fourth option where you have nmigen autodetect yowasp binaries if there's no system ones so that the user doesn't need to specify or do anything differently after installing yowasp
<whitequark>
okay, so why are you suggesting to put all the discovery logic in nmigen (unfairly privileging yowasp for no actual reason) instead of putting it in yowasp?
<whitequark>
yowasp isn't special
<whitequark>
in fact it is worse than any native build
<whitequark>
perhaps you could say "not better"
<agg>
that's a fair objection, not for me to say how it balances out the user convenience
<agg>
I wouldn't personally object to you making yowasp special inside nmigen, at least to the extent of it being a fallback default if there's no unprefixed toolchain
<agg>
if you don't want to do that it rules out my idea, which is of course fine too
<whitequark>
i don't like automatic fallbacks like that because they add another level of indirection that complicates debugging
<whitequark>
the process of choosing "either $YOSYS or, lacking that, yosys on PATH" is straightforward
<whitequark>
the process of looking whether you have a bunch of random things on PATH (I bet we'll want to add other packages to the discovery process later) is not
<whitequark>
NMIGEN_USE_YOSYS that we have is a necessary evil
<whitequark>
anyway, i understand your suggestion better now. thanks for the input!
<whitequark>
jeanthom: so, TOOLCHAIN_PREFIX isn't an inherently bad idea, but there are a few issues with it
<whitequark>
the main ones i can think of are:
<whitequark>
- nothing else uses it
<whitequark>
- it's coarse-grained, though being able to override individual components with YOSYS NEXTPNR_ICE40 vars etc could help with that
<whitequark>
- it would pretty significantly complicate both our templated build scripts and our python code
<jeanthom>
mmh
<whitequark>
someone™ would have to go through the .bat and .sh file generator and fix the code related to environment variables
<whitequark>
and then through nmigen._toolchain
<whitequark>
and none of that has actual tests at the moment...
<whitequark>
and the user experience would be the same as with `yowasp-env` command
<whitequark>
agg: (to add) there is a reason yowasp homepage prominently says "Unofficial"
<whitequark>
if it was adopted by yosyshq, then sure, that would have been reasonable to add as a fallback
<whitequark>
but i already proposed that and it was soundly rejected
<whitequark>
so... i don't think it's something we should do
<agg>
that's fair
<agg>
shame as it definitely makes using those tools so so much easier
<whitequark>
do you think having the `yowasp-env` or `yowasp-run` commands would raise the barrier significantly?
<whitequark>
I guess I should've started with that
<agg>
right now my build process for generating gateware and loading it is like "python3 -m myproject <serial number> --program", which works for me with system yosys; probably with any other prefixes or env vars it would get put into a bash script or makefile that handles them
<agg>
my current interest is around getting colleagues able to build and run the gateware without having to build their own copies of yosys etc
<whitequark>
hmm
<agg>
it's not a problem to put things into a makefile really, at which point specifying all the env vars separately is good enough anyway I guess; anything more than just running python inside the relevant venv is enough complexity to warrant a makefile
<d1b2>
<Falteckz> Currently I build in VSCode since that's where I'm writing nMigen python.
<d1b2>
<Falteckz> I can just configure all the env stuff on the workspace
<d1b2>
<Falteckz> So Env vars good for me
<agg>
i'm not using nmigen.cli though, it wouldn't be at all hard for my own python script to set the env vars as appropriate
<whitequark>
Falteckz: if you configure the vars manually then you're already OK i think
<whitequark>
without the new script
<agg>
in fact, that's probably what I would do instead of a makefile, now that I think about it
<whitequark>
agg: aha!
<d1b2>
<Falteckz> There is a new script? Cause I wrote a wrapper around Sim and Build...
<whitequark>
so I can export a function from yowasp_env that just does it
<agg>
!
<agg>
yea
<d1b2>
<Falteckz> n...migen..CLI?
<d1b2>
<Falteckz> Darn it!!
<d1b2>
<Falteckz> I made my own CLI for nought
<agg>
I mean, assuming "it" is "set the relevant environment variables so that subsequent nmigen build commands will use yowasp", that sounds perfect
<whitequark>
Falteckz: if it makes you feel better, nmigen.cli is not very good
<whitequark>
agg: correct
<agg>
Falteckz: it really depends what you want, nmigen.cli isn't useful for me and wasn't hard to write my own
<agg>
nmigen is very easy to use without the built in cli
<d1b2>
<Falteckz> If it makes you feel better neither is my cli
Asuu has quit [Read error: Connection reset by peer]
<whitequark>
nmigen.cli basically just exists for examples
<whitequark>
it really is an afterthought
<whitequark>
it should be replaced from ground up
<agg>
also when i started this project nmigen didn't have Platform or build, so I had my own versions of those too :p
<whitequark>
ouch!!
<d1b2>
<Falteckz> I just have a function in a helper that I defer to, and it handles cli stuff
<agg>
it wasn't much work and the api you ended up with for platform and build almost exactly matched what I was already using, so it wasn't at all hard to move over
<whitequark>
ah, you've already migrated
<agg>
yea
<d1b2>
<Falteckz> Anyone used the ACM example by @Kate Temkin on TinyFPGA BX ?
Asuu has joined #nmigen
<d1b2>
<Falteckz> Is it significantly smaller than the usbserial module?
<d1b2>
<Falteckz> I've a suspect that nmigen-stdio/serial does not work at high utilisation
<d1b2>
<Falteckz> Looks like the start and stop states might get messed up, but I can't be sure.
<whitequark>
Falteckz: yeah that might be buggy, I'll fix it once I get around
<d1b2>
<Falteckz> Same if I get the time, or at least write my own fork and offer it
<d1b2>
<Falteckz> Provided it isn't more awful
<d1b2>
<Falteckz> Was going to just add states for STOP and START to the FSM, would increase clarity during sim at least.
<d1b2>
<Falteckz> Further I would like to increase the shift register to 16bit, so that the next octet can be latched while the previous one is still being written
<whitequark>
the latter part I consider out of scope
<whitequark>
if you want buffering you should add a FIFO
<whitequark>
well
<whitequark>
streams will make this much easier
<whitequark>
the reason -stdio and to a lesser degree -soc don't get much love is that we don't have streams yet
<d1b2>
<Falteckz> constructs I've not encountered
<whitequark>
because we don't have them yet
<whitequark>
:p
<d1b2>
<Falteckz> Haha but even from a philosophical point
<whitequark>
take a look at AXI4-Stream
<jeanthom>
Falteckz: I think zignig got it working on this board
<d1b2>
<Falteckz> Oh, that's like Wishbone but scary
<whitequark>
no the -Stream one is much simpler
<d1b2>
<Falteckz> Perfect
<d1b2>
<Falteckz> @jeanthom good to know!
<d1b2>
<Falteckz> I assume you would not be implementing all of AXI4-Stream
<d1b2>
<Falteckz> and it's just a conceptual simularity
<d1b2>
<Falteckz> TID/TDEST/TUSER all seem superfluous
<d1b2>
<Falteckz> I would even go so far as to suggest that an early implementation would not need strobe, but I'm bias towards 8bit data bus 😄
<daveshah>
Those are optional anyway iirc
<daveshah>
wide buses are useful when you need to meet difficult timing constraints (e.g. 10GbE and beyond, even 1GbE on slower ECP5s)
<daveshah>
although not all of them will need strobe
<d1b2>
<Falteckz> My life would be going pretty great if that was a problem I needed to solve.
<whitequark>
Falteckz: yes, it's a conceptual similarity
<d1b2>
<Falteckz> fwiw, the stdio/serial in it's current minimal intended design, cannot reach, I do not think, full speed.
<d1b2>
<Falteckz> There would be clock latency between octets, which is probably okay for most usecases
<whitequark>
ah i see
<d1b2>
<Falteckz> Until someone wants to push it to the limit and it turns to garbage
<whitequark>
okay i'll rewrite that
<whitequark>
you're right
<d1b2>
<Falteckz> I figured a mux would be fast for a 8bit * 2 ping-pong buffer. But sure if you're going to rewrite it anyway, I'll continue to stand on your shoulders ⛰️
<agg>
in principle it could indicate ready (and so clock in the next word) while transmitting the stop bit, right?
<d1b2>
<Falteckz> it could yes
<agg>
without needing to clock in the next word early or using a double sized buffer
<whitequark>
good idea
<d1b2>
<Falteckz> That's a good point. It was during the stop bit that I intended to swap the buffer, but perhaps that's better
<whitequark>
so, some context
<whitequark>
while writing that module i tried to keep the resource usage very low
<whitequark>
and focused too much on that, to the detriment of correctness
<whitequark>
don't do that
<whitequark>
:p
<d1b2>
<Falteckz> 😛 noted
<d1b2>
<Falteckz> Does that count as premature optimisation?
<d1b2>
<Falteckz> Fwiw, it is very small
<d1b2>
<Falteckz> It's also buggy :p
<whitequark>
yes
<whitequark>
very much premature
<d1b2>
<Falteckz> Huh! Neat trick with the parity bit using a 0 length signal
<ktemkin>
Faltecks: the ACM example is about 1.5k-2k LEs all nicely double buffered for throughput and fully spec compliant
<ktemkin>
compared to 1.1k base for the tinyfpga_bx_usbserial
<awygle>
I can't decide if that seems big or small
<awygle>
Do you have a summary of sizes for different use cases / configurations someplace?
<ktemkin>
you can get the LUNA ACM one smaller than the Verilog usbserial if you remove “unnecessary” descriptors and usb request / pull out the double buffering
<whitequark>
boneless is like half that
<ktemkin>
strict USB compliance and throughput make things bigger
<whitequark>
yeah
<whitequark>
i *think* the glasgow firmware actually passes all USB conformance tests except for sleep current
<whitequark>
so, at least as good as basically every USB peripheral on market :p
<ktemkin>
(And that’s using distram since the Bx was asked for, so some of those LEs are just fancy FFs)
<whitequark>
distram?
<ktemkin>
distributed ram instead of block ram
<whitequark>
oh
<whitequark>
wait, bx has no block ram?
<whitequark>
(aside: in yosys we call the various kinds of memories "FFRAM", "LUTRAM" and "BRAM" for least ambiguity)
<ktemkin>
it has a small amount of block ram; I just grabbed it to simulate having a CPU there
<whitequark>
ah
<awygle>
how much of that is phy? how much is storage? at what point do I stop asking questions that I could probably answer myself by playing with the code for twenty minutes?
<whitequark>
makes sense
<ktemkin>
since that’s what I thought the most likely use case would be
<whitequark>
you'd need to synthesize it with -noflatten to answer those
<ktemkin>
awygle: I’m on my phone and just woke up, so I have no idea
<ktemkin>
but the PHY code is very, very similar to the one in usbserial (they both inherit architecture from Luke Valenty’s usb stack at some point)
<awygle>
Yeah fair, I got excited. Sorry.
<ktemkin>
LUNA’s is a rewrite of a rewrite of Luke’s code >.>
<awygle>
LUNA is super cool and also super intimidating
<ktemkin>
that’s my fault for the architecture docs not being more prominent / complete
<awygle>
na it's the usb.... association? special interest group? those folks' fault
<awygle>
primarily
<whitequark>
USB Implementers Forum
<ktemkin>
USB-IF does the implementation stuff
<awygle>
I really appreciate your work to make the topic more approachable
<whitequark>
wait, is there something other than USB-IF doing the work?
<ktemkin>
USB Promoter Group is the more expansive one that does high-level stuff and tries to squish USB into every use case
<whitequark>
oh!
<ktemkin>
awygle: I have some training materials that I think explain the USB stuff well, but they need to be recorded and/or translated into prose, still
<ktemkin>
I’ll try to re-prioritize those, I’ve been putting them off for too long
<awygle>
that would be great. i'm in no particular hurry, but i do a) want to use LUNA b) badly need to get up to speed on usb
<ktemkin>
luckily USB2 isn’t *that* complicated, especially if you’re trying to use it rather than implement all the low-level stuff; it’s just a bit of an odd half-duplex protocol
<awygle>
what i mostly want to be able to do is, given a base design (say, ttyACM serial with a ULPI transcevier), and a proposed change (say, add a mass storage endpoint), have a ballpark idea of the increase in complexity and resource usage associated with the change
<ktemkin>
well, bulk-only storage is pretty much just sticking SCSI-ish commands over pretty much the same design
<ktemkin>
so just add whatever the complexity / resource usage is of the SCSI pieces you want to implement, essentially
<awygle>
i see
<awygle>
what about DFU?
<ktemkin>
it’s a little status FSM and then some simple vendor requests, plus the complexity of whatever flashing process you want to use
proteus-guy has joined #nmigen
<awygle>
those both seem fairly low overhead, which is encouraging. thanks
<ktemkin>
:)
<ktemkin>
np
<ktemkin>
I’ll have a sample DFU application at some point probably not too far in the future
<ktemkin>
(I’ve been asked to replace Fomu’s foboot bootloader)
<awygle>
great, i'll keep an eye out for that :)
<awygle>
i should have plenty of LUTs to play around with but every one i don't use i can spend on a faster CPU core :p
<lkcl_>
allows visualisation of nmigen code by executing it and single-stepping it server-side, and communicating the state to the front-end, which can do things like... e.g.... modify part of an SVG to highlight a Signal.
<d1b2>
<286Tech> @whitequark Do you have a suggestion for how I should share code for the PLL issue? Right now I have a PR, but it's just for having some code to look at. If you want, I could put it in a gist and link to it in the issue.
<whitequark>
286Tech: I think the focus on code is premature in this case. I mean, a PR works and doesn't hurt anyone, but I wouldn't start the design from the *implementation*
<whitequark>
my normal approach here is to start from the API, and in particular from the way it'd be *used*
<d1b2>
<286Tech> I agree
<whitequark>
i.e.: come up with some code using the PLL, assuming the implementation is perfect and magically written by someone omniscient, then work backwards from that to fit it into what's actually realistic
<whitequark>
I haven't actually read the code in the PR for that reason; it's just the wrong end of the process
<d1b2>
<286Tech> My brain just likes to see some implementation to spot the positives/negatives, but yes, the API should first be designed well.
<d1b2>
<286Tech> I can remove the PR 🙂
<whitequark>
as you wish
<whitequark>
it's not a problem that it's open, it's just premature
<d1b2>
<286Tech> As you said, I want to look at it from the user's perspective first. How is it going to be used, and if everyone agrees, then I'll start looking into the implementation.
<d1b2>
<286Tech> I'll just remove it, and go back to the drawing board first.
<_whitenotifier-b>
[nmigen-boards] whitequark edited a comment on pull request #75: boards: add Colorlight 5a-75b 7.0 - https://git.io/JJmg5
<_whitenotifier-b>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JJm2T
<awygle>
EnableInserter doesn't do any clock gating does it? it basically wraps the whole module in a `with m.If(self.ce):`?
<_whitenotifier-b>
[nmigen] whitequark commented on issue #425: Support for PLL primitives - https://git.io/JJm2L
<whitequark>
correct
<whitequark>
there are actually some people who think it should do clock gating, which would be an unmitigated disaster on FPGAS
<whitequark>
(you might guess that the person who proposed it works on ASICs...)
<daveshah>
Kind of incidental, but the UltraScale+ has a structure that hypothetically would be conducive to clock gating
<daveshah>
With enables at the leaf global buffer level
<_whitenotifier-b>
[nmigen] GuzTech commented on issue #425: Support for PLL primitives - https://git.io/JJm2Y
<daveshah>
Sadly Vivado doesn't actually map this and it may well even be broken but I'd love to play with this in nextpnr once more pressing stuff it out the way
<daveshah>
(leaf level is 30 SLICEs, and you have 16 potentially gated global signals per leaf to work with)
<awygle>
that's pretty dang useful
<awygle>
the ecp5 has some interesting stuff for clock gating too but it's at a much higher level of abstraction ofc
<awygle>
or, not abstraction. it's coarser-grained.
<daveshah>
Yeah it is at the entry point to global routing
<daveshah>
Rather than almost at the exit
<awygle>
mhm. it makes me want it for my "single-step an FPGA" dream tho
<daveshah>
Indeed it definitely has uses
<daveshah>
Also for low power stuff
<whitequark>
awygle: i think we can achieve single-stepping an FPGA with scan chain insertion alone
<awygle>
the best way to select a value from a Python list using an nmigen signal is just to Array(thelist), right?
<whitequark>
yes
<daveshah>
Even more tangentially the UltraScale+ leaf clock buffers also have programmable delays to "fudge" setup/hold requirements
<daveshah>
This is used by Vivado as a kind of fine grain retiming
<daveshah>
In theory they can also become pulse generators, in combination with FFs becoming latches, but I've never actually seen Vivado do this
<awygle>
that's kinda hilarious actually
<awygle>
not quite as "fuck it" as the stratix but still, cool
<daveshah>
The UltraScale+ clocking architecture is quite interesting
<daveshah>
The row clock buffers also have programmable delays to iron out skews in the global routing
<awygle>
i wonder if that would increase their window of acceptable performance and improve yield
<awygle>
there'd have to be a calibration step but that's probably already true
<daveshah>
I think it is more to enable the global clock not to need to originate from the center
<daveshah>
As it would in a true tree topology
<awygle>
ah, that too
<whitequark>
i kinda really want to work on scan chain insertion
<whitequark>
but... i don't have any fun testcase
<whitequark>
i guess i could run minerva-soc or something
<d1b2>
<Qyriad> Am I reading that right that it doesn't support returning any pointers at all?
<whitequark>
no, you can return c_void_p
<whitequark>
that's it
<whitequark>
c_char_p too I think
<whitequark>
since those are primitive
<d1b2>
<Qyriad> that's still ridiculously limited
<whitequark>
yes
<whitequark>
very obnoxious
<whitequark>
this is gonna make my code *so much worse*
<mwk>
... I'm impressed by the last comment on that bug, with a workaround
<mwk>
The fix involves using ctypes to access ctypes own internals, and build a modified version of the Structure data type that is able to perform a copy when used as returned value.
<whitequark>
*phew* rewritten
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
SpaceCoaster has joined #nmigen
<awygle>
whitequark: mind if i edit the "deprecate record.connect" issue to reflect the new plan?
<awygle>
alternately i could close it and reopen it
<whitequark>
look at my code, ye tired, and despair; for i have done the same
* awygle
, tired, looks
<awygle>
that looks pretty good honestly
<awygle>
as good as possible given, like, what it is
<whitequark>
well the ctypes part yes
<whitequark>
the rest of the simulator... i hate it the more i look at it
<whitequark>
there are no clear lines to split it on
<whitequark>
so it's just this weird amalgamation of classes that share some behavior but not other without a nice interface
<whitequark>
which means they could as well be one class, and that *used to be the case* but now it needs to handle cxxrtl too...
<awygle>
:(
<_whitenotifier-b>
[nmigen] FFY00 opened issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwM
<_whitenotifier-b>
[nmigen] FFY00 edited issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwM
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwQ
<_whitenotifier-b>
[nmigen] whitequark edited a comment on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwQ
<_whitenotifier-b>
[nmigen] cr1901 commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmwA
<cr1901_modern>
_whitenotifier is surprisingly convenient sometimes.
<awygle>
i love how python will complain that i didn't overload an abstract method, but if i overload it with completely the wrong signature it's happy as a clam
<_whitenotifier-b>
[nmigen] whitequark commented on issue #428: Refactor platform programming API to better support multiple programmers - https://git.io/JJmrl