Random Access Requirement: More Info

Hi,

here is some more information on the random access requirement.

* Introduction

There is a general consensus in the group that one of the major goals
for SCE-MI 2.0 is to enhance ease of use.

The random access requirement falls in the category of ease of use
enhancements to SCE-MI.  Random access is defined as non-sequential
access to fields of a message.  There are two categories of random
access that will be considered in the following: random access from
the HDL side and random access from the sofware side.

* Random access from the HDL side

SCE-MI 1.x messages already offer full random access so the random
access requirement in the context of the SCE-MI 2.0 effort applies to
variable length messages (VLM).

Given that the group has not fully converged on the concept of VLM,
the following definition is given in order to allow the discussion of
the random access requirement.  However, this does not mean that the
random access requirement is only applicable to this particular
definition of VLM.  A VLM is defined as consisting of one or more
message words where each message word has the same fixed width in
terms of a number of bits.  A SCE-MI 1.x message can thus be viewed as
a degenerate VLM that is one message word long.

Random access can now be divided into two separate concepts: 1) random
access of bits within a message word and 2) random access of message
words within a message.  (1) is automatically provided in any
reasonable concept of VLM.  Hence, (2) is where the focus of the
random access requirement lies.  In other words, the random access
requirement states that the application should be able to access the
individual message words of a VLM in any order.

Random access can be divided into several levels according to how
restricted the random access is:

  Sequential access: no random access at all

  Local random access: random access is available within some
    window of the current message word

  Forward random access: random access is available forward
    from the current message word, but never backwards, i.e.,
    one cannot go back to earlier message words

  Full random access: no restrictions at all.

Orthogonally, the following characteristics are also a consideration:

  Static access: the transactor always accesses the message words in
    the same fixed pattern

  Dynamic access: the transactor may dynamically change its access
    pattern, e.g., as a function of bus interface activity, message
    content, internal state, etc.

Note, it has been implicitly assumed that only one message word is
accessed per clock cycle.  If the transactor requires access to
multiple words it can either use the uclock or a wider port.  Hence,
it does not appear to be necessary to consider multi-message word
random access on a per-uclock basis.

Some scenarios where random access could be useful:

  Abort/error conditions in the middle of a large message: the
    transactor experiences an abort (e.g., PCI abort) on the bus
    interface and needs to skip to the end of the message to terminate
    the current transaction early.

  Reassembly of split and segmented transactions: some protocols allow
    bus transaction to be segmented into smaller entities which can
    arrive out of order.  Random access would be a convenient
    mechanism for reassembling the segments and present a coherent
    message to the software side.

  Compressed or otherwise encoded messages: transactions may be
    conveyed in compressed form or as a generator in order to reduce
    message transfer overhead.

  Structured messages: transactions that consist of various predefined
    fields that need to be extracted at varying rates.  Depending on
    the state of the transactor, some fields may need to be skipped,
    etc.

  Decouple software side and hardware side of transactor: if the two
    sides of the transactor are decoupled, a new degree of reuse can
    be achieved where a single software side can be used to drive
    a family of hardware sides and vice versa.  Random access can
    enable this decoupling by allowing the standardization of
    transaction representation in VLMs within the family of
    transactors.  For instance, a transactor could be defined to
    consist of a number of pre-defined fields that are made available
    in the VLM.  Random access would allow access to those fields a
    particular transactor cares about.

As mentioned in the introduction, the random access requirement is an
ease of use requirement.  All of the above can be done today in SCE-MI
1.x.  But this is also true of any of the other proposals/requirements
that are currently being considered for SCE-MI 2.0.  Random access as
proposed would simplify the task of creating transactors that require
this type of access.

* Random access from the software side

SCE-MI 1.x already offers full random access to the software side
representation of messages.  What it does not offer, however, is the
ability to access selected portions of the message word as it exists
on the hardware side.  This ability would enable the software side to
access individual fields of a message without having to transfer the
whole message.  Note, the term `message' is misleading in this context
as this type of random access makes most sense when the data being
accessed represent stored state that is being presented to the
transactor by the SCE-MI infrastructure.  This is useful for handling
transactor configuration parameters and reading of transactor state
variables such as statistics counters and error indicators.

With the random access capability, state can be updated on a per-field
basis without requiring the software side to keep track of the total
state vector and push the whole vector to the software side each time
a field needs to be updated.

Similarly, reading of transactor state can be limited to those fields
that are relevant in each situation.

This type of random access can be emulated in SCE-MI 1.x by
instantiating a port per smallest unit/field that will be accessed.
However, this could lead to a large number of ports and likely poor
performance due to per-port SCE-MI infrastructure overhead.  The
random access capability allows multiple fields to be grouped but
still accessed individually.  Other benefits of this feature include
the ability to create parameterized, generic transactor configuration
and status blocks that can be used by a family of transactors where
each transactor has its own definition of fields.

* Conclusion

All of the enhancements to SCE-MI currently being considered for
SCE-MI 2.0 can be implemented at the application layer in SCE-MI 1.x
with varying stretches of the imagination and levels of effort, and
the random access requirement is no exception.  It is an ease of use
enhancement that will greatly simplify the types of data/message
accesses discussed above.  For instance, in the transactor
configuration example, instead of having to instantiate multiple ports
with their associated port proxy objects and the code to manage these,
one only needs one port and one port proxy.

Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com> 
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com 
78 Dragon Ct.                             Tel:   781 721 8229 
Woburn, MA 01801                          Fax:   781 932 7488