Spartan 3E

First question to ask (if you are no really _big_ customer):

Where to I get XC3SE from?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

"> First question to ask (if you are no really _big_ customer):

There is a small Polish shop which sells them:

1 PLN = 0.26 Euro.

The largest device they have is 3S500, which costs 38,5 Euro @ 1 piece quantity. But I don't know whether they sell the chips outside the country. Anyway, that's the reason I have decided to divorce with Altera -- nobody sells their nice chips. :-(

Best regards Piotr Wyderski

Make sure they have them on stock. Every other lokation I have seen, that lists them, state no explicit lead time.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

does, and they have office in Poland. For over the desk buying if so required.

Now if altera only had webpack for linux.. ;)

Piotr,

Since no one else seems to wish to answer your technical questions, I will:

see below

Austin

Almost identical. 3E uses the same process as 3. The families are cost optimized for logic, and the other for IO.

The routing is the same as Spartan 3. If you had problems before, then you will have them again (with a particular routing). Not sure what you are trying to do. There may be a different suggested way to solve the problem using these families' architecture.

You may use a sine wave clock, but that will mean that you will have more jitter than if you use a square wave clock. That has nbothing to do with Spartan 3E (or 3), it is just the fact that a sine wave is provides a vaying time if there is any ground bounce, Vcc bounce, cross talk, etc (which there always is). I would suggest using the largest p-p sine wave you can get, if this is desired, then the transition through the zero crossing will be the fastest. For example, if the differential input is in a 2.5V bank, a 2.5 V sine wave (rail to rail) is best as the LVDS input buffer slices at about 50 mV or less between + and -.

What I don't get is why the 3E "only" has such small devices if they are trully logic optimized? Personally, I would love to use a 208-pin version of an FPGA with 4+ million "gates"... My I/O requirements for my current project are minimal... the logic requirements are somewhat larger.

--Toby.

Tobias Weingartner schrieb:

Maybe because you application is not the typical one, that was found by evaluating sales/custumer requirements. A FPGA will never be a perfect match in IO, logic, whatever. Thats the "sacrifice" to flexibility.

Regards Falk

Hi, Tobias, Falk said it: we are not a boutique. Spartan, even more than Virtex, is aimed at the high-volume market. If you have peculiar requirements, you must make trade-offs. C'est la vie. Peter Alfke, Xilinx

What about using some module, like the Zefants

or the HydraX

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Austin already replied on some of these topics ...

... but I wanted to amplify a bit further on your second question.

For most applications, you can simultaneously use both the block RAM and its neighboring embedded mutliplier. There is a limit, however, if and only if you use the block RAM in x36 mode (512 x 36).

There is further information on page 46 (right hand column) in the Spartan-3E data sheet.

-- Steve Knapp

[cut -- thank you all for your answers!]

I asked that question because the data sheet doesn't say anything about the behaviour of the block RAMs configured as ROMs:

"Each multiplier is located adjacent to an 18 Kbit block RAM and shares some interconnect resources. Configuring an

18 Kbit block RAM for 36-bit wide data (512 x 36 mode) prevents use of the associated dedicated multiplier.

The upper 16 bits of the 'A' multiplicand input are shared with the upper 16 bits of the block RAM's Port A Data input. Similarly, the upper 16 bits of the 'B' multiplicand input are shared with Port B's data input."

The ROM memories do not have data input ports and thus there is nothing to share, except for the implementation-dependent side effects.

Best regards Piotr Wyderski