FPGA Central

Hi,

Please excuse me for sounding like I don't have a clue what I'm talking
about. I am here because I want to learn.

I have a project I have been working on that requires physical hardware.
I will be getting someone to assist with building the hardware, but it
will be up to me to programme it. Originally I was going to use a
microcontroller, as I have C programming experience. After further
investigation, I thought it would be a better idea to use an FPGA and do
it all in hardware. The functionality is mainly I/O related, so hardware
seems like a sensible choice.

Why I am here is to seek some advise on which language to use, what
software I will require, and how far I can get using open source or free
software, before we actually need to build the hardware to test with.

I am open minded about learning SystemC, VHDL, or Verilog in order to
get this done. Which of these would allow me to get further, bearing in
mind I need to write code, debug it, and eventually get it on to an
FPGA, using (I assume) vendor-specific tools?

SystemC seems like the obvious choice given it is based on C++, but
there doesn't seem to be any clear description on how to get from
SystemC code to an FPGA.

Thanks,

RL.

RL wrote:

> I have a project I have been working on that requires physical hardware.
> I will be getting someone to assist with building the hardware, but it
> will be up to me to programme it. Originally I was going to use a
> microcontroller, as I have C programming experience. After further
> investigation, I thought it would be a better idea to use an FPGA and do
> it all in hardware. The functionality is mainly I/O related, so hardware
> seems like a sensible choice.

You could bit-bang the IO from a microcontroller
parallel port. There is no reason to use an
FPGA unless the CPU is too slow.

> Why I am here is to seek some advise on which language to use, what
> software I will require, and how far I can get using open source or free
> software, before we actually need to build the hardware to test with.

If you have six months or less to finish this
consider deferring the HDL/FPGA learning process.
You can get a CPU board the uses GNU tools.

> I am open minded about learning SystemC, VHDL, or Verilog in order to
> get this done. Which of these would allow me to get further, bearing in
> mind I need to write code, debug it, and eventually get it on to an
> FPGA, using (I assume) vendor-specific tools?

If you go the FPGA route, use vhdl or verilog.

> SystemC seems like the obvious choice given it is based on C++, but
> there doesn't seem to be any clear description on how to get from
> SystemC code to an FPGA.

Add a year to your schedule and lots of $ to your budget for this.

-- Mike Treseler

RL wrote:
> Hi,
>
> Please excuse me for sounding like I don't have a clue what I'm talking
> about. I am here because I want to learn.
>
> I have a project I have been working on that requires physical hardware.
> I will be getting someone to assist with building the hardware, but it
> will be up to me to programme it. Originally I was going to use a
> microcontroller, as I have C programming experience. After further
> investigation, I thought it would be a better idea to use an FPGA and do
> it all in hardware. The functionality is mainly I/O related, so hardware
> seems like a sensible choice.
>
> Why I am here is to seek some advise on which language to use, what
> software I will require, and how far I can get using open source or free
> software, before we actually need to build the hardware to test with.

Xilinx and Altera both provide free-as-in-beer toolchains, though you
will have to buy or build a jtag cable dongle to connect to actual
hardware. Also, there are development boards of all different sizes that
might allow you to avoid or postpone building you own hardware. See the
FAQ for comprehensive lists of these.

> I am open minded about learning SystemC, VHDL, or Verilog in order to
> get this done. Which of these would allow me to get further, bearing in
> mind I need to write code, debug it, and eventually get it on to an
> FPGA, using (I assume) vendor-specific tools?
>
> SystemC seems like the obvious choice given it is based on C++, but
> there doesn't seem to be any clear description on how to get from
> SystemC code to an FPGA.

The particular syntax and semantics of VHDL or Verilog will not be a
problem if you are already comfortable with software languages, though I
would avoid SystemC if only because no free tools support it AFAIK.

Knowing how the subset of the language that is synthesizable maps to
real hardware is usually more of an issue, which is where the big
learning curve is if you are new to hardware design.

-Jeff

"RL" <[email protected]> wrote in message
news:fcf5so$pu1$[email protected]..
> Hi,
>
> Please excuse me for sounding like I don't have a clue what I'm talking
> about. I am here because I want to learn.
>
> I have a project I have been working on that requires physical hardware. I
> will be getting someone to assist with building the hardware, but it will
> be up to me to programme it. Originally I was going to use a
> microcontroller, as I have C programming experience. After further
> investigation, I thought it would be a better idea to use an FPGA and do
> it all in hardware. The functionality is mainly I/O related, so hardware
> seems like a sensible choice.
>
> Why I am here is to seek some advise on which language to use, what
> software I will require, and how far I can get using open source or free
> software, before we actually need to build the hardware to test with.
>
> I am open minded about learning SystemC, VHDL, or Verilog in order to get
> this done. Which of these would allow me to get further, bearing in mind I
> need to write code, debug it, and eventually get it on to an FPGA, using
> (I assume) vendor-specific tools?
>
> SystemC seems like the obvious choice given it is based on C++, but there
> doesn't seem to be any clear description on how to get from SystemC code
> to an FPGA.

As adviced by others you can make your life easier and save some money by
using VHDL or Verilog. However, SystemC doesn't have to be ruled out if you
prefer to go down that route but it will require some financial investment
and a thorough evaluation. As you probably know the simulation tools are
free but synthesis is the real budget killer. Have a look at SystemCrafters
which sells a low-cost SystemC synthesis tool. I have no association with
this company but the price looks interesting :-)

http://www.systemcrafter.com/index.php

Hans
www.ht-lab.com


>
> Thanks,
>
> RL.

Jeff Cunningham <[email protected]> wrote:

>RL wrote:
>> Hi,
>>
>> Please excuse me for sounding like I don't have a clue what I'm talking
>> about. I am here because I want to learn.
>>
>> I have a project I have been working on that requires physical hardware.
>> I will be getting someone to assist with building the hardware, but it
>> will be up to me to programme it. Originally I was going to use a
>> microcontroller, as I have C programming experience. After further
>> investigation, I thought it would be a better idea to use an FPGA and do
>> it all in hardware. The functionality is mainly I/O related, so hardware
>> seems like a sensible choice.
>>
>> Why I am here is to seek some advise on which language to use, what
>> software I will require, and how far I can get using open source or free
>> software, before we actually need to build the hardware to test with.
>
>Xilinx and Altera both provide free-as-in-beer toolchains, though you
>will have to buy or build a jtag cable dongle to connect to actual
>hardware. Also, there are development boards of all different sizes that

That is not entirely true. It is very easy to use a microcontroller to
load the FPGA contents either parallel or serial (SPI).

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

On 15 Sep, 00:36, RL <r...@null.void.test> wrote:
....
> Why I am here is to seek some advise on which language to use, what
> software I will require, and how far I can get using open source or free
> software, before we actually need to build the hardware to test with.

>From one beginner to another I found http://www.digilentinc.com/ a
good place to start. As well as selling development boards they link
to comprehensive development environment software from Xilinx. The
Xilinx software and a Xilinx version of the Modelsim simulator are
both free.

Digilent also have downloadable videos on how to use the Xilinx-
provided software. This is a boon to show which options to use as the
software itself has many features. You need to know which ones to use
to get started. The current software interface is slightly different
from that shown in the videos but it is possible to work out with a
bit of patience.

> I am open minded about learning SystemC, VHDL, or Verilog in order to
> get this done. Which of these would allow me to get further, bearing in
> mind I need to write code, debug it, and eventually get it on to an
> FPGA, using (I assume) vendor-specific tools?
>
> SystemC seems like the obvious choice given it is based on C++, but
> there doesn't seem to be any clear description on how to get from
> SystemC code to an FPGA.

You probably know Verilog has C syntax. Using the above software you
can test either VHDL or Verilog without programming the FPGA.
Digilent's Basys board will program by USB so is a doddle. The board
can also be powered by USB or by an external single volt supply.

There may be other good suppliers. I don't know. I found Digilent
first and they had what I wanted. YMMV. I have no connection with
them.

--
James

Hi -

On Sat, 15 Sep 2007 11:36:35 +1200, RL <[email protected]> wrote:

>Hi,
>
>Please excuse me for sounding like I don't have a clue what I'm talking
>about. I am here because I want to learn.
>
>I have a project I have been working on that requires physical hardware.
>I will be getting someone to assist with building the hardware, but it
>will be up to me to programme it. Originally I was going to use a
>microcontroller, as I have C programming experience. After further
>investigation, I thought it would be a better idea to use an FPGA and do
>it all in hardware. The functionality is mainly I/O related, so hardware
>seems like a sensible choice.
>
>Why I am here is to seek some advise on which language to use, what
>software I will require, and how far I can get using open source or free
>software, before we actually need to build the hardware to test with.
>
>I am open minded about learning SystemC, VHDL, or Verilog in order to
>get this done. Which of these would allow me to get further, bearing in
>mind I need to write code, debug it, and eventually get it on to an
>FPGA, using (I assume) vendor-specific tools?
>
>SystemC seems like the obvious choice given it is based on C++, but
>there doesn't seem to be any clear description on how to get from
>SystemC code to an FPGA.

Mike Treseler has already addressed the issue of whether a
microcontroller solution might not be more suitable (I suspect it is),
so I'll set that aside.

There's one issue that's more important than languages, tools, and the
like, to wit:

Do you know how to do digital design? In particular,

- Do you know the principles of synchronous logic design?
- Do you know how to reliably initialize a digital circuit?
- Do you know how to analyze a timing path?
- Do you know how to move signals between mutually asynchronous clock
domains?
- Do you know how to handle digital signals at the FPGA I/O? Do you
understand the fundamentals of different digital interface standards?
(I'm talking about the simple stuff, like what qualifies as a valid
HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain
to a 3.3V domain). Do you know how to use signal terminations to
guarantee good signal quality?

And I'm just scratching the surface.

You are embarking on a hardware design, not a programming exercise.
Hardware design skills are essential, no matter what the SystemC
brochure says.

Maybe this is coming across as unduly harsh; that's not my intent. All
of us hardware designers were newcomers at one point, so folks
starting out in hardware design today deserve our support. But I'd
really, really like to drive a stake in the heart of the "designing
FPGAs is programming" meme.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

Hi,

Thanks to everyone who responded. I'm still undecided on which path to
take for this particular project, but I've spent about two hours so far
going through a VHDL tutorial. It is starting to make sense, so at least
I will have a better idea of what is going on in the rest of the hardware.

A few comments for Bob below...

> Mike Treseler has already addressed the issue of whether a
> microcontroller solution might not be more suitable (I suspect it is),
> so I'll set that aside.

I should have mentioned, I am driving this development, and from my
point of view spending six months refining my VHDL skills wouldn't be a
major issue if the end result is going to justify this.

> There's one issue that's more important than languages, tools, and the
> like, to wit:
>
> Do you know how to do digital design? In particular,
>
> - Do you know the principles of synchronous logic design?
> - Do you know how to reliably initialize a digital circuit?
> - Do you know how to analyze a timing path?
> - Do you know how to move signals between mutually asynchronous clock
> domains?
> - Do you know how to handle digital signals at the FPGA I/O? Do you
> understand the fundamentals of different digital interface standards?
> (I'm talking about the simple stuff, like what qualifies as a valid
> HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain
> to a 3.3V domain). Do you know how to use signal terminations to
> guarantee good signal quality?
>
> And I'm just scratching the surface.
>
> You are embarking on a hardware design, not a programming exercise.
> Hardware design skills are essential, no matter what the SystemC
> brochure says.

I may be completely wrong about this, so feel free to comment.

My intention is to only work on what is going on internally within the
FPGA (or CPU), and only the core logic to make it do what it has to do.
The actual interfacing to other electronic components will be handled by
someone with more knowledge than myself. I will be mainly concerned with
the internal logic of what happens when external events occur (in this
case, button presses, serial communications, and one clock).

Any electronics knowledge I once had was a decade ago, so I'm starting
out with very little. From a point of view of interpreting the input and
getting the output I want, dealing only with 0s and 1s, I don't think
I'm taking on too much.

If I use a CPU, I need to read and write binary values that the
supporting electronics has to handle. If I used VHDL, I need to design
hardware to do certain things when values change, and set output
accordingly. The approaches are different, but taking the black box
approach, inputting and outputting binary values, both should work
equally well.

I can see some major advantages doing this in VHDL. Yes, I have more to
learn, but I wouldn't have to worry about interrupts and race
conditions. In theory, and again I may be wrong, I should be able to be
more confident that the FPGA does what I expect, when I expect it to.

> Maybe this is coming across as unduly harsh; that's not my intent. All
> of us hardware designers were newcomers at one point, so folks
> starting out in hardware design today deserve our support. But I'd
> really, really like to drive a stake in the heart of the "designing
> FPGAs is programming" meme.

This is actually part of the reasoning behind selecting VHDL in
preference to SystemC. With SystemC, I could see there would be a
tendency to fall back to the familiar style of programming used for
software development. Hardware is a completely different concept and
should be treated as such.

Thanks again for your comments and suggestions.

RL

Hi RL,

>Hardware is a completely different concept and
> should be treated as such.
I agree with you there.
But then you go on to say:

>The approaches are different, but taking the black box
> approach, inputting and outputting binary values, both should work
> equally well.
Which I agree with in the sense that both the cpu and fpga can
probably do what you want assuming we are not talking about high speed
IO or very heaving processing. But I disagree in the sense that in
general, when developing for a cpu one is describing your design in C/C
++, whereas for FPGA its VHDL and its digital logic design. C/C++ is
at a higher level of abstraction than VHDL/digital design. For this
type of "control" problem, the average engineer familiar with both the
C and VHDL toolsets will be able to complete the C design in much less
time than the VHDL one. Maybe a factor of 10 or more depending on the
complexity of the control problem. With VHDL you are working at a much
lower level. I suppose its even lower than assembly code if you wanted
a comparison.

Since you havn't done electronics for a while, I would recommend the C/
cpu approach and leave the FPGA until a more appropriate project comes
up?

Cheers
Andrew





On Sep 16, 8:04 am, RL <r...@null.void.test> wrote:
> Hi,
>
> Thanks to everyone who responded. I'm still undecided on which path to
> take for this particular project, but I've spent about two hours so far
> going through a VHDL tutorial. It is starting to make sense, so at least
> I will have a better idea of what is going on in the rest of the hardware.
>
> A few comments for Bob below...
>
> > Mike Treseler has already addressed the issue of whether a
> > microcontroller solution might not be more suitable (I suspect it is),
> > so I'll set that aside.
>
> I should have mentioned, I am driving this development, and from my
> point of view spending six months refining my VHDL skills wouldn't be a
> major issue if the end result is going to justify this.
>
>
>
> > There's one issue that's more important than languages, tools, and the
> > like, to wit:
>
> > Do you know how to do digital design? In particular,
>
> > - Do you know the principles of synchronous logic design?
> > - Do you know how to reliably initialize a digital circuit?
> > - Do you know how to analyze a timing path?
> > - Do you know how to move signals between mutually asynchronous clock
> > domains?
> > - Do you know how to handle digital signals at the FPGA I/O? Do you
> > understand the fundamentals of different digital interface standards?
> > (I'm talking about the simple stuff, like what qualifies as a valid
> > HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain
> > to a 3.3V domain). Do you know how to use signal terminations to
> > guarantee good signal quality?
>
> > And I'm just scratching the surface.
>
> > You are embarking on a hardware design, not a programming exercise.
> > Hardware design skills are essential, no matter what the SystemC
> > brochure says.
>
> I may be completely wrong about this, so feel free to comment.
>
> My intention is to only work on what is going on internally within the
> FPGA (or CPU), and only the core logic to make it do what it has to do.
> The actual interfacing to other electronic components will be handled by
> someone with more knowledge than myself. I will be mainly concerned with
> the internal logic of what happens when external events occur (in this
> case, button presses, serial communications, and one clock).
>
> Any electronics knowledge I once had was a decade ago, so I'm starting
> out with very little. From a point of view of interpreting the input and
> getting the output I want, dealing only with 0s and 1s, I don't think
> I'm taking on too much.
>
> If I use a CPU, I need to read and write binary values that the
> supporting electronics has to handle. If I used VHDL, I need to design
> hardware to do certain things when values change, and set output
> accordingly. The approaches are different, but taking the black box
> approach, inputting and outputting binary values, both should work
> equally well.
>
> I can see some major advantages doing this in VHDL. Yes, I have more to
> learn, but I wouldn't have to worry about interrupts and race
> conditions. In theory, and again I may be wrong, I should be able to be
> more confident that the FPGA does what I expect, when I expect it to.
>
> > Maybe this is coming across as unduly harsh; that's not my intent. All
> > of us hardware designers were newcomers at one point, so folks
> > starting out in hardware design today deserve our support. But I'd
> > really, really like to drive a stake in the heart of the "designing
> > FPGAs is programming" meme.
>
> This is actually part of the reasoning behind selecting VHDL in
> preference to SystemC. With SystemC, I could see there would be a
> tendency to fall back to the familiar style of programming used for
> software development. Hardware is a completely different concept and
> should be treated as such.
>
> Thanks again for your comments and suggestions.
>
> RL

Andrew FPGA wrote:
> IO or very heaving processing. But I disagree in the sense that in
> general, when developing for a cpu one is describing your design in C/C
> ++, whereas for FPGA its VHDL and its digital logic design. C/C++ is
> at a higher level of abstraction than VHDL/digital design. For this

I think this point is often missed by people coming from the software
side. HDL synthesis is more like a macro assembler for hardware than a
high level language. As such, you really need to know basic hardware
design to get good results.

-Jeff

Nico Coesel wrote:
> Jeff Cunningham <[email protected]> wrote:
>
>> Xilinx and Altera both provide free-as-in-beer toolchains, though you
>> will have to buy or build a jtag cable dongle to connect to actual
>> hardware. Also, there are development boards of all different sizes that
>
> That is not entirely true. It is very easy to use a microcontroller to
> load the FPGA contents either parallel or serial (SPI).

fair enough. how would you load the microcontroller?

-Jeff

"RL" <[email protected]> wrote in message
news:fchdql$2nq$[email protected]..
> Hi,
>
... snip
>
> This is actually part of the reasoning behind selecting VHDL in preference
> to SystemC. With SystemC, I could see there would be a tendency to fall
> back to the familiar style of programming used for software development.
> Hardware is a completely different concept and should be treated as such.

I don't want to turn into a SystemC evangelist but SystemC supports the same
low-level RTL constructs as Verilog or VHDL. The language supports
processes, sensitivity lists, wait statements, resolved/unresolved signals,
variables, delta cycles, positional/named instantiations, 'X'/'Z' values,
hierarchy, IO ports etc. Obviously the language is not intended to be used
at the synthesisable RTL level but if you want to use it at this level you
can.

Good luck with your project, sound like fun,

Hans
www.ht-lab.com


>
> Thanks again for your comments and suggestions.
>
> RL

RL wrote:
> Hi,
>
> Please excuse me for sounding like I don't have a clue what I'm talking
> about. I am here because I want to learn.
>
> I have a project I have been working on that requires physical hardware.
> I will be getting someone to assist with building the hardware, but it
> will be up to me to programme it. Originally I was going to use a
> microcontroller, as I have C programming experience. After further
> investigation, I thought it would be a better idea to use an FPGA and do
> it all in hardware. The functionality is mainly I/O related, so hardware
> seems like a sensible choice.

What sort of IO ? - Microcontrollers are also designed for I/O related
tasks, and have many hardware peripherals for the common tasks.

Only when you hit a limit on a uC, should you look at FPGA.
Examples where a FPGA/CPLD is nessary might be if you need simultaneous
changes on 80 IO lines, or a special 50MHz serial link, or
high bandwidth memory access.

Another approach is to start with a uC, and refine the design in uC/SW,
and then move whatever portion of the design needs HW to speed up.

For specialist uC look at devices like these
http://www.parallax.com/propeller/index.asp
http://www.innovasic.com/fido.htm

-jg

Hi -

On Sun, 16 Sep 2007 08:04:18 +1200, RL <[email protected]> wrote:

>Hi,
>
>Thanks to everyone who responded. I'm still undecided on which path to
>take for this particular project, but I've spent about two hours so far
>going through a VHDL tutorial. It is starting to make sense, so at least
>I will have a better idea of what is going on in the rest of the hardware.
>
>A few comments for Bob below...
>
>> Mike Treseler has already addressed the issue of whether a
>> microcontroller solution might not be more suitable (I suspect it is),
>> so I'll set that aside.
>
>I should have mentioned, I am driving this development, and from my
>point of view spending six months refining my VHDL skills wouldn't be a
>major issue if the end result is going to justify this.
>
>> There's one issue that's more important than languages, tools, and the
>> like, to wit:
>>
>> Do you know how to do digital design? In particular,
>>
>> - Do you know the principles of synchronous logic design?
>> - Do you know how to reliably initialize a digital circuit?
>> - Do you know how to analyze a timing path?
>> - Do you know how to move signals between mutually asynchronous clock
>> domains?
>> - Do you know how to handle digital signals at the FPGA I/O? Do you
>> understand the fundamentals of different digital interface standards?
>> (I'm talking about the simple stuff, like what qualifies as a valid
>> HIGH or LOW for a 3.3V logic signal, or how to interface a 5V domain
>> to a 3.3V domain). Do you know how to use signal terminations to
>> guarantee good signal quality?
>>
>> And I'm just scratching the surface.
>>
>> You are embarking on a hardware design, not a programming exercise.
>> Hardware design skills are essential, no matter what the SystemC
>> brochure says.
>
>I may be completely wrong about this, so feel free to comment.
>
>My intention is to only work on what is going on internally within the
>FPGA (or CPU), and only the core logic to make it do what it has to do.
>The actual interfacing to other electronic components will be handled by
>someone with more knowledge than myself. I will be mainly concerned with
>the internal logic of what happens when external events occur (in this
>case, button presses, serial communications, and one clock).

Do you plan to review this person's design? If so, you'll need to be
conversant with the I/O-related issues I mentioned above.

>Any electronics knowledge I once had was a decade ago, so I'm starting
>out with very little. From a point of view of interpreting the input and
>getting the output I want, dealing only with 0s and 1s, I don't think
>I'm taking on too much.
>
>If I use a CPU, I need to read and write binary values that the
>supporting electronics has to handle. If I used VHDL, I need to design
>hardware to do certain things when values change, and set output
>accordingly. The approaches are different, but taking the black box
>approach, inputting and outputting binary values, both should work
>equally well.
>
>I can see some major advantages doing this in VHDL. Yes, I have more to
>learn, but I wouldn't have to worry about interrupts and race
>conditions. In theory, and again I may be wrong, I should be able to be
>more confident that the FPGA does what I expect, when I expect it to.

The fact that you'll be working within the confines of an FPGA does
simplify things somewhat, but it's by no means a get-out-of-jail-free
card. It's like being at the beach: you have a lot of sand, and you
can build a beautiful castle, or something that looks like you just
filled up a pail and overturned it.

Here's one example of the problems you'll have to deal with. You have
a single clock, some button inputs, and a serial link or links. The
serial links are probably asynchronous to the clock, and the button
pushes most certainly are. How do you take these asynchronous signals
and synchronize them to your clock domain safely and reliably? The
FPGA gives you the raw materials with which to craft a good circuit,
but it's not automatic: you have to design a solution.

>> Maybe this is coming across as unduly harsh; that's not my intent. All
>> of us hardware designers were newcomers at one point, so folks
>> starting out in hardware design today deserve our support. But I'd
>> really, really like to drive a stake in the heart of the "designing
>> FPGAs is programming" meme.
>
>This is actually part of the reasoning behind selecting VHDL in
>preference to SystemC. With SystemC, I could see there would be a
>tendency to fall back to the familiar style of programming used for
>software development. Hardware is a completely different concept and
>should be treated as such.

VHDL is nothing more than a means of describing your logic design.
Yes, the synthesizer will do some of the low-level scut work, like
reducing Booleans expressions. But when all is said and done, you
still have to do the design.

If you decide to proceed with the FPGA design, Eric Crabill's SJSU
course is an excellent introduction. You can find the presentations
here:

http://www.engr.sjsu.edu/crabill/

Good luck,
Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com