MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #yosys
Jybz has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
m4ssi has joined #yosys
<Xiretza>
daveshah: confirmed, thank you!
strongsaxophone has joined #yosys
marex-cloud has joined #yosys
dys has joined #yosys
develonepi3 has quit [Ping timeout: 245 seconds]
kraiskil has joined #yosys
<mwk>
daveshah: btw, xilinx sometimes packs even a LUT5 and LUT6 together if the bits align just right
<mwk>
and such a thing can drive a MUXF tree
<daveshah>
Yup, it was just an issue with the MUX output contention
<mwk>
I've seen such a thing in ISE output, they use the primary FF in always-enabled latch mode to route out of that mess
<daveshah>
Ah, I haven't implemented that yet but Vivado does that too
<daveshah>
The time I saw that I think it was actually to legalise a carry output
<mwk>
yes
<mwk>
that as well
<mwk>
with carry there's no way around that
<mwk>
well, there is, but not without lengthtening the carry chain or other contortions
kraiskil has quit [Ping timeout: 260 seconds]
<daveshah>
Indeed - I do the former in nextpnr-xilinx but using the latch mode might be a better option
<mwk>
I use the latch mode in nextpnr-leuctra
<mwk>
(we need to sit down at some point and merge all this mess into a single unified target... preferably when I've had a proper night of sleep)
<daveshah>
Yes
<daveshah>
The problem is the lack of a deduplicated db for UltraScale atm
<mwk>
I can arrange that
<mwk>
I mean, I don't have one yet, but I can produce one in a week or two
<daveshah>
Right, there is also the question of timing, for xc7 I pull timing out of Xray and I want to do similar with xcup
<daveshah>
(from RapidWright in that case)
<mwk>
I'll be looking into timing extraction soon as well
<mwk>
no guarantees about that one though
<daveshah>
The primitive sets used are slightly different but that should be unifiable
<daveshah>
We can always just keep the xc7/xcup packing separate to start with
<daveshah>
from the leuctra packing
<daveshah>
just harmonise the database
<mwk>
actually I really thing we should merge them
<mwk>
well, the slice packing at least
<mwk>
I/O is a vastly different beast
<mwk>
xc6s slice is much closer to xc7 slice than xc7 is to ultrascale
<mwk>
basically just one fewer mux than xc7 (the secondary FF is perma-connected to LUT's O5 output)
<daveshah>
Yes, for xc7 at least
<daveshah>
For xcup I'd also need to do some work on the rapidwright side to split the larger primitives you've used
<mwk>
you mean, split up LEUCTRA_LC into LUTs/MUXs/CARRY4s?
<daveshah>
Yes, those are the primitives nextpnr-xilinx uses
<mwk>
it's kind of the opposite of what I'm doing in the post-processing step, ise really wants a SLICE* as a whole
<daveshah>
Right
<mwk>
(and my bitstream database also deals with whole slices as a unit, there's just too many common bits)
<daveshah>
The fasm backend will probably need some changes for the different db and slice structure but that shouldn't be so bad
<daveshah>
It all sounds fairly doable particularly if we keep BRAM and IO separate
<mwk>
BRAM packing will not really be a thing with -leuctra backend
<daveshah>
No, it's not so much packing as things like rewriting write enables
<mwk>
it should just go through the generic path for random primitives that just need to be passed through with minor changes
<mwk>
oh, xc7 needs that?
<daveshah>
Yes quite a bit of that
<mwk>
xc6s dumps most of this stuff on the synthesis tool
<daveshah>
Also connecting to both lower and upper signals for the 36 size primitives
<daveshah>
It's code that can just copy across from nextpnr-xilinx though
<mwk>
it actually tells you in the HDL library document exactly which signals you're supposed to tie how
<mwk>
also uhh
<mwk>
you know that xc7 support is in scope for nextpnr-leuctra as well, right? :p
<daveshah>
Yes, I do, that's why we are planning to merge to two
<daveshah>
*the two
<mwk>
good
<daveshah>
I've got most of these annoying things debugged now
<mwk>
(current status is that leuctra bitgen supports only xc3se and xc6s though; other stuff may need to wait a bit for the big rewrite)
kraiskil has joined #yosys
<daveshah>
Yes, we can just use the fasm backend for prjxray bitgen for now anyway
<daveshah>
That was another very annoying thing but should port across OK
<daveshah>
Mostly just slice structure changes
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
rohitksingh has quit [Ping timeout: 246 seconds]
<mwk>
alright, in any case
<mwk>
I'll be busy with unrelated stuff this week
<mwk>
then I'll have some time to figure out the new db format (there are a couple issues with my current one that I really need to solve first; first and foremost the issue of alias pips)
<mwk>
right now I represent all inter-tile connections as bidirectional pips on the edges, which is not a great idea
<daveshah>
So I think I might continue with the short term plan to upstream the current nextpnr-xilinx for xc7 and xcup, even though this will be replaced by the leuctra db in the long term
<mwk>
for one, it can result in unsound routing when there are wires that can be driven from multiple directions... xc6s doesn't have those, but every single other xilinx family does
<daveshah>
Yes, the slice 'X' wires if nothing else
<mwk>
uh?
<daveshah>
iirc anyway
<daveshah>
Oh no I'm thinking of something else
<mwk>
no, I mean the long lines
<mwk>
which you can drive from top or bototm
<mwk>
(or, on some families, from the middle)
<daveshah>
One option would just be to have getPipsUphill etc iterate over all "neighbourhood" wires
<mwk>
yep
<daveshah>
That's basically what nextpnr-xilinx does
<mwk>
but it also requires having a unique WireId for a given node
<mwk>
unique canonical one
<daveshah>
Indeed, because nextpnr-xilinx doesn't deduplicate intertile nodes (only tile wires, pips and sites) this if fairly easy
<mwk>
right
<mwk>
so we need to figure how to approach it for deduplication
<daveshah>
I had to do some special casings of globals to get it to work well, but in the nexus arch that I'm working on I'm playing about with the concept of neighbourhoods
<daveshah>
Instead of just considering connections to adjacent neighbours I consider neighbours to be all other tiles that a tile has connection
<daveshah>
Then store the mappings for each set of possible "neighbourhoods" for a tile type separately
<mwk>
you mean, directly and indirectly?
<daveshah>
This works fairly well for something simple like CrossLink NX but might need more special casing for Xilinx with all the different long connections
<mwk>
yes
<daveshah>
Any nodal connection
<daveshah>
Lattice don't really have a concept of tile wires, only nodes, so I kind of do the splitting up myself
fsasm has joined #yosys
az0re has quit [Write error: Connection reset by peer]
ZirconiumX has joined #yosys
develonepi3 has joined #yosys
<strongsaxophone>
is it possible to draw module level schematic with yosys? (not gate level like the example in the yosys documentation)
<daveshah>
Yes, this will happen if you don't use flatten in your flow (something like proc; hierarchy; show top)
<daveshah>
It won't be very pretty though
<strongsaxophone>
Okay, Thank you.
attie has quit [Remote host closed the connection]
attie has joined #yosys
<strongsaxophone>
daveshah: I got amazed with the result. Its fantastic.
<ZirconiumX>
ABC9 seems to be having major issues with my synthesis script and I don't understand why
<ZirconiumX>
...Oh, I see why. Nevermind
m4ssi has quit [Remote host closed the connection]
emeb has joined #yosys
strongsaxophone has quit [Ping timeout: 265 seconds]
citypw has quit [Ping timeout: 268 seconds]
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #yosys
citypw has joined #yosys
C-M has joined #yosys
citypw has quit [Ping timeout: 268 seconds]
az0re has joined #yosys
ZipCPU has quit [Remote host closed the connection]
Forty-Bot has quit [Ping timeout: 265 seconds]
ZipCPU has joined #yosys
pepijndevos[m] has joined #yosys
fsasm has quit [Ping timeout: 260 seconds]
kraiskil has quit [Ping timeout: 260 seconds]
rohitksingh has joined #yosys
dys has quit [Ping timeout: 252 seconds]
klotz has joined #yosys
klotz has quit [Quit: klotz]
pointfree has quit []
pointfree has joined #yosys
m_w has joined #yosys
pointfree has quit [Ping timeout: 260 seconds]
m_w has quit [Quit: leaving]
Jybz has joined #yosys
Jybz has quit [Quit: Konversation terminated!]
dys has joined #yosys
rohitksingh has quit [Ping timeout: 245 seconds]
strongsaxophone has joined #yosys
strongsaxophone has quit [Ping timeout: 268 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 260 seconds]
rohitksingh has joined #yosys
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #yosys
kraiskil has joined #yosys
rohitksingh has quit [Ping timeout: 240 seconds]
pointfree has joined #yosys
dys has quit [Ping timeout: 268 seconds]
kraiskil has quit [Ping timeout: 268 seconds]
develonepi3 has quit [Remote host closed the connection]