This page contains links to various references and technical
reports related to Rosetta. Some published papers are included,
but the majority of works referenced here are references for
accepted language elements or proposals for new language
elements. Many of the documents are historical in nature. The
old user and semantics guides are here along with what was called
the strawman. Most of the information from these documents is now
incorporated into the language reference manual.
Interactions Proposal and Paper
The latest proposal for new interaction definition syntax and
constructs. Download and review. Also, a technical paper on
how we anticipate interactions will be used in actual design
situations.
Development of the Rosetta LRM is being lead by Peter
Ashenden. The current draft is available for download
below. rosetta-std.pdf is the main LRM
document. rosetta-files.tgz contains Rosetta
source files developed to support the
standard. to-do-list.txt is a list of open
tasks.
The following are outstanding issues remaining to be resolved:
Complete specification of names in expressions chapter.
Review specification of types, and specifically of
polymorphic and dependent types. It would probably be wise
to define specific syntax for type schema denoting
polymorphic and dependent types, so that we can appeal to
the existing literature. Our notion of a function denoting
a polymorphic/dependent type is shaky and leads to
definitional problems. The same might also be said of
domains as types. Perhaps a specific type schema denoting
facets derived from a given domain would be more
appropriate than using the domain itself as the type.
Review specification of universal type formation in
expressions chapter. Currently, set(universal) is not
appropriate, since it doesn't take account of the way
polymorphic and dependent types are represented. However,
if type schema are introduced, then all types really would
be sets again, and scheme just ways to denote particular
sets. Then set(universal) should be ok. Check this.
Review denotational semantics of let expressions. Need
to nail this down a bit more rigorously.
Review type rules. Can they be defined only in terms of
the kernel language, or are there cases where type rules
need to be specified for full language constructs? Is it
sufficient to say that a full-language specification is
well typed iff its simplified and resolved form is well
typed?
Specify semantics of facet instantiation.
Specify semantics of facet inclusion.
Specify denotational semantics of an anonymous facet.
Review simplification semantics for components.
Review transformation semantics for domains.
Complete language design for translators:
Application using tick operations
Features for specifying default translators (on
included facets, on use clauses, in domains)
Review and complete model-of-computation (MoC) domains.
Develop useful translators between MoC domains.
Review interactions - are they needed? If not in the
form proposed, then in what form
Define consistency of a specification.
Review Bugzilla issues:
Address unresolved issues.
Check previously resolved issues and make sure they
are either addressed in the LRM or are no longer
pertinent.
These documents are provided for anyone interested in the
history of Rosetta's language constructs and semantics. They
are in no way final and were working documents. Currently
accepted language elements can be found in the Language
Reference Manual.
Strawman
The Strawman reflects current thinking about the Rosetta
language. It is not designed to be a standard or a final
implementation guide, but a record of what we are currently
thinking. When looking at the Strawman it is best to think of
walking into a research meeting and looking at the blackboard
without participating in the previous discussions - you will
learn something, but the information will necessarily be
incomplete.
Updates to the types chapter reflect some minor changes in
available types and functions. Constructed types now allow
constructors without parameters. Function types have been
cleaned up, and the semantics of enumerations is now defined
using constructed types.
The document chapters have been rearranged to provide a more
logical information flow
Updates reflect work by the Accellera Committee and semantics
definition work at KU and Adelaide. The types section is
undergoing review by the Accellera committee. Please visit The
SLDS-Rosetta page to see exactly what is under review and/or
participate in the review process.
Updates to the semantics chapter reflect joint work of The
University of Kansas and Adelaide University in defining the
underlying formal semantics of domains and facets. This work
is ongoing and some information has not yet been reflected in
the strawman. Contact the Rosetta group for more information.
Darrell Barker of the Air Force Research Lab's Information
Directorate has written a paper from a user's perspective on
the benefits of requirements modeling. This paper describes
his perspectives on the motivations behind systems level
design languages like Rosetta.
The Rosetta committee developed a demonstration of Rosetta
used in energy aware modeling. The demonstration shows how
Rosetta language features and tools can be used to
automatically generate custom energy analysis models from
domain specific descriptions of power consumption and
functional requirements models. The Rosetta approach differs
from traditional approach in that the analysis is performed at
the systems level prior to detailed or even architectural
design. The objective is helping the systems engineer decide
between implementation options early in the design
process. The slides associated with the demonstration
presentation are available as a zipped PowerPoint file.
This very brief white paper discusses the underlying semantics
of interactions and potential applications of Rosetta to
embedded software. Please note that the PostScript version may
produce better output on some printers.
