Issue in Python API for XEM3010?

FrontPanel
1

@O-K and others
I recently noticed a problem in running the Python script of DES with old XEM3010, which is, I could only run DESTester.py once after XEM3010 is first powered on. The XEM initialization would fail if I try to run the script again, i.e., it would not read out the XEM3010 device information, program the FPGA successfully again, UNLESS, I power cycle the board.
This problem does not exist with Spartan 6 boards, like XEM6006 or 6010. I can re-run DESTester.py as many times as I want, without having to power-cycle the boards.
This problem does not exit with other API, like MATLAB. I can redo the initialization, re-programming as many times as I want without power-cycling, with MATLAB.
Please advise what I have missed with Python, does the Frontpanel instance (“XEM”) need to be deleted at the end of each run for XEM3010. If so, how to do that in Python ? Thanks in advance.

PS - we a a large number of legacy 3010 boards in our systems, that is why I still have to deal with these.

2

Can you please confirm which version of the FrontPanel SDK you are using?

Which version of firmware do you have on the XEM3010? and on the XEM6006 / XEM6010?

3

I am using Front Panel 5.24, and having this problem. I could go back to 3.16 on one of my real old laptop to see if it has the same behavior.

4

Firmware versions
XEM 3010: Firmware version: 3.1
Serial Number: 141100088W
XEM 6010: Firmware version: 3.1
Serial Number: 11180001CF
XEM 6006: Firmware version: 3.1
Serial Number: 14060007VF

I am running Python 2.7 on windows 10.

5

With consistent firmware versions, you should not see any difference in behavior among these three USB 2.0 devices. Can you confirm that the XEM3010 jumpers are located where they should be for FrontPanel configuration and communication?

6

Thanks for pointing to the FPGA programing related pins. After reading the users manual, I noticed XEM 3010 uniquely has a group of pins in the top-level port that has to be properly terminated in the RTL code

output wire i2c_sda,
output wire i2c_scl,
output wire hi_muxsel,
…
assign i2c_sda = 1’bz;
assign i2c_scl = 1’bz;
assign hi_muxsel = 1’b0;

In my Verilog, I mistakenly deleted them, thought they were unused pins, that caused the problem I was experiencing. After putting these three pins back in the code, I can now repeatedly run python to initiate the XEM instance.

I lucked out with the S6 boards because they do not have these three signal pins that S3 board does.

7

@O-K
There is a bug in DESTester.py of Samples, 5.24 Release;
There is an extra “s” in ln 12
self.xem = devices.Open()

should be
self.xem = device.Open()