citypw has quit [Remote host closed the connection]
dh73 has quit [Quit: Leaving.]
dys has quit [Ping timeout: 265 seconds]
citypw has joined #yosys
dys has joined #yosys
emeb_mac has quit [Quit: Leaving.]
rombik_su has joined #yosys
dys has quit [Ping timeout: 268 seconds]
dys has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
rombik_su has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
philtor has quit [Ping timeout: 260 seconds]
vidbina has quit [Quit: vidbina]
vidbina has joined #yosys
<lukego>
I'd like to meet all'yall open source hardware hackers at FOSDEM. Is there a particularly popular place to stay for this crowd i.e. hotel recommendation?
<lukego>
(I'm meanwhile setting up my dev env... learning to solder, going to make a power supply board, then going to try and put my ECP5 BGA and 10G ethernet PHY BGAs onto a first simple board of some kind...)
<lukego>
I did catch fpgadave's talk about Project Trellis last year but I was mostly hanging out with the software networking crowd beyond that.
<tnt>
definitely not in december ...
<lukego>
er, feb :-
<finnb>
I went last year but felt it was a little too busy to actually attend a lot of the talks I wanted to see
<tnt>
you just can't change room ...
<tnt>
pick one, go in the morning, leave in the evening.
<finnb>
I think if you're going, it's a lot for the social
<finnb>
I know ticketing it would go against the principles but they either need to get a bigger venue or limit the number of people that can go
<finnb>
The Trellis talk last year was great :)
vidbina has quit [Ping timeout: 265 seconds]
<lukego>
Software networking room was a bit of a disaster last year. Small room with bad A/V. Most of the people in the room couldn't hear the talk and were only there to hold their seat for one of the other talks coming later.
<lukego>
but that's part of the charm of FOSDEM I suppose :) created a pretty good hallway track
<lukego>
I suppose also that since nobody has name tags your best bet for finding like-minded people is to loiter around outside relevant devrooms and chat to other people who are interested in the topic but couldn't get a seat :)
<mwk>
ZirconiumX: so how it works is, operator== compares by identity (or by value for const signals)
<ZirconiumX>
Right, I see
<mwk>
but since wires in modules can be assigned to each other (which is represented by module->connections), and you usually want this to be transparent in your passes, the SigMap util is used
<mwk>
you construct a SigMap from a module, and it maps every SigBit to a "canonical" one from the assigned-to-each-other set
<mwk>
then to compare two signals, you do sigmap(a) == sigmap(b)
<mwk>
where sigmap is your pre-constructed SigMap object
<mwk>
and you have to be careful to not invalidate SigMap before you stop using it
<mwk>
(which is not that hard, as long as you don't add/remove connections)
* mwk
feels the whole thing to be a mess, but eh
* mwk
would really love the whole thing to be more SSAish and have a single well-defined instantly-accessible driver for every wire
<mwk>
gimme LLVM :3
<ZirconiumX>
Context: I'm writing an ALM packing pass. I realise Yosys is the wrong place to put this, but lacking nextpnr support and Quartus stubbornly refusing Yosys output, I'd like some way of obtaining ALM numbers
<ZirconiumX>
Plus this gives me practice for writing Yosys passes, so
<ZirconiumX>
I feel like the most realistic numbers would come from representing the cells as layers of a tree and then trying to pack each layer
<mwk>
uh what?
<ZirconiumX>
...This is going to need a diagram, isn't it?
<ZirconiumX>
Now, LUT3 depends on the output of LUT 1, so you might not be able to fuse LUT 3 into LUT 1
<ZirconiumX>
But you could try to pack LUT 1 and LUT 2 together
<mwk>
why not?
<mwk>
I mean, if they are otherwise fusable?
* ZirconiumX
sighs and reaches for the output of `show` because apparently this is not realistic enough
<ZirconiumX>
Note the "might not" there
<mwk>
yes, but why does the fact that LUT 3 depends on LUT 1 matter?
<mwk>
I mean, worse case, you'll just have a path straight from ALM output to its own input?
<ZirconiumX>
I thought combinational loops were a bad thing
<mwk>
they are, but it's not going to be a real combinational loop
<ZirconiumX>
Okay, then clearly I don't know anything here.
TheHolyC has quit [Max SendQ exceeded]
TheHolyC has joined #yosys
dh73 has quit [Ping timeout: 265 seconds]
dh73 has joined #yosys
emeb_mac has joined #yosys
<dh73>
AFAIK, Quartus/Synplify starts the ALM packing by mapping logic using ALM legal constraints (2 4-input luts, 1 6-output luts, 1 5-input lut + 1 3-input lut, etc), then the Quartus fitter place these instances correctly. I have no deep details honestly, but that's the pattern I've seen.
<dh73>
For instance; ALUT usage by number of inputs
<ZirconiumX>
I sent this paper to mwk, but it's quite useful here too
<ZirconiumX>
I have a rough formula for ALM packing, but I'm looking for generally more realistic numbers.
Jybz has quit [Quit: Konversation terminated!]
cznwhale has joined #yosys
<cznwhale>
hello; I am new to yosys - but read the documentation ~80%
<cznwhale>
is it possible to synthetize a design using only toffoli gates?
<cznwhale>
and without any classic gates
<cznwhale>
(nand, nor, not)
<cznwhale>
(toffoli gate are universal reverible gates - and they have 3 in/ 3 out)
<daveshah>
cznwhale: Probably not very well. You can synthesise to arbitrary gate libraries with abc and liberty files but that only maps single output gates
<daveshah>
ie it would only use the final output of the Toffoli gate and not the "route throughs"
<cznwhale>
can you point me in some documentation what is a "gate library"?
<cznwhale>
I tried some experiments
<cznwhale>
if I remove from the liberty file the nor for example (and leave the not and nand)
<cznwhale>
the output netlist will corectly contain only not and nand
<cznwhale>
but if I remove the not
<cznwhale>
an internal error in the abc will pop out
<daveshah>
ABC requires a not gate and a buffer in a liberty file
<cznwhale>
but why this limitation
<cznwhale>
?
<cznwhale>
a NOT is very simple build with a NAND
<daveshah>
There's no reason, just ABC expecting a typical gate library
<daveshah>
You could always use techmap afterwards to convert the NOT to a NAND
<daveshah>
ie a real world ASIC gate library would always have NOT and buffer cells, and I guess ABC didn't consider more obscure applications
<cznwhale>
so in fact there is no flexibility in the final netlist
<daveshah>
?
<cznwhale>
I refer that the liberty file does not alow much things to be variable
<cznwhale>
maybe only the names of the gates
<cznwhale>
but not the functions
<ZirconiumX>
You can go add things beyond the gates
<ZirconiumX>
But ABC is fairly limited here because this part of ABC was designed for ASIC synthesis.
<daveshah>
cznwhale: you can have a totally variable set of gates
<daveshah>
There is only one ABC requirement and that is that the set of gates must include not
<daveshah>
The workaround is to use Yosys techmap to convert that not into whatever you want
<cznwhale>
and use extensions for my exotic gate functions, right?
<daveshah>
You don't need to use any extensions
<daveshah>
Standard liberty functions should be fine
<cznwhale>
maybe I didn't understand right the whole flow
<cznwhale>
I saw in the example of synth script
<cznwhale>
that the ABC is called almost the last command
<daveshah>
Yes, that's usually the case
<cznwhale>
(actually the last is an "opt")
<ZirconiumX>
Yosys is a series of passes. You can call any of these passes in whatever order you want
<daveshah>
The previous commands tend to be doing higher level (eg word level) transformations
<cznwhale>
but if I want to have in the final netlist an exotic gate
<cznwhale>
ABC will not handle it
<daveshah>
Then you will probably want techmap after abc to deal with the NOT case
<cznwhale>
I must put some other final command for yosys to do the replacement
<daveshah>
That is "techmap"
<cznwhale>
OK
<cznwhale>
thank you very much!
<ZirconiumX>
ABC is limited to single-output gates. Since I worked on targeting 7400-series logic chips, my solution was a post-processing pass that merged single-output gates into a chip
<cznwhale>
the post-process was your own?
<ZirconiumX>
Yep
<cznwhale>
or a yosys command
<cznwhale>
ok!
<ZirconiumX>
Well, specifically it was pepijndevos' idea; a Python script that operated on the Yosys netlist.