Div and Rem act as sources of X

I ran into this problem when trying to run LEC to test examples for #1365.

From IEEE 1364-2005 (same for older standards):

For the division or modulus operators, if the second operand is a zero, then the entire result value shall be x.

I know these don’t pop up too much in practice, but it might be reasonable to control via randoms.

z <= a / b;                        // source of X
z <= a % b;                        // source of X
z <= (b == 0) ? _RAND_0 : a % b;   // no X
z <= (b == 0) ? _RAND_0 : a / b;   // no X

[albert-magyar]

Is this meant to be the in a synthesizeable code block produced by FIRRTL? This would generate additional hardware. Having them return 0 is probably less hardware, but still more than nothing (which leaves the synthesis tool to do as it pleases).

Sorry I didn’t specify; this would be simulation only – the _RAND_ signals are generally only used in simulation. This would fit in our existing set of conditional compilation modes that cover things like register initialization.

[aswaterman]

Can use an ifdef-guard in the same manner as out-of-bounds array indices, so that the new Verilog only affects simulation, letting the synthesis tool do as it pleases.

On Thu, Feb 13, 2020 at 10:18 AM John Wright [e-mail] wrote:

Is this meant to be the in a synthesizeable code block produced by FIRRTL? This would generate additional hardware. Having them return 0 is probably less hardware, but still more than nothing (which leaves the synthesis tool to do as it pleases).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/freechipsproject/firrtl/issues/1393?email_source=notifications&email_token=AAH3XQQ7GOC5MKVUGIF6RLLRCWFG7A5CNFSM4KUXJE32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWBW6A#issuecomment-585898872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3XQXDBSZMYMSALUQJBCDRCWFG7ANCNFSM4KUXJE3Q .