EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

New invention: Systematic method of coding wave pipelined ci

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - New invention: Systematic method of coding wave pipelined ci

Goto page Previous  1, 2, 3, 4  Next

KJ
Guest

Thu Mar 05, 2015 6:05 am   



On Wednesday, March 4, 2015 at 10:06:05 AM UTC-5, Weng Tianxiang wrote:
Quote:
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
Guest

Thu Mar 05, 2015 7:59 am   



On Wednesday, March 4, 2015 at 8:05:16 PM UTC-8, KJ wrote:
Quote:
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
Guest

Thu Mar 05, 2015 12:58 pm   



On Wednesday, March 4, 2015 at 9:59:17 PM UTC-8, Weng Tianxiang wrote:
Quote:
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
Guest

Thu Mar 05, 2015 8:14 pm   



On Friday, February 27, 2015 at 11:51:37 AM UTC-8, KJ wrote:
Quote:
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

Quote:
- 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
Guest

Thu Mar 05, 2015 8:20 pm   



On Thursday, March 5, 2015 at 12:59:17 AM UTC-5, Weng Tianxiang wrote:
Quote:
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.

Quote:

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.

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

Quote:

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.

Quote:

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>
Quote:
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 =======

KJ
Guest

Thu Mar 05, 2015 8:24 pm   



On Thursday, March 5, 2015 at 5:59:00 AM UTC-5, Weng Tianxiang wrote:
Quote:
On Wednesday, March 4, 2015 at 9:59:17 PM UTC-8, Weng Tianxiang wrote:
You don't have to look for mutually exclusive conditions in any artificial
examples.


You provided the examples.

Quote:

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.


I've already shown that it would not under common situations.

Quote:

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.


The only 'more info' that is needed is to code properly. If something is mutually exclusive, then it should be coded as a single signal that has multiple values, not as separate signals. Although as I've demonstrated, separate signals can still be properly analyzed by synthesis and the optimum solution obtained without 'orif'.

Kevin Jennings

Weng Tianxiang
Guest

Sat Mar 07, 2015 7:38 pm   



On Thursday, March 5, 2015 at 10:24:35 AM UTC-8, KJ wrote:
Quote:
On Thursday, March 5, 2015 at 5:59:00 AM UTC-5, Weng Tianxiang wrote:
On Wednesday, March 4, 2015 at 9:59:17 PM UTC-8, Weng Tianxiang wrote:
You don't have to look for mutually exclusive conditions in any artificial
examples.

You provided the 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.

I've already shown that it would not under common situations.


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.

The only 'more info' that is needed is to code properly. If something is mutually exclusive, then it should be coded as a single signal that has multiple values, not as separate signals. Although as I've demonstrated, separate signals can still be properly analyzed by synthesis and the optimum solution obtained without 'orif'.

Kevin Jennings


Hi KJ,

"If something is mutually exclusive, then it should be coded as a single signal that has multiple values, not as separate signals. "

How can a compiler know that a group of signals coming from two different state machines are mutually exclusive unless you give more info?

Those situations are common in my coding.

As my example has shown, there is no better way than using a case statement to tell a compiler that those signals are mutually exclusive.

Please let me know if there is a better way than using case statement to do so.

Weng

KJ
Guest

Sun Mar 08, 2015 11:40 pm   



On Saturday, March 7, 2015 at 12:38:52 PM UTC-5, Weng Tianxiang wrote:
Quote:
On Thursday, March 5, 2015 at 10:24:35 AM UTC-8, KJ wrote:

"If something is mutually exclusive, then it should be coded as a single
signal that has multiple values, not as separate signals. "

How can a compiler know that a group of signals coming from two different
state machines are mutually exclusive unless you give more info?


Synthesis tool don't give a hoot about whether you think something is mutually exclusive or not. They implement Boolean logic from a hardware description. I've already shown you two examples where you seem to believe it to not be possible that synthesis tools do the proper thing, and apparently you can't accept it.

Quote:
Those situations are common in my coding.


OK...so what?

Quote:
As my example has shown, there is no better way than using a case statement
to tell a compiler that those signals are mutually exclusive.


A case statement does not "tell a compiler that those signals are mutually exclusive". It is a enumeration of all of the states possible and what is to be done under those conditions. Nothing more, nothing less.

Quote:
Please let me know if there is a better way than using case statement to do
so.

I already did, you don't accept it so I'm done.


Kevin Jennings

Weng Tianxiang
Guest

Mon Mar 09, 2015 12:02 pm   



On Tuesday, March 3, 2015 at 9:26:46 PM UTC-8, Weng Tianxiang wrote:
Quote:
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.


Here are more contents.

Definitions of wave-pipelining component and critical path component

[0062] A design component is called a critical path component (CPC) if it is an entity (a term in VHDL-2002) in HDL and encapsulates the static logic part of a critical path which is to be wave-pipelined circuit. There are two types of CPCs:
• A series CPC: it encapsulates a series critical path’s static logic part.
• A feedback CPC: it encapsulates a feedback critical path’s static logic part.

[0063] A CPC also refers to a CPC instantiation when it will not be misunderstood. The required interfaces of both a series CPC and a feedback CPC are always the same. The combinational logic of a CPC may be located within or outside of the component and there is no limit on it.

[0064] A design component is called a wave-pipelining component (WPC) if it is an entity in HDL, provided by HDL in a new wave-pipelining system library and used to generate a critical path’s dynamic logic part, i.e., to generate output data valid signal and write enable signals to the input and output registers of a critical path.

[0065] There are three types of WPC:
• A series_module is used to connect to a series CPC with input data acceptable on every clock cycle.
• An input_delay_module is used to connect to a series or feedback CPC with input data acceptable on every one or more clock cycle.
• A multiple_copy_module1 or a multiple_copy_module2 is used to connect to multiple copied series or feedback CPCs with input data acceptable on every clock cycle.

[0066] A WPC also refers to a WPC instantiation when it will not be misunderstood. Later multiple_copy_module refers to either of multiple_copy_module1 and multiple_copy_module2.

A synthesizer’s new signals, switch and table

[0067] A synthesizer that is able of handling wave-pipelining needs six signals, one switch, one table and the table’s row index to help finish its job:
• A floating signal target_running_frequency: it is set up by a designer and the target running frequency under which a design finally runs.
• A bit signal generate_circuit: it is set up by a designer and its initial value is deasserted. A synthesizer will generate related circuit files for a design under slow mode for slow mode hardware testing if generate_circuit is asserted and no errors are detected after a synthesization, or will not otherwise. A synthesizer will always generate related circuit files for a design under target mode for target mode hardware testing if no errors are detected after a synthesization.
• A bit signal feedback_bit: it is set up by a synthesizer and its initial value is deasserted. Assert the bit if a CPC is being analyzed and determined to have feedbacks, and deassert it after the analysis is finished.
• A bit signal keep_target_circuit: it is set up by a designer and its initial value is deasserted. Assert the bit if a designer wants to keep all CPC new circuits automatically and successfully modified by a synthesizer under target mode unchanged under slow mode when he is switching to synthesize the same design from under target mode to under slow mode and the related code doesn’t change, or deassert it otherwise. The bit provides a method for a designer to check if the new automatically and successfully modified circuits by a synthesizer don’t change basic logic.
• An integer signal parent_series_clock_number: it is set up by a synthesizer and Its initial value is zero. When the instantiation of a WPC delay_input_module or multiple_copy_module is being analyzed and executed its series_clock_number value is stored in parent_series_clock_number, and it is cleared to zero when the execution is finished.
• An integer signal start_number: it is set up by a synthesizer and used when the synthesizer determines that a CPC cannot meet the wave-pipelining requirements with input data acceptable on every clock cycle and the CPC is linked with a WPC input_delay_module or multiple_copy_module. The start_number is made equal to 2 if a WPC multiple_copy_module is linked or to feedback_clock_number if a WPC input_delay_module is linked as the starting value of wave constant input_clock_number or multiple_copy_number.
• A bit switch running_mode: it is set up by a designer and it has two valid values with slow mode being its initial value:
o Slow mode: under slow mode a digital designer designs his code, a design is synthesized, simulated, and hardware tested under the following assumptions:
 Signals take one clock cycle to propagate through any of CPCs under slow running frequency.
 Any of CPCs has input data acceptable on every clock cycle.
 No multiple copied CPCs are generated.
o Target mode: under target mode a design is synthesized, simulated, hardware tested and finally runs under predetermined target running frequency, and its implementation is determined and generated by a synthesizer under the following assumptions:
 Signals take one or more clock cycle to propagate through any of CPCs as designed.
 Each of CPCs has input data acceptable on every one or more clock cycle as wave-pipelining ready code indicates and it is necessary.
 Multiple copied CPCs are generated as wave-pipelining ready code indicates and it is necessary.
• A wave constant signal table: it is generated and manipulated by a synthesizer and stores information about each linked pair of a CPC and a WPC; all wave constant values and alias wave constant values can be accessed from the table.
• An integer row_index to the wave constant signal table: it is set up by a synthesizer and its initial value is 1. It is used as a row index for a new link statement in the wave constant signal table and will be increased by 1 after a synthesizer finishes the filling of the row during the source code scanning.

Thank you for your reading.

Weng

Weng Tianxiang
Guest

Sat Mar 14, 2015 7:30 am   



On Monday, March 9, 2015 at 3:02:48 AM UTC-7, Weng Tianxiang wrote:
Quote:
On Tuesday, March 3, 2015 at 9:26:46 PM UTC-8, Weng Tianxiang wrote:
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.

Here are more contents.

Definitions of wave-pipelining component and critical path component

[0062] A design component is called a critical path component (CPC) if it is an entity (a term in VHDL-2002) in HDL and encapsulates the static logic part of a critical path which is to be wave-pipelined circuit. There are two types of CPCs:
• A series CPC: it encapsulates a series critical path’s static logic part.
• A feedback CPC: it encapsulates a feedback critical path’s static logic part.

[0063] A CPC also refers to a CPC instantiation when it will not be misunderstood. The required interfaces of both a series CPC and a feedback CPC are always the same. The combinational logic of a CPC may be located within or outside of the component and there is no limit on it.

[0064] A design component is called a wave-pipelining component (WPC) if it is an entity in HDL, provided by HDL in a new wave-pipelining system library and used to generate a critical path’s dynamic logic part, i.e., to generate output data valid signal and write enable signals to the input and output registers of a critical path.

[0065] There are three types of WPC:
• A series_module is used to connect to a series CPC with input data acceptable on every clock cycle.
• An input_delay_module is used to connect to a series or feedback CPC with input data acceptable on every one or more clock cycle.
• A multiple_copy_module1 or a multiple_copy_module2 is used to connect to multiple copied series or feedback CPCs with input data acceptable on every clock cycle.

[0066] A WPC also refers to a WPC instantiation when it will not be misunderstood. Later multiple_copy_module refers to either of multiple_copy_module1 and multiple_copy_module2.

A synthesizer’s new signals, switch and table

[0067] A synthesizer that is able of handling wave-pipelining needs six signals, one switch, one table and the table’s row index to help finish its job:
• A floating signal target_running_frequency: it is set up by a designer and the target running frequency under which a design finally runs.
• A bit signal generate_circuit: it is set up by a designer and its initial value is deasserted. A synthesizer will generate related circuit files for a design under slow mode for slow mode hardware testing if generate_circuit is asserted and no errors are detected after a synthesization, or will not otherwise. A synthesizer will always generate related circuit files for a design under target mode for target mode hardware testing if no errors are detected after a synthesization.
• A bit signal feedback_bit: it is set up by a synthesizer and its initial value is deasserted. Assert the bit if a CPC is being analyzed and determined to have feedbacks, and deassert it after the analysis is finished.
• A bit signal keep_target_circuit: it is set up by a designer and its initial value is deasserted. Assert the bit if a designer wants to keep all CPC new circuits automatically and successfully modified by a synthesizer under target mode unchanged under slow mode when he is switching to synthesize the same design from under target mode to under slow mode and the related code doesn’t change, or deassert it otherwise. The bit provides a method for a designer to check if the new automatically and successfully modified circuits by a synthesizer don’t change basic logic.
• An integer signal parent_series_clock_number: it is set up by a synthesizer and Its initial value is zero. When the instantiation of a WPC delay_input_module or multiple_copy_module is being analyzed and executed its series_clock_number value is stored in parent_series_clock_number, and it is cleared to zero when the execution is finished.
• An integer signal start_number: it is set up by a synthesizer and used when the synthesizer determines that a CPC cannot meet the wave-pipelining requirements with input data acceptable on every clock cycle and the CPC is linked with a WPC input_delay_module or multiple_copy_module. The start_number is made equal to 2 if a WPC multiple_copy_module is linked or to feedback_clock_number if a WPC input_delay_module is linked as the starting value of wave constant input_clock_number or multiple_copy_number.
• A bit switch running_mode: it is set up by a designer and it has two valid values with slow mode being its initial value:
o Slow mode: under slow mode a digital designer designs his code, a design is synthesized, simulated, and hardware tested under the following assumptions:
 Signals take one clock cycle to propagate through any of CPCs under slow running frequency.
 Any of CPCs has input data acceptable on every clock cycle.
 No multiple copied CPCs are generated.
o Target mode: under target mode a design is synthesized, simulated, hardware tested and finally runs under predetermined target running frequency, and its implementation is determined and generated by a synthesizer under the following assumptions:
 Signals take one or more clock cycle to propagate through any of CPCs as designed.
 Each of CPCs has input data acceptable on every one or more clock cycle as wave-pipelining ready code indicates and it is necessary.
 Multiple copied CPCs are generated as wave-pipelining ready code indicates and it is necessary.
• A wave constant signal table: it is generated and manipulated by a synthesizer and stores information about each linked pair of a CPC and a WPC; all wave constant values and alias wave constant values can be accessed from the table.
• An integer row_index to the wave constant signal table: it is set up by a synthesizer and its initial value is 1. It is used as a row index for a new link statement in the wave constant signal table and will be increased by 1 after a synthesizer finishes the filling of the row during the source code scanning.

Thank you for your reading.

Weng


Here are more contents. It shows how a complicated problem is resolved by creative ideas.


New keyword wave and wave constant in HDL

[0068] When writing wave-pipelining code, digital designers don’t know how many clock cycles signals need to propagate through a critical path, and to finish their jobs, it may take several working cycles for them manually to adjust their code to make a wave-pipelined circuit working. This method is not feasible on a design-wide or chip-wide scale, because a design may have 100 or more critical paths to be wave-pipelined circuits and there is no guarantee for designers to perfectly remember which is finished and which is not, and most importantly, synthesizers are left aside of the business of wave-pipelining, giving no help at all. One of obstacles using wave-pipelining in HDL is how to establish a communication channel between a synthesizer and digital designers to provide the following essential functions:

• How a designer can use after-synthesization information to write code for wave-pipelined circuits before they have been synthesized in HDL for wave-pipelining technology. This function is not necessary for successfully generating a wave-pipelined circuit, but beneficial to implement a complex one.

• If all pieces of wave-pipelining ready code are written, a design has passed simulations and/or hardware testing under slow mode perfectly, and a synthesizer certifies that all wave-pipelining requirements are met with input data acceptable on every one or more clock cycle and no errors are detected after a synthesization, then correct full design circuits can be generated under target mode and work as designed with no code change during the switching from slow mode to target mode or vice verse on a design-wide or chip-wide scale. This function is critical and essential for successfully generating all wave-pipelined circuits on a design-wide or chip-wide scale in HDL.

[0069] New keyword wave and three wave constants are introduced to resolve the problem. In the following listing characters in bold type are new suggested definitions based on VHDL-2002.

entity_declaration ::=
entity identifier is
entity_header
entity_declarative_part
[begin
entity_statement_part ]
end [ entity ] [ entity_simple_name ] ;

entity_header ::[formal_generic_clause ]
[formal_port_clause ]

generic_clause ::= generic ( generic_list ) ;
generic_list ::= generic_interface_list
interface_list ::= interface_element { ; interface_element }
interface_element ::= interface_declaration

interface_declaration ::interface_constant_declaration
|interface_wave_constant_declaration
| interface_signal_declaration
| interface_variable_declaration
| interface_file_declaration

interface_constant_declaration ::[constant] identifier_list : [ in] subtype_indication [ := static_expression ]

interface_wave_constant_declaration ::wave [constant] wave_constant_list : [ in ] subtype_indication
[ := static_expression ]

wave_constant_list ::=
wave_constant_element { , wave_constant_element }

wave_constant_element ::=
wave_constant
|internal_wave_constant

wave_constant ::series_clock_number
| input_clock_number
| multiple_copy_number

internal_wave_constant ::= one_hot

entity_declarative_part ::{ entity_declarative_item }

entity_declarative_item ::subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| alias_wave_constant_declaration
| signal_declaration
|shared_variable_declaration
| file_declaration
| alias_declaration
| attribute_declaration
| attribute_specification
| disconnection_specification
| use_clause
| group_template_declaration
| group_declaration

architecture_body ::architecture identifier of entity_name is
architecture_declarative_part
begin
architecture_statement_part
end[ architecture ] [ architecture_simple_name ] ;

architecture_declarative_part ::{ block_declarative_item }

block_declarative_item ::subprogram_declaration
| subprogram_body
| type_declaration
| subtype_declaration
| constant_declaration
| alias_wave_constant_declaration
| signal_declaration
| shared_variable_declaration
| file_declaration
| alias_declaration
| component_declaration
| attribute_declaration
| attribute_specification
| configuration_specification
| disconnection_specification
| use_clause
| group_template_declaration
| group_declaration

constant_declaration ::constant identifier_list : subtype_indication [ := expression ] ;

alias_wave_constant_declaration ::wave [ constant ] alias_wave_constant_list : subtype_indication :=
wave_constant ;

alias_wave_constant_list ::alias_wave_constant { , alias_wave_constant }

alias_wave_constant ::= identifier

[0070] The set of following rules is called wave constant mechanism:

• There are three wave constants related to wave-pipelining technique: series_clock_number, input_clock_number and multiple_copy_number.

• A wave constant can only be declared in the generic_clause of the entity definition of a WPC embodiment, plays the same role as a generic constant declared in the same place does except that it has actual initial value 1 under slow mode, and actual initial value equal to or greater than 1 determined and assigned by a synthesizer under target mode, and the static expression in an interface wave constant declaration is always ignored.

• A WPC instantiation must not include corresponding association element with a formal wave constant in the generic map aspect.

• Any wave constant declared in a WPC definition is accessible by designers through an alias wave constant declaration.

• An alias wave constant declaration identifies a list of alias wave constants which are assigned a wave constant. Each alias wave constant must be linked with a WPC instantiation through a link statement and shares the wave constant value of the linked WPC instantiation for testing, debugging or implementing purpose. An alias wave constant plays the same role as a normal constant declared in the same place does.

• A CPC may have any of its linked WPC’s wave constants and output signals as its own input signal, but must have no input signals which are related to any unrelated WPC instantiation’s wave constants.

• The internal wave constant one_hot is used internally by a synthesizer to optimize the implementation of a WPC and not accessible by designers.

• A synthesizer has its discretion to determine internal wave constant one_hot value based on the environment and the consideration of its production technique used unless a WPC input_delay_module has its R_O output connected in which case one_hot will be ‘1’ in order to generate valid R_O output signal.


Thank you for your reading.

Weng

KJ
Guest

Mon Mar 16, 2015 12:52 pm   



On Saturday, March 14, 2015 at 1:45:11 AM UTC-4, Weng Tianxiang wrote:

Quote:
Here are more contents. It shows how a complicated problem is resolved by
creative ideas.

snip
[0069] New keyword wave and three wave constants are introduced to resolve
the problem. In the following listing characters in bold type are new suggested
definitions based on VHDL-2002.


Do you have any data to support your contention that your solution actually solves the problem of designer productivity in implementing wave-pipeline code?

Kevin

Weng Tianxiang
Guest

Tue Mar 17, 2015 8:15 pm   



On Monday, March 16, 2015 at 3:52:56 AM UTC-7, KJ wrote:
Quote:
On Saturday, March 14, 2015 at 1:45:11 AM UTC-4, Weng Tianxiang wrote:

Here are more contents. It shows how a complicated problem is resolved by
creative ideas.

snip
[0069] New keyword wave and three wave constants are introduced to resolve
the problem. In the following listing characters in bold type are new suggested
definitions based on VHDL-2002.


Do you have any data to support your contention that your solution actually solves the problem of designer productivity in implementing wave-pipeline code?

Kevin


KJ,
I didn't invent any method to generate correct wave pipelined circuits, what I did is I invented a systematic method for all digital designers to be able to write any types of wave pipelined circuits in HDL and shifted the responsibility to generate such circuits from individual designers to compilers!!!

So your question is pointless.

Here is a historical example:
Before HDL introduction, everyone had to write logic to make 32-bit*32-bit multiplication if he needed to do it.

After HDL and multiple sign "*' introduction, everyone now can do 32*32 multiplication using multiple sign "*'.

What difference between my invention and multiple sign "*' introduction is that the idea behind my method is very complex, non-obvious so that after 1967 first paper published on wave pipelined circuits, no one had figured out how it can be done in HDL.

The invention is 65 pages long, a jumbo invention according to USPTO standards, and describes all rules for designers and compilers to observe to make such things happening harmoniously without any defects.

The results of my invention are:
1. Every digital designer can write wave pipelined circuits in HDL if the invention is adopted by HDL.

2. Every wave pipelined circuit published publicly, implemented or non-implemented, ASIC or FPGA, can be implemented by any compiler without any doubt..

3. The method to write the circuit for digital designers is both very simple and comprehensive. The method will not generate any extra logic, compared to the original method.

4. What a designer needs to do is very simple: tell compiler that this is a wave pipelined circuit design and generate it for me, and I have tools to check if you do a correct thing and if you cannot do it, let me know what I should do to improve the successful rate.

Please be patient to see my posting which will finally publish all related source code for public to check if my claims are correct.

After that you may have more rights to comment and I will welcome any comments.

Weng

KJ
Guest

Wed Mar 18, 2015 3:26 am   



On Tuesday, March 17, 2015 at 2:15:26 PM UTC-4, Weng Tianxiang wrote:
Quote:

KJ,
I didn't invent any method to generate correct wave pipelined circuits,


I never said or implied that you did

Quote:
what I did is I invented a systematic method for all digital designers to be
able to write any types of wave pipelined circuits in HDL and shifted the
responsibility to generate such circuits from individual designers to
compilers!!!


And my question was simply: "Do you have any data to support your contention that your solution actually solves the problem of designer productivity in implementing wave-pipeline code?"

Quote:

So your question is pointless.

Sure...if you have nothing to support your position, try to blame it on the question. So I'll have to assume at this point that this you have nothing to back up your claims, just like you had nothing to backup your claims with 'orif' which I showed to be incorrect.


<snip the pointless historical example>
Quote:

What difference between my invention and multiple sign "*' introduction is
that the idea behind my method is very complex, non-obvious so that after
1967 first paper published on wave pipelined circuits, no one had figured out
how it can be done in HDL.


But does your method have any practical utility? You say it does, and maybe you're right, but you haven't demonstrated that with any of your posting here. To get a patent you may not need to show this, but since you're posting here to an open forum you should consider that without practical utility what you're posting isn't interesting reading.

Maybe you haven't gotten to that part of showing the utility even after all of the postings in this newsgroup, or maybe it's because this idea is like your idea for 'orif' which has little or no real utility as I demonstrated on one of the sidebars of this thread.

Quote:
The invention is 65 pages long, a jumbo invention according to USPTO
standards, and describes all rules for designers and compilers to observe to
make such things happening harmoniously without any defects.

The results of my invention are:
1. Every digital designer can write wave pipelined circuits in HDL if the
invention is adopted by HDL.


Without any data to backup what you say...it becomes easy to claim most anything

Quote:
2. Every wave pipelined circuit published publicly, implemented or non-
implemented, ASIC or FPGA, can be implemented by any compiler without any
doubt.


Can you provide evidence of this?

Quote:
3. The method to write the circuit for digital designers is both very simple
and comprehensive. The method will not generate any extra logic, compared to
the original method.


You're contradicting yourself. A few lines up you said "no one had figured out how it can be done in HDL" and yet now you say that there is some "original method". And again...can you demonstrate it or can you only claim that it must be?

Quote:
4. What a designer needs to do is very simple: tell compiler that this is a
wave pipelined circuit design and generate it for me, and I have tools to
check if you do a correct thing and if you cannot do it, let me know what I
should do to improve the successful rate.


What if I tell it that it is a wave pipelined circuit when in fact it is not?

Quote:
Please be patient to see my posting which will finally publish all related
source code for public to check if my claims are correct.


OK

Quote:
After that you may have more rights to comment and I will welcome any
comments.


I have the same 'rights' to post and comment here as you do.

Kevin Jennings


Guest

Wed Mar 18, 2015 11:31 pm   



On Wednesday, March 18, 2015 at 2:26:49 PM UTC+13, KJ wrote:
Quote:
On Tuesday, March 17, 2015 at 2:15:26 PM UTC-4, Weng Tianxiang wrote:

After that you may have more rights to comment and I will welcome any
comments.

I have the same 'rights' to post and comment here as you do.

Kevin Jennings


I'd echo Kevin's sentiments. If you want to control the story do your own blog or website.

In the mean time your comportment in this thread doesn't portray you nor your questionable-yet-not-to-be-questioned ideas in a particularly good light.

Weng Tianxiang
Guest

Fri Mar 20, 2015 4:49 pm   



On Tuesday, March 17, 2015 at 6:26:49 PM UTC-7, KJ wrote:
Quote:
On Tuesday, March 17, 2015 at 2:15:26 PM UTC-4, Weng Tianxiang wrote:

KJ,
I didn't invent any method to generate correct wave pipelined circuits,

I never said or implied that you did

what I did is I invented a systematic method for all digital designers to be
able to write any types of wave pipelined circuits in HDL and shifted the
responsibility to generate such circuits from individual designers to
compilers!!!


And my question was simply: "Do you have any data to support your contention that your solution actually solves the problem of designer productivity in implementing wave-pipeline code?"


So your question is pointless.

Sure...if you have nothing to support your position, try to blame it on the question. So I'll have to assume at this point that this you have nothing to back up your claims, just like you had nothing to backup your claims with 'orif' which I showed to be incorrect.

snip the pointless historical example

What difference between my invention and multiple sign "*' introduction is
that the idea behind my method is very complex, non-obvious so that after
1967 first paper published on wave pipelined circuits, no one had figured out
how it can be done in HDL.


But does your method have any practical utility? You say it does, and maybe you're right, but you haven't demonstrated that with any of your posting here. To get a patent you may not need to show this, but since you're posting here to an open forum you should consider that without practical utility what you're posting isn't interesting reading.

Maybe you haven't gotten to that part of showing the utility even after all of the postings in this newsgroup, or maybe it's because this idea is like your idea for 'orif' which has little or no real utility as I demonstrated on one of the sidebars of this thread.

The invention is 65 pages long, a jumbo invention according to USPTO
standards, and describes all rules for designers and compilers to observe to
make such things happening harmoniously without any defects.

The results of my invention are:
1. Every digital designer can write wave pipelined circuits in HDL if the
invention is adopted by HDL.


Without any data to backup what you say...it becomes easy to claim most anything

2. Every wave pipelined circuit published publicly, implemented or non-
implemented, ASIC or FPGA, can be implemented by any compiler without any
doubt.


Can you provide evidence of this?

3. The method to write the circuit for digital designers is both very simple
and comprehensive. The method will not generate any extra logic, compared to
the original method.


You're contradicting yourself. A few lines up you said "no one had figured out how it can be done in HDL" and yet now you say that there is some "original method". And again...can you demonstrate it or can you only claim that it must be?

4. What a designer needs to do is very simple: tell compiler that this is a
wave pipelined circuit design and generate it for me, and I have tools to
check if you do a correct thing and if you cannot do it, let me know what I
should do to improve the successful rate.


What if I tell it that it is a wave pipelined circuit when in fact it is not?

Please be patient to see my posting which will finally publish all related
source code for public to check if my claims are correct.


OK

After that you may have more rights to comment and I will welcome any
comments.

I have the same 'rights' to post and comment here as you do.

Kevin Jennings


KJ,

"Critical questions are inventions' mother."

Einstein

Thank you for your critical comments.

The reason is that your comments are driving me to file another patent application on the same wave-pipelined circuits theory to fully support my theory and meet your curiosity:

1. It will provide an example implementation used for a 4-core processor environment with source code included. The included source code is not necessary, but will certainly accelerate the process of understanding, distributing, helping and correct assessing my patent applications.

2. It will fully describe using the implementable example why my invented method really resolves the 50-year pending problem and makes it successful without failure with sharp-point targeting and answering all questionable-yet-not-to-be-questioned ideas.

I will continue publishing all remaining part of my patent application when I am available, including all related source code of 52,089 bytes, about 1,100 lines, for public verification, because that invention is targeted and assumed to be incorporated into all HDL language, and public has the rights to know it.

If any readers find any questionable-yet-not-to-be-questioned ideas while reading my application text, you may immediately ask me the questions after my posting and I will immediately answer your doubts without any delay.


Weng

Goto page Previous  1, 2, 3, 4  Next

elektroda.net NewsGroups Forum Index - VHDL Language - New invention: Systematic method of coding wave pipelined ci

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map