Tuesday, 2019-05-14

*** tpb has joined #symbiflow00:00
litghostkgugala: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/timings/CLBLL_L.sdf#L4 If I read this correctly, then everything is in units of picoseconds?  That seems wrong00:17
tpbTitle: prjxray-db/CLBLL_L.sdf at master · SymbiFlow/prjxray-db · GitHub (at github.com)00:17
litghostkgugala: Why do you believe the values are in picoseconds versus nanoseconds?00:17
litghostkgugala: Also, I'm trying to find T_setup for D w.r.t. CLK, and I don't see it00:25
litghostkgugala: I believe the speed model in question would be bel_d_reg_init_ff_setup_din_clk, but I don't see it in our output SDF.  Did I missing ?00:32
litghostkgugala: I believe https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/timings/CLBLL_L.sdf#L300 is missing SR and DIN?00:46
tpbTitle: prjxray-db/CLBLL_L.sdf at master · SymbiFlow/prjxray-db · GitHub (at github.com)00:46
*** futarisIRCcloud has joined #symbiflow01:31
*** Bertl_oO is now known as Bertl_zZ01:37
*** citypw has joined #symbiflow01:40
*** jevinskie has joined #symbiflow02:52
*** proteusguy has quit IRC04:07
*** jevinskie has quit IRC04:44
*** jevinskie has joined #symbiflow05:03
*** jevinskie has quit IRC05:43
mithrokgugala / mkurc: I _think_ I have pack_patterns working in https://github.com/SymbiFlow/symbiflow-arch-defs/pull/703/files05:54
tpbTitle: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)05:54
*** proteusguy has joined #symbiflow05:54
mithroWhat is still not working is pack_pattern and mode interaction05:58
*** jevinskie has joined #symbiflow06:00
*** citypw has quit IRC06:10
*** citypw has joined #symbiflow06:22
*** citypw has quit IRC06:36
*** citypw has joined #symbiflow06:53
*** OmniMancer has joined #symbiflow06:58
sf-slack2<kgugala> @litghost indeed those timings look like ns - this is an easy fix. I'll do that07:13
sf-slack2<kgugala> @litghost the bel_d_reg_init_ff_setup_din_clk is dumped from the design, but it is not emitted to json from which the sdf is created07:14
sf-slack2<kgugala> @litghost this looks like a bug, I'll check it07:14
*** citypw has quit IRC07:20
*** Bertl_zZ is now known as Bertl08:46
*** futarisIRCcloud has quit IRC10:40
*** Vonter has quit IRC10:44
*** Vonter has joined #symbiflow11:01
sf-slack2<kgugala> @litghost https://github.com/SymbiFlow/prjxray/pull/83511:18
tpbTitle: Bel timings fixes by kgugala · Pull Request #835 · SymbiFlow/prjxray · GitHub (at github.com)11:18
*** Vonter has quit IRC11:46
*** Vonter has joined #symbiflow11:58
*** proteusguy has quit IRC12:13
*** jevinskie has quit IRC13:15
sf-slack2<mkurc> @litghost I updated examples and answered your comments in https://docs.google.com/document/d/1J8lLT4SzlK_56-vBfz0f2DaNLHPn9rABUB0Fu1ljF4M13:49
tpbTitle: Google Docs - create and edit documents online, for free. (at docs.google.com)13:49
*** alexhw has joined #symbiflow15:07
*** OmniMancer has quit IRC15:25
sf-slack2<acomodi> Good time of day :)15:49
litghostGood time of day!15:51
mithroAnyone have a good example of a flipflop with a timing model attributes set in v2x?15:54
litghostIn v2x?  No15:54
litghostBut I could create one if you needed15:54
sf-slack2<mkurc> Morning15:56
mithrolitghost / kgugala: I could use an initial review of https://github.com/SymbiFlow/symbiflow-arch-defs/pull/70316:00
tpbTitle: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)16:00
litghostYep, saw the notification from github16:00
mithrolitghost: Don't go into to much detail yet, still have to get the mode interaction stuff working correctly16:01
sf-slack2<kgugala> sure, I'll take a look on that16:01
mithrokgugala / litghost: Just need the correct way to fill in https://github.com/SymbiFlow/symbiflow-arch-defs/pull/703/files#diff-2b42945a483e14aa20428a9e6c64f5f116:02
tpbTitle: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)16:02
mithro<pb_type> 'ff' timing-annotation/<model> mismatch on port 'Q' of model 'dff', port is a sequential output but has neither min nor max T_clock_to_Q specified16:02
litghostYa, you need to have T_clock_to_Q and T_setup at a minimum16:05
litghostT_hold is pretty much always required for a modelling standpoint, but not from VPR standpoint16:06
mithroIs T_clock_to_Q put on the D or Q value?16:11
litghostThat's a v2x question, unclear16:11
litghostI would put it on Q or CLK, not D16:11
mithromkurc: https://github.com/YosysHQ/yosys/issues/100116:26
tpbTitle: Could the output json include the parameters on modules? · Issue #1001 · YosysHQ/yosys · GitHub (at github.com)16:26
mithrolitghost: Can you write up the frontend parameters / attributes thingy16:27
mithrotmichalak: Please put your stuff in https://docs.google.com/document/d/1y_9tFoLzVC_PrZA2YIej__7LsgiXgrTN3oitTcsXEF8/edit# ?16:33
tpbTitle: Project U-Ray - Extending Project X-Ray to 7 Series, Ultrascale and Ultrascale+ Parts - Google Docs (at docs.google.com)16:33
sf-slack2<tmichalak> @mithro: done16:42
sf-slack2<tmichalak> I started a document on creating a DSP fuzzer, strarting from base address calculation: https://drive.google.com/open?id=1qsSFwYRFljJ-2C4UxJpOsNADi-nrdax8UX88g62OVO416:44
tpbTitle: Meet Google Drive – One place for all your files (at drive.google.com)16:44
mithrokgugala: I'm not sure the issue you suggested https://github.com/SymbiFlow/symbiflow-arch-defs/pull/645 is correct16:46
tpbTitle: WIP - utils/vlog: More tests from timing tutorial. by mithro · Pull Request #645 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)16:46
mithrokgugala: Do you have more information?16:46
litghostmkurc: https://github.com/YosysHQ/yosys/issues/100916:48
tpbTitle: Attributes on parameters / localparams are not parsed correctly per Verilog 2005 spec · Issue #1009 · YosysHQ/yosys · GitHub (at github.com)16:48
sf-slack2<kgugala> @mithro I can provide you with more info, what examples would you like to get?16:50
sf-slack2<mkurc> @litghost Thanks16:54
mithrokgugala: I'm unsure why you think that the issue is the eblif file?16:55
sf-slack2<kgugala> @mithro: because the eblifs do not correspond to top level pb_type they should test16:59
mithrokgugala: Hrm?17:01
sf-slack2<kgugala> if you look at the eblif generated for dsp_in_registered (https://github.com/SymbiFlow/symbiflow-arch-defs/pull/645#issuecomment-492279485) and the pb type it should correspond to https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/utils/vlog/tests/dsp_in_registered/golden.pb_type.xml you'll see that the eblif is missing clk input17:03
tpbTitle: WIP - utils/vlog: More tests from timing tutorial. by mithro · Pull Request #645 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)17:03
sf-slack2<kgugala> also, the eblif, does not use any $dffs17:04
mithrolitghost: Previously with the cmake stuff, only files had directory information in the target name. The `get_rel_target` makes the other targets follow the same pattern as the file targets and include the directory information. This means if you have something called "omux" under the xc7 directory and something called "omux" under the ice40 directory the target names won't conflict.17:04
sf-slack2<kgugala> so the circuit it implements want's to connect inbuf directly to dsp_combinational17:04
sf-slack2<kgugala> s/it//17:05
sf-slack2<kgugala> this connection is not feasible in the arch generated from the verilog in this test17:06
mithrokgugala: So the actual issue is that you need multiple leaf elements to fill in a tile17:06
sf-slack2<kgugala> @mithro multiple elements + top level (which is not taken into account now)17:07
mithrokgugala: You don't need a top level17:07
mithrokgugala: You just need enough .subckt parts to cross a tile17:10
sf-slack2<kgugala> @mithro: but what about top level ports? And their connections to the leafs?17:10
sf-slack2<kgugala> like in the above example clk input is defined in the top pb_type17:11
sf-slack2<kgugala> and then connected to leafs17:12
sf-slack2<kgugala> as direct connections in the top pb_type17:12
tpbTitle: symbiflow-arch-defs/vpr_pbtype_to_eblif.py at 4e524075fa8f2e9811d2217e77da0e2a83ea09ee · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)17:17
sf-slack2<kgugala> @mithro: this scripts calls find leaf https://github.com/SymbiFlow/symbiflow-arch-defs/blob/4e524075fa8f2e9811d2217e77da0e2a83ea09ee/utils/vpr_pbtype_to_eblif.py#L8317:20
tpbTitle: symbiflow-arch-defs/vpr_pbtype_to_eblif.py at 4e524075fa8f2e9811d2217e77da0e2a83ea09ee · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)17:20
sf-slack2<kgugala> which returns the first found pb_type with eblif attribute17:21
mithrokgugala: Yes17:26
sf-slack2<kgugala> so this one is invalid -- we should include all the leafs there17:27
sf-slack2<kgugala> + info how they are connected17:27
sf-slack2<kgugala> potencially the top level may instantiate other non leaf pb_types17:27
mithrokgugala: Once we have found a leaf, we should walk outward adding extra models as needed to get to the top level pins17:27
sf-slack2<kgugala> @mithro: yes17:28
sf-slack2<kgugala> and we should do that for all the found leaf pb_types17:28
mithrokgugala: I think that is potentially a more exhaustive test17:29
mithrokgugala: This test was just to check that vpr would accept the pb_type.xml in some form17:29
sf-slack2<kgugala> @mithro: dsp_in_registered has two leaf pb_types - dff and dsp_combinational17:30
sf-slack2<kgugala> and it is not very complicated test17:30
mithrokgugala: Yes, but dsp_mode has a *whole* bunch -- I think in that case we just want to test one?17:30
*** jevinskie has joined #symbiflow17:39
sf-slack2<kgugala> @mithro: yes, dsp_mode is even more complicated, it instantiates non leaf pb_types which instantiates leafs. Solving this would solve our issues here17:48
litghostmithro: I highly recommend further splitting your PR, because I think some changes are closer to being ready to merge.  For example, I'm pretty sure the XML sort stuff is fine, it just needs some tests and documentation.  Where as the FASM MUX stuff might need more iterations18:01
mithrolitghost: Yeah, I'm splitting xslt stuff into it's own pull request with some tests18:01
*** adjtm has joined #symbiflow19:31
*** adjtm_ has quit IRC19:33
*** jevinskie has joined #symbiflow20:34
*** jevinskie has quit IRC20:41
*** Bertl is now known as Bertl_oO20:51
*** jevinskie has joined #symbiflow21:07
*** jevinskie has quit IRC21:14
mithrolitghost: Do you know if you can decompose the timing information in the carry block into muxcy / xorcy components?21:23
litghostmithro: That's actually exactly the opposite of what we want to do21:26
litghostmithro: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/72921:26
tpbTitle: [xc7] CARRY4 timing model requires 1 black box · Issue #729 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)21:26
mithrolitghost: for the basic additive model they should be isomorphic, right?21:28
litghostmithro: But they aren't additive, take a look at the timing values21:33
litghostmithro: How do you draw a path from DI0 to CO3 with decompistion21:33
litghostmithro: I don't think you can21:33
mithroDI0 -> CO3= DI0 → MUXCY A → MUXCY B → MUXCY C → MUXCY D → CO321:39
litghostmithro: But looks at the actual values21:43
litghostmithro: How do you decompose the delay values to reconstitute that path21:44
litghostmithro: I don't believe you can21:44
mithrolitghost: You might be right, but I haven't seen proof either way at the moment?21:47
litghostmithro: Why do I need to prove to you why it cannot be done?  Don't you actually need to engage with the problem and see if your suggestion can work here?21:48
litghostmithro: To be clear, I already considered why it can be done in a decompisitional way, and I don't believe it can21:50
mithrolitghost: More I haven't looked at the problem close enough to have a good enough understanding to prove to myself that decomposition won't work and haven't yet seen a good example of how it wouldn't work (but don't currently have time to find that example)21:50
litghostmithro: Then why don't you take my word that I did consider it, and don't believe that avenue is worth considering21:50
mithrolitghost: It would be good to have an understandable explanation of they the decomposition doesn't work (for future reference)21:51
mithrolitghost: Like, I'm 75% sure you are right, I just don't understand why you are right yet and it would be good to document why you are?21:52
litghostmithro: I don't agree.  We always consider alternatives, and prune those choices based on judgement.  We don't exhaustively prove every avenue that doesn't work, in fact doesn't work21:53
litghostmithro: I'm open to a decomposition approach, but I don't see how to get from here to there, and I don't see why it matters one way or another.  And I definitely don't see a reason to prove that decomposition doesn't work21:54
litghostmithro: In fact, the real problems has to do with approximating the change in delay caused by the DI mux, which is totally immaterial to the MUXCY decomposition problem21:56
mithrolitghost: Well, could it be done via adding an extra delay when the mode has the flip flop enabled?21:57
litghostmithro: But is specifically long the AX -> output path, so a straight delay is definitely wrong21:57
litghostmithro: Approximating the delay as an input delay is reasonable per the spreadsheet21:58
litghostmithro: To provide clarity, the S -> FF path delay is not affected by the fanout on the AX -> FF or AX -> ??? path21:59
litghostmithro: So adding an additional delay from the CARRY blackbox to the FF will result in the wrong value21:59
mithrolitghost: If you were able to decompose it horizontally, you could have a <mode "CO0 output"> / <mode "CO0 to FF"> / <mode "CO0 to FF and output"> with different timing?21:59
litghostmithro: I don't think VPR supports routing based modes with a change in blackbox22:00
litghost*without a change in blackbox22:01
litghostmithro: Also the mode would depend on an input routing mux in addition to two output routing muxes22:01
mithrolitghost: The first mode would not have a FF black box, the second mode would not have a CO0 to output pathway and the last mode would have both?22:01
litghostmithro: But the FF isn't part of the carry, it is downstream of the FF input MUX22:02
litghostmithro: So you cannot include the FF inside the mode, without a fairly dramatic mode explosion22:02
mithrolitghost: I think some whiteboarding might help but I'm going back to the thing I'm suppose to be trying to finish :-P22:05
*** Jon_ has quit IRC22:40
*** Bertl_oO is now known as Bertl_zZ23:33
hackerfooFrom looking at RAM36E1, it looks like there are 4 ports, AU, AL, BU, and BL, where U/L share cascade and ECC logic. There are four sets of 15 bit addresses. Maybe it's possible to build a dual-read, dual-write 36K block RAM.23:35
litghosthackerfoo: Unless I'm missing something, that is what the Xilinx documentation explicitly says?23:38
litghosthackerfoo: That is what they mean by "true dual port"23:38
hackerfooI think that's slightly different than two RAM18E1s in SDP mode.23:38
litghosthackerfoo: But it's the same as RAM18E1 in TDP, with double the underlying memory23:39
hackerfooTDP is any combination of two ports, read or write, and SDP is one read + one write, but at twice the width.23:39
litghosthackerfoo: Agreed? And?23:39
litghosthackerfoo: Actually maybe not.  TDP is two read ports and two write ports23:40
hackerfooWhat I'm suggesting is similar to two RAM18E1s in SDP mode, but sharing the same address space.23:40
hackerfooI'm 50/50 on whether it will work or not.23:40
litghosthackerfoo: I think you are just describing normal RAM36E1 TDP mode23:41
litghosthackerfoo: How is it different?23:41
hackerfooThere aren't enough address lines for TDP to do 2 independent reads and 2 independent writes at the same time.23:42
litghosthackerfoo: But each port can do a read or a write (or read/write)23:42
litghosthackerfoo: I don't think what you are thinking works, because AU and AL access a disjoint space23:43
hackerfooThere are 4 sets of address lines in a RAM36E1, which makes sense because they are somehow composed out of two RAM18E1s, each of which have 2 sets of address lines.23:43
litghosthackerfoo: Right, but AU simply accesses the upper half, and AL accesses the lower half23:43
litghosthackerfoo: I don't believe AU can access the lower half of the space23:44
litghosthackerfoo: The high address pins are simply selecting which half gets accessed23:44
hackerfooThat's the question I have, since I didn't see any documentation on the U/L ports.23:46
hackerfooThat makes sense, because it's similar to how it works with distributed RAM.23:46
hackerfooDo all the U/L corresponding pins just get tied together, then?23:49
hackerfooIt looks like it.23:51
hackerfooIs it better to do that in the tech map or the pb_type? Probably the pb_type.23:54

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