Verilog/VHDL and using FPGAs - How interconnected are these two

[pigtwo]

Hello again!

I have a pretty general question about Verilog and FPGAs.  I'm interested in FPGAs and I want to start reading something about them but I'm a little confused about how Verilog(and any other HDL) relates to FPGAs. 

Pretty much what I’m asking is if I want to know how to use a FPGA dev board, do I need to learn Verilog and read about FPGAs in general or are these pretty much the same thing(IE any book about Verilog will cover basic FPGA information). 

I realize my question is kind of vague and that reflects my understanding of the subject. 

For example, I was going to read This book on Verilog and read This books on just general FPGA stuff. 

I'm concerned that there might be a significant overlap in this books. 

Another example to try to clarify: I was looking at the data sheet for the Spartan 3E and I notice something called a clock network.  Besides what I glean from the words 'clock network', I have no idea what this is.  Would a Verilog book go over things like this, or would a different type of text be more appropriate.

Thanks!

[marshallh]

Verilog itself (and vhdl) are themselves hardware description languages. The effect is a lot like using HTML to "describe" how the entire page looks. It is not sequential list-based execution.

90% of the verilog language is not synthesizable - you could simulate it, but there is no way to physically embody that description in modern FPGAs (well, affordably).

FPGAs are blank slates to an extent, augmented with various extra features like regularly placed ram blocks (measured in tens of kilobytes at most) and DSP/multiplier blocks. The meat and potatos of the FPGA is the majority of the die area, usually a multiple-input LUT that has SRAM inputs.

Basically, you need to do more reading.

A clock network is a "special case" interconnect on the silicon - it provides a low skew clock to logic all over the die. You can feed clock networks with external clock signals, or drive them with PLLs onboard. A quick note on the Spartan3 DCMs - they are "cheapo" PLLs - that's why they aren't called PLLs.  You can use them to a limited extent to multiply and divide clocks but they are not the greatest and all hell breaks loose if you try chaining them.

Modern design techniques focus on synchronous (clocked) logic.

The link between verilog and FPGAs is this : the synthesizer ( quartus_map or xilinx XST or synopsys synplify) takes the verilog and figures out how to implement it with the chosen device technology - building up from very small dumb blocks.
You end up with a netlist and settings for the LUTs. Next, the fitter (quartus_fit or xilinx P&R) decides how to lay out the elements and connect them as per the given netlist. This is a lot like physically placing components on a pcb and trying to untangle the ratsnest of connections.

[mikeselectricstuff]

Yes you do need to learn either VHDL or Verilog to do anything useful with FPGAs.
You don't need both. All FPGA tools can use either, and even a mixture, so you can incorporate other peoples' components into a design in the other language fairly easily
You also need to know about logic hardware design - state machines, registers, multiplexers, memory etc.
You need to work out what hardware logic you need to do what you want, and then express that logic in the HDL.
There may still be some FPGA tools that support schematic entry but this is of limited use and has pretty much died out.
You need to concentrate on the aspects of VHDL or Verilog that are synthesisable, so a book/tutorial aimed specifically at FPGA design will be much more useful than more generic language material, as much of the latter  will not be useful.
For VHDL I'd recommend "VHDL for programmable logic" by Kevin Skahill -  out of print but available cheap used at Amazon.
Anything with "FPGA" and "VHDL" or "Verilog" in the  title is a good start.
I don't know enough about both languages to suggest which to learn - I chose VHDL mostly due to finding a good book - from what I know now maybe Verilog might have been a better choice.
 

[pigtwo]

Ah I see.  I think I understand (at least a little better) now.

I was very confused for a little while about why Verilog/VHDL would have unsynthesizable things in it.  I was under the impression that HDLs were used solely for implementing on FPGAs.  But from reading both your posts it seems HDLs are mainly used for simulating circuits and FPGAs(IE the  synthesizer ) just uses these languages to implement the circuit.

Is this correct?  I think that is the main point of my confusion.

I'll have to look around for a good book. 

[marshallh]

Both languages are also used for creating testbenches to verify/test HDL that will be synthesized.

There are lots of practical considerations that require you to only use s small subset of the language.

VHDL is more popular among european developers. It is strongly typed and is designed to not allow any ambiguity, in theory preventing bugs from working into the code.

Verilog is more flexible and less strict, it is also very easy to shoot yourself in the foot with. What would cause a show-stopping error in VHDL will just cause most verilog compilers to throw a warning (easily ignored when you have 200-300 warnings anyway)

I use verilog, but it takes a careful mindset and deep understanding to not write yourself into a hole

[nctnico]

What I've always liked about VHDL is that it is more like a programming language than Verliog. With VHDL you can do a lot with just a few lines of code. People tend to just go ahead and create a whole bunch of equations while a simple function can do exactly the same. Working with FPGAs needs a mindset which is more geared towards software engineering than using logic chips or equations to do the work. The synthesizer is smart enough to come up with an efficient solution.

[vvanders]

If you decide to go with VHDL I highly recommend this book:

http://www.amazon.com/Circuit-Design-Simulation-Volnei-Pedroni/dp/0262014335

It does a really good job of describing how the language works and common tasks but also how things synthesize based on usage.

As someone coming from a more traditional software background I've found it to be the best reference by far.

[flynnjs]

I was very confused for a little while about why Verilog/VHDL would have unsynthesizable things in it.  I was under the impression that HDLs were used solely for implementing on FPGAs.  But from reading both your posts it seems HDLs are mainly used for simulating circuits and FPGAs(IE the  synthesizer ) just uses these languages to implement the circuit.

HDLs are for describing hardware, not just FPGAs. FPGA are obviously a subset of hardware and therefore not everything can be synthesised into one.

I started with VHDL but have since generally writen in Verilog as I find it slightly less verbose and therefore quicker to write.
For introductory projects there's not much between them but things start getting different when you wish to break out of plain synthesis and start scripting test data and doing other stuff that creeps in with bigger projects.

 As Mike said recently "Who left out #define and #include?" or something to that effect :-)

[nctnico]

From what I've read its easier to write test benches using Verilog.

About include/define: in VHDL its quite easy to make configurable designs and optionally leave things out of include them. One of the bigger projects I worked on used an external SRAM to store all kinds of data in different areas of the memory for several channels. I made the design configurable so the memory areas in the SRAM got sized depending on how many channels where required. A wise decision because the design started with 16 channel, then 30 and later on 96 channels. All I needed to change was one number to make it work.

[mikeselectricstuff]

In my limited experience of FPGA software, one of the more annoying things I find is the poor support for product variants - in particular a way to have the same design with different pin setups for prototype and production PCBs, or different FPGA sizes. Devboards typically have bigger devices than will be used in production, so it's a clear need. Things like being able to enable .disable debug functionality are also less easy than they should be.
This is trivial with programming languages like C, but current FPGA tools seem to be in the stone age in some respects.

[nctnico]

In my limited experience of FPGA software, one of the more annoying things I find is the poor support for product variants - in particular a way to have the same design with different pin setups for prototype and production PCBs, or different FPGA sizes. Devboards typically have bigger devices than will be used in production, so it's a clear need. Things like being able to enable .disable debug functionality are also less easy than they should be.
This is trivial with programming languages like C, but current FPGA tools seem to be in the stone age in some respects.

Its not hard to ditch the IDE and use a batch file / shell script, makefiles or TCL scripts to put FPGA projects together instead. One of my former employers had close to 100 different products which shared a fair amount of the same FPGA design. At compile time the proper files where copied into the project and then synthesized/fitted into the proper FPGA design.

[mikeselectricstuff]

In my limited experience of FPGA software, one of the more annoying things I find is the poor support for product variants - in particular a way to have the same design with different pin setups for prototype and production PCBs, or different FPGA sizes. Devboards typically have bigger devices than will be used in production, so it's a clear need. Things like being able to enable .disable debug functionality are also less easy than they should be.
This is trivial with programming languages like C, but current FPGA tools seem to be in the stone age in some respects.

Its not hard to ditch the IDE and use a batch file / shell script, makefiles or TCL scripts to put FPGA projects together instead. One of my former employers had close to 100 different products which shared a fair amount of the same FPGA design. At compile time the proper files where copied into the project and then synthesized/fitted into the proper FPGA design.

I'm sure you can, but FFS it's 2013 - I shouldn't have to! FPGA tools need to come out of the Dark Ages

[nctnico]

Actually you could use #define and #include if you pre-process the file afterwards. The C pre-processor is a seperate program which will happily process any file you feed it. CPP (C Pre Processor) is nothing more than a fancy search & replace tool. I've used it to add pre-processor capabilities to a compiler I wrote for a proprietary PLC.

[Hardcorefs]

No one has mentioned that the TEST BENCHES for the FPGA code is also written in VHDL.

Working with FPGA means you MUST work with simulation tools first, then compile the design later, Unfortunately 'compile times' are in the dark ages when compared with modern compilers.

So the work flow is:
IDEA
DESIGN & SIMULATE
COMPILE
LOAD to FPGA

you cannot work 'live', because it takes too damned long.

IDEA
DESIGN
COMPILE
LOAD TO FPGA

Another mistake many new people make is to include delay statements or loops in the VHDL, it  completes synthesis and runs  but cannot be placed into an FPGA

something like this, cannot be placed into an FPGA:

Code: [Select]

for I in 0 to 128*pSCRYPT_PARAMETER_r-1 loop
Addr := I/pOCTET_PER_LINE+4;
Index:= CONV_INTEGER(CONV_STD_LOGIC_VECTOR(I,32) and CONV_STD_LOGIC_VECTOR(pOCTET_PER_LINE-1,32));
Octet := test_octet_stream2(test_octet_stream'length-I*8-1 downto test_octet_stream'length-I*8-8);
MYRAM(Addr)(Index*8+7 downto Index*8) <= Octet;
end loop;
      -- hold reset state for 100 ns.
i_ARst <= '1';
      wait for 100 ns;
i_ARst <= '0';
      wait for i_Clk_period*10;

The other issue is the complete 'crapness' of IDE tools, whilst they may have 'glossy' 2013 GUI's ,many just tie back to batch executed scripts, and in some cases windows tools are tied to crap like only working in 1GB of ram, whilst you have 16GB in the machine.

It is trying to accomplish simple things that make you want to cry......
 I.E if I have a section of logic that executes at high speed, WHY can I not just use D&D to place existing compiled code, then add other logic around it, WHY must I drop down to the command line, and WHY can I not save sections from past compiles and just recompile modifications.. Instead of waiting 16 hours for a complete re-compile.

[Bassman59]

I was very confused for a little while about why Verilog/VHDL would have unsynthesizable things in it.  I was under the impression that HDLs were used solely for implementing on FPGAs.  But from reading both your posts it seems HDLs are mainly used for simulating circuits and FPGAs(IE the  synthesizer ) just uses these languages to implement the circuit.

Is this correct?  I think that is the main point of my confusion.

Both languages were originally designed for system modeling and simulation. Synthesis was added later. As the languages evolved, the support for synthesis greatly improved.

[lgbeno]

Don't let anyone's comments discourage you from getting into FPGAs, it's a very useful and marketable skill.

I would say that verilog is a little more natural of a language than Vhdl but you will need to learn one of them for sure.

 About the hardware vs simulation, going straight to hardware is frustrating because often you'll want to know what is going on inside you code and simulation will give you much better insight. I'm still always tempted to go straight to hardware anyway because its more exciting and I think that's fine if you are that type of learner.  Best thing is just try it out!

Stick with Dave's advice though, start with a known good code reference and modify things from there.

I'm also a big advocate for the terasic de0 nano board it's cheap and has a lot of goodies.

[pigtwo]

Oh I'm still very interested in FPGAs.  I'm mainly interested in them because they seem very useful for testing circuits.  Like you could build half a circuit in real life and the other half on an FPGA to test if you built the first half right.

I think I'm going to go with Verilog just because of the syntax.  But I'll certainly try both.  I thought the same thing about AT&T assembly but then I ended up liking it a lot more than Intel syntax. 

Coincidentally I already bought the de0 nano a while back.  This actually leads me to another question. 

How different are FPGAs made by different manufacturers (IE Xilinx and Altera) ? If I learned how to use one, how hard would it be to use the other after that?

[mikeselectricstuff]

How different are FPGAs made by different manufacturers (IE Xilinx and Altera) ? If I learned how to use one, how hard would it be to use the other after that?

Hardly at all. Unless you care about the higher end of performance (hundreds of MHz upwards) It's mostly about the size, pincount, memory/package options and peripherals like clock generators, memory, special IO functions like DDR memory interfaces, PCI etc.
The bread & butter functionality is basically the same.
The HDL hides the low-level detail. The only differences are in the I/O options, how the clock generators (PLLs,DCMs), memory  and other 'extras' are implemented. In many cases you won't be using many, if any of these.

In some cases you can the code more portable as, for example, things like memories and multipliers can be invoked either using native VHDL operations (arrays and * operations), or explicitly by including the appropriate components. However with the former approach you need to check that the compiler has interpreted your code as you expected - manufacturers typically give guidelines on how to do this. 
 
The step from nothing to _any_ fpga is much, much bigger than between different families or manufacturers.

It's similar to the situation with micros and C - the language is mostly the same, the peripherals are the main difference.
Again like micros, devtools are at least as big a difference as the hardware -
I've never used Altera, but Xilinx and Lattice are based on the same software, so if you know one, the other is an easy switch.

[flynnjs]

Also, if you use any canned libraries (which manufacturers are pushing more
and more to allow faster development at the expense of being able to
port out to a competitor!) then you'll quckly run into portability issues.
Same goes with embedded processors...stick with a 3rd party design
from Opencores or something rather than get locked into NIOS/Blaze.

-

  I'm mainly interested in them because they seem very useful for testing circuits.  Like you could build half a circuit in real life and the other half on an FPGA to test if you built the first half right.

You might be better not going to an FPGA at all and just use the simulator stage