What is the benefit in learning ARM Cortex and FPGA's? - Page 1
Forum section: electronics / general

author: Arrow
author_rank: Contributor
timestamp: February 01, 2013, 01:14:23 pm
content: Hi all,I was planning to learn ARM cortex and FPGA, but I would like to know what is the benefit of learning those.Right now I am using ATmel's 8051 AT89LP single cycle 20Mips. and Silicon LAbs C8051F120 /020 100Mips and AVR Atmega128.They are all 8 bit processors. May be some one can give me some advice.

author: jerry507
author_rank: Regular Contributor
timestamp: February 01, 2013, 03:19:18 pm
content: FPGAs IMO are pretty specialized devices, so while you won't find yourself using them all the time in a commercial application they're certainly a different way of thinking. Well worth the time spent. Plus you can do some things you'd never do with a micro.I use ARMs in various products, and they really allow you to use a variety of features that people demand today. USB, LCDs, ethernet or wireless. You can do all these things on less powerful processors too, but if you want to use a combination or ALL of those you really need to set up in horsepower. ARM is also a bit of a mindset shift because you're going to learn a core and a general style of how the peripherals are partially setup but obviously peripherals will differ manufacturer to manufacturer.You've got a wide range of processors, but the more processors you know the easier it is to pick new ones up. Well worth it if you need to jump around as I do in my job.

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2013, 06:38:59 pm
content: Actually the ARM processor itself is not very difficult. Its a RISC CPU so it has very few instructions. In the Cortex series they actually simplified things a lot in comparison to the ARM7TDMI based controllers. Its no more complex than an 8 bit controller. The only difference is that you'll find more powerfull and complex peripherals.

author: Arrow
author_rank: Contributor
timestamp: February 01, 2013, 07:48:16 pm
content: Does it has an completely new assembly language or are they like the AVR and the MCS51?

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 01, 2013, 08:58:47 pm
content: The ARM instruction set (I"m not talking about the Thumb subset) set is absolutely wonderful and a joy to work with. Three operands, conditional execution of every instruction, the barrel shifter you insert in the datapath on most instructions etc.Much nicer and better thought out then both AVR and MCS8051 IMO.But I also think programming in assembly is just silly nowadays for any project of any serious size. You'd better learn C first.

author: nctnico
author_rank: Super Contributor
timestamp: February 01, 2013, 10:53:10 pm
content: Exactly. And unlike any other microcontroller I know off you don't need any assembly language to get an ARM Cortex Mx controller to run software written in C. Even the interrupts don't need special care or a stub in assembly.

author: Arrow
author_rank: Contributor
timestamp: February 01, 2013, 11:37:22 pm
content: What about time critical processes?

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 01, 2013, 11:43:14 pm
content: Possible exception, yes.

author: ve7xen
author_rank: Super Contributor
timestamp: February 02, 2013, 12:11:52 am
content: Quote from: nctnico on February 01, 2013, 10:53:10 pmAVR and MSP430 don't require any asm startup code either...In fact I find themmucheasier to build for, since you can just gcc a C source that will work. These Cortex chips require special linker scripts, startup code, and some other stuff I still have trouble setting up properly with open-source dev tools. The $$$$ toolchains work out of the box, of course.

author: joelby
author_rank: Frequent Contributor
timestamp: February 02, 2013, 02:03:52 am
content: A couple of good applications for FPGAs are:Interfacing high speed devices (ADCs, DACs, Camera Link, transceivers), particularly those with differential (e.g. LVDS) interfaces and wide interfaces, or devices with many (tens to hundreds) of high speed I/Os.High speed and low latency data conversion and signal processing, such as real-time video, network data processing, software defined radioParallel processing of multiple data streamsMost of these sorts of applications are difficult or impossible with a regular microcontroller, but the applications tend to be a bit more specialised.

author: Harvs
author_rank: Super Contributor
timestamp: February 02, 2013, 03:07:06 am
content: Quote from: Arrow on February 01, 2013, 01:14:23 pmTo program FPGAs, yep there's a heap of learning involved. First learning a HDL, then learning a tool chain, then learning a specific device family (to make proper use of its features.)With ARM Cortex Mx, to be honest it's just another core that you'll program with C/C++. Same story really as PIC32's MIPS etc. There are some interesting aspects of it to learn, but none of it is that different to anything else.However, tool chains can be a right PITA. Atmel and PIC largely shield their customers from it by given away a free (largely working) IDE with compiler etc. Unless you've got money to burn on a commercial toolchain (e.g. for a commercial project) pulling together an Eclipse tool chain with gcc compiler for ARM is a bit like pulling teeth. I'm sure some will disagree, but I don't find spending many hours trying to sort out those sorts of issues fun, interesting or in any way educational.PIC32 isn't a bad processor to learn either, with the MIPS core.

author: nctnico
author_rank: Super Contributor
timestamp: February 02, 2013, 12:25:37 pm
content: Quote from: ve7xen on February 02, 2013, 12:11:52 amI don't know about the AVR but the MSP430 sure needs assembly to get started. The fact that this is well hidden by the compiler doesn't make it less true. A C program needs a valid stack pointer. The MSP430 has no way to do this other than setting up the stack pointer by assembly. The Cortex Mx however can setup the stack pointer from the interrupt vector table which can be defined at compile/link time. Oh, and every microcontroller needs link scripts. These are often well hidden by compiler makers but they are there.edit: to get linker scripts and startup code I just look for an example project which uses a similar controller and copy the linker script and startup code from there. The manufacturers have many examples on their websites so this is an easy route.

author: andersm
author_rank: Super Contributor
timestamp: February 02, 2013, 12:38:06 pm
content: Quote from: ve7xen on February 02, 2013, 12:11:52 amAVR/MSP430 GCC toolchains require startup code and linker scripts as much as any other version, the packaged versions you're using may just be better at hiding it.Quote from: Harvs on February 02, 2013, 03:07:06 amI've been getting into the PIC32 for a couple of project, and IMO unless there is a particular set of peripherals you need, there is no reason to even consider them. Compared to the Cortex-M they just feel clumsy and outdated, and carry baggage dating back to the first MIPS CPUs of the mid-80s. Having suffered with incompatible implementations for so much of its life, I can understand why MIPS stick so rigidly to their defined architecture, but does anyone outside the company care that you could theoretically write an operating system that ran on both a microcontroller and a supercomputer?In some ways the current PIC32MX feel like the old ARM7TDMI (eg. separate 32 and 16-bit instruction sets). The upcoming MIPS M14K-based chips will modernize the core slightly (mainly by introducing a new mixed 32/16-bit instruction set much like Thumb-2), but it still looks a far cry from the M3 and M4.

author: Harvs
author_rank: Super Contributor
timestamp: February 02, 2013, 01:35:40 pm
content: Quote from: andersm on February 02, 2013, 12:38:06 pmI don't think they're better than the ARMs out there as a chip, defiantly not. But, they come with an easy to use free toolchain (albeit with non-optimized compiler) that works, and decent documentation which I think if fairly important for someone starting out. Unfortunately I've wasted many hours dealing with toolchains for the STM32, different story if you've got $1k+ to throw at a toolchain.I guess the same reason as people are still using AVRs. Makes no sense from a processing power vs cost perspective, but it's very easy to get started installing the tool chain and there's reasonable documentation.

author: andersm
author_rank: Super Contributor
timestamp: February 02, 2013, 02:17:34 pm
content: Quote from: Harvs on February 02, 2013, 01:35:40 pmIt's only the shortcut flags (-O2, -Os etc.) that have been disabled from the free compilers. You can manually enter every compiler flag that a particular -O flag enables and get the same effect. And while it's excellent that Microchip support Windows, Linux and OS X, in practice I've found MPLAB X slow, buggy and unreliable. I had less problems setting up an ARM toolchain from scratch (selfbuilt GCC, OpenOCD etc.)

author: nctnico
author_rank: Super Contributor
timestamp: February 02, 2013, 02:53:34 pm
content: It depends on what your background is whether a toolchain is easy to setup or not. But there are lots of tutorials online to get up & running quickly. That is how I got started with ARM. Monkey see... monkey do...

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 02, 2013, 03:50:44 pm
content: Quotethe ARM is an '80s design too and it started out as a PC CPU, for the Acorn Archimedes (ARM2 at 8MHz). Lovely and extremely fast computer in those days. After the core got scaled up and (fairly recently) scaled down, and more or less took over the world. Often as an fairly invisible part of an ASIC like GPS chipsets.

author: andersm
author_rank: Super Contributor
timestamp: February 02, 2013, 04:09:26 pm
content: Quote from: jeroen74 on February 02, 2013, 03:50:44 pmARMv7-M, on the other hand, is a new design from 2006. ARM weren't afraid of breaking compatibility when designing what genuinely feels like a newer generation of embedded architectures.

author: Harvs
author_rank: Super Contributor
timestamp: February 03, 2013, 03:06:14 am
content: Quote from: nctnico on February 02, 2013, 02:53:34 pmWhen I relatively recently got started out (6 odd months ago), I found a number of tutorials. Problem was, they varied as to what version of compiler, openOCD and eclipse they used, and all of them were well out of date. It took a few hours of playing around and finding little bits of information on various sites to actually get something to compile with the current versions of everything. Defiantly wasn't a straight forward "follow the bouncing ball" arrangement (e.g. a tutorial would say to put a setting under a certain menu in Eclipse, but that menu structure was completely missing in the new version, and they'd re-named what the setting was now called.)My install is still very touchy with respect to debugging. Workable, but far from nice. Maybe I should take the time to learn the makeup tool chains better one day.

author: jerry507
author_rank: Regular Contributor
timestamp: February 04, 2013, 07:04:50 pm
content: Both the TI and Freescale ARMs that I've used both had startup asm code. Whether it was "necessary", I'm not sure but it was definitely there.Talking about ARM as a core is pointless. The ARM core is a small part of using any ARM processor especially if you're writing in C. There is a very different style to how peripherals are designed in an ARM processor and it can trip you up. When was the last time you had to turn on the clock to a port module in a PIC? The clocking systems in the ARMs are so much more complicated than a PIC (even the newer ones!) and this can lead to a lot of wasted time trying to configure a peripheral and finding out that you forgot to turn on the clock in SIM.ARMs are definitely a lot more COMPLICATED, which translates into time spent learning them. And unless you have an application that needs the power, I find working on the smaller chips moves faster and is generally easier. At that point too it's personal preference. I like pics much more than ARMs so if I don't need the ARM I go with what I like.

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2013, 08:07:41 pm
content: Quote from: jerry507 on February 04, 2013, 07:04:50 pmIt may be there as a legacy because they had the code for clearing the memory and copying the constants already on the shelf but this can be done from C as well (been there, done that).QuoteThe user manual of NXP's Cortex controllers describes exactly which clocks and power enables should be set to get a peripheral running at the beginning of every chapter describing a peripheral. IOW it doesn't have to be complicated with proper documentation.

author: Arrow
author_rank: Contributor
timestamp: February 04, 2013, 09:09:37 pm
content: Am I right if I say that ARM is more when you want to put an OS on a chip with GUI. And you want to control many peripherals.

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 04, 2013, 09:17:19 pm
content: Big ARMs yes, not the Cortex and ARM7-TDMI I'd say.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 07, 2013, 03:39:51 am
content: Quote from: nctnico on February 04, 2013, 08:07:41 pmYup.Code:void /* __attribute__ ((__interrupt__)) */ reset_handler() {extern int main();extern unsigned __data_start; /* start of .data in the linker script */extern unsigned __data_end__; /* end of .data in the linker script */extern unsigned const __data_load; /* initialization values for .data */extern unsigned __bss_start__; /* start of .bss in the linker script */extern unsigned __bss_end__; /* end of .bss in the linker script */unsigned const *src;unsigned *dst;/* copy the data segment initializers from flash to RAM... */src = &__data_load;for (dst = &__data_start; dst < &__data_end__; ++dst, ++src) {*dst = *src;}/* zero fill the .bss segment... */for (dst = &__bss_start__; dst < &__bss_end__; ++dst) {*dst = 0;}/* call all static construcors in C++ (harmless in C programs) */__libc_init_array();/* call the application's entry point */main();for(;;);}

author: kshitij
author_rank: Newbie
timestamp: February 08, 2013, 05:04:47 am
content: ARM (not ARM Cortex, just the ARM architecture in general) is the de-facto architecture of choice for most embedded appliances. Its market coverage is analogous to Windows's share of the OS market. So there you go; that should be the only motivation you'll ever need. I'm not sure about Cortex having as much share as ARM7TDMI, though (someone pls correct me here, if I am wrong). Maybe a couple more years of manufacturers spewing out Cortex-based multimedia appliances, and it'll be on the same footing.Quote from: Arrow on February 04, 2013, 09:09:37 pmFor the most part, yes. It is a CPU architecture specification (usually fabricated as a microcontroller by its licensees), and its primary targets (these days), commonly, do have a resident OS . However, it can be used just as easily as any other 32-bit microcontroller to target any embedded application without an OS. It has a harder learning curve, when compared to 8-bit micros like AVR ATmega's and PIC's.Quote from: Harvs on February 03, 2013, 03:06:14 amAh, yes, the GCC naming conventions.They have the following format,arch-vendor-(os)-(abi/eabi)The (Embedded-/)Application Binary Interface is generally not mentioned in toolchains targeting PC-based operating systemsSo for example:(1) x86_64-w64-mingw32 == x86_64 architecture(=AMD64)/w64 (=mingw-w64 as "vendor")/mingw32 (32 bit Windows API)(2) i686-pc-msys == i686 architecture (Pentium Pro or higher?, 32 bit)/ generic pc as "vendor"/ msys (windows implementation of linux shell)(3) i686-unknown-linux-gnu = i686 architecture (Pentium Pro or higher?, 32 bit)/ No vendor/ 32-bit GNU/linux systemAnd for embedded systems,(1) arm-none-linux-gnueabi == ARM Compiler/No Vendor/ Embedded Systems running Linux OS/ GNU EABI interface(2) arm-none-eabi == ARM Compiler/No Vendor/ bare-metal Embedded System without OS/ Standard ARM EABI interface(same as aboveexcept for the final binary file compatibility, though GCC folks try to be as compatible as possible)(3) arm-eabi == ARM Compiler/ Standard ARM EABI Interface == most likely, a vendor-only toolchain, a.k.a, specific only to vendor ARM CPU's and supporting only native apps. Android targeting toolchains used in-house by some mobile manufacturers tend to have this notation.Note that different vendors try their best to comply with the ARM EABI, but sometimes aren't adaptable with each other.There is a GNU EABI too, different from the ARM EABI (its the specification for the toolchain targeting an embedded system with a GNU/Linux resident OS, somewhat compatible with ARM EABI).This means that there can be arm-none-eabi and arm-none-gnueabi toolchains too. For the most part, GNU attempts consistency with the ARM ABI.Debian OS uses a different naming convention, so it might be like arch-(os)-(abi/vendor), e.g., i686-mingw32-pc, etc.FPGA's primary purpose was (and still is, for the most part) to bridge a gap between PLD's and ASIC's. They are meant to implement Physical Layer algorithmic constructs, albeit faster (and more expensive) than digital signal processors (DSP's). This is the biggest difference. They are used for physical layer apps requiring very high sample rates (such as prototyping a wireless transceiver which has a bandwidth of 100 MHz). Consider a typical multimedia embedded device,Wireless Signal ==> Radio hardware for downconversion==>Signal Processing on the received signal(ASIC's or DSP's) ==>Software/OS (could be running on an ARM Cortex...)An FPGA would prototype/replace the ASIC-based signal processing section since it requires very high sampling rates.So , if you intend to work on designing signal processing routines such as carrier recovery, adaptive equalization, modulators/demodulators for digital comms, FPGA's provide the fastest route to rapid prototyping. And as long as you have access to all this PHY-based IP, you can normally implement faster image & video processing routines on them. For eg; target recognition, feature extraction etc. FPGA vendors also provide microprocessor cores (like a PowerPC or even ARM) which can used to realize complete physical layer subsystems.The learning curve here is rather high (wasted two yrs of my MS being a lab rat). You need to learn about the target device specs , the EDA vendor toolchain, and how it integrates with other applications. As an example, I frequenty create my algorithms in Matlab/Coware SPW, export the VHDL code to Xilinx ISE to fine tune them, and finally design the system in Xilinx EDK using the VHDL code/IP I just created.This is why companies usually have a team which designs the RF subsystem for the radio part, a separate team designing the DSP part, and another team which works on the processor-based software aspect. Finally, when nothing works, we always blame the PCB guys claiming signal integrity issues, even though they drafted for the specs given

author: andyturk
author_rank: Frequent Contributor
timestamp: February 08, 2013, 05:52:55 am
content: Nice first post, kshitij!

author: Arrow
author_rank: Contributor
timestamp: February 08, 2013, 12:57:13 pm
content: Quote from: andyturk on February 08, 2013, 05:52:55 amFirst post with alot of knowledge!!! welcome!!!!Question:There are many companies that make ARM processors, which should I go for?

author: kshitij
author_rank: Newbie
timestamp: February 09, 2013, 01:38:57 am
content: Quote from: Arrow on February 08, 2013, 12:57:13 pmHonestly, use whatever works out best for you. There are so many variants from different companies out there, that if I suggest one, people will counter with a long list of their version of better chipsets.If possible, do try and get a cheap eval kit, and, a good book (quite a few of them show up on an "arm cortex" search on Amazon). I googled some EK's for you,1)http://www.arm.com/support/university/development-platforms/cortex-m3-development-platforms.php2)http://www.google.co.in/search?q=arm+cortex+olimex&aq=f&oq=arm+cortex+olimex3)http://microcontrollershop.com/default.php?cPath=154_170_3564)http://www.lpctools.com/evaluation.boards.kits.lpc13xx.cortex.m3.aspxGo for the cheapest one (unless, ofc, you're funded)Another option, get a free chipset sample from the manufacturer , and solder it onto a cheap header board (several can be found on Digikey ). If you're in college, see if some professor knows a local electronics dealer, or if he can get enrolled in a University program with manufacturers. I know Atmel & TI send some free kits for a University program affiliate (atleast in US).

author: TheDirty
author_rank: Frequent Contributor
timestamp: February 09, 2013, 02:10:06 am
content: I would definitely narrow down the selection to those manufacturers that are putting out cheap dev boards with debuggers and are targetting lower cost developers.You really have 3 selections for Cortex-M with cheap hobby focused or easy access development.Your main 2 are:NXP LPC has the LPCXpresso development boards. M3, M0, M4ST has the STM32 development boards. M3, M0, M4FBoth of these guys offer a decent selection both of basic development boards with their JTAG debuggers on board.You can also go TI, but the only thing they are running right now is the Cortex-M4F with the Stellaris Launchpad. Selection and availability is pretty scarce.

author: Marco
author_rank: Super Contributor
timestamp: February 09, 2013, 02:48:58 am
content: There's also Freescale Kinetis ... haven't got very far with the board, but this guy has :http://mcuoneclipse.com/Long term support, who knows ... but for now they are interesting boards/chips.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 09, 2013, 03:05:22 am
content: Quote from: kshitij on February 09, 2013, 01:38:57 amCheap is good.I've been using STM32 mcus in my projects mostly because their Discovery line of eval boards are pretty nice. The STM32VLDiscovery is less than $10 USD and gets you breadboard-ready hacking platform with on-board debugging that only needs USB for power. Throw in GCC, Open OCD and a few hours of your time, and you're up and running with ARM.The disco boards are cheap from ST, but the VL has a wimpy processor. The mcu that comes on the board only has 8K of RAM. Fortunately, ST processors are generally pin-compatible, so you can whip out your hot air gun, desolder the original chip and drop in a STM32F103RGT6 monster ($12 in single quantity) with 1M of flash and 96K of RAM.

author: westfw
author_rank: Super Contributor
timestamp: February 09, 2013, 05:23:49 am
content: QuoteThe AVR and MCS51 don't have the same assembly language. The ARM assembler is not particularly any more different than the differences between AVR and 8051. The most popular assembler for ARM (perhaps the only one?) is the Gnu Assembler, which has a lot of commonality even between different architectures (all the pseudo-ops are the same, etc.) OTOH, it's not my favorite assembler :-(QuoteI don't think I understand why that's important. It's almost possible on AVR; several AVR chip families initialize the stack pointer to appropriate values, and I've written avr-gcc programs where the only assembler "initialization" was setting up the "known zero" register, which is a compiler optimization that isn't strictly necessary.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 13, 2013, 05:42:22 am
content: Don't forget the Raspberry Pi, which is very powerful for its price. Also note that nearly all of the phones and tablets out there are also ARM based.

author: Neilm
author_rank: Super Contributor
timestamp: February 13, 2013, 06:54:09 am
content: Quote from: kshitij on February 08, 2013, 05:04:47 amI would also use FPGAs / CPLDs to bridge the gap between an embedded processor and a lot of interface circuits - for example a processor connecting to a bunch of switches, relays and ADCs. Either you have to buy a much more powerful processor to get the physical IO you want, or you put a small CPLD in to interface to all that and use your processor for some else.Neil

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2013, 08:05:29 am
content: Are you mad? A CPLD requires programming during manufacturing. Ditto for an FPGA although that could be part of the microcontroller firmware. Either way it adds way more costs than a bigger microcontroller. Not only for manufacturing but also for development.An FPGA or CPLD is only usefull if you need to handle a lot of data very fast.

author: Marco
author_rank: Super Contributor
timestamp: February 13, 2013, 08:36:45 am
content: Quote from: nctnico on February 13, 2013, 08:05:29 amice40 gives you more than 100 i/o for 5 bucks in singles ... if you really need a ton of i/o it can be interesting.

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2013, 10:17:42 am
content: Well, a bunch of 74HC595, TPIC6C595, 74HC165 connected to the SPI bus give you any number of I/O without having to route lots of lines across a board. And they are way cheaper per pin than a CPLD.

author: Marco
author_rank: Super Contributor
timestamp: February 13, 2013, 11:52:06 am
content: I don't care about CPLDs, I was talking about the ICE40 ... it is actually in the same range of price per pin.

author: jerry507
author_rank: Regular Contributor
timestamp: February 13, 2013, 04:47:52 pm
content: You're already programming a micro during manuf, what's one more device? That's a complete red herring.

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 13, 2013, 05:35:14 pm
content: It does add cost and one more thing to maintain. CPLDs usually do not have the same programming interface as the MCU used.I wouldn't use a CPLD for interfacing to slow I/O stuff like switches and relays.

author: nctnico
author_rank: Super Contributor
timestamp: February 13, 2013, 08:44:41 pm
content: Quote from: jerry507 on February 13, 2013, 04:47:52 pmOne more device means connecting a different programmer and waiting for it to be programmed. Secondly someone needs to write the 'code' for the CPLD, have meetings with the firmware programmers about the interface between the uC and CPLD and the CPLD just adds to the amount of code that needs to be documented, maintained, etc. So yes, using a CPLD adds a significant amount of costs to a product.

author: jerry507
author_rank: Regular Contributor
timestamp: February 14, 2013, 04:49:59 pm
content: I mentioned programming costs alone. It really doesn't cost that much more. The cost of 1 or more programmers, and a pretty small amount of time programming it. I'm not sure why you'd not be programming in a jig, in which case it doesn't even add time to hook it all up.I assume people are using CPLDs not because they want an IO expander, but because they want some dedicated logic. In that case using std logic is... well, stupid. The CPLD is compression of std logic, so if the design is simple enough to use std logic, use that. Otherwise use a CPLD.Stating the CPLDs are stupid ALL THE TIME is silly. They obviously have a place, and if it makes sense use one.

author: westfw
author_rank: Super Contributor
timestamp: February 15, 2013, 10:13:56 am
content: QuoteAlso, you can embed FPGA "code" inside your microprocessor object code, so you wind up with only one image to burn, and remove a specialty FPGA config device from the BOM.(don't get carried away. I yelled at someone (metaphorically speaking) when they complained that our utility for converting a binary to to a C uint_8_t array broke on something as large as a linux ISO...)

author: jeroen74
author_rank: Frequent Contributor
timestamp: February 15, 2013, 05:08:05 pm
content: Most FPGA don't need a speciality devices. Those Altera EPCS devices are way overpriced and can be replaced by a 25F80 for example for a fraction of the price.