Tuesday, 2019-04-02

*** tpb has joined #symbiflow00:00
*** sxpert has joined #symbiflow00:19
mithrolol - I just discovered        "char *strfry(char *string);" :-p01:05
hackerfooI can see that being useful for something, but not memfrob(3)01:09
futarisIRCcloudThe answer is 42.01:17
sorearunclear why glibc has those glorified april fools' jokes01:52
hackerfooGot "buttons" to work on the BASYS 3. It looks like at leaast 8GB RAM is the bare minimum to do this, or at least 4GB isn't enough. I'll try later on a laptop with 8GB.02:27
tpbTitle: RFC 8565 - Hypertext Jeopardy Protocol (HTJP/1.0) (at tools.ietf.org)03:09
*** citypw has joined #symbiflow03:20
*** _whitelogger has quit IRC04:22
*** _whitelogger has joined #symbiflow04:25
tpbTitle: GitHub - mithro/idstring (at github.com)05:53
mithroWhat I did today rather than all the things I should be doing....05:54
mithroWanted to get it down on paper before I forgot the idea05:54
*** kraiskil has joined #symbiflow05:59
*** kraiskil has quit IRC06:50
sf-slack<tmichalak> mithro: what is our approach for triggering a new prjxray-db build? The last update was 6 days ago and we see stable fails on the kintex database. Could you schedule a new run soon?07:23
*** kraiskil has joined #symbiflow07:34
*** celadon has joined #symbiflow08:12
*** kraiskil has quit IRC08:17
*** celadon has quit IRC08:43
*** Bertl_zZ is now known as Bertl09:01
*** OmniMancer has joined #symbiflow09:15
*** futarisIRCcloud has quit IRC09:17
*** kraiskil has joined #symbiflow09:19
*** kraiskil has quit IRC09:28
*** kraiskil has joined #symbiflow09:42
*** kraiskil has quit IRC09:43
*** kraiskil has joined #symbiflow09:43
*** celadon has joined #symbiflow09:47
*** kraiskil has quit IRC09:51
*** citypw has quit IRC10:01
*** kraiskil has joined #symbiflow10:03
*** Bertl is now known as bertl_oO10:27
*** i8hantanu has joined #symbiflow12:13
*** kraiskil has quit IRC13:34
*** kraiskil has joined #symbiflow13:47
*** i8hantanu has quit IRC14:23
sf-slack<mkurc> @litghost: Good time of day. I've added an "alternative" approach to the document describing the grid split: https://docs.google.com/document/d/1xvoga0CCXdNYolZU7GukBtFu2eE2XGYs04d7aRW5dM0 See the last page. Can you tell me does it make sense ?14:30
tpbTitle: Google Docs - create and edit documents online, for free. (at docs.google.com)14:30
*** bertl_oO is now known as Bertl14:38
*** kraiskil has quit IRC14:51
*** kraiskil has joined #symbiflow15:05
*** kraiskil has quit IRC15:05
*** kraiskil has joined #symbiflow15:06
*** Bertl is now known as Bertl_oO15:07
*** OmniMancer has quit IRC15:18
*** kraiskil has quit IRC15:29
mithromkurc: Will you have time after the sync up to chat about the tile split with myself and keith?16:06
mithrotmichalak: You ask me to update it...16:06
mithrotmichalak: But I don't quite understand what you mean by "we see stable fails"?16:06
sf-slack<mkurc> @mithro: Yes I will16:07
sf-slack<tmichalak> @mithro: I mean that for kintex we see the same conflicts for BYP_ALT.GFAN and that's because in the master prjxray-db the bits in the segbits_int_l.db are wrong16:08
mithrotmichalak: The existing database shouldn't be involved when running on CI?16:19
sf-slack<tmichalak> @mithro: Right, due to the fact that much changed between the current prjxray-db and the latest prjxray results  I didn't see in the log the cause of the kintex step failing, namely this collision:   00420c81_048_25: had INT_R_X25Y24.INT_R.CLK1.ER1END1, got CLK_HROW_BOT_R_X67Y26.CLK_HROW_BOT_R.CLK_HROW_CK_INT_0_1_ACTIVE   00420c81_051_24: had INT_R_X25Y25.INT_R.CLK0.ER1END1, got16:34
*** kraiskil has joined #symbiflow16:41
mithrotmichalak: The CI starts from an empty database every time16:56
mithro"KaHyPar (Karlsruhe Hypergraph Partitioning) is a multilevel hypergraph partitioning framework providing direct k-way and recursive bisection based partitioning algorithms that compute solutions of very high quality." -17:15
mithroelms: https://github.com/inveniosoftware/requirements-builder17:19
tpbTitle: GitHub - inveniosoftware/requirements-builder: Build requirements files from setup.py. (at github.com)17:19
mithroelms: Where did we get to with Python formatting stuff on symbiflow-arch-defs?17:22
tpbTitle: GitHub - wyvernSemi/pcievhost: PCIe (1.0a to 2.0) Virtual host model for verilog (at github.com)17:23
elmsmithro: I have a PR that does a check and have a local change I need to clean up to actually run yapf on all the fiiles. I was going to look at it soon.17:23
*** kraiskil has quit IRC17:26
*** kraiskil has joined #symbiflow17:27
litghostkgugala: https://forums.xilinx.com/t5/Timing-Analysis/Understanding-Vivado-Timing-Parameters/td-p/75614617:29
tpbTitle: Solved: Understanding Vivado Timing Parameters - Community Forums3rd Party Header & Footer (at forums.xilinx.com)17:29
*** Bertl_oO is now known as Bertl17:31
mithroelms: We should make sure to add the reformat patch to a .git-blame-ignore-revs file. (https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html)17:35
tpbTitle: git-hyper-blame(1) (at commondatastorage.googleapis.com)17:35
mithrokgugala: We should also do that for the vtr reformatting patches17:35
kgugala@litghost I've seen that, fortunately we can extract this info17:42
sf-slack<kgugala> @litghost I added the latest sdfs to the issue https://github.com/SymbiFlow/prjxray/pull/70617:46
tpbTitle: WIP: fuzzers: timings: add bel timing fuzzer by kgugala · Pull Request #706 · SymbiFlow/prjxray · GitHub (at github.com)17:46
sf-slack<kgugala> @mithro sure, we can add this to the format target17:48
*** kraiskil has quit IRC19:50
mithroI'm planning on applying to Season of Docs for SymbiFlow -> https://developers.google.com/season-of-docs20:46
tpbTitle: Season of Docs | Google Developers (at developers.google.com)20:46
litghostmithro/elms: There is a modelling error in https://github.com/SymbiFlow/symbiflow-arch-defs/pull/511 when a DRAM WE signal is tied to VCC.  However I'm not sure why that is ever a valid configuration.  Can we simply forbid tying the DRAM WE signal to VCC?21:10
tpbTitle: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)21:10
litghostmithro/elms: If that is not acceptable, I'll need to figure out a subtler model for the CE signal on SLICEM's.  None of the solutions I've come up with are pretty so far21:11
mithrolitghost: I'm not sure I understand what is meant by "modelling error"?21:12
litghostmithro: In #511, I've added a graph edge from the VCC network to the CE pin on the SLICEM21:13
litghostmithro: If the design is tying FF CE signals to CE, this is a valid model21:13
litghostmithro: However the SLICEM CEUSEDMUX is only upstream of the FF CE signals, NOT the DRAM WE mux21:13
litghostmithro: As a result, the graph is wrong if (and only if) the design ties the DRAM WE signal to VCC and VPR chooses the CE signal on the WE mux21:14
mithroelms: I think we want to add DEDENT_CLOSING_BRACKETS=True, INDENT_DICTIONARY_VALUE=True and SPLIT_BEFORE_FIRST_ARGUMENT=True to our yapf config?21:21
elmsmithro: I don't have a preference. As long as it's consistent and I don't have to think about it.21:23
mithrolitghost: I think I understand but a diagram would help....21:23
litghostmithro: Just look at the SLICEM diagram from CLB document21:23
litghostmithro: Figure 2-321:24
litghostmithro: Yes21:26
mithroelms: Could you add them and to the reformat and let me take a look?21:26
litghostmithro: That path cannot be tied to VCC without active configuration21:26
litghostmithro: Unlike the other CE path (which has that CEUSEDMUX)21:27
elmsmithro: I'll merge the https://github.com/SymbiFlow/symbiflow-arch-defs/pull/519 And add them to #522 for you to look unless you object21:28
tpbTitle: Add target to use yapf to check all python files by elmsfu · Pull Request #519 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)21:28
elmslitghost: what do you mean by active configuration?21:28
litghostelms: CEUSEDMUX defaults to tying CE to VCC.  It actually takes a bit to disable this.  This is not true of the path above.  #511 adds an edge from VCC to the CE pin, which is not correct if attempting to tie WEN to VCC21:30
litghostelms: But having WEN tied to VCC is weird21:30
litghostmithro: Ignore the WE site pin, not relevant here21:32
litghostmithro: One option is to not enable the CE -> WEN connection, but it seems less drastic to just disallow tying WEN to VCC21:32
elmslitghost: can you link to the added edge in #51121:34
tpbTitle: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)21:34
mithrolitghost: When the CE is not used, the CE is tied to VCC via not configuring the CEUSEDMUX, right?21:36
litghostmithro: Not exactly.  If FF.CE is unused OR FF.CE == VCC, then CEUSEDMUX = 021:36
litghostmithro: It's pretty common to have FF.CE tied to VCC21:37
mithrolitghost: When FF.CE is tied high it effectively disables the clock enable functionality, right? I'm not sure I understand the difference between FF.CE tied high and "FF.CE unused" ?21:40
litghostmithro: Unused could simply be that nothing in the SLICE is using an FF.  A design that instances an FF, but ties the signal to VCC, is not the same as a design with no FFs21:40
mithrolitghost: Ahh - okay21:41
elmslitghost: So vpr is unaware that by default it will be tied to VCC and that is the cause of the issue?21:43
litghostelms: Keep in mind that VPR doesn't actually understand what "VCC" is, fundimentally.  A signal is just a signal21:43
litghostelms: The issue in this case is that I made a model simplification that is invalid if WEN is tied to VCC21:44
litghostelms: To fix that simplification requires some other comprimises21:44
litghostelms: Either in the form of missing routing (e.g. remove the WE mux) or complexity (adding a synthentic site pin) or a major undertaking (truely teach VPR about site internal constant sources)21:45
mithrolitghost: So my change to the diagram around the CEUSEDMUX is wrong, right?21:46
litghostmithro: How so?  besides the VCC on the WE site pin, it looks right21:46
mithrolitghost: the CEUSEDMUX doesn't select between CE and VCC, it just connects or disconnects the CE to the FF?21:47
litghostmithro: No, the CEUSEDMUX does select between CE and VCC21:47
litghostmithro: But the CEUSEDMUX doesn't affect the CE -> WEN path21:48
elmslitghost: How would you implement the special case to accommodate the simplification? I'd be ok with a work around if we open an issue to document it. Because ideally we have an accurate model, but I understand if it 's not the time to solve that particular case now.21:49
litghostelms: If we split the CE -> WEN and CE -> FF signal into two site pins, then we could add the edge only to the CE -> FF path21:50
mithrolitghost: So if CE is unused but WE is tied high, then VPR could chose CE of WE for VCC?21:50
litghostmithro: No.  If VPR chooses CE as WEN, and WEN is tied, then it can choose the VCC -> CE site pin connection.  This graph edge is wrong, because it is modelling the CEUSEDMUX, which does not affect the CE -> WEN path21:51
litghostelms: Splitting the CE -> WEN and CE -> FF site pins is fairly hairy, especially in light of the incoming SLICE split and the equivilent tile work21:52
litghostelms: Which would both be directly impacted by aliasing site pins21:52
litghostelms: Oh, sorry are you talking about how would I enforce that WEN is not tied to VCC?  Via the DRAM techmap21:58
mithrolitghost: could you just move the WEN mux up into the routing?21:58
litghostmithro: Interesting.  I'd have to think about how to do that21:59
litghostmithro: That might work as a variation on the tiedable signal idea22:00
mithrolitghost: The other thing I was trying to understand is CEUSEDMUX should be set only when the signal coming out of the CEUSEDMUX is used by something downstream? It is unclear to me why CEUSEDMUX is being set when VCC->top level CE pin?22:02
litghostmithro: You have it backwards, CEUSEDMUX is set when not tying VCC -> top level22:02
mithrolitghost: Going to get coffee - what does "set" mean? The feature is enabled or the bit value is 1?22:04
litghostmithro: Set in this instance means CEUSEDMUX = 122:05
litghostmithro: Which means "connect CE to FF.CE", rather than the default of "connect VCC to FF.CE"22:05
*** Miyu has quit IRC22:16
*** Miyu has joined #symbiflow22:16
mithrolitghost: Sorry I went to get coffee and then started chatting to hzeller22:41
litghostmithro: I think the idea of moving the WE mux into the rr graph is viable.  It will complicate some parts of the timing import, but in some ways it may actually be easier22:42
*** hzeller has joined #symbiflow22:43
litghostmithro: I'm testing the idea now, and will see if I can make VPR emit all configurations22:43
*** nonlinear has quit IRC22:44
*** nonlinear has joined #symbiflow22:44
mithrolitghost: Okay22:47
*** hzeller has quit IRC23:02
*** hzeller has joined #symbiflow23:02
hackerfooI'm working on https://github.com/SymbiFlow/symbiflow-arch-defs/issues/409 - How can I verify ram_test? The UART on the basys3 seems to be very busy, but I can't find a baud rate to make sense out of it.23:14
tpbTitle: RAM32X1D not working · Issue #409 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:14
tpbTitle: symbiflow-arch-defs/xc7 at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:15
litghostIt's 500k baud23:15
tpbTitle: symbiflow-arch-defs/read_uart.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:15
litghosthackerfoo: I typically just run23:16
litghoststty raw 500000 < /dev/ttyUSB123:16
litghostxxd /dev/ttyUSB123:16
litghosthackerfoo: Do note that read_uart.py will erronously print an error due to a total lack of framing or checksums in the output23:16
litghosthackerfoo: I kept the UART stream a little too simple, and because of the counter the E sigil can appear23:17
mithrohzeller: https://github.com/SymbiFlow/fpga-tool-perf23:23
tpbTitle: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at github.com)23:23
hackerfooHow long does the test typically take? I don't see any output from read_uart.py yet.23:26
litghosthackerfoo: Immiedate23:28
litghosthackerfoo: That tool only runs with python3, not python223:28
litghosthackerfoo: Side affect of bytes/str, etc23:28
hackerfooThanks. I've got it working now.23:30
*** futarisIRCcloud has joined #symbiflow23:37

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!