00:58 <mithro> lol - I just discovered "char *strfry(char *string);" :-p

01:01 <hackerfoo> I can see that being useful for something, but not memfrob(3)

01:09 <futarisIRCcloud> The answer is 42.

01:44 <sorear> unclear why glibc has those glorified april fools' jokes

02:20 <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.

03:01 <futarisIRCcloud> https://tools.ietf.org/html/rfc8565

03:01 <tpb> Title: RFC 8565 - Hypertext Jeopardy Protocol (HTJP/1.0) (at tools.ietf.org)

05:45 <mithro> https://github.com/mithro/idstring

05:45 <tpb> Title: GitHub - mithro/idstring (at github.com)

05:46 <mithro> What I did today rather than all the things I should be doing....

05:46 <mithro> Wanted to get it down on paper before I forgot the idea

07:15 <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?

14:22 <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:22 <tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)

15:58 <mithro> mkurc: Will you have time after the sync up to chat about the tile split with myself and keith?

15:58 <mithro> tmichalak: You ask me to update it...

15:58 <mithro> tmichalak: But I don't quite understand what you mean by "we see stable fails"?

15:59 <sf-slack> <mkurc> @mithro: Yes I will

16:00 <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:12 <mithro> tmichalak: The existing database shouldn't be involved when running on CI?

16:26 <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:26 <sf-slack> CLK_HROW_BOT_R_X67Y26.CLK_HROW_BOT_R.CLK_HROW_CK_INT_1_0_ACTIVE

16:48 <mithro> tmichalak: The CI starts from an empty database every time

17:07 <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:11 <mithro> elms: https://github.com/inveniosoftware/requirements-builder

17:11 <tpb> Title: GitHub - inveniosoftware/requirements-builder: Build requirements files from setup.py. (at github.com)

17:14 <mithro> elms: Where did we get to with Python formatting stuff on symbiflow-arch-defs?

17:15 <mithro> https://github.com/wyvernSemi/pcievhost

17:15 <tpb> Title: GitHub - wyvernSemi/pcievhost: PCIe (1.0a to 2.0) Virtual host model for verilog (at github.com)

17:15 <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:21 <litghost> kgugala: https://forums.xilinx.com/t5/Timing-Analysis/Understanding-Vivado-Timing-Parameters/td-p/756146

17:21 <tpb> Title: Solved: Understanding Vivado Timing Parameters - Community Forums3rd Party Header & Footer (at forums.xilinx.com)

17:27 <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:27 <tpb> Title: git-hyper-blame(1) (at commondatastorage.googleapis.com)

17:27 <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:39 <sf-slack> <kgugala> @litghost I added the latest sdfs to the issue https://github.com/SymbiFlow/prjxray/pull/706

17:39 <tpb> Title: WIP: fuzzers: timings: add bel timing fuzzer by kgugala · Pull Request #706 · SymbiFlow/prjxray · GitHub (at github.com)

17:40 <sf-slack> <kgugala> @mithro sure, we can add this to the format target

20:39 <mithro> I'm planning on applying to Season of Docs for SymbiFlow -> https://developers.google.com/season-of-docs

20:39 <tpb> Title: Season of Docs | Google Developers (at developers.google.com)

21:03 <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:03 <tpb> Title: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

21:03 <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:05 <mithro> litghost: I'm not sure I understand what is meant by "modelling error"?

21:05 <litghost> mithro: In #511, I've added a graph edge from the VCC network to the CE pin on the SLICEM

21:05 <litghost> mithro: If the design is tying FF CE signals to CE, this is a valid model

21:06 <litghost> mithro: However the SLICEM CEUSEDMUX is only upstream of the FF CE signals, NOT the DRAM WE mux

21:06 <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:15 <elms> mithro: I don't have a preference. As long as it's consistent and I don't have to think about it.

21:15 <mithro> litghost: I think I understand but a diagram would help....

21:15 <litghost> mithro: Just look at the SLICEM diagram from CLB document

21:16 <litghost> https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf

21:16 <litghost> mithro: Figure 2-3

21:18 <mithro> https://usercontent.irccloud-cdn.com/file/ysGg7da9/image.png

21:18 <litghost> mithro: Yes

21:18 <mithro> elms: Could you add them and to the reformat and let me take a look?

21:19 <litghost> mithro: That path cannot be tied to VCC without active configuration

21:19 <litghost> mithro: Unlike the other CE path (which has that CEUSEDMUX)

21:20 <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:20 <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:20 <elms> litghost: what do you mean by active configuration?

21:22 <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:22 <litghost> elms: But having WEN tied to VCC is weird

21:23 <mithro> https://usercontent.irccloud-cdn.com/file/5RIQ6jTO/image.png

21:23 <mithro> Opps

21:24 <mithro> https://usercontent.irccloud-cdn.com/file/k7SI33jp/image.png

21:24 <litghost> mithro: Ignore the WE site pin, not relevant here

21:25 <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:26 <elms> litghost: can you link to the added edge in #511

21:26 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/pull/511/files#diff-a48b9df8cf746f828953d55760151686R34

21:26 <tpb> Title: WIP: Initial constant routing support. by litghost · Pull Request #511 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

21:28 <mithro> litghost: When the CE is not used, the CE is tied to VCC via not configuring the CEUSEDMUX, right?

21:29 <litghost> mithro: Not exactly. If FF.CE is unused OR FF.CE == VCC, then CEUSEDMUX = 0

21:29 <litghost> mithro: It's pretty common to have FF.CE tied to VCC

21:32 <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:33 <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:34 <mithro> litghost: Ahh - okay

21:35 <elms> litghost: So vpr is unaware that by default it will be tied to VCC and that is the cause of the issue?

21:35 <litghost> elms: Keep in mind that VPR doesn't actually understand what "VCC" is, fundimentally. A signal is just a signal

21:36 <litghost> elms: The issue in this case is that I made a model simplification that is invalid if WEN is tied to VCC

21:36 <litghost> elms: To fix that simplification requires some other comprimises

21:38 <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:38 <mithro> litghost: So my change to the diagram around the CEUSEDMUX is wrong, right?

21:38 <litghost> mithro: How so? besides the VCC on the WE site pin, it looks right

21:39 <mithro> litghost: the CEUSEDMUX doesn't select between CE and VCC, it just connects or disconnects the CE to the FF?

21:40 <litghost> mithro: No, the CEUSEDMUX does select between CE and VCC

21:40 <litghost> mithro: But the CEUSEDMUX doesn't affect the CE -> WEN path

21:41 <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:42 <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:42 <mithro> litghost: So if CE is unused but WE is tied high, then VPR could chose CE of WE for VCC?

21:43 <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:44 <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:45 <litghost> elms: Which would both be directly impacted by aliasing site pins

21:50 <litghost> elms: Oh, sorry are you talking about how would I enforce that WEN is not tied to VCC? Via the DRAM techmap

21:50 <mithro> litghost: could you just move the WEN mux up into the routing?

21:51 <litghost> mithro: Interesting. I'd have to think about how to do that

21:52 <litghost> mithro: That might work as a variation on the tiedable signal idea

21:54 <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?

21:55 <litghost> mithro: You have it backwards, CEUSEDMUX is set when not tying VCC -> top level

21:57 <mithro> litghost: Going to get coffee - what does "set" mean? The feature is enabled or the bit value is 1?

21:57 <litghost> mithro: Set in this instance means CEUSEDMUX = 1

21:57 <litghost> mithro: Which means "connect CE to FF.CE", rather than the default of "connect VCC to FF.CE"

22:34 <mithro> litghost: Sorry I went to get coffee and then started chatting to hzeller

22:34 <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:35 <litghost> mithro: I'm testing the idea now, and will see if I can make VPR emit all configurations

22:40 <mithro> litghost: Okay

23:06 <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:06 <tpb> Title: RAM32X1D not working · Issue #409 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

23:07 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7

23:07 <tpb> Title: symbiflow-arch-defs/xc7 at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

23:07 <litghost> It's 500k baud

23:07 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/common/read_uart.py

23:07 <tpb> Title: symbiflow-arch-defs/read_uart.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

23:08 <hackerfoo> Thanks

23:08 <litghost> hackerfoo: I typically just run

23:08 <litghost> stty raw 500000 < /dev/ttyUSB1

23:08 <litghost> xxd /dev/ttyUSB1

23:08 <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:09 <litghost> hackerfoo: I kept the UART stream a little too simple, and because of the counter the E sigil can appear

23:15 <mithro> hzeller: https://github.com/SymbiFlow/fpga-tool-perf

23:15 <tpb> Title: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at github.com)

23:18 <hackerfoo> How long does the test typically take? I don't see any output from read_uart.py yet.

23:20 <litghost> hackerfoo: Immiedate

23:20 <litghost> hackerfoo: That tool only runs with python3, not python2

23:20 <litghost> hackerfoo: Side affect of bytes/str, etc

23:22 <hackerfoo> Thanks. I've got it working now.