| Electronics > Beginners |
| Intro to VHDL & FPGA? |
| << < (3/5) > >> |
| emece67:
. |
| james_s:
The most important thing to remember with HDL is that you're not writing a program. You're describing digital hardware with a special language that superficially resembles a programming language. Picture a schematic of digital logic, now to try to describe it in words, that is what VHDL and Verilog do. In many ways I think existing programming experience is a liability rather than an asset in this case. FPGA development is not programming, it is hardware design. |
| hamster_nz:
I like talking VHDL. Feel free to PM me any questions that you are not brave enough to ask in public. I get the feeling that not many like my VHDL style tips, but here goes. - Avoid 'variables' like the plague. A ':=' is an abomination. You will know when there is no better way, and you are forced to use them. - In a process, try to avoid reading a signal after it is assigned. This will allow you to keep better track of things in your head. It will read like software code. - Consider using the "two process" methodology for a while.See https://www.gaisler.com/doc/structdesign.pdf. It will be attractive for a while, then you seem to grow out of it once you 'grok' HDL more. - Only use STD_LOGIC and STD_LOGIC_VECTOR ports on the interfaces of modules. - Always use SIGNED and UNSIGNED in preference to INTEGER types. - When new to the game, use IP blocks or primitives for memory. Once they stress you out, then infer as many of these as possible. - If designing an simple FSM with lots of sequential states, ask yourself is a one-hot shift register might be a better idea (this will only make sense once you have a coded a few ugly FSMs) - If you have small counters (e.g. counting to 8 or 10) then a shift register might be a better counter. - Separate any I/O magic into their own module, and use the vendor primitives so you get exactly what you ask for. - Avoid clocking wizards. Use the vendor specific primitives so you get what you ask for. - Try to avoid vendor special features, where it makes sense. For example, I always use the vendor's FIFO when two clock domains are involved as it is just too hard to get it right. - Shift registers are cheap. Far cheaper than you would expect. Use them where possible. - Your job is to give the tools more than enough hints to give you the result you want. Don't think that the tools are super-smart. Give them no option but to give you what you want. - If somebody says "Ew! that code looks as if it was written by a 4-year old" but it works, then your job is done. Don't try to show how smart you are, try to show how simple the problem is. - Don't use Verilog. I'm converting a significant bit of VHDL to Verilog and I can not believe how much it hurts. Verilog takes any old tosh and makes it into a working design. |
| agehall:
--- Quote from: hamster_nz on February 15, 2019, 08:26:44 am ---- Don't use Verilog. I'm converting a significant bit of VHDL to Verilog and I can not believe how much it hurts. Verilog takes any old tosh and makes it into a working design. --- End quote --- Curious - what version of Verilog? I've used some VHDL and I'm thinking of trying some SystemVerilog in my next project. From what I've seen, it looks pretty neat. |
| tggzzz:
--- Quote from: rstofer on February 13, 2019, 08:25:34 pm ---There's a lot of good stuff in hamster_nz's code. It's worth visiting his site - lots of projects, quality code. Search for his name here and then find a link to his site in his signature line. --- End quote --- There's no such link that I can see. Given hamster_nz's rules of thumb he outlined above, it may well be worth reading that. Overall my generic (i.e. language independent) "in the absence of more information" position is: * as many FSMs as it takes to make the implementation easy to understand, design/test incrementally, and change later on * two processes for each FSM: one for the asynchronous part, and one for the registers * get the clock domain strategy sorted out before implementing anything, and use manufacturers blocks for every signal that crosses clock-domains * use manufacturers blocks wherever possible, both primitive and "IP-level"; reinventing an ellipitical wheel makes people look stupidBut, of course, good taste is important and those rules of thumb can be broken after careful thought and understanding of the consequences. |
| Navigation |
| Message Index |
| Next page |
| Previous page |