Thursday, 2019-05-09

*** tpb has joined #symbiflow00:00
hackerfooI guess "disconnected" is really VCC or ground, anyway.00:01
litghosthackerfoo: No neccesarily :/00:01
litghosthackerfoo: Ah!00:02
litghosthackerfoo: For muxes internal to the SLICE, there is no way to turn them off00:02
litghosthackerfoo: That is not generally true for outputs from the SLICE00:02
hackerfooAt least, you can't have multiple drivers, where it would be useful to have a high impedance state?00:02
tpbTitle: prjxray-db/segbits_clbll_l.db at master · SymbiFlow/prjxray-db · GitHub (at
litghosthackerfoo: In that case, each output of the mux asserts something, so the absence of a mux selection is valid, in which case no FASM feature is written, and the output of the mux is likely supressed00:03
litghosthackerfoo: In terms of internal muxes, they are selecting from one of many inputs, assuming we used "valid" bit patterns, there will not be multiple drivers00:04
litghosthackerfoo: routing muxes are more "exciting"00:04
*** hzeller_ has joined #symbiflow00:37
*** hzeller_ has quit IRC01:06
*** hzeller_ has joined #symbiflow01:07
*** futarisIRCcloud has quit IRC01:44
*** hzeller_ has quit IRC02:00
*** futarisIRCcloud has joined #symbiflow02:07
*** hzeller_ has joined #symbiflow02:11
*** Bertl_oO is now known as Bertl_zZ03:33
*** jevinskie has joined #symbiflow05:54
sf-slack2<mkurc> @mithro I am working on "adding fasm support to the muxgen". But it is actually more complicated than that.06:10
sf-slack2<mkurc> @mithro A generated mux does not require fasm features as it is a blackbox which we directly instantiate.06:11
*** proteusguy has quit IRC06:30
sf-slack2<mkurc> @mithro We rather require support for generating 'mux' in 'interconnect' with fasm features.06:32
*** hzeller_ has quit IRC07:06
*** jevinskie has quit IRC07:12
*** OmniMancer has joined #symbiflow07:14
*** jevinskie has joined #symbiflow07:14
*** kraiskil_ has joined #symbiflow07:30
*** celadon_ has quit IRC09:16
*** celadon has joined #symbiflow09:25
*** celadon_ has joined #symbiflow09:35
*** celadon has quit IRC09:36
*** Bertl_zZ is now known as Bertl09:46
*** Vonter has quit IRC10:25
*** Vonter has joined #symbiflow10:26
*** kraiskil_ has quit IRC10:29
*** futarisIRCcloud has quit IRC10:47
*** kraiskil_ has joined #symbiflow11:18
*** celadon_ has quit IRC13:08
*** celadon has joined #symbiflow13:09
*** kraiskil__ has joined #symbiflow13:26
*** kraiskil_ has quit IRC13:29
*** proteusguy has joined #symbiflow14:09
*** hzeller_ has joined #symbiflow14:24
*** hzeller_ has quit IRC14:34
*** Bertl is now known as Bertl_oO14:49
litghostMux gen can generate both logic and routing muxs14:52
mithromkurc: litghost is correct15:00
mithromkurc: Do you have an example of what you think needs to be solved?15:00
*** hzeller_ has joined #symbiflow15:05
*** kraiskil__ has quit IRC15:10
*** hzeller_ has quit IRC15:30
*** hzeller_ has joined #symbiflow15:49
*** kraiskil__ has joined #symbiflow16:15
*** hzeller_ has quit IRC16:18
*** hzeller_ has joined #symbiflow16:22
*** hzeller_ has quit IRC17:02
*** jevinskie has quit IRC17:34
sf-slack2<mkurc> @mitho @litghost I created a document describing my proposal for V2X routing muxes:
tpbTitle: Google Docs - create and edit documents online, for free. (at
sf-slack2<mkurc> There is an example of verilog code and resulting pb_type.xml inside17:49
*** OmniMancer has quit IRC17:55
litghostmkurc: I'm very confused, I believe mithro is work on the routing muxes,
tpbTitle: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at
elmsmithro: digshadow: I'm looking at running again. I already have started running some locally. Any pointers on setting it up for regular automated runs in the cloud?18:11
tpbTitle: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at
digshadowelms: TBH the biggest issue was that it was a pain to get all of the tools licensed18:12
digshadowI made a token effort at trending type stuff, but I don't think it was really finished18:13
elmsdigshadow: ok I remember some discussion and thought that's sort of where it was left.18:15
*** jevinskie has joined #symbiflow18:15
elmsI think I'll try running all non-licensed and then start with licensed less often locally. The results for those shouldn't really change.18:16
sf-slack2<kgugala> @litghost: as @mkurc started working on the muxgen stuff @mithro wanted him to contribute to the #70318:16
mithrokgugala: Hrm?18:18
digshadowmithro: shared a gdoc with you about state of 2064 development. If at least the IOB bitstream question looks good I'll send that to ken for comment18:18
mithrodigshadow: Mind if I put it in the SymbiFlow shared public folder?18:19
sf-slack2<kgugala> @mithro maybe I got wrong impression? You pinged as here yesterday and later @mkurc in the issue18:19
mithrokgugala: I send @mkurc an FYI that I was working on the routing mux FASM stuff18:20
sf-slack2<kgugala> Ah18:20
sf-slack2<kgugala> So can we help with it?18:21
sf-slack2<kgugala> Or you want to finish it yourself?18:21
mithrokgugala: I'm going to finish it off today18:21
litghostI believe mkurc had started on the FASM feature and FASM prefix stuff, and I was requesting additional design documentation on that18:21
litghostmkurc also had a little bit on the FASM LUT annotations18:22
sf-slack2<kgugala> @mithro: great18:22
mithroI was under the impression that mkurc was working on *other* FASM attribute stuff18:22
digshadowmithro: sure move it as you wish18:22
digshadowand I will delete mine if needed18:22
digshadowi'll stop editing18:23
sf-slack2<mkurc> I took task related to FASM support to V2X. And support for "fasm_mux" in interconnects was there. And i made a proposal how I see the solution.18:24
litghostmkurc: FYI, I do like the shape of your FASM_MUX solution18:27
litghostmkurc: However I do think there was some confusion that mithro was going to tackle that particular annotation18:28
mithroFYI -
tpbTitle: Use v2x for XML generation Milestone · GitHub (at
sf-slack2<mkurc> @litghost Thanks18:30
sf-slack2<mkurc> @mithro @litghost BTW I answered your comments in #68518:31
sf-slack2<mkurc> I am concerned about the solution proposed in #703. It requires having a pb_type with only `<interconnect>/<mux>` inside (no child pb_types). It is not clearly stated in the VPR doc but according to @acomodi findings this is illegal.18:36
sf-slack2<mkurc> If a pb_type does not have child pb_types then it is concidered as a leaf and cannot have the <interconnect> inside.18:36
litghostmkurc: I believe this is legal, but it generates warnings.  Example:
tpbTitle: symbiflow-arch-defs/slicem.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** hzeller_ has joined #symbiflow18:51
sf-slack2<mkurc> @litghost Interesting. If it is legal than we can proceed with approach in #70318:56
*** hzeller_ has quit IRC18:57
*** kraiskil__ has quit IRC19:26
*** kraiskil__ has joined #symbiflow19:53
*** _whitelogger has quit IRC20:26
*** _whitelogger has joined #symbiflow20:28
mithrolitghost / mkurc: Yes it is legal but not great, I'm just adding some code to v2x to "lower" routing muxes into the pb_type interconnect for now20:43
litghostmithro: Sounds good to me20:44
*** tmichalak has joined #symbiflow21:00
hackerfooIs there any interest in the XC7 block RAM FIFO modes?
tpbTitle: Implement block RAM FIFO{18,36}E1 primitives · Issue #709 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** futarisIRCcloud has joined #symbiflow21:14
*** kraiskil__ has quit IRC22:20
hackerfoolitghost: Do you think it would make sense to break the block RAMs in half the way we did with DPRAM32? There are two symetrical halves that only share the memory array.22:23
litghosthackerfoo: I don't think so.  The routing graph actually treats them seperately22:24
litghosthackerfoo: You'd have to prove that the routing graph is the same for each black box22:24
litghosthackerfoo: Which would be exciting22:24
hackerfoolitghost: Okay. Maybe I'll think about that later.22:25
digshadowmithro: ken added comments to the XC2064 doc. So basically 1) IOB is incomplete 2) no bitstream to verilog support, although some (partial?) work was done on bitstream to netlist 3) no XC2018 support from ken23:27
digshadowwhich roughly matches my expectations23:27
mithrodigshadow: Guess I was dreaming23:32
mithrodigshadow: Ahh yeah - maybe it was bitstream to netlist (rather than bitstream to verilog)23:32
mithromight be worth poking cr1901_modern in ##openfpga23:33
hackerfooI'm curious: why the XC2064? Because it's simple?23:34
mithrohackerfoo: Yeah23:34
mithroIt's also real hardware23:34
hackerfooIt *was* real hardware.23:35
hackerfooAlthough I see you can still get them, but not through DigiKey.23:35
*** Bertl_oO is now known as Bertl_zZ23:43
hackerfooIs there a test that infers dist. RAM? I want to test inferring RAM32X1D.23:53
hackerfooOtherwise I'll write a quick ram_shifter test.23:54
litghostI want to say both murax and picosoc prefer RAM32X1D over RAM64X1D due to their register sizes23:54
hackerfooThanks, I'll try it.23:55

Generated by 2.13.1 by Marius Gedminas - find it at!