| *** tpb has joined #symbiflow | 00:00 | |
| hackerfoo | Does anyone else typically have to remove the `build` directory in symbiflow-arch-defs after pulling in changes? It might only be when updating a submodule. | 00:26 |
|---|---|---|
| *** proteusguy has joined #symbiflow | 00:27 | |
| *** citypw has quit IRC | 01:57 | |
| *** citypw has joined #symbiflow | 03:04 | |
| *** Bertl_oO is now known as Bertl_zZ | 03:32 | |
| *** citypw has quit IRC | 06:17 | |
| *** citypw has joined #symbiflow | 06:30 | |
| sf-slack2 | <mkurc> @hackerfoo I do it occasionally. It seems that submodules are updated only when running `make env` in the root. You can try running `make env` without removing the `build` directory. | 07:06 |
| *** kraiskil has joined #symbiflow | 07:38 | |
| *** felix_ has quit IRC | 07:50 | |
| *** felix_ has joined #symbiflow | 07:51 | |
| *** JuanP has joined #symbiflow | 09:05 | |
| JuanP | Hi, I compiled a verilog file and diff occur between trellis ans diamond. Here is the pastebin: https://pastebin.com/2WVEXMtm. is is normal? | 09:06 |
| JuanP | Note: the code obviously does nothing interesting here | 09:06 |
| daveshah | You mean the config is different? | 09:07 |
| *** kraiskil has quit IRC | 09:07 | |
| *** kraiskil has joined #symbiflow | 09:08 | |
| daveshah | Coming up with the optimal mapping from Verilog to a place-and-routed design is hard (ie effectively impossible) and there may be more than one optimal solution anyway | 09:08 |
| daveshah | All FPGA tools have different mapping rules, optimisations, heuristics, etc | 09:09 |
| daveshah | It would be exactly the same as a diff between the assembly produced by gcc and Visual C++, for example | 09:09 |
| JuanP | yes the bitstreams are different. So it is a normal behavior then | 09:20 |
| JuanP | the bottom line being: fpga are difficult to code for because there may be something hidden by the manufacturer still | 09:21 |
| daveshah | As I say, this is exactly the same as almost any other toolchain - software or fpga | 09:25 |
| daveshah | Different toolchains will do different optimisations, have different mapping rules, etc | 09:25 |
| daveshah | FPGA placement and routing is perhaps even more complicated due to the use of heuristics like SA that depend on pseudo random decisions | 09:26 |
| JuanP | I get it perfectly. BTW, Diamond doesn't show all the wires a device is made of, does it? i mean, in Diamond, no overall view of the wires connecting one tile/slice/mux to one another, If yes, how did you achieve to get their names and position? | 09:29 |
| JuanP | (you get the compoenent names but that's it) | 09:30 |
| *** kraiskil has quit IRC | 09:30 | |
| daveshah | You can go into physical view and enable the view of all the wires etc | 09:33 |
| daveshah | There are some toolbar buttons that toggle | 09:33 |
| JuanP | got it. it works. Was lookig at the floorplan. FINE! David, you are a wondeful person | 09:36 |
| *** JuanP has left #symbiflow | 09:38 | |
| *** citypw has quit IRC | 10:03 | |
| *** kraiskil has joined #symbiflow | 10:26 | |
| *** kraiskil has quit IRC | 10:57 | |
| *** kraiskil has joined #symbiflow | 11:17 | |
| *** Bertl_zZ is now known as Bertl | 11:48 | |
| *** kraiskil has quit IRC | 12:45 | |
| *** kraiskil has joined #symbiflow | 13:27 | |
| *** kraiskil has quit IRC | 13:59 | |
| sf-slack2 | <acomodi> I think I spotted the issue with the equivalent tiles: I have added a workaround to get the correct slice to be added as prefix during the `fasm` generation. The workaround basically extracts the meta of the equivalent tile's slice. The issue was that the in the database (specifically in tile_type_CLB*.json), the SLICE sites are not ordered (e.g. in CLBLM SLICE X0Y0 is the first, while in CLBLL, SLICE X1Y0 is the | 14:04 |
| sf-slack2 | first). This means that the `placement_index` of a `pb_graph_node` that I have used in genfasm was not consistent between equivalent tiles | 14:04 |
| sf-slack2 | <acomodi> I think that once the tiles are split, the issue will be no more. I have temporarily swapped the order of the SLICEs in the tile_type_CLB*.json files to be all consistent one another and verify that this was the issue. | 14:06 |
| sf-slack2 | <acomodi> confirmed! the issue was the one described above. `simple_ff` test is working with equivalent tiles. I am going to check all the tests now | 14:14 |
| *** kraiskil has joined #symbiflow | 14:16 | |
| sf-slack2 | <mkurc> Great! | 14:16 |
| sf-slack2 | <mkurc> Regarding the CLB tile split: I've written code which splits CLBs to "specialized" SLICE tiles (eg. CLBLL_L_SLICEL_X0Y0) and generates wire and pip mapping between CLB and SLICE tiles. Those specialized SLICEs will be converted to generic SLICEs when generating the `arch.xml`. Progressing with the integration with the rest of the prjxray import flow. | 14:18 |
| *** celadon has quit IRC | 14:22 | |
| *** futarisIRCcloud has quit IRC | 14:22 | |
| *** celadon has joined #symbiflow | 14:23 | |
| *** Bertl is now known as Bertl_oO | 14:48 | |
| *** citypw has joined #symbiflow | 15:01 | |
| sf-slack2 | <acomodi> chain_packing test works on HW with equivalent tiles | 15:18 |
| *** kraiskil has quit IRC | 15:26 | |
| *** citypw has quit IRC | 16:05 | |
| *** JuanP has joined #symbiflow | 16:10 | |
| JuanP | @Davesha: I did the compilation again and Diamond showed a clock of 350ishMHz while trellis showed 630ishMHz. That is impressive | 16:11 |
| daveshah | Probably good luck on such a small design. Usually Yosys&nextpnr is ~20-30% behind Diamond | 16:13 |
| JuanP | Yes I will throw a proper one soon and we will see. But overall I am very happy that this project exists. | 16:14 |
| JuanP | Sorry I misspelled your name Dave | 16:15 |
| JuanP | Bye | 16:15 |
| *** JuanP has quit IRC | 16:15 | |
| *** Maya-sama has joined #symbiflow | 16:27 | |
| *** Miyu has quit IRC | 16:30 | |
| *** Maya-sama is now known as Miyu | 16:31 | |
| elms | acomodi: Awesome! | 16:45 |
| sf-slack2 | <acomodi> elms: Yep, I still need to run all the tests. In the meanwhile I have started a picosoc build. Hopefully, In about an hour the bitstream should be available. | 16:50 |
| elms | mithro: is there a way to rerun a build on kokoro? specifically a conda install failed https://source.cloud.google.com/results/invocations/bcf1bf0f-320d-454c-aba9-964b5ab06b65/targets/foss-fpga-tools%2Fsymbiflow-arch-defs%2Fpresubmit%2Fxc7/log | 16:52 |
| hackerfoo | elms: The "kokoro:force-run" tag should cause a PR to run again. | 17:00 |
| mithro | kgugala / acomodi: I have some stuff around v2x stuff | 17:08 |
| mithro | Currently in a meeting then need to pack with chicago, will try and get back to you ASAP | 17:08 |
| sf-slack2 | <kgugala> @mithro can you take a look on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/639 | 17:09 |
| tpb | Title: v2x dsp_in_registered test fix by kgugala · Pull Request #639 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 17:09 |
| sf-slack2 | <kgugala> this adds multiple instance handling to v2x | 17:09 |
| sf-slack2 | <kgugala> it's not complete though - we still need to update pb_num in included xmls | 17:10 |
| *** kraiskil has joined #symbiflow | 17:16 | |
| mithro | kgugala: I'm just packing, I'll be back in 2-3 hours | 18:13 |
| sf-slack2 | <kgugala> @mithro sure, just ping me here or in the PR | 18:14 |
| hackerfoo | Can we use the ARM cores on the ZYBO? It seems like they would be good for driving tests in hardware. | 18:21 |
| sf-slack2 | <kgugala> @hackerfoo we still miss info how the core connects to the logic | 18:22 |
| sf-slack2 | <kgugala> to be more precise which PS pin goes to which PIP | 18:22 |
| sf-slack2 | <kgugala> also, we need yosys update so it can handle PS instance | 18:22 |
| sf-slack2 | <kgugala> + arch.xml and routing graph update | 18:23 |
| sf-slack2 | <kgugala> I agree this would be a great way of testing things | 18:23 |
| *** kraiskil has quit IRC | 18:39 | |
| elms | hackerfoo: I recall it being easy to load a bitstream from the ARM core, but yeah interacting once loaded is a little tricky. Once we understand the PS interconnect or maybe we could have it as part of a test harness. | 18:42 |
| hackerfoo | I guess it won't happen any time soon, then. It would be nice to have the board cycle through a bunch of tests, since it's probably at least 1000x faster than simulation and more accurate, although generating bitstreams will still be slow, so maybe it doesn't matter much. | 19:04 |
| hackerfoo | Any idea why this line isn't `.IS_WCLK_INVERTED(IS_WCLK_INVERTED)` as it is elsewhere? https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/techmap/cells_map.v#L497 | 20:30 |
| tpb | Title: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:30 |
| sf-slack2 | <kgugala> hackerfoo: I think @mkurc may shed some light on it | 20:34 |
| elms | hackerfoo: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/390 | 20:48 |
| tpb | Title: Moved techmaps from Yosys to SymbiFlow by mkurc-ant · Pull Request #390 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:48 |
| *** kraiskil has joined #symbiflow | 20:51 | |
| sf-slack2 | <mkurc> @hackerfoo This should not have any effect unless you have DRAM writes on negedge of clock in your design. | 21:07 |
| sf-slack2 | <mkurc> @hackerfoo According to the documentation of Xilinx primitive library there is no `.IS_WCLK_INVERTED` parameter in the `RAM32X1D` primitive. Nor there is in any other DRAM primitives. | 21:07 |
| sf-slack2 | <mkurc> @hackerfoo You are probably right, it should be passed as for all other DRAM types | 21:08 |
| sf-slack2 | <mkurc> @hackerfoo I'll check tomorrow whether it has any influence on the FASM output. | 21:10 |
| hackerfoo | mkurc: Thanks. https://github.com/SymbiFlow/symbiflow-arch-defs/issues/640 | 21:11 |
| tpb | Title: Make sure IS_WCLK_INVERTED is passed for all DRAM types · Issue #640 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:11 |
| *** kraiskil has quit IRC | 22:11 | |
| *** adjtm has quit IRC | 23:33 | |
| *** adjtm has joined #symbiflow | 23:34 | |
| * hackerfoo uploaded an image: di2.jpg (85KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/TTolIpydInbNswIWQifhFqoo > | 23:45 | |
| hackerfoo | ^ I think this means DI2 affects O6, not DI1. | 23:46 |
| mithro | @kgugala + @acomodi - FYI - https://github.com/SymbiFlow/symbiflow-arch-defs/issues/642 | 23:50 |
| tpb | Title: Make v2x produce the new composable interconnect specification again (IE Revert #637). · Issue #642 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:50 |
| mithro | kgugala / acomodi: Hopefully you are asleep right now and will see that in the morning | 23:51 |
| mithro | hackerfoo: I confirm I would be suspicious | 23:52 |
| hackerfoo | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/primitives/slicem/Ndram/ntemplate.N_dram.model.xml#L67-L68 | 23:53 |
| tpb | Title: symbiflow-arch-defs/ntemplate.N_dram.model.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:53 |
| mithro | hackerfoo: Yeah, that potentially looks wrong (I'm not 100% confident that Vivado isn't lying in some way) but I'm not sure what effect incorrect model definitions would have.... | 23:57 |
| *** digshadow has joined #symbiflow | 23:59 | |
| mithro | hackerfoo: You might want to ask digshadow about this | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!