ucb-bar / chisel2-deprecated

chisel.eecs.berkeley.edu
387 stars 90 forks source link

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

Open shunshou opened 8 years ago

shunshou commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

shunshou commented 8 years ago

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)?