<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.
proteusguy has joined #symbiflow
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #symbiflow
Bertl_oO is now known as Bertl_zZ
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #symbiflow
<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.
kraiskil has joined #symbiflow
felix_ has quit [Ping timeout: 252 seconds]
felix_ has joined #symbiflow
JuanP has joined #symbiflow
<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?
<JuanP> Note: the code obviously does nothing interesting here
<daveshah> You mean the config is different?
kraiskil has quit [Ping timeout: 244 seconds]
kraiskil has joined #symbiflow
<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
<daveshah> All FPGA tools have different mapping rules, optimisations, heuristics, etc
<daveshah> It would be exactly the same as a diff between the assembly produced by gcc and Visual C++, for example
<JuanP> yes the bitstreams are different. So it is a normal behavior then
<JuanP> the bottom line being: fpga are difficult to code for because there may be something hidden by the manufacturer still
<daveshah> As I say, this is exactly the same as almost any other toolchain - software or fpga
<daveshah> Different toolchains will do different optimisations, have different mapping rules, etc
<daveshah> FPGA placement and routing is perhaps even more complicated due to the use of heuristics like SA that depend on pseudo random decisions
<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?
<JuanP> (you get the compoenent names but that's it)
kraiskil has quit [Ping timeout: 258 seconds]
<daveshah> You can go into physical view and enable the view of all the wires etc
<daveshah> There are some toolbar buttons that toggle
<JuanP> got it. it works. Was lookig at the floorplan. FINE! David, you are a wondeful person
JuanP has left #symbiflow [#symbiflow]
citypw has quit [Ping timeout: 258 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 268 seconds]
kraiskil has joined #symbiflow
Bertl_zZ is now known as Bertl
kraiskil has quit [Ping timeout: 244 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 252 seconds]
<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
<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
<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.
<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
kraiskil has joined #symbiflow
<sf-slack2> <mkurc> Great!
<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.
celadon has quit [Quit: ZNC 1.7.2+deb2 - https://znc.in]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
celadon has joined #symbiflow
Bertl is now known as Bertl_oO
citypw has joined #symbiflow
<sf-slack2> <acomodi> chain_packing test works on HW with equivalent tiles
kraiskil has quit [Read error: Connection reset by peer]
citypw has quit [Ping timeout: 258 seconds]
JuanP has joined #symbiflow
<JuanP> @Davesha: I did the compilation again and Diamond showed a clock of 350ishMHz while trellis showed 630ishMHz. That is impressive
<daveshah> Probably good luck on such a small design. Usually Yosys&nextpnr is ~20-30% behind Diamond
<JuanP> Yes I will throw a proper one soon and we will see. But overall I am very happy that this project exists.
<JuanP> Sorry I misspelled your name Dave
<JuanP> Bye
JuanP has quit [Quit: Page closed]
Maya-sama has joined #symbiflow
Miyu has quit [Ping timeout: 245 seconds]
Maya-sama is now known as Miyu
<elms> acomodi: Awesome!
<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.
<hackerfoo> elms: The "kokoro:force-run" tag should cause a PR to run again.
<mithro> kgugala / acomodi: I have some stuff around v2x stuff
<mithro> Currently in a meeting then need to pack with chicago, will try and get back to you ASAP
<sf-slack2> <kgugala> @mithro can you take a look on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/639
<tpb> Title: v2x dsp_in_registered test fix by kgugala · Pull Request #639 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <kgugala> this adds multiple instance handling to v2x
<sf-slack2> <kgugala> it's not complete though - we still need to update pb_num in included xmls
kraiskil has joined #symbiflow
<mithro> kgugala: I'm just packing, I'll be back in 2-3 hours
<sf-slack2> <kgugala> @mithro sure, just ping me here or in the PR
<hackerfoo> Can we use the ARM cores on the ZYBO? It seems like they would be good for driving tests in hardware.
<sf-slack2> <kgugala> @hackerfoo we still miss info how the core connects to the logic
<sf-slack2> <kgugala> to be more precise which PS pin goes to which PIP
<sf-slack2> <kgugala> also, we need yosys update so it can handle PS instance
<sf-slack2> <kgugala> + arch.xml and routing graph update
<sf-slack2> <kgugala> I agree this would be a great way of testing things
kraiskil has quit [Read error: Connection reset by peer]
<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.
<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.
<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
<tpb> Title: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <kgugala> hackerfoo: I think @mkurc may shed some light on it
<tpb> Title: Moved techmaps from Yosys to SymbiFlow by mkurc-ant · Pull Request #390 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
kraiskil has joined #symbiflow
<sf-slack2> <mkurc> @hackerfoo This should not have any effect unless you have DRAM writes on negedge of clock in your design.
<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.
<sf-slack2> <mkurc> @hackerfoo You are probably right, it should be passed as for all other DRAM types
<sf-slack2> <mkurc> @hackerfoo I'll check tomorrow whether it has any influence on the FASM output.
<tpb> Title: Make sure IS_WCLK_INVERTED is passed for all DRAM types · Issue #640 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
kraiskil has quit [Read error: No route to host]
adjtm has quit [Read error: Connection reset by peer]
adjtm has joined #symbiflow
<hackerfoo> ^ I think this means DI2 affects O6, not DI1.
<tpb> Title: Make v2x produce the new composable interconnect specification again (IE Revert #637). · Issue #642 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> kgugala / acomodi: Hopefully you are asleep right now and will see that in the morning
<mithro> hackerfoo: I confirm I would be suspicious
<tpb> Title: symbiflow-arch-defs/ntemplate.N_dram.model.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<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....
digshadow has joined #symbiflow
<mithro> hackerfoo: You might want to ask digshadow about this
tpb has quit [Remote host closed the connection]
<mithro> hackerfoo: I believe he wrote the initial fuzzers
tpb has joined #symbiflow
<digshadow> Hi hackerfoo. Whats your question?
<hackerfoo> digshadow: from the picture above of Vivado's routing of a RAM32X1S, it seems it's using DI2 for the input and O6 as the output.
<hackerfoo> This seems to contradict information in the arch-defs repo.
<digshadow> What is conflicting? Which is input vs output? How the pins are assigned? What does arch-defs have?
<hackerfoo> It's more of an observation at this point. I'm going to try to change the definitions to get VPR to route it the same way.