00:50 <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:52 <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?

12:06 <mithro> cjearls: There are no 35t parts only 50t parts

12:51 <tnt> mithro: but does the tool currently allow to "fake" the idcode in the bitstream ?

12:51 <tnt> Because they might be 50t internally but they are still fused to identify as 35t and only accept bitstreams marked for 35t.

12:52 <sf-slack1> <kgugala> @tnt there is no check in the chip, the only checks are done in the software

12:53 <tnt> Oh really ? Interesting, I never tried, but I thought that the chip checked ... (a bit like the ecp5)

13:12 <gatecat> afaik a default Xilinx bitstream does have an IDCODE check in it like, the ECP5

13:13 <gatecat> also 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:15 <sf-slack1> <kgugala> I'm pretty sure I used 50t bitstream with 35t device

13:59 <Lofty> mithro: 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.

14:17 <_whitenotifier-3> [fpga-interchange-schema] gatecat opened issue #50: Site PIP usage contract - https://git.io/J3XkB

14:22 <_whitenotifier-3> [sv-tests] udif opened issue #1501: Build fails with "No rule to make target 'image/bin/surelog'" - https://git.io/J3XL1

16:41 <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 <tpb> Title: Mercury 2 - Xilinx Artix-7 FPGA development board MicroNova (at www.micro-nova.com)

17:32 <tnt> cjearls: What mithro meant is that the die inside a 35t is the same as a 50t, it's purely a market segmentation thing.

17:48 <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:55 <gatecat> I think this part is already supported: https://github.com/SymbiFlow/prjxray-db/tree/master/artix7/xc7a35tftg256-1

17:56 <mithro> @acomodi - Which of the pathways on https://docs.google.com/drawings/d/12SjkmrsoI-Me4feKJoUV5F_0cfH75AoWoEqyvfI2Uuw/edit are tested in CI?

17:56 <tpb> Title: Copy of FPGA Interchange Testing Flow - Google Zeichnungen (at docs.google.com)

17:57 <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 incorrectly

17:57 <sf-slack1> <acomodi> mithro: at the moment only bit2fasm (theres a typo and the red fasm2bit should be bit2fasm) is missing

17:58 <mithro> acomodi: You should have edit access

17:58 <mithro> cjearls: The Arty A7-35T is the most tested part....

17:59 <sf-slack1> <acomodi> Right, fixed

17: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 2

17:59 <sf-slack1> <acomodi> @cjearls I think that, regarding the symbiflow-examples, what is missing is the pin mapping in the install package

18:00 <sf-slack1> <cjearls> Is fixing that as simple as getting the pin mapping from the database and adding a file for it?

18:01 <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 toolchain

18:01 <sf-slack1> <acomodi> let me grab the link to the issue

18:01 <sf-slack1> <cjearls> Oh, awesome!

18:05 <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 related

18:22 <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:35 <gatecat> timo.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:38 <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 <gatecat> yes, tristate behaviour is down to the BB primitive (or an inferred tristate) and not the flop. tristates should be fully supported

23:31 <mithro> gatecat: 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 <tpb> Title: Xilinx Series 7 Carry Routing Options - Google Zeichnungen (at docs.google.com)

23:32 <mithro> gatecat: Could you give me@mith.ro edit access to the Macro Placement doc?