Hi @dnltz ,

There is a guide for this case -- https://prjxray.readthedocs.io/en/latest/db_dev_process/newpart.html. You would just be adding a new package (256 pins) for a currently supported device (35t). So you'd skip steps 2-4 of that guide.

However, we have planned a project to automatically generate the pinmaps for all packages once a device is supported -- f4pga/prjxray#1476 -- but I don't know what the timeline is for that.

Guide to adding a new device to an existing family — Project X-Ray 0.0-3294-g2353b22c documentation

Thanks @tcal-x ! That was exactly what I was looking for :)

Yes, would be nice to have all available packages in the example. Do you need more hardware for testing? I could send a board with this package in January.

Hi @dnltz ,
I don't we'll need real hardware, although thank you for the offer. We test mainly by running designs through Symbiflow, then exporting back into Verilog+constriants, reading that into Vivado, then generating a bitstream from there, and diffing between the bitstreams. This is done in the symbiflow-arch-defs repository. So we'll want to add some tests there. Here for example is my PR for adding tests for the 100T: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1515/files. You would touch just a few files -- a new entry in the boards file xc/xc7/boards.cmake, then some new test variants under xc/xc7/tests/. Unfortunately I haven't yet written the step-by-step guide for this side of things.

GitHub

Initial support for Artix 100t parts by tcal-x · Pull Request #1515 · SymbiFlow/symbiflow-arch-defs

Initial support for xc7a100t parts: board arty100t-full arch artix7_100t device xc7a100t-virt parts xc7a100tcsg324-1, xc7a100tfgg676-1 tests "arty100t" versions of: buttons, co...

@dnltz We would like someone to do f4pga/prjxray#1475 and f4pga/prjxray#1476. It should just be some Python work, if you feel up for it!

hey @litghost - I'm very busy right now until end of December. I can do these PRs than, if it's not that urgent.

Coming back to my original problem, the way to make my part available in the prebuild toolchain is to add it as board to this project, right?

Coming back to my original problem, the way to make my part available in the prebuild toolchain is to add it as board to this project, right?

Next step is to update the prjxray-db package. I'll poke @mithro

The Zynq build got stuck in some way, so I killed it and kicked it off again.

In the meantime, I pushed the Artix + Kintex stuff to f4pga/prjxray-db@master...mithro:master

There seems to be a lot of changes in the mask_bram_l and mask_dsp_l files -- is that expected?

A zynq run completed successfully, see the changes at f4pga/prjxray-db@master...mithro:master

If someone confirms that the mask changes for bram and dsp are expected, I'll push the result to the database.

I am not sure what are the mask files used at this point, or if they are every used in the flow. As for they are expected or not, the only recent changes to the DSP happened here and the output is already checked-in in the db, so the change seems a bit odd.

I think I can close this issue. @mithro Can I add a not for sale board with this part?

@dnltz - Add to were?

@mithro - My understand is that the flow needs data from xc7a50t_test which are generated with this project. So my idea was to add the board here to this project to have my part deployed. Not sure if this is the right way.

@dnltz Oh, I understand. It might be worth chatting with @litghost if there is a good way to support all the parts now? If there isn't an easy way, landing that option in the short term is 100% fine.

@dnltz So you remember how we made the mapping from part -> device -> fabric in prjxray? That same distinction exists in arch-defs, but pre-dates the prjxray change. arch-defs simple maps part directly to fabric (and a "board") in https://github.com/SymbiFlow/symbiflow-arch-defs/blob/a3c75b4b7304a29ff3d48b594e5afe922ce00f7e/xc/xc7/boards.cmake

The key CMake function is add_xc_board, which is defined here: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/a3c75b4b7304a29ff3d48b594e5afe922ce00f7e/xc/common/cmake/device_define.cmake#L1-L11

The key portion for expanding part support for everything is generating "pinmap.csv" for every part in prjxray, which is here: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/a3c75b4b7304a29ff3d48b594e5afe922ce00f7e/xc/common/cmake/device_define.cmake#L160-L172

In summary:

• arch-defs manually mapped part -> fabric in xc7/boards.cmake
• That information now exists in prjxray per your update
• The only thing that needs to be done to support more parts is to create the pinmap.csv for each part. In order to generalize this, there needs to be a map from prjxray fabric to arch-def DEVICE.
  • For example, the prjxray fabric "xc7a50t" is the arch-def DEVICE "xc7a50t".

Because the naming conventions in arch-defs appear to generally match the naming conventions from prjxray, I believe it should be possible to emit CMake targets to generate the "pinmap.csv" for every part now in prjxray as part of the install targets.

Does this make sense?

GitHub

SymbiFlow/symbiflow-arch-defs

FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. - SymbiFlow/symbiflow-arch-defs

One additional note, the current add_xc_board names the output pinmap CSV based on the name of the board, but it probably should just be named for the package.

I'm not very familiar with cmake. A target is a function like ADD_XC_BOARD, right? If that's true, my understanding or idea would be to add a new function to generate all pinmaps for a fabric and to add the function calls to the boards.cmake for each device.

I'm not very familiar with cmake. A target is a function like ADD_XC_BOARD, right? If that's true, my understanding or idea would be to add a new function to generate all pinmaps for a fabric and to add the function calls to the boards.cmake for each device.

@litghost