| *** tpb has joined #symbiflow | 00:00 | |
| mithro | litghost: What is the status of https://github.com/SymbiFlow/symbiflow-arch-defs/pull/688? | 00:04 |
|---|---|---|
| tpb | Title: file_targets.cmake: correctly handle included files by kgugala · Pull Request #688 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 00:05 |
| *** hzeller has joined #symbiflow | 00:38 | |
| mithro | litghost: Does cmake correctly handle changing of version number for conda dependencies? | 01:04 |
| mithro | litghost: I'm getting `Unexpected command-line argument '--disable_check_route'` | 01:04 |
| litghost | Unclear, I typically get a conda update in that case | 01:13 |
| litghost | Because cmake detects a rule change | 01:13 |
| *** hzeller_ has joined #symbiflow | 01:17 | |
| *** hzeller has quit IRC | 01:20 | |
| *** hzeller_ has quit IRC | 01:33 | |
| hackerfoo | FYI, CI doesn't seem to re-run automatically when something gets merged afterwards that affects it, so arch-defs #678 should break the build: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/97966c24aba60e15686a13effda157a7b1fa9ea1/xc7/tests/dram/CMakeLists.txt#L78 | 01:35 |
| tpb | Title: symbiflow-arch-defs/CMakeLists.txt at 97966c24aba60e15686a13effda157a7b1fa9ea1 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 01:35 |
| hackerfoo | I fixed it in #682 | 01:35 |
| hackerfoo | I'm tired of Conda 504 errors breaking tests. | 01:45 |
| mithro | hackerfoo: It's been a lot more unreliable lately... | 01:50 |
| mithro | hackerfoo: https://docs.anaconda.com/anaconda-repository/admin-guide/install/config/mirrors/mirror-anaconda-repository/ | 01:51 |
| tpb | Title: Mirroring an Anaconda repository Anaconda 2.0 documentation (at docs.anaconda.com) | 01:51 |
| hackerfoo | Or we could fix this: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/564 | 01:52 |
| tpb | Title: cmake -DUSE_CONDA=FALSE is broken · Issue #564 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 01:52 |
| mithro | hackerfoo: Yes, we should also fix that.... | 01:52 |
| mithro | hackerfoo: There is also https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#configure-conda-for-use-behind-a-proxy-server-proxy-servers and https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#offline-mode-only-offline ? | 01:54 |
| mithro | Also https://superuser.com/questions/979800/how-do-i-create-a-local-update-server-for-anaconda-python | 01:54 |
| tpb | Title: repository - How do I create a local update server for Anaconda Python? - Super User (at superuser.com) | 01:54 |
| hackerfoo | Can we list local channels first, so that it will use local packages when present? | 01:56 |
| mithro | hackerfoo: What do you mean? | 01:57 |
| hackerfoo | I'm guessing there's a list of channels in a configuration file from looking at this: https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#offline-mode-only-offline | 01:58 |
| hackerfoo | this: https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#channel-locations-channels | 01:58 |
| mithro | hackerfoo: Yeah | 01:59 |
| hackerfoo | I'm also guessing that they are tried in order, starting from the top. | 01:59 |
| hackerfoo | Ah, yes, it says that. | 02:00 |
| hackerfoo | So if you put a file URL at the top pointing to local packages, it should use those if present. | 02:01 |
| *** hzeller_ has joined #symbiflow | 02:08 | |
| mithro | hackerfoo: https://github.com/enjoy-digital/litescope | 03:50 |
| tpb | Title: GitHub - enjoy-digital/litescope: Small footprint and configurable embedded FPGA logic analyzer (at github.com) | 03:50 |
| *** alexhw has quit IRC | 05:49 | |
| *** alexhw has joined #symbiflow | 05:50 | |
| *** hzeller_ has quit IRC | 05:53 | |
| *** hzeller_ has joined #symbiflow | 06:02 | |
| *** OmniMancer has joined #symbiflow | 06:42 | |
| *** proteusguy has joined #symbiflow | 06:44 | |
| *** proteusguy has quit IRC | 07:13 | |
| *** hzeller_ has quit IRC | 07:19 | |
| *** proteusguy has joined #symbiflow | 07:29 | |
| *** adjtm has quit IRC | 07:44 | |
| *** adjtm has joined #symbiflow | 08:08 | |
| *** GuzTech has joined #symbiflow | 08:50 | |
| sf-slack2 | <acomodi> I think it would be good to rebase upstream VTR master on Symbiflow VTR fork, I am going to open a PR with all the (possible) conflicts solved. In addition I would say that we should do this regularly to keep everything updated and reduce the number of possible conflicts | 08:52 |
| sf-slack2 | <mkurc> I added an issue related to adding "fasm_mux" support to the V2X: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/697 | 09:00 |
| tpb | Title: Add support for "fasm_mux" in "interconnect" to V2X · Issue #697 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 09:00 |
| sf-slack2 | <acomodi> Upstream merge PR is here: https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/49 | 09:19 |
| tpb | Title: Merge upstream by acomodi · Pull Request #49 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 09:19 |
| *** Akorsvang has quit IRC | 09:56 | |
| *** _whitelogger has quit IRC | 10:02 | |
| *** _whitelogger has joined #symbiflow | 10:04 | |
| *** kraiskil has joined #symbiflow | 10:35 | |
| *** futarisIRCcloud has quit IRC | 10:37 | |
| *** proteusguy has quit IRC | 11:17 | |
| *** proteus-guy has joined #symbiflow | 11:17 | |
| *** proteus-guy has quit IRC | 11:34 | |
| *** kraiskil has quit IRC | 12:07 | |
| *** proteusguy has joined #symbiflow | 12:12 | |
| *** OmniMancer1 has joined #symbiflow | 12:16 | |
| *** OmniMancer has quit IRC | 12:16 | |
| *** kraiskil has joined #symbiflow | 12:23 | |
| *** kraiskil_ has joined #symbiflow | 12:44 | |
| *** kraiskil has quit IRC | 12:47 | |
| *** hzeller_ has joined #symbiflow | 14:27 | |
| *** hzeller_ has quit IRC | 14:53 | |
| *** GuzTech has quit IRC | 15:19 | |
| sf-slack2 | <acomodi> opened the PR upstream here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/559 | 15:29 |
| tpb | Title: WIP [DNM]: Equivalent Tiles placement by acomodi · Pull Request #559 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 15:29 |
| *** OmniMancer1 has quit IRC | 15:45 | |
| *** kraiskil_ has quit IRC | 16:22 | |
| sf-slack2 | <acomodi> Good news is that picosoc seems to be working on HW with the equivalent tiles and tile split. Need to double check that though | 16:26 |
| *** kraiskil_ has joined #symbiflow | 16:36 | |
| hackerfoo | acomodi: Nice! | 16:38 |
| *** jevinskie has quit IRC | 17:16 | |
| hackerfoo | Any ideas why bram_shifter.v (https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/bram_shifter/bram_shifter.v) doesn't use block RAM, where `ram0` was copied from bram.v (https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/tests/bram/bram.v) which does use block RAM? | 18:43 |
| tpb | Title: symbiflow-arch-defs/bram_shifter.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 18:43 |
| litghost | hackerfoo: Too deep, that test requires a RAMB36E1, not a RAMB18E1 SDP | 18:45 |
| litghost | hackerfoo: Maybe? | 18:45 |
| litghost | hackerfoo: What does Vivado do? | 18:45 |
| hackerfoo | I'll try it. | 18:45 |
| litghost | hackerfoo: I'm wrong, that should fit | 18:46 |
| hackerfoo | I copied from bram, which uses RAMB18 | 18:48 |
| hackerfoo | Can Vivado load a .pcf file? | 18:52 |
| litghost | hackerfoo: No it uses tcl or xdc (which is tcl like) | 18:53 |
| *** kraiskil_ has quit IRC | 19:29 | |
| *** celadon_ has joined #symbiflow | 20:23 | |
| *** proteusguy has quit IRC | 20:23 | |
| *** celadon has quit IRC | 20:23 | |
| hackerfoo | litghost: Vivado uses a RAMB18E1 for bram_shifter.v | 20:23 |
| litghost | hackerfoo: Okay, so that points to some kind of yosys issue. Check if it's our techmap by doing the standard Yosys flow only | 20:24 |
| hackerfoo | Also, I made this which automatically creates Vivado projects from a list of Verilog files: https://github.com/HackerFoo/hackerfoo-go-functions/blob/master/functions/symbiflow#L45-L145 | 20:27 |
| tpb | Title: hackerfoo-go-functions/symbiflow at master · HackerFoo/hackerfoo-go-functions · GitHub (at github.com) | 20:27 |
| hackerfoo | It's pretty basic, but it works. | 20:27 |
| *** proteusguy has joined #symbiflow | 20:36 | |
| mithro | kgugala / mkurc: Is anyone working on adding fasm metadata output to muxgen at the moment? | 22:07 |
| hackerfoo | litghost: Yosys+Vivado? Do we have anything to automate that? | 22:22 |
| litghost | hackerfoo: I don't believe so | 22:22 |
| litghost | hackerfoo: I know people have done it in the past | 22:22 |
| hackerfoo | Can I just feed top_synth.v into Vivado? | 22:23 |
| litghost | hackerfoo: No, as we've already applied VPR specific transformations | 22:25 |
| litghost | hackerfoo: You have two options | 22:25 |
| litghost | hackerfoo: You can either just use the Vivado path (e.g. don't pass "-vpr" to synth_xilinx and don't apply the xc7 VPR techmap) | 22:25 |
| litghost | hackerfoo: Or you can write a techmap to lower from the VPR specific blackboxes to something Vivado understands | 22:26 |
| litghost | hackerfoo: In theory both paths are equivilant, the first is easier to do | 22:26 |
| hackerfoo | Yeah, the first sounds easier. I'll do that. Thanks. | 22:27 |
| hackerfoo | litghost: `grep RAMB18E1 top.eblif` shows nothing for bram_shifter, but does for bram. I don't think I need Vivado to confirm Yosys isn't working, right? | 22:49 |
| litghost | hackerfoo: Yes. | 22:49 |
| litghost | hackerfoo: I guessed that you take the original verilog (not the post-synth verilog) and confirm Vivado synthesized a BRAM | 22:50 |
| litghost | suggested* | 22:50 |
| hackerfoo | It did. | 22:50 |
| litghost | hackerfoo: I believe you confirmed that bram_shifter under vivado did synth a BRAM, but Yosys | 22:50 |
| litghost | hackerfoo: Right, so that points to something in Yosys doing something different | 22:50 |
| litghost | hackerfoo: It is possible that Yosys made a legal transformation of the underlying design such that a BRAM was no longer required | 22:51 |
| hackerfoo | So I should probably compare logs between bram and bram_shifter? | 22:51 |
| litghost | hackerfoo: For example, if Yosys understood that only the first 64 elements would be accessed, then it might emit LUT-RAM's instead | 22:51 |
| litghost | hackerfoo: Yosys (in theory) will only make legal synthesis transformations, and if you aren't actually using enough of the RAM, it might be superior to synthesis the RAM as a LUT-RAM | 22:52 |
| litghost | hackerfoo: Even if we wanted a BRAM | 22:52 |
| hackerfoo | The design does work on hardware. Maybe I should add more to the initialization. It's just weird, because I copy-pasted from bram. | 22:52 |
| hackerfoo | I would think (* ram_style = "block" *) would force Yosys to use block RAM. | 22:53 |
| litghost | hackerfoo: I believe ram_style is a Verilog extension, and I would not be suprised if Yosys does not respect it | 22:56 |
| litghost | hackerfoo: Ya, a quick grep in Yosys shows that ram_style is not supported | 23:01 |
| litghost | hackerfoo: It's an open question if Yosys should support something akin to ram_style or not, but I believe it effecitively always uses "ram_style = best" | 23:02 |
| hackerfoo | I added more entries to the initialization, and still nothing. Either that doesn't do anything, or Yosys figured out that I'm just overwriting it. | 23:02 |
| hackerfoo | It's just stuffing it all in 8xRAM128X1D. I guess that works. | 23:07 |
| hackerfoo | For 64x16bits | 23:07 |
| hackerfoo | I guess I'll have to use the RAMB18E1 primitive, then. | 23:08 |
| litghost | hackerfoo: Ya | 23:14 |
| litghost | hackerfoo: Did you just inadvertently test RAM128X1D? | 23:17 |
| hackerfoo | I think I know why it's not using block RAM. I'm only using one bit out of each entry. | 23:18 |
| hackerfoo | litghost: I already have a shifter test for RAM128X1D. | 23:18 |
| litghost | hackerfoo: Ah, sure | 23:18 |
| hackerfoo | It's cool that it figured that out, though. 1024x1bit fits in 8xRAM128X1D. | 23:19 |
| mithro | hackerfoo: Yosys can produce edif which Vivado reads | 23:20 |
| mithro | hackerfoo: This python script generates Yosys -> Vivado flow https://github.com/enjoy-digital/litex/blob/master/litex/build/xilinx/vivado.py#L112-L179 | 23:21 |
| tpb | Title: litex/vivado.py at master · enjoy-digital/litex · GitHub (at github.com) | 23:21 |
| mithro | https://www.irccloud.com/pastebin/d9lptH6H/ | 23:22 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 23:22 |
| hackerfoo | I don't think the result would be any different from Yosys+VPR, although it seems Yosys is smarter than Vivado in this case. | 23:23 |
| mithro | hackerfoo: Memory inference is one area that Yosys seems to be better than other tools | 23:23 |
| *** futarisIRCcloud has joined #symbiflow | 23:24 | |
| litghost | hackerfoo/mithro : Vivado was specifically instructed to emit a BRAM, and that is what it did | 23:25 |
| litghost | hackerfoo/mithro: Yosys ignored (and doesn't understand) the instruction | 23:25 |
| hackerfoo | litghost: True. I'll see what happens without the annotation. | 23:26 |
| mithro | I'm not following the full chat - just throwing random comments in... | 23:26 |
| hackerfoo | Vivado still uses RAMB18E1. I don't know whether that's the right choice or not. The answer is probably "it depends." | 23:29 |
| hackerfoo | Although distributed RAM's faster, right? | 23:30 |
| litghost | hackerfoo: Depends | 23:33 |
| litghost | hackerfoo: I believe BRAM is less power efficient? | 23:33 |
| litghost | hackerfoo: And speed is relative to placement | 23:34 |
| hackerfoo | Is there an easier way than {x, x, ... (16 times)} in Verilog to fan out a wire? | 23:47 |
| hackerfoo | Now I'm getting a RAMB18E1. | 23:47 |
| litghost | hackerfoo: Yes! | 23:51 |
| litghost | hackerfoo: https://stackoverflow.com/questions/17192590/whats-the-best-way-to-create-a-mask-knowing-the-number-of-bits | 23:51 |
| tpb | Title: verilog - Whats the best way to create a mask knowing the number of bits? - Stack Overflow (at stackoverflow.com) | 23:51 |
| litghost | hackerfoo: Very usefully, but I never remember the syntax off the top of my head | 23:51 |
| litghost | hackerfoo: I always just google it | 23:51 |
| hackerfoo | litghost: Thanks | 23:52 |
| mithro | litghost: Do I recall you "discovered" that a `<direct>`interconnect doesn't mean "always connected" but is a mux? | 23:54 |
| litghost | mithro: Yes | 23:54 |
| litghost | mithro: With the additional caveat that it was in a "unconnected" blackbox pin | 23:55 |
| mithro | https://www.irccloud.com/pastebin/1cF33CxV/ | 23:55 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 23:55 |
| litghost | mithro: What's the question? | 23:55 |
| mithro | When COMMON_SLICE.AX is used you don't output any FASM features? | 23:55 |
| litghost | mithro: That is currently correct, we do not have the zero feature | 23:56 |
| litghost | mithro: I believe hackerfoo added an issue on this | 23:56 |
| mithro | litghost: You mean it is missing from the prjxray FASM database? | 23:56 |
| hackerfoo | <direct> is more of a switch. | 23:56 |
| litghost | https://github.com/SymbiFlow/prjxray/issues/817 | 23:56 |
| tpb | Title: Add feature for each input of a mux · Issue #817 · SymbiFlow/prjxray · GitHub (at github.com) | 23:56 |
| litghost | hackerfoo: <direct> and <mux> are actually identical under the hood | 23:56 |
| litghost | <mux> has slightly more legilable .net output | 23:57 |
| hackerfoo | That's how I understood it. Does <mux> support being disconnected, then? | 23:58 |
| litghost | hackerfoo: Yes | 23:58 |
| litghost | <mux> can select "nothing" | 23:58 |
| hackerfoo | That seems problematic if the hardware can't do that. | 23:59 |
| litghost | hackerfoo: The output of the mux from VPR's standpoint is "don't care' or "undefined" | 23:59 |
| litghost | hackerfoo: Not really, as long as something isolates the downstream signal | 23:59 |
| litghost | hackerfoo: Which usually happens as soon as the routing fabric is encountered | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!