Thursday, 2021-05-06

« Wednesday, 2021-05-05 Index Friday, 2021-05-07 »
*** tpb has joined #symbiflow00:00
*** Degi has quit IRC00:09
*** Degi has joined #symbiflow00:10
*** TMM has quit IRC00:17
*** TMM has joined #symbiflow00:17
*** gsmecher has quit IRC00:28
*** calphool has quit IRC00:42
sf-slack1<cjearls> In the guide to adding a new device to an existing family, I have questions about all the values in the settings file: 1. When choosing a package for XRAY_PART, how do you know a package is fully bonded?  2. What do the values in XRAY_ROI_TILEGRID mean and how do I know if the bounding boxes are a tight fit for the new part I'm adding? 3. How do I find out what tiles need to be added to XRAY_IOI3_TILES?00:50
sf-slack1<cjearls> Does there even need to be a separate artix7_35t.sh for 35t parts, or does artix7_50t.sh work for them?00:52
*** extorr has joined #symbiflow01:14
*** ByteLawd has quit IRC01:15
*** tnt has quit IRC01:18
*** tnt has joined #symbiflow01:18
*** rvalles has quit IRC01:26
*** rvalles has joined #symbiflow01:26
*** tux3 has quit IRC01:52
*** heath has quit IRC01:52
*** tux3 has joined #symbiflow01:53
*** heath has joined #symbiflow01:53
*** kgugala_ has joined #symbiflow04:17
*** kgugala__ has joined #symbiflow04:20
*** kgugala has quit IRC04:20
*** kgugala_ has quit IRC04:21
*** kgugala has joined #symbiflow04:50
*** kgugala__ has quit IRC04:53
*** cr1901_modern has quit IRC05:32
*** citypw has joined #symbiflow05:37
*** kgugala_ has joined #symbiflow06:10
*** kgugala has quit IRC06:14
*** extorr has quit IRC06:59
*** extorr has joined #symbiflow07:00
*** cr1901_modern has joined #symbiflow07:44
*** kraiskil has joined #symbiflow08:30
*** kraiskil has quit IRC09:19
*** HackerFoo has quit IRC10:22
*** m_hackerfoo has quit IRC10:22
*** m_hackerfoo has joined #symbiflow10:26
*** HackerFoo has joined #symbiflow10:26
*** proteusguy has quit IRC11:10
*** citypw has quit IRC11:59
mithrocjearls: There are no 35t parts only 50t parts12:06
*** citypw has joined #symbiflow12:12
tntmithro: but does the tool currently allow to "fake" the idcode in the bitstream ?12:51
tntBecause they might be 50t internally but they are still fused to identify as 35t and only accept bitstreams marked for 35t.12:51
sf-slack1<kgugala> @tnt there is no check in the chip, the only checks are done in the software12:52
tntOh really ? Interesting, I never tried, but I thought that the chip checked ... (a bit like the ecp5)12:53
gatecatafaik a default Xilinx bitstream does have an IDCODE check in it like, the ECP513:12
gatecatalso like the ECP5 you could probably create a bitstream without the IDCODE check that works on both parts (I haven't tried this for ECP5, idk what X-ray does for Xilinx)13:13
sf-slack1<kgugala> I'm pretty sure I used 50t bitstream with 35t device13:15
*** citypw has quit IRC13:51
Loftymithro: I feel like calphool is now going to expect that Mistral would be able to import designs into Quartus when that... wasn't really on the cards initially.13:59
*** gsmecher has joined #symbiflow14:03
-_whitenotifier-3- [fpga-interchange-schema] gatecat opened issue #50: Site PIP usage contract - https://git.io/J3XkB14:17
-_whitenotifier-3- [sv-tests] udif opened issue #1501: Build fails with "No rule to make target 'image/bin/surelog'" - https://git.io/J3XL114:22
*** proteusguy has joined #symbiflow14:39
*** Raito_Bezarius has quit IRC15:01
*** Raito_Bezarius has joined #symbiflow15:14
*** lkcl has quit IRC15:36
*** lkcl- has joined #symbiflow15:44
*** lkcl has joined #symbiflow15:44
*** lkcl has quit IRC15:55
*** lkcl- is now known as lkcl15:55
sf-slack1<cjearls> @mithro: The Mercury 2 (https://www.micro-nova.com/mercury-2) user manual (https://static1.squarespace.com/static/545510f7e4b034f1f6ee64b3/t/5d43ca193b50bf0001adebe3/1564723738807/Mercury2_reference_manual.pdf) says it uses the XC7A35T-1FTG256C. Is that not a 35t part?16:41
tpbTitle: Mercury 2 - Xilinx Artix-7 FPGA development board MicroNova (at www.micro-nova.com)16:41
*** kraiskil has joined #symbiflow17:08
*** kraiskil has quit IRC17:18
tntcjearls: What mithro meant is that the die inside a 35t is the same as a 50t, it's purely a market segmentation thing.17:32
sf-slack1<cjearls> Yep, that makes sense to me. How does that affect adding support for a 35t part? Is there somewhere I can find more information on the XRAY_ROI_TILEGRID or XRAY_IOI3_TILES?17:48
sf-slack1<cjearls> Or does that mean that the 35t parts are all already supported because of support for the 50t?17:48
gatecatI think this part is already supported: https://github.com/SymbiFlow/prjxray-db/tree/master/artix7/xc7a35tftg256-117:55
mithro@acomodi - Which of the pathways on https://docs.google.com/drawings/d/12SjkmrsoI-Me4feKJoUV5F_0cfH75AoWoEqyvfI2Uuw/edit are tested in CI?17:56
tpbTitle: Copy of FPGA Interchange Testing Flow - Google Zeichnungen (at docs.google.com)17:56
sf-slack1<cjearls> I couldn't seem to get it working in the symbiflow-examples repo, but I'll have to run make again to remember what the error was. Maybe I was just configuring something incorrectly17:57
sf-slack1<acomodi> mithro: at the moment only bit2fasm (theres a typo and the red fasm2bit should be bit2fasm) is missing17:57
mithroacomodi: You should have edit access17:58
mithrocjearls: The Arty A7-35T is the most tested part....17:58
sf-slack1<acomodi> Right, fixed17:59
sf-slack1<cjearls> Ok, I'm getting an error that opt/symbiflow/xc7/install/share/symbiflow/arch/xc7a50t_test/xc7a35tftg256-1/pinmap.csv doesn't exist when I try to generate a bitstream for the Mercury 217:59
sf-slack1<acomodi> @cjearls I think that, regarding the symbiflow-examples, what is missing is the pin mapping in the install package17:59
sf-slack1<cjearls> Is fixing that as simple as getting the pin mapping from the database and adding a file for it?18:00
sf-slack1<acomodi> There is an open issue to try and fix this, so that all the "prjxray-supported" parts (which are all the parts belonging to the 25T, 50T, .. 200T family IIRC) are supported in the toolchain18:01
sf-slack1<acomodi> let me grab the link to the issue18:01
sf-slack1<cjearls> Oh, awesome!18:01
sf-slack1<acomodi> There are two actually: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/1800 and https://github.com/SymbiFlow/symbiflow-arch-defs/issues/2131 which are related18:05
sf-slack1<timo.callahan> gatecat: where should I file an issue for this?  I believe it is related to an inferred tri-state, probably related to quad SPI:   `ERROR: Cell type 'IFD1P3BX' instantiated as 'IFD1P3BX' is not supported by this device.`18:22
*** TMM has quit IRC18:27
*** TMM has joined #symbiflow18:27
gatecattimo.callahan: nextpnr is as good as anywhere - the workaround for now is probably to use a regular flipflop instead of an IO one (you could file a litex issue for the workaround too)18:35
sf-slack1<timo.callahan> gatecat: would I still be able to get tri-state behavior on the pin, just using a different flop primitive?18:38
gatecatyes, tristate behaviour is down to the BB primitive (or an inferred tristate) and not the flop. tristates should be fully supported18:38
*** kgugala has joined #symbiflow19:25
*** kgugala_ has quit IRC19:25
*** kgugala_ has joined #symbiflow19:32
*** kgugala has quit IRC19:33
*** adjtm has joined #symbiflow19:36
*** adjtm_ has quit IRC19:39
*** kgugala_ has quit IRC19:46
*** kgugala has joined #symbiflow19:46
mithrogatecat: Did you see https://docs.google.com/drawings/d/18PW1kIcOZMz2d_jYJLvnf8AMRRhLgmjpWfmArqHUSyM/edit https://docs.google.com/drawings/d/1ZG3eqAp7NrDsf6Ra6zHrVOJyxxCmblpOPVFW8NpE4aQ/edit and https://docs.google.com/drawings/d/1qREImoaUjWDSsnbimDu-Mig3_M9hTr-6q-zbPd2VPEM/edit ?23:31
tpbTitle: Xilinx Series 7 Carry Routing Options - Google Zeichnungen (at docs.google.com)23:31
mithrogatecat: Could you give [email protected] edit access to the Macro Placement doc?23:32
« Wednesday, 2021-05-05 Index Friday, 2021-05-07 »

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