05:01 <sf-slack> <fdarling> @timo.callahan thanks for the tip. I followed that guide and was able to install symbiflow locally in my home folder. After setting up a couple of paths, I was able to build "counter_test" for the (default) basys3. However, I want to actually compile for my MicroNova Mercury 2 board: https://www.cncwiki.org/index.php?title=MicroNova_Mercury_2_FPGA_Development_Board It features an xc7a35tftg256-1 chip, and that isn't

05:01 <sf-slack> in the database. Strangely, that specific device is used as an example in the documentation on how to add a device: https://readthedocs.org/projects/prjxray/downloads/pdf/latest/#page=67 (page 63 or page 67) I guess it's just a version of another chip with fewer pins bonded? There is a bit of a learning curve with this, and I'd appreciate any help!

05:01 <tpb> Title: MicroNova Mercury 2 FPGA Development Board - CNC Wiki (at www.cncwiki.org)

08:22 <sf-slack> <fdarling> I think there actually _is_ support for the xc7a35tftg256-1 chip already, I was just having a problem with my .xdc file. I got it to compile and flash, but it isn't working correctly. Progress at least!

08:40 <sf-slack> <fdarling> it seems that the XDC musn't set properties of unused pins with SymbiFlow, though with Xilinx Vivado this is acceptable

15:47 <cr1901_modern> Why does xc7 and quicklogic have a techmap directory in symbiflow, as opposed to using techmap from your yosys installation?

16:24 <gatecat> cr1901_modern: my understanding is that there are some special rules needed (e.g. around carries) that aren't suitable for upstream yosys

16:25 <cr1901_modern> I see... I can't seem to get through this builod system... I feel genuinely stuck

16:27 <cr1901_modern> For instance... the developed families right now seem to distinguish family from arch. For machxo2 devices, this doesn't make sense... it's one family, one arch w/ about 8 devices

16:30 <cr1901_modern> Why does xc7/archs/artix7/devices/ have a bunch of subdirectories that are development-board specific?

16:31 <mithro> cr1901_modern: Probably because we were focused on a single dev board and then expanded things

16:33 <mithro> cr1901_modern: Our work pretty much always starts narrow and then is expanded / make more generic

16:33 <mithro> cr1901_modern: Focus on doing one thing on one board with one part

16:33 <mithro> cr1901_modern: When you get *that* working then worry about expanding it to more board / parts / etc

16:34 <cr1901_modern> Alright. I'll focus on tinyfpga Ax. I'll push the code I have (ignoring my local work, because I want a clean slate now)

16:36 <cr1901_modern> My goal right now is to get all the CMake infrastructure set up for symbiflow to target TinyFPGA Ax on MachXO2, so nominally I don't need to touch it again. Once I do that, I can start "plumbing" the RE'd database for bits and routing graph through the symbiflow arch() function piecemeal

16:36 <cr1901_modern> Does this sound like a reasonable goal, or am I going about this the wrong way?

16:38 <mithro> Expecting to never touch the cmake system again is not a goal that is going to particularly help you here

16:39 <mithro> And in fact that is probably what is causing your issues with the cmake system...

16:41 <cr1901_modern> https://github.com/cr1901/symbiflow-arch-defs/tree/machxo2/machxo2 This is what I have that actually works (my local tree is a mess, so not pushing it right now).

16:41 <cr1901_modern> >Add MachXO2 CMake files into build system except for arch() invocation <-- commit msg

16:42 <cr1901_modern> I intended to put the arch invocation here: https://github.com/cr1901/symbiflow-arch-defs/blob/machxo2/machxo2/facade.cmake#L49. My local changes include adding the yosys conv/synth.tcl scripts so the arch() function actually have something to do.

16:42 <cr1901_modern> facade.cmake was based on icestorm.cmake. litghost and others have made clear that quicklogic and xc7 are better backends to look at going forward

16:42 <cr1901_modern> Okay, fair enough

16:44 <sf-slack> <timo.callahan> @fdarling Yes you're on the right track, good progress! Yeah I think you're right about SymbiFlow being a bit pickier. So maybe now all you need to do is make sure you specify the right package pins for the LED connections, which you should be able to get from a board schematic. Does the board have one RGB LED? Even then you can 'count' with 3 bits connected to the different colors, so you cycle through

16:44 <sf-slack> all 8 combinations.

16:44 <mithro> cr1901_modern: I would suggest doing something like "cp <src> machxo2" and then just start modifying the existing files

22:07 <sf-slack> <fdarling> https://pastebin.com/tFLqtRTj

22:07 <tpb> Title: MicroNova Mercury 2 with SymbiFlow counter_test attempt - Pastebin.com (at pastebin.com)

22:09 <sf-slack> <fdarling> @timo.callahan that pastebin post above shows what I did to try and get it to work. It compiled and flashed, but the board behaved weird -- the LEDs would be off, then after a few seconds one LED would come on (almost like a really really slow clock?) except the 7-segments nearby on the "Mercury Base Board" were also dimly lit like weak pull-ups, and it wouldn't do anything further. I feel like the bitstream is not at

22:09 <sf-slack> all correct...

22:17 <sf-slack> <fdarling> https://youtu.be/8ky3we8QGAM

22:17 <sf-slack> <fdarling> it doesn't even work if I reduce the test case to: assign leds = 3'b111;

22:21 <mithro> fdarling: There is a flow at j.mp/symbiflow-testing that might help you figure out were the issue is

22:21 <mithro> fdarling: It is also much easier to put everything into a github repo and share that so other people can see exactly what you are doing

22:23 <sf-slack> <fdarling> I am not yet sure what I would need for a minimal working project, since I am not having much success at the moment

22:30 <mithro> fdarling: I'm afraid from your current description there isn't really a lot we can do to help you debug. I can think of *hundreds* of potential things that are going wrong and without the ability to see *exactly* what you are doing and what output you are seeing it is pretty hard to help. Hence why I'm suggesting publishing your current effort so we don't have to guess as many things.

22:31 <mithro> fdarling: Plus we would like you to eventually send your changes to be included, hence it is good to get things moving in that direction anyway.

22:32 <sf-slack> <fdarling> I am not against making a github repo, I am just not quite sure what to put into it at the moment

22:32 <mithro> fdarling: What ever you are trying to run

22:32 <sf-slack> <fdarling> are there minimal examples of "standalone" SymbiFlow projects that reference the tools installed in a home folder?

22:32 <sf-slack> <fdarling> I am using a modified folder in the examples repo (which is quite large)

22:34 <mithro> fdarling: If I understand what you are trying to do, you shouldn't have needed to modify any of the tools, only the example code