Re: Size does matter

40K gates is way too small for anything I'm considering, and the "added value" stuff just wastes internal space. We all know where to find AVR core and serial if we want it.

Rob

Marc Van Riet wrote:

40K gates is way too small for anything I'm considering, and the "added value" stuff just wastes internal space. We all know where to find AVR core and serial if we want it included.

Rob

Marc Van Riet wrote:

Marc,

Looking at the AT94K05AL right now ... 5K usable gates, 20K SRAM.

EP1C6 (a better comparison) - 6K LE's (registers), 92K ram

APA150 - 150K gates, 6K registers, 36K ram

Add to that the need for an expensive IAR compiler for the AVR core and it's pretty average. It's difficult to do a meaningful feature comparison though, owing to the different architectures. I do know that the EP1C6 and APA150 are very similar in price (when the config chip is added into the equation). May check out the Atmel too, just to be sure I'm not missing out on any bargains.

Rob

Marc Van Riet wrote:

Marc,

By a very strange coincidence, a Belgian friend of mine (well, he's from Bruges so he's a bit weird :) who designs very tiny RF and micro boards (mostly portable stuff using MSP430) happened to have a kit from

that uses the AT40K chip. He offered it to me - complete with tool chain - for as long as I need it.

So, it looks like I'm AVR'ing for now, but I'd rather be drinking a nice cold Orval.

Rob

Marc Van Riet wrote:

Hi Rob,

After reading the ProASIC Plus data sheet, I believe you should be comparing to a Cyclone EP1C3, not a EP1C6.

The APA series uses a logic cell that can be either a 3-input LUT or a flop. Cyclone (EP1Cx) has a 4-input LUT _and_ a register, plus a bunch of dedicated circuitry for performing asynchronous clear, asynchronous load, synchronous clear, synchronous load, clock enable, dynamic add/subtract, and other stuff I'm probably forgetting. The register and LUT can feed one another, or can be used independently, allowing LUTs and flops to be packed together into a single cell. So my guess is that a APA150 with 6K cells will be somewhere in the neighbourhood of the density of a EP1C3.

In addition, the APA devices are manufactured on a .22u technology with programmable cells, while Cyclone is manufactured on a 0.13u copper process. My guess is that Cyclone will be signficantly faster.

Of course, your best bet is to get your hands on the CAD tools and push the big green button :-). Cyclone is supported in the Web Edition of Quartus II

3.0, available at

Regards,

Paul Leventis Altera Corp.

You have alternatives besides IAR.

The CodeVision compiler from http://www.hpinfotech.ro/ looks good, I have associates who used it and didn't have anything unpleasant to say. There is a version of the compiler that also supports the FPSLIC too. It supports a number of optimizations and also includes pragmas so you can optimize for speed or size.

There is also ImageCraft

I test drove the 30-day eval and found it had functionality, but wasn't laid out (in my opinion) as well as the above. Code produced looked OK I found CodeVision was better in some instances, but I didn't spend too much time trying to optimize for my test runs.

There is also AVR-GCC if you feel like dealing with GNU stuff...I have

*major* problems with this toolchain since(among other issues) it does not support "dead code" removal which should rip out any pieces of compiled code that aren't referenced in your program. I have a small set of C routines that I use in many of my projects but often not all functions in the "common set" C file are used. GCC won't remove those (even if you mess around with the linker scripts).

Also, there aren't any pragmas for optimization (just your standard -o1

-o2 -o3 switches) which means you have to segment code into seperate files to get it optimized the way you want (very sub-optimal).

GCC just wasn't meant for 8-bit micros, and I found plenty of fault with the code it generates too.

Anyway, you have some alternatives.

-- Jay.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

if you are looking for plug in cabaliity as main criteria, then Rena Electronics sell a board that is 15x15 PGA foot print with a XC2S100-5VQFP onboard. get you 100k gates and nice prototyping plugin capabilities.

You can also buy just the TQFP/VQFP to PGA adaptor board with no FPGA.

Also they will sell you an adaptor board and you send them the chip and they will attach it.

This will not give you small physical size but ease from soldering fine pitch QFP packages.

The only way I would attempt soldering BGA packages on a small scale production is to use a hot plate and a lot of flux. Place the PCB, should be FR4 min., on the hot plate at about 275C with BGA on board aligned as close as possible. Use liquid flux and wait about 30 seconds. If the BGA is close to alignment, +/- half a ball width, then it will align with the pads. Once it starts to float the remove from the hot plate gently. Let cool and pray!

james ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...snip...

Well, all the marketing "stuff" aside, I have been thinking about this the last few days, and I think marketing teams are missing some opportunities. I know that in some of my recent designs, I could have used a small to medium FPGA instead of a CPLD if the FPGA were available in a small package. And contrary to what FAEs may tell you in this newsgroup, FPGAs with Flash is not a bad idea either.

If a 50K gate FPGA (1,536 logic cells in the XC3S for example) could be put in a 48 pin TQFP, and include Flash on die, then that would be a great product! I know that the chip designers would have a hard time figuring out how to do this, but it would be a CPLD killer! I have already replaced one of the larger CPLDs on my current board with an FPGA. I have a second CPLD that could easily be replaced by an FPGA with flash. Even if they had to go back to .25 micron process to get the flash, would that be so bad? A decent FPGA could easily be built at those densities that would kick CPLD butt.

Is Lattice the only company that thinks a decent sized FPGA with on die flash is a good idea?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Yes, and there is also a hole in the CPLD sector, around TQFP64. CPLD started with PLCC68/PLCC84 pin devices, but never replaced them with the move to SMD, so you have just 44/100 commonly.

Look at the FLASH ProASIC from Actel, that's quite close to what you describe. Comes in TQFP100 and FBGA144. Getting to TQFP48 is a bigger ask, as the market would be thinning a lot - how many Vcc/Gnd/Core/JTAG pins do you loose ?

FBGA144 is not as nice to apply, but it is 13mm on an edge, so not much larger than TQFP48. No, you cannot deploy this on single sided PCB. TQFP100 is 16mm / edge, and that is single sided possible.

Philips have pitched at this big core/small package (TQFP48) with their first ARM uC variants.

-jg

actel ProAsic+ and upcoming ProAsic will have not only flash configuration but user BlockFlash cells :)

antti

GCC? Bwahahaha. If only you knew my opinion of that crud.

I hadn't heard of Codevision, thanks for the tip.

Rob

What I'm missing (besides a Flash) is memory! All this SOPC talk forgets that for a decent CPU you need external memory. I don't need additional single cycle, synchchronous, fast memory. Keep the block rams and add a 'slow' 128 kB block (perhaps only 8 bit port is ok) with let's say 30 ns access time. This would also help for large FIFOs. A summery for a 'dream' SOPC FPGA:

3000 - 5000 LCs 5 kByte block ram 128 kB 'slow' async ram 512 kB flash (for configuration AND user data) 48 - 100 pin TQFP (with pad distance > 0.5mm => cheaper production) price below EP1C6 :-)

That would be REALLY cool

my 2c Martin

---------------------------------------------- JOP - a Java Processor core for FPGAs: