Monday, 2019-03-04

*** tpb has joined #symbiflow00:00
*** proteusguy has joined #symbiflow01:34
*** proteusguy has quit IRC01:56
*** citypw has joined #symbiflow03:03
*** OmniMancer has joined #symbiflow05:49
*** OmniMancer has quit IRC08:39
*** OmniMancer has joined #symbiflow08:40
*** celadon has quit IRC09:04
*** celadon has joined #symbiflow09:09
*** celadon has quit IRC09:31
*** citypw has quit IRC09:54
*** celadon has joined #symbiflow11:45
*** lopsided98 has quit IRC11:49
*** lopsided98 has joined #symbiflow11:50
*** duck2 has joined #symbiflow14:11
sf-slack<kgugala> hello duck214:17
*** OmniMancer has quit IRC14:19
duck2I'm interested in at least doing the groundwork for supporting spartan6, since the chip is found everywhere14:20
duck2even in my electronics box14:20
duck2wanted to ask how big of a bite is this before i start digging UGs14:22
*** duck2_ has joined #symbiflow14:39
*** duck2 has quit IRC14:42
*** citypw has joined #symbiflow14:48
*** duck2_ has quit IRC15: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 #symbiflow15:21
litghostduck2: 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
litghosttmichalak: The current IOB fuzzer is good enough for, but we still need to document the differential signalling standards.  However I think can hold off for now15:30
tpbTitle: Issues · SymbiFlow/prjxray · GitHub (at
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 ?15:40
tpbTitle: { "grid_deltas": [0,+1], "tile_types": ["TILE_A", "TILE_B"], "wire_pairs": - (at
sf-slack<mkurc> I meant the "tileconn.json" file (not "tileconn.db")15:41
litghostmkurc: Yes those are equivalent15:43
litghostmkurc: 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
litghostmkurc: But why would that involve tileconn?  The connections from tileconn are the same.15:52
litghostmkurc: 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 #symbiflow15: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 `` script.15:55
litghostmkurc: Redefining the grid in the VPR sense.  E.g. a VPR specific grid15:56
litghostmkurc: Leave the files in prjxray-db alone15: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 #symbiflow16:14
*** citypw has quit IRC16:48
litghostmkurc: 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 IRC19:05
elmsmithro: Do you know if we should be passing -noabc here
tpbTitle: symbiflow-arch-defs/synth.tcl at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithroelms: Hrm, not sure - why?19:13
elmsI 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 oversight19:13
elmsmithro: just thought you might know the impact of abc pass running twice19:14
mithroelms: abc run twice gives you a small improvement?19:15
daveshahI've seen times when it has slightly increased design size too19:16
daveshahNormally it's a small improvement19:16
elmsok I'll leave it.19:17
elmsdaveshah: the change that exposed the vpr blif parsing is actually adding "-dress" in Can you give me a quick idea of that change?19:18
daveshahThat was intended to improve netname preservation19:19
daveshahThere is a chance of some less conventional netnames as a result of how they are recovered19:19
elmsdaveshah: 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 grammar19:22
daveshahI see19:23
daveshahI'm interested where the ? came from19:23
daveshahIf it came from abc, then abc would have written it to a blif file19:23
daveshahIf it's a Yosys internal name, it wouldn't have been passed to ABC but could be preserved for reasons other than -dress19:24
elms`.names m1.cnt[1] m1.cnt[0] $abc$1762$abc$764$techmap$auto$$16.$xor$?techmap.v?:263$75_Y[1]`19:27
elmsdaveshah: does that suggest one of the other?19:28
daveshahThat appears to have come from Yosys19:28
tpbTitle: symbiflow-arch-defs/iceram.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** aroder has joined #symbiflow19:39
*** aroder has quit IRC19:41
sorearduck2: there are I think three people already doing s6, it’s a crowded field21:17
*** Bertl_oO has joined #symbiflow21:27
Bertl_oOmithro suggested to come here ...21:28
*** xobs has quit IRC21:28
Bertl_oOI wondering what's necessary to get a prjxray database for the xc7z020clg400 used in the 7020 MicroZed21:29
*** xobs has joined #symbiflow21:29
litghostBertl_oO: Modify with your part, and then run all fuzzers per the README21:32
tpbTitle: prjxray/ at master · SymbiFlow/prjxray · GitHub (at
litghostBertl_oO: We haven't been testing with that part, so it may break, but I expect most things will work.21:32
litghostBertl_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 resident21:34
Bertl_oOokay, no problem, what run time should I expect?21:35
litghostBertl_oO: At N=96, ~90 minutes assuming nothing fails.  Scale that time roughly with N.21:37
Bertl_oOthe 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
litghostBertl_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_oOokay, no problem, tx21:38
mithrolitghost: IIRC the newer vivado make it much harder to use one of the muxes in the fuzzers21:44
*** proteusguy has joined #symbiflow21:53
duck2sorear: i see. at first sight i thought it was not crowded since and look empty. i also found about which targets xc6slx9 but isn't documented or integrated with anything.22:26
tpbTitle: Apply prjxray ideas to document the bitstream for Spartan 6 parts · Issue #10 · SymbiFlow/ideas · GitHub (at
duck2as 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 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 us22:37
tpbTitle: [link] Bitstream generation for xc6slx9 (spartan 6) - could be incorporated / extended? : yosys (at
mithroduck2: Nobody has put forth an actual plan for Spartan 6 stuff yet -- the bitstream is useless without all the other parts of the toolchain22:44
mithroduck2: 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 IRC22:58
*** kc8apf has joined #symbiflow23:07
sorearduck2: i just poked the last person I've seen working on s6 (mwk in ##openfpga) and he wants to talk to you23:39
mithrolitghost: Could the arch example in be a bit simpler?23:48
tpbTitle: Add metadata support to architecture and rr_graph XML. by litghost · Pull Request #473 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostmithro: Probably.  I took the example from libarch and added the metadata.23:48

Generated by 2.13.1 by Marius Gedminas - find it at!