I did now two alternative implementations. One that implements the wrap_ts function described below and one that only changes Tristate class and does not need changes to the MiSoC cores. I consider the first one cleaner though but any of the two will allow me to use the MiSoC cores for my use case.I did submit PRs, for wrap_ts #147 for Migen and #94 for MiSoC. For the Tristate change there is only #148 for Migen. greets,Staf. Staf Verhaegen schreef op ma 22-10-2018 om 22:08 [+0200]: > Sébastien Bourdeauducq schreef op ma 22-10-2018 om 11:03 [+0800]: > > Hi, > > > > On 10/18/18 12:50 AM, Staf Verhaegen wrote: > > > I am interested to know if the change to MiSoC is the direction > > > to go > > > for such a change. If OK, I can do a PR on github. If not, I > > > would like > > > to discuss alternative solutions. > > > > Would it be possible to achieve a working result by overriding the > > implementation of the tristate special using special_overrides? > > Current code assumes a special needs to be added but that is not the > case when the record with the right fields is passed. The code could > be changed once to make it future proof, e.g. change: > > ts = TSTriple(1) > self.specials += ts.get_tristate(signal) > > to > > ts = wrap_ts(signal, self) > > wrap_ts could then add something to self.specials if needed. In the > future new types can then be supported by only changing wrap_ts. > OK ? > > > Worst case, can the tristate special just instatiate the ASIC I/O > > cell? > > I want to be able to mux for example I2C and UART to the same pins > configurable by CSR. This is not possible is I2C instantiates the I/O > pin. > > greets, > Staf. > > _______________________________________________ > M-Labs devel mailing list > https://ssl.serverraum.org/lists/listinfo/devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ M-Labs devel mailing list https://ssl.serverraum.org/lists/listinfo/devel
