Closed kaolpr closed 2 years ago
Well, just after submitting this issue I've noticed that it's improper use of Cat
:man_facepalming:. When used properly it actually results in output I've suggested as a solution. So no work needed here, closing issue.
However, the behavior of Vivado is still misleading (not that it's the first time).
I've came across a strange behaviour of Vivado and proposed PR is a workaround for that.
As an example - let's have two separate inouts that we want to enable with one signal using
TSTriple
:Above translates to the following Verilog:
What gives the following schematics after synthesis in Vivado (2021.1):
Not exactly what was intended (actually this behavior was indirectly reported in #192).
It can be avoided by declaring two signals of interest as a vector:
Verilog for above:
And synthesis result:
Of course we can say that one can just use vectors. However, this can be pretty misleading. Even taking into account that the rule is to instantiate tristates only in top entity, as we clearly are in the top entity. I also did not notice any warning from synthesis engine.
I came across that issue while trying to instantiate single MiSoC SPI master with generic interface (
SPIInterface
) for the setup with nCS lines defined as two different 1-bit ports (what is pretty legible and would prefer to keep it that way).It also took me a while to figure out, as Verilog looks basically fine. Only after looking into synthesized design I've noticed lack of output buffers for some of my ports.
It can be changed in
SPIInterface
class (so that every CS lines gets its ownTSTriple
) and that's the workaround I intend to use for now, but maybe it could be modified at Migen level? I'm thinking of modification that could output something like that:With intermediate signal
port
Vivado cooperates smoothly:Unfortunately I'm not that familiar with the internals of Migen FHD to Verilog translation to submit PR :(