Received: by oak.acorn.co.uk (4.1/Ai1.6)
	id AA07871; Fri, 23 Apr 93 09:22:04 BST
Received: from oak.acorn.co.uk by acorn.co.uk (4.1/Am33)
	id AA09776; Fri, 23 Apr 93 09:20:34 BST
X-Account: 220
Date: Fri, 23 Apr 93 09:23:39 BST
From: mchallis (Mike Challis)
To: bcockburn, kwelton, jroach, cwhyte
Cc: wstoye, dlowdell, mbird
Subject: Medusa Expansion Card FS Review
Message-Id: <2BD7B59B@mchallis>


                       FUNCTIONAL SPECIFICATION REVIEW


Topic:   Expansion Card Software Functional Specification
            - 0197,269/FS

Date:    22nd April 1993

Present: Bruce Cockburn   (author)
         Kevin Welton     (reviewer)
         Jonathan Roach   (project manager)
         Charles Whyte    (SQA)
         Mike Challis     (chairman)



1  Scope


Medusa platforms offer the following enhancements to the Acorn expansion
card interface:

  - 32-bit wide data path
  - 16M address space (EASI)
  - dedicated network card interface
  - DMA

This specification covers extensions to the Podule Manager required to
support these features.




2  Major issue


There does not appear to be sufficient time/resource allocated to development
testing - see section 6 below for details.



3  Other issues


3.1:  It's possible to design podule software in such a way that the podule
will work both with the current and the extended interface. This FS should
note the recommended way to determine which interface is available, thus
helping to make sure that this information finds its way into the Medusa
PRM.

3.2:  SWI Podule_ReadInfo should return the logical DMA channel number(s)
associated with the podule/network card: bits 13 and 14 of R0 could request
primary and secondary DMA channel numbers.

3.3:  Note that bits 15 to 31 of R0 should be set to zero, and that any
non-zero value here will generate an error.

3.4:  Many podule manager SWIs expect R3 to contain some podule identifier:
podule number, CMOS base address etc. An exact specification of what is
accepted (and how it is interpreted) should be included, and an error should
be returned if the contents of R3 are unrecognisable or incorrect.

3.5:  The FS proposes that non-zero interrupt relocations are not permitted
for the network card. Check that this is satisfactory.

3.6:  Note the default podule speed.

3.7:  Some minor changes to the kernel may be needed to make sure that it is
possible to *unplug a fifth podule (the network card).

3.8:  Note that SWI Podule_ReadInfo is intended to supersede other Podule
manager SWIs such as Podule_HardwareAddress; this needs to get into the
Medusa PRM.



4  Compatibility issues


HCCS market a podule into which further 'MicroPodules' can be plugged ('The
Ultimate Expansion System'). It would be worthwhile to discover how this
system uses the existing Podule Manager, and whether we could/should provide
further support for similar approaches in Medusa.



5  Development Test Strategy


No issues other than time available - see below.
  


6  Planning and timescales


Sufficient time for Bruce to complete the Podule Manager code and to remove
the 16M file size limit from NetFS has been allocated.


However, just three weeks are available for Bruce to complete the development
testing of:

  -  NetFS
  -  FPSC
  -  Econet
  -  Podule Manager

This is unlikely to be sufficient, given the difficulty of locating network
problems, and the turnround time for podule testing (where re-blowing EPROMs
is involved).



7  Match with market requirement


The proposed FS meets the requirements given in the Project Specification.



Mike Challis
22nd April 1993
