Up to date and not ancient VHDL tutorial!

[ali_asadzadeh]

Hi,
I was searching the web for a decent and cool and new way of interactively learning VHDL or verilog, but I do not know why what ever I have found was old, like 2000 or before and it was actually boring!

So what am I missing? do we live in a brand new world for VHDL or verilog with a decent colorful and new and fun tutorial?

Any Ideas would highly appriciated! currently I'm interested in VHDL but I might consider Verilog after I have done some projects with VHDL.

[coppice]

Verilog and VHDL haven't really changed much since 2000. Why would you expect newer tutorials?

[rstofer]

You might Google for 'xilinx vhdl tutorial'

I haven't seen a comprehensive multi-part video tutorial but Xilinx publishes a lot of documentation for their devices and tools.

[RoGeorge]

So what am I missing?

You have wrong expectation. An HDL (Hardware Description Language) is not about cool and fun, it's about hard and tedious.

For example, VHDL is a strongly-typed language, which can make it very frustrating, especially at the beginning.
https://whatis.techtarget.com/definition/strongly-typed

You may want to try Verilog, which is considered to be a little "friendlier" than VHDL, but don't expect any "Python friendliness".

Not recent, but a good starting point: https://www.fpga4fun.com/HDLtutorials.html

[ataradov]

I doubt you will find "colorful" and "fun" tutorials on HDLs. It is not Arduino, you actually need to do a lot of prep work to get started.

If you want to ease into it, it is really better to get a cheap board and try the supplied examples. And then modify them in small increments to make sure that things still work.

[janoc]

This course is a pretty decent starting point using VHDL and the Xilinx tools:
http://hamsterworks.co.nz/mediawiki/index.php/FPGA_course

It is meant to go with the Papillio FPGA board and the LogicStart Megawing accessory for it but you can easily adapt that to your own board.

[KaneTW]

For example, VHDL is a strongly-typed language, which can make it very frustrating, especially at the beginning.

That's a huge benefit. Strongly-typed languages are much easier to learn.

[hamster_nz]

This course is a pretty decent starting point using VHDL and the Xilinx tools:
http://hamsterworks.co.nz/mediawiki/index.php/FPGA_course

It is meant to go with the Papillio FPGA board and the LogicStart Megawing accessory for it but you can easily adapt that to your own board.

Must.... update... to... use... signed.... and unsigned....

[ralphrmartin]

... try the supplied examples. And then modify them in small increments to make sure that things still work.

An excellent approach to any development work.

[james_s]

A book I found very helpful was Free Range VHDL, it's free to download too.

I personally find VHDL much easier to understand than Verilog but that's largely personal preference, so I'd suggest try both and see which you like better. Verilog looks a bit more like C, which can actually turn out to be more of a hindrance than help if you happen to know C already.

[hamster_nz]

TLDR: It isn't that the tutorials suck, it is most likely that they don't match your expectations.

Some of the 'problems' with HDLs for synthesis are:

* The building blocks are far more simple / restrictive

Everything has to be able to be efficiently implemented in the on-chip resources. LUTs, Flip-flops, routing resources, DSP blocks, block memory, shift registers. These are very simple, generic primitives (except for the DSP blocks). The functionality is in the structures you describe/

If you were given a box of 74 series D-type flip-flops and Quad 2-input NAND gates and told to build a CPU you would think "oh, she's a big job...", so it is unreasonable to expect that as a beginner you can sit down with an FPGA and create a CPU core as their first project. They will need largely the same knowledge, and if they don't have it you will have to learn it (or implement an existing, well documented design).

* If you usually write S/W you will feel that you have one hand tied behind your back, and three broken fingers on the other hand.

For example, you are only allowed to use a restricted subset of 'loops' - a bit like how there are (usually) no loops in machine code , but only jumps to other bits of code.

Dynamic allocation of FPGA resources doesn't happen - there is no equivalent of "new' or "malloc()" to give you resources when you need them at runtime - everything is statically allocated.

* You need to develop the mindset of thinking in the dimension of 'time' (well more precisely 'now' and 'the next clock cycle')

Timing is everything in HDL design. Timing is mostly irrelevant in most software code (unless you do a lot of multi-core development, or bit-banging) and you have learnt to mostly ignore it other than "oh are these nested loops fast or slow".

* Your code is far more nuanced than in software code

You end up having to 'refactor' (e.g. a codeword for "completely rewrite") things quite often. Often can't salvage an 'almost working' solution because the design is often fundamentally broken. Sometimes it uses excessive resources, or is obviously "the wrong way" to solve the problem, or it it works but not at the clock speed than you need it to work at.

* Debugging is completely different

You need to work out how to use simulation, virtual logic analyzers, and that big gulf between timescales of 1 millisecond and 1 second which is hard to debug

[james_s]

The thing you need to remember is that you're not writing a program.

You're using a language that superficially resembles a programming language, to describe a digital circuit made out of gates and flip-flops.

[rstofer]

It really helps if you have had a course or two in logic design.  Your best friends need to be FSMs, MUXs, Decoders and Registers.

It would seen strange to me to have any kind of FPGA project that wasn't loaded in FSMs.  State machines rule!

Once you know how to code these simple building blocks, the rest is just details.

Attached is a nice description of a RISC CPU including the block diagram and the state machine.  This project is realizable in an FPGA by replacing the bus with a MUX and a couple of changes in the existing MUXs - you'll see where the problem occurs when you start to write the FSM.

http://people.cs.georgetown.edu/~squier/Teaching/HardwareFundamentals/LC3-trunk/docs/LC3-uArch-PPappendC.pdf

This is a pretty nice project for learning.  I built it on a NEXYS 4 DDR from Digilent.  I used that board because it has 8 each 7 segment displays and a 16 toggle switches.  It is not the economy spread and many other boards will work just as well.  It is important to have enough RAM or BlockRAM to form a useful memory system.  The board I used will easily support 64k words of 16 bits.

https://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/

It's pretty straightforward moving from the state diagram to the FSM code.

There is also an LC3b project out there that adds byte operations.

[ali_asadzadeh]

Thanks guys for your feedback.

A book I found very helpful was Free Range VHDL, it's free to download too.

I have downloaded the book and started to read.

maybe there is some hidden cool ways to learn these out there, because I have got the Cortex M0 files from ARM, it's in verilog, also I think most or all of their cores are in verilog and since they are desiging new chips every year,and there is a ton of other companies making chips, so there should be lot's of great ways to teach their new stuff! shouldn't it be the way?

[ataradov]

because I have got the Cortex M0 files from ARM, it's in verilog

It is auto-generated for obfuscation reasons from a netlist or something like this. The original source could have been anything.  And generated stuff could have been VHDL just as easily.

ARM uses a mix of Verilog and VHDL from the code that seems to be hand written.

so there should be lot's of great ways to teach their new stuff! shouldn't it be the way?

Not really. Learning the language to a usable state takes a couple of  days (perfecting is harder, of course) and ultimately the language does not matter all that much.

What you really need to learn is how the hardware is architected and designed. And this takes a long time, but the language has very little to do with this. It is done with a pen and paper. For anything complicated writing the code right away is a wrong way to go.

[NorthGuy]

I think a common mistake is to start learning FPGA from the language perspective. These are called Hardware Description Languages. IMHO, it is better to start from the "hardware" you're describing. To make first steps and describe your first "hardware" you only need very basic subset of the language. I first used VHDL and I continue using it. It is enough to describe what I design, although it is quite clumsy. Looking at Verilog, it looks similar - I can understand the code rather easily, although I've never written anything in Verilog. Verilog does look a touch better, but I'm afraid it is the same as the grass on the neighbour's lawn which is always greener.

[rstofer]

Then there is Patterson & Hennesey, the book on MIPS processors:
https://www.elsevier.com/books/computer-organization-and-design-mips-edition/patterson/978-0-12-407726-3

Learn to code the building blocks first.  MUX, Decoder, FSM and Registers including counters.

Take a block diagram of a project and lay out the building blocks.  For CPUs, it will be obvious which block you need and where to put it.  Then it's just a matter of instantiating and interconnecting the blocks.

For people interested in ARM cores, there is this book:

https://www.amazon.com/gp/product/0128000562/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

Their earlier work on a MIPS like CPU

https://www.amazon.com/gp/product/0123944244/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

Both of these books include code in Verilog and VHDL.  The point of these books is to create a finished project.  They necessarily cover everything from architecture to HDL.

[ali_asadzadeh]

rstofer Thanks so much

[nctnico]

I think a common mistake is to start learning FPGA from the language perspective. These are called Hardware Description Languages. IMHO, it is better to start from the "hardware" you're describing. To make first steps and describe your first "hardware" you only need very basic subset of the language. I first used VHDL and I continue using it. It is enough to describe what I design, although it is quite clumsy.

The first two lines are exactle the reason why you find it clumsy. IMHO the trick is not to describe hardware but OTOH know what the synthesizer makes of it. In other words: do take the software approach because that will get you something which works quickly while writing only a few lines of code. But it still means peaking under the hood what the synthesizer has produced and reading the synthesizer manual from A to Z. Unfortunately I see very little VHDL code which is written in a clever way so the synthesizer takes care of the hard work.
 
To the OP: a good place to start is using a simulator so you are not bound by any hardware platform for the first steps.

[rstofer]

"HDL Chip Design" by Douglas J Smith shows multiple methods for coding the various building blocks.  Then he shows what kind of hardware the code will produce.  The idea is to look at both complexity and levels.  Levels of logic goes right straight to speed.

The book provides examples in both Verilog and VHDL and shows both correct and incorrect coding.

https://www.alibris.com/Hdl-Chip-Design-A-Practical-Guide-for-Designing-Synthesizing-and-Simulating-Asics-and-FPGAs-Using-VHDL-or-Verilog-Douglas-J-Smith/book/30212803

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

[nctnico]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

That is a good tip indeed. I use the RTL schematic viewer every now and then to check how a design is implemented and whether everything is connected the way I expect it.

[FlyingDutch]

Hello,

check these sites:

http://www.fpga4student.com/p/fpga-projects.html

https://www.fpga4fun.com/

http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects

You can find on these pages many interesting projects (VHDL/Verilog).

Regards

[ali_asadzadeh]

Thanks, I already new about the FPGA4fun

[james_s]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

[rstofer]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

I was staggered to see that a +1 binary counter I coded turned into an adder and a register.  I don't know what I expected but that wasn't it!

As the design gets larger, the utility diminishes.  There's just too much information.  Still, it is useful to drill down into the modules, clear down to gates and flops.  Just to see...

Absolutely, nice tidy modules, that's the key!

[Bassman59]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

I was staggered to see that a +1 binary counter I coded turned into an adder and a register.  I don't know what I expected but that wasn't it!

I'm not sure what else you'd get! An incrementer is no more than an adder with one of the inputs set to a constant 1. The other input comes from the adder output.

But -- the adder part is purely combinatorial. If you don't register its output, then you've got a combinatorial loop between the adder input and output, and that's bad.

Some FPGA families have specialist adder resources. Others do not. For the former, the synthesizer will preferably use the adder (until it runs out of them). The register may be part of the adder resource. For the latter, it will build the adder out of combinatorial logic, and stick registers on the output.

As the design gets larger, the utility diminishes.  There's just too much information.  Still, it is useful to drill down into the modules, clear down to gates and flops.  Just to see...

Yes, you can't look at the whole design without getting lost. But you can drill down into a specific module and see what the synth did with your code. I do this all the time.

[Bassman59]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

Look at the "technology" view, which shows how the tool mapped your nice RTL into the resources available in the chip!

[Sal Ammoniac]

Someone mentioned Free Range VHDL. I'll second that as I found it to be a very good tutorial when I was learning HDLs. Make sure you get the latest version, as there're many older versions floating around on the 'net and some of them are quite old.

http://freerangefactory.org/pdf/df344hdh4h8kjfh3500ft2/free_range_vhdl.pdf

I learned VHDL first and then Verilog, but overall I prefer Verilog. It's really a personal choice, however, as you can do the same thing in either language.

[rstofer]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

I was staggered to see that a +1 binary counter I coded turned into an adder and a register.  I don't know what I expected but that wasn't it!

I'm not sure what else you'd get! An incrementer is no more than an adder with one of the inputs set to a constant 1. The other input comes from the adder output.

I had thought it would be a ripple counter with a bunch of D-flops strung together with some logic, like the 74161 but with D-flops.  On reflection, I realized that the adder is a much better solution since the carry logic is built in to the LUT and the LUT doesn't really have J-K flops.

If I were building such a counter out of TTL, I certainly wouldn't be using a 74181 and 74182 to implement a binary counter and that's where I was coming from.

As I said, on reflection, I see exactly why it is done the way it is.

[Bassman59]

I only know about Xilinx tools but one of the things I can do is view the final logic diagram (called RTL Schematic).  It's a really nice way to see how the building blocks are implemented.  It will also show the block layout for large projects and allow you to drill down through modules.

Altera Quartus has a very similar tool and it's quite useful. My observation is that code that produces nice tidy looking results on the RTL schematic usually works well too.

I was staggered to see that a +1 binary counter I coded turned into an adder and a register.  I don't know what I expected but that wasn't it!

I'm not sure what else you'd get! An incrementer is no more than an adder with one of the inputs set to a constant 1. The other input comes from the adder output.

I had thought it would be a ripple counter with a bunch of D-flops strung together with some logic, like the 74161 but with D-flops.  On reflection, I realized that the adder is a much better solution since the carry logic is built in to the LUT and the LUT doesn't really have J-K flops.

You can't use a ripple counter in an FPGA, as it's an asynchronous counter and the Q output of stage n clocks the flip-flop for stage n+1. Static timing analysis doesn't work on that kind of circuit, and in many FPGA fabrics (notably recent Xilinx) the only access to the flip-flop's clock input is through a global net, not from general logic.

As I said, on reflection, I see exactly why it is done the way it is.

Always worth thinking on these things.

[chris_leyson]

If you want to learn about how to use logic resources in an FPGA then try a simple 8-bit micro like the Picoblaze from Xilinx. It's small and it's fast, 96 slices on Spartan3 and 26 slices on Spartan 6. Xilinx UG129 gives a good overview. https://www.xilinx.com/support/documentation/ip_documentation/ug129.pdf

Picoblaze will teach you some basic VHDL syntax by building an 8-bit microprocessor from simple logic elements and it will also give you tools to test analize your hardware. Test and analysis are the two of the most powerful aspects of VHDL that are often overlooked, in fact it's why VHDL was conceived in the first place, it's a hardware description language not a hardware synnthesis language.

[emece67]

.

[rstofer]

That book sells for $105 for paperback on Alibris, the hardbound version is a touch over $200.

https://www.alibris.com/Circuit-Synthesis-with-VHDL-Roland-Airiau/book/1108885

[NorthGuy]

As I said, on reflection, I see exactly why it is done the way it is.

The counter is actually much simple than adder, and can be made much faster in general logic than using carry elements. FPGA doesn't have gates, but rather uses LUTs. 6-input LUT can calculate any bit of a 6-bit counter at once. This is faster than carry chains. If you use faster clocks you often can see your adders replaced with general logic. Also, some of the Xilinx's LUT may be configured into 32-bit shift registers which can cascade and replace short counters.

Xilinx allows two different levels of schematics - one is a simple schematics done from VHDL - called "elaborated design". Here you will see adders, muxes, gates etc. This is an abstraction of VHDL and has nothing to do with real FPGA.

Another level is post-synthesis schematics where you will see the elements of real FPGA - LUTs, DSPs etc.

These two are completely different schematics. It's important to know which one you're looking at.

Also you can look at the real FPGA map where you get the post-implementation view - all the elements of the FPGA are there, you can see which are used by the design and how they're connected together.

[legacy]

In my first university course at computer science's campus (when I was younger, oh ... Erasmus in the South East region of England, the best experience ever) we used this book as the reference and it really gave us good points to be discussed in the classroom, making a practice of them during laboratories.

It's about Verilog, and the technology it talks about didn't include modern b-ram and resources offered by modern XILINX FPGAs, therefore it's more conservative on the design approach, but it this is good as it makes good points about the methodology, with criticism on the differences between FPGA-design and ASIC-design.

[Bassman59]

If you want to learn about how to use logic resources in an FPGA then try a simple 8-bit micro like the Picoblaze from Xilinx. It's small and it's fast, 96 slices on Spartan3 and 26 slices on Spartan 6. Xilinx UG129 gives a good overview. https://www.xilinx.com/support/documentation/ip_documentation/ug129.pdf

Picoblaze will teach you some basic VHDL syntax by building an 8-bit microprocessor from simple logic elements

Actually, PicoBlaze is an awful example of how to do a micro in an FPGA. Rather than using behavioral code to describe the logic, Ken Chapman's code instantiates FPGA primitives directly. It's as if he took an old schematic (remember when we did schematic entry for FPGAs?) of the design, which used those primitives, and had it export to a VHDL netlist. Good luck decoding the LUT4 instances with their INIT values to figure out what the hell it's doing.

The claim was that such direct instantiation of primitives was done for performance reasons, but everybody understands it was done to make porting to other FPGA vendors' devices impossible.

(That said, PicoBlaze works as advertised and I've used it many times.)

[james_s]

I hate FPGA code that directly instantiates primitives, it's an absolutely stupid practice that has no tangible benefits. Even amongst FPGAs from the same vendor, code with direct instantiation often will not synthesize for a different generation of FPGA from the same vendor without modifications. Write agnostic code and let the software figure out how to synthesize it.

[hamster_nz]

I hate FPGA code that directly instantiates primitives, it's an absolutely stupid practice that has no tangible benefits. Even amongst FPGAs from the same vendor, code with direct instantiation often will not synthesize for a different generation of FPGA from the same vendor without modifications. Write agnostic code and let the software figure out how to synthesize it.

I don't know Ken, but I am sure he is pretty smart when it comes to FPGA stuff. I would not be surprised at all if his requirements for PicoBlaze made this style of coding the right way to do things.

The initial release of PicoBlace was about 14 years ago, when FGPAs were much smaller, and tools were much simpler. The audience of potential users is large, and minimizing support tickets due to implementation issues is an important consideration.  It makes sense to pay careful attention and use very descriptive, structural HDL - even to the point of doing most the synthesis before the HDL is even written.

[Bassman59]

I hate FPGA code that directly instantiates primitives, it's an absolutely stupid practice that has no tangible benefits. Even amongst FPGAs from the same vendor, code with direct instantiation often will not synthesize for a different generation of FPGA from the same vendor without modifications. Write agnostic code and let the software figure out how to synthesize it.

I don't know Ken, but I am sure he is pretty smart when it comes to FPGA stuff. I would not be surprised at all if his requirements for PicoBlaze made this style of coding the right way to do things.

Again, the first requirement was: Xilinx only.

[asmi]

Again, the first requirement was: Xilinx only.

Unless you demonstrate the evidence of this, I call on this one. If they really wanted to make it Xilinx-only, they would've delivered the core as encrypted IP.

[NorthGuy]

I don't know Ken, but I am sure he is pretty smart when it comes to FPGA stuff. I would not be surprised at all if his requirements for PicoBlaze made this style of coding the right way to do things.

Again, the first requirement was: Xilinx only.

I think he's just one of the old-school guys who likes doing things efficiently (and I bet Xilinx wanted PicoBlaze to be very efficient). When you assemble everything from LUTs you immediately see where the bottleneck is.

[james_s]

Unless you demonstrate the evidence of this, I call on this one. If they really wanted to make it Xilinx-only, they would've delivered the core as encrypted IP.

It's blatantly obvious to anyone who has worked with this stuff. You an instantiate primitives directly, or you can write agnostic code and let the fitter instantiate these same primitives appropriate for the specific part being used. The end result is exactly the same, the difference is that agnostic code can be built for any suitable device while directly instantiating primitives locks it to that specific family unless you modify it.

[nctnico]

Again, the first requirement was: Xilinx only.

Unless you demonstrate the evidence of this, I call on this one. If they really wanted to make it Xilinx-only, they would've delivered the core as encrypted IP.

You could have looked up the source yourself. Picoblaze instantiates Xilinx primitives directly (Spartan2 / Virtex2 IIRC). I doubt it can even synthesize on modern Xilinx devices due to architectural differences. I've used Picoblaze myself in a couple of designs. Mr Chapman created Picoblaze to show off how you can utilize a 'small' FPGA to the max but it turned out the end result was very useful as well.

[chris_leyson]

Many years ago and just for fun I wrote a decimal version of the KCPSM3. I added a decimal flag to the status register and two additional instructions SED and CLD to set or clear the flag bit. In decimal mode you just do BCD add and subtract using a little bit of extra carry logic. I also added two shift instructions to do binary/BCD conversion and that neatly filled up a small gap in the instruction set. I emailed Ken Chapman and asked if was OK to publish the design, and he said it was OK as long as I state that it is for Xilinx devices only. I also asked why the KCPSM3 was written with primatives and he said it was so you got exactly the same logic no matter what syntheseis tool was used. Anyway, I never finished the design as there was a fair bit of additional logic to get the status register carry flags to work correctly and it just added too much delay. I've still got the VHDL somewhere so one day I might get around to finishing it.

[legacy]

I doubt it can even synthesize on modern Xilinx devices due to architectural differences.

yup, there are some examples of this even with projects at OpenCores.

[legacy]

RAMB4_S8 from Xilinx Web pack ISE 4.2.03i is a clue of "Xilinx Specific" 

[NorthGuy]

It's blatantly obvious to anyone who has worked with this stuff. You an instantiate primitives directly, or you can write agnostic code and let the fitter instantiate these same primitives appropriate for the specific part being used. The end result is exactly the same ...

Not exactly the same.

It's as if you would say that you can write code in assembler, or you can write agnostic code in C and let the compiler create the same assembler commands.

Even though the end result is the same when running at lower clock speeds, the well-written hand-crafted code with manual instantiations is likely to run at much faster clock speeds.

[james_s]

Well look at the RTL viewer, in most cases at least, the fitter infers exactly the same primitives, whether you specify them directly or create a generic element. How many ways can you create a RAM or ROM, or PLL? I suppose there are cases where you could get different results, but overall the software seems very good at coming up with an optimal solution provided the code is well written. At any rate I have yet to experience any issues whatsoever from changing directly instantiated primitives to agnostic HDL in code that I've ported to other platforms, if someone can find a specific example where directly instantiated primitives produces a demonstrably superior result then I'd like to see it. Otherwise I remain of the opinion that it is done primarily as a method of locking a design in to a specific vendor/product line, with likely some doing it out of habit formed in some earlier time when the software was less sophisticated and required more human optimization.

[legacy]

Even though the end result is the same when running at lower clock speeds, the well-written hand-crafted code with manual instantiations is likely to run at much faster clock speeds.

Reasons why the kernel of RiscOS v1-v2-3 was written in assembly? (ARM610, StrongArm)
Reasons why the kernel of the first gen of AmigaOS was written in assembly? (m68020, m68030)

ain't it? 

[james_s]

Earlier times, less sophisticated compilers. It's kind of an apples to oranges comparison between HDL and high level programming languages. Hand optimized assembly language is something that is quite rare these days and getting rarer all the time. The hardware is more complex and powerful and the compilers are more sophisticated, causing a much lower return on investment for a human to get in there and tweak things by hand. There are still cases where it might make sense, but these are going to be special cases where it's worth putting in big effort to squeeze out that last 1% performance boost.

[hamster_nz]

If someone can find a specific example where directly instantiated primitives produces a demonstrably superior result then I'd like to see it.

I don't think I would ever be able to loosen your dogmatic view that no benefit can be had by using primitives. However, here are some things that might help:

- A 31-page overview of the PicoBlaze/KCPSM design, written by the designer is available at http://bleyer.org/pacoblaze/picoblaze.pdf which talks about the trade off between architecture and resources may show the designer's original intention. It is not supposed to be portable, it was supposed to take maximum advantage of a given FPGA architecture.

- The design is Xilinx IP, and restricted by its license to only be used on Xilinx devices, so discussing portability to other vendor's FPGAs is a straw man. You are legally not allowed to do this.

- Synthesis tools are ignorant of the H/W layer, and like to do things like replace chains LTU-implemented shift registers, undoing the designers intent of synchronizing signals. Or if they do keep the registers as FFs, it does not put them as close as possible, lowering MTBF - unless you use some-what hit-and-miss vendor specific synthesis attributes.

- When memory blocks are inferred you don't know what they are called, so you can't use tools such as "memtool.exe" to replace memory contents without rebuilding the entire bitstream. As a workaround you can sometimes look at the final design and infer what the memory block was called but that is somewhat of a hack compared with just using a primitive.

- When you infer a 1024x18-bit memory that is initially all zeros it will be optimized away, so there will be no memory block you could push any desired contents into.

- A  smaller table of filter constants may end up implemented in LUTs, limiting the performance of DSP blocks because the tools can no longer use dedicated routing paths. (That is unless of course you once again resort to vendor specific synthesis attributes).

- You may explicitly want a chain of flip-flops to be flip-flops, so they can be placed across the die to help with timing. This can have you reaching for vendor-specific compiler settings and once again, vendor specific synthesis attributes.

- There are perfectly functional designs that can be implemented using primitives and/or manual placement that cannot be correctly inferred. As an extreme example,how about  "A 7.4 ps FPGA-Based TDC with a 1024-Unit Measurement Matrix" https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5424742/

....

And just in case you say "but these can all be addressed with synthesis attributes and implementation options" that leaves you in a worse position than using primitives - your design now depends on fine-level details in your build environment, and the correct incantation to use which will be different between vendors, tools and even tool versions.

Why not just build a small library of behavioral descriptions of the missing Xilinx primitives, and then you can build the design on any vendor that lacks them. They are simple enough to model, and if you truly believe what you assert, the result should be the same and still optimal.

[chris_leyson]

I wish I hadn't mentioned KCPSM3 it's almost turned into a flame war. The intention of my post was to highlight the underlying FPGA fabric albeit from a Xilinx perspective and I thought Picoblaze might have been a good example in that respect. Is it any help with VHDL, absolutely not and it really is a pain to work with instantiated primatives, I should know I've got the decimal KCPSM3D VHDL design open and I'm thinking I've got no documentation, no test code and worse still no assembler and now I've got to reverse engineer the primatives I added to figure out what is going on, what was I thinking Anyway, the design was done as a bit of fun and I just used the same style of coding, it didn't occur to me to patch in some simple RTL.

[james_s]

I don't think I would ever be able to loosen your dogmatic view that no benefit can be had by using primitives. However, here are some things that might help:

It's not a dogmatic view, if there is an easy way to demonstrate an advantage then I'll change my mind. Even now I can believe there could be specific cases where it has benefit, I just don't think there is an automatic benefit and see no reason to default to that approach. I am highly skeptical that the benefit extends to the sort of FPGA projects that interest me though, I've seen directly instantiated primitives used in retro computing and arcade projects where it is simply not necessary, on multiple occasions I have reworked existing code to make it agnostic without any apparent consequences.

If it is necessary to achieve one's goals then go ahead and do it, but don't just do it to show off or to lock into a specific vendor/family. Certainly with any sort of hobbyist/open source project one should strive to write agnostic code so it can be easily ported to whatever hardware one wants to use. This is one reason I've never bothered to use any of the platform specific cores, there are plenty of open and vendor agnostic processor cores that do the job.

[emece67]

.

[legacy]

I never liked such an approach, which I've seen in some avionics systems. I suspected that such strategy was used to "bypass" or "shortcircuit" some compliance tests during the DO-254 certification, as you can fully test each individual component and then rely on such 100 % coverage to claim 100 % coverage of the whole system

oh, well ... 

[nctnico]

I don't think I would ever be able to loosen your dogmatic view that no benefit can be had by using primitives. However, here are some things that might help:

It's not a dogmatic view, if there is an easy way to demonstrate an advantage then I'll change my mind. Even now I can believe there could be specific cases where it has benefit, I just don't think there is an automatic benefit and see no reason to default to that approach. I am highly skeptical that the benefit extends to the sort of FPGA projects that interest me though, I've seen directly instantiated primitives used in retro computing and arcade projects where it is simply not necessary, on multiple occasions I have reworked existing code to make it agnostic without any apparent consequences.

I agree. Instantiating primitives is like writing software in assembler. With the good synthesizers and fast FPGAs we have today it is much less necessary.

[james_s]

Emphasis mine. I second that. But, on the other side, the 100 % agnostic code, IMHO, cannot be achieved in many, many cases. The very same moment you need a memory or some chunky operator (say *, /, ...) you better use (or, at least, consider the use) of a vendor module, or your own implementation of such component.

Well yes, I do that of course, I use memory devices and PLLs, but I use the wizard to create them as components which are then instantiated in the main code, and they can be easily modified with those same wizards to suit other FPGA families. Porting to a different vendor is relatively simple too because while the components will not be identical, there is usually something equivalent. You can just create a 2k*8 RAM, etc, no need to instantiate specific BRAM blocks directly.

[NorthGuy]

I'm not sure about magical synthesisers and fast FPGAs. There was fast progress in the past, not so much lately. Xilinx's UltraScale+ is not even twice as fast as 7-series. Xilinx now have Vivado, which has lots of bells and whistles, some of them very useful actually, but it works noticeably slower than "ancient" ISE and doesn't really produce better results. Most of the progress in the tools goes towards "idiotisation" of the user - "you don't need to use VHDL because HLS allows you to program FPGA in C", or "you don't really need to program anything at all - just connect the AXI interfaces of the stock IPs".

My approach is very pragmatic. If you fill direct instantiation helps, there's no reason to avoid it. You may have to do some additional work if you want to port to another vendor. But this is not a good reason to do extra work right now. Rather take the advantage of the hardware you use at the present moment. When you port to another platform, you will take advantage of the new hardware.

[Bassman59]

I'm not sure about magical synthesisers and fast FPGAs. There was fast progress in the past, not so much lately. Xilinx's UltraScale+ is not even twice as fast as 7-series.

It's probably worth looking through the data sheets for the actual timing in the chips. There's a lot to digest, of course, but I'm not surprised that UltraScale+ isn't "twice as fast."

Xilinx now have Vivado, which has lots of bells and whistles, some of them very useful actually, but it works noticeably slower than "ancient" ISE and doesn't really produce better results.

it's impossible to a truly fair comparison between Vivado and ISE, unless you choose parts that both support (Artix 7 and Kintex 7, and some Zync, as I'm looking in the ISE 14.7 settings). I wouldn't expect synthesis to be better in one than the other, except maybe in language support, as they both have to understand the target architecture. The place-and-route should be about the same.

As for tools speed? That depends on how many CPU cores each can use, how much memory, and again, perhaps it's worth doing the test on a real, non-trivial-size design.

Most of the progress in the tools goes towards "idiotisation" of the user - "you don't need to use VHDL because HLS allows you to program FPGA in C", or "you don't really need to program anything at all - just connect the AXI interfaces of the stock IPs".

All of the FPGA vendors have this notion that everyone is in this "time to market" rush that demands the use of vendor-supply cores for functionality. The reality is that most designs really are application-specific, and while we may use some standard stuff, there is a lot of the design that isn't, and that's when the push-button wire-it-up-in-a-schematic-like-thing flow falls flat on its face.

And with the complexity of the on-chip hard processor cores, it's all so goddamn complex that unless you're a ninja, you've got no choice but to use their wire-it-up methodology. It at least guarantees that your bus addresses and such are all correct so your processor firmware works. I remember back with the old Xilinx EDK and the PowerPC basically creating a wrapper for all of my logic that needed to talk to the processor ... this wrapper had their bus interface and decoded addresses and all that. This seemed to be simpler than having a half-dozen different "cores" hanging off of their bus.

I do not miss any of that at all.

But, anyway, Vivado's real problem is less the speed at which the tools run but for its horrific idea of usability. The user interface is AWFUL and it's clear they didn't have actual users go through it early on and actually test it. And bad UX stuff gets ingrained in the design and never goes away. And don't get me started on its hostility towards source-code control, something that Xilinx got right, finally, by ISE 14.7.

[ebclr]