Messages from 153925

Article: 153925
Subject: Re: Replacement for XC4005E
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 30 Jun 2012 00:27:38 GMT
Links: << >> << T >> << A >>

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>rickman <gnuarm@gmail.com> wrote:
>
>(snip)
>> One final comment.  I resisted the switch from schematic to HDL back
>> in the day.  Now I would not touch schematic.  The single biggest
>> reason to use HDL is the vendor independence.  It makes it so easy to
>> switch from one line of devices to another.  Learning an HDL is not
>> really so tough, especially if you don't do software.  When I learned
>> I kept thinking it was like other software and it isn't.  It describes
>> hardware so the code works very differently.  If you need help with
>> that, I think I could be useful to you in getting up the learning
>> curve.  I've helped others before.
>
>I agree. For one, I prefer structural verilog and continuous 
>assignment, which looks less like software. 
>
>Also, it helps to have learned about digital logic before, or 
>not so long after, you start learning software programming
>language(s). 
>
>Think in terms of wires and gates, then write them down.

The problem with that method is that you limit yourself to making a
netlist manually. HDLs offer a lot of power which allows you to
describe a large amount of hardware with just a few lines of code.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Article: 153926
Subject: Re: The definition of comnatorial prcess?
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 29 Jun 2012 18:45:17 -0700 (PDT)
Links: << >> << T >> << A >>

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=A0pm, 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 grou=
p:
> > > > >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 t=
he
> > > > > word "combinarotial" in VHDL-2002 specification.
> > >
> > > > > I want to grammarly define a combinatorial process which cannot h=
ave a
> > > > > clock statement in one of my thinking.
> > >
> > > > > process_statement_part ::=3D
> > > > > { sequential_statement }
> > >
> > > > > sequential_statement ::=3D
> > > > > 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 ::=3D
> > > > > { combinatorial_sequential_statement }
> > >
> > > > > combinatorial_sequential_statement ::=3D
> > > > > assertion_statement =A0 -- 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 misun=
derstanding of what the word "sequential" is refering to.
> > >
> > > > "sequential" with respect to the VHDL language means, that the stat=
ements inside a block are evaluated one after another. This has no connecti=
on whatsoever to the resulting circuit.
> > >
> > > > The opposite of "sequential" here is "concurrent", not "combinatori=
cal".
> > > > "Combinatorical" has no meaning for the language, and therefore doe=
sn'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 "syn=
chronous description". Such a "synchronous description" results in some cir=
cuit with registers. everything else is just gates, and with feedbacks or i=
ncomplete conditional branches sometimes to latches, which are identified b=
y 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 descri=
ptions for things that are nicely covered in one compact and generic descri=
ption.
> > >
> > > > The contradiction of such a request can already be found in the pro=
posed syntax description:
> > > > =A0combinatorial_process_statement_part ::=3D
> > > > { combinatorial_SEQUENTIAL_statement }
> > >
> > > > Does this ease up something?
> > > > and how to avoid the usage of
> > >
> > > > =A0 if rising_edge(clk) then
> > >
> > > > in such a dedicated combinatorical process.
> > >
> > > > and what if in a dedicated non_combinatorical process only this is =
used:
> > >
> > > > =A0 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
> > > > =A0 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 proc=
ess:
> > > 1. The new process is a concurrent process as other processes are.
> > > 2. In the new process, no traditional clock statement, explicit or im=
plicit, is allowed.
> > > 3. In the new process all sequential statements, excluding wait state=
ment, 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 def=
inition of it in VHDL language. I would like to have someone to fill the ga=
p.
> > >
> > > Is it clear enough now?
> > >
> > > 1. " if rising_edge(clk) then": the situation will be excluded by not=
e 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 pr=
ocesses explicitly:
> > > a. always_comb;
> > > b. always_latch;
> > > c. always_ff.
> > >
> > > No any ambiguity is generated in any situations.
> > >
> > > Thank you for your discussion.
> > >
> > > Weng
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > The resulting logic comes from how you describe the process, not what
> > label you attach.
> >=20
> > Rick
>=20
> Rick,
> Your following comment hit the point:
> " Your "new process" type defined above is not guaranteed to generate=20
> combinatorial logic because you don't exclude feedback or require all=20
> input combinations to be defined."
>=20
> If there is no clock statement and not wait statement allowed in a proces=
s, how do you generate a ff? latch is allowed to be generated in my case.
>=20

You've forgotten a very basic principle...EVERY logic circuit (including fl=
ip flops) can be described with nothing more than nand (or nor) gates.  A f=
lip flop can be described with nand gates.  The (likely) fact that no synth=
esis 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 tim=
e.  There are many such limitations, but those are all examples where synth=
esis tools are not able to adhere to the language defintion while also synt=
hesizing 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 pre=
vent a flip flop from being described in HDL.  Therefore, any such definiti=
on 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

Article: 153927
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Fri, 29 Jun 2012 19:29:32 -0700 (PDT)
Links: << >> << T >> << A >>

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=A0pm, 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 Tianxian=
g:
> > > > > > The following topic may be one of the longest debate in vhdl gr=
oup:
> > > > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/thre=
ad/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 ::=3D
> > > > > > { sequential_statement }
> > > >
> > > > > > sequential_statement ::=3D
> > > > > > 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 ::=3D
> > > > > > { combinatorial_sequential_statement }
> > > >
> > > > > > combinatorial_sequential_statement ::=3D
> > > > > > assertion_statement =A0 -- 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 mis=
understanding of what the word "sequential" is refering to.
> > > >
> > > > > "sequential" with respect to the VHDL language means, that the st=
atements inside a block are evaluated one after another. This has no connec=
tion whatsoever to the resulting circuit.
> > > >
> > > > > The opposite of "sequential" here is "concurrent", not "combinato=
rical".
> > > > > "Combinatorical" has no meaning for the language, and therefore d=
oesn't need to be specified anywhere in the standard. But when you look int=
o part 4(?) of the Standard (The synthesis part) there you find the term "s=
ynchronous description". Such a "synchronous description" results in some c=
ircuit 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 desc=
riptions for things that are nicely covered in one compact and generic desc=
ription.
> > > >
> > > > > The contradiction of such a request can already be found in the p=
roposed syntax description:
> > > > > =A0combinatorial_process_statement_part ::=3D
> > > > > { combinatorial_SEQUENTIAL_statement }
> > > >
> > > > > Does this ease up something?
> > > > > and how to avoid the usage of
> > > >
> > > > > =A0 if rising_edge(clk) then
> > > >
> > > > > in such a dedicated combinatorical process.
> > > >
> > > > > and what if in a dedicated non_combinatorical process only this i=
s used:
> > > >
> > > > > =A0 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 gramma=
r specification is sufficient.
> > > >
> > > > > Apply Occams razor.
> > > >
> > > > > Have a nice synthesis
> > > > > =A0 Eilert
> > > >
> > > > Eilert,
> > > > Actually I want to create something new in HDL, a new type of proce=
ss, that leads to the problem: the concept of a concurrent combinatorial pr=
ocess:
> > > > 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 sta=
tement, are allowed.
> > > >
> > > > Someone may ask that what "a traditional clock statement" means? Al=
l those who write logic programming in VHDL know it, but there is never a d=
efinition 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 n=
ote 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
> > >=20
> > > 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.
> > >=20
> > > 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.
> > >=20
> > > The resulting logic comes from how you describe the process, not what
> > > label you attach.
> > >=20
> > > Rick
> >=20
> > Rick,
> > Your following comment hit the point:
> > " Your "new process" type defined above is not guaranteed to generate=
=20
> > combinatorial logic because you don't exclude feedback or require all=
=20
> > input combinations to be defined."
> >=20
> > If there is no clock statement and not wait statement allowed in a proc=
ess, how do you generate a ff? latch is allowed to be generated in my case.
> >=20
>=20
> 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 syn=
thesis 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 t=
ime.  There are many such limitations, but those are all examples where syn=
thesis tools are not able to adhere to the language defintion while also sy=
nthesizing the optimal circuit.  Limitations can disappear in the future.
>=20
> In any case, since a flip flop can be described with only nand or nor gat=
es, then it is not possible to limit the current scope of the language to p=
revent a flip flop from being described in HDL.  Therefore, any such defini=
tion that you come up with to try to prevent a flip flop from being describ=
ed will ultimately have a hole in the definition.
>=20
> 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 s=
ynthesis tool on the market will take a nand gate description and synthesiz=
e 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 thi=
nk his comment has already given the right answer I am looking for.

Thank you.

Weng

Article: 153928
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Sat, 30 Jun 2012 19:39:53 -0700 (PDT)
Links: << >> << T >> << A >>

On Jun 29, 8:09=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:
> > On Jun 29, 6:31=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > > On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
> > > > On Jun 29, 2:25=A0pm, 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 Tianxi=
ang:
> > > > > > > The following topic may be one of the longest debate in vhdl =
group:
> > > > > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/th=
read/bd...
>
> > > > > > > The debute focus later turns to which is best way to use one
> > > > > > > sequential process or two combinarotial process and sequentia=
l
> > > > > > > process.
>
> > > > > > > The most important and strange thing is that I cannot even fi=
nd the
> > > > > > > word "combinarotial" in VHDL-2002 specification.
>
> > > > > > > I want to grammarly define a combinatorial process which cann=
ot have a
> > > > > > > clock statement in one of my thinking.
>
> > > > > > > process_statement_part ::=3D
> > > > > > > { sequential_statement }
>
> > > > > > > sequential_statement ::=3D
> > > > > > > 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 ::=3D
> > > > > > > { combinatorial_sequential_statement }
>
> > > > > > > combinatorial_sequential_statement ::=3D
> > > > > > > assertion_statement =A0 -- 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 m=
isunderstanding 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 conn=
ection whatsoever to the resulting circuit.
>
> > > > > > The opposite of "sequential" here is "concurrent", not "combina=
torical".
> > > > > > "Combinatorical" has no meaning for the language, and therefore=
 doesn't need to be specified anywhere in the standard. But when you look i=
nto 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 identifi=
ed 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 de=
scriptions for things that are nicely covered in one compact and generic de=
scription.
>
> > > > > > The contradiction of such a request can already be found in the=
 proposed syntax description:
> > > > > > =A0combinatorial_process_statement_part ::=3D
> > > > > > { combinatorial_SEQUENTIAL_statement }
>
> > > > > > Does this ease up something?
> > > > > > and how to avoid the usage of
>
> > > > > > =A0 if rising_edge(clk) then
>
> > > > > > in such a dedicated combinatorical process.
>
> > > > > > and what if in a dedicated non_combinatorical process only this=
 is used:
>
> > > > > > =A0 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 gram=
mar specification is sufficient.
>
> > > > > > Apply Occams razor.
>
> > > > > > Have a nice synthesis
> > > > > > =A0 Eilert
>
> > > > > Eilert,
> > > > > Actually I want to create something new in HDL, a new type of pro=
cess, 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 o=
r implicit, is allowed.
> > > > > 3. In the new process all sequential statements, excluding wait s=
tatement, 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 th=
e 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 o=
f 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. =A0If 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. =A0If 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 a=
ll
> > > > input combinations to be defined. =A0Many a new HDL designer has
> > > > inadvertently left out some input combinations or used feedback and
> > > > ended up with latches. =A0Heck, even experienced designers do this =
once
> > > > in a while.
>
> > > > The resulting logic comes from how you describe the process, not wh=
at
> > > > 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 pr=
ocess, how do you generate a ff? latch is allowed to be generated in my cas=
e.
>
> > > Weng
>
> > A latch is a sequential device. =A0It has memory and that is how
> > "sequential" is defined.
>
> > As I said, I don't see the value of your proposition. =A0What 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 g=
ive me an exception:
> If there is no clock statement and not wait statement allowed in a proces=
s, 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 comm=
ent 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

Article: 153929
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sat, 30 Jun 2012 19:48:30 -0700 (PDT)
Links: << >> << T >> << A >>

On Saturday, June 30, 2012 7:39:53 PM UTC-7, rickman wrote:
> On Jun 29, 8:09=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > On Friday, June 29, 2012 4:17:21 PM UTC-7, rickman wrote:
> > > On Jun 29, 6:31=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> > > > On Friday, June 29, 2012 12:35:18 PM UTC-7, rickman wrote:
> > > > > On Jun 29, 2:25=A0pm, 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 Tian=
xiang:
> > > > > > > > The following topic may be one of the longest debate in vhd=
l 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 on=
e
> > > > > > > > sequential process or two combinarotial process and sequent=
ial
> > > > > > > > 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 ca=
nnot have a
> > > > > > > > clock statement in one of my thinking.
> >
> > > > > > > > process_statement_part ::=3D
> > > > > > > > { sequential_statement }
> >
> > > > > > > > sequential_statement ::=3D
> > > > > > > > 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 ::=3D
> > > > > > > > { combinatorial_sequential_statement }
> >
> > > > > > > > combinatorial_sequential_statement ::=3D
> > > > > > > > assertion_statement =A0 -- 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 th=
e statements inside a block are evaluated one after another. This has no co=
nnection whatsoever to the resulting circuit.
> >
> > > > > > > The opposite of "sequential" here is "concurrent", not "combi=
natorical".
> > > > > > > "Combinatorical" has no meaning for the language, and therefo=
re 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 ter=
m "synchronous description". Such a "synchronous description" results in so=
me circuit with registers. everything else is just gates, and with feedback=
s or incomplete conditional branches sometimes to latches, which are identi=
fied by the tools, so the designer can decide wether they are intended or n=
ot.
> >
> > > > > > > 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 t=
he proposed syntax description:
> > > > > > > =A0combinatorial_process_statement_part ::=3D
> > > > > > > { combinatorial_SEQUENTIAL_statement }
> >
> > > > > > > Does this ease up something?
> > > > > > > and how to avoid the usage of
> >
> > > > > > > =A0 if rising_edge(clk) then
> >
> > > > > > > in such a dedicated combinatorical process.
> >
> > > > > > > and what if in a dedicated non_combinatorical process only th=
is is used:
> >
> > > > > > > =A0 wait for 1 ns;
> >
> > > > > > > but no event related stuff?
> >
> > > > > > > So there's no gain, just increased confusion and waste of pap=
er.
> >
> > > > > > > A process does what the designer wants it to do.
> > > > > > > Either synchronous or combinatorical. For that purpose one gr=
ammar specification is sufficient.
> >
> > > > > > > Apply Occams razor.
> >
> > > > > > > Have a nice synthesis
> > > > > > > =A0 Eilert
> >
> > > > > > Eilert,
> > > > > > Actually I want to create something new in HDL, a new type of p=
rocess, that leads to the problem: the concept of a concurrent combinatoria=
l process:
> > > > > > 1. The new process is a concurrent process as other processes a=
re.
> > > > > > 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 gramma=
r.
> >
> > > > > > 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. =A0If 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 t=
he
> > > > > outputs are defined for all combinations of inputs. =A0If you wan=
t 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 genera=
te
> > > > > combinatorial logic because you don't exclude feedback or require=
 all
> > > > > input combinations to be defined. =A0Many a new HDL designer has
> > > > > inadvertently left out some input combinations or used feedback a=
nd
> > > > > ended up with latches. =A0Heck, even experienced designers do thi=
s 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 genera=
te
> > > > combinatorial logic because you don't exclude feedback or require a=
ll
> > > > 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 c=
ase.
> >
> > > > Weng
> >
> > > A latch is a sequential device. =A0It has memory and that is how
> > > "sequential" is defined.
> >
> > > As I said, I don't see the value of your proposition. =A0What are you
> > > trying to accomplish?
> >
> > > Rick
> >
> > Hi Rick,
> > I hope to publish my paper as soon as possible, but I cannot disclose i=
ts 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 proc=
ess, 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 co=
mment on IF it is useful.
> >
> > Weng
>=20
> 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".
>=20
> 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".
>=20
> If you are suggesting some sort of formalism that treats latches as
> combinatorial logic then by my reckoning you are in left field.
>=20
> Rick

Hi Rick,
Thank you for your concern.

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

I have abandoned the idea to use the clock statement or other inaccurate de=
scriptions.

Weng

Article: 153930
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Sat, 30 Jun 2012 19:50:21 -0700 (PDT)
Links: << >> << T >> << A >>

On Jun 29, 10:29=A0pm, 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=A0pm, 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 Tianxi=
ang:
> > > > > > > The following topic may be one of the longest debate in vhdl =
group:
> > > > > > >http://groups.google.com/group/comp.lang.vhdl/browse_thread/th=
read/bd...
>
> > > > > > > The debute focus later turns to which is best way to use one
> > > > > > > sequential process or two combinarotial process and sequentia=
l
> > > > > > > process.
>
> > > > > > > The most important and strange thing is that I cannot even fi=
nd the
> > > > > > > word "combinarotial" in VHDL-2002 specification.
>
> > > > > > > I want to grammarly define a combinatorial process which cann=
ot have a
> > > > > > > clock statement in one of my thinking.
>
> > > > > > > process_statement_part ::=3D
> > > > > > > { sequential_statement }
>
> > > > > > > sequential_statement ::=3D
> > > > > > > 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 ::=3D
> > > > > > > { combinatorial_sequential_statement }
>
> > > > > > > combinatorial_sequential_statement ::=3D
> > > > > > > assertion_statement =A0 -- 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 m=
isunderstanding 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 conn=
ection whatsoever to the resulting circuit.
>
> > > > > > The opposite of "sequential" here is "concurrent", not "combina=
torical".
> > > > > > "Combinatorical" has no meaning for the language, and therefore=
 doesn't need to be specified anywhere in the standard. But when you look i=
nto 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 identifi=
ed 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 de=
scriptions for things that are nicely covered in one compact and generic de=
scription.
>
> > > > > > The contradiction of such a request can already be found in the=
 proposed syntax description:
> > > > > > =A0combinatorial_process_statement_part ::=3D
> > > > > > { combinatorial_SEQUENTIAL_statement }
>
> > > > > > Does this ease up something?
> > > > > > and how to avoid the usage of
>
> > > > > > =A0 if rising_edge(clk) then
>
> > > > > > in such a dedicated combinatorical process.
>
> > > > > > and what if in a dedicated non_combinatorical process only this=
 is used:
>
> > > > > > =A0 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 gram=
mar specification is sufficient.
>
> > > > > > Apply Occams razor.
>
> > > > > > Have a nice synthesis
> > > > > > =A0 Eilert
>
> > > > > Eilert,
> > > > > Actually I want to create something new in HDL, a new type of pro=
cess, 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 o=
r implicit, is allowed.
> > > > > 3. In the new process all sequential statements, excluding wait s=
tatement, 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 th=
e 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 o=
f 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. =A0If 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. =A0If 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 a=
ll
> > > > input combinations to be defined. =A0Many a new HDL designer has
> > > > inadvertently left out some input combinations or used feedback and
> > > > ended up with latches. =A0Heck, even experienced designers do this =
once
> > > > in a while.
>
> > > > The resulting logic comes from how you describe the process, not wh=
at
> > > > 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 pr=
ocess, how do you generate a ff? latch is allowed to be generated in my cas=
e.
>
> > You've forgotten a very basic principle...EVERY logic circuit (includin=
g flip flops) can be described with nothing more than nand (or nor) gates. =
=A0A flip flop can be described with nand gates. =A0The (likely) fact that =
no synthesis tool on the market will take a nand gate description and synth=
esize a flip flop simply reflects the limitations of the tools at this poin=
t in time. =A0There are many such limitations, but those are all examples w=
here synthesis tools are not able to adhere to the language defintion while=
 also synthesizing the optimal circuit. =A0Limitations can disappear in the=
 future.
>
> > In any case, since a flip flop can be described with only nand or nor g=
ates, then it is not possible to limit the current scope of the language to=
 prevent a flip flop from being described in HDL. =A0Therefore, any such de=
finition that you come up with to try to prevent a flip flop from being des=
cribed 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. =A0The (likely) fact that =
no synthesis tool on the market will take a nand gate description and synth=
esize a flip flop simply reflects the limitations of the tools at this poin=
t in time."
>
> James comment on VHDL-2008 in comp.lang.vhdl group is very useful and I t=
hink 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

Article: 153931
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 1 Jul 2012 03:34:47 +0000 (UTC)
Links: << >> << T >> << A >>

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

Article: 153932
Subject: Re: The definition of comnatorial prcess?
From: Rob Doyle <radioengr@gmail.com>
Date: Sun, 01 Jul 2012 00:29:22 -0700
Links: << >> << T >> << A >>

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.

Article: 153933
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 1 Jul 2012 07:42:51 +0000 (UTC)
Links: << >> << T >> << A >>

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

Article: 153934
Subject: Re: The definition of comnatorial prcess?
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 01 Jul 2012 09:08:47 +0100
Links: << >> << T >> << A >>

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

Article: 153935
Subject: Re: The definition of comnatorial prcess?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 1 Jul 2012 09:58:52 -0700 (PDT)
Links: << >> << T >> << A >>

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

Article: 153936
Subject: Re: The definition of comnatorial prcess?
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 1 Jul 2012 12:39:28 -0700 (PDT)
Links: << >> << T >> << A >>

On Sunday, July 1, 2012 3:29:22 AM UTC-4, Rob Doyle wrote:
> On 6/30/2012 8:34 PM, glen herrmannsfeldt wrote:
>=20
> > 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
>=20
> Why do you say that?  With two transparent latches (a master and
> a slave) you can make an edge triggered flip-flop, right?
>=20
> Even wikipedia has a some examples.
>=20

I don't think that's the point.  I aleady pointed out earlier to Weng's que=
ry that since every circuit can be described with nand or nor gates that a =
flip flop can be described without reference to any 'clocks' or edges or wa=
it statements.  Wikipedia (and other sources) simply describe such an imple=
mentation.

I also stated that I would not expect any synthesis tool on the market to t=
ake such a description and implement with a hard flip flop.  Instead it wou=
ld most likely simply implement the gate description.  At a functional leve=
l the whole thing is a flip flop (with probably very poor timing performanc=
e metrics) but it wasn't implemented as optimally as it could have been imp=
lemented (i.e. with a single hard flip flop).  However, that is simply a li=
mitation of the synthesis tool in taking a valid description and inferring =
the optimal logic.  That could change in the future.  There are many things=
 that use to not be synthesizable but now are.

I wouldn't expect the optimal implementation of a gate level description of=
 a flip flop to be something that any synthesis tool provider has anywhere =
on the 'to do' list, there are much better things 'to do'.  However, nobody=
 can absolutely rule it out either.

Kevin Jennings

Article: 153937
Subject: Re: The definition of comnatorial prcess?
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 1 Jul 2012 13:03:38 -0700 (PDT)
Links: << >> << T >> << A >>

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

>   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
>=20
> 1. complete sensitivity list (like VHDL 2008 (all) as Jim said)
> 2. no feedback
> 3. no incomplete assignment of outputs
>=20
> Some examples
>=20
> process(all)
> begin
>   o <=3D not i;
> end process;
>=20

Not necessarily...what if the logic for i is "i <=3D o"?  Then it is feedba=
ck.

Here's another:

process(sel, a, b)
begin
  o <=3D a when sel =3D '0' else b;
end process;

Is the above description that of a 2->1 mux (as suggested by the signal nam=
es) or a transparent latch?  If it's a mux, one would think that this is si=
mple combinatorial logic with no memory; if it's a transparent latch then i=
t certainly does have memory.  Without context, one cannot say whether the =
above process is a mux or a latch.

The point is that you can't look at the process level to determine whether =
or not some logic description has feedback or not.  However, synthesis tool=
s don't look any higher than the process level in order to generate the fir=
st cut at the logic because they do not need to look any higher, the proces=
s (and only the process) contains the logic being described.  It then optim=
izes Boolean logic according to the usual rules of Boolean logic.  So for p=
urposes of generating logic, synthesis tool do not care at all if there is =
feedback.  Timing analyzer do, but they do analysis of an existing circuit,=
 not generation of the circuit.

That's why Weng's fundamental premise of how to define a 'combinatorial pro=
cess' was inherently flawed.  Whether or not a given process implements mem=
ory or not cannot be determined simply from the process so any attempt to d=
o so will ultimately fail.  In any case, it appears that he has moved on an=
d abandoned this line.

Kevin Jennings

> process(all)
> begin
>   o <=3D not o; -- feedback
> end process;
>=20
> process(all)
> begin
>   if enable =3D '1' then
>     o <=3D i;
>   end if;
>   -- o not assigned when enable =3D '0', implies transparent latch
> end process;
>=20
> 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).
>=20
> So I guess you could propose them for VHDL if you like!
>=20
> regards
> Alan
>=20
> --=20
> Alan Fitch

Article: 153938
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Sun, 1 Jul 2012 13:24:08 -0700 (PDT)
Links: << >> << T >> << A >>

On Jun 30, 11:34=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> > I think you have a different perspective on what synthesis tools do
> > compared to my experience. =A0The 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. =A0If you use a bunch of ands and ors to describe how a F=
F
> > works I would not doubt for a moment that the tools would utilize a
> > FF. =A0But 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. =A0What
> > happens when you try to use combinatorial logic and you fail to fully
> > define the behavior? =A0Will it not generate a latch? =A0What will it
> > generate?
>
> -- glen

But an edge triggered ff is just two sequential latches with opposite
level sensitivities, no?

Rick

Article: 153939
Subject: Re: The definition of comnatorial prcess?
From: rickman <gnuarm@gmail.com>
Date: Sun, 1 Jul 2012 13:24:53 -0700 (PDT)
Links: << >> << T >> << A >>

On Jul 1, 12:58=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> 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. =A0A latch is a typ=
e of
> > >> flipflop. =A0I don't know what you mean when you say it is "allowed"=
 to
> > >> be generated. =A0I 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. =A0There are no "clock statements=
"
> > >> that I know of. =A0You wait for an edge and make an assignment and d=
o
> > >> nothing the rest of the time, or you wait for a level and make an
> > >> assignment and do nothing the rest of the time. =A0What 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. =A0There 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" =3D "transparent latch" or "edge triggered
> > flip-flop": hence using "transparent" and "edge-triggered" when teachin=
g
> > to avoid confusion.
>
> > > Hi Rick,
> > > Thank you for your concern.
>
> > > I actually find that James has given the right answer: It requires th=
e format he suggested: process(all) that says what I want to say.
>
> > > I have abandoned the idea to use the clock statement or other inaccur=
ate descriptions.
>
> > > Weng
>
> > Hi Weng,
> > =A0 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
> > =A0 o <=3D not i;
> > end process;
>
> > process(all)
> > begin
> > =A0 o <=3D not o; -- feedback
> > end process;
>
> > process(all)
> > begin
> > =A0 if enable =3D '1' then
> > =A0 =A0 o <=3D i;
> > =A0 end if;
> > =A0 -- o not assigned when enable =3D '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 war=
n
> > 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 comb=
inatorial 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 fe=
edback 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

You still have not explained what the utility of your approach is.  I
don't understand how the shorthand process(all) changes the
situation.  This is just a shorthand so the designer does not need to
specify each of the inputs to the process.  It does not in any way
change the functionality of the process or act as any sort of "hint"
to the compiler.

Rick

Article: 153940
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 1 Jul 2012 22:06:22 +0000 (UTC)
Links: << >> << T >> << A >>

Alan Fitch <apf@invalid.invalid> wrote:

(snip)

>  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

So, what about the ones-complement adder with end-around-carry?

That has feedback, but hopefully is still combinatorial.

-- glen

Article: 153941
Subject: Re: The definition of comnatorial prcess?
From: Alan Fitch <apf@invalid.invalid>
Date: Sun, 01 Jul 2012 23:33:05 +0100
Links: << >> << T >> << A >>

On 01/07/12 21:03, KJ wrote:
> On Sunday, July 1, 2012 4:08:47 AM UTC-4, Alan Fitch wrote:
> 
>>   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;
>>
> 
> Not necessarily...what if the logic for i is "i <= o"?  Then it is feedback.

Good point. Perhaps I should have said "if STA says 'combinational loop
detected'" then that is feedback :-)

> 
> Here's another:
> 
> process(sel, a, b)
> begin
>   o <= a when sel = '0' else b;
> end process;
> 
> Is the above description that of a 2->1 mux (as suggested by the signal names) or a transparent latch?  If it's a mux, one would think that this is simple combinatorial logic with no memory; if it's a transparent latch then it certainly does have memory.  Without context, one cannot say whether the above process is a mux or a latch.
> 

It's up to the synthesis tool. But it looks like a mux to me. But I
guess I'll wait for STA to tell me if there's some outside feedback I
can't see.


> The point is that you can't look at the process level to determine whether or not some logic description has feedback or not.  However, synthesis tools don't look any higher than the process level in order to generate the first cut at the logic because they do not need to look any higher, the process (and only the process) contains the logic being described.  It then optimizes Boolean logic according to the usual rules of Boolean logic.  So for purposes of generating logic, synthesis tool do not care at all if there is feedback.  Timing analyzer do, but they do analysis of an existing circuit, not generation of the circuit.
> 
> That's why Weng's fundamental premise of how to define a 'combinatorial process' was inherently flawed.  Whether or not a given process implements memory or not cannot be determined simply from the process so any attempt to do so will ultimately fail.  In any case, it appears that he has moved on and abandoned this line.
>

I agree with you - but the people who wrote the SystemVerilog standard
don't.

Alan


> Kevin Jennings
> 


-- 
Alan Fitch

Article: 153942
Subject: Re: The definition of comnatorial prcess?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 1 Jul 2012 22:35:31 +0000 (UTC)
Links: << >> << T >> << A >>

rickman <gnuarm@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.

(snip)
> But an edge triggered ff is just two sequential latches with 
> opposite level sensitivities, no?

I don't believe that is quite enough. If you read

http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Master.E2.80.93slave_pulse-triggered_D_flip-flop

It says: 

  "Nearly simultaneously, the twice inverted "enable" 
   of the second or "slave" D latch transitions from 
   low to high (0 to 1) with the clock signal."

Now, how do you implement "nearly simultaneously"?

It depends in a complicated way on the timing through the second
inverter, and the timing through the master section. Even more,
it depends on the timing being different for rising and falling
edges of the clock.

In my first digital electronics (lecture) class, (CS/EE4)
all the class discussion and demonstrations were done
with a two-phase clock. (Must not be so bad, many microprocessors
use a one, and some even a four-phase clock.)

With two phases, you use one for the master and one for the
slave, and be sure that there is no overlap between them.

As we were going to have to work with TTL, where FFs only have
a single clock input, the lecturer explained that they work
with two different thresholds on the clock input.

I never tried to understand that detail since.

In any case, with an FPGA I don't believe that you can get the
timing close enough to separate the master and slave clocks.
Maybe if built from discrete gates or transistors.

-- glen

Article: 153943
Subject: Re: The definition of comnatorial prcess?
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 1 Jul 2012 16:06:47 -0700 (PDT)
Links: << >> << T >> << A >>

On Sunday, July 1, 2012 6:33:05 PM UTC-4, Alan Fitch wrote:
> On 01/07/12 21:03, KJ wrote:
> >=20
> > Here's another:
> >=20
> > process(sel, a, b)
> > begin
> >   o <=3D a when sel =3D '0' else b;
> > end process;
> >=20
> > Is the above description that of a 2->1 mux (as suggested by the signal=
 names) or a transparent latch?  If it's a mux, one would think that this i=
s simple combinatorial logic with no memory; if it's a transparent latch th=
en it certainly does have memory.  Without context, one cannot say whether =
the above process is a mux or a latch.
> >=20
>=20
> It's up to the synthesis tool. But it looks like a mux to me. But I
> guess I'll wait for STA to tell me if there's some outside feedback I
> can't see.
>=20

It's not up to the synthesis tool, it's up to the designer who wrote the co=
de that is to be synthesized.  To see the transparent latch, make the follo=
wing connection:

b <=3D o; -- or a <=3D o;

Where 'sel' plays the role of the latch enable.

Kevin Jennings

Article: 153944
Subject: Generate a pulse with a definite width
From: "nba83" <nba_baheri@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.com>
Date: Mon, 02 Jul 2012 04:26:51 -0500
Links: << >> << T >> << A >>

hi
is it a good practice to generate a pulse strobe in Verilog with this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
this signal after some delay, I used this code,I 'm skeptical that this
code is not efficient
		if(BoardConfigReceivedStrobe)
		begin
			DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
			if(DelayCounterBoardConfig>100)
			begin
				DelayCounterBoardConfig<=0;
				BoardConfigReceivedStrobe<=0;
			end
		end

tnx in advanced for any comments
Neda 		   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153945
Subject: Re: Generate a pulse with a definite width
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 2 Jul 2012 03:34:54 -0700 (PDT)
Links: << >> << T >> << A >>

On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
> hi
> is it a good practice to generate a pulse strobe in Verilog with this code?
> or do i need to write a fsm for such applications?
> BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
> this signal after some delay, I used this code,I 'm skeptical that this
> code is not efficient
> 		if(BoardConfigReceivedStrobe)
> 		begin
> 			DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
> 			if(DelayCounterBoardConfig>100)
> 			begin
> 				DelayCounterBoardConfig<=0;
> 				BoardConfigReceivedStrobe<=0;
> 			end
> 		end
> 
> tnx in advanced for any comments
> Neda 		   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com

For a fixed count value like you have a more efficient way of counting is usually an LFSR.  Since a binary counter to 100 as you have now is not really that large to begin with it may not save you all that much.

Kevin Jennings

Article: 153946
Subject: Re: The definition of comnatorial prcess?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 02 Jul 2012 13:11:06 +0200
Links: << >> << T >> << A >>

On 07/01/2012 10:03 PM, KJ wrote:

> That's why Weng's fundamental premise of how to define a
> 'combinatorial process' was inherently flawed.  Whether or not a
> given process implements memory or not cannot be determined simply
> from the process so any attempt to do so will ultimately fail.

This line of reasoning would apply to any type of logic
description, not just VHDL or Verilog. It would imply that
the use of the word "combinatorial" is meaningless, which
is rather absurd.

It is perfectly possible to make meaningful statements of a VHDL
process in isolation. If its behavior is stateless, it is quite
appropriate to call it combinatorial. There is no contradition
with the fact that such logic may become part of the state
in a higher level circuit.

I suspect we will continue to talk about clocked processes
and combinatorial processes, and everyone will perfectly
understand what is meant.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 153947
Subject: Re: The definition of comnatorial prcess?
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 2 Jul 2012 07:41:41 -0700 (PDT)
Links: << >> << T >> << A >>

On Monday, July 2, 2012 7:11:06 AM UTC-4, Jan Decaluwe wrote:
> On 07/01/2012 10:03 PM, KJ wrote:
>=20
> > That's why Weng's fundamental premise of how to define a
> > 'combinatorial process' was inherently flawed.  Whether or not a
> > given process implements memory or not cannot be determined simply
> > from the process so any attempt to do so will ultimately fail.
>=20
> This line of reasoning would apply to any type of logic
> description, not just VHDL or Verilog.

Agreed.

> It would imply that
> the use of the word "combinatorial" is meaningless, which
> is rather absurd.
>=20

No, it would not imply that statement.  I'm simply saying that you can't lo=
ok at a process and label it as 'combinatorial' (i.e. without state) or not=
.  Weng's was originally asking because he said he said he wanted to "gramm=
arly (sic) define a combinatorial (sic) process which cannot have a clock s=
tatement".  What isn't totally clear from that is whether he meant to exclu=
de latches or just flip flops from his definition of a combinatorial proces=
s.  He later posted something that indicated that latches would be OK, but =
that appeared to be in some larger context, not just in the labelling of a =
process being of a certain type.

I'm saying that the labelling of a process as being with or without state i=
s not possible without considering the context that the process is in (i.e.=
 what the signal connections are).  The example I offered to demonstrate th=
is clearly is the process for a 2->1 mux which can be used completly unchan=
ged to implement a transparent latch.

> It is perfectly possible to make meaningful statements of a VHDL
> process in isolation. If its behavior is stateless, it is quite
> appropriate to call it combinatorial. There is no contradition
> with the fact that such logic may become part of the state
> in a higher level circuit.

The example I proposed for the process that implements a 2->1 mux but can b=
e used unchanged to implement a transparent latch would contradict your sta=
tement if the 'meaningful statement' is that such a process does not implem=
ent state.

>=20
> I suspect we will continue to talk about clocked processes
> and combinatorial processes, and everyone will perfectly
> understand what is meant.
>=20

Eh...maybe we should give it up, it's not that important.  Bottom line is t=
hat simulation and synthesis tools simulate or implement the described logi=
c and do not have need for labelling a process as 'combinatorial'.

Kevin Jennings

Article: 153948
Subject: Re: The definition of comnatorial prcess?
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 02 Jul 2012 18:54:57 +0200
Links: << >> << T >> << A >>

On 07/02/2012 04:41 PM, KJ wrote:
> On Monday, July 2, 2012 7:11:06 AM UTC-4, Jan Decaluwe wrote:
>> On 07/01/2012 10:03 PM, KJ wrote:
>>
>>> That's why Weng's fundamental premise of how to define a
>>> 'combinatorial process' was inherently flawed.  Whether or not a
>>> given process implements memory or not cannot be determined
>>> simply from the process so any attempt to do so will ultimately
>>> fail.
>>
>> This line of reasoning would apply to any type of logic
>> description, not just VHDL or Verilog.
>
> Agreed.
>
>> It would imply that the use of the word "combinatorial" is
>> meaningless, which is rather absurd.
>>
>
> No, it would not imply that statement.  I'm simply saying that you
> can't look at a process and label it as 'combinatorial' (i.e. without
> state) or not.

My point is that with that same reasoning, you would not be able
to label, say, a Karnaugh map as describing combinatorial logic.
I don't find that useful.

>> It is perfectly possible to make meaningful statements of a VHDL
>> process in isolation. If its behavior is stateless, it is quite
>> appropriate to call it combinatorial. There is no contracdition with
>> the fact that such logic may become part of the state in a higher
>> level circuit.
>
> The example I proposed for the process that implements a 2->1 mux but
> can be used unchanged to implement a transparent latch would
> contradict your statement if the 'meaningful statement' is that such
> a process does not implement state.

That process itself does not implement state, the
way it is used may or may not. Just like a Karnaugh map.

>> I suspect we will continue to talk about clocked processes and
>> combinatorial processes, and everyone will perfectly understand
>> what is meant.
>>
>
> Eh...maybe we should give it up, it's not that important.  Bottom
> line is that simulation and synthesis tools simulate or implement the
> described logic and do not have need for labelling a process as
> 'combinatorial'.

I want to be able to talk about such processes to designers,
if only to persuade them to avoid them and describe the
behavior in clocked processes only :-)


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 153949
Subject: Re: Generate a pulse with a definite width
From: Gabor <gabor@szakacs.invalid>
Date: Mon, 02 Jul 2012 15:32:21 -0400
Links: << >> << T >> << A >>

KJ wrote:
> On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
>> hi
>> is it a good practice to generate a pulse strobe in Verilog with this code?
>> or do i need to write a fsm for such applications?
>> BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
>> this signal after some delay, I used this code,I 'm skeptical that this
>> code is not efficient
>> 		if(BoardConfigReceivedStrobe)
>> 		begin
>> 			DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
>> 			if(DelayCounterBoardConfig>100)
>> 			begin
>> 				DelayCounterBoardConfig<=0;
>> 				BoardConfigReceivedStrobe<=0;
>> 			end
>> 		end
>>
>> tnx in advanced for any comments
>> Neda 		   
>> 					
>> ---------------------------------------		
>> Posted through http://www.FPGARelated.com
> 
> For a fixed count value like you have a more efficient way of counting is usually an LFSR.  Since a binary counter to 100 as you have now is not really that large to begin with it may not save you all that much.
> 
> Kevin Jennings

The only thing that looks unnecessarily complex is the magnitude
comparison "> 100" instead of an equallity comparison like "== 101"
which should give the same results unless your counter increments
outside of the posted part of the logic.

-- Gabor

Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search