Is there a way to programmatically choose to use/not use an IO?

[shunshou]

I'm trying to make a very generic counter template, where given a set of user parameters, I'll get back a counter with just the right amount of IO for control signals (i.e. sometimes [call it a SimpleCounter] you want the counter to change every clock cycle, other times you want it to change every 3 clock cycles; in the former case, I don't want to have to manually hook the change input to Bool(true). I'd rather just not have a change input and get rid of the mux). What's the best way to conditionally add signals to an IO bundle?

It seems like there is a + operator that will create a new Bundle that is composed of the elements of the two bundles being added, but does that actually work / does someone have an example for how to use it? I keep getting an error saying that a signal I expect to see in the resultant bundle doesn't exist in Bundle.

[jeuneS2]

On 2015-10-29 11:07, Angie Wang wrote:

I'm trying to make a very generic counter template, where given a set of user parameters, I'll get back a counter with just the right amount of IO for control signals (i.e. sometimes [call it a SimpleCounter] you want the counter to change every clock cycle, other times you want it to change every 3 clock cycles; in the former case, I don't want to have to manually hook the change input to Bool(true). I'd rather just not have a change input and get rid of the mux). What's the best way to conditionally add signals to an IO bundle?

It seems like there is a + operator that will create a new Bundle that is composed of the elements of the two bundles being added, but does that actually work / does someone have an example for how to use it? I keep getting an error saying that a signal I expect to see in the resultant bundle doesn't exist in Bundle.

I don't know if it's really the most elegant way, but the Patmos processor uses reflection to add I/O pins depending on the configuration. The function genTraitedClass (https://github.com/t-crest/patmos/blob/master/hardware/src/util/Config.scala#L429) takes a base class and adds traits (which represent the pins to add) as needed. For example, if Patmos had a UART as its only I/O device, the function would generate a class definition "class TraitPatmosCoreIO_Uart extends patmos.PatmosCoreIO with io.Uart.Pins" for the io bundle of the processor core. PatmosCoreIO has the default signals, and the trait Uart.Pins adds the I/O pins. The generated class has therefore all the signals and can be used just like any other bundle. As the generated class passes the Scala type checking, no magic is required from Chisel.

Cheers, Wolfgang

[shunshou]

Thanks. I'll give it a shot. :)

[shunshou]

I'm a little confused as to how you got the code to behave well when you're specifying T (I'm not familiar with reflection). The class (TraitPatmosCoreIO_Uart) has to already exist (although I thought the point of this was to create it at runtime), otherwise it won't compile (type not found error)?