<mithro> ZipCPU: 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)
<ZipCPU> mithro: 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.
<mithro> ZipCPU: Is SymbiYosys different then using http://www.clifford.at/yosys/cmd_equiv_induct.html ?
<tpb> Title: Yosys Open SYnthesis Suite :: Command Reference :: equiv_induct (at www.clifford.at)
<tpb> Title: yosys/equiv_opt.cc at master · YosysHQ/yosys · GitHub (at github.com)
<ZipCPU> mithro: 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.
<mithro> ZipCPU: time for a new blog post? :-P
<ZipCPU> When I get to it ... but so far I've had other things on my desk
OmniMancer has joined #symbiflow
Bertl_oO is now known as Bertl_zZ
citypw has joined #symbiflow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
nnn_ has joined #symbiflow
nnn_ has quit [Client Quit]
futarisIRCcloud has joined #symbiflow
citypw has quit [Ping timeout: 245 seconds]
Bertl_zZ is now known as Bertl
<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.
<sf-slack2> <arora.prayas> I ran 'make' in the vtr-velilog-to-routing directory.
<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 ?
<sf-slack2> <acomodi> https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/BUILDING.md here's some more detailed instructions on how to build VTR
<tpb> Title: vtr-verilog-to-routing/BUILDING.md at master · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <acomodi> There is a command to get all the required dependencies
adamgreig has quit [Ping timeout: 252 seconds]
adamgreig has joined #symbiflow
<sf-slack2> <acomodi> by using fasm2bels I could understand something more about the equivalent tile issue which does not let it run on HW correctly
<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.
<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.
<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.
<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: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/64ca52b4c7d849bc67d21872235b1b721ce25397/xc7/fasm2bels/make_routes.py#L517
<tpb> Title: symbiflow-arch-defs/make_routes.py at 64ca52b4c7d849bc67d21872235b1b721ce25397 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<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/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/build/env/conda/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File
<sf-slack2> "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/__main__.py", line 4, in <module> main() File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/fasm2bels.py", line 271, in main top.make_routes(allow_orphan_sinks=args.allow_orphan_sinks) File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/verilog_modeling.py", line 973, in make_routes
<sf-slack2> net_map=self.net_map, File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 668, in make_routes allow_orphan_sinks=allow_orphan_sinks File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 550, in expand_sink allow_orphan_sinks=allow_orphan_sinks File
<sf-slack2> "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 438, in expand_sink allow_orphan_sinks=allow_orphan_sinks File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 438, in expand_sink allow_orphan_sinks=allow_orphan_sinks File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 438, in
<sf-slack2> expand_sink allow_orphan_sinks=allow_orphan_sinks [Previous line repeated 1 more time] File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 550, in expand_sink allow_orphan_sinks=allow_orphan_sinks File "/home/alessandro/projects/symbiflow/symbiflow-arch-defs/xc7/fasm2bels/make_routes.py", line 518, in expand_sink 'HARD0'], (sink_node_pkey, tile, site_pin)
<sf-slack2> AssertionError: (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 ```
acomodi has joined #symbiflow
<sf-slack2> <mkurc> I had similar errors when trying to use fasm2verilog.
<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)?
<sf-slack2> <mkurc> I think that the tool is a problem. Because I ran it on working design of a counter test.
<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’:
<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 ...
<sf-slack2> <acomodi> @arora.prayas It is not an issue, but probably worth to solve it though.
<sf-slack2> <acomodi> @mkurc Ok, I'll try to run it as well to double-check on a running test design
<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.
<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: https://pastebin.com/p4APnu5z
<tpb> Title: SINK NODE: 1124330 TILE NAME: CLBLM_R_X5Y132 WIRE NAME: CLBLM_CLK1 SINK WIRE: 1 - Pastebin.com (at pastebin.com)
<sf-slack2> <mkurc> @acomodi So I guess that the curious thing is that the orphan sinks are clocks, right ?
<sf-slack2> <acomodi> Yep, and they refer to the equivalent tiles (CLBLMs) that are used instead of the original one (CLBLLs)
<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 issue
<sf-slack2> <mkurc> @acomodi I remember a suggestion from @litghost that you can enable routing debugging in the VPR
JuanP has joined #symbiflow
<sf-slack2> <acomodi> @mkurc Yeah, I think it is a good idea to check in detail what is happening there during routing
<JuanP> Hi, 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. thanks
<daveshah> JuanP: If you are interested in the meaning of bits, have a look at https://symbiflow.github.io/prjtrellis-db/
<tpb> Title: Project Trellis HTML Documentation (at symbiflow.github.io)
<daveshah> And it's machine readable form https://github.com/SymbiFlow/prjtrellis-db
<tpb> Title: GitHub - SymbiFlow/prjtrellis-db: Project Trellis database (at github.com)
<JuanP> great, 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 ourselves
<JuanP> * bitstream example
<daveshah> Yes I might look at getting something like that together
<daveshah> Have you looked at ecpunpack? It can turn a bitstream to a simple text format
<tpb> Title: Textual Configuration Format Project Trellis 0.0-231-g0bc07e3 documentation (at prjtrellis.readthedocs.io)
<JuanP> ecpunpack 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 BTW
citypw has joined #symbiflow
<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.
<sf-slack2> <mkurc> @acomodi That's great!
<sf-slack2> <kgugala> @acomodi that's awesome
<litghost> acomodi: 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 pins
<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...)
<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 this
<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 ?
<litghost> Push what you have
<litghost> #537 is close, just some outstanding review comments
JuanP has quit [Quit: Page closed]
<sf-slack2> <mkurc> @litghost Here it is: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/610
<tpb> Title: WIP: CLB to SLICE split by mkurc-ant · Pull Request #610 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
citypw has quit [Ping timeout: 246 seconds]
citypw has joined #symbiflow
proteusguy has quit [Ping timeout: 245 seconds]
proteusguy has joined #symbiflow
Bertl is now known as bertl_oO
bertl_oO is now known as Bertl_oO
OmniMancer has quit [Quit: Leaving.]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #symbiflow
<mithro> FYI - nextpnr is now in the SymbiFlow conda-packages
<mithro> So is verilator and iverilog
<mithro> FYI - I started a "FASM Feature Naming Style Guide" at https://docs.google.com/document/d/1DpNa1muvC8-ekjJeG9MSVUTnQnz1W0lnLBQTHmdTsA4/edit#
<tpb> Title: FASM Feature Naming Style Guide - Google Docs (at docs.google.com)
<mithro> litghost: This is the style of diagram was I was looking for
<tpb> Title: WIP: Generate flip flop models using v2x by mithro · Pull Request #597 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> litghost: Or should I take it back and land it?
<litghost> mithro: If you have time, take and land it, however it requires solving the v2x multi instance problem, which I believe kgugala is working on
futarisIRCcloud has joined #symbiflow
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow