New invention: Systematic method of coding wave pipelined ci

[Weng Tianxiang]

Hi Jim, glen, JK, rickman, Mike, Andy,

I have filed a provisional patent application: "Systematic method of coding wave pipelined circuits in HDL". If it is proved correct, the patent will introduce 1 keyword, 3 permanent constants, 1 concurrent statement and four source code modules for a new library in HDL and thoroughly resolve a pending problem so that every digital designer can code wave-pipelined circuits in HDL.

Here is the abstract of the invention:

The present invention classifies all critical paths into two basic types: a series critical path and a feedback critical path, and divides each of wave-pipelined circuits into two components: a static logic part, called critical path component (CPC), and a dynamic logic part, formalized into four wave-pipelining components (WPC) shared by all wave-pipelined circuits. Each wave-pipelining ready code in HDL comprises two components: a WPC instantiation and a CPC instantiation wire-connected and linked by a new link statement. Each WPC has new wave constants which play the same role as generic constants do, but whose initial values are determined and assigned by a synthesizer after code analysis, so designers can use after-synthesization information in their code before synthesization for wave-pipelining technology. The responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL is shifted from designers to synthesizers.

Anyone who are interested in its content is welcome to send a email request to the following email address: wtx wtx @ gmail . com with title "Systematic" and he will receive the full documents: one specification, 9 drawings and one text file in VHDL.

If one reviews the files and feels that it would be a good thing to recommend the application to his company to buy it, the first person to do it after his recommended company does so will receive $10,000 commission fee.

Thank you.

Weng

 

[Svenn]

On 24/02/15 18:09, Weng Tianxiang wrote:

If one reviews the files and feels that it would be a good thing to recommend the application
to his company to buy it, the first person to do it after his
recommended company does so
will receive $10,000 commission fee.

In my country, I would go to jail for doing so.

--
Svenn

 

[Weng Tianxiang]

On Thursday, February 26, 2015 at 3:37:37 AM UTC-8, Svenn Are Bjerkem wrote:

On 24/02/15 18:09, Weng Tianxiang wrote:
If one reviews the files and feels that it would be a good thing to recommend the application
to his company to buy it, the first person to do it after his
recommended company does so
will receive $10,000 commission fee.

In my country, I would go to jail for doing so.

--
Svenn

Svenn,

Do it following your company bylaw:
1. The recommendation does benefit your company.
2. Tell your company the commission fee. If your company agree you can accept it; if not abandon it.
3. Pay due tax properly.

I am not generate a crime scene for you to do the wrong thing.

Weng

 

[Weng Tianxiang]

On Tuesday, February 24, 2015 at 9:09:40 AM UTC-8, Weng Tianxiang wrote:

Hi Jim, glen, JK, rickman, Mike, Andy,

I have filed a provisional patent application: "Systematic method of coding wave pipelined circuits in HDL". If it is proved correct, the patent will introduce 1 keyword, 3 permanent constants, 1 concurrent statement and four source code modules for a new library in HDL and thoroughly resolve a pending problem so that every digital designer can code wave-pipelined circuits in HDL.

Here is the abstract of the invention:

The present invention classifies all critical paths into two basic types: a series critical path and a feedback critical path, and divides each of wave-pipelined circuits into two components: a static logic part, called critical path component (CPC), and a dynamic logic part, formalized into four wave-pipelining components (WPC) shared by all wave-pipelined circuits. Each wave-pipelining ready code in HDL comprises two components: a WPC instantiation and a CPC instantiation wire-connected and linked by a new link statement. Each WPC has new wave constants which play the same role as generic constants do, but whose initial values are determined and assigned by a synthesizer after code analysis, so designers can use after-synthesization information in their code before synthesization for wave-pipelining technology. The responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL is shifted from designers to synthesizers.

Anyone who are interested in its content is welcome to send a email request to the following email address: wtx wtx @ gmail . com with title "Systematic" and he will receive the full documents: one specification, 9 drawings and one text file in VHDL.

If one reviews the files and feels that it would be a good thing to recommend the application to his company to buy it, the first person to do it after his recommended company does so will receive $10,000 commission fee.

Thank you.

Weng

Hi,
I want to add some introductions to what the wave-pipelined circuits are and their status.

[0003] A synchronous digital system contains a lot of registers. Valid data flow through successive registers from system input registers to system output registers. All data flows are synchronous with triggering edges of a chip clock. For example, data flow from registers A to registers B, from registers B to registers C and so on in a successive order on the same clock cycle.
[0004] A path in a synchronous digital system is a route between any neighboring registers connected by combinational logic. If the target running frequency for a digital design is predetermined, the upper limit of propagating time for any paths is determined and has the inverse value of the target running frequency. A path is called a critical path if the time signals take to propagate through it is beyond the predetermined propagating time, and the time is called the path's critical time. If there are any critical paths, digital designers must spend time reducing all critical times by all means and eliminating all critical paths to meet the target running frequency.
[0005] Wave-pipelining is a technology which completes an operation that needs several clock cycles to propagate without intermediate registers and with input data acceptable on every clock cycle. For example, in a conventional pipelining operation, data flow from registers A to registers D through registers B and C to divide the critical path time into multiple smaller intervals to meet the critical time: A to B to C to D; with wave-pipelining, data flow through registers A and D without intermediate registers B and C. Absolutely, wave-pipelining will reduce logic resource usage and is superior to the conventional pipelining technology if it can be used.

Here are the most important inequalities involving wave-pipelining from paper "Wave-Pipelining: A Tutorial and Research Survey" by Wayne P. Burleson et al in IEEE Trans. Very Large Scale Integra. (VLSI) Syst., vol. 6, no. 3, pp. 464-474, Sep. 1998.

[0018] Currently many memory chip manufacturers successfully use wave-pipelining in their memory chip products with higher rate outputs, reduced power consumption and logic resources; and a few scientists use FPGA chips as a base to show some circuits can be done with wave-pipelining in isolated environments. Their works prove that the wave-pipelining is a very powerful tool to reduce power consumption and logic resources. Now there are two major existing obstacles preventing any ordinary digital designers from using the wave-pipelining in HDL:
* The software algorithms making wave-pipelining successful, like Wong and Klass algorithms and others, have already been developed and matured, but ordinary digital designers have no means or resources to access to the technology, because there are no international HDL standards on how synthesizer manufacturers incorporate those capabilities into their products.
* HDL needs the capabilities for digital designers to write wave-pipelining ready code for any number of critical paths on a design-wide or chip-wide scale instead of in an isolated environment and the written code can be identified, synthesized and used to generate wave-pipelined circuits by any synthesizer in ASIC or FPGA, and they should be part of HDL standards.
[0019] The target of the present invention is:
* Invent a wave-pipelining coding system as new part of HDL standards for designers to write wave-pipelining ready code which can be identified, synthesized and used to generate wave-pipelined circuits by any synthesizer in ASIC or FPGA.
* Make wave-pipelining ready code written based on the coding system working with no extra logic generated, compared with independently written wave-pipelined circuits, and with no code changes when switching from non-wave-pipelined mode to wave-pipelined mode or vice verse if all of wave-pipelining ready code meet wave-pipelining requirements.
* Shift burdens of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL from individual designers to synthesizer manufacturers.
[0020] If the coding system becomes new part of HDL standards all synthesizer manufactures will automatically be forced to implement all well-known wave-pipelining algorithms and techniques within their products, a competition will start for better implementations, making wave-pipelining technique available to every digital designer in HDL.

Weng

 

[KJ]

On Thursday, February 26, 2015 at 9:03:15 PM UTC-5, Weng Tianxiang wrote:

If the coding system becomes new part of HDL standards all
synthesizer manufactures will automatically be forced to implement all well-
known wave-pipelining algorithms and techniques within their products, a
competition will start for better implementations, making wave-pipelining
technique available to every digital designer in HDL.

A couple of problems with your assumptions:
- No standard body will accept a patent burdened idea to incorporate into a new revision of a standard. You would likely have to effectively surrender your patent rights (should they be granted in the first place) in order to get this to happen.
- If you think that simply being part of a standard will force synthesis vendors to do anything at all, you're very mistaken.
- Wave pipelining has not caught on with FPGA suppliers in the 45 years since the concept was first introduced nor in the 16 years since Burleson's paper was published so uptake on the technique has not been very quick. That doesn't imply that it will never catch on, but it does suggest the wait will be significant.

Kevin Jennings

 

[Weng Tianxiang]

On Friday, February 27, 2015 at 11:51:37 AM UTC-8, KJ wrote:

On Thursday, February 26, 2015 at 9:03:15 PM UTC-5, Weng Tianxiang wrote:
[0020] If the coding system becomes new part of HDL standards all
synthesizer manufactures will automatically be forced to implement all well-
known wave-pipelining algorithms and techniques within their products, a
competition will start for better implementations, making wave-pipelining
technique available to every digital designer in HDL.

A couple of problems with your assumptions:
- No standard body will accept a patent burdened idea to incorporate into a new revision of a standard. You would likely have to effectively surrender your patent rights (should they be granted in the first place) in order to get this to happen.

I don't have experience with it and will do some research on it.

> - If you think that simply being part of a standard will force synthesis vendors to do anything at all, you're very mistaken.

It's not my business. I invent something and let others do their part. As I often see Jim calling for help to do something with new standard implementations from manufacturers.

> - Wave pipelining has not caught on with FPGA suppliers in the 45 years since the concept was first introduced nor in the 16 years since Burleson's paper was published so uptake on the technique has not been very quick. That doesn't imply that it will never catch on, but it does suggest the wait will be significant.

You are right. In 2002 I published a paper "HDL code inefficient sourses and its solutions", introducing 5 keywords "orif, elsor, errels, machine and exclusive", and they are incorporated into Verilog-2008 and VHDL-2008/2009, according to Jim's comment, that takes 6 years to become standards.

Weng

Kevin Jennings

 

On Saturday, February 28, 2015 at 10:46:43 AM UTC+13, Weng Tianxiang wrote:

> You are right. In 2002 I published a paper "HDL code inefficient sourses and its solutions", introducing 5 keywords "orif, elsor, errels, machine and exclusive", and they are incorporated into Verilog-2008 and VHDL-2008/2009, according to Jim's comment, that takes 6 years to become standards.

None of those are reserved words in IEEE Std 1076-2008 (published in 2009).

See Issue Report 2012
http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Forward the submitter's request to the VHDL-200x Modeling and
Productivity group for consideration.

You'd be hard pressed to find any record that a 'VHDL-200x Modeling and
Productivity group' considered your issue. This would have been under the auspices of Accellera's VHDL activities and all those records are not available today.

There is a Unique Condition proposal encompassing IR2012:
http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition

It doesn't appear to be currently gaining a lot of traction.

Searching IEEE std 1800-2012 (SystemVerilog) shows they aren't keywords there either. (Note there is unique and unique0). (See Annex B Keywords)

 

[Weng Tianxiang]

On Sunday, March 1, 2015 at 4:22:50 PM UTC-8, diog...@gmail.com wrote:

On Saturday, February 28, 2015 at 10:46:43 AM UTC+13, Weng Tianxiang wrote:

You are right. In 2002 I published a paper "HDL code inefficient sourses and its solutions", introducing 5 keywords "orif, elsor, errels, machine and exclusive", and they are incorporated into Verilog-2008 and VHDL-2008/2009, according to Jim's comment, that takes 6 years to become standards.

None of those are reserved words in IEEE Std 1076-2008 (published in 2009).

See Issue Report 2012
http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Forward the submitter's request to the VHDL-200x Modeling and
Productivity group for consideration.

You'd be hard pressed to find any record that a 'VHDL-200x Modeling and
Productivity group' considered your issue. This would have been under the auspices of Accellera's VHDL activities and all those records are not available today.

There is a Unique Condition proposal encompassing IR2012:
http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition

It doesn't appear to be currently gaining a lot of traction.

Searching IEEE std 1800-2012 (SystemVerilog) shows they aren't keywords there either. (Note there is unique and unique0). (See Annex B Keywords)

Thank you for your valuable comment.

Jim, the current chairman of VHDL committee, told me the information.

I will response to you comment a few days later and hope to make some contributions to SystemVerilog-2012.

Weng

 

[Weng Tianxiang]

On Sunday, March 1, 2015 at 9:11:36 PM UTC-8, Weng Tianxiang wrote:

On Sunday, March 1, 2015 at 4:22:50 PM UTC-8, diog...@gmail.com wrote:
On Saturday, February 28, 2015 at 10:46:43 AM UTC+13, Weng Tianxiang wrote:

You are right. In 2002 I published a paper "HDL code inefficient sourses and its solutions", introducing 5 keywords "orif, elsor, errels, machine and exclusive", and they are incorporated into Verilog-2008 and VHDL-2008/2009, according to Jim's comment, that takes 6 years to become standards.

None of those are reserved words in IEEE Std 1076-2008 (published in 2009).

See Issue Report 2012
http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Forward the submitter's request to the VHDL-200x Modeling and
Productivity group for consideration.

You'd be hard pressed to find any record that a 'VHDL-200x Modeling and
Productivity group' considered your issue. This would have been under the auspices of Accellera's VHDL activities and all those records are not available today.

There is a Unique Condition proposal encompassing IR2012:
http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition

It doesn't appear to be currently gaining a lot of traction.

Searching IEEE std 1800-2012 (SystemVerilog) shows they aren't keywords there either. (Note there is unique and unique0). (See Annex B Keywords)

Thank you for your valuable comment.

Jim, the current chairman of VHDL committee, told me the information.

I will response to you comment a few days later and hope to make some contributions to SystemVerilog-2012.

Weng

Thank you very much for your comment.

0. I don't have any written versions of Verilog-2008 or VHDL-2008/2009.

The information I listed in my comment was based on Jim Lewis's comment, the chairman of current VHDL committee.
His comment happened in about 2010 and I cannot find it again now. But you may see the following comments:
https://groups.google.com/forum/#!topic/comp.lang.vhdl/V1ZeRkQ-El4


1. "This would have been under the auspices of Accellera's VHDL activities and all those records are not available today.?

You are right. Jim Lewis is the current chairman of Accellera's VHDL and the first man mentioned reserved word "errels".

2. "None of those are reserved words in IEEE Std 1076-2008 (published in 2009)."

It must be the situation that those reserved words mentioned in my paper were incorporated into IEEE Std 1076-2008 (published in 2009) using different names. I was not contacted in their incorporation activities. Jim Lewis will clear that later.

3. "See Issue Report 2012 http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt"

This request was made by me in 2001. It doesn't mean anything now, because it occurred in 2002 and we are talking about Verilog-2008 and VHDL-2008/2009.

4. In http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition

Current Situation section clearly describes the situation and what the target is, but the application range is narrowed unintentionally:
"In those above 3 situations, a superfluous condition is posed on the equation; it means a priority tree is implied in all three situations. Actually most of time when dealing with main data flow, all above conditions are mutually exclusive, so there is no need to pose the extra conditions on the final equation."

The above situation occurs not only in main data flow, but also occurs when dealing with logic flow in a non-clocked state machine process.

5. There are two errors in section of Implementation:
"The proposed solution is to introduce a new keyword 'elsor', which implies that the conditions are mutually exclusive. The keyword would have to be used throughout the statement, and imply that all the conditions are mutually exclusive. The question of checking whether none of the conditions have been met can be handled by an assertion.?

5.1. New keyword "elsor" can be nested, and has not to be used throughout the statement.

In page 169 of The 11th Annual International HDL Conference, the paper "HDL Code Inefficiency Sources and its Solutions" describes:
"To make HDL code efficient, we should have a way to let HDL compilers know if there are any partially or totally mutually exclusive conditions contained in "if...elsif...else" statement.

The solution is to include two new keywords"orif" and "elsor" in the next HDL version. "orif" is used in sequential environments and "elsor" in concurrent environments.

Proposal 1: In sequential situations, any "elsif" keyword in "if...elsif...else" statement may be replaced by new keyword "orif", specifying that conditions at any contiguous block of "orif(...)" lines and the condition at "if(...)" or "elsif(...) line that is located above the contiguous block of "orif(...)" lines are mutually exclusive.

And a new keyword "errels" can be added after last "orif(...)" line of any contiguous "orif(...)" blocks to specify what action should be taken when violations of expecting mutually exclusive conditions occur during simulation. All other rules appled to "if...elsif...else" don't change.

Example:
A : process(clk, nreset)
begin
if nreset = '0' then
Outbus <= (others=>'0');

elsif clk'event and clk = '1' then
if C1 then -- C1 and C2 are mutually exclusive
Outbus <= Bus1;
orif C2 then
Outbus <= Bus2;
errels -- if both C1 and C2 are true, an error occurs
Outbus <= Outbus ;
assert false
report "1: mutually exclusive is violated"
severity note;

elsif C3 then -- C3 and C4 are mutually exclusive
Outbus <= Bus3;
orif C4 then
Outbus <= Bus4;
errels -- if both C3 and C4 are true, an error occurs
Outbus <= Outbus ;
assert false
report "2: mutually exclusive is violated"
severity note;

else
Outbus <= (others=>'0');
end if;
end if;
end process;

The above equation tells that (C1 and C2), (C3 and C4) are mutually exclusive. The following equation in AHDL is expected:

Outbus <= (C1 * Bus1 + C2 * Bus2) + !(C1 + C2) (C3 * Bus3 + C4 * Bus4);

The new keyword "orif" is to emphasize that "or" operations are involved to save logic.

Statements following "errels" are skipped in synthesis, but are involved in simulation.

5.2 揟he question of checking whether none of the conditions have been met can be handled by an assertion.?

I don抰 know SystemVerilog, but the above question can be handled without any additional rules and it can be handled as an usual 搃f卐lsif卐lse?does.

If one contiguous block of "orif" and its above "if(...)" or "elsif(...)" is treated as one if-level in a "if...elsif...else" statement, nothing should have changed. Please see following examples.

5.3. In the above conetext "The 'unique' keyword implies an error if none of the conditions is met and there is no 'else', whereas the 'unique0' keyword does not imply this additional check."

When no conditions are true in the mutually exclusive group, the situation is treated in the same way as how a usual "if...elsif...else" is treated, but when more than one condition in a mutually exclusive group of conditions is true, an error occurs, that can be detected using "elserr".

OneHot0(...) really has the bad effects as the recommendation indicated.

6. Here I give a very useful example showing how the new keyword "orif" is used and how it would save logic in my unpublished code:

If an idle state in a state machine State_2 is monitoring a data bus to see if the command target address appeared in the bus falls into a designated address space, the code would be:

case State_2 is
when Idle_s =>
if Address = Area1 then
State_2_NS <= S1;

elsif Address = Area2 then
State_2_NS <= S2;

elsif Address = Area3 then
State_2_NS <= S3;

elsif Address = Area4 then
State_2_NS <= S4;

elsif Address = Area5 then
State_2_NS <= S5;

else
State_2_NS <= Idle_s;
end if;
end if;
...

No experienced designers would write the above dumb code. Because each of area addresses can be written as a 32-bits address or so and rewrite the equation to make them do no more logic comparison than needed.

case State_2 is
when Idle_s =>
if Address_H8 = Common_address_H8 then
case Address_L24 is
when Address_L24_1 =>
State_2_NS <= S1;

when Address_L24_2 =>
State_2_NS <= S2;

when Address_L24_3 =>
State_2_NS <= S3;

when Address_L24_4 =>
State_2_NS <= S4;

when Address_L24_5 =>
State_2_NS <= S5;

when others =>
State_2_NS <= Idle_s;
end case;
end if;
...

Now my problem comes here due to the jump conditions which are mutually exclusive and cannot be divided as above example shows.

In one state machine State_1 it generates 7 situations which are generated in one if-statement and mutually exclusive and very complex.
In another state machine State_2 it is waiting in idle state to monitor the progress of State_1 and acts when one of 7 situations occurs.
The situations are very common in complex designs.

case State_2 is
when Idle_S =>
If situation_1 then
State_2_NS <= S2_1;

elsif situation_2 then
State_2_NS <= S2_2;

elsif situation_3 then
State_2_NS <= S2_3;

elsif situation_4 then
State_2_NS <= S2_4;

elsif situation_5 then
State_2_NS <= S2_5;

elsif situation_6 then
State_2_NS <= S2_6;

elsif situation_7 then
State_2_NS <= S2_7;

else
State_2_NS <= Idle_S;
end if;

The above code is unacceptable because all situation_x are mutually exclusively generated in one if-statement in State_1 state machine.

What I can do now in State_1 is as follows:

code <= "000"; -- no action
if A1 then
code<= "001"; -- situation_1

else A2 then -- situation_2
code<= "010";

elsif A3 then
if A4 then -- situation_3
code<= "011";
else A5 then -- situation_4
code<= "101";
...

In State_2 I have to use a case statement to simplify the situations as following code shows:

case State_2 is
when Idle_s =>
case code is
when "001" => ...; -- situation_1

when "010" => ...; -- situation_2

when "011" => ...; -- situation_3

when others =>Idle_s;-- no action

If new keyword "orif" is introduced as my specification tells, the new code in State_1 would be:

situation_1 <= '0"; -- situation_1
situation_2 <= '0"; -- situation_2
situation_3 <= '0"; -- situation_3
situation_4 <= '0"; -- situation_4
situation_5 <= '0"; -- situation_5
situation_6 <= '0"; -- situation_6
situation_7 <= '0"; -- situation_7

if A1 then
situation_1 <= '1"; -- situation_1

else A2 then
situation_2 <= '1"; -- situation_2

elsif A3 then
if A4 then
situation_3 <= '1"; -- situation_3
else A5 then
situation_4 <= '1"; -- situation_4
...

the code in State_2 would be:

case State_2 is
when Idle_s =>
if situatino_1 = '1' then
State_2_NS <= S1; -- situation_1

orif situatino_2 = '1' then
State_2_NS <= S2; -- situation_2

orif situatino_3 = '1' then
State_2_NS <= S3; -- situation_3

orif situatino_4 = '1' then
State_2_NS <= S4; -- situation_4

orif situatino_5 = '1' then
State_2_NS <= S5; -- situation_5

orif situatino_6 = '1' then
State_2_NS <= S6; -- situation_6

orif situatino_7 = '1' then
State_2_NS <= S7; -- situation_7

errels -- if more than one wire is asserted
State_2_NS <= Idle_s; -- keep State_2 unchanged
assert false
report "Violation of mutually exclusiveness occurs"
severity failure;

-- that is what should be done if no condition is true in a contiguous block of "orif"
else
State_2_NS <= Idle_s; -- keep State_2 unchanged
end if;
...


Weng

 

[KJ]

On Monday, March 2, 2015 at 2:49:26 PM UTC-5, Weng Tianxiang wrote:
> On Sunday, March 1, 2015 at 9:11:36 PM UTC-8, Weng Tianxiang wrote:

It looks like you submitted this back in 2001 but the suggestion was not recommended for a change to VHDL-2002 (http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt).

It did not make the cut in VHDL-2008 either.

Along with any other open proposals, it has been ported over to the current working group for consideration (http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition). That working group has been together for just about 3 years, it's not clear if there is any particular target date that they are working toward.

Kevin

 

[Weng Tianxiang]

On Monday, March 2, 2015 at 12:17:52 PM UTC-8, KJ wrote:

On Monday, March 2, 2015 at 2:49:26 PM UTC-5, Weng Tianxiang wrote:
On Sunday, March 1, 2015 at 9:11:36 PM UTC-8, Weng Tianxiang wrote:

It looks like you submitted this back in 2001 but the suggestion was not recommended for a change to VHDL-2002 (http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt).

You are right.

It did not make the cut in VHDL-2008 either.

No, it did make the cut in Verilog-2008 for both groups of new keywords and in VHDL-2008/2009 for either.

Jim Lewis provided me with the info in 2010 or 2011, but I couldn't find his record. I will try again.

Along with any other open proposals, it has been ported over to the current working group for consideration (http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition). That working group has been together for just about 3 years, it's not clear if there is any particular target date that they are working toward.

You are right. I am very thankful for this SystemVerilog-1012 group. I will try to publish a paper that will definitely confirm using schematics diagrams that "orif" saves logic in such a dramatic way as I claimed.

Kevin

Hi KJ,
Thank you for your comment.

Weng

 

[Weng Tianxiang]

On Thursday, February 26, 2015 at 6:03:15 PM UTC-8, Weng Tianxiang wrote:

On Tuesday, February 24, 2015 at 9:09:40 AM UTC-8, Weng Tianxiang wrote:
Hi Jim, glen, JK, rickman, Mike, Andy,

I have filed a provisional patent application: "Systematic method of coding wave pipelined circuits in HDL". If it is proved correct, the patent will introduce 1 keyword, 3 permanent constants, 1 concurrent statement and four source code modules for a new library in HDL and thoroughly resolve a pending problem so that every digital designer can code wave-pipelined circuits in HDL.

Here is the abstract of the invention:

The present invention classifies all critical paths into two basic types: a series critical path and a feedback critical path, and divides each of wave-pipelined circuits into two components: a static logic part, called critical path component (CPC), and a dynamic logic part, formalized into four wave-pipelining components (WPC) shared by all wave-pipelined circuits. Each wave-pipelining ready code in HDL comprises two components: a WPC instantiation and a CPC instantiation wire-connected and linked by a new link statement. Each WPC has new wave constants which play the same role as generic constants do, but whose initial values are determined and assigned by a synthesizer after code analysis, so designers can use after-synthesization information in their code before synthesization for wave-pipelining technology. The responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL is shifted from designers to synthesizers.

Anyone who are interested in its content is welcome to send a email request to the following email address: wtx wtx @ gmail . com with title "Systematic" and he will receive the full documents: one specification, 9 drawings and one text file in VHDL.

If one reviews the files and feels that it would be a good thing to recommend the application to his company to buy it, the first person to do it after his recommended company does so will receive $10,000 commission fee.

Thank you.

Weng

Hi,
I want to add some introductions to what the wave-pipelined circuits are and their status.

[0003] A synchronous digital system contains a lot of registers. Valid data flow through successive registers from system input registers to system output registers. All data flows are synchronous with triggering edges of a chip clock. For example, data flow from registers A to registers B, from registers B to registers C and so on in a successive order on the same clock cycle.
[0004] A path in a synchronous digital system is a route between any neighboring registers connected by combinational logic. If the target running frequency for a digital design is predetermined, the upper limit of propagating time for any paths is determined and has the inverse value of the target running frequency. A path is called a critical path if the time signals take to propagate through it is beyond the predetermined propagating time, and the time is called the path's critical time. If there are any critical paths, digital designers must spend time reducing all critical times by all means and eliminating all critical paths to meet the target running frequency.
[0005] Wave-pipelining is a technology which completes an operation that needs several clock cycles to propagate without intermediate registers and with input data acceptable on every clock cycle. For example, in a conventional pipelining operation, data flow from registers A to registers D through registers B and C to divide the critical path time into multiple smaller intervals to meet the critical time: A to B to C to D; with wave-pipelining, data flow through registers A and D without intermediate registers B and C. Absolutely, wave-pipelining will reduce logic resource usage and is superior to the conventional pipelining technology if it can be used.

Here are the most important inequalities involving wave-pipelining from paper "Wave-Pipelining: A Tutorial and Research Survey" by Wayne P. Burleson et al in IEEE Trans. Very Large Scale Integra. (VLSI) Syst., vol. 6, no. 3, pp. 464-474, Sep. 1998.

[0018] Currently many memory chip manufacturers successfully use wave-pipelining in their memory chip products with higher rate outputs, reduced power consumption and logic resources; and a few scientists use FPGA chips as a base to show some circuits can be done with wave-pipelining in isolated environments. Their works prove that the wave-pipelining is a very powerful tool to reduce power consumption and logic resources. Now there are two major existing obstacles preventing any ordinary digital designers from using the wave-pipelining in HDL:
* The software algorithms making wave-pipelining successful, like Wong and Klass algorithms and others, have already been developed and matured, but ordinary digital designers have no means or resources to access to the technology, because there are no international HDL standards on how synthesizer manufacturers incorporate those capabilities into their products.
* HDL needs the capabilities for digital designers to write wave-pipelining ready code for any number of critical paths on a design-wide or chip-wide scale instead of in an isolated environment and the written code can be identified, synthesized and used to generate wave-pipelined circuits by any synthesizer in ASIC or FPGA, and they should be part of HDL standards.
[0019] The target of the present invention is:
* Invent a wave-pipelining coding system as new part of HDL standards for designers to write wave-pipelining ready code which can be identified, synthesized and used to generate wave-pipelined circuits by any synthesizer in ASIC or FPGA.
* Make wave-pipelining ready code written based on the coding system working with no extra logic generated, compared with independently written wave-pipelined circuits, and with no code changes when switching from non-wave-pipelined mode to wave-pipelined mode or vice verse if all of wave-pipelining ready code meet wave-pipelining requirements.
* Shift burdens of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL from individual designers to synthesizer manufacturers..
[0020] If the coding system becomes new part of HDL standards all synthesizer manufactures will automatically be forced to implement all well-known wave-pipelining algorithms and techniques within their products, a competition will start for better implementations, making wave-pipelining technique available to every digital designer in HDL.

Weng

Here I add some contents of the invention:

Main idea behind the present invention

[0057] The most difficult part coding all types of wave-pipelined circuits on a design-wide scale in HDL is that a wave-pipelined circuit code always comprises two logic parts:
* A static logic part: it doesn't change if the number of series clock cycles through the circuit changes and is unique for each of wave-pipelined circuits.
* A dynamic logic part: it does change if the number of series clock cycles through the circuit changes and is the same for one of groups of wave-pipelined circuits.
[0058] Every wave-pipelined circuit has its own change rules and those changes are unknown to designers when they are writing code and will be known to a synthesizer only after it has analyzed the circuit.
[0059] The present invention classifies all critical paths into two basic types: a series critical path and a feedback critical path, and divides each of wave-pipelined circuits into two components: one is static logic part and called critical path component (CPC); another is dynamic logic part and formalized into four wave-pipelining components (WPC) shared by all wave-pipelined circuits. Under the present invention each of standard wave-pipelining ready code in HDL comprises two components: a WPC instantiation and a CPC instantiation which are wire-connected and linked by a new concurrent link statement. Each of four WPC embodiments has a group of new type wave constant, which plays the same role as a generic constant does, but whose initial value is determined and assigned by a synthesizer after it has analyzed the linked CPC component under slow mode and target mode, respectively, so designers can use after-synthesization information in their code before synthesization in HDL for wave-pipelining technology. Following the instructions of the present invention creates a situation that digital designers can write wave-pipelining ready code in HDL and the responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL is shifted from individual designers to synthesizer manufacturers.

How the method works

[0060] The systematic method of coding wave-pipelined circuits in HDL comprises following ten parts:
1. Define five signals, one counter, one switch and one table that will be used when generating wave-pipelined circuits on a design-wide or chip-wide scale in HDL.
2. Define the interfaces of a CPC each of which encapsulates a critical path's static logic part.
3. Define and implement four WPC embodiments in HDL each of which is a critical path's dynamic logic part: a series_module, an input_delay_module, a multiple_copy_module1 and a multiple_copy_module2.
4. Define one new keyword wave and three new wave constants which provide a means to dynamically transfer after-synthesization information to designers' code before synthesization.
5. Define the methods of determining and searching for wave constant values of a known WPC instantiation under slow mode and target mode, respectively..
6. Define three versions of a concurrent link statement: link1, link2 and link3, and rules on how they are used.
7. Define the pairing rules between a WPC and a CPC.
8. Define how a digital designer prepares wave-pipelining ready code systematically.
9. Shift the responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL from individual designers to synthesizer manufacturers.
10. Define how four WPC embodiments are simulated and debugged under any of current versions of a synthesizer in HDL.
[0061] It is fair to put the burden of successfully generating wave-pipelined circuits based on wave-pipelining ready code squarely on synthesizer manufacturers' shoulder if all necessary information is passed to a synthesizer. For example, with tens of papers claiming that successful wave-pipelined circuits are implemented in FPGA chips in an isolated environment, it is the responsibility of FPGA synthesizers to be capable of generating those wave-pipelined circuits in a design-wide environment without designers' further involvements, a process similar for them to the task of generating a circuit with the highest running frequency and minimum used resources if possible for any normal digital design code.

Thank you for your reading.

 

[hssig]

Aaah, the "VHDL hater" is back ;-)

 

[Weng Tianxiang]

On Tuesday, March 3, 2015 at 11:47:41 PM UTC-8, hssig wrote:
> Aaah, the "VHDL hater" is back ;-)

Hi HSSIG,

Ha, Ha, Ha, Ha, you have a really good memory!!! The story happened 13 years ago!!!

You must have attended the 11th International HDL conference held in Double Tree hotel, San Jose，CA，in March, 2002, and listened to my presentation!

When I was doing my presentation, a big laugh was burst when I said "I hate VHDL, because it lacks the data grammar structure which can nicely handle the mutually exclusive cases."

During the period I met great pressure to increase the running frequency for a 66MHz PCI DMA board. How could I do it to increase the running frequency to meet 66MHz requirement in VHDL from 23 MHz running frequency achieved from an Altera chip? I hoped to get experts' help, but none touched and answered my question. Finally I successfully finished the job and my design got 480 MByte/s on a maximum 528 MByte/s 66MHz PCI bus achieved through a Xilinx chip.

Thank you for giving me the nickname "VHDL hater."

After my distributions of my paper in this and FPGA group, I received more than 150 paper requests to get the article within 3 month period.

Now I gladly know that even SystemVerilog, a HDL language Intel uses, lacks the function, even SystemVerilog-2012 "doesn't appear to be currently gaining a lot of traction."

“One person's medicine, another one's fortune."

Now it give me a chance to make a fortune to publish another group of invention-patents which had been finished at least 4 years ago and would schematically and definitely show that new keyword "orif" and its data structure really saves logic and it is really indispensable，essential, necessary, all-important, of the utmost importance, of the essence, vital, must-have, crucial, key, needed, required, requisite, imperative and invaluable.

Thank you for your comment.

Weng

 

On Tuesday, February 24, 2015 at 12:09:40 PM UTC-5, Weng Tianxiang wrote:

Hi Jim, glen, JK, rickman, Mike, Andy,

I have filed a provisional patent application: "Systematic method of coding wave pipelined circuits in HDL". If it is proved correct, the patent will introduce 1 keyword, 3 permanent constants, 1 concurrent statement and four source code modules for a new library in HDL and thoroughly resolve a pending problem so that every digital designer can code wave-pipelined circuits in HDL.

Here is the abstract of the invention:

The present invention classifies all critical paths into two basic types: a series critical path and a feedback critical path, and divides each of wave-pipelined circuits into two components: a static logic part, called critical path component (CPC), and a dynamic logic part, formalized into four wave-pipelining components (WPC) shared by all wave-pipelined circuits. Each wave-pipelining ready code in HDL comprises two components: a WPC instantiation and a CPC instantiation wire-connected and linked by a new link statement. Each WPC has new wave constants which play the same role as generic constants do, but whose initial values are determined and assigned by a synthesizer after code analysis, so designers can use after-synthesization information in their code before synthesization for wave-pipelining technology. The responsibility of analyzing and manipulating wave-pipelining ready code, generating and implementing wave-pipelined circuits on a design-wide or chip-wide scale in HDL is shifted from designers to synthesizers.

Anyone who are interested in its content is welcome to send a email request to the following email address: wtx wtx @ gmail . com with title "Systematic" and he will receive the full documents: one specification, 9 drawings and one text file in VHDL.

If one reviews the files and feels that it would be a good thing to recommend the application to his company to buy it, the first person to do it after his recommended company does so will receive $10,000 commission fee.

Thank you.

Weng

Want to learn more in engineering? If you are interested in learning
VHDL programming and FPGA development take my course today! This coupon
is good till April 6th, 2015 for $60 - 40% off the cost of the class at
regular price! Join now!
https://www.udemy.com/vhdl-and-fpga-development-for-beginners-and-intermediates/?couponCode=March60#/

 

[KJ]

On Wednesday, March 4, 2015 at 10:06:05 AM UTC-5, Weng Tianxiang wrote:

On Tuesday, March 3, 2015 at 11:47:41 PM UTC-8, hssig wrote:

Now it give me a chance to make a fortune to publish another group of
invention-patents which had been finished at least 4 years ago and would
schematically and definitely show that new keyword "orif" and its data
structure really saves logic and it is really indispensable，essential,
necessary, all-important, of the utmost importance, of the essence, vital,
must-have, crucial, key, needed, required, requisite, imperative and
invaluable.

You might want to save some of those superlatives for a different invention, they do not apply to 'orif'.

Back when you first proposed it, you used the keyword 'elsor' [1] which is also how it is currently reflected in the proposal presented on the 1076 TWIKI page [2]. However, the real problem is that if the control signals really are mutually exclusive, all of the different forms that you presented will produce exactly the same result today. In your proposal, you presented three different alternative forms (if/elsif...endif; sequential if/endif and concurrent 'when/else') and you declared but presented no actual evidence that these three will have 'superfluous condition is posed on the equation' and that a 'priority tree' will be created which will in turn create extra logic over the preferred form of a simple 'and/or' structure. You're mistaken. All three of the alternatives will produce the exact same logic as the preferred 'and/or' form. [3].

In order for their to be any actual utility to 'orif', you would first have to come up with a scenario where the input control signals a, b, c, d, e truly are mutually exclusive but the synthesis tool generates different results. One possible approach would be to say that a-e are top level inputs to the design and that those inputs are supposed to come from the output of a decoder so therefore they are mutually exclusive. Besides limiting 'orif' to only be applicable to the scenario where the controls come only from device input pins, this ignores the real world possibility that those input pins have been shorted together so a-e are not absolutely guaranteed to be mutually exclusive.

But I'll leave it to you to:
- Come up with the scenario where a-e are provably mutually exclusive but a real synthesis tool produces different results for the four approaches that you have defined and I have implemented in [3].
- Show how that scenario is of actual widespread benefit to anyone

Kevin Jennings

1. http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt
2. http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition
3. Using brand 'Q' synthesis tool, and the code below, you will get exactly the same result no matter what value you set the generic 'Method'.
======= START OF CODE ======library ieee;
use ieee.std_logic_1164.all;

entity Orif_Example is
generic(Method: in natural range 0 to 3);
port(
Address: in natural range 0 to 5;
Abus: in std_ulogic;
Bbus: in std_ulogic;
Cbus: in std_ulogic;
Dbus: in std_ulogic;
Ebus: in std_ulogic;
Outbus: out std_ulogic
);
end Orif_Example;

architecture RTL of Orif_Example is
signal a: std_ulogic;
signal b: std_ulogic;
signal c: std_ulogic;
signal d: std_ulogic;
signal e: std_ulogic;
begin
a <= '1' when (Address = 1) else '0';
b <= '1' when (Address = 2) else '0';
c <= '1' when (Address = 3) else '0';
d <= '1' when (Address = 4) else '0';
e <= '1' when (Address = 5) else '0';

GEN_METHOD_0 : if (Method = 0) generate
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);
end generate GEN_METHOD_0;

GEN_METHOD_1 : if (Method = 1) generate
-- One statement structure in serial mode:
process(all)
begin
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;
end process;
end generate GEN_METHOD_1;

GEN_METHOD_2 : if (Method = 2) generate
-- or in another equal form:
process(all)
begin
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;
end process;

end generate GEN_METHOD_2;

GEN_METHOD_3 : if (Method = 3) generate
-- In concurrent mode:
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';
end generate GEN_METHOD_3;
end RTL;
======= END OF CODE =======

 

[Weng Tianxiang]

On Wednesday, March 4, 2015 at 8:05:16 PM UTC-8, KJ wrote:

On Wednesday, March 4, 2015 at 10:06:05 AM UTC-5, Weng Tianxiang wrote:
On Tuesday, March 3, 2015 at 11:47:41 PM UTC-8, hssig wrote:

Now it give me a chance to make a fortune to publish another group of
invention-patents which had been finished at least 4 years ago and would
schematically and definitely show that new keyword "orif" and its data
structure really saves logic and it is really indispensable，essential,
necessary, all-important, of the utmost importance, of the essence, vital,
must-have, crucial, key, needed, required, requisite, imperative and
invaluable.


You might want to save some of those superlatives for a different invention, they do not apply to 'orif'.

Back when you first proposed it, you used the keyword 'elsor' [1] which is also how it is currently reflected in the proposal presented on the 1076 TWIKI page [2]. However, the real problem is that if the control signals really are mutually exclusive, all of the different forms that you presented will produce exactly the same result today. In your proposal, you presented three different alternative forms (if/elsif...endif; sequential if/endif and concurrent 'when/else') and you declared but presented no actual evidence that these three will have 'superfluous condition is posed on the equation' and that a 'priority tree' will be created which will in turn create extra logic over the preferred form of a simple 'and/or' structure. You're mistaken. All three of the alternatives will produce the exact same logic as the preferred 'and/or' form. [3].

In order for their to be any actual utility to 'orif', you would first have to come up with a scenario where the input control signals a, b, c, d, e truly are mutually exclusive but the synthesis tool generates different results. One possible approach would be to say that a-e are top level inputs to the design and that those inputs are supposed to come from the output of a decoder so therefore they are mutually exclusive. Besides limiting 'orif' to only be applicable to the scenario where the controls come only from device input pins, this ignores the real world possibility that those input pins have been shorted together so a-e are not absolutely guaranteed to be mutually exclusive.

But I'll leave it to you to:
- Come up with the scenario where a-e are provably mutually exclusive but a real synthesis tool produces different results for the four approaches that you have defined and I have implemented in [3].
- Show how that scenario is of actual widespread benefit to anyone

Kevin Jennings

1. http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt
2. http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition
3. Using brand 'Q' synthesis tool, and the code below, you will get exactly the same result no matter what value you set the generic 'Method'.
======= START OF CODE ======> library ieee;
use ieee.std_logic_1164.all;

entity Orif_Example is
generic(Method: in natural range 0 to 3);
port(
Address: in natural range 0 to 5;
Abus: in std_ulogic;
Bbus: in std_ulogic;
Cbus: in std_ulogic;
Dbus: in std_ulogic;
Ebus: in std_ulogic;
Outbus: out std_ulogic
);
end Orif_Example;

architecture RTL of Orif_Example is
signal a: std_ulogic;
signal b: std_ulogic;
signal c: std_ulogic;
signal d: std_ulogic;
signal e: std_ulogic;
begin
a <= '1' when (Address = 1) else '0';
b <= '1' when (Address = 2) else '0';
c <= '1' when (Address = 3) else '0';
d <= '1' when (Address = 4) else '0';
e <= '1' when (Address = 5) else '0';

GEN_METHOD_0 : if (Method = 0) generate
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);
end generate GEN_METHOD_0;

GEN_METHOD_1 : if (Method = 1) generate
-- One statement structure in serial mode:
process(all)
begin
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;
end process;
end generate GEN_METHOD_1;

GEN_METHOD_2 : if (Method = 2) generate
-- or in another equal form:
process(all)
begin
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;
end process;

end generate GEN_METHOD_2;

GEN_METHOD_3 : if (Method = 3) generate
-- In concurrent mode:
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';
end generate GEN_METHOD_3;
end RTL;
======= END OF CODE ======

Hi KJ,
Thank you for taking time to discuss the keyword "orif".

I don't have to generate other example and just use your example with following changes: Generate a, b, c, d, e in two different state machines with the two state machines being mutually exclusive, so that a-e are mutually exclusive.

The two state machine may be a read state machine and a write state machine of a bus. And a-e are used to drive the 2nd bus.

Now please generate your code to see how a compiler knows if a-e are mutually exclusive. The generated code must be different!!!

What your example provides is the simplest one and a compiler can do it very easily!!!

Nature and coding in complex situations are more complex than your example provides.

1. You must acknowledge that there are situations that only the code writer knows which conditions are mutually exclusive.

http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition#Arguments_FOR

Current Situation
Consider a basic equation in hardware design:
-- no priority tree is implied
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);

One statement structure in serial mode: -- a priority tree is implied
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;

or in another equal form: -- a priority tree is implied
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;

In concurrent mode: -- a priority tree is implied
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';

In those above 3 situations, a superfluous condition is posed on the equation, it means a priority tree is implied in all three situations. Actually most of time when dealing with main data flow, all above conditions are mutually exclusive, so there is no need to pose the extra conditions on the final equation.

Weng

 

[Weng Tianxiang]

On Wednesday, March 4, 2015 at 9:59:17 PM UTC-8, Weng Tianxiang wrote:

On Wednesday, March 4, 2015 at 8:05:16 PM UTC-8, KJ wrote:
On Wednesday, March 4, 2015 at 10:06:05 AM UTC-5, Weng Tianxiang wrote:
On Tuesday, March 3, 2015 at 11:47:41 PM UTC-8, hssig wrote:

Now it give me a chance to make a fortune to publish another group of
invention-patents which had been finished at least 4 years ago and would
schematically and definitely show that new keyword "orif" and its data
structure really saves logic and it is really indispensable，essential,
necessary, all-important, of the utmost importance, of the essence, vital,
must-have, crucial, key, needed, required, requisite, imperative and
invaluable.


You might want to save some of those superlatives for a different invention, they do not apply to 'orif'.

Back when you first proposed it, you used the keyword 'elsor' [1] which is also how it is currently reflected in the proposal presented on the 1076 TWIKI page [2]. However, the real problem is that if the control signals really are mutually exclusive, all of the different forms that you presented will produce exactly the same result today. In your proposal, you presented three different alternative forms (if/elsif...endif; sequential if/endif and concurrent 'when/else') and you declared but presented no actual evidence that these three will have 'superfluous condition is posed on the equation' and that a 'priority tree' will be created which will in turn create extra logic over the preferred form of a simple 'and/or' structure. You're mistaken. All three of the alternatives will produce the exact same logic as the preferred 'and/or' form. [3].

In order for their to be any actual utility to 'orif', you would first have to come up with a scenario where the input control signals a, b, c, d, e truly are mutually exclusive but the synthesis tool generates different results. One possible approach would be to say that a-e are top level inputs to the design and that those inputs are supposed to come from the output of a decoder so therefore they are mutually exclusive. Besides limiting 'orif' to only be applicable to the scenario where the controls come only from device input pins, this ignores the real world possibility that those input pins have been shorted together so a-e are not absolutely guaranteed to be mutually exclusive.

But I'll leave it to you to:
- Come up with the scenario where a-e are provably mutually exclusive but a real synthesis tool produces different results for the four approaches that you have defined and I have implemented in [3].
- Show how that scenario is of actual widespread benefit to anyone

Kevin Jennings

1. http://www.eda.org/isac/IRs-VHDL-2002/IR2012.txt
2. http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition
3. Using brand 'Q' synthesis tool, and the code below, you will get exactly the same result no matter what value you set the generic 'Method'.
======= START OF CODE ======> > library ieee;
use ieee.std_logic_1164.all;

entity Orif_Example is
generic(Method: in natural range 0 to 3);
port(
Address: in natural range 0 to 5;
Abus: in std_ulogic;
Bbus: in std_ulogic;
Cbus: in std_ulogic;
Dbus: in std_ulogic;
Ebus: in std_ulogic;
Outbus: out std_ulogic
);
end Orif_Example;

architecture RTL of Orif_Example is
signal a: std_ulogic;
signal b: std_ulogic;
signal c: std_ulogic;
signal d: std_ulogic;
signal e: std_ulogic;
begin
a <= '1' when (Address = 1) else '0';
b <= '1' when (Address = 2) else '0';
c <= '1' when (Address = 3) else '0';
d <= '1' when (Address = 4) else '0';
e <= '1' when (Address = 5) else '0';

GEN_METHOD_0 : if (Method = 0) generate
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);
end generate GEN_METHOD_0;

GEN_METHOD_1 : if (Method = 1) generate
-- One statement structure in serial mode:
process(all)
begin
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;
end process;
end generate GEN_METHOD_1;

GEN_METHOD_2 : if (Method = 2) generate
-- or in another equal form:
process(all)
begin
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;
end process;

end generate GEN_METHOD_2;

GEN_METHOD_3 : if (Method = 3) generate
-- In concurrent mode:
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';
end generate GEN_METHOD_3;
end RTL;
======= END OF CODE ======
Hi KJ,
Thank you for taking time to discuss the keyword "orif".

I don't have to generate other example and just use your example with following changes: Generate a, b, c, d, e in two different state machines with the two state machines being mutually exclusive, so that a-e are mutually exclusive.

The two state machine may be a read state machine and a write state machine of a bus. And a-e are used to drive the 2nd bus.

Now please generate your code to see how a compiler knows if a-e are mutually exclusive. The generated code must be different!!!

What your example provides is the simplest one and a compiler can do it very easily!!!

Nature and coding in complex situations are more complex than your example provides.

1. You must acknowledge that there are situations that only the code writer knows which conditions are mutually exclusive.

http://www.eda.org/twiki/bin/view.cgi/P1076/UniqueCondition#Arguments_FOR

Current Situation
Consider a basic equation in hardware design:
-- no priority tree is implied
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);

One statement structure in serial mode: -- a priority tree is implied
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;

or in another equal form: -- a priority tree is implied
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;

In concurrent mode: -- a priority tree is implied
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';

In those above 3 situations, a superfluous condition is posed on the equation, it means a priority tree is implied in all three situations. Actually most of time when dealing with main data flow, all above conditions are mutually exclusive, so there is no need to pose the extra conditions on the final equation.

Weng

Hi KJ,
You don't have to look for mutually exclusive conditions in any artificial examples.

Just look at any of your successful projects, check any of complex if-statements to see if there are any contiguous conditions which are mutually exclusive in an if-statement. If you find some, change related "elsif" to "orif", then this part of logic would run faster than the original one without effecting other logic.

No matter it is a partial or a full if-statement.
No matter it is a data bus or a state machine logic.
No matter it is a top level if-statement or a deeply nested if-statement.

That is the real magic the keyword "orif" plays: you provide more info and the compiler should generate more efficient logic accordingly.

Please remember that a compiler cannot know more than what you understand as a code writer.

Thank you.

Weng

 

[Weng Tianxiang]

On Friday, February 27, 2015 at 11:51:37 AM UTC-8, KJ wrote:

On Thursday, February 26, 2015 at 9:03:15 PM UTC-5, Weng Tianxiang wrote:
[0020] If the coding system becomes new part of HDL standards all
synthesizer manufactures will automatically be forced to implement all well-
known wave-pipelining algorithms and techniques within their products, a
competition will start for better implementations, making wave-pipelining
technique available to every digital designer in HDL.

A couple of problems with your assumptions:
- No standard body will accept a patent burdened idea to incorporate into a new revision of a standard. You would likely have to effectively surrender your patent rights (should they be granted in the first place) in order to get this to happen.

Hi KJ,
Here is an example that MIT has 4 patents for HDTV and now it is suing a Japanese HDTV manufacturer.

MIT Sues Funai Over 4 HDTV Patents
http://www.law360.com/articles/342212/mit-sues-funai-over-4-hdtv-patents

Weng

- If you think that simply being part of a standard will force synthesis vendors to do anything at all, you're very mistaken.
- Wave pipelining has not caught on with FPGA suppliers in the 45 years since the concept was first introduced nor in the 16 years since Burleson's paper was published so uptake on the technique has not been very quick. That doesn't imply that it will never catch on, but it does suggest the wait will be significant.

Kevin Jennings

 

[KJ]

On Thursday, March 5, 2015 at 12:59:17 AM UTC-5, Weng Tianxiang wrote:

On Wednesday, March 4, 2015 at 8:05:16 PM UTC-8, KJ wrote:

I don't have to generate other example and just use your example with
following changes: Generate a, b, c, d, e in two different state machines
with the two state machines being mutually exclusive, so that a-e are
mutually exclusive.

You're the one making the unsubstantiated claim, so you should generate the example. But I did make up one as you said [1]. Two state machines. One generates a, b, c. The other generates d, e. Which state machine is active at any given time is controlled by an external device I/O pin.

The result is exactly the same as I previously stated. Regardless of the method chosen to implement the data bus muxing, the synthesized output files are identical.

Now please generate your code to see how a compiler knows if a-e are
mutually exclusive. The generated code must be different!!!

They are not different.

What your example provides is the simplest one and a compiler can do it
very easily!!!

You provided no example of how a-e would be generated and probably mutually exclusive which is more than you provided. You simply made claims based on the appearance of the source code and an incorrect assumption of how synthesis tools would create logic

Nature and coding in complex situations are more complex than your example
provides.

Don't try to hide behind 'complex situations'. In a good design you would not code something that is intended to be mutually exclusive in a way that makes it possibly not exclusive (i.e. the generation of a-e). So there would be no a-e, but simply an enumeration or an integer that might get decoded into a-e at some point in a manner essentially identical to what I showed..

What I'm showing here on this post is that even if you try to make it 'more complex', the described logic still resulted in absolutely no difference in the synthesized logic output so the 'orif' still would provide no benefit.. You're presenting 'orif' as if is somehow widely applicable to any number of situations. While there might be niches where 'orif' does have use, I've shown here in these two posts that it is not nearly as universal as you seem to think. So the scope of where it is useful is quite a bit smaller. In fact, to this point, you have not provided a single scenario where it can actually be shown to result in less logic as you claim. What you should focus on is what types of situations would 'orif' actually be beneficial instead of making a claim, not testing it and then be called on it. I'm not saying 'orif' isn't useful, but the scope of where it would be useful has not been shown.

1. You must acknowledge that there are situations that only the code writer knows which conditions are mutually exclusive.

You have not presented actual working sample of such code to demonstrate a single situation. I'll accept that maybe you could, but just have not. On the other side, I've put forth two examples of situations where 'orif' would have no benefit even though you claimed that it would.

For me though, these situations would not arise because I wouldn't be writing code where something that is mutually exclusive is not explicitly coded in that way as well. There would be no need for "only the code writer knows..."

<snip>

In those above 3 situations, a superfluous condition is posed on the
equation, it means a priority tree is implied in all three situations.
Actually most of time when dealing with main data flow, all above
conditions are mutually exclusive, so there is no need to pose the extra
conditions on the final equation.

I've shown that to not be the case.

Kevin

[1] Modified code that demonstrates a 'more complex' version of creating a-e that still results in identical implementation of the logic
======= START OF CODE ======library ieee;
use ieee.std_logic_1164.all;

entity Orif_Example is
generic(
Excl_Method:in natural range 0 to 1;
Method: in natural range 0 to 3);
port(
Clock: in std_ulogic;
Selector: in std_ulogic;
Address: in natural range 0 to 5;
Abus: in std_ulogic;
Bbus: in std_ulogic;
Cbus: in std_ulogic;
Dbus: in std_ulogic;
Ebus: in std_ulogic;
Outbus: out std_ulogic
);
end Orif_Example;

architecture RTL of Orif_Example is
signal a: std_ulogic;
signal b: std_ulogic;
signal c: std_ulogic;
signal d: std_ulogic;
signal e: std_ulogic;
begin
GEN_EXCL_METHOD_0 : if (Excl_Method = 0) generate
a <= '1' when (Address = 1) else '0';
b <= '1' when (Address = 2) else '0';
c <= '1' when (Address = 3) else '0';
d <= '1' when (Address = 4) else '0';
e <= '1' when (Address = 5) else '0';
end generate GEN_EXCL_METHOD_0;

GEN_EXCL_METHOD_1 : if (Excl_Method = 1) generate
type t_STATES1 is (Idle, St_a, St_b, St_c);
type t_STATES2 is (Idle, St_d, St_e);
signal State1: t_STATES1;
signal State2: t_STATES2;
begin
process(Clock)
begin
if rising_edge(Clock) then
a <= '0';
b <= '0';
c <= '0';
d <= '0';
e <= '0';
case State1 is
when Idle => null;
when St_a => a <= '1'; if (Selector = '1') then State1 <= St_b; end if;
when St_b => b <= '1'; if (Selector = '1') then State1 <= St_c; end if;
when St_c => c <= '1'; if (Selector = '1') then State1 <= St_a; end if;
end case;
case State2 is
when Idle => null;
when St_d => d <= '1'; if (Selector = '0') then State2 <= St_e; end if;
when St_e => e <= '1'; if (Selector = '0') then State2 <= St_d; end if;
end case;
end if;
end process;
end generate GEN_EXCL_METHOD_1;

GEN_METHOD_0 : if (Method = 0) generate
Outbus <= (a and ABus) or (b and BBus) or (c and CBus) or (d and DBus) or (e and EBus);
end generate GEN_METHOD_0;

GEN_METHOD_1 : if (Method = 1) generate
-- One statement structure in serial mode:
process(all)
begin
if(a = '1') then OutBus <= ABus;
elsif(b = '1') then Outbus <= BBus;
elsif(c = '1') then Outbus <= CBus;
elsif(d = '1') then Outbus <= DBus;
elsif(e = '1') then Outbus <= EBus;
else Outbus <= '0';
end if;
end process;
end generate GEN_METHOD_1;

GEN_METHOD_2 : if (Method = 2) generate
-- or in another equal form:
process(all)
begin
Outbus <= '0';
if(a = '1') then OutBus <= ABus; end if;
if(b = '1') then OutBus <= BBus; end if;
if(c = '1') then OutBus <= CBus; end if;
if(d = '1') then OutBus <= DBus; end if;
if(e = '1') then OutBus <= EBus; end if;
end process;

end generate GEN_METHOD_2;

GEN_METHOD_3 : if (Method = 3) generate
-- In concurrent mode:
OutBus <= ABus when a = '1'
else BBus when b = '1'
else CBus when c = '1'
else DBus when d = '1'
else EBus when e = '1'
else '0';
end generate GEN_METHOD_3;
end RTL;
======= END OF CODE =======