Mobile Hardware Processes and Design Considerations

A process is extracted from a configuration bitstream by analysing resource usage and I/O requirements. Nets which lead to I/O points are viewed as the process-to-be’s main interface points to the outside world. If such points are named in an accompanying user constraints file (UCF), in the usual format, then the name persists through from the design/programming stage to run-time.

4.3.1 Resource Mappings and layout

The system works best with designs that have a roughly rectangular layout. This is because when used CLB resources are found, a 2D sub-matrix is built from the layout shape of the design. Rectangles allow space to be used efficiently and quickly, rather

than complex transformations having to occur at run-time. If the design is not particularly rectangular in shape, or is sparse in its layout (few CLBs laid out erratically over a large area), then there would be wastage in terms of resources.

It is possible to assert constraints to synthesis tools to make layouts compact and rectangular in shape, although tools have been developed in this system to make sure designs can be utilised properly. Precapture, for example, allows designs to be compacted and transformed prior to run-time use, with a rectangular shape.

A new technique is also being developed that allows such 2D objects to overlap and resources to be shared within their respective areas. This inter-mesh works at a finer level of granulation, to allow resources to be individually possessed.

4.3.2 Block RAM (BRAM)

On device block RAMs are supported and captured by Reconnetics. When a process is instantiated that uses BRAMs, certain strategies are used for their handling and placement. The location to place the BRAM is taken primarily from the desired loading point of the process. Other BRAMs are located sequentially on the side nearest the process. This resource allocation can fail if not enough BRAMs are available.

Another way of using BRAMs is through the special bramobj object. This is used in a similar way to processes, the main difference being that the coordinates you give for the location in a loadAt() statement refer to the BRAM row and column. Automatic loading and placing is also available.

There are a few ways of changing BRAM contents. To initialise BRAM contents to zero, the resetBRAM() command can be used. To set specific values, two methods can be used. The first is setBRAM(); mainly for inserting a small number of values. The second is to use readHex(), which will allow an Intel Hex format file to be read into a BRAM. Most assemblers can output this particular format.

4.3.3 Bi-Directional Wires

Bi-directional lines are nearly always (dependent on the device in question) split into two uni-directional lines, avoiding contention. The Reconnetics system analyses networks and decides how such lines should be handled. Usually, such nets are handled by adding _IN and _OUT to the wire name to identify the separate nets.

4.3.4 Tri-State Wires

At the present time nets which lead to tri-state input controls are locked to the destination point by default. To utilise, simply keep the I/O lines at their default location as well. Of course, some HDLs do not use tri-state wires at all.

4.3.5 Mobility

In the case of MHPs, mobility can be thought of in at least two ways; internal to the device and external, over networks. The idea was to create a vehicle in which the process’s physical design can be transported and re-created wherever. The method that was chosen, a Java class, allows the design to be held in a host computer, transmitted and then instantiated in an FPGA, which may actually be different than the original compilation intended.

4.3.6 Re-Use

While processes can easily be used on devices they were originally compiled for, there is also a degree of device independence. Re-use capability is determined by three main parameters – the actual device type, clock speed and clock routing. Using this system the device type (currently within the Xilinx Virtex series) can be changed quite easily. A design originally intended for a small device (such as XCV50) can easily be transferred to a much larger device and vice versa, resources allowing. The clock speed can be maintained at its old frequency. The clock routing for a specific canvas can be changed, there are tools which do this; particular care needs to be taken when adjusting clock nets attached to BRAMs.

4.3.7 Interaction

Interaction is possible between the processes themselves and between the processes and the system. Inter-process communication is, of course, wire based. Such wire connections can be controlled within the user written DCP.

The system itself can observe and interact with the instantiated design by the user defining locations, usually registers, in the circuit, with a given name. These usually are clocked registers, which may be, for example, buffered I/O points. As well as collecting data from such points, it is also possible to set values at inputs.

4.3.8 Usage outside of Reconnetics

MHPs are capable of being used outside of Reconnetics, as long as the JBits and the Reconnetics classes are in the class path of the Java compiler and the interface for the MHP is followed and understood. The methods for a standard MHP (an fpgaObject) have been elaborated as; build(), destroy(), port(), with numerous CLB() and BRAM() methods. A call to the build() method with the appropriate parameters will result in the circuit being instantiated, for example:

fpgaObject pulsecounter = new fpgaObject();

boolean placed_ok = pulsecounter.build(JbitsCanvas, row, col);

This will deposit the circuit in a bitstream (JbitsCanvas) at row, col for download to a device. Using MHPs in this way does have some advantages for the more knowledgeable user – it is certainly more high-level than trying to do the same thing in pure JBits code, although lacks many of the managed and secure features of the actual run-time system. Reconnetics allows placement to be very simple and safe, with many supporting features that would probably take a long time and therefore be inefficient to develop for a “one-off” system.

Further details of class signatures, methods and usage of Reconnetics classes are available in Appendix III.

This section has presented the Reconnetics dynamic run-time system and its mobile components, from the system’s programmer perspective. A system overview

was presented and the main aspects of the implementation explored. Detail was given of how MHP programs are generated and their constituent methods.

The next chapter will examine how the system is utilised from a user point of view, giving examples and exploring possible scenarios for deployment.