Coding Practices for Combinational and Sequential circuits

Hi,

I have been always been taught so and try to strictly follow the
practice of splitting my design into combinational and sequential
blocks (see example below). However, I have been asked to look at
somebody's design at my workplace that does not do so, and I do not
know whether I should ignore his style or bring it to the notice of
the manager. I am looking for the most convincing explanation as to
why the second style is not good.

----------My style----------------------

Sequential
---------------

always @(posedge clock)
data_out <= data_out_comb;

Combinational
---------------------

always @(reset_n or data_a or data_b)
if (~reset_n)
data_out_comb = 0;
else
data_out_comb = data_a + data_b;




-------Mixed sequential and combinational design----------------

always @ (posedge clock or negedge reset_n)
begin
if(~reset_n)
data_out <= 0;
else
data_out <= data_a + data_b;
end



P.S The second coding style doesn't even have the signals data_a and
data_b in the sensitivity list.


Thanks
kb33

"kb33" <kanchan.devarakonda@gmail.com> wrote in message
news:148cf446-25ee-40e1-996c-a25671a4dab1@j22g2000hsf.googlegroups.com...
> Hi,
>
> I have been always been taught so and try to strictly follow the
> practice of splitting my design into combinational and sequential
> blocks (see example below). However, I have been asked to look at
> somebody's design at my workplace that does not do so, and I do not
> know whether I should ignore his style or bring it to the notice of
> the manager. I am looking for the most convincing explanation as to
> why the second style is not good.
>
> ----------My style----------------------
>
> Sequential
> ---------------
>
> always @(posedge clock)
> data_out <= data_out_comb;
>
> Combinational
> ---------------------
>
> always @(reset_n or data_a or data_b)
> if (~reset_n)
> data_out_comb = 0;
> else
> data_out_comb = data_a + data_b;
>
>
>
>
> -------Mixed sequential and combinational design----------------
>
> always @ (posedge clock or negedge reset_n)
> begin
> if(~reset_n)
> data_out <= 0;
> else
> data_out <= data_a + data_b;
> end
>
>
>
> P.S The second coding style doesn't even have the signals data_a and
> data_b in the sensitivity list.
>
>
> Thanks
> kb33
>
>
>

There is nothing wrong with either style. They both synthesize, simulate and
read. It is style and there are many different syles that people have. It's
personal preference.

Mike

On Aug 27, 11:32*am, kb33 <kanchan.devarako...@gmail.com> wrote:
> Hi,
>
> I have been always been taught so and try to strictly follow the
> practice of splitting my design into combinational and sequential
> blocks (see example below). However, I have been asked to look at
> somebody's design at my workplace that does not do so, and I do not
> know whether I should ignore his style or bring it to the notice of
> the manager. I am looking for the most convincing explanation as to
> why the second style is not good.
>
> ----------My style----------------------
>
> Sequential
> ---------------
>
> always @(posedge clock)
> * *data_out <= data_out_comb;
>
> Combinational
> ---------------------
>
> always @(reset_n or data_a or data_b)
> * *if (~reset_n)
> * * * data_out_comb = 0;
> * *else
> * * * data_out_comb = data_a + data_b;
>
> -------Mixed sequential and combinational design----------------
>
> always @ (posedge clock or negedge reset_n)
> * *begin
> * * * if(~reset_n)
> * * * * *data_out <= 0;
> * * * else
> * * * * *data_out <= data_a + data_b;
> * *end
>
> P.S The second coding style doesn't even have the signals data_a and
> data_b in the sensitivity list.
>
> Thanks
> kb33

There is nothing wrong with the second example. In fact, it is my
preferred
style. More concise, less prone to typos.


John Providenza

kb33 <kanchan.devarakonda@gmail.com> writes:

> -------Mixed sequential and combinational design----------------
>
> always @ (posedge clock or negedge reset_n)
> begin
> if(~reset_n)
> data_out <= 0;
> else
> data_out <= data_a + data_b;
> end
>
>
>
> P.S The second coding style doesn't even have the signals data_a and
> data_b in the sensitivity list.

And, it *should not*. The logic is not sensitive to changes in those
signals. It merely samples those signals when the appropriate edges
occur. If you add the data_a or data_b signals to the sensitivity
list, you will get something that doesn't behave properly. It will
change at non edges of the clock and reset signals.

Hope this helps,
Chris

On Aug 27, 11:26*pm, Chris F Clark <c...@shell01.TheWorld.com> wrote:
> kb33 <kanchan.devarako...@gmail.com> writes:
> > -------Mixed sequential and combinational design----------------
>
> > always @ (posedge clock or negedge reset_n)
> > * *begin
> > * * * if(~reset_n)
> > * * * * *data_out <= 0;
> > * * * else
> > * * * * *data_out <= data_a + data_b;
> > * *end
>
> > P.S The second coding style doesn't even have the signals data_a and
> > data_b in the sensitivity list.
>
> And, it *should not*. *The logic is not sensitive to changes in those
> signals. *It merely samples those signals when the appropriate edges
> occur. *If you add the data_a or data_b signals to the sensitivity
> list, you will get something that doesn't behave properly. *It will
> change at non edges of the clock and reset signals.
>
> Hope this helps,
> Chris

The second style requires half the always blocks, half the signal
declarations, and does not require all of the inputs to be listed in
the sensitivity list.

What's not to like?

Many simulators also merge multiple always blocks with the same
sensitivity lists into one for execution, reducing scheduling
overhead. The second style is more amenable to this optimization,
since only the clock and reset are ever used in the sensitivity lists.
Having a lot of processes in the first style with more or less random
sensitivity lists defeats the optimization.

Andy

On Aug 28, 6:37*am, Andy <jonesa...@comcast.net> wrote:
> On Aug 27, 11:26*pm, Chris F Clark <c...@shell01.TheWorld.com> wrote:
>
>
>
> > kb33 <kanchan.devarako...@gmail.com> writes:
> > > -------Mixed sequential and combinational design----------------
>
> > > always @ (posedge clock or negedge reset_n)
> > > * *begin
> > > * * * if(~reset_n)
> > > * * * * *data_out <= 0;
> > > * * * else
> > > * * * * *data_out <= data_a + data_b;
> > > * *end
>
> > > P.S The second coding style doesn't even have the signals data_a and
> > > data_b in the sensitivity list.
>
> > And, it *should not*. *The logic is not sensitive to changes in those
> > signals. *It merely samples those signals when the appropriate edges
> > occur. *If you add the data_a or data_b signals to the sensitivity
> > list, you will get something that doesn't behave properly. *It will
> > change at non edges of the clock and reset signals.
>
> > Hope this helps,
> > Chris
>
> The second style requires half the always blocks, half the signal
> declarations, and does not require all of the inputs to be listed in
> the sensitivity list.
>
> What's not to like?
>
> Many simulators also merge multiple always blocks with the same
> sensitivity lists into one for execution, reducing scheduling
> overhead. The second style is more amenable to this optimization,
> since only the clock and reset are ever used in the sensitivity lists.
> Having a lot of processes in the first style with more or less random
> sensitivity lists defeats the optimization.
>
> Andy

I have seen people that like to separate the next state logic from
the
clocked logic in state machines. This potentially makes decoding
outputs
for a Mealy state machine more concise to code. Thus you end up with
a
structure similar to the "officially sanctioned" organizations desired
by
the OP.

John Providenza

On Aug 27, 2:32 pm, kb33 <kanchan.devarako...@gmail.com> wrote:
> Hi,
>
> I have been always been taught so and try to strictly follow the
> practice of splitting my design into combinational and sequential
> blocks (see example below). However, I have been asked to look at
> somebody's design at my workplace that does not do so, and I do not
> know whether I should ignore his style or bring it to the notice of
> the manager. I am looking for the most convincing explanation as to
> why the second style is not good.
>
> ----------My style----------------------
>
> Sequential
> ---------------
>
> always @(posedge clock)
> data_out <= data_out_comb;
>
> Combinational
> ---------------------
>
> always @(reset_n or data_a or data_b)
> if (~reset_n)
> data_out_comb = 0;
> else
> data_out_comb = data_a + data_b;
>
> -------Mixed sequential and combinational design----------------
>
> always @ (posedge clock or negedge reset_n)
> begin
> if(~reset_n)
> data_out <= 0;
> else
> data_out <= data_a + data_b;
> end
>
> P.S The second coding style doesn't even have the signals data_a and
> data_b in the sensitivity list.
>
> Thanks
> kb33

If you want to synthesize this code, you may find that your
version doesn't work (at least XST won't take it) BECAUSE
it has assignments to the same register in more than one
always block.

On Thu, 28 Aug 2008 07:43:54 -0700 (PDT), gabor <gabor@alacron.com>
wrote:

>On Aug 27, 2:32 pm, kb33 <kanchan.devarako...@gmail.com> wrote:
>> Hi,
>>
>> I have been always been taught so and try to strictly follow the
>> practice of splitting my design into combinational and sequential
>> blocks (see example below). However, I have been asked to look at
>> somebody's design at my workplace that does not do so, and I do not
>> know whether I should ignore his style or bring it to the notice of
>> the manager. I am looking for the most convincing explanation as to
>> why the second style is not good.
>>
>> ----------My style----------------------
>>
>> Sequential
>> ---------------
>>
>> always @(posedge clock)
>> data_out <= data_out_comb;
>>
>> Combinational
>> ---------------------
>>
>> always @(reset_n or data_a or data_b)
>> if (~reset_n)
>> data_out_comb = 0;
>> else
>> data_out_comb = data_a + data_b;
>>
>> -------Mixed sequential and combinational design----------------
>>
>> always @ (posedge clock or negedge reset_n)
>> begin
>> if(~reset_n)
>> data_out <= 0;
>> else
>> data_out <= data_a + data_b;
>> end
>>
>> P.S The second coding style doesn't even have the signals data_a and
>> data_b in the sensitivity list.
>>
>> Thanks
>> kb33
>
>If you want to synthesize this code, you may find that your
>version doesn't work (at least XST won't take it) BECAUSE
>it has assignments to the same register in more than one
>always block.

The OP was just showing two examples of the same design. The first two
always blocks is one implementation and the third always is the second
implementation. They are not meant to be used together.

jprovidenza@yahoo.com wrote:

> I have seen people that like to separate the next state logic from
> the
> clocked logic in state machines. This potentially makes decoding
> outputs
> for a Mealy state machine more concise to code. Thus you end up with
> a
> structure similar to the "officially sanctioned" organizations desired
> by
> the OP.

The OP said nothing about Mealy machines or
"officially sanctioned" organizations.

He asked if he should "bring it to the notice of the manager"
I have found that this is almost always a bad idea.

Looks to me like the reviewee has
more language savvy than the reviewer,
and bringing the boss into the loop won't help.

-- Mike Treseler

On Aug 28, 1:28 pm, Mike Treseler <mtrese...@gmail.com> wrote:
> jprovide...@yahoo.com wrote:
> > I have seen people that like to separate the next state logic from
> > the
> > clocked logic in state machines. This potentially makes decoding
> > outputs
> > for a Mealy state machine more concise to code. Thus you end up with
> > a
> > structure similar to the "officially sanctioned" organizations desired
> > by
> > the OP.
>
> The OP said nothing about Mealy machines or
> "officially sanctioned" organizations.
>
> He asked if he should "bring it to the notice of the manager"
> I have found that this is almost always a bad idea.
>
> Looks to me like the reviewee has
> more language savvy than the reviewer,
> and bringing the boss into the loop won't help.
>
> -- Mike Treseler

Thanks for all the help, everybody! I must say this discussion has
forced me to think whether all that I learnt the text book way is
actually the best thing. In fact, I did a small experiment - I
synthesized a piece of Verilog code (from the same guy whose code I
am looking at). First I synthesized it as is, and then I split the
code into sequential and combinational blocks and re-synthesized. The
synthesis results were better for the original. Splitting the design
into two always blocks used up more Logic cells (I was targetting an
Altera FPGA)

ANother strange observation that I made - when the sensitivity list
has only the clock and reset, it doesn't complain about or generate
latches for missing assignments (let's say a missing "else" part to an
"if" and so on). However, the moment the design was spilt into
sequential and combinational, every bit of every signal had to be
assigned a default value, and all "if" statements had to be matched
with "else", otherwise (obviously), latches were generated.


So my next questions are as follows:

1. Assuming that having everything in one always block with just the
reset and clock in the sensitivity list is better, why doesn't the
synthesis tool complain about any missing "else" statements or missing
bit assignments? And why does it not generate latches?

2. I am totally confused as to which style should be adopted. Is it
that one is better for ASICs and the other better for FPGAs?

3. My company RTL coding guidelines still state that I should have
different combinational and sequential blocks (which I already
follow), but at the same time my current project requires that I use
as less resources on my FPGA as possible. So maybe if I were to use
just one always block, I might save Logic cells on the FPGA.


Please advise!

Thanks
kb33