<tnt>
mithro: the issue is you need svg drawing version of all the components you use to look decent ... it can't use the 3d models from kicad.
<mithro>
gatecat: Are Issues #43, #42 and #40 on FPGA Interchange Schema related?
<mithro>
gatecat: I guess that should have been pull requests -- and Issues #44 / #41?
<gatecat>
mithro: yes and #42 contains #40 in it
<gatecat>
issue #44 is a wider issue
<mithro>
gatecat: My current thinking (and it's open to changing) is that "Macros" are actually just a shorthand for a given set of BELs configured a certain way. The synthesis tool should expand the macros into the BELs so that the PnR tool doesn't need to care. There might be a reason for the synthesis tool to indicate to the PnR tool that these BELs are all part of a "macro" and the PnR tool should keep them together....
<gatecat>
there are some problems here with the logical netlist, among other things
<gatecat>
in any event, doing macro expansion in PnR is not onerous, and keeps the whole flow neater as it is fully netlist compatible with the vendor tools throughout then
<mithro>
Well in some ways, this is our chance to change vendor tools behaviour -- so it would be good to think about how we want things to be done verses how the vendor tools do them
<gatecat>
I personally think this way is neater
<mithro>
gatecat: Is the macro expansion likely to be identical for all PnR tools?
<gatecat>
it depends, as some tools might want to represent hierarchy in different ways (or indeed never expand the macro but place it as one unit)
<gatecat>
the names of the subcells that it expands into is well defined and basically the same throughout
<gatecat>
I personally think that netlist compatibility with existing flows is important, for the simple reason of avoiding the need for extra synthesis steps for interchange flows which will make them appear inherently messier
<mithro>
gatecat: Thinking about #44 -- I'm on the side of "describe the device" with potential "hints for place and route tooling"
<gatecat>
mithro: right, the big question is how much in the way of "hints for place and route tooling" you have
<gatecat>
that's the whole premise behind #44
<mithro>
gatecat: Can we separate them though? IE The place and route tool should still *work* when the hints data is discarded, it just has to potentially work harder?
<gatecat>
that's basically the state of things at the moment
<gatecat>
it already will figure things out from the site routing - the problem isn't just having to work harder, but also that it currently doesn't figure things out but effectively bruteforces them so there are QoR issues too
<gatecat>
although this is partly due to some wider and nextpnr-specific issues with how the post-placement refinement works
<mithro>
gatecat: For the RAM128XD example -- what could you add an example of what the "right" version would look like verse the "quirky" placement?
<gatecat>
mithro: updated
<mithro>
@gatecat Where are the RAM blocks in your first diagram?
<gatecat>
in totally different sites
<gatecat>
(the key thing to highlight was how LUT route-throughs enable a questionable placement of the MUXFs)
<mithro>
gatecat: Isn't this the issue that the MUX was placed without considering delay?
<gatecat>
yes, the lack of timing data and strong pull from the IO probably isn't helping
<gatecat>
but still, it will take a lot of luck for it to end up in the right site
<gatecat>
and without placement constraints, it will be a hard job for SA to swap them all at once (but this more of a nextpnr specific issue)
<mithro>
gatecat: I would be very surprised if the delay between the LUT output and the MUX input direct path is anything but the fastest?
<gatecat>
right, but there are always other things pulling the muxes and LUTs in the other direction
<gatecat>
the placer has other objectives than the delay (which isn't in the data at all atm...) of that one path
<mithro>
What are the other objectives?
<gatecat>
all the other nets
kgugala has joined #symbiflow
kgugala_ has quit [Ping timeout: 252 seconds]
<mithro>
@gatecat I still think I'm missing something here, the 4 nets that are involved on that MUX are the two inputs, the select and the output right? The two inputs are direct output from the LUTs right?
<tpb>
Title: RAM128X1D Placement - Google Zeichnungen (at docs.google.com)
<gatecat>
mithro: imagine a simple chain: input->LUT->mux->output - the natural placement will be the LUT and mux at 1/3 and 2/3 respectively
<gatecat>
because there's nothing specifically telling the placer - and you can argue that it should see the dedicated path, and I agree that's fair but isn't happening atm - that the LUT and mux should actually belong together
epony has joined #symbiflow
<mithro>
gatecat: `D2_1` must be much greater than `D1_1`, right?
<gatecat>
mithro: yes, and of course an ideal placer should take that into account, but everything is based on heuristics and sometimes those don't work quite as well as you want
<mithro>
gatecat: I guess this is the advantage of the current VPR approach of clustering things together before placement
<gatecat>
sure
<gatecat>
the big question is to what extent the interchange format should contain explicit hints for that clustering; and other similar problems like global clock structures (e.g. https://github.com/SymbiFlow/nextpnr/issues/263)
rj has joined #symbiflow
epony has quit [Ping timeout: 240 seconds]
rj has quit [Ping timeout: 240 seconds]
rj has joined #symbiflow
nickoe has quit [Ping timeout: 240 seconds]
rj has quit [Ping timeout: 240 seconds]
rj has joined #symbiflow
gsmecher has joined #symbiflow
epony has joined #symbiflow
toshywoshy has quit [Ping timeout: 250 seconds]
toshywoshy has joined #symbiflow
epony has quit [Ping timeout: 240 seconds]
umarcor|2 has quit [Read error: Connection reset by peer]
umarcor|2 has joined #symbiflow
umarcor has joined #symbiflow
umarcor|2 has quit [Read error: Connection reset by peer]
umarcor|2 has joined #symbiflow
umarcor has quit [Read error: Connection reset by peer]