<cr1901_modern>
Btw, I got this warning when compiling nextpnr-generic (for example) about strict aliasing for the pybindings: http://ix.io/2qc9 Is this bad? Or is it unavoidable in the context of whatever horrifying thing Boost does to generate Python bindings?
maartenBE has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #yosys
maartenBE has joined #yosys
<az0re>
mithro: Noice
<mithro>
cr1901_modern: Guess so :-P -- First step is to make them run in iverilog / verilator now
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #yosys
citypw has joined #yosys
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #yosys
az0re has quit [Ping timeout: 240 seconds]
az0re has joined #yosys
AdamHorden has quit [Read error: Connection reset by peer]
<tpb>
Title: Add WASI platform support by whitequark · Pull Request #145 · YosysHQ/prjtrellis · GitHub (at github.com)
<whitequark>
cr1901_modern: seems like a bug, but not sure
<daveshah>
whitequark: looks good, I'll take a proper look later. The multithreading stuff was just for fuzzing, so won't cause any loss with wasm
<whitequark>
yeah I assumed so
dys has quit [Ping timeout: 260 seconds]
dys has joined #yosys
<whitequark>
daveshah: i think #145 works well now
<whitequark>
btw it looks like nextpnr-ecp5 fails --test too
<whitequark>
same bel z check issue
<whitequark>
well, similar
X-Scale has quit [Ping timeout: 240 seconds]
emeb has joined #yosys
<daveshah>
whitequark: looks good, merged, thanks
<daveshah>
I will look into the test issue and set up CI to actually run them, at least for a few device variants
jfcaron_ has joined #yosys
X-Scale has joined #yosys
jakobwenzel has quit [Remote host closed the connection]
jfcaron_ has left #yosys ["Leaving"]
FabM has quit [Quit: Leaving]
laudecay1 has joined #yosys
<laudecay1>
hiya so i am writing verilog and i want to write a thing like systemverilog's count_bits or count_ones, but in as few gates as possible
<laudecay1>
it gets mad when i say something like assign a = $countbits b; though
<laudecay1>
is there some kind of shorthand for this in verilog? or do i need to write a module myself?
<Lofty>
You would have to write a module yourself
<laudecay1>
ah ok
<laudecay1>
thanks!
<Lofty>
It more or less boils down to add-reducing your input, except I don't think Verilog lets you do that directly
<laudecay1>
what do you mean by add-reduce?
<Lofty>
Do you know how things like or-reduce work?
<Lofty>
(unary | on a signal)
<laudecay1>
i'm currently writing code that produces verilog, and i need to be able to write it to support a variety of input and output sizes- so my plan was to make $INPUT_SIZE bitmasks, or them with the input, check equality of each, then add those
<laudecay1>
i come from a math background with a bit of C, i know what bitwise | does if that's what you're asking
<laudecay1>
oh like a map-reduce thing on the bits of the input
<Lofty>
x | y is binary |
<Lofty>
|x is like x[0] | x[1] | ...
<laudecay1>
yeahhhhhh ok i haven't seen that notation but that's like a haskell fold
<Lofty>
Here you want x[0] + x[1] + x[2] ...
<laudecay1>
yeah
<Lofty>
Though, have fun with expression widths there
<laudecay1>
does verilog get mad about expression widths?
<Lofty>
No, Verilog *is* mad about expression widths
<laudecay1>
:(
<laudecay1>
big sad
<laudecay1>
ok hm.
<laudecay1>
i can handle breaking up expression widths, but
<laudecay1>
how would you recommend doing this with fewest gates possible?
<Lofty>
By "gate" do you mean ASIC gates, or FPGA LUTs?
<laudecay1>
like, would the "and it with a bunch of bitmasks" approach be reasonable?
<Lofty>
I don't think so, really.
<laudecay1>
fewest 2-input and + not gates is ideal if possible
<Lofty>
<Lofty> So to get a 2-bit result from addition, you need to zero-extend i and j to 2-bit, or assign it to a 2-bit wire
<laudecay1>
oh wow that's really helpful
<laudecay1>
thank you so much!!
laudecay1 has quit [Ping timeout: 264 seconds]
emeb_mac has joined #yosys
emeb_mac has quit [Client Quit]
dys has quit [Ping timeout: 244 seconds]
kraiskil has joined #yosys
laudecay1 has joined #yosys
<laudecay1>
hey im back- how do i test a circuit? i have the module signature here: module Population_count_32_to_32(input wire [0:31] a, output wire [0:31] b);
<laudecay1>
i'd read -sv the file, then i run `eval -table a $abstract\Population_count_32_to_32`
<laudecay1>
and i get an error it's failing to parse the table expression a
dys has joined #yosys
laudecay1 has quit [Ping timeout: 256 seconds]
AdamHorden has joined #yosys
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #yosys
kraiskil has quit [Ping timeout: 240 seconds]
az0re has joined #yosys
<az0re>
Hey so I was just perusing the README and I noticed that Yosys already depends on libboost-system-dev, libboost-python-dev, and libboost-filesystem-dev
<az0re>
Where exactly do these dependencies come from?
<daveshah>
libboost-python-dev will be from the python bindings
<daveshah>
seems like filesystem is python related too
<az0re>
So I guess the Boost situation is a bit more complicated than I thought...
<az0re>
I'm sure whitequark would vigorously oppose any further dependencies, but it's not a blanket ban
<daveshah>
It's only because the Python support is optional and disabled-by-default
<az0re>
daveshah: Yup, I see, thanks
<az0re>
Is that the only requirement in order to introduce a Boost dependency? That it be disabled by default?
<daveshah>
That kind of decision would be beyond my pay grade
Asu has quit [Ping timeout: 246 seconds]
Asuu has joined #yosys
m4ssi has quit [Remote host closed the connection]
<whitequark>
az0re: i am vigorously opposed to anything from boost that is not absolutely necessary
<whitequark>
which is to say anything new from boost at all
<whitequark>
and i'd rather get rid of boost-python; there are better solutions available now, though i think they weren't there when this code was added
<daveshah>
Yeah the Yosys Python bindings are actually fairly old now
<daveshah>
They were held back for ages because of some academic dispute
<tpb>
Title: GitHub - pybind/pybind11: Seamless operability between C++11 and Python (at github.com)
<whitequark>
that's just 3 years old though, so it didn't exist when the bindings were added, i think
<daveshah>
I guess it would have just about done, but certainly not as well known
<whitequark>
perhaps not working as well as now either?
<whitequark>
the point being, i think boost-python was an appropriate choice *at the time it was added*
<whitequark>
but not anymore
<daveshah>
I should look at pybind11 for nextpnr at some point
<whitequark>
az0re: if you want to use something like std::filesystem we should find a polyfill that isn't boost-related
<whitequark>
remember how you (correctly) judged against using some hypergraph partitioner because it used scons? i would rather have to use scons when cross-compiling yosys than b2
<whitequark>
yosys also has this annoying situation where it doesn't use cmake. with nextpnr it's generally easy to add any dependency that uses cmake because it can usually be vendored without much trouble, or just built in the same way as nextpnr itself
<whitequark>
yosys is special
<whitequark>
because of its baroque makefiles i think that any utility dependency should be just vendored into it, like i did with json11
<daveshah>
Even with nextpnr I am preferring vendoring in these days, for stuff that isn't too big or fast-changing
<whitequark>
eigen? :)
<whitequark>
i currently actually install it into a temporary prefix in yowasp so that find_package() works
<daveshah>
Possibly a bit tricky with the blas dependency too
<daveshah>
But I can look into that for sure
<whitequark>
I... think the cross-builds don't use blas?
<whitequark>
hm
<whitequark>
I wonder if they run slower because of that
<whitequark>
certainly I can't compile asm-laden fortran into wasm
<daveshah>
The performance difference is tiny anyway
<daveshah>
I don't think it materially affects any ice40 or ecp5 design, it would be a small part of a small part of runtime
<daveshah>
For some reason I thought it requires blas, but if it works without then that sounds fine
<daveshah>
I rejected one sparse matrix solver because it was full of non-thread-safe f2c...
<whitequark>
works perfectly fine as just a single header
<whitequark>
i'm not actually sure how to make it use blas
<whitequark>
well not single header, headers alone
<daveshah>
That's easy enough then
Asuu has quit [Remote host closed the connection]
<emeb>
OK - I've got a super sketchy design ganked from the web that uses a combinatorial loop to do some I2C stuff. It simulates fine and mostly synthesizes OK w/ yosys + nextpnr BUT I get this --- Warning: The network is combinational (run "fraig" or "fraig_sweep")
<emeb>
And that particular part of the design doesn't work right.
<emeb>
so the question is how to stick fraig_sweep in there?
<emeb>
(FWIW - this design apparently works in Xilinx tools, but requires some synthesis pragmas to preserve the structure - ie "keep" on the two nets of the loop)
<Lofty>
emeb: Don't
<Lofty>
The warning is harmless
<Lofty>
This is because the network is presented to ABC as a combinational cloud
<emeb>
Lofty: thx
<Lofty>
emeb: It actually seems the warning is out of date
<Lofty>
Yosys runs `ifraig`, and if you use what little help there is within ABC, `fraig -h` suggests `ifraig` as a replacement
<emeb>
Lofty: haha
<emeb>
well, this logic is nasty so I'm not surprised that it misbehaves in the real world.