|
Message
From: "Ian Buckley" <ibuckley@r...>
Date: Tue, 11 Nov 2003 16:47:18 -0800
Subject: [openrisc]
Title: Message
I ran into problems
with the OR1200 data cache last week where an illegal
Wishbone
bus transaction
locked up my memory controller design. I traced the problem to a
bus
cycle that had no
SEL_O bits asserted, and hence to the data cache where I believe
I
found the
problem.
In file
or1200_dc_top.v the line:
assign dcsb_sel_o =
(dc_en & dcfsm_biu_read & !dcfsm_biu_write & !dcdmmu_ci_i ) ?
4'b1111 : dcpu_sel_i;
causes the first
DWORD fetched as part of a line refill to use 4'b1111 as SEL_O but afterwards on
subsequent fetches
to complete the line
refill, state changes in the CPU cause spurious bus value changes in the DMMU
which can
(should you happen
to have them as part of the dcache_inhibit logic defined in or1200_config.v)
cause incorrect
values (i.e NOT
4'b1111) as the SEL_O for these transactions.
For reference I
fixed the problem for our specific configuration and application as
follows:
I brought the
'cache_inhibit' signal up through the hierarchy from or1200_dc_fsm.v into
or1200_dc_top.v and
modified the offending line as shown:
assign dcsb_sel_o =
(dc_en & dcfsm_biu_read & !dcfsm_biu_write & !cache_inhibit) ?
4'b1111 : dcpu_sel_i;
For reference we had
the following definition for data cachability in or1200_defines.v when this
cropped up:
`define
OR1200_DMMU_CI ~((dcpu_adr_i[31:28] == 4'b1111) || (dcpu_adr_i[31:28] ==
4'b0000))
Whilst so far my fix
has verified and held solid, I have not thought it through for other
possible OR1200 configurations,
Ian
Ian Buckley, Architect,
Rosum.
|
Browse
