<anuejn>
I am also quite shure, that using setattr doesnt work in that scenario because at least some __.*__ methods (e.g. __add__) are looked up on the objects class rather than the object itself
<vup>
hmm
<anuejn>
maybe we should have a class in nmigen from which you can inherit that gives you more or less the exact behaviour UserValue had?
<vup>
anuejn: doing it in __new__ works
<_whitenotifier-f>
[nmigen] bobtwinkles opened issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkezX
<vup>
whoops no I am stupid
<vup>
but setattr on the class works :)
<anuejn>
up but that is... evil and can lead to really bad suprises
<anuejn>
I would highly recomand against doing that from personal experience ;)
<d1b2>
<OmniTechnoMancer> setattr on object 😄
<vup>
well you could create a new class in __new__ each time
<vup>
that wouldn't be too bad :)
<anuejn>
right
peeps[zen] is now known as peepsalot
<_whitenotifier-f>
[nmigen] adamgreig commented on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkewL
<whitequark>
anuejn: no, absolutely not. that would defeat the purpose of removing UserValue.
<anuejn>
ok so then I need some Inspiration on how to implement a certain thing
<anuejn>
I want to add some metadata (a direction) to a signal
<whitequark>
sure
<anuejn>
my naive approach would be to just Create a UserValue that wraps my Signal and has an additional direction field
<whitequark>
would Interfaces that will ship in 0.4 solve your problem?
<anuejn>
yup
<whitequark>
then you can keep using the compatibility fallback for UserValue between now and the moment we implement those
<whitequark>
once we fix it to not break your code
<anuejn>
I am trying to design something like that (to experiment with the designspace and be able to maybe write an RFC)
<whitequark>
so the thing about interfaces is that the signals in them would still not be directional
<whitequark>
the container is
<anuejn>
okay right maybe going with UserValue for the time being
<anuejn>
is the right way
<whitequark>
can you file a bug about UserValue brokenness, ideally with a test case?
<anuejn>
whitequark: I was thinking that it might be desirable to have a wrapper around the signals that hold the direction information
<anuejn>
but that might be a dead path
<anuejn>
whitequark: UserValue brokenness? you mean Record brokenness?
<whitequark>
er, yes, sorry
<anuejn>
I can do that
<whitequark>
thx
<_whitenotifier-f>
[nmigen] whitequark commented on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkeoC
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkeoC
<_whitenotifier-f>
[nmigen] anuejn opened issue #533: Breaking change in Record - https://git.io/JkeoE
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkeKD
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkeKQ
jjeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[nmigen] cestrauss commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jke1o
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-f>
[nmigen] cestrauss commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkeDt
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkeDs
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkeDE
emeb has joined #nmigen
<_whitenotifier-f>
[nmigen] whitequark commented on issue #533: Breaking change in Record - https://git.io/JkeS4
<_whitenotifier-f>
[nmigen] cestrauss commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jke9J
noknok has joined #nmigen
jjeanthom has quit [Ping timeout: 246 seconds]
<_whitenotifier-f>
[nmigen] RobertBaruch commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jke7m
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jke78
<_whitenotifier-f>
[nmigen] RobertBaruch commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jke5V
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-f>
[nmigen] cestrauss commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jkvev
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/Jkvvc
<_whitenotifier-f>
[nmigen] cestrauss commented on issue #526: Past should not be allowed in m.d.comb - https://git.io/JkvvR
<_whitenotifier-f>
[nmigen] whitequark edited issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JTAwv
<_whitenotifier-f>
[nmigen] daveshah1 commented on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkvvX
<awygle>
Wild how much I feel like I'm gonna be left behind by that multiclock discussion if I don't comment right now right now right now
<awygle>
Even though I know a design decision like that won't be decided in the next 20 days let alone 20 minutes
<awygle>
Brains
<_whitenotifier-f>
[nmigen] RobertBaruch commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvJA
<_whitenotifier-f>
[nmigen] whitequark opened issue #534: Deprecate lexically dependent behavior of Past/Rose/Fell/... without explicit domain= argument - https://git.io/JkvU3
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvU2
<awygle>
Fine prove me wrong lol
<whitequark>
oops lmao
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvUb
<_whitenotifier-f>
[nmigen] rroohhh edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvUb
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvTY
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvT4
<_whitenotifier-f>
[nmigen] awygle commented on issue #533: Breaking change in Record - https://git.io/JkvTz
<awygle>
wow we've really burned down a lot of issues since i started paying attention
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvT1
<whitequark>
yup, i put a lot of effort into finally getting the release out
<whitequark>
it was going to happen in uh... spring
<_whitenotifier-f>
[nmigen] awygle commented on issue #423: Emit a warning when an Assign expression is not added to a domain - https://git.io/JkvTy
<awygle>
i noticed because issues that i think of as being fairly "recent" are on the second page, and also there's only 3 pages lol
<_whitenotifier-f>
[nmigen] whitequark commented on issue #423: Emit a warning when an Assign expression is not added to a domain - https://git.io/Jkvkk
<awygle>
ugh i'm really struggling to explain my position in a github comment on #526
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvkW
<whitequark>
do you disagree with the deprecation? that's really the only thing i'm convinced of, so far
<_whitenotifier-f>
[nmigen] awygle commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvkz
<awygle>
i don't disagree so much as i'm not yet convinced
<awygle>
on that topic i basically agree with rroohh
<vup>
(btw I am rroohhh on gh)
<awygle>
oh, cool
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvko
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvkP
<awygle>
i know you didn't ask me but Past(z) should ideally give the value of y on the last sync tick, but it'd be reasonable to have it error out instead
<awygle>
(which i guess is just x
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvk9
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvkj
<awygle>
i wish github issues were threaded :(
<_whitenotifier-f>
[nmigen] awygle commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvIs
<vup>
awygle: in the last example `z` is a `Signal`?
<_whitenotifier-f>
[nmigen] awygle edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvIs
<awygle>
ah you are right, my derp
<vup>
and I would also be fine with it being an error, however I don't really see a reason for that
<vup>
In my head there is no difference between `m.d.sync += y.eq(x); m.d.comb += z.eq(y + 1)` and `m.d.sync += `z.eq(x + 1)`
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvIR
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvI2
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvI2
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvIb
<_whitenotifier-f>
[nmigen] rroohhh edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvIb
<vup>
Most of the work needed for what I suggested will have to be done for #6 eventually, right? Maybe it makes sense to think about it again when #6 / the infrastructure work for that is done.
<awygle>
i suddenly feel very rust about this lol
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvtJ
korken89 has joined #nmigen
<_whitenotifier-f>
[nmigen] awygle commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvtc
<korken89>
Hi all! I have been learning about clock domains in nMigen, but I have gotten stuck on defining a clock domain from an external source. What I have is class which on init takes a clock domain as a parameter and sets it as `self.cd`. However, I need to know the name of the clock domain, so in my module I overwrite the `sync` domain with the input
<korken89>
domain as `m.domain.sync = self.cd`. However if I then do some synchronous logic such as `m.d.sync += some_stuff` it says that the domain is not defined. And it is correct, the "sync" domain does not exist, but I overwrote it. So my question is, how does on give a clock domain to a class and use this domain without knowing its name?
<korken89>
Overwriting was clearly not the correct way to do it :)
<vup>
korken89: you need to add a new domain using m.domains += ClockDomain("the_name")
<korken89>
Yes, but this assumes I know the name
<vup>
ah self.cd is a string?
<korken89>
No, a `ClockDomain`
<whitequark>
korken89: can you tell us a bit more about the module that is parameterized over a clock domain?
<whitequark>
does that module use a single clock domain, or several?
<korken89>
What I am trying to do is a slave SPI, so it has the SPI clock domain and the FPGA clock domain
<korken89>
But I want to make it a bit generic
<korken89>
So I want do "give" it a clock domain which is the SPI slave clock domain
<korken89>
Without forcing a name on it and allow the implementor to give whatever domain
<whitequark>
ah yes. in this case, you shouldn't give it a clock domain object
<korken89>
Oh
<korken89>
Do you have an example on how one should do it? :)
<whitequark>
so, there are several possible ways to handle this
<whitequark>
I would recommend that you encapsulate clock domain instantiation and crossing to the SPI peripheral module itself
<whitequark>
i.e. you would give it the clock, the I/O pins, and it would contain the CDC logic completely internally
<korken89>
Makes sense, but how do I give a clock without having a clockdomain?
<whitequark>
I mean the SPI clock pin
<whitequark>
if you do `platform.request("spi", 0)` then that includes a clock pin.
<korken89>
I have the CDC logic in the module, this was my plan
<korken89>
Hmm, okey
<korken89>
But lets say I give it the name "spi_clock"
<korken89>
What if I have this name in another module?
<korken89>
Or make 2 instatiations?
<korken89>
Won't this collide?
<whitequark>
use ClockDomain("spi_clock", local=True) when adding the internal clock domain
<korken89>
(I have assumed clock domains are global)
<korken89>
Ahh
<whitequark>
that is correct, but nMigen also has local clock domains for exactly this purpose
<korken89>
So one can make it local, awesome!!
<korken89>
This makes it so much cleaner, thank you for clarifying!
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvtd
<_whitenotifier-f>
[nmigen] whitequark commented on issue #403: Records don't work in Assert - https://git.io/JkvqU
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #403: Records don't work in Assert - https://git.io/JkvqU
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #403: Records don't work in Assert - https://git.io/JkvqU
<_whitenotifier-f>
[nmigen] BracketMaster commented on issue #403: Records don't work in Assert - https://git.io/Jkvqt
<_whitenotifier-f>
[nmigen] BracketMaster closed issue #403: Records don't work in Assert - https://git.io/JfQsY
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #403: Records don't work in Assert - https://git.io/JkvqE
<_whitenotifier-f>
[nmigen] whitequark reopened issue #403: Records don't work in Assert - https://git.io/JfQsY
<_whitenotifier-f>
[nmigen] whitequark commented on issue #403: Records don't work in Assert - https://git.io/Jkvqr
emeb has quit [Quit: Leaving.]
<korken89>
whitequark I gave it a try and seem to work as advertised! I just found one quirk, if I in some module at a higher level than the my SPI module define a ClockDomain that has the same name as the local domain, I get a weird error.
emeb_mac has joined #nmigen
<whitequark>
korken89: please open a bug with an MCVE
<whitequark>
an AssertionError is *never* intended behavior
<korken89>
Good to know!
<_whitenotifier-f>
[nmigen] whitequark commented on issue #443: add API to get simulation time for debugging - https://git.io/Jkvqh
<_whitenotifier-f>
[nmigen] whitequark opened issue #535: Don't represent simulation time as floating point - https://git.io/Jkvmm
<_whitenotifier-f>
[nmigen] whitequark edited issue #535: Don't represent simulation time as floating point - https://git.io/Jkvmm
<_whitenotifier-f>
[nmigen] whitequark commented on issue #443: add API to get simulation time for debugging - https://git.io/Jkvmn
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvtd
<_whitenotifier-f>
[nmigen] whitequark edited a comment on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvtd
<_whitenotifier-f>
[nmigen] korken89 opened issue #536: Local clock domain can collide with global domain, causing assert failure - https://git.io/JkvmX
<korken89>
Nice, the bot reports that I opened an issue :)
<_whitenotifier-f>
[nmigen] rroohhh commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/Jkvmb
<mithro>
@whitequark I impressed by the amount of activity (for example in issues) on nmigen that I see from people who are not you! Seems like a community is really forming.
<whitequark>
indeed
<whitequark>
I'll know I succeeded when I'm no longer the sole de-facto maintainer :)
<korken89>
This tool is amazing IMO! I remade a semi-tricky old VHDL processing part in an image processing pipeline to try nmigen + formal verification out, and it was really straight forward and I got the formal verification to find old known bugs :D
<whitequark>
nice!!
<korken89>
I'm not going back unless I have to!
<korken89>
Still learning though, but so far I'm super impressed
<mithro>
whitequark: Being able to hand over a project to somewhere else (or even better a group of other people) and be certain that is in good hands / will continue without me is something I aim for with most of my projects
<whitequark>
korken89: there's so much work left to do, but I'm consistently amazed by how much people achieve even with very little first-party documentation and with multiple sharp edges we still have around in the core language
<whitequark>
mithro: indeed, and for a programming language, it's pretty much mandatory
<whitequark>
even Guido, the original BDFL, could only spend so many years in that position
<korken89>
whitequark: It's quite a breath of fresh air, so I have no problem with a little sharp edges right now ^^
<whitequark>
korken89: please do file usability issues on the tracker as well
<whitequark>
nMigen is ultimately limited by Python in the quality of its diagnostics, but it's often possible to stretch things a lot
<korken89>
I mean, the only thing I had issues with is finding real world examples to get a feel for how to structure projects, but the nMigen examples in the icebreaker repo helped a lot
<_whitenotifier-f>
[nmigen] cr1901 commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvYD
<cr1901_modern>
korken89: Glad to hear the nmigen examples helped :D. I should prob add more
<korken89>
Please do, they were quite great!
<korken89>
Btw, looking at the synthesis and PnR reports, I can't find a report on the clock skew in the design. Is there something I should do to get it reported or am I maybe just missing it?
<whitequark>
nextpnr doesn't calculate clock skew
<whitequark>
it only has basic support for timing constraints/reports at the moment, another notable omission is IOB timing
<korken89>
Oh, I see
<whitequark>
that one is probably the last remaining reason to use iCECube :/
<whitequark>
(but fortunately for you nMigen does know how to call that)
<korken89>
Oh, nice
<korken89>
I want to try the ECP5 and port my old FT232H sync FIFO interface
<korken89>
It runs at 60 MBit/s and I remember I got clock skew issues on the Artix-7 when I was not careful
<korken89>
But if the tools can pipe into the official tool when needed I see no problem :)
<mithro>
IIRC vpr does understand clock skew and IOB timing. It also seems like litghost (with feedback from daveshah) is getting close to coming up with an FPGA description format that will be usable by both nextpnr + vpr and targetable by all of X-Ray / U-Ray/ Trellis / Oxide and Icestorm
<whitequark>
mithro: nice!
<whitequark>
korken89: yes, you can use Diamond for ECP5 just as well
<korken89>
Awesome!
<whitequark>
for every architecture that has a vendor toolchain, nMigen knows how to talk to that
<whitequark>
precisely because of issues like this
<korken89>
That is super handy!
<korken89>
I mean sure I'd like to go open as far as possible, but still that one can use an existing tool where the OS tools have not caught up yet is super great!
<korken89>
Plus, I guess as soon as nextpnr gets the support one can just switch back?
<daveshah>
If it does
<whitequark>
nMigen doesn't try to dictate which tools you should use; it adapts to the toolchain you pick instead
<cr1901_modern>
even the yosys dependence is in principle abstracted away w/ wasm
<whitequark>
switching between toolchains boils down to passing a toolchain= argument to .build()
<whitequark>
cr1901_modern: the Yosys that nMigen uses for converting to Verilog is an implementation detail
<cr1901_modern>
fair
<whitequark>
it doesn't know anything about the platform and doesn't really touch the netlist
<whitequark>
just a complicated-looking way of transforming text to text
<_whitenotifier-f>
[nmigen] whitequark commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvOR
<_whitenotifier-f>
[nmigen] cr1901 commented on issue #526: Behavior of Past/Rose/Fell/... is poorly suited for multiclock or asynchronous designs - https://git.io/JkvOo
<korken89>
Ah nice the ECP5 diamond license was free if one does not use SERDES :)
<daveshah>
If you do need to use a part with SERDES, devkits include a full license and are much cheaper than a license
<korken89>
Oh, just like with Xilinx devkits
<korken89>
Thanks for the tip!
<daveshah>
No, Xilinx licenses are part number locked
<daveshah>
Lattice licenses aren't
<korken89>
Ah, even better
<korken89>
Is there a dev board you recommend that has best bang for buck to get a license?
<daveshah>
Heck, I was even able to use a license from an ECP5 devkit with an old Diamomd version to generate a bitstream for the notionally nonexistent ECP4
<daveshah>
If you are looking at Lattice ones in particular, I usually recommend the LFE5UM5G-85F-EVN but its out of stock at the moment
<daveshah>
The ULX3S and Orange Crab are worth a look otherwise
<korken89>
All include a license?
<daveshah>
No, only the Lattice ones do
<korken89>
Even the orangeecrab?
<korken89>
Ah makes sense
<daveshah>
The ULX3S and Orange Crab don't have a serdes so don't need one
<korken89>
For the board I am designing my own :)
<daveshah>
Nice
<korken89>
Porting an Xilinx based design the the ECP5
<korken89>
I have a stereo camera design I'd like to port to ECP5
<cr1901_modern>
whitequark: What does Past(z, domain="foo") do if Signal "z" is clocked by domain "bar"? Does it error or silently break?
<whitequark>
cr1901_modern: the same thing as m.d.foo += a.eq(z)
<whitequark>
i.e. silently introduce a CDC violation until #6 is implemented
<whitequark>
I think these two should be consistent because Past() is syntactic sugar for a chain of FFs (as $past is in SVA)
<cr1901_modern>
I did not know that re: $past in SVA. You might ask "well what other way is there to do it?" Well, I thought SVA would have a bunch of edge cases that make $past NOT sugar for a chain of FFs
<cr1901_modern>
Tbh I keep having to relearn about $past when I need it
<cr1901_modern>
Anyways, I agree with awygle that m.d.comb += Past() should be an error
<cr1901_modern>
Uhhh, Past(z), where "z" is driven by comb "domain" should be an error*
<awygle>
the more i think about it the less convinced i am that "Past() behavior depends on other modules when used on signals from other modules" is a problem
<whitequark>
what you're suggesting is equivalent to global type inference coupled with type-based overloading, which is a catastrophically bad idea
<whitequark>
i would know, i designed three languages that had it
<whitequark>
you can get it to work technically (Crystal for example), and people keep trying because the niceties it brings are immediate but the problems only become obvious when your programs get orders of magnitude larger and the behavior is too entrenched to remove (or maybe the entire language is built on it, like i did)
samlittlewood has joined #nmigen
<whitequark>
in ARTIQ, this "spooky action at a distance" first made people happy because hey, it's obvious what the types should be!
<_whitenotifier-f>
[nmigen] bobtwinkles commented on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/Jkv3X
<whitequark>
a year or two later, well, the programs are a lot larger and no longer fit in your head, and now you suddenly can't figure out when something broke after changing an apparently unrelated part of the program
<whitequark>
(i knew this would happen but i was paid to develop specifically that, so i did my best to mitigate the fallout instead)
<cr1901_modern>
>but now I'm thinking that Past et al. should be allowed in m.d.comb.
<awygle>
fundamentally Past() seems very well behaved. flip flops are clocked by clock signals. the Past value of a flip flop's output is the value on the previous cycle of that clock signal. using Past in any other context makes little sense.
<whitequark>
awygle: i agree, which is why #6 should issue a diagnostic if you use Past to sample anything in a different domain
<whitequark>
the same way it should issue a diagnostic if you use a normal register to sample anything in a different domain
<whitequark>
if my formal specification says Assert(Past(x.out, domain="read")), it is effectively also an assertion on the domain that drives x.out
<whitequark>
not only does the explicit domain declaration make the behavior of Past() completely local, but it also helps finding bugs that would otherwise be missed!
<awygle>
why not default to the only sensible use of Past? requiring it to be manually specified every time seems unnecessary
<whitequark>
(just answered that)
<awygle>
a formal specification saying Assert(Past(x.out, domain="read")) is depending on an implementation detail of the DUT module
<whitequark>
the domains that drive a module's outputs (and sample a module's inputs) are a part of the module's contract
* cr1901_modern
's bandwidth is bad tonight... will come back to this
<whitequark>
note that Past(x.out, domain="read") asserts that x.out can be sampled from the `read` domain in the formal spec's module
<whitequark>
it doesn't restrict the implementation of the DUT any more than doing m.d.read += y.eq(x.out) would in normal synthesizable code that uses the same module
<awygle>
but it implicitly does, because it requires the output to be driven by a domain named "read"
<whitequark>
nope, you can use DomainRenamer
<whitequark>
assuming #6 introduces the notion of domain equivalence (not trivial but possible and probably reasonable to have), you could even have a completely different clock domain that has the same asynchronous control set
<whitequark>
the only thing #6 should really care about, in an ideal world, is timing arcs between signals in a design
<whitequark>
in nmigen, we have clock domain names (strings), clock domains (ClockDomain objects), and async control sets (groups of signals)
<whitequark>
clock domain names only matter insofar as nmigen doesn't require you to pass ClockDomain objects explicitly everywhere. it's a form of late binding (because you decide which ClockDomain object the name resolves to after you have created the module)
<whitequark>
not even the simplest possible implementation of #6 would care about the specific *name* of the domain within the DUT. at worst, it would care about which ClockDomain object the name within DUT resolves to
<whitequark>
at best, it would care about async control set equivalence. instead of ClockDomain objects, it would collect their clock and async reset (if any) signals, and then canonicalize those through comb assignment chains. if cd_a.clk is assigned to cd_b.clk, then m.d.a += x.eq(y); Past(x, domain="b") is valid
korken89 has quit [Ping timeout: 245 seconds]
<_whitenotifier-f>
[nmigen] bobtwinkles commented on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkvGy
<_whitenotifier-f>
[nmigen] bobtwinkles edited a comment on issue #532: XDR configuration should allow disabling gearboxes - https://git.io/JkvGy