| *** tpb <[email protected]> has joined #symbiflow | 00:00 | |
| *** benreynwar <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 02:36 | |
| *** benreynwar <[email protected]> has joined #symbiflow | 02:39 | |
| sf-slack | <gergo> I'd like to target the Nexys A7-50T dev board with Symbiflow. I've downloaded and set up the example repo, added a new `.xdc` file to `xc7/counter_test` , and edited the `Makefile` to set `PARTNAME :=xc7a50tcsg324-1` . At first, this failed because Symbiflow doesn't include the part definition for this A7 model; so I downloaded the files from https://github.com/SymbiFlow/prjxray-db/tree/master/artix7/xc7a50tcsg324-1 and | 07:19 |
|---|---|---|
| sf-slack | now I get all the way to the `symbiflow_place` step. However, that then complains about a missing `arch/xc7a50t_test/xc7a50tcsg324-1/pinmap.csv` file, and I haven't been able to find a repository of `pinmap.csv` files the same way I've found the `part.json` etc. files. So my question is, where can I download a `pinmap.csv` file for an arbitrary Xilinx Artix7 model, or alternatively, how do I generate one? | 07:19 |
| sf-slack | <gergo> This is the board in question: https://www.xilinx.com/products/boards-and-kits/1-zywan9.html | 07:36 |
| sf-slack | <gergo> I can see that the Nexys 4 DDR is one of the supported boards, and this one is supposed to be the same but with a slightly different Artix 7 part. Can I take the `pinmap.csv` that the Nexys 4 DDR uses and tweak that? | 07:46 |
| *** Veera <[email protected]> has joined #symbiflow | 07:57 | |
| *** Veera <[email protected]> has quit IRC (Remote host closed the connection) | 08:19 | |
| *** Veera <[email protected]> has joined #symbiflow | 08:19 | |
| *** duck2 <[email protected]> has quit IRC (Quit: Ping timeout (120 seconds)) | 08:26 | |
| *** duck2 <[email protected]> has joined #symbiflow | 08:26 | |
| sf-slack | <kgugala> @gergo you may try using `xc7a35tcsg324-1` part | 08:36 |
| sf-slack | <kgugala> xc50 and xc35 have the same fabric | 08:36 |
| sf-slack | <gergo> Oh really? So would it work if I just took the `xc7a35tcsg324-1` 's `pinmap.csv` and copy it into the new name? I think that would be cleaner than pretending that my FPGA target is something it isn't. | 08:58 |
| sf-slack | <kgugala> I haven't seen any case of damaging FPGA with an incorrect bit file :) | 09:25 |
| sf-slack | <kgugala> but | 09:25 |
| sf-slack | <kgugala> if you e.g. drive low some pin that is connected to VCC in the board then you can damage the chip | 09:25 |
| sf-slack | <kgugala> but you'd have to drive the pin in your design | 09:25 |
| sf-slack | <kgugala> the toolchain will not make such things | 09:26 |
| sf-slack | <kgugala> (by itself) | 09:26 |
| sf-slack | <gergo> Right, sure, yeah I meant the case where the bitfile itself breaks something. I understand damaging a single pin's buffers with stupid wiring. Ask how I know :) | 09:30 |
| lambda | can't the same thing happen internally, i.e. pips connecting two outputs that try to drive the net to different levels? | 09:31 |
| sf-slack | <kgugala> ;) | 09:31 |
| sf-slack | <gergo> Alright, by using `pinmap.csv` from `xc7a35tcsg324` I managed to get counter_test working on my Nexys A7-50T! | 09:31 |
| sf-slack | <kgugala> awesome! | 09:31 |
| sf-slack | <gergo> for the next step I'll need to figure out how to do this fully automated, because there are some manual steps still | 09:32 |
| sf-slack | <gergo> also very annoying that if I override DATABASE_DIR for the `write_bitstream` step, then I need to copy all 400+ files from `.conda/envs/xc7/share/symbiflow/prjxray-db/artix7/` to my directory where I added the new board | 09:33 |
| sf-slack | <gergo> but I'm hoping this will turn out to be just a problem with the high-level Symbiflow shell scripts, and once I start using the underlying tools directly it will be solvable | 09:34 |
| sf-slack | <gergo> my aim is to ship all board-specific files (both `.v` / `.xdc` stuff and FPGA part definitions) and nothing more, with my project | 09:34 |
| sf-slack | <kgugala> yes, this is in the scripts | 09:34 |
| sf-slack | <gergo> so someone can use an unmodified Symbiflow installation and still build for my board which is not fully included in the Symbiflow distribution | 09:35 |
| sf-slack | <gergo> thanks this has been huge help | 09:35 |
| sf-slack | <gergo> On an unrelated note, is there a story for clock managers with Symbiflow? | 09:35 |
| sf-slack | <kgugala> BTW script sources are here https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/toolchain_wrappers if you'd like to improve them | 09:35 |
| sf-slack | <kgugala> we do support MMCMM and PLL so you can them in your designs | 09:36 |
| sf-slack | <gergo> Is there an example project? My current, Vivado-based project uses this ugly huge ClockWiz `.xci` file. | 09:37 |
| sf-slack | <kgugala> oh | 09:37 |
| sf-slack | <gergo> I'm not married to the `.xci` file (in fact, the opposite)... Ideally I'd just say "I want 25.175 MHz from 100 MHz" and the rest should be done for me :) | 09:38 |
| sf-slack | <kgugala> yep, you should directly instantiate a PLL with proper config | 09:39 |
| sf-slack | <kgugala> this way you have the whole design in the code | 09:39 |
| sf-slack | <gergo> that is exactly what I'd like. Do you have a documentation pointer? | 09:39 |
| sf-slack | <kgugala> give me a sec | 09:40 |
| sf-slack | <kgugala> here https://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug953-vivado-7series-libraries.pdf you can find info how to instantiate different blocks (PLL is on page 317, MMCM on 264) | 09:42 |
| sf-slack | <kgugala> this one https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf discusses clocking network in 7-series | 09:42 |
| sf-slack | <kgugala> here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/tests/mmcm/mmcme2_test.v is our MMCM test (it does instantiate MMCM primitive :)) | 09:43 |
| sf-slack | <kgugala> https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/tests/mmcm (readme here gives a bit more info ) | 09:44 |
| *** Veera <[email protected]> has quit IRC (Remote host closed the connection) | 09:44 | |
| sf-slack | <kgugala> similar thing for PLL https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc/xc7/tests/pll | 09:44 |
| *** Veera <[email protected]> has joined #symbiflow | 09:44 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 10:00 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 10:00 | |
| *** Veera <[email protected]> has quit IRC (Remote host closed the connection) | 11:07 | |
| *** Veera <[email protected]> has joined #symbiflow | 11:08 | |
| sf-slack | <gergo> So this https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc/xc7/tests/pll/plle2_test.v defines the clocks? | 12:11 |
| sf-slack | <kgugala> PLLE_ADV generates the clocks, you have to provide it with some input clocks and parameters how the clock should be generated. In the test PLL is fed with 2 clocks (100MHz and 50MHz) and later you have global MULT and bunch of DIVIDE params (for every clock out) | 12:41 |
| *** Veera <[email protected]> has quit IRC (Remote host closed the connection) | 12:48 | |
| *** Veera <[email protected]> has joined #symbiflow | 12:48 | |
| sf-slack | <gergo> right, so it's pretty much the same as what I used to input into Vivado's "clock wizard", but in a .v file. | 12:55 |
| sf-slack | <kgugala> Yep | 12:56 |
| sf-slack | <gergo> So this turns out to be trickier than what I hoped. The actual command run by SymbiFlow is `xcfasm --db-root /somewhere/prjxray-db/artix7 --part xc7a50tcsg324-1 --part_file /somewhere-else/counter_test/artix7/xc7a50tcsg324-1/part.yaml --sparse --emit_pudc_b_pullup --fn_in top.fasm --bit_out top.bit` . So there are two paths: the `--db-root` and the `--part-file`. The problem is that the `--db-root` seems to be used both | 12:59 |
| sf-slack | to look up `package_pins.csv` for the given part, but also for all these other 400+ files that I'm not sure what they are (descriptions of FPGA sub-parts?) that I don't want to change or distribute. | 12:59 |
| sf-slack | <gergo> Might be worth opening a Github issue_ | 13:00 |
| sf-slack | <kgugala> sure, it'll be easier to discuss there | 13:40 |
| lkcl | folks hi we have encountered a segfault in vpr when using the version provided by the conda install | 13:45 |
| lkcl | http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-October/003847.html | 13:45 |
| tpb | Title: [Libre-soc-dev] LibreSOC Implementation on arty7 fpga dev boards. (at lists.libre-soc.org) | 13:45 |
| lkcl | this is for the upcoming OpenPOWER course initiative so will have 500+ students using it some time within the next 2-3 weeks | 13:46 |
| lkcl | (no pressure, then :) ) | 13:46 |
| lkcl | i advised varun to join #symbiflow in order to get some feedback on how to triage the segfault. | 13:47 |
| lkcl | we need to use a specific checkout version of yosys so he has adapted the standard symbiflow conda install to include that | 13:48 |
| lkcl | other than that one detail it is exactly the same conda install as published in the docs | 13:49 |
| lkcl | Segmentation fault (core dumped) vpr ${ARCH_DEF} ${EBLIF} --device | 13:50 |
| lkcl | ${DEVICE_NAME} ${VPR_OPTIONS} --read_rr_graph ${RR_GRAPH} | 13:50 |
| sf-slack | <gergo> https://github.com/SymbiFlow/symbiflow-xc-fasm/issues/16 for anyone interested | 13:51 |
| lkcl | Varun is a PhD student and a user of symbiflow. | 13:52 |
| lkcl | what instructions can he be given that would allow him to provide you with the required information to triage and reproduce this error? | 13:52 |
| lkcl | everyone involved in the development of the OpenPOWER Educational Course to be run across multiple Universities in India in 10 days time are volunteers | 13:57 |
| lkcl | unfortunately therefore we can't provide a budget or a contract to pay anyone to fix this, for which i must apologise. | 13:57 |
| lkcl | we have to rely instead on your goodwill and the common interest of ensuring that open source tools are reliable and functional for a wide range of projects | 13:59 |
| lkcl | this particular one being high-profile (500+ students) Academic and Educational purposes. | 14:00 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 14:30 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 14:30 | |
| *** Veera <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 20:41 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!