From brash@AM.RDGENG.REO.RDGENG.RDGMTS.mts.dec.com  Tue Oct 15 12:26:29 1996
Return-Path: <brash@AM.RDGENG.REO.RDGENG.RDGMTS.mts.dec.com>
Received: from server21.digital.fr by art-1.acorn.co.uk (SMI-8.6/SMI-SVR4)
	id MAA14618; Tue, 15 Oct 1996 12:26:19 +0100
Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id NAA11993 for <mstephens@art.acorn.co.uk>; Tue, 15 Oct 1996 13:29:29 +0100 (MET)
Received: from valmts.vbe.dec.com (valmts.vbe.dec.com [16.36.176.78]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id NAA13982 for <mstephens@art.acorn.co.uk>; Tue, 15 Oct 1996 13:29:19 +0100 (MET)
Received: from mts.dec.com by valmts.vbe.dec.com (PMDF V5.0-7 #16475)
 id <01IAO8KV40B40000VO@valmts.vbe.dec.com> for mstephens@art.acorn.co.uk; Tue,
 15 Oct 1996 13:24:00 +0100 (CET)
Received: with PMDF-MR; Tue, 15 Oct 1996 12:18:35 +0000 (GMT)
MR-Received: by mta RDGENG.MUAS; Relayed; Tue, 15 Oct 1996 12:18:35 +0000
MR-Received: by mta REOVTX; Relayed; Tue, 15 Oct 1996 11:19:37 +0000
MR-Received: by mta RDGMTS; Relayed; Tue, 15 Oct 1996 11:19:41 +0000
MR-Received: by mta VALMTS; Relayed; Tue, 15 Oct 1996 11:20:19 +0000
Disclose-recipients: prohibited
Date: Tue, 15 Oct 1996 12:18:35 +0000 (GMT)
From: BRASH DTN 830-6163 <brash@AM.RDGENG.REO.mts.dec.com>
Subject: FWD: Re: StrongARM bug (fwd) (fwd)
To: Mike Stephens <mstephens>
Message-id: <9935191215101996/A05479/REOVTX/11AA7B132200*@MHS>
Autoforwarded: false
MIME-version: 1.0
Content-type: MESSAGE/RFC822
Importance: normal
Priority: normal
Sensitivity: Company-Confidential
UA-content-id: 11AA7B132200
X400-MTS-identifier: [;9935191215101996/A05479/REOVTX]
Hop-count: 3

Received: from mail.vbo.dec.com (mail.vbo.dec.com)
 by valmts.vbe.dec.com (PMDF V5.0-7 #16475)
 id <01IANHKFDFIO007VXB@valmts.vbe.dec.com> for david.brash@reo.mts.dec.com;
 Tue, 15 Oct 1996 00:14:55 +0100 (CET)
Received: from server21.digital.fr (server21.digital.fr [193.56.15.21])
 by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA09225 for
 <david.brash@reo.mts.dec.com>; Tue, 15 Oct 1996 00:17:27 +0100 (MET)
Received: from relay-1.mail.demon.net (relay-1.mail.demon.net [158.152.1.140])
 by server21.digital.fr (8.7.5/8.7) with SMTP id AAA01866 for
 <david.brash@reo.mts.dec.com>; Tue, 15 Oct 1996 00:17:01 +0100 (MET)
Received: from post.demon.co.uk ([(null)]) by relay-1.mail.demon.net  id
 ab02625; Mon, 14 Oct 1996 19:26 -0300 (BST)
Received: from eidos.demon.co.uk ([158.152.55.149]) by relay-3.mail.demon.net
 id aa21502; Mon, 14 Oct 1996 19:17 -0300 (BST)
From: Stephen Streater <sbs@eidos.co.uk>
Subject: Re: StrongARM bug (fwd) (fwd)
To: "david.brash" <david.brash@reo.mts.dec.com>
Cc: sbs <sbs@eidos.co.uk>
Reply-to: sbs <sbs@eidos.co.uk>
Message-id: <1641@eidos.co.uk>
Autoforwarded: false
MIME-version: 1.0
X-Mailer: PCElm 1.10
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Delivery-date: Mon, 14 Oct 1996 23:16:45 GMT
Importance: normal
Lines: 77

Forwarded message follows:

I think this is what you need. We have verified that this does in
fact fix all the known problems which we have been having at Eidos.

> > > > This is related to other (fixed) bugs on earlier revisions of 
> > > > the silicon, and shows up in Rev J (Eidos prototypes) and Rev K 
> > > > (as distributed by ART). This program is a RISC PC+SA program 
> > > > which tests out the STM on line 220 until it breaks once or it 
> > > > succeeds 100,000 times.
> > > > 
> > > > Summary of the bug:
> > > > In SVC26 or SVC32 modes, STM with a ^ storing both USR and SVC 
> > > > mode registers (R10-R12 USR and R13-R14 SVC) can store R11 twice 
> > > > instead of R11 and R12.
> > > > 
> > > > This bug does not seem to occur if the STM is to memory in the
> > > > cache. 
> > > > 
> > > > On uncached memory, this code seems to go wrong only about 1/800 
> > > > of the time - could this be something to do with the D-CACHE 
> > > > size - it seems reasonably consistent where it goes wrong.
> > > > 
> > > > The alignment of the STM affects the bug - the code is assembled 
> > > > 8 times at 4 byte intervals, and half of them work consistently, 
> > > > half of them don't work.
> > > > 
> > > > Draining the write buffer after the STM does not affect the 
> > > > reliablity of the program.
> 
> 
> Stephen,
> 
> Rich Witek and I believe we have located and reproduced the bug.  It
> is, we believe, a fairly easy metal 1 fix.  Temporarily, the following
> software workaround should fix the problem:
> 
>   Where you have: 
>      stmia r9, {r10-r14}^
> 
>   Replace with:
>      mcr MMUCP, 0, r9, MMUIDReg, c0 
>      stmia r9, {r10-r14}^
> 
>   along with the definitions:
>   MMUCP     CP    15
>   MMUIDReg  CN    0 
> 
> This will effectively insert a nop (a store TO the chip ID register)
> which will not fault and allow the stmia enough time to complete
> properly.  This has been verified on our behavioral model.
> 
> There are some internal workings associated with the mcr that make
> it necessary to insert this opcode instead of a simple nop.  We have
> also verified that non-hat stmia opcodes do not exhibit this behavior.
> 
> Please try this in your environment and let Rich and I know the results.
> Rich is at witek@pa.dec.com.
> 
> Thanks for your help and we'll get back to you as soon as we finalize 
> the actual fix.
> 
> 
> ken
> +-----------------------------------------------------------------+
> |     Any comments or opinions are solely those of the author     |
> |             and not Digital Equipment Corporation.              |
> +-----------------------------------------------------------------+
> |  Ken Patton                                  patton@pa.dec.com  |
> |  Digital Semiconductor                                          |
> |  Austin Research & Design Center                 Austin, Texas  |
> +-----------------------------------------------------------------+
> |      I have seen enough to know that I have seen too much.      |
> +-----------------------------------------------------------------+
> 
> 
Stephen Streater

