Monday, 2022-02-14

*** tpb <[email protected]> has joined #symbiflow00:00
bl0x_o/00:05
*** bl0x_ <bl0x_!~bastii@p200300d7a738c50034438ab600b54555.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 250 seconds)02:42
*** bl0x_ <bl0x_!~bastii@p200300d7a7126c008067f8019810f7a2.dip0.t-ipconnect.de> has joined #symbiflow02:43
sf-slack<hansfbaier> Hi,03:42
sf-slack<hansfbaier> you might find this helpful: https://github.com/kintex-chatter/scratchpad/issues/103:42
sf-slack<hansfbaier> This is how I did it (would do it for the artix):03:43
sf-slack<hansfbaier> 1. Create a blinky for the xc7a50t03:43
sf-slack<hansfbaier> 2. Create a blinky for the xc7a75t03:43
sf-slack<hansfbaier> 3. Run implementation on both and open the viewers of both03:44
sf-slack<hansfbaier> I mean the implementation view. If you zoom close enough, you can see the tile and site numbers of each basic element03:44
sf-slack<hansfbaier> Look which region of which site the config file selects in 50t03:44
sf-slack<hansfbaier> Then look at the a75t viewer and select the analogous region there03:45
*** Luke <Luke!~ldm@hacksoc/member> has quit IRC (Quit: o/ 4w 6d 23h 59m 16s)04:00
*** Luke <Luke!~ldm@hacksoc/member> has joined #symbiflow04:03
*** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Quit: ec)04:32
sf-slack<abhijeet.astronomy> hi04:46
*** tcal <[email protected]> has quit IRC (*.net *.split)05:51
*** marzoul <[email protected]> has quit IRC (*.net *.split)05:51
*** marzoul <[email protected]> has joined #symbiflow05:52
*** tcal <tcal!sid456577@2a03:5180:f:2::6:f781> has joined #symbiflow05:52
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:f8ef:a9df:2427:39ab> has quit IRC (Quit: Leaving)06:13
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:a1f7:d0a2:f5bc:88fc> has joined #symbiflow06:17
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:a1f7:d0a2:f5bc:88fc> has quit IRC (Remote host closed the connection)06:17
*** marzoul <[email protected]> has quit IRC (Ping timeout: 256 seconds)07:48
nimhI am following some digilent examples for the arty_35 using symbiflow09:12
nimhone of their examples infers a dsp slice09:13
nimhI changed symbiflow_synth to point to an updated synth.tcl and removed the -nodsp flags09:13
nimhlooks 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
nimhI'm using VPR FPGA Placement and Routing.09:18
nimhVersion: 8.1.0-dev+06317d04209:18
nimhRevision: 8.0.0-4118-g06317d04209:18
sf-slack<acomodi> nimh: DSPs are not currently supported, and they would need to be added to the architecture data in symbiflow-arch-defs09:21
nimhany steps I can take to have dsp mapping work?09:21
nimhok - is there some technical reason that hasn't been done, or it just needs someone to do it?09:22
nimhand is that something I could do armed with ug479_7Series_DSP48E1.pdf or is it more involved?09:22
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 PnR09:24
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
nimhacomodi - 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
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-examples09:36
nimhacomodi, right you are, I'll get that underway.  I thought I saw some docs somewhere on how to add stuff to VPR?09:43
*** marzoul <[email protected]> has joined #symbiflow10:06
nimhacomodi: - is this what needs to be done for the dsp48e1? https://symbiflow.readthedocs.io/en/latest/toolchain-desc/yosys.html#technology-mapping-in-symbiflow-toolchain11:06
tpbTitle: Yosys — SymbiFlow (at symbiflow.readthedocs.io)11:06
nimhi.e. create the model.xml and pb_type.xml?11:06
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:a1f7:d0a2:f5bc:88fc> has joined #symbiflow11:07
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
nimhgot it, thanks.11:28
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 representing11:33
sf-slackthe IOs, enabling place and route confined in the ROI region only11:33
sf-slack<acomodi> Given that this is not needed anymore as IOs are now documented, you should probably be able to leave those variables blank11:34
*** balrog <balrog!znc@user/balrog> has quit IRC (Quit: Bye)14:09
*** balrog <balrog!znc@user/balrog> has joined #symbiflow14:16
marzoul@sf-slack Thank you for the details14:24
marzoulI was thinking my fuzzer005 failure was probably not due to me not setting these variables, this kind of confirms14:24
marzoulAnd another question, about message "Because some devices share the same fabric"14:33
marzoulfrom the guide to add a new part : https://symbiflow.readthedocs.io/projects/prjxray/en/latest/db_dev_process/newpart.html14:33
marzoulI don't understand what it means, saying that xc7a35t shares same fabric as xc7a50t14:33
marzoulBecause... these are 2 different parts with very different amount of logic inside14:33
tpbTitle: Guide to adding a new device to an existing family — Project X-Ray 0.0-3534-g5349556b documentation (at symbiflow.readthedocs.io)14:33
nimhthe xc7a50t has the same things inside it as the xc7a35t, just more of it14:37
tntHuh no ...it has the exact same things inside, same amount.14:38
marzoulFrom Xilinx docs : 35t has 5142 slices, 50t has 820014:39
tntIt'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
marzoulwow, quite surprising14:40
tntYou 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
marzoulweird that 30% of the device is not usable with the 35t14:40
marzoulmaybe production yield issues, why not14:41
nimhI was wondering why the symbiflow-examples built things for the 50t when given the arty_35 as a target14:46
nimhtnt - when you say "the software" which software is that?14:47
marzoulI see 2 ways to interpret how DB generation is done :14:47
marzoul1) Generation of DB manages to do its job for 35t, from settings of 50t, and produces a correct DB specialized for 35t14:47
marzoul2) Or no difference at all, and the goal is to actually use the 8200 slices of the chip 35t where vivado would only allow 514214:47
marzoulWhich is correct ?14:47
marzoulIf 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 faulty14:49
tntnimh: vivado.15:01
tntmarzoul: no. vivado will use any slice in the fabric and not a fixed subset. It just limits the total.15:02
tntThere is nothing new or exceptional about this btw ... other fpga manufacturer do it too and it's fairly common knowledge ....15:03
tntthe lattic up3k is the same as the up5k. The ECP5 12F is the same as the 25F, ....15:03
marzoultnt Interesting15:07
marzoulSo it means that eventually, nextpnr will give more luts than vivado for the 35t15:07
marzoulQuite enlightening =D15:07
marzoul+60% more slices actually15:19
*** cr1901_ <cr1901_!~cr1901@2601:8d:8600:911:a1f7:d0a2:f5bc:88fc> has joined #symbiflow17:38
*** cr1901 <cr1901!~cr1901@2601:8d:8600:911:a1f7:d0a2:f5bc:88fc> has quit IRC (Ping timeout: 240 seconds)17:41
*** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow18:39
*** marzoul <[email protected]> has quit IRC (Ping timeout: 252 seconds)20:09
*** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (Ping timeout: 260 seconds)20:59
*** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #symbiflow21:11
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
tpbTitle: 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/!