Download PDF1 - Greg Gibeling

be complicated and error prone at best, simply because the access needed was not envisioned are part
of the design.
We also intend to shift from the JFlex [60] and
CUP [54] parser generators to ANTLR [73], which
besides using a better parsing algorithm should allow RDLC3 to generate more helpful error messages, a perennial sore spot for users. The more
powerful parser should also allow us to restructure
the language syntax to reduce the reliance on keywords, improve the specification of types, and general reduce the verbosity of RDL. Trivial changes
in this regard can make a programming language
of any kind significantly more accessible to novices,
whose focus is generally on the lexical structure and
syntax rather than the language semantics. Further, given the the number of special purpose keywords (see Section 5.4) in RDL2, we believe an
annotation mechanism integrated with the plugin
framework (see Section 10) may be a more flexible
and simpler choice.
In addition to language level changes, we believe that there are abstraction changes necessary
to grow to truly large designs. In particular we have
found the lack of a platform level I/O abstraction to
be limiting when dealing with a wide variety platforms. Because RDL does not capture platform I/O
it automatically manage it, something novice hardware designers and even some experts will assuredly
require. We believe that adding the concept of platform level firmware to RDL, including the language
and compiler structures to support it will be relatively easy and go a long way to fixing this problem. Furthermore, this should replace the awkward
language and platform qualified plugin system (see
Section 6.5.2).
Since the initial design of the channel model (see
Section 3.3) it has become clear to us that there
are other channel models which would be useful.
In particular shift-register channels, in contrast to
credit-based flow control channels, would not require handshaking and could be used to implement
many designs much more efficiently. Expanding
on this, several users have requested the ability
to specify different variants of the inside edge interface (see Section 3.2), all supporting the same
concepts but with slightly different signaling conventions. Integration of existing code, in particular
reducing the workload described in [84], would be
simplified by features as simple as the option to
specify that certain inside edge signals are active
low.
We believe a generalized inside edge interface
could allow RDLC3 to support several novel features with little cost. Ideas like allowing a unit
implementation to pipeline the simulation of tar-
get cycles, or a link which can undo or redo the
sending of messages within the current target cycle
are good examples. More interesting is the idea of
making space-time tradeoffs by, for example, delivering the elements of an array message at a rate of
one per host cycle to a pipelined unit implementation. A variant of this called implementation multithreading (see Section 16.4.2) is likely to be critical
in larger systems. Taking this to an extreme, ideas
like message cancellations which flow opposite normal messages could lead to very large performance
improvements [35, 34] for certain target systems.
We have planned from the beginning but never
had the time to implement support for the simulation of globally asynchronous, locally synchronous
(GALS) designs, and other such designs without a
single target clock. In particular we have worked
out, but not yet implemented many of the details
to support units to have dependent clocks related
by simple rational divisors.
It should be clear from the above ideas that we
have successfully identified many shortcomings in
RDLC2. Though RDLC2 successfully and greatly
expanded the range of systems for which RDL could
be used, we expect RDLC3 will make a significant
impact by finally delivering on the complete feature
set needed by the majority of projects, in a clean,
simple and unified manner.
16.4.2
Implementation Multithreading
Because the RAMP project hopes to scale to thousands of processor cores without thousands of FPGAs, it is clear that simple structural models will
not be sufficient. To this end, we have been exploring a concept we call implementation multithreading, whereby a single unit implementation simulates multiple instances in the target system. By
time multiplexing the unit implementation, we can
allow a researcher to trade time, of which there is
an infinite amount, for FPGA or CPU space, which
is extremely expensive.
16.4.3
Debugging & RADTools
Debugging any concurrent system is well know to
be difficult, if not impossible in real world conditions thanks to the non-determinism underlying
the synchronization failures we most often would
wish to debug. Because a properly implemented1
RDL simulation is completely deterministic and repeatable it is possible to expose these bugs. Better
1 By this we mean that unit implementations are deterministic.
140