Friday, 2019-04-19

*** tpb has joined #symbiflow00:00
mithroZipCPU: Have you done much logical equivalence checking with SymbiYosys? If so what size modules are reasonable to look at? (and have I already asked you this previously? :-P)01:09
ZipCPUmithro: My conclusion following my experiences with the equivalence checking capability of SymbiYosys is that it is both difficult to set up, and difficult to comprehend the results.  As a result, I haven't done much with it.  Not sure I'd know the answer to your question.01:15
mithroZipCPU: Is SymbiYosys different then using ?01:18
tpbTitle: Yosys Open SYnthesis Suite :: Command Reference :: equiv_induct (at
mithroZipCPU: and
tpbTitle: yosys/ at master · YosysHQ/yosys · GitHub (at
ZipCPUmithro: See ... that's the problem I have.  I have no experience using those yosys commands, and so have little understanding of what they do.  I then find myself trying to instruct folks, and ... not knowing the answers.01:35
mithroZipCPU: time for a new blog post? :-P01:44
ZipCPUWhen I get to it ... but so far I've had other things on my desk01:45
*** OmniMancer has joined #symbiflow03:02
*** Bertl_oO is now known as Bertl_zZ03:58
*** citypw has joined #symbiflow04:01
*** futarisIRCcloud has quit IRC05:16
*** nnn_ has joined #symbiflow08:18
*** nnn_ has quit IRC08:20
*** futarisIRCcloud has joined #symbiflow09:21
*** citypw has quit IRC10:12
*** Bertl_zZ is now known as Bertl11:01
sf-slack2<arora.prayas> Hi all, I was trying setup vtr on my machine. I have a directory named sandbox with following repositories in it.11:32
sf-slack2<arora.prayas> I ran 'make' in the vtr-velilog-to-routing directory.11:33
sf-slack2<arora.prayas> I think the build passed but I think I don't have all the dependencies.  How can I install all the dependies ?11:33
sf-slack2<acomodi> here's some more detailed instructions on how to build VTR11:34
tpbTitle: vtr-verilog-to-routing/ at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
sf-slack2<acomodi> There is a command to get all the required dependencies11:35
*** adamgreig has quit IRC11:59
*** adamgreig has joined #symbiflow12:00
sf-slack2<acomodi> by using fasm2bels I could understand something more about the equivalent tile issue which does not let it run on HW correctly12:02
sf-slack2<acomodi> First of all: different builds produce different effects. I tried also the counter test (where the placement used CLBLMs instead of the packed CLBLLs) and in some cases blinky worked fine, while in others only 2 out of 4 leds where blinking.12:04
sf-slack2<acomodi> I had to enable the `allow_orphan_sinks` option in fasm2bels to obtain the verilog equivalent and let it run through vivado.12:06
sf-slack2<acomodi> By inspecting the implemented design on the GUI I have observed that there are IO pins which are not correctly routed (they are connected to HARD1) and some others are connected to a carrychain which most probably has an issue, given the fact that for some builds, IO pins routed to the corresponding carrychain (here I am considering `chain_packing` test) are permanently switched off.12:10
sf-slack2<acomodi> Another thing to be mentioned is that, in order to get a verilog file from the chain_packing test I had to disable this assert:
tpbTitle: symbiflow-arch-defs/ at 64ca52b4c7d849bc67d21872235b1b721ce25397 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<acomodi> When it was enabled I got the following error message: ``` Traceback (most recent call last):   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/build/env/conda/lib/python3.7/", line 193, in _run_module_as_main     "__main__", mod_spec)   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/build/env/conda/lib/python3.7/", line 85, in _run_code     exec(code, run_globals)   File12:14
sf-slack2"/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 4, in <module>     main()   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 271, in main     top.make_routes(allow_orphan_sinks=args.allow_orphan_sinks)   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 973, in make_routes12:14
sf-slack2net_map=self.net_map,   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 668, in make_routes     allow_orphan_sinks=allow_orphan_sinks   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 550, in expand_sink     allow_orphan_sinks=allow_orphan_sinks   File12:14
sf-slack2"/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 438, in expand_sink     allow_orphan_sinks=allow_orphan_sinks   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 438, in expand_sink     allow_orphan_sinks=allow_orphan_sinks   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 438, in12:14
sf-slack2expand_sink     allow_orphan_sinks=allow_orphan_sinks   [Previous line repeated 1 more time]   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 550, in expand_sink     allow_orphan_sinks=allow_orphan_sinks   File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/", line 518, in expand_sink     'HARD0'], (sink_node_pkey, tile, site_pin)12:14
sf-slack2AssertionError: (1124829, 'CLBLM_R_X5Y134', 'DQ') xc7/tests/chain_packing/CMakeFiles/file_xc7_tests_chain_packing_chain_packing_basys3_artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test_top_bit.v.dir/build.make:62: recipe for target 'xc7/tests/chain_packing/chain_packing_basys3/artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test/top_bit.v' failed ```12:14
*** acomodi has joined #symbiflow12:15
sf-slack2<mkurc> I had similar errors when trying to use fasm2verilog.12:16
sf-slack2<acomodi> You think is due to the tool or to the wrong fasm (which means something bad happened during some of the VPR stages)?12:18
sf-slack2<mkurc> I think that the tool is a problem. Because I ran it on working design of a counter test.12:19
sf-slack2<arora.prayas> I ran 'make' in the vtr-verilog-to-routing directory. I gave the following warnings: ... Scanning dependencies of target vpr [ 14%] Building CXX object vpr/CMakeFiles/vpr.dir/src/main.cpp.o [ 16%] Linking CXX executable ../../vpr/vpr /home/prayas/sandbox/vtr-verilog-to-routing/vpr/src/base/read_netlist.cpp: In function ‘set_atom_pin_mapping’:12:19
sf-slack2/home/prayas/sandbox/vtr-verilog-to-routing/vpr/src/base/vpr_types.cpp:128:12: warning: potential null pointer dereference [-Wnull-dereference]      return child_pbs == nullptr;             ^ /home/prayas/sandbox/vtr-verilog-to-routing/vpr/src/base/vpr_types.cpp:128:12: warning: potential null pointer dereference [-Wnull-dereference] [ 16%] Built target vpr ...12:19
sf-slack2<acomodi> @arora.prayas It is not an issue, but probably worth to solve it though.12:21
sf-slack2<acomodi> @mkurc Ok, I'll try to run it as well to double-check on a running test design12:22
sf-slack2<arora.prayas> Yup, The build is ready. I'll look into this and also run some tests to understand the flow for perl to python migration.12:22
sf-slack2<acomodi> When translating from fasm2verilog as I said I have allowed `orphan_sinks` and printed all of them on stdout. Here there is a fraction of the output relative to the orphan sinks which is curious:
sf-slack2<mkurc> @acomodi So I guess that the curious thing is that the orphan sinks are clocks, right ?13:45
sf-slack2<acomodi> Yep, and they refer to the equivalent tiles (CLBLMs) that are used instead of the original one (CLBLLs)13:50
sf-slack2<acomodi> @mkurc I am starting to think that I missed some steps when dealing with the equivalent tiles which break something during routing. Probably is a clock related issue13:52
sf-slack2<mkurc> @acomodi I remember a suggestion from @litghost that you can enable routing debugging in the VPR13:57
*** JuanP has joined #symbiflow13:57
sf-slack2<acomodi> @mkurc Yeah, I think it is a good idea to check in detail what is happening there during routing13:58
JuanPHi, I am willing to help treillis. For ECP5, where can I find the details of commands for the bitstream? I read multiple lattice docs and the treillis doc seems to only talk about configuration commands but not what we put inside the frames. thanks13:59
daveshahJuanP: If you are interested in the meaning of bits, have a look at
tpbTitle: Project Trellis HTML Documentation (at
daveshahAnd it's machine readable form
tpbTitle: GitHub - SymbiFlow/prjtrellis-db: Project Trellis database (at
JuanPgreat, just a suggestion, maybe it would help to have a simple and concise example so that we can be sure to understand all that data and find a way by ourselves14:22
JuanP* bitstream example14:23
daveshahYes I might look at getting something like that together14:26
daveshahHave you looked at ecpunpack? It can turn a bitstream to a simple text format14:26
tpbTitle: Textual Configuration Format Project Trellis 0.0-231-g0bc07e3 documentation (at
JuanPecpunpack is a good thing. I will use it for now, but definitely, if you could add an example, I am pretty sure devs would be more encline to tinker. Just my 2cts though! Thanks for this great project BTW14:31
*** citypw has joined #symbiflow14:52
sf-slack2<acomodi> @mkurc good news, I guess, I think I made something wrong when modifying genfasm to deal with the equivalent tiles. I reverted the genfasm changes and produced a verilog design with fasm2verilog which is correctly implemented by vivado and all of the carrychains in the `chain_packing` test are working.14:57
sf-slack2<mkurc> @acomodi That's great!14:57
sf-slack2<kgugala> @acomodi that's awesome14:57
litghostacomodi: The recommended way to use fasm2v right now is to ensure that all input pins are connected to sinks and all output pins are connected to sourced.  There is also a restriction with constant routing that output pins cannot be tied to VCC/GND.  I general tied unused input pins to 1 or more unused output pins15:01
sf-slack2<mkurc> On my side: I made a progress regarding CLB split. I created and filled in new tables in the SQL database. The first one relates new SLICE tiles to concrete site instances of former CLBs. The second one maps pips which are related to particular instances of new SLICE tiles to concrete SLICE tile instances within a former CLB. (That's a bit enigmatic though...)15:06
sf-slack2<acomodi> litghost: Yeah, makes sense that all pins are connected to the relative sink/source. In fact there still is something that is not correct as there still are orphan sinks. I need to further investigate this15:06
sf-slack2<mkurc> @litghost I think now I have to create a WIP PR with my latest work regarding the CLB split. But that work is based on #537. How do you want to progress with that ?15:08
litghostPush what you have15:09
litghost#537 is close, just some outstanding review comments15:10
*** JuanP has quit IRC15:10
sf-slack2<mkurc> @litghost Here it is:
tpbTitle: WIP: CLB to SLICE split by mkurc-ant · Pull Request #610 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** citypw has quit IRC15:22
*** citypw has joined #symbiflow16:01
*** proteusguy has quit IRC16:02
*** proteusguy has joined #symbiflow16:04
*** Bertl is now known as bertl_oO16:51
*** bertl_oO is now known as Bertl_oO16:51
*** OmniMancer has quit IRC16:53
*** futarisIRCcloud has quit IRC17:01
*** _whitelogger has quit IRC17:47
*** _whitelogger has joined #symbiflow17:49
mithroFYI - nextpnr is now in the SymbiFlow conda-packages19:14
mithroSo is verilator and iverilog19:14
mithroFYI - I started a "FASM Feature Naming Style Guide" at
tpbTitle: FASM Feature Naming Style Guide - Google Docs (at
mithroThis is a really interesting document ->
mithrolitghost: This is the style of diagram was I was looking for22:07
mithrolitghost: Are you working on ?22:58
tpbTitle: WIP: Generate flip flop models using v2x by mithro · Pull Request #597 · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrolitghost: Or should I take it back and land it?22:58
litghostmithro: If you have time, take and land it, however it requires solving the v2x multi instance problem, which I believe kgugala is working on23:00
*** futarisIRCcloud has joined #symbiflow23:48

Generated by 2.13.1 by Marius Gedminas - find it at!