Computer-Aided Protocol Engineering (CAPE) Tools v1.5
Frequently Asked Questions
Are there any royalities that need to be paid on the resulting code?
No. All code and information produced by the CAPE tools that is derived from
your protocol description completely belongs to you. In fact we provide editable
code header template files for inserting your intellectual property protection
notices and source code control codings in the header of output files.
Are there any binary files that need to be deployed with the resulting code?
No. All example C codes that operate the protocol are provided in source form.
What variety of C code does the CAPE tool generate?
Simple C mostly as data structures. No C++ constructs or libraries are used.
Examples of the C code are shown in Application Note 5.
The CAPE Tool generates a threaded-code interpreter. This means that most of
the information from an individual protocol is encoded as C data structures that
are interpreted by a small C code interpreter. The source of an example
interpreter in included for you to modify. Examples of modifications are also given.
How do I know the output code from the CAPE tool will work in my operating
Communication protocols and real-time interactions take place in a wide variety of operating
environments. The operating environment of a microporcessor driven cellular phone
is much different from the I/O processor of a mainframe. We expect all users to
have different operating environments. Threaded code is very compact and has a
high locality. This suits both very small microprocessor environemnts and virtual
memory based environments.
But how do I connect to my particular environment?
In your protocol or interaction description you describe events that
trigger actions. Basically, it is a finite state machine (FSM) model. The CAPE
tool generated code establishes connections to these events and actions as
data definitions and function templates. You must implement the operating
environment specific raising of events and implementation of actions. These are
linked with the protocol interpreter and the generated protocol .c and .h files.
Examples of these files are given in Application Note 5.
Won't a threaded interpreter be too slow?
Most of the CPU time spent in a protocol is spent in the events (breaking packets)
and actions (building packets). Very little is spent in the management of the
protocol. Only the management is interpreted.
How do I specify my protocol?
The CAPE Tool compiles a description in Bayfront Technologies Protocol
Description Language (PDL) which is a simple intuitive language for just
discribing the basics of a finite state machine. Examples of PDL are
given in Application Note 5.
Why use a separate protocol description language?
Because we have a discription of a FSM in a FSM language rather than say C
macros or templates we can do more than just generate code. In particular we
can check definitional completeness,
generate state transition diagrams,
generate state description diagrams,
and produce different coding styles. In addition,
a description language and implementation provides an educational
framework for developers new to protocols.
Can I build protocol stacks?
Yes. Although the CAPE Tool works only on one FSM at a time the output
tables from multiple FSMs may coexist. In fact, it is easy to modify the
protocol interpreter to provide AT&T Streams-like priority processing for
a protocol stack.
Can I have multiple FSM's per stack layer?
Yes. In fact most protocol layers consist of two FSMs: control the link and
provide service. Link control usually enables/disables the provision of service.
Because you control the protocol interpreter, how the two (or more) FSMs interact
is completely up to you. As an example, a link FSM may either freeze or
reset a service FSM on link failures.
Is the generated code reentrant?
Yes. All of the protocol instance information stored by the
protocol interpreter is accessed
through a context block pointer.
Back to index page
copyright © 2001 Bayfront Technologies, Inc.