Thursday, 2019-05-02

« Wednesday, 2019-05-01 Index Friday, 2019-05-03 »
*** tpb has joined #symbiflow00:00
*** futarisIRCcloud has joined #symbiflow00:38
*** hzeller has joined #symbiflow00:39
*** space_zealot has joined #symbiflow01:18
*** mats has quit IRC01:29
*** hzeller has quit IRC01:58
*** mats_ has joined #symbiflow02:03
hackerfooCheck this out: https://docs.verilogtorouting.org/en/latest/tutorials/arch/xilinx_virtex_6_like/02:21
hackerfooThey just flattened the muxes! I was thinking about that, but it introduces some invalid configurations.02:24
hackerfooCan I list multiple FASM features? e.g. SLICEM_MODES.DI = BDI1MUX.DI ADI1MUX.BDI102:34
hackerfooIt doesn't complain, at least.02:46
*** Bertl_oO is now known as Bertl_zZ03:16
*** space_zealot has quit IRC04:55
*** jevinskie has joined #symbiflow05:10
*** hzeller has joined #symbiflow05:10
*** hzeller has quit IRC05:15
*** citypw has quit IRC05:23
*** jevinski_ has joined #symbiflow05:47
*** jevinskie has quit IRC05:48
*** kraiskil has joined #symbiflow06:31
*** jevinskie has joined #symbiflow07:25
*** jevinski_ has quit IRC07:25
*** kraiskil has quit IRC07:36
*** OmniMancer has joined #symbiflow07:42
*** kraiskil has joined #symbiflow07:48
*** auscompgeek has quit IRC07:56
*** auscompgeek has joined #symbiflow07:56
*** Vonter has quit IRC07:57
*** Vonter has joined #symbiflow08:00
*** GuzTech has joined #symbiflow08:20
*** kraiskil has quit IRC08:53
*** OmniMancer1 has joined #symbiflow09:16
*** futarisIRCcloud has quit IRC09:17
*** OmniMancer has quit IRC09:19
*** futarisIRCcloud has joined #symbiflow10:15
*** kerel_ has joined #symbiflow10:26
*** rvalles_ has joined #symbiflow10:27
*** rvalles has quit IRC10:27
*** kerel has quit IRC10:27
*** Bertl_zZ is now known as Bertl10:55
*** kraiskil has joined #symbiflow11:17
sf-slack2<kgugala> @mithro @litghost https://github.com/SymbiFlow/symbiflow-arch-defs/pull/639#issuecomment-48863501511:25
tpbTitle: reenable v2x dsp tests by kgugala · Pull Request #639 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)11:25
*** rvalles_ is now known as rvalles11:29
*** jevinskie has quit IRC12:20
*** jevinskie has joined #symbiflow12:24
*** GuzTech has quit IRC15:06
*** OmniMancer1 has quit IRC15:08
litghostelms: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/551#issuecomment-48871035515:16
tpbTitle: PVT corner timing models · Issue #551 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)15:16
litghostelms: Looks like kmurray is also thinking along the same lines as you about an explicit split15:16
*** hzeller has joined #symbiflow15:45
*** jevinskie has quit IRC16:09
*** jevinskie has joined #symbiflow16:09
*** lethalbit has quit IRC16:10
*** lethalbit has joined #symbiflow16:11
*** tux3 has quit IRC16:41
*** tux3 has joined #symbiflow16:41
*** futarisIRCcloud has quit IRC16:47
*** acomodi has joined #symbiflow16:48
*** hzeller has quit IRC16:56
*** tux3 has quit IRC17:13
*** tux3 has joined #symbiflow17:13
*** tux3 has quit IRC17:19
*** tux3_ has joined #symbiflow17:19
*** tux3 has joined #symbiflow17:20
*** tux3_ has quit IRC17:26
litghosthackerfoo: I'm relatively sure that https://docs.verilogtorouting.org/en/latest/tutorials/arch/xilinx_virtex_6_like/ is just plain wrong17:40
litghosthackerfoo: So I wouldn't use it as a reference17:41
litghosthackerfoo: Can I list multiple FASM features? -> Yes, but I'm not sure when that is valid17:41
litghosthackerfoo: Can you explain what you are trying to do with "BDI1MUX.DI ADI1MUX.BDI1"?17:41
litghosthackerfoo: Because I'm pretty sure it's wrong17:41
hackerfooI'm trying to flatten two chained muxes into one, since I don't think VTR supports chaining things together.17:43
hackerfooI understand why they have this limitation, to prevent combinatorial explosion in the interconnect.17:43
hackerfooMy current approach is to just see if this works for now, and then add support for parallel muxes to VTR later.17:44
litghosthackerfoo: Cascaded muxes do work, you just cannot connect them directly, you need to pass through an intermediate pb_type17:45
hackerfooIf muxes could switch multiple signals in parallel, I could properly flatten the two muxes into a single parallel one.17:45
litghosthackerfoo: Why do you need to mux multiple singles at all?17:46
litghosthackerfoo: The underlying structure in this case is always N to 1 muxes17:46
litghostsignals*17:46
hackerfooBut then the connection information would be lost, right? You'd have to explicitly instantiate the intermediate pb_type, so VPR could no longer make that decision by itself.17:47
litghosthackerfoo: Can you make a diagram? I don't think I get what you are trying to model17:47
litghosthackerfoo: I believe you are trying to model the fact that the ADI1MUX uses the output of the BDI1MUX17:48
litghosthackerfoo: The solution is for the output of the BDI1MUX to go through the B LUT-RAM intermediate, and then connect to the ADI1MUX17:48
litghosthackerfoo: This is what the PARENT_DI stuff was about17:49
hackerfooYeah, give me a minute.17:49
hackerfooI want to allow VPR to make the decision, instead of forcing it.17:49
litghosthackerfoo: There is no forcing?  You are still just modelling the BDI1MUX and the ADI1MUX, yes?17:50
mithrolitghost: So, I'm now generating an arch.xml with v2x which includes the pb_type.xml / model.xml -- what would be the best way to run vpr on it to test the arch.xml is valid?17:54
hackerfooRather than saying, for instance, DI goes to D_DRAM.DI and B_DRAM.DI when they implement a dual port RAM, I want VPR to see that they share an input, and route it through DI, setting BDI1MUX.DI17:54
litghostmithro: Simplest test?  PnR a wire17:54
hackerfooThis should work fine, since there's only one mux.17:54
hackerfooBut I want it to work the same for the lower half.17:54
mithrolitghost: Yes, but how do I do that in the cmake?17:55
litghostmithro: Same way you write any test that PnR's, use add_fpga_target17:55
litghosthackerfoo: I think you would agree that the CDI1MUX and BDI1MUX can be modelling with simply a <mux> interconnect block, yes?17:56
litghostmodelled*17:56
hackerfooThe problem with the flattened mux is if VPR wants A_DRAM.DI to connect to DI amd B_DRAM.DI to BI, that would be invalid, but VPR won't know that.17:56
hackerfooYes.17:57
litghosthackerfoo: Don't use the flattened mux?17:57
litghosthackerfoo: Have ADI1MUX mux ADI1 and the output of the BDI1MUX17:57
litghosthackerfoo: In order to use the output of the BDI1MUX, you have to pass it through an intermediate pb_type, but that's fine17:58
hackerfooBut then, how does VPR know when to get A_DRAM.DI from BDIMUX? The previous solution was to force it with the modes, which worked except in 32 bit mode.17:59
litghosthackerfoo: Just re-write the mux without the modes18:00
litghosthackerfoo: The previous implementation was based on a bad understanding of the underlying hardware18:00
hackerfooThere's a bunch of ways to do it that *almost* work.18:01
hackerfooBut since the tutorial uses the flattening approach, I'm guessing that that way is the least broken, so I'm just going to try it.18:01
litghosthackerfoo: The tutorial is wrong18:01
litghosthackerfoo: Ignore the tutorial18:02
litghosthackerfoo: It is modelling something like a v618:02
hackerfooI don't have a better solution.18:02
hackerfoov6 has the same arrangement.18:02
litghosthackerfoo: But that tutorial isn't actually designed to run on hardware18:02
litghosthackerfoo: So it can add flying elphanets and still be a valid tutorial18:02
hackerfooMaybe I should ask on #vtr?18:03
litghosthackerfoo: It isn't actually a model of the real hardware18:03
hackerfooIf their own example doesn't work, we should let them know, at least.18:04
litghosthackerfoo: Their example works fine, but it isn't actually modelling a real piece of silicon18:04
litghosthackerfoo: It is modelling a fictous similiar piece of hardware18:05
litghosthackerfoo: You have to understand, VTR was never design to operate on real hardware18:05
litghosthackerfoo: It is a research tool for hypothetical FPGA's18:05
hackerfooThat's not what it says: https://docs.verilogtorouting.org/en/latest/tutorials/arch/xilinx_virtex_6_like/18:05
hackerfooIn order to demonstrate the expressiveness of the architecture description language, we use it to describe a section of a commercial logic block. In this example, we describe the Xilinx Virtex-6 FPGA logic slice [Xilinx Inc12], shown in Fig. 40, as follows:18:06
litghosthackerfoo: And what does the title say: "Virtex 6 like"18:07
litghosthackerfoo: Their model does not accurately represent the ADI1MUX behavior18:07
litghosthackerfoo: And it should be obvious that is the case!18:07
litghosthackerfoo: Their description of the SLICEM can output something the hardware cannot model, therefore it is wrong, period18:08
litghosthackerfoo: As a concrete example, their model does not correctly model that the D LUT-RAM must be enabled for the C/B/A LUT-RAM's to be used18:09
hackerfooAnyway, I could fix it if it weren't for this:18:09
* hackerfoo uploaded an image: Screenshot from 2019-05-02 11-00-50.png (17KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/lxSgwKzRitxuNinyaBzvPUwN >18:09
litghosthackerfoo: You are more than welcome to submit a PR to VTR to fix that, but that seems unnessecary.  Cascaded mux's are supported18:10
hackerfooI want to avoid introducing another stub.18:13
litghosthackerfoo: I'm not sure why you think a stub is required?  Maybe I don't understand what you mean by a stub18:13
mithrolitghost: So it seems to get cmake to use an arch.xml I have to call DEFINE_ARCH, DEFINE_DEVICE_TYPE, DEFINE_DEVICE, ADD_FPGA_TARGET?18:13
litghostmithro: In a word, yes18:14
litghostmithro: But why not just latch this off of the testarch?18:14
litghostmithro: Testarch already has those setup18:14
litghostmithro: And it feels like testarch is the natural place to put this stuff18:14
mithrolitghost: I'm just trying to run model.xml / pb_type.xml generated from v2x through vpr to check that it is valid18:15
hackerfooI'm guessing there's no way to tie muxes together?18:15
litghosthackerfoo: You can cascade a mux through an intermediate type18:16
litghosthackerfoo: Linking mux choices is not supported, except through modes18:16
litghosthackerfoo: And VPR cannot switch modes based soley on routing discessions18:16
mithrolitghost: I have a script which generates an arch.xml with exactly 1 tile, a wrapper around the pb_type and enough IBUF / OBUF18:17
litghostmithro: Then you'd need to make an arch, etc, if you want to use the existing stuff18:17
litghostmithro: You could always write your own add_custom_target and invoke VPR directly18:17
litghostmithro: If you already have an arch.xml, an eblif, and don't need a custom rrgraph18:18
litghostmithro: But that flow is very different than a architecture pack/place/route18:18
litghostmithro: Also, for wire.eblif to work, you need a route through lut18:20
litghostmithro: With only 1 tile, I assume not all of them will have a ".names" subckt18:21
mithroI have an eblif already18:21
litghostmithro: Sure18:21
litghostmithro: If you want to invoke VPR directly, you'll need to write that yourself18:21
mithrookay, I think I'll do that18:23
* hackerfoo uploaded an image: Screenshot from 2019-05-02 11-14-47.png (96KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/PyWdToQzlbVenAHvLrHMbfTz >18:23
litghosthackerfoo: The middle mux isn't legal and the bottom mux is wrong if the mux selector isn't the same18:26
litghosthackerfoo: The top mux should be able to be modelled, so I don't know what the problem is18:27
hackerfooYes, I know, hence the question about linking muxes.18:27
hackerfooWith real muxes, you'd just tie the selection lines together.18:27
litghosthackerfoo: VPR doesn't support that idea18:28
hackerfooDon't we work on VPR, though? Does it support any form of constraints other than modes?18:28
hackerfooAnyway, the architecture definition was already wrong, so I'm just going to see if I can make it almost correct for now, and see if it works.18:30
litghosthackerfoo: As I stated earlier, you are more than welcome to start on a PR for linked muxes or muxes of bus's18:30
hackerfooThen I can add what I need to VPR later.18:30
hackerfoolitghost: Okay. Thanks.18:31
litghosthackerfoo: I believe what was there before could never get into trouble because the techmap output a configuration that was always valid18:32
litghosthackerfoo: It consumed the BI1 pin when it didn't need too, but wasn't invalid on hardware18:32
litghosthackerfoo: I'm ignoring the RAM32 of course18:32
*** Bertl is now known as Bertl_oO18:42
*** acomodi has quit IRC18:58
*** lopsided98 has quit IRC19:00
*** lopsided98 has joined #symbiflow19:02
*** hzeller has joined #symbiflow19:59
*** kraiskil has quit IRC20:00
litghosthackerfoo: kem_ is active on #vtr-dev if you want to poke him about the mux stuff20:44
hackerfooOkay. I didn't want to bother -dev with a user question, but #vtr is pretty quiet.20:45
hackerfooThere's no ADIMUX.BDI1 fasm feature? It's not listed in the documentation.21:11
litghosthackerfoo: There is not.  The absence of ADI1MUX.ADI1 is either BDI1 or MC3121:18
litghosthackerfoo: Presumably MC31 is controlled via the SRL bit21:18
litghosthackerfoo: But we don't have evidence of that at this minute21:18
hackerfooThen I guess we don't need to worry about the chained mux problem right now, since we can't configure them that way yet.21:20
litghosthackerfoo: That doesn't follow?21:24
litghostADI1 can be either AX, BX, or DX, yes?21:24
litghostADI1 can only come BX if BDI1 = BX21:24
litghostand ADI1 can only become DX if BDI1 = DX21:24
litghostAm I missing something?21:24
hackerfooNo, ADIMUX selects AI, BDI1, and BMC31.21:25
hackerfooSo this is also probably why RAM128X1D doesn't (didn't?) work.21:26
hackerfooUntil we figure that bit out, RAM128X1D and RAM256X1S will have to use AI.21:27
litghosthackerfoo: I wasn't talking about ADIMUX, I was talking about the effective ADI1 connection, which can be either AX, BX or DX21:28
litghosthackerfoo: s/X/I/21:29
hackerfooOh, okay. I get it. Currently, ADI1MUX.AI = 0 ==> BDI1?21:29
litghostADI1 can be AI, BI or DI21:29
litghosthackerfoo: Yes, ADI1MUX.AI = 0 ==> BDI121:29
hackerfooRight.21:29
litghosthackerfoo: BDI1 can be either BI or DI based on the state of BDI1MUX21:30
hackerfooI see. I forgot that the default isn't DI for ADI1MUX, like the others, so the default is BDI1.21:31
hackerfooIt would be nice if the other inputs were defined to make it easier to read, and to detect conflicts.21:33
litghostOther formatS?21:33
hackerfooSo that if VPR emits fasm that switches a mux multiple ways, it would get caught instead of just picking the non-default.21:35
hackerfooThere seems to be a lot of silent failure in our toolchain.21:36
hackerfooI got all the shifter tests working again.21:38
litghosthackerfoo: This particular case could be addressed in several ways.  It is illegal to write FASM like:21:38
litghostFEATURE_A = 121:38
litghostFEATURE_A = 021:38
litghostAnd it is illegal to write:21:38
litghostFEATURE_A = 121:38
litghostFEATURE_B = 121:38
litghostWhere those features result in conflicting bits21:38
litghostIn pretty much all cases, we can write the mux statement to generate that sort of conflict21:39
hackerfooAh. That's probably why elms was suggesting `:`, so it would be `<input> : <feature> = <value>`.21:39
litghosthackerfoo: not really, the code in VPR to handle : is the same as =21:40
litghosthackerfoo: "<feature> = 1" and "<feature>" are the same statement21:40
hackerfooOh. Can't we define a feature for each input? So e.g. CDI1MUX.DI is defined to set the bit to 0?21:41
litghosthackerfoo: It's probably better to fix the fuzzer to emit a "zero feature"21:42
litghosthackerfoo: Which defines "all bits cleared"21:42
litghosthackerfoo: Example: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_bram_l.db#L321:42
tpbTitle: prjxray-db/segbits_bram_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com)21:42
litghosthackerfoo: And then the mux will assert those bits are cleared21:42
litghosthackerfoo: It also will then show up in bit2fasm output21:43
litghosthackerfoo: FEATURE = 0 will disappear in a round trip FASM -> bit -> FASM21:43
litghosthackerfoo: Zero features will appear21:43
litghosthackerfoo: Zero features added to the fuzzers until after the xDI fuzzer was written21:43
hackerfooAt least for muxes, that would be nice, so the FASM is easier to read.21:44
litghosthackerfoo: Agreed.  The current metadata was written for an MVP, which we do in fact have21:44
hackerfooSure. If I create an issue, should it be in prjxray?21:45
litghostYes, because we need the segbit database to be updated first21:46
litghostxDI fuzzer is https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/019-clb-ndi1mux/generate.py21:46
tpbTitle: prjxray/generate.py at master · SymbiFlow/prjxray · GitHub (at github.com)21:46
litghosthttps://github.com/SymbiFlow/prjxray/issues/347 is also relevant21:46
hackerfooThanks21:46
tpbTitle: dbfixup: automatically create .dbf files · Issue #347 · SymbiFlow/prjxray · GitHub (at github.com)21:46
litghostAs .dbf files are how zero features are defined21:46
litghostExample DBF file to go with the link I sent: https://github.com/SymbiFlow/prjxray/blob/master/fuzzers/060-bram-cascades/bits.dbf21:47
tpbTitle: prjxray/bits.dbf at master · SymbiFlow/prjxray · GitHub (at github.com)21:47
hackerfooNow I need to fix 2xRAM128X1S not getting packed together.21:55
litghosthackerfoo: What error are you getting?  I may have found a bug a packer change we made, and have a PR with a fix21:55
hackerfooWhen running "make dram_2_128x1s_assert_usage", both CLBLM_R and L are used.21:57
hackerfooAssertionError: Expect usage of block CLBLM_L = 0, found 121:57
litghosthackerfoo: Before you debug too far, make sure that Vivado packs them correctly21:57
hackerfooOkay, I'll check.21:57
litghosthackerfoo: Correctly is the wrong term, but as we are asserting21:57
hackerfooI should check master, too.21:58
litghosthackerfoo: Yep21:58
hackerfooIt works on master. Is there a list of the Kokoro tests somewhere?22:00
litghosthackerfoo: "make all_xc7"22:01
litghosthackerfoo: Not really22:01
hackerfooThanks22:01
litghosthackerfoo: Right now most of our tests are just targets22:01
litghosthackerfoo: Kokoro runs "make all_xc7"22:02
litghosthackerfoo: I recommend a "-j" of roughly CPU/4 and RAM/10 GB22:02
litghostMaybe RAM/5 GB22:02
litghosthackerfoo: I run "-j16" and it doesn't chew all my ram22:03
hackerfooI'll do that after I fix 128x1s22:05
litghosthackerfoo: Oh and kokoro is just running whatever is in https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/.github/kokoro/xc7.sh22:05
tpbTitle: symbiflow-arch-defs/xc7.sh at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:05
hackerfooI updated my PR if you want to look at the changes.22:06
litghosthackerfoo: To notify you want a re-review, just request a new review22:06
litghosthackerfoo: It's the little recycle icon next to me name22:07
hackerfooI meant just if you're curious. I still have a bit more work to do before it's ready for a proper review. Thanks.22:08
litghosthackerfoo: Ah, ok22:08
litghosthackerfoo: Probably need a huge "this may emit invalid configurations!!!!" warning22:10
litghosthackerfoo: For giggles, you can manually add the zero DB entries to prjxray-db and use those22:10
litghosthttps://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_clblm_l.db#L35222:11
tpbTitle: prjxray-db/segbits_clblm_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com)22:11
litghostSo22:12
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.AI 00_0022:12
litghostCLBLM_L.SLICEM_X0.BLUT.DI1MUX.BI 00_2022:12
litghostBecomes22:12
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.AI 00_0022:12
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.DI !00_00 !00_2022:12
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.BI !00_00 00_2022:12
litghostCLBLM_L.SLICEM_X0.BLUT.DI1MUX.BI 00_2022:12
litghostCLBLM_L.SLICEM_X0.BLUT.DI1MUX.DI !00_2022:12
litghostThis won't prevent VPR from outputing an invalid configuration, but would allow fasm2frames to generate it error when it happens22:13
litghostAnother probably better configuration would be :22:15
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.AI 00_0022:15
litghostCLBLM_L.SLICEM_X0.ALUT.DI1MUX.BDI1 !00_0022:15
litghostCLBLM_L.SLICEM_X0.BLUT.DI1MUX.BI 00_2022:15
litghostCLBLM_L.SLICEM_X0.BLUT.DI1MUX.DI !00_2022:15
litghostAnd have the fasm_mux line have two features22:15
hackerfooYeah. I wouldn't want to control both muxes with one feature. VPR would just set both features.22:18
hackerfooThat's what I wrote at first.22:19
litghostDid it work, except for the fact that ALUT.DI1MUX.BDI1 isn't defined?22:20
litghoste.g. did VPR output the right feature?22:20
hackerfooI didn't hit any of the multiple feature inputs, if that's what you're asking about. I should try that.22:22
litghosthackerfoo: I'd recommend adding routing tests for them22:23
litghosthackerfoo: E.g. a case in https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/tests/dram22:24
tpbTitle: symbiflow-arch-defs/xc7/tests/dram at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:24
litghosthackerfoo: I believe all of the ones in https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/tests/dram use seperate D lines22:24
tpbTitle: symbiflow-arch-defs/xc7/tests/dram at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:24
litghosthackerfoo: We probably want common D lines, and in an ideal world would check the state of the DI muxes to verify the "right" thing happened22:25
hackerfooWhy? Internally all the dual port and >64 modes use shared DI.22:26
hackerfooI'm interested in how RAM1X32S works when using O5.22:28
hackerfooIt would have to connect CX/DX externally, I think.22:28
litghosthackerfoo: The current tests in https://github.com/SymbiFlow/symbiflow-arch-defs/tree/master/xc7/tests/dram all use seperate D lines, so anything packed into C/B/A will use their AI mux, rather than the common DI line22:30
tpbTitle: symbiflow-arch-defs/xc7/tests/dram at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:30
hackerfoolitghost: No, not the dual port or >64 bit ones, because they are composed of multiple DPRAM32/64s sharing inputs.22:31
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/dram/dram_2_64x1d.v#L24 is in[13] and https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/dram/dram_2_64x1d.v#L46 is in[12]22:32
tpbTitle: symbiflow-arch-defs/dram_2_64x1d.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:32
litghostSo for it work correctly, the second RAM64X1D needs to use BI rather than DI (or be packed into a second SLICEM)22:33
hackerfoohttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/techmap/cells_map.v#L645-L68322:33
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)22:33
litghostI'm talking about the level above that22:33
litghoste.g. two instances of RAM64X1D can either share or have different D lines22:34
litghostIf the D lines are common, then all of the xDI1MUX's should use the DI site pin22:34
hackerfooIf they work independently, they should work shared. Primitives should be independent.22:34
litghostNot true22:34
litghostHave vivado pack two RAM64X1D's with common D lines, but different INIT's22:35
litghostThe DI line will be the only site pin, BI will not be used22:35
litghostFor clarify, when I say DI, I mean the SLICEM.DI site pin22:35
hackerfooI see. You want to make sure VPR takes advantage of the internal muxes even across primitives.22:36
litghostYes22:36
litghostIt actually causes some errors in fasm2v if we don't22:36
litghostbecause Vivado will take advatange, even if VPR didn't22:36
*** proteusguy has quit IRC22:36
litghostAnd I don't think we can control it22:36
mithrolitghost: I have some comments around the implicit dff stuff, will try and comment a bit later tonigh22:40
litghostmithro: k22:41
litghostmithro: I'm interested how you are planning to solve things like FASM tagging implicitly.  I'm not sure you can22:41
hackerfooApparently, if you list FASM features separated by spaces, they just get concatenated.23:00
litghosthackerfoo: We generally eat whitespace23:01
litghosthackerfoo: In this case, it prevented a natural extension23:01
mithroHow do you do the equivalent of "basename" in cmake?23:01
litghostget_filename_component23:01
litghosthackerfoo: I would be open to <pin> : <feature>, <feature>23:02
litghostwhich would allow for <pin>:<feature>=2,<feature> ,etc23:02
litghosthackerfoo: And wouldn't require a large extension to the VPR FASM parser (which is brick stupid)23:02
mithrolitghost: What about "basename xyz.xml .xml" ? (IE strip extensions?)23:03
litghostmithro: Same, still get_filename_component23:03
litghostmithro: It's overloaded23:03
hackerfoolitghost: Whatever works. I don't think writing architecture descriptions in XML is ever going to be pleasant. Luckily, it shouldn't be a common task.23:05
litghosthackerfoo: The good news is v2x in theory is replacing right these XML's by hand, and I think that will be more extensible than this23:06
hackerfooI don't mind verbosity, but I don't like how VPR just seems to take reasonable-looking stuff and do unexpected things with it without complaining.23:07
hackerfoo"X = Y\n X = Z\n" doesn't work either. No error, though.23:09
litghosthackerfoo: Not sure what you mean?  Anything in the metadata tags is our code, so don't blame VPR for that23:09
hackerfooWhere's the parser?23:09
litghosthttps://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/utils/fasm/src/fasm.cpp23:10
tpbTitle: vtr-verilog-to-routing/fasm.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)23:10
litghosthackerfoo: genfasm is seperate from the rest of VPR, but we need their internal data structures for now23:11
litghosthackerfoo: It's possible with the work that duck2 is doing, we can just parse the VPR outputs without libvpr, but that isn't something on the main line23:11
hackerfooWow, that really is a simple parser. It just splits on = and :, and expects two items.23:14
hackerfooOh well, I don't need that now.23:14
litghosthackerfoo: I did say it was dumb as bricks23:15
hackerfooThe surprising part is that it eats spaces. I figured if it didn't fail, it would work.23:16
litghosthackerfoo: The eating of spaces is intentional, but it probably shouldn't eat interior spaces23:17
hackerfooThe same thing for repeated inputs, where it only uses the first one.23:18
litghosthackerfoo: But it is important to do something like python's "str.strip()" to avoid leading and trailing white space23:18
hackerfooSomething like http://re2c.org or a hand-rolled tokenizer would take care of that.23:19
tpbTitle: re2c re2c 1.1.1 documentation (at re2c.org)23:19
litghosthackerfoo: We do like inside VPR, and so new dependencies are not really good ideas.  Fixing the space issue with a parse doesn't actually solve the "using only the first mux entry", which is probably just a bug23:20
litghostlive*23:20
hackerfooIt doesn't have to be that complicated: https://github.com/HackerFoo/poprc/blob/master/tok.c23:20
tpbTitle: poprc/tok.c at master · HackerFoo/poprc · GitHub (at github.com)23:20
*** Bertl_oO is now known as Bertl_zZ23:20
hackerfooBut, yeah, not now.23:21
hackerfooThe cool thing about re2c is that it doesn't add dependencies, it generates C from regular expressions. I haven't tried it yet, though.23:23
hackerfooBut it's probably overkill for this.23:23
litghosthackerfoo: There is a pass of FASM error check that is probably worth doing.  Something like lint_fasm, that would check for fasm_mux issues like this23:24
litghosthackerfoo: For example, there should be a fasm_mux for each input to the mux23:24
litghosthackerfoo: And no entries for non-existent inputs23:24
litghosthackerfoo: etc etc23:24
hackerfooFrom looking at output_fasm_mux, I bet it doesn't handle FOO[0].BAR[1]23:28
litghostIt does I believe23:29
litghostLemme go look around23:29
litghosthttps://github.com/SymbiFlow/symbiflow-arch-defs/blob/6d5640672f41eb2d048f65b97b2d7d028b1e1d03/ice40/devices/top-routing-virt/tiles/pio/pio.pb_type.xml#L4623:29
tpbTitle: symbiflow-arch-defs/pio.pb_type.xml at 6d5640672f41eb2d048f65b97b2d7d028b1e1d03 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)23:30
litghostThat's what "parse_name_with_optional_index" handles23:30
hackerfooI meant two levels of indexing, since there's only one index for each side in the code.23:30
litghosthackerfoo: Ya, it would explode23:32
*** space_zealot has joined #symbiflow23:32
litghosthackerfoo: But not fail silently23:32
litghostAh, I remember23:33
litghostIt splits the two VPR parts23:33
litghostSo it is parsing FOO[0] into "FOO" and 023:33
litghostSo it does work23:34
litghostI remember needing support for that, so I remember testing it23:34
hackerfooWhere does the 0 go? Assuming it reads 1 as the index in "FOO[0].BAR[1]".23:36
litghostmux_pb_index and mux_pin_index23:37
hackerfooSo it would read it as "FOO[0] = BAR[1]"? Then "FOO[0].BAR[1] = BAZ" would fail, I guess, because it would see 3 parts.23:38
litghostYou aren't reading the code23:40
litghostIt splits on "=:" first23:40
litghostSo part[0] is "FOO[0].BAR[1] " and part[1] is "BAZ"23:40
litghostThen it is split FOO[0] / BAR[1]23:40
litghostThen parsed into (FOO, 0), (BAR 1)23:41
litghostThat part is fine23:41
litghostThe handling of the right hand side of the parse is less than ideal if we intended to support multiple FASM features23:41
litghostleft hand side is actually okay23:41
hackerfooAh, I see. vtr_parts != mux_parts. My mistake.23:42
litghostYa23:43
« Wednesday, 2019-05-01 Index Friday, 2019-05-03 »

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