<whitequark>
awygle: definitely built into the stdio core
<_whitenotifier-9>
[nmigen] whitequark commented on issue #383: UnusedMustUse warnings are emitted after the toolchain ran - https://git.io/JfCqZ
<_whitenotifier-9>
[nmigen] whitequark closed issue #383: UnusedMustUse warnings are emitted after the toolchain ran - https://git.io/Jfc6I
<awygle>
huh. vaguely surprised to hear that. mk then
<whitequark>
awygle: why surprised? should i reconsider it, in your view
<whitequark>
?
<whitequark>
awygle: the UART is talking to something in another clock domain (async domain, that is)
<whitequark>
just like you'd have a phase adjuster inside a high speed SERDES to get the edge where you want it, you have similar CDC mechanisms inside the UART
<whitequark>
cr1901_modern: you can never avoid flip-flops becoming metastable if you violate their setup/hold constraints
<whitequark>
think of it this way
<whitequark>
no matter how low the setup/hold requirements of a real FF are, you can always deliberately put an edge smack in the middle of the zone where it's actually sampling your value, which will cause the output to become metastable
<whitequark>
so the first FF always will, in some circumstances, have an indeterminate output
<whitequark>
now, let's look at the second
<whitequark>
the process in which a metastable flip-flop gets back into a determinate state is similar to radioactive decay
<whitequark>
and as you probably know, if you hold a single radioactive atom, then no matter how low the half-life is, there is a nonzero probability it will survive for the next whole secondd
<whitequark>
this means that, purely theoretically, no matter how many FFs you chain in a synchronizer, you will never be *completely sure* the output is stable
<whitequark>
just like, when you drop a pen on the table, you're never completely sure that it won't just tunnel through the wood and fall on the floor, being a quantum object
<whitequark>
but after two or three FFs it becomes vastly more likely that the FPGA will fail in a different way with a more severe result before you ever observe this failure, which means that, as an engineer, you should be more interested in those failures instead
<awygle>
whitequark: I was taught to keep modules single-domain if possible. The rationale had something to do with clock domain analysis. I can't say I necessarily understand the supposed advantage tho.
<awygle>
I am fine with your assessment, I definitely do understand not wanting to leave the possibility of forgetting it
<awygle>
And as I can't explain why doing it the other way would be helpful, I probably shouldn't give it any weight
<whitequark>
awygle: oh, is it Cliff Cummings' recommendation about CDCs?
<whitequark>
I *think* that references ancient useless timing analyzers that choke on the slightest issue
<awygle>
That and digital logic design class in school
<whitequark>
hmm
<awygle>
Which could easily also be out of date
<awygle>
Our synthesizer didn't even do verilog-2001 after all
Degi has quit [Ping timeout: 272 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
momota has joined #nmigen
momota has quit [Remote host closed the connection]
<agg>
Does putting the 2ff inside the uart reception port really count as making the uart not single-domain? It just adds latency, there's no second clock inside the module
proteus-guy has quit [Ping timeout: 256 seconds]
<whitequark>
it does, morally speaking
<whitequark>
think of every HDL module port as having an (invisible, in most HDLs) attribute that says which clock it's synchronous to
<whitequark>
(or more precisely, which control set does it belong to)
proteus-guy has joined #nmigen
thinknok has quit [Ping timeout: 240 seconds]
<agg>
Hmm yea I guess the cdc morally occurs inside the module in that case
<agg>
Presumably doesn't have an impact on clock domain analysis in this case though?
<whitequark>
it does, well, it should ideally
<whitequark>
mostly we don't have a proper clock domain analysis
Asu has joined #nmigen
Asu is now known as Asuu
Asuu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<cr1901_modern>
>but after two or three FFs it becomes vastly more likely that the FPGA will fail in a different way
<cr1901_modern>
Indeed. I shouldn't have questioned that a 2FF _can_ have metastability.
<cr1901_modern>
I think I was distinguishing between "metastability due to a blatant edge on the input" (for the first FF), and "metastability due to an indeterminate value taking it's good ol' time to settle" (every other FF).
<cr1901_modern>
The second situation is... not the first failure cause I would think of.
<cr1901_modern>
(Ditto with the related "the first FF's Q decided to never settle on a determinate value")
<sorear>
have you encountered the concept of an "arbiter"
proteus-guy has quit [Remote host closed the connection]
<cr1901_modern>
The thing that decides whether two pieces of hardware need access to the same bus?
<sorear>
the problem here is continuity - the phase of the source clock is a continuous variable, electronics compute continuous functions, so there *must* be some clock phase which causes the electronics to output "0.5"
proteus-dude has joined #nmigen
<cr1901_modern>
Then I'm guessing there's no real difference in the behavior of the output value for "metastability due to a blatant edge on the input" and "metastability [on the input] due to an indeterminate value taking it's good ol' time to settle"
<cr1901_modern>
Buridan's Ass will probably enlighten me.
<sorear>
the first 1FF is metastable due to a blatant edge on the input
<sorear>
the length of time the 1FF takes to settle is random and unbounded
<sorear>
it is _extremely likely_ to have settled by the next clock cycle, and thus clock a well-defined value into the second register
<cr1901_modern>
Right. My question is if you feed a 1FF with a stable "0.5" (analogous to an ass being placed straight between water and hay), what happens? Sure this experiment's been done plenty of times... just didn't think about it much before today.
<sorear>
you can't, because the 1FF picks up ambient and quantum noise which is amplified exponentially
<sorear>
the Intel RDRAND circuit uses a flip-flop biased as close as technically possible to its midpoint iirc
<sorear>
if you replace the FF with a combinatorial circuit you can measure the input-output curve
<cr1901_modern>
>with a combinatorial circuit
<cr1901_modern>
By that I assume you mean a plain ol' buffer or inverter?
<sorear>
yes
<sorear>
a buffer is just an amplifier and has well-defined gain
<_whitenotifier-9>
[nmigen] anuejn commented on issue #383: UnusedMustUse warnings are emitted after the toolchain ran - https://git.io/JfCDV
thinknok has joined #nmigen
proteus-dude has quit [Quit: Leaving]
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
thinknok has quit [Ping timeout: 265 seconds]
jeanthom has joined #nmigen
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]