Up to date and not ancient VHDL tutorial!

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