The definition of comnatorial prcess?

[Weng Tianxiang]

The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::=
{ sequential_statement }

sequential_statement ::=
wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::=
{ combinatorial_sequential_statement }

combinatorial_sequential_statement ::=
assertion_statement -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

 

[glen herrmannsfeldt]

Weng Tianxiang <wtxwtx@gmail.com> wrote:

The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

I know verilog much better than VHDL, but ...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

It might not be related to a VHDL specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

Well, yes, but you probably also shouldn't have any type of latch,
such as you might build out of NAND gates. But some kinds of
feedback loops might be allowed. (An always interesting question is
the end-around carry in ones-complement adders.)

I will guess, then, that in some cases it isn't possible to prove
that a given logic block is, or isn't, combinatorial.

-- glen

 

[Alan Fitch]

On 28/06/12 21:11, glen herrmannsfeldt wrote:

Weng Tianxiang <wtxwtx@gmail.com> wrote:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

I know verilog much better than VHDL, but ...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

It might not be related to a VHDL specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

Well, yes, but you probably also shouldn't have any type of latch,
such as you might build out of NAND gates. But some kinds of
feedback loops might be allowed. (An always interesting question is
the end-around carry in ones-complement adders.)

I will guess, then, that in some cases it isn't possible to prove
that a given logic block is, or isn't, combinatorial.

-- glen

The definition I always use for combinational logic is

"The steady-state value of a combinational logic function is purely
defined by boolean logic functions of the steady state value of the inputs."

This implies no memory (state).

VHDL, as a modelling language, allows you to describe such behaviour,
but it isn't defined in the language.

A different approach has been taken in SystemVerilog, where keywords
always_comb, always_latch, and always_ff have been introduced to allow
the designer to describe design intent in the simulation model.

VHDL just does whatever you tell it to, it's up to you to tell it to do
"the right thing" with regard to the hardware you want to model.

regards
Alan


--
Alan Fitch

 

[glen herrmannsfeldt]

Alan Fitch <apf@invalid.invalid> wrote:

(snip, I wrote)

I know verilog much better than VHDL, but ...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

(snip)

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

Well, yes, but you probably also shouldn't have any type of latch,
such as you might build out of NAND gates. But some kinds of
feedback loops might be allowed. (An always interesting question is
the end-around carry in ones-complement adders.)

I will guess, then, that in some cases it isn't possible to prove
that a given logic block is, or isn't, combinatorial.

The definition I always use for combinational logic is

"The steady-state value of a combinational logic function is
purely defined by boolean logic functions of the steady state
value of the inputs."

This implies no memory (state).

Sounds good to me. As far as I know, though, there isn't
any simple test for it.

Also, no guarantee on how fast the output gets to where
it is suppose to be.

VHDL, as a modelling language, allows you to describe
such behaviour, but it isn't defined in the language.

A different approach has been taken in SystemVerilog,
where keywords always_comb, always_latch, and always_ff
have been introduced to allow the designer to describe
design intent in the simulation model.

So far I haven't been interested in SystemVerilog.

VHDL just does whatever you tell it to, it's up to you
to tell it to do "the right thing" with regard to the
hardware you want to model.

-- glen

 

Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:

The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> { sequential_statement }

sequential_statement ::> wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> assertion_statement -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.


Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
combinatorial_process_statement_part ::{ combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
Eilert

 

[Weng Tianxiang]

On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:

Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd9acd78a33d1dae/3de3fe8ea3eec9ad?hl=en&q=combinatorial&lnk=ol&

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > { sequential_statement }

sequential_statement ::> > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > assertion_statement -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.


Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
combinatorial_process_statement_part ::> { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

 

[rickman]

On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd....

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > { sequential_statement }

sequential_statement ::> > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical"..
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct. If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs. If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined. Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches. Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

 

[Weng Tianxiang]

On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:

On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > { sequential_statement }

sequential_statement ::> > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct. If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs. If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined. Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches. Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

Weng

 

[rickman]

On Jun 29, 6:31 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > { sequential_statement }

sequential_statement ::> > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

Weng

A latch is a sequential device. It has memory and that is how
"sequential" is defined.

As I said, I don't see the value of your proposition. What are you
trying to accomplish?

Rick

 

[Weng Tianxiang]

On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:

On Jun 29, 6:31 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > > { sequential_statement }

sequential_statement ::> > > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

Weng

A latch is a sequential device. It has memory and that is how
"sequential" is defined.

As I said, I don't see the value of your proposition. What are you
trying to accomplish?

Rick

Hi Rick,
I hope to publish my paper as soon as possible, but I cannot disclose its details now.

I would like to ask you the question you mentioned earlier and hope you give me an exception:
If there is no clock statement and not wait statement allowed in a process, how do you generate a ff?

latch is allowed to be generated in my case.

After my paper publication, you may have another real opportunity to comment on IF it is useful.

Weng

 

[KJ]

On Friday, June 29, 2012 6:31:24 PM UTC-4, Weng Tianxiang wrote:

On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > { sequential_statement }

sequential_statement ::> > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct. If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs. If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined. Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches. Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

You've forgotten a very basic principle...EVERY logic circuit (including flip flops) can be described with nothing more than nand (or nor) gates. A flip flop can be described with nand gates. The (likely) fact that no synthesis tool on the market will take a nand gate description and synthesize a flip flop simply reflects the limitations of the tools at this point in time. There are many such limitations, but those are all examples where synthesis tools are not able to adhere to the language defintion while also synthesizing the optimal circuit. Limitations can disappear in the future.

In any case, since a flip flop can be described with only nand or nor gates, then it is not possible to limit the current scope of the language to prevent a flip flop from being described in HDL. Therefore, any such definition that you come up with to try to prevent a flip flop from being described will ultimately have a hole in the definition.

Kevin Jennings

 

[Weng Tianxiang]

On Friday, June 29, 2012 6:45:17 PM UTC-7, KJ wrote:

On Friday, June 29, 2012 6:31:24 PM UTC-4, Weng Tianxiang wrote:
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > > { sequential_statement }

sequential_statement ::> > > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct. If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs. If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined. Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches. Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.


You've forgotten a very basic principle...EVERY logic circuit (including flip flops) can be described with nothing more than nand (or nor) gates. A flip flop can be described with nand gates. The (likely) fact that no synthesis tool on the market will take a nand gate description and synthesize a flip flop simply reflects the limitations of the tools at this point in time. There are many such limitations, but those are all examples where synthesis tools are not able to adhere to the language defintion while also synthesizing the optimal circuit. Limitations can disappear in the future.

In any case, since a flip flop can be described with only nand or nor gates, then it is not possible to limit the current scope of the language to prevent a flip flop from being described in HDL. Therefore, any such definition that you come up with to try to prevent a flip flop from being described will ultimately have a hole in the definition.

Kevin Jennings

KJ,
You are right, but I think you are nitpicking.
"A flip flop can be described with nand gates. The (likely) fact that no synthesis tool on the market will take a nand gate description and synthesize a flip flop simply reflects the limitations of the tools at this point in time."

James comment on VHDL-2008 in comp.lang.vhdl group is very useful and I think his comment has already given the right answer I am looking for.

Thank you.

Weng

 

[rickman]

On Jun 29, 8:09 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:
On Jun 29, 6:31 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > > > { sequential_statement }

sequential_statement ::> > > > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not..

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper..

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are..
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

Weng

A latch is a sequential device.  It has memory and that is how
"sequential" is defined.

As I said, I don't see the value of your proposition.  What are you
trying to accomplish?

Rick

Hi Rick,
I hope to publish my paper as soon as possible, but I cannot disclose its details now.

I would like to ask you the question you mentioned earlier and hope you give me an exception:
If there is no clock statement and not wait statement allowed in a process, how do you generate a ff?

latch is allowed to be generated in my case.

After my paper publication, you may have another real opportunity to comment on IF it is useful.

Weng

I'm sorry, but I don't understand your question. A latch is a type of
flipflop. I don't know what you mean when you say it is "allowed" to
be generated. I also don't know what you mean by "clock statement".

All of the code I have seen describes the behavior of a ff, either
edge sensitive or level sensitive. There are no "clock statements"
that I know of. You wait for an edge and make an assignment and do
nothing the rest of the time, or you wait for a level and make an
assignment and do nothing the rest of the time. What makes it
"sequential" is the "do nothing" the rest of the time when the
sequential logic "remembers" the previously calculated state.
Combinatorial logic is always a direct reflection of all inputs, all
the time. There is no "remember".

If you are suggesting some sort of formalism that treats latches as
combinatorial logic then by my reckoning you are in left field.

Rick

 

[Weng Tianxiang]

On Saturday, June 30, 2012 7:39:53 PM UTC-7, rickman wrote:

On Jun 29, 8:09 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:
On Jun 29, 6:31 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > > > > { sequential_statement }

sequential_statement ::> > > > > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not.

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper.

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are.
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not..

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

Weng

A latch is a sequential device.  It has memory and that is how
"sequential" is defined.

As I said, I don't see the value of your proposition.  What are you
trying to accomplish?

Rick

Hi Rick,
I hope to publish my paper as soon as possible, but I cannot disclose its details now.

I would like to ask you the question you mentioned earlier and hope you give me an exception:
If there is no clock statement and not wait statement allowed in a process, how do you generate a ff?

latch is allowed to be generated in my case.

After my paper publication, you may have another real opportunity to comment on IF it is useful.

Weng

I'm sorry, but I don't understand your question. A latch is a type of
flipflop. I don't know what you mean when you say it is "allowed" to
be generated. I also don't know what you mean by "clock statement".

All of the code I have seen describes the behavior of a ff, either
edge sensitive or level sensitive. There are no "clock statements"
that I know of. You wait for an edge and make an assignment and do
nothing the rest of the time, or you wait for a level and make an
assignment and do nothing the rest of the time. What makes it
"sequential" is the "do nothing" the rest of the time when the
sequential logic "remembers" the previously calculated state.
Combinatorial logic is always a direct reflection of all inputs, all
the time. There is no "remember".

If you are suggesting some sort of formalism that treats latches as
combinatorial logic then by my reckoning you are in left field.

Rick

Hi Rick,
Thank you for your concern.

I actually find that James has given the right answer: It requires the format he suggested: process(all) that says what I want to say.

I have abandoned the idea to use the clock statement or other inaccurate descriptions.

Weng

 

[rickman]

On Jun 29, 10:29 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Friday, June 29, 2012 6:45:17 PM UTC-7, KJ wrote:
On Friday, June 29, 2012 6:31:24 PM UTC-4, Weng Tianxiang wrote:
On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
On Jun 29, 2:25 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Friday, June 29, 2012 12:13:33 AM UTC-7, (unknown) wrote:
Am Donnerstag, 28. Juni 2012 20:14:33 UTC+2 schrieb Weng Tianxiang:
The following topic may be one of the longest debate in vhdl group:
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/bd...

The debute focus later turns to which is best way to use one
sequential process or two combinarotial process and sequential
process.

The most important and strange thing is that I cannot even find the
word "combinarotial" in VHDL-2002 specification.

I want to grammarly define a combinatorial process which cannot have a
clock statement in one of my thinking.

process_statement_part ::> > > > > > > { sequential_statement }

sequential_statement ::> > > > > > > wait_statement
| assertion_statement
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

combinatorial_process_statement_part ::> > > > > > > { combinatorial_sequential_statement }

combinatorial_sequential_statement ::> > > > > > > assertion_statement   -- wait_statement is deleted here !!!
| report_statement
| signal_assignment_statement
| variable_assignment_statement
| procedure_call_statement
| if_statement
| case_statement
| loop_statement
| next_statement
| exit_statement
| return_statement
| null_statement

Weng

Hi Weng,
I think the discussion you mentioned above is caused by a big misunderstanding of what the word "sequential" is refering to.

"sequential" with respect to the VHDL language means, that the statements inside a block are evaluated one after another. This has no connection whatsoever to the resulting circuit.

The opposite of "sequential" here is "concurrent", not "combinatorical".
"Combinatorical" has no meaning for the language, and therefore doesn't need to be specified anywhere in the standard. But when you look into part 4(?) of the Standard (The synthesis part) there you find the term "synchronous description". Such a "synchronous description" results in some circuit with registers. everything else is just gates, and with feedbacks or incomplete conditional branches sometimes to latches, which are identified by the tools, so the designer can decide wether they are intended or not..

Therfore there is no need to make up fancy words and lenghty descriptions for things that are nicely covered in one compact and generic description.

The contradiction of such a request can already be found in the proposed syntax description:
 combinatorial_process_statement_part ::> > > > > > { combinatorial_SEQUENTIAL_statement }

Does this ease up something?
and how to avoid the usage of

  if rising_edge(clk) then

in such a dedicated combinatorical process.

and what if in a dedicated non_combinatorical process only this is used:

  wait for 1 ns;

but no event related stuff?

So there's no gain, just increased confusion and waste of paper..

A process does what the designer wants it to do.
Either synchronous or combinatorical. For that purpose one grammar specification is sufficient.

Apply Occams razor.

Have a nice synthesis
  Eilert

Eilert,
Actually I want to create something new in HDL, a new type of process, that leads to the problem: the concept of a concurrent combinatorial process:
1. The new process is a concurrent process as other processes are..
2. In the new process, no traditional clock statement, explicit or implicit, is allowed.
3. In the new process all sequential statements, excluding wait statement, are allowed.

Someone may ask that what "a traditional clock statement" means? All those who write logic programming in VHDL know it, but there is never a definition of it in VHDL language. I would like to have someone to fill the gap.

Is it clear enough now?

1. " if rising_edge(clk) then": the situation will be excluded by note 2, not by grammar.

2. "wait for 1 ns;": wait statement is prohibited in the grammar.

I don't see any conflicts now.

I appreciate the SystemVerilog grammar by declaring three types of processes explicitly:
a. always_comb;
b. always_latch;
c. always_ff.

No any ambiguity is generated in any situations.

Thank you for your discussion.

Weng

I don't see the need for such a new construct.  If you want a
combinatorial circuit then write the process with all the inputs in
the sensitivity list, use no feedback of any kind and make sure the
outputs are defined for all combinations of inputs.  If you want a
sequential circuit add the reset (if used) and the clock to the
sensitivity list, use all the feedback you want or don't want and
don't worry about which combinations of inputs you specify or not.

Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined.  Many a new HDL designer has
inadvertently left out some input combinations or used feedback and
ended up with latches.  Heck, even experienced designers do this once
in a while.

The resulting logic comes from how you describe the process, not what
label you attach.

Rick

Rick,
Your following comment hit the point:
" Your "new process" type defined above is not guaranteed to generate
combinatorial logic because you don't exclude feedback or require all
input combinations to be defined."

If there is no clock statement and not wait statement allowed in a process, how do you generate a ff? latch is allowed to be generated in my case.

You've forgotten a very basic principle...EVERY logic circuit (including flip flops) can be described with nothing more than nand (or nor) gates.  A flip flop can be described with nand gates.  The (likely) fact that no synthesis tool on the market will take a nand gate description and synthesize a flip flop simply reflects the limitations of the tools at this point in time.  There are many such limitations, but those are all examples where synthesis tools are not able to adhere to the language defintion while also synthesizing the optimal circuit.  Limitations can disappear in the future.

In any case, since a flip flop can be described with only nand or nor gates, then it is not possible to limit the current scope of the language to prevent a flip flop from being described in HDL.  Therefore, any such definition that you come up with to try to prevent a flip flop from being described will ultimately have a hole in the definition.

Kevin Jennings

KJ,
You are right, but I think you are nitpicking.
"A flip flop can be described with nand gates.  The (likely) fact that no synthesis tool on the market will take a nand gate description and synthesize a flip flop simply reflects the limitations of the tools at this point in time."

James comment on VHDL-2008 in comp.lang.vhdl group is very useful and I think his comment has already given the right answer I am looking for.

Thank you.

Weng

I think you have a different perspective on what synthesis tools do
compared to my experience. The tools don't know anything about what
you are trying to do or whether you are describing NAND gates or FFs.
All they know is the description you give and they figure out how to
implement it. If you use a bunch of ands and ors to describe how a FF
works I would not doubt for a moment that the tools would utilize a
FF. But the only way to tell is to try it.

The real issue is that your idea of trying to "force" the tool to use
combinatorial logic or FFs or latches is not going to work. What
happens when you try to use combinatorial logic and you fail to fully
define the behavior? Will it not generate a latch? What will it
generate?

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:

(snip)

I think you have a different perspective on what synthesis tools do
compared to my experience. The tools don't know anything about what
you are trying to do or whether you are describing NAND gates or FFs.

I agree.

All they know is the description you give and they figure out how to
implement it. If you use a bunch of ands and ors to describe how a FF
works I would not doubt for a moment that the tools would utilize a
FF. But the only way to tell is to try it.

Normally you can't make a traditional edge tricgered FF out of
orginary gates. You can make a transparent latch, and some other
devices with state.

The real issue is that your idea of trying to "force" the tool to use
combinatorial logic or FFs or latches is not going to work. What
happens when you try to use combinatorial logic and you fail to fully
define the behavior? Will it not generate a latch? What will it
generate?

-- glen

 

[Rob Doyle]

On 6/30/2012 8:34 PM, glen herrmannsfeldt wrote:

Normally you can't make a traditional edge tricgered FF out of
orginary gates. You can make a transparent latch, and some other
devices with state.

-- glen

Why do you say that? With two transparent latches (a master and
a slave) you can make an edge triggered flip-flop, right?

Even wikipedia has a some examples.

http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29

I hacked a D flip-flop in a 16L8 once... as a fix.
I don't recall being too grossed out by it.

-- Rob.

 

[Alan Fitch]

On 01/07/12 03:48, Weng Tianxiang wrote:

On Saturday, June 30, 2012 7:39:53 PM UTC-7, rickman wrote:

<snip>

I'm sorry, but I don't understand your question. A latch is a type of
flipflop. I don't know what you mean when you say it is "allowed" to
be generated. I also don't know what you mean by "clock statement".

All of the code I have seen describes the behavior of a ff, either
edge sensitive or level sensitive. There are no "clock statements"
that I know of. You wait for an edge and make an assignment and do
nothing the rest of the time, or you wait for a level and make an
assignment and do nothing the rest of the time. What makes it
"sequential" is the "do nothing" the rest of the time when the
sequential logic "remembers" the previously calculated state.
Combinatorial logic is always a direct reflection of all inputs, all
the time. There is no "remember".

If you are suggesting some sort of formalism that treats latches as
combinatorial logic then by my reckoning you are in left field.

Rick

Hi Rick, when I'm teaching synthesis as part of teaching VHDL or

Verilog, I tend to use "transparent latch" for level sensitive latches,
and "edge-triggered D-type flip-flop" for D-type flip-flops. I then
abbreviate these to "latch" and "flip-flop". So by my usage, I don't
regard a (transparent) latch as a flip-flop. However when I worked at
Philips Semiconductors years ago, people used "latch" to describe
D-types and transparent latches!

So I don't know if "latch" = "transparent latch" or "edge triggered
flip-flop": hence using "transparent" and "edge-triggered" when teaching
to avoid confusion.

Hi Rick,
Thank you for your concern.

I actually find that James has given the right answer: It requires the format he suggested: process(all) that says what I want to say.

I have abandoned the idea to use the clock statement or other inaccurate descriptions.

Weng

Hi Weng,
if you follow the definition of combinational logic I gave before (the
steady state value of the output is *only* a unique function of the
steady state values of the inputs) then you must follow three rules

1. complete sensitivity list (like VHDL 2008 (all) as Jim said)
2. no feedback
3. no incomplete assignment of outputs

Some examples

process(all)
begin
o <= not i;
end process;

process(all)
begin
o <= not o; -- feedback
end process;

process(all)
begin
if enable = '1' then
o <= i;
end if;
-- o not assigned when enable = '0', implies transparent latch
end process;

In SystemVerilog, as you mentioned yourself, they've introduced
always_comb, always_latch, always_ff to allow design intent to be
expressed for both simulation and synthesis (i.e. a simulator could warn
you about incomplete assignment if you used always_comb).

So I guess you could propose them for VHDL if you like!

regards
Alan

--
Alan Fitch

 

[glen herrmannsfeldt]

Rob Doyle <radioengr@gmail.com> wrote:

(snip, I wrote)

Normally you can't make a traditional edge tricgered FF out of
orginary gates. You can make a transparent latch, and some other
devices with state.

Why do you say that? With two transparent latches (a master and
a slave) you can make an edge triggered flip-flop, right?

As it was explained to me many years ago, you want a different
threshold for the two. Maybe that isn't always necessary, but
only an optimization, or maybe technology dependent.

Even wikipedia has a some examples.

http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29

I hacked a D flip-flop in a 16L8 once... as a fix.
I don't recall being too grossed out by it.

I will have to look at those.

-- glen

 

[Weng Tianxiang]

On Sunday, July 1, 2012 1:08:47 AM UTC-7, Alan Fitch wrote:

On 01/07/12 03:48, Weng Tianxiang wrote:
On Saturday, June 30, 2012 7:39:53 PM UTC-7, rickman wrote:


snip


I'm sorry, but I don't understand your question. A latch is a type of
flipflop. I don't know what you mean when you say it is "allowed" to
be generated. I also don't know what you mean by "clock statement".

All of the code I have seen describes the behavior of a ff, either
edge sensitive or level sensitive. There are no "clock statements"
that I know of. You wait for an edge and make an assignment and do
nothing the rest of the time, or you wait for a level and make an
assignment and do nothing the rest of the time. What makes it
"sequential" is the "do nothing" the rest of the time when the
sequential logic "remembers" the previously calculated state.
Combinatorial logic is always a direct reflection of all inputs, all
the time. There is no "remember".

If you are suggesting some sort of formalism that treats latches as
combinatorial logic then by my reckoning you are in left field.

Rick

Hi Rick, when I'm teaching synthesis as part of teaching VHDL or
Verilog, I tend to use "transparent latch" for level sensitive latches,
and "edge-triggered D-type flip-flop" for D-type flip-flops. I then
abbreviate these to "latch" and "flip-flop". So by my usage, I don't
regard a (transparent) latch as a flip-flop. However when I worked at
Philips Semiconductors years ago, people used "latch" to describe
D-types and transparent latches!

So I don't know if "latch" = "transparent latch" or "edge triggered
flip-flop": hence using "transparent" and "edge-triggered" when teaching
to avoid confusion.


Hi Rick,
Thank you for your concern.

I actually find that James has given the right answer: It requires the format he suggested: process(all) that says what I want to say.

I have abandoned the idea to use the clock statement or other inaccurate descriptions.

Weng

Hi Weng,
if you follow the definition of combinational logic I gave before (the
steady state value of the output is *only* a unique function of the
steady state values of the inputs) then you must follow three rules

1. complete sensitivity list (like VHDL 2008 (all) as Jim said)
2. no feedback
3. no incomplete assignment of outputs

Some examples

process(all)
begin
o <= not i;
end process;

process(all)
begin
o <= not o; -- feedback
end process;

process(all)
begin
if enable = '1' then
o <= i;
end if;
-- o not assigned when enable = '0', implies transparent latch
end process;

In SystemVerilog, as you mentioned yourself, they've introduced
always_comb, always_latch, always_ff to allow design intent to be
expressed for both simulation and synthesis (i.e. a simulator could warn
you about incomplete assignment if you used always_comb).

So I guess you could propose them for VHDL if you like!

regards
Alan

--
Alan Fitch

Alan, Rick, glen, Rob,
Thanks for your joining my discussions.

I think I have already got the right answer from James, by using process(all).

Alan, your suggestion of the following text may be right for a fully combinatorial logic.

1. complete sensitivity list (like VHDL 2008 (all) as Jim said)
2. no feedback
3. no incomplete assignment of outputs

But I don't have to limit it grammatically in my case. If someone uses feedback in my proposed something, it would be an error which the designer is responsible to correct it that would lead him to delete the feedback.

Thank all of you.

Weng