| *** tpb has joined #symbiflow | 00:00 | |
| *** citypw has joined #symbiflow | 03:44 | |
| *** Bertl is now known as Bertl_zZ | 04:23 | |
| *** proteusguy has quit IRC | 04:33 | |
| *** somlo has quit IRC | 04:34 | |
| *** somlo has joined #symbiflow | 05:01 | |
| *** OmniMancer has joined #symbiflow | 05:32 | |
| *** citypw has quit IRC | 07:01 | |
| *** citypw has joined #symbiflow | 07:15 | |
| *** OmniMancer has quit IRC | 08:14 | |
| *** OmniMancer has joined #symbiflow | 08:16 | |
| *** citypw has quit IRC | 10:15 | |
| *** _whitelogger has quit IRC | 10:19 | |
| *** _whitelogger has joined #symbiflow | 10:22 | |
| *** Bertl_zZ is now known as Bertl | 11:56 | |
| *** sxpert has quit IRC | 12:26 | |
| *** Bertl is now known as Bertl_oO | 12:44 | |
| *** i8hantanu has joined #symbiflow | 13:37 | |
| *** proteusguy has joined #symbiflow | 13:50 | |
| *** proteusguy has quit IRC | 14:20 | |
| *** proteusguy has joined #symbiflow | 14:30 | |
| 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. | 14:32 |
|---|---|---|
| *** citypw has joined #symbiflow | 14:34 | |
| *** OmniMancer has quit IRC | 14:59 | |
| *** proteusguy has quit IRC | 15:02 | |
| 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) | 15:26 |
| 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. | 15:31 |
| litghost | acomodi: Sounds like metastability, e.g. timing violations | 15:37 |
| sf-slack1 | <acomodi> litghost: yes indeed, for now I guess we can count on the 25MHz until we have timing information | 15:38 |
| litghost | acomodi: I've merged both of your PR's, starting a conda package rebuild now | 15:39 |
| 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 | 15:42 |
| sf-slack1 | <mkurc> yeah, I've also stumbled upon RAMB36 which is enabled in latest master+wip Yosys | 15:42 |
| mithro | Morning | 16:03 |
| mithro | mkur: Regarding the split, there are actually two goals with doing the split | 16:04 |
| sf-slack1 | <mkurc> Morning | 16:05 |
| mithro | mkurc: A goal with the split was to remove the need for the round-robin carry chain option | 16:07 |
| sf-slack1 | <mkurc> That would require unified tile type of SLICEL and SLICEM. I don't know how to do it yet | 16:09 |
| mithro | mkurc: Yes | 16:09 |
| litghost | mkurc: The "unified" tile type is simple the site SLICEL and SLICEM | 16:10 |
| litghost | mkurc: We understand how to map wires from the site to the tile | 16:10 |
| litghost | mkurc: We "just" have to unwrap the routing | 16:10 |
| sf-slack1 | <mkurc> I understand | 16:10 |
| sf-slack1 | <mkurc> Right now what I did was everything without the unwrapping. | 16:11 |
| sf-slack1 | <mkurc> I've gained more knowledge how things are defined and connected and now I can move on to it | 16:12 |
| sf-slack1 | <acomodi> mithro, @mkurc: I think that round robin is still needed to switch from slicem and slicel tile types | 16:12 |
| litghost | acomodi: Yes and no, the plan is to replace the round robin strategy with the equivilant tile strategy | 16:13 |
| mithro | acomodi: As any SLICEM can be a SLICEL, once the equivalent types exist then everything getting packed into SLICELs becomes fine | 16:13 |
| litghost | https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/17 | 16:14 |
| tpb | Title: Implement equivalent tile types support · Issue #17 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 16:14 |
| litghost | acomodi: The key here is that equivalant tiles solves a broad class of problem present in VPR, like IOB equivance | 16:14 |
| litghost | acomodi: It also gives greater power to the placer, rather than hampering it | 16:15 |
| 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? | 16:18 |
| 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. | 16:19 |
| litghost | acomodi: So the packer will see both SLICEM and SLICEL, and pick SLICEL if it only needs SLICEL | 16:19 |
| litghost | acomodi: The placer will then understand that some tiles can support a SLICEL or a SLICEM and some tiles only support SLICEL | 16:20 |
| litghost | acomodi: https://github.com/SymbiFlow/yosys/pull/16/files | 16:23 |
| tpb | Title: Temporarily disable RAMB36 synthesis. by litghost · Pull Request #16 · SymbiFlow/yosys · GitHub (at github.com) | 16:23 |
| 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? | 16:26 |
| litghost | acomodi: Not exactly correct | 16:26 |
| litghost | acomodi: In most cases, you are are right | 16:26 |
| litghost | acomodi: However there are probably some structures that would use a SLICEM and carry chain at the same time | 16:27 |
| litghost | acomodi: The SLICEM can do both shift register operations and DRAM | 16:27 |
| 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 | 16:28 |
| 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? | 16:30 |
| litghost | acomodi: Once the placer understands tile equivilance, not | 16:30 |
| litghost | acomodi: The placer should consume SLICEMs as well | 16:30 |
| sf-slack1 | <acomodi> litghost: perfect, all clear now. Thanks | 16:31 |
| mithro | acomodi: The placer might end up placing a SLICEL at a SLICEM site if it improves timing as well | 16:32 |
| *** citypw has quit IRC | 16:33 | |
| 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 | 16:37 |
| mithro | acomodi: What is the SLICEM carry chain issue? | 16:37 |
| sf-slack1 | <acomodi> mithro: the one about the `modes` which I have dropped to focus on the picosoc. https://github.com/SymbiFlow/symbiflow-arch-defs/issues/372 | 16:38 |
| tpb | Title: VTR cannot pack slicem.carrychain · Issue #372 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 16:38 |
| mithro | acomodi: Were you able to make a little test arch which demonstrates the issue? | 16:39 |
| 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 | 16:43 |
| 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`? | 16:45 |
| *** sxpert has joined #symbiflow | 16:45 | |
| 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 | 16:46 |
| *** i8hantanu has quit IRC | 16:47 | |
| mithro | acomodi: Have you seen https://docs.google.com/drawings/d/1qREImoaUjWDSsnbimDu-Mig3_M9hTr-6q-zbPd2VPEM/edit | 16:50 |
| tpb | Title: Verilog to Routing (VtR / VPR) - Carry Chain + Pack Patterns - Google Drawings (at docs.google.com) | 16:50 |
| sf-slack1 | <acomodi> mithro: No, I haven't, but it can be useful, thanks | 16:54 |
| 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. | 16:56 |
| 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. | 16:59 |
| mithro | Is someone working on the equivalent placement types stuff at the moment? | 17:06 |
| mithro | kgugala: BTW What is the status of the clang-format stuff? | 17:35 |
| sf-slack1 | <kgugala> mithro: I think it's ready for PR | 17:37 |
| mithro | kgugala: Do we have an example of changes it formatting will make somewhere? | 17:37 |
| sf-slack1 | <kgugala> beside clang-format rule we had to add a python script to handle the comments | 17:37 |
| sf-slack1 | <kgugala> the commit is here: | 17:37 |
| sf-slack1 | <kgugala> https://github.com/kgugala/vtr-verilog-to-routing/commit/3adc9fd28924d81497df8cdddabb07e8c99d043b | 17:37 |
| tpb | Title: vpr: Add make target for source code formatting · kgugala/vtr-verilog-to-routing@3adc9fd · GitHub (at github.com) | 17:37 |
| sf-slack1 | <kgugala> I can run the formatting and push it to a branch | 17:38 |
| mithro | kgugala: please do | 17:38 |
| mithro | Where should I be putting comments? | 17:38 |
| sf-slack1 | <kgugala> mithro: here are the format results https://github.com/kgugala/vtr-verilog-to-routing/tree/code-format-result | 17:43 |
| tpb | Title: GitHub - kgugala/vtr-verilog-to-routing at code-format-result (at github.com) | 17:43 |
| sf-slack1 | <kgugala> you can open an issue in my fork | 17:43 |
| mithro | kgugala: Okay, so we also need to land the rule into the libs/EXTERNAL/ projects separately | 17:46 |
| mithro | kgugala: I'm kind of surprised at how small the change ends up being... | 17:47 |
| sf-slack1 | <kgugala> The same rule for all libs/EXTERNAL? | 17:49 |
| mithro | kgugala: most of the libs/EXTERNAL are owned by vtr developers I believe | 17:49 |
| mithro | (well not libcatch or libpugixml) | 17:50 |
| mithro | But libsdcparse, libblifparse and libtantum I think? | 17:50 |
| litghost | mithro: Changing 228 files and a total of 40k lines is small to you? | 18:01 |
| litghost | Request for comment on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445 | 18:01 |
| tpb | Title: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 18:01 |
| mithro | litghost: Smaller than expected, not small in general | 18:02 |
| litghost | Sure | 18:02 |
| mithro | litghost: I think the sqlite idea kind of makes some sense | 18:04 |
| 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 | 18:05 |
| 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 | 18:06 |
| litghost | mithro: This may help with that, TBD | 18:06 |
| *** Miyu has joined #symbiflow | 18:09 | |
| mithro | litghost: I wonder if it makes sense to use sqlalchemy rather than sqlite directly? | 18:09 |
| litghost | mithro: I'd have to take a look. | 18:09 |
| litghost | mithro: Step one is to get the thing to work at all. | 18:09 |
| litghost | mithro: Still debugging teething problems | 18:10 |
| litghost | mithro: But I think it's really close | 18:10 |
| litghost | mithro: I also chose sqlite3 because it is built into python3 directly | 18:11 |
| mithro | litghost: We already have non-directly included Python deps, so I wouldn't worry to much about that | 18:13 |
| mithro | litghost: I'm not particularly fond of your formatting around those sql queries and some of them are pretty complicated.... | 18:14 |
| 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 | 18:14 |
| litghost | mithro: Are you talking about the use of "?" or inline in general? | 18:14 |
| mithro | litghost: Just the choice around wrapping choices inside the strings which contain the sql | 18:15 |
| litghost | I'm open to a standard SQL formatting to conform too | 18:16 |
| 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.... | 18:17 |
| litghost | mithro: I only chose sqlite3 because it seems to fit our needs (no server, file oriented) | 18:18 |
| mithro | litghost: Yeah, I think sqlite3 makes the most sense here | 18:18 |
| mithro | > shows a Critical Path Delay (CPD) of 6 billion seconds. | 18:21 |
| mithro | :-P | 18:21 |
| litghost | :) | 18:21 |
| mithro | litghost: I'm thought we did values of 0 previously and something failed which is how we ended up with 1? | 18:22 |
| litghost | mithro: Unclear, that issue was on testarch | 18:22 |
| litghost | mithro: Do want to choose a couple SQL examples and add a comment with a new proposed syntax? | 18:30 |
| mithro | litghost: Okay, will do that in an hour or two, have to run away now | 18:31 |
| litghost | k | 18:31 |
| *** somlo has quit IRC | 20:14 | |
| *** somlo has joined #symbiflow | 20:17 | |
| *** somlo has quit IRC | 20:37 | |
| mithro | litghost: This is my suggested wrapping -> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445/files#diff-7f1b8c30132d9771af24e70f3ed0aabc | 23:24 |
| tpb | Title: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:24 |
| litghost | Basically lots more white space | 23:26 |
| litghost | You are missing some useful indentation though, but I think I can adapt the style | 23:26 |
| litghost | mithro: I'm not so sure about https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445/commits/2be55bdb5ba8910e229853c6342761aa2ab1c019 | 23:27 |
| tpb | Title: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:27 |
| litghost | mithro: Seems too far | 23:27 |
| litghost | SELECT x FROM y WHERE z is pretty common construct | 23:28 |
| litghost | I agree once you start getting into multiple joins and the like, it has to be broken up | 23:28 |
| mithro | litghost: If you could fit it on one line, I'd be okay with (SELECT x FROM y WHERE z) | 23:29 |
| litghost | Any thoughts about just using http://www.dpriver.com/pp/sqlformat.htm ? | 23:30 |
| tpb | Title: Instant SQL Formatter (at www.dpriver.com) | 23:30 |
| litghost | Defaults seem pretty good | 23:30 |
| mithro | litghost: It seems to uppercase NAME | 23:33 |
| litghost | That's probably fixable | 23:33 |
| litghost | https://pypi.org/project/format-sql/ | 23:33 |
| tpb | Title: format-sql · PyPI (at pypi.org) | 23:33 |
| mithro | both https://www.freeformatter.com/sql-formatter.html#ad-output and https://codebeautify.org/sqlformatter format things closer to my style... | 23:37 |
| tpb | Title: Free Online SQL Formatter - FreeFormatter.com (at www.freeformatter.com) | 23:37 |
| mithro | Ahh that format-sql formats much closer to my style too... | 23:37 |
| litghost | format-sql takes python files | 23:37 |
| litghost | so we can just add it to the make format | 23:38 |
| litghost | which I like | 23:38 |
| mithro | litghost: I'm happy with that | 23:38 |
| litghost | Me too | 23:39 |
| litghost | auto-formatting == no debate, unless the tool is broken | 23:39 |
| mithro | I'm a little worried the tool won't handle your WITH / AS statements | 23:40 |
| litghost | Actually the "?" was the problem :( | 23:40 |
| mithro | litghost: It kind of looks abandoned too... | 23:42 |
| litghost | Oh, and WITH statements | 23:42 |
| litghost | :( :( :( | 23:42 |
| litghost | Oh well | 23:42 |
| litghost | I'm okay with using https://codebeautify.org/sqlformatter with some c/p | 23:42 |
| tpb | Title: Best SQL Formatter Online (at codebeautify.org) | 23:42 |
| litghost | Not ideal, but better than lots of hand formatting | 23:42 |
| mithro | litghost: I mean we could just fix that package for our needs? | 23:43 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!