WireIn/Out Frequency and FPGA Resource

Hi I have two questions.

  1. I read on the Front Panel user guide the following quote

“Wires are updated periodically using a polling mechanism. The rate of update is determined by how fast the PC can poll the FPGA. In FrontPanel, this value is user-configurable. Even at the highest update rate (25 millisecond period), very little USB bandwidth is consumed, so you should not notice any performance penalty.”

Given that, when I do:

usbFrontPanel.SetWireInValue(0x06, 0x1);



Will UpdateWireIns() and UpdateWireOuts() block until the wire is updated? (ie. if it takes 5 ms to update the WireOut outputs, UpdateWireOuts() will block for 5ms). If not, then what is the behavior?

  1. I have tried to synthesize the following design in Xilinx ISE. It’s very small, and only include the host interface and 3 TriggerIn components. However, I get the following warning: “More than 100% of Device resources are used.” Is this an ignorable warning or do the components mentioned above taken up more than the entire FPGA?

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_misc.all;
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.all;

entity HardwareWrapper is
port (
hi_in : in STD_LOGIC_VECTOR(7 downto 0);
hi_out : out STD_LOGIC_VECTOR(1 downto 0);
hi_inout : inout STD_LOGIC_VECTOR(15 downto 0);

	clk1			: in STD_LOGIC

end HardwareWrapper;

architecture Behavioral of HardwareWrapper is

component okHostInterface port (
	hi_in			: in	std_logic_vector(7 downto 0);
	hi_out		: out	std_logic_vector(1 downto 0);
	hi_inout		: inout	std_logic_vector(15 downto 0);
	ti_clk		: out	std_logic;
	ok1			: out	std_logic_vector(30 downto 0);
	ok2			: in	std_logic_vector(16 downto 0));
end component;

component okTriggerIn port (
	ok1			: in	std_logic_vector(30 downto 0);
	ok2			: out	std_logic_vector(16 downto 0);
	ep_addr		: in	std_logic_vector(7 downto 0);
	ep_clk		: in	std_logic;
	ep_trigger	: out	std_logic_vector(15 downto 0));
end component;

signal ti_clk : STD_LOGIC;
signal ok1 : STD_LOGIC_VECTOR(30 downto 0);
signal ok2 : STD_LOGIC_VECTOR(16 downto 0);

signal TrigIn40 : STD_LOGIC_VECTOR(15 downto 0);
signal TrigIn41 : STD_LOGIC_VECTOR(15 downto 0);
signal TrigIn42 : STD_LOGIC_VECTOR(15 downto 0);


okHI : okHostInterface port map (
hi_in => hi_in, hi_out => hi_out, hi_inout => hi_inout,
ti_clk => ti_clk, ok1 => ok1, ok2 => ok2);
ep40 : okTriggerIn port map (
ok1 => ok1, ok2 => ok2,
ep_addr => x"40", ep_clk => clk1, ep_trigger => TrigIn40);
ep41 : okTriggerIn port map (
ok1 => ok1, ok2 => ok2,
ep_addr => x"41", ep_clk => clk1, ep_trigger => TrigIn41);
ep42 : okTriggerIn port map (
ok1 => ok1, ok2 => ok2,
ep_addr => x"42", ep_clk => clk1, ep_trigger => TrigIn42);

end Behavioral;

Actually, I would like to tag along and ask a relevant question. If I am interested in response time, what should I use to get data back? WireOut or TriggerOut? For example, if a signal becomes high at one of the I/O pins, and I have software that polls this pin, should I use WireOut or TriggerOut to get the results back as soon as possible?

All API calls are blocking. Although the API should be thread-safe to interact with different XEMs (i.e. two XEMs connected to the same system), you cannot interact with the same XEM simultaneously.

Which resources are beyond 100%? I would guess this is the tristate buffers which are inferred in the design. These will map to MUXes which are available. The new ISE 10.x tools, I believe, are the first to report the “resources beyond 100% warning”. This can be safely ignored.

As for response time, wires and triggers updates take about the same amount of time. Pipes have a little more overhead in the setup for the actual transfer. In all cases, however, keep in mind that neither USB nor Windows are real-time systems and nothing is guaranteed.

Thank you for your reply.