<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)
<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] 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>
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
<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
<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)
<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
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>
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.
<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 :)
<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?
<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
<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.
<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
<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