Thread View: comp.sys.transputer
3 messages
3 total messages
Started by Tim Wilkinson
Wed, 04 Nov 1992 10:27
Link Splitting
Author: Tim Wilkinson
Date: Wed, 04 Nov 1992 10:27
Date: Wed, 04 Nov 1992 10:27
21 lines
1150 bytes
1150 bytes
Dear all
I'm looking for some info on the probability of splitting a single transputer
link to allow it to be connected to more than one destination transputer.
Any details or advice would be much appreciated.
Cheers
Tim
-------------------------------------------------------------------------------
Tim Wilkinson Department Of Computer Science
The University Of Hull
Kingston Upon Hull
North Humberside
HU6 7RX
email tjw@cs.hull.ac.uk
-------------------------------------------------------------------------------
Re: Link Splitting
Author: Andy Rabagliati
Date: Thu, 05 Nov 1992 04:59
Date: Thu, 05 Nov 1992 04:59
33 lines
1670 bytes
1670 bytes
In article <27661@castle.ed.ac.uk> bxhv02@castle.ed.ac.uk (Tim Wilkinson) writes: > >I'm looking for some info on the probability of splitting a single transputer >link to allow it to be connected to more than one destination transputer. > Tim Wilkinson email tjw@cs.hull.ac.uk A transputer uses both wires of a link, even for unidirectional communication. Each byte that goes out, must have an acknowledge come back before another byte will be sent. So, don't even *think* of bi-directional communication. The Correct Way would be to have the two 'return' wires go into a circuit that produced a 200ns pulse (10Mhz) or 100ns pulse (20Mhz) when one ack had been received from each return wire. The Dirty Way would be connect one return wire, ignore the other return wire, and hope for the best. What could go wrong ? Well, only that the second receiving transputer could drop, garble, and generally behave in a very un-transputery fashion. But, if it isn't doing anything else, and (especially) if you are nice to it and have comms go straight into internal RAM, or you help it along by delaying the other ack by a tick or two, you might get away with it. Don't tell the Transputer police, though. print ! "Just another occam hacker", Cheers, Andy. -- andyr@wizzy.com Andy Rabagliati, RR1 Box 33, Wyalusing, PA 18853 (717)746-7780
Re: Link Splitting
Author: Henk Uijterwaal
Date: Mon, 09 Nov 1992 15:17
Date: Mon, 09 Nov 1992 15:17
37 lines
2137 bytes
2137 bytes
In article <27661@castle.ed.ac.uk>, bxhv02@castle.ed.ac.uk (Tim Wilkinson) writes: +> Dear all +> I'm looking for some info on the probability of splitting a single transputer +> link to allow it to be connected to more than one destination transputer. +> Any details or advice would be much appreciated. +> +> Cheers +> +> Tim At NIKHEF-H (the lab I where worked before moving to the supercollider) we developed a circuit for broadcasting with TP links, e.g. 1 sending transputer to n receiving transputers, one way only. Basically the circuit looked like this: 1)DATA. Just connect the receiving TP's to the sending TP. 2) ACKNOWLEDGE. Connect every receiving TP to a flip-flop. The initial condition of all flip flop's should be low. The first bit of the acknowledge packet will set the flip-flop output high. Connect all flip-flop's to an AND gate. As soon as all TP's have acknowledged the data packet, the output of the gate will become high. This triggers a pulse former which then creates a 3 bit acknowledge packet. This packet is sent to the sending TP and resets the flip flop's. For the sending TP it looks like only 1 packet has been sent. There is no problem with receiving TP's not ready to receive data. (Probably this explanation is as clear as mud. I have the diagram in postscript somewhere, if anybody is interested let me know and I'll send you a copy). This circuit only works in one direction, the receiving TP's cannot send anything over the link to the sending TP but for our application this was not a problem. Henk.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads