process

[u_stadler]

hi

one question: is there any advantage or reason to have more than one
process in an architecture?
any disadvantage or is it just good design practice?

thanks
urban

 

[David Bishop]

hi

one question: is there any advantage or reason to have more than one
process in an architecture?
Yes.

any disadvantage or is it just good design practice?

Breaking up your design into smaller process statements makes it easier
for Synthesis. It also makes your design much more modular. I tend to
break my VHDL code up into several process statements, where the first
one registers the inputs, and the last one registers the outputs.

 

[Ralf Hildebrandt]

one question: is there any advantage or reason to have more than one
process in an architecture?
any disadvantage or is it just good design practice?

Normally one uses a process to describe a flipflop, a latch or a bunch
of combinational logic. You may mix all this into a single process, but
then it is very difficult to see, what hardware will be the result after
synthesis.

Processes are "boxes" that group some things, that are closely related.
For e.g. a mux such closely related things are the inputs and the selectors.
Sometimes this kind of fine grain description is too fine - especially
for state machines, where it is often handy to put some muxes, adders
and the flipflops into one process. But nevertheless - the process again
groups signals, that are closely related.

Every group of such signals may be put into a component, but connecting
so many components will result in a design one may not oversee any more.

Ralf

 

[Mike Treseler]

one question: is there any advantage or reason to have more than one
process in an architecture?

It's mostly a matter of style for synchronous designs.
If you think algorithmically you will like sharing
functions, procedures and variables in a single process.
If you think schematically, you will like
the netlist feel of multiple processes and
won't mind having to declare signals to
wire them together.

-- Mike Treseler

 

[Hal Murray]

Breaking up your design into smaller process statements makes it easier

for Synthesis.

Are synthesis tools really so primitave that they can't break things
up and/or put them together as appropriate for their needs? Anybody got
any numbers or examples to back that up?

 

[Jos De Laender]

Normally one uses a process to describe a flipflop, a latch or a bunch
of combinational logic. You may mix all this into a single process, but
then it is very difficult to see, what hardware will be the result after
synthesis.

Processes are "boxes" that group some things, that are closely related.
For e.g. a mux such closely related things are the inputs and the
selectors.
Sometimes this kind of fine grain description is too fine - especially
for state machines, where it is often handy to put some muxes, adders
and the flipflops into one process. But nevertheless - the process again
groups signals, that are closely related.

Every group of such signals may be put into a component, but connecting
so many components will result in a design one may not oversee any more.

This was indeed my remark after reading previous paragraphs : grouping
like you say (that's in a structural way) should in my opinion be done
by using entities. Is there by the way any reason why using multiple
processes would be more overseeable than multiple entities ?

Jos

 

[Ralf Hildebrandt]

Jos De Laender wrote:

This was indeed my remark after reading previous paragraphs : grouping
like you say (that's in a structural way) should in my opinion be done
by using entities. Is there by the way any reason why using multiple
processes would be more overseeable than multiple entities ?

Sometimes you have to model every flipflop manually - including very
special async set/reset and the normal D-type input (comb. logic). Often
two flipflops not very similar and have nothing more in common, than
maybe they are groupd into a bigger vector (that is read by another
component in parallel).
If you would put such two flipflops into on process, it is difficult to
see what part belongs to the one ff and what part to the other and
easily you may add unwanted overhead.

For combinational logic this makes really a difference, because you have
to assign a value (at least don't care 'X') in every possible branch to
avoid modelling a latch. If you put some similar, but not equal signals
into one process, it may be, that your if/case-branches become ugly.
Reading you design some days or weeks later may be not really nice.

For the synthesis breaking the desing into smaller processes means doing
a part of the synthesis manually. Usually the best advice for synthsis
is a clear description without to much manual modelling, but if it is
really clear what you want to model, it helps the synthesis tool a
little bit find out, what exactly you have described. For example if you
just write a<=b+c; somewhere in a process within one branch of
if/case-statements and a<=b+d; in an other the synthesis tool has two
options how to implement it
* two adders followed by a mux
* a mux followed by an adder
Obviously the 2nd option occupies less area. Are you shure, that every
synthesis tool, that will be used with your code will choose the 2nd
alternative?

Ok - often (yes - sometimes very often ;-)) the designer does not choose
the best solution and the sythesis tool is smarter. Then it might be not
the best option to break everything down, but on the other hand, if you
can break it down, then the synthesis tool will do it too and
additionally you really know whats going on in your design. (It is not
just a bunch of magic gates that do the job, which makes bugtracking and
bug-avoiding easy.)

Ralf

 

[Adrian Spilca]

hi

one question: is there any advantage or reason to have more than one
process in an architecture?
any disadvantage or is it just good design practice?

thanks
urban

I am a beginner in VHDL, so I might be wrong. But I read all the replies so
far and I think the main reason was not mentioned.

Processes are parallel executing units. Within a process (or including
everything in one process) means statements will be executed sequentially.

If you define signals in your architecture, it is very likely that you will
need to define more processes (unless the block you are describing is a
simple one). That is because a signal will only assign a value at the exit
of the process, which means there is no much sense to use sequential
statements to successively alter a signal.

It is a matter of taste whether to use signals (have control over the
synthesis) or variables (give credit to the tools). For the simulator it
probably doesn't matter. But if you think of synthesising your design and
more, to get some manual intervention in order to make it smaller / faster,
you will have to describe your design in a modular way and think more or
less of every module as a piece of hardware primitive.

Adrian

 

[Mike Treseler]

Are synthesis tools really so primitave that they can't break things
up and/or put them together as appropriate for their needs?

Synthesis tools do a much better job that they
get credit for. I have coded very complex design
entities for packet processing applications
using a single process and have never had a
problem with synthesis. I always view the rtl
schematics generated by synthesis and the
work is always as good or better than I could
have done myself manually using multiple processes
or entities.

Anybody got
any numbers or examples to back that up?

Using single process coding saves me time.
I don't get paid to do designs more than
once so I don't have any formal proof.
All I can say is "try it and see".
You might agree.

I do have an example benchmark comparing
synthesis performance vs. template type here:
http://home.comcast.net/~mike_treseler/uart.vhd

Anyone interested in this subject ought to read
and think about Ian Lang's articles here:
http://www.designabstraction.co.uk/Articles/Advanced Synthesis Techniques.htm

-- Mike Treseler

 

[Mike Treseler]

If you define signals in your architecture, it is very likely that you will
need to define more processes (unless the block you are describing is a
simple one). That is because a signal will only assign a value at the exit
of the process, which means there is no much sense to use sequential
statements to successively alter a signal.

Exactly. A single process can update the
output register values on each clock edge.
The only "signal" assignment you really need
is to update the entity output ports from
the local register variable.

It is a matter of taste whether to use signals (have control over the
synthesis) or variables (give credit to the tools).

You have hit the nail on the head.
Many distrust their synthesis tools without
ever having put them in the game.

For the simulator it probably doesn't matter.

Simulation runs much faster using variables
and a single process.

But if you think of synthesising your design and
more, to get some manual intervention in order to make it smaller / faster,
you will have to describe your design in a modular way and think more or
less of every module as a piece of hardware primitive.

Trust involves giving up some control,
but I can easily verify the the quality of the work.
If I already have the primitive netlist in my head,
and I simply need to make multiple copies,
then I don't need synthesis. However, this
has never been the case in my designs.
For me, the point is to get the fpga image
done quickly and to have it work the first time.

-- Mike Treseler

 

[mindenpilot]

hi

one question: is there any advantage or reason to have more than one
process in an architecture?
any disadvantage or is it just good design practice?

thanks
urban

I'm another VHDL beginner, so I'm going to ask another question in response
to your question and hope someone will answer.
Since processes can be like flip flops, could you possibly use multiple
processes if your complex combinational logic exceeds static timing?
That is, break up the logic so that the flop to flop path goes through fewer
gates?

Adam

 

[Mike Treseler]

Since processes can be like flip flops,

(or anything else)

could you possibly use multiple
processes if your complex combinational logic exceeds static timing?
That is, break up the logic so that the flop to flop path goes through fewer
gates?

Yes this is called pipelining and
you can do it by wiring processes
together.

Within a single synchronous process you can
do the same thing with a
case rollover_count_v is ...


-- Mike Treseler

 

[Ralf Hildebrandt]

mindenpilot wrote:

Since processes can be like flip flops

No - a process can be used to model a flipflop, latch or combinational
logic (and some special things like tri-state buffers). Additionally
often one models inside a process a flipflop and the related
combinational logic.

It depends just on you what you put into a process.

, could you possibly use multiple
processes if your complex combinational logic exceeds static timing?

The path length does not depend on how you model the path. It depends on
what you model. For example the following two processes
---
process(sel,data1,data2)
begin
if (sel='1') then
muxed<=data1;
else muxed<=data2;
end if;
end process;

process(reset,clk)
begin
if (reset='1') then
dff<='0';
elsif rising_edge(clk) then
dff<=muxed;
end if;
end process;
---
represent the same as the next process;
---
process(reset,clk)
begin
if (reset='1') then
dff<='0';
elsif rising_edge(clk) then
if (sel='1') then
dff<=data1;
else dff<=data2;
end if;
end if;
end process;
---
It is just a matter of coding style. Almost everytime you have several
possible options to model the same hardware. Remember that e.g. the mux
from the example can be also written with
---
muxed<=data1 when sel='1' else data2;
---

Short: The way of coding does not change hardware, but the idea behind
the model does.



To give a more practival example: If you have a counter, that counts
downward to zero (and then something has to happen) you could just test
---
....
if (counter=0) then...
....
---
but this is not the best solution for this problem, because decrementing
to zero results in a carry-out. So if the carry-out is '1', zero is
reached and therefore you just have to check one signal - not a full
vector. This is an idea, that improves the design. You may code this
similar to the 2-process example given above or with the 1-process
example. For this example I personally (!) prefer the 2-process style,
because this makes it easier for me to read my code and to model it
avoiding unnessecary overhead for synthesis. Nevertheless - both coding
styles will result in the same hardware - if modelled well.


Ralf

 

[Dave Pollum]

Ralf Hildebrandt wrote:

To give a more practival example: If you have a counter, that counts
downward to zero (and then something has to happen) you could just test
---
...
if (counter=0) then...
...
---
but this is not the best solution for this problem, because decrementing
to zero results in a carry-out. So if the carry-out is '1', zero is
reached and therefore you just have to check one signal - not a full
vector. This is an idea, that improves the design. <snipped>

Ralf

Ralf, I'm still a bit of a newbie. Could you post some code that shows
the counter with a "carry-out"?
Thanks,
-Dave

 

[Ralf Hildebrandt]

Dave Pollum wrote:

Ralf, I'm still a bit of a newbie. Could you post some code that shows
the counter with a "carry-out"?

constant width : integer:=16;
signal cnt : unsigned(width-1 downto 0);
signal cnt_dec : unsigned(width downto 0);

....

cnt_dec<= ('0' & cnt) - 1; -- decrementer with carry-out
-- or more elegant (and also suitable for type signed)
-- cnt_dec<=resize(cnt, width+1) - 1;

-- cnt_dec(width) is carry_out

process(reset,clk)
begin
if (reset='1') then
cnt<=(others=>'0');
elsif rising_edge(clock) then
cnt<=cnt_dec(width-1 downto 0);
if (cnt_dec(width)='1') then -- cnt=0

-- do somthething special here
end if;
end if;
end process;


You may put the decrementer into the synchronous process - hardware will
be the same. For me (!) it is more convenient to have it outside to
highlight the functional behavior - especially, if the synchronous
process will be bigger.


Ralf

 

[Rob Dekker]

Ralf Hildebrandt wrote: [...]

Every group of such signals may be put into a component, but connecting so many components will result in a design one may not
oversee any more.

This was indeed my remark after reading previous paragraphs : grouping like you say (that's in a structural way) should in my
opinion be done by using entities. Is there by the way any reason why using multiple processes would be more overseeable than
multiple entities ?

For synthesis it makes a big difference if code is partitioned using
multiple processes versus multiple entities.
Entities define hierarchy borders in synthesis tools, while
multiple processes create logic in a single level of hierarchy.

The hierarchy borders of entities can typically not be crossed by optimization
algorithms inside the synthesis tool (including even simple optimizations such
as constant propagation).

In the end, that means a smaller and faster implementation using processes.

So, use entity design partitioning only for large blocks which require a
defined, solid interface.

Rob