Thursday, 2019-03-07

*** tpb has joined #symbiflow00:00
*** citypw has joined #symbiflow03:44
*** Bertl is now known as Bertl_zZ04:23
*** proteusguy has quit IRC04:33
*** somlo has quit IRC04:34
*** somlo has joined #symbiflow05:01
*** OmniMancer has joined #symbiflow05:32
*** citypw has quit IRC07:01
*** citypw has joined #symbiflow07:15
*** OmniMancer has quit IRC08:14
*** OmniMancer has joined #symbiflow08:16
*** citypw has quit IRC10:15
*** _whitelogger has quit IRC10:19
*** _whitelogger has joined #symbiflow10:22
*** Bertl_zZ is now known as Bertl11:56
*** sxpert has quit IRC12:26
*** Bertl is now known as Bertl_oO12:44
*** i8hantanu has joined #symbiflow13:37
*** proteusguy has joined #symbiflow13:50
*** proteusguy has quit IRC14:20
*** proteusguy has joined #symbiflow14: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 #symbiflow14:34
*** OmniMancer has quit IRC14:59
*** proteusguy has quit IRC15: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
litghostacomodi: Sounds like metastability, e.g. timing violations15:37
sf-slack1<acomodi> litghost: yes indeed, for now I guess we can count on the 25MHz until we have timing information15:38
litghostacomodi: I've merged both of your PR's, starting a conda package rebuild now15: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` techmap15:42
sf-slack1<mkurc> yeah, I've also stumbled upon RAMB36 which is enabled in latest master+wip Yosys15:42
mithroMorning16:03
mithromkur: Regarding the split, there are actually two goals with doing the split16:04
sf-slack1<mkurc> Morning16:05
mithromkurc: A goal with the split was to remove the need for the round-robin carry chain option16:07
sf-slack1<mkurc> That would require unified tile type of SLICEL and SLICEM. I don't know how to do it yet16:09
mithromkurc: Yes16:09
litghostmkurc: The "unified" tile type is simple the site SLICEL and SLICEM16:10
litghostmkurc: We understand how to map wires from the site to the tile16:10
litghostmkurc: We "just" have to unwrap the routing16:10
sf-slack1<mkurc> I understand16: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 it16:12
sf-slack1<acomodi> mithro, @mkurc: I think that round robin is still needed to switch from slicem and slicel tile types16:12
litghostacomodi: Yes and no, the plan is to replace the round robin strategy with the equivilant tile strategy16:13
mithroacomodi: As any SLICEM can be a SLICEL, once the equivalent types exist then everything getting packed into SLICELs becomes fine16:13
litghosthttps://github.com/SymbiFlow/vtr-verilog-to-routing/issues/1716:14
tpbTitle: Implement equivalent tile types support · Issue #17 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)16:14
litghostacomodi: The key here is that equivalant tiles solves a broad class of problem present in VPR, like IOB equivance16:14
litghostacomodi: It also gives greater power to the placer, rather than hampering it16: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
litghostacomodi: 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
litghostacomodi: So the packer will see both SLICEM and SLICEL, and pick SLICEL if it  only needs SLICEL16:19
litghostacomodi: The placer will then understand that some tiles can support a SLICEL or a SLICEM and some tiles only support SLICEL16:20
litghostacomodi: https://github.com/SymbiFlow/yosys/pull/16/files16:23
tpbTitle: 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
litghostacomodi: Not exactly correct16:26
litghostacomodi: In most cases, you are are right16:26
litghostacomodi: However there are probably some structures that would use a SLICEM and carry chain at the same time16:27
litghostacomodi: The SLICEM can do both shift register operations and DRAM16:27
litghostacomodi: 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 chain16: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
litghostacomodi: Once the placer understands tile equivilance, not16:30
litghostacomodi: The placer should consume SLICEMs as well16:30
sf-slack1<acomodi> litghost: perfect, all clear now. Thanks16:31
mithroacomodi: The placer might end up placing a SLICEL at a SLICEM site if it improves timing as well16:32
*** citypw has quit IRC16: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 25MHz16:37
mithroacomodi: 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/37216:38
tpbTitle: VTR cannot pack slicem.carrychain · Issue #372 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)16:38
mithroacomodi: 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 packer16: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 #symbiflow16:45
mithroacomodi: If this seems like a problem that might crop up a lot, it would be good to have a low level test for it16:46
*** i8hantanu has quit IRC16:47
mithroacomodi: Have you seen https://docs.google.com/drawings/d/1qREImoaUjWDSsnbimDu-Mig3_M9hTr-6q-zbPd2VPEM/edit16:50
tpbTitle: 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, thanks16: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
mithroIs someone working on the equivalent placement types stuff at the moment?17:06
mithrokgugala: BTW What is the status of the clang-format stuff?17:35
sf-slack1<kgugala> mithro: I think it's ready for PR17:37
mithrokgugala: 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 comments17:37
sf-slack1<kgugala> the commit is here:17:37
sf-slack1<kgugala> https://github.com/kgugala/vtr-verilog-to-routing/commit/3adc9fd28924d81497df8cdddabb07e8c99d043b17:37
tpbTitle: vpr: Add make target for source code formatting · kgugala/[email protected] · GitHub (at github.com)17:37
sf-slack1<kgugala> I can run the formatting and push it to a branch17:38
mithrokgugala: please do17:38
mithroWhere 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-result17:43
tpbTitle: 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 fork17:43
mithrokgugala: Okay, so we also need to land the rule into the libs/EXTERNAL/ projects separately17:46
mithrokgugala: 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
mithrokgugala: most of the libs/EXTERNAL are owned by vtr developers I believe17:49
mithro(well not libcatch or libpugixml)17:50
mithroBut libsdcparse, libblifparse and libtantum I think?17:50
litghostmithro: Changing 228 files and a total of 40k lines is small to you?18:01
litghostRequest for comment on  https://github.com/SymbiFlow/symbiflow-arch-defs/pull/44518:01
tpbTitle: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)18:01
mithrolitghost: Smaller than expected, not small in general18:02
litghostSure18:02
mithrolitghost: I think the sqlite idea kind of makes some sense18:04
litghostmithro: 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 graphs18:05
litghostmithro: 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 graph18:06
litghostmithro: This may help with that, TBD18:06
*** Miyu has joined #symbiflow18:09
mithrolitghost: I wonder if it makes sense to use sqlalchemy rather than sqlite directly?18:09
litghostmithro: I'd have to take a look.18:09
litghostmithro: Step one is to get the thing to work at all.18:09
litghostmithro: Still debugging teething problems18:10
litghostmithro: But I think it's really close18:10
litghostmithro: I also chose sqlite3 because it is built into python3 directly18:11
mithrolitghost: We already have non-directly included Python deps, so I wouldn't worry to much about that18:13
mithrolitghost: I'm not particularly fond of your formatting around those sql queries and some of them are pretty complicated....18:14
litghostmithro: 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 again18:14
litghostmithro: Are you talking about the use of "?" or inline in general?18:14
mithrolitghost: Just the choice around wrapping choices inside the strings which contain the sql18:15
litghostI'm open to a standard SQL formatting to conform too18:16
mithrolitghost: 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
litghostmithro: I only chose sqlite3 because it seems to fit our needs (no server, file oriented)18:18
mithrolitghost: Yeah, I think sqlite3 makes the most sense here18:18
mithro> shows a Critical Path Delay (CPD) of 6 billion seconds.18:21
mithro:-P18:21
litghost:)18:21
mithrolitghost: I'm thought we did values of 0 previously and something failed which is how we ended up with 1?18:22
litghostmithro: Unclear, that issue was on testarch18:22
litghostmithro: Do want to choose a couple SQL examples and add a comment with a new proposed syntax?18:30
mithrolitghost: Okay, will do that in an hour or two, have to run away now18:31
litghostk18:31
*** somlo has quit IRC20:14
*** somlo has joined #symbiflow20:17
*** somlo has quit IRC20:37
mithrolitghost: This is my suggested wrapping -> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445/files#diff-7f1b8c30132d9771af24e70f3ed0aabc23:24
tpbTitle: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:24
litghostBasically lots more white space23:26
litghostYou are missing some useful indentation though, but I think I can adapt the style23:26
litghostmithro: I'm not so sure about https://github.com/SymbiFlow/symbiflow-arch-defs/pull/445/commits/2be55bdb5ba8910e229853c6342761aa2ab1c01923:27
tpbTitle: WIP: Initial Sqlite3 XC7 routing graph implementation. by litghost · Pull Request #445 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:27
litghostmithro: Seems too far23:27
litghostSELECT x FROM y WHERE z is pretty common construct23:28
litghostI agree once you start getting into multiple joins and the like, it has to be broken up23:28
mithrolitghost: If you could fit it on one line, I'd be okay with (SELECT x FROM y WHERE z)23:29
litghostAny thoughts about just using http://www.dpriver.com/pp/sqlformat.htm ?23:30
tpbTitle: Instant SQL Formatter (at www.dpriver.com)23:30
litghostDefaults seem pretty good23:30
mithrolitghost: It seems to uppercase NAME23:33
litghostThat's probably fixable23:33
litghosthttps://pypi.org/project/format-sql/23:33
tpbTitle: format-sql · PyPI (at pypi.org)23:33
mithroboth https://www.freeformatter.com/sql-formatter.html#ad-output and https://codebeautify.org/sqlformatter format things closer to my style...23:37
tpbTitle: Free Online SQL Formatter - FreeFormatter.com (at www.freeformatter.com)23:37
mithroAhh that format-sql formats much closer to my style too...23:37
litghostformat-sql takes python files23:37
litghostso we can just add it to the make format23:38
litghostwhich I like23:38
mithrolitghost: I'm happy with that23:38
litghostMe too23:39
litghostauto-formatting == no debate, unless the tool is broken23:39
mithroI'm a little worried the tool won't handle your WITH / AS statements23:40
litghostActually the "?" was the problem :(23:40
mithrolitghost: It kind of looks abandoned too...23:42
litghostOh, and WITH statements23:42
litghost:( :( :(23:42
litghostOh well23:42
litghostI'm okay with using https://codebeautify.org/sqlformatter with some c/p23:42
tpbTitle: Best SQL Formatter Online (at codebeautify.org)23:42
litghostNot ideal, but better than lots of hand formatting23:42
mithrolitghost: 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!