| *** tpb has joined #symbiflow | 00:00 | |
| hackerfoo | I guess "disconnected" is really VCC or ground, anyway. | 00:01 |
|---|---|---|
| litghost | hackerfoo: No neccesarily :/ | 00:01 |
| litghost | hackerfoo: Ah! | 00:02 |
| litghost | hackerfoo: For muxes internal to the SLICE, there is no way to turn them off | 00:02 |
| litghost | hackerfoo: That is not generally true for outputs from the SLICE | 00:02 |
| hackerfoo | At least, you can't have multiple drivers, where it would be useful to have a high impedance state? | 00:02 |
| litghost | hackerfoo: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_clbll_l.db#L77 | 00:02 |
| tpb | Title: prjxray-db/segbits_clbll_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com) | 00:02 |
| litghost | hackerfoo: In that case, each output of the mux asserts something, so the absence of a mux selection is valid, in which case no FASM feature is written, and the output of the mux is likely supressed | 00:03 |
| litghost | hackerfoo: In terms of internal muxes, they are selecting from one of many inputs, assuming we used "valid" bit patterns, there will not be multiple drivers | 00:04 |
| litghost | hackerfoo: routing muxes are more "exciting" | 00:04 |
| *** hzeller_ has joined #symbiflow | 00:37 | |
| *** hzeller_ has quit IRC | 01:06 | |
| *** hzeller_ has joined #symbiflow | 01:07 | |
| *** futarisIRCcloud has quit IRC | 01:44 | |
| *** hzeller_ has quit IRC | 02:00 | |
| *** futarisIRCcloud has joined #symbiflow | 02:07 | |
| *** hzeller_ has joined #symbiflow | 02:11 | |
| *** Bertl_oO is now known as Bertl_zZ | 03:33 | |
| *** jevinskie has joined #symbiflow | 05:54 | |
| sf-slack2 | <mkurc> @mithro I am working on "adding fasm support to the muxgen". But it is actually more complicated than that. | 06:10 |
| sf-slack2 | <mkurc> @mithro A generated mux does not require fasm features as it is a blackbox which we directly instantiate. | 06:11 |
| *** proteusguy has quit IRC | 06:30 | |
| sf-slack2 | <mkurc> @mithro We rather require support for generating 'mux' in 'interconnect' with fasm features. | 06:32 |
| *** hzeller_ has quit IRC | 07:06 | |
| *** jevinskie has quit IRC | 07:12 | |
| *** OmniMancer has joined #symbiflow | 07:14 | |
| *** jevinskie has joined #symbiflow | 07:14 | |
| *** kraiskil_ has joined #symbiflow | 07:30 | |
| *** celadon_ has quit IRC | 09:16 | |
| *** celadon has joined #symbiflow | 09:25 | |
| *** celadon_ has joined #symbiflow | 09:35 | |
| *** celadon has quit IRC | 09:36 | |
| *** Bertl_zZ is now known as Bertl | 09:46 | |
| *** Vonter has quit IRC | 10:25 | |
| *** Vonter has joined #symbiflow | 10:26 | |
| *** kraiskil_ has quit IRC | 10:29 | |
| *** futarisIRCcloud has quit IRC | 10:47 | |
| *** kraiskil_ has joined #symbiflow | 11:18 | |
| *** celadon_ has quit IRC | 13:08 | |
| *** celadon has joined #symbiflow | 13:09 | |
| *** kraiskil__ has joined #symbiflow | 13:26 | |
| *** kraiskil_ has quit IRC | 13:29 | |
| *** proteusguy has joined #symbiflow | 14:09 | |
| *** hzeller_ has joined #symbiflow | 14:24 | |
| *** hzeller_ has quit IRC | 14:34 | |
| *** Bertl is now known as Bertl_oO | 14:49 | |
| litghost | Mux gen can generate both logic and routing muxs | 14:52 |
| mithro | mkurc: litghost is correct | 15:00 |
| mithro | mkurc: Do you have an example of what you think needs to be solved? | 15:00 |
| *** hzeller_ has joined #symbiflow | 15:05 | |
| *** kraiskil__ has quit IRC | 15:10 | |
| *** hzeller_ has quit IRC | 15:30 | |
| *** hzeller_ has joined #symbiflow | 15:49 | |
| *** kraiskil__ has joined #symbiflow | 16:15 | |
| *** hzeller_ has quit IRC | 16:18 | |
| *** hzeller_ has joined #symbiflow | 16:22 | |
| *** hzeller_ has quit IRC | 17:02 | |
| *** jevinskie has quit IRC | 17:34 | |
| sf-slack2 | <mkurc> @mitho @litghost I created a document describing my proposal for V2X routing muxes: https://docs.google.com/document/d/12a79JCkSdCoZ0D-fz8Vguk8CSsg46VzdABIc72P-sao | 17:48 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 17:48 |
| sf-slack2 | <mkurc> There is an example of verilog code and resulting pb_type.xml inside | 17:49 |
| *** OmniMancer has quit IRC | 17:55 | |
| litghost | mkurc: I'm very confused, I believe mithro is work on the routing muxes, https://github.com/SymbiFlow/symbiflow-arch-defs/pull/703 | 17:57 |
| tpb | Title: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 17:57 |
| elms | mithro: digshadow: I'm looking at running https://github.com/SymbiFlow/fpga-tool-perf again. I already have started running some locally. Any pointers on setting it up for regular automated runs in the cloud? | 18:11 |
| tpb | Title: GitHub - SymbiFlow/fpga-tool-perf: FPGA tool performance profiling (at github.com) | 18:11 |
| digshadow | elms: TBH the biggest issue was that it was a pain to get all of the tools licensed | 18:12 |
| digshadow | I made a token effort at trending type stuff, but I don't think it was really finished | 18:13 |
| elms | digshadow: ok I remember some discussion and thought that's sort of where it was left. | 18:15 |
| *** jevinskie has joined #symbiflow | 18:15 | |
| elms | I think I'll try running all non-licensed and then start with licensed less often locally. The results for those shouldn't really change. | 18:16 |
| sf-slack2 | <kgugala> @litghost: as @mkurc started working on the muxgen stuff @mithro wanted him to contribute to the #703 | 18:16 |
| mithro | kgugala: Hrm? | 18:18 |
| digshadow | mithro: shared a gdoc with you about state of 2064 development. If at least the IOB bitstream question looks good I'll send that to ken for comment | 18:18 |
| mithro | digshadow: Mind if I put it in the SymbiFlow shared public folder? | 18:19 |
| sf-slack2 | <kgugala> @mithro maybe I got wrong impression? You pinged as here yesterday and later @mkurc in the issue | 18:19 |
| mithro | kgugala: I send @mkurc an FYI that I was working on the routing mux FASM stuff | 18:20 |
| sf-slack2 | <kgugala> Ah | 18:20 |
| sf-slack2 | <kgugala> So can we help with it? | 18:21 |
| sf-slack2 | <kgugala> Or you want to finish it yourself? | 18:21 |
| mithro | kgugala: I'm going to finish it off today | 18:21 |
| litghost | I believe mkurc had started on the FASM feature and FASM prefix stuff, and I was requesting additional design documentation on that | 18:21 |
| litghost | mkurc also had a little bit on the FASM LUT annotations | 18:22 |
| sf-slack2 | <kgugala> @mithro: great | 18:22 |
| mithro | I was under the impression that mkurc was working on *other* FASM attribute stuff | 18:22 |
| digshadow | mithro: sure move it as you wish | 18:22 |
| digshadow | and I will delete mine if needed | 18:22 |
| digshadow | i'll stop editing | 18:23 |
| sf-slack2 | <mkurc> I took task related to FASM support to V2X. And support for "fasm_mux" in interconnects was there. And i made a proposal how I see the solution. | 18:24 |
| litghost | mkurc: FYI, I do like the shape of your FASM_MUX solution | 18:27 |
| litghost | mkurc: However I do think there was some confusion that mithro was going to tackle that particular annotation | 18:28 |
| mithro | FYI - https://github.com/SymbiFlow/symbiflow-arch-defs/milestone/2 | 18:29 |
| tpb | Title: Use v2x for XML generation Milestone · GitHub (at github.com) | 18:29 |
| sf-slack2 | <mkurc> @litghost Thanks | 18:30 |
| sf-slack2 | <mkurc> @mithro @litghost BTW I answered your comments in #685 | 18:31 |
| sf-slack2 | <mkurc> I am concerned about the solution proposed in #703. It requires having a pb_type with only `<interconnect>/<mux>` inside (no child pb_types). It is not clearly stated in the VPR doc but according to @acomodi findings this is illegal. | 18:36 |
| sf-slack2 | <mkurc> If a pb_type does not have child pb_types then it is concidered as a leaf and cannot have the <interconnect> inside. | 18:36 |
| litghost | mkurc: I believe this is legal, but it generates warnings. Example: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/primitives/slicem/slicem.pb_type.xml#L219 | 18:38 |
| tpb | Title: symbiflow-arch-defs/slicem.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 18:38 |
| *** hzeller_ has joined #symbiflow | 18:51 | |
| sf-slack2 | <mkurc> @litghost Interesting. If it is legal than we can proceed with approach in #703 | 18:56 |
| *** hzeller_ has quit IRC | 18:57 | |
| *** kraiskil__ has quit IRC | 19:26 | |
| *** kraiskil__ has joined #symbiflow | 19:53 | |
| *** _whitelogger has quit IRC | 20:26 | |
| *** _whitelogger has joined #symbiflow | 20:28 | |
| mithro | litghost / mkurc: Yes it is legal but not great, I'm just adding some code to v2x to "lower" routing muxes into the pb_type interconnect for now | 20:43 |
| litghost | mithro: Sounds good to me | 20:44 |
| *** tmichalak has joined #symbiflow | 21:00 | |
| hackerfoo | Is there any interest in the XC7 block RAM FIFO modes? https://github.com/SymbiFlow/symbiflow-arch-defs/issues/709 | 21:01 |
| tpb | Title: Implement block RAM FIFO{18,36}E1 primitives · Issue #709 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:01 |
| *** futarisIRCcloud has joined #symbiflow | 21:14 | |
| *** kraiskil__ has quit IRC | 22:20 | |
| hackerfoo | litghost: Do you think it would make sense to break the block RAMs in half the way we did with DPRAM32? There are two symetrical halves that only share the memory array. | 22:23 |
| litghost | hackerfoo: I don't think so. The routing graph actually treats them seperately | 22:24 |
| litghost | hackerfoo: You'd have to prove that the routing graph is the same for each black box | 22:24 |
| litghost | hackerfoo: Which would be exciting | 22:24 |
| hackerfoo | litghost: Okay. Maybe I'll think about that later. | 22:25 |
| digshadow | mithro: ken added comments to the XC2064 doc. So basically 1) IOB is incomplete 2) no bitstream to verilog support, although some (partial?) work was done on bitstream to netlist 3) no XC2018 support from ken | 23:27 |
| digshadow | which roughly matches my expectations | 23:27 |
| mithro | digshadow: Guess I was dreaming | 23:32 |
| mithro | digshadow: Ahh yeah - maybe it was bitstream to netlist (rather than bitstream to verilog) | 23:32 |
| mithro | might be worth poking cr1901_modern in ##openfpga | 23:33 |
| hackerfoo | I'm curious: why the XC2064? Because it's simple? | 23:34 |
| mithro | hackerfoo: Yeah | 23:34 |
| mithro | It's also real hardware | 23:34 |
| hackerfoo | It *was* real hardware. | 23:35 |
| hackerfoo | Although I see you can still get them, but not through DigiKey. | 23:35 |
| *** Bertl_oO is now known as Bertl_zZ | 23:43 | |
| hackerfoo | Is there a test that infers dist. RAM? I want to test inferring RAM32X1D. | 23:53 |
| hackerfoo | Otherwise I'll write a quick ram_shifter test. | 23:54 |
| litghost | I want to say both murax and picosoc prefer RAM32X1D over RAM64X1D due to their register sizes | 23:54 |
| hackerfoo | Thanks, I'll try it. | 23:55 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!