Would it have been better to use a ring counter instead of an adder for the modulo 3, modulo 5, and state counters?
Yes, parallel counters would be a simpler solution.
Implementing FizzBuzz on an FPGA
21–30 of 63 posts
Re: Implementing FizzBuzz on an FPGA
#22> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
Think of it more like SQL, where you're describing a model, then a series of steps.
Re: Implementing FizzBuzz on an FPGA
#23Earlier quoted context omitted.
I would suggest that you be VERY careful with that expressiveness if you want to do anything in an actual hardware context. Verilog makes it very easy (IME much easier than VHDL) to create structures that, while technically possible to synthesize, take enormous amounts of logic resources.
The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks. Some interesting ones: * Never use asynchronous resets [on FPGAs] * if-else if-else chaining leads to unnecessary delays (priority encoders) * Avoid latches by making sure to assign default values * Never assume default values and/or states
Sometimes if-else-chaining is what you need. But if you are doing one of n-select, a switch is what you should use.
If you are using Verilog 2001 or later, you can use always @* to implicitly declare all variables a combinational process depends on. It used to be a huge source of latches.
I would also highly advice against mixing blocking (i.e a = x) and non-blocking (i.e. a I also recommend separating data path logic (the processing you do) with the control path (the FSM that keep track of what is happening inside your machine).
Never assume values or states is really good. I usually assign default states at the top of processes. Then for other state you only have to define that. It is really helpful in FSMs.
Not claiming to having a great coding style, but if you want some examples on RTL code and testbenches here are my cores for AES, SHA256 and many others:
Re: Implementing FizzBuzz on an FPGA
#24Earlier quoted context omitted.
Your professor seems great so far but pretty silly of him to teach you verilog instead of VHDL. As an EE myself I haven't seen a job description that says verilog over vhdl in a long time. Might want to familiarize yourself with both if you plan to pursue hardware design further.
VHDL is popular in Europe and the US East Coast. Verilog is king on the West Coast. An an EE who was schooled in VHDL, gave VHDL classes to new hires and was conditioned to look down on Verilog: after moving from Europe to the East Coast and then the West Coast, I eventually saw the error of my ways and I'm very happy to not have to deal with VHDL anymore. And for the open source crowd: there is a much large body of…
I always got more of a VHDL for FPGAs and Verilog for chips kind of vibe. Not that there's anything intrinsic in those languages, just the kinds of industries that ship FPGAs seem to gravitate to a DoD specified language.
And can you elaborate on what you like about Verilog?
Re: Implementing FizzBuzz on an FPGA
#25Earlier quoted context omitted.
The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks. Some interesting ones: * Never use asynchronous resets [on FPGAs] * if-else if-else chaining leads to unnecessary delays (priority encoders) * Avoid latches by making sure to assign default values * Never assume default values and/or states
* Never use asynchronous resets [on FPGAs] It makes no difference for most FPGAs. Most have dedicated resources dedicated to resets and consume equal resources for async and sync resets. For ASIC, sync resets these days are considered safer against glitches because they only have an impact during a rising edge of the clock instead of all the time. But it's not something to be super religious about.
From my understanding, many FPGAs do not have a dedicated reset distribution network. Instead, P&R consumes a ton of resources to propagate resets across the chip.
My information could be out of date though!
Re: Implementing FizzBuzz on an FPGA
#26Earlier quoted context omitted.
The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks. Some interesting ones: * Never use asynchronous resets [on FPGAs] * if-else if-else chaining leads to unnecessary delays (priority encoders) * Avoid latches by making sure to assign default values * Never assume default values and/or states
Sometimes if-else-chaining is what you need. But if you are doing one of n-select, a switch is what you should use. If you are using Verilog 2001 or later, you can use always @* to implicitly declare all variables a combinational process depends on. It used to be a huge source of latches. I would also highly advice against mixing blocking (i.e a = x) and non-blocking (i.e. a I also recommend separating data path logi…
Thanks for the pointers!
Actually, the first thing our professor taught us is when exactly to use blocking and non-blocking and that they should never be mixed.
By the way, I ran across some of your code on GH about a year back and have been following you ever since. Nice coincidence haha :)
Re: Implementing FizzBuzz on an FPGA
#27> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
It depends very much where we as developers come from.
My CS degree had quite a few sections of electronic lectures.
In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.
Re: Implementing FizzBuzz on an FPGA
#28> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
Think of it more like SQL, where you're describing a model, then a series of steps.
Maybe more like dataflow or flow-based programming. Let them play with those a while. Then, make the black boxes FSM's with serious constraints about size or execution time. They'll start getting the idea. Messing with a synchronous or time-oriented language might help, too, in terms of a metaphor for clocks.
Re: Implementing FizzBuzz on an FPGA
#29Earlier quoted context omitted.
The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks. Some interesting ones: * Never use asynchronous resets [on FPGAs] * if-else if-else chaining leads to unnecessary delays (priority encoders) * Avoid latches by making sure to assign default values * Never assume default values and/or states
Your professor seems great so far but pretty silly of him to teach you verilog instead of VHDL. As an EE myself I haven't seen a job description that says verilog over vhdl in a long time. Might want to familiarize yourself with both if you plan to pursue hardware design further.
That is very strange. Verilog and SystemVerilog totally dominates VHDL across the globe in terms of market share. Including Europe. Esp if you are designing ASICs, but also for FPGAs.
If you are desinging ASICs and use VHDL you will quite likely end up having mixed language RTL design. And after synthesis the netlist will be in Verilog. So any co-simulation between RTL and netlist must support both languages. Which costs extra in licenses.
Other reasons for choosing Verilog is that the tool developers (being mainly in the US) knows Verilog best. If you look at the adaption rate of new language features, Verilog (SystemVerilog) gets much more attention.
VHDL is for some reason considered a good school language. I don't see the point of it. It's a bit like teaching the ISO stack. The industry has chosen another stack, the pedagogical value if ISO vs TCP/IP is slim to none. The same can (imho) be said for VHDL.
Re: Implementing FizzBuzz on an FPGA
#30Amazing project to learn how FPGAs work. Not overkill with some high speed interfaces, but touches all problems: no easy division by 3 and 5, counters everywhere, no copy/paste solutions, no libraries with helpful functions. Though Xilinx ISE is obsolete, Vivado is the current tool.
As kens said, and to expand, Xilinx's Vivado doesn't support the Spartan 6, however they _do_ still fully support the Spartan 6 and continue to produce new chips. To support this, they've released a Virtualbox compatible image which runs Oracle Linux with ISE configured specifically to program Spartan 6 FPGAs.[1]
[1]: https://www.xilinx.com/support/download/index.html/content/x...