Good intros to FPGAs?

[Infraviolet]

I've never done anything with FPGAs before but feel I ought to learn about them at some point.

Can anyone recommend good online resources for learning about their principles, and recommend a brand of FPGAs which are compatible with linux-compatible open source software toolchains (none of the software I'd need for programming them would be anything which can't run on a linux PC or which needs some connection to a remote server, even just for an initial activation, which might go down) and which offers fairly decent availability on a wide variety of different chips/boards. Effectively like arduino, but for FPGAs.

[free_electron]

There are no open source toolchains except for a limited one or two device from latticce. and those toolchains are made by external people (not latticce) whoe reverse engineered the bitstream.
The guts of an FPGA are the secret sauce owned by the device maker.

Learn verilog or vhdl. the rest is just sending it through the synthesizer. The source verilog or vhdl is portable , the bitstream is not.

[Someone]

Effectively like arduino, but for FPGAs.

There is nothing like this for FPGAs. There are some higher level abstractions such as Migen/LiteX which are trying to move into that space but they still end up using the vendor tools (not open source) to actually implement the design.

Do you like programming all your own libraries in assembler/C ? If no, FPGAs are probably not for you, its even lower level with fewer instructions/libraries/hard peripherals.

[ataradov]

Yeah, forget about OSS software for FPGA. Lattice tools don't need an internet connection on their own, but they do require you to request a licence via a web site every 6 months. Others are very similar.

[Infraviolet]

So unlike a lot of microcontrollers you're saying its not just the guts inside the chip's black resin body they keep secret, but also the protocol for "flashing" it and the compilation chain?

[Foxxz]

Look at lattice if you want an open source toolchain (yosys). I recommend the ICE40 line of FPGAs. The lattice produced dev boards are well documented. But you are probably better off using the manufacturer tools like icecube2. I'm using the radiant toolchain right now and its kind of a pain in the butt because most documentation you find is for icecube2 and most of the primitives used in icecube2 have changed or don't work in radiant and they primitives are used in examples everywhere on the internet.

This guy's videos are a good primer
https://www.youtube.com/c/Nandland

Be aware every model of FPGA deb board is going to have differences on which pins attach to what. So examples for one model of board may not work on yours when it comes to things like UARTS, LEDS, etc.

Get comfortable with the idea that you will be spending alot of time simulating your designs as debugging in hardware is difficult.

[ataradov]

The actual programming algorithm is not secret. But you are not programming "registers". Tools generate a binary file that you program into the device memory. The structure of that file is not documented. The actual low level architecture of the block interconnects is also not documented.

You can try yosys, but if you are just starting, it may not be the best thing. It is missing a ton of features. Unlike for compilers, where free tools are orders of magnitude better than commercial stuff, for FPGA proprietary tools are the only real option for now.

[Foxxz]

So unlike a lot of microcontrollers you're saying its not just the guts inside the chip's black resin body they keep secret, but also the protocol for "flashing" it and the compilation chain?

Loading the design itself into an FPGA is trivial and usually well understood. But how the bitstream is generated for any specific FPGA is proprietary and the format is not well understood. FPGAs have LUTs, routing fabric, memory, and hard IP blocks like DSPs, SPI, I2C, PWM, and whatever else the manufacturer has decided to include. Bitstreams aren't so much instructions but a bunch of bits that setup all the LUTs, load values into memory, connect all the parts to the routing fabric, and enable the IP blocks.

[free_electron]

easy start : get a terasic board for altera (now owned by intel) .
get an older version of quartus software . it exists on linux. license is free.
you can start as simple as drawing a schematic using 74xx ttl chip.
has built in verilog and vhdl synthesizer and simulator ( the later versions of quartus require mentor modelsim. there is a free version but that makes it even more complicated. )

you'll probably need specific versions of linux like redhat. may be a pain to get running on others. that stuff is target towards commercial users that frequently already have other tools like Cadence or Synopsys, specman and other stuff that is only supported on redhat.
This is not a 'let me compile it' , can i have the source ? world.

learning verilog : Verilog for synthesis by Bhasker is very good. no nonsense , no blabla that is not synthesizable, and simple to understand.
and use systemverilog 2005 or later that has always_ff and always_comb constructs and learn how to use scheduled logic instead of complicated if-then elseif trees. the logic becomes self explaining and you get it right first time in 99% of the cases without hidden pathways or even needing simulation

[SiliconWizard]

You can try yosys, but if you are just starting, it may not be the best thing. It is missing a ton of features. Unlike for compilers, where free tools are orders of magnitude better than commercial stuff, for FPGA proprietary tools are the only real option for now.

Yes. It would even be a very bad idea, actually. While yosys/nextpnr has become pretty good, you can still consider it experimental, and not particularly easy to use either for a beginner. If you're just starting with FPGAs, that would be like doubling the difficulty.

And if you're looking for some point-and-click environment a la Arduino, it's just the opposite of that.

So yeah, learn with vendor tools first. Once you're experienced enough with FPGAs and HDLs, you can always consider yosys if the FPGA you wanna use is supported, if you're comfortable with command-line tools and if open-source tools really matter that much to you. And still, be prepared for some head-scratching here and there and spending more time than you had expected on github opening tickets.

[hamster_nz]

easy start : get a terasic board for altera (now owned by intel) .
get an older version of quartus software . it exists on linux. license is free.
you can start as simple as drawing a schematic using 74xx ttl chip.
has built in verilog and vhdl synthesizer and simulator ( the later versions of quartus require mentor modelsim. there is a free version but that makes it even more complicated. )

you'll probably need specific versions of linux like redhat. may be a pain to get running on others. that stuff is target towards commercial users that frequently already have other tools like Cadence or Synopsys, specman and other stuff that is only supported on redhat.
This is not a 'let me compile it' , can i have the source ? world.

learning verilog : Verilog for synthesis by Bhasker is very good. no nonsense , no blabla that is not synthesizable, and simple to understand.
and use systemverilog 2005 or later that has always_ff and always_comb constructs and learn how to use scheduled logic instead of complicated if-then elseif trees. the logic becomes self explaining and you get it right first time in 99% of the cases without hidden pathways or even needing simulation

Wise advice. Also, don't cheap out and get a no-name development board from AliExpress or ebay, unless you have a helpful mentor who can assist you with getting started. Go Digilient board (for AMD/Xilinx) or Terasic board (for Intel/Altera).

[BrianHG]

...has built in verilog and vhdl synthesizer and simulator ( the later versions of quartus require mentor modelsim. there is a free version but that makes it even more complicated. )

As Modelsim is available free with Altera/Intel Quartus and Lattice Diamond and Xilinx ISE, I do recommend learning how to program and work within Modelsim natively as it has it's own built in really fast Verilog and VHDL compilers.

I know this is an extra step prior to transferring your HDL code to your selected FPGA vendor, but you will begin with the ground difficult step of simulation your first design with a simulator tool separate of your chosen vendor's FPGA tool.  I went the other way around and began relying on Altera's Quartus to simulate my designs and looking back, suffered where recompiled could have been under a second each testing of my code and the ability to sniff hidden registers for debugging after-the-fact which wasn't a well flushed out capability in the full FPGA compiler tools.

I believe downloading Quartus 13.0 through 20.1 (latest Quartus has switched away from Modelsim) includes a download option for a free Modelsim as well as Lattice Diamond v3.12 and later.  I'm not sure which Xilinx packages include a free Modelsim.

[rstofer]

Buy the GO board, follow the examples in verilog or vhdl at the site
https://nandland.com/

https://freecomputerbooks.com/Free-Range-VHDL.html  The book is free in PDF format

There are more capable boards at https://digilent.com/shop/boards-and-components/system-boards/fpga-boards/

My favorite is the Nexys A7 board.  I choose it for the shiny features like buttons, switches, LEDs, Displays etc.  Having onboard IO is pretty useful.  It's pretty expensive compared to an Artix A7 or the GO board but, in my view, worth every penny.  But I don't have a bunch of them...  The BASYS boars are pretty handy as well.

https://vhdlwhiz.com/basic-vhdl-tutorials/

[RoGeorge]

See if this place suits you:
https://www.fpga4fun.com/FPGAinfo1.html

Keep in mind that:
- FPGA is not software.  You do not write "programs" for FPGA, you write schematic, with flip-flops and logic gates and so on, except you'll use text to describe the schematic, instead of drawing lines like you do with other electronic schematics.

- you'll need to know/learn digital design, meaning logic gates, flip-flops, multiplexers, counters, state machines, Mealy Moore state machines, synchronous design techniques (e.g. clock domain crossing, metastability, etc.) and so on.  It's not software, it's hardware.  It's all digital schematics written in text, and called HDL (Hardware Design Language).  For example, Quartus still retains a graphic editor, where you draw flip-flops, and logic gates, and circuits from the 400 TTL family to design your schematic instead of describing your schematic wit VHDL or Verilog "code".

- the two main HDL languages are VHDL and Verilog.  Verilog is easier to beginners, but some companies are using VHDL only.

- again, these are not programming languages, and they are not "executed" in order, line by line, like the code is usually executed in other programming language.  In HDL, the language is for drawing digital schematics.

- there are some tools called High Level Syntheses that can convert, for example, a C program into a HDL schematic, but not every C program can be converted, and this way will usually waste too much FPGA area.  Anything serious will usually need to be written in VHDL or Verilog.

- FPGA's are much, much more complicated than any Arduino, both when learning about them, and when using them in practice.

- main two FPGA manufacturers are the former Xilinx and Altera.  Both of them have a free version of IDE+tools.  For Xilinx it's called Vivado, for Altera is called Quartus.  Both are running in Linux

- in FPGA, IDE+tools are proprietary, and very expensive.  There is something free for ICE40, but that's it.  Nothing that I know of for more recent FPGAs

- you can write HDL, synthesize it, then instead of downloading the bitstream (a bitstream is the equivalent of a binary in microcontrollers, but it's not a program, it's more like a map/table of on/off switches), you can simulate your design any hardware.  It's as easy as downloading Quartus for example ( https://www.intel.com/content/www/us/en/products/details/fpga/development-tools/quartus-prime.html ), then trying to use it.

To prepare against disappointments, keep in mind that learning FPGA will take many weeks or months, if not years.  It's not something that can be learned in a weekend.

[laugensalm]

Seems there are many different perspectives.
The closest to an Arduino-simple approach I was getting is using Python HDL and Jupyter Notebooks with the basic OSS tools set up in a container to:

• Write a hardware description in MyHDL
• Synthesize via yosys and display inferred hardware elements
• Run simulation, display waveform traces
• Download to ECP5 FPGA

The setup is found at https://github.com/hackfin/hdlplayground, when you hit that blue binder button, it will start a virtual machine to play with. For the intro, you might want to look at the 'embedded world 2021' stuff, this shows some basic steps on how to create hardware using Python and how the corresponding VHDL/Verilog output looks like.

When running it locally, developing code and getting it verified is a matter of seconds. Actually, yosys isn't so much experimental if you do some diving into the internals, it's a very powerful and fast tool, for example, I'm getting a complex RISC-V SoC synthesized in under a minute whereas the Lattice tools take ~5 times longer.

However there are limitations in this Docker setup, and it's no longer maintained, although the Python code you'd write is reusable for the next generation. For professional development you'll likely be back at the vendor tools and still quite a bit of VHDL/Verilog coding for particular integration scenarios.

[ataradov]

Suggesting MyHDL to beginners is plain sadism. It might be close to Arduino, but realistically to get anywhere in FPGA world you need to get away from Arduino mindset.

Yosys/arachne-pnr workflow is missing very basic things that are necessary for majority of real project. Things like timing constraints are not implemented.

Vendor tools for FPGAs suck, but realistically they are the only option.

[hamster_nz]

Suggesting MyHDL to beginners is plain sadism. It might be close to Arduino, but realistically to get anywhere in FPGA world you need to get away from Arduino mindset.

Yosys/arachne-pnr workflow is missing very basic things that are necessary for majority of real project. Things like timing constraints are not implemented.

Vendor tools for FPGAs suck, but realistically they are the only option.

^^^^

I hate to say it, but this is the correct answer.

[laugensalm]

Suggesting MyHDL to beginners is plain sadism. It might be close to Arduino, but realistically to get anywhere in FPGA world you need to get away from Arduino mindset.

Agree on the last one, but your first statement demonstrates you haven't tried, and my experience with students has shown otherwise. Or you mixed up with migen?

However, I agree that the legacy MyHDL code base isn't fit for the future and for complex projects, therefore the 'jupyosys' approach is currently revisited with a different kernel (myhdl compatible up to some point).
In general, let's forget about Arduino, as it obscures quite a bit on the innards. Here, we'd like to do the opposite, write a functional description, verify, see what it's inferred to. However, in some cases when dealing with pipelines, abstraction levels help, though one should be able to read Verilog or VHDL.

Let aside arachne-pnr, but nextpnr is significantly more powerful. PnR level optimization is in fact becoming less of an issue to me, but I agree that you have to stick with the vendor tools if you need to integrate classic V*-Code for proper timing closure.

[pcprogrammer]

This site is also nice to learn about verilog: https://www.asic-world.com/verilog/veritut.html

[chris_leyson]

Xilinx Picoblaze 8 bit processor user guide UG129 for the KCPSM3 version of the processor is a good introduction. HDL is open source and available in VHDL and Verilog.

[tggzzz]

I've never done anything with FPGAs before but feel I ought to learn about them at some point.

Good for you, but realise that it is a steep learning curve and that experience writing programs does not translate to creating hardware. To start with, hardware is inherently parallel, and software programmers have great difficulty creating parallel programs.

Well, that's not quite true. Enterprise level computing has finally evolved to look more like hardware: you interconnect (i.e. wire together) pre-defined blocks in parallel, and the enterprise framework implements the parallel processing.

Can anyone recommend good online resources for learning about their principles, and recommend a brand of FPGAs which are compatible with linux-compatible open source software toolchains (none of the software I'd need for programming them would be anything which can't run on a linux PC or which needs some connection to a remote server, even just for an initial activation, which might go down) and which offers fairly decent availability on a wide variety of different chips/boards. Effectively like arduino, but for FPGAs.

All decent toolchains will have to be proprietary. Many, if not all, will run well in Linux.

The key point is that while the LUTs will be well described and defined, they are only a tiny part of the problem.

One major issue is the interconnection fabric is complex and device specific, and is more important than the LUTs.

Another major issue is the layout/placement, which is critically dependent on the delays in the interconnect fabric. It takes longer for a signal to cross the chip than it does to go through a LUT. You have to specify timing constraints, and how those drive the layout is critical and a manufacturer's secret sauce. Often it is necessary for you to tell the toolchain where to place LUTs, so that it can place components sufficiently well to meet the timing constraints, and do that within a reasonable elapsed time.

So, pick a manufacturer's toolchain that will run on your hardware. That will dictate which families of devices you can use. Then buy a module with a suitable FPGA on it; don't attempt to make your own.

[agehall]

I think it is worth emphasizing that FPGAs are programmable logic which is in many ways very different from how you learn to use something like an Arduino. I would say it is very useful to be well versed in traditional programming (C/C++) but one always have to remember that it is really logic gates you are creating which means you have to think a bit differently.

Get a decent board from Digilent or some other big manufacturer and start playing with it, following tutorials. FPGAs are fun but takes a lot of practice. They are not super difficult to get started with these days but there are also a lot less tutorials a la Arduino, so expect to do some more “advanced” reading to understand things.

Once you get past the basics, it becomes much more about knowing the tool chain and the specifics of your FPGA and the what the tool chain provides you with. All of them have their own special sauce that you can use to make things easier and better but it takes a lot to learn this for a hobbyist.

And, lastly, don’t forget to ask questions here. There are plenty of people here with tons of experience that share their knowledge. I think I owe quite a few people here a beer or two for the knowledge I’ve accumulated by just reading their posts here.

[ali_asadzadeh]

After learning the basics, the best blog and gold mine on hole web is zipcpu.com blog, you would thank me later for the tip

[tggzzz]

I think it is worth emphasizing that FPGAs are programmable logic which is in many ways very different from how you learn to use something like an Arduino. I would say it is very useful to be well versed in traditional programming (C/C++) but one always have to remember that it is really logic gates you are creating which means you have to think a bit differently.

C programming expertise is valuable, but not when it comes to programming FPGAs in an HDL. What, for example, is the FPGA equivalent of a C for loop?

(And if C++ is the answer, I want to examine the question in detail )

[agehall]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

[rstofer]

But, just like Arduino, your first project is to get an LED blinking.  Then you move on to designing simple, then more complex, CPUs and systems.  But first the blinking LED.

Once you have selected a board, which implies a chip manufacturer and a specific toolchain, post back and somebody can help with 'blinky'.

Realistically, there are only a few constructs to learn.  You just manipulate the basic structure to fit the application.  Getting the FSM (Finite State Machine) working is probably the most complex and I'm going to recommend a 2 process design.  You can research 1, 2 or 3 process FSMs.

https://vhdlwhiz.com/n-process-state-machine/

At the NandLand site, there are a number of tutorials for the GO board.  Including a blinking LED:

https://nandland.com/your-first-vhdl-program-an-led-blinker/
https://nandland.com/go-board-tutorials/

[free_electron]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

that's what state machines are for. create counter ,load counter, wait for counter to reach zero then next state

[pcprogrammer]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

[Someone]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot. For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
I use them pretty regularly for all sorts of functions that other people would/could/did write out as repetitive verbose error prone structures. The only difference is that the are always parallel/concurrent evaluations of the loop, no possibility of putting a wait inside there for synthesis yet delays inside for loops are pretty routine for simulation (where until and always loops are very common).

[emece67]

.

[tggzzz]

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot. For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/
I use them pretty regularly for all sorts of functions that other people would/could/did write out as repetitive verbose error prone structures. The only difference is that the are always parallel/concurrent evaluations of the loop, no possibility of putting a wait inside there for synthesis yet delays inside for loops are pretty routine for simulation (where until and always loops are very common).

The context is discussing why experience with C is not helpful when creating FPGAs in an HDL.

Your reference correctly states "For loops do not behave the same way in hardware as in software."

In C it is quite reasonable to write "for ( i=0, i<32768, i++) {...something complex...}". Not so much in an FPGA!

[tinker357]

Hi,
This is my first post so please be gentle.

Keep in mind that:
- FPGA is not software.  You do not write "programs" for FPGA, you write schematic, with flip-flops and logic gates and so on, except you'll use text to describe the schematic, instead of drawing lines like you do with other electronic schematics.

- you'll need to know/learn digital design, meaning logic gates, flip-flops, multiplexers, counters, state machines, Mealy Moore state machines, synchronous design techniques (e.g. clock domain crossing, metastability, etc.) and so on.  It's not software, it's hardware.  It's all digital schematics written in text, and called HDL (Hardware Design Language).  For example, Quartus still retains a graphic editor, where you draw flip-flops, and logic gates, and circuits from the 400 TTL family to design your schematic instead of describing your schematic wit VHDL or Verilog "code".

For my first meaningful FPGA program, I chose to add more functionality to an open source oscilloscope project.  Being a long-time firmware programmer, I am used to programming in C, and toggling GPIOs and viewing on a logic analyzer to debug.

I needed to do the following, which I could figure out how to do like a programmer, but I had no idea of how this could be done writing a schematic:
  Use 1 to 10 4K BRAMs, (which allows up to 8KB samples if using 4 channels, or 40KB if using one channel.
  Turn the BRAMs on and off at the appropriate time, and from experiments it seemed I had to turn on the BRAM one clock cycle before I actually wanted to store to it.
  If doing peak detect, use two BRAMs per channel, one for high voltage, and one for low voltage.
  If doing hi-res, average multiple samples per interval.

In addition, since I was acquiring samples at 100 MHz, looking for trigger, storing samples to BRAM each cycle, and then sending all the data out over a serial port, it seemed much easier to use GPIO toggles to debug rather than figure out how to create a simulation to do all this.  Also, most of my bugs seemed to occur when I was switching from one BRAM to another, or the samples to store before the trigger occurred in a different BRAM in the linked list of BRAMs.

Since verilog looks so much like C, I just relied on the compiler to turn it into hardware, which seemed to work fine in most cases.  The only real problem I had was that it seemed that when I saved the offset and BRAM number of when the trigger occurred, sometimes  it did not get saved correctly, but when I added a GPIO toggle when this occurred, it worked (kind of like it was getting optimized out).  I tried looking at the netlist RTL viewer, but it is gigantic and hard for me to follow.

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
 

[agehall]

There are numerous things you need to be aware of and that will trap you if you think like a programmer.

First of all, assignments may not happen instantly. This is a big thing and can cause a ton of issues.

Secondly, you always have to remember that you are building hardware, not writing a program even though you are programming. This implies things like having true concurrency in many cases which can work for or against you.

Again, I think having a C/C++ background can be very helpful, as long as one understands that it is hardware you are building with your code. Don’t do things like a huge for-loop as there is no such thing in hardware. State machines are your best friend and don’t be afraid of using them.

Again, we all have different ways of learning and how we relate to old knowledge. For me, C/C++ translates very well into SystemVerilog and some patterns come in handy. For a less experienced programmer and/or someone without experience in building hardware logic circuits this may not be true.

[RoGeorge]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

So bad?  I didn't say it's good or bad, I wrote it's different, and told the main differences.  Hardware and software are not the same, and sometimes this difference matters.

Now about the notions of bad vs good (because you seem preoccupied if the method you used was bad).  Good and bad only make sense in regards to a given goal.  There is no such thing as absolute good or evil.

If the goal was to read the datastream (and the tools were able to hide the differences between software and hardware), that's very well.  Nothing wrong to achieve a goal faster, or easier.  Well done with your proj, by the way.   

There are even easier ways to make use of an FPGA, for example National Instruments' LabView FPGA is all graphic, will let one drag and drop blocks and do the most amazing things with an FPGA, without the need to write a single line of code.

However, if the goal is to learn about FPGA, then refusing to take into account the differences between how synthetizable HDL works vs how a software programming language works will be bad.  And also technically incorrect.

[pcprogrammer]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

[rstofer]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

Because a software programmer is generally looking at a single line of code being executed and then the next line, etc.  Clearly, threads expand this view but not all that much.

HDL programmers understand that thousands of lines of code are executing concurrently.  Consider:

Code: [Select]

ACC_Zero <= '1' when ACC = "0000000000000000" else '0';This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff.  It just sets up a signal to indicate the accumulator is zero.  I never look back at that code while I consider how my FSMs deal with it.  It exists, it is guaranteed to be available under all conditions and anywhere I want to use it.  I can pass it as an input to other components, whatever.  It simply exists and is constantly evaluated.  If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it.  It just happens because it is nothing more than a really wide NOR gate following synthesis.

The thought process changes substantially between hardware and software.

[pcprogrammer]

...(I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)
 

Using the same master clock edge and non blocking assignments are proper things to use, but to assume that timing is not an issue is wrong. When looking at it from a hardware standpoint one has to think about propagation delay, setup and hold times, clock skew and many more aspects that come into play.

It all depends on how the logic is placed in the FPGA what the delay's between logic blocks, memory blocks, interconnects, etc are going to be. By telling your FPGA tools what the timing constraints on your clock and signals are it can take this in account and try to optimize the placing and routing.

Think of the FPGA as an array of dedicated TTL ic's with a big routing matrix between the pins. A signal that has to go through a block at the lower left corner and then through the interconnect up to a block on the upper right corner will take its time. This limits the maximum frequency a design can run at. The same applies to the clock signal. Even though there are special clock routes through the FPGA there can still be a delay in the rising of the signal at one end of the trace to the other end of the trace.

In programming a processor this is not an issue because, to state it simple and bluntly, every instruction has a fixed duration and everything is done sequential.

[agehall]

Could someone tell me why thinking of the flow as a programmer would instead of how a hardware engineer would is so bad? (I did trigger almost all actions to occur on the clock edge, and used <= for non-blocking assignment, so timing was not an issue.)

Because a software programmer is generally looking at a single line of code being executed and then the next line, etc.  Clearly, threads expand this view but not all that much.

HDL programmers understand that thousands of lines of code are executing concurrently.  Consider:

Code: [Select]

ACC_Zero <= '1' when ACC = "0000000000000000" else '0';This piece of code, in my case, is near the top of the code, after the declarations but before I get into the messy stuff.  It just sets up a signal to indicate the accumulator is zero.  I never look back at that code while I consider how my FSMs deal with it.  It exists, it is guaranteed to be available under all conditions and anywhere I want to use it.  I can pass it as an input to other components, whatever.  It simply exists and is constantly evaluated.  If I do some operation that affects the accumulator, the ACC_Zero signal will follow along without my having to reevaluate it.  It just happens because it is nothing more than a really wide NOR gate following synthesis.

The thought process changes substantially between hardware and software.

And to add to that - you could add that statement anywhere in source file. The fact that everything is evaluated concurrently is something that can throw a traditional programmer off quite a bit as they are normally used to read code sequentially while in HDL, you need to consider what happens at every signal change.

[Someone]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

[tggzzz]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

[Someone]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

Your short one liner makes a broad and misleading generalization. There are loops, they are almost exactly the same as C. Understanding the difference between synthesizable and non-synthesizable constructs/features is the underlying matter. You're just as wrong as the people who try and make generalizations about resets.

VHDL/Verilog can be used as high level languages, but there isnt a readily available or open source library ready to go as the OP specifically asks about (in reference to Audrino). At which point pretty much every single thing you said is incorrect:

Obviously there is no loop in the FPGA world like there is in C/C++. This is where one has to drop the high-level programming thinking.

[tggzzz]

Well there is the Phase Locked Loop

Or its just a stupid "argument" to stir the pot.

It was just a joke, but apparently not a good one

Your joke was good! The throwaway/shitpost comment you were replying to was the misleading/silly one. They were trying to add confusion and contention/argument to a thread where a beginner is asking for guidance, not really helping at all.

Sometimes knowing what to avoid is very valuable information. Life is too short to make the same mistakes other people have made - but making new mistakes isn't dishonourable.

Your short one liner makes a broad and misleading generalization. There are loops, they are almost exactly the same as C. Understanding the difference between synthesizable and non-synthesizable constructs/features is the underlying matter. You're just as wrong as the people who try and make generalizations about resets.

Loops might be used when testing FPGAs, but that is outside FPGAs.

Of course there are loops in HDLs. But if they aren't synthesisable they aren't in FPGAs.

If loops are synthesisable, then their semantics are very different to those in C.

VHDL/Verilog can be used as high level languages, but there isnt a readily available or open source library ready to go as the OP specifically asks about (in reference to Audrino). At which point pretty much every single thing you said is incorrect:

HDLs and C are Turing Complete, so of course they are equivalent. But the abstractions are very different.

While you could write a transaction processing system in Prolog or an HDL, doing so would be (at best) only of academic interest.

Understand the abstractions and what they are not suitable for. That's bog standard engineering: use the right tool for the job, and don't resort to imaginative hillbilly constructions.

Whether or not a "library" (to use your word) is or isn't open source is irrelevant. The FPGA equivalent of a library is the hardware building blocks (sometimes called IP blocks) provided by the device manufacturer

[Someone]

Whether or not a "library" (to use your word) is or isn't open source is irrelevant.

That's what the OP asked about... hence the replies discussing that rather than your pet flavour point.

Of course there are loops in HDLs. But if they aren't synthesisable they aren't in FPGAs.

If loops are synthesisable, then their semantics are very different to those in C.

Its the wall of text needed to clairify that possible corner case which you omit that is the problem. Loops do exist in HDL, they are synthesiable, and do the same job as in C....   iterating over a section of code in a controllable way. The significant difference that everyone keeps pointing to in the thread is that the majority of HDL code (there are examples/structures that do not have this characteristic) is executed in parallel, which is not something specific to loops but applies to almost all aspects of HDL coding.

Can you have a syntheisable loop with a wait statement inside to blink an LED? no, but that's true of any HDL structure. Yet you only talk about loops as if they are somehow treated differently.

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

[pcprogrammer]

The main key here is semantics.

This line explains it.

For loops in synthesizable code are used to expand replicated logic.

It is not the for loop itself that is synthesized. It is the logic in it that is implemented repeatedly.

As a programmer who originated from being trained as a hardware engineer, I also choose verilog to start with doing FPGA again, just because it looks a lot like C. The truth is I had to free myself of the programmers way of looking at things, even though I have used FPGA in the past. The difference is that I, at that time used schematics to implement the FPGA and with that you are in a "hardware" mode and not a "programmers" mode.

I think that before starting with FPGA's and HDL's it is better to first learn a bit about digital hardware in the gates and flip-flops sense. This way you also get familiar with things like propagation delay and setup and hold times.

Assuming that when you know how to program and understand a bit about micro processors and some electronics that it is easy to move on to FPGA's is very wrong.

[Someone]

For loops in synthesizable code are used to expand replicated logic.

It is not the for loop itself that is synthesized. It is the logic in it that is implemented repeatedly.

that may be an overly narrow view of loops, since "replicated" isn't always the result of a loop, and you can have loops in functions or with blocking assignments that work even more like sequential instructions in C. A loop is a programming construct that can be used for all sorts of different purposes, in HDL its often used to express things which would be awkward or verbose in other ways.

One common example:
https://stackoverflow.com/questions/14113125/short-way-to-write-vhdl-priority-encoder
which could be written in HDL or C, and a common solution in the other direction:
https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObvious
Equally could be implemented in HDL or C.

So there are real uses of loops, being able to be directly translated between C and synthesiable HDL (in either direction) with no functional difference. Implementation/efficiency differences, but still using loops to solve the problem.

[pcprogrammer]

The priority encoder is a nice example.

Wat one has to understand as a difference between it running on a processor or a FPGA is that on the processor it is a sequential evaluation of the if statements and takes the given number of loops to come to the result, where as, if I'm not mistaken, in the FPGA it happens "instantaneous" meaning all the if's are evaluated concurrently.

The HDL compiler will translate it into a bunch of "gates" to evaluate the signals.

Or am I totally wrong here?

[Someone]

Wat one has to understand as a difference between it running on a processor or a FPGA is that on the processor it is a sequential evaluation of the if statements and takes the given number of loops to come to the result, where as, if I'm not mistaken, in the FPGA it happens "instantaneous" meaning all the if's are evaluated concurrently.

That's true if the ifs/loops contain only combinatorial non-blocking assignments. Throw in blocking assignments, or sensitivity/registers and it gets more complicated (before talking about delays in simulation, or generate for loops). Loops and functions with blocking assignments can read and function just like C, the choice is there for the coder to pick what they think is best. Most people would agree a loop is much better than those repeated ifs in the priority encoder example, even though they will synthesize to the same structure.

[RoGeorge]

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

I see it different.

Here's a quote from the link you posted:

For loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.

To make an analogy, that type of "for" loops are rather like the preprocessor directives for C (if it were to make a parallel with C).  I wouldn't say C has an "#include" or a "#define" keyword.  Those directives are for the preprocessor, not for the C compiler.

I'm thinking about a "for" in a HDL in a similar way I'm thinking about a macro in C.  Except in HDL the "macro" is usually written in the same HDL language as the synthetisable HDL parts, while a C macro uses different keywords than C.

I wouldn't say a macro in C is to be compiled, I'll say is to be expanded/transformed into more C code, then compiled.  Same with the "for" loops in HDL.  Those are not turned directly into gates and flip-flops.  Those "for" loops are expanded (unrolled) into more HDL source code, and only after that the HDL is synthesised into interconnections between gates and flip-flops in the FPGA, just like a C macro after expansion would be turned into more C code then eventually compiled into executable binaries.

If one uses C macros as if it were C code, that will get unpredictable results, or compiling errors.  Same in HDL with the "for" loops, which should be considered rather a macro for HDL, and not like synthetizable code.

As long as one notices the difference between C macros vs C code, and uses them properly, I don't care if one insists to say a macro in C is eventually compilable code.  Well, one might say that, but that looks twisted to me.

I'll say a C macro is not compilable code, same as a "for" loop is not synthetizable HDL.

[Someone]

We can trivially point to synthesiable loops, in C syntax, as I already did:

For loops are pretty much identical to their C structure and function:
https://nandland.com/for-loop-2/

The clue is in the heading in that link:
"Using For Loops in Synthesizable Code"
So you're wrong, but you keep shouting about how you're not without actually adding anything concrete or new. Signal to noise is dropping rapidly here.

You misunderstood.  That's a quote from the link you posted:

For loops in synthesizable code are used to expand replicated logic. They are simply a way of shrinking the amount of code that is written by the hardware designer. Again, until you understand how exactly this expansion of replicated logic works, do not use for loops.

To make an analogy, that type of "for" loops are rather like the preprocessor directives for C (if it were to make a parallel with C).  I wouldn't say C has an "#include" or a "#define" keyword.  Those directives are for the preprocessor, not for the C compiler.

I'm thinking about a "for" in a HDL in a similar way I'm thinking about a macro in C.  Except in HDL the macro is usually in the same HDL language as the synthetisable HDL parts.

I wouldn't say a macro in C is to be compiled, I'll say is to be expanded/transformed into more C code, then compiled.  Same with the "for" loops in HDL.  Those are not turned directly into gates and flip-flops.  Those "for" loops are expanded (unrolled) into more HDL source code, and only after that the HDL is synthesised into interconnections between gates and flip-flops in the FPGA, just like a macro would be in C.

If one uses C macros as if it were C code, that will get unpredictable results, or compiling errors.  Same in HDL with the "for" loops, which should be considered rather a macro for HDL, and not like synthetizable code.

You're only just considering a subset of the uses of a loop in HDL (and making plainly false generalised statements). Synthesiable loops can have variable numbers of iterations and make complex control structures, just because you haven't seen it or used it doesn't mean they don't exist. Its not just a trivial roll/unroll operation. That article gives some replication examples, but that is not the entirety of HDL loops.

The quote above is to start pointing out that tggzzz (who's quote you removed from the nesting so the text above is out of context) is factually wrong that loops are not sythesizable. Are we past that point yet? Once you see that loops are synthesizable, they can be used for all sorts of things, replication is just one of those applications. You want to write fancy algorithms with loops that modify the loop variable? HDL will do that with some futzing, but "simple" loops are just like C.

Or is this some bizarre pile on from a bunch of people who don't actually use or write HDL?

[sicco]

For me, Icestudio and Icebreaker (ice40) were what Arduino is for microcontrollers: cheap, open, easy & free. Up and running, blinking the first LED, in less than an hour.

https://github.com/FPGAwars/icestudio/wiki

I disagree with the suggestion that it takes weeks or months to get going.
It is work in progress, targeted at education / hobby use, just like Arduino, has a sizeable and growing community, and it has improved a lot in recent years. I have now removed the Lattice tools from my PC: too heavy, too much license hassle.
With Icestudio, you first graphically draw (=wire) circuits as gates, counters, flipflips and only later on you get persuaded to write verilog code. And only after that’s under the belt, you start peeking inside huge libraries (collections) and learn how to wire in dual port ram, spi, i2c, the pll, dsp mac blocks and so on.

[pcprogrammer]

Or is this some bizarre pile on from a bunch of people who don't actually use or write HDL?

I can only speak for myself, but I'm in the process of learning HDL. I have not yet run into a situation where I needed a "for loop" construction and your example with the priority encoder helped in seeing a use for it. Can't directly think of a setup where the "for loop" has to do a variable number of iterations, like you pointed out to be possible, but assume they will exist.

As this thread is about "intros to FPGAs" I think the whole "for loop" discussion is a bit to advanced and so you are on the mark with your S/N ratio remark earlier.

For me good to know the "for loop" exists and what it can do. The pointer to the nandland.com website is very useful.

[rstofer]

The 'for loop' discussion brings out 2 points:  HDL doesn't work like C and, generally, HDL for loops are used to replicate logic.

Suppose you had a component that implemented a 1 bit full adder with Carry In, A, B as inputs and Y, Carry Out as outputs.  Nothing special, just a neat 1 bit adder.

You would use a 'for' loop to connect 16 of these adders in series to create a 16 bit full adder

You can follow along here but the 'for' loop is on page 13 (there are previous incantations, I think this is the cleanest):

http://osorio.wait4.org/SSC0113/AULA02/eecs_317_adder.pdf

It is an elegant way of avoiding having to write out 'n' lines of code to describe the interconnects.  But you could!  It might be a great exercise to unroll the loop on page 13 line 8.  In fact, I highly recommend it.  It will put the 'for loop' to bed.

The first line to get synthesized looks like:

Code: [Select]

full_adder PORT MAP (t(0), a(0), b(0), S(0), t(1));

This kind of 'for' loop is used all the time but it is important to realize that it is unrolled during synthesis. It is not executed as logic.

The take-away from all of this is the HDL isn't C and shutting off the application code mindset is going to be very important.  You need to think in terms of gates and flops.  Gates and flops...  You could actually write your VHDL at the gate and flop level.  It would be verbose and cumbersome but it could be done.  The HDL allows us to take a step up and think in terms of components.

You not only need to think about the value of a signal, you need to think about when, exactly, it changes.  You need to keep quite a few signals in mind as you write the code because it's going to matter when they change relative to some other chunk of code which relies on them.  When do the signals get updated?

[tggzzz]

This kind of 'for' loop is used all the time but it is important to realize that it is unrolled during synthesis. It is not executed as logic.

The take-away from all of this is the HDL isn't C and shutting off the application code mindset is going to be very important.  You need to think in terms of gates and flops.  Gates and flops...  You could actually write your VHDL at the gate and flop level.  It would be verbose and cumbersome but it could be done.  The HDL allows us to take a step up and think in terms of components.

Precisely.

It is useful, and often necessary, to write your code at the gate level - particularly if you expand "gate" to include IP supplied by the device manufacturer.

The benefits are that you can instantiate well-designed components that can't easily be defined in HDLs. Examples include specific IO blocks e.g. SERDES or DRAM interfaces, clock tiles with specific properties, clock distribution strategies, signals that cross clock domains. By "wiring together" such blocks in an HDL, you get the benefit of predictable performance that is not subject to the whim of the synthesis and placement tools. That can be vital as you push the capabilities of the FPGAs in terms of speed and performance.

Note those benefits are the same as the benefits for wiring ICs together

[laugensalm]

The whole loop argument would be pretty much void, if generator statements for hardware elements are semantically separated from flow of control (which needs to be run in order to synthesize), somewhat following the C preprocessor analogon brought up earlier.
Yes, VHDL has the `generate` keyword, but you can still write funky code using functions and variables where the synthesis path becomes obscure and non-explicit. It also makes synthesis support of the usual set of language constructs explode in complexity, some may argue that those V*-Languages were never designed with synthesis in mind and that you'll be left with writing non-portable code for specific tools anyhow. Unfortunately, that's what can make development in V* very tedious and why they were avoided for a large project here in the first place.

As a software minded person, I tend to waste less time with language peculiarities when inference paths/design rules are under control and things are spelled out in a simple and as explicit-as-possible manner. Like for example, Python code for a bit flip logic:

Code: [Select]

    @sensitivity.generator
    def wireup():
        for i in range(8):
            j = 7 - i
            yield [ z[i] <= s[j] ]

The above code is run for transfer to RTL and the list in `yield` contains the statements that directly infer to RTL (logic), in this case a simple assignment. There's more aspects to it: Verification can be done in-situ, plus translation style is determined by the caller instead of pragma-style decoration/configuration options/ifdef mess.
Nevertheless, V* is eventually used for transfer and possibly for primitive (gate) level verification. So even when using simplified Python or other flashy HDL approaches, being able to debug V* is pretty mandatory when it comes to the engineering part, i.e. moving from the dry dock of the simulation world towards a real hardware project, like having to write a crt0.s when starting bare metal as a C coder.

The discussion seems to have gotten off track - to wrap this up and to not scare the TO any further: there's pretty much two approaches, either starting out with a specific hardware and some refdesign to hack on in whatever language, or the dry dock abstracted approach without the requirement to buy any hardware, focusing on the actual modeling, simulation and verification. I guess it's pretty much of personal preference which gives more 'instant gratification', some just like seeing those LEDs blink. Both approaches worked for us, but most important thing is to be able to debug (tools, knowledge) in order to be effective and avoid frustrations. And to stay with the event driven way of thinking before moving on the HLS concepts.

[hamster_nz]

A badly thought out view is that iteration that loops provides in programming splits into two types - iterative processing and iterating over data. Loops in HDL are great for iterating over data, but not so good for iterative processing.

I wouldn't want to use a loop to calculate Fibonacci numbers based on an input value, but I would use a loop to add two large sets of numbers together.

[nctnico]

The take-away from all of this is the HDL isn't C and shutting off the application code mindset is going to be very important.  You need to think in terms of gates and flops.  Gates and flops...  You could actually write your VHDL at the gate and flop level.  It would be verbose and cumbersome but it could be done.  The HDL allows us to take a step up and think in terms of components.

You not only need to think about the value of a signal, you need to think about when, exactly, it changes.  You need to keep quite a few signals in mind as you write the code because it's going to matter when they change relative to some other chunk of code which relies on them.  When do the signals get updated?

No. That is the path straight to a world of pain. People who do this tend to write obfustigated, unmaintainable HDL code. If you are going to work on more complex projects, you'll get stuck quickly because thinking in gates & flipflops is equal to writing a C program using inline assembler. I've come across lots of VHDL code where 10 to 15 lines could be replaced by 3 lines at most. The best way to becoming an effective FPGA developer is to use a HDL and all it's features (like functions, records, etc) to the fullest extend to describe a problem and let the synthesizer deal with it. 99% of the logic in most designs doesn't even need to be fast. Optimise the 1% that doesn't meet timing requirements.

For example: I never infer instantiate memory; I create an array but I do read the synthesis manual to understand how the synthesizer deals with the memory. But in the end it is the synthesizer that will choose to use memory blocks or flipflops to create the actual memory in logic.

All this leads to highly flexible and re-usable code that is also easy to understand and maintain.

Edit: typo

[SiliconWizard]

Memories can be tricky. Sure the simplest ones are a no-brainer, but as soon as you wanna make the tools infer true dual-port stuff, make sure its gets into EBR rather than distributed memory, and most of all, as soon as you wanna implement some kind of "byte enable" (that's the one I had the most trouble with trying to use pure HDL, with most vendors), things can get problematic fast, and that's where you'll end up instantiating a vendor primitive/IP.

[Someone]

The first line to get synthesized looks like:

Code: [Select]

full_adder PORT MAP (t(0), a(0), b(0), S(0), t(1));
This kind of 'for' loop is used all the time but it is important to realize that it is unrolled during synthesis. It is not executed as logic.

It actually depends on the synthesiser, some internal intermediary might be an unrolling of that loop but it's never explicit or required. Funnily enough that example is one where using a loop to build hand crafted adders is often less resource efficient than just adding higher level signed/unsigned vectors with that hard to understand."+" operator Synthesis can pull out larger optimised structures with higher level code. While the optimisation of logic is usually impressive, trying to infer larger functions from logic usually fails. Writing out a gate level adder rarely maps to the hard adder resources.

Synthesis is not standardised, its tool/device/vendor specific. People trying to say it will do anything specific are living in dreamland. The tools take the HDL standard and implement what was described, they don't use inspectable things like loop unrolling, and even if they did (in some specific circumstances) by the time the logic optimisation ran over it the result would be unrecognisable.

[tggzzz]

Memories can be tricky. Sure the simplest ones are a no-brainer, but as soon as you wanna make the tools infer true dual-port stuff, make sure its gets into EBR rather than distributed memory, and most of all, as soon as you wanna implement some kind of "byte enable" (that's the one I had the most trouble with trying to use pure HDL, with most vendors), things can get problematic fast, and that's where you'll end up instantiating a vendor primitive/IP.

Precisely.

And with other components such as queues crossing clock domains, specialised IO blocks, and complex vendor supplied IP functional components.

A good engineer uses what the tool manufacturers provide, rather than taking a long time to reinvent an elliptical wheel.

[gnuarm]

Precisely.

It is useful, and often necessary, to write your code at the gate level - particularly if you expand "gate" to include IP supplied by the device manufacturer.

While using components is useful, I have not found it necessary to use gate level coding... ever.  Typically, instantiation is used for very special cases, or modularity in the design.  Virtually never gates or anything at the TTL MSI level or below. 

Things like counters, adders, and registers are a single line of code for the declaration and very few lines of code for the RTL description.  I've never used components for those.

The benefits are that you can instantiate well-designed components that can't easily be defined in HDLs. Examples include specific IO blocks e.g. SERDES or DRAM interfaces, clock tiles with specific properties, clock distribution strategies, signals that cross clock domains. By "wiring together" such blocks in an HDL, you get the benefit of predictable performance that is not subject to the whim of the synthesis and placement tools. That can be vital as you push the capabilities of the FPGAs in terms of speed and performance.

I don't know that speed is actually the issue.  You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

[gnuarm]

For example: I never infer memory; I create an array but I do read the synthesis manual to understand how the synthesizer deals with the memory. But in the end it is the synthesizer that will choose to use memory blocks or flipflops to create the actual memory in logic.

All this leads to highly flexible and re-usable code that is also easy to understand and maintain.

I think you meant you *always* infer memory and never instantiate it.  Is that right? 

[gnuarm]

Memories can be tricky. Sure the simplest ones are a no-brainer, but as soon as you wanna make the tools infer true dual-port stuff, make sure its gets into EBR rather than distributed memory, and most of all, as soon as you wanna implement some kind of "byte enable" (that's the one I had the most trouble with trying to use pure HDL, with most vendors), things can get problematic fast, and that's where you'll end up instantiating a vendor primitive/IP.

My preference would be to infer everything I can, but memory can be tricky.  You have to tailor it to the synthesis engine and the target, so in the end, it is not nearly as flexible as you might want.  Even with inference, I've had to have different code for different families of parts.

Instantiation can be a real PITA.  Has anyone tried to work with the Gowin documentation for their libraries?  It is a pretty ugly combination of different types of diagrams, some showing all the bits and bobs in the chip to allow flexibility and other diagrams seem to be tailored to specific modes, but good luck tying any of it to the library components. 

[nctnico]

For example: I never infer memory; I create an array but I do read the synthesis manual to understand how the synthesizer deals with the memory. But in the end it is the synthesizer that will choose to use memory blocks or flipflops to create the actual memory in logic.

All this leads to highly flexible and re-usable code that is also easy to understand and maintain.

I think you meant you *always* infer memory and never instantiate it.  Is that right?

You are right. I'll change it.

[nctnico]

Memories can be tricky. Sure the simplest ones are a no-brainer, but as soon as you wanna make the tools infer true dual-port stuff, make sure its gets into EBR rather than distributed memory, and most of all, as soon as you wanna implement some kind of "byte enable" (that's the one I had the most trouble with trying to use pure HDL, with most vendors), things can get problematic fast, and that's where you'll end up instantiating a vendor primitive/IP.

Precisely.

And with other components such as queues crossing clock domains, specialised IO blocks, and complex vendor supplied IP functional components.

A good engineer uses what the tool manufacturers provide, rather than taking a long time to reinvent an elliptical wheel.

The problem is that manufacturers tend to provide tools that are dumbed down or don't offer maximum flexibility. In reality instantiation is mostly a remnant of the time where programmable logic was defined using schematic entry.

Specific to the memory example: try to design a truly generic FIFO. If you infer memory, the synthesizer can choose the optimum type of memory depending on the depth of the FIFO. This means you never have to bother with choosing between FIFOs depending on what kind of programmable logic you are using. However, to make such a design succefully you have to understand how the synthesizer deals with infering memory so you can write the HDL in a way it does what you want.

In general: it is well worth spending time on reading the synthesis manual. It makes your workflow much more efficient compared to instantiating all kinds of vendor specific blocks because that also requires to understand those blocks fully. Another example: many FPGAs have DSP blocks. Usually these aren't the easiest to instantiate. Inferring these is much easier because you can simply write: a = b*c +d in HDL which on top of everything is also much easier to understand for someone else looking at the code.

[emece67]

.

[tggzzz]

Precisely.

It is useful, and often necessary, to write your code at the gate level - particularly if you expand "gate" to include IP supplied by the device manufacturer.

While using components is useful, I have not found it necessary to use gate level coding... ever.  Typically, instantiation is used for very special cases, or modularity in the design.  Virtually never gates or anything at the TTL MSI level or below. 

Things like counters, adders, and registers are a single line of code for the declaration and very few lines of code for the RTL description.  I've never used components for those.

Agreed. That's why I didn't use those as examples, and why I explicitly expanded "gate" to include arbitrarily complex functional blocks.

The benefits are that you can instantiate well-designed components that can't easily be defined in HDLs. Examples include specific IO blocks e.g. SERDES or DRAM interfaces, clock tiles with specific properties, clock distribution strategies, signals that cross clock domains. By "wiring together" such blocks in an HDL, you get the benefit of predictable performance that is not subject to the whim of the synthesis and placement tools. That can be vital as you push the capabilities of the FPGAs in terms of speed and performance.

I don't know that speed is actually the issue. 

Speed is usually an issue. Poorly constrained implementations lead to "trivial" changes drastically changing the maximum speed.

In some cases I've had to resort to manually nailing down blocks so that the placement can give remotely useful results.

I always consider floorplanning when starting a design. It goes with the territory of defining clock domains before starting implementation.

"Thinking in procedural languages" when designing software systems leads to fragile distributed/networked software applications. People ignore that their design could fail because of a computer you didn't know existed and which is under the control of another company.

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Yes, as I said.

They have to be instantiated, and that doesn't fit well into the mentality of using a procedural language.

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

I was discussing principle. Using pre-existing blocks, whether IPs or ICs, is conceptually very similar. The size/complexity hidden within the blocks changes over time, but the principle remains unchanged.

[nctnico]

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

No, what you write only applies to people that do not take the timing relationships into account. But that is a competence issue, not a problem that comes from using a higher level language.

[tggzzz]

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

No, what you write only applies to people that do not take the timing relationships into account. But that is a competence issue, not a problem that comes from using a higher level language.

Strawman argument. In this context, that specific incompetence stems from using the tool inappropriately, i.e. thinking you can "write like C" in an HDL.

Remember that's the OP's starting point: thinking that experience creating arduino/C applications might be relevant to FPGA/HDL applications.

[laugensalm]

For some time ago I think that all those hype on HLS tools, MyHDL, Migen and others came bacause people do not really understand (or believe on) the true capabilities of VHDL, SystemVerilog and modern synthesis tools. I also in doubt that the astounding results of SpinalHDL cannot be mimmicked with modern VHDL/SV. Many still think that traditional HDLs are just a textual means to describe netlists, instead of a textual means to describe behavior, structure and information flow, and at different levels of abstraction.

Believe me, those *working* on the innards of those HDL generator languages understand the architectural details and flaws of Verilog and VHDL very well. One good read on the simple integer arithmetics pitfalls: https://www.jandecaluwe.com/hdldesign/counting.html.
When having to write architecture-agnostic code that needs to verify for ASIC silicon as well, verification of authored VHDL or Verilog95 code proves highly ineffective compared to modern approaches.

And even if the languages would be improved, take for example VHDL2019: No FPGA tool maintainer is actually expecting to ever integrate support for it. So, real world looks like this: We're still stuck with a subset of VHDL93 for most tools, no OO, no user defined data types that would allow to specify inference behaviour. Same hassle for the full SystemVerilog language set.

With primitive-connection-based versus behaviour-based HDL authoring: first will always synthesize for a specific architecture (but isn't portable). Second will not necessarily infer as wanted or be understood at all by various synthesis tools (let aside non-portable attribute decorations). So one is eventually left with iterating through a mixture of both approaches in order to keep code portable. For large projects, this is a real maintenance nightmare and a lot of copy-paste engineering. Yes, when the V*-languages were conceived, engineers didn't really make use of OOP, nor did they have a concept of functional programming (which makes transpilation/translation a lot less expensive).

This is something where functional and OO approaches for transpilation to V* or direct RTL are way less costly, be it Scala or Python based. Nevertheless, even if a full verification chain is present for HDL X -> result, one might have to be able to read V*, because Tools just make mistakes and the only 'copper standards' available in this domain are for those two V* (Let aside integration of external code/blackbox primitives)

[nctnico]

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

No, what you write only applies to people that do not take the timing relationships into account. But that is a competence issue, not a problem that comes from using a higher level language.

Strawman argument. In this context, that specific incompetence stems from using the tool inappropriately, i.e. thinking you can "write like C" in an HDL.

It is not a strawman argument. You can actually 'write like C' using HDL (sequential versus parallel aside) but just like in C you have a finite amount of resources to complete a task in time. One of the problems is that people think that 'in time' means that only the fastest solution suffices but that isn't true. That isn't what 'in time' means. Remember that optimisation before figuring out whether or not you actually need optimisation, is a waste of effort and money.

[tggzzz]

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

No, what you write only applies to people that do not take the timing relationships into account. But that is a competence issue, not a problem that comes from using a higher level language.

Strawman argument. In this context, that specific incompetence stems from using the tool inappropriately, i.e. thinking you can "write like C" in an HDL.

It is not a strawman argument. You can actually 'write like C' using HDL (sequential versus parallel aside) but just like in C you have a finite amount of resources to complete a task in time. One of the problems is that people think that 'in time' means the fastest solution but that isn't true. That isn't what 'in time' means. Remember that optimisation before figuring out whether or not you actually need optimisation, is a waste of effort and money.

Sure all the languages are Turing complete (just like the C++ preprocessor language!), and you can write Fortran in any language. Speed is irrelevant to that. I'm sure you've seen such idiocies as well.

You can also use a bicycle to cross the USA or go over the Alps, but that doesn't make it a good idea. (Unless you are Dervla Murphy going to India in 1963, as per "Full Tilt" )

[gnuarm]

I don't know that speed is actually the issue. 

Speed is usually an issue. Poorly constrained implementations lead to "trivial" changes drastically changing the maximum speed.

I don't find the tools to be the problem with speed.  Speed problems usually come from either poorly written code, meaning it expands into large logic, or and overly crowded chip that prevents good placement and efficient routing.

In some cases I've had to resort to manually nailing down blocks so that the placement can give remotely useful results.

I always consider floorplanning when starting a design. It goes with the territory of defining clock domains before starting implementation.

I'm not sure what that means.  Floorplanning is something you do to constrain placement.  It has no meaning before you have a design.  If your designs are so difficult to meet timing, that you have to plan the placement before you do the design, then you are in the 1% of designs that are pushing the chips to their limits. 

I don't normally have designs like that.

"Thinking in procedural languages" when designing software systems leads to fragile distributed/networked software applications. People ignore that their design could fail because of a computer you didn't know existed and which is under the control of another company.

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

I think you are carrying that water too far and your bucket has a leak. 

You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Yes, as I said.

They have to be instantiated, and that doesn't fit well into the mentality of using a procedural language.

Whatever that means.  My point is there are times when instantiation is required. Otherwise, I use inference which works just fine.  I typically have some idea of what logic and in particular, registers will be inferred.  It's not my goal to dominate the tool and use inference as a substitute for instantiation, meaning, controlling the inference so tightly that I get exactly what I want.  The point is to let the tool do the walking!

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

I was discussing principle. Using pre-existing blocks, whether IPs or ICs, is conceptually very similar. The size/complexity hidden within the blocks changes over time, but the principle remains unchanged.

So you are talking modularity?  Yes, but even with that, my designs use most modules exactly once.  It's more a way of decomposing the design to give it structure and an means of testing units rather than the whole.  Instantiation is seldom about component reuse because most components don't get reused.  Pretty not much like wiring ICs together where you use the same ICs over and over.

[tggzzz]

I don't know that speed is actually the issue. 

Speed is usually an issue. Poorly constrained implementations lead to "trivial" changes drastically changing the maximum speed.

I don't find the tools to be the problem with speed.  Speed problems usually come from either poorly written code, meaning it expands into large logic, or and overly crowded chip that prevents good placement and efficient routing.

You misunderstand. I've seen a design with, IIRC, around 40% occupancy, mostly datapath with a relatively small amount of control logic. A trivial change in the control logic caused a factor of 4 change in the maximum clock rate. Nailing down the data path reduced the clock rate change to essentially zero.

Go figure.

In some cases I've had to resort to manually nailing down blocks so that the placement can give remotely useful results.

I always consider floorplanning when starting a design. It goes with the territory of defining clock domains before starting implementation.

I'm not sure what that means.  Floorplanning is something you do to constrain placement.  It has no meaning before you have a design.  If your designs are so difficult to meet timing, that you have to plan the placement before you do the design, then you are in the 1% of designs that are pushing the chips to their limits. 

I disagree. Perhaps my designs are pushing the limits harder than yours.

I don't normally have designs like that.

"Thinking in procedural languages" when designing software systems leads to fragile distributed/networked software applications. People ignore that their design could fail because of a computer you didn't know existed and which is under the control of another company.

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

I think you are carrying that water too far and your bucket has a leak. 

Unhelpful analogy which gives no insight. I've seen the effects I've described.

You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Yes, as I said.

They have to be instantiated, and that doesn't fit well into the mentality of using a procedural language.

Whatever that means.  My point is there are times when instantiation is required. Otherwise, I use inference which works just fine.  I typically have some idea of what logic and in particular, registers will be inferred.  It's not my goal to dominate the tool and use inference as a substitute for instantiation, meaning, controlling the inference so tightly that I get exactly what I want.  The point is to let the tool do the walking!

I have no idea what you mean by "dominate the tool".

Inference and instantiation are orthogonal. You can (and do) have inference with and without instantiation.

Software programmers, particularly when using C and higher optimisation levels, often have to look at the asm code to see if there are any "unexpected" effects (that's why the Linux kernel uses -O2 not -O3). Similarly it is often beneficial (and sometimes necessary) to look at what the synthesis and placement has done with your design.

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

I was discussing principle. Using pre-existing blocks, whether IPs or ICs, is conceptually very similar. The size/complexity hidden within the blocks changes over time, but the principle remains unchanged.

So you are talking modularity?  Yes, but even with that, my designs use most modules exactly once.  It's more a way of decomposing the design to give it structure and an means of testing units rather than the whole.  Instantiation is seldom about component reuse because most components don't get reused.  Pretty not much like wiring ICs together where you use the same ICs over and over.

We are discussing several effects, in this case modularity.

Whatever the modularity, whether or not you are instantiating one or more instances of a component is irrelevant.

[gnuarm]

I don't know that speed is actually the issue. 

Speed is usually an issue. Poorly constrained implementations lead to "trivial" changes drastically changing the maximum speed.

I don't find the tools to be the problem with speed.  Speed problems usually come from either poorly written code, meaning it expands into large logic, or and overly crowded chip that prevents good placement and efficient routing.

You misunderstand. I've seen a design with, IIRC, around 40% occupancy, mostly datapath with a relatively small amount of control logic. A trivial change in the control logic caused a factor of 4 change in the maximum clock rate. Nailing down the data path reduced the clock rate change to essentially zero.

What does "nailing down the data path" mean exactly? 

Do you understand what caused the change in clock rate?

Go figure.

In some cases I've had to resort to manually nailing down blocks so that the placement can give remotely useful results.

I always consider floorplanning when starting a design. It goes with the territory of defining clock domains before starting implementation.

I'm not sure what that means.  Floorplanning is something you do to constrain placement.  It has no meaning before you have a design.  If your designs are so difficult to meet timing, that you have to plan the placement before you do the design, then you are in the 1% of designs that are pushing the chips to their limits. 

I disagree. Perhaps my designs are pushing the limits harder than yours.

Ok, so you have more designs in the 1% then.

I don't normally have designs like that.

"Thinking in procedural languages" when designing software systems leads to fragile distributed/networked software applications. People ignore that their design could fail because of a computer you didn't know existed and which is under the control of another company.

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

I think you are carrying that water too far and your bucket has a leak. 

Unhelpful analogy which gives no insight. I've seen the effects I've described.

Ok, then can you provide some examples of "thinking in procedural languages"?  I've never seen anyone code an entire design in sequential code such as processes, although that's perfectly reasonable too.  I don't know of any designs that can't be done in sequential code.  So I'm thinking I not following what you mean by the term above.

You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Yes, as I said.

They have to be instantiated, and that doesn't fit well into the mentality of using a procedural language.

Whatever that means.  My point is there are times when instantiation is required. Otherwise, I use inference which works just fine.  I typically have some idea of what logic and in particular, registers will be inferred.  It's not my goal to dominate the tool and use inference as a substitute for instantiation, meaning, controlling the inference so tightly that I get exactly what I want.  The point is to let the tool do the walking!

I have no idea what you mean by "dominate the tool".

Inference and instantiation are orthogonal. You can (and do) have inference with and without instantiation.

Software programmers, particularly when using C and higher optimisation levels, often have to look at the asm code to see if there are any "unexpected" effects (that's why the Linux kernel uses -O2 not -O3). Similarly it is often beneficial (and sometimes necessary) to look at what the synthesis and placement has done with your design.

I've not seen software people dig into the asm code routinely unless they HAD a problem to solve.  No one codes in C caring about the asm, mostly, because it is hard to understand after the tool is done optimizing it.  Often it is much more efficient than what is hand coded. 

I look at the synthesis result on small blocks that I wish to optimize or when learning to use a new tool.  If this is done routinely, like with writing C code, it becomes very time wasting.  I use the same coding styles over and over, so once I've learned a tool, I don't need to keep looking over my shoulder to check that the result is effective. 

Here's an analogy.  I got a kayak and proceeded to kayak for some weeks or even months before learning from others.  I found I was gripping the paddle too tightly, trying to control every aspect of its motion.  I learned that the paddle finds its own center and a relaxed grip is much less tiring.  I code that way as well, relaxed, using the style that works for the tool I'm using.  I don't need to keep checking it unless there's a problem.

Like with the kayak paddle, if you are getting poor results, you probably have a poor style for that tool.  Rather than fix things with instantiation (gripping the paddle tightly) it is better to learn how to code properly for the tool (a relaxed grip with an understanding of how the paddle should be used).  I find it much less tiring to work with the tools, rather than to beat them into submission with excessive use of instantiation. 

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

I was discussing principle. Using pre-existing blocks, whether IPs or ICs, is conceptually very similar. The size/complexity hidden within the blocks changes over time, but the principle remains unchanged.

So you are talking modularity?  Yes, but even with that, my designs use most modules exactly once.  It's more a way of decomposing the design to give it structure and an means of testing units rather than the whole.  Instantiation is seldom about component reuse because most components don't get reused.  Pretty not much like wiring ICs together where you use the same ICs over and over.

We are discussing several effects, in this case modularity.

Whatever the modularity, whether or not you are instantiating one or more instances of a component is irrelevant.

I'm not sure what you are discussing.  Modularity in HDL is done with instantiation mostly.  Some people use procedures, but I find that limiting. 

Modularity is to facilitate understanding the design, as well as testing and decision hiding.  I don't use it to control layout, mostly because I seldom need to control layout.  Controlling layout to achieve timing, is under the heading of optimization which is to be avoided if possible.  I certainly don't do it routinely. 

[tggzzz]

I don't know that speed is actually the issue. 

Speed is usually an issue. Poorly constrained implementations lead to "trivial" changes drastically changing the maximum speed.

I don't find the tools to be the problem with speed.  Speed problems usually come from either poorly written code, meaning it expands into large logic, or and overly crowded chip that prevents good placement and efficient routing.

You misunderstand. I've seen a design with, IIRC, around 40% occupancy, mostly datapath with a relatively small amount of control logic. A trivial change in the control logic caused a factor of 4 change in the maximum clock rate. Nailing down the data path reduced the clock rate change to essentially zero.

What does "nailing down the data path" mean exactly? 

Do you understand what caused the change in clock rate?

Placing individual LUTs in the datapath. And it was an exceedingly simple and regular datapath.

The tools placed the datapath "suboptimally", for reasons best known to itself. That meant the control path timing changed radically, with consequent timing changes.

Go figure.

In some cases I've had to resort to manually nailing down blocks so that the placement can give remotely useful results.

I always consider floorplanning when starting a design. It goes with the territory of defining clock domains before starting implementation.

I'm not sure what that means.  Floorplanning is something you do to constrain placement.  It has no meaning before you have a design.  If your designs are so difficult to meet timing, that you have to plan the placement before you do the design, then you are in the 1% of designs that are pushing the chips to their limits. 

I disagree. Perhaps my designs are pushing the limits harder than yours.

Ok, so you have more designs in the 1% then.

Who knows whether it is 1%, 5%, 10%, 50%. And who cares.

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

I don't normally have designs like that.

"Thinking in procedural languages" when designing software systems leads to fragile distributed/networked software applications. People ignore that their design could fail because of a computer you didn't know existed and which is under the control of another company.

Thinking in procedural languages when designing FPGAs leads to fragile hardware implementations where I/O has multiple different clocks. People that ignore that their design could fail due to metastability problems even in plesiochronous systems where the clock rates are nominally the same.

I think you are carrying that water too far and your bucket has a leak. 

Unhelpful analogy which gives no insight. I've seen the effects I've described.

Ok, then can you provide some examples of "thinking in procedural languages"?  I've never seen anyone code an entire design in sequential code such as processes, although that's perfectly reasonable too.  I don't know of any designs that can't be done in sequential code.  So I'm thinking I not following what you mean by the term above.

See earlier posts in this thread. More generally, use duckduckgo.

You literally can't infer special purpose blocks in the HDL typically.  Clock multiplexers are a good example.  I've never seen an HDL inference that would work in place of an instantiation.  SERDES is just one of those blocks of logic that can't be inferred, no?

Yes, as I said.

They have to be instantiated, and that doesn't fit well into the mentality of using a procedural language.

Whatever that means.  My point is there are times when instantiation is required. Otherwise, I use inference which works just fine.  I typically have some idea of what logic and in particular, registers will be inferred.  It's not my goal to dominate the tool and use inference as a substitute for instantiation, meaning, controlling the inference so tightly that I get exactly what I want.  The point is to let the tool do the walking!

I have no idea what you mean by "dominate the tool".

Inference and instantiation are orthogonal. You can (and do) have inference with and without instantiation.

Software programmers, particularly when using C and higher optimisation levels, often have to look at the asm code to see if there are any "unexpected" effects (that's why the Linux kernel uses -O2 not -O3). Similarly it is often beneficial (and sometimes necessary) to look at what the synthesis and placement has done with your design.

I've not seen software people dig into the asm code routinely unless they HAD a problem to solve.  No one codes in C caring about the asm, mostly, because it is hard to understand after the tool is done optimizing it.  Often it is much more efficient than what is hand coded. 

The combination of the C compiler optimiser, the C language specification, and programmer knowledge combine to cause "surprises". That's why LinusT doesn't allow using -O3 and above in the Linux kernel.
"- -O3 has a *loong* history of generating worse code than -O2 so I will *not* be taking these kinds of patches without some very serious explanations of why -O3 has suddenly become acceptable again. "
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Against-O3-Kernel

I look at the synthesis result on small blocks that I wish to optimize or when learning to use a new tool.  If this is done routinely, like with writing C code, it becomes very time wasting.  I use the same coding styles over and over, so once I've learned a tool, I don't need to keep looking over my shoulder to check that the result is effective. 

The OP is not in that position.

My jobs have rarely involved such repetition, because if that was the case then it couldn't be my job!

Distracting uus with yor backwoods experiences won't shed any light on FPGA designs.

Here's an analogy.  I got a kayak and proceeded to kayak for some weeks or even months before learning from others.  I found I was gripping the paddle too tightly, trying to control every aspect of its motion.  I learned that the paddle finds its own center and a relaxed grip is much less tiring.  I code that way as well, relaxed, using the style that works for the tool I'm using.  I don't need to keep checking it unless there's a problem.

Like with the kayak paddle, if you are getting poor results, you probably have a poor style for that tool.  Rather than fix things with instantiation (gripping the paddle tightly) it is better to learn how to code properly for the tool (a relaxed grip with an understanding of how the paddle should be used).  I find it much less tiring to work with the tools, rather than to beat them into submission with excessive use of instantiation. 

Note those benefits are the same as the benefits for wiring ICs together

As opposed to writing HDL and using programmable logic?

I was discussing principle. Using pre-existing blocks, whether IPs or ICs, is conceptually very similar. The size/complexity hidden within the blocks changes over time, but the principle remains unchanged.

So you are talking modularity?  Yes, but even with that, my designs use most modules exactly once.  It's more a way of decomposing the design to give it structure and an means of testing units rather than the whole.  Instantiation is seldom about component reuse because most components don't get reused.  Pretty not much like wiring ICs together where you use the same ICs over and over.

We are discussing several effects, in this case modularity.

Whatever the modularity, whether or not you are instantiating one or more instances of a component is irrelevant.

I'm not sure what you are discussing.  Modularity in HDL is done with instantiation mostly.  Some people use procedures, but I find that limiting. 

Modularity is to facilitate understanding the design, as well as testing and decision hiding.  I don't use it to control layout, mostly because I seldom need to control layout.  Controlling layout to achieve timing, is under the heading of optimization which is to be avoided if possible.  I certainly don't do it routinely.

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

[nctnico]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

[free_electron]

two schools of thought
- write it hardware agnostic, let the compiler figure it out. it should run anywhere...
- write it tightly coupled to the hardware to squeeze every nanosecond out of it. hand place and route.

both are a path to failure.
one path leads to bloated hardware because you don't use the capabilities of the machine , the other leads to bloated codebase and a waste of time doing things the machine can do (synthesizer)

USE THE TOOLS ! don't spend time doing things the machine can do. fail fast and early. work in modules. instantiate modules. draw a schematic if you want to. nobody limits you in what you are allowed to do. the tools all allow for schematic entry and hdl and/or a mixture.
i hate instantiating submodules. i can never remember the syntax and if i change signal orders or add signals it means more typing. So my toplevel is always a schematic. nice drawing showing the relation between blocks and the i/o pins/ click on a block and there is the HDL (in my case verilog2005). Easy to maintain , easy to write, easy to debug. i typically reserve a number of pins as debug channel. if i need to see internal signals just wire them to the debug channel. i sometimes drop in a big multiplexer to sniff more.

[tggzzz]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

I presume you agree with all the other points I made. If not then it looks like you at simply finding a way, any way, to appear to win a discussion.

[tggzzz]

two schools of thought
- write it hardware agnostic, let the compiler figure it out. it should run anywhere...
- write it tightly coupled to the hardware to squeeze every nanosecond out of it. hand place and route.

both are a path to failure.
one path leads to bloated hardware because you don't use the capabilities of the machine , the other leads to bloated codebase and a waste of time doing things the machine can do (synthesizer

I don't disagree.

One reason for articulating extremes is to examine where things fail. As Arthur C Clarke put it, the only way to find the limits of the possible is to go beyond them into the impossible.

Another rs to clarify essential points of a discussion that might be more generally applicable. To achieve that, it is often necessary to avoid discussing details that are only applicable in one situation.

Of course real life projects and situations are never black a and white; they are always shades of grey.

USE THE TOOLS ! don't spend time doing things the machine can do. fail fast and early. work in modules. instantiate modules. draw a schematic if you want to. nobody limits you in what you are allowed to do. the tools all allow for schematic entry and hdl and/or a mixture.
i hate instantiating submodules. i can never remember the syntax and if i change signal orders or add signals it means more typing. So my toplevel is always a schematic. nice drawing showing the relation between blocks and the i/o pins/ click on a block and there is the HDL (in my case verilog2005). Easy to maintain , easy to write, easy to debug. i typically reserve a number of pins as debug channel. if i need to see internal signals just wire them to the debug channel. i sometimes drop in a big multiplexer to sniff more.

Yes, that tends to aid a key objective: simple clarity.

[hamster_nz]

Unless you are writing purely structural HDL and are using only the vendor's primitives then all your HDL code is inferred. It's just that in some cases what will be inferred is more obvious (such as an counter) than in others (an array used as a dual-port memory).

And that's before the tools optimize the design by extracting common logic, removing inaccessible/unused registers, constant propagation, duplicating registers or logic to reduce fan-out, inserting clock buffers and so on.

[nctnico]

Any engineer will choose the smallest slowest cheapest part for their design; anything else is wasteful.

So very wrong! A good engineer will choose a part that leads to the lowest overall cost of the project! Bonus points for choosing a part that allows for a sensible extension of features for a product. Labour is super expensive and swamps production costs for many of projects even if the number of units runs into thousands. Unfortunately many people overlook this because they don't have a good grasp on how much time they will spend on coding. Penny wise, pound foolish.

I presume you agree with all the other points I made. If not then it looks like you at simply finding a way, any way, to appear to win a discussion.

No, I just picked this particular piece because it is something that people tend to trip over and end up wasting lots of time and money.

And why would discussions need to be won somehow? What benefit would that bring?

[rstofer]

FWIW, there is no schematic entry capability in Xilinx Vivado.  It was a feature of the now obsolete ISE tools.

Another feature of ISE is the ability to generate a template for instantiating components.  No guessing, no signals to forget, etc.  There is an add-on for Vivado that provides a similar way of doing the same thing.  In my view, the ISE approach is better but ISE is history.

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design.  I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

[tggzzz]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

[Neomys Sapiens]

FPGA-Based Embedded System Developer's Guide   A. Arockia Bazil Raj   CRC Press      2018

EEDigital            Applications of Field-Programmable Gate Arrays in Scientific Research   Hartmut F.-W. Sadrozinski and Jinyuan Wu   CRC Press      2011

Principles and Structures of FPGAs   Hideharu Amano (Ed.)   Springer      2018

Engineering Applications of FPGAs - Chaotic Systems, Artificial Neural Networks, Random Number Generators, and Secure Communication Systems   Esteban Tlelo-Cuautle, J. de Jesus Rangel-Magdaleno, L.G. de la Fraga   Springer      2016

Fault-Tolerance Techniques for SRAM-based FPGAs   F.L.Kastensmidt, L.Carro, R.Reis   Springer      2006

Design Recipes for FPGAs   Peter R. Wilson   Newnes      2006

The Design Warrior's Guide to FPGAs   C. Maxfield   Newnes      2004

[SiliconWizard]

As an intro, unless you are already familiar with the concepts, I'd suggest starting with more fundamental concepts before even touching any FPGA.
Start with logic and basic digital electronics. Someone having a hard time with logic equations and sequential logic will really struggle to do anything useful and understand what's going on with FPGAs.

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing.  The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

[free_electron]

Verilog for synthesis by Bhasker.

lots of books blabber about Verilog (or vhdl) but 70% of it isn't even synthesizable, it's simulation only.
i never write verilog testbenches. i draw a waveform exactly of what i expect to go in, corner cases and all and verify that it reacts correctly at module level.

The problem with verilog testbenches is that it is very hard to describe the corners and you have the tendency to write an "ideal" testbench. It's faster to just draw the input stimuli and look at the output. Plus you can cross correlate with the logic analyser if it fails on bench. you can do a testbench at top level but at module level i prefer waveform.

There is another book , letter size ( A4 ), light blue in color  HDL chip design By Douglas Smith. This was handed out by synopsys when you did their tool training. Out of print. It handles both verilog and vhdl. The specialty of this one is that it shows both Verilog and VHDL  and a flow diagram and the actual schematic of what the stuff synthesizes to. It's over 500 pages.
Finding it new is like ridiculously expensive... you can find used on amazon or ebay

[tggzzz]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing. 

Rubbish.

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

Not in that case.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

[tggzzz]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.
and yes , i'm familiar with that 1680. I have a 1682ad and a 1690A and a 16801A and a 16902A with several 167xx and 169xx series boards that use large xilinx chips. But again ,low volume. Open up a larger volume HPAK oscilloscope and it's asic. Those fpga's are memory mappers, basically fancy dram controllers. The real guts is under the heatsinks. That's where triggering happens.
The previous generation asics are in the LogicWave (which has a USB port but they never got it working... so you are stuck with a EPP printerport interface) and the older 1660 series.

There is a point where the overhead of a FPGA becomes too much. Speed is impaired because of lack in routing channels and die area. memory is impaired and the chip becomes too expensive.

the FPGA code is a static file. they just alter registers. they don't alter the bitstream.  there is ways to hack those cards and make the machine loader believe it has a different board and load a bitstream with more options. many of the 169xx series boards are identical apart from the id code flashed in them. they are actually 16755 or 16754 with different bitstream

[SiliconWizard]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

Except if you expect regular changes/improvements. FPGAs are a no-brainer for this, while you can forget about it with ASICs.

[free_electron]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

Except if you expect regular changes/improvements. FPGAs are a no-brainer for this, while you can forget about it with ASICs.

that's why fpga are used to prototype stuff !.

[tggzzz]

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

if you are going for that, a t a price point : go full asic. fpga is too expensive.

Rubbish.

If you think that isn't right, then I suggest you tell Agilent/Keysight - and I'm sure many other test equipment manufacturers.

But before you do that, I suggest you look inside their equipment. One I'm familiar with is the 1680 series logic analysers. They contain multiple Xilinx FPGAs right next to the pins. Now if you think that the sample rate isn't one of the key marketing points, then I have a bridge to sell you. No, I'm not going to dismantle mine just to prove a blatantly obvious point.

I'll also bet that many of the LUTs are nailed down, since the control processor reloads the FPGA on the fly with the sampling and triggering parameters you have specified on the front panel. How else could you radically change the front-end sampling and triggering functionality with a 2.5ns clock?

I'm sure other manufacturers are the same. ISTR hearing that Rigol/Siglent class machines are based around Zync 7 series FPGAs, which also contain a couple of high-end ARM cores.

Those are all low volume applications.

Your points, position, and arguments mutate every time counterexamples show them to be lacking. That's not unreasonable, but beware the "no true Scotsman fallacy".

Nobody in his right mind will use fpga for large volume. asic is cheaper.

Nobody in their right mind would even consider that an FPGA is suitable in all cases.

and yes , i'm familiar with that 1680. I have a 1682ad and a 1690A and a 16801A and a 16902A with several 167xx and 169xx series boards that use large xilinx chips. But again ,low volume. Open up a larger volume HPAK oscilloscope and it's asic. Those fpga's are memory mappers, basically fancy dram controllers. The real guts is under the heatsinks. That's where triggering happens.
The previous generation asics are in the LogicWave (which has a USB port but they never got it working... so you are stuck with a EPP printerport interface) and the older 1660 series.

There is a point where the overhead of a FPGA becomes too much. Speed is impaired because of lack in routing channels and die area. memory is impaired and the chip becomes too expensive.

So FPGAs aren't the fastest devices and have their own limitations? I encourage you to submit that remarkable revelation to the IEEE so it can be published in a learned journal.

Incidentally, such internal limitations are why it can be beneficial to nail down specific functions in specific LUTs.

the FPGA code is a static file. they just alter registers. they don't alter the bitstream.  there is ways to hack those cards and make the machine loader believe it has a different board and load a bitstream with more options. many of the 169xx series boards are identical apart from the id code flashed in them. they are actually 16755 or 16754 with different bitstream

Maybe; I haven't examined the design in that much detail.

But Xilinx devices can have some parts reloaded with different bitstreams while the other parts continue to operate. That's very powerful, and could have very interesting uses.

[gnuarm]

Verilog for synthesis by Bhasker.

lots of books blabber about Verilog (or vhdl) but 70% of it isn't even synthesizable, it's simulation only.
i never write verilog testbenches. i draw a waveform exactly of what i expect to go in, corner cases and all and verify that it reacts correctly at module level.

Not as a put down or anything, but if you are "drawing" waveforms, you must have some simple testbenches.  I often simulate stuff that has thousands of timing points, often with dozens of inputs.  It is so much easier to program that up than it would be to define timing points, especially when there is feedback, interaction.

One of the things I do when testing the completed design, is when it's part of a communications link, for example, two instances connect through a "mock" network.  The only issue with that is getting the various blocks "tuned" or "aligned" so it doesn't take half a million clocks to synchronize.

The problem with verilog testbenches is that it is very hard to describe the corners and you have the tendency to write an "ideal" testbench. It's faster to just draw the input stimuli and look at the output. Plus you can cross correlate with the logic analyser if it fails on bench. you can do a testbench at top level but at module level i prefer waveform.

What sorts of designs do you do that the digital interface has corners to test?  I'm testing functionality, which is either it works, or it doesn't work.  Maybe I'm not understanding what's going on.

There is another book , letter size ( A4 ), light blue in color  HDL chip design By Douglas Smith. This was handed out by synopsys when you did their tool training. Out of print. It handles both verilog and vhdl. The specialty of this one is that it shows both Verilog and VHDL  and a flow diagram and the actual schematic of what the stuff synthesizes to. It's over 500 pages.
Finding it new is like ridiculously expensive... you can find used on amazon or ebay

I have that book.  It's a bit odd, in that it doesn't flow like most, going through the aspects of the languages as other books do.  It is an excellent way to compare the two languages and the examples are very thorough. 

[gnuarm]

Suitable coding styles can indeed help the synthesiser and placement tools. Coding styles derived from previous experiences with procedural programming languages are not suitable.

Controlling layout is a last resort to achieve the required function. Yes, speed is normally part of the required function.

You seem to acknowledge that coding style is an important habit to develop, then you rather toss that away by saying you need to use layout to achieve a stable design. 

There is no contradiction there; the concepts are orthogonal.

I didn't say you need to use layout to achieve a stable design. I said I have seen cases where it is necessary. Some != all.

I expect there was something going on that you didn't quite catch.  Whatever.  I prefer to spend my time working on the design, rather than struggling to meet timing.

So do I. It isn't always possible.

Timing is part of the design requirements, and if you don't meet the requirements then the design has failed.

Yes, but a properly constructed design will easily meet timing. 

Rubbish.

Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.

If that's the case, then you don't have a design that meets timing and the compiler is mucking up because of a small change.  You have a design that, from the start, you expect to floorplan and small changes are expected to mess with the optimization.  If that's the case, then it's nothing like what we've been discussing and that's why optimizations are typically done last, after the logic is working. 

The situation you described is clearly a poorly constructed design that the place and route had trouble with.  Most likely, the code had some extraneous logic that was not intended, which was slowing down the timing.  I've seen that, where I expected a simple adder to be inferred, but I screwed up the carry and it had to toss a whole other adder in to do what my code asked it to do.  Once I identified the culprit, it was an easy fix and no layout tools required.

Not in that case.

Ok, then nothing you've said about the compiler mucking up your design is really relevant.

[free_electron]

Your points, position, and arguments mutate every time counterexamples show them to be lacking. That's not unreasonable, but beware the "no true Scotsman fallacy".

of course they do. there is only one constant : it all depends. nothing is clear cut. it all depends on circumstances.

i state that asic is cheaper if you are going for full performance and want to push the technology hard especially as a selling point. Real logic will always outperform fpga. FPGA has too much internal delays, delays that can be easier eliminated i hard logic as opposed to the routing fabric in an fpga.

you counterstate: look at the agilent logic analyser cards.

i counterstate : yes they used fpga but because it is low volume and they can afford to plonk down oodles of money for devices that co do the work ( those devices were not cheap back in the day those boards were deigned !) they got the performance they needed at the price they could afford ( ever seen the new price of one of those boards ? some were over 30.000 $ ). and even at that price it was cheaper than designing an asic simply because of the volume. ASIC has a large NRE.
look at the megazoom asic : there they did go full custom. simply because the number of oscilloscopes is 100 x or more larger than the number of those logic analysers. it woudl not make sense to use an FPGA.

i hear you coming with another counterpoint : but but the own/siglent/rigol are all using the xilinx zync.  yes, but that thing didn't exist 10 years ago ! that's why the 4000 series et al are using megazoom asics. and once  go to the faster scopes that zync thing can't cope either. wanna push the limit real hard in the 20+Gs/s you'll need to resort to something other than silicon.... your fpga cannot cope . that's why the real speed demons are indium phosphide semiconductors. There's two waferfabs in the world that can process those. ( the actual transsitors are Indium - gallium arsenide. the indium phosphide is the substrate). they only exist as 3 or 4 inch wafers as they are brittle.

and i hear another counterpoint coming : "but that's low volume ! you said asic  is for high volume.."  ,yes, except if the costs are irrelevant. they can afford to make those weirdo parts for the few hundred scopes they will ever sell. there simply is no other way to get the performance. and the people needing those scopes will pay.

Nobody in their right mind would even consider that an FPGA is suitable in all cases.

just like nobody in their right mind would consider an asic is suitable in all cases. why would fpga's exist ?

So FPGAs aren't the fastest devices and have their own limitations? I encourage you to submit that remarkable revelation to the IEEE so it can be published in a learned journal.

Been there, done that : published in IEEE ETW99 (and gave the speech) as well as "journal of computer standards and interfaces" and IMEKO TC congress. Detailed a FPGA based data generation/acquisition system to test fast A/D-D/A. back in the day (1997) there was nothing that could do what we needed,  so i rolled my own. Designed it using schematic capture and Verilog in the xilinx tools on Sun workstation. used a 3000 series coupled with lots of fast SRAM.

https://www.ieee-ets.org/past_events/etw99/pre_program.html  look for "pulsar"
https://www.sciencedirect.com/science/article/abs/pii/S0920548999000173

[laugensalm]

Those are all low volume applications. Nobody in his right mind will use fpga for large volume. asic is cheaper.

I'd be happy to list plenty of high volume applications for FPGAs on another page, rendering the above statement void, but you might also just do some market analysis on the keywords 'huawei, ice40'. The times, they are a changin'.
Still, this discussion is getting childish and completely out of focus.

[ale500]

those tiny ice40 chips are used in some other phones too, look at the tear downs at I fix it.