[evla-sw-discuss] [Fwd: Re: Accelerated Technologies "Nucleus" ROTS]

[Bill Sahr]

-------- Original Message --------
Subject: Re: Accelerated Technologies "Nucleus" ROTS
Date: Wed, 12 Dec 2001 14:28:59 -0700 (MST)
From: Kevin Ryan <kryan at aoc.nrao.edu>
To: kryan at zia.aoc.NRAO.EDU, bsahr at cv3.cv.nrao.edu
CC: bclark at ozone.aoc.NRAO.EDU, bsahr at zia.aoc.NRAO.EDU,
ghunt at zia.aoc.NRAO.EDU,gvanmoor at zia.aoc.NRAO.EDU,
browen at zia.aoc.NRAO.EDU,wkoski at cv3.cv.nrao.edu,
gpeck at cv3.cv.nrao.edu,ksowinski at cv3.cv.nrao.edu

Bill,

The only point I was trying to make was that the price of the
new OS is approaching that of VxWorks.  The advantages of 
VxWorks over another RTOS (price not considered) are great for
us at here at NRAO in terms of our experience with it. 

There is a large learning curve with RTOS's not just in terms
of what goes onto the target processor, but also with the 
development systems.  It would not be in our best interest to
spend the extra time on a new system, if that system offered
few or no new benefits.  And it would be even worse, if that
system offered *less* benefits as I am initially inclined to
think in this case.

I disagree with your assertion that we might consider designing 
the rest of the real-time system around the requirements of the 
MIB.

I, for one, did not completely endorse the use of the EC-1 when
it was first mentioned but I figured it was the hardware folk's
'thing' so I did not concern myself much about it.  Now that we
software people are becoming more involved with it, I guess it is
time to chime in my opinion.   

There are plenty of ready-made (COTS) boards, in industry standard 
form factors, such as Industry Pack (IP) and PCI Mezzanine Card (PMC),
that have VxWorks board support packages and that use up-to-date
processors and that have nearly the same I/O capabilites as the EC-1
(some with additional ADC and DAC's already on board).

I am willing to bet that we could buy cheaper than we could build.

Wayne told me that he was not totally committed to the EC-1, that he
picked it only because of the wide variety of I/O ports it supported
including CAN which he thought would be good in case it might be used
on ALMA. 

I also just found out on Monday that we may not be able to use the
EC-1 based MIB for the Correlator.  

So what it all boils down to is:

1) We come up with a good idea of a common module that could be used
   to interface software to EVLA hardware for both the antennas and 
   the correlator.

2) We picked a wierd processor for this module because it supports 
   CAN which is used on ALMA but which will not be used on EVLA.

3) We are now thinking of having to purchase and learn how use a new
   RTOS because it supports the wierd processor that supports CAN 
   that is used on ALMA.

4) This means we will have to buy *two* expensive RTOS licenses (one
   that supports the rest of the system, and one that supports the
   wierd processor.  
    ... Or else  ...
4b)We redesign the rest of the real-time system to support the new RTOS.

5) We find out that the wierd processor might not have the power 
   required to control the correlator.

Do you see where this is going?  We have a home-made module, for the
purpose of an EVLA-wide, common hardware/software interface, that 
works on ALMA, but not necessarily the EVLA itself.

We've just lost sight of the big picture.

Kevin