Thursday, 2019-02-28

*** tpb has joined #symbiflow00:00
*** proteusguy has quit IRC02:50
*** citypw has joined #symbiflow03:21
*** asd123_ has joined #symbiflow05:19
*** asd123_ has quit IRC05:28
*** xvilka has joined #symbiflow05:37
*** OmniMancer has joined #symbiflow06:08
*** citypw has quit IRC10:13
sf-slack<acomodi> So, regarding the BRKH_INT issue, I think that there should be a fuzzer as there are some pips included in them11:27
*** proteusguy has joined #symbiflow11:37
sf-slack<kgugala> From what I see there are 14 PIPs there and they are used to route the signals between clock regions11:56
sf-slack<kgugala> so if those are used in our case we're running outside the ROI11:57
*** asdf1234 has joined #symbiflow12:15
*** asdf1234 has left #symbiflow12:21
*** apurvanandan has joined #symbiflow12:22
apurvanandanI would like to know that can I contribute to your orgnisation in GSoC, if I have experience with Verilog/VHDL but little experience of working of EDA tools?12:24
sf-slack<mgielda> Hi! Great! Please take a look at the ideas list and look for topics that fit your skill set and interests. Doing what you like is key to a successful application12:44
sf-slack<mgielda> You actually just need to know how to program and understand the concepts to realise many of them, but we don't expect people to have lots of prior experience with exactly this12:50
sf-slack<mgielda> the ideas list12:50
tpbTitle: Issues · SymbiFlow/ideas · GitHub (at
sf-slack<acomodi> litghost, @kgugala: I have checked the routing graph with the graphics tool. There are quite a lot wires going out of the ROI for what regards picosoc. Therefore, the BRKH issue popped up14:36
*** OmniMancer has quit IRC14:45
*** kraiskil has joined #symbiflow14:55
*** citypw has joined #symbiflow14:56
*** apurvanandan has quit IRC15:37
*** kraiskil has quit IRC15:43
litghostacomodi: Two options.  One is to the explicitly remove all pips out side of the ROI15:47
litghostacomodi: Other is to check whether the BRKH pips are real or not15:47
litghostvia a minitest or fuzzer15:47
litghostIf the pips are real, then we need a fuzzer.  If the pips are ppips, then add BRKH to the ppips fuzzer15:49
litghostFYI, the ppips fuzzer is for pips that are either always one or implicit.  In generally we've seen most pips that are inline line the pips in the BRKH are ppips not real ones15:50
sf-slack<acomodi> @litghost: I think that the first one is the fastest and can be used for the short term. The second has to be done for sure because it will be needed when we go out of the ROI15:50
* litghost acomodi:
sf-slack<acomodi> Yeah, I agree, I have seen those BRKH PIPs and they should be ppips15:51
sf-slack<mkurc> Good time of day. I've been thinking about the mithro's concept about adding a `<tile_type>` instead of a top-level `<pb_type>` to the VPR. I've been through the VPR code and narrowed down the problem down to making the clustering step operate at second level pb_types (childs of the root pb_type). Can anybody provide me with some insights is it the right way to do it?16:14
sf-slack<kgugala> this will be hard to do16:14
sf-slack<kgugala> if you look at the way the packer searches for the root block you'll see it does that recursively16:15
sf-slack<kgugala> so you never know how many steps are left16:16
sf-slack<kgugala> moreover it always compares the root type of the cluster with a root type of a chain root pin16:16
sf-slack<kgugala> and because of the pin you'll never know which slice you're considering16:17
litghostmkurc: The proposal I heard the other day was to leave the clusterer alone16:17
litghostmkurc: And change the placer to understand that a tile can map to one or more pb_types16:17
sf-slack<kgugala> @litghost: I agree16:18
sf-slack<kgugala> this is the way to go16:18
litghostmkurc: So the slice_m pb_type is a super set of the slice_l pb_type, so the placer would be able to take a slice_l cluster and put it on a slice_m tile16:18
litghostmkurc: This is assuming we've done the tile split16:18
litghostmkurc: I also chatter with the  VPR devs, and they indicated your idea of splitting the tile at the grid level and leaving the routing graph (e.g. channel definitions) would work16:19
sf-slack<mkurc> Ok then, I'll look into the placer starting from tomorrow.16:32
litghostmkurc: Before that, we probably need to split the tiles?16:39
litghostmkurc: That way once the placer is updated, we have a good test case?  It would also be find to construct a test architecture to test the feature16:39
litghostmkurc: Split the CLB tiles into two slices16:40
*** kraiskil has joined #symbiflow16:41
sf-slack<acomodi> litghost: would it be ok just to reduce the Y_MAX from the ROI from 52 (which includes the BRKH tiles) to 51?16:58
*** citypw has quit IRC17:00
litghostacomodi: Should be fine.17:04
*** celadon has quit IRC17:12
elmslitghost: have you had the case that you needed to emit a feature if for a counter case? eg emit feature IO.Disable if that IO pad is not used18:19
litghostelms: To date, no.  That is something that likely need to be handled in a post VPR fixup phase18:20
litghostelms: If we add active IO FASM annotations, it should be a straight forward fixup18:20
litghostelms: I'd recommend handling it in the FASM to asc phase18:21
litghostmkurc: Regression in murax was due to enabling RAM32X1D,
tpbTitle: RAM32X1D not working · Issue #409 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostmkurc: I'm gonna disable yosys RAM32X1D synthesis for now.  I never tested RAM32X1D, so it is not super uprising there was a bug.18:23
sf-slack<acomodi> litghost: murax is built til the end and does not work on HW or it does not reach the end of the compilation?18:25
sf-slack<acomodi> Because I had tested all the dram_tests and there were two of them that did present a weird (probably wrong) behavior on HW18:26
litghostacomodi: Fails on hardware.  Like I said, I never tested RAM32X1D.  I only tested RAM64X1D.18:26
litghostacomodi: This wasn't a problem before, because yosys would never emit a RAM32X1D until
tpbTitle: Moved techmaps from Yosys to SymbiFlow by mkurc-ant · Pull Request #8 · SymbiFlow/yosys · GitHub (at
sf-slack<acomodi> Ok, got it, I had previously seen that 32X1D was not working and there is also another configuration which is not working on HW. It is reported in this PR
tpbTitle: d_dram.pb_type: update xml definition to solve slicem issue by acomodi · Pull Request #402 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostacomodi: The other mode you reported not working is 32X1 DRAM mode.  So I suspect there is some bug in either the FASM or pb_type for the 32 wide DRAMs.  There is actually never a reason to use a RAM32X1D over a RAM64X1D, as the consume the same number of resources18:32
litghostacomodi: 32X2S or 32X2D is a useful mode, so we should eventually debug it, but I don't think it's a priority.18:33
sf-slack<acomodi> litghost: right, I guess for now it's ok just to disable it from Yosys as you said. We need to file a ticket and get back to it later on18:35
litghostacomodi: Already filed:
tpbTitle: RAM32X1D not working · Issue #409 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostand PR is, just waiting for green from CI18:36
sf-slack<acomodi> Great, BTW the picosoc run I have launched earlier is about to finish, probably it could present the same issue with the DRAM32x1d, but other than that it should produce a bit file18:39
sf-slack<acomodi> If that happens I'll test it on HW tomorrow18:40
litghostacomodi: It will almost certainly fail, unless there are no RAM32X1D, which is possible18:40
sf-slack<acomodi> Yep, tomorrow I'll test again. Anyways I got a bitstream for picosoc finally, just finished18:45
elmslitghost: when we want to add more complex IO modes for ice40, there will be other complicated cases. As of now the other IO are just driven to constant 0 output. Are you also thinking a post stage is also when hard IP blocks would be handled?18:56
litghostelms: Are you implying that unused ice40 IO drive output?  That doesn't make sense.  They should be tristated?18:58
elmsIs no bits in the IO tile are set I think so.18:58
litghostelms: Not sure I understand.  If no bits are set in the ice40 bitstream, are the outputs tristated?18:59
elmsI haven't confirmed, but it does seem like the default high-z there should be some bits set18:59
litghostelms: So part of the FASM specification is the idea of a "default" bitstream, which is the set of bits if no features are enabled.  I believe tristating outputs should be part of that "default" set.  If a feature wants to enable an IO, it would clear the high-z bit.19:00
litghostelms: Can that work?19:00
elmsI think it would require diverging from icestorm nomenclature which I want to be as close to as possible.19:03
elmslitghost: Are you saying the feature would be affirmative as in IO.Enable which would clear a bit, eg "!1_20" or something?19:04
litghostelms: Yes.19:06
litghostelms: IMO, an empty FASM file should generate a bitstream that does "nothing", e.g. is safe to load on any design.19:07
litghostelms: Having an empty FASM file drive outputs on every  output  pin of an ice40 is a recipe for disaster19:08
elmsThe advanced cases are also going to cause some issues. Features are mutually exclusive right? Also I haven't found the specifics, but apparently there are times that IO bits are in other IO tiles19:08
litghostelms: Example?  Features do not have to be mutually exclusive, but they cannot request a bit be cleared and set19:09
elmslitghost: agreed. But I think there is a sensible way to handle that in the fasm to bitstream19:09
litghostelms: This is ignoring bits set in the "default" bitstream19:09
litghostelms: I am also saying handle it in the fasm to bitstream layer.  I'm saying logically handling it in the fasm to bitstream layer is equivilant to what I am describing above, e.g. setting a feature will clear a bit.19:12
elmslitghost: re mutual exclusive, two features can't be set that set the state of a specific bit. Can both of these be enabled?19:15
elmsfeature1 0_0 0_219:15
elmsfeature2 0_0 0_319:15
litghostelms: That's perfect fine.  Setting a bit in multiple features is legal.  Disagreement about the bit is an error.19:15
elmsDo you have an existing example of a default bitstream for existing fasm?19:17
litghostelms: No, because to date 7-series a zero bitstream is acceptable.  However it shouldn't be too hard.  Just have a set of default bits, that can be cleared by the FASM bits.19:18
litghostelms: Because compile the FASM feature to bits, check for conflicts within the FASM bits, and then have the FASM bits override the default bits19:19
litghostelms: You should be able to declare the "default" bitstream using FASM features (e.g. tristate), but you'll need to book keep the default bits from the FASM bits to not raise a conflict19:20
litghostelms: Should be straight forward19:20
elmslitghost: I would like to keep the features using icestorm nomenclature if possible. That said the default stream would have some bits set which would correspond to features being set. It doesn't seem reconcilable. So maybe I should have a method to denote the contra case in a somewhat standard way.19:21
litghostelms: By contra case, you mean a feature that is "not tristate"?19:22
elmslitghost: Hmm so I can keep the same features but add some negated features as well.19:22
litghostelms: Of course19:23
litghostelms: We do that with zero bit groups in prjxray19:23
elmslitghost: can you point me to that?19:23
litghostelms: To be clear, negated features are no-ops.  But negated bits are doable19:23
litghostelms: Do you want an example of the zero bit group, or zero bit features?19:24
litghost is a zero bit features (e.g. this feature requires those 3 bits to be cleared)19:24
tpbTitle: prjxray-db/segbits_bram_l.db at master · SymbiFlow/prjxray-db · GitHub (at
elmsI guess I was thinking "enable 0_0" "disable !0_0"19:24
litghostelms: That is fine in FASM parlance.  As long as the input FASM file doesn't specify both features19:25
elmslitghost: ok. I'll do that and see if that gives a safe empty fasm bitstream.19:27
elmslitghost: I've also been back and forth about where the fasm2asc code should live. If I follow prjxray it should live in icestorm, but depending on the fasm python package may require some more justification. The other option is to have it live in arch-defs and we still generate an asc file for icestorm.19:28
litghostelms: I think having it in arch-defs is fine for now.  icestorm itself doesn't use it.  prjxray actually uses the FASM stuff as part of ROI generation.19:29
elmslitghost: sounds good. that's what I was leaning toward.19:30
*** abhyuday has joined #symbiflow20:28
*** abhyuday has quit IRC20:31
elmslitghost: I thought I needed to wait to merge until I saw a new vpr . Is that not where the new build would show up?20:37
tpbTitle: Remove tile level fasm_prefix by elmsfu · Pull Request #407 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostelms: I tested murax with and it was fine20:41
tpbTitle: Remove tile level fasm_prefix by elmsfu · Pull Request #407 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostelms: So I went ahead and merged it20:42
litghostelms: Actually I guess I do have the latest VPR :/20:42
elmslitghost: was that a local build of vpr? I'm not sure the anaconda build of vpr has20:42
*** kraiskil has quit IRC20:42
litghostelms: Ya, local20:42
elmsI just looked and saw there is a bump file in the anaconda repo20:43
elmswhat's up with that
tpbTitle: conda-packages/.bump at master · SymbiFlow/conda-packages · GitHub (at
litghostelms: Writing to the .bump file causes travis to rebuild and deploy the packages20:44
elmshmm ok20:45
elmslitghost: not sure why PR 407 didn't generate a travis build for arch-defs. That should have failed.20:46
litghostGood question, it was green when I merged20:46
litghostAh, no 7-series stuff is being tested on travis, only on kokoro20:46
litghostAnd I don't think the kokoro CI is wired in?20:46
elmslitghost: another fasm/ice40 corner case. a parameter is integer type, but only 2 bits are used. Should I add ability to map eblif param bit range in fasm_params ? or is there a better solution?20:51
litghostelms: Bit ranges are supports?  Just specify the slice you are interested in?20:51
elmson the eblif side?20:51
elmseg fasm_INIT[1:0] = eblif_init[3:2]20:52
litghostelms: In general if parameter munging is required, I've been doing it in synthesis as a techmap20:52
elmslitghost: example?20:52
litghostelms: Yosys is fairly powerful, and I'd rather not put too much into genfasm if we can avoid it20:52
litghostinversion - >
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghoststring to bit ->
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostenum mapping ->
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostelms: In this case I'm open to expanding the genfasm ability, but I think I prefer to keep as much of the munging in a yosys techmap rather than code in VPR20:54
elmslitghost: exactly why I'm asking :)20:55
litghostelms: If you don't mind doing it via techmap, I think that is the cleaner solution20:57
litghostelms: I think Yosys can do any parameter munging we could need, where-as genfasm would need to eventually gain more and more capabilities if we added eblif side manipulation21:00
elmssounds good. I'd like to be consistent across archs as well. There are going to be a lot of permutations, test coverage for all this will be interesting (thinks of future self)21:02
litghostelms: What do you mean by "lots of permutations"?  I lack context for this issue21:03
elmslitghost: maybe permutations isn't right, but there are a lot of modules to make sure are behaving correctly eventually on hardware21:06
litghostelms: Sure.  I hope there are test fixtures for various tiles.  I've been building that up for 7-series as I've gone along21:07
litghostelms: E.g a FF test, a LUT test, a DRAM test, BRAM tests, etc21:08
elmslitghost: there are some tests, but not great coverage for all the combinations of latching and inverted clocks, etc.21:27

Generated by 2.13.1 by Marius Gedminas - find it at!