Vinalon has quit [Remote host closed the connection]
Vinalon has joined #nmigen
_whitelogger has joined #nmigen
<ronyrus>
I have a real noob question. :) afaiu, when viewing a vcd produced by the simulation the changes in values are epsilon after the rising edge, but in GTKWave it looks on the edge itself.
<ronyrus>
Is there a way to change it? Visually it's very confusing.
<whitequark>
there isn't
<whitequark>
i think all EDA tools produce this kind of waveform output when they assume zero propagation delay
<daveshah>
If it did it would start to get very confusing if you were simulating something that had delays in it
<daveshah>
eg Verilog delays or post PnR simulation
<ronyrus>
I see. Can I supply a propagation delay for the simulation?
<ronyrus>
*to the simulation
<ronyrus>
as a parameter
<whitequark>
nmigen always simulates with zero delay
<whitequark>
if the delay was non-zero, it would also probably not match your intuition well
<whitequark>
because e.g. there would be an epsilon delay every time you connect something through a comb assignment
<ronyrus>
Interesting. I didn't think about it. ok :)
<whitequark>
maybe there should be something like distinguishing comb and sync signals in waveform view
<whitequark>
so you can see the implicit depenency
<whitequark>
but i'm not sure if it would help a lot, because you still have the problem where testbench code can change something an epsilon before a clock or an epsilon after a clock
Asu has joined #nmigen
<ronyrus>
yeah, maybe for the simple case I will just time shift it in GTKWave ...
<ronyrus>
right now I'm looking at something super simple, my mental problem is seeing a new value for a signal on 'this' clock, but thinking about it's being registered on the 'next' clock.
<whitequark>
yes. i think everyone goes through learning this
<ronyrus>
ok, just like muscle memory, will take time to adjust.
Asuu has joined #nmigen
Asu has quit [Ping timeout: 265 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 256 seconds]
____ has joined #nmigen
<anuejn>
whitequark: do you think, that a pr that adds typing in some places is useful?
<anuejn>
e.g. making signal generic over its width
<whitequark>
anuejn: that seems like a really complex PR
<anuejn>
or would you rather add typing for everything at once?
<whitequark>
at least to make it useful
<whitequark>
right now i don't have the bandwidth to design or review something like that
<anuejn>
ok, i see
<anuejn>
thanks anyways
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
Vinalon has quit [Ping timeout: 264 seconds]
<anuejn>
whitequark: what do you think about making Module a contextmanager-like thingy to support that usecase, that i had a few days ago where i dont want to pass the module and instead have some kind of getter for the current one?
<whitequark>
anuejn: i don't have any significant language changes planned for 0.3
<anuejn>
okay
<whitequark>
what i consider a priority now is the stream interface, nmigen-soc, improving FSMs
<whitequark>
and of course cxxsim
<whitequark>
in general, there should be no "current global / thread local module" at all
<whitequark>
so any ergonomics improvement in that direction would have to be fully local
<whitequark>
after 0.3, i'm open to considering improvements in that area; we certainly could use some
<anuejn>
at the moment i cant think of any way to improve ergonomics in that area withot something like that
<anuejn>
or maybe i didnt understand you right
<whitequark>
without something like what?
<anuejn>
some way to get some "active" module out of some kind of global scope
<whitequark>
there will be no such feature
<anuejn>
but lets discuss this further, when it is better suited for your timeline :)
<whitequark>
at the very beginning, even before i wrote any code for nmigen, i decided against using implicit global eDSL
<whitequark>
so that's not going to change
<anuejn>
okay i see your point there
<whitequark>
however, that doesn't mean we can't improve ergonomics
<whitequark>
we just have to find out some other way
<vup>
Do you think a way forward could be some way of attaching a module to signals / a signal, which then automatically gets added as a submodule to the module the signals get used in?
<whitequark>
i don't think that's a particularly good design either; though it is one of the more obvious ones
<whitequark>
i'm not even sure if the answer lies in extending the current module system, rather than building on top of it
<vup>
yeah I am not that convinced of that idea aswell, but it is the best I could come up with
<tpw_rules>
yeah in firefox it didn't load the whole paste and kept giving me the "page is slowing down your browser"
<agg>
if you know you're always 8 bits of data, generating a sclk at 1/2 sync clock, always rx+tx in each transaction, it's easy to make something pretty small and simple
<agg>
huh
<Degi>
works for me in ff
<agg>
yea same
<tpw_rules>
oh, i opened it in a new tab and now it works...
<agg>
i also have a more general spi master that is parameterised over 'n' bits and 'r' clock divider (power of 2), which is a little more code
<agg>
and a matching spi slave that's got n data bits and is handles cdc from the spi clock domain
<Degi>
Hm I think ill do a n/2 output clock where n is an integer
<agg>
but in general for spi flash writing it was so simple to just write ^
<agg>
probably worth doing spi master and slave as separate things
<Degi>
Hm how can I get vscode to use the docstrings from the nmigen pip package?
<Degi>
Oh the code just doesnt contain docstrings...
<ZirconiumX>
Degi: it does
<ZirconiumX>
Not everything has docstrings though
<Degi>
Heh this is the first time I use VSCode tbh... (the last time was Visual Studio a few years ago on windows)