Good intros to FPGAs? - Page 1
Forum section: electronics / general

author: Infraviolet
author_rank: Super Contributor
timestamp: July 01, 2022, 11:09:15 pm
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 01, 2022, 11:15:03 pm
content: 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.

author: Someone
author_rank: Super Contributor
timestamp: July 01, 2022, 11:35:38 pm
content: Quote from: Infraviolet on July 01, 2022, 11:09:15 pmThere 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.

author: ataradov
author_rank: Super Contributor
timestamp: July 01, 2022, 11:53:22 pm
content: 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.

author: Infraviolet
author_rank: Super Contributor
timestamp: July 02, 2022, 12:03:12 am
content: 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?

author: Foxxz
author_rank: Regular Contributor
timestamp: July 02, 2022, 12:04:47 am
content: 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 primerhttps://www.youtube.com/c/NandlandBe 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.

author: ataradov
author_rank: Super Contributor
timestamp: July 02, 2022, 12:05:08 am
content: 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.

author: Foxxz
author_rank: Regular Contributor
timestamp: July 02, 2022, 12:11:15 am
content: Quote from: Infraviolet on July 02, 2022, 12:03:12 amLoading 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 02, 2022, 12:16:46 am
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 02, 2022, 12:18:04 am
content: Quote from: ataradov on July 02, 2022, 12:05:08 amYes. 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 02, 2022, 01:40:54 am
content: Quote from: free_electron on July 02, 2022, 12:16:46 amWise 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).

author: BrianHG
author_rank: Super Contributor
timestamp: July 02, 2022, 02:18:51 am
content: Quote from: free_electron on July 02, 2022, 12:16:46 amAs 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.

author: rstofer
author_rank: Super Contributor
timestamp: July 02, 2022, 04:52:18 am
content: Buy the GO board, follow the examples in verilog or vhdl at the sitehttps://nandland.com/https://freecomputerbooks.com/Free-Range-VHDL.htmlThe book is free in PDF formatThere are more capable boards athttps://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/

author: RoGeorge
author_rank: Super Contributor
timestamp: July 02, 2022, 06:27:11 am
content: See if this place suits you:https://www.fpga4fun.com/FPGAinfo1.htmlKeep 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 (HardwareDesign 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.

author: laugensalm
author_rank: Regular Contributor
timestamp: July 02, 2022, 07:31:29 am
content: 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 MyHDLSynthesize via yosys and display inferred hardware elementsRun simulation, display waveform tracesDownload to ECP5 FPGAThe setup is found athttps://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.

author: ataradov
author_rank: Super Contributor
timestamp: July 02, 2022, 07:40:53 am
content: 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.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 02, 2022, 08:19:51 am
content: Quote from: ataradov on July 02, 2022, 07:40:53 am^^^^I hate to say it, but this is the correct answer.

author: laugensalm
author_rank: Regular Contributor
timestamp: July 02, 2022, 08:40:27 am
content: Quote from: ataradov on July 02, 2022, 07:40:53 amAgree 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 02, 2022, 09:12:30 am
content: This site is also nice to learn about verilog:https://www.asic-world.com/verilog/veritut.html

author: chris_leyson
author_rank: Super Contributor
timestamp: July 02, 2022, 09:20:37 am
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 02, 2022, 09:51:31 am
content: Quote from: Infraviolet on July 01, 2022, 11:09:15 pmGood for you, but realise that it is a steep learning curve and that experience writing programs doesnottranslate 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.QuoteAll decent toolchains willhaveto 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 specifytiming 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.

author: agehall
author_rank: Frequent Contributor
timestamp: July 02, 2022, 02:16:50 pm
content: 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: July 02, 2022, 06:16:06 pm
content: 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

author: tggzzz
author_rank: Super Contributor
timestamp: July 02, 2022, 07:48:58 pm
content: Quote from: agehall on July 02, 2022, 02:16:50 pmC 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)

author: agehall
author_rank: Frequent Contributor
timestamp: July 02, 2022, 07:59:03 pm
content: 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.

author: rstofer
author_rank: Super Contributor
timestamp: July 02, 2022, 09:46:41 pm
content: 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/

author: free_electron
author_rank: Super Contributor
timestamp: July 03, 2022, 04:43:32 am
content: Quote from: agehall on July 02, 2022, 07:59:03 pmthat's what state machines are for. create counter ,load counter, wait for counter to reach zero then next state

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 03, 2022, 06:06:23 am
content: Quote from: agehall on July 02, 2022, 07:59:03 pmWell there is the Phase Locked Loop

author: Someone
author_rank: Super Contributor
timestamp: July 03, 2022, 07:31:48 am
content: Quote from: pcprogrammer on July 03, 2022, 06:06:23 amOr 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).

author: emece67
author_rank: Frequent Contributor
timestamp: July 03, 2022, 11:30:09 am
content: .

author: tggzzz
author_rank: Super Contributor
timestamp: July 03, 2022, 11:49:20 am
content: Quote from: Someone on July 03, 2022, 07:31:48 amThe 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!

author: tinker357
author_rank: Newbie
timestamp: July 03, 2022, 01:50:16 pm
content: Hi,This is my first post so please be gentle.Quote from: RoGeorge on July 02, 2022, 06:27:11 amFor 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.)

author: agehall
author_rank: Frequent Contributor
timestamp: July 03, 2022, 02:36:22 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 03, 2022, 02:44:32 pm
content: Quote from: tinker357 on July 03, 2022, 01:50:16 pmSo 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 03, 2022, 03:10:51 pm
content: Quote from: Someone on July 03, 2022, 07:31:48 amIt was just a joke, but apparently not a good one

author: rstofer
author_rank: Super Contributor
timestamp: July 03, 2022, 03:12:52 pm
content: Quote from: tinker357 on July 03, 2022, 01:50:16 pmBecause 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: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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 03, 2022, 03:28:06 pm
content: Quote from: tinker357 on July 03, 2022, 01:50:16 pmUsing 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.

author: agehall
author_rank: Frequent Contributor
timestamp: July 03, 2022, 05:33:10 pm
content: Quote from: rstofer on July 03, 2022, 03:12:52 pmAnd 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.

author: Someone
author_rank: Super Contributor
timestamp: July 03, 2022, 09:49:45 pm
content: Quote from: pcprogrammer on July 03, 2022, 03:10:51 pmYour 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 03, 2022, 10:22:11 pm
content: Quote from: Someone on July 03, 2022, 09:49:45 pmSometimes knowing what toavoidis very valuable information. Life is too short to make the same mistakes other people have made - but makingnewmistakes isn't dishonourable.

author: Someone
author_rank: Super Contributor
timestamp: July 03, 2022, 11:46:11 pm
content: Quote from: tggzzz on July 03, 2022, 10:22:11 pmYour 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:Quote from: agehall on July 02, 2022, 07:59:03 pm

author: tggzzz
author_rank: Super Contributor
timestamp: July 04, 2022, 12:35:46 am
content: Quote from: Someone on July 03, 2022, 11:46:11 pmLoops 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'tinFPGAs.If loops are synthesisable, then their semantics areverydifferent to those in C.QuoteHDLs 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 arenotsuitable 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

author: Someone
author_rank: Super Contributor
timestamp: July 04, 2022, 04:39:34 am
content: Quote from: tggzzz on July 04, 2022, 12:35:46 amThat's what the OP asked about... hence the replies discussing that rather than your pet flavour point.Quote from: tggzzz on July 04, 2022, 12:35:46 amIts 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:Quote from: Someone on July 03, 2022, 07:31:48 amThe 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 04, 2022, 05:12:57 am
content: The main key here is semantics.This line explains it.QuoteIt 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.

author: Someone
author_rank: Super Contributor
timestamp: July 04, 2022, 05:56:35 am
content: Quote from: pcprogrammer on July 04, 2022, 05:12:57 amthat 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-encoderwhich could be written in HDL or C, and a common solution in the other direction:https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogObviousEqually 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 04, 2022, 06:18:08 am
content: 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?

author: Someone
author_rank: Super Contributor
timestamp: July 04, 2022, 06:33:24 am
content: Quote from: pcprogrammer on July 04, 2022, 06:18:08 amThat'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.

author: RoGeorge
author_rank: Super Contributor
timestamp: July 04, 2022, 07:15:13 am
content: Quote from: Someone on July 04, 2022, 04:39:34 amI see it different.Here's a quote from the link you posted:QuoteTo 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.

author: Someone
author_rank: Super Contributor
timestamp: July 04, 2022, 07:37:53 am
content: Quote from: RoGeorge on July 04, 2022, 07:15:13 amYou're only just considering a subset of the uses of a loop in HDL (and making plainly false generalised statements). Synthesiable loopscanhave 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?

author: sicco
author_rank: Regular Contributor
timestamp: July 04, 2022, 08:45:06 am
content: 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/wikiI 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.

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 04, 2022, 09:00:11 am
content: Quote from: Someone on July 04, 2022, 07:37:53 amI 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 thenandland.comwebsite is very useful.

author: rstofer
author_rank: Super Contributor
timestamp: July 04, 2022, 04:02:38 pm
content: 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 adderYou 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.pdfIt 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: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?

author: tggzzz
author_rank: Super Contributor
timestamp: July 04, 2022, 04:38:04 pm
content: Quote from: rstofer on July 04, 2022, 04:02:38 pmPrecisely.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

author: laugensalm
author_rank: Regular Contributor
timestamp: July 04, 2022, 08:01:21 pm
content: 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:@sensitivity.generatordef wireup():for i in range(8):j = 7 - iyield [ z <= s ]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.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 04, 2022, 09:20:47 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 04, 2022, 11:00:51 pm
content: Quote from: rstofer on July 04, 2022, 04:02:38 pmNo. 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 neverinferinstantiate 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 04, 2022, 11:37:55 pm
content: 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.

author: Someone
author_rank: Super Contributor
timestamp: July 05, 2022, 12:08:21 am
content: Quote from: rstofer on July 04, 2022, 04:02:38 pmIt 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."+" operatorSynthesis 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 12:19:24 am
content: Quote from: SiliconWizard on July 04, 2022, 11:37:55 pmPrecisely.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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 05, 2022, 01:05:39 am
content: Quote from: tggzzz on July 04, 2022, 04:38:04 pmWhile 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.QuoteI 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?QuoteAs opposed to writing HDL and using programmable logic?

author: gnuarm
author_rank: Super Contributor
timestamp: July 05, 2022, 01:09:11 am
content: Quote from: nctnico on July 04, 2022, 11:00:51 pmI think you meant you *always* infer memory and never instantiate it. Is that right?

author: gnuarm
author_rank: Super Contributor
timestamp: July 05, 2022, 01:14:07 am
content: Quote from: SiliconWizard on July 04, 2022, 11:37:55 pmMy 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 07:56:25 am
content: Quote from: gnuarm on July 05, 2022, 01:09:11 amYou are right. I'll change it.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 08:24:02 am
content: Quote from: tggzzz on July 05, 2022, 12:19:24 amThe 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.

author: emece67
author_rank: Frequent Contributor
timestamp: July 05, 2022, 08:48:28 am
content: .

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 09:24:57 am
content: Quote from: gnuarm on July 05, 2022, 01:05:39 amAgreed. That's why I didn't use those as examples, and why I explicitly expanded "gate" to include arbitrarily complex functional blocks.QuoteSpeed 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.Ialwaysconsider 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.QuoteYes, as I said.They have to be instantiated, and that doesn't fit well into thementalityof using a procedural language.QuoteI 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 11:36:50 am
content: Quote from: tggzzz on July 05, 2022, 09:24:57 amNo, 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 11:54:50 am
content: Quote from: nctnico on July 05, 2022, 11:36:50 amStrawman 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.

author: laugensalm
author_rank: Regular Contributor
timestamp: July 05, 2022, 12:09:03 pm
content: Quote from: emece67 on July 05, 2022, 08:48:28 amBelieve 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)

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 12:10:50 pm
content: Quote from: tggzzz on July 05, 2022, 11:54:50 amIt 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 01:30:25 pm
content: Quote from: nctnico on July 05, 2022, 12:10:50 pmSure 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")

author: gnuarm
author_rank: Super Contributor
timestamp: July 05, 2022, 03:07:51 pm
content: Quote from: tggzzz on July 05, 2022, 09:24:57 amI 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.QuoteI'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.QuoteI think you are carrying that water too far and your bucket has a leak.QuoteWhatever 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!QuoteSo 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 04:11:30 pm
content: Quote from: gnuarm on July 05, 2022, 03:07:51 pmYou 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.QuoteI disagree. Perhaps my designs are pushing the limits harder than yours.QuoteUnhelpful analogy which gives no insight. I've seen the effects I've described.QuoteI 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.QuoteWe 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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 05, 2022, 05:36:13 pm
content: Quote from: tggzzz on July 05, 2022, 04:11:30 pmWhat does "nailing down the data path" mean exactly?Do you understand what caused the change in clock rate?QuoteOk, so you have more designs in the 1% then.QuoteOk, 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.QuoteI'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.QuoteI'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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 06:27:27 pm
content: Quote from: gnuarm on July 05, 2022, 05:36:13 pmPlacing 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.QuoteWho 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.QuoteSee earlier posts in this thread. More generally, use duckduckgo.QuoteThe 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-KernelQuoteThe OP is not in that position.My jobs have rarely involved such repetition, because if that was the case then itcouldn'tbe my job!Distracting uus with yor backwoods experiences won't shed any light on FPGA designs.QuoteSuitable 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 07:57:02 pm
content: Quote from: tggzzz on July 05, 2022, 06:27:27 pmSo very wrong! Agoodengineer 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 05, 2022, 08:13:19 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 09:53:43 pm
content: Quote from: nctnico on July 05, 2022, 07:57:02 pmI 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 05, 2022, 10:03:45 pm
content: Quote from: free_electron on July 05, 2022, 08:13:19 pmI 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.QuoteYes, that tends to aid a key objective: simple clarity.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 05, 2022, 11:01:56 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2022, 11:11:50 pm
content: Quote from: tggzzz on July 05, 2022, 09:53:43 pmNo, 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?

author: rstofer
author_rank: Super Contributor
timestamp: July 05, 2022, 11:13:44 pm
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 06, 2022, 12:27:15 am
content: Quote from: tggzzz on July 05, 2022, 06:27:27 pmYou 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.

author: tggzzz
author_rank: Super Contributor
timestamp: July 06, 2022, 01:01:21 am
content: Quote from: gnuarm on July 06, 2022, 12:27:15 amThere is no contradiction there; the concepts are orthogonal.I didn't say youneedto use layout to achieve a stable design. I said I have seencaseswhere it is necessary. Some != all.QuoteSo 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.

author: Neomys Sapiens
author_rank: Super Contributor
timestamp: July 06, 2022, 01:52:56 am
content: FPGA-Based Embedded System Developer's Guide A. Arockia Bazil Raj CRC Press 2018EEDigital Applications of Field-Programmable Gate Arrays in Scientific Research Hartmut F.-W. Sadrozinski and Jinyuan Wu CRC Press 2011Principles and Structures of FPGAs Hideharu Amano (Ed.) Springer 2018Engineering 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 2016Fault-Tolerance Techniques for SRAM-based FPGAs F.L.Kastensmidt, L.Carro, R.Reis Springer 2006Design Recipes for FPGAs Peter R. Wilson Newnes 2006The Design Warrior's Guide to FPGAs C. Maxfield Newnes 2004

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 06, 2022, 03:00:32 am
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 06, 2022, 04:57:27 am
content: Quote from: tggzzz on July 06, 2022, 01:01:21 amYes, 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 06, 2022, 05:03:04 am
content: 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

author: tggzzz
author_rank: Super Contributor
timestamp: July 06, 2022, 07:34:41 am
content: Quote from: gnuarm on July 06, 2022, 04:57:27 amRubbish.Many designs and implementations have to push the technology as hard as possible, since the performance is a selling point.QuoteNot in that case.

author: free_electron
author_rank: Super Contributor
timestamp: July 06, 2022, 01:35:31 pm
content: Quote from: tggzzz on July 06, 2022, 07:34:41 amif you are going for that, a t a price point : go full asic. fpga is too expensive.

author: tggzzz
author_rank: Super Contributor
timestamp: July 06, 2022, 03:22:12 pm
content: Quote from: free_electron on July 06, 2022, 01:35:31 pmRubbish.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.

author: free_electron
author_rank: Super Contributor
timestamp: July 06, 2022, 05:52:21 pm
content: Quote from: tggzzz on July 06, 2022, 03:22:12 pmThose 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 06, 2022, 06:17:36 pm
content: Quote from: free_electron on July 06, 2022, 05:52:21 pmExcept if you expect regular changes/improvements. FPGAs are a no-brainer for this, while you can forget about it with ASICs.

author: free_electron
author_rank: Super Contributor
timestamp: July 06, 2022, 06:51:22 pm
content: Quote from: SiliconWizard on July 06, 2022, 06:17:36 pmthat's why fpga are used to prototype stuff !.

author: tggzzz
author_rank: Super Contributor
timestamp: July 06, 2022, 09:38:30 pm
content: Quote from: free_electron on July 06, 2022, 05:52:21 pmYour points, position, and arguments mutate every time counterexamples show them to be lacking. That's not unreasonable, but beware the "no true Scotsman fallacy".QuoteNobody in their right mind would even consider that an FPGA is suitable in all cases.QuoteSo 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.QuoteMaybe; 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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 06, 2022, 10:29:28 pm
content: Quote from: free_electron on July 06, 2022, 05:03:04 amNot 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.QuoteWhat 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.QuoteI 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.

author: gnuarm
author_rank: Super Contributor
timestamp: July 06, 2022, 10:33:39 pm
content: Quote from: tggzzz on July 06, 2022, 07:34:41 amIf 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.QuoteOk, then nothing you've said about the compiler mucking up your design is really relevant.

author: free_electron
author_rank: Super Contributor
timestamp: July 07, 2022, 12:32:49 am
content: Quote from: tggzzz on July 06, 2022, 09:38:30 pmof 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.Quotejust like nobody in their right mind would consider an asic is suitable in all cases. why would fpga's exist ?QuoteBeen 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.htmllook for "pulsar"https://www.sciencedirect.com/science/article/abs/pii/S0920548999000173

author: laugensalm
author_rank: Regular Contributor
timestamp: July 08, 2022, 11:21:30 am
content: Quote from: free_electron on July 06, 2022, 05:52:21 pmI'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.

author: ale500
author_rank: Frequent Contributor
timestamp: July 23, 2022, 06:38:54 pm
content: those tiny ice40 chips are used in some other phones too, look at the tear downs at I fix it.