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

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod