Programming Lattice FPGAs on a Mac?

[mr_darker]

Anyone out there using a Mac for Lattice FPGAs?
Are there Mac alternatives for Lattice's Diamond IDE?
I've never used one before and don't know of any other IDEs for FPGAs.  Tried looking up 'open source FPGA IDE' and 'lattice diamond mac alternative' but didn't find anything.  Am I doomed to find a windows PC?

Looking to start messing around with my xo3 evaluation board, get acquainted with VHDL, the xo3 architecture, and hopefully soon use it in a design.


Side question:  Making an array of FPGAs, an array of arrays, aka a bigger array.  Anything wrong with doing that to get bigger FPGAs for less money?  (comparing Logic Blocks per dollar)

[SiliconWizard]

Not that I kow of. There are Windows and Linux versions.
You can always run either of those on a virtual machine on your Mac instead of resorting to use a PC.

[ataradov]

It it extremely hard to get it running even on Linux, where it is officially supported.

[joshtyler]

Side question:  Making an array of FPGAs, an array of arrays, aka a bigger array.  Anything wrong with doing that to get bigger FPGAs for less money?  (comparing Logic Blocks per dollar)

If you have what is essentially a monolithic design, that you intend to partition between FPGAs, you are creating a world of hurt for yourself! Whilst what you describe is technically feasible, you will have to partition your design into independent chunks with a minimal interface between chips which you define at the time of board creation (or at least define the number of pins and IO standard at board creation time). In addition it means that the partitions of your design have to have a roughly even split in terms of resource usage, which often is not the case. Not to mention the fact that you now have multiple designs to implement, multiple designs to meet timing on, multiple chips to program, each time you change your code, making your iteration time vastly greater. Assuming that you value your time, then you are likely better off buying the larger FPGA.

Having said that, if you have the same design which you want to replicate multiple times (one instance per FPGA) then the approach you describe makes a lot of sense. It could also make sense if your design consisted of several largely independent blocks with a simple and well defined interface. (E.G. You have a video processing system, which feeds into a video encoder, and the interface between the two is just a pixel stream). You would likely be best off using a high speed serial interface (with an FPGA that has appropriate gigabit transceivers)  between the FPGAs if you need high data throughput.

[asmi]

Side question:  Making an array of FPGAs, an array of arrays, aka a bigger array.  Anything wrong with doing that to get bigger FPGAs for less money?  (comparing Logic Blocks per dollar)

In short - forget it. It might work for some corner cases, but in general having one large FPGA is eons better than a bunch of smaller ones.

[Bassman59]

Not that I kow of. There are Windows and Linux versions.
You can always run either of those on a virtual machine on your Mac instead of resorting to use a PC.

I run Lattice Diamond in a Windows 7 VM on my Macs and the software works as expected. I can even program the chips with the HW-USBN-2B. No problems.

[Bassman59]

Anyone out there using a Mac for Lattice FPGAs?

I do. I run a Windows 7 VM in VMWare Fusion. It all works, even the USB programmer.

Side question:  Making an array of FPGAs, an array of arrays, aka a bigger array.  Anything wrong with doing that to get bigger FPGAs for less money?  (comparing Logic Blocks per dollar)

The interconnect between the various FPGAs will kill you. They'll kill you because of PCB routing congestion, they'll kill you because I/O speeds are usually slower than internal clock rates (use the PLL to bump you clock up), they'll kill you because of power consumption, they'll kill you because programming the FPGAs with JTAG means either a large JTAG chain or multiple JTAG connectors.

[aandrew]

It it extremely hard to get it running even on Linux, where it is officially supported.

Why do you say that? Perhaps I can help shed some light. I have the ICE40 stuff working on an Ubuntu VM that I'm accessing using xrdp (so I can just use any RDP client, my fave is Jump Desktop). The GUI works pretty much exactly the same as on Windows (and is considerably more archaic than the more popular Lattice Diamond or whatever they call the latest incarnation for their MachXO devices).

What I wish was for better command line documentation. I've been trying to get a decent set of CLI commands so I can do away with the GUI and just build with a small Makefile.

[ataradov]

and is considerably more archaic than the more popular Lattice Diamond or whatever they call the latest incarnation for their MachXO devices

Ok, I was talking about Lattice Diamond. I did not know they had a different IDE for ICE40. But even if it is the case, the original question was about Diamond.

And unlike Altera and Xilinx stuff, you have to work to make it work.

[ataradov]

Well, I just tried to install iCEcube2 and it fails to recognize the host ID. Their official FAQ suggests renaming networking interface to "eth0", since that what is hard coded in their license check. And the solution is to edit udev rules to rename the interface. F that. They can keep their quality enterprise software.

Why they insist on using that abomination of a license manager for free licenses is beyond me.

[NiHaoMike]

Micah Elizabeth Scott did a bit of ICE40 FPGA programming on a Mac, probably worth checking exactly how she did it.

[ataradov]

Micah Elizabeth Scott did a bit of ICE40 FPGA programming on a Mac, probably worth checking exactly how she did it.

Yes, I've seen the streams. I'm waiting for the CrowdSupply campaign for that board she used. I know I can probably use some standard dev kit, but I'm in no hurry at the moment, but I will definitely investigate that toolchain.

[Bassman59]

Why they insist on using that abomination of a license manager for free licenses is beyond me.

That applies to ALL OF THE FPGA VENDORS.

[ataradov]

That applies to ALL OF THE FPGA VENDORS.

I'm not sure if Intel has removed it or jut made it totally seamless, but Quartus just works for me. I know I had to deal with it in the past with Xilinx as well, and when time came for a new FPGA project, I just went with Altera.

[Bassman59]

That applies to ALL OF THE FPGA VENDORS.

I'm not sure if Intel has removed it or jut made it totally seamless, but Quartus just works for me. I know I had to deal with it in the past with Xilinx as well, and when time came for a new FPGA project, I just went with Altera.

I have not looked at Altera in a couple of years, so I don't remember. Maybe Intel "Saw the light!" I've been in Microsemi (now Microchip) land for a couple of years so I haven't kept up on Brand A and Brand X.

Here's a funny thing. The Microsemi fitter takes a long time to chug through my current design, and to get it to meet timing i need to do the multiple-runs thing. I thought it might be interesting to run the tools on Linux to see if there was any significant difference in performance. My computer, a Dell quad Core i7 of some sort, already had a spare hard drive inside that I was using for backup, so I decided to install the most recent CentOS (recommended by Microsemi) on it. That went OK, and I installed the Microsemi tools and tried to run them. Oh no, you need to download and install all of these other depedencies! Was I asked about installing those dependencies when I installed Linux? Not that I remember! Are these dependencies easy to install? Of course not!

So I finally got the dependencies installed and went to launch Libero. Oh shit, forgot about the license nonsense. Get this: in order to run their free software, it wanted to me to install a license server.

That's when I gave up and rebooted back into Windows 7.

I still don't understand why these companies all keep fucking with trying to get their software to run on Linux when they could choose a much more stable Unix variant that most people agree "just works" -- macOS.

[aandrew]

Well, I just tried to install iCEcube2 and it fails to recognize the host ID. Their official FAQ suggests renaming networking interface to "eth0", since that what is hard coded in their license check. And the solution is to edit udev rules to rename the interface. F that. They can keep their quality enterprise software.

Yes, that is a problem. The Great Network Interface Renaming threw a lot of wrenches into the gears.

What I did was to disable the new system. Basically adjust the kernel command line parameters to include "net.ifnames=0" and "biosdevname=0". For the GRUB bootloader, you find GRUB_CMDLINE_LINUX in /etc/default/grub.conf and change it thusly:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

and run update-grub and then finally reboot.  You can also do it through udev rules but this works well enough for me. It's not intuitive, but then again hardly anything about Linux is. :-)

Why they insist on using that abomination of a license manager for free licenses is beyond me.

licenses for dev software is one of the most stupid things I've ever run across in this industry. Most of the tools are free anyway, so why bother with the licenses? paying for IP cores and licensing it to the PC is perhaps a good argument, but is still easy to work around and just causes trouble due to bad assumptions such as "the first network interface is always named eth0". 

[ataradov]

Yes, that is a problem. The Great Network Interface Renaming threw a lot of wrenches into the gears.

Only in the gears of poorly written software.

I know how to change the name of the interface, I'm just not going to do that.

[mr_darker]

Thanks for the advice!  I just decided to stop being lazy and finally invest time to get my netbook that's got ArchLinux on it going and usable, so it's running Diamond now.

Side question:  Making an array of FPGAs, an array of arrays, aka a bigger array.  Anything wrong with doing that to get bigger FPGAs for less money?  (comparing Logic Blocks per dollar)

If you have what is essentially a monolithic design, that you intend to partition between FPGAs, you are creating a world of hurt for yourself! Whilst what you describe is technically feasible, you will have to partition your design into independent chunks with a minimal interface between chips which you define at the time of board creation (or at least define the number of pins and IO standard at board creation time). In addition it means that the partitions of your design have to have a roughly even split in terms of resource usage, which often is not the case. Not to mention the fact that you now have multiple designs to implement, multiple designs to meet timing on, multiple chips to program, each time you change your code, making your iteration time vastly greater. Assuming that you value your time, then you are likely better off buying the larger FPGA.

Having said that, if you have the same design which you want to replicate multiple times (one instance per FPGA) then the approach you describe makes a lot of sense. It could also make sense if your design consisted of several largely independent blocks with a simple and well defined interface. (E.G. You have a video processing system, which feeds into a video encoder, and the interface between the two is just a pixel stream). You would likely be best off using a high speed serial interface (with an FPGA that has appropriate gigabit transceivers)  between the FPGAs if you need high data throughput.

There is no single chip that comes anywhere near the amount of hardware that I am aiming for.  Currently the plan is to make little "modules" containing like 25 or 100 FPGAs on each, and some ROM on the other side of each FPGA (saves on BGA routing if the pitch is similar, just going straight through).  This scales the hardware and ROM equally.  I want to make a linux kernel set up for FPGA computing, no processors.  As far as I know, FPGA computers are only novelty video game systems, the only serious attempt i've found is COPACOBANA (which uses multiple FPGAS btw) which is meant for encryption cracking and doesn't really count as it has no operating system.  I know it's a massive project likely, years long probably, and it's gonna be way more expensive in hardware to match a CPU.  But ima do it anyways, if I can.  Rather than allocating time on a processor core for processes, I intend to make a kernel that allocates HARDWARE for processes (and probably needs a hardware equivalent of virtual memory mapping).  Starting out i've selected a FPGA that has nonvolatile-instant-on-background-reconfigurable configuration memory, as this takes care of a lotta FPGA issues, eventaully tho there's an FPGA that I'd like to migrate to that doesn't have these features, but has the most bang per buck in terms of hardware.  A processorless reconfigurable computer is what i'm aiming for, bigger things later lol.
Learned linux programs are mostly all distributed with source code, which makes me feel like there's a way to compile everything in a way optimized for FPGAs, rather than run a softCPU for anything that wasn't designed to be run on an FPGA.  "We'll get there when we get there"

The FPGA i'm starting out with is the Lattice MachXO3L (the version with flash memory isn't a good fit due to the 100k cycle life of the flash memory, it'd not last long being used as ram in a computer).  Eventually, I feel switching to their ECP5 chips would offer the most bang for your buck, aka, make it the cheapest to scale the computer's power up, imagine there's no limit on how much power we need, so you just want the cheapest.

Knowing little about FPGAs, having never programmed one, am i horribly wrong anywhere?  Any major issues i'm not seeing?

[ataradov]

There is no single chip that comes anywhere near the amount of hardware that I am aiming for.

Are you sure? 100 of MachXO3L will probably be covered by a single high-end Xilinx device.

Learned linux programs are mostly all distributed with source code, which makes me feel like there's a way to compile everything in a way optimized for FPGAs, rather than run a softCPU for anything that wasn't designed to be run on an FPGA.

This is a strange statement. Even if you have the code, you can't just magically compile for "FPGA". You still need something that will sequentially execute instructions, since that's what high level programming languages map to. Xilinx is trying some  compile C into hardware thing, but it is a very different story.

Knowing little about FPGAs, having never programmed one, am i horribly wrong anywhere?  Any major issues i'm not seeing?

Make a board with just one and play with it first. You will then have realistic understanding if what FPGAs can and can't do.

Realistically you can interconnect 6-8 high end FPGAs on a single boards, but they are already sold a finished products, and it is cheaper to buy one.

With a 100 chips you will go mad ensuring signal integrity and writing constraints files.

[mikeselectricstuff]

licenses for dev software is one of the most stupid things I've ever run across in this industry. Most of the tools are free anyway, so why bother with the licenses?

My guess is that they have to pay for at least some of the components - just look at how many different names appear in copyright messages when you do a compile.

[rstofer]

As far as I know, FPGA computers are only novelty video game systems, the only serious attempt i've found is COPACOBANA (which uses multiple FPGAS btw) which is meant for encryption cracking and doesn't really count as it has no operating system. 

You need to take a step back and truly understand what you get in an FPGA.  You get logic, boxes and boxes of logic chips.  Millions of flip-flops and a similar number of multiplexers.  You get no 'computer' at all!  If there is to be some kind of general purpose computing, you need to create a 'soft core' - some kind of CPU.

There are some CPU cores that will run Linux and, of course, there are Z80 cores that will run most of the early arcade games.  And 6502 cores and lots of PDP-11 projects.

Starting out i've selected a FPGA that has nonvolatile-instant-on-background-reconfigurable configuration memory, as this takes care of a lotta FPGA issues,

Like what?  The non-volatile chips tend to be small, the bigger chips all use some form of EEPROM storage for the bitstream.  In addition, the EEPROM can contain initial memory contents and, in some cases, multiple images.

Knowing little about FPGAs, having never programmed one, am i horribly wrong anywhere?  Any major issues i'm not seeing?

In my view, you are attributing capabilities to FPGAs and compilers that simply don't exist.  We can use C to describe hardware (I have never done it, I use VHDL) but when we want to start running application code, there needs to be some kind of processor to run it.  Unless the application can be fully described in hardware.  Maybe it can...

[NiHaoMike]

I still don't understand why these companies all keep fucking with trying to get their software to run on Linux when they could choose a much more stable Unix variant that most people agree "just works" -- macOS.

Because you want a nice machine to run that sort of software, preferably one that's not crazy overpriced for how well it performs.

[james_s]

I still don't understand why these companies all keep fucking with trying to get their software to run on Linux when they could choose a much more stable Unix variant that most people agree "just works" -- macOS.

Because you want a nice machine to run that sort of software, preferably one that's not crazy overpriced for how well it performs.

While Macs are expensive for what you get, the cost of the PC is peanuts compared to the cost of the engineer developing the HDL so I doubt the cost is really an issue. More likely it's a historical matter, FPGA development was being done on Windows PCs and Unix workstations back when the Mac was a niche product used in schools and graphic arts. By the time we had a Unix-based Mac OS, standard PC hardware running Windows or Linux was already entrenched. You don't see a lot of Macs in any kind of hardware design, there isn't much CAD/CAM/EDA/FPGA stuff for MacOS and with the direction Apple is going, I don't see that changing any time soon. My work issued laptop is a Macbook Pro and it's a nice machine for what I use it for, however to call it "Pro" is a joke. With the RAM and storage soldered to the motherboard, the only ports on it are USB-C, it wouldn't be my choice for hardwre development either. Apple is focused almost entirely on mobile devices.

[rstofer]

Apple used to make it darn near impossible to develop software for their machines.  Back in the very beginning, if you wanted to write code for the brand new Mac 128k, you had to get their permission and buy a Lisa machine to do it.  And a Lisa cost $10,000 in those dollars.  So, a lot of us lost interest and have never came back.  To this day, I don't and won't own Apple products.

I don't know how software development for Apple is today.  I know it is a little awkward for iOS but it is possible to independently develop software.

macOS has about 10x the percentage of desktops (nearly 14%) as Linux (about 1.6%) so, all else being equal in terms of stumbling blocks, you would think that everybody would pick macOS for their second release and just kiss off Linux altogether.  At 84%, Windows is a given!

http://gs.statcounter.com/os-market-share/desktop/worldwide/

But I don't know if 'all else being equal in terms of stumbling blocks' applies to macOS but it represents 10x more machines than Linux.

[james_s]

The Mac 128k came out nearly 35 years ago, it's a bit silly to compare current Apple products with that, the current offerings have nothing in common with the 68k generation. There is no particular challenge to developing software for OSX, it's BSD Unix under the skin afterall. I think the percentage of Linux desktops in the hardware design field is probably quite a bit higher than in elsewhere in tech though. Originally most of the FPGA software was written for Unix workstations and Linux started taking over that area before OSX was a thing. The software was ported to Windows because the vast number of Wintel machines out there made this an obvious choice.