<litghost>
There is a defect in the CMake dependencies around python libraries, solution is to remove <build_dir>/xc7/archs/artix7/channels.db
<litghost>
Sorry for the confusion
<litghost>
Of course maybe I'm misunderstanding what you are trying to do
<litghost>
That particular error would arise if the arch.xml and rrgraph.xml got out of sync
<lromor[m]>
I'
<litghost>
That message was truncated, I don't follow what you were asking for
<lromor[m]>
* When generating the packed netlist (.net) I'm using those the arch timings and the rr graph. I guess there's a mismatch.
<litghost>
The mismatch inidicated in that error is a mismatch between the arch.xml and rrgraph.xml
<litghost>
I recommend re-running the following CMake target "file_xc7_archs_artix7_devices_rr_graph_xc7a50t-arty-swbut_test.lookahead.bin"
<lromor[m]>
I'm not sure at which point I should remove the channels.db as it's not a dependency of my vpr command.
<litghost>
I would remove channels.db and then rebuild up to "file_xc7_archs_artix7_devices_rr_graph_xc7a50t-arty-swbut_test.lookahead.bin"
<litghost>
Then take the new arch.xml/rrgraph.xml/lookaheads
<lromor[m]>
ok
<litghost>
Does that make sense?
<lromor[m]>
Yup! Thanks!
craigo has quit [Ping timeout: 240 seconds]
<litghost>
One thing we will likely be adding the in next couple weeks once the ROI breakout is done is some kind of "make install" that exports the files needed to run VPR against various circuits
<litghost>
Outside of the symbiflow CMake system
<litghost>
I imagine that will make your flow easier
<lromor[m]>
That would ideal! Thank you for your work!
kraiskil has quit [Ping timeout: 246 seconds]
<lromor[m]>
litghost: That fixed the issue! Thanks
<litghost>
Great!
kraiskil has joined #symbiflow
freemint has joined #symbiflow
kraiskil has quit [Read error: Connection reset by peer]
Bertl_oO is now known as Bertl_zZ
<hackerfoo>
litghost: Routing works now, but it's still a little under 2x slower than before for some reason. I'm going to try to get the PR out today.
<litghost>
Sounds good
<litghost>
I have my debugging tools ready to go and tommorow hopefully I'll be able to see problems
<hackerfoo>
litghost: The PR is ready for review. There are some things you can tweak at the top of connection_box_lookahead_map.cpp. The things we decide to keep can be made into flags.
<mithro>
litghost: The INT_L.IMUX_L33.LOGIC_OUTS_L18 change in that pull request doesn't look right?
<litghost>
mithro: Ya, there was no change that should have caused that
<litghost>
mithro: So it's some form of instability
<hackerfoo>
litghost: I'm currently running it, but last time it ran for 1188s with 2.4e9 heap pushes and a CPD of 11.809. This was with BREAK_ON_MISS = true, so I'm running without that since I don't trust that optimization yet.
<hackerfoo>
It'll probably be the same, though.
<litghost>
hackerfoo: Okay, that matches about what I was getting with your wip-testing @ 0477b874ad1be65626c99ae13f707586a7dae116
<hackerfoo>
The fill now follows a diamond pattern to match the Manhattan distance, and penalizes based on the distance. The max_fill's (sizes of largest hole) are still surprizingly high.
<hackerfoo>
So increasing sampling from 3x3 might help, because there is a lot of guessing right now.
<litghost>
hackerfoo: I don't expect increasing the sample grid will change much actually, as the holes are likely a function of the graph structure
<litghost>
hackerfoo: I do think a 2D interpolation may be better suited to hole filling, but I'm waiting to get data to support that
<mithro>
litghost: Should I just revert those changes?
<hackerfoo>
Turning on FILL_LIMIT limits the amount of filling, but then I get an error routing GND to a LUT.
<litghost>
mithro: Just the ones to INT_L
<hackerfoo>
Even setting it at 30.
<litghost>
hackerfoo: It's interesting, I didn't see the same issue on the prevoius search, but I cannot explain why yet
<litghost>
hackerfoo: I was able to use a fill limit of 3 and it worked
<hackerfoo>
Maybe I'll try it again, because I fixed some things.