| *** tpb has joined #symbiflow | 00:00 | |
| *** sxpert has joined #symbiflow | 00:19 | |
| mithro | lol - I just discovered "char *strfry(char *string);" :-p | 01:05 |
|---|---|---|
| hackerfoo | I can see that being useful for something, but not memfrob(3) | 01:09 |
| futarisIRCcloud | The answer is 42. | 01:17 |
| sorear | unclear why glibc has those glorified april fools' jokes | 01:52 |
| hackerfoo | Got "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 |
| futarisIRCcloud | https://tools.ietf.org/html/rfc8565 | 03:09 |
| tpb | Title: RFC 8565 - Hypertext Jeopardy Protocol (HTJP/1.0) (at tools.ietf.org) | 03:09 |
| *** citypw has joined #symbiflow | 03:20 | |
| *** _whitelogger has quit IRC | 04:22 | |
| *** _whitelogger has joined #symbiflow | 04:25 | |
| mithro | https://github.com/mithro/idstring | 05:53 |
| tpb | Title: GitHub - mithro/idstring (at github.com) | 05:53 |
| mithro | What I did today rather than all the things I should be doing.... | 05:54 |
| mithro | Wanted to get it down on paper before I forgot the idea | 05:54 |
| *** kraiskil has joined #symbiflow | 05:59 | |
| *** kraiskil has quit IRC | 06: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 #symbiflow | 07:34 | |
| *** celadon has joined #symbiflow | 08:12 | |
| *** kraiskil has quit IRC | 08:17 | |
| *** celadon has quit IRC | 08:43 | |
| *** Bertl_zZ is now known as Bertl | 09:01 | |
| *** OmniMancer has joined #symbiflow | 09:15 | |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** kraiskil has joined #symbiflow | 09:19 | |
| *** kraiskil has quit IRC | 09:28 | |
| *** kraiskil has joined #symbiflow | 09:42 | |
| *** kraiskil has quit IRC | 09:43 | |
| *** kraiskil has joined #symbiflow | 09:43 | |
| *** celadon has joined #symbiflow | 09:47 | |
| *** kraiskil has quit IRC | 09:51 | |
| *** citypw has quit IRC | 10:01 | |
| *** kraiskil has joined #symbiflow | 10:03 | |
| *** Bertl is now known as bertl_oO | 10:27 | |
| *** i8hantanu has joined #symbiflow | 12:13 | |
| *** kraiskil has quit IRC | 13:34 | |
| *** kraiskil has joined #symbiflow | 13:47 | |
| *** i8hantanu has quit IRC | 14: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 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 14:30 |
| *** bertl_oO is now known as Bertl | 14:38 | |
| *** kraiskil has quit IRC | 14:51 | |
| *** kraiskil has joined #symbiflow | 15:05 | |
| *** kraiskil has quit IRC | 15:05 | |
| *** kraiskil has joined #symbiflow | 15:06 | |
| *** Bertl is now known as Bertl_oO | 15:07 | |
| *** OmniMancer has quit IRC | 15:18 | |
| *** kraiskil has quit IRC | 15:29 | |
| mithro | mkurc: Will you have time after the sync up to chat about the tile split with myself and keith? | 16:06 |
| mithro | tmichalak: You ask me to update it... | 16:06 |
| mithro | tmichalak: But I don't quite understand what you mean by "we see stable fails"? | 16:06 |
| sf-slack | <mkurc> @mithro: Yes I will | 16: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 wrong | 16:08 |
| mithro | tmichalak: 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, got | 16:34 |
| sf-slack | CLK_HROW_BOT_R_X67Y26.CLK_HROW_BOT_R.CLK_HROW_CK_INT_1_0_ACTIVE | 16:34 |
| *** kraiskil has joined #symbiflow | 16:41 | |
| mithro | tmichalak: The CI starts from an empty database every time | 16: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 |
| mithro | elms: https://github.com/inveniosoftware/requirements-builder | 17:19 |
| tpb | Title: GitHub - inveniosoftware/requirements-builder: Build requirements files from setup.py. (at github.com) | 17:19 |
| mithro | elms: Where did we get to with Python formatting stuff on symbiflow-arch-defs? | 17:22 |
| mithro | https://github.com/wyvernSemi/pcievhost | 17:23 |
| tpb | Title: GitHub - wyvernSemi/pcievhost: PCIe (1.0a to 2.0) Virtual host model for verilog (at github.com) | 17:23 |
| elms | mithro: 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 IRC | 17:26 | |
| *** kraiskil has joined #symbiflow | 17:27 | |
| litghost | kgugala: https://forums.xilinx.com/t5/Timing-Analysis/Understanding-Vivado-Timing-Parameters/td-p/756146 | 17:29 |
| tpb | Title: Solved: Understanding Vivado Timing Parameters - Community Forums3rd Party Header & Footer (at forums.xilinx.com) | 17:29 |
| *** Bertl_oO is now known as Bertl | 17:31 | |
| mithro | elms: 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 |
| tpb | Title: git-hyper-blame(1) (at commondatastorage.googleapis.com) | 17:35 |
| mithro | kgugala: We should also do that for the vtr reformatting patches | 17:35 |
| kgugala | @litghost I've seen that, fortunately we can extract this info | 17:42 |
| sf-slack | <kgugala> @litghost I added the latest sdfs to the issue https://github.com/SymbiFlow/prjxray/pull/706 | 17:46 |
| tpb | Title: 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 target | 17:48 |
| *** kraiskil has quit IRC | 19:50 | |
| mithro | I'm planning on applying to Season of Docs for SymbiFlow -> https://developers.google.com/season-of-docs | 20:46 |
| tpb | Title: Season of Docs | Google Developers (at developers.google.com) | 20:46 |
| litghost | mithro/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 |
| tpb | Title: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:10 |
| litghost | mithro/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 far | 21:11 |
| mithro | litghost: I'm not sure I understand what is meant by "modelling error"? | 21:12 |
| litghost | mithro: In #511, I've added a graph edge from the VCC network to the CE pin on the SLICEM | 21:13 |
| litghost | mithro: If the design is tying FF CE signals to CE, this is a valid model | 21:13 |
| litghost | mithro: However the SLICEM CEUSEDMUX is only upstream of the FF CE signals, NOT the DRAM WE mux | 21:13 |
| litghost | mithro: 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 mux | 21:14 |
| mithro | elms: 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 |
| elms | mithro: I don't have a preference. As long as it's consistent and I don't have to think about it. | 21:23 |
| mithro | litghost: I think I understand but a diagram would help.... | 21:23 |
| litghost | mithro: Just look at the SLICEM diagram from CLB document | 21:23 |
| litghost | https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf | 21:23 |
| litghost | mithro: Figure 2-3 | 21:24 |
| mithro | https://usercontent.irccloud-cdn.com/file/ysGg7da9/image.png | 21:26 |
| litghost | mithro: Yes | 21:26 |
| mithro | elms: Could you add them and to the reformat and let me take a look? | 21:26 |
| litghost | mithro: That path cannot be tied to VCC without active configuration | 21:26 |
| litghost | mithro: Unlike the other CE path (which has that CEUSEDMUX) | 21:27 |
| elms | mithro: I'll merge the https://github.com/SymbiFlow/symbiflow-arch-defs/pull/519 And add them to #522 for you to look unless you object | 21:28 |
| tpb | Title: 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 |
| elms | litghost: what do you mean by active configuration? | 21:28 |
| litghost | elms: 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 VCC | 21:30 |
| litghost | elms: But having WEN tied to VCC is weird | 21:30 |
| mithro | https://usercontent.irccloud-cdn.com/file/5RIQ6jTO/image.png | 21:31 |
| mithro | Opps | 21:31 |
| mithro | https://usercontent.irccloud-cdn.com/file/k7SI33jp/image.png | 21:31 |
| litghost | mithro: Ignore the WE site pin, not relevant here | 21:32 |
| litghost | mithro: One option is to not enable the CE -> WEN connection, but it seems less drastic to just disallow tying WEN to VCC | 21:32 |
| elms | litghost: can you link to the added edge in #511 | 21:34 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/pull/511/files#diff-a48b9df8cf746f828953d55760151686R34 | 21:34 |
| tpb | Title: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:34 |
| mithro | litghost: When the CE is not used, the CE is tied to VCC via not configuring the CEUSEDMUX, right? | 21:36 |
| litghost | mithro: Not exactly. If FF.CE is unused OR FF.CE == VCC, then CEUSEDMUX = 0 | 21:36 |
| litghost | mithro: It's pretty common to have FF.CE tied to VCC | 21:37 |
| mithro | litghost: 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 |
| litghost | mithro: 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 FFs | 21:40 |
| mithro | litghost: Ahh - okay | 21:41 |
| elms | litghost: So vpr is unaware that by default it will be tied to VCC and that is the cause of the issue? | 21:43 |
| litghost | elms: Keep in mind that VPR doesn't actually understand what "VCC" is, fundimentally. A signal is just a signal | 21:43 |
| litghost | elms: The issue in this case is that I made a model simplification that is invalid if WEN is tied to VCC | 21:44 |
| litghost | elms: To fix that simplification requires some other comprimises | 21:44 |
| litghost | elms: 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 |
| mithro | litghost: So my change to the diagram around the CEUSEDMUX is wrong, right? | 21:46 |
| litghost | mithro: How so? besides the VCC on the WE site pin, it looks right | 21:46 |
| mithro | litghost: the CEUSEDMUX doesn't select between CE and VCC, it just connects or disconnects the CE to the FF? | 21:47 |
| litghost | mithro: No, the CEUSEDMUX does select between CE and VCC | 21:47 |
| litghost | mithro: But the CEUSEDMUX doesn't affect the CE -> WEN path | 21:48 |
| elms | litghost: 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 |
| litghost | elms: 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 path | 21:50 |
| mithro | litghost: So if CE is unused but WE is tied high, then VPR could chose CE of WE for VCC? | 21:50 |
| litghost | mithro: 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 path | 21:51 |
| litghost | elms: Splitting the CE -> WEN and CE -> FF site pins is fairly hairy, especially in light of the incoming SLICE split and the equivilent tile work | 21:52 |
| litghost | elms: Which would both be directly impacted by aliasing site pins | 21:52 |
| litghost | elms: Oh, sorry are you talking about how would I enforce that WEN is not tied to VCC? Via the DRAM techmap | 21:58 |
| mithro | litghost: could you just move the WEN mux up into the routing? | 21:58 |
| litghost | mithro: Interesting. I'd have to think about how to do that | 21:59 |
| litghost | mithro: That might work as a variation on the tiedable signal idea | 22:00 |
| mithro | litghost: 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 |
| litghost | mithro: You have it backwards, CEUSEDMUX is set when not tying VCC -> top level | 22:02 |
| mithro | litghost: Going to get coffee - what does "set" mean? The feature is enabled or the bit value is 1? | 22:04 |
| litghost | mithro: Set in this instance means CEUSEDMUX = 1 | 22:05 |
| litghost | mithro: Which means "connect CE to FF.CE", rather than the default of "connect VCC to FF.CE" | 22:05 |
| *** Miyu has quit IRC | 22:16 | |
| *** Miyu has joined #symbiflow | 22:16 | |
| mithro | litghost: Sorry I went to get coffee and then started chatting to hzeller | 22:41 |
| litghost | mithro: 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 easier | 22:42 |
| *** hzeller has joined #symbiflow | 22:43 | |
| litghost | mithro: I'm testing the idea now, and will see if I can make VPR emit all configurations | 22:43 |
| *** nonlinear has quit IRC | 22:44 | |
| *** nonlinear has joined #symbiflow | 22:44 | |
| mithro | litghost: Okay | 22:47 |
| *** hzeller has quit IRC | 23:02 | |
| *** hzeller has joined #symbiflow | 23:02 | |
| hackerfoo | I'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 |
| tpb | Title: RAM32X1D not working · Issue #409 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:14 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7 | 23:15 |
| tpb | Title: symbiflow-arch-defs/xc7 at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:15 |
| litghost | It's 500k baud | 23:15 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/common/read_uart.py | 23:15 |
| tpb | Title: symbiflow-arch-defs/read_uart.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:15 |
| hackerfoo | Thanks | 23:15 |
| litghost | hackerfoo: I typically just run | 23:16 |
| litghost | stty raw 500000 < /dev/ttyUSB1 | 23:16 |
| litghost | xxd /dev/ttyUSB1 | 23:16 |
| litghost | hackerfoo: Do note that read_uart.py will erronously print an error due to a total lack of framing or checksums in the output | 23:16 |
| litghost | hackerfoo: I kept the UART stream a little too simple, and because of the counter the E sigil can appear | 23:17 |
| mithro | hzeller: https://github.com/SymbiFlow/fpga-tool-perf | 23:23 |
| tpb | Title: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at github.com) | 23:23 |
| hackerfoo | How long does the test typically take? I don't see any output from read_uart.py yet. | 23:26 |
| litghost | hackerfoo: Immiedate | 23:28 |
| litghost | hackerfoo: That tool only runs with python3, not python2 | 23:28 |
| litghost | hackerfoo: Side affect of bytes/str, etc | 23:28 |
| hackerfoo | Thanks. I've got it working now. | 23:30 |
| *** futarisIRCcloud has joined #symbiflow | 23:37 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
