00:01 <sf-slack> <timo.callahan> @kgugala @pzierhoffer, do you know if the tflite zephyr magic wand demo has been tested on the Arty board at your end recently? I tried going through the demo again just now -- the Renode sim worked as expected, but so far I haven't been able to get any reaction out of the actual HW board, not even "Angle" (L) shape. That *did* work for me the first time I went through the demo, a couple of months ago. Of

00:01 <sf-slack> course my accelerometer might have gone bad or something like that. But just wondering if you'd tested on an Arty board recently. Thanks!

00:02 <sf-slack> <timo.callahan> P.S. I do get the "4 bytes lost due to alignment...." and "Got accelerometer..." messages, just nothing after that from the board.

02:56 <sf-slack> <timo.callahan> @kgugala I did find a bug in Edalize around passing synth options to Yosys. I'll report it on their github.

04:26 <sf-slack> <kgugala> @timo.callahan are you talking about the bug from Wednesday? I already fixed it and opened a PR in edalize

04:27 <sf-slack> <kgugala> as for the demo - it is important to hold the board correctly so the accelerometer axis are oriented as the neural network model expects

05:37 <sf-slack> <timo.callahan> @kgugala Ah, I see the PR at edalize, thank you!

11:22 <tnt> So, I've been trying to build the quicklogic toolchain for the past 4hours or so. I don't want conda anywhere near me so I added -DUSE_CONDA=false. Also it seems a lot of the dependencies are only needed for XC7 which I couldn't care less about so I've tried stripping most of theses. And finally I don't want anything to do with nodejs either which I'm hoping is optional.

11:22 <tnt> Now I'm hit with "PYTHON3_TARGET is empty for target env, check target definition." and I'm not even sure what PYTHON3_TARGET is supposed to store.

12:26 <tnt> Huh so after many efforts, the 'make file_build_quicklogic_techmap_cells_sim.v' worked ... and generated ./techmap/cells_sim.v ...

12:26 <tnt> and then what ?

13:40 <shapr> daveshah: I'm sad to hear about lattice trying to prevent reverse engineering, is there some effort to describe to them how much that will hurt their business?

14:27 <shapr> is there some effort to create an explicit open-ness agreement with an FPGA vendor?

14:27 <shapr> I'd expect Intel to open up Altera completely

14:45 <HackerFoo> tnt: This might help with `-DUSE_CONDA=FALSE`: https://github.com/HackerFoo/nix-symbiflow/blob/master/patches/symbiflow-arch-defs.patch

14:45 <tpb> Title: nix-symbiflow/symbiflow-arch-defs.patch at master · HackerFoo/nix-symbiflow · GitHub (at github.com)

15:28 <tnt> HackerFoo: yeah, I managed to get it to build (with way more hacking than that to remove all the dependencies that are not needed for quicklogic) ... but something still fails and the generated xml is somehow invalid https://pastebin.com/raw/c4Mn2ixM

15:36 <sf-slack> <kgugala> tnt: which repo did you use? What exactly did you run?

15:42 <tnt> kgugala: quicklogic/quicklogic-upstream-rebase branch quicklogic/quicklogic-upstream-rebase (which is also tag v0.1.0)

15:42 <tnt> https://github.com/QuickLogic-Corp/symbiflow-arch-defs/tree/quicklogic-upstream-rebase

15:42 <tpb> Title: GitHub - QuickLogic-Corp/symbiflow-arch-defs at quicklogic-upstream-rebase (at github.com)

15:42 <tnt> cmake .. -DCMAKE_INSTALL_PREFIX=/my/prefix -DUSE_CONDA=false

15:44 <sf-slack> <kgugala> can you try the guide from https://github.com/QuickLogic-Corp/symbiflow-arch-defs/tree/quicklogic-upstream-rebase/quicklogic

15:44 <tpb> Title: symbiflow-arch-defs/quicklogic at quicklogic-upstream-rebase · QuickLogic-Corp/symbiflow-arch-defs · GitHub (at github.com)

15:44 <sf-slack> <kgugala> it still assumes conda for getting VPR (and some other tools)

15:44 <tnt> No because I don't want conda

15:46 <sf-slack> <kgugala> It's hard to tell why the xml is incorrect in your case

15:46 <tnt> I also don't want nodejs or any of the dependencies that are just needed for the ice40 or the xilinx support ...

15:46 <sf-slack> <kgugala> since you do not use the dependencies from conda this could easily be a version issue

15:46 <tnt> https://pastebin.com/hQwsj1CX

15:46 <tpb> Title: 2336,2339c2336,2339 < < (at pastebin.com)

15:47 <tnt> Here's a snippet of difference between the xml generated and the one extracted from the binary distribution.

15:47 <sf-slack> <kgugala> if you simplly run make all_conda it will put evertyhing in build/conda directory and will not pollute your system

15:47 <sf-slack> <kgugala> later you can simply remove that

17:41 <HackerFoo> tnt: If you use Nix, you could try https://github.com/HackerFoo/nix-symbiflow

17:41 <tpb> Title: GitHub - HackerFoo/nix-symbiflow: Nix packages for SymbiFlow projects and dependencies (at github.com)

17:42 <HackerFoo> Otherwise, you need to make sure you have the right dependencies. The biggest one is getting the right VPR.

17:44 <HackerFoo> All the dependencies are documented in a fairly readable form in https://github.com/HackerFoo/nix-symbiflow/blob/master/default.nix

17:44 <tpb> Title: nix-symbiflow/default.nix at master · HackerFoo/nix-symbiflow · GitHub (at github.com)

17:44 <tnt> I have the right VPR. Same git commit.

17:44 <tnt> ATM it seems like yosys is the issue ...

17:45 <tnt> The f_frag.model.xml that's generated from the f_frag.sim.v is invalid.

18:28 <tnt> https://pastebin.com/GYzbEqi7

18:28 <tpb> Title: command ======================================================================= - Pastebin.com (at pastebin.com)

18:29 <tnt> That's the difference ...

18:29 <tnt> The yosys I'm using is a merged version of master with the quicklogic branch (because I need the latest fixes for ice40/ecp5). there was no conflict, clean rebase but it's obviously broken.

18:31 <tnt> err, wrong paste but same idea https://pastebin.com/yeBaSQ8L

18:31 <tpb> Title: command ======================================================================= - Pastebin.com (at pastebin.com)

18:45 <tnt> It's the (* whitebox *)

18:46 <tnt> in the source .v that mess up newer yosys ... or at least makes it behave in a way that doesn't work.

18:46 <sf-slack> <kgugala> I'm afraid there will be more problems with mainline yosys

18:46 <sf-slack> <kgugala> the V2X (xml arch generation from verilog models) requires a few features not yet merged to mainline

18:47 <sf-slack> <kgugala> they are present in symbiflow's fork

18:47 <tnt> it's not mainline, it's the quicklogic branch merged with master.

18:49 <sf-slack> <kgugala> so this one may actually work

18:49 <tnt> The quick logic branch is a bunhc of patch above c9555c9adeba886a308c60615ac794ec20d9276e which is from 3 months ago. So what I'm using is just pretty much all the patch above that rebased on today's master.

18:50 <sf-slack> <kgugala> unless nothing else broke

18:50 <tnt> well it "almost" does ...except that the (*whitebox*) attribute seem to prevent yosys from "selecting" stuff in that module (which means v2x fails to discover the clocked and comb path ) see pastebin above

18:52 <sf-slack> <kgugala> actually whitebox should act the oppsite - Yosys should be able to get inside the module and figure out the internals

18:52 <sf-slack> <kgugala> is this the only file that fails?

18:52 <tnt> No, it's just the first

18:52 <sf-slack> <kgugala> as far as I remember there were a lot of whiteboxes

18:53 <tnt> Oh yeah, I'm pretty sure it fails for all of them.

18:54 <sf-slack> <kgugala> so removing the attributes may get you a little bit further, but I doubt it will work

18:54 <sf-slack> <kgugala> whitebox attribute handling is gereic Yosys functionality (not related to QL specific changes)

18:57 <daveshah> I think there was a way added of selecting inside whiteboxes

18:57 <daveshah> > By default, patterns will not match black/white-box modules or theircontents. To include such objects, prefix the pattern with '='.

18:58 <daveshah> would be needed in the scripts for new Yosys

19:02 <tnt> daveshah: Oh, interesting.

19:05 <tnt> Of course just replaceing F1 with =F1 wasn't good enough. That got rid of "Warning: Selection "F1" did not match any object." but the selection result (as written to file) is empty.

19:15 <tnt> got it ... maybe https://pastebin.com/V16dVPWP

19:15 <tpb> Title: [Diff] diff --git a/v2x/yosys/run.py b/v2x/yosys/run.py index ef2627e..b6f3746 100755 - - Pastebin.com (at pastebin.com)

19:29 <tnt> Well that got it further .... now it just seems to hang on "Generating rr_graph_ql-eos-s3_wlcsp.rr_graph.real.patched.xml.cache, rr_graph_ql-eos-s3_wlcsp.rr_graph.real.bin, rr_graph_ql-eos-s3_wlcsp.place_delay.bin"

19:29 <sf-slack> <kgugala> this takes some time

19:30 <sf-slack> <kgugala> but you need to do this once, later the toolchain will use the generated files

19:32 <tnt> ok, letting it run. I just see vpr taking 100% of cpu and not printing anything to vpr_stdout.log atm.

19:32 <tnt> Ah yeah, it completed successfully it seems.

19:33 <tnt> trying the bin2seven now

19:35 <tnt> I'm a bit worried about the time it takes to build a 93 lines verilog file though.

19:36 <sf-slack> <kgugala> if you're running it from arch-defs it takes longer

19:37 <sf-slack> <kgugala> binary toolchain takes ~40 seconds to synth, pack, place and route and generate the bitstream

19:37 <sf-slack> <kgugala> (for such design)

19:39 <tnt> Ok, it did build sucessfully (well without errors, I have no idea if the result is valid).

19:39 <sf-slack> <kgugala> you'd have to program the FPGA

19:39 <tnt> Don't have one, so can't do that :p

19:40 <tnt> There seem to be a load of warning like "Warning 1: Model 'ASSP' input port 'WBs_RD_DAT' has no timing specification (no clock specified to create a sequential input port, not combinationally connected to any outputs, not a clock input)

19:40 <tnt> is that expected ?

19:40 <sf-slack> <kgugala> or run bin2seven_bit_v target and simulate the resulting verilog

19:40 <sf-slack> <kgugala> this one decompiles the bitstream and generates a structural verilog from it

19:41 <sf-slack> <kgugala> as for the warining - yes it is expected

19:41 <sf-slack> <kgugala> (for now)

19:45 <tnt> So I guess no timing analysis for the RAM or the wishbone bridge ?

19:46 <sf-slack> <kgugala> RAM timings are in progress here https://github.com/antmicro/symbiflow-arch-defs/tree/ram_timings

19:46 <tpb> Title: GitHub - antmicro/symbiflow-arch-defs at ram_timings (at github.com)

19:46 <sf-slack> <kgugala> ASSP (Hard CPU with the WB bridge) is next

19:47 <tnt> Ok great. First thing I'd like to do is port my USB core to it ... so RAM and cpu bridge are kind of important :p

19:48 <sf-slack> <kgugala> indeed

19:48 <sf-slack> <kgugala> :)

19:51 <tnt> mm, something is still broken somewhere in the install ... I see "-- Installing: /opt/openfpga/vtr/share/arch/ql-eos-s3_wlcsp/pinmap.csv" 4 times during make install

19:51 <tnt> So it's overwriting each pinmap over the same destination which is ... not what's supposed to happen I guess.

19:53 <sf-slack> <kgugala> I don't think this is a real problem - it wants to install the pin config for every board we degined in the arch-defs

19:54 <sf-slack> <kgugala> all of them have the same chip package

19:54 <sf-slack> <kgugala> so even if it is everwting sth - it should not break anything

19:54 <sf-slack> <kgugala> but I'll check that

19:55 <tnt> In the binary distribution I see PU64_pinmap.csv / chandalar_pinmap.csv / PD64_pinmap.csv / WR42_pinmap.csv

19:56 <sf-slack> <kgugala> the binary disro was created from arch-defs

19:57 <sf-slack> <kgugala> I'll definitely have to check this

19:57 <sf-slack> <kgugala> thanks for pointing

21:52 <andrewb1999> Has anyone seen this error with VPR placement before? : place_macro.cpp:135 find_all_the_macro: Assertion 'cluster_ctx.clb_nlist.net_sinks(curr_net_id).size() == 1' failed.

22:58 <_whitenotifier-f> [sv-tests] wsnyder opened issue #853: New uvm-agent tests are not legal; need UVM first - https://git.io/Jf16Z