There are certainly many ways to start an FPGA design; for example one can:
- Open up an editor and start coding
- Look for, duplicate and modify an existing reference design
Which approach one chooses is probably a question of deadlines and personal preference.
Our engineers, for example, learned to design by coding so if given the time, they would rather write it out in Verilog/VHDL while referring to reference designs if any exist.
Coding something at least once and making that work is likely the most effective way of "learning by doing" in our opinion. Should you be blessed with the luxury of time and curiosity, there are plenty of resources out there to help.
First, pick a language from the current de-facto standards: Verilog or VHDL. References abound for these two languages and they have been in active use for decades. It seems that VHDL is more popular in Europe and in military/aerospace applications. Verilog accounts for the most of the "rest".
SystemVerilog and SystemC have been on the fringes for a while now, and are seeing increasing use. However their adoption seems to be hampered by a lack of robust and readily-available tool support.
Important things to look out for while coding include:
- Sequential(anything that remembers state) and Combinational logic
- Blocking vs Non-blocking statements (see quick explanation)
- Clocking--see here for a discussion on differences in clock-gating between ASICs and FPGAs
Having an already working reference is a boon in almost all(except when the reference design is too convoluted to understand!) cases. Finding a suitable one might involve trawling FPGA vendors' and design services' and tool vendors' websites for "application notes" or using specialized search engines.
Once a suitable one that fulfills one's end-application is found, here are some considerations:
- Is it available in source code or at least, can it be easily modified?
- What application software/hardware is required to test it - boards, drivers, end-applications?
- Which software/hardware tools are needed to run it and produce the same outputs as advertised - FPGA tools, simulators?
The above factors likely dictate if this reference design is going to be useful, impossible to replicate or too limiting.
Whether the design is created from scratch or from an existing reference, the typical steps in the development process are:
- Functional simulation to prove that your logic works(no going into timing yet!)
Shameless plug: Our online simulation platform using industry-grade simulation tools can help you do functional simulations with minimal hassle!
- If functional simulation passes, time to implement your design on FPGA software
- Input constraints such as clock frequencies and pin locations so that the FPGA software can try to compile your design for your desired speed and IO(e.g. connect the Write-Enable in your code module to the physical Write-Enable signal on your eventual hardware test board) behavior.
Here is where one gets intimately familiar with the FPGA software π
- Typically one also picks a specific FPGA/CPLD device here--which always seems strange because at this stage it is too early to commit to a specific device in our opinion. Kinda like limiting yourself to one tree before understanding the entire forest of possibilities.
- Run the FPGA software to put your design through synthesis, place-and-route, timing analysis and finally(if all goes well), programming file generation.
- If failures occur,
- Examine error logs
- Can't meet target frequency? Too long a datapath? Software can't wrap its head around a certain code construct? -> Change source code
- Constraints are too strict? -> Reduce target frequency or move IO pins or relocate logic blocks
- Repeat
If at the end, you get a working design, all the above was worth your efforts!