Wednesday, 2019-05-29

*** tpb has joined #symbiflow00:00
mithrolitghost: It looks like there are changes to the fasm tool which hasn't been sent upstream to vtr?00:08
litghostmithro: 3 I believe now.  The router changes, hackerfoo's parameter change and your pointer fix00:09
mithrolitghost: I don't see any upstream pull requests for them?00:10
litghostmithro: I was waiting till the decision was made for genfasm sub-stuff00:10
mithrolitghost: genfasm sub-stuff?00:10
mithrolitghost: Oh you mean OWNERs00:11
litghostmithro: I forgot what it was called00:11
mithroI would just send it00:11
mithrolitghost: Did you see that one of the fasm unittests is failing?00:50
tpbTitle: Travis CI - Test and Deploy with Confidence (at
mithrolitghost: also
tpbTitle: Run unit tests in Travis CI · Issue #610 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrolitghost: Should I look at it?00:52
litghostmithro: Feel free00:52
tpbTitle: Snippet | IRCCloud (at
mithrolitghost: Should they have that newline?00:54
litghostYes, ish00:54
litghostThe answer is yes00:54
litghost should have the newline00:54
litghostThe better answer is, the newline doesn't matter, so the test simply behaving like a change detector00:54
*** ZipCPU has joined #symbiflow01:13
*** space_zealot has joined #symbiflow01:17
*** proteusguy has quit IRC01:39
*** citypw has joined #symbiflow04:18
*** citypw has joined #symbiflow04:19
mithrohackerfoo: When you get a moment, can you look at ?04:22
tpbTitle: xc7: Use the common_slice definition when LUTRAM used as a LUT. by mithro · Pull Request #779 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** vitamin-q[m] has quit IRC04:44
*** synaption[m] has quit IRC04:45
*** mrhat2010[m] has quit IRC04:45
*** nrossi has quit IRC04:45
*** xobs has quit IRC04:45
*** alexhw[m] has quit IRC04:45
*** zeigren has quit IRC04:45
*** xobs has joined #symbiflow04:53
*** proteusguy has joined #symbiflow05:20
*** alexhw[m] has joined #symbiflow05:22
*** nrossi has joined #symbiflow05:22
*** synaption[m] has joined #symbiflow05:22
*** vitamin-q[m] has joined #symbiflow05:22
*** zeigren has joined #symbiflow05:22
*** mrhat2010[m] has joined #symbiflow05:22
*** proteusguy has quit IRC05:27
*** proteusguy has joined #symbiflow05:56
*** OmniMancer has joined #symbiflow07:11
*** lopsided98 has quit IRC08:31
*** lopsided98 has joined #symbiflow08:33
*** Bertl_zZ is now known as Bertl08:35
*** proteusguy has quit IRC09:28
*** space_zealot has quit IRC12:38
*** futarisIRCcloud has joined #symbiflow13:03
*** space_zealot has joined #symbiflow13:14
sf-slack2<acomodi> litghost: I am dealing with the non-consecutive ptc. I have applied the changes here
tpbTitle: WIP: rr_graph_reader: allow non-consecutive ptc by acomodi · Pull Request #64 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
sf-slack2<acomodi> litghost: I still need to find all the locations where I need to have a check whether the inode is valid or not14:49
sf-slack2<acomodi> litghost: I have removed the dummy_tracks from the `` script and tested if now the routing reading happens correctly and it does.14:50
sf-slack2<acomodi> litghost: the issue is that now router loops infinitely and the Overused RR nodes increase at each iteration14:50
sf-slack2<mkurc> @litghost: I filed an issue to the VPR regarding modelling of async S/R flip-flops:
tpbTitle: Problem defining a FF with async reset with timings · Issue #617 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
sf-slack2<mkurc> @litghost And I got an answer which from my understanding means that such logic is currently not supported.15:22
sf-slack2<mkurc> @litghost The functionality of such a FF does not correspond to any timing model shown in the examples:
sf-slack2<mkurc> @litghost I think that what we need is a cell model which has FFs on D and CE inputs but the output Q depends on those FFs plus on the CLR (combinationaly)15:27
sf-slack2<mkurc> @litghost We need something like that:
tpbTitle: Pasteboard - Uploaded Image (at
*** futarisIRCcloud has quit IRC15:32
*** OmniMancer has quit IRC16:22
litghostOne way to model that might be to emit two black boxes17:11
litghostHave the combitorial path from SR to Q in the second black box, and SR to CLK in the first second black box17:12
litghostJust an idea off the top of my head, unclear if that would actually work17:12
*** Bertl is now known as Bertl_oO17:14
*** bjorkintosh has quit IRC19:12
*** bjorkintosh has joined #symbiflow20:24
*** bjorkintosh has quit IRC20:39
sf-slack2<kgugala> @mithro we really need the latest database to get green CI on this one
tpbTitle: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrokgugala: Okay, will look at that this afternoon21:00
sf-slack2<kgugala> awesome, thanks21:00
*** Bertl_oO is now known as Bertl_zZ21:13
hackerfooI found this to descramble parallel make output:
tpbTitle: GNU make: Parallel Output (at
sf-slack2<kgugala> this is really cool21:35
mithrohackerfoo: Already tried that previously it doesn't really work in our system21:57
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfoomithro: --output-sync=recurse also doesn't work? On local builds it seems to be better, at least.22:00
mithrohackerfoo: I think the issue is that it ends up with no output until the command finishes22:44
*** space_zealot has quit IRC23:12
hackerfooInterleaving 36k bits seems to be a lot of work for Yosys.23:29
litghosthackerfoo: Like its slow?23:29
litghosthackerfoo: Or just hard to do?23:29
hackerfoolitghost: It's been running for a while now.23:35
litghosthackerfoo: Any chance you made an infinite loop?23:35
litghosthackerfoo: I'd bet on an infinite loop over Yosys being super slow, but who knows23:35
* hackerfoo sent a long message: < >23:46
hackerfoolitghost: ^ I don't think so?23:47
litghosthackerfoo: Depends on the width of i, but I assume it's a 32-bit int23:47
litghosthackerfoo: Might be worth making a little example and profile it23:48
litghosthackerfoo: something like interleave 1k, 2k, 4k, etc23:48
mithrohackerfoo: I think you want i to be an integer rather than a 1 bit width register?23:48
litghosthackerfoo: Oh, also you problably want to be using generate for and genvar?23:49
hackerfooCan't generate in a function.23:49
litghosthackerfoo: Does it work without the function as a generate statement?23:50
litghosthackerfoo: Working is better than pretty23:50
litghosthackerfoo: Anyways, I think @mithro has the right idea, reg by itself isn't wide enough23:50
litghosthackerfoo: So you did make an infinite loop23:51
hackerfooSure. I'll keeping trying stuff until I find something that works.23:51
mithrohackerfoo: I 1bit register will never get bigger than 1, not matter how much you want it too :-P23:51
hackerfooI was trying to use a 7-level macro, but couldn't figure that out.23:51
mithroI would think a generate statement would just work in this case?23:52
hackerfoogood catch litghost , but now it just seems to crash.23:52
litghostWell crashing is a yosys bug you can file :)23:52
hackerfoomithro: Depends on how much voltage you apply.23:52
litghostOr do you mean generating an error23:52
hackerfooI can't find the error, at least.23:53
litghosthackerfoo: I recommend a nice small reproducible case, and create an issue upstream once you've narrowed it23:58

Generated by 2.13.1 by Marius Gedminas - find it at!