The definition of comnatorial prcess?

Not necessarily...what if the logic for i is "i

F

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

Rick

e of

to

".

" o g

e format he suggested: process(all) that says what I want to say.

ate descriptions.

the

n

all).

inatorial logic.

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.

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

(snip)

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

That has feedback, but hopefully is still combinatorial.

-- glen

(snip, I wrote)

(snip)

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

"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

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.

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

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

Agreed.

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.

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.

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

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.

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

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

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.

that is to be synthesized. To see the transparent latch, make the following connection:

--
Alan Fitch

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

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

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

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 s= eems OK that a process can be used to describe different hardware. The lan= guages 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 su= ch 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) o= r to test such a design (verifiers)

- Interpreting the language and performing a completely computer based func= tion with no direct connection to any specific hardware (simulation and syn= thesis tool writers)

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

e adenine (abbreviated A), cytosine (C), guanine (G) and thymine (T).

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

interested in: ff, latch and combinatorial. By combinatorial signal it mea= ns it is neither a ff nor a latch.

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

ce one ambiguous process definition: process_com, process_latch and process= _ff.

signment, it would generate an error. So no any confusion will be introduce= d.

Assuming the 'process_xxx' to be optional, I suppose there may be some valu= e to having an error being declared if somebody describes a hunk of logic b= ut declares it to be something else. Maybe it would help those folks who t= oday write combinatorial processes and are ignoring the warnings that are a= lready being reported about latches being created and sensitivity lists bei= ng 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 requi= ring a label, OK.

Kevin Jennings

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

: It introduces 3 types of basic circuits in digital world: always_comb, al= ways_latch, and always_ff.=20

one process implying more than 3 different things that I don't see any end=

-light in the discussion.

e adenine (abbreviated A), cytosine (C), guanine (G) and thymine (T).

interested in: ff, latch and combinatorial. By combinatorial signal it mea= ns it is neither a ff nor a latch.

don any attempts to use it accurately. So I am finally easy with process(al= l) specification.

ce one ambiguous process definition: process_com, process_latch and process= _ff.

signment, it would generate an error. So no any confusion will be introduce= d.

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 me= ntioned) 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 th= at would be forbidden in a process_ff, because no logic is allowed there, o= r is it?

I'm missing one person in this discussion, who's name just don't comes to m= y 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 arc= hitecture. He makes heavy use of variables, functions and procedures to kee= p his code structured.=20

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 t= his 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)=20

-- pragma combinatorical begin

y

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

rickman wrote: (snip)

(snip)

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

.

is

d

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