|
Message
From: "Damjan Lampret" <lampret@o...>
Date: Wed, 12 Nov 2003 14:34:49 +0100
Subject: Re: [openrisc]
Thanks. I'll look at these and if it has any implications for the other
configurations. I'm thinking to reduce number of configurations as it seems
there is always a leak in one of the configuration. Fix one bug and it works
for most but opens an bug in an completely third configuration. I'm working
to have a better set of test cases covering more configurations but maybe
the quick way to reduce amount of configurability, at least temporarily.
regards,
Damjan
----- Original Message -----
From: "Ian Buckley" <ibuckley@r...>
To: <openrisc@o...>
Sent: Wednesday, November 12, 2003 1:47 AM
Subject: [openrisc]
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.
ibuckley@r... <mailto:ibuckley@r...> , (408) 412 4012
|
 |
Browse
