Could someone please comment on the lack of a default for rf_addrw in or1200_ctrl.v?

I'm seeing zeroes on the rf_addrw signal when trying to execute "l.mfspr r9,r0,0x0011" (the SR).

Ultimately the regfile write enable hits the (artificial default) address zero instead of 9 on the next state.

Is this the right place for this sort of question?

Thanks and regards,
Dave

This forum typically gets questions of a less technical nature. I find the best discussions on the guts of the RTL designs or software occurs on the mailing lists:
http://opencores.org/or1k/OR1K:Community_portal#Mailing_lists

We are currently cross-posting to both the openrisc lists on openrisc.net and opencores.org until we settle on one. I'd direct questions there, as well as here, to reach as many of the other developers and users as possible.

It looks like l.mtspr also has problems. sel_a is being set to zero (SEL_RF) for this instruction, which ultimately causes addrbase in or1200_sprs.v to be incorrect and thus fail to write the SR.

Or am I just missing something obvious?

Thanks for any help, pointers, or info.

Regards,
Dave

That surely must contain the destination register address for the mfspr instructions. It will select the register's address in the decode stage from the instruction, and should be present on rf_addrw during the execute stage.

//
// Register file write address
//
always @(posedge clk or `OR1200_RST_EVENT rst) begin
if (rst == `OR1200_RST_VALUE)
rf_addrw else if (!ex_freeze & id_freeze)
rf_addrw else if (!ex_freeze)
case (id_insn[31:26]) // synopsys parallel_case
`OR1200_OR32_JAL, `OR1200_OR32_JALR:
rf_addrw default:
rf_addrw endcase
end

Check you are observing the correct instruction in the pipeline.

Yes I'm confident I'm looking at the correct instruction. I've hacked a fix for this problem; now I'm working on the mtspr question I posted as a followup. It seems addrbase is using operand_a which contains the data to be written to the SR, not an address (presumably the group address). I've attached a screen image of the waveforms. The code sequence in the pipeline is
l.nop 0x46
l.mfspr r9,r0,17 (SR)
l.ori r9,r9,16 (bit 4, ICE)
l.mtspr r0,r9,17 (SR)

I've got the mfspr working, as well as the ori, but because addrbase is incorrect in or1200_sprs.v, the SR is not written (although spr_we does fire, sr_we does not).

There seems to be some confusion about where the various operands come from in the m(t/f)spr cases...?

Thanks,
Dave

Oops, here are the waveforms.

I'd need to run some waveforms to check where the l.mt/fspr operands are coming from, but I'm certain that it works, otherwise the various bits of software we run ont he OR1200 wouldn't function, as the l.mt/fspr instructions are quite common. Perhaps over time it was changed by the original developers, and the legacy code not removed?

Aargh! The confusion is mine - so sorry for the noise here. I'm hand coding small memory images as a starting point and I put the register and immediate bits in the wrong place! Please forgive me.

Dave

Ok this is my last post for this week I promise! :-) I've corrected the instruction bits as follows:

0x1500_0046 // l.nop 0x46
0xB409_0011 // l.mfspr r9,r0,17 (SR)
0xA929_0010 // l.ori r9,r9,16 (bit 4, ICE)
0xC000_4811 // l.mtspr r0,r9,17 (SR)

What's happening is the same value that's supposed to be written to the SR (operand_a?) is being used as the addrbase in or1200_sprs.v. This causes bit 10 to be set thus mismatch the SR address. Please see the attached waveforms.

Thanks and regards,
Dave

No problem. But why hand-code? or32-elf-as will do the job for you.

Very limited budget forces me to simplify drastically - the risk of another set of unknown dependencies and such seems too great. 6 or 8 instructions isn't a big deal to create by hand.