The definition of comnatorial prcess?

[KJ]

On Sunday, July 1, 2012 3:29:22 AM UTC-4, Rob Doyle wrote:

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.

I don't think that's the point. I aleady pointed out earlier to Weng's query 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 wait statements. Wikipedia (and other sources) simply describe such an implementation.

I also stated that I would not expect any synthesis tool on the market to take such a description and implement with a hard flip flop. Instead it would most likely simply implement the gate description. At a functional level the whole thing is a flip flop (with probably very poor timing performance metrics) but it wasn't implemented as optimally as it could have been implemented (i.e. with a single hard flip flop). However, that is simply a limitation 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

 

[KJ]

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.

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.

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.

Kevin Jennings

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

 

[rickman]

On Jun 30, 11:34 pm, 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.  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

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

Rick

 

[rickman]

On Jul 1, 12:58 pm, 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.  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

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

 

[Alan Fitch]

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

 

[glen herrmannsfeldt]

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

 

[glen herrmannsfeldt]

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

 

[KJ]

On Sunday, July 1, 2012 6:33:05 PM UTC-4, Alan Fitch wrote:

On 01/07/12 21:03, KJ wrote:

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.

It's not up to the synthesis tool, it's up to the designer who wrote the code that is to be synthesized. To see the transparent latch, make the following connection:

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

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

Kevin Jennings

 

[Jan Decaluwe]

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

 

[KJ]

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.. Weng's was originally asking because he said he said he wanted to "grammarly (sic) define a combinatorial (sic) process which cannot have a clock statement". What isn't totally clear from that is whether he meant to exclude latches or just flip flops from his definition of a combinatorial process. 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 is not possible without considering the context that the process is in (i.e. what the signal connections are). The example I offered to demonstrate this clearly is the process for a 2->1 mux which can be used completly unchanged 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 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.

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'.

Kevin Jennings

 

[Jan Decaluwe]

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

 

[Alan Fitch]

On 02/07/12 00:06, KJ wrote:

On Sunday, July 1, 2012 6:33:05 PM UTC-4, Alan Fitch wrote:
On 01/07/12 21:03, KJ wrote:

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.


It's not up to the synthesis tool, it's up to the designer who wrote the code that is to be synthesized. To see the transparent latch, make the following connection:

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

Sorry, I left out too many steps. What I intended to say was that I tend
to assume that people design latches by mistake. Therefore they will
find out when STA (Static Timing Analysis) tells them there is
combinational feedback.

regards
Alan

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

Kevin Jennings

--
Alan Fitch

 

[Weng Tianxiang]

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.
Kevin

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.

Jan

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.

Alan

That is why I say SystemVerilog does a correct and better thing than VHDL: It introduces 3 types of basic circuits in digital world: always_comb, always_latch, and always_ff.

That eliminates all confusions introduced by VHDL ambiguous definition of one process implying more than 3 different things that I don't see any end-light in the discussion.

In DNA world, there are only 4 gene bases: The four bases found in DNA are adenine (abbreviated A), cytosine (C), guanine (G) and thymine (T).

Over there people in DNA world always talk about A, C, G and T.

In digital electric world there are only 3 basic circuits that people are interested in: ff, latch and combinatorial. By combinatorial signal it means it is neither a ff nor a latch.

After realizing that combinatorial is fully excluded in VHDL-2008, I abandon any attempts to use it accurately. So I am finally easy with process(all) specification.

I really recommend that VHDL-201x use 3 process type definitions to replace one ambiguous process definition: process_com, process_latch and process_ff.

Each type generates only one type of logic. When process_com misses an assignment, it would generate an error. So no any confusion will be introduced.

Weng

 

[Rob Doyle]

On 7/1/2012 12:42 AM, glen herrmannsfeldt wrote:

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

I don't think different thresholds are necessary.
The master and slave latches work on alternate
phases of the clock.

Way back in the days, we designed latches,
flip-flops, shift registers, and memory with just
transmission gates and inverters using a two-phase
non-overlapping clock...

I guess that was in the day when transistors were
expensive and logic simulation was done with SPICE.

Anyway, the following set of latches /does/ simulate
(Xilinx ISE) as a positive edge-triggered toggle
flip-flop:

---- begin ----

architecture Beh of test is

signal input : std_logic;
signal master : std_logic := '0';
signal slave : std_logic := '0';
signal clk : std_logic := '1';

begin

-- Clock

process
begin
wait for 10 ns;
clk <= not(clk);
end process;

-- Master Latch

master <= input when clk = '0' else master;

-- Slave Latch

slave <= master when clk = '1' else slave;

-- Make flip-flop toggle

input <= not(slave);

end Beh;

---- end ----

It sure looks combinatorial ... Hmm....

Rob.

 

[Jan Decaluwe]

On 07/03/2012 03:43 AM, Weng Tianxiang wrote:

That is why I say SystemVerilog does a correct and better thing than
VHDL: It introduces 3 types of basic circuits in digital world:
always_comb, always_latch, and always_ff.

That eliminates all confusions introduced by VHDL ambiguous
definition of one process implying more than 3 different things that
I don't see any end-light in the discussion.

In digital electric world there are only 3 basic circuits that people
are interested in: ff, latch and combinatorial. By combinatorial
signal it means it is neither a ff nor a latch.

I really recommend that VHDL-201x use 3 process type definitions to
replace one ambiguous process definition: process_com, process_latch
and process_ff.

You should think differently about VHDL/Verilog. Their
purpose is absolutely not limited to describing circuits
according to your classification.

First and foremost, you use them for high-level modeling
and verification. Your classification doesn't apply to such
modeling.

Secondly, in RTL modeling a clocked process is a very effective
modeling abstraction from which both sequential devices and
combinatorial logic are inferred.

For the latter reason, I believe always_ff is problematic.
If it restricts assignments to FF inference only, it is a step
backwards compared to a classic clocked process. Otherwise
it is confusing. (I don't know which path vendors choose.)

For those reasons, the VHDL process and Verilog initial/always
will never go away and will continue to be used intensively.

--
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

 

[KJ]

That eliminates all confusions introduced by VHDL ambiguous definition of one process implying more than 3 different things that I don't see any end-light in the discussion.

You seem to be the only one that has stated any confusion, everybody else seems OK that a process can be used to describe different hardware. The languages are meant to describe hardware, both do exactly that. The source of the confusion that you seem to think exists is only in the lack of ability to slap a particular label on the process. Why you see some utility is such a label is of course your concern, but to the vast majority of those who use the language, they are interested in one of the following two areas:
- Describing a function that needs to meet a performance goal (designers) or to test such a design (verifiers)
- Interpreting the language and performing a completely computer based function with no direct connection to any specific hardware (simulation and synthesis tool writers)

What you describe as a confusion is of no consequence to either of these classes of users of the language. These groups probably account for nearly all users of the languages. Outside of those groups of people, it probably doesn't much matter what someone might think.

In DNA world, there are only 4 gene bases: The four bases found in DNA are adenine (abbreviated A), cytosine (C), guanine (G) and thymine (T).

Over there people in DNA world always talk about A, C, G and T.

Is this relevant? In the English speaking world, they talk about 26 letters...that would be just as relevant.

In digital electric world there are only 3 basic circuits that people are interested in: ff, latch and combinatorial. By combinatorial signal it means it is neither a ff nor a latch.

There is another one that is important and widely used that you have not considered (or at least you haven't mentioned).

I really recommend that VHDL-201x use 3 process type definitions to replace one ambiguous process definition: process_com, process_latch and process_ff.

Each type generates only one type of logic. When process_com misses an assignment, it would generate an error. So no any confusion will be introduced.

Assuming the 'process_xxx' to be optional, I suppose there may be some value to having an error being declared if somebody describes a hunk of logic but declares it to be something else. Maybe it would help those folks who today write combinatorial processes and are ignoring the warnings that are already being reported about latches being created and sensitivity lists being expanded. For those of us that use clocked processes nearly exclusively, it would not be of any value so as long as you don't burden us with requiring a label, OK.

Kevin Jennings

 

Am Dienstag, 3. Juli 2012 03:43:47 UTC+2 schrieb Weng Tianxiang:

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.
Kevin

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.

Jan

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.

Alan

That is why I say SystemVerilog does a correct and better thing than VHDL: It introduces 3 types of basic circuits in digital world: always_comb, always_latch, and always_ff.

That eliminates all confusions introduced by VHDL ambiguous definition of one process implying more than 3 different things that I don't see any end-light in the discussion.

In DNA world, there are only 4 gene bases: The four bases found in DNA are adenine (abbreviated A), cytosine (C), guanine (G) and thymine (T).

Over there people in DNA world always talk about A, C, G and T.

In digital electric world there are only 3 basic circuits that people are interested in: ff, latch and combinatorial. By combinatorial signal it means it is neither a ff nor a latch.

After realizing that combinatorial is fully excluded in VHDL-2008, I abandon any attempts to use it accurately. So I am finally easy with process(all) specification.

I really recommend that VHDL-201x use 3 process type definitions to replace one ambiguous process definition: process_com, process_latch and process_ff.

Each type generates only one type of logic. When process_com misses an assignment, it would generate an error. So no any confusion will be introduced.

Weng

Hi Weng,
I think it's a matter of how one thinks about it.
What you call "ambiguous" is seen by others (including me) as multivalent.

Also limiting specialized process types would be a step back (as already mentioned) and just make things unnecessary complicated.
When a process is intended to generate only logic - latch - FFs, excluding everything else, this is like it was at PLD-times.
There you had languages like ABEL or Log/IC which had barely just two kinds of assignments, registerd and unregistered. At least you could write some boolean equation behind a registered assignment. But as I understand you that would be forbidden in a process_ff, because no logic is allowed there, or is it?

I'm missing one person in this discussion, who's name just don't comes to my mind at the moment, but I think everyone will know who I'm talking about.
That guy prefered a design style that had everything in one process per architecture. He makes heavy use of variables, functions and procedures to keep his code structured.

He too would probably be asking: "What's the gain of your proposal?"
Just having the opportunity to get some dedicated error messages instead of just warnings when latches occur unintended?
If this is really needed by designers and the toolmakers see a market for this feature, some attributes/pragmas would acheive the same, and they have no impact on the grammar.

e.g. (done with concurrent assignments to save lines)
-- pragma combinatorical begin

y <= a nand b; -- would be accepted

q <= a when rising_edge(clk); -- a simple D-FF would be rejected here and give an error

-- pragma combinatorical end

Similar things could be done for latch and FFs.
The tools would need the same code as for your proposal to identify the forbidden situations, but the basic language definition for a process could still be pure and ... multivalent. ;-)

By the way, when I saw the Systemverilog always_comb etc. keywords for the first time it made me grin and shake my head. Later on I thougth "OK, this might be useful for verilog, where you have stuff like always @(...posedge reset) which could be misinterpreted as an edge sensitive input. VHDL does not have this ambiguouty, so luckyly it's not needed there".

Have a nice synthesis
Eilert

 

[rickman]

On Jul 1, 6:35 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

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

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

I'm not sure what point you are trying to make. The issue at hand is
whether the tools should be able to infer an edge triggered ff from an
HDL combinatorial description of the gates that make up such a
device. To make a gate design work correctly requires careful
analysis of delays to preclude the two enables from overlapping.
However if I describe two latches with a proper logical description
why can't the tool infer a ff in an FPGA? Logically it is correct and
it will give the correct behavior in simiulation. Isn't that what
really matters, not whether the tool can design an edge sensitive ff
from LUTs but if the description is adequate to infer a ff?

Rick

 

[glen herrmannsfeldt]

rickman <gnuarm@gmail.com> wrote:
(snip)

http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Master.E2.80...

(snip)

I'm not sure what point you are trying to make. The issue at hand is
whether the tools should be able to infer an edge triggered ff from an
HDL combinatorial description of the gates that make up such a
device. To make a gate design work correctly requires careful
analysis of delays to preclude the two enables from overlapping.
However if I describe two latches with a proper logical description
why can't the tool infer a ff in an FPGA? Logically it is correct and
it will give the correct behavior in simiulation. Isn't that what
really matters, not whether the tool can design an edge sensitive ff
from LUTs but if the description is adequate to infer a ff?

OK, I suppose I agree with that one. Though I am not so sure that
any of the tools would actually figure it out. Normally, you
use the negedge or posedge (in verilog, or equivalent in VHDL)
that specifically asks for an edge triggered FF.

If you do actually manage with gates and delays to make something
that is logically correct, I would be surprised if it worked at all.

As far as I know, it is usual for the tools to ignore any delay
statements. Without delays, any delay based latch or FF will fail.

-- glen

 

[rickman]

On Jul 9, 1:15 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

rickman <gnu...@gmail.com> wrote:

(snip)

http://en.wikipedia.org/wiki/Flip-flop_%28electronics%29#Master.E2.80....

(snip)

I'm  not sure what point you are trying to make.  The issue at hand is
whether the tools should be able to infer an edge triggered ff from an
HDL combinatorial description of the gates that make up such a
device.  To make a gate design work correctly requires careful
analysis of delays to preclude the two enables from overlapping.
However if I describe two latches with a proper logical description
why can't the tool infer a ff in an FPGA?  Logically it is correct and
it will give the correct behavior in simiulation.  Isn't that what
really matters, not whether the tool can design an edge sensitive ff
from LUTs but if the description is adequate to infer a ff?

OK, I suppose I agree with that one. Though I am not so sure that
any of the tools would actually figure it out. Normally, you
use the negedge or posedge (in verilog, or equivalent in VHDL)
that specifically asks for an edge triggered FF.

If you do actually manage with gates and delays to make something
that is logically correct, I would be surprised if it worked at all.

As far as I know, it is usual for the tools to ignore any delay
statements. Without delays, any delay based latch or FF will fail.

-- glen

I agree 100% that would be hard to create a edge sensitive ff from
logic in an FPGA or elsewhere unless you have a way to assure non-
overlapping clocks. I don't think delay statements (even if they were
not ignored by synthesis), would be enough to fully specify a
correctly working ff. I think a logic description without delay
statements would produce a ff that works in simulation. The problem
is that an implementation would have unknown delays but more
specifically the skew of the clock signals would need to be
controlled. In fact, skew would likely need to be added to make the
two enables (master and slave) each less than 50% duty cycle. It
would be hard to do that with delay statements. But with no delay a
logic simulation would work because of the delta delays I think.

I have no idea if a properly constructed logic description would infer
an edge triggered ff in an FPGA or not. I guess that might just be a
bit too much to expect from the tools.

Rick