Re:nMigen – A refreshed Python toolbox for building complex ...
by a1369209993 on Saturday October 23, 2021 @09:59PM
(#28974235)
IIUC, this is actually a general deficiency in the type system for variable-width tuples. Consider:
f1 :: (Bit,()) -> Int
f1 (0,()) = 3
f1 (1,()) = 3
-- f1 (0,undefined) is undefined
f2 :: (Bit,(Bit,())) -> Int
-- and so on. Conversely
g2 :: Bit -> Bit -> Int
g1 :: Bit -> Int
g0 :: Int
-- doesn't have this problem but also doesn't work well for busses.
-- The 'obvious' approach
h3 :: (Bit,Bit,Bit) -> Int
h2 :: (Bit,Bit) -> Int
h1 :: (Bit) -> Int
h0 :: () -> Int
-- doesn't work generically; (Bit) isn't a tuple at all,
-- and n-element tuples are totally unrelated to m(!=n)-element tuples
-- (they're literally declared as:
data (a,b) = (a,b)
data (a,b,c) = (a,b,c)
-- in module GHC.Tuple)
If you have the circuit
f :: () -> Int
f () = 3
Vs
g :: () -> Int
g _ = 3
Are the exact same thing in hardware but different in software.
“f undefined” is undefined in software but “g undefined” is not. Neither is undefined in hardware.
This distinction comes up very rarely. Only if you have a parametric circuit that sometimes takes zero-bit inputs (I.e. if the input is unused in some instantiations).