Heterogeneous tiles implementation

[acomodi]

Signed-off-by: Alessandro Comodi acomodi@antmicro.com

This PR is an initial implementation of the heterogeneous tiles introduced with verilog-to-routing/vtr-verilog-to-routing#1208.

TODO:

• find a better way to use the start_tile implementation so that it gets used more generally by the various tile import scripts.
• produce a new VtR master+wip with the heterogeneous tiles implementation

[acomodi]

Update: I am testing this PR alongside with the VtR heterogenous implementation integrated in master+wip and the litex-linux base test seems to be working, meaning that it passes Memtest.

I need to setup locally a tftp server to load linux binaries in DDR

[litghost]

Update: I am testing this PR alongside with the VtR heterogenous implementation integrated in master+wip and the litex-linux base test seems to be working, meaning that it passes Memtest.

I need to setup locally a tftp server to load linux binaries in DDR

Awesome!

[acomodi]

Edit: Linux boots correctly. I used UART to load binaries as I have some troubles with the tftp server (on the local host, so unrelated to the bitstream).

[litghost]

Waiting for CI results. I want to compare quality and runtime results. Overall looks great!

[acomodi]

For some reason the vendor tool buildfailed. I think though, by looking at the log, that all the tests acutally passed.

[litghost]

For some reason the vendor tool buildfailed. I think though, by looking at the log, that all the tests acutally passed.

There was a failure, but I don't think it is related.

[acomodi]

I have run the bram_test_36 on test on symbiflow master against a local master+wip version with the updated master and explicit_ports and it seems to correctly route the constant net.

This indicates that there might be something not correctly working with:

• The heterogeneous tiles VtR implementation: I do not think this is the case, because there is nothing in the heterogeneous tiles that changes routing behaviour. One thing to check though is the correctness of the post-placement synchronization of the net terminals, which should be fine though as, if they weren't, there would most probably be a VTR assertion failure. In addition, the BRAM tile has only one equivalent site as well as only one sub tile;
• Changes introduced with this PR
• ??

[acomodi]

@litghost I realized one other thing that is different w.r.t. symbiflow master is that we are now using the bucket router_heap. I have tried to remove it and use the default one and, at least locally, the failing bram_36_diff_fasm test passes correctly.

I think that might be the reason for the vendor tools to fail. Anyhow, I am unsure whether this is a strong failure, meaning that it could potentially be solved in fasm2bels, as probably, for this weird route through two FAN pips, the tcl won't include the fixed route to the REGCLKB site pin of the BRAM 36.

[litghost]

we are now using the bucket router_heap

We were using the bucket heap before, the difference is the default router heap was set to the bucket heap, and now it matches upstream, and the default router heap is binary again. See https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/462/files#diff-f021ce5c0df49c7bf6020d0a4d94db66L1720

GitHub

Heterogeneous master+wip by acomodi · Pull Request #462 · SymbiFlow/vtr-verilog-to-routing

Included branches: wip/heterogeneous_tiles Deleted branches: wip/add_explicit_ports wip/refactor_heap3

[litghost]

Thanks for splitting the functions, I think it looks much clearer.

[litghost]

Because SITE_TYPES is now a mutliValueArgs, this is simply a CMake list

[acomodi]

@litghost Indeed, what I meant was that by leaving the default heap (which is the binary with the new master+wip) the vendor tools pass.

What remains to understand is why using the bucketed one (still to verify with CI though) the bram_test_36 fails.

[litghost]

@litghost Indeed, what I meant was that by leaving the default heap (which is the binary with the new master+wip) the vendor tools pass.

I expect randomness? I doubt the default heap always passes. It is worth making sure the bucket heap is completing faster than the binary heap, and by a significant amount. If the binary heap is 1% slower, but always has a green CI, that is not the same situation as a 10-15% slower, right?

[acomodi]

@litghost I would say we let this CI run finish and extract run-time data. As I suppose, the bucket heap should give us greater performance, in that case we may consider solving the weird jump on the FAN_BOUNCE in fasm2bels?
What I have experienced is that, for several runs, the bucket heap always failed that test, instead the binary one did succeed everytime.

[litghost]

in that case we may consider solving the weird jump on the FAN_BOUNCE in fasm2bels?

No this should be fixed in either fasm2frames or before fasm2frames.

[acomodi]

@litghost All right, then is it worth restoring the bucket heap (if it results to be required to maintain the great improvement w.r.t. the binary one), removing the diff fasm test from the bram_test_36 and opening an issue to keep track of this?

[litghost]

@litghost All right, then is it worth restoring the bucket heap (if it results to be required to maintain the great improvement w.r.t. the binary one), removing the diff fasm test from the bram_test_36 and opening an issue to keep track of this?

To be clear, I don't believe switching from the binary to bucket or vise-versa actually fixes the vendor tools test. However if the vendor tools test is consistently green on binary, then let's do that.

[litghost]

If CI is green, merge

[acomodi]

xc7 vendor tools went green even though GH does report it as still running. Merging.