00:02 <_whitenotifier-9> [nmigen] akukulanski commented on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/Jfctr

00:03 <_whitenotifier-9> [nmigen] akukulanski edited a comment on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/Jfctr

00:04 <_whitenotifier-9> [nmigen] akukulanski edited a comment on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/Jfctr

00:04 <_whitenotifier-9> [nmigen] akukulanski edited a comment on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/Jfctr

02:08 <ktemkin> Sarayan: seems like an odd place for it, but thanks for the compliment ^^

03:53 <_whitenotifier-9> [nmigen] whitequark commented on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/JfcGs

04:31 <awygle> whitequark: so if i have a Value which is (& (sig a) (sig b)), i can't use Past on it because it's not a Signal. is there a way to like, evaluate that expression so i can use Past on it, or is an intermediate wire a requirement?

04:34 <whitequark> awygle: the whole restriction on what you can use Past() on is artificial

04:34 <awygle> did we talk about this before, and i agreed to fix it, and haven't yet? or was that a different thing

04:34 <whitequark> it's a limitation of the current internals that has no reason to exist other than "I didn't think it through"

04:34 <whitequark> i'm not sure if there is a nice easy fix

04:35 <whitequark> the planned rewrite of the AST transformers would fix it as a side effect

04:37 <awygle> ah, mk

04:37 <awygle> well nvm then

04:37 <awygle> intermediate signal is no great hardship

04:37 <awygle> unless i should file a bug to track?

04:40 <_whitenotifier-9> [nmigen-boards] whitequark closed pull request #62: add empty resources to tinyfpga_ax* - https://git.io/JfnHU

04:40 <_whitenotifier-9> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JfcGx

04:40 <_whitenotifier-9> [nmigen/nmigen-boards] zignig 2f02b39 - tinyfpga_ax{1,2}: add missing `resources`.

04:40 <_whitenotifier-9> [nmigen-boards] whitequark commented on pull request #62: add empty resources to tinyfpga_ax* - https://git.io/JfcGp

04:41 <_whitenotifier-9> [nmigen-boards] whitequark commented on issue #61: Spork Errors - https://git.io/JfcGh

04:41 <_whitenotifier-9> [nmigen-boards] whitequark closed issue #61: Spork Errors - https://git.io/JfnyU

04:42 <_whitenotifier-9> [nmigen] whitequark closed pull request #382: vendor: add bit file generation for machXO2 - https://git.io/JfnF5

04:42 <_whitenotifier-9> [nmigen] whitequark commented on pull request #382: vendor: add bit file generation for machXO2 - https://git.io/JfcZv

04:42 <_whitenotifier-9> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JfcZf

04:42 <_whitenotifier-9> [nmigen/nmigen] trabucayre e301798 - vendor.lattice_machxo2: generate binary bitstreams.

04:42 <_whitenotifier-9> [nmigen] whitequark edited a comment on pull request #382: vendor: add bit file generation for machXO2 - https://git.io/JfcZv

04:43 <awygle> whitequark: also, is there a way to name the traces from Cover statements? i'm getting six traces (expected) but idk which corresponds to which Cover property

05:12 <whitequark> awygle: hm. which traces?

05:13 <whitequark> i don't recall deliberately adding traces for covers

05:13 <whitequark> so it could be a side effect or something

05:14 <awygle> they just happen from sby i think

06:07 <_whitenotifier-9> [nmigen-boards] whitequark reviewed pull request #49 commit - https://git.io/JfcC0

06:07 <_whitenotifier-9> [nmigen-boards] whitequark reviewed pull request #49 commit - https://git.io/JfcCE

06:07 <_whitenotifier-9> [nmigen-boards] whitequark reviewed pull request #49 commit - https://git.io/JfcCu

06:07 <_whitenotifier-9> [nmigen-boards] whitequark reviewed pull request #49 commit - https://git.io/JfcCz

06:48 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWc

06:50 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWc

06:51 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWc

06:54 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWE

07:01 <_whitenotifier-9> [nmigen] programmerjake commented on issue #381: [RFC] Add a (more) general shape conversion operator - https://git.io/JfcWi

07:01 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWP

07:01 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWP

07:10 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWP

07:10 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWE

07:10 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWc

07:14 <_whitenotifier-9> [nmigen-boards] peteut reviewed pull request #49 commit - https://git.io/JfcWN

07:48 <_whitenotifier-9> [nmigen-boards] zignig commented on issue #61: Spork Errors - https://git.io/Jfc8U

13:03 <_whitenotifier-9> [nmigen] anuejn opened issue #383: UnusedMustUse warnings are emitted after the toolchain ran - https://git.io/Jfc6I

13:04 <_whitenotifier-9> [nmigen] anuejn edited issue #383: UnusedMustUse warnings are emitted after the toolchain ran - https://git.io/Jfc6I

19:34 <awygle> would you expect a UART in nmigen-stdio to have the FFSynchronizer built in, or have it be at the top level and the output passed into the UART receiver?

19:40 <cr1901_modern> Just gonna put this out there... whenever I've implemented a UART myself, I don't bother w/ the synchronizer. Yes, I know this is a bad idea. But I just never remember to do it b/c UARTs tend to be so damn slow.

19:40 <cr1901_modern> So prob should be built in to make it lazy/forgetful-proof?

19:43 <daveshah> Being slow definitely doesn't prevent metastability

19:44 <daveshah> The low edge frequency does mean it is less likely to happen just because there are fewer transitions

19:44 <daveshah> Of course a 2FF doesn't prevent it either, but does take the probability so low that most people don't care

19:45 <awygle> cr1901_modern: I just spent a week chasing bugs caused by lacking one lol

19:46 <cr1901_modern> >Of course a 2FF doesn't prevent it either

19:46 <cr1901_modern> It doesn't? Prob should reread that one EEtimes article

19:48 <awygle> You can't totally prevent it even with an arbitrary number of synchronizing flip flops, but you can drive the probability of metastability at the output arbitrarily low.

19:48 <cr1901_modern> Well I guess statistically it doesn't, but I would be concerned if I personally saw metastability lasted so long that Q was still indeterminate (between 0 and 1) a full clock cycle later.

19:48 <cr1901_modern> (As opposed to settling on either the correct or incorrect value)

19:48 <awygle> Yeah exactly

19:55 <daveshah> In any case alpha particles/cosmic rays mean current FPGA/ASIC reliability is ultimately limited anyway

19:58 <Sarayan> ktemkin: I find twitter a little too public, and DM to oeasily leading to misinterpretations