<_whitenotifier-3>
[symbiflow-arch-defs] acomodi opened issue #1400: Diff tests fail for BRAM test 36 - https://git.io/JvA4x
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #symbiflow
Bertl_zZ is now known as Bertl
adjtm_ has quit [Quit: Leaving]
adjtm has joined #symbiflow
adjtm has quit [Remote host closed the connection]
adjtm has joined #symbiflow
kraiskil has quit [Ping timeout: 256 seconds]
rvalles has quit [Ping timeout: 260 seconds]
rvalles has joined #symbiflow
rvalles has quit [Ping timeout: 265 seconds]
rvalles has joined #symbiflow
<daniellimws>
mithro: Adding to my question earlier, are the makefiles under vpr/muxes https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/vpr/muxes/logic meant to generate the pbxml files from the verilog sources, hence the purpose of the test cases? Asking because I was not able to generate the xml files, and not exactly sure what the verilog sources are for
<tpb>
Title: GitHub - SymbiFlow/python-symbiflow-v2x: Tool for converting specialized annotated Verilog models into XML needed for Verilog to Routing flow. (at github.com)
<mithro>
daniellimws: If you are looking at potentially writing cocotb tests, I would suggest looking at the xc7 primitives for LUTRAM / BRAM
<daniellimws>
mithro: I'm wondering if cocotb tests are needed for vpr design sources? I don't see any in that repo. Or are they good to have but no one has added them yet?
<mithro>
daniellimws: However a bunch of the v2x functionality is broken for xc7 primitives
<mithro>
daniellimws: cocotb tests are probably not needed for the stuff under the vpr directory -- that would be more feeling out how the cocotb tests should be integrated
<daniellimws>
mithro: Could you suggest any primitives that I can add? And how would I verify that they are correct?
citypw has quit [Ping timeout: 240 seconds]
OmniMancer has quit [Quit: Leaving.]
Bertl is now known as Bertl_oO
bunnie[m] has left #symbiflow ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<mithro>
daniellimws: I think it is mostly verifying primitives at the moment rather than adding them
<_whitenotifier-3>
[symbiflow-arch-defs] mithro opened issue #1401: Empty directories with just CMakefiles? - https://git.io/JvAM6
<sf-slack>
<acomodi> probably a leftover during the refactoring of the xc7 tree
<sf-slack>
<acomodi> Uncaught by CI as the ramb18e1 and rambfifo36 subdirectories were not included in the CMakeLists.txt
<_whitenotifier-3>
[symbiflow-arch-defs] mithro opened issue #1402: Broken documentation for dram - https://git.io/JvAM9
<mithro>
acomodi: We should add something in the CI which detects CMakeLists.txt files which are not included.
<_whitenotifier-3>
[symbiflow-arch-defs] mithro opened issue #1403: Add CI to detect CMakeLists.txt files which are not used / dead - https://git.io/JvAM5
<_whitenotifier-3>
[symbiflow-arch-defs] kgugala opened issue #1405: Add an cmake option to disable a200t installtion - https://git.io/JvA9f
proteus-guy has joined #symbiflow
kraiskil has quit [Ping timeout: 265 seconds]
kraiskil has joined #symbiflow
<lambda>
I'm trying to use nextpnr for an xc7a35tfgg484-1 - I see that package is already in the database for the xc7a50t, how much effort would it be to adapt that for the 35?
<ZirconiumX>
daveshah: ^
<daveshah>
This is a prjxray issue, not a nextpnr one
<daveshah>
It shouldn't be a big patch at all, copy all the files and just change the idcode though
<daveshah>
After all they are the same silicon
<lambda>
wait, which ones, all the 35t's or the 35tfgg484 and the 50tfgg484?
<daveshah>
All of the above afaik
<daveshah>
I don't think there are any genuinely 35t parts
<lambda>
huh, didn't know that
<daveshah>
The number is made up anyway, it's a LUT4 equivalence so 0.625 LUT6s per notional unit or thereabouts
<ZirconiumX>
It's funny to compare across vendors. Altera/Intel use 0.4 ALM LUT6s per LUT4, because of the input overprovisioning
<ZirconiumX>
It's still a made-up number, but the architectural difference is fun
<litghost>
lambda: But what daveshah said is basically what is happening
<litghost>
lambda: Feel free to submit a PR adding packages you are interested in
<lambda>
litghost: sorry, I can't figure out where the extra parts are actually coming from (granted I don't really know much about the xray infrastructure at all). the only mentions of e.g. "csg324" I can find are in minitests/, which from my understanding is just used for testing, not the actual database.
<litghost>
I linked where the extra parts are coming from
<litghost>
Each line that calls into "make -C fuzzer roi_only" is for a new part using a piece of silicon already documented
<litghost>
So we have tilegrid address for the A50T (35T as well) and A200T silicon, but only a subset of the packages for each
<lambda>
litghost: so the xc7a35tcsg324-1 part is created using some Arty minitests?
<litghost>
Sort of. The arty minitests define XRAY_PART as xc7a35tcsg324-1, XRAY_EQUIV_PART as c7a50tfgg484-1 (e.g. which tilegrid/tileconn to use) plus some example IO's for use with the fuzzer
<lambda>
litghost: oh, I see now, roi_only does all the real magic
<litghost>
lambda: Ya. That target name is poorly named, but yes
<lambda>
litghost: so mashing together settings/artix7.sh for the fgg484 pins and minitests/roi_harness/arty-common.sh for the EQUIV_PART stuff should do?