Lattice Diamond 3.12_240 painfully slow startup on Debian 11

[davorin]

Good afternoon (o;

Reisntalled Lattice Diamond 3.12 on my Debian 11.1 box with help of the alien rpm2deb conversion tool...

Now when I fire up diamond through console I see no error/warning messages...but the start up screen displays for around almost 4 minutes "Initializing ECO Editor" until the IDE is displayed...
Also dealing with the programming cable is painfully slow...but the HW-USBN-2A clone is detected and works then...

Interestingly synthesizing a design works fast as expected...


Anyone else has/had this slow startup issue?

[ataradov]

Try to run it though strace and see what it is doing during that time.

[SiliconWizard]

Yeah. Never used Diamond on Linux, so can't comment further. Except that it may be related to the license checker?

[davorin]

Hmm...seeing loads of these with strace:

Code: [Select]

openat(AT_FDCWD, "/dev/bus/usb/010", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
fstat(11, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
getdents64(11, 0x18a0590 /* 3 entries */, 32768) = 72
openat(AT_FDCWD, "/dev/bus/usb/010/001", O_RDWR) = 12
ioctl(12, USBDEVFS_CONNECTINFO, 0x7ffff7c75018) = 0
read(12, "\22\1\20\3\t\0\3\tk\35\3\0\20\5\3\2\1\1", 18) = 18
read(12, "\t\2\37\0\1\1\0\340", 8)      = 8
read(12, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f\0060\0\0\2\0", 23) = 23
close(12)                               = 0
getdents64(11, 0x18a0590 /* 0 entries */, 32768) = 0
close(11)                               = 0
openat(AT_FDCWD, "/dev/bus/usb/010/001", O_RDWR) = 11
ioctl(11, USBDEVFS_IOCTL, 0x7ffff7c767e0) = 5
close(11)                               = 0
openat(AT_FDCWD, "/dev/bus/usb/009", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
fstat(11, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
getdents64(11, 0x18a0590 /* 3 entries */, 32768) = 72
openat(AT_FDCWD, "/dev/bus/usb/009/001", O_RDWR) = 12
ioctl(12, USBDEVFS_CONNECTINFO, 0x7ffff7c75018) = 0
read(12, "\22\1\0\2\t\0\1@k\35\2\0\20\5\3\2\1\1", 18) = 18
read(12, "\t\2\31\0\1\1\0\340", 8)      = 8
read(12, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17
close(12)                               = 0
getdents64(11, 0x18a0590 /* 0 entries */, 32768) = 0
close(11)                               = 0
openat(AT_FDCWD, "/dev/bus/usb/009/001", O_RDWR) = 11
ioctl(11, USBDEVFS_IOCTL, 0x7ffff7c767e0) = 3
close(11)                               = 0
openat(AT_FDCWD, "/dev/bus/usb/008", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
fstat(11, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0
getdents64(11, 0x18a0590 /* 5 entries */, 32768) = 120
openat(AT_FDCWD, "/dev/bus/usb/008/003", O_RDWR) = 12
ioctl(12, USBDEVFS_CONNECTINFO, 0x7ffff7c75018) = 0
read(12, "\22\1\0\3\t\0\3\t\t!\23\10\21\220\1\2\0\1", 18) = 18
read(12, "\t\2\37\0\1\1\0\340", 8)      = 8
read(12, "\0\t\4\0\0\1\t\0\0\0\7\5\201\23\2\0\10\0060\0\0\2\0", 23) = 23
close(12)                               = 0

Guess I have too many USB devices connected....

[SiliconWizard]

Looks like it's scanning all USB devices  - in the hopes of finding a supported USB programmer I guess? That's just awful and kinda rude.

[davorin]

Well I disconnected all USB devices except mouse/keyboard and the HW-USBN-2A programmer...still takes 4 minutes for the main screen....

Not sure if the built-in SD card reader/USB hub causes this delays...still unkown why it accesses all /dev/bus/usb/*/* hundreds of times...

Guess I have to go the yosys/trellis/pnrnext-ecp5 route....leaving my Lattice JTAG clone unusable as no opensource package supports it....but there's the dirtyjtag project for reusing an ST-Link V/2 ;-)

[SiliconWizard]

Hmm. Not sure what the HW-USBN-2A (and clones) are based on. I thought they were using an FTDI chip (which would be supported by many open source tools then), but maybe only the -2B version is.

Anyway, if you're going to use open-source tools, there are many options for JTAG access. You could use any ftdi-based JTAG probe and use either OpenOCD or eccprog ( https://github.com/gregdavill/ecpprog ) which is very handy.

[davorin]

IIRC they have a Cypress inside....I'll put some FTDI JTAG cables on my shopping list ;-)

BTW: Is there an open source IDE to enhance the yosys/trellis /nextpnr workflow instead of putting together Makefiles manually?

[ataradov]

Yes, it looks like it is scanning for USB devices. I'm running 3.12.0.240 under Ubuntu Mate and I see it pause for like 30 seconds on the same stage. But it is not anywhere close to 4 minutes.

So this looks hardware dependent, probably not an OS fault.

The programmer startup time is also slow for me. Again, nothing like 4 minutes, but it probably takes a minute.

[SiliconWizard]

The programmer startup time is also slow for me. Again, nothing like 4 minutes, but it probably takes a minute.

This phase is also slow on Windows. Not a whole minute, but something like 20s-30s. I'm sure the implementation is quite horrible with a lot of hard-coded pauses and such.

Anyway, for the ECP5, I use ecpprog and ecpdap (depending on the probe - ecpdap supports DAP probes.) Those work qquite well and are pretty fast, at least compared to Lattice own stuff.

[ataradov]

I use my own programmer for Lattice (https://github.com/ataradov/edbg), it does what I need it to do. Slow programming did not really bother me, but I needed to have the programming implemented to support it on a custom board from the main MCU, so I just transferred the same algorithm into EDBG tool.

[davorin]

Good morning (o;

Just installed the same converted debian package diamond-3-12-base_3.12-241_amd64.deb on my office computer which runs Debian 11.1 as well..but it's an Intel machine instead of a threadripper setup...

Starting up Diamond 3.12 takes around 15 - 20 seconds....what I was used to.....so it definitively behaves differently on different hardware....

[laugensalm]

I've had this issues with many previous versions of Diamond as well. When there was other FTDI 2232H based hardware connected, it would tend to take ages to start up. Putting all this software into a Docker container can save you a lot of hassle. The most up to date HOWTO is probably this one: https://github.com/Gekkio/docker-fpga

Moving to the yosys based toolchain is only an option for designs with either relaxed timing or already optimized HDL. I'm not aware of ready made fancy IDE setups though, although I assume there's integrations with VScode and similar. I'm using JupyterLab as IDE, helps a lot with verification through pytest.