| *** tpb <[email protected]> has joined #symbiflow | 00:00 | |
| tpb | <bl0x_> o/ | 00:05 |
|---|---|---|
| tpb | <sf-slack> <hansfbaier> Hi, | 03:42 |
| tpb | <sf-slack> <hansfbaier> you might find this helpful: https://github.com/kintex-chatter/scratchpad/issues/1 | 03:42 |
| tpb | <sf-slack> <hansfbaier> This is how I did it (would do it for the artix): | 03:43 |
| tpb | <sf-slack> <hansfbaier> 1. Create a blinky for the xc7a50t | 03:43 |
| tpb | <sf-slack> <hansfbaier> 2. Create a blinky for the xc7a75t | 03:43 |
| tpb | <sf-slack> <hansfbaier> 3. Run implementation on both and open the viewers of both | 03:44 |
| tpb | <sf-slack> <hansfbaier> I mean the implementation view. If you zoom close enough, you can see the tile and site numbers of each basic element | 03:44 |
| tpb | <sf-slack> <hansfbaier> Look which region of which site the config file selects in 50t | 03:44 |
| tpb | <sf-slack> <hansfbaier> Then look at the a75t viewer and select the analogous region there | 03:45 |
| tpb | <sf-slack> <abhijeet.astronomy> hi | 04:46 |
| tpb | <nimh> I am following some digilent examples for the arty_35 using symbiflow | 09:12 |
| tpb | <nimh> one of their examples infers a dsp slice | 09:13 |
| tpb | <nimh> I changed symbiflow_synth to point to an updated synth.tcl and removed the -nodsp flags | 09:13 |
| tpb | <nimh> looks like yosys infers the dsp48e1 slices as it's in the synth .v, but then symbiflow_pack (and I guess vpr?) fail with "Message: Failed to find matching architecture model for 'DSP48E1'" | 09:17 |
| tpb | <nimh> I'm using VPR FPGA Placement and Routing. | 09:18 |
| tpb | <nimh> Version: 8.1.0-dev+06317d042 | 09:18 |
| tpb | <nimh> Revision: 8.0.0-4118-g06317d042 | 09:18 |
| tpb | <sf-slack> <acomodi> nimh: DSPs are not currently supported, and they would need to be added to the architecture data in symbiflow-arch-defs | 09:21 |
| tpb | <nimh> any steps I can take to have dsp mapping work? | 09:21 |
| tpb | <nimh> ok - is there some technical reason that hasn't been done, or it just needs someone to do it? | 09:22 |
| tpb | <nimh> and is that something I could do armed with ug479_7Series_DSP48E1.pdf or is it more involved? | 09:22 |
| tpb | <sf-slack> <acomodi> Just needs someone to do it actually, the DSP is already documented in prjxray for bitstream generation, and what is needed is the information for VPR to correctly use it in PnR | 09:24 |
| tpb | <sf-slack> <acomodi> Yeah, that can come in handy, as well as previous PRs that aimed at adding support for missing primitives (e.g. https://github.com/SymbiFlow/symbiflow-arch-defs/pull/2053) | 09:25 |
| tpb | <nimh> acomodi - okay, thanks. I will take a look time permitting. I followed the symbiflow-examples guide for installing things, do I also need to clone symbofilow-arch-defs or is that already done when installing symbiflow-examples? | 09:26 |
| tpb | <sf-slack> <acomodi> nimh: you'd need to clone that as well. Bascially symbiflow-arch-defs generates all the architecture data and routing graphs binaries and uploads them in a bucket, where they are fetched in symbiflow-examples | 09:36 |
| tpb | <nimh> acomodi, right you are, I'll get that underway. I thought I saw some docs somewhere on how to add stuff to VPR? | 09:43 |
| tpb | <nimh> acomodi: - is this what needs to be done for the dsp48e1? https://symbiflow.readthedocs.io/en/latest/toolchain-desc/yosys.html#technology-mapping-in-symbiflow-toolchain | 11:06 |
| tpb | <tpb> Title: Yosys — SymbiFlow (at symbiflow.readthedocs.io) | 11:06 |
| tpb | <nimh> i.e. create the model.xml and pb_type.xml? | 11:06 |
| tpb | <sf-slack> <acomodi> Indeed, this is part of what needs to be done, other than that there would be the addition of the tech mapping to the VPR primitive and the addition of the new pb_type to the cmake infrastructure (much similarly I think as it happens for PR#2053) | 11:09 |
| tpb | <nimh> got it, thanks. | 11:28 |
| tpb | <sf-slack> <acomodi> @marzoul: The ROI concept was initially used to test limited portions of the device, to focus mostly on the basic FPGA elements such as LUTs and FFs first, rather than having to solve the IOs which were a bit more complex to handle. The ROI grid (defined by those variables) was then used to generate a harness, used to drive the IO signals into the ROI grid, and from then on VPR could use synthetic tiles representing | 11:33 |
| tpb | <sf-slack> the IOs, enabling place and route confined in the ROI region only | 11:33 |
| tpb | <sf-slack> <acomodi> Given that this is not needed anymore as IOs are now documented, you should probably be able to leave those variables blank | 11:34 |
| tpb | <marzoul> @sf-slack Thank you for the details | 14:24 |
| tpb | <marzoul> I was thinking my fuzzer005 failure was probably not due to me not setting these variables, this kind of confirms | 14:24 |
| tpb | <marzoul> And another question, about message "Because some devices share the same fabric" | 14:33 |
| tpb | <marzoul> from the guide to add a new part : https://symbiflow.readthedocs.io/projects/prjxray/en/latest/db_dev_process/newpart.html | 14:33 |
| tpb | <marzoul> I don't understand what it means, saying that xc7a35t shares same fabric as xc7a50t | 14:33 |
| tpb | <marzoul> Because... these are 2 different parts with very different amount of logic inside | 14:33 |
| tpb | <tpb> Title: Guide to adding a new device to an existing family — Project X-Ray 0.0-3534-g5349556b documentation (at symbiflow.readthedocs.io) | 14:33 |
| tpb | <nimh> the xc7a50t has the same things inside it as the xc7a35t, just more of it | 14:37 |
| tpb | <tnt> Huh no ...it has the exact same things inside, same amount. | 14:38 |
| tpb | <marzoul> From Xilinx docs : 35t has 5142 slices, 50t has 8200 | 14:39 |
| tpb | <tnt> It's a commercial difference, not a physical one. It's encoded with a jtag ID of 35T and the software will only alow you to use X amount of resources inside of it, but the actual chip die is the same. | 14:39 |
| tpb | <marzoul> wow, quite surprising | 14:40 |
| tpb | <tnt> You can actually see it pretty easily when you look at the size (in bytes) of the configuration bitstream. They're identical for 35T and 50T. | 14:40 |
| tpb | <marzoul> weird that 30% of the device is not usable with the 35t | 14:40 |
| tpb | <marzoul> maybe production yield issues, why not | 14:41 |
| tpb | <nimh> I was wondering why the symbiflow-examples built things for the 50t when given the arty_35 as a target | 14:46 |
| tpb | <nimh> tnt - when you say "the software" which software is that? | 14:47 |
| tpb | <marzoul> I see 2 ways to interpret how DB generation is done : | 14:47 |
| tpb | <marzoul> 1) Generation of DB manages to do its job for 35t, from settings of 50t, and produces a correct DB specialized for 35t | 14:47 |
| tpb | <marzoul> 2) Or no difference at all, and the goal is to actually use the 8200 slices of the chip 35t where vivado would only allow 5142 | 14:47 |
| tpb | <marzoul> Which is correct ? | 14:47 |
| tpb | <marzoul> If the Xilinx-documented number of slices of only 5142 comes from production yield issues, it might not be wise to try to use the 30% of the device supposed to be faulty | 14:49 |
| tpb | <tnt> nimh: vivado. | 15:01 |
| tpb | <tnt> marzoul: no. vivado will use any slice in the fabric and not a fixed subset. It just limits the total. | 15:02 |
| tpb | <tnt> There is nothing new or exceptional about this btw ... other fpga manufacturer do it too and it's fairly common knowledge .... | 15:03 |
| tpb | <tnt> the lattic up3k is the same as the up5k. The ECP5 12F is the same as the 25F, .... | 15:03 |
| tpb | <marzoul> tnt Interesting | 15:07 |
| tpb | <marzoul> So it means that eventually, nextpnr will give more luts than vivado for the 35t | 15:07 |
| tpb | <marzoul> Quite enlightening =D | 15:07 |
| tpb | <marzoul> +60% more slices actually | 15:19 |
| tpb | <bl0x_> tnt: I did not know this, but it makes perfect sense. I've looked online for some more data and found this (oldish) thread: https://www.eevblog.com/forum/microcontrollers/artix-7-only-has-three-different-die-sizes/ This effectively makes routing on the 15T and 35T easier than one would expect when approaching the (artificial) fill level. | 21:46 |
| tpb | <tpb> Title: Artix-7 only has three different die sizes? - Page 1 (at www.eevblog.com) | 21:46 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!