JHDL Overview

Main Menu


	\| Mailing List \| BYU Configurable Computing Laboratory \| Bug Reports \|

General Overview

JHDL is a method of describing (programmatically, in JAVA) the components and connections in a digital logic circuit. More specifically, JHDL provides object classes used to build up circuit structure. These include:

static cells, such as boolean gates, registers, etc.,
parameterizable modules, such as multipliers, counters, etc., and
generic platform-independent APIs

for creating wires and basic circuit elements (i.e. the Logic class.)

Simply put, JHDL is a structurally based Hardware Description Language (HDL) implemented with JAVA.

Available appendages to the JHDL circuit model include a set of tools for debugging, simulating, testing and interfacing to the circuit, both as it exists in simulation ("in software",) and while the program is executing on an FPGA ("in hardware.") These appendages interact with the JHDL circuit model through three well defined APIs:

Circuit Structure and Circuit State APIs allow for the creation of netlisters and other specialized viewers (e.g. schematics, waveforms, memory viewers, hierarachy browers, etc.)
Simulator APIs allow tools to control execution of the simulator (for both simulation and hardware execution) as well as recieve key feedback from the simulator.

These features allow designers to quickly and easily design, debug and deploy custom configurable computing machine (CCM) applications -- either a stand-alone (no computer interface), or with an accompanying runtime user interface (UI.)

JHDL is an exploratory attempt to identify the key features and functionality of good FPGA tools. The design of an FPGA system has three major arenas:

The structure or organization of the circuits.
The layout of the circuits.
The interface of the FPGA circuits with the host application software.

All traditional FPGA tools present some method for designing the circuit structure. A few of these also permit the user to perform the layout of the circuit; more often, circuit layout must be performed with a separate, non-integrated tool. But almost no tools provide a way to naturally interface the running hardware platform with the software running on the host machine. This last issue is important: FPGA-based systems typically operate in tandem with a general-purpose host microprocessor and it is important to simulate the entire system, including the host computer system and its application software in conjunction with the FPGA design to ensure that the entire application works as desired.

Motivating JHDL design environment choices

It has long been felt (at least in the lab at BYU anyway) that existing FPGA design tools take too long to learn, are too difficult to use, and don't attack the entire problem. Based on experiences developing several relatively large and complex applications, we have developed a set of criteria for our ideal CAD tool:

Intuitive and easy to learn. The design tool should be based on a general-purpose language that allows the user to describe circuits using easily understood general-purpose language constructs and that leverages existing compilers, debuggers, and so forth, as much as possible.
Distributed as a set of libraries and applications, with no custom compilers, pre-processors, thread or graphics packages, etc.
Fully models run-time reconfiguration of FPGAs. The design tool should allow the user to explicitly schedule reconfiguration using natural language constructs.
Specifically targets high-performance FPGA design. This means that the tools should provide natural and concise constructs for describing circuit structure and topology (placement). Module generators should be well-supported.
Natural coupling of the hardware system with the host software. Allow the user to describe, simulate and execute the entire application including all host software in a single integrated environment.
Unified simulation/execution environment. For example, in simulation mode, circuit execution is modeled by a simulator; but in hardware mode, the exact same code should automatically translate into configuration download, data transfer and direct control of the FPGA hardware.
Provide a host of services to the user to hide tedium and verbosity. At the same time, allow the user to ``get under the hood'' and access the ``bare metal'' whenever he wants.
Allow for platform- and device-independent design specification wherever possible. When a JHDL function is called, the tools do ``whatever makes sense'' to map the directive to the target hardware. But again, the user should be able to bypass the tools and get at the ``bare metal'' to get exactly what he wants.

Based on these criteria, we made a series of initial design decisions that have driven the JHDL design environment. First, JHDL is based on Java. Java was chosen because it is a high-level, object-oriented language that is easy to learn and intuitive to use. It is distributed with standard compilers and library packages that guarantee cross-platform execution. Because JHDL relies on a high-level language, it is easy to integrate the ``hardware part'' of the application with the ``software part.'' The user models and controls his circuit with Java classes, which can naturally interface with GUI objects, file or console I/O routines, and so forth. Thus the end FPGA application is developed in a single, unified, co-debugged piece of Java code.

Second, JHDL models FPGA behavior using simple object-oriented techniques. Each circuit element is modeled with a discrete Java object. Circuit configuration is modeled by construction of JHDL objects; reclamation of FPGA hardware is modeled by destruction of the corresponding Java objects. This turns out to be an extremely good model of run-time reconfiguration of hardware. This model allows JHDL to control both simulation and execution of RTR systems with a single piece of hardware description code.

Third, the JHDL design environment treats software and hardware the same. A standard set of APIs are used both for accessing the simulator and the hardware platform thereby making it possible to transparently switch back and forth between the two without requiring any modifications to the designer's application code (FPGA circuits, GUIs, host interfaces, etc.).

Developing JHDL to be a usable and effective tool

As users of other CAD tools, we are keenly aware of tool usability issues and other frustrations of end-users. However, awareness alone is not sufficient to guarantee that JHDL would evolve into a powerful and usable CAD tool. Thus to ensure that JHDL would be a usable tool that met the many goals stated above, JHDL has been incrementally developed in concert with a variety of applications. About 1/2 of the lab staff at BYU does only FPGA-based application development while the other 1/2 works on JHDL development. In addition, nearly all of the JHDL developers have some experience developing FPGA-based applications.

The current state of JHDL

At BYU we have found JHDL to be a very effective CAD tool. Students learn it quickly and become productive designers quickly relative to just about any other CAD tool we have used. JHDL has displaced all other CAD tools and is used extensively to develop high-performance applications in automated target recognition, sonar beamforming, and other applications. In its current state JHDL includes:

a library that supports Xilinx 4K, Virtex, and Virtex II series devices.
a graphical debugging tool that allows designers to simulate, debug and hierarchically navigate their designs. This tool can display a schematic view annotated with simulation or execution data, provide a waveform view of any desired signals, and allows the designer to invoke any public methods implemented by the circuit class (via Java reflection).
a schematic generator that can automatically create a high-quality schematic view of a JHDL description,
an EDIF 2.0 netlist class that generates output compatible with current Xilinx M2 place and route software,
an EDIF parser allowing the user to import externally-generated designs and modules into JHDL,
simulation models and transparent run-time support for the Annapolis Microsystems WildForce platform and the SLAAC1 platform,
a table-based state-machine generator, and
facilities for instrumenting both simulation and hardware execution to streamline the circuit verification process,
a graphical floorplanner (under development) that will be used cooperatively with the schematic view to manually floor-plan designs.

In addition to these specific design aids, JHDL provides a unified design environment where a single, user interface can be used for both simulation and execution. This allows the designer to request either simulation or execution (or a mixture of the two) using the exact same commands for both. For example, within this unified environment, commands such as set-breakpoint, examine-variable, single-step, etc., are the same whether performing simulation or execution. This is a big advantage for designers because they can learn a single debugging environment that works for both simulation and execution --in contrast with current systems where execution and simulation environments are distinct and very different. Moreover, this is what makes it possible to use the same program for both software simulation and hardware execution. Design views are unified as well; for example, the schematic view can display either simulated values or values retrieved from the FPGA platform during execution using the same view and interface. Much of the flexibility of this environment is due to the dual simulation/execution environment supported in the original version of JHDL [Bellows-Hutchings98]. As reported previously, switching between simulation and execution mode is done by simply clicking a radio button in the circuit browser.

Limitations

Currently, JHDL doesn't support all forms of digital systems design that you may be familiar with. In particular, asynchronous loops are unsupported and, if they exist in your circuit, will result in a simulator error message to the effect that "xxx not on propagate list".

JHDL is very much a work in progress. This is a nice way of saying that there are still a lot of things to be worked out and there are a lot of bugs yet to be fixed. In addition, because JHDL is part of a research project, it will likely continue to undergo substantial changes as a part of the process of natural exploration. In spite of this, we have found JHDL to be a very effective way to do FPGA design and will continue to use it to develop our own applications.