<sf-slack>
<timo.callahan> I'm seeing this when trying to use Symbiflow for a LiteX build. I don't know what changed; it worked three weeks ago, and I don't think I've updated Symbiflow or LiteX. `ERROR: set_property IO_LOC_PAIRS: Incorrect number of arguments.` I'm using symbiflow from a symbiflow-examples install that I did in December. Where should I start looking?
<litghost>
Did you update the symbiflow plugins?
<sf-slack>
<timo.callahan> Where do they live? How could I have accidentally updated them? Or are you suggesting that I *should* update them?
<litghost>
I guess the question I have is what changed. Have you updated any packages?
<litghost>
The latest set of packages clearly work, but how is your system different from that
<sf-slack>
<timo.callahan> Do you think the issue is strictly in SymbiFlow, or potentially with LiteX? Actually let me check myself by running some of the examples in symbiflow-examples....
<litghost>
IO_LOC_PAIRS is symbiflow specific
<litghost>
So I can confidently say it's something in SymbiFlow
<litghost>
But maybe not
<litghost>
If for some reason LiteX set a pindef to "" (e.g. empty) that could mess things up
<litghost>
For example, "set_property IO_LOC_PAIRS X5 [get_cells X]" is legal, but "set_property IO_LOC_PAIRS [get_cells X]" would not be
<litghost>
Another possibility is that you have a mismatch between packages, and rather than generating a nice message, it generates that message (e.g. a bug)
<sf-slack>
<timo.callahan> Hmm, symbiflow examples are working for me (counter, picosoc_demo), so let me try to find a different LiteX directory to try rebuilding. Thanks for your help, @litghost!
hansfbaier has quit [Quit: WeeChat 2.8]
<sf-slack>
<timo.callahan> More info: Symbiflow stil does work with the older LiteX build I had. But I still see the error with my new build. Also, I see a warning right before the error: `Warning: Couldn't find port matching serial_tx` then `ERROR: set_property IO_LOC_PAIRS: Incorrect number of arguments.`. But `serial_tx` does exist; it's an output reg on the top "arty" module. And if I comment out the lines regarding
<sf-slack>
`serial_tx` in arty.xdc, then I see the warning with the next pin (`serial_rx`), and then the error.
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #symbiflow
<sf-slack>
<timo.callahan> Ok, I think the problem is that "symbiflow_synth" is not finding the right top, even though we specify "-t arty".
_whitelogger_ has joined #symbiflow
_whitelogger_ has joined #symbiflow
shah has joined #symbiflow
shah has joined #symbiflow
shah has quit [Client Quit]
shah has quit [Client Quit]
krogozinski_ has quit [Ping timeout: 240 seconds]
krogozinski_ has quit [Ping timeout: 240 seconds]
<sf-slack>
<timo.callahan> More findings: my custom function unit module Verilog, which was generated from nmigen/yosys, was marked `(* top = 1 *)`, but was then included into VexRiscv, which was then included into Litex (`arty`). Because of the attribute, the custom function unit module became the top when everything was fed into `symbiflow_synth` / yosys, and all other modules (Litex, VexRiscv) were removed. Which then led to the
<sf-slack>
<timo.callahan> More findings: my custom function unit module Verilog, which was generated from nmigen/yosys, was marked `(* top = 1 *)`, but was then included into VexRiscv, which was then included into Litex (`arty`). Because of the attribute, the custom function unit module became the top when everything was fed into `symbiflow_synth` / yosys, and all other modules (Litex, VexRiscv) were removed. Which then led to the
<sf-slack>
obscure error, because those top LiteX pins had been trimmed. Debugging was made more difficult initially by the fact that info and warnings from synthesis were sent to /dev/null by the Makefile recipe.
<sf-slack>
obscure error, because those top LiteX pins had been trimmed. Debugging was made more difficult initially by the fact that info and warnings from synthesis were sent to /dev/null by the Makefile recipe.