Xilinx vs Altera

What's the big deal? I'm no expert, but is 0.8mm that much more difficult to deal with than 1.0?

Interesting. Are you planning to sell blank boards or stuffed ones? Will the PCB database be open source, or just gerber files? What particular audio applications do you think people would use it for?

What would your board bring to the table not available from the jillion of dev boards out there? multichannel audio I'm guessing. What if you made an interface board with a lot of audio on it and made it where it could connect to umpteen different boards already available. Then you could quickly adapt your IP designs to new generation devices next year and the year after.

-Jeff

1. Benchmark both with something resembling the final design. You should have all the logic connected to at least drive all of the external output/inout pins and use all of the input to at least do 'something'. For the IP that you'll be developing you'll need to generate it in a vendor neutral way, which can usually be done (except for non-inferrable things like PLL/DLLs). Try out the vendor specific cores for things you're missing even if they won't necessarily be in the final design.

1a. Try not to get too wrapped around the axle about having everything functional before moving on. There is a bit of a risk but as long nothing is getting totally optomized away, you should be able to make a reasonable benchmark.

1. Run the designs through place and route. Pay attention to the reports about unneeded I/O, make sure nothing gets optomized away, make sure that IP blocks are consuming resources (an unconnected input or output in an internal block can make the whole thing disappear).
2. Decide on what metrics are important for your project (i.e. device cost, clock speed, packaging, bigger parts in the same package, tool hassles, etc.) and evaluate all the FPGA vendors based on those metrics...also may not necessarily want to exclude the 'other guys' beside brand A and X. They're the two biggest, not the only ones.

Kevin Jennings

Lattice have an open source, 32 bit processor core. Add that to your short list ? - this sounds fairly core-agnostic, so you could start with a Xilinx/Altera core, then move to lattice as the system is proven, and ready for wider deployment.

-jg

It adds a lot to board cost. This is a hobby project, lol.

Stuffed, I doubt people would want to solder the BGA... Open source, And multichannel remote audio soundcard with DSP capabilities. One of the guys is more interested in recording capabilities and I'm more interested in playback, anyway the hardware is the same, only difference is the number of ADC/DACs in the daughterboard...

But since it's an FPGA and the audio stuff will be on a separate (much cheaper to manufacture) board it could be pretty much anything else... The "remote" part will be either ethernet (currently prototyped) or FireWire with a DICE chip (this is under review). It is not very fixed at the moment. But since Ethernet adds little cost and can serve many purposes it is here to stay.

Low noise/EMI, small, cheap, and ethernet that works without headaches. Believe it or not I found no such thing on the market.

Chips are hard to obtain for a hobby project. DigiKey et al only stock X & A...

I was talking about the core, not the silicon.

If this is an open-source project, it makes sense to use an open source core ?

Also, Lattice Silicon is available from Mouser, and Jameco et al.

-jg

It adds a lot to board cost. This is a hobby project, lol.

I just did an ARM chip that had .65mm ball pitch. There aren't a lot of guys that can laser drill and do a 3/3 technology. Yes, you pay, but get used to it--things are getting smaller!!

PFC wrote:

I am not an expert on Altera licensing, but as far as I can tell you use Quartus web edition and open core evaluation during development. This means you can use the DDR core (the sdram core is always free from Altera, and runs a lot more than 50 MHz, as is their dma core) and the NIOS core while connected to Quartus with by jtag. For stand-alone use, you have to buy a NIOS license and a DDR core license (in practice, you buy a licence for the full version of Q, and get the DDR core license along with it, as well as other cores - the FIR and FFT cores might be of interest). When you buy these, you get a year's worth of upgrades and support, and a perpetual license for the cores.

Of course, it might work out cheaper (depending on your volumes, and development times and costs) just to use two SDRAM chips and a faster clock, saving you the need to buy Q. Similarly, you might find a different cpu core such as Lattice's free core, or something from opencores, will do the same job.

se =

=

=

e, =

u =

=

=

=

Duhhhhhhhhh I missed the fact that the "free" NIOS was not free, thanks for pointin= g =

this out !

Or a 32 bit SDRAM which is what I had in mind initially.

I have an escape route. If I include FireWire in the project (which now seems likely), then I c= an =

use the ARM7 cpu which is in the DICE FireWire chip. I would have to =

connect its bus to the FPGA, using lots of pins, but there are enough pi= ns =

to do this. I think this is going to be the simplest way to pass the =

licensing minefield.

Now I am thinking about the memory interface :

- DDR=3Dhard, SDR=3Deasy,

- DDR=3D2.5V, SDR=3D3.3V,

- We want some LVDS IO and lots of 3.3V IO, so we want one 2.5V bank, =

Xilinx has 4 banks and Altera 8, so LVDS IO mandates DDR on Xilinx lest = a =

lot of pins be wasted, not so on Altera because of the 8 banks,

- But Altera Cyclone III has extremely tight tolerances on 3.3V because = of =

the process used, I read on this group that actually it likes 3.0V bette= r, =

and a little overshoot on 3.3V makes it latchup apparently.

- This makes me uneasy to use Altera because there will be cables, and =

cables =3D risks of overshoot...

Yes, you can use the Nios "freely" during development, and "freely" once you've paid the license :-) It's not unreasonable, actually - it's a one-off cost for a perpetual royalty-free license. But for a low-budget project, it's a significant cost.

If you have an external processor connected anyway, you can also save a bit by using the processor to download the FPGA configuration - no need for a configuration flash, and it's easier to update the fpga software in the field. I might also suggest an FTDI FT2232C USB device - you can use it to download software into an FPGA or a processor via SPI or UART, thus avoiding any flash at all on the card (if you are happy always being connected to a PC, of course).

Look carefully at the Altera application notes for how to use 3.3V safely on the CIII - don't just accept the word of a Xilinx employee! (I'm not accusing anyone in c.a.f. of lying - but you can't except a X employee to go out of their way to put Altera devices in the best light.) I haven't used a CIII yet, so I have no experience here.

a =

d =

=

an =

T, =

Actually this CPU needs a parallel flash to boot (which it then copies = to =

its own SDRAM). Since I'll put the FPGA on the CPU bus, I could use a =

small SPI flash to program the FPGA into a SRAM containing the CPU =

bootloader, this way I can do without the parallel Flash and the special= =

cable to program it (who needs YET ANOTHER JTAG cable ?). Then the CPU c= an =

read the rest of the firmware from SPI flash and reconfigure the FPGA fr= om =

a choice of bitstreams...

=

st =

se =

=

d =

Heheh. Actually I looked and it doesn't seem that scary. But the issue = =

made me a bit uneasy as I said. I will look more.

I tried to generate some DDR interface with the Xilinx MIG but it's not= =

very noob friendly. I need to try harder, lol.

And academic if you can use the FG676 which is still 1mm (and gives more I/O)

- Brian

What I'm thinking of is that the CPU would boot from parallel flash (unless you are using the FTDI USB device mentioned), and copy its own software into sdram for speed. Then it uses an SPI interface to download the fpga firmware into the fpga, so that the fpga does not have any configuration flash devices.

Normally you don't need a special cable to program the parallel flash on the board - you either pre-program it (if it's a big volume product) before mounting, or use the cpu's debug port or built-in bootloader (depending on the cpu in question).

me too. I'm working on high-speed signal compression, btw. contact me (through my initials at ygdes.com) when you have something ready !

yg

me too. I'm working on high-speed signal compression, btw. contact me (through my initials at ygdes.com) when you have something ready !

yg

If you are going to do multi-channel audio, Xilinx may have the advantage that you can use the LUTs as 16x1 memory instead of flipflops. If you want to process up to 16 channels, you can use luts as temporary storage for filter results etc. The space savings can be huge.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

For the FIR I will probably use some BRAM but I was looking into this the other day and I really like the tiny FIFOs you can make with the Xilinx parts. Very useful for me ! I can instantiate one FIFO per channel using very little slices and it greatly simplifies my data flow. And the SRLs are nice to make audio I²S encoders, too.

PFC schrieb:

How about some core developed by the free hardware community like OpenRISC?

Philipp

I have an escape route. If I include FireWire in the project (which now seems likely), then I can use the ARM7 cpu which is in the DICE FireWire chip. I would have to connect its bus to the FPGA, using lots of pins, but there are enough pins to do this. I think this is going to be the simplest way to pass the licensing minefield.

==========

If you're going that route, the Atmel AP7 Cortex M3 has dual Ethernet MII/RMII MAC, USB 2.0 PHY, LCD/TFT, yada yada (all the makings of a WinCE device). I don't recall seeing 1394 in its feature list, however. $25 single quantity. No licensing of "core" issues, obviously. Development tools are open source GCC. Some applications benefit less from FPGA capabilities than other, more traditional solutions. Your project description can fit this slot.

Come to think of it, I would like such a device if paired with a mid-size Spartan, something on the WebPack supported-device list. A development platform with broad connectivity options using free and open source tools sounds very, very appealing. Even the relatively large S3ADSP 1800 can take advantage of offloading some functions to a real MPU, filling some of the ground between it and the 3400, and avoiding EDK licensing. That's pushing toward a LinuxCE with onboard FPGA. IOW, fpga for the masses. Hmmm...