FPGA selection recommendation

Started by Piotr Wyderski April 14, 2018
I need an FPGA chip with about 100 GPIO pins and capable of hosting a 
CPU with an existing Linux port, mainly to run a web server. I would
like to connect it to a 16-bit 	DRAM, so there should exist a memory 
controller with this feature, either a hard macro or a soft IP core.
There should also be a fast ethernet MAC. Nothing fancy, but:

1. This is for a small non-profit project, so the IP cores must be free.
Paying O(500) bucks for a Nios/MicroBlaze license is out of the 
question. Ditto about the MAC. As far as I know, neither Xiling nor
Altera have a free/very cheap licensing option for non-profit 
applications, so the most obvious way is a no-go. Are there any
*reasonable* open CPU/MAC/memory controller cores to use instead?
$1000 per year is extremely cheap for commercial purposes, but
a showstopper for hobby applications, where you can buy a bucket
of STM32-class chips.

2. The chip must be hand-solderable and introduce no thermal strain 
problems. This excludes the BGA/chip scale packages and leaves only
the QFP variants on the table. I don't care about the superior
signal integrity benefits of the leadless packages, 50MHz is more
than needed. But this requirement kills Zynq/Cyclone V, otherwise
a perfect choice for this application. The PCB must be manufacturable
in a cheap PCB shop and they can often do at most 4 layers.

3. The FPGA must be SRAM-based.

4. I don't want the SOM modules.

The older Spartan 3Es (3S500E) or equivalent Cyclone 3 in PQFP208
would have been aa good choice here, but I seem to be blocked by
the licenseing issues. I'd gladly stick to these platforms, but
could you please recommend me any robust open-source IP cores
which fit inside this class of FPGAs?

	Best regards, Piotr

On Saturday, 14 April 2018 17:06:42 UTC+2, Piotr Wyderski  wrote:

> I need an FPGA chip with about 100 GPIO pins and capable of hosting a > CPU with an existing Linux port, mainly to run a web server. I would > like to connect it to a 16-bit DRAM, so there should exist a memory > controller with this feature, either a hard macro or a soft IP core. > There should also be a fast ethernet MAC. Nothing fancy, but: > > 1. This is for a small non-profit project, so the IP cores must be free.
<snip> I'm playing with the Terasic DE1-SoC (sporting a dual core ARM aside a mid-range Cyclone V), pretty cheap and pretty cool. But in hindsight I should have gone for the one with no OpenCL support but the HDMI output instead... I mean, I thought OpenCL would be my way, as I was coming from pure software, then, after purchasing my board, I have realised the Intel OpenCL SDK isn't free and not even cheap. After learning the A of the ABC of digital design in Verilog, I am now playing with the Intel HLS compiler... A lot of (free) IP cores, and indeed there is a free toolchain: not possible to go supertech with it, such as you cannot do explicit placement or project partitioning, but otherwise no limitations. -- That said, I am seeing a lot of people around here rather talking of Xilinx, but I have no experience with those. Julio
Julio Di Egidio wrote:

> I'm playing with the Terasic DE1-SoC (sporting a dual core ARM aside a mid-range > Cyclone V), pretty cheap and pretty cool.
But this is a ready-made FPGA development kit and one of the essential aspects of my projects is to create a working system from scratch, including custom board design and hand soldering by the advanced hobbyists. I don't want it to be pure Arduino-style software massaging.
> That said, I am seeing a lot of people around here rather > talking of Xilinx, but I have no experience with those.
Because Xilinx and Altera are the elite in this business. They have just forgotten about the hobbyists and charge them the same way as their industrial clients, despite the fact the hobby projects generate zero income. There used to be some exceptions for students, but not all hobbyists are students and even $500 for a yearly NIOSII license is more than the entire hobby budget. Same with MicroBlaze. The price is way too low for professional purchases and way too high for hobbyists, hence the problem. I don't understand this strategy of deterence, but it clearly works. Anyway, it's not my point, the manufacturers can set the price of their tools as high as they wish. I accept the situation and just ask: what cores/chips should I use instead? Best regards, Piotr
On Saturday, 14 April 2018 18:30:45 UTC+2, Piotr Wyderski  wrote:
> Julio Di Egidio wrote: > > > I'm playing with the Terasic DE1-SoC (sporting a dual core ARM aside a
mid-range
> > Cyclone V), pretty cheap and pretty cool. > > But this is a ready-made FPGA development kit and one of the essential > aspects of my projects is to create a working system from scratch, > including custom board design and hand soldering by the advanced > hobbyists. I don't want it to be pure Arduino-style software massaging.
I have no idea why you'd call it Arduino-style, but never mind, to each his requirement.
> > That said, I am seeing a lot of people around here rather > > talking of Xilinx, but I have no experience with those. > > Because Xilinx and Altera are the elite in this business. They have > just forgotten about the hobbyists and charge them the same way as their > industrial clients, despite the fact the hobby projects generate > zero income.
I don't see how you'd say that either, ~250 bucks for a development and prototyping board, plus indeed an industry level mind-set (not everything is so polished in fact, but that's another story) seems pretty cool to me. Anyway, I do come from the industry... Thanks for the feedback and good luck, Julio
On Sat, 14 Apr 2018 17:06:37 +0200, Piotr Wyderski wrote:

> I need an FPGA chip with about 100 GPIO pins and capable of hosting a > CPU with an existing Linux port, mainly to run a web server. I would > like to connect it to a 16-bit DRAM, so there should exist a memory > controller with this feature, either a hard macro or a soft IP core. > There should also be a fast ethernet MAC. Nothing fancy, but: > > 1. This is for a small non-profit project, so the IP cores must be free. > Paying O(500) bucks for a Nios/MicroBlaze license is out of the > question. Ditto about the MAC. As far as I know, neither Xiling nor > Altera have a free/very cheap licensing option for non-profit > applications, so the most obvious way is a no-go. Are there any > *reasonable* open CPU/MAC/memory controller cores to use instead? > $1000 per year is extremely cheap for commercial purposes, but > a showstopper for hobby applications, where you can buy a bucket > of STM32-class chips. > > 2. The chip must be hand-solderable and introduce no thermal strain > problems. This excludes the BGA/chip scale packages and leaves only > the QFP variants on the table. I don't care about the superior > signal integrity benefits of the leadless packages, 50MHz is more > than needed. But this requirement kills Zynq/Cyclone V, otherwise > a perfect choice for this application. The PCB must be manufacturable > in a cheap PCB shop and they can often do at most 4 layers. > > 3. The FPGA must be SRAM-based. > > 4. I don't want the SOM modules. > > The older Spartan 3Es (3S500E) or equivalent Cyclone 3 in PQFP208 > would have been aa good choice here, but I seem to be blocked by > the licenseing issues. I'd gladly stick to these platforms, but > could you please recommend me any robust open-source IP cores > which fit inside this class of FPGAs? > > Best regards, Piotr
100 GPIO + CPU + Ethernet + DRAM + Linux in non-BGA? Not likely I have not done an exhaustive search in a while but 144pin XC6SLX9 will give you 102 IO pins. You can get a Altera EP1C12Q240C7N in a QFP-240 with 173 IO. If this is a learning tool to program a FPGA I can see the need but I scoped out FPGA vs a SOM or Raspberrry PI Compute module and the latter always won. Even in quanity I cannot compete price wise with a SOM or Rpi CM. A XC6SLX9 will run you 16 bucks from Digi-Key and the EP1C12Q240C7N is $48. I dont think you will have enough resources in the FPGA to do a soft cpu, dram controller and ethernet block plus some gpio pins. You can buy a CM3 for $30. You will be hard pressed to make a board, get the FPGA, config memory, DRAM, Phy, etc for 30 bucks unless you are thinking mega quanity. No way you are gonna hand solder enough boards to get in that range. Granted you will have to have a carrier board/socket for the CM3 or SOM so that adds to the $30 cost. A uC with maybe a SPI or I2C port expander would give you more horse power and still be hand solderable. -- Chisolm Republic of Texas
Julio Di Egidio wrote:

> I have no idea why you'd call it Arduino-style, but never mind, to each > his requirement.
By "Arduino-style" I mean buying a ready-made board and mixing existing code snippets without deeper understanding of the physical aspect of the device or even of the problem domain. I want to show how hard is to make such a board, solving all the problems on the way, and that it is finally doable. Anybody can buy any kit without understanding of the effort put into its creation and claim to be a hacker. My goal is to provide much deeper understanding of its *construction*, not *use*. IMHO one should be allowed to buy such a kit only after succesful completion of a DYI board. I mean, the kits are for professionals, because they offer significant development time (and money) saving.
> I don't see how you'd say that either, ~250 bucks for a development and > prototyping board, plus indeed an industry level mind-set (not everything > is so polished in fact, but that's another story) seems pretty cool to me. > Anyway, I do come from the industry...
I also come from the industry, but a different one. And it is perfectly normal to pay for the tools you earn your money with. Even as much as $50k per seat per year, been there, done that. But if a guy just wants to play with the technology involved and from the very beginning it is clear that he will make no money on that (come on, he wouldn't even afford the EMI testing required before product introduction to the market), it's not very wise to repel him with industrial-level charges, because you're most likely repelling your future user or at least a friendly advocate. This thread is an example of this situation, the message is: what should I use (i.e. learn and get used to) *instead of* Quartus/ISE. I don't have to understand this marketing policy, but I can certainly adapt to it. Professionally I'd probably get something from the Ultrascale line and wouldn't care about the complexity of the proper BGA package soldering, because it would be done by a machine anyway, a 10 layer board wouldn't be a problem because they are affordable in quantity. Fine, but it is not a professional application. And it seems that creating a simple web server on a custom FPGA board is not doable using the proper, vendor-approved tools, purely because of licensing costs. Crazy, but true. :-/ So the only option here is to get something working from opencores, but I can't say much about the quality of their particular implementations, hence the question. I need a GCC-supported CPU, a memory controller and a MAC. The budget is $10. :-) Best regards, Piotr
Piotr Wyderski <peter.pan@neverland.mil> wrote:
> I need an FPGA chip with about 100 GPIO pins and capable of hosting a > CPU with an existing Linux port, mainly to run a web server. I would > like to connect it to a 16-bit DRAM, so there should exist a memory > controller with this feature, either a hard macro or a soft IP core. > There should also be a fast ethernet MAC. Nothing fancy, but:
What's the application that needs an on-FPGA CPU, rather than a CPU with attached FPGA? Could you use an existing CPU instead? eg a Beaglebone with FPGA wired to the PRU pins? Anything with a 16 bit DRAM (SDRAM?) isn't going to be very fast.
> 1. This is for a small non-profit project, so the IP cores must be free. > Paying O(500) bucks for a Nios/MicroBlaze license is out of the > question. Ditto about the MAC. As far as I know, neither Xiling nor > Altera have a free/very cheap licensing option for non-profit > applications, so the most obvious way is a no-go. Are there any > *reasonable* open CPU/MAC/memory controller cores to use instead? > $1000 per year is extremely cheap for commercial purposes, but > a showstopper for hobby applications, where you can buy a bucket > of STM32-class chips.
OpenRISC might be worth a look. There are some RISC-V cores but nothing I've seen stable enough to use for real Linux work. On all of these the Linux ports are a bit sketchy (you'll be managing your own toolchains and OS builds - no apt-get install here). For Linux you'll need an MMU, which will eat BRAMs. What storage will you be using for the OS and data? To save area, perhaps use an external ethernet MAC chip? You'll need an external chip for the PHY anyway. By the end of all this, you've built yourself a pretty cumbersome Linux system. I'd suggest trying to use a hard CPU in some way instead.
> 2. The chip must be hand-solderable and introduce no thermal strain > problems. This excludes the BGA/chip scale packages and leaves only > the QFP variants on the table. I don't care about the superior > signal integrity benefits of the leadless packages, 50MHz is more > than needed. But this requirement kills Zynq/Cyclone V, otherwise > a perfect choice for this application. The PCB must be manufacturable > in a cheap PCB shop and they can often do at most 4 layers.
The cheap Altera boards on ebay seem to be QFP Cyclone II and Cyclone IV, but they aren't very big.
> The older Spartan 3Es (3S500E) or equivalent Cyclone 3 in PQFP208 > would have been aa good choice here, but I seem to be blocked by > the licenseing issues. I'd gladly stick to these platforms, but > could you please recommend me any robust open-source IP cores > which fit inside this class of FPGAs?
Cyclones should build with the free Quartus Lite (formerly Web edition). I think NIOS and other bits of basic IP should be included, but I haven't confirmed that. Theo
Joe Chisolm wrote:

> 100 GPIO + CPU + Ethernet + DRAM + Linux in non-BGA? Not likely
The number of GPIOs is just a rough estimate and not all of them must be created equal. There are dirt-cheap 16-bit SPI expander chips. The CPU and Linux running capabilities are not related to the specific packaging, it's just a legal (licensing) problem. On the market there are still the old Cyclones in PQ240, many chips from Altera and Xilinx are available in PQ208 and a horde of them is in PQ144. But even if you solder it succesfully to the board, you can't do much with it only because of the legal wall. I don't want to persuade Xilinx/Altera their policy is wrong, I don't even want to discuss it, as it is a pure waste of time of all the involved parties. I just consider this situation to be a law of nature and adapt to it by avoiding the quality implementations the vendors don't want to share. So I am open to the alternatives (Microsemi, Lattice, open-source IP cores, legacy chips).
> If this is a learning tool to program a FPGA I can see the need > but I scoped out FPGA vs a SOM or Raspberrry PI Compute module and > the latter always won.
Exactly, but the purpose is to learn building such a system from scratch, including PCB design, and it is beyond hobby capabilities to re-create even an RPi.
> Even in quanity I cannot compete price wise > with a SOM or Rpi CM.
It's not about competition, it's about learning this particular design process. Don't want it, don't play it, it has never been aimed at stealing the market share of the (good!) solutions you mention.
> No way you are gonna hand solder > enough boards to get in that range.
But it's not the goal. This price battle has already been lost, I'm perfectly aware of it. The goal is to build a decent, working FPGA system from the first principles.
> A uC with maybe a SPI or I2C port expander would give you more horse > power and still be hand solderable.
But there are no PLD resources, which are the main point here. The only solderable CPU with PLD I know of is PSOC5LP in TQ100, but it is way too small to host a Linux port and doesn't have a MAC on board. Best regards, Piotr
Piotr Wyderski <peter.pan@neverland.mil> wrote:
> But it's not the goal. This price battle has already been lost, > I'm perfectly aware of it. The goal is to build a decent, working FPGA > system from the first principles.
If that's the goal, you have options: 1. Use a ready-made FPGA board (with a BGA part) 2. Use a system-on-module and your own carrier 3. Use separate CPU and FPGA chips 4. Be a microcontroller, don't run Linux If you've discounted those, you've constrained the problem so much that the only solution to your constraints is the empty set. Theo
Theo Markettos wrote:

> What's the application that needs an on-FPGA CPU, rather than a CPU with > attached FPGA? Could you use an existing CPU instead? eg a Beaglebone with > FPGA wired to the PRU pins?
This is an option, but the CPU must be capable enough to run a decent OS, which means a fast ARM with MMU, which most likely means BGA again. So then it is better to use a Zynq/Cyclone V with such an ARM on chip.
> Anything with a 16 bit DRAM (SDRAM?) isn't going to be very fast.
The performance doesn't have to be stellar.
> OpenRISC might be worth a look. There are some RISC-V cores but nothing > I've seen stable enough to use for real Linux work. On all of these the > Linux ports are a bit sketchy (you'll be managing your own toolchains and > OS builds - no apt-get install here).
The compiler toolchain must be existing and stable, the hobbyists will not debug their custom GCC ports.
> What storage will you be using for the OS and data?
Probably a QSPI FLASH, maybe an SDHC card.
> By the end of all this, you've built yourself a pretty cumbersome Linux > system. I'd suggest trying to use a hard CPU in some way instead.
Is there anything solderable and still capable of running a pretty heavy OS?
> Cyclones should build with the free Quartus Lite (formerly Web edition). I > think NIOS and other bits of basic IP should be included, but I haven't > confirmed that.
There are evaluation versions of the mentioned IPs, but they work as long as the JTAG is connected. You'll not create a stand-alone device this way. Best regards, Piotr