Getting started...

I'd like to get started in writing some simple fpga applications(LED 
blinker, etc...).

I would like to use a C++ based design. I see that SystemC is C++ based and 
is free but I'm unsure how all the different steps work.

Do I simply write code in my prefered language(VHDL, Verilog, SystemC, 
etc...) and use the appropriate tool to "compile" it then bring that into an 
appropriate program to create a hex dump for sending to the fpga(or send 
directly from the program)?

I have some proASIC's I brought a while back that I would like to use. The 
libero IDE just crashes on my comp so I can't use it.

Can someone give me very simple and straight forward process for how one 
goes about getting code to machine?

For example, with microchip pics:

1. Write code
2. Compile code to binary using MPLab or other supported IDE.
(2.5. Simulate if necessary)
3. Program chip using a programmer(or directly from MPLab)
(4. Debug)

Most likely the fpga's are pretty much identical but I have not found any 
good simple explanation on how to do this.

Right now I don't have a programmer but if it's simply done through JTAG and 
any appropriate JTAG interface can do it then it shouldn't be a problem. 
I'll just program a pic to dump the data to the fpga? (similar to 
programming a pic from the pc, for example.)


Main thing right now is that I just need to get coding... wether it's 
SystemC or not... But I would like to be able to code independently of the 
fpga so I don't lock myself into one(at this point at least).

On Oct 11, 11:43=A0am, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com>
wrote:
> I'd like to get started in writing some simple fpga applications(LED
> blinker, etc...).
>
> I would like to use a C++ based design. I see that SystemC is C++ based a=
nd
> is free but I'm unsure how all the different steps work.
>
> Do I simply write code in my prefered language(VHDL, Verilog, SystemC,
> etc...) and use the appropriate tool to "compile" it then bring that into=
 an
> appropriate program to create a hex dump for sending to the fpga(or send
> directly from the program)?
>
> I have some proASIC's I brought a while back that I would like to use. Th=
e
> libero IDE just crashes on my comp so I can't use it.
>
> Can someone give me very simple and straight forward process for how one
> goes about getting code to machine?
>
> For example, with microchip pics:
>
> 1. Write code
> 2. Compile code to binary using MPLab or other supported IDE.
> (2.5. Simulate if necessary)
> 3. Program chip using a programmer(or directly from MPLab)
> (4. Debug)
>
> Most likely the fpga's are pretty much identical but I have not found any
> good simple explanation on how to do this.
>
> Right now I don't have a programmer but if it's simply done through JTAG =
and
> any appropriate JTAG interface can do it then it shouldn't be a problem.
> I'll just program a pic to dump the data to the fpga? (similar to
> programming a pic from the pc, for example.)
>
> Main thing right now is that I just need to get coding... wether it's
> SystemC or not... But I would like to be able to code independently of th=
e
> fpga so I don't lock myself into one(at this point at least).

yes, you can implement a PIC in FPGA and use MPLAB to write
application for your own PIC-FPGA

but if you really want todo something with FPGA please try to
understand they are not processors
and it doesnt really matter what design enty method you use, without
understanding what the
FPGA tools generate as result you have little chance of doing anything
useful

Antti

On Sun, 11 Oct 2009 03:43:14 -0500, "Jon Slaughter" <Jon_Slaughter@Hotmail.com>
wrote:

>I'd like to get started in writing some simple fpga applications(LED 
>blinker, etc...).
>
>I would like to use a C++ based design. I see that SystemC is C++ based and 
>is free but I'm unsure how all the different steps work.

If you have $50k or so for a SystemC toolchain, consider it; for a reliable tool
flow at price:free, stick with VHDL (or Verilog. The language wars rage, and
basically reduce to: some prefer Verilog because it's more like C; I strongly
prefer VHDL because it's more like Pascal.)

>Do I simply write code in my prefered language(VHDL, Verilog, SystemC, 
>etc...) and use the appropriate tool to "compile" it then bring that into an 
>appropriate program to create a hex dump for sending to the fpga(or send 
>directly from the program)?

Not quite.

>I have some proASIC's I brought a while back that I would like to use. The 
>libero IDE just crashes on my comp so I can't use it.

The tools are probably more important than the chips, at least for learning.
When you need the ultimate performance, or the last cent on the BOM, then worry
about the chip.

Xilinx Webpack on Linux or Windows (my choice) or Altera Quartus (Windows only
for the free Web edition) are the way to go. (Others may me incomplete; no
simulator? or simply not work...)

>Can someone give me very simple and straight forward process for how one 
>goes about getting code to machine?
>
>For example, with microchip pics:
>
>1. Write code

Ditto but the code looks different.
e.g. for a LED blinker:
(1) identify a clock input to your FPGA (from the board's documentation
e.g. a 50MHz crystal oscillator, and a LED for output.
(2) write a synchronous divide by 50M counter in VHDL; see "counter" and
"clocked process" in the synthesis style guide supplied with the tools), and
connect the clock and counter MSB(*) to signals named "Clock" and "LED"
(3) write a constraint file (.ucf for Xilinx) which connects "Clock" and "LED"
to the appropriate FPGA pins, and sets the I/O standards, e.g. LED drive
strength. Also tell it your clock rate (see "timing constraints"). 
Stage 2 "compile" tools will meet that speed target, or tell you why it can't.

(*) for equal on/off times you want a /25M counter followed by a /2 stage

1.5 Simulate.

For a LED blinker you don't want to simulate 1 second...
Simulation is slow. So make the counter division ratio a constant, and change it
between 50M for operation, and (say) 50 for simulation. More generally; think
about testability; i.e. how to test in reasonable time.

Write a testbench to supply a clock. (The tools have templates for this) For a
LED flasher I wouldn't bother writing a tester for the output signal; just watch
it toggling in the wave window.


>2. Compile code to binary using MPLab or other supported IDE.

Synthesize; fix any synth errors.
Back end tools; (Translate/Map/Place&Route for Xilinx); fix any errors.
(e.g. rewrite for faster logic if it can't meet your speed target. Unlikely at
50MHz; probable at 200MHz)

Generate bitfile.

>(2.5. Simulate if necessary)

Rarely if ever do you need to simulate after Stage 2. It can OCCASIONALLY be
useful for identifying missing timing constraints, or chasing synth tool bugs.
But it's MUCH slower than "behavioural simulation" on the source.

>3. Program chip using a programmer(or directly from MPLab)

Depends on the board. 
(1) Program ("configure") via JTAG to chip
(2) Program FLASH memory, maybe via JTAG, and configure from that
(3) load bitfile into CompactFlash card and transfer that to socket on board.
(4) etc. Some cards are configurable across the PCI bus.

>(4. Debug)
Simulate at 1.5; there may be board level issues to debug, but not many.

>Right now I don't have a programmer but if it's simply done through JTAG and 
>any appropriate JTAG interface can do it then it shouldn't be a problem. 
>I'll just program a pic to dump the data to the fpga? (similar to 
>programming a pic from the pc, for example.)

USB to JTAG cable is common. (From Xilinx for a price. Other versions from other
people for less. Antti and others will know far more on the specifics)

>Main thing right now is that I just need to get coding... wether it's 
>SystemC or not... But I would like to be able to code independently of the 
>fpga so I don't lock myself into one(at this point at least).

Download Webpack/Quartus and get going. 

The constraint file will be device-specific, but that's all. 
Pure VHDL is pretty much portable, barring tool bugs.
(Vendor specific models, e.g. for DSP blocks, RAM blocks, PowerPCs, clock PLLs
are a different matter)

You can get 90% done before deciding on the hardware...

Boards: look at www.enterpoint.co.uk among others.

- Brian

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:6fe3d5pmrusq6cgp4s2vi2ct4sqah2jto8@4ax.com...
> On Sun, 11 Oct 2009 03:43:14 -0500, "Jon Slaughter" 
> <Jon_Slaughter@Hotmail.com>
> wrote:
>
>>I'd like to get started in writing some simple fpga applications(LED
>>blinker, etc...).
>>
>>I would like to use a C++ based design. I see that SystemC is C++ based 
>>and
>>is free but I'm unsure how all the different steps work.
>
> If you have $50k or so for a SystemC toolchain, consider it; for a 
> reliable tool
> flow at price:free, stick with VHDL (or Verilog. The language wars rage, 
> and
> basically reduce to: some prefer Verilog because it's more like C; I 
> strongly
> prefer VHDL because it's more like Pascal.)
>
>>Do I simply write code in my prefered language(VHDL, Verilog, SystemC,
>>etc...) and use the appropriate tool to "compile" it then bring that into 
>>an
>>appropriate program to create a hex dump for sending to the fpga(or send
>>directly from the program)?
>
> Not quite.
>
>>I have some proASIC's I brought a while back that I would like to use. The
>>libero IDE just crashes on my comp so I can't use it.
>
> The tools are probably more important than the chips, at least for 
> learning.
> When you need the ultimate performance, or the last cent on the BOM, then 
> worry
> about the chip.
>
> Xilinx Webpack on Linux or Windows (my choice) or Altera Quartus (Windows 
> only
> for the free Web edition) are the way to go. (Others may me incomplete; no
> simulator? or simply not work...)
>
>>Can someone give me very simple and straight forward process for how one
>>goes about getting code to machine?
>>
>>For example, with microchip pics:
>>
>>1. Write code
>
> Ditto but the code looks different.
> e.g. for a LED blinker:
> (1) identify a clock input to your FPGA (from the board's documentation
> e.g. a 50MHz crystal oscillator, and a LED for output.
> (2) write a synchronous divide by 50M counter in VHDL; see "counter" and
> "clocked process" in the synthesis style guide supplied with the tools), 
> and
> connect the clock and counter MSB(*) to signals named "Clock" and "LED"
> (3) write a constraint file (.ucf for Xilinx) which connects "Clock" and 
> "LED"
> to the appropriate FPGA pins, and sets the I/O standards, e.g. LED drive
> strength. Also tell it your clock rate (see "timing constraints").
> Stage 2 "compile" tools will meet that speed target, or tell you why it 
> can't.
>
> (*) for equal on/off times you want a /25M counter followed by a /2 stage
>
> 1.5 Simulate.
>
> For a LED blinker you don't want to simulate 1 second...
> Simulation is slow. So make the counter division ratio a constant, and 
> change it
> between 50M for operation, and (say) 50 for simulation. More generally; 
> think
> about testability; i.e. how to test in reasonable time.
>
> Write a testbench to supply a clock. (The tools have templates for this) 
> For a
> LED flasher I wouldn't bother writing a tester for the output signal; just 
> watch
> it toggling in the wave window.
>
>
>>2. Compile code to binary using MPLab or other supported IDE.
>
> Synthesize; fix any synth errors.
> Back end tools; (Translate/Map/Place&Route for Xilinx); fix any errors.
> (e.g. rewrite for faster logic if it can't meet your speed target. 
> Unlikely at
> 50MHz; probable at 200MHz)
>
> Generate bitfile.
>
>>(2.5. Simulate if necessary)
>
> Rarely if ever do you need to simulate after Stage 2. It can OCCASIONALLY 
> be
> useful for identifying missing timing constraints, or chasing synth tool 
> bugs.
> But it's MUCH slower than "behavioural simulation" on the source.
>
>>3. Program chip using a programmer(or directly from MPLab)
>
> Depends on the board.
> (1) Program ("configure") via JTAG to chip
> (2) Program FLASH memory, maybe via JTAG, and configure from that
> (3) load bitfile into CompactFlash card and transfer that to socket on 
> board.
> (4) etc. Some cards are configurable across the PCI bus.
>
>>(4. Debug)
> Simulate at 1.5; there may be board level issues to debug, but not many.
>
>>Right now I don't have a programmer but if it's simply done through JTAG 
>>and
>>any appropriate JTAG interface can do it then it shouldn't be a problem.
>>I'll just program a pic to dump the data to the fpga? (similar to
>>programming a pic from the pc, for example.)
>
> USB to JTAG cable is common. (From Xilinx for a price. Other versions from 
> other
> people for less. Antti and others will know far more on the specifics)
>
>>Main thing right now is that I just need to get coding... wether it's
>>SystemC or not... But I would like to be able to code independently of the
>>fpga so I don't lock myself into one(at this point at least).
>
> Download Webpack/Quartus and get going.
>
> The constraint file will be device-specific, but that's all.
> Pure VHDL is pretty much portable, barring tool bugs.
> (Vendor specific models, e.g. for DSP blocks, RAM blocks, PowerPCs, clock 
> PLLs
> are a different matter)
>
> You can get 90% done before deciding on the hardware...
>
> Boards: look at www.enterpoint.co.uk among others.
>


Thanks, You cleared up a few of the things I was vague on. But I'm still a 
bit vague as you say the tools such as quartus is device independent? This 
means I can use it for non altera products?

As I said, I brought some proASIC3's a while back and would like to use them 
for simple things to learn fpga. The libero IDE simply crashes in XP and 
complains of a license problem in vista(didn't do this in 8.5 but I recently 
upgraded and now it won't work... trying to update the license file if they 
ever send it).


In any case if I can get 90% done without the hardware then I guess I should 
get started.

Actually my end goal for this is to write a parallel LED driver frontend. 
Basically deals with the PWM and serial communications between the drivers 
and uC. Since each driver drives a matrix it requires a relatively high 
refresh rate(100*num rows) which the uC cannot communicate with all the 
drivers(since it would have to do so sequentially(or approximately at 
least). With the fpga I figure I can parallel all the devices, handle the 
PWM quite easily(just basically a compare), and decode some serial comm from 
the uC. I think it shouldn't be a problem for the fpga.

Also, Their is free software for the SystemC that you can "Synthesize" code. 
I'm not sure how far it goes though.

http://www.systemc.org/downloads/standards/

I prefer to program in C++ since I have been programming in C/C++/C# for 
many years. While my simple applications do not require oop it's always nice 
to have when things get more complex.

Anyways, thanks for the help...

"Jon Slaughter" <Jon_Slaughter@Hotmail.com> wrote:

>
>
>
>Thanks, You cleared up a few of the things I was vague on. But I'm still a 
>bit vague as you say the tools such as quartus is device independent? This 
>means I can use it for non altera products?
>
>
>In any case if I can get 90% done without the hardware then I guess I should 
>get started.
>
>Actually my end goal for this is to write a parallel LED driver frontend. 
>Basically deals with the PWM and serial communications between the drivers 
>and uC. Since each driver drives a matrix it requires a relatively high 
>refresh rate(100*num rows) which the uC cannot communicate with all the 
>drivers(since it would have to do so sequentially(or approximately at 
>least). With the fpga I figure I can parallel all the devices, handle the 
>PWM quite easily(just basically a compare), and decode some serial comm from 
>the uC. I think it shouldn't be a problem for the fpga.

IMHO you should step a bit further into the real world. The main
question you should ask yourself is: how much time can I to spend on
this project?

You could cut the corners and use schematic entry and use 74***
replacements or go all the way and learn VHDL (IMHO VHDL is more like
a real language than Verilog which just looks like netlist). 

And there is more to it than just creating the logic. You'll have to
understand how constraints work to specify the timing.

Either way, your project seems perfect for the first FPGA design.
Almost any device will do. So choose a supplier with the lowest price,
free software and devices in a package you can put on a board and get
on with it!

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Sun, 11 Oct 2009 07:50:29 -0500, "Jon Slaughter" <Jon_Slaughter@Hotmail.com>
wrote:

>
>Thanks, You cleared up a few of the things I was vague on. But I'm still a 
>bit vague as you say the tools such as quartus is device independent? This 
>means I can use it for non altera products?

I *hope* I didn't say that! Quartus is Altera-specific; Webpack is
Xilinx-specific, etc.

But pure VHDL code you write and simulate with one toolchain (say, you like the
simulator) should be device-independent, and re-synthesise for another vendor's
device (in that vendor's tools!) with very little difficulty.

>As I said, I brought some proASIC3's a while back and would like to use them 
>for simple things to learn fpga. The libero IDE simply crashes in XP and 
>complains of a license problem in vista(didn't do this in 8.5 but I recently 
>upgraded and now it won't work... trying to update the license file if they 
>ever send it).

If you can't develop in Libero you can't use those FPGAs.
But you may be able to develop in other tools, and then beg a little time on a
machine that DOES run Libero.

Or for $50-100 get another hardware platform. How much is your time worth?

- Brian

On Oct 12, 1:33=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 11 Oct 2009 07:50:29 -0500, "Jon Slaughter" <Jon_Slaugh...@Hotmai=
l.com>
> wrote:
>
>
>
> >Thanks, You cleared up a few of the things I was vague on. But I'm still=
 a
> >bit vague as you say the tools such as quartus is device independent? Th=
is
> >means I can use it for non altera products?
>
> I *hope* I didn't say that! Quartus is Altera-specific; Webpack is
> Xilinx-specific, etc.
>
> But pure VHDL code you write and simulate with one toolchain (say, you li=
ke the
> simulator) should be device-independent, and re-synthesise for another ve=
ndor's
> device (in that vendor's tools!) with very little difficulty.
>
> >As I said, I brought some proASIC3's a while back and would like to use =
them
> >for simple things to learn fpga. The libero IDE simply crashes in XP and
> >complains of a license problem in vista(didn't do this in 8.5 but I rece=
ntly
> >upgraded and now it won't work... trying to update the license file if t=
hey
> >ever send it).
>
> If you can't develop in Libero you can't use those FPGAs.
> But you may be able to develop in other tools, and then beg a little time=
 on a
> machine that DOES run Libero.
>
> Or for $50-100 get another hardware platform. How much is your time worth=
?
>
> - Brian

Brian,

I have seen Libero to crash very very seldom (I have one design that
crashes actel fitter)

a person who is not able to install Libero, well ability to install
and run software is i would
say necessary to anyone who wants to work with FPGA's.

Actel libero ALL version have worked on more than one PC (XP/Vista)
each time i have installed them.

hmm.. I havent upgraded to 8.6! could be 8.6 no longer works, unitl
8.5 all versions works for sure

Antti

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message 
news:hfm4d5hb053p9j8g38c3nvvepgoseplqlv@4ax.com...
> On Sun, 11 Oct 2009 07:50:29 -0500, "Jon Slaughter" 
> <Jon_Slaughter@Hotmail.com>
> wrote:
>
>>
>>Thanks, You cleared up a few of the things I was vague on. But I'm still a
>>bit vague as you say the tools such as quartus is device independent? This
>>means I can use it for non altera products?
>
> I *hope* I didn't say that! Quartus is Altera-specific; Webpack is
> Xilinx-specific, etc.
>
> But pure VHDL code you write and simulate with one toolchain (say, you 
> like the
> simulator) should be device-independent, and re-synthesise for another 
> vendor's
> device (in that vendor's tools!) with very little difficulty.
>
>>As I said, I brought some proASIC3's a while back and would like to use 
>>them
>>for simple things to learn fpga. The libero IDE simply crashes in XP and
>>complains of a license problem in vista(didn't do this in 8.5 but I 
>>recently
>>upgraded and now it won't work... trying to update the license file if 
>>they
>>ever send it).
>
> If you can't develop in Libero you can't use those FPGAs.
> But you may be able to develop in other tools, and then beg a little time 
> on a
> machine that DOES run Libero.
>
> Or for $50-100 get another hardware platform. How much is your time worth?

It's worth a lot... hence the reason I don't worry about the cost when I'm 
learning something new.

In any case, I just installed quartus. I've heard some people complaining 
about it being a bit buggy. But at least it gets to the IDE.

Thanks,
Jon

On Oct 12, 9:59=A0am, "Jon Slaughter" <Jon_Slaugh...@Hotmail.com> wrote:
> "Brian Drummond" <brian_drumm...@btconnect.com> wrote in message
>
> news:hfm4d5hb053p9j8g38c3nvvepgoseplqlv@4ax.com...
>
>
>
>
>
> > On Sun, 11 Oct 2009 07:50:29 -0500, "Jon Slaughter"
> > <Jon_Slaugh...@Hotmail.com>
> > wrote:
>
> >>Thanks, You cleared up a few of the things I was vague on. But I'm stil=
l a
> >>bit vague as you say the tools such as quartus is device independent? T=
his
> >>means I can use it for non altera products?
>
> > I *hope* I didn't say that! Quartus is Altera-specific; Webpack is
> > Xilinx-specific, etc.
>
> > But pure VHDL code you write and simulate with one toolchain (say, you
> > like the
> > simulator) should be device-independent, and re-synthesise for another
> > vendor's
> > device (in that vendor's tools!) with very little difficulty.
>
> >>As I said, I brought some proASIC3's a while back and would like to use
> >>them
> >>for simple things to learn fpga. The libero IDE simply crashes in XP an=
d
> >>complains of a license problem in vista(didn't do this in 8.5 but I
> >>recently
> >>upgraded and now it won't work... trying to update the license file if
> >>they
> >>ever send it).
>
> > If you can't develop in Libero you can't use those FPGAs.
> > But you may be able to develop in other tools, and then beg a little ti=
me
> > on a
> > machine that DOES run Libero.
>
> > Or for $50-100 get another hardware platform. How much is your time wor=
th?
>
> It's worth a lot... hence the reason I don't worry about the cost when I'=
m
> learning something new.
>
> In any case, I just installed quartus. I've heard some people complaining
> about it being a bit buggy. But at least it gets to the IDE.
>
> Thanks,
> Jon- Hide quoted text -
>
> - Show quoted text -

if people complain about Quartus being buggy, you should really get
Xilinx tools
then you have a big can of bugs, in real nice package

honestly, ALL FGPA tools work (=3D=3D are useable with some effort),
but you have to spend some of your valuable time with them

Antti

On Sun, 11 Oct 2009 21:37:57 -0700 (PDT), "Antti.Lukats@googlemail.com"
<antti.lukats@googlemail.com> wrote:

>On Oct 12, 1:33&#4294967295;am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:

>> If you can't develop in Libero you can't use those FPGAs.
>> But you may be able to develop in other tools, and then beg a little time on a
>> machine that DOES run Libero.
>>
>> Or for $50-100 get another hardware platform. How much is your time worth?
>>
>> - Brian
>
>Brian,
>
>I have seen Libero to crash very very seldom (I have one design that
>crashes actel fitter)

Good to know; I have never tried it (and frankly, I don't think either of us
would make the same statement about the Xilinx tools!) I was just following
Jon's statement there.

>hmm.. I havent upgraded to 8.6! could be 8.6 no longer works, unitl
>8.5 all versions works for sure

Maybe Jon should [up|down]grade to 8.5...

- Brian