Exploring an old FPGA and software (Altera Cyclone with Quartus-II 10.1)

[MarkMLl]

I find that I've got an "educational" Cyclone (not -II etc.) board like this http://kiedontaa.blogspot.com/2019/12/gameboy-to-vga.html knocking around, plus a DVD with Quartus-II 10.1... newer "free" versions don't support designing for hardware that old, but they might support programming old chips if the design has been completed elsewhere.

I've got the software running on Windows XP except for the interface to the USB Blaster.

I've also got it running on both Debian Lenny (i386) and Buster (amd64), I had to jump through a few hoops since it became quite obvious that Altera hadn't tested it. Again, I can't get the USB Blaster to work.

Short question: I've got what purports to be the right XP driver from https://www.terasic.com.tw/wiki/File:Usb_blaster_q16.1.zip, it loads correctly in response to the USB Blaster being plugged in but Quartus can't see it. Does anybody have a driver of equivalent age to Quartus=II v10?

In slightly more detail: I couldn't get the recommended Linux install program to work, the 'install' program did with caveats. It's necessary to create a local ~/adm/qenv.sh containing QENV_STATUS=0 for each user, then to run a manual command to install the required devices... which are only in the subscription section of the DVD. Finally, edit the supplied global qenv.sh and add -m 1 to grep in place of piping the result through uniq... if you don't do that things will only run on the rare occasion that the OS thinks that every CPU is running at precisely the same speed.

I think that in the case of Linux the USB Blaster problem is that "Lenny" has usbfs but no libudev, while "Buster" has abandoned usbfs. I'm not sure I've got the energy to start messing around with intermediate versions.

And yes, I know I should be looking for newer hardware and am. But I'd still like to get this going if possible, since with the LEDs etc. on the board it's a bit friendlier towards traditional electronics design than the newer boards which only have headers.

MarkMLl


A FEW DAYS LATER: for the sake of Google et al., appended is a fairly detailed blow-by-blow account of getting Quartus v10.1 and v14.1 operational on current Linux (Debian "Buster") x86_64).

Code: [Select]

# As a prerequisite to both 10.1 and 14.1, make sure that libpng12
# is available from e.g. http://ftp.debian.org/debian/pool/main/libp/libpng/
# hence something like

/usr/lib/x86_64-linux-gnu/libpng12.so.0.50.0
/usr/lib/x86_64-linux-gnu/libpng12.so.0 -> /usr/lib/x86_64-linux-gnu/libpng12.so.0.50.0
/usr/lib/i386-linux-gnu/libpng12.so.0.50.0
/usr/lib/i386-linux-gnu/libpng12.so.0 -> /usr/lib/i386-linux-gnu/libpng12.so.0.50.0

sudo mkdir /usr/local/altera
sudo chown markMLl:staff /usr/local/altera
cd ~/Quartus-II/linux_installer
cd quartus_free
./install
cd ../modelsim_ase
./install
# Both above installed into /usr/local/altera/10.1

Create ~/adm/qenv.sh

QENV_STATUS=0

# Edit /usr/local/altera/10.1/quartus/adm/qenv.sh to look like

cpumodel=`grep -m 1 'model name' /proc/cpuinfo | sed -e's/model name.*: //g' | uniq`
...
export QTB_CPU_FREQ=`cat /proc/cpuinfo | grep -m 1 "cpu MHz" | cut -c 12-18 | uniq`

i.e. adding grep's -m 1 option, the | uniq could probably be discarded.

export PATH=/usr/local/altera/10.1/quartus/bin:$PATH
quartus_sh --qinstall -qda /home/markMLl/Quartus-II/devices/subscription/cyclone.qda

# I've not had this running long emough to verify that those are permanently
# installed rather than being a 30-day evaluation.

# Edit /usr/local/bin/quartus10 to contain

#!/bin/sh

export PATH=/usr/local/altera/10.1/quartus/bin/quartus:$PATH
/usr/local/altera/10.1/quartus/bin/quartus

# Create a file like /etc/udev/rules.d/51-altera-usb-blaster.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666"

udevadm control --reload-rules && udevadm trigger

# However do not expect 10.1's JTAG to work, jtagd is buggy (I speculate that
# this is the point at which Altera attempted to move away from the deprecated
# usbfs API and didn't quite get it right).

# 14.1 should install into e.g. /usr/local/altera/14.1 without trouble, but it
# assumes the existence of libpng12, ~/adm/qenv.sh and udev rules as configured
# above. Use a similar shim file e.g. /usr/local/bin/quartus14. As soon as you
# start it disable all Internet access, otherwise it will bomb after a few minutes
# when it finds it can't "phone home"... it might be necessary to toggle this.

# 14.1 appears to still be able to program Cyclone (i.e. -I) devices, but don't try
# to hack things by symlinking 14.1's jtagd into 10.1's bin directory.


[BrianHG]

All versions of Quartus since at least 9.1 is available from Intel's site.  (Though you may need to register to download.)
For 64bit OS, only the drivers for USB Blaster in version 13.1 and later will work without crashing.

Earlier versions of Quartus will still work and see the USB Blaster and your FPGA in it's programmer, it's just programming in some modes like ActiveSerial which will want newer Quartus.

You may install multiple versions of Quartus in your system simultaneously.  Quartus 13.1 I believe is the last to support CycloneIII directly.  All versions after that only support CycloneIV and up.

I do not know about earlier programmers like the ByteBlasterMV.  Those old parallel port type programmers need a true old fashioned parallel port and 32/16 bit os which allows direct access to the port.

[MarkMLl]

All versions of Quartus since at least 9.1 is available from Intel's site.  (Though you may need to register to download.)
For 64bit OS, only the drivers for USB Blaster in version 13.1 and later will work without crashing.

Versions older than 13 have been withdrawn, so there's nothing left that will do the original Cyclone chips. There's rumblings that it's something to do with security.

I'll try getting some newer versions and see if the supplied jtagd works, since the protocol it implements will probably be compatible with 10.1. I'll report back on any progress for the record.

I was fairly impressed with how well this older software worked on a current copy of Linux. I was much less impressed by some very sloppy work that needed fixing to get it to that stage.

MarkMLl

[james_s]

IIRC you can get older versions of Quartus from torrent sites, it's still the free version but it allows you to bypass the requirement to sign up in order to download.

I use Quartus II 13.0 spi on Win7 x64 and it works great with the USB byte blaster. I have quite a few Cyclone II boards, it's an old part but plenty powerful for what I'm doing.

[MarkMLl]

IIRC you can get older versions of Quartus from torrent sites, it's still the free version but it allows you to bypass the requirement to sign up in order to download.

I use Quartus II 13.0 spi on Win7 x64 and it works great with the USB byte blaster. I have quite a few Cyclone II boards, it's an old part but plenty powerful for what I'm doing.

One of my jobs for today is getting a slightly more recent card: some sellers on AliExpress have an "11th Anniversary" sale for a couple of days. I'm inclined to stick with Altera until I have a good reason to change now that I've determined that they're Linux-friendly, although I might get one of these very cheap boards as well to see if anything at all can be done with it.

https://www.aliexpress.com/item/1005001413627842.html

Interest is largely educational, although I also want to be prepared for some edge-coincidence stuff that is likely to challenge a microcontroller.

MarkMLl

[james_s]

If you want to play with a cheap board like that, I'd suggest trying out the software first. I personally quite like Quartus, Xilinx ISE is not bad either, it has some things I like better and other things that are worse. The random Chinese stuff can be a real crapshoot, and you spend so much time in the software that a cheap board is a false economy if the software is painful to use. Given you can get Cyclone II boards for around $13 I have not tried to find something cheaper.

[MarkMLl]

If you want to play with a cheap board like that, I'd suggest trying out the software first. I personally quite like Quartus, Xilinx ISE is not bad either, it has some things I like better and other things that are worse. The random Chinese stuff can be a real crapshoot, and you spend so much time in the software that a cheap board is a false economy if the software is painful to use. Given you can get Cyclone II boards for around $13 I have not tried to find something cheaper.

I've ordered up a Cyclone IV board with seven-segment displays etc., plus something that purports to be a "real" USB Blaster. OTOH if I'd known in advance how disagreeable Intel has made downloading 14.1 I think I'd have gone for a different manufacturer.

10.1's jtagd is throwing a segfault, I suspect that it's a libc version issue. It will be interesting to see whether 14.1's jtagd is more reliable, and whether having it in memory is sufficient to get 10.1's JTAG facility working. I'll report back presently.

I've also ordered a "Tang Nano" knowing that it (and its software support) are likely to be quirky https://hackaday.com/2019/11/03/the-5-fpga/ , with the specific intention of comparing it against the offerings from a mainstream vendor. I don't have a specific application in mind, and in particular I don't have a specific application in mind which would demand such a low price and would tolerate the risk of dodgy silicon from an unknown fab.

MarkMLl

[MarkMLl]

If you want to play with a cheap board like that, I'd suggest trying out the software first. I personally quite like Quartus, Xilinx ISE is not bad either, it has some things I like better and other things that are worse. The random Chinese stuff can be a real crapshoot, and you spend so much time in the software that a cheap board is a false economy if the software is painful to use. Given you can get Cyclone II boards for around $13 I have not tried to find something cheaper.

I've ordered up a Cyclone IV board with seven-segment displays etc., plus something that purports to be a "real" USB Blaster. OTOH if I'd known in advance how disagreeable Intel has made downloading 14.1 I think I'd have gone for a different manufacturer.

10.1's jtagd is throwing a segfault, I suspect that it's a libc version issue. It will be interesting to see whether 14.1's jtagd is more reliable, and whether having it in memory is sufficient to get 10.1's JTAG facility working. I'll report back presently.

Wrapping this up, although I might edit a bit more detail into my OP to cover installation of 10.1.

14.1 from Intel (still badged Altera) installs OK on Linux, although it might be necessary to get the png12 library from somewhere: they've changed the way the installation is bundled and you can't just grab the library from the installation files any more.

It runs, but will crash after a few minutes when it tries to 'phone home to a non-existent server (fixable from an options screen).

As expected, it doesn't support devices older than Cyclone-IV (i.e. can't open existing projects). The programmer does appear to also support Cyclone (i.e. -I), -II, -III and -III LS, although I'm not at the stage of actually writing a tentative design to hardware yet.

The jtagd daemon is reliable, and it appears to be usable by 10.1. It does time out however... I don't know if that can be configured, possibly telling it to accept remote connections would keep it active.

Which all in all is probably about as good as can be expected.

MarkMLl

[BrianHG]

As expected, it doesn't support devices older than Cyclone-IV (i.e. can't open existing projects). The programmer does appear to also support Cyclone (i.e. -I), -II, -III and -III LS, although I'm not at the stage of actually writing a tentative design to hardware yet.

The jtagd daemon is reliable, and it appears to be usable by 10.1. It does time out however... I don't know if that can be configured, possibly telling it to accept remote connections would keep it active.

Which all in all is probably about as good as can be expected.

MarkMLl

All Quartus' should be able to open all Quartus version projects.  It's just the newer versions wont 'Compile FIT' for the older cyclones.  They will compile your older design for the newer IC.

Going in the other direction, when you get an unsupported feature setting in the .qsf file when opening a design in an older Quartus, usually you can comment out that quoted bad line with a '#' at the beginning in the .qsf file, sometimes it's required for 2 or 3 lines, then the newer code will run in older versions of Quartus.

If you use the GUI megafunction editor, you may need to edit some functions in the newer Quartus unless you do it the manual way.

[james_s]

If you need an older version I can look for the CD that came with my DE2 board, I think it's version 6.something. I never installed it because I had already downloaded 13.0 but I rarely throw away anything like that either.

[BrianHG]

Version 9.1 is the last version with the old GUI engine and support for the built in simulator & waveform editor.
Also compiles faster than the new ones.

Funny, it is still downloadable from Intel's website.

[MarkMLl]

All Quartus' should be able to open all Quartus version projects.  It's just the newer versions wont 'Compile FIT' for the older cyclones.  They will compile your older design for the newer IC.

"Web Edition" 14.1 can't open a project created for a Cyclone (i.e. -I) by 10.1. The error dialog(ue) implies that "Subscription Edition" can.

MarkMLl

[MarkMLl]

If you need an older version I can look for the CD that came with my DE2 board, I think it's version 6.something. I never installed it because I had already downloaded 13.0 but I rarely throw away anything like that either.

Thanks but I specifically got hold of a DE0 DVD and the 10.1 on it runs (with a few tweaks). Can't program using it though.

It will be a real PITA if Intel continue pruning versions though.

MarkMLl

[MarkMLl]

Version 9.1 is the last version with the old GUI engine and support for the built in simulator & waveform editor.
Also compiles faster than the new ones.

Funny, it is still downloadable from Intel's website.

Are you sure it's still there?

In practice I think that library problems- particularly on Linux which is my preferred platform- will at some point prevent older versions from running. JTAG is already a problem on 10.1, and at some point older versions will insist on having usbfs which was deprecated at the kernel level quite some years ago.

With a bit of effort I find it is possible to run Debian "Lenny" binaries in a Docker container on Debian "Buster" (i.e. the the current stable version), that covers a spread of about 12 years and includes being able to run old X11 programs without modification. In principle at least it's possible to run much older versions using full emulation, but this wouldn't necessarily include graphical software. In all cases USB access for JTAG etc. is likely to be a problem.

MarkMLl

[RoGeorge]

If a docker container has problems with old USB devices, try making a virtual machine (VM) instead of using a container.  Install inside the VM whatever version of Linux and Quartus were in use back then, and never connect the virtual machine to the Internet in order to avoid unwanted upgrades or security problems.

Once you have an old Linux+Quartus installed inside a VM, the virtual disk can be preserved and run later on any OS by passing the USB from the host to the VM.  Passing a USB device from the host os to the guest VM means just a couple of mouse clicks, and it works very reliable.

Once created, a VM can be run even between different virtualization engines (e.g. virtual machines made with VMware can be imported and run in VirtualBox).

For many Linux flavors there are already made installs of old versions, ready to run (e.g. linuxvmimages.com, osboxes.org, etc.)

[MarkMLl]

If a docker container has problems with old USB devices, try making a virtual machine (VM) instead of using a container.

Yes, my final para touched on that. I've done it as routine for certain types of USB device, but I'm a little wary of things like these USB Blaster programmers which rely heavily on libusb for their interface: once one gets deeply into arbitrary devices one finds that it's a minefield of indeterminate device names, parameters which have to be parsed out of the /sys tree, HID quirks and (in the case of Windows) missing drivers.

In short, we might have been better off during the DOS era when device configuration was by DIL switch and most low-level debugging could be done with a Periscope board.

Fortunately Quartus-II 10.1 still works, subject to using a later version's jtagd. I've been able to program up a demo using both VHDL and Verilog similar to what was on the Cyclone card to start with (source for which was of course unavailable) and I now also have a Cyclone IV board so won't have to use software quite so old.

MarkMLl

[MarkMLl]

I trust the community will excuse an epilogue on this.

"Web Edition" of Quartus-II 14.1 downloaded from Intel is now announcing that it's a 30-day evaluation and will expire at the end of the month. I don't know whether that will leave device programming support operational, or at least the JTAG daemon runnable so that I can continue to use 10.1 which I have on DVD.

The Tang Nano demo board has justified its low price: the USB interface illicitly claims to be an FTDI device and only enumerates on the crappiest USB ports or hubs. However I have managed to get a demo project compiled and loaded using the supplied software, but since this requires a "phone home" at least during installation I think I'd be happier with something open-source which I could be certain would remain usable.

Which I think emphasises that unless one has corporate cash to spare or is absolutely confident that one can complete evaluation and preferably development in a matter of days it might be unwise to select any manufacturer or product line which does not have open tools available or at least a well-documented programming interface.

MarkMLl

[MarkMLl]

The Tang Nano demo board has justified its low price: the USB interface illicitly claims to be an FTDI device and only enumerates on the crappiest USB ports or hubs. However I have managed to get a demo project compiled and loaded using the supplied software, but since this requires a "phone home" at least during installation I think I'd be happier with something open-source which I could be certain would remain usable.

I've been tinkering with this over the last couple of days and think I have got to the bottom of some of the problems, at least on Linux.

As is by now fairly well appreciated, Gowin/Sipeed (or somebody acting on their behalf) has been extremely naughty and liberated FTDI's USB vid:pid codes with the presumable objective of eliminating the "Windows sees an unknown device and wants a driver" problem. While their intent might be praiseworthy the way they've gone about it isn't.

I don't think this is something that FTDI can kill remotely via a Windows driver update, since when they did that in the past to microcontrollers masquerading as their devices they relied on the device having NVR storage that they could overwrite.

On Linux, it is necessary to have a udev rule file to tell the kernel to make the device accessible to an ordinary user (typically a member of the plugdev group). It is also necessary to make sure that the ftdi_sio driver (kernel module) is not loaded, since if it is loaded (either already or when the Tang Nano is hotplugged) the Gowin programmer utility will attempt to invoke rmmod to unload it... and that's a root-only operation.

Finally, it is also generally understood that the interface chip on the Tang Nano is underpowered and needs to be plugged into old hardware: a USB v1 hub or a cheap "high performance" hub that isn't. If (on Linux) dmesg reports problems or lsusb doesn't show the device don't expect to be able to get any further.

I had problems finding a copy of the actual "as-shipped" configuration that is loaded onto the boards in the factory, so checked timing etc. and re-implemented it. Of course, I then sorted out Sipeed's broken link and found the original...

However, my https://github.com/MarkMLl/tang_nano_as_shipped might still interest since it shows the Linux configuration changes that are necessary for reliable operation, investigates where primitives are actually defined (and documented), and explores various clock sources: I've had it clocked at >100MHz using the internal PLL which opens up some interesting possibilities... provided obviously that the devices are reliable, it's bad QA and usability testing that gave us the driver problem.

On the balance, I think I'd have been happier if Sipeed had left off the LCD interface and used the few fen they'd saved to upgrade the USB interface chip to something a bit more capable: having a USB-C connection to something with USB v1 performance and all the related driver problems etc. really is a pretty weird combination. If they'd also put on a decent driver for a run of I2C wiring even better.

Finally, I'd say that I'm rather warming to the board and to the Gowin software. They "do what they say on the can", and particularly in view of the low price and comparatively small software footprint I think that just about everybody who is involved in digital electronics but isn't already committed to a particular FPGA architecture should have at least one in his parts boxes. After all most of us, particularly those used to microcontroller programming, are very much constrained by our knowledge of Verilog and VHDL... but these boards are cheap enough and accessible enough to be a viable replacement for just one or two SSI/MSI chips.

MarkMLl