ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 20th
lkcl_ has joined #nmigen
<ktemkin> actually, hell, I'll accept the change as is and then take the more work later; it's easier than getting my brain to articular a complex thought at the moment >.>
lkcl__ has quit [Ping timeout: 258 seconds]
<_whitenotifier-b> [nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJO4S
<_whitenotifier-b> [nmigen] whitequark commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJO4p
<_whitenotifier-b> [nmigen] programmerjake opened pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBq
<_whitenotifier-b> [nmigen] programmerjake commented on issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJOBY
<_whitenotifier-b> [nmigen] programmerjake edited pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBq
<_whitenotifier-b> [nmigen] whitequark commented on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBW
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel_ has joined #nmigen
<_whitenotifier-b> [nmigen] programmerjake commented on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOB7
<_whitenotifier-b> [nmigen] codecov[bot] commented on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBF
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBF
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBF
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBF
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #nmigen
<awygle> whitequark: can you tick the simulator multiple clocks at once? also, can you assert a module's state machine's state directly or do you need to add debugging logic to the core?
<whitequark> a) yes, b) yes, grep find_generated()
<whitequark> in nmigen sources
<awygle> mk will do
<awygle> how do i do the first one? yield Tick(8) didn't work, neither did yield Tick('sync', 8)
<whitequark> uh, 8?
<awygle> i wanted to tick it 8 clocks
<whitequark> oh, multiple *cycles* at once
<whitequark> that's completely different
<awygle> i ended up doing "for _ in range(8) yield"
<whitequark> yes, that's how you do it
<awygle> arright
<whitequark> so, fun fact
<whitequark> because of all the python overhead (clocks are toggled in python), cxxsim is currently only 4 times faster than pysim
<whitequark> on minerva-soc
<whitequark> amdahl's law
<whitequark> ok, not exactly that, but a similar effect
<awygle> that's not too surprising i guess
<awygle> kind of a bummer tho
<whitequark> probably going to be even slower once i finish hooking it up
<whitequark> interestingly, the python overhead is ~fixed, so the larger the design is, the more of a difference this'll make
<_whitenotifier-b> [nmigen] whitequark closed issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYIO
<_whitenotifier-b> [nmigen] whitequark closed pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJOBq
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJO00
<_whitenotifier-b> [nmigen/nmigen] programmerjake 58f1d4b - sim.pysim: write the next, not curr signal value to the VCD file
<_whitenotifier-b> [nmigen] whitequark reopened issue #429: values in vcd are zero despite simulation's nonzero values - https://git.io/JJYIO
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJO0z
<_whitenotifier-b> [nmigen/nmigen] whitequark df0b70a - Deploying to gh-pages from @ 58f1d4bcb67176bb91082ff3c2065fea9a10837e 🚀
<_whitenotifier-b> [nmigen] programmerjake commented on pull request #430: write next state to vcd instead of curr state, since state is written just prior to commit - https://git.io/JJO0Q
<TD-Linux> swear that nmigen-boards' setup.py test did something yesterday, but today it just says it ran 0 tests
<whitequark> it would be super surprising to me if it did anything
<TD-Linux> ah it does check syntax and nothing else
<whitequark> oh
<TD-Linux> (I've been using blinky for an actual test)
gregdavill has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOEA
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOue
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOuJ
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOuU
<TD-Linux> any suggestions for naming the virtual pins? I was thinking "vcc_virtual" and "gnd_virtual". they are the same as the LUNA names right now, but I think that's confusing because LUNA doesn't use PinsN so porting a design from LUNA to nmigen-boards would short them
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOuz
electronic_eel_ has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
<_whitenotifier-b> [nmigen-boards] gregdavill commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOup
<_whitenotifier-b> [nmigen] programmerjake opened issue #431: add event variables to vcd - https://git.io/JJOzV
PyroPeter_ has joined #nmigen
lkcl__ has joined #nmigen
PyroPeter_ is now known as PyroPeter
lkcl_ has quit [Ping timeout: 256 seconds]
<_whitenotifier-b> [nmigen-boards] tdaede commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOgO
proteus-guy has quit [Ping timeout: 272 seconds]
jeanthom has joined #nmigen
hitomi2504 has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 272 seconds]
Asu has joined #nmigen
<whitequark> sigh, github is down
<trabucayre> yep :(
jeanthom has joined #nmigen
<_whitenotifier-b> [nmigen] whitequark commented on issue #431: add event variables to vcd - https://git.io/JJO6G
<_whitenotifier-b> [nmigen] whitequark closed issue #431: add event variables to vcd - https://git.io/JJOzV
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJO6W
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO64
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO62
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO6a
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO6V
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO6w
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJO6r
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO6w
<_whitenotifier-b> [nmigen-boards] daveshah1 reviewed pull request #76 commit - https://git.io/JJO6K
<_whitenotifier-b> [nmigen-boards] daveshah1 reviewed pull request #76 commit - https://git.io/JJO6i
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOim
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJO10
<_whitenotifier-b> [nmigen-boards] tdaede opened pull request #77: Add RGB LEDs to blinky test. - https://git.io/JJO1u
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJO1V
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJO1M
gregdavill_ has joined #nmigen
gregdavill has quit [Ping timeout: 256 seconds]
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJO1x
<_whitenotifier-b> [nmigen/nmigen-boards] tdaede 342b009 - Add RGB LEDs to blinky test.
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #77: Add RGB LEDs to blinky test. - https://git.io/JJO1u
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOMO
<whitequark> so
<whitequark> would anyone here be up to solving some longstanding nmigen-boards issues?
<whitequark> e.g.: factoring out DDR3
<TD-Linux> whitequark, what's the intended way for overrides to be passed via the platform constructor
<whitequark> TD-Linux: there isn'
<whitequark> *isn't
<whitequark> overrides are passed to .build()
<whitequark> OrangeCrabR2_0Platform().build(fragment, ecppack_opts="...")
<TD-Linux> whoa it works with both a bare option and an override dict
<whitequark> oh?
<TD-Linux> whitequark, I could do the busywork of moving platforms to a DDR3Resource but I guess it requires solving https://github.com/nmigen/nmigen-boards/issues/74 first
<whitequark> TD-Linux: does it? I'd say that whichever solution we end up with, DDR3Resource makes it easier to deploy it
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<whitequark> you need to rebase #76 I think for it to become mergeable
<TD-Linux> ok. I didn't solve the connector vs resource thing yet
<TD-Linux> whitequark, I guess it's easier to change Pins to PinsN if it's all in one place
<whitequark> yes, though IIRC that was not what we decided to do when we discussed it on IRC
<_whitenotifier-b> [nmigen] programmerjake commented on issue #431: add event variables to vcd - https://git.io/JJOMP
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<TD-Linux> ok I can search for the irc discussion
<_whitenotifier-b> [nmigen] whitequark commented on issue #431: add event variables to vcd - https://git.io/JJOMD
<_whitenotifier-b> [nmigen] whitequark edited a comment on issue #431: add event variables to vcd - https://git.io/JJOMD
<_whitenotifier-b> [nmigen] whitequark commented on issue #431: add event variables to vcd - https://git.io/JJOMS
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOM7
<_whitenotifier-b> [nmigen] whitequark opened issue #432: Add support for Display - https://git.io/JJOMF
<_whitenotifier-b> [nmigen] whitequark edited issue #427: Add support for Assert in simulation - https://git.io/JJmIV
<_whitenotifier-b> [nmigen] whitequark edited issue #432: Add support for Display in simulation - https://git.io/JJOMF
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJODe
<whitequark> TD-Linux: looks like in the IRC discussion we decided that xdr=2 or xdr=4 would work there
<_whitenotifier-b> [nmigen-boards] whitequark commented on issue #74: DDR pins and *_n signals - https://git.io/JJOD3
<_whitenotifier-b> [nmigen-boards] whitequark closed issue #74: DDR pins and *_n signals - https://git.io/JJtgV
<_whitenotifier-b> [nmigen] programmerjake commented on issue #431: add event variables to vcd - https://git.io/JJODl
<MadHacker> ktemkin: Have you tried out LUNA's ACM serial stuff on Windows at all yet? I'm seeing two devices created, and no drivers. I'm thinking I should work a bit on the descriptors and add in the WCID magic to make it use the standard usbser.sys?
<whitequark> that should work on Windows
<whitequark> I'm guessing LUNA might not be answering to {GET,SET}_LINE_CODING
<TD-Linux> just so I understand correctly, the ecp5 platform instances the ddr modules so it grabs the io buffer directly, skipping the Pins/PinsN logic?
<MadHacker> whitequark: I think that's what stops PuTTY working with it even when I force-install the right driver, but the two-interfaces thing is also confusing it a bit.
<MadHacker> I probably need to properly look over the descriptors and tweak. I did previously the same for Fomu, should be managable enough.
<whitequark> ahh
<whitequark> is it a composite device?
<whitequark> IIRC you can't have inf-less composite devices on Windows, ever
<whitequark> TD-Linux: the platform doesn't (and can't) instantiate anything, platforms are declarative
<whitequark> well, currently, anyway
<MadHacker> No, two interfaces not subdevices.
lkcl__ has joined #nmigen
<MadHacker> ACM's weird.
<whitequark> right, I thought there was also DFU involved
<whitequark> for some reason
<whitequark> that looks like it should work
<MadHacker> There was for Fomu, not LUNA.
<whitequark> ah right
<MadHacker> In context, my running-luna-on-it-hardware is a USB+Ethernet+uSD card interface for a BBC Micro (8-bit 6502 machine).
<MadHacker> So somewhat off the beaten track already.
lkcl_ has quit [Ping timeout: 240 seconds]
<_whitenotifier-b> [nmigen] whitequark commented on issue #431: add event variables to vcd - https://git.io/JJOD9
<_whitenotifier-b> [nmigen] whitequark edited a comment on issue #431: add event variables to vcd - https://git.io/JJOD9
<TD-Linux> hmm just realized my LDQS and HDQS are opposite the order in LUNA. I assumed LDQS would be first given the bit order in the rest of nmigen?
<whitequark> LDQS should be first yes
<TD-Linux> ok same for LDM
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
<_whitenotifier-b> [nmigen] whitequark commented on issue #431: add event variables to vcd - https://git.io/JJOyl
<_whitenotifier-b> [nmigen] whitequark edited a comment on issue #431: add event variables to vcd - https://git.io/JJOyl
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOSG
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOSn
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOSG
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOSy
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO9U
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO9U
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOSn
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOSG
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO9U
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJO9O
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJO9n
<_whitenotifier-b> [nmigen-boards] gregdavill reviewed pull request #76 commit - https://git.io/JJO9o
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO9M
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJO9M
<DaKnig> how does nmigen deal with arrays? python list of signals?
<DaKnig> from what I understand signals are just numbers/bit arrays like in verilog
<whitequark> DaKnig: have you looked at https://nmigen.info/nmigen/latest/lang.html yet? it explains in depth how signals work
q3k has quit [Ping timeout: 260 seconds]
<whitequark> but not arrays, yet
<DaKnig> I looked there, and that's what I read so far. I finished the part about signals.
<whitequark> great! so, for arrays, there's the Array class, which is indexable with a Signal, unlike Python list
<whitequark> in other respects it works basically the same
<DaKnig> can you index it with a python int?
<whitequark> sure, in that case you just get the element
<DaKnig> also can you make an array of arrays (of arrays...)?
q3k has joined #nmigen
<DaKnig> rn Im porting some ugly code from vhdl to nmigen, and I use arrays of arrays there
<whitequark> yes, you can do that
<whitequark> the resulting multiplexers can get quite large, but it works fine
<DaKnig> nice!
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<MadHacker> whitequark: Does it ever manage to infer a memory from that?
<whitequark> MadHacker: nMigen never "infers" anything
<whitequark> very much on purpose
<whitequark> if you want a memory, you use a Memory()
<_whitenotifier-b> [nmigen-boards] tdaede reviewed pull request #76 commit - https://git.io/JJOH0
<DaKnig> isnt inferring memory the job for the synth tool?
<MadHacker> Sorry, let me rephrase, does it generate them in such a way that it's possible that yosys+nextpnr between them will do so?
<DaKnig> nmigen is not a synth tool from what I understand
<whitequark> it is not the job of a toolchain to guess what kind of primitive you wanted
<MadHacker> I'm aware nmigen won't do that and isn't intended to.
<whitequark> MadHacker: it does not, and if it did, it would be a bug
<MadHacker> OK.
<whitequark> DaKnig: memory inference is the task of the language frontend even with Verilog
<whitequark> though some parts of that process might be done by the optimizer for various reasons
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOHo
<_whitenotifier-b> [nmigen-boards] whitequark reviewed pull request #76 commit - https://git.io/JJOHo
<DaKnig> where can I look for small examples of complete circuits?
<Lofty> DaKnig: Well, nmigen has an examples directory
<DaKnig> I didnt notice! ok will take a look
<whitequark> (some parts such as deciding whether a given port is synchronous or asynchronous, for example... which leads to extremely subtle bugs nMigen then ends up having to work around with Verilog-based targets!)
<DaKnig> it's a bit annoying that Cat(A,B) puts A in the lower part and B in the higher part
<DaKnig> VHDL solves that by giving each array-type signal a direction
<whitequark> it's how Python containers work
<TD-Linux> clearly nmigen should have used powerpc bit numbering
<whitequark> TD-Linux: i actually call this out as a (non-)solution in the guide
<DaKnig> im not sure following python behavior with everything is the best solution
<whitequark> DaKnig: well, it's a HDL embedded in Python, it better follow how Python abstractions work
<whitequark> note that we don't follow every Python convention everywhere
<whitequark> for example, nMigen aggressively checks types upfront instead of relying on duck typing
* TD-Linux now wonders if unicode right to left overrides are allowed in python
<whitequark> but in this case? the collection interface is pretty fundamental to Python and it is explicitly required to have [0] be the first element
<whitequark> so it's either the current behavior, or having lsb be the bit with the highest index
<TD-Linux> the error checking is super appreciated, coming from debugging oMigen by reading the verilog
<whitequark> yep
<whitequark> a few hardline Python people blow a gasket at this, but I don't really care
<whitequark> what matters is the experience of using it, not some arbitrary conventions
<whitequark> sometimes the arbitrary conventions help, sometimes the opposite, it takes actual judgement to see which
<DaKnig> yes
<whitequark> what would have also been possible is to not implement len() and [] for values at all
<whitequark> so you'd have value.width and value.slice(...)
<DaKnig> is there an operation for reversing the bits of a value?
<whitequark> reverse(value)
<whitequark> well, Cat(reverse(value))
<DaKnig> NameError: name 'reverse' is not defined
<whitequark> er, sorry
<whitequark> Cat(reversed(value))
<whitequark> `reversed` is a standard Python function
<whitequark> you could also do value[::-1]
<DaKnig> im learning so much about python :)
<DaKnig> ok thanks
<DaKnig> so nmigen doesnt have "ports", just signals that you can use as ports, right?
<whitequark> basically yea
<DaKnig> what's "Elaboratable"
<DaKnig> ?
<whitequark> semantically, or in terms of implementation?
<DaKnig> what does it mean when a class ( a component) inherits from that?
<DaKnig> what is that class?
<whitequark> it is a class that generates some kind of circuit in its `elaborate` method
<Lofty> FWIW, #243 proposes something which I think is a lot more useful than Verilog/VHDL style ports
<Lofty> Basically you declare public, nonoptional signals by making them must_read/must_write
<whitequark> (but note that I don't think must_read/must_write are the way to go here; see https://github.com/nmigen/nmigen/issues/243#issuecomment-578782512)
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
<Lofty> Well, thinking a little more about it, attaching them to Elaboratables is not general enough.
<Lofty> e.g. the Value operators that take in Signals are not Elaboratables
<whitequark> right, so it is possible to have both that and some kind of must_use lint
<whitequark> but the latter is not directly related to ports
Asuu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
<Lofty> It seemed from your comment you thought these were mutually exclusive
<whitequark> Lofty: well, sort of
<whitequark> we need something that would positively declare ports, not just a lint
<whitequark> and must_read/must_write are not appropriate for that task
<whitequark> but it's possible, in principle, to have both
<Lofty> Okay, hmm
<whitequark> since that issue was about specifying the ports of an elaboratable, I said that must_* are not the right approach for the task
<whitequark> but that doesn't mean it's not the right approach for anything
_whitelogger has joined #nmigen
gregdavill_ has quit [Quit: Leaving]
electronic_eel has quit [*.net *.split]
Degi has quit [*.net *.split]
zignig has quit [*.net *.split]
Degi has joined #nmigen
electronic_eel has joined #nmigen
zignig has joined #nmigen
<lkcl__> > "DakKnig: im not sure following python behavior with everything is the best solution"
<lkcl__> DaKnig: how else would it be done? python lists (slices) are start:end inclusive. python list indexing is left to right.
<lkcl__> in effect what you're asking is, "python, the programming language, please invert the ordering of arguments and lists"
<lkcl__> :)
<whitequark> python slices are start:end exclusive
<whitequark> well, start inclusive, end exclusive
<whitequark> (verilog has both start and end inclusive)
<lkcl__> whitequark: ah, yes, thank you for the correction.
<whitequark> anyway, you can also do what myhdl does and break the contract of python: http://docs.myhdl.org/en/stable/manual/hwtypes.html#bit-slicing
<whitequark> i specifically chose not to do that
<lkcl__> you should see the auto-generated output from the POWER9 spec converter. i had to output "end+1" on all slices.
<lkcl__> and as for the POWER9 endianness...
<lkcl__> DaKnig: i do a *lot* of vhdl to nmigen conversion because we're using microwatt (vhdl) as a reference guide for libre-soc. you get... used to it :)
<lkcl__> whitequark: i'm grateful that you did. non-compliance with python, when we have significant use of python OO features to create dynamic classes, would have been absolute hell.
<lkcl__> myhdl can get away with it because myhdl is a python AST language translator. it takes the *actual* python source code and converts it to HDL.
<whitequark> not here
<whitequark> you can index `intbv` directly in python code without generating anything
<whitequark> it can *partly* get away with it, sure, but not entirely
<lkcl__> :)
cr1901_modern has quit [Read error: Connection reset by peer]
<lkcl__> one of the very specific reasons why we picked nmigen over myhdl was because you can do python for-loops to generate AST.
cr1901_modern has joined #nmigen
<lkcl__> we use this to read a CSV file containing information that is used to generate a (massive) nmigen Switch/Case array.
<lkcl__> you simply cannot do that in myhdl: you're forced to write out every single line of the switch statement... *as python code*.
<whitequark> yep
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
<lkcl__> honestly it makes understanding the code a little bit harder (due to the abstraction) however it's also far shorter, and we can use the same machine-readable CSV files for other purposes (automated documentation, automated unit tests, formal proofs, website)
<whitequark> yep
<lkcl__> whitequark: is there a rotl function anywhere around? in a library or as an actual operator?
<whitequark> .rotate_left()
<lkcl__> whitequark: ahh :)
<whitequark> but the amount is constatn
<whitequark> *constant
<lkcl__> ah ok. we need a variable version (POWER9)
<whitequark> Cat(value, value).bit_select(amount, len(value))
<whitequark> this is defined for amounts in range(len(value))
<lkcl__> oh right. ahhh that explains why microwatt repeats a value twice for 32-bit. neat trick, wondered why it was done.
<lkcl__> thanks
<whitequark> it is done because this way the operation can be mapped to a barrel shifter
<whitequark> if you expressed it as a 32:1 mux, chances would be much lower that the backend can implement it efficiently
<lkcl__> interesting
<whitequark> both bit_select and word_select are using shift primitives
<lkcl__> hmmm i wonder if that decreases the gate count... hmmm..
* lkcl__ just going to check
<lkcl__> we're currently using:
<lkcl__> comb += shr.eq(self.a >> (self.width - self.b))
<lkcl__> comb += self.o.eq(shl | shr)
<lkcl__> comb += shl.eq(self.a << self.b)
<lkcl__> that's interesting. yosys shows no difference. going with bit_select anyway because it's shorter
<lkcl__> (one line, not 3)
<whitequark> abc can probably see through it
cr1901_modern1 has joined #nmigen
<_whitenotifier-b> [nmigen-boards] whitequark synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
cr1901_modern has quit [Ping timeout: 256 seconds]
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJObR
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 272 seconds]
<_whitenotifier-b> [nmigen-boards] tdaede synchronize pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOA0
<_whitenotifier-b> [nmigen-boards] tdaede commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOAa
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOAr
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #76: Add OrangeCrab board. - https://git.io/JJYiY
<TD-Linux> dfu-suffix checking for a dfu header makes me want to attempt to make a bitstream that happens to have a dfu magic in it
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+1/-0/±0] https://git.io/JJOA6
<_whitenotifier-b> [nmigen/nmigen-boards] tdaede 856f712 - Add OrangeCrab R2.0 board.
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #76: Add OrangeCrab board. - https://git.io/JJOAi
<whitequark> lol
<TD-Linux> whitequark, thanks for reviewing this!
<whitequark> thanks for submitting it! one more thing I don't have to do myself :)
<whitequark> we really need (a) an autoformatter and (b) clear guidelines for nmigen-boards
<whitequark> which will definitely happen
<TD-Linux> the only thing my editor's formatter doesn't handle correctly is the function continuation indent
<whitequark> right so editor formatters (which do not normalize) are mostly fine
<whitequark> but autoformatters (which do usually normalize) mangle the code horribly
<TD-Linux> just having more examples to draw from helps with (b) as well (as long as they are correct!)
<whitequark> there are quite a few boards already, right?
<TD-Linux> yeah, and I drew a lot from versa_ecp5.py (which is formatted wrong btw)
<whitequark> dirty secret of nmigen-boards: there actually isn't a single consistent formatting style in it
<whitequark> even *i* can't remember exactly how it should look like
<TD-Linux> but orangecrab added several new conventions (required_tools, weird feather naming, psuedo power, program pin)
<TD-Linux> only led being a rgb one
<TD-Linux> I need to do ulx3s at some point too. it's a lot more complex but also more straightforward I think
<whitequark> required_tools is the same convention as before (well, the boards repo already has some uses of file_templates)
<whitequark> (which works the same way)
<whitequark> weird feather naming is also an existing convention, it's just not clearly codified anywhere
<whitequark> pseudo power and program pin are indeed new
<whitequark> not really sure if pseudo power is implemented in a particularly great way but oh well
<whitequark> it'll do for now
<trabucayre> maybe a stupid question: attrs=Attrs(IO_TYPE="LVCMOS33") mean something like IO_TYPE=LVCMOS33 in lpf ?
<whitequark> exactly that
<trabucayre> so for orangeCrab why SPIFlashResources has IO_STANDARD="LVCMOS33" ?
<whitequark> possibly an error? I didn't proofread those in particular
<daveshah> Yes ECP5 should be IO_TYPE
<daveshah> this should probably be at least a warning in nextpnr actually
<TD-Linux> yeah whoops I took too much ice40
<_whitenotifier-b> [nmigen-boards] trabucayre opened pull request #78: orangecrab_r0_2: IO_STANDARD -> IO_TYPE - https://git.io/JJOxp
<TD-Linux> my test didn't include the SPIFlashResources so it was ommitted from the lpf
<TD-Linux> oh actually this sort of breaks psuedo power
<trabucayre> I saw that by chance while looking at this board and machxo3_sk
<daveshah> In actual fact it won't the SPI flash as nextpnr (and Diamond iirc) defaults to LVCMOS33 for ECP5
<daveshah> *won't affect
<daveshah> But it will become a warning in nextpnr soon (then probably an error after a phase in period) as it is not the first time bad LPF properties being ignored has caused confusion
<daveshah> IO_STANDARD being the Xilinx terminology
<trabucayre> intel too
<trabucayre> altera
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJOps
<_whitenotifier-b> [nmigen/nmigen-boards] trabucayre 2cd86c1 - orangecrab_r0_2: IO_STANDARD -> IO_TYPE
<_whitenotifier-b> [nmigen-boards] whitequark closed pull request #78: orangecrab_r0_2: IO_STANDARD -> IO_TYPE - https://git.io/JJOxp
hitomi2504 has quit [Quit: Nettalk6 - www.ntalk.de]
jeanthom has quit [Ping timeout: 264 seconds]
proteus-guy has joined #nmigen
<awygle> whitequark: Instance inputs go to Yosys, right? so the input has to be Yosys-compatible, i.e. Verilog?
<Lofty> awygle: yep
<awygle> ah, thanks Lofty
<Lofty> Well, they can be VHDL if you're brave enough to parse those files with GHDL
<awygle> i am not a bad enough dude to ~~rescue the president~~ use GHDL
<whitequark> awygle: err, what are instance inputs?
<whitequark> `platform.add_file`?
<awygle> yeah
<whitequark> those go to the toolchain, which might not necessarily be yosys
<awygle> oh, hm
<whitequark> for example if you use diamond you can add VHDL files
<awygle> that's cool
<whitequark> you can also add sdc files, though that's not currently working for all toolchains, i think
<whitequark> but it def works for xilinx
<awygle> so what exactly is yosys used for, in cases where you don't use it as the synthesis tool? i know it's _something_ which is why the lightweight yowasp version exists
<Lofty> awygle: RTLIL -> Verilog
<whitequark> converting rtlil to verilog (and cxxrtl, in the future)
<awygle> is it nmigen->rtlil->yosys->verilog->diamond or something?
<Lofty> Yep
<lkcl__> there's also a vhdl plugin somewhere, so hypothetically it can be used for inter-HDL language conversion
<daveshah> ignore that plugin
<whitequark> that doesn't work
<daveshah> ghdl is much much better
<lkcl__> daveshah: ah :) sigh. in _theory_... :)
<daveshah> and it can be, I have done mixed language Verilog+VHDL sim using Yosys, ghdl and cxxrtl
<daveshah> the VHDL part was the MiST SNES core so non-trivial, the main change to it being replacing the Altera memory modules
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
* lkcl__ has POWER9 instructions executing: enough to run a helloworld program
<lkcl__> hurrah!
<hell__> :o
<Lofty> Congrats
<Lofty> Meanwhile, I've been working on an FPGA in nMigen because I'm apparently a masochist
<lkcl__> Lofty: thx. it's still a work-in-progress.
<lkcl__> Lofty: wait... is that... you're *designing* an FPGA, written in nmigen?
<Lofty> Yes
<lkcl__> coool
<lkcl__> do you have a funding route to get it into silicon?
<Lofty> The logic element is about where I want it in terms of features, but I think some data-driven development is required
<Lofty> I do: Google are funding wafers of chips that use their new SkyWater PDK
<lkcl__> if you're seriously committed to this, i can help advise a potential way to get you development funding and pay for a 180nm proof-of-concept ASIC.
<Lofty> They have an area limit though: 10mm^2
<lkcl__> 10 mm^2 in 180nm is around 120,000 gates... double that for 130 nm.
<lkcl__> 240,000 gates (ish) is reasonable
<d1b2> <TiltMeSenpai> lol nmigen-targeted fpga designed in nmigen
<lkcl__> if you spin it right (security, privacy) and as long as it's considered "in the public good", you should be able to put in a NLNet Grant application for up to EUR 50,000
<Lofty> I'm presuming the Liberty cell area is given in square microns: for a 4xLUT4 + carry lookahead logic + 4xDFF logic element, it's like 3170.5 u^2
<lkcl__> that should pay for your development costs, easily, enough to focus on it full-time if you wanted to.
<Lofty> But the tooling is lacking, presently, so take that with a good helping of salt
<lkcl__> Lofty: yyyeah we're working with Jean-Paul from Sorbonne University (coriolis2) and Staf Verhaegen (Chips4Makers).
<lkcl__> i mentioned a couple days ago: Staf is looking to support open silicon commercial projects by creating the cell libraries needed
<awygle> just out of curiosity (i'm unlikely to do anything) - do you have to be a European to apply for an NLNet grant?
<Lofty> Or, to put it another way: you can fill the die area with approximately 3K LMs for a total of 12K LUT4s
<lkcl__> then if you're prepared to write a reaaaasonably simple Makefile setup, you can "throw the ILANG file at coriolis2 auto-place/route" and it stands a reasonable chance of success
<lkcl__> awygle: you need to be linked somehow to the EEC area. citizen of Iceland would do, for example :)
* awygle sighs in american
<awygle> ah well
<lkcl__> or, be part of a team that *includes* one person with an address in the EU / EEC
<Lofty> Hurray for Brexit >.>
<lkcl__> find... _someone_ willing to help / sign
<lkcl__> Lofty: lol.
<lkcl__> awygle: NLNet would _greatly_ prefer that there be no limit as to who can apply. unfortunately, the EUR 11 million (ish) that they have is funding from an EU Horizon 2020 Programme Grant, and consequently have to respect the wishes of _their_ funders.
* lkcl__ sigh
<awygle> copy. makes sense
<lkcl__> find a friend or associate in the EEC, ask them to do something as simple as sign the Memorandum of Understanding, and you're good.
* Lofty wonders how much area there is to save by just using SkyWater full adders instead of the carry lookahead logic they presently have
<Lofty> It's really nice that you can just chop and change things like this in nMigen
<lkcl__> Lofty: interesting. they have full adders as part of their Standard Cell Library? how many bits?
<Lofty> They do, yes
<Lofty> It's probably just an individual full adder though
<lkcl__> the reason i ask is because most Standard Cell Libraries have like... 2-bit and 4-bit full adders and that's about it
<lkcl__> ah then yes i'd expect that.
<lkcl__> Lofty: look up nsxlib
<lkcl__> that's what Staf is working to improve (and he implemented for the test ASIC he did in April).
<Lofty> I suspect the propagation delay for ripple-carry is higher than carry-lookahead though
<lkcl__> Lofty: definitely.
jeanthom has quit [Ping timeout: 240 seconds]
<Lofty> At present I have an intra-module carry-lookahead chain
<lkcl__> unless there are seriously good reasons, you really want to rely on the tools to do the conversion for you.
<lkcl__> Lofty: ooo :)
<lkcl__> you may be interested to know, we had to create a dynamic partitioned version of Signal.
<lkcl__> a class - named PartitionedSignal - that subdivides at runtime-selectable breakpoints
<lkcl__> Lofty: that's funny. we had to create something like that, too :)
<lkcl__> oh hang on, not quite. we did a parallel version
<lkcl__> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_mul_add/adder.py;h=e1849b4d25fc5ec4fc4473cc02b32f49dd5912b2;hb=79424307e264164e69bc3c0fe5d9285e139f746a#l52
<lkcl__> Lofty: so... wait... is the class Carry also parallel? i see it also takes a width parameter
<lkcl__> m.d.comb += carry[i].eq((carry[i-1] & self.i_prop[i]) | self.i_gen[i])
<Lofty> It's a carry lookahead adder, so it's all parallel
<lkcl__> that's ... mmm.... there's a chain/dependency there between carry[i] and carry[i-1]
<Lofty> There *is*, but it's comparatively limited
<awygle> When you say eec, is that a synonym for EU, or do you mean eea, or is it something I'm not aware of?
<lkcl__> you might be interested in the Multiplier that Jacob did. it's a Wallace Tree multiplier which propagates the carry over to the next stage in the pipeline
<lkcl__> awygle: EEC -> European Economic C-for-something
<Lofty> Community, probably
<lkcl__> Lofty: community, yes. had to look it up :)
<awygle> Seems like that got eaten by the EU?
<Lofty> Yep
<whitequark> completely not confusing at all
<lkcl__> awygle: Iceland is separate and is part of the EEC
<lkcl__> whitequark, lol
<lkcl__> whitequark: ooo, reminds me of the XKCD 32-way Venn Diagram...
<lkcl__> which i'd never seen before so was really impressed
<awygle> whitequark: yeah but there's no eec there which is why I asked
<whitequark> oh right
* whitequark stares
<lkcl__> haha, Iceland's membership is... frozen https://en.wikipedia.org/wiki/Enlargement_of_the_European_Union
<lkcl__> Lofty: https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_mul_add/multiply.py;hb=HEAD
<Lofty> It's difficult to do much in the way of fancy carry logic for an FPGA though
<lkcl__> Lofty: it's... a handful
<lkcl__> yeah. are you thinking of doing a small DSP block?
<lkcl__> like, some multiply blocks and so on?
<Lofty> Maybe.
<lkcl__> because without those, the amount of LUTs needed is just... mental
<Lofty> Of course, but it also means you have less LUTs for everything else.
* lkcl__ looks up the Chisel FPGA...
<lkcl__> got it
<lkcl__> Lofty: idea for you. if you make sure to be compatible with that, you won't have to spend months on developing a toolchain.
<Lofty> I have this small thing called Yosys in mind
<Lofty> I decided to call the project Rain
<Lofty> Because, um
<Lofty> Sky
<Lofty> water
<Lofty> *ba dum tss*
<lkcl__> yosys integration makes the most sense
<whitequark> Redundant Array of Independent N-luts
<Lofty> Reusable Array of Independent N-luts works even better, I think
<MadHacker> Reconfigurable
<whitequark> right
<lkcl__> i worried for a minute there that it might have been "Recursive Array of ..."
<mwk> luts made of luts made of...
<Lofty> RAIN Acronym of Infinite Names
<MadHacker> Reluctantly Adds Integer Numbers.
<Lofty> So, ripple carry with vendor cells is indeed smaller, which makes sense, I suppose
<awygle> Raisins Aren't In Nachos
<lkcl__> haha
<awygle> That actually sounds pretty good...
<MadHacker> Reliably Adds Integers? No.
<awygle> Reoccurring Anger Ignites Nation
<Lofty> So *that's* why they're called the Fire Nation
<awygle> Requires Alert Intern Nearby
<awygle> I'll stop lol
<whitequark> lol
<Lofty> 45 whole square microns
<Lofty> Maybe I'll just be boring and put some carry-select logic in here
<Lofty> Having saved die area it instead gets used on some other inane thing
<sorear> oh _that's_ where the avocado diagram comes from
<whitequark> the what
<lkcl__> sorear: you mean, the XKCD 32-way venn diagram? it's really pretty, isn't it?
<sorear> yes
* lkcl__ yaaa, managed to do an actual useful formal proof of PowerISA extswsli
<Lofty> Old McPowerPC had a farm
<Lofty> eieio
<Lofty> (Enforce In-order Execution of I/O)
<lkcl__> Lofty: i'm guessing you know there's an actual eieio instruction... teehee
<Lofty> Yeah; I read the GameCube CPU docs
<lkcl__> i'd make a joke that they have "undo" instructions, but they're called "Transactions"
* lkcl__ screams briefly
<whitequark> also "rvwinkle"
<whitequark> each time i read that i think of hellsing
<whitequark> which is definitely *not* what the designers intended
<miek> if i want to add nmigen-boards support for orangecrab r0.1 too, what's the preferred way to do that? split the common bits into a base class & use inheritance?
<Lofty> I tried to use inheritance for MiSTer/DE10Nano
<Lofty> Didn't go too well
<whitequark> miek: can probably just copy
<whitequark> is there uh... 1.0?
<miek> ok, cheers. also i just noticed r0.2 ended up in a file named with the version number, shall i put r0.1 in its own file then?
<Lofty> https://puu.sh/G6JZm/03ea789765.png <-- Rain diagram nobody asked for
<awygle> here comes the RAIN again
<whitequark> yes
<awygle> is that yEd?
<Lofty> mwk might be interested
<whitequark> miek: we don't have a super developed convention for this, but what i'm thinking of is putting boards related so closely they inherit from the common base in one file
<whitequark> boards related less closely than that in separate files
<lkcl__> Lofty, coool
<Lofty> Personal thought is that the gen output can/should be another output to allow some level of fracturability
<mwk> hm, is fracturability a big win on LUTs that small?
<Lofty> Maybe not
<Lofty> But equally I don't have many LUTs to begin with
<sorear> forcing all LUT outputs to go through the carry chain could be bad for speed
<Lofty> Not really
<Lofty> They're going through the input and then straight to the sum output
<Lofty> It's a couple of gate delays
<mwk> it's a xor gate, not worse than the mux you'd otherwise need to select between carry and not-carry, I guess
<mwk> but... you need to initialize the carry chain with 0 in this case, so that it properly bypasses the P signal
<mwk> that could be messy in p&r
* Lofty points to the gen mux with convenient zero input
<mwk> yes, but sum out == P ^ Cin
<mwk> so you need Cin == 0
<Lofty> From the gen mux
<mwk> but Cin always comes from the LE below, no?
<Lofty> It can, yes
<mwk> so there are more muxes?
<Lofty> No, the carry chain covers multiple LUTs;
<Lofty> So it only matters per LE
<Lofty> If I'm considering having a carry-select system, I probably get it for free, really
<miek> hmm, is it correct to split the pins string like this: https://github.com/nmigen/nmigen-boards/blob/2cd86c1f61a5380e428e67430e5b81ff9dcd0f96/nmigen_boards/orangecrab_r0_2.py#L53 or will that end up looking for a pin named "C18H16"?
<Lofty> miek: the latter
<Lofty> >>> print("foo" "bar")
<Lofty> foobar
<whitequark> miek: common footgun :/
<daveshah> I've made that mistake in litex at least a couple of times now
<whitequark> we should fix it properly by redesigning the nmigen.build API
<whitequark> medium to long term goal
<hell__> it's the same behavior as in C
<sorear> I feel like the way to go here is to first assemble a corpus of designs, then tweak a parameterized model in vtr or something until your made up benchmark is happy
<whitequark> got "hello, world!" from cxxsim
<hell__> :o
<awygle> !
<whitequark> the startup time is brutal
<whitequark> and there's no way to reset the simulation yet
<Lofty> sorear: was that meant for me?
<sorear> Lofty: yes
<Lofty> I'd agree with that, but I'm not looking forward to writing an architecture description
<whitequark> okay, final result with minerva: cxxsim is 80% faster at the cost of 6 second startup latency
<Lofty> That's pretty hefty
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 4 commits to cxxsim [+3/-0/±7] https://git.io/JJ3Yw
<_whitenotifier-b> [nmigen/nmigen] whitequark 09fbe91 - _toolchain.cxx: new toolchain.
<_whitenotifier-b> [nmigen/nmigen] whitequark 4f8892a - wip
<_whitenotifier-b> [nmigen/nmigen] whitequark 588a6e8 - wip
<_whitenotifier-b> [nmigen/nmigen] whitequark 091cd08 - wip
<whitequark> interestingly, a lot of that is spent in the RTLIL backend alone
<whitequark> lkcl__: awygle: jfng: the code is horrible and too slow, but it does work
<whitequark> feel free to start testing
<awygle> woo :D
<awygle> this is still on the branch right?
<whitequark> yes, and this will get completely rewritten at least once before it ships
<awygle> mk
<awygle> i'll try it with all my tests in a bit
<whitequark> you'll need to make heavy use of `reset` to see any benefit whatsoever, i think
<whitequark> i might also need to add `clone` or something to be MT-safe
<awygle> oh i'm sure i won't see any speed benefit
<awygle> my tests are (almost) all tiny
<awygle> i'll just report to you if it, uh, explodes.
<whitequark> when
<whitequark> not if
<whitequark> i'm basically 100% certain there are bugs
<whitequark> ok here's one
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to cxxsim [+0/-0/±1] https://git.io/JJ3Yd
<_whitenotifier-b> [nmigen/nmigen] whitequark 71037d7 - wip
chipmuenk has quit [Quit: chipmuenk]
Asuu has quit [Remote host closed the connection]
<Lofty> I can never remember whether you're meant to make the Memory a submodule, or its {Read,Write}Ports
<whitequark> think of Memory like Signal
<whitequark> well, it is more or less a 2d signal
<Lofty> "hmm, let's add a small 8-bit by 8-bit (= 2KiB) memory"
<Lofty> Chip area for module '\top': 81191.619200
<Lofty> This is just the memory
<Lofty> For comparison, here's a logic module: Chip area for module '\top': 3124.246400
<Lofty> I suspect memories are going to eat up much of my die budget
jeanthom has joined #nmigen
<lkcl__> whitequark: how is it initiated / used?
<lkcl__> i updated yosys recently and also got that SRLatch example compiled (after some modifications)
<lkcl__> Lofty: when doing chip layouts, SRAMs are always done as custom blocks.
<Lofty> Mmm
<sorear> lofty is doing a FPGA, which is the one case where that doesn't apply
<lkcl__> Jean-Paul informs me that yosys is particularly bad at detecting them, and will often create a dog's dinner mess.
<lkcl__> sorear: for an SRAM it would make no difference, it would still be an SRAM, even in an FPGA
<sorear> big memories like the Lattice 256Kbit SPRAM are memory-compiler outputs, but small memories are just custom logic
<daveshah> The block RAM is also memory compiler output
<lkcl__> sorear: yes, agreed.
<daveshah> The LUTs certainly aren't though, although I suspect they may be custom cells in themselves
<Lofty> My LUTs are at present shift registers attached to multiplexers
<lkcl__> daveshah: that sounds quite plausible
jeanthom has quit [Ping timeout: 272 seconds]
<lkcl__> i saw a really, really cool implementation of PowerISA crnand/nor/etc. instructions in microwatt.
<lkcl__> it basically actually took the 4 bits of the instruction and used them as a truth table!
<daveshah> I think most of the FPGAs these days are based on word/bit lines rather than shift registers
<daveshah> From the nuggets I've seen anyway
<Lofty> Hmm, maybe
<whitequark> lkcl__: replace back.pysim.Simulator/sim.pysim.Simulator with sim.cxxsim.Simulator. that's it
<lkcl__> daveshah: oh. i just remembered something i wanted to ask you. you created a SDRAM board for the versa-ecp5, right?
<lkcl__> whitequark: cool!
<sorear> a stretched-out SRAM structure costs 6 transistors per bit and gives you the normal and inverted value of every config bit for free, as long as you don't load too much
<lkcl__> i have to try this out
<lkcl__> daveshah: that's the one. do you happen to have any available (for sale)? we need a way to test opencores SDRAM
<lkcl__> prior to putting it into the ASIC
<daveshah> No, I don't have any around
<daveshah> You could use a ULX3S if you can get hold of one as another option
<lkcl__> daveshah: anyone you know of made then?
<lkcl__> ahh will look that up, thank you
<lkcl__> whitequark: AttributeError: /tmp/nmigen_cxx_k82hs6p2/sim.so: undefined symbol: cxxrtl_design_create
<sorear> the mention of SONOS in the skywater-pdk readme makes me wonder if you could do a significantly denser flash fpga
<Lofty> Maybe I don't trust the tools enough, but I have this nasty suspicion that whatever autogenerated clock tree I get is going to have a *lot* of skew
<lkcl__> whitequark: just doing a yosys "git pull", noticed some additions. rebuilding
<lkcl__> rebuild of yosys fixed the dynamic load error
<lkcl__> not getting expected results from a simulation (large one) - will investigate more tomorrow (when it's not midnight). it actually ran, though
<Degi> Hmh I think this might be wrong but not sure https://github.com/nmigen/nmigen/blob/master/nmigen/lib/cdc.py#L113
<whitequark> Degi: howso?
<Degi> I think thats for the reset synchronizer
<Degi> Or does the AsyncFFSynchronizer also reset something?
<whitequark> oh excellent catch!
<whitequark> Co-authored-by: what's <your@email>?
<awygle> oof my bad
<_whitenotifier-b> [nmigen] FFY00 opened pull request #433: docs: add install instructions for arch - https://git.io/JJ3CO
<_whitenotifier-b> [nmigen] FFY00 commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CC
<_whitenotifier-b> [nmigen] FFY00 opened issue #434: Use prebuilt yosys in CI - https://git.io/JJ3CE
<_whitenotifier-b> [nmigen] whitequark commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3Cz
<_whitenotifier-b> [nmigen] FFY00 commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3Cw
<_whitenotifier-b> [nmigen] FFY00 edited a comment on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CC
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJ3CK
<_whitenotifier-b> [nmigen/nmigen] whitequark ecb3a69 - lib.cdc: fix typo.
<whitequark> Degi: ah, co-authored-by doesn't work with GH usernames :/
<whitequark> it probably just pinged you
<whitequark> ah well
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJ3CX
<_whitenotifier-b> [nmigen/nmigen] whitequark cecfc92 - Deploying to gh-pages from @ ecb3a69d485b30767bef83c5b5f7804d14f34ed7 🚀
<_whitenotifier-b> [nmigen] whitequark commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CD
<_whitenotifier-b> [nmigen] whitequark commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CH
<_whitenotifier-b> [nmigen] whitequark commented on issue #434: Use prebuilt yosys in CI - https://git.io/JJ3C5
<_whitenotifier-b> [nmigen] codecov[bot] commented on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CF
<_whitenotifier-b> [nmigen] whitequark commented on issue #434: Use prebuilt yosys in CI - https://git.io/JJ3Cb
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CF
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #433: docs: add install instructions for arch - https://git.io/JJ3CF