BYU Configurable Computing Home
|
Internal Lab Page
Brigham Young University Configurable Computing Lab
Generic JHDL Platform Tools
Updated: June 24, 2002
| Table of Contents |
|
|
| See Also |
|
|
The following are a series of classes which were created to aid in the design
of
board models. By extending these classes the designer can access a
simplified interface system which makes the multiple connections needed in
a board model. The most extensive use of these interfaces was done in work
for the slaac1v_new board model. These classes were also used in the original
work done for the osiris board model, which now resides in the
isi/jhdl/platforms/osiris branch of the cvs repository. Referring to the
source code of these two models would be the best aid in understanding the
comments below.
Board level is the top level of the design and GenericBoard provides a series
of methods to describe the orginazation of the board model. A FCCM
(a.k.a. board)may contain more than one FPGA or processing elements (PE). For
this reason there is the method
setTotalPEs(# of PEs). Similarly there are
usually multiple memories and register sets so there are also the
setTotalMems(# of mems) and
setTotalRegisterSets(# of register sets)
methods. In association with these methods there are the following methods
which create an instance of the various components of the board model.
declarePE("cellname","classname",index)
declareMemory("cellname","classname",index)
declareRegisterInterface("cellname","classname",set)
declareCell("cellname","classname")
This last method is how all other cells on the board are instanced. Each PE in turn
extends GenericProcessingElement and each memory extends
GenericMemory. The cells instanced by declareCell() however
simply extend Logic.
All of the components above enjoy the use of the simplified connection calls
provided by the platforms/util
classes. For components with similar interfaces ConnectionTemplate
may be used. All other connections within the board model are made using the
defineConnection(width,"cellname:portname,cellname:portname,...","wirename")
method. The cellname:portname distinguishes explicitly every cell that wire is
connected to and the appropriate port name for that wire in that cell. Once the
ConnectionTemplates are made and all remaing connections defined the
board model will be wired together correctly with no further work at the top level.
Handles, getCell, peProgram, loadPe...
The GenericBoard class also provides handles to many of the objects needed for hardware
mode functionality. Some of these simply return a desired element such as
getPE(index)
getCell("cellname").
Other methods may be overridden to program the PEs
(peProgram(index,"classname")) or load the memories
(loadMem(index,"filename")). See the
API documentation for a complete listing of methods available in
GenericBoard.
Now that the board model is described all that is left at this level is to call
the constructDescribedModel() method. This class will
probably contain the main method of your design as well as the resources needed for
hardware mode and readback. Refer to the documentation on
Board Models in JHDL
for more information.
Each PE extends this class which provides methods to describe the connections of that PE.
Within each PE (and every other component instanced in
GenericBoard) there must be a CellInterface declared. This
CellInterface only need declare the ports used in that component. The
API documentation
is the best reference to all methods available. Special attention should be paid to the
following methods:
loadUserCore("design_class")
preConstructBuild(class)
postConstructBuild().
These three methods allow the user to specify what is built, and to some extent when.
The pre- and post- have reference to the method call of loadUserCore. The user may
simply call loadUserCore and his design will be loaded. If something more complex is
desired one or both of the ConstructBuild methods may be called. An example of when
these may be used is to identify the presence of a register interface in the user's
design and appropriate calls to create the needed interfaces. Again the best reference
is to look at available source.
GenericMemory provides access to the same simplified connection interface but is used
in a slightly different manner than the other Generic cells. In the design of the
memories no class extends GenericMemory but rather a wrapper is creted that instances
GenericMemory. The GenericMemory is a data structure and not a structural cell. It
is the wrapper that must provide the CellInterface. These wrapper classes also provide
a description of the proper timing for memory accesses. This wrapper is what is actually
instanced in the GenericBoard. The GenericMemory provides methods
to load and read data from the memory. See the
API documentation
and existing source code for further information.
The GenericUserCore and the GenericInterfaceCell are components not
instanced directly by the GenericBoard. The GenericUserCore is
extended by a wrapper for the user's design and contains a further description of
interfaces with the user's design. Because the class which extends GenericUserCore is
to in turn be extended by the user's design it is left to the user to define the desired
CellInterface. The main role of the wrapper created is to instance the various
GenericInterfaceCells. This builds the interfaces desired for the
user's design without the end user having to worry about how to do it.
The GenericInterfaceCell is a slightly different entity than all other components of the
platforms/util
package. Cells that extend GenericInterfaceCell declare their own CellInterface but
their constructors only need a reference to their parent. This is unlike all other
components which require a specific constructor consisiting of the parent, the name,
and a PortAssociation. The connections declared in the
GenericInterfaceCell using the methods provided. The
API documentation
documents all of these methods. The
connect_pad("portname","wirename") method is used for
wires connected directly to i/o pads. The
connect_conduit("portname","wirename") method is for
all wired internal to the board model. The other methods are for specific cases and
combinations of these connections.
The API documentation
for the ConnectionTemplate is very useful in understanding how to use this connection
class. This class connects two (and only two) cells together by first adding all of
the needed connections
(addConnection(width,"cell1port","cell2ort","wirename"))
and then making the connections
(makeConnections(GenericBoard,"cell1","cell2",substitutions)).
ConnectionTemplate greatly simplifies connection of cells with mutliple instances.
As mentioned above, all components which do not extend
GenericInterfaceCell must have a PortAssociation passed to the
constructor. This PortAssociation allows these components to simply call the method
connectAllPorts(this). These components simply
extend Logic and declare their own CellInterface, but still have access to the wonderful
Generic interfacing abilities. These components have access to the wires it needs
through the method getWire("portname"). Note the
comments provided by the API documentation.