2012/5/8 R. Diez <[email protected]> > Hi all: > > I'm still developing a modified test suite and I'm seeing differences > again between or1ksim and or1200. This time it's related to the l.div > instruction. > > File inst-set-text.exp states that dividing by zero should yield zero and > the carry flag should be set: > > " 0x0000000c / 0x00000000 = 0x00000000: OK" \ > " - carry flag set: TRUE" \ > " - overflow flag set: FALSE" \ > " - exception triggered: FALSE" \ > " 0xfffffff4 / 0x00000000 = 0x00000000: OK" \ > " - carry flag set: TRUE" \ > " - overflow flag set: FALSE" \ > " - exception triggered: FALSE" \ > > However, the or1ksim simulator leaves the result register untouched, (the > 0xfffffffd comes from a previous l.div instruction): > > report(0x0000000c); > report(0x00000000); > report(0xfffffffd); > report(0x00000001); > report(0x00000000); > report(0x00000000); > > report(0xfffffff4); > report(0x00000000); > report(0xfffffffd); > report(0x00000001); > report(0x00000000); > report(0x00000000); > > ORPSoC V2's or1200 RTL delivers different results: > > report(0x0000000c); > report(0x00000000); > report(0x00000000); > report(0x00000000); > report(0x00000001); > report(0x00000000); > > report(0xfffffff4); > report(0x00000000); > report(0x00000000); > report(0x00000000); > report(0x00000001); > report(0x00000000); > > The division result is zero, and the overflow flag is set, instead of the > carry flag. > > I looked in the test source code (is-div-test.S), and I found 2 > contradictory comments about the expected flags: > > * The l.div and l.divu instructions should set the carry flag as well as > * triggering an event when divide by zero occurs. > (this is implemented in inst-set-text.exp, and matches the architecture > specification) > > /* Divide by zero. Should set the overflow flag. */ > (this is what the or1200 simulation is delivering) > > The specificacion does say it should be the carry flag, but, on the other > hand, dividing by zero should trigger the Range Exception, and the flag > that enables it is called SPR_SR_OVE (OVE = Overflow). > > By the way, I have got no reaction at all to my last 2 messages to this > mailing list about similar issues with other instructions, there were > titled: > > 1) Different SPR_EPCR_BASE address on range exception with or1ksim and > with or1200 > 2) Different l.sub overflow flag with or1ksim and with or1200 > > If this message finds no resonance either, I don't think I will post any > more messages about the test suite results against or1200 in the future. > > Regards, > rdiez > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc >
Hi Ruben, I have seen your mails, and appreciate what you are doing, but haven't had the time to analyze the problem further. My guess is that the same applies to the other developers as well. I know that it's frustrating to report stuff that no one seems to care about, but unfortunately we have to live with that. Could you please report them as bugs on bugzilla.opencores.org too? I regularly go through the list there and try to fix things (or force them down the other guys throats) when I have the time, and they don't get lost as easily as they can do on the mailing lists. -- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
