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.

Reply to
RL
Loading thread data ...

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.

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.

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

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

-- Mike Treseler

Reply to
Mike Treseler

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.

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

Reply to
Jeff Cunningham

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 :-)

formatting link

Hans

formatting link

Reply to
HT-Lab

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
Reply to
Nico Coesel

On 15 Sep, 00:36, RL wrote: ...

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.

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

Reply to
James Harris

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

formatting link

Reply to
Bob Perlman

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...

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.

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.

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

Reply to
RL

Hi RL,

I agree with you there. But then you go on to say:

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

Reply to
Andrew FPGA

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

Reply to
Jeff Cunningham

fair enough. how would you load the microcontroller?

-Jeff

Reply to
Jeff Cunningham

.. snip

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

formatting link

Reply to
HT-Lab

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

formatting link
formatting link

-jg

Reply to
Jim Granville

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.

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.

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:

formatting link

Good luck, Bob Perlman Cambrian Design Works

formatting link

Reply to
Bob Perlman

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.