Informatik 12 - ReCoNets

The phrase "ReCoBus" is used in two senses. Firstly, it stands for a complex and regular structured monolithic macro containing all logic and routing of a backplane bus that is highly optimized for FPGAs. Note that a ReCoBus hard macro is far behind the concept that is known as a Xilinx "bus macro".
Secondly, we are using the term ReCoBus if we speak about the technology allowing us to integrate pre-synthesized and completely placed and routed modules to the reconfigurable backplane of the system. Like how you can plug your new network card in an empty PCI slot of your PC, it is possible to plug in a reconfigurable module into the ReCoBus backplane. Instead using a screwdriver, you only have to load the according configuration data to the FPGA.

What is an I/O bar?

A ReCoBus provides us only the backplane bus. In order to allow links to I/O pins or direct communication between any reconfigurable or static module we developed so called "I/O bar" macros.
An I/O bar is a regular structured segmented communication structure that reserves routing resources providing us a logic routing plane that can be modified at runtime. Click here for technical details on I/O bars.

Why you generate macros instead implementing the backplane bus in VHDL or Verilog?

The ReCoBus project aims at integrating fully routed modules without any additional synthesis or place & route step. This is carried out by plugging together some modules to a backplane bus by putting together partial configuration bitstreams. And comparable to a backplane on a PCB, all bus connection pins have to be located in all sockets at exactly the same relative position. As we want to be able to locate modules to different sockets of a ReCoBus, we further have to constrain the routing from socket to socket and within the socket to be 100% equal for all slots. This can only be ensured with hard macros.

Is a ReCoBus based in the Xilinx "bus macros" or are there any differences?

No, a ReCoBus is not based on the traditional bus macro concept. Note that we are not speaking about tristate based communication as it is slow and only available on a few older FPGA architectures.
As the high level tools are not allowing us to constrain signals to specific wires for the communication across the boundary of a partially reconfigurable module (all entity signals), macros have to be used for this purpose. To do so, the Xilinx bus macros instantiates a LUT configured in route through mode on both sides of a specific wire. This macro can than be instantiated using Verilog or VHDL. That's all this macro does.
Opposed to this, a ReCoBus hard macro contains also the bus logic and it is not only a simple point-to-point link but more a large multipoint communication macro spanning over the complete reconfigurable area. With a ReCoBus it is possible to connect up to two signals per LUT within a reconfigurable module, as we can also use the flip-flops. Including many further optimizations, this allows us to build complex communication architectures consuming at least five times less the amount of LUTs as required with the traditional bus macro approach. And even more important, a ReCoBus can provide high speed and is easy to use by our tool ReCoBus-Builder.

What FPGAs are supported by the ReCoBus-Builder tool?

Currently, we support all Spartan-3, Virtex-II and Virtex-II Pro FPGAs from Xilinx. Virtex-IV FPGAs are in the test phase and future versions of the ReCoBus-Builder tool will include Virtex-V devices. The ReCoBus technology itself is platform independent and consequently applicable to FPGAs from different vendors or even structured ASIC devices. In the latter case, a ReCoBus may help in implementing static only systems in a highly modular manner. We focused on Xilinx FPGAs, as these devices provide partial runtime reconfiguration as well as tools giving full control over all low level resources (for example LUTs or wires).

What's the difference between the ReCoBus-Builder and the Xilinx PlanAhead tool?

As the ReCoBus-Builder is basically a floorplanning tool, it has some similarities with the PlanAhead. In addition to PlanAhead, the ReCoBus-Builder generates the complete communication architecture for the communication with the reconfigurable modules as hard macros and according VHDL instantiation templates. Reconfigurable systems based on a ReCoBus provide a much higher placement flexibility and can integrate many times more modules into a system as the PlanAhead / bus macro approach can do.

How does the ReCoBus-Builder tool integrates into the Xilinx tools?

ReCoBus-Builder basically assists the floorplanning, the communication architecture generation, and the partial bitstream assembly. All logic synthesis has to be done by any external tool (for example XST). The ReCoBus-Builder automatically generates VHDL templates for the partial system containing the communication hard macros, some additional logic, and the connections to the partial modules. The place and route process is carried out by the Xilinx P&R tools that follow area and placement constraints exported from the ReCoBus-Builder. Note that we are not requiring the patches offered at the Xilinx partial reconfiguration lounge.

How does the ReCoBus-Builder deals with design hierarchies?

As compared to the Xilinx partial flow, we are not forced to follow a special design hierarchy or directory structure for the design files. It is also not required to instantiate all macros at the top level while preventing us to implement any logic within top. However, it is recommend to encapsulate the partial sub-system into an own hierarchy branch.

How to deal with dedicated FPGA resources such as block RAM columns?

Block RAMs or multiplier columns are simply bypassed by a ReCoBus and modules may use such resources for implementing their functionality. Dedicated resources restrict the module placement and it is important to place the module at a position that provides the same resources at exactly the same relative position as used by the original implementation of the module. For example, if a module consists of two columns with the left one being a column of CLBs containing the logic and the right column containing block-RAM memory, this module can only be located to places providing a CLB column left and a block RAM right.
In Virtex-IV FPGAs there exist either block RAM columns or multiplier columns. For these devices, it is possible to enhance relocatability by preventing the use of such dedicated resources for implementing the module functionality. This technique leads to a very poor device utilization and may only be interesting for research purpose. Note that a single multiplier can replace by up to 400 LUTs and one fully utilized block RAM would require more than 2000 LUTs on a Virtex-IV FPGA. However, the ReCoBus-Builder supports this approach by allowing a selectively blocking of logic CLBs, block RAMs, or multiplier resources.

Are the partial modules required to span over the complete height of the device?

In the case of Virtex-II FPGAs, the smallest chunk of atomically addressable configuration data is called a frame that contains configuration bits for the resources within a complete column of the device. By overwriting the present configuration with the same data, a Virtex FPGA can continue operating without taking the risk of glitches. Note that there are some limitations regarding I/O pins and the use of LUT-primitives as distributed memory. Following a few design rules, the ReCoBus-Builder tool is capable to build communication architectures suitable for a 2-dimensional module placement. Our bitstream assembly tools can deal with these issues. This helps us, for example, to utilize the top and bottom I/O cells within the span of the runtime reconfigurable area.
Virtex-IV FPGAs provide a sub-column-wise reconfiguration pattern. Here, only 16 vertically aligned CLBs (a cluster of 8 LUTs) are configured at a point of time. This matches ideal for implementing ReCoBuses suitable for 2D placement.
For Spartan-3 FPGAs there are some more restrictions as compared to Virtex-II devices, as described for the next question.

Does a ReCoBus support runtime reconfiguration on Xilinx Spartan-3 FPGAs?

Yes - but with some restrictions. Beside the limitations found in Virtex-II FPGAs that arise from the full column-wise reconfiguration scheme, Spartan-3 FPGAs require deleting all logic and routing information of a complete CLB column prior to the configuration write process. This will typically lead to an interruption of the ReCoBus communication.

Can we implement self-reconfiguration on Xilinx Spartan-3 FPGAs?

Sure - although Spartan-3/-3E devices have no internal configuration access port (ICAP), it is simply possible to feed back some I/O signals to the configuration interface for allowing self-reconfiguration. In the easiest case, this can be carried out by some wire bridges plugged directly into an board extension connector (see our Spartan-3 Demo on the Digilent Board).
Performing read or write operations on the parallel select map port is as easy to implement as writing a simple PIO port.
By the way, despite the fact that some versions of the FPGA-Editor show an ICAP primitive for Spartan-3/-3E FPGAs, these devices can only be configured using an external interface.

What arbitration scheme does a ReCoBus use?

How are the modules mapped into the address space of the system?

It is possible to define the maximal size of the register file of a module within the ReCoBus-Builder tool by specifying the number of LSB address bits that are directly passed to the module. The next (typically 4) address bits are used within the bus to generate the chip select signal for the individual modules, while all remaining MSB address bits determine the base address of the complete ReCoBus subsystem. With respect to the static system, all modules and the ReCoBus itself behave like one single module making it simple to integrate a ReCoBus into existing systems.

I want to integrate multiple instances of the same module into the system - how can I set the base addresses?

There are three options available. In the easiest case, the Address is set during the link phase of the bitstream for the initial system by manipulating the equation of the LUT responsible to decode the chip select signal of a particular module. As a second option for runtime reconfigurable systems, we can generate tiny partial bitstreams that set the module address. Finally, there is an option to set the address within the ReCoBus after downloading a partial module bitstream to the FPGA. Note that the base address decoding is part of the ReCoBus and completely transparent to the modules.

I want to integrate multiple instances of the same module into the system - do I need multiple bitstreams?

No - our bitstream assembly tools can load the same partial bitfile as a copy to multiple positions (1D or 2D) of the initial design. This option is further applicable for the Xilinx Virtex-IV and Virtex-V architectures for providing runtime reconfiguration. If a Virtex-II or Spartan-3 system is capable to merge bitstreams together at runtime, the same partial bitstream instance can be loaded to multiple positions - even in a two dimensional manner.
In some cases, it may be interesting to build implementation alternatives in order to increase the placement flexibility. For example, it could be advantageous to generate alternative implementations of a module containing some block RAM memory with different relative positions of memory within the module.

How many slave modules can be connected to a ReCoBus?

Currently the ReCoBus uses a 4-Bit LUT for decoding an internal address for generating the chip select signal. This allows us to address up to 15 individual modules connected to the bus. One of the 2^4=16 code words is used to encode that no module is selected. However, multiple modules may use the same chip select signal in combination of different internal LSB addresses for individually accessing more than 15 modules in a system. As an alternative, it is possible to provide multiple chip select signals within a single socket of a ReCoBus that may be decoded inside the modules or transparently for the modules in simple module wrappers.

How many masters are supported?

Whenever possible, DMA access should be implemented in a centralized DMA unit and not distributed within the modules connected to a ReCoBus. However, multi-master modes are possible and the number of masters is virtually unlimited. In practice, one ReCoBus should contain not more than 15 master modules.

How does the ReCoBus approach influences the place and route results?

Fitting modules into fixed bounding boxes influences the placement and consequently the routing and therefore the achievable clock frequency. Many test P&R runs haven't clearly demonstrated a strong improvement or a degradation of the clock speed. In all examined real-life applications (DSP, Crypto, Networking) we found that a logic utilization of at least 90% (on a Xilinx Virtex-II) is allowed while still being able to fully route all signals of a partial module.

Is it required that modules have a rectangular shape?

No - it's not. Modules may have a shape similar to what you know from the Tetris game. This is an interesting option for increasing the resource utilization in the case of dedicated RAM or multiplier primitives. But as you may know from Tetris, finding an optimal placement for fancy shaped modules is a difficult task.
By the way, we call this packaging problem "FPGATris".

What bus protocol standard does a ReCoBus follow?

Up to now, we haven't specified a special ReCoBus protocol. Instead to this, we provide the implementation of any bus protocol on the physical level using FPGA primitives (LUTs or FFs) and some wiring resources. This includes all required dedicated or shared read and write signals within a bus. It is optional possible to specify pipeline registers within the bus for higher throughput. As a consequence, you may implement virtually any established bus standard including Amba, Avalon, CoreConnect, or Wishbone.

Do I have to rewrite my modules when using a ReCoBus?

In most cases not. Module libraries are typically based on common communication standards that should be implementable using a ReCoBus and some I/O bars. There are only a few cases where you have to modify the module code. For example if your modules contains tristate I/O or if you use the initial value feature provided for Xilinx FPGAs, you will have to rewrite smaller parts.

Can modules have I/O pins?

Can modules also have tristate I/O pins?

Regardless of building runtime reconfigurable systems, tristate drivers are typically only available at the I/O pins itself. Therefore, a pair of unidirectional data read and write wires have to be routed to the I/O pin primitives together with the output enable signal. As a consequence, tristate drivers must be located in the static part of the system and the unidirectional data pair has to be routed via an I/O bar. Note that an I/O bar can provide two signal links within one LUT in opposite direction by utilizing the according flip-flop in addition to the LUT.

Can two reconfigurable modules communicate within the reconfigurable area?

How to apply a reset to a partially reconfigured module?

A ReCoBus generates a reset during the configuration process for a particular module that is automatically released after loading a module configuration to the FPGA. If required, we can also include a global reset signal within the bus. If the module features one reset input only, both reset sources - the configuration reset and the global reset - may be OR-ed within a wrapper.

Frequently Asked Questions about the ReCoBus Technology

What is a ReCoBus?