yippee! a new unit test (test_alu_compunit.py) just picked up that we are using rc from Decode2ExecuteType in the wrong way. as RC and OE are both of type "Data", the test needs to be on "rc_ok" enabled. i think. the symptoms: test_alu_compunit.py fails because CR0 is not being outputted on OP_CMP. as in: cr0.ok is not being set. it's not being set because in CommonOutputStage: comb += self.o.cr0.data.eq(cr0) comb += self.o.cr0.ok.eq(op.rc.rc & op.rc.rc_ok) # CR0 to be set op.rc.rc & op.rc.rc_ok is *zero*, and yet the test in test_output_caller.py (and test_alu_compunit.py) is this: def check_extra_alu_outputs(self, alu, dec2, sim, code): rc = yield dec2.e.rc.data if rc: ....
michael, any clues?
ah. just as in the unit tests which check if OP_CMP* is enabled, this was missing in CommonOutputStage. however this highlights something else: the destination for CR output needs to be implicitly set to CR0 when RC is enabled, otherwise the output stage has ni idea where to put the result.
(In reply to Luke Kenneth Casson Leighton from comment #2) > however this highlights something else: the destination for CR output needs > to be implicitly set to CR0 when RC is enabled, otherwise the output stage > has no idea where to put the result. ... which is in decode2.cr_out bitfield. so the unit tests need to be modified to check if cr out ok is set, rather than use RC or the OP_CMP* test.