| *** tpb has joined #symbiflow | 00:00 | |
| *** proteusguy has joined #symbiflow | 01:34 | |
| *** proteusguy has quit IRC | 01:56 | |
| *** citypw has joined #symbiflow | 03:03 | |
| *** OmniMancer has joined #symbiflow | 05:49 | |
| *** OmniMancer has quit IRC | 08:39 | |
| *** OmniMancer has joined #symbiflow | 08:40 | |
| *** celadon has quit IRC | 09:04 | |
| *** celadon has joined #symbiflow | 09:09 | |
| *** celadon has quit IRC | 09:31 | |
| *** citypw has quit IRC | 09:54 | |
| *** celadon has joined #symbiflow | 11:45 | |
| *** lopsided98 has quit IRC | 11:49 | |
| *** lopsided98 has joined #symbiflow | 11:50 | |
| *** duck2 has joined #symbiflow | 14:11 | |
| duck2 | hello | 14:16 |
|---|---|---|
| sf-slack | <kgugala> hello duck2 | 14:17 |
| *** OmniMancer has quit IRC | 14:19 | |
| duck2 | I'm interested in at least doing the groundwork for supporting spartan6, since the chip is found everywhere | 14:20 |
| duck2 | even in my electronics box | 14:20 |
| duck2 | wanted to ask how big of a bite is this before i start digging UGs | 14:22 |
| *** duck2_ has joined #symbiflow | 14:39 | |
| *** duck2 has quit IRC | 14:42 | |
| *** citypw has joined #symbiflow | 14:48 | |
| *** duck2_ has quit IRC | 15:11 | |
| sf-slack | <tmichalak> litghost: looking at the latest changes to the IOB fuzzer, what are the things that we are still missing for the documentation of the IOBs to be considered complete? | 15:17 |
| *** duck2 has joined #symbiflow | 15:21 | |
| litghost | duck2: 6-series parts are likely a significant amount of work. Many of the fuzzers are 7-series specific, and may fail in unexpected ways on 6-series. | 15:29 |
| litghost | tmichalak: The current IOB fuzzer is good enough for https://github.com/SymbiFlow/prjxray/issues/684, but we still need to document the differential signalling standards. However I think can hold off for now | 15:30 |
| tpb | Title: Issues · SymbiFlow/prjxray · GitHub (at github.com) | 15:30 |
| sf-slack | <mkurc> I have a question about tile connection definition in prjxray database (file 'tileconn.db'). Do these rules specify connection directions ? | 15:40 |
| sf-slack | <mkurc> In other words: Are these two definitions equivalent https://pastebin.com/Sn4ZTJH8 ? | 15:40 |
| tpb | Title: { "grid_deltas": [0,+1], "tile_types": ["TILE_A", "TILE_B"], "wire_pairs": - Pastebin.com (at pastebin.com) | 15:40 |
| sf-slack | <mkurc> I meant the "tileconn.json" file (not "tileconn.db") | 15:41 |
| litghost | mkurc: Yes those are equivalent | 15:43 |
| litghost | mkurc: Why? | 15:43 |
| sf-slack | <mkurc> @litghost I am working on the conversion from top-level CLBs to top-level SLICEs. After splitting a CLB in the grid i must re-define some connection rules to match the split. | 15:51 |
| sf-slack | <mkurc> @litghost I just want to be sure that I understand data structures that I'am working on. | 15:51 |
| litghost | mkurc: But why would that involve tileconn? The connections from tileconn are the same. | 15:52 |
| litghost | mkurc: The fact that some wires are being split across two tiles for VPR is not something we should change prjxray db output for? | 15:52 |
| *** zzx has joined #symbiflow | 15:54 | |
| sf-slack | <mkurc> I agree. But I'm trying to implement the CLB split by modifying tileconn.json and tilegrid.json. Because as you have mentioned earlier when splitting the grid I need to re-define routing channels. And the easiest way to do it is change input data to the `prjxray_form_channels.py` script. | 15:55 |
| litghost | mkurc: Redefining the grid in the VPR sense. E.g. a VPR specific grid | 15:56 |
| litghost | mkurc: Leave the files in prjxray-db alone | 15:56 |
| sf-slack | <mkurc> I don't want to change the db. I only need to extract data from it for the VPR in a little different way. Since all the `prjxray_*.py` scripts which do that are very tightly coupled with the database structures (tiles) I want to do it by changing input data rather than the way they process it. It is not going to be a permanent change to the db. | 16:01 |
| *** proteusguy has joined #symbiflow | 16:14 | |
| *** citypw has quit IRC | 16:48 | |
| litghost | mkurc: I don't know if I mentioned this, but when I met with the VPR devs I asked about channel definitions and their geometric constraints. VPR has a check for channel to tile connectivity, but it is overly conservative. It is likely okay for the router to not modify the channels too much for the tile split. The VPR devs suggested adding a radius constraint for non-adjency and a flag to control it. | 17:03 |
| *** proteusguy has quit IRC | 19:05 | |
| elms | mithro: Do you know if we should be passing -noabc here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/yosys/synth.tcl#L3 | 19:12 |
| tpb | Title: symbiflow-arch-defs/synth.tcl at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 19:12 |
| mithro | elms: Hrm, not sure - why? | 19:13 |
| elms | I see we call abc explicitly on line 8. The recent yosys changes exposed an issue in vpr that I'll about to push a PR for, but made me wonder if this was an oversight | 19:13 |
| elms | mithro: just thought you might know the impact of abc pass running twice | 19:14 |
| mithro | elms: abc run twice gives you a small improvement? | 19:15 |
| daveshah | I've seen times when it has slightly increased design size too | 19:16 |
| daveshah | Normally it's a small improvement | 19:16 |
| elms | ok I'll leave it. | 19:17 |
| elms | daveshah: the change that exposed the vpr blif parsing is actually adding "-dress" in synth_ice40.cc Can you give me a quick idea of that change? | 19:18 |
| daveshah | That was intended to improve netname preservation | 19:19 |
| daveshah | There is a chance of some less conventional netnames as a result of how they are recovered | 19:19 |
| elms | daveshah: Yeah vpr, had a restricted set that didn't allow '?' in netnames and that popped up. I guess there isn't a true spec that specifies valid grammar | 19:22 |
| daveshah | I see | 19:23 |
| daveshah | I'm interested where the ? came from | 19:23 |
| daveshah | If it came from abc, then abc would have written it to a blif file | 19:23 |
| daveshah | If it's a Yosys internal name, it wouldn't have been passed to ABC but could be preserved for reasons other than -dress | 19:24 |
| elms | `.names m1.cnt[1] m1.cnt[0] $abc$1762$abc$764$techmap$auto$alumacc.cc:474:replace_alu$16.$xor$?techmap.v?:263$75_Y[1]` | 19:27 |
| elms | daveshah: does that suggest one of the other? | 19:28 |
| daveshah | That appears to have come from Yosys | 19:28 |
| elms | verilog: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/tests/iceram/iceram.v | 19:28 |
| tpb | Title: symbiflow-arch-defs/iceram.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 19:28 |
| *** aroder has joined #symbiflow | 19:39 | |
| aroder | Hey | 19:40 |
| *** aroder has quit IRC | 19:41 | |
| sorear | duck2: there are I think three people already doing s6, it’s a crowded field | 21:17 |
| *** Bertl_oO has joined #symbiflow | 21:27 | |
| Bertl_oO | Greetings! | 21:27 |
| Bertl_oO | mithro suggested to come here ... | 21:28 |
| *** xobs has quit IRC | 21:28 | |
| Bertl_oO | I wondering what's necessary to get a prjxray database for the xc7z020clg400 used in the 7020 MicroZed | 21:29 |
| *** xobs has joined #symbiflow | 21:29 | |
| litghost | Bertl_oO: Modify https://github.com/SymbiFlow/prjxray/blob/master/settings/zynq7.sh with your part, and then run all fuzzers per the README | 21:32 |
| tpb | Title: prjxray/zynq7.sh at master · SymbiFlow/prjxray · GitHub (at github.com) | 21:32 |
| litghost | Bertl_oO: We haven't been testing with that part, so it may break, but I expect most things will work. | 21:32 |
| litghost | Bertl_oO: It will take a while to run, add "-j<N> MAX_VIVADO_PROCESS=<N>" to your make string, but unless you have >32 GB, I'd keep N low. At N=56, I can typically hit ~50-60 GB resident | 21:34 |
| Bertl_oO | okay, no problem, what run time should I expect? | 21:35 |
| litghost | Bertl_oO: At N=96, ~90 minutes assuming nothing fails. Scale that time roughly with N. | 21:37 |
| Bertl_oO | the readme says vivado 2017.2, is that the only version which works or is 2017.4 or even 2018.3 fine as well? | 21:37 |
| litghost | Bertl_oO: At this time, only version. It is likely that there is nothing insurmountable about using a newer version, but some of the fuzzers did not operate at new version. | 21:38 |
| Bertl_oO | okay, no problem, tx | 21:38 |
| mithro | litghost: IIRC the newer vivado make it much harder to use one of the muxes in the fuzzers | 21:44 |
| *** proteusguy has joined #symbiflow | 21:53 | |
| duck2 | sorear: i see. at first sight i thought it was not crowded since https://github.com/SymbiFlow/ideas/issues/10 and https://github.com/timvideos/getting-started/issues/45 look empty. i also found about https://github.com/Wolfgang-Spraul/fpgatools which targets xc6slx9 but isn't documented or integrated with anything. | 22:26 |
| tpb | Title: Apply prjxray ideas to document the bitstream for Spartan 6 parts · Issue #10 · SymbiFlow/ideas · GitHub (at github.com) | 22:26 |
| duck2 | as far as i can see, the only thing missing from a s6 flow is the pnr part or an arch-def to pass to vtr or nextpnr. is this right? i found https://www.reddit.com/r/yosys/comments/74kk8i/link_bitstream_generation_for_xc6slx9_spartan_6/ where clifford vienna says spartan6 bitstream is not worth it... however as a uni student, pretty much every FPGA i see around is spartan6(the rest is cycloneIV) so it would be super useful to not us | 22:37 |
| tpb | Title: [link] Bitstream generation for xc6slx9 (spartan 6) - could be incorporated / extended? : yosys (at www.reddit.com) | 22:37 |
| mithro | duck2: Nobody has put forth an actual plan for Spartan 6 stuff yet -- the bitstream is useless without all the other parts of the toolchain | 22:44 |
| mithro | duck2: It seems better use of your time to contribute to the S7 stuff and I send you some S7 hardware though..... | 22:53 |
| *** proteusguy has quit IRC | 22:58 | |
| *** kc8apf has joined #symbiflow | 23:07 | |
| sorear | duck2: i just poked the last person I've seen working on s6 (mwk in ##openfpga) and he wants to talk to you | 23:39 |
| mithro | litghost: Could the arch example in https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/473/files be a bit simpler? | 23:48 |
| tpb | Title: Add metadata support to architecture and rr_graph XML. by litghost · Pull Request #473 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 23:48 |
| litghost | mithro: Probably. I took the example from libarch and added the metadata. | 23:48 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!