<ZirconiumX>
This isn't an academic "trivial" type thing
<ZirconiumX>
You just exhaustively search for the best result out of all possibilities by some arbitrary metric
<ZirconiumX>
Yosys uses efficiency
ld-cd3 has joined #yosys
<ZirconiumX>
Which is effectively "the best solution is the one that wastes the least space"
ld-cd has quit [Ping timeout: 260 seconds]
ld-cd3 is now known as ld-cd
<ld-cd>
:/ not again
<ZirconiumX>
Once again, check the logger :P
<tnt>
not again ?
<ZirconiumX>
ld-cd's having connection issues
<ZirconiumX>
And so am I, apparently.
<tnt>
Ah ...
ld-cd has quit [Ping timeout: 260 seconds]
<tnt>
The systematic way might work for BRAMs but even then, the "metric" part becomes more fuzzy when you start accounting for some of the hw bram options (all stuff yosys doesn't support at all like changing r/w width etc ...). But for DSPs, properly inferring more than simple multiplies with all the freakin' modes that the DSP mode start supporting seems far from trivial.
<tnt>
especially if you mix-in retiming, pipeline levels and auxiliary logic in fabric to actually implement the behavior you need when 1 dsp slice isn't enough by itself.
<ZirconiumX>
To me it's possibly something you'd try to do after a LUT mapping pass: if you have too many DSPs, find the least critical one and relax it into soft logic
<tnt>
you need to find that you can use a dsp in the first place
<ZirconiumX>
True, yeah
<ZirconiumX>
But to me it's more a case of having <some other algorithm> eagerly mark things as "you can use a DSP here", and then relax the forest of nodes into something legal
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
strongsaxophone has quit [Remote host closed the connection]
ld-cd has joined #yosys
<ld-cd>
And I'm back
<ld-cd>
ZirconiumX: if you're still here, so for now is block ram support made through mappings like the multiplier you pointed out earlier?
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` has joined #yosys
ktemkin has quit []
ktemkin has joined #yosys
X-Scale` is now known as X-Scale
<mwk>
ld-cd: not quite
<mwk>
there's a techmap involved
<mwk>
but the main part is the memory_bram pass, which ingests a blockram description file
<mwk>
where you define what kinds of blockrams (or LUT rams) your target supports, what are the dimensions and capabilities of each
<mwk>
memory_bram pass looks at these rules and picks an option, then emits an internal blockram cell
<mwk>
which is then mapped to actual vendor primitive using techmap
<ld-cd>
ok that makes sense
<ld-cd>
but theres no abc style optimization like for example merging two single ports into a dual port if it fits?
<mwk>
there's a memory_opt pass, but it's kind of simplistic
<mwk>
doesn't do all that much
<ld-cd>
would that be a good place to start if I was looking to start contributing
<mwk>
*shrug* tbh in my experience the place where you start doesn't matter all that much in the end
<mwk>
note that the memory_bram pass is scheduled for bulldozing though
* mwk
considers it to be the worst part of yosys for practical usage right now
<ld-cd>
whats it being replaced with
<mwk>
something new, to be designed
<mwk>
perhaps just a more fleshed out version of the same idea
<ld-cd>
would memory_opt probably stay around though?
emeb_mac has joined #yosys
<mwk>
probably yes
rohitksingh has joined #yosys
d0nker5 has quit [Ping timeout: 255 seconds]
d0nker5 has joined #yosys
<ld-cd>
awesome
proteusguy has joined #yosys
citypw_ has joined #yosys
ld-cd has quit [Remote host closed the connection]
citypw has joined #yosys
citypw_ has quit [Ping timeout: 256 seconds]
emeb has quit [Quit: Leaving.]
dormito has quit [Ping timeout: 256 seconds]
dormito has joined #yosys
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
_whitelogger has joined #yosys
emeb_mac has quit [Quit: Leaving.]
ZipCPU|afk has quit [Ping timeout: 272 seconds]
m4ssi has joined #yosys
rohitksingh has quit [Ping timeout: 240 seconds]
twnqx has joined #yosys
dormito has quit [Ping timeout: 256 seconds]
dormito has joined #yosys
dys has joined #yosys
twnqx has quit [Ping timeout: 240 seconds]
develonepi3 has joined #yosys
strongsaxophone has joined #yosys
Sarayan has joined #yosys
* Sarayan
waves
<Sarayan>
whitequark (or others), is there an output format for yosys from which something like cxxrtl could run without reimplementing half of yosys itself?
<Sarayan>
I'm thinking about embedding yosys in another app without actually embedding it but just using it externally
<tnt>
cxxrtl takes rtlil as input right ?
<Sarayan>
Hmmm, probably
<Sarayan>
that's yosys' own internal IR, right?
<tnt>
yup.
<tnt>
you can read/write it with yosys. with read_ilang / write_ilang
<Sarayan>
I doubt wq did a bunch of levels of transformations from there
<Sarayan>
oh, that's what ilang is
<tnt>
and apparently you have a special yosys branch that has write_cxxrtl to output ... cxxrtl code.
<Sarayan>
yeah, but that's c++ code
<Sarayan>
and what I'd like is more in the JIT area
<tnt>
I don't get what you're trying to do ...
<Sarayan>
a software-ish debugger
<Sarayan>
which would require simming on the fly and interactively
<Sarayan>
changing what you want to look at dynamically, possibly what the sim actually stores, etc
<tnt>
huh ok. Don't see what you're looking for. I mean cxxrtl the way I understand it is (1) a part that takes rtlil and converts it to C++ code and (2) a runtime library in support of that c++ code that help "step" the simulation forward.
<Sarayan>
yeah
<tnt>
then you just feed both (along with a stimulus) to any C++ compiler and you get a binary.
<Sarayan>
yeah
<Sarayan>
it works rather well too, I use it a lot
<Sarayan>
(write_cxxrtl branch in wq's yosys fork)
<Sarayan>
*but* it's kinda slow, having a compiler in the loop, and it can be annoying system-wise building the communication between the simulation executable and the debugger
<Sarayan>
so I'd rather have say llvm build executable code directly in memory from a cached version of the rtlil
<Sarayan>
instead of running yosys and gcc/clang to build a shared library to dl-load in