I'm going to try FPGA for the first time - question

[alank2]

I've seen the example project at Grant Searle's site here:

http://searle.hostei.com/grant/Multicomp/index.html

And I'm going to order this here:

https://www.amazon.com/RioRand-EP2C5T144-Altera-Cyclone-Development/dp/B00LEMKR92#Ask
https://www.amazon.com/gp/product/B00IRODADK/ref=ox_sc_act_title_1?ie=UTF8&psc=1&smid=A240XKQA2DV1DP

Question #1 - once you program this with the USB blaster, does it stay?  If you power cycle it, will it remember the way it was programmed?

Question #2 - I've been watching some VHDL tutorials on YouTube.  Is VHDL a language designed to prevent someone from having to lay out the gates manually?  Much like C is to assember, VHDL is to the gates themselves?

Any other ideas or tips for someone just starting out with FPGA?  I'm familiar with AVR's...

[rstofer]

1)  There is an EPROM on board so, yes, the program should be retained.  BUT...  You will probably be given a map of the JTAG chain and you get to choose which device (EPROM or FPGA) you wish to program.  During development it is common to just program the FPGA because you don't care if you lose the program and it is generally faster to program.  You program the EPROM when you want to save the program.

2) Verilog and VHDL are both hardware descriptive languages.  They describe hardware, that's all.  For some toolchains you can still do schematic entry.  That tends to take a long time...

I like to think of VHDL as a Pascal like approach to hardware description.  To me, Verilog is more like C.

[Neilm]

Schematic entry and VHDL/Verilog will be synthesised (think compiled but it isn't) into logic terms. These are then fitted into the FPGA by the place and route procedures.

I would tend to avoid schematic entry as this is usually locked to the suppliers tool chain, so if you change supplier you have to re-enter the logic from scratch. With VHDL and Verilog you just change any manufacturer specific commands and re synthesize.

[rstofer]

One thing to think about:  Put a 330 Ohm resistor in series with every pin you bring off the board.  Such a low resistance on an output probably won't impact external circuitry, especially if it is CMOS but the resistor will protect the FPGA pin should you accidentally short an output.

[alank2]

Are FPGA's pretty touchy to a short?  I've used AVR's for years and never killed a pin though I have shorted an output a few times for sure.

[rstofer]

Well, the boards tend to cost a lot (a whole lot more than the one at Amazon) and I certainly wouldn't want to let the magic smoke out.  Most of the newer Digilent boards have the resistors on every pin leaving the board (at the PMOD connectors).

Are they more sensitive than AVRs?  I have no idea.  For the cost of some resistors, I hope to avoid the question.

Digilent isn't totally consistent:  They don't do it here:
https://reference.digilentinc.com/_media/cmod_a7/cmod_a7_sch.pdf

They do it here (using 200 ohm resistors):
https://reference.digilentinc.com/_media/basys3:basys3_sch.pdf

[hamster_nz]

I've accidentally shorted unprotected pins many times, with no ill effect. The outputs are current limited to about 50mA (at least for those I have tested). They seem to be pretty robust for the performance that they offer.

However some of that robustness might come from the power supplies being used. Most of the boards have pretty advanced regulators on them which can shut down quickly, I imaging it might be very different if it was being powered by a 10A PSU...

[Kilrah]

Digilent isn't totally consistent:  They don't do it here

Digilent offer both "Standard PMOD" that has the resistors and "Hi-speed PMOD" on which signals are routed as differential pairs and don't have the protection resistors so as not to disturb high speed signals.

16.1 Standard Pmod
The standard Pmod connector is connected to the PL of the Zynq via 200 Ohm series resistors. The series resistors prevent short circuits that can occur if the user
accidently drives a signal that is supposed to be used as an input. The downside to this added protection is that these resistors can limit the maximum switching speed
of the data signals. If the Pmod being used does not require high-speed access, then the standard Pmod connector should be used to help prevent damage to the
devices.

16.4 High-Speed Pmod
The High-speed Pmods use the standard Pmod connector, but have their data signals routed as impedance matched differential pairs for maximum switching speeds.
They have pads for loading resistors for added protection, but the ZYBO ships with these loaded as 0-Ohm shunts. With the series resistors shunted, these Pmods
offer no protection against short circuits, but allow for much faster switching speeds. The signals are paired to the adjacent signals in the same row: pins 1 and 2, pins
3 and 4, pins 7 and 8, and pins 9 and 10.
Traces are routed 100 ohm (+/- 10%) differential.
These connectors should be used only when high speed differential signaling is required or the other Pmods are all occupied. If used as single-ended, coupled pairs
will have significant crosstalk. In applications where this is a concern, the standard Pmod connector shall be used. Another option would be to ground one of the
signals (drive it low from the FPGA) and use its pair for the signal-ended signal.
Since the High-Speed Pmods have 0-ohm shunts instead of protection resistors, the operator must take precaution to ensure that they do not cause any shorts.

[Sal Ammoniac]

As an FPGA beginner myself, here are my thoughts. First, going for the cheapest board available, unless you're a starving student, is rarely a good idea. I suggest you consider a board from a more established vendor with a few more built-in peripherals and I/O devices. You'll pay more, but you'll have more options and better quality. Look at Digilent and Terasic -- they both make quality boards that are well-supported.

It's best, too, to go with a board with a recent FPGA. Some cheap boards use older FPGAs that have limited support. Same goes for the tools. For example, Xilinx no longer updates their ISE software--they've moved on to Vivado. Unfortunately, Vivado doesn't support the Spartan series, so you need at least an Artix.

As far as choosing an HDL, you can't really go wrong with either Verilog or VHDL. VHDL is more Ada-like while Verilog is more like C. Verilog is easier to learn, but VHDL has better type checking and won't let you make mistakes as easily as Verilog will. I myself prefer Verilog as I like its more concise syntax better. With either of these, you typically don't lay out gates directly--the synthesis tool does that. You describe the functionality of the circuit at a higher level. For example, the Verilog statement c <= a + b; will infer an adder and place it into your design--you don't have to specify the adder at the gate level. Whichever HDL you choose keep in mind that these are not programming languages--these are languages used to describe hardware. If you try to write algorithmic code in Verilog or VHDL like you would in C, you're going to find yourself in a world of hurt. Your designs will be inefficient and probably won't even synthesize.

[alank2]

Do you get a choice between VHDL and Verilog?  Or is that choice made by which brand FPGA you select?

[george.b]

Do you get a choice between VHDL and Verilog?  Or is that choice made by which brand FPGA you select?

You can choose alright, it's not a brand thing.

[Kilrah]

Every manufacturer's software I've seen can take and use/generate both VHDL and verilog.

I agree with going with a recent device and tools if you want to learn something that you can put to use efficiently afterwards. Obviously the advantage of that board is that it's exactly what the creator of the project you're interested in has used so you might be able to get it working faster and wih less effort than if porting it to another board - BUT that is not a given, since in this world it can be a bigger pain to port things between 2 different development tool versions than different hardware...

[pix3l]

I've used Lattice FPGAs which can be programmed (or described ;-) in both Verilog and VHDL

[Buriedcode]

The board you linked is similar to one I have, which is a bare basic FPGA, with config memory, all IO's broken out, and 128MBbit SDRAM.   You'll notice it has two 10-way IDC headers, one is for JTAG - directly configuring the FPGA, and one is for AS - programming the configuration device.  If you use the JTAG one, it'l configure the FPGA but won't remember configuration on power-up, it will instead read the onboard config chip.   This is handy for development because as far as I am aware, there is no limit as to how many times you can do this.   If you want the configuration to be permanent - so it 'remembers' your design, and loads it in on power up, you'll want to plug your USB blaster into the other header 'AS' (active serial) which puts the config in non-volatile memory.

As others have said, whilst a nice bare board is probably all you need, it does make life difficult, especially if you're just starting out, because you could make a very complicated design... but how would you know it works? You'll need to hook up outputs, LED's, display, dedicated serial output etc.. and inputs like buttons, otherwise it is essentially a 'black box' that gives you no real indication of what its doing and whether your design is functional.  Some bells and whistles aren't really needed, many go overboard with multiple displays, VGA out (which is actually quite handy) endless switches etc..

Also, with FPGA's as you probably know, whilst there are dedicated functions on some pins, for the most part, you have to manually assign each pin in your design.  If you have a few LED's, and a button, fine, but as soon as you start adding things like external memory, buses, assigning pins gets old real fast.  You can import assignments into Quartus but even then you have to manually assign the pins at first and manually export.  So if you can find a board that is widely used, there will be multiple example projects, assignment files (so you can load in a file for that board and it knows what is connected to what) and support.  I highly recommended you get something like the DE-0 nano: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=593

There are many example projects to get you started, both in VHDL and verilog, and all the support files (assignments).  It will save you a lot of time, at the expense of possibly shielding you from some of the donkey-work involved.  But at least it lets you focus on writing HDL.  Don't make the mistake I did and start of with a very cheap board.  It'll be functional, but you'll spend just as much time checking pinouts with a multimeter and hooking up external boards as you will developing modules.

Edit: Forgot to say back in uni we used VHDL and used it for some later projects of my own.  I switched to verilog because frankly, it *is* C-like, but it isn't really 'code', its a hardware description language, you can't think of it as 'C', more a C-syntax-like-way of describing behavior.  It also seems to have better support in Quartus for simulation, but only in specific areas that you probably won't use anyway.

[mikeselectricstuff]

The board you linked is similar to one I have, which is a bare basic FPGA, with config memory, all IO's broken out, and 128MBbit SDRAM.   You'll notice it has two 10-way IDC headers, one is for JTAG - directly configuring the FPGA, and one is for AS - programming the configuration device.  If you use the JTAG one, it'l configure the FPGA but won't remember configuration on power-up, it will instead read the onboard config chip.   This is handy for development because as far as I am aware, there is no limit as to how many times you can do this.   If you want the configuration to be permanent - so it 'remembers' your design, and loads it in on power up, you'll want to plug your USB blaster into the other header 'AS' (active serial) which puts the config in non-volatile memory.

The normal development flow is to program the FPGA RAM during development, for speed. In some cases ( e.g. lattice EC) it is possible to use the same programming header to program external flash - the programming software first loads a simple bit file into the FPGA which maps the programming port pins to the serial flash device, to allow access through the FPGA   I don't know if Xilinx or Altera support this on any of their devices. 

[Sal Ammoniac]

The normal development flow is to program the FPGA RAM during development, for speed. In some cases ( e.g. lattice EC) it is possible to use the same programming header to program external flash - the programming software first loads a simple bit file into the FPGA which maps the programming port pins to the serial flash device, to allow access through the FPGA   I don't know if Xilinx or Altera support this on any of their devices. 

This is exactly how it works for Xilinix FPGAs too.

[alank2]

Is the U3 on the backside of the board the EEPROM for holding the program then?

[bingo600]

Alan i did this course -

Using a mix of  MAX240 board , the same fpga board as you , and a S3E
http://www.pyroelectro.com/edu/fpga/

http://www.pyroelectro.com/forums/viewforum.php?f=26

It was nice to get experience with VHDL

I'm using Altera Quartus 13.0sp1  - Anything newer didn't have support for the older CPLD's

/Bingo

[alank2]

Hi Bingo!

Alan i did this course -
Using a mix of  MAX240 board , the same fpga board as you , and a S3E
http://www.pyroelectro.com/edu/fpga/
http://www.pyroelectro.com/forums/viewforum.php?f=26
It was nice to get experience with VHDL

Are these free?  They look pretty nice.

I'm using Altera Quartus 13.0sp1  - Anything newer didn't have support for the older CPLD's

This is the version that Grant's site talks about as well - I need to download it but it is many GB!

Thanks,

Alan

[bingo600]

Yepp the course is free , and Chris would prob. review your ansvers if you posted them.

I did upload my solution to most of the homework to.

Ohh this VHDL book is free : http://freerangefactory.org/

http://freerangefactory.org/books_tuts.html

http://www.gstitt.ece.ufl.edu/courses/eel4712/labs/free_range_vhdl.pdf


Fun .....
The first time i have ever "compiled" my own book , to get the latest edition
https://github.com/fabriziotappero/Free-Range-VHDL-book


/Bingo

[Sal Ammoniac]

Ohh this VHDL book is free : http://freerangefactory.org/

This is one of the best books for learning VHDL. Highly recommended.

[mikeselectricstuff]

Had a quick skim through that book & there is at least one aspect that is not explained well.
It repeatedly describes statements in a process block as being sequential, implying sequential in time - the author even admits he can't quite get his head round this.
What they are is a list of statements in order of increasing priority, not time. Once I understood that, things became a lot clearer.



 

 

[Sal Ammoniac]

Had a quick skim through that book & there is at least one aspect that is not explained well.
It repeatedly describes statements in a process block as being sequential, implying sequential in time - the author even admits he can't quite get his head round this.
What they are is a list of statements in order of increasing priority, not time. Once I understood that, things became a lot clearer.

This is why a lot of good programmers have a hard time understanding HDLs and FPGAs -- they're stuck in a mindset where everything happens sequentially one step at a time.

[rstofer]

Had a quick skim through that book & there is at least one aspect that is not explained well.
It repeatedly describes statements in a process block as being sequential, implying sequential in time - the author even admits he can't quite get his head round this.
What they are is a list of statements in order of increasing priority, not time. Once I understood that, things became a lot clearer.

Yes, subsequent assignments refine prior assignments in a kind of priority scheme.  But that's just one aspect.  Consider the following clocked process where the assignments result in a sequence (ignore syntax):

process(clk, In)
  A    <= In;
  B    <= A;
  C    <= B;
  Out <= C;
end process;

Assume A,B,C & D are '0' and when you walk through 4 clocks, you will see the value of 'In' "sequentially" walk toward 'Out'.  I see this type of code used quite often in Verilog and not so much in VHDL.  Maybe I'm not looking hard enough.

[hamster_nz]

process(clk, In)
  A    <= In;
  B    <= A;
  C    <= B;
  Out <= C;
end process;

Assume A,B,C & D are '0' and when you walk through 4 clocks, you will see the value of 'In' "sequentially" walk toward 'Out'.  I see this type of code used quite often in Verilog and not so much in VHDL.  Maybe I'm not looking hard enough.

It does show up in VHDL a bit. I've come to the conclusion that pretty much everything that can be re-written to "hide" this behavior should be, if only for the sanity of a newbie or when running step-by-step simulations.

So your example of:

Code: [Select]

process(clk, In)
begin
  if rising_edge(clk) then
    A    <= In;
    B    <= A;
    C    <= B;
    Out <= C;
  end if;
end process;

Is better described as:

Code: [Select]

process(clk, In)
begin
  if rising_edge(clk) then
    Out <= C;
    C    <= B;
    B    <= A;
    A    <= In;
  end if;
end process;

Even though the end result is identical.

For my code, I have a style of "where possible, never access a signal after it is assigned a new value, and if you do, put a "-- initial value" comment, just to let the reader know it is not the one that has just been assigned".

Some people find this annoying and point out "but that is not how HDLs work! that is what makes it different from software! If they don't know about delayed assignment then they shouldn't be here".

My reply is usually "Meh".