The FrontPanel-enabling modules have been designed to consume as few resources as possible within the FPGA.  The resource requirements for each block are listed in the tables below.  Keep in mind that these are requirements for an endpoint with all bits used.  In many cases, the place and route tools will optimize and remove unused components.

The resource requirements above do not include the resources required by instantiated FIFOs except for the Block RAM requirements.

Multiple endpoints are attached to the okEH bus on the okHost by using a Wire-OR.  Each endpoint is told when it can assert its data on the bus.  At all other times, it drives 0.  The Wire-OR component performs a bitwise OR operation on each bit of the bus and outputs the result.  In this manner, multiple endpoints can share a bus without requiring the use of tristates or a large mux.

The okWireOR is provided as a parameterized helper module in okLibrary.v and okLibrary.vhd.  Please refer to the provided samples to see how to instantiate this module.

The host interface is the gateway for FrontPanel to control and observe your design.  It contains the logic that communicates with the PCI Express bridge.  Exactly one host interface must be instantiated in any design which uses the FrontPanel components.

The okHost component is the only block which is synthesized with your design.  It contains an okCoreHarness component (provided as a pre-synthesized module) as well as the necessary IOB components to connect to the host interface pins of the FPGA.

The diagram below illustrates the structural relationships between the various endpoints, the okWireOR, and okHost modules.

This module must be instantiated in any design that makes use of FrontPanel virtual interface components.  The following signals need to be connected directly to pins on the FPGA which go to the USB microcontroller on the XEM.  For a listing of the pin locations for a particular XEM product, please see the user’s manual for that device.

The remaining ports of the okHost are connected to endpoints inside your design.  These signals are collectively referred to as the target interface bus.  Endpoints connect to one or more of these signals for proper operation.

Instantiation of the okHost is simple in either VHDL or Verilog.  Use the templates below in your toplevel HDL design.  A more detailed listing can be found later in this manual as one of the examples.  If pipes are not used in your design, you can force the inputs (okEHI and okEHO) to all 0’s and leave the outputs (okHEI and okHEO) unconnected.

VERILOG INSTANTIATION

okHost_XEM6110 hostIF (.okGH(okGH), .okHG(okHG), ..., .ti_clk(ti_clk));Code language: CSS (css)

VHDL INSTANTIATION

okHI : okHost_XEM6110 port map (okGH => okGH, okHG => okHG, ...
    ti_clk => ticlk);Code language: PHP (php)

In addition to the target interface pins, the okWireIn adds a single 32-bit output bus called EP_DATAOUT[31:0].  The pins of this bus are connected to your design as wires and act as asynchronous connections from FrontPanel components to your HDL.

When FrontPanel updates the Wire Ins, it writes new values to the wires, then updates them all at the same time.  Therefore, although the wires are asynchronous endpoints, they are all updated at the same time on the host interface clock.

VERILOG INSTANTIATION

okWireIn wire03 (.ok1(okHE), .ep_addr(8'h03), .ep_dataout(ep03data));

VHDL INSTANTIATION

wire03 : okWireIn port map (ok1 => okHE,
    ep_addr => x"03", ep_dataout => ep03data);Code language: PHP (php)

An okWireOut module adds a single 32-bit input bus called EP_DATAIN[31:0].  Signals on these pins are read whenever FrontPanel updates the state of its wire values.  In fact, all wires are captured simultaneously (synchronous to the host interface clock) and read out sequentially.

VERILOG INSTANTIATION

okWireOut wire21 (.ok1(okHE), .ok2(okEHx),
    .ep_addr(8'h21), .ep_datain(ep21data));

VHDL INSTANTIATION

wire21 : okWireOut port map (ok1 => ok1, ok2 => ok2,
    ep_addr => x"21", ep_datain => ep21data);Code language: PHP (php)

The okTriggerIn provides EP_CLK and EP_TRIGGER[31:0] as interface signals.  The Trigger In endpoint produces a single-cycle trigger pulse on any of EP_TRIGGER[31:0] which is synchronized to the clock signal EP_CLK.  Therefore, the single-cycle does not necessarily have to be a single host interface cycle.  Rather, the module takes care of crossing the clock boundary properly.

VERILOG INSTANTIATION

okTriggerIn trigIn53 (.ok1(okHE),
    .ep_addr(8'h53), .ep_clk(clk2), .ep_trigger(ep53trig));

VHDL INSTANTIATION

trigIn53 : okTriggerIn port map (ok1 => okHE,
    ep_addr => x"53", ep_clk => clk2, ep_trigger => ep53trig);Code language: PHP (php)

The target may trigger the host using this module.  EP_TRIGGER[31:0] contains 32 independent trigger signals which are monitored with respect to EP_CLK.  If EP_TRIGGER[x] is asserted for the rising edge of EP_CLK, then that trigger will be set.  The next time the host checks trigger values, the triggers will be cleared.

VERILOG INSTANTIATION

okTriggerOut trigOut6A (.ok1(okHE), .ok2(okEHx),
    .ep_addr(8'h6a), .ep_clk(clk2), .ep_trigger(ep6Atrig));

VHDL INSTANTIATION

trigOut6A : okTriggerOut port map (ok1 => okHE, ok2 => okEHx,
    ep_addr => x"6a", ep_clk => clk2, ep_trigger => ep6Atrig);Code language: PHP (php)

The okPipeIn module provides a way to move synchronous multi-byte data from the host to the target.  As usual, the host is the master and initiates all transfers.  Therefore the target should be ready to accept data as it is moved through this pipe (up to 50 MHz).  A small FIFO (511 words) is built into the okPipeIn to allow some flexibility, but it is generally assumed that the transfer will run to completion expeditiously.

EP_CLK may be independent of the host interface clock.  When the API initiates a pipe transfer (WriteToPipeIn), EP_START wil be asserted for a single EP_CLK cycle.  This is to indicate to user HDL that the transfer has started.  User HDL may reset the FIFO (empty it) at any time but requires at least three clock cycles to complete..  EP_FIFO_RESET may be tied to EP_START for convenient operation.

The EP_EMPTY signal will deassert when data is available in the FIFO.  User code should then assert EP_READ to read each available word until EP_EMPTY is deasserted.  EP_VALID is used to indicate when valid data is available on EP_DATA.  EP_COUNT[8:0] pessimistically indicates the number of words remianing in the FIFO.  It may temporarily under-report the count, but will never over-report so that underflow is avoided.

At the end of the complete transfer, EP_DONE is asserted for one EP_CLK cycle.

The timing diagram below indicates how data is presented by the okPipeIn to user HDL.  In this case, 4 data words have been placed into the FIFO by the okHost.  These four data words are read out with a brief pause inserted for illustration.  EP_EMPTY is shown coincident with the last word read out and remains asserted to indicate that no more data is available.  Any reads at this point will cause an underflow condition (not indicated) and EP_VALID will not be asserted.

VERILOG INSTANTIATION

okPipeIn pipeIn (.okHEI(okHEI), .okEHI(okEHI),
    .ep_clk(pipeInClk), .ep_start(pipeInStart), .epdone(pipeInDone),
    .ep_fifo_reset(pipeInReset), .ep_read(pipeInRead),.ep_data(pipeInData),
    .ep_valid(pipeInValid), .ep_count(pipeInCount), .ep_empty(pipeInEmpty));Code language: CSS (css)

VHDL INSTANTIATION

pipeIn : okPipeIn port map (okHEI => okHEI, okEHI => okEHI,
    ep_clk => pipeInClk, ep_start => pipeInStart, ep_done => pipeInDone,
    ep_fifo_reset => pipeInReset, ep_read => pipeInRead, ep_data => pipeInData,
    ep_valid => pipeInValid, ep_count => pipeInCount, ep_empty => pipeInEmpty);Code language: PHP (php)

The okPipeOut module provides a way to move synchronous multi-byte data from the target to the host.  As usual, the host is the master and initiates all transfers.  The target should be ready to provide data when it is requested.  A small FIFO (511 words) is built into the okPipeOut to allow some flexibility, but the transfer will run to completion in all cases.  If user HDL is unable to keep up with the transfer, the FIFO will underrun.  This error condition will be reported to user software, but the transfer will complete and the data following underrun will be unreliable.

EP_CLK may be independent of the host interface clock.  When the API initiates a pipe transfer (ReadFromPipeOut), EP_START wil be asserted for a single EP_CLK cycle.  This is to indicate to user HDL that the transfer has started.  User HDL may start filling the transfer FIFO at this time.  User HDL may reset the FIFO at any time, but requires at least three clock cycles to complete.  During this time, EP_FULL will be asserted..  EP_FIFO_RESET may be tied to EP_START for convenient operation.

EP_FULL will assert when the FIFO is unable to accept data.  EP_COUNT indicates the number of words currently in the FIFO and may also be used by the user HDL to determine when to provide more data.

The timing diagram below illustrates the communication.

VERILOG INSTANTIATION

okPipeOut pipeOut (.okHEO(okHEO), .okEHO(okEHO),
    .ep_clk(pipeOutClk), .ep_start(pipeOutStart),.ep_done(pipeOutDone),
    .ep_fifo_reset(pipeOutReset), .ep_write(pipeOutWrite), .ep_data(pipeOutData),
    .ep_count(pipeOutCount), .ep_full(pipeOutFull));Code language: CSS (css)

VHDL INSTANTIATION

pipeOut : okPipeOut port map (okHEO => okHEO, okEHO => okEHO,
    ep_clk => pipeOutClk, ep_start => pipeOutStart, ep_done => pipeOutDone,
    ep_fifo_reset=>pipeOutReset, ep_write=>pipeOutWrite, ep_data => pipeOutData,
    ep_count => pipeOutCount, ep_full => pipeOutFull);Code language: PHP (php)