<somlo>
playing with the nextpnr-himbaechel xilinx blinky, I noticed that if I try to use the green LEDs ([15:12], T10, T9, J5, H5, currently commented out in the example arty xdc file), I get an "unipmemented" assertion failure in nextpnr/himbaechel/uarch/xilinx/fasm.cc:326
<somlo>
After some clumsy poking around, it looks like tile_type/src/dst are RIOI3_SING / RIOI_OLOGIC0_OQ / RIOI_O0 (none of that means anything to me, yet... :) )
<somlo>
Wondering if this is worth pursuing as a n00b project to slowly gather situational awarenes w.r.t. the way things hang together, or if maybe something else (easier) would make more sense :)
<somlo>
gatecat, lofty: ^^^^; any other ideas/clues much appreciated :)
<lofty>
somlo: might be useful, yes
mewt has quit [Ping timeout: 248 seconds]
mewt has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
FabM has joined #yosys
<somlo>
guess I need to detour into reading up on FASM, and also all the information encoded in the tile, src, and dst names...
FabM has quit [Ping timeout: 244 seconds]
<somlo>
ok, FASM as a file format is fairly straightforward, the magic is in the name of the various entries. And, the method I'm studying (write_pip() in himbaechel/uarch/xilinx/fasm.cc) seems to be doing a bit of "sed"-like editing of the tile name, src, and dst, so I'm guessing the "unimplemented" assertion is more sed-like rules being needed to write out the "correct" FASM ?
<somlo>
so what I really need is a quick and efficient way to come up to speed on the PIP nomenclature. Do I go straight to the firehose (prjxray) for that, or is there a better/smarter way to start digging ?
<lofty>
somlo: probably prjxray; every project has its own naming rules
<somlo>
I guess this is very much specific to xilinx fpga layout, and their feature naming scheme. fingers crossed for some comprehensible documentation :D
mewt has quit [Ping timeout: 248 seconds]
mewt has joined #yosys
tecepe has joined #yosys
tecepe has quit [Client Quit]
tecepe has joined #yosys
<tecepe>
Hello, I am having trouble using the VTR container. When running `vtr_flow/scripts/run_vtr_task.py vtr_flow/tasks/regression_tests/vtr_reg_basic/basic_timing`, what I get as answer is a bunch of errors related to "yosys failed". I then realized that yosys as a command is not available in $PATH. I was wondering what I am missing. Please feel free to
<tecepe>
point me out to a different forum if this is not the right one to ask this.
<lofty>
tecepe: for problems in a container, you should probably go to the VTR people