Re: Ada95/Mil-Std-1553 Problem (Long Post - Sorry About That)

[mfb@mbunix.mitre.org (Michael F Brenner)]

My experience with 1553 indicates the following:
    (a) The bit structures are easier to deal with in Ada-95 because
    of the modular types.
    (b) To be compatible with C or FORTRAN or JOVIAL at the other
    end, let the high-order bit be always zero
    (c) The hard part is the conversion from 1553A to 1553B which
    requires a method of using the extra wire when no response
    is received on the first wire, for extra reliability. It is 
    easier to design this in First, rather than add this in later.
    (d) While everyone frowns on overlaying data using address
    clauses, I have seen them used on 1553A or 1553B drivers on
    MIPS, 80x86, and 680x0 CPUs in Ada, with no efficiency hit or
    reliability problems. In all three compilers, there WAS an
    efficiency hit for using an unchecked_conversion: it did a
    copy operation for most or all accesses.
    (e) Getting rid of the tag is a bigger problem than you indicate
    because the machine-independent specification of how to represent
    the tags is not in the Ada Standards, but in the CORBA standard.
    Since not everyone on the other side will have access to CORBA,
    you should not use tags, discriminants, or unconstrained elements
    in the message data structures themselves. Instead, ACCESS EACH
    ELEMENT through an object oriented interface (a get function and
    a set procedure). This use of object oriented design forgives
    many coding sins and deals with the foibles of many languages,
    operating systems, message formats, and hardware protocols like
    the 1553.
    (f) You are absolutely right about avoiding dynamic allocations
    because of unpredicatability of time, even in the fastest systems.
    You are also right that a good approximation to the amount
    of time your system will take is proportional to the number of
    copies of the data you make. Therefore, at this first approximate
    level, reducing the number of copies is indeed critical. 
    (g) But in these days of plummeting memory chip prices, and continued
    blossoming of CPU speeds, we should not restrict ourselves to
    slow, small-RAM hardware solutions. A MIPS R10000 chip today with
    dual ported memory for the buffers is no more expensive than
    the LSI-11, 680x0, or Spark chip solutions were last year. The
    new desktop Pentium PRO 200MHz chips with PCI bus and memory
    mapped I/O to dual ported memory can copy the buffer in zero time
    or less (because of overlapping, pre-reading, hardware memory
    protection, write-back cache larger than the size of the buffer,
    and mapping registers). The translation lookaside buffers for
    virtualizing the Spark, MIPS, TI, and Alpha chips, when combined
    with 2 levels of cache can give statistical determinate memory
    access of a single cycle, with the worst case only 8 cycles.
    All of these brands of chips permit the addition of DMA
    channels which can read and write memory in parallel. These are
    just some of the more common brands of chips and there are
    many more brands and many custom chips, ASICs, PALs, etc. Do not
    limit yourself to fore-ordained hardware. Be flexible enough to 
    recognize that any Ada procedure or task can be replaced by a
    chip. For example, they have RISK chip CPU boards that plug into
    a PC, that you talk to through memory mapped RAM locations. 
    Sometimes the best software solution is improved hardware.