FW: NI VXIpc SBC and VxWorks

[johill@lanl.gov (Jeff Hill)]

All,

This response from National Instruments may be of interest to persons 
that are considering the National Instruments VXIpc / vxWorks product 
combination.

Jeff Hill

> -----Original Message-----
> From: Scot Salmon [mailto:scot.salmon@natinst.com] 
> Sent: Wednesday, July 21, 1999 1:00 PM
> To: johill@lanl.gov
> Cc: shariff.dsouza@natinst.com; Scott Kovner
> Subject: NI-VXI for VxWorks
> 
> 
> Jeff,
> 
> Casey is no longer with National Instruments; Roger Hamilton
> (roger.hamilton@natinst.com) is the new support contact for the VXI
> group.
> 
> I appreciate the opportunity to comment on your e-mail; feel free to
> forward my reply (below) as appropriate.
> 
> > The primary problems were:
> > 1) Persistent random crashes in the nivxi system code under
> > interrupt load
> > 2) Our VXI interrupt service routine was run at task level, and
> > not at interrupt level, by the nivxi library. No equivalent
> > to WRS's intConect() was implemented for VXI interrupts.
> > 3) 300-500 uS average interrupt latency, and I suspect, much
> > higher peak interrupt latency.
> > 4) NI indicated that bug fixes to the initial
> > product would not be attempted until the system programmer
> > had finished a SCSI driver for the product.
> >
> > Its possible that items (1) and (4) could have been
> > resolved if we were patient, but unfortunately, we had
> > time pressure and we were unwilling to wait. I think that
> > items (2) and (3) however indicate design flaws inappropriate
> > in a real time CPU product, and therefore I cannot recommend
> > its use on EPICS system unless NI takes steps to redesign
> > their system software.
> >
> > I have CC'd to NI in case they would like to comment on the
> > the current state of the above issues.
> 
> Your assessment is largely accurate, although of course we would tend to
> disagree with the use of the word "flaws" to describe our design
> decisions.
> 
> As you suspected, issues 1 and 4 have been resolved by now.
> 
> Issues 2 and 3 are, as you are no doubt aware, the same issue.  I am
> surprised that you would ever encounter latency over 300uS as we have
> never seen anything in excess of 285uS in our tests, but the underlying
> decision to attach user-defined interrupt handlers at the task level
> instead of in the ISR does result in the issues you describe.
> 
> The decision to go with this design was made because of the high premium
> our customers had placed on architectural consistency with NI-VXI for
> VXIpc-7xx/8xx for Windows.  I understand and agree with VxWorks
> customers like yourself who point out that, unfortunately, this decision
> really slants the product away from some of the advantages of VxWorks.
> 
> If a sizable opportunity comes up in the future we can likely provide
> you with an extra set of tools to implement *certain subsets* of the WRS
> VME API, but (as you probably remember) we are not in a position to
> ensure the availability of WRS's API in general.  We support the NI-VXI
> API, which provides the functionality most customers demand, and in
> certain cases we would be able to expand our library to provide
> *specific* functionality if NI-VXI does not fully meet a requirement.
> 
> As an example, we might be able to provide a hook into the interrupt
> service routine, along with documentation about how to interpret the
> hardware's raw status information within the ISR.  Using this
> information, real-time deterministic functionality similar to
> intConnect() would be possible.
> 
> On an optimistic note, we are currently working on revisions to the core
> NI-VXI architecure that would allow for more efficient processing of
> interrupts when ported to platforms, like VxWorks, where a task thread
> is not the recommended place to handle interrupts.  We intend to bring
> this new core architecture to VxWorks at some point in the future.
> 
> It is certainly not our intention to alienate customers who are
> interested in NI products when we retire a hardware platform like the
> VXIcpu-030, but it is not always possible to keep all features of old
> products when we move to a new line.  I sincerely apologize for the
> inconvenience this caused you and I hope that you will still consider NI
> solutions when they fit your needs in the future.
> 
> --
> Scot Salmon, Staff Software Engineer
> National Instruments, Austin, TX
> scot.salmon@natinst.com
> 101010, 222, 52, ...
>