Hi guys,
Here are a few comments regarding FPGAs, perhaps they'll
be of interest to this discussion.
I have had good experiences using Altera FPGAs, and have not
used the Xilinx parts or tools, so won't comment on them.
Development kits - you get what you pay for.
For example, I purchased an Altera university program
board (UP1), and its pretty I/O limited, eg. a serial port
would have been nice, or perhaps a DB25 in a standard
parallel port layout. I found the I/O buffers had trouble
driving a cable, so had to make adapters with buffers
before I could communicate between the board and a
control PC. I also purchased a Cypress CY37000 board
and it pretty much was the CPLD on a footprint with a
header breakout.
Pay a little more for your development kit and it
will payoff in the long-run. For example, an 'expensive'
(eg. $1k, or the price of a decent home PC) development
kit usually comes with a lot of hardware examples,
and software pre-ported to the platform. For example,
the Altera kits often come with NIOS II processor builds,
and the uCOS-II, eCOS, and uCLinux ports.
So consider the price of such a platform as being both
the hardware and software you get.
The Altera web site lists Altera's kits:
http://www.altera.com/products/devkits/kit-dev_platforms.jsp
and partner kits
http://www.altera.com/products/devkits/kit-dev_platforms_partner.jsp
A partner of note; Microtronix was the originator of the uCLinux
port, so their kits will likely support it. I believe the
NIOS II forum is run by Microtronix www.niosforum.com.
Why pay good money for these kits? ... well, your time
is worth money too, so its nice to start with something
that works and add an incremental change to the design.
Its also another source of information, eg. a working eCOS
port on a NIOS II processor wouldn't be too much different
than an eCOS port on an ARM processor, so using the NIOS
as a reference design, getting eCOS running on an LPC wouldn't
be too difficult. The resources consumed by a NIOS port
(eg. required Flash and RAM) would give you an idea of
whether an LPC part with internal Flash+SRAM would work,
or whether a part with an external bus was a requirement.
Last week (out of interest) I looked at interfacing an LPC part
(one of the devices with an external memory bus) to an Altera
Cyclone II FPGA. Here's a couple of comments regarding
that 'preliminary' investigation.
Hand-solderable parts ... most of the darn FPGAs come in BGA
packages. However, parts like the Cyclone II EP2C5 and
EP2C8 come in 144-pin and 208-pin packages. The number
of user I/O pins is 89 and 142 pins max respectively.
So lets say you interfaced a 24-bit address, 32-bit data,
and say 6-control lines microcontroller bus to this FPGA,
that would use 62-I/O pins and leave you with 27 and
80-pins respectively. So depending on your other interface
requirements, the 208-pin package would be the way
to go. Of course, you don't need to decode all the address
bits, and you could use an 8-bit or 16-bit interface,
so you can save pins there. And there is always the option
of talking to your FPGA using SPI. Clearly the interface
requirements change depending on the speed required from the
interface.
How about price, well the EP2C5/8 parts are about $13-24ea
(see Arrow's web site). Not too expensive. But then since
these devices are SRAM based, you need to load the FPGA
configuration. The Cyclone II NIOS II kit uses an
EPCS64, and that part is $32 - more expensive than the
FPGA! If you are going to have a microcontroller on the board,
then it might pay to use the micro to load the FPGA
(its pretty easy). I believe most of the Altera boards
contain an Altera MAX CPLD with a controller assigned to
this task, but a micro could do the trick.
What about the NIOS II processor instead of the LPC part?
Well, the LPC is highly integrated with respect to the NIOS II
processor; you could reproduce the functionality of the
LPC using a NIOS processor, but at several times the expense.
Use FPGAs as co-processors, i.e., add them to a design
to off-load a critical task.
FPGAs can be an expensive solution to a problem, so use them
where necessary. If board real-estate is not an issue, and
a standard part exists to 'do the job', then use the standard
part along with a reduced-size FPGA. As an example,
the PCI interface can be implemented in an FPGA, but you can
buy <$20 parts from PLX technologies and AMCC that do a much
better job than any of the PCI cores I've looked at.
Tools; if you want to program in VHDL/Verilog, the Altera
web version of Quartus II should be adequate for what you
want to do. However, if you want to use the NIOS II processor,
I believe you will need to license the SOPC Builder features.
I use the full-versions of Altera's tools provided to me
through their university program. I also use Mentor Graphics
FPGA Advantage tool-suite (ModelSim and Precision-RTL),
again through their university program.
VHDL or Verilog? I learnt both. I ended up going with VHDL
since I needed to use features of the language that weren't
available in Verilog (or were available, but not supported
by the Altera tool of the time; MAX+plus II). The differences
between the languages are ultimately syntactical. An
HDL based design typically consists of;
- vendor instantiated blocks (eg. an Altera lpm_counter for
a counter).
- user-defined blocks of logic
- user-defined state machines
- a heirachical connection of logic blocks, eg. think
of a schematic page containing design blocks.
Quartus lets you mix and match schematic capture and HDL, so
you can have a nice top-level schematic, that contains other
schematic components or HDL documents. Personally I prefer
text for everything (since I process using the Mentor tools
and scripts), but an engineer I helped transition from
pure-schematic based design to mixed designs liked using
schematics for the top-level.
Anyway, feel free to ask more questions, or for help if
you get yourself a development board.
Regards,
Dave