«

Dear Ingmar,

Thank you very much for your complete and informative explanation for
such a newbie as me. I recommend this article to be assembled into
VHDL FAQ... :=)

I now understand that in a clocked section, the "else" branch can be
safely ignored since it will be a register anyway... I also understand
that special care should be taken when the "if" statement is outside
the clocked section...

I want to further ask:

p0: PROCESS(rst, clk)
BEGIN
if rst = '1' then
for I in 0 to 7 loop
for J in 0 to 7 loop
XX(I)(J)<=0;
end loop;
end loop;
elsif (clk'event and clk = '1') then
XX(POSY)(POSX)<=CONV_INTEGER(X);
else
...
end if;
END PROCESS p0;


I the above code, since the "else" part is outside the clocked
section, but parallel to the asynchonous reset section, do I need to
put something inside the "else" branch? Or, can I safely ignore the
"else" branch?

I hope you can further clarify this issue for me!

Thank you very much,

-Walala

Ingmar Seifert <> wrote in message news:<bjut2p$r1o$>...
> walala wrote:
> > Dear all,
> >
> > I feel confused by "else null" statement:
> >
> > if rst = '1' then
> > count <= 0;
> > elsif clk'event and clk = '1' then
> > if(INPUTEND = '1') then
> > ...
> > end if;
> > end if;
>
> *Registers:*
> In the above example the if-statement is in a *clock-section*.
> For example:
> if(INPUTEND = '1') then
> output <= inputsignal1;
> end if;
> The synthesisis-tool generates a register for the signal called output.
> The clock input of the register is connected to the clock, and the
> enable signal of the register is generated by a block of logic. Here it
> is obviously, that there don't needs to be logic.
> Attention: It doesn't matter if here is a else-branch. In any case a
> register will be generated.
>
> *Latches:*
> Latches are elements, that are triggered by a signal.
> If you write the following out of a clock section then the
> synthesis-tool generates logic.
> if(INPUTEND = '1') then
> output <= inputsignal;
> else
> output <= inputsignal;
> end if;
>
> But if you write only:
> if(INPUTEND = '1') then
> output <= inputsignal;
> end if;
> the synthesis tool has to generate a latch because it can't generate
> logic because it can't generate a boolean equation for the logic. So it
> has to generate a latch.
> Some architectures don't have latches, so they shouldn't used.
>
> *Avoidance of Latches:*
> To avoid (unwanted) latches you either have to desribe what will happen
> with each signal in each branch (like in the logic-example) or do the
> following.
> If you are only interested what happens if INPUTEND='1' and the other
> cases don't care, you can set a default value for the signal output.
> Then in all cases where you haven't specified, what should be happen
> with the ouput-signal the standard value is used by the synthesis-tool
> and logic is genereated. So you can save code and avoid the generation
> of latches.
> A little example (out of a clock section again):
> output <= (others=>'0');
> if(INPUTEND = '1') then
> output <= inputsignal;
> end if;
> It gets only the value of inputsignal, when INPUTEND='1', in all other
> not explicit specified cases it gets the value zero.
>
>
> I hope this helps you understand the problem.
> I can't say anything about the sense of null-statements in the
> else-branches, because I never used it there.
>
>
> Regards,
> Ingmar Seifert

walala wrote:
> Dear Ingmar,
>
> Thank you very much for your complete and informative explanation for
> such a newbie as me. I recommend this article to be assembled into
> VHDL FAQ... :=)

Thanks .
It took me some time too to understand when and why a latch is
synthesized, why a register is put in and all these things. In online
ressources (as well as in many books) you often find the standard syntax
desription. Often examples (and often very easy ones) are given without
a connection to the synthesis result. Unless I write a testbench, this
is very important to me. I don't write the code just for fun.
But a lot of authors don't bother, so it's hard to get some answers to
important questions.

>
> I now understand that in a clocked section, the "else" branch can be
> safely ignored since it will be a register anyway... I also understand
> that special care should be taken when the "if" statement is outside
> the clocked section...
>
> I want to further ask:
>
> p0: PROCESS(rst, clk)
> BEGIN
> if rst = '1' then
> for I in 0 to 7 loop
> for J in 0 to 7 loop
> XX(I)(J)<=0;
> end loop;
> end loop;
> elsif (clk'event and clk = '1') then
> XX(POSY)(POSX)<=CONV_INTEGER(X);
> else
> ...
> end if;
> END PROCESS p0;
>
>
> I the above code, since the "else" part is outside the clocked
> section, but parallel to the asynchonous reset section, do I need to
> put something inside the "else" branch? Or, can I safely ignore the
> "else" branch?

I'm sure you have this from a book. No, you don't need to put something
in it. As you said, it is not clocked.
if rst = '1' then
for I in 0 to 7 loop
for J in 0 to 7 loop
XX(I)(J)<=0;
end loop;
end loop;
This means only, that the rst signal is connected to the registers that
form your matrix.

If you would put something in the else branch I think logic would be
generated. But I'm not 100 percent sure about this.

Could anyone confirm this?

> -Walala
>

Could you please use your real name for further posts.
In usenet it's common to post with real name. Some people ignore threads
without real names and so you get fewer answers.


Regards,
Ingmar Seifert

In article < >,
walala <> wrote:

> p0: PROCESS(rst, clk)
> BEGIN
> if rst = '1' then
> for I in 0 to 7 loop
> for J in 0 to 7 loop
> XX(I)(J)<=0;
> end loop;
> end loop;
> elsif (clk'event and clk = '1') then
> XX(POSY)(POSX)<=CONV_INTEGER(X);
> else
> ...
> end if;
> END PROCESS p0;

Synth tools generally dislike "else" statements after "if" statements that
get implemented as an edge triggered flip-flop. The "elsif" after the
initial "if" is ok because this converts to a reset input on the
flip-flop.

Try to imagine the strange sort of logic that the else can lead to. The
XX value can be changed at any time the clk signal isn't rising. Doing
that in real life isn't easy.

--
--
forging knowledge