OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
citypw has quit [Ping timeout: 250 seconds]
_whitelogger has joined #symbiflow
Bertl_zZ is now known as Bertl
sxpert has quit [Ping timeout: 252 seconds]
Bertl is now known as Bertl_oO
i8hantanu has joined #symbiflow
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 252 seconds]
proteusguy has joined #symbiflow
<sf-slack1>
<mkurc> Tile grid split update: We are now able to use 3/4 of all available carry chains. I've had to disable SLICEM CC since it is broken now. All remaining chains for SLICELs are ok. Also the `--round_robin_prepacking` option in VPR is broken on master+wip branch (there is a PR with a fix). The option is mandatory for the VPR to use all the chains.
citypw has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
proteusguy has quit [Ping timeout: 252 seconds]
<sf-slack1>
<acomodi> picosoc update: 50MHz correctly builds and is not correctly working on HW: leds are switching on and off at a very high frequency (visible only with the oscilloscope) and UART is printing a lot of garbage (I have set the correct value of the prescaler to match the 50MHz working frequency)
<sf-slack1>
<mkurc> Tile grid split update: Despite the fact that we can utilize 3/4 carry chains the picosoc now refuses to pack. The VPR says that there is not enough resources.
<litghost>
acomodi: Sounds like metastability, e.g. timing violations
<sf-slack1>
<acomodi> litghost: yes indeed, for now I guess we can count on the 25MHz until we have timing information
<litghost>
acomodi: I've merged both of your PR's, starting a conda package rebuild now
<sf-slack1>
<acomodi> litghost: ok, for the picosoc to work though there is the need of a new harness and also to disable ramb36 in yosys `bram.txt` techmap
<sf-slack1>
<mkurc> yeah, I've also stumbled upon RAMB36 which is enabled in latest master+wip Yosys
<mithro>
Morning
<mithro>
mkur: Regarding the split, there are actually two goals with doing the split
<sf-slack1>
<mkurc> Morning
<mithro>
mkurc: A goal with the split was to remove the need for the round-robin carry chain option
<sf-slack1>
<mkurc> That would require unified tile type of SLICEL and SLICEM. I don't know how to do it yet
<mithro>
mkurc: Yes
<litghost>
mkurc: The "unified" tile type is simple the site SLICEL and SLICEM
<litghost>
mkurc: We understand how to map wires from the site to the tile
<litghost>
mkurc: We "just" have to unwrap the routing
<sf-slack1>
<mkurc> I understand
<sf-slack1>
<mkurc> Right now what I did was everything without the unwrapping.
<sf-slack1>
<mkurc> I've gained more knowledge how things are defined and connected and now I can move on to it
<sf-slack1>
<acomodi> mithro, @mkurc: I think that round robin is still needed to switch from slicem and slicel tile types
<litghost>
acomodi: Yes and no, the plan is to replace the round robin strategy with the equivilant tile strategy
<mithro>
acomodi: As any SLICEM can be a SLICEL, once the equivalent types exist then everything getting packed into SLICELs becomes fine
<litghost>
acomodi: The key here is that equivalant tiles solves a broad class of problem present in VPR, like IOB equivance
<litghost>
acomodi: It also gives greater power to the placer, rather than hampering it
<sf-slack1>
<acomodi> litghost, mithro: ok, now I get it. Basically being SLICEMs an "extension" of SLICELs we can see all of them as SLICELs. Having a unified tile type for the SLICEs we are not going to constrain the packer and placer to the deal with specific SLICEs. Does this make sense?
<litghost>
acomodi: Not quiet. SLICEM is a super set of SLICEL. The packer will always pack into the smallest type, and the placer will then have the option to target both SLICEL and SLICEM tiles.
<litghost>
acomodi: So the packer will see both SLICEM and SLICEL, and pick SLICEL if it only needs SLICEL
<litghost>
acomodi: The placer will then understand that some tiles can support a SLICEL or a SLICEM and some tiles only support SLICEL
<sf-slack1>
<acomodi> litghost: Ok, thanks for the explanation. Just a question then, carry chains can be both in SLICEMs and SLICELs. As far as I understood packer will prefer SLICELs over SLICEMs, therefore SLICEMs will never be used for carry chains, is this right?
<litghost>
acomodi: Not exactly correct
<litghost>
acomodi: In most cases, you are are right
<litghost>
acomodi: However there are probably some structures that would use a SLICEM and carry chain at the same time
<litghost>
acomodi: The SLICEM can do both shift register operations and DRAM
<litghost>
acomodi: I don't have a pen and pencil, but I imagine certain operations could leverage both the shift register and carry chain, or the DRAM and carry chain
<sf-slack1>
<acomodi> litghost: Ok, so in that case SLICEMs will be selected by the packer. I am just thinking to corner cases for which there is no need to use SLICEMs, and all the SLICELs are consumed to implement carrychains and the placer will return an error because no more resources are available, even though SLICEMs could be used. could this situation happen?
<litghost>
acomodi: Once the placer understands tile equivilance, not
<litghost>
acomodi: The placer should consume SLICEMs as well
<sf-slack1>
<acomodi> litghost: perfect, all clear now. Thanks
<mithro>
acomodi: The placer might end up placing a SLICEL at a SLICEM site if it improves timing as well
citypw has quit [Ping timeout: 240 seconds]
<sf-slack1>
<acomodi> mithro: Ok, makes sense, provided that there will be timing information available. BTW I am attacking the SLICEM carry chain issue once again since picosoc has been verified to be working at 25MHz
<mithro>
acomodi: What is the SLICEM carry chain issue?
<mithro>
acomodi: Were you able to make a little test arch which demonstrates the issue?
<sf-slack1>
<acomodi> mithro: well, to demonstrate the issue I have just used the `chain_prepacking` test in `xc7/tests`. Right now the issue is not there anymore since all second slices have been disabled and SLICEMs are not selected by the packer
<sf-slack1>
<acomodi> mithro: but no, I have been using the whole architecture to do so. should I use a smaller arch and add it to `testarch`?
sxpert has joined #symbiflow
<mithro>
acomodi: If this seems like a problem that might crop up a lot, it would be good to have a low level test for it
i8hantanu has quit [Quit: Connection closed for inactivity]
<tpb>
Title: Verilog to Routing (VtR / VPR) - Carry Chain + Pack Patterns - Google Drawings (at docs.google.com)
<sf-slack1>
<acomodi> mithro: No, I haven't, but it can be useful, thanks
<sf-slack1>
<acomodi> mithro: anyway, for now this `modes` issue regarded only SLICEMs. I do not know yet if the issue with the mode is specific to this particular case or it could crop up for other cases.
<sf-slack1>
<acomodi> mithro: for now I think I'll solve the issue using the whole architecture and the `chain_prepacking` test. Once I understand what causes this issue I will try to generalize it and replicate it on a `testarch`, if it makes sense.
<mithro>
Is someone working on the equivalent placement types stuff at the moment?
<mithro>
kgugala: BTW What is the status of the clang-format stuff?
<sf-slack1>
<kgugala> mithro: I think it's ready for PR
<mithro>
kgugala: Do we have an example of changes it formatting will make somewhere?
<sf-slack1>
<kgugala> beside clang-format rule we had to add a python script to handle the comments
<mithro>
litghost: Smaller than expected, not small in general
<litghost>
Sure
<mithro>
litghost: I think the sqlite idea kind of makes some sense
<litghost>
mithro: Ya. I had started it back in December, but never finished it. It's probably time to dust it off, between the timing import, the tile split and the trying to get VPR to actually route quickly on our graphs
<litghost>
mithro: Something about our graphs is breaking a new VPR feature for high fan out nets, kem_ indicated it could be a problem with the location information in the graph
<litghost>
mithro: This may help with that, TBD
Miyu has joined #symbiflow
<mithro>
litghost: I wonder if it makes sense to use sqlalchemy rather than sqlite directly?
<litghost>
mithro: I'd have to take a look.
<litghost>
mithro: Step one is to get the thing to work at all.
<litghost>
mithro: Still debugging teething problems
<litghost>
mithro: But I think it's really close
<litghost>
mithro: I also chose sqlite3 because it is built into python3 directly
<mithro>
litghost: We already have non-directly included Python deps, so I wouldn't worry to much about that
<mithro>
litghost: I'm not particularly fond of your formatting around those sql queries and some of them are pretty complicated....
<litghost>
mithro: I'm also warying of adding "magic". The performance of certain queries is actually extremely important. If sqlalchemy can improve those queries great, but the general critism I hear from ORMs is that at some point you have to drop back into SQL to make them performant again
<litghost>
mithro: Are you talking about the use of "?" or inline in general?
<mithro>
litghost: Just the choice around wrapping choices inside the strings which contain the sql
<litghost>
I'm open to a standard SQL formatting to conform too
<mithro>
litghost: I have had good experience with sqlalchemy but I'm not sure it necessarily adds much value when we only care about one backend....
<litghost>
mithro: I only chose sqlite3 because it seems to fit our needs (no server, file oriented)
<mithro>
litghost: Yeah, I think sqlite3 makes the most sense here
<mithro>
> shows a Critical Path Delay (CPD) of 6 billion seconds.
<mithro>
:-P
<litghost>
:)
<mithro>
litghost: I'm thought we did values of 0 previously and something failed which is how we ended up with 1?
<litghost>
mithro: Unclear, that issue was on testarch
<litghost>
mithro: Do want to choose a couple SQL examples and add a comment with a new proposed syntax?
<mithro>
litghost: Okay, will do that in an hour or two, have to run away now
<litghost>
k
somlo has quit [Remote host closed the connection]