Open rsetaluri opened 5 years ago
One way to approach this would be consider that the interface to the fault Tester
object is a magma circuit, so perhaps poke
, expect
should match the magma type system. How this is enforced (fault frontend versus target) would be an implementation detail, but I would vote that poke
and expect
exhibit the same semantics as wiring constant values in magma
. So, we do promotion when possible, but truncation is an error (the user needs to do this themselves).
One question is whether we can factor the code in a way such that we can use the exact same rules as magma (perhaps this requires magma to abstract it's type checking code for integers into routines which we can call in fault).
I think this might be better to do at the frontend, because the targets may have different semantics/ For example, verilator and ncsim might follow different type checking/promotion/conversion rules for integers than magma. I think our goal was to have a test bench work on all targets, so it should be specified in one frontend, and mapped to the semantics of the target. So my vote is to use magma's typing rules for the frontend.
Good idea, I'm on board for that. So just to be clear, the most-user facing functions (e.g. Tester.poke/expect
) should have promotion logic (e.g. python int
to magma.uint
), and the interface to the targets will be such that they all receive magma values (via the action objects).
Imagine a circuit with input
I
of typeBits(4)
. If we have afault.Tester
for this circuit, and we issue for example apoke(circuit.I, 100)
, what should happen? I see 3 options:Tester.poke(port, value)
do a type check thatvalue
is compatible with the type ofport
. Right now we do some type checking (e.g. ifport
is typeBits
only a bit-vector or int is allowed forvalue
), but this doesn't check if the value fits in the bit-width. We could also do this in thePoke
class constructor -- but this is the same idea.int
based, so we can always dotop->I = value
. On the other hand, another simulator may have a bit-vector interface, alatop.I = BitVector(value, n)
, in which case this may not always work.The issue is more complex for
expect()
thanpoke()
because if a bit-vector gets truncated it may return a false-positive equality. For examplethough
My hunch is that we should issue a warning in the top-level
poke
andexpect
functions and try to enforce that the targets maintain as much structure as possible (i.e. do not truncate/zext).