plonk has quit [Remote host closed the connection]
plonk has joined #m-labs
plonk has quit [Changing host]
plonk has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
futarisIRCcloud has joined #m-labs
<_whitenotifier-3>
[smoltcp] HeroicKatora commented on pull request #285: [WIP. Don't merge] Resilience to error in packet decoding - https://git.io/fjFN7
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
<TD-Linux>
in migen is there a way for a signal to be wired up as a global reset?
<_whitenotifier-3>
[smoltcp] HeroicKatora closed pull request #285: [WIP. Don't merge] Resilience to error in packet decoding - https://git.io/fjFAF
<lkcl>
whitequark: is there a yosys "cell" for an And-Or-Invert (AOI) logic block? https://en.wikipedia.org/wiki/AND-OR-Invert apparently these can be implemented more efficiently than doing it as two ANDs and a NOR [or a single AND and a NOR]
<lkcl>
more to the point: if one was ever added, would you be happy to add nmigen support for it?
<TD-Linux>
lkcl, FPGAs implement boolean logic via LUTs, so it's not more efficient for those
<lkcl>
TD-Linux: thank you. the Libre RISCV SoC is not targetting an FPGA.
<lkcl>
it'll be a multi-million gate ASIC with a 40 GMACs FPU.
<mtrbot-ml>
[mattermost] <miguel_moreno> miguel_moreno joined the team.
<_whitenotifier-3>
[smoltcp] whitequark commented on pull request #285: [WIP. Don't merge] Resilience to error in packet decoding - https://git.io/fjbTH
<whitequark>
TD-Linux: a "global reset" is not an ubiquitous FPGA primitive, e.g. ice40 doesn't have it
<whitequark>
and ecp5 has it but it's not supported by nextpnr
<whitequark>
you want to wire something to all your clock domains or something like that
<whitequark>
lkcl: yosys has a cell for AOI, and you can instantiate it in nmigen just fine. nmigen will not have an AST node for AOI because it's the wrong abstraction level. you can describe it behaviorally if you want.
<whitequark>
TD-Linux: regarding DriverConflict, well, omigen flattened the hierarchy, nmigen tries to not do that
<whitequark>
note that just overriding stuff in order in a *single module* is just fine. doing this *across modules* is the problem
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
olofk has joined #m-labs
<olofk>
Hi all. Looking for some Migen/Litex hand-holding
<olofk>
I have a core that contains a bunch of CSRStorage/CSRStatus. Now I want to expose a single axi/wb slave interface but I have no idea how to put this together
<mtrbot-ml>
[mattermost] <sb10q> You call get_csrs on your core to get the description, and this csrbank will give you a wishbone interface
<olofk>
cool, thanks! So now I have a CSRBank object. Do I add it as a submodule and start pulling out the pins with platform.request? I'm generating a stand-alone migen core in a verilog-based SoC
<olofk>
Fantastic! I think I got it rigt
<olofk>
Now I think I've seen some method to also generate a csv or similar with the register map.
<olofk>
I could pick it out from the generated verilog. That's good enough for now
<olofk>
Now I just have to figure out how the core actually works :)
<_whitenotifier-3>
[nmigen] whitequark created branch vendor.lattice_ecp5-diamond - https://git.io/fhUU5
<_whitenotifier-3>
[m-labs/nmigen] whitequark pushed 1 commit to vendor.lattice_ecp5-diamond [+0/-0/±1] https://git.io/fjbtY
<TD-Linux>
tx_counter is driven both in the IDLE state, as well as the counter logic in the sync block above
<whitequark>
TD-Linux: you're using nmigen.compat. do not use that
<TD-Linux>
ah this will go away when I convert everything off of compat?
<whitequark>
yep
<TD-Linux>
cool
<whitequark>
there is intentionally no effort to make nmigen.compat flow idiomatic. it exists to let you migrate off omigen partially
<TD-Linux>
as for reset, I didn't imagine it using the fpga reset signal, but just inserting a synchronous reset on everything within that clock domain (as nmigen already knows all the reset values)
<whitequark>
I'm confused. what's wrong with driving ResetSignal("domain") ?
<TD-Linux>
whitequark, that's the answer I was after. thanks
<whitequark>
note that ResetSignal("sync") without explicitly instantiating ClockDomain("sync") won't work
<whitequark>
well, not guaranteed to. on iCE40 for example there is some code in the vendor support that makes sure your design is reset until BRAMs are initialized
<whitequark>
you can make a new domain, or copy that code into your design
<TD-Linux>
whitequark, oh cool you were able to patch around that bug? neat