Questions about AN61345 - Designing with EZ-USB FX2LP™ Slave FIFO Interface using FPGA

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 Hi,

   

I have just read the AN61345 by Rama Sai Krishna V, which explains and provides examples for a complete configuration of a Host + FX2LP + FPGA system. I saw in the Document History that there used to be a version with details about the Virtex5. 

   

I am currently trying to develop a system like the one described in that application note on a Avnet Virtex5 board, and was wondering if that version of the document is still available.

   

Thank you so much.

   

Regards,

   

Alessandro Angelino

0 Likes
1 Solution
Anonymous
Not applicable

 Can you please explain your application?

View solution in original post

0 Likes
30 Replies
Anonymous
Not applicable

 Can you please explain your application?

0 Likes
Anonymous
Not applicable

 The older projects had a timing  voilation and using internal IFCLK in FX2LP. So the projects had been updated.

   

The new projects use external IFCLK on FXLP.

   

If you still want the files, you can mail nikl@cypress.com or rskv@cypress.com

Anonymous
Not applicable

 Check this post for info on the latest projects:

   

http://www.cypress.com/?app=forum&id=167&rID=78668

Anonymous
Not applicable

Hi, thank you for your help.

   

 

   

The project I'm working on is based on a pre-existing design which worked with the serial port. Now I would like to upgrade it to a USB connection, using the CyAPI library on the host side.

   

 

   

I just need quite a little amount of data to be sent from the FPGA to the PC and other data on the way back - all data is provided by the FPGA itself, so no particular computation is needed by the USB controller. I saw the AN61345 and realized that the slave mode is probably the most suitable for my design, but this is the very first time I'm approaching USB, so I was looking for something very close to my configuration in order to have more material to start from.

   

 

   

I will also read the link you posted, and maybe try to send an email for those older versions of the application note.

   

 

   

Do you have any suggestion for the implementation of such a system on a Virtex5 Avnet board? Thank you!

0 Likes
Anonymous
Not applicable

In particular, my problem is related to the pin assignment in the .ucf file, which I don't know how to adapt to my board.

0 Likes
Anonymous
Not applicable

 Pin assignment depends on your hardware.

   

Either you already have a hardware and then you decide which pins you want to use and put it down in your ucf.

   

Or first decide your pin assignment, create an ucf and then design your hardware accordingly.

   

Let us know details on your interface so that one of us can assist you in deciding the pin assignment.

Anonymous
Not applicable

Yes, I'd really appreciate someone's help about this topic.

   

 

   

The hardware I'm working on is an Avnet board, the V5LX50, with a Xilinx XC5VLX50-FF676 FPGA and a Cypress CY7C68013A-100AC USB Microcontroller. I would like to modify the ucf file given with the design example related to the AN61345 in order to make it compatible with the board I'm using... but actually I don't know where to start from!

   

 

   

Thank you very much in advance!

0 Likes
Anonymous
Not applicable

 alemrto

   

In the loopback example (path: \AN61345 - Source files for FPGA code and FX2LP Firmware\001-61345\FPGA Source Code_Verilog\Loopback\fx2lp_loopback_proj\) you can find a ucf file with the following content:

   

   

NET "clk"  LOC = "K14" |IOSTANDARD = LVCMOS33 ;

   

 

   

NET "clk_out"  LOC = "J14" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; 

   

 

   

NET "fdata<0>"  LOC = "C16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; 

   

NET "fdata<1>"  LOC = "C15" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<2>"  LOC = "D16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<3>"  LOC = "D14" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<4>"  LOC = "E13" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<5>"  LOC = "E12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<6>"  LOC = "F16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<7>"  LOC = "F15" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<8>"  LOC = "P10" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<9>"  LOC = "N12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<10>"  LOC = "P12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<11>"  LOC = "N5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<12>"  LOC = "P5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<13>"  LOC = "L8" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<14>"  LOC = "L7" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<15>"  LOC = "R5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

 

   

NET "faddr<0>"  LOC = "T5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA4

   

NET "faddr<1>"  LOC = "N11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA5

   

NET "slrd"  LOC = "K11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "slwr"  LOC = "J11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "sloe"  LOC = "T3" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA2

   

NET "flaga"  LOC = "F12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "flagd"  LOC = "T10" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

 

   

NET "done"  LOC = "G11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

Anonymous
Not applicable

 To explain the signals:

   

"clk" is the IFCLK (input clock for Slave fifo interface; can be internal/external); on ZTEX board this is connected to "K14" pin of FPGA.

   

In you case you will to find which pin of FPGA is IFCLK of Fx2lp connected to and replace K14 with the pin.

   

Make the similar changes in the verilog code

Anonymous
Not applicable

 Similarly for 

   

clk_out: clock out from FX2LP; this is input clock to FPGA PLL; a phase shift clock is generated using clk_out of FX2LP and given to IFCLK of Fx2LP

   

fdata: slave fifo data; can be 8/16 bit data;

   

faddr<0>, <1>: is slave address

   

slrd, slwr and sloe are general slave read, write and enable signals

   

Flag a/d: flags to indicate fifo status

   

done: is high when FPGA configuration is done; in Fx2lp firmware this bit is polled for (check code in TD_Poll function); when this bit is high the IFCLK is changed from internal to external in FX2LP firmware (because if IFCLK is supposed to be External, the IFCLK should already be present when IFCLK is configured as external)

Anonymous
Not applicable

 for all of the above signals of FX2LP you need to find the corresponding connections on FPGA on your board and make the corresponding changes in ucf and verilog code.

   

Please let me know if the information helped.

Anonymous
Not applicable

 Hi,

   

 UCF file is shown below

   

 

   

NET "clk" TNM_NET = "clk";

   

NET "clk"  LOC = "K14" |IOSTANDARD = LVCMOS33 ;

   

 

   

NET "clk_out"  LOC = "J14" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; 

   

 

   

NET "fdata<0>"  LOC = "C16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; 

   

NET "fdata<1>"  LOC = "C15" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<2>"  LOC = "D16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<3>"  LOC = "D14" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<4>"  LOC = "E13" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<5>"  LOC = "E12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<6>"  LOC = "F16" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<7>"  LOC = "F15" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<8>"  LOC = "P10" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<9>"  LOC = "N12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<10>"  LOC = "P12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<11>"  LOC = "N5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<12>"  LOC = "P5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<13>"  LOC = "L8" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<14>"  LOC = "L7" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "fdata<15>"  LOC = "R5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

 

   

NET "faddr<0>"  LOC = "T5" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA4

   

NET "faddr<1>"  LOC = "N11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA5

   

NET "slrd"  LOC = "K11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "slwr"  LOC = "J11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "sloe"  LOC = "T3" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ; # PA2

   

NET "flaga"  LOC = "F12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "flagd"  LOC = "T10" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "pkt_end"  LOC = "T11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "sync"  LOC = "G12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

NET "done"  LOC = "G11" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

You can map the pins as per your hardware connection by changing LOC, Eg if pin F12 of FPGA is connected to Flagd, for this UCF can be changed as

   

NET "flagd"  LOC = "F12" |IOSTANDARD = LVCMOS33 |DRIVE = 12 ;

   

Regards

   

Prajith

Anonymous
Not applicable

That was really helpful, thank you!

   

 

   

I created my own UCF file following your suggestions. Actually there were some problems with my target device, because some of the signals were multiplexed and needed other signals in order to be used.

   

 

   

I still have some doubts:

   

 

   

1) PRJI posted a sample version of the UCF file with the "sync" signal, but I don't have it in my design example. Shall I add it?

   

 

   

2) I had to make the following modifications to the VHDL code of the design example to adapt it to the Virtex5:

   

ODDR_2 was substituted with ODDR

   

DCM_SP was substituted with DCM_ADV

   

and after synthesization i have the following warnings:

   

 

   

CODE:

   

dout_next <= data_array(conv_integer(read_index(7 downto 0))); 

   

WARNING:

   

Index value(s) does not match array range, simulation mismatch.

   

 

   

CODE:

   

process(current_loop_back_state, flagd) begin
        if((current_loop_back_state = loop_back_write) and (flagd = '1') and (fifo_empty = '0')) then
            slwr_n <= '0';
        else
            slwr_n <= '1';
        end if;
    end process;

   

WARNING:

   

One or more signals are missing in the process sensitivity list. To enable synthesis of FPGA/CPLD hardware, XST will assume that all necessary signals are present in the sensitivity list. Please note that the result of the synthesis may differ from the initial design specification. The missing signals are: fifo_empty. (The same warning is displayed for the LoopBack mode state machine combo)

   

 

   

Is it a problem?

   

 

   

3) I tried the design with the USB Control Center: it successfully executes the bulk out transfer, and when I try the bulk in transfer, I only receive the "ODD" part of data correctly:

   

 

   

INPUT:

   

BULK OUT transfer
0000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0010 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
0020 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
0030 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
0040 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
0050 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
0060 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
0070 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
0080 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
0090 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
00A0 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
00B0 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
00C0 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
00D0 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
00E0 E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
00F0 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
0100 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0110 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
0120 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
0130 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
0140 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
0150 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
0160 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
0170 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
0180 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
0190 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
01A0 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
01B0 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
01C0 C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
01D0 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF
01E0 E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
01F0 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF
BULK OUT transfer completed

   

 

   

OUTPUT:

   

BULK IN transfer
0000 FE 01 FE 03 FE 05 FE 07 FE 09 FE 0B FE 0D FE 0F
0010 FE 11 FE 13 FE 15 FE 17 FE 19 FE 1B FE 1D FE 1F
0020 FE 21 FE 23 FE 25 FE 27 FE 29 FE 2B FE 2D FE 2F
0030 FE 31 FE 33 FE 35 FE 37 FE 39 FE 3B FE 3D FE 3F
0040 FE 41 FE 43 FE 45 FE 47 FE 49 FE 4B FE 4D FE 4F
0050 FE 51 FE 53 FE 55 FE 57 FE 59 FE 5B FE 5D FE 5F
0060 FE 61 FE 63 FE 65 FE 67 FE 69 FE 6B FE 6D FE 6F
0070 FE 71 FE 73 FE 75 FE 77 FE 79 FE 7B FE 7D FE 7F
0080 FE 81 FE 83 FE 85 FE 87 FE 89 FE 8B FE 8D FE 8F
0090 FE 91 FE 93 FE 95 FE 97 FE 99 FE 9B FE 9D FE 9F
00A0 FE A1 FE A3 FE A5 FE A7 FE A9 FE AB FE AD FE AF
00B0 FE B1 FE B3 FE B5 FE B7 FE B9 FE BB FE BD FE BF
00C0 FE C1 FE C3 FE C5 FE C7 FE C9 FE CB FE CD FE CF
00D0 FE D1 FE D3 FE D5 FE D7 FE D9 FE DB FE DD FE DF
00E0 FE E1 FE E3 FE E5 FE E7 FE E9 FE EB FE ED FE EF
00F0 FE F1 FE F3 FE F5 FE F7 FE F9 FE FB FE FD FE FF
0100 FE 01 FE 03 FE 05 FE 07 FE 09 FE 0B FE 0D FE 0F
0110 FE 11 FE 13 FE 15 FE 17 FE 19 FE 1B FE 1D FE 1F
0120 FE 21 FE 23 FE 25 FE 27 FE 29 FE 2B FE 2D FE 2F
0130 FE 31 FE 33 FE 35 FE 37 FE 39 FE 3B FE 3D FE 3F
0140 FE 41 FE 43 FE 45 FE 47 FE 49 FE 4B FE 4D FE 4F
0150 FE 51 FE 53 FE 55 FE 57 FE 59 FE 5B FE 5D FE 5F
0160 FE 61 FE 63 FE 65 FE 67 FE 69 FE 6B FE 6D FE 6F
0170 FE 71 FE 73 FE 75 FE 77 FE 79 FE 7B FE 7D FE 7F
0180 FE 81 FE 83 FE 85 FE 87 FE 89 FE 8B FE 8D FE 8F
0190 FE 91 FE 93 FE 95 FE 97 FE 99 FE 9B FE 9D FE 9F
01A0 FE A1 FE A3 FE A5 FE A7 FE A9 FE AB FE AD FE AF
01B0 FE B1 FE B3 FE B5 FE B7 FE B9 FE BB FE BD FE BF
01C0 FE C1 FE C3 FE C5 FE C7 FE C9 FE CB FE CD FE CF
01D0 FE D1 FE D3 FE D5 FE D7 FE D9 FE DB FE DD FE DF
01E0 FE E1 FE E3 FE E5 FE E7 FE E9 FE EB FE ED FE EF
01F0 FE F1 FE F3 FE F5 FE F7 FE F9 FE FB FE FD FE FF
BULK IN transfer completed

   

 

   

is this something related to hardware? I think this behavior is quite strange, it seems like only a part of the data, systematically, is being read, while the other is given as simple repetition of the last (even) hex received.

   

 

   

Thank you very much again for your help.

0 Likes
Anonymous
Not applicable

 0000 FE 01 FE 03 FE 05 FE 07 FE 09 FE 0B FE 0D FE 0F

   

0010 FE 11 FE 13 FE 15 FE 17 FE 19 FE 1B FE 1D FE 1F
0020 FE 21 FE 23 FE 25 FE 27 FE 29 FE 2B FE 2D FE 2F
0030 FE 31 FE 33 FE 35 FE 37 FE 39 FE 3B FE 3D FE 3F
0040 FE 41 FE 43 FE 45 FE 47 FE 49 FE 4B FE 4D FE 4F
0050 FE 51 FE 53 FE 55 FE 57 FE 59 FE 5B FE 5D FE 5F
0060 FE 61 FE 63 FE 65 FE 67 FE 69 FE 6B FE 6D FE 6F

   

 

   

The input data is like this because FGPA is sending out data as soon as it is configured.

   

So solve this issue, you will need a sync signal from FX2LP

Anonymous
Not applicable

 For eg, this should be the algorithm:

   

1) FX2LP comes up with internal clock and enables JTAG for FPGA; FX2Lp keeps polling DONE bit from FPGA

   

2) FPGA is configured through JTAG and makes DONE bit high afer it comes up and also provide IFCLK to FX2LP

   

3) FX2LP changes the IFCLK to external and pulls a SYNC bit high

   

4) FPGA on receiving the SYNC bit, enters the data transfer loop

Anonymous
Not applicable

 If you do not have SYNC bit implementation in FPGA, the FPGA will start data transfer as soon as it comes up and will be in unknown state when FX2LP IFCLK changes from internal and external and FX2LP is ready for data transfer

Anonymous
Not applicable

 Sorry...What I posted previously is required if it is a Streamer application, like when FPGA sends continous data to FX2LP.

   

In case of loop-back, are you driving 8 bit data from FGPA or 16 bit data?

   

Because FX2LP is configured in 16 bit slave fifo mode in the AN project

Anonymous
Not applicable

In my case I'm implementing the loopback, and am using the file provided in the AN, "fifo_512x8.vhd".

   

 

   

Shall I turn it to a "fifo_512x16.vhd"?

   

 

   

Anyway, I found something that may identify the problem. I saw that the FX2LP waits for the DONE signal on GPIFADR[1], right? The problem is that on the board I'm using (V5LX50 by Avnet) that signal is used as "SelectMAP Port Mode" and I don't manage mapping it in the UCF file (Xilinx gives an error), while RDY[3] is used as FPGA _DONE as you can see at http://www.ece.ucdavis.edu/vcl/vclpeople/jwwebb/measbd/ctrl_fpga/avnet_v5lx50/xlx_v5_lx_dev-ug-rev1.... (page 23 of 40).

   

 

   

Shall I change the FX2LP firmware to map it differently (to RDY[3])?

0 Likes
Anonymous
Not applicable

I saw that in the firmware there is this line:

   

 

   

OEC&=0xFD;   // PC.1 as input (Clock changing signal)
SYNCDELAY;

   

 

   

shall I change it to use another pin which I can connect to in my hardware? It would be really helpful if you helped me on this, if you agree that this could be a way to solve the issue.

   

Thank you!
 

0 Likes
Anonymous
Not applicable

 Yes, since FX2LP is in 16 bti slave interface mode, you can choose to send 16 bit data from FPGA.

   

If you feel 8 bit interface is sufficient for your application, you can change the FX2LP firmware to make FX2LP work as slave with 8 bit interface. (I can point to the changes you need to make, if you want 8 bit slave interface)

   

RDY3 seems to be a GPIF ready pin, I am not too sure if this pin can be used as a GPIO in Slave fifo interface. (Let me get back to you on this)

Anonymous
Not applicable

 For using 'done' from FPGA you have two options:

   

1) If you go with 8 bit interface, you can use any on port D on FX2LP (PD.0-PD.7)

   

2) If you go with 16 bit interface(you cannot use port D), PA.0 is still unused

   

All ports are default inputs unless you define them as output

   

In FW.c, you can find the following code:

   

   

   // Initialize user device

   

    TD_Init();

   

   //JTAG Enable and SYNC signals for ZTEX Spartan 6 module 1.1 (FGPA+FX2LP setup)

   

OEA|=0x02; //Declare PA.1 as output

   

SYNCDELAY;

   

IOA|=0x02; //output 1 on PA.1

   

SYNCDELAY;

   

 

   

OEC|=0x01; //PC.0 as output (SYNC signal)

   

SYNCDELAY;

   

IOC|=0x00; //output 0 on PC.0...SYNC signal is LOW 

   

SYNCDELAY;

   

 

   

OEC&=0xFD; //PC.1 as input (Clock changing signal)

   

SYNCDELAY;

Anonymous
Not applicable

 You can replace :

   

OEC&=0xFD; //PC.1 as input (Clock changing signal)

   

with

   

OEA&=0xFE; //PA.0 as input (Clock changing signal)

Anonymous
Not applicable

 Next change will be in slave.c:

   

Replace: IOC & 0x02

   

with: IOC & 0x01

   

 

   

This should basically change the logic to the following:

   

PA.0 is monitored for 'done' from fpga and once PA.0 is high, SYNC signal is sent from FX2LP on PC.0

Anonymous
Not applicable

 FYI

   

In Spartan-6, you need a JTAG enable signal (to download fpga bitstream through JTAG) , which is mapped to PA.1. So in FX2Lp firmware, in FW.C there are these instructions:

   

   

   //JTAG Enable and SYNC signals for ZTEX Spartan 6 module 1.1 (FGPA+FX2LP setup)

   

OEA|=0x02; //Declare PA.1 as output

   

SYNCDELAY;

   

IOA|=0x02; //output 1 on PA.1 (JTAG ENABLE)

   

SYNCDELAY;

   

If VIRTEX 5 does not have a dedicated pin to enable JTAG configuration, you can even use PA.1 for any purpose.

Anonymous
Not applicable

 Please go through OEX and IOX instructions in FX2LP TRM to understand how to handle IOs.

   

 

   

Thanks

   

Nikhil

Anonymous
Not applicable

 Let me know how things have worked out after making the above suggested changes.

   

 

   

Thanks

   

Nikhil

Anonymous
Not applicable

Thank you for your reply!

   

 

   

I managed changing the 'done' signal mapping both on the FPGA and the FX2LP side, using your suggestions for the firmware changes.

   

 

   

The problem is that the output is still the one I showed you some posts ago. In particular, every 16 bits sent in BULK OUT, the first 8 bits are WRONG and the last 8 bits are CORRECT, in BULK IN. Moreover, the wrong 8 bits are stuck on the first 8 bits of the last 16 bit vector I send in BULK OUT.

   

 

   

So if in BULK OUT I send 512x8 bits:

   

00 01 02 03 ... FC FD FE FF

   

In BULK IN I will receive 512x8 bits:

   

FE 01 FE 03 ... FE FD FE FF

   

 

   

The same happens if I send, for example, two groups of data to form a whole packet of 512x8bits data:

   

FIRST BULK OUT      :   AA 03 05 BC ... FA 08     (256x8 bits)

   

SECOND BULK OUT:   BE 04 10 01 ... CC 32    (256x8 bits)

   

UNIQUE BULK IN     :    FA 03 FA BC ... FA 08

   

                                         CC 04 CC 01 ... CC 32      (total: 512x8 bits)

   

 

   

There is something about the whole design I am sure I'm missing. On the FPGA side I've used the fifo_512x8.vhd provided with the AN. Does it mean it is an 8 bits FIFO? Because from its code I can only find references to being a 16 bits FIFO (the FIFO itself is defined as an array of 512 std_logic_vector of 16 bits). Meanwhile, I guess from your previous posts that the FX2LP is working (with the slave.hex firmware provided with the AN) with a 512x16 bits FIFO, isn't it? But in the USB Control Center tool, the BULK IN transfers will already work after at least 512x8 bits have been sent.

   

 

   

Probably I am confused by the result I expect and the actual behavior of the system. Could you please explain, from the files provided in the AN, if the whole system is expected to work with a 512x8 or 512x16 bits?

0 Likes
Anonymous
Not applicable

 I am not sure why I am unable to find any source with the name "fifo_512x8.vhd" in the AN projects.

   

The interface is 16 bit interface.

   

Tha data being sent is 512x8 bits.

   

But the interface handles the data as 256x16 bit data.

   

If you have not touched FX2LP firmware ( except 'done' and 'sync' part), I suggest you check the part of FPGA code where the loop back is being handled.

   

FX2LP is like a pipe for USB data. So if the data received is wrong, it must be that FPGA has sent it wrong.

   

Seems like the upper 8 bits of data are being saturated/ not being refreshed with the new data. Please try looking at how the upper 8 bits are being handled in the FPGA.

Anonymous
Not applicable

You're suggestion turned out to be correct! There was a hardware issue I taught I had solved, while I was still unable to read from 8 out of 16 bits of the bus.

   

 

   

Since the flagd is used on the Avnet V5LX50 to drive a logic net which selects between the onboard flash and the usb fifo bus [7:0], the firmware needs to be changed in order to use a different flag for EP6 FULL. Of course the 'done' port must be changed for things to work as well, following your instructions.

   

 

   

Thank you for your patience! I only have a last question. Now that all signals should be working fine, I receive back 510 bytes out of 512 correct: the two that are always wrong are the first two, always stuck at FF, whatever data I send. Do you have any idea of the reason why this is happening? Thank you again!

0 Likes
Anonymous
Not applicable

 1st two bytes of every IN packet are FF?

   

or only the 1st IN packet?

   

If only 1st two bytes of 1st IN transfer are FF, then I suspect FX2LP is receiving the data even before the FPGA configuration is done?

   

Mostly this could happen if done-sync combination have not been correctly implemented.

0 Likes