Beginner Advice (Languages, tools etc.)

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" <rl@null.void.test> wrote in message 
news:fcf5so$pu1$1@lust.ihug.co.nz...
> 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 <jcc@sover.net> 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 <rl@null.void.test> 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