<sf-slack>
<acomodi> So, regarding the BRKH_INT issue, I think that there should be a fuzzer as there are some pips included in them
proteusguy has joined #symbiflow
<sf-slack>
<kgugala> From what I see there are 14 PIPs there and they are used to route the signals between clock regions
<sf-slack>
<kgugala> so if those are used in our case we're running outside the ROI
asdf1234 has joined #symbiflow
asdf1234 has left #symbiflow [#symbiflow]
apurvanandan has joined #symbiflow
<apurvanandan>
I 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?
<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 application
<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 this
<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 up
OmniMancer has quit [Quit: Leaving.]
kraiskil has joined #symbiflow
citypw has joined #symbiflow
apurvanandan has quit [Ping timeout: 256 seconds]
kraiskil has quit [Ping timeout: 240 seconds]
<litghost>
acomodi: Two options. One is to the explicitly remove all pips out side of the ROI
<litghost>
acomodi: Other is to check whether the BRKH pips are real or not
<litghost>
via a minitest or fuzzer
<litghost>
If the pips are real, then we need a fuzzer. If the pips are ppips, then add BRKH to the ppips fuzzer
<litghost>
FYI, 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 ones
<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 ROI
<sf-slack>
<acomodi> Yeah, I agree, I have seen those BRKH PIPs and they should be ppips
<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?
<sf-slack>
<kgugala> this will be hard to do
<sf-slack>
<kgugala> if you look at the way the packer searches for the root block you'll see it does that recursively
<sf-slack>
<kgugala> so you never know how many steps are left
<sf-slack>
<kgugala> moreover it always compares the root type of the cluster with a root type of a chain root pin
<sf-slack>
<kgugala> and because of the pin you'll never know which slice you're considering
<litghost>
mkurc: The proposal I heard the other day was to leave the clusterer alone
<litghost>
mkurc: And change the placer to understand that a tile can map to one or more pb_types
<sf-slack>
<kgugala> @litghost: I agree
<sf-slack>
<kgugala> this is the way to go
<litghost>
mkurc: 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 tile
<litghost>
mkurc: This is assuming we've done the tile split
<litghost>
mkurc: 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 work
<sf-slack>
<mkurc> Ok then, I'll look into the placer starting from tomorrow.
<litghost>
mkurc: Before that, we probably need to split the tiles?
<litghost>
mkurc: 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 feature
<litghost>
mkurc: Split the CLB tiles into two slices
kraiskil has joined #symbiflow
<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?
citypw has quit [Ping timeout: 240 seconds]
<litghost>
acomodi: Should be fine.
celadon has quit [Quit: ZNC 1.7.1+deb2+b3 - https://znc.in]
<elms>
litghost: 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 used
<litghost>
elms: To date, no. That is something that likely need to be handled in a post VPR fixup phase
<litghost>
elms: If we add active IO FASM annotations, it should be a straight forward fixup
<litghost>
elms: I'd recommend handling it in the FASM to asc phase
<tpb>
Title: Moved techmaps from Yosys to SymbiFlow by mkurc-ant · Pull Request #8 · SymbiFlow/yosys · GitHub (at github.com)
<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 https://github.com/SymbiFlow/symbiflow-arch-defs/pull/402
<tpb>
Title: d_dram.pb_type: update xml definition to solve slicem issue by acomodi · Pull Request #402 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost>
acomodi: 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 resources
<litghost>
acomodi: 32X2S or 32X2D is a useful mode, so we should eventually debug it, but I don't think it's a priority.
<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 on
<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 file
<sf-slack>
<acomodi> If that happens I'll test it on HW tomorrow
<litghost>
acomodi: It will almost certainly fail, unless there are no RAM32X1D, which is possible
<sf-slack>
<acomodi> Yep, tomorrow I'll test again. Anyways I got a bitstream for picosoc finally, just finished
<litghost>
Yay!
<elms>
litghost: 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?
<litghost>
elms: Are you implying that unused ice40 IO drive output? That doesn't make sense. They should be tristated?
<elms>
Is no bits in the IO tile are set I think so.
<litghost>
elms: Not sure I understand. If no bits are set in the ice40 bitstream, are the outputs tristated?
<elms>
I haven't confirmed, but it does seem like the default high-z there should be some bits set
<litghost>
elms: 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.
<litghost>
elms: Can that work?
<elms>
I think it would require diverging from icestorm nomenclature which I want to be as close to as possible.
<elms>
litghost: Are you saying the feature would be affirmative as in IO.Enable which would clear a bit, eg "!1_20" or something?
<litghost>
elms: Yes.
<litghost>
elms: IMO, an empty FASM file should generate a bitstream that does "nothing", e.g. is safe to load on any design.
<litghost>
elms: Having an empty FASM file drive outputs on every output pin of an ice40 is a recipe for disaster
<elms>
The 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 tiles
<litghost>
elms: Example? Features do not have to be mutually exclusive, but they cannot request a bit be cleared and set
<elms>
litghost: agreed. But I think there is a sensible way to handle that in the fasm to bitstream
<litghost>
elms: This is ignoring bits set in the "default" bitstream
<litghost>
elms: 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.
<elms>
litghost: re mutual exclusive, two features can't be set that set the state of a specific bit. Can both of these be enabled?
<elms>
feature1 0_0 0_2
<elms>
feature2 0_0 0_3
<litghost>
elms: That's perfect fine. Setting a bit in multiple features is legal. Disagreement about the bit is an error.
<elms>
ok
<elms>
Do you have an existing example of a default bitstream for existing fasm?
<litghost>
elms: 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.
<litghost>
elms: Because compile the FASM feature to bits, check for conflicts within the FASM bits, and then have the FASM bits override the default bits
<litghost>
elms: 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 conflict
<litghost>
elms: Should be straight forward
<elms>
litghost: 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.
<litghost>
elms: By contra case, you mean a feature that is "not tristate"?
<elms>
litghost: Hmm so I can keep the same features but add some negated features as well.
<litghost>
elms: Of course
<litghost>
elms: We do that with zero bit groups in prjxray
<elms>
litghost: can you point me to that?
<litghost>
elms: To be clear, negated features are no-ops. But negated bits are doable
<litghost>
elms: Do you want an example of the zero bit group, or zero bit features?
<elms>
I guess I was thinking "enable 0_0" "disable !0_0"
<litghost>
elms: That is fine in FASM parlance. As long as the input FASM file doesn't specify both features
<elms>
litghost: ok. I'll do that and see if that gives a safe empty fasm bitstream.
<elms>
litghost: 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.
<litghost>
elms: 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.
<elms>
litghost: sounds good. that's what I was leaning toward.
<litghost>
elms: Writing to the .bump file causes travis to rebuild and deploy the packages
<elms>
hmm ok
<elms>
litghost: not sure why PR 407 didn't generate a travis build for arch-defs. That should have failed.
<litghost>
Good question, it was green when I merged
<litghost>
Ah, no 7-series stuff is being tested on travis, only on kokoro
<litghost>
And I don't think the kokoro CI is wired in?
<litghost>
Unclear
<elms>
litghost: 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?
<litghost>
elms: Bit ranges are supports? Just specify the slice you are interested in?
<elms>
on the eblif side?
<elms>
eg fasm_INIT[1:0] = eblif_init[3:2]
<litghost>
elms: In general if parameter munging is required, I've been doing it in synthesis as a techmap
<elms>
litghost: example?
<litghost>
elms: Yosys is fairly powerful, and I'd rather not put too much into genfasm if we can avoid it
<litghost>
elms: 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 VPR
<elms>
litghost: exactly why I'm asking :)
<litghost>
elms: If you don't mind doing it via techmap, I think that is the cleaner solution
<litghost>
elms: 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 manipulation
<elms>
sounds 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)
<litghost>
elms: What do you mean by "lots of permutations"? I lack context for this issue
<elms>
litghost: maybe permutations isn't right, but there are a lot of modules to make sure are behaving correctly eventually on hardware
<litghost>
elms: Sure. I hope there are test fixtures for various tiles. I've been building that up for 7-series as I've gone along
<litghost>
elms: E.g a FF test, a LUT test, a DRAM test, BRAM tests, etc
<elms>
litghost: there are some tests, but not great coverage for all the combinations of latching and inverted clocks, etc.