One-hot Mux Implementation

[RobB720]

Hi,

I remember reading in the documentation that it is possible to implement a one-hot routing mux option.

Can this be done please?

If difficult, what would be the best way to post process the binary encoded mux configurations in the bitstream into their one-hot equivalents?

Best regards,
Rob.

[KelvinChung2000]

I assume you are talking about the shift register configuration. You can modify the CSV file to make FABulous generate a shift register configuration. However, this is not tested at the moment.

I am unsure about the conversion, but if you look into the ConfigFSM.v, you can see the loading logic. From my understanding, the configuration happens row by row, so all you may need is to reverse the bitstream order.

[RobB720]

Thanks Kelvin, however, I am referring to the routing muxes. If you have, for example, a 16 bit routing mux driving a route with one of 16 possible inputs, by default FABulous assumes binary encoding using 4bits of configuration. One-hot representation would use 16bits with one out of the 16 configuration inputs set '1'. This is an extreme example using many more cfg bits, but traditionally two stages of one-hot muxes are used for improved speed with a lower area penalty.

Could one-hot routing muxes be added as any option?

[dirk-koch]

Hi Rob,
good question.
I experimented with one hot muxes early on in FABulous, but dropped it then as it costs us more area.
Xilinx&Co use dedicated SRAM cells for configuration storage, which are cheaper than our latches (which is still better than all those shiftregister configuration schemes). Meaning: as we pay more for configuration storage, fully encoding makes more sense for us. Side note: This is why Tabula used encoded multiplexers for their space-time fabric as they need overproportional config memory.
We are working on a dedicated cell for providing config SRAM cell combined with a multiplexer, so what you are asking for has to be integrated in FABulous later this year. We just don't want to rush here as this may have side effects with all the bitstream generation and optimizations we are currently integrating,

[RobB720]

Hi Dirk, Kelvin,
I am using SRAM and I need one-hot muxes for architectural reasons, so it is good news that you are working on this issue! Are you able to be a bit more specific on timescales e.g. Q3 or Q4?

These timescale should be OK for us, but I will need to hack something together for verification sims in a month or two. Is there a way of identifying where a the binary mux configurations are in a bitstream so I could expand them using a post-processing script? Appreciate this might have complications...

Many thanks,
Rob.

[dirk-koch]

Conservatively it should be done mid Q4 the latest.
I am thinking of using FABulous for non-volatile FPGAs that would also need this.
Cheers,
Dirk