Which code is synthesizable?

[aryajur]

Hello,
I am very new to VHDL and I am still learning but I have one very basic confusion. I have read that VHDL follows a top down approach to design generally and it is very convenient.
What I don't understand is suppose we make a VHDL program for some circuit, we may be starting from the behavioral description of the differnt modules and then define details. How do we know at which stage our code is completely synthesizable automatically to a gate level netlist. I mean if out code is very abstract I don't think that a synthesizer will be able to produce a gate netlist. So how do we know that this is the minimum details we need to give so now the code is synthesizable??

Please clarify anyone.

 

[VHDLguy]

hmm. interesting question. For my own part I was taught some basic structures and rules from which I have expanded with experience.

most books will probably list those simple structures, but maybe not in a "these are the basic structures for synthesizable code".

to begin with, if you only use a small set of things:
- don't use variables
- if statements
- case statements
- std_logic_vector and std_logic types

and a few rules like:
- never have a signal in more that one process (a hard rule, not a guideline for synthesizability)
- avoid BIG processes keep them simple and limited to small functions (rather than the whole design). if possible fit them into one page - but sometimes you just have to break this rule.
- try to create a hierarchy, not your whole design in one file.

What is hard for synthesizers?
- big processes. especially big chunks of combinatorial logic.

well there is a start. Maybe someone can find a website with some simple structures and post it. maybe I will if I have time.



--

http://www.lateralsands.com/

 

[aryajur]

Thanks for ur explanation it does clarify some points for me. Just one question from it though u wrote

if you only use a small set of things:
- don't use variables
- if statements
- case statements
- std_logic_vector and std_logic types

so does this mean do not use if statement, case statements, etc or to use them ??

 

[VHDLguy]

sorry, that was confusing.
use:
- if
- case
- std_logic std_logic_vector

don't use
- variables

To add some more to that. as you get the feel of things you can add in variables to help with big loops and similar type things. but avoid using them just in general coding, in the middle of if statements etc.

for example:
signal abc : std_logic_vector(100 downto 0);
signal def : std_logic_vector(100 downto 0);
signal ghi : std_logic_vector(100 downto 0);

...

for i in range (100 downto 0) loop
ghi(i) <= abc(i) xor def(i);
end loop;

for any easy example like this there may be an overload funtion to just say ghi <= abc xor def; But in some examples there is not and a loop (with loop variable) is the way to go.

There will always be people who say - &quot;variables are the best thing since sliced bread&quot; - and they can be used well... but in my experience they can more easily be used badly, and its not often that you HAVE to use them.


A good rule is that if you can't imagine what the synthesizer would create (in hardware) then the synthesizer might have difficulty too. Of course when you start you don't really have a good understanding of what the synthesizer would based on different structure's anyway.

--

http://www.lateralsands.com/

 

[VHDLguy]

This site has some good guidelines, but not much about synthesizability:

http://www.cs.ualberta.ca/~amaral/courses/329/labs/VHDL_Guideline.html

I like their quote about variables:
&quot;Variables are commonly not understood and are therefore not used. Variables are also commonly used and not understood. Variables can be very powerful when used correctly&quot;

This website has a bunch of good easy VHDL examples:

http://www.cs.ucr.edu/content/esd/labs/tutorial

if you look at all the behaviour code examples almost all of the basic structures are covered:
- processes for combinational (or combinatorial whatever you like to call it) circuits
- processes for clocked circuits
- if statements in processes
- case statements in processes.

There isn't much logic outside of processes. And I didn't notice any synchronous resets, I think they were all asynchronous. but you should get the idea.


And one thing that I forgot to mention. Avoid inferring Latches. This can be a problem in a few ways:
1. You were not try to create a latch - you just missed some signals from the sensitivity list of a combinatorial process.
2. You were trying to create a latch (so functionaly its ok), but you are designing an ASIC and now you can't put that register on a boundary scan chain (since only flip-flops can be on the boundary scan chain). Result: your fault coverage is reduced.

1. is more likely to be a problem for most people. Often your synthesizer will say that you missed a signal and that it is assuming you meant to include it. But your simulator will not do that and hence what you synthesize is not the same as what you saw in simulation.

--

http://www.lateralsands.com/