<povikMartinPovie>
where should aiger import go in the source tree?
<whitequark[cis]>
/aiger probably
<whitequark[cis]>
as a new crate prjunnamed_aiger
Wanda[cis] has joined #prjunnamed
<Wanda[cis]>
what's the usecase for aiger import?
<povikMartinPovie>
I can think of two: reading pre-computed libraries for substitution based optimizations, and for reading in of some benchmarks
<povikMartinPovie>
you don't want it as a generic component?
<Wanda[cis]>
hm.
<Wanda[cis]>
benchmarks could be useful actuall
<Wanda[cis]>
s/actuall/actually/
<povikMartinPovie>
one can always go via Yosys...
<Wanda[cis]>
but for the first one
<Wanda[cis]>
I don't believe it's a good fit
<Wanda[cis]>
like, are you talking about the &dc2 thing?
<povikMartinPovie>
yes, that's the immediate thing
<Wanda[cis]>
I don't believe this stuff should be represented as a Design or read from a file at all
<whitequark[cis]>
those should be emitted as Rust code or a data file embedded in the binary
<whitequark[cis]>
it should not be an aiger file
<Wanda[cis]>
it should be transformed, via some build-time process, to something that's embedded in the binary
<Wanda[cis]>
yes.
<Wanda[cis]>
also, aiger still is not a good fit
<Wanda[cis]>
because you want to associate pass-specific metadata with the subgraphs
<Wanda[cis]>
in fact, I think that the representation abc itself uses is quite good
<Wanda[cis]>
just wrap it up with stronger typing or something and let's go
<Wanda[cis]>
also, be back in 15min
<povikMartinPovie>
isn't abc's repre a compressed aig?
<povikMartinPovie>
I don't see how that's too different from Design
<povikMartinPovie>
anyway, I'm not opposed to wrapping it up as typed static data
<povikMartinPovie>
I'm thinking more of getting it functional, packaging comes later
<Wanda[cis]>
it's a compressed aig with significant metadata
<Wanda[cis]>
it doesn't quite fit into a Design, you'd have to also represent the metadata (the mapping of NPN classes to subgraphs and subgraph weights) somewhere to the side
<Wanda[cis]>
you cannot use the usual metadata for this, because why would we ever want that for a general netlist; also you need to look things up by the NPN class
<Wanda[cis]>
moreover, there are no situations where you want to actually execute any Design operations on that thing. you don't want to run any optimization or lowering passes on it, and the only operation you want to do on it (extract a cone rooted in the given output and transplant it to another Design) is very simple
<Wanda[cis]>
ie. it's easier to roll a one-off data structure than do a special-purpose importer that preserves the metadata attachments
<povikMartinPovie>
there's no metadata
<povikMartinPovie>
you can create the npn class index rather trivially
<Wanda[cis]>
there is. there's the subgraph weights.
<povikMartinPovie>
all you need is for the distinct structures to correspond to different outputs
<Wanda[cis]>
further, there's the thing about embedding it in the binary
<Wanda[cis]>
we currently have no reasonable means of serializing Design into Rust consts
<Wanda[cis]>
it'd be somewhat nontrivial to do so, too
<Wanda[cis]>
basically: abc has the entire thing in 3 int arrays, which are already optimized for easy access right where they're needed; it'd be easiest to just copy this thing wholesale as three big consts
<Wanda[cis]>
yes, I was complaining that the origin of those is opaque and I'd want to know how they were generated; however, importing the exact same opaque graph from an external AIG file is not meaningfully different from stuffing the arrays into the source code
<povikMartinPovie>
I have the aiger data so I'm going with that for now, I prefer that to reversing abc's arrays
<whitequark[cis]>
I think we shouldn't merge the whole aiger dance
<whitequark[cis]>
as a prototype it's fine but it'll have to be reworked