Examples of using traits to modify published classes?

[Warren Savage]

I'm a bit of a newbie to Chisel, but getting the hang of it pretty quickly. I could use some advise from the experienced people in this group on something I've been struggling with.

Here's what I'd like to do:

1. Create some class
2. Instead of passing a huge list of complex parameters, extend the class with a trait that contains a default set of values
3. Publish those classes as part of package

Then I would like to:

1. Import that package into another project
2. Instantiate the imported class with a trait that overrides or extends the default set in the published class

This is elegant at least in my head, but I've struggled with making it robust.  This leads me to believe that 1) its not really possible, 2) its a bad idea, 3) I'm just missing something.

I've had a look at the ChipYard examples, but that seems a bit heavy weight and also very Rocket-oriented.  Any pointers to best practices or examples for doing this sort of thing with published classes would appreciated.

Warren

[Kevin Laeufer]

Hi Warren,

My advice for parameterizing modules would be to use plain good-old case
classes with default values. So something like:

```
case class CpuParams(
xlen: Int = 32,
aluDepth: Int = 3,
makeAlu: Int => Alu = new SimpleAlu(_),
debugTrace: Boolean = false,
)


class Cpu(p: CpuParams) extends Module { /* ... */ }
```

Then you can overwrite parameters selectively when instantiating your
module:

```
new Cpu(CpuParams(debugTrace = true))
```

This is one of the simplest approaches and thus the least likely to find
you programmed into a corner. Approaches using inheritance often end up
in suboptimal situations that are hard to fix.

Kevin

On 2/6/22 11:38, Warren Savage wrote:
> I'm a bit of a newbie to Chisel, but getting the hang of it pretty
> quickly. I could use some advise from the experienced people in this
> group on something I've been struggling with.
>
> Here's what I'd like to do:
>

> 1. Create some class
> 2. Instead of passing a huge list of complex parameters, extend the

> class with a trait that contains a default set of values

> 3. Publish those classes as part of package

>
> Then I would like to:
>

> 1. Import that package into another project
> 2. Instantiate the imported class with a trait that overrides or

> extends the default set in the published class
>
> This is elegant at least in my head, but I've struggled with making it
> robust.  This leads me to believe that 1) its not really possible, 2)
> its a bad idea, 3) I'm just missing something.
>
> I've had a look at the ChipYard examples, but that seems a bit heavy
> weight and also very Rocket-oriented.  Any pointers to best practices or
> examples for doing this sort of thing with published classes would
> appreciated.
>
> Warren
>

> --
> You received this message because you are subscribed to the Google
> Groups "chisel-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chisel-users...@googlegroups.com
> <mailto:chisel-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chisel-users/11d892b7-5db4-4b8c-bd38-1c0f7601e570n%40googlegroups.com
> <https://groups.google.com/d/msgid/chisel-users/11d892b7-5db4-4b8c-bd38-1c0f7601e570n%40googlegroups.com?utm_medium=email&utm_source=footer>.