The complex times a fixedpoint problem

[chick]

@stevobailey has identified a problem where parameterized types being passed to a module may result in operators being applied to two different types. For example: a FixedPoint number being multiplied with a DspComplex[FixedPoint]. Type classes do not help us here because the operand are not of the same type. @grebe created an implementation using additional implicits that allow the FixedPoint to be coerced upward in order to correctly apply the desired operations. After a long discussion with @stevobailey @shunshou @chick and @grebe it was believed that we identified an simpler more explicable scheme involving traits that can be added to modules that would get the desired results. This issue is to make sure we don't lose track of that goal.

[grebe]

I did investigate this last week and ran into problems. I'll summarize the approaches I played around with.

Zero width wire hack
I thought about having DspScalar[T<:Data:Real](real: T) extends DspComplex(real, zeroWidthWireOfTypeT), but the problem is that zero width wires don't behave exactly how you'd like them to. They behave like the identity through arithmetic operations. There are reasons that this makes sense, but it does mean that multiplication won't work the way we want it to (it will look like a 1 rather than a 0).

Scalar Traits
I thought about making traits for DspRealScalar and DspImagScalar and having DspComplex extend both. There are problems with this. [T <: Data : Ring] is not legal for traits because : Ring is sugar for an argument (implicit ev: Ring[T]) and traits don't take arguments. Instead of making them traits you can make them classes, but you can't extend multiple classes. You might be able to make something work with Either types, but it won't be Data anymore then and will be really ugly.

Using Optionable Bundles
This probably requires rewriting significant amounts of existing code, but is the least hackish approach. If real and imag are Option scalars are super easy to deal with. I haven't investigated this much since it seems like the most work, but as the other options haven't been looking good maybe it is worth investigating. I think we'd have real and imag be functions that return _real.getOrElse(Ring[T].zero) (where _real is Option[T]). @shunshou how do you feel about this idea?

Record hack
I also played around with making DspComplex a record and doing DspScalar extends DspComplex {override val elements }. The scalars work by themselves, but assignment between complex and scalars fails. I think DspComplex := DspScalar is the one I was running into, but the other way around might also fail. I did override def imag.

@jackkoenig, Suppose I have a class (call it B) that extends an instance of Record (call it A), and B overrides elements to be a subset of A's. The elements in A that are not in B have their associated vals overridden in B. Is there a way to make A := B work?

[jackkoenig]

So there is an open Chisel task (couldn't find a Github issue though), to be able to bulk connect child bundles to instances of their parent types. This is a little different though, since Bundles can only ever add fields to their parents, it is safer than what you're doing here. This example is especially weird because the child has fewer fields than the parent. I'm not sure if this "bulkConnectToParent" operation even really makes sense on Records, it seems like more of a Bundle thing.

My suggestion is to define your own "casting" methods, like A.toB and/or B.toA. Then you can connect or multiply or whatever as you please.