RFC: ARM+FPGA tiny board

our

it

(ARM7TDMI

necessary

is

(application

can

for

core

programmers,

an

all.

I think the FPGA does separate it from most of the pack, though it is still not alone. The size is quite attractive, making it lean towards a powerful minaturized mobile application. However, the FPGA is not incredibly power-efficient; some applications might require all the flip-flops, but a low-power CoolRunner variation might be something to consider. They are quite inexpensive and can fit a surprising amount of logic, I have a four-axis (8 coil) bipolar microstepping translator and driver project that so far fits into 128. The processor itself would probably be able to handle many of the tasks you would use all the flip-flops for, anyway. The CPLD also won't need to be reloaded every power cycle.

I think you what need to do is identify your competitors. In this case, I think your main competitor is the Pocket PC series of devices, which get up to a full day's worth of battery life, have an integrated LCD controller and LCD, standard interfaces to memory and expansion cards, and with a 200MHz processor and 64 megabytes of RAM can be had for less than $200. Your device needs to make up its shortcomings in the display, memory, and standard interface department, by pushing the programmable device aspect and large number of high-speed user I/O. Price the device in a range where customers won't choose instead to build their own CompactFlash interface card with a CPLD, and end up with a more powerful system for less money. If you target this to engineers in a production environment, you could possibly get away with a price near $400-$500, if you have a lot of options and good support (you've also got to compete against the popular PC104 systems, and low-power options probably won't be a selling point). If you target to hobbyists, I think a $175 to $250 range would be realistic though they will always buy something cheaper if they can. Basically find a cheap ARM board and a cheap FPGA board, and add the prices together.

Hi Pablo,

Interesting product. Some comments:

IMHO, this board is a bit complicated for introductory embedded learning purposes. And I expect it will be a bit too expensive. You'll be competing with sub-$200 boards from Atmel and sub-$100 ARM boards based on other ARMs. Maybe it's better marketed as a poor-man's-ASIC :)

I would personally pay up to about $300 for the board and documentation. I wouldn't pay extra for a parallel port wiggler, etc. because I already have these tools. For "production", I would only be willing to pay around half that price for a board including FPGA. I would suggest preloading Angel or (better) RedBoot in ROM, not including JTAG tools with the appliance, and letting people use it the good old way with a serial cable.

The FPGA isn't directly useful to me - because I don't have enough time to use it effectively (one-man team...) But it could become useful if I could download canned applications from you - LCD controller being the application of primary interest!

Lose the prototyping area. Bring the signals to headers. I'm not hacking stuff onto an eval board.

Hi Pablo,

Interesting idea ;)

Our board is going to have an ARM and an FPGA tightly coupled as well. But we will have a lot more of course.

Having gone down this road before, I would recommend that you used different devices than the two you have picked. I think you will find it is cheaper to use an ARM with internal Flash and RAM. Of course how much you need depends on your application and a SOC ARM may not have enough. But you can sell the board with/without the external Flash and RAM to make a low cost version possible.

We picked the OKI ARM chips, the ML67Q5003 in particular. It has 32 kB RAM and 512 kB Flash on chip. It also has tons of IO and multiple IO devices (UARTs, SPI, I2C, ADC...). It will directly support SDRAM and provides chip selects for Flash and IO devices.

The Spartan IIE FPGAs are ok devices, but as someone else pointed out, they are not very low power. They also have an issue with a power on current surge that requires 0.5 Amps of current minimum without allowing the voltage to drop. And all this is during the voltage ramp up process! Then to top it all off, these parts are not 5 volt tolerant. There are still a lot of apps that need to interface to 5 volt signals.

We picked the Altera EP1K series of FPGAs. They are fairly low cost and less power hungry than the Spartan IIE devices. Their power on current is much lower and the core voltage matches the OKI ARM chip.

Pablo Bleyer wrote:

For the JTAG interface, just add an Multi-ICE 20-pin header. Most designers have Wiggler-like Dongle. Or if you need a better flash programming baudrate or debugging baudrate, use the Chameleon POD with raven_all_speeds configuration. (note: Chameleon POD can operates as Raven, Wiggler, Xilinx_parallel_cable, Altera_ByteBlaster, Lattice_ispDownload, Atmel_AVR_stkxxx, configutation! ALL config for FREE, ALL in ONE Dongle)

Laurent

Hello Rick!

We picked up this AT91 for its availability in low volumes, sleep modes (internal PLL that boosts 32kHz to 32MHz) and temperature range. Yes, we considered and are considering other devices as well, like OKI chips (they support external SDRAM, though these are difficult to source in industrial temp) and the LPC22XXs. If this works out perhaps we can offer other family siblings with the same board format and other MCUs. Nice thing is that they are all ARMs so code reusability and compatibility is secured.

We have measured the ramp-up current of SpartanII and IIe FPGAs and it is really not an issue with this kind of boards (of course, the power supply was designed considering the FPGA requirements). We have used Xilinx FPGAs in several designs, so we are confident with the parts and we know their features and limitations. We try very hard to design our boards with reliability in mind and we do lots of tests in field and harsh environments (Chilean mining industry, do I need to say more? ;^)

In standby (MCU at 32kHz --not in sleep--, FPGA clocks halted) the unit takes ~60mA @ 3.3V input. When the MCU is running at 32MHz the board typically consumes ~140mA at the same voltage. FPGA consumption varies, but for simple apps it's below 100mA working at full MCU clock. So a typical application always at full MCU clock can run for ~10 hours with two rechargeable NiMH AA batteries. If the board enters sleep mode power consumption can be reduced a lot and will improve stand-alone operation considerably.

Yep, we know that there are a lot of 5V systems out there. We analyzed the situation and it really was cheaper to make the core module as simple as possible, and add a couple of 25 cent 5V tolerant transceivers to the add-on modules that use 5V parts (and where there is more space).

Have you measured their standby current (before configuration) and static consumption (after configuration and halted clocks)? That would be nice figures to compare.

Thanks for your comments. Cheers!

PabloBleyerKocik / pbleyer /"Simplicity is prerequisite for reliability." @embedded.cl / -- Edsger Wybe Dijkstra

Or you could just add the Xilinx coolrunner part that they are using on the Chameleon pod and connect directly to the PC!

Many of the newer ARMs are available in Industrial temps (OKI only comes in Industrial) and some work with a 32 kHz xtal (the OKI does not).

Unfortunately the LPC22xx are not out yet. Only the versions with no external bus are available.

Wow! That is a lot more than other devices can do, but I guess if it is not an issue with your application it does not matter. The OKI part runs at 60 MHz with less than 60 mA @ 2.5v. Of course the FPGA current will depend on the app inside, but we are designing with > Then to top it all off, these parts are not 5 volt tolerant.

I guess if you have picked the Xilinx parts for other reasons that would be true. But the power and the 5 volt tolerance is the main reason we picked the Altera ACEX part. This just eliminates the extra parts and keep the power supply simple. We are using a couple of switched capacitor converters to keep it as efficient as possible.

I have not measured it, but the numbers that Altera has given me are 100 mA startup surge and 5/10 mA static current (commercial/industrial temps).

Actually, we are doing something much better, but it will only see the light once we have the necessary ROI to fund its production ;^)

Regards.

"rickman" escribió en el mensaje news: snipped-for-privacy@yahoo.com...

Main problem is, as always, availability. There are some newer parts that have more features than the one we are using at a similar price, but, believe me, we laid out all the information we had on the table before we picked up the processor.

The LCP21XX are supposedly to be available, but they are very difficult to source. Waiting for the LPC22XX was simply out of the question. Also, these devices are too new to put them out directly into production without knowing the exact erratas. These chips look good, though, so surely we will be evaluating them to use them in our solutions.

Thanks, that is a good figure to know about.

Well, so I guess in this case the datasheet reflects reality (not always the case, with any vendor indeed).

Regards.

-- PabloBleyerKocik / "Personally I don`t understand the motivation pbleyer / to build robots in human form since humans are @embedded.cl / so available and inexpensive." -- Lou Boyd

Yes, we considered a CPLD versus the FPGA. For some applications the CPLD fits fine, but it leaves a lot of applications out. For example, we have had applications where we need a *lot* of UARTs, you can only fit one or two UARTs in most reasonably priced CPLDs. There is also a benefit/cost relationship. Indeed, the Coolrunner XC2C128 costs only ~US$4 less than the Spartan XC2S100E, and the latter has far more resources. The FPGA itself is not as power-hungry as one might think.

It is really not a PocketPC. You cannot put a PocketPC in an industrial environment! The idea of the board is to use it for deeply embedded devices, although of course you can plug an LCD and other consumer-electronics stuff to it. We are targeting the sub-US$100 market of 8 and 16 bit module boards.

The idea for the battery operation is that you use the low power modes of the processor to reach weeks of battery life.

Yes, we will make modules and FPGA cores available for this. We know that the 1MB RAM limit could scare many people out there, but for the applications we have in mind there is no need for more (really -- eCos is so configurable that it only takes the memory resources it actually needs). The CF module, for example, will add enough memory for data logging applications, that is a typical scenario where you need lots of memory (eg 512MB).

In fact, we are targeting hobbyist and other OEMs. We are trying to sell the core board and modules for less than US$100, and the kit in no more than US$200.

Thanks again for your comments, they are very valuable.

Regards.

Hello Lewin. Thanks for replying.

Yep, that's a nice comparison. ;^) However, we are trying to sell the core module and other modules for less than US$100 (single quantities), and the kit for something between US$150 and US$200.

The idea of the core+module is to make modules as cheap as possible (eg 2 layer PCBs instead of the 6 layer PCB the core has). This will allow people to build their own custom boards cheaply too.

Wow, that's a lot more than the price we thought we could sell the boards. We are pushing our costs as low as we can. We don't have all the cost figures yet (since this will be a first full fledged production we cannot benefit from scale economies yet), but the idea is to make the price low cost. If we have success we expect prices to improve.

Yes, that is the whole idea of it (like you said, a poor-man's ASIC. ;^) In the future we will provide FPGA cores, auto-configurable modules and configuration tools. For now the kit will be available, and most of the software (including HDL code) will be open source.

Thanks, that is worthful. We were into the discussion of how valuable was the prototyping area for some people.

Thanks again for your comments and suggestions!

Regards.

Nice looking board! How can you make a 6 layer board stuffed with memory, arm7 processor and a spartan II and sell for under $100??? I could see if you are making several hundred to thousands....

Which board house made the board? Digikey must be really juicing me on pricing...

Rick

Hello Rick.

"Rick" escribió en el mensaje news:CphXb.9460$ snipped-for-privacy@nwrddc02.gnilink.net...

arm7

are

No, we are not (yet -- but fingers are crossed. ;^) Our post was trying to analyze the demand for the product. We don't have final cost figures, but, yes, we think will be able to sell the core in single quantities around that amount.

Protos were manufactured by E-teknet

Digikey has improved its pricing a lot, but on some parts they are still pricey (specially AT91 mcus in this case). You can buy packs from, eg, Avnet (60 units) at the same price Digikey offers them at 1000 units.

Regards.

Another vote for headers.

If one of them bears some relationship to a SODIMM socket, you could conceivably support SDRAM through a controller in the FPGA, for those who need it. Just a thought.

- Brian

One thing to be aware of: Cost, and bigtime.

Hello Brian.

All the available MCU and FPGA signals have been exported to the headers (120 pins total). The idea of dual headers is to be able to stack modules up or down and keep things compact. We have also a design for a backplane, where the core module fits in dual headers and there are AGP132 connectors for the add-on modules that also have an edge connector (these have a length of ~2.7" that fits that format). So, yes, it's possible to have a module with SDRAMs controlled by the FPGA, although this will take some pins of the headers for the SDRAM control signals. If the module has an external controller that would be better, but perhaps a cleaner choice would be to use PSRAMs.

The extra 12 signals of the AGP132 connectors are used for alternative voltages (eg negative voltages for bipolar DACs), and 4 pins are used for module auto-detection.

Thanks for your comments. Regards.

My vote would be for both headers and a proto area. The extra square inches of board space is not very much cost. When it comes to the headers, I always make the pinout compatible with the HP logic analyzer pinout. But not many agree with me on that. I find it so much more convenient to be able to plug in the pods rather than to have to clip all those little leads on. :)

If anyone is interested, I can provide the HP doc on how to do this.