@schwigi That looks like a bug to me,oe should be a vector: nmigen.vendor.intel#L286.

self._get_oereg should be employed here as well nmigen.vendor.intel#L223.

Refer to ALTIOBUF IP COre User Guide, UG-01024 for details.

I did some debugging runs and the problem is not in the platform.intel part.

In lib/io.py:43 the oe width is hard coded to 1. For Intel FPGAs it is clear that you must use width here as well. Not sure however how other FPGAs behave though.

I did some debugging runs and the problem is not in the platform.intel part.

No, the problem is in vendor.intel.

In lib/io.py:43 the oe width is hard coded to 1.

This is deliberate: a wide tristate signal is treated as a single entity for the purposes of output enable. That is how (n)Migen define its behavior, which is completely independent of any platform. Any platform that has output enable with the same width as output should use Repl.

If you want to control direction per-bit, you should instantiate a tristate per bit.

@schwigi: shouldn't this

also read i_oe=self._get_oereg(m, pin),?

@peteut: You are right, get_tristate should use _get_oereg as well.

Thanks for correcting my oversight ^.^'