Support

 

This document describes the differences between the 3.0.x and 3.1 release versions of the Opal Kelly FrontPanel framework. The API has not changed in this release. However, there has been a slight change to how endpoint modules are connected to the FrontPanel Host Interface. Additionally, the Windows driver has been modernized and now supports 64-bit editions of Windows XP and Windows Vista.

Driver Change

FrontPanel 3.1 ships with a new USB driver for the Opal Kelly FrontPanel-enabled devices. This driver now support 64-bit editions of Windows XP and Windows Vista.

Although the API has not changed, you will need to use the latest DLL to communicate with the new driver. In most cases, you should be able to just drop in the new DLL. No re-build will be necessary. Note that Windows will associate all devices with the new driver, so a “mixed” system with both old and new drivers is not possible.

With the new driver installed and associated with an attached device (in this case, an XEM3001v2), your device list within Device Manager will now display as shown below. Note that a new device family (FrontPanel devices) has been added.

Devices attached to the NEW driver will look as shown above. Devices attached to the OLD driver will appear in the Universal Serial Bus Controllers group at the bottom of the list.

Note: Windows will only automatically update the driver for devices that are attached at the time you install the new FrontPanel software. To update other devices, after FrontPanel is installed, just right click on the device in Device Manager and click “Update Driver Software…” Windows should take care of the rest.

HDL Changes

The FrontPanel 3.0 and previous HDL modules used a shared bus to connect the endpoint modules to the host interface module. This was done using a bus described in HDL as a tri-state bus. Xilinx FPGAs have not supported tri-states within the fabric for some time now, including Spartan-3. However, the synthesis tools have accommodated by converting the bus into a large mux.

With new devices such as the Virtex-5, Xilinx has deprecated this conversion support. Therefore, we have chosen to describe the bus as a Wire-OR configuration where all endpoint modules are bitwise-ORed and the result is sent to the okHost. This change requires a slight change in your HDL as you migrate to the new modules.

okWireOR HDL module

The okWireOR HDL modules is a simple parameterizable piece of HDL which creates 16 N-input OR gates. These combine the ok2 busses from each of the endpoints into a single ok2 bus on the okHost. For convenience, both VHDL and Verilog versions take a parameter (N) to set the size of the gates. As you add endpoints to your design, you must increase this N appropriately.

Consider the Counters sample. The Verilog host interface declarations with FrontPanel 3.0 looked like this:

okHostInterface okHI(
      .hi_in(hi_in), .hi_out(hi_out), .hi_inout(hi_inout),
      .ti_clk(ti_clk), .ok1(ok1), .ok2(ok2));

okWireIn ep00 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h00), .ep_dataout(ep00wire));

okWireOut ep20 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h20), .ep_datain(ep20wire));
okWireOut ep21 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h21), .ep_datain(ep21wire));
okWireOut ep22 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h22), .ep_datain(ep22wire));

okTriggerIn ep40 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h40), .ep_clk(clk2), .ep_trigger(ep40wire));
      
okTriggerOut ep60 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h60), .ep_clk(clk1), .ep_trigger(ep60trig));
okTriggerOut ep61 (.ok1(ok1), .ok2(ok2), .ep_addr(8'h61), .ep_clk(clk2), .ep_trigger(ep61trig));

with FrontPanel 3.1, this same set of declarations looks like this:

wire [17*5-1:0]  ok2x;
okHost okHI(
	.hi_in(hi_in), .hi_out(hi_out), .hi_inout(hi_inout), .ti_clk(ti_clk),
	.ok1(ok1), .ok2(ok2));

okWireOR # (.N(5)) wireOR (ok2, ok2x);

okWireIn     wi00(.ok1(ok1),                           .ep_addr(8'h00), .ep_dataout(ep00wire));
okWireOut    wo20(.ok1(ok1), .ok2(ok2x[ 0*17 +: 17 ]), .ep_addr(8'h20), .ep_datain(ep20wire));
okWireOut    wo21(.ok1(ok1), .ok2(ok2x[ 1*17 +: 17 ]), .ep_addr(8'h21), .ep_datain(ep21wire));
okWireOut    wo22(.ok1(ok1), .ok2(ok2x[ 2*17 +: 17 ]), .ep_addr(8'h22), .ep_datain(ep22wire));
okTriggerIn  ti40(.ok1(ok1),                           .ep_addr(8'h40), .ep_clk(clk2), .ep_trigger(ep40wire));
okTriggerOut to60(.ok1(ok1), .ok2(ok2x[ 3*17 +: 17 ]), .ep_addr(8'h60), .ep_clk(clk1), .ep_trigger(ep60trig));
okTriggerOut to61(.ok1(ok1), .ok2(ok2x[ 4*17 +: 17 ]), .ep_addr(8'h61), .ep_clk(clk2), .ep_trigger(ep61trig));

The only difference is how the ok2 bus is connected. In FrontPanel 3.0, all HDL modules had an ok2 port. In FrontPanel 3.1, some do not. Also note the additional okWireOR module. Finally, note that each of the HDL modules with an ok2 port attach to a different range of signals on ok2x.

FrontPanel 3.1 Modules with ok2 Ports
okTriggerOut okWireOut
okPipeIn okPipeOut
okBTPipeIn okBTPipeOut

In the example above,

  • wo20.ok2 is attached to ok2x[16:0], the first 17 bits of ok2x.
  • wo21.ok2 is attached to ok2x[33:17], the second 17 bits of ok2x.
  • …and so on…

The okWireOR takes this 17*5-bit (85-bit) bus and distills it to a single 17-bit bus which is attached to the okHost.

It is important to note the following:

  1. ok2x is declared as a 17*5-bit (85-bit) wire bus.
  2. okWireOR has the parameter N set to 5.
  3. There are exactly 5 HDL module connections to ok2x and none are shared.

Summary

Updating your HDL code from FrontPanel 3.0 to FrontPanel 3.1 should be a relatively routine task. Although not currently required on Spartan-3 devices, this migration was necessary to support the Virtex-5 devices and others for which Xilinx will deprecate tristate synthesis in their ISE tools.

The WireOR declaration is little awkward but should result in slightly lower resource usage for the FrontPanel host interface.

 
frontpanel3p1deltas.txt · Last modified: 2010/04/30 17:23 by opalkelly_admin