[Logo] [Bayfront Technologies] [CAPE Logo]

Bayfront Technologies
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 environment?

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, generate simulations, perform/generate analysis, 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.
[index] Back to index page


copyright © 2001 Bayfront Technologies, Inc.