IRC logs for #openrisc Sunday, 2012-11-25

@stekernit's getting close, all tests pass except the last debug step one06:44
@stekernand there is something fishy with the uart test, only the line feeds show in the output06:45
@stekernthis is a fun case: l.lwz r3, 0x2000(r0); l.divu r3, r3, r407:27
@stekernthe load is in mem stage and the divu is in exec stage07:28
@stekernthe result from the load is needed before the divu can 'start'07:28
@stekerncurrently the alu operations are 'held off' by the decode_valid signal, but I can't easily just cut that off whenever I notice notice that kind of condition07:32
@stekernperhaps squezing in a nop bubble in between the l.lwz and l.divu is the way to go07:33
@stekernjuliusb: what do you think?07:33
-!- Netsplit *.net <-> *.split quits: heroux, olofk08:10
@juliusbstekern: what puts in the nop bubble?13:59
@juliusbthe decode stage?13:59
@stekernjuliusb: yes, I'm thinking that it could be detected there that there is a load or mfspr op in execute stage and an instruction in decode needing the register that that load/mfspr is going to write to14:57
@stekernso instead of outputting that instruction it outputs a nop and when the load/mfspr is done in mem stage the 'real' instruction is pushed out14:59
@stekernthe other option I guess is to stall the decode_valid signal as long as memsatge is stalling15:00
@stekernbut that will only help alu instructions, I need to postpone jumps to15:00
@stekernlike: l.lwz r3, 0(r0); l.jr r315:01
@stekernconnecting that stall signal directly to branch_occur works, but creates a naughty path15:02

Generated by 2.15.2 by Marius Gedminas - find it at!