Lattice Diamond is making me sad - Page 1
Forum section: electronics / general

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 12:08:46 am
content: Hi all,I've purchased one of the MachXO2 breakout boards that mikeselectricstuff is always raving about. The Lattice Diamond software is actually quite good I think; it is fairly intuitive, and I managed to work out how to synthesise and pinmap a really basic design in about 2 minutes.Unfortunately the programmer is being painful. I've tried installing on Ubuntu 14.04 which is technically unsupported, and I got everything working (as in, no library errors). Unfortunately the jtag server just can't seem to do anything properly:Code:ERROR: pgr_program failed.Failed to Open FTDI USB port. Make sure to select the right cable type.If you have not installed the FTDI Windows USB Driver, follow the instructions in the Programmer Help topic:"Installing/Uninstalling Parallel Port Driver and USB Driver".If you have installed the driver, if you recently plugged in the cable, please wait a few seconds and try again.This will give the operating system time to recognize the cable.And in the device programmer log I get:Code:System Information:-----------------------------------------------------Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/LinuxError communicating with FTUSB cable.JTAG_OpenEx function: Device not opened.So I decided to try installing it on CentOS which is 100% binary compatible with RHEL (which is a supported platform). CentOS is now even coordinated by Red Hat as a free version of RHEL. Unfortunately I got the exact same errorsI've tried using wireshark to dump the communication between the JTAG server and Diamond, and the server is responding to a command from the IDE with 2020: Command not found and then the connection is terminated. I'm not seeing any errors on the command line, nothing in dmesg, and using strace just shows the JTAG server sending a few bytes and going back to sleep.I've tried to find out how to contact Lattice support, but I'm not that hopeful anything will come of it. Can anyone think of what I can do here?

author: ve7xen
author_rank: Super Contributor
timestamp: May 09, 2014, 12:45:10 am
content: Does your user have write permission on the correct /dev node (either the tty or I think there is a special FTDI device interface)?

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 12:54:10 am
content: Yep, added a udev rule for it. Diamond can detect the cable (which is not possible if the udev rule is missing), it just can't communicate with it. I have also tried running diamond as root.

author: Harvs
author_rank: Super Contributor
timestamp: May 09, 2014, 04:19:15 am
content: Have you tried it on a Windows PC just to make sure the hardware is OK?

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 07:15:40 am
content: Yep, just checked it then. Works fine under windows.

author: poorchava
author_rank: Super Contributor
timestamp: May 09, 2014, 07:25:29 am
content: Then it's not diamond which is making you sad - it's Linux.

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 07:29:58 am
content: Quote from: poorchava on May 09, 2014, 07:25:29 amWhile I appreciate the tongue in cheek humor, I can program it fine using urJTAG on linux, but I have to do a bunch of silly steps in diamond and then another program to get the bitstream as an SVF. I was hoping to avoid this, but I guess I don't have much of a choice nowThe only piece which doesn't work is "JTAGLServer" which is provided as binary-only by lattice, so it's not really fair to blame linuxThe command line sucks a bit too much for me to handle on windows, so I like to do my development on Linux. Altera and Xilinx work fine...

author: andersm
author_rank: Super Contributor
timestamp: May 09, 2014, 08:39:37 am
content: Is the Lattice software expecting FTDI's own Linux drivers?

author: rolfe
author_rank: Newbie
timestamp: May 09, 2014, 08:45:38 am
content: Yep, I struggled with this for a long time. There are several things you need to do:1. Dig out the online help that talks about Linux installation. There's some useful stuff there.2. Download the latest FTDI drivers, something like libftd2xx1.1.12.tar.gz, and install.3. Make sure you rmmod ftdi_sio, so you don't pick up the standard driver.4. Upgrade to Diamond 3.1 to avoid the problem where it fails to program after a few goes.Once I sorted out the above, it all just worked.Rolfe

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 08:53:09 am
content: Quote from: rolfe on May 09, 2014, 08:45:38 amHOORAY! Once I removed the ftdi_sio driver, it worked!My friend, I owe you a beer.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 09, 2014, 09:51:43 am
content: After having some nasty problems with the programmer software in Diamond 2.1, I use their older ISPVM software for programming - I'd hope the original issues have been fixed in 3.x, but as I also found that ISPVM was quite a lot faster for the devices I was using at the time I stuck with it.But sounds like this is a Linux/FTDI issue so probably wouldn't make a differenceQuoteMaybe they fixed that issue, but could be worth checkingISPVM to compare speeds.From memory, programming the XO2-7000 device on the devboard takes about 5 secs in SRAM mode and 30 secs to program the flash using ISPVM

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 10:11:09 am
content: Quote from: mikeselectricstuff on May 09, 2014, 09:51:43 amInteresting. I will have to try it out and see how speedy it is. I just got my board working under Ubuntu 14.04 and the erase/program/verify time for the 7000HE on flash was 1 minute and 28 seconds using diamond.For the record (in case anyone ever googles this), this is definitely an FTDI/Lattice issue. The kernel attaches the ftdi_sio driver for all FTDI devices that get plugged in by default. The software is supposed to tell it if it needs to use it for something else, and then it is released. But for some crazy reason they don't call usb_deatch_kernel_driver_np() in their FTDI d2xx driver. No idea why, because *everyone* else does this (libftdi, urJtag, etc) and it is well documented in libusb which is the foundation of the d2xx driver anyway.Thanks all for your assistance.

author: jeremy
author_rank: Super Contributor
timestamp: May 09, 2014, 10:49:50 am
content: And once again, for historical purposes:You can force the kernel to always unload the ftdi_sio for just the lattice device and give access to a non-superuser using these udev rules:Code:ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666"ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", ATTRS{product}=="Lattice FTUSB Interface Cable", RUN+="/bin/sh -c 'echo $kernel > /sys/bus/usb/drivers/ftdi_sio/unbind'"Just put the rules in /etc/udev/rules.d/98-lattice.rules or wherever your distribution hides the udev rules.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 10, 2014, 07:47:33 pm
content: Just did a speed comparison between the Diamond 3.1 internal programmer and the older ISPVM standalone util.SRAM : diamond 11 secs, ISPVM 4 secsFlash : Diamond 40 secs ISPVM 30 secsDiamond seems to always hang around for about 5 secs before doing anything - FAIL.And despite being more "integrated" you still can't set it up to automatically program after a compile.When will FPGA software come out of the stone age?

author: peepo
author_rank: Contributor
timestamp: December 30, 2015, 12:25:08 pm
content: I am having significant issues trying to program MachXO3 using ubuntu:https://www.eevblog.com/forum/microcontrollers/lattice-diamond-program-ftdi-issue/comments appreciated

author: pix3l
author_rank: Regular Contributor
timestamp: January 06, 2016, 08:54:25 am
content: @mikeselectricstuff: could you tell me how you got ISPVM working with the XO2? I've spent numerous hours but can not get it to work..

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 06, 2016, 10:22:54 am
content: Quote from: pix3l on January 06, 2016, 08:54:25 amWhat exactly is the problem?I just run it (having set the right cable type) & it works. The only issue I've ever had with Lattice programming is theor USB cable usually needs about 22pf on the clock line - seen this on both XO2 and the old EC FPGAs

author: pix3l
author_rank: Regular Contributor
timestamp: January 06, 2016, 03:05:53 pm
content: When I open the .xcf file from my project, I get an error saying "MachXO2-2000ZE not supported"

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 06, 2016, 04:22:18 pm
content: Quote from: pix3l on January 06, 2016, 03:05:53 pmAssuming you have the latest version, and it lets you select that device, but gives the error when loading, then I suggest you raise a support ticket with Lattice

author: pix3l
author_rank: Regular Contributor
timestamp: January 06, 2016, 04:48:14 pm
content: Yes I have the latest version (18.1) and no, it does not let me select any MachXO2 device...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: January 06, 2016, 04:58:02 pm
content: Unless they've changed something and not updated the version number, something's not right - My 18.1 install (Win7) allows selection of XO2 parts.

author: pix3l
author_rank: Regular Contributor
timestamp: January 07, 2016, 03:23:55 pm
content: Hi Mike,I redownloaded the installer from their website and this installer was named "ispVMSystemV18.1.1.exe". So apparently they also have minor versions which they "conveniently" don't state in the about tab of the tool. After installing this version, I went to Options > Device Database Installation, which allowed me to add support for the XO2-family. For completeness sake: the XO2 was not in the Device Database Installation menu of the other 18.1 version that I had.Anyway, let's get streaming some bits!

author: Brane212
author_rank: Contributor
timestamp: July 08, 2016, 04:15:03 pm
content: Hi to all,thanks for this thread. It saved my bacon. I have tried programming the board for bazzilion times and always failed miserably through FTDI, while Lattice ISP programming calbe worked.It turned out to be same reason as with cups printing- I needed to remove kernel module, led generic USB layer show USB device and leave it accessible to the program, which accesses it with libftdi.Thanks again.But I have one more question:I have two such boards. Originally both were with XO27000HE chip, but I managed to let magic smoke out of one, so I replaced it. BUt because Farnell didn't have HE version, I used HC instead and adapted VCC from 1.2V to 3.3V. Basically I bricked two Vccx testpoints together and so now I have 3.3V for I/O and core.New chip seem to be soldered on correctly, but I can't program it through FTDI ( haven't checked ISP cable yet).When trying to program basic demo ( blinks LEDs), it fails with:QuoteI suspect FTDI's EEPROM might be the possible issue- that it expects HE version.I noticved that those boards tend to carry different chips- early ones were with XO2-1200HEDo they have to be tweaked (EEPROM) or should this just work and I screwed something else ?

author: ale500
author_rank: Frequent Contributor
timestamp: July 09, 2016, 05:30:14 am
content: I have both boards, one with a 1200-ZE and one with the 7000HE, they are great ! both have 2 regulators on board. I think you may have destroyed some pads during desoldering/soldering or you may have gotten some bridges/short-circuits between the pins. It would be good if you could check the connections between the FTDI chip and the fpga, there are some holes on the board (J1). Did you remove the old 1.2 V regulator ? or just short-circuited both outputs (1.2 & 3.3) ?

author: Brane212
author_rank: Contributor
timestamp: July 09, 2016, 03:36:09 pm
content: I didn't bother at first to do it the right way, so I just shorted bot regulators.After that, I have removed the R56 ( which is bridge for VCCcore) and connect the FPGA-side of it to 3.3V.Anyway, it works now. I managed somehow to cut DI line in a stupid way. After patching, whole thing works fine now.This thread is worth pinning-up, though. That problem with ftdi_io is guaranteed to trip so many others....

author: Tainer
author_rank: Contributor
timestamp: July 19, 2016, 04:38:52 pm
content: OK, so I had to install diamond on linux recently and had to spend a good evening to get it up and running. I've seen other posts of people struggling with it so I decided to write a small guide on this topic, since none of the instructions worked for me. In my case I'm using XO3 board, diamond 3.7 on debian.Step 1: getting diamond + licenseYou have to register on their website to obtain the license. That might require a dozen of fake email addresses, since their stupid authentication system is living it's own life. When you fill in your "company" don't write "Unaffiliated" as suggested on the website - that will most likely result in unactivated account and you will keep getting "page not found" errors. To obtain a license you need to fill in your MAC address - I usually generate a random address and spoof it when I need to. Also, you have to renew the license every 6 months. Honestly, that's just a pain in the ass which is why I've been looking towards other vendors for quite a while.Step 2: installing diamondIn case your distribution doesn't support rpm-packages you can still install it without any problems. However,don't use alienon debian and it's derivatives - you'll waste lots of time and it won't work properly. Simply unpack the rpm package (put it in ~/local/diamond for example) and then unpack .tar archives in each subfolder (./bin/bin.tar, ./cae_library/cae_library.tar, etc). Now you should be able to run ./bin/lin64/diamond. If it complains about missing libraries then install those separately.Step 3: installing the licenseMAC address in the license file has to match the address ofeth0interface. To spoof MAC-address run:Code:# ip link set dev eth0 down# ip link set dev eth0 address XX:XX:XX:XX:XX:XXI do that on every machine where I use diamond.Great idea, Lattice. Thanks for making my life so much easier.Step 4: getting the programmer to workAt this point if you attach the programmer and run diamond, it will crash with a segfault and complain about usb write permissions. To get the programmer working we need to set the appropriate permissions and also unbind the ftdi_sio driver. However, in my case XO3 board has a FT2232H chip which provides a dual interface. If you look at dmesg output you should see something like[71334.912360] usb 8-2: Product: Lattice XO3L Starter Kit[71334.912363] usb 8-2: Manufacturer: Lattice[71334.915149] ftdi_sio 8-2:1.0: FTDI USB Serial Device converter detected...[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detectedIf you try to unbind ftdi_sio from device 8-2 it will not work - you have to specify device 8-2:1.0. In this case we only need to unbind the first interface, since it's used for programming.Here is a complete udev rule:Code:# Lattice FTDI programmerSUBSYSTEM == "usb", DRIVER == "usb", \ATTRS{idVendor} == "0403", ATTRS{idProduct} == "6010", \MODE := "0666", RUN += "/bin/sh -c 'basename %p:1.0 > /sys/bus/usb/drivers/ftdi_sio/unbind'"Place it under/etc/udev/rules.d/49-lattice.rulesand runudevadm triggerafterwards.If everything works properly, you should have similar dmesg output after attaching the board:[71334.915526] usb 8-2: FTDI USB Serial Device converter now attached to ttyUSB0[71334.918138] ftdi_sio 8-2:1.1: FTDI USB Serial Device converter detected...[71334.927683] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0[71334.927699]ftdi_sio 8-2:1.0: device disconnected

author: Brane212
author_rank: Contributor
timestamp: July 20, 2016, 02:11:35 pm
content: Couple more remarks about Diamond:1. Check file owners. When you find and untar all those tarwhatevers, you'l find they have undefined owners and possibly permissions.This can causevarious problems later, during usage, when programs call each other.2. Same problem with libraries. Depending on your distro, it might happen that Diamond needs library that you don't have or that has wrong version and/or missing feature.You can see that it has some libraries (libQtsomething ) but this just burries basic problem one level deeper- those libraries then just depend on some other libs on your system.I usually copy libQtxxx from my system folder into Diamond/libs and if needed, I compile them specially for this purpose. There muste be other solutions, but I never bothered.3. network card name. For some reason, Diamond checks JUST interfaces named ethX. If you have on your system NIC that either gets kernel's basic name like enp0sx or udev renames it to something like lan or wlan, you are f**ed. You have to correct change it to ethX.4. As said before, at least for the time being, you have to remove or deactivate ftd_sio kernel module ( or compile kernel without it, if its built-in), if you plan to use FTDI-based programmers that are onboard.

author: humbug11
author_rank: Newbie
timestamp: July 26, 2016, 04:00:00 pm
content: I managed to get Diamond working on Linux, thanks for the tips!However, for some reason it is almost an order of magnitude slower than on Windows. I'm using the "pgrcmd" to program devices from the command line using an xcf file created with Diamond. On Windows, CRAM program & verify takes less than 10s whereas on Linux it is more than one minute! Does anyone know if there is a way to make this faster? I need to program the NVCRAM of a few hundred devices and waiting 1 minute isn't really practical. All our work is on Linux, so it would be annoying to need a Windows PC just for this step.

author: Tainer
author_rank: Contributor
timestamp: July 29, 2016, 11:45:12 pm
content: Diamond is indeed slower under linux. Programming doesn't take that long for me, however the programmer takes about 10 seconds before it starts doing anything (I use the GUI thing from within diamond).I think your best option is to follow Mike's advice and use ISPVM software.Latest version for linux is 17.9, although 18.1 runs ok under wine.Code:http://files.latticesemi.com/ispVM/ispVMSystemV18.1.1.ziphttp://files.latticesemi.com/ispVM/ispvm_v17_9_linux.tar.gzBoth versions did not support XO3, however you can add missing database files (Database/xpga/xo3) from diamond programmer.This is as far as I got with ISPVM, since for some reason it refused to detect FTDI cable. I might give it another shot and revisit this post later.

author: janoc
author_rank: Super Contributor
timestamp: July 30, 2016, 10:54:16 am
content: Quote from: jeremy on May 09, 2014, 08:53:09 amActually, you don't have to remove the driver - which will also prevent any other FTDI adapters from working.Just detach it like this (modify for your device, of course):https://lwn.net/Articles/143397/That can be automated by a small script. There is even a ready made utility for this somewhere on Github.

author: corecode
author_rank: Newbie
timestamp: March 30, 2017, 03:52:01 pm
content: I just installed Lattice Diamond 3.9 on Archlinux, and I kept getting crashes *after* doing the whole udev dance.Turns out that their libftcjtag (which seems to be a libusb derivative) has a bug in theirEventDestroy()function which leads to a segfault in libpthread's__lll_unlock_elision. The bug is a doublepthread_mutex_unlock(), which leads to a segfault on modern Intel processors which support thexstart/xendtransactional memory instructions.AllEvent*()functions leave the mutex unlocked upon exit, yetEventDestroy()callspthread_mutex_unlock():0000000000023c8b <EventDestroy@@Base>:23c8b: 55 push %rbp23c8c: 48 89 e5 mov %rsp,%rbp23c8f: 48 83 ec 10 sub $0x10,%rsp23c93: 48 89 7d f8 mov %rdi,-0x8(%rbp)23c97: 48 8b 45 f8 mov -0x8(%rbp),%rax23c9b: 48 89 c7 mov %rax,%rdi23c9e: e8 ad d7 fe ff callq 11450 <pthread_mutex_unlock@plt>23ca3: 48 8b 45 f8 mov -0x8(%rbp),%rax23ca7: 48 83 c0 28 add $0x28,%rax23cab: 48 89 c7 mov %rax,%rdi23cae: e8 fd bc fe ff callq f9b0 <pthread_cond_destroy@plt>23cb3: 48 8b 45 f8 mov -0x8(%rbp),%rax23cb7: 48 89 c7 mov %rax,%rdi23cba: e8 61 d6 fe ff callq 11320 <pthread_mutex_destroy@plt>23cbf: c9 leaveq23cc0: c3 retqtogether with:http://repo.or.cz/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/x86/elision-unlock.c:Quotedoes exactly what the comment sayszsh: segmentation fault (core dumped) /usr/local/diamond/3.9_x64/bin/lin64/diamond#0 0x00007ffff620c6c0 in __lll_unlock_elision () from /usr/lib/libpthread.so.0#1 0x00007fffd1cb5ca3 in EventDestroy () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1#2 0x00007fffd1cb00f2 in FT_Close () from /usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so.1Fix:Using the offset of the call topthread_mutex_unlock()identified in the objdump ofEventDestroy():printf "\x90\x90\x90\x90\x90"| sudo dd of=/usr/local/diamond/3.9_x64/bin/lin64/libftcjtag.so bs=1 seek=$((0x23c9e)) conv=notruncWin!Edit: turns out that you also need to either patch the same bug out ofcableservermain, or you just nuke it alltogether:ln -fs $(which false) /usr/local/diamond/3.9_x64/bin/lin64/cableserver

author: janoc
author_rank: Super Contributor
timestamp: March 30, 2017, 04:10:50 pm
content: Quote from: corecode on March 30, 2017, 03:52:01 pmThat's a pretty hardcore method of patching binariesI think I will stick with my hex editor.