ozkan@VUSE.VANDERBILT.EDU (Mehmed Ozkan) (03/08/90)
We had a similar problem as Klaus had with EXPRESS. We use a SUN 3/110 as the host system to our transputer network. It has a B011 board with one t800 and a c004 on it. We have a number of transputer boards in an Inmos item box. As we set up the configuration for the root transputer only, every thing works fine. When we connect the external transputers to the root and configure accordingly, the external transputers are not reached even if we proggrammed the cross-bar switch properly. The only solution with the latest release of the EXPRESS is to take the c004 switch out and hardwire an 84-pin header instead, for a fixed configuration. Then things starts moving. However, it is not the most desired solution, since we can not have the flexibilty of a crossbar switch, any more. Mehmed Ozkan Vanderbilt University Center for Intelligent Systems Nashville, TN 37235
K312240%AEARN@CORNELLC.CIT.CORNELL.EDU (Klaus Kusche) (03/09/90)
Dear Mailing List: Just another problem concerning Express: We have the following hardware: * A PC/386 compatible with one 100% B004-compatible transputer board. The board has a subsystem error/reset/analyze logic which behaves B004-compatible, *not* B008-compatible: Resetting the board itself is *not* propagated to the subsystem reset. I will call this transputer the root from now on. * An external box containing 16 transputers and 4 C004 link switches. All the links go through the C004's, no hardwired connections. Root link 3 controls C004 configuration, root link 1 and 2 go to C004's, again no hardwired connections. All the reset signals of these transputers and all the reset signals of the C004 switches are wired together to a single reset line. This line (together with the combined analyze and error signals) is connected to the root's subsystem port. I will call these 16 transputers external transputers from now on. Usually, I use this configuration as follows: * I execute a program on the root which resets the subsystem and sets up the desired C004 connections. This leaves the root in a dirty state, the C004's in the desired topology, and the external transputers in a clean reset state. * Then I boot the application normally. This resets and boots the root, but as the root reset is not propagated to the subsystem, the application will find a network of reset transputers in the desired link configuration. * Before running the next program, I use my reset and reconfigure tool again. This method has been tested and proven to work as desired. With Express, the following happens: * I run my configuration tool. * I run the 'cnftool' with graphics and the automatic worm. It does find all 17 transputers, and it shows the correct link connections loaded into the C004's in the first step. * I rerun my configuration tool, setting up exactly the same configuration again. * I try to run 'exkload' to boot Express. It reports that it was able to find the root transputer, but that all links to the external transputers are unconnected. * Obviously, when initializing the root transputer Express also issues a subsystem reset, which causes all the C004's to revert to their 'all links unconnected' state. I tried all possible changes to the reset information in the Express configuration description (by entering the configuration by hand in text mode, by patching that file, etc.). I'm absolutely sure that this file specifies 'down' type reset for all transputers (which should work), and *never* specifies 'subsystem' reset, and the graphical reset tree displayed by the 'cnftool' confirms that, but still, whenever I try 'exkload', the link switches are obviously reset for some damned reason. Now my questions: * Is my assumption correct that 'exkload' always issues a subsystem reset, even if the configuration file does not indicate a subsystem? * Have I missed some tricky detail? * What can be done against this nasty behaviour??? Many thanks in advance for your help! ************************************************************************ * Klaus Kusche * * Research Institute for Symbolic Computation * * Johannes Kepler University Tel: +43 7236 3231 67 * * A-4040 Linz Telex: (Austria) 22323 uni li a * * Austria (Europe) Fax: +43 7236 3231 30 * * * * Bitnet: K312240@AEARN * * Arpa/CS/Internet: K312240%AEARN.BITNET@CUNYVM.CUNY.EDU * * UUCP: mcvax!aearn.bitnet!K312240 * * Janet: k312240@earn.aearn or k312240%aearn@earn-relay * ************************************************************************
K312240@AEARN.BITNET (Klaus Kusche) (03/20/90)
Dear Mailing List:
I finally got Strand-88 running on our PC-based transputer system.
(concerning my previous mail that the Express system which is behind
Strand seems to reset the link switches before loading the system:
It really does, I had to patch 'exkload', but now everything works
fine...).
However, I'm very frustrated with the topologies that Strand is able to
run on:
* We were not able to use any of the predefined Express topology
classes 'torus' or 'hypercube', we had to classify every topology
as 'general' (this could also be a lack of documentation).
* Given that, *any* (really, no exception!) topology containing a
circle deadlocked sooner or later: Some during 'exkload' or 'topinit',
the remaining ones during the Strand bootstrap. We never reached the
Strand prompt.
So, only tree topologies remain. However, again there was a problem:
* In the Express topology file, it must be specified for each node
which node is responsible for resetting this node, and if this node
is connected to the system or the subsystem control lines of the node
resetting it.
* 'exkload' insists that there is a direct link connection between any
nodes whose reset signals are connected.
* 'exkload' also insists that each node resets at most one node via
system reset, and at most one node via subsystem reset.
* Hence, by definition it is not possible (and 'exkload' strictly
enforces that definition) to have any topology which contains a
transputer being the common root of three independent subtopologies
(ternary trees, which would be the most natural trees for transputers,
are the most important examples of such impossible topologies):
+ The root of one of those subtopologies is reset by this transputer
using the system reset ('down' in Inmos terminology).
+ The root of the second subtopology is also reset by this transputer
using the subsytem reset.
+ However, there is no legal choice for the reset of the third
subtopology: The only transputer it is connected to by link has no
more unused reset outputs, and resets not going along a link are
not allowed.
To increase confusion, 'cnftool' simply hangs on such topologies
without any message, rebooting the PC is the only way out...
Needless to say, our hardware of course does allow such configurations:
All transputers are controlled by a single reset...
To sum up: For two different reasons, it was impossible for us up to
now to run Strand on any topologies which are not variations of binary
trees (the pipeline being a special case of this).
Did anyone manage to get more than this?
P.S.: Some people asked what version of Express we use. It is
impossible to tell that! The only thing I can tell is that it is the
version which is part of Strand, and that some files contain the string
'August 1988'. However, I scanned all the binaries: No copyright, no
date, no version number!!! (have you ever seen such a software?)
************************************************************************
* Klaus Kusche *
* Research Institute for Symbolic Computation *
* Johannes Kepler University Tel: +43 7236 3231 67 *
* A-4040 Linz Telex: (Austria) 22323 uni li a *
* Austria (Europe) Fax: +43 7236 3231 30 *
* *
* Bitnet: K312240@AEARN *
* Arpa/CS/Internet: K312240%AEARN.BITNET@CUNYVM.CUNY.EDU *
* UUCP: mcvax!aearn.bitnet!K312240 *
* Janet: k312240@earn.aearn or k312240%aearn@earn-relay *
************************************************************************