Wednesday, 2021-11-03

*** tpb <[email protected]> has joined #symbiflow00:00
*** lkcl <[email protected]> has quit IRC (Quit: BNC by #bnc4you)00:28
*** lkcl <[email protected]> has joined #symbiflow02:36
sf-slack<mkurc> @torsten.reuschel Hi. Good to hear that somebody is interested in Kintex 7 support :)08:11
sf-slack<mkurc> So to have support for a Kintex in SymbiFlow there are two things needed: prjxray database and architecture for VPR. All the fuzzers (supposedly) run for both Artix and Kintex devices. So adding a new Kintex part there should give you everything although some tweaks to the fuzzers may be required.08:11
sf-slack<mkurc> VPR architecture is another story. In symbiflow-arch-defs there is a set of Python scripts which generate base architecture XML for VPR and then patch the routing graph it generates with the actual routing architecture. I don't think that they have been tried on a Kintex. Probably the best way to start is to examine the CMake build system, add a new architecture there and try running the whole flow.08:11
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)11:45
*** TMM_ <[email protected]> has joined #symbiflow11:45
sf-slack<torsten.reuschel> @mkurc: Thank you for the input. The fuzzer 005 fails for me with Vivado telling me the design is empty. Seems that this may happen when no outputs are present in a design, cf. https://www.element14.com/community/thread/78101 Seems as if some tweak is needed here. Any advice where to start with this? Fuzzers 001 and 072 complete without issues12:24
sf-slack<mkurc> @torsten.reuschel Well as far as I remember 005 is for the tilegrid and may be very specific to a part. So some work may be needed to add the larger Kintex.12:36
sf-slack<torsten.reuschel> Understood. I see that is broke down at fuzzers/orphan_int_column12:37
sf-slack<torsten.reuschel> The generated top module in top.v is indeed empty.12:42
sf-slack<torsten.reuschel> How would I be able to isolate this case, i.e. tweak "make db-part-only-..." so that it generates only this test?12:51
sf-slack<mkurc> So in other words you want to run just the fuzzer 005 ?12:54
sf-slack<torsten.reuschel> Ideally just fuzzer005/orphan_int_column13:08
sf-slack<torsten.reuschel> @mkurc: I've isolated the test by commenting out all other preceeding tests in the fuzzer 005 Makefile, not sure if this might break anything else. Looks like it generates the empty module as before, though.13:23
sf-slack<mkurc> For 005 commenting others should work. But generally it is better to do as the step 9 in the prjxray readme suggests.13:26
sf-slack<torsten.reuschel> Right.. I should confirm with the entire/unmodified fuzzer if in doubt.13:34
sf-slack<torsten.reuschel> @mkurc: Do  you expect modifications for the larger Kintex7 to be necessary in the Python-generator script (e.g. fuzzer005/orphan_int_column/top.py) or in some specific spot of the database? Data structure looks reasonable near https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/005-tilegrid/orphan_int_column/top.py#L335: a prjzray.grid is delivered to the loop, but the loop then outputs an empty13:45
sf-slackstructure13:45
sf-slack<torsten.reuschel> I feel like wading through fog right now. Not sure that I am even looking in the right place13:46
sf-slack<torsten.reuschel> @fahrenkrog: The flash memory has to be erased prior to programming. It sounds reasonable that this takes a few seconds13:56
sf-slack<mkurc> @torsten.reuschel TBH I cannot tell out of my head what are the required changes to 005. You may try digging deeper into the fuzzer to understand its operation.14:07
sf-slack<torsten.reuschel> Okay fair enough. Thank you!14:14
sf-slack<fahrenkrog> @torsten.reuschel Yes, makes sense, when I reprogram the SPI flash. I was wondering after the flash has been programmed with the bitstream, from power-on until the FPGA flashes the "Done" LED it's taking about 10 seconds. I recall that being pretty instant, as in less than 1 seconds in other boards I've used.14:24
sf-slack<torsten.reuschel> @fahrenkrog: Ok, I would think that to be odd as well. Don't have an explanation for that14:32
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)14:40
*** TMM_ <[email protected]> has joined #symbiflow14:40
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow15:13
sf-slack<torsten.reuschel> @litghost: I see that you created https://github.com/SymbiFlow/prjxray/tree/master/fuzzers/005-tilegrid/orphan_int_column . In the case of ac7k325t, the output of https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/005-tilegrid/orphan_int_column/top.py#L129 is empty. Is this a valid state?15:37
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)15:47
sf-slack<torsten.reuschel> @mkurc: Do you know how to make a sensible choice for the device families defined in /prjxray/settings/ ? I think that I need to modify `XRAY_ROI_TILEGRID` (cf. for example https://github.com/SymbiFlow/prjxray/blob/master/settings/artix7.sh#L15 ) as I go from xc7k70 to xc7k32515:48
sf-slack<mkurc> Hm, I'd say that those coords should cover the entire fabric. Otherwise you won't fuzz base addresses for tiles outside.15:50
sf-slack<mkurc> The best way to tell which ones to use is to open the device floorplan in Vivado15:50
sf-slack<mkurc> Although please double check how those coords are used in 005. Because the fuzzer runs both for eg. Artix50T and 200T which differ in size and the script seems to define only one range.15:53
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow15:55
sf-slack<torsten.reuschel> Thanks for the hint on checking the floorplan in Vivado! The definition of `XRAY_ROI_TILEGRID` differs between Artix50T and 200T15:56
*** mgielda <[email protected]> has joined #symbiflow16:08
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)16:18
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow16:28
*** mgielda <[email protected]> has quit IRC (Quit: Connection closed)16:39
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)16:47
sf-slack<tmichalak> @fahrenkrog it's strange that it takes so long, it's 1-2 seconds in my case16:56
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow16:58
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)17:15
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow17:20
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)17:58
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow18:09
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)18:26
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow18:37
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)18:54
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow19:04
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)19:22
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow19:32
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)20:07
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow20:18
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)20:51
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow20:56
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)21:18
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow21:29
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)21:48
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow21:53
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)22:18
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow22:28
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds)22:46
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow22:51
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Quit: ec)23:21

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!