New to FPGA, seeking advice

Hi

I'm an embedded systems designer who feels that it's about time he started to learn about using FPGAs. I'm happy using PLDs, designed in something like CUPL but don't know where to start on bigger devices.

I only have a small budget for development tools and I'm in the UK.

From what I can see my best choice of manufacturer is probably down to Xilinx or Altera.

Can anyone suggest an evaluation board that would get me started?

I see that devices are sold in terms of their gate count. How efficient is a typical design? For instance, if I want to make a 16 by

16 CPU controlled crosspoint how many FPGA gates will I need? I can see that I need 16 OR gates each with 16 AND array inputs for the output terms, 64 latches to store the selection and some more gates to do the latch address decoding. Is there any easy way to choose the right part?

Thanks

Brian

--
Brian Fairchild
B dot Fairchild at Dial dot Pipex dot Com
 Click to see the full signature
Reply to
Brian Fairchild
Loading thread data ...

Hello Brian,

Take a look at these:

formatting link
formatting link

To start experimenting you'll need a System Board and one of the peripheral boards. The Spartan2e on this board has 200K gates, for your design it should be way too big... to give you an idea of what you can get into it, take a look at the list of applications they give at the Xilinx ip center.

Good luck

Yves

Brian Fairchild wrote:

Reply to
Yves Deweerdt

Hi Brian,

You might have a look at

formatting link
There are some good evaluation boards that are not so expensive.

That is very difficult to answer. This issue has been discussed sometimes in this newsgroup already, and will probably be discussed again and again.

You should never ever draw some conclusions from the gate-count given by the manufacturers. This is just a marketing number. I started with Lucent (now Lattice) ORCA FPGAs and got a feeling what can be put inside. Then I turned to Xilinx Virtex FPGAs (because of the free development software) and got rather shocked how much less one can put into such an FPGA with a comparable gate count.

For instance, they include internal RAM-Blocks in the official gate-count number. That gives a shiny value, but is nonsense if you ask me. My guess is that the Xilinx people that are around here in this newsgroup think similar because they are more engineers rather than marketing people. But apart from that, the Xilinx FPGAs are not bad ones.

Instead, have a look at the building blocks, see what they provide and how much of them are available and then draw conclusions whether it is sufficient for your design. And when you made some designs for a specific FPGA series, you will soon develop a feeling which array size could be appropriate for which problem.

Once you got some design software, you might also try to synthesize your design (provided it has been finished already) and try to fit it into different FPGA types. There you will also see how much of the FPGAs' capacity would be used.

Regards, Mario

Reply to
Mario Trams

(snip)

Well, some designs fit the FPGA model better than others. My guess is that a crossbar switch is one that doesn't fit very well, but that is a guess.

The traditional CMOS definition for gate count is the number of transistors divided by four. It takes four to make a CMOS 2 input NAND gate. RAM arrays are included in that count.

(snip)

This is probably the best way. First, the manufacturer given gate count is a maximum, and you should expect somewhat less. There may be a wide variation on how much you actually get.

-- glen

Reply to
Glen Herrmannsfeldt

All,

I beg to differ. We have not only a good solution, but a great solution:

formatting link

The worlds first FPGA cross bar switch that uses the programmable interconnect as....well, as a corss bar switch! Extremely efficient (able to do 1024x1024 in a 2V6000 at 155 Mbs each wire, non-blocking).

For a really small cross bar, one could use the ICAP with the microblaze for control, and a bram for the patterns....and perhaps only 16 CLBs for a 16X16 non-blocking cross point switch.....

Aust>

Reply to
Austin Lesea

Just as an academic thing for myself.

Is a bi-directional crosspoint switch able to be produced with a FPGA? My understanding is they are a matrix of fets each one having a memory cell to store it's setting.

So I would say that it was impossible. Even a fully digital one would still require that an an I/O pin can be used for input and output at the same time.

Can anyone confirm or deny?

Thanks Ralph

Reply to
Ralph Mason

In a flurry of electrons Ralph Mason spake thus:

To clarify, what I wanted to do as an example was a uni-directional crosspoint.

--
Brian Fairchild
B dot Fairchild at Dial dot Pipex dot Com
 Click to see the full signature
Reply to
Brian Fairchild

interconnect

1024x1024 in

for

16X16

That does sound pretty neat. I was thinking of it in terms of synthesizable logic using CLB's.

Can you do a barrel shifter for floating point prenormalization/postnormalization that way, too?

-- glen

Reply to
Glen Herrmannsfeldt

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

Glen,

Do not see why not. The downside is that you need to reconfigure the interconnect to change a cross point, so the update rate is slow. For most traffic bearing circuit switch applications, a few ms to change the x-point is not an issue, but for a packet system it would not be fast enough.

A barrel shifter seems like something you would want to update very quickly, and for that, you would probably rather use the multiplier as a barrel shifter.

Aust> > All,

Reply to
Austin Lesea

Ralph,

Since the virtex architecture is fully buffered (patented), there is no such thing as a bididrectional connection.

Aust>

Reply to
Austin Lesea

Deny.

Crossbars are uni-directional. Now, the REAL relay crossbars used by the telcos upto the 1970s ARE bi-directional.

Reply to
Tom Seim

Tom,

Although the x-bar relays were bi-directional, they were only used in a uni-directional fashion for toll switching (full duplex four wire). The only bidirectional metallic stage was the first level concentrator for the phone lines to the subscribers with the x-bar 5 WeCo Class 5 office. After that, the circuits were separated into transmit and receive.

The older Strowger step by step relays were bidirectional switching from subsrciber to subscriber, and four wire for toll circuits.

Telco lore bonus question: why is positive ground battery used in telecom?

Inter-office tie trunk tivia: a revertive dial trunk line would dial the foreign office by initiating the call, and telling the foreign office to start dialing. When the foreign office had dialed the right number of digits, the local office would signal it to stop, and go on to the next digit.

Extra point question: which class 5 local electronic office switch was demanded by a PUC/PSC to be removed from service due to incredibly poor performance? What state's PUC/PSC?

Aust> "Ralph Mason" wrote in

message news:...

Reply to
Austin Lesea

in

So this partial reconfig, is clever enough that a portion of the FPGA can keep running, while the rest is respun - or would what you describe above need two FPGA ?

-jg

Reply to
Jim Granville

But thats exactly what an FPGA is only the latch data that control the cross switches are in your bit file.

For the particular crossbar mentioned, the whole device would have to be fully or partially reprogrammed on the fly. if the lines stay connected for long enough, the difficulty of reconfiguring is justifed. If this RC approach hadn't been available ie fused/eeprom FPGA etc, then the density & speed would be orders lowers. Probably the single sneakiest best use of RC I heard of so far.

JJ

Reply to
john jakson

But thats exactly what an FPGA is only the latch data that control the cross switches are in your bit file.

For the particular crossbar mentioned, the whole device would have to be fully or partially reprogrammed on the fly. if the lines stay connected for long enough, the difficulty of reconfiguring is justifed. If this RC approach hadn't been available ie fused/eeprom FPGA etc, then the density & speed would be orders lowers. Probably the single sneakiest best use of RC I heard of so far.

JJ

Reply to
john jakson

uni-directional fashion for toll switching (full duplex four wire).

phone lines to the subscribers with the x-bar 5 WeCo Class 5

subsrciber to subscriber, and four wire for toll circuits.

The voltage is negative with respect to ground to help reduce corrosion problems.

-48V is the standard voltage used in phone exchanges. (Actually it's more like -52V when float charging, but you get the idea.) (ETSI standard ETS 300 132-2 says -40,5 to -57,0 Vdc at the equipment input. A "slight degradation in performance" may exist for voltages in the range -40,5 to -44,0 Vdc. Telcordia will have similar specs.)

The magnitude of the voltage is 48V because that voltage is a good compromise between a number of factors, one major one being the ability to drive enough power down a long (high resistance) line to the phone. Really old phone exchanges needed a certain loop current to activate the hook relay.

ISDN lines are usually biased at a higher voltage which can be up to

120V (max allowable for TNV), as the ISDN equipment needs more power.

Note that some areas use -60V (= 5 x 12V) for POTS.

Regards, Allan.

foreign office by initiating the call, and telling the foreign

of digits, the local office would signal it to stop, and go on

demanded by a PUC/PSC to be removed from service due to incredibly

in message news:...

Reply to
Allan Herriman

in

As far as I'm aware this FPGA cross bar requires an external controller, not even an FPGA I think they use a PC running JBITS and so on.

the fun starts when you have a microblaze on the FPGA that is controlling the dynamic reconfig of the rest of the chip while it keeps running....

ICAP makes this possible. one of my crazier ideas now that I have uclinux running on microblaze is to include a java virtual machine running under uclinux (already done on non-microblaze targets, minimal porting effort required) then you could run JBits on the microblaze, and use it to reconfigure itself.....

so many ideas, so little time! :)

john

Reply to
John Williams

way is

which

using

which can

A subject that comes up reasonably often is doing floating point arithmetic in FPGA's. For example, as a systolic array. The prenormalization/postnormalization for floating point add/subtract, using barrel shifters in CLB's are so big that it is just about impractical. I was considering the crossbar switch as an array of muxes, which would also be huge.

I do believe that reconfiguration is too slow for floating point normalization, but maybe the SRL16's.

There is something called block floating point (I have never used it) where you have a whole array that has one characteristic but different mantissa for each element. (Apparently very useful for some algorithms.) In that case, the 16 clocks to load the SRL16's might be fast enough for a whole array of numbers. Post normalization could still be a problem, though.

-- glen

Reply to
Glen Herrmannsfeldt

I have Digilab 2E lying around that I use for prototyping. It's nice because there isn't a lot of fluff, just some programming hardware, voltage regulators, oscillator, EEPROM socket, and easy-access connectors around the whole board.

It may be tempting to just poke wires into the connectors...don't! I got away with it for quite a while, until one of my unbuffered/isolated wires crossed a power supply and toasted the Spartan. I had to desolder it and plunk on a new one this week. Fortunately that particular chip costs only $25 from Digikey. Better than $120 for a new Digilent board! They do use a

2.5V supply for the 1.8V chip, fortunately the supply range is fairly flexible.
Reply to
Garrett Mace

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.