Problem updating/reading values on a WireOut

Spartan-6 USB 3.0 Modules
1

Hi,

I’m using an XEM6310 board, with 1.8 firmware and Front Panel v4.2.6.
I’m currently working on a design that is derived from the PipeTest example. In the FPGA, I implemented 2 FIFOs : one being filled while the other is being read through a PipeOut. When, say, FIFO1 is filled with a stream and ready to be read by the SW, the size of this stream (number of bytes) is sent by the FPGA using a WireOut, and a Trigger is activated, to notify the SW that the function ReadFromPipeOut can be called.
The FIFOs use two clocks : sys_clkp (the oscillator on the board) for the WR port, and okClk for the RD port.

See the relevant part of the VHDL code (process synchronized on okClk) :

[CODE]PipeInterface : process(Reset, okClk)
begin
if (Reset = ‘1’) then
FifoFlushState ‘0’); – used to notify the SW that a stream is ready
ep20wire ‘0’); – used to send to the SW the size of this stream

elsif rising_edge(okClk) then

	case FifoFlushState is
	
		when FIFO_RESET_ST =>
			FifoFlushState	
			if (Stream0Ready = '1') then
				FifoFlushState	

		ep60triggerOut	

		if (Stream0Ready = '1') then
			FifoFlushState	

	end case;
end if;

end process;[/CODE]

On the SW side, functions are called this way (I’m really not a C++ programmer so this may not be standard syntax…) :

[CODE]dev->UpdateTriggerOuts();

long flag = 0;
while (flag != 1)
{
flag = dev->IsTriggered(0x60, 0x00000001);
}

dev->UpdateWireOuts();
iCurrentStreamSize = dev->GetWireOutValue(0x20) + 8; // FPGA sends on this wire the size of the next stream
ret2 = dev->ReadFromPipeOut(0xA0, iCurrentStreamSize, pBuffer);[/CODE]

I run tests where 25 streams with increasing size (from 176 to 3672 bytes) are generated and sent through the PipeOut.
The thing is, sometimes it works fine (the 25 stream sizes are correct, and when I display the data I can see that it is correct), sometimes the value on the WireOut does not update, or is totally wrong. Is there something fundamentaly wrong in my implementation ? Should I give more time to the WireOut so that it updates correctly ?

Thanks in advance for your answers.
Remi

2

Remi–

WireOuts are read on the USB host interface clock (for USB 3.0 modules, this is a 100.8 MHz clock).

Is the signal you’re providing to the WireOut on the same clock domain? If not, you will need to transfer it to that domain safely.

3

No, you’re right. StreamSize0 and SteamSize1 are registered in a process synchronized on sys_clkp (the 100MHz oscillator if I’m not mistaken). That being said, I made sure that these signals were not modified at the moment they are read in the PipeInterface process. Do you think this precaution was not enough ? Anyway I’ll try and implement a clean clock domain transfer, and will give you the results.

Thanks for your answer.

Remi

4

I applied the modifications you suggested, and I no longer encounter the data update problem on the WireOut. Thank you very much.

I have another question that is not totally related but I prefer not to create a new thread for it. On the FrontPanel User Manual (page 17), it says : “If an error occurs during the transmission of a bulk transfer, the host will request that the missing packet be repeated. The host will also properly reconstitute the transmission so that everything is properly sequenced.”

This means that designers do not need to implement an error detection system, with a re-send mechanism in case of corrupted data or something equivalent ?

Thanks in advance,

Remi

5

Yes, that’s correct. USB takes care of all this at lower layers.

Generally speaking, errors simply shouldn’t occur. If they do, something very unlikely has gone wrong or something catastrophic has occurred.

6

Actually, the function ReadFromPipeOut in my program sometimes returns the error -1. (it is called as shown in the first post of this thread)
I wanted to know if you could give me more details about this error case, because -1 is defined only as “failed” in okFrontPanelDLL.h. Could it be that there is too much / not enough data to read ? I’m currently trying to send “streams” of 130744 bytes from the board to the PC.

Remi

7

Please note from the FrontPanel API Reference (
http://library.opalkelly.com/library/FrontPanelAPI/classokCFrontPanel.html
) that USB 3.0 pipe reads must be an integer multiple of 16 bytes.

8

Thanks for your answer. I corrected this and now use a multiple of 16 bytes, but “-1 errors” still occur. What kind of symptom can be behind this ? A memory problem ? or communication ?

Thanks,
Remi