Open seldridge opened 6 years ago
Unless you want to enable direct instantiation of an injector in Chisel code, I don't think this is necessary, as transforming arbitrary Data
into a UInt
and back is pretty easy. If this is referencing the issue with 0-width fields, the solution I came up with is to simply modify the Type
of the Expression
input into toBits
and the one on the rhs
of fromBits
to remove bundle fields that have zero width.
Also, you don't need to include a generator for the Data
type of the signal; you can store it using chisel3.core.chiselTypeOf
The serialization issue is still present, though.
Unless you want to enable direct instantiation of an injector in Chisel code, I don't think this is necessary, as transforming arbitrary Data into a UInt and back is pretty easy.
This is tricky as we're using the injectors only in FIRRTL, but we are writing them in Chisel. They should be as useful as possible outside of our narrow use case, i.e., I think it's beneficial if they're normal Chisel modules that you can interact with and use in your design. A user may want to use the fault injectors that the chiffre
library provides independent of use only in FIRRTL.
Does chisel3.core.chiselTypeOf
have a way to encode constructor parameters? I was originally thinking about the () => Data
encoding from the perspective of encoding a function to create an injector, i.e., () => Module
. That's already a problem here with the injector constructor needing to have a rigid set of parameters. It's worse with arbitrary Chisel types.
chiselTypeOf(target)
returns target.cloneTypeFull
and the comment says it's intended to be used for constructing hardware to construct other hardware of the same type.
When I tried serializing a chiselTypeOf(UInt(3.W))
, I got a JSON map that had a width
field of 3. I think the problem was that the serialization didn't include specific type information, so json4s just tried to use Data
's default constructor, which doesn't have a width parameter.
Related to #14, #18, an injector should be an injector into arbitrary
Data
, not an injector into a flattenedUInt
. Roughly, the following should be what anInjectorIo
is:This introduces complications into inline compilation as the type that you want to inject into should be some Chisel
Data
. However, this information is lost at the FIRRTL level. The fault instrumentation annotations can be modified to encode information about the underlying type that will be injected into. Alternatively, the type could be rebuilt from the component. The latter is complicated, but the former is, too. The former requires, I think, the capability to serialize a() => Data
function in an annotation.