Article View: comp.robotics
Article #964Re: 68HC11EVBU fanout data
From: Ronald E Garnett
Date: Tue, 13 Oct 1992 18:04
Date: Tue, 13 Oct 1992 18:04
61 lines
3310 bytes
3310 bytes
fredm@media.mit.edu (Fred G Martin) writes: >In article <1992Oct12.163640.25052@hemlock.cray.com> kilian@cray.com >(Alan Kilian) writes: >>The synchronous connections are generally daisy chained so that each CPUs >>output only drives one other CPUs input. This way you can connect an infinite >>number of CPUs together. Like this: >While this arrangement will probably work technically, I don't think >it's standard practice. >First off, it's generally not problematic for a CMOS output to drive >lots and lots of CMOS inputs. 10 is easy, 100 is likely to be >possible. So there isn't a fan-out problem in the first place that >might need to be solved by the daisy-chaining scheme. Also, in your >solution, the SCK (serial clock) line from the master must drive all >of the slaves, so if there is a fan out problem, the daisy-chain >doesn't solve it. >Second, your scheme is very sensitive to the exact number of CPUs in >the chain. If the master CPU (CPU A in your example) wants to get >data back from CPU B, it must know exactly how many CPU's are in the >return data path (in your example, one; CPU C). This isn't a very >easy arrangement to deal with in software: if you add a CPU to the >loop, either you have to change a bunch of constants or get the >network to figure out for itself how many CPUs there are. >The more accepted solution will tie together each of the MOSI, MISO, >and SCK lines for each CPU. The one CPU is the master (its Master Out >Slave In functions as output) and all the other CPUs are slave (their >MOSIs are input). Likewise, a given slave can respond to the master >by driving its MISO (Master In Slave Out). >This topology is much more robust when it comes to adding and removing >nodes; if each node has a unique ID, then the master can send out a >network package of sorts that is addressed to a particular slave. If >that slave doesn't respond, well then it is not connected. But >communication with all of the other slaves can continue without >modification. That is the scheme I was planning on using, but was unsure of the fanout. Have you seen any data, or have you seen implementations yourself which have had large numbers of "passengers on the bus? A second question is: Since this is essentially a bus, what bus arbitration schemes are typically used? I have a few ideas, but nothing concrete yet. Third question (related to the first): The capacitance of the bus is going to be a strong factor as the number of nodes increases. And the physical length is goin g to be a consideration when operating at MHz speeds. Any data (experimental or otherwise)? Thank you all for your input! Ron Garnett, Grad student in E.E. UIUC at Champaign, Urbana .
Technical Details
Message-ID:
<Bw2nIy.4DL@news.cso.uiuc.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!ogicse!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!ehsn2.cen.uiuc.edu!rg9538References:
<1992Oct12.163640.25052@hemlock.cray.com> <1992Oct13.162310.3110@news.media.mit.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!ogicse!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!ehsn2.cen.uiuc.edu!rg9538 From: rg9538@ehsn2.cen.uiuc.edu (Ronald E Garnett) Newsgroups: comp.robotics Subject: Re: 68HC11EVBU fanout data Message-ID: <Bw2nIy.4DL@news.cso.uiuc.edu> Date: 13 Oct 92 18:04:09 GMT Article-I.D.: news.Bw2nIy.4DL References: <1992Oct12.163640.25052@hemlock.cray.com> <1992Oct13.162310.3110@news.media.mit.edu> Sender: usenet@news.cso.uiuc.edu (Net Noise owner) Organization: University of Illinois at Urbana Lines: 61