Fifo Interface

Spartan-3 USB 2.0 Modules
1

Hi,

A part of my project needs the FPGA spartan3 ( XC3S100) to be interfaced with the USB via FIFO. I made the FIFO using logic core’s FIFO generator v 2.3. I am intending to make a asynchronous FIFO. The FIFO has full, almost full, read , write signals. Would XEM3010 be the right choice for it? Please advice!

Regards
John

2

Yes, the HDL blocks we provide with the XEM3010 can interface directly with the FIFO cores from the CORE generator.

Please have a look at the FrontPanel User’s Manual (available online) to get a better idea of how the big picture would look.

3

Hi John,

just be careful, note that the pipes do not have control inputs for your FIFO full and empty signals… I understand the new firmware will have this capability…

Bill

4

Bill–

You have this new firmware. You haven’t tried it yet? :slight_smile:

5

Hi Jake,

I am upto my eyeballs in stuff here, and just getting things caught up… after a nice winters nap… ZZZzzz… I am putting together a demo project to try it out right now! (if I can get VSS to let go) I would love to be able to demo a customer some blazingly fast throughput!

Bill

6

I just went throught the nasty process of upgrading all my code from Visual Studio v6 to v8. I am using FP3.0.0b. and firmware 2.4.

Everything compiles and links using the new OkFrontPanel.lib of 7/19/06.

Version 6 works.

FrontPanel works.

Version 8 gives me a HEAP CORRUPTION DETECTED error, and crashes hard. Not when I construct the object, but when I try to use the GetDeviceCount(). I am totally stuck.

This app has the additional nastiness that all the calls to the OK routines are in a separate dll (not the OK dll) from the main routine… so when I get to the next step adding the OK dll this will get even more convoluted…

Any help is much appreciated!

Bill

void CLlcOkDll_v8App::initializeXem()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());

q.m_iInitializeXem = 0;
q.m_iNumXEM = 0;

// get the first xem
q.m_xemA = new okCUsbXEM3001v2();
q.m_pllA = new okCPLL22150();

// count how many xem w/ error
switch( q.m_iNumXEM = q.m_xemA->GetDeviceCount()){
	case 0:		q.m_ulStatus |= ERR_NO_XEM;
				if( q.iFaultORide == 0){
					delete q.m_xemA;
					delete q.m_pllA;
					return;
				}
				break;

	case 1:		q.m_ulStatus |= ERR_ONE_XEM;
				if( q.iFaultORide == 0){
					delete q.m_xemA;
					delete q.m_pllA;
					return;
				}
				break;
	
	case 2:		q.m_xemB = new okCUsbXEM3001v2();
				q.m_pllB = new okCPLL22150();

#ifdef _MESS_DEBUG
AfxMessageBox( “Two XEM found”, MB_OK, 0);
#endif
break;

	default:	q.m_ulStatus |= ERR_TOO_MANY_XEM;
				if( q.iFaultORide == 0){
					delete q.m_xemA;
					delete q.m_pllA;
				}
				return;
				break;
}
7

Bill-

If you’re using FP3.0.0b, you shouldn’t be able to create an okCUsbXEM3001v2 object. It’s gone.

The okCUsbFrontPanel object handles all boards now.

8

I was hoping for the “oh I’ve seen that one before, do this and that”.

In abscence of a magic bullet solution, I rolled back FrontPanel to 1.30, and compiled with okCUsbFrontPanel.h 11/9/05 and okFrontPanel.lib 11/9/05.

I still have the same problem. Heap corruption after the end of the heap buffer, during a call to _free_dbg, from okCUsbDevice::GetDeviceList: during the call:

q.m_iNumXEM = q.m_xemA->GetDeviceCount();

I have checked the heap before this call with a malloc and a free, and a heapCheck, and no problems found.

Any suggestions are welcome…

Bill

9

What constrains are required in the .ucf file to handle the requirements of the OpalKelly IP and the interface with the XEM3010 hardware (e.g. USB interface). (I have not migrated yet to FP 3).

Examples:

  1. I am using location constrains such as this one (based on FP examples):

NET “hi_addr” LOC = “R8”;

The Xilinx flow considers this pin to be LVCMOS25 by default. Do I need to constrain it to be LVCMOS33? Does this apply to all the XEM3010 internal pins?

2.The only timing constrain in my ucf file is:

NET “hi_clk” TNM_NET = “hi_clk”;
TIMESPEC “TS_hi_clk” = PERIOD “hi_clk” 20 ns HIGH 50 %;

Do I need timing constrains for the offset between the hi_clk clock and the data lines of the USB interface (e.g. hi_addr<>)? I assume that the external USB interface expects some timing relation between the hi_clk and the data lines.

Thanks,

Kam

10

I just posted to the wrong thread. Please ignore.

:wink:

Kam