FPGA Newbie

Hey Guys/Gals,

I'm only fairly new to FPGA's, I've used the xilinx xc2s400e, but this was on a digilent board and the whole environment was set up for me.

I'm doing my final year thesis for engineering and am highly interested in using an FPGA as the IC's I am after, well, dont exist.

The main purpose of the FPGA is to replace a 32input or gate (which is made out of 4-8input or gates and 1x4 input), 32 bit mux (made out of 2x16 bit muxes and 1x2bit mux) and 32 d-latches (each latch also has to have logic on its input - ie. an extremely simple finite state machine (2 states))

I am considering using the xilinx xc2s50e... however I do have a couple of concerns...

Do I actually have to 'clock' the chip? or can I have it run asynchronously like most logic gates??

I do have a few other questions, but thats the main one.

Cheers Matt

Reply to
Matt Sorrensen
Loading thread data ...

You don't need to clock the FPGA but be aware that FPGA logic is very fast and ripple delays can cause glitches very easily. This is a much greater issue that in descrete logic chips. A clock can help to stabilse this albeit with some time penalty.

John Adair Enterpo> Hey Guys/Gals,

Reply to
John Adair

Indeed you are, or you'd know there're not many 'Gals' on this newsgroup, more's the pity... :-)

Yep, async will work fine. I guess you have some input which 'clocks' the latches? Of course, you're almost certain to want to do something clever later on which needs a clock. I'd make provision for a oscillator module just in case. Use something > 24MHz so there are no restrictions on using the on-chip digital clock managers. Good luck, Syms.

Reply to

Actually spartan 2e only has DLL's not DCM's so your clock may also want to be related to a useful system frequency. Also be aware that although the internal logic is quite fast (John's note about glitches), getting on and off the chip in a timely manner may require the fastest speed grade. I use a spartan 2 (not e) as a clock multiplexer and needed to use -6 speed grade to get about

6-7 nS pin-to-pin timing. I'm not sure if it's cheaper, but the spartan 2 comes in a smaller core part XC2S15 which is probably still bigger than you need for a few gates.

Also when using an FPGA for pin-to-pin combinatorial functions you'll find that keeping the input and output pins near eachother will greatly improve timing, as the routing delays can be larger than logic delays. So for example if you had a

32-bit wide mux, you'd run much faster with a pinout like A0, B0, Y0, A1, B1, Y1, ... than with a pinout like A0, A1, A2, A3, ... A31, B0, B1, ... B31, Y0, Y1, Y2, ... Y31.
Reply to

For the simple functions you are trying to implement I would recommend a CPLD over an FPGA. Either Altera MaxII or Xilinx equivalent. These will be much cheaper ($2 or $3) and are standalone non volatile instant boot devices, as opposed to an FPGA which will need some separate boot flash and a loader.

Reply to
Icky Thwacket

Good advice - CPLDs are easier to learn. Most vendors also support simpler language flows, for CPLDs

The logic above is close to the bottom end of the scale. So 64 or 128 macrocell CPLDs would be candidates, which points to

Vendor Boolean Language Devices Atmel : CUPL : ATF1504/ATF1508 Lattice : ABEL : MACH4064/4128 Xilinx : ABEL : XC2C64, XC2C128, or the XC95xx series Altera : AHDL : MAX7064/MAX7128 ICT : WinPlace : See web link

formatting link

The ICT ones might be light on IO lines.

Reply to
Jim Granville


Indeed it is a shame there isnt that many 'gals' on here, but its better to be safe than sorry :-)

With the latches, what I hope to achieve is basically like a storage device. I have 32 inputs coming in and wish to read back the values at a later time, hence the mux, which i described wrong as being a 32-bit mux, I should've said a 32input mux (32 inputs to 1 output, 5 select lines).

When you say "Yep, async will work fine. I guess you have some input which 'clocks' the latches?" - all I want the latches to do is to be able to decide when the input has gone high and to latch this value, that is, the input to the latch is the "output of the latch" OR "the input". I will also have a Reset Line to clear these values. Does this mean that I wont have to add a clock signal to it?

I do agree that having provisions for a clock input is a great idea - thanks :-)

Thanks for all the hints and tips guys it is very much appreciated -

Regards Matt

Reply to
Matt Sorrensen

That was another of my concerns, so the memory on the xilinx xc2s50e is volatile?

The main reason I was considering using an FPGA was that I have access through uni to the development boards - which mind you are a pain to set up as well as lecturers/students who have done the courses. Plus I already have the code written for what I require. :-) and 'hopefully' it works

I will check out the CPLD's however

Thanks for your advice

Cheerrs Matt

Reply to
Matt Sorrensen

Oh, I don't know. I think Lattice still manufacture GALs, don't they? :-)

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
 Click to see the full signature
Reply to
Jonathan Bromley

If you have code (even nearly OK), most vendors tools allow re-target to different devices, so you can check the CPLD size needed quite quickly. -jg

Reply to
Jim Granville

And are available in much 'easier' packages like PLCCs, and use a single supply voltage. The fact that they are much simpler devices probably also reduces the likelihood of glitches in asynchronous logic.

Reply to
Mike Harrison

After all your project is a thesis, so including discussion of alternatives is just as important as the solution.

"While a satisfactory solution could have been produced using many discrete logic ICs, or one or more CPLDs, the selection of an FPGA solution was heavily influenced by time limits and presence of appropriate hardware and software in the school laboratory."

Reply to
David Kelly

Very true, alas I suspect CPLD's are to blame for the present lack of gals...

Reply to

Oh, the gals are still about, now just a bit long in the tooth, and not as attractive as they were in the past! :)


Reply to
Jim Granville

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.