learning VHDL

[Vilvox]

Hello,

I try to learn VHDL and conception flow but i still hve some understanding
problemes ?

* As far as I know, between functionnal and timing simulation, there is the
synthesis step, where we give frequency and hardware specifications.
But what are practical differences for simulation before and after synthesis
?

* Behavioural coding is a way to code state machine (Mealy for exemple) in
VHDL, from a state graph.
But where does the RTL coding comes among this coding ?
The transformation from VHDL code to electronic elements (flip-flop, NAND
gates, ...) is not automatic with CAD tools ?

To sum up, does the designer still have to deal with the flip-flop and gates
description ?

Thanks for your time,

 

[Ralf Hildebrandt]

Hi "Vilvox"

* As far as I know, between functionnal and timing simulation, there is the
synthesis step, where we give frequency and hardware specifications.
But what are practical differences for simulation before and after synthesis
?

I would call them differences.
The synthesis tool translates your code to a netlist, where specific
elementes are connected together. The hardware library of your target
process (standart cell CMOS, FPGA...) provides these elements.

The connection in the netlist is not very different to a netlist for an
analog simulator like spice / spectre - but has totally different
syntax. ,-)

The netlist is plain VHDL. Components are intantiated and connected
together. You could also manually write it - but it would be huge amount
of work. ;-)

The components instantiated in the netlist (the logical gates, that are
supported by your target process) got behavioral descriptions in VHDL.
These descriptions provide simulated behavior of the real gate. (e.g.
setup- and hold-times are modelled and much more)

If you simulate with the netlist, you simulate with the delays, thet are
described in the behavioral description of the gate. It is nothing more
than a simple "after XYZ ns".

-> If you simulate you not-synthesized behavioral description, you
mostly simulate without delay times - unless you write some into your
code. (But this leads to not-sythesizable code.) If you simulate with
the synthesized description (the netlist), you simulate with the
gate-delays simulated by the behavioral descriptions of the gates. No
wire-delay is simulated at this point.

If you do a layout, you can extract the wire delays and simulate with
them. This is called back-annotation.

* Behavioural coding is a way to code state machine (Mealy for exemple) in
VHDL, from a state graph.

... not only state machines... simply everything.

But where does the RTL coding comes among this coding ?

You can write VHDL on behavior level:

if (a='1' AND b='0') XOR c='1 then -- and so on...

you can also write on a lower level:
d<=(a AND NOT(b)) XOR c;

and you can also directly instantiate the AND-, the NOT- and the
XOR-gate from you target process library - e.g.:

AND_gate01: dd_and2 port map(A=>a, B=>b, Q=>dummy);

(the last is the code of a netlist ,-))


As you can see - the borders between behavioral and RTL-coding are very
smooth.

The transformation from VHDL code to electronic elements (flip-flop, NAND
gates, ...) is not automatic with CAD tools ?

It is. This is what synthesis does.

To sum up, does the designer still have to deal with the flip-flop and gates
description ?

Not unless problems occur.


Ralf

 

[Jerker Hammarberg]

I'm a beginner too, but I think I can give some partial answers. If I'm
wrong, I hope the gurus will correct me!

* Behavioural coding is a way to code state machine (Mealy for exemple) in
VHDL, from a state graph.
But where does the RTL coding comes among this coding ?
The transformation from VHDL code to electronic elements (flip-flop, NAND
gates, ...) is not automatic with CAD tools ?

There should be some behavioural synthesis tools that would compile all the
way down from behavioural level. I know of one, namely Synopsys Behavioral
Compiler.

To sum up, does the designer still have to deal with the flip-flop and gates
description ?

I'm not sure if I understand the question, but you shouldn't have to deal
with flip-flops and gates even with "ordinary" synthesis tools at RTL. I'm
actually myself struggling with a state machine where behavioural synthesis
would have done the trick; you can see my attempts in the thread "Beginner
question: What trigs processes". No explicit flip-flops or gates in sight!

Of course there may be applications where it is appropriate to design at
structural or gate level.

/Jerker

 

[Pieter Hulshoff]

* Behavioural coding is a way to code state machine (Mealy for exemple)
RTL is just a limitation on how you can write your code so the synthesizer
will understand it. RTL stands for Register Transfer Level (if I'm not
mistaken), and it implies that you have to set up your code to describe how
the data is transferred (and transformed) from one register to the next.

It is, provided your VHDL code adheres to some rules.

I'm not sure if I understand the question, but you shouldn't have to deal
with flip-flops and gates even with "ordinary" synthesis tools at RTL.

You are correct here. The designer doesn't have to deal with the FF and
gates description, but a designer should be thinking in those terms. He/she
should think: I will place my data in a register here, then perform these
actions (multiply, add, fourier transformation, and then place my data in
this register here.

I know all this must sound a bit cryptic, but it's easier to explain based
on some small design you have in mind. If you have something of that kind,
just let me know, and I'll see if I can make the answer clear based on some
VHDL code.

Regards,

Pieter Hulshoff

 

[Vilvox]

To sum up, does the designer still have to deal with the flip-flop and
gates

Not unless problems occur.

in such a case, does the designer have to deal with the netlist by hand ?

 

[Ralf Hildebrandt]

Hi "Vilvox"!

in such a case, does the designer have to deal with the netlist by hand ?

No, but in such a case, the designer should think about, how the
synthesis tool solves the specific problem. Sometimes one has to look at
the synthesis solution and has to think about, what could be the problem
for an error.

A good example is the "muxed latch problem": One has to latch some data,
but one has to chose from some different sources to latch. (e.g. 3-way
muxed input to a latch) If one describe the mux-selector and the
latch-enable to be the same, the following might occur: Because of the
normal gate- and wire-delays the mux-selecetor may switch short before
the latch-enable is turned off. -> Wrong data might be latched.
If you only look at the behavioral description, no error is visible.
Behavioral simulation is fine. If you look at a graphical visualisation
of the netlist, this muxed-latch-problem is visible (after some time you
look at it ,-) ).


Ralf