Conditional signal assignment or process statement
 

Hi Gurus,

What is your opinion for coding combinational logic (multiplexer) in
VHDL. Using a conditional signal assignment or using a process? What are
the pro's and con's for both?

I can imagine that for simulation performance a process is efficienter
as it will only be reached when one of the signals on the sens. list
changes. A con could be the danger of an incomplete sens. list.

I would like to know your opinion and what your are using.

Thanks,

Devas

Re: Conditional signal assignment or process statement
 

On 12 Apr., 08:37, devas <geve...@gmail.com> wrote:
> Hi Gurus,
>
> What is your opinion for coding combinational logic (multiplexer) in
> VHDL. Using a conditional signal assignment or using a process? What are
> the pro's and con's for both?
>
> I can imagine that for simulation performance a process is efficienter
> as it will only be reached when one of the signals on the sens. list
> changes. A con could be the danger of an incomplete sens. list.
>
> I would like to know your opinion and what your are using.
>
> Thanks,
>
> Devas

Hi Devas,
with the upcoming of VHDL-2008 and the
process(all)
feature, the differences in performance and danger of simulation
faults should be rendered to almost neglectable.
Also with VHDL-2008 the
when..else
and
with..select
constructs can be used inside processes.
So, even the coding style difference is mostly evened out.

What's left is merely a question of personally prefered coding style.

One might argue, that not all synthesis tools support this yet, but
time flies and before long this won't be a problem anymore.
---
My personal choice is to have as few concurrent code lines in my
architecture as possible, and put every functional part in processes.
Sometimes specific assignments to output ports are necessary, but
that's just one-liners.

Have a nice synthesis
Eilert

Re: Conditional signal assignment or process statement
 

On Apr 12, 7:37*am, devas <geve...@gmail.com> wrote:
> Hi Gurus,
>
> What is your opinion for coding combinational logic (multiplexer) in
> VHDL. Using a conditional signal assignment or using a process? What are
> the pro's and con's for both?
>

Theres not really a lot of difference. A signal assignment outside of
a formal process is really just another process, with the sensitivity
list set by the signals on the right hand side.

so this code:

output <= a when sel = '0' else b;

is the same as:

process(a, b, sel)
begin
if sel = '0' then
output <= a;
else
output <= b;
end if;
end process;

Re: Conditional signal assignment or process statement
 

On Apr 12, 4:16*am, Tricky <trickyh...@gmail.com> wrote:
> On Apr 12, 7:37*am, devas <geve...@gmail.com> wrote:
>
> > Hi Gurus,
>
> > What is your opinion for coding combinational logic (multiplexer) in
> > VHDL. Using a conditional signal assignment or using a process? What are
> > the pro's and con's for both?
>
> Theres not really a lot of difference. A signal assignment outside of
> a formal process is really just another process, with the sensitivity
> list set by the signals on the right hand side.
>
> so this code:
>
> output <= a when sel = '0' else b;
>
> is the same as:
>
> process(a, b, sel)
> begin
> * if sel = '0' then
> * * output <= a;
> * else
> * * output <= b;
> * end if;
> end process;

I see one major difference. The process is eight lines of code and
the concurrent statement is only one. Which do you think is easier to
read and provides fewer opportunities for errors?

Rick

Re: Conditional signal assignment or process statement
 

On Apr 12, 3:11*pm, rickman <gnu...@gmail.com> wrote:
> > so this code:
>
> > output <= a when sel = '0' else b;
>
> > is the same as:
>
> > process(a, b, sel)
> > begin
> > * if sel = '0' then
> > * * output <= a;
> > * else
> > * * output <= b;
> > * end if;
> > end process;
>
> I see one major difference. *The process is eight lines of code and
> the concurrent statement is only one. *Which do you think is easier to
> read and provides fewer opportunities for errors?

In the interests of civil discussion I'll
temporarily pretend that this stance doesn't
make my blood boil.

Instead I'll politely point out that, on the
very rare occasions when I really want something
that simple as a standalone thing, then the
concurrent statement is indeed probably better.
Three-state I/O buffers are the best and
commonest example.

And I'll also politely point out that
decomposing designs into pieces small enough
to represent as concurrent statements makes
each piece trivially easy to understand, but
makes the whole design as comprehensible as
a broken-up jigsaw puzzle.

Taking a complicated thing and breaking it
into lots of simple pieces doesn't make it
simpler. It simply turns the complicated
thing into a pile of pieces.
--
Jonathan Bromley

Re: Conditional signal assignment or process statement
 

On Apr 12, 11:54*am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
> On Apr 12, 3:11*pm, rickman <gnu...@gmail.com> wrote:
> > I see one major difference. *The process is eight lines of code and
> > the concurrent statement is only one. *Which do you think is easier to
> > read and provides fewer opportunities for errors?
>

> Instead I'll politely point out that, on the
> very rare occasions when I really want something
> that simple as a standalone thing, then the
> concurrent statement is indeed probably better.

Based on what devas posted, the 'standalone thing' is all that one can
guess that devas is interested in for the reasons that were listed.

>
> Taking a complicated thing and breaking it
> into lots of simple pieces doesn't make it
> simpler. *It simply turns the complicated
> thing into a pile of pieces.

I agree in principle...but in this case, the only context given by
devas in his posting was in the pros and cons of coding a mux as
either a conditional signal assignment or using a process. In this
case, there is no 'complicated thing' being broken into simpler
pieces.

Your comment though is valid, but should be directed to devas within
the context of 'hey, why are you spending time thinking about the
coding of a mux'? The opportunities to code a mux by itself are
relatively few and far between. The opportunities to describe logic
that also includes mux-like behavior are far more numerous and rarely
are enhanced by the ability to describe this behavior explicitly as a
standalone thing (whether as a process or concurrent statement).

But then again maybe devas is just getting started in design and/or
VHDL or perhaps his interest is not in designing something in VHDL but
is actually in simulator performance, or some theoretical language
aspect, something more abstract, who knows?

In any case, devas was already aware of the major drawback from the
standpoint of creating reliable/maintainable designs of the process
which is that of an incomplete sensitivity list (prior to VHDL-2008).
On the other hand, devas seems misinformed (or maybe needs to
experimentally try) about why he thinks the process approach would be
more efficient in simulation than the concurrent assignment.

Kevin Jennings

Re: Conditional signal assignment or process statement
 

On Tue, 12 Apr 2011 09:27:39 -0700 (PDT), KJ wrote:

>Based on what devas posted, the 'standalone thing' is all that one can
>guess that devas is interested in for the reasons that were listed.

I apologize if I confused or misled the OP. My post
was responding to yet another clear description of the
position that states "bugs increase monotonically with
lines of code, therefore anything that locally reduces
the number of lines of code is good". This I regard as
such pernicious nonsense that I will unapologetically
seize on any opportunity to challenge it, especially
if expressed in a way that encourages the decomposition
of designs into absurdly small and meaningless pieces.

>In this case, there is no 'complicated thing'
>being broken into simpler pieces.

True. I carefully pointed out that this can happen, in some
very specific situations, and there the shorter description
is entirely appropriate.

>Your comment though is valid, but should be directed to devas within
>the context of 'hey, why are you spending time thinking about the
>coding of a mux'?

It could have been, but wasn't; that was not my target.
The OP's question was reasonable, and evinced reasonable
answers; it was the added spin on those answers that
riled me.
--
Jonathan Bromley

Re: Conditional signal assignment or process statement
 

For one simple, combinatorial function with one output, I prefer the
concurrent assignment.

Features that make me lean toward using a process include:

more than one output controlled similarly by the same inputs,
logic that feeds a register within the same architecture,
nested if-then logic,
existence of related logic that is already in a process

Since one or more of these features is often present in my projects, I
usually use processes with sequential statements, synchronous when
possible.

Extensive use of concurrent statements starts to look like coding a
netlist (and reads like one too), instead of coding a synthesizeable
behavior with sequential statements, which is usually easier to
understand.

Andy

Re: Conditional signal assignment or process statement
 

On 4/11/2011 10:37 PM, devas wrote:

> What is your opinion for coding combinational logic (multiplexer) in
> VHDL. Using a conditional signal assignment or using a process? What are
> the pro's and con's for both?

> I would like to know your opinion and what your are using.

Synthesis requires an entity.
Since each entity has code overhead,
I describe logic at a higher level for less overall code.

I describe the entity output ports only
in terms of input ports and local variables,
rather than muxes and flops.

For example in this stack design: http://bit.ly/fkbaqW
no muxes are described directly,
yet synthesis inferred several: http://bit.ly/g5Asyr


-- Mike Treseler

Re: Conditional signal assignment or process statement
 

On Apr 13, 4:13*am, Andy <jonesa...@comcast.net> wrote:
> For one simple, combinatorial function with one output, I prefer the
> concurrent assignment.

Yes, for me as well. If a block (or sub-block) seems simple enough to
describe as a one-liner (or a few lines) of concurrent statements, go
for it. If my block/sub-block starts getting a bit more complex, I'll
start putting those concurrent statements within a process instead.

When it gets difficult to behaviourally describe your functionality
with just a few concurrent statements, and when you start breaking up
a concurrent statement to multiple smaller concurrent statements,
that's when you're beginning to change your behavioural design to a
structural one, i.e. one that doesn't describe the behaviour and
therefore is difficult to understand. When I could foresee that I'm
heading this (wrong) direction, I'll steer myself back to enclose
those statements in a process, and add whatever other functionality I
need.

Daniel Kho