Download PDF1 - Greg Gibeling

Figure 11 Host Model
Host α
(Gateware/FPGA)
Library
Output
Outside Edge
Outside Edge
Link A
(Channel A)
Link B
(Channel B)
Unit1
Unit2
(Wrapper)
(Wrapper)
Link C
(Channel C)
Link D
(Channel G)
Link E
(Channel F)
Link E
(Channel E)
Library
Input
Link D
(Channel D)
Terminal
Terminal
Link D
(Channels D & G)
RS232
Link E
(Channels
E & F)
TCP/IP
Terminal
Platform γ
Link E
(Channel E)
Terminal
Platform β
(Misc.)
Link E
(Channel F)
(Workstation)
Unit3
(Wrapper)
Link F
(Channel H)
Library
Debug
Outside Edge
However, for those researchers interested in moving
from simulation to e.g. ASIC the ability to incorporate the “golden” model of the chip in with an
RDL simulation is invaluable.
There is also the perception (and reality) of startup costs. If one is asked to learn both RDL and
a new HDL (e.g. VHDL when they already know
Verilog) the price of using RDL may well be too
high, particularly at universities where graduate
student time is at a premium.
In sum, the need to integrate existing HDL
means that RDL must be language independent, or
else the cost of integrating these designs becomes
prohibitively high.
Thus far we have justified the need for both board
and language level portability. However, RDF must
go one step further and, though seemingly contrary
to the stated goal of RAMP [90], embrace abstraction portability, to cover both hardware and software simulators.
Researchers have been designing software-based
architectural simulators for many years [14, 22], and
to great effect. While these simulators are prohibitively slow for software development and difficult to parallelize, they are functionally correct and
highly believable. By allowing RDF to span hardware and software we allow hybrid simulators [28]
to be built using the speed of hardware where possible, and the flexibility of software where needed.
18
Even more interesting, by allowing the partition
between the two to move easily, we can allow a
researcher to prototype their ideas in software and