00:17 <_whitenotifier-a> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JWgEa

00:17 <_whitenotifier-a> [YoWASP/nextpnr] whitequark d8d55e7 - Update dependencies.

00:54 <_whitenotifier-a> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JWgPA

00:54 <_whitenotifier-a> [YoWASP/yosys] whitequark 5efdf81 - Update dependencies.

01:02 <mithro> Yay - https://www.crowdsupply.com/great-scott-gadgets/luna

11:02 <Degi> \o/

17:29 <_whitenotifier-a> [nmigen] jfng opened pull request #622: _toolchain: substitute '+' with 'X' in tool_env_var(). - https://git.io/JWKaY

17:31 <_whitenotifier-a> [nmigen] codecov[bot] commented on pull request #622: _toolchain: substitute '+' with 'X' in tool_env_var(). - https://git.io/JWKVe

17:32 <_whitenotifier-a> [nmigen] codecov[bot] edited a comment on pull request #622: _toolchain: substitute '+' with 'X' in tool_env_var(). - https://git.io/JWKVe

17:33 <_whitenotifier-a> [nmigen] codecov[bot] edited a comment on pull request #622: _toolchain: substitute '+' with 'X' in tool_env_var(). - https://git.io/JWKVe

17:48 <mithro> People might find https://www.bunniestudios.com/blog/?p=6140 and https://ci.betrusted.io/betrusted-soc/doc/engine.html interesting

20:09 <ldm> I know it's a bit apples-and-oranges, but how does the xc7a35t compare against ECP5-12k? Trying to work out if it's significantly faster or about the same as the ECP that I've got rn

20:24 <DX-MON> so.. I'm trying to translate some code written in verilog into nMigen (by someone else).. and I'm wondering how I represent the assignment `default: debounce <= 3'bxxx;`

20:25 <tpw_rules> i don't think nmigen has a concept of 1'bx or 1'bz

20:25 <DX-MON> I've guessed that I can take the match string `4'b0zz0` and turn that into the case '0--0'

20:25 <DX-MON> hmm.. unfortunate

20:27 <DX-MON> I'm unsure what to translate this into then.. :|

20:27 <tpw_rules> add some sort of enable signal

20:28 <Sarayan> z doesn't exist in a fpga

20:28 <DX-MON> it's a debouncer that must step every clock cycle and which was written without documentation as to how and why it works

20:29 <d1b2> <DX-MON> this is the source verilog I'm trying to translate

20:29 <d1b2> <DX-MON> https://cdn.discordapp.com/attachments/726185180599156796/865691657021554758/unknown.png

20:30 <DX-MON> Sarayan: I understand that.. I think that's been used to help make it simulatable in a manner that allows detecting errors.. however, I don't know what yosys is translating this working code to internally

20:31 <Sarayan> It's a don't care, so '-' is good

20:32 <DX-MON> ok, so the z's side of things is fine.. that leaves me bewildered as to how to handle those x's

20:32 <tpw_rules> is that state even reachable?

20:32 <DX-MON> I.. don't actually know

20:32 <DX-MON> this is why I wish this had more documentation

20:32 <Sarayan> I suspect it's the verilog version of abort(), use 0 and it's all good

20:32 <DX-MON> (by which I mean.. any..)

20:32 <tpw_rules> it does not seem to be

20:33 <DX-MON> okie

20:33 <tpw_rules> yeah i think they just had doctrine that their case needed a default state

20:33 <tpw_rules> but i counted the states and there are 16 of them so it can't be reached

20:33 <d1b2> <DX-MON> https://cdn.discordapp.com/attachments/726185180599156796/865692624504619018/unknown.png

20:33 <DX-MON> this is how I trsnalted it

20:33 <DX-MON> *translated

20:34 <tpw_rules> you need to swap the arguments to Cat, probably

20:34 <tpw_rules> low bits go on the left

20:34 <tpw_rules> also it would probably be clearer to keep the binary number assignments to debounce. you can use 0b

20:34 <DX-MON> I was considering expanding the values out, yes

20:35 <DX-MON> as for Cat.. good call as it's generating a backwards casez to the source verilog..

20:36 <DX-MON> the source code I'm trying to rework is really.. dense.. V_V it's making for a misurable experience

20:36 <DX-MON> like.. this:

20:36 <DX-MON> always @(posedge clk)

20:36 <DX-MON> samp_cnt <= ({ 1'b0, samp_cnt[SAMP_TW-1:0] } + 1) & {(SAMP_TW+1){~samp_cnt[SAMP_TW]}};

20:36 <DX-MON> I think I've figured out how it works and what it does but like.. aaaa

20:36 <Sarayan> I find nmigen *way* more readable

20:37 <tpw_rules> is there any particular reason you are translating it?

20:37 <DX-MON> agreed Sarayan

20:37 <tpw_rules> if it's purely because you need to use it, you can simply use an Instance to instantiate it as verilog

20:38 <DX-MON> tpw_rules: the project I'm working in is pure nMigen and I really don't want to have to deal with copying in this other code while respecting its different license to my project and then having to manage it within an otherwise pure project

20:38 <tpw_rules> ok. just making sure you knew that was an option

20:38 <DX-MON> I'm aware of the option and had already considered.. and discounted.. it

20:40 <DX-MON> I'm also essentially doing some groundwork for the nMigen version of the iCEBreaker Bitsy examples as the code in question is to take a button input, debounce it, count how long it's held down for, and use that as input to the warmboot block to allow the user gateware to reboot back into the bootloader gateware cleanly

21:26 <DX-MON> well, it's still broken but at least now I'm confident that it's not because of the debouncer.. frustrating though certain parts of the peripheral do now work

22:57 <_whitenotifier-a> [nmigen] rroohhh opened issue #623: Option to disable debug verilog generation - https://git.io/JW6o3