14:09 <duck2> hello

14:09 <sf-slack> <kgugala> hello duck2

14:12 <duck2> I'm interested in at least doing the groundwork for supporting spartan6, since the chip is found everywhere

14:13 <duck2> even in my electronics box

14:14 <duck2> wanted to ask how big of a bite is this before i start digging UGs

15:09 <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: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:22 <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:22 <tpb> Title: Issues · SymbiFlow/prjxray · GitHub (at github.com)

15:32 <sf-slack> <mkurc> I have a question about tile connection definition in prjxray database (file 'tileconn.db'). Do these rules specify connection directions ?

15:33 <sf-slack> <mkurc> In other words: Are these two definitions equivalent https://pastebin.com/Sn4ZTJH8 ?

15:33 <tpb> Title: { "grid_deltas": [0,+1], "tile_types": ["TILE_A", "TILE_B"], "wire_pairs": - Pastebin.com (at pastebin.com)

15:34 <sf-slack> <mkurc> I meant the "tileconn.json" file (not "tileconn.db")

15:35 <litghost> mkurc: Yes those are equivalent

15:35 <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:44 <sf-slack> <mkurc> @litghost I just want to be sure that I understand data structures that I'am working on.

15:44 <litghost> mkurc: But why would that involve tileconn? The connections from tileconn are the same.

15:45 <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:48 <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:49 <litghost> mkurc: Redefining the grid in the VPR sense. E.g. a VPR specific grid

15:49 <litghost> mkurc: Leave the files in prjxray-db alone

15:54 <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:55 <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.

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:05 <tpb> Title: symbiflow-arch-defs/synth.tcl at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

19:06 <mithro> elms: Hrm, not sure - why?

19:06 <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:07 <elms> mithro: just thought you might know the impact of abc pass running twice

19:08 <mithro> elms: abc run twice gives you a small improvement?

19:09 <daveshah> I've seen times when it has slightly increased design size too

19:09 <daveshah> Normally it's a small improvement

19:09 <elms> ok I'll leave it.

19:10 <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:11 <daveshah> That was intended to improve netname preservation

19:12 <daveshah> There is a chance of some less conventional netnames as a result of how they are recovered

19:15 <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:15 <daveshah> I see

19:15 <daveshah> I'm interested where the ? came from

19:16 <daveshah> If it came from abc, then abc would have written it to a blif file

19:16 <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:20 <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:20 <elms> daveshah: does that suggest one of the other?

19:21 <daveshah> That appears to have come from Yosys

19:21 <elms> verilog: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/ice40/tests/iceram/iceram.v

19:21 <tpb> Title: symbiflow-arch-defs/iceram.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

19:32 <aroder> Hey

21:09 <sorear> duck2: there are I think three people already doing s6, it’s a crowded field

21:20 <Bertl_oO> Greetings!

21:20 <Bertl_oO> mithro suggested to come here ...

21:21 <Bertl_oO> I wondering what's necessary to get a prjxray database for the xc7z020clg400 used in the 7020 MicroZed

21:24 <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:24 <tpb> Title: prjxray/zynq7.sh at master · SymbiFlow/prjxray · GitHub (at github.com)

21:25 <litghost> Bertl_oO: We haven't been testing with that part, so it may break, but I expect most things will work.

21:26 <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:27 <Bertl_oO> okay, no problem, what run time should I expect?

21:29 <litghost> Bertl_oO: At N=96, ~90 minutes assuming nothing fails. Scale that time roughly with N.

21:30 <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:31 <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:31 <Bertl_oO> okay, no problem, tx

21:37 <mithro> litghost: IIRC the newer vivado make it much harder to use one of the muxes in the fuzzers

22:19 <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:19 <tpb> Title: Apply prjxray ideas to document the bitstream for Spartan 6 parts · Issue #10 · SymbiFlow/ideas · GitHub (at github.com)

22:30 <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:30 <tpb> Title: [link] Bitstream generation for xc6slx9 (spartan 6) - could be incorporated / extended? : yosys (at www.reddit.com)

22:36 <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:46 <mithro> duck2: It seems better use of your time to contribute to the S7 stuff and I send you some S7 hardware though.....

23:31 <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:40 <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:40 <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:41 <litghost> mithro: Probably. I took the example from libarch and added the metadata.