Up to date and not ancient VHDL tutorial!

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