futarisIRCcloud has quit [Quit: Connection closed for inactivity]
emeb_mac has quit [Quit: Leaving.]
kgugala has joined #yosys
kgugala_ has quit [Ping timeout: 256 seconds]
jakobwenzel has joined #yosys
Asu has joined #yosys
dys has joined #yosys
hitomi2500 has joined #yosys
citypw has joined #yosys
<hitomi2500>
I've been browsing thru gowin techlib, and it seems that only 8/16/32 bit modes are supported, but not 9/18/36. Is it intentional, or is this just a work in progress? Can i probably add those without touching anything outside the techlib?
<daveshah>
I vaguely remember some discussion about that, but not any details unfortunately
<daveshah>
You might be able to look at how ECP5 does 9/18/36 modes
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 256 seconds]
kraiskil has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
dys has quit [Ping timeout: 260 seconds]
<Lofty>
cc pepijndevos
hitomi2500 has quit [Read error: Connection reset by peer]
indy has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
dys has joined #yosys
futarisIRCcloud has joined #yosys
indy has quit [Ping timeout: 240 seconds]
indy has joined #yosys
hitomi2500 has joined #yosys
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` has joined #yosys
indy has quit [Read error: Connection reset by peer]
X-Scale` is now known as X-Scale
indy has joined #yosys
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
dys has quit [Ping timeout: 240 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
emeb has joined #yosys
daknig has quit [Ping timeout: 246 seconds]
daknig has joined #yosys
daknig has quit [Ping timeout: 264 seconds]
daknig has joined #yosys
jfcaron has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
emeb has quit [Ping timeout: 260 seconds]
emeb has joined #yosys
jakobwenzel has quit [Quit: jakobwenzel]
indy has quit [Ping timeout: 265 seconds]
indy has joined #yosys
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
jeanthom has joined #yosys
kraiskil has joined #yosys
az0re has quit [Remote host closed the connection]
<whitequark>
what was the irc nickname of the person who wanted to redo memory inference?
<whitequark>
(I should write down these mappings)
<Lofty>
lambda,
<lambda>
o/
<whitequark>
oh hi
<whitequark>
so I brought up your question on the meeting just now
<whitequark>
we can indeed get rid of the $mem cell as it currently is
<Lofty>
\o/
<lambda>
hooray :)
<whitequark>
the main problem is techmapping $mem (which is no longer done, but used to be) and simulating via writing an instance of $mem (which isn't strictly necessary and can be handled in write_verilog)
<mwk>
also backends that currently handle $mem need to handle the other $mem* cells instead
<whitequark>
yeah, I think that would make sense as a first step towards redoing inference?
<mwk>
btor, firrtl, smt2, smv
<whitequark>
since after that you wouldn't need to care about the constraints placed by having $mem
<mwk>
... alright, in case of smv the "fix" is to change the "FIXME" comment to refer to the new cell types
<whitequark>
lol
<mwk>
I'd say that it's more important to, y'know, actually design stuff first
<mwk>
since the $memwr/$memrd cells we end up with will probably have a few more ports and parameters
<whitequark>
I'm somewhat biased because I've had to work around $mem/$mem* one too many times
<mwk>
also there's likely to be a $memrdwr cell that does both, I guess
<Lofty>
mwk just ninja'd me
<whitequark>
yep, for SPRAM
<mwk>
or TDP
<Lofty>
Or TDP, right?
<Lofty>
Fuck
jeanthom has quit [Ping timeout: 260 seconds]
az0re has joined #yosys
mirage335 has quit [Ping timeout: 260 seconds]
mirage335 has joined #yosys
<whitequark>
az0re: I discussed hypergraph partitioning on the meeting
<whitequark>
the consensus was that we should integrate daveshah's code in-tree whenever it's ready, and until that relying on an external tool is ok, since the primary user is formal verification, and it'll be a while until any synthesis or simulation flows will start partitioning anyway
<az0re>
okie dokie
<az0re>
sounds good to me
<az0re>
thanks
<az0re>
I'll put up a draft PR later today
cvl has joined #yosys
mwk has quit [Read error: Connection reset by peer]
cvl has quit [Client Quit]
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #yosys
mwk has joined #yosys
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #yosys
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
<ross_s>
Does there exista machine-parsable output option for yosys's stat command? Trying to optimize the size of a design and manually working out how many resources are consumed by multiple nexted generated instances is a bit tedious
<ross_s>
Or if people know of better ways to try and drill down on where all my slices are going, very open to advice
<whitequark>
no, but we can introduce it
<whitequark>
something like `stat -json` (sigh, json) or `stat -tsv` (no one knows what tsv is but it's at least easy to explain)
<ross_s>
yeah, any format I can then pull into a program for tabulation would be great. Let me take a look at the source and see if this looks like something I'd be able to come up with a first pass at, or if the internals are too complex for someone without much experience with them
<mwk>
sounds simple and useful
<tnt>
I mean you can read the json design pretty easily.
<ross_s>
even with -noflatten the output json seems to lose a lot of design info though
<daveshah>
In that case it is just gone though
<ross_s>
true. I also searched for a module I already removed, which explains why I didn't find it
<ross_s>
I guess I'll start by trying to build something that just parses the synth_ecp5 output json then
<mwk>
well, stat also does some useful(ish) tech-dependent things like aggregating LUT counts of different types, taking LC sharing into account, etc
<mwk>
(though it's done in kind of dumb ways tbh)
<whitequark>
wait, really?
<mwk>
at least it dos for xilinx
<whitequark>
... I had no idea
<mwk>
... ugh, yes, only for xilinx (and for cmos)
<whitequark>
should it be doing that?
<tnt>
I thought stat just counted instances. didn't know there was anything more to it.
<az0re>
I am actually just about to introduce a PR to expose `statdata_t` to the Yosys namespace, if that's relevant
<mwk>
"stat -tech xilinx" to do the "pack LUTs into slices" stats, or "stat -tech cmos" to do the "so how many transistors is that" stats
<whitequark>
both
<mwk>
unfortunately xilinx seems to be the only supported fpga family
<mwk>
and uhh let's say it's quite dumb
<mwk>
could be more useful if we added rules like "so RAMB8BWER counts as half a RAMB16BWER, occupying the same resource"
<whitequark>
the three human languages: french, russian and english
<whitequark>
the two kinds of logic: cmos and xilinx
<whitequark>
(the former is according to ISO, of course)
<whitequark>
i feel like instead of `stat -tech xilinx` it would make more sense to have `stat_xilinx` as a separate pass
<whitequark>
reusing the rendering logic from the normal `stat
<whitequark>
if at all
<whitequark>
if we actually do add all the techs it's going to get really unwieldy and gross, like the current techmap
<mwk>
what about the current techmap?
<mwk>
oh you just mean the pass, with all its features
<whitequark>
yes
<whitequark>
techmap has a zillion special cases for other reasons, but it still does
<whitequark>
and unlike stat, techmap is a lot harder ot fix
<whitequark>
with stat we can just avoid the problem in first place
<mwk>
I mean perhaps if we could make stat eat a "config file" of sorts it could be made generic
<daveshah>
I feel think that's just going to end up with a lot of duplication between all the different stat_ passes, once we end up with more
<Lofty>
(* stat_area *)
<Lofty>
/s
<mwk>
like '"$_AND_" counts as 4 "transistors"'
<daveshah>
something configurable, or just a per-arch function in stat, seems best
<whitequark>
i'm fine with either configurable stat or a clean separation of architectures inside the same pass
<whitequark>
as long as it's not going to be techmap#2
adjtm_ has quit [Remote host closed the connection]
adjtm_ has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
<az0re>
mwk: Isn't that the point of the `CellCosts::cmos_gate_cost()` etc.?
<mwk>
well that's just for cmos
lambda has quit [Ping timeout: 272 seconds]
<az0re>
I'm adding a unit gate cost, too
<az0re>
But anyway, isn't that where to add cell costs? Why a separate config file?
<mwk>
because you want different metrics on FPGAs
<mwk>
eg. it doesn't make sense to have both BRAMs and DSPs somehow converted to a common unit, you just cannot exchange one for the other
<mwk>
also because in general it's good to keep stuff in data files and not as c++ code
<whitequark>
one advantage of using data files is that you can compile a subset of yosys that way
<mwk>
in particular for FPGA techlibs, which there are craploads of, and shouldn't be stuffed in common code
<whitequark>
well... theoretically, right now it's a massive pain
<whitequark>
i'm going to redo the yosys build system one day to be more friendly to this kinda thing