Bertl_oO is now known as Bertl_zZ
<hackerfoo> Has anyone seen this error from VPR? Primitive 'FDRE_ZINI' not recognized by netlist writer
<hackerfoo> Maybe it's a flip flop that's not implemented.
<hackerfoo> I'll just comment things out until it compiles.
<hackerfoo> Nevermind. I got it to work.
<hackerfoo> Check it out, I made a memory tester. It works, even: https://gist.github.com/HackerFoo/060598d144e7ca3f6115cc584b21ab81
<tpb> Title: mem_tester.v · GitHub (at gist.github.com)
<hackerfoo> It reads and writes from a shift register (from switches to leds) and uses the dual port ram as a double buffer, so flipping SW0 swaps the pages.
<mithro> I don't understand why netlistsvg is choosing such a bad position for the DLUT and other similar parts
<hackerfoo> D must be routed incorrectly for RAM32X1D. Even setting `.D(1'b0)` still streams out a repeating pattern of 1100 regardless of the initial contents. WE works, though, and I'm guessing the address lines work because I do get a pattern.
<mithro> file:///usr/local/google/home/tansell/github/SymbiFlow/symbiflow-arch-defs/build/xc7/primitives/slicel/slicel.flat.svg https://usercontent.irccloud-cdn.com/file/AvgSmZ0Q/image.png
<hackerfoo> RAM32X1S also seems broken when using my tester. Is that expected?
<hackerfoo> RAM64X1S and RAM64X1D both work.
citypw has joined #symbiflow
<mithro> hackerfoo: Your big on nix stuff right? Might want to checkout https://git.m-labs.hk/M-Labs/HeavyX
<tpb> Title: M-Labs/HeavyX: Next-generation FPGA SoC toolkit - M-Labs Git (at git.m-labs.hk)
<tpb> Title: M-Labs/HeavyX: Next-generation FPGA SoC toolkit - eda/vivado.nix at master - M-Labs Git (at git.m-labs.hk)
<hackerfoo> mithro: I hadn't seen that, thanks.
<hackerfoo> I was using this for Vivado. They also have a .nix for MiGen: https://github.com/lukaslaobeyer/nix-fpgapkgs
<tpb> Title: GitHub - lukaslaobeyer/nix-fpgapkgs: Nix channel with FPGA development tools (at github.com)
<mithro> hackerfoo: He is the guy who did the really cool assembly assistant thingy -> https://github.com/lukaslaobeyer/assemblyassist
<tpb> Title: GitHub - lukaslaobeyer/assemblyassist: Assistance for manually placing large numbers of components on a circuit board, as efficiently as possible. (at github.com)
_whitelogger has joined #symbiflow
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
celadon has quit [Quit: ZNC 1.7.2+deb2 - https://znc.in]
celadon has joined #symbiflow
rvalles has joined #symbiflow
citypw has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #symbiflow
duck2 has quit [Quit: The Lounge - https://thelounge.chat]
Bertl_zZ is now known as Bertl
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #symbiflow
proteusguy has quit [Ping timeout: 255 seconds]
<sf-slack2> <acomodi> litghost: v2x PR should be all right. The xc7 CI failed because of an issue in fasm2bels which is solved by https://github.com/SymbiFlow/symbiflow-arch-defs/pull/605
<tpb> Title: fasm2bels: hotfix after graph2.py changes by acomodi · Pull Request #605 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
proteusguy has joined #symbiflow
<sf-slack2> <acomodi> litghost: I have also corrected and added documentation on PR https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/36, I will continue working on that. First thing is to solve genfasm issue when creating FASM lines of equivalent tiles.
proteusguy has quit [Ping timeout: 258 seconds]
OmniMancer has quit [Quit: Leaving.]
proteusguy has joined #symbiflow
<sf-slack2> <acomodi> I have a question about the conda environment: I do not why but the Miniconda.sh file is downloaded multiple times when building targets in symbiflow arch-defs. What could be the issue with that? Here there is a pastebin of the issue https://pastebin.com/xRSXgP5e
<tpb> Title: [100%] Generating env/Miniconda3-4.5.12-Linux-x86_64.sh --2019-04-17 15:39:51-- - Pastebin.com (at pastebin.com)
<litghost> Check the modified timestamp. Make sure it is when the file was downloaded
<litghost> I wonder if wget is writing some other time
<sf-slack2> <acomodi> well, weirdly it says that Miniconda*.sh was downloaded on the 2nd of January 2019
citypw has joined #symbiflow
<sf-slack2> <mkurc> @litghost I modified prjxray import scripts so that now all pips (including pseudo and bidirectional) are imported to the channels.db. I made a PR: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/604
<tpb> Title: Import of all pips (bidirectional and pseudo) to channels.db by mkurc-ant · Pull Request #604 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <acomodi> litghost: this is Miniconda*.sh file stat https://pastebin.com/UQuGED7x
<tpb> Title: stat Miniconda3-4.5.12-Linux-x86_64.sh File: Miniconda3-4.5.12-Linux-x86_64. - Pastebin.com (at pastebin.com)
<sf-slack2> <mkurc> @litghost BTW the arch defs CI is failing even on master. We need to merge https://github.com/SymbiFlow/symbiflow-arch-defs/pull/605
<tpb> Title: fasm2bels: hotfix after graph2.py changes by acomodi · Pull Request #605 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> Was waiting for green
<sf-slack2> <kgugala> @litghost @mithro do you have any preference how sdfs should land in the DB folder?
<litghost> We talked about starting to add subdirectories
<sf-slack2> <kgugala> additional timings folder with all the sdfs inside should do the job
<litghost> Probably a good time to start
<sf-slack2> <kgugala> cool, so let it be a subdir
Bertl is now known as Bertl_oO
Vonter_ has joined #symbiflow
<sf-slack2> <acomodi> I think the issue with genfasm and equivalent tile types is a little bit harder than I first thought. The problem is that genfasm walks the `pbs` to get the `metadata`. Unfortunately, a `SLICEM` has different `modes` and `metas` (AFAIK) making my idea of a solution unfeasible.
Vonter has quit [Read error: Connection reset by peer]
<sf-slack2> <acomodi> In fact, I was thinking to retrieve the correct `metadata` of the `equivalent tile` by traversing the pb_graph structure from the top tile down to the primitive, but the issue is: how can I traverse the graph and get the correct `meta` if, for instance, a SLICEM has different `modes` and children `pb_types` w.r.t. SLICEL?
duck2 has joined #symbiflow
<sf-slack2> <acomodi> If this issue makes sense and is real (maybe I am missing something), do you have an idea on how to proceed?
<sf-slack2> <mkurc> On my side: I am currently progressing with the CLB split. I added new tile types to the SQL database. I also wrote code that inserts those new types to the VPR grid instead of CLBs. Tomorrow I will start with pips and pins relocation.
<litghost> Equivalent tiles should have equivalent fasm
<litghost> The prefix will move to the tile once the split is complete
<sf-slack2> <acomodi> Ok, so I guess this is not such a huge issue as I thought after all
citypw has quit [Ping timeout: 244 seconds]
<sf-slack2> <acomodi> litghost: I also got the results of the titan benchmarks for the `mode_selection` feature. Here's vaughnbetz comment on the comparison results: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issuecomment-484147091
<tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <acomodi> litghost, mithro: I think I need some suggestions to compose a high level comment to the mode selection feature. One of the things that is not fully clear to me is why was this feature needed in the first place.
<litghost> acomodi: It handles bugs in mode selection in the packer
<litghost> acomodi: So my contribution is specifically about the idea that all edges have to come from the same mode
<litghost> acomodi: This applies in two cases
<litghost> acomodi: When VPR is picking route through wires is 1
<tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<litghost> acomodi: Which is detecting invalid packing as a result of conflicting modes
<litghost> acomodi: The general theme of the PR is handling edge cases where it is possible to construct mode trees that the packer could select invalid combinations
<litghost> acomodi: In our case like packing a LUT, there is a top level DRAM vs LUT mode
<litghost> acomodi: If the packer chooses the LUT mode for the LUT and DRAM mode for the DRAM, the cluster is invalid
<litghost> acomodi: The previous could would ASSERT in that case
<litghost> acomodi: The new code reports a cluster conflict, and either trys the next mode (which may work) or eventually starts a new cluster
<sf-slack2> <acomodi> litghost: Ok, so, just to be sure, in the previous code the LUT mode for LUT and DRAM for DRAM it ended up in an assertion error, which now is correctly handled. Is this correct?
<sf-slack2> <acomodi> litghost: Anyway, thanks, I will pack all this information in a high level comment and update the PR description
<litghost> acomodi: Ya
_whitelogger_ has joined #symbiflow
_whitelogger has quit [Ping timeout: 240 seconds]
<sf-slack2> <acomodi> litghost, mithro: I have updated the high level comment, please double-check if it is correct https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issue-264647785
<tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<mithro> acomodi: I'm a bit concerned by the increase in pack time...
<sf-slack2> <acomodi> mithro: I will double-check again the code (making it a triple-check I guess :)) and analyze which are the most time consuming steps. It seems odd also to me that the pack time increased by a non-negligible amount.
<sf-slack2> <acomodi> anyway, I have solved with a workaround the genfasm issue for the equivalent tiles and tried `chain_packing_test` on HW. I have seen that all the carry chains have been placed in CLBLMs instead of CLBLLs and well, by testing on HW there are good and bad news.
<mithro> acomodi: The packer should preference the most "populous" tile type first?
<sf-slack2> <acomodi> good news is that nothing broke and something happened. Bad news is that only one carry chain out of 8 is blinking.
<sf-slack2> <acomodi> mithro: Yeah, I actually "forced" the placer to use CLBLMs to check if everything still worked on HW.
<mithro> acomodi: Ahh okay
<sf-slack2> <acomodi> mithro: I am still dealing with the placer algorithm in order to let him choose the best configuration based both on "populousity" (I don't know if that is the correct word) and timing as well
<sf-slack2> <acomodi> litghost: PR https://github.com/SymbiFlow/symbiflow-arch-defs/pull/316 is now green on CI
<tpb> Title: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> acomodi: Thanks, still some outstanding review ocmments
Maya-sama has joined #symbiflow
Miyu has quit [Read error: Connection reset by peer]
Maya-sama is now known as Miyu
<sf-slack2> <mkurc> @litghost I have a question regarding the CLB split: Are we aiming at having a top-level SLICE tile with a single SLICE site inside? Or at having a top-level SLICE tile with all content of the former SLICE site ?
<litghost> First
<litghost> mkurc: SLICEL tile contains SLICEL site
<litghost> mkurc: Today the CLBLL_L contains two SLICEL sites, right
<sf-slack2> <mkurc> @litghost Ok, thanks
tux3 has quit [Remote host closed the connection]
tux3 has joined #symbiflow
Vonter_ has quit [Ping timeout: 246 seconds]
Vonter has joined #symbiflow
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow