New coding method for a state machine in groups in HDL

[Weng Tianxiang]

On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Using different combinations of all jumping signals belonging to a SG, one can generate different simplest circuits to finish the job. 

For years now you've made these same claims about your state machines without providing any evidence to back the claim. During those years I've provided evidence showing your claims to be false. I doubt there will be anything different this time since it appears to be more of the same.

Kevin Jennings

KJ,

Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago.

If you can find any point, please show it and don't talk nothing.

I remember you were talking about some jumping signal generations last time and I didn't see any point of your argument.

Let HT-Lab or Rick as arbitrator to determine whether your standpoint is meaningless or not. Last time Rick was on my side.

Actually this patent, US 10482208, has nothing to do with how to generate jumping signals for a state machine!!!

I define the jumping signals for a state machine in the patent, but never mention how to generate them.

Weng

 

[KJ]

On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote:

On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago.
I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup. You have not provided any evidence backing your statement.

I remember you were talking about some jumping signal generations last time and I didn't see any point of your argument.
OK, but that speaks to your abilities.

Let HT-Lab or Rick as arbitrator to determine whether your standpoint is meaningless or not. Last time Rick was on my side.

HAHAHA, we're choosing teams now???

Actually this patent, US 10482208, has nothing to do with how to generate jumping signals for a state machine!!!
Who care what the patent has nothing to do about?

Kevin Jennings

 

[Weng Tianxiang]

On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote:

On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote:
On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago.
I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup. You have not provided any evidence backing your statement.


I remember you were talking about some jumping signal generations last time and I didn't see any point of your argument.
OK, but that speaks to your abilities.


Let HT-Lab or Rick as arbitrator to determine whether your standpoint is meaningless or not. Last time Rick was on my side.

HAHAHA, we're choosing teams now???


Actually this patent, US 10482208, has nothing to do with how to generate jumping signals for a state machine!!!
Who care what the patent has nothing to do about?

Kevin Jennings

KJ,
On one side you said:
"I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup."

On other side you said:
"Who care what the patent has nothing to do about?"

Here are the facts:
1. It became patent US 10482208 since 11/19/2019.

2. If you can pinpoint any unsubstantiated claim from the official US patent, what you make may invalidate the patent.

3. I welcome your action and have no objection against it, because I believe the state machine's new coding method certainly will be accepted into HDL SOMEDAY, because it generates no burden for coding state machines and finally perfects the work made by a lot of papers one of which has 224 cites,
http://www.scarpaz.com/2100-papers/Low%20Power/00503933.pdf,
and every code designer will benefit on the new coding method.

Last time Rick and you were arguing against each other on your pointless points and I firmly stand with Rick, but I did not participate your argument, not because you are an expert and comments are valuable, but because your point is no sense and pointless in any way and I don't want to spend any time on your pointless points.

KJ, please be BRAVE to pinpoint WHICH PAGE, WHICH LINES 哦人WHICH FIGURES have any type of LOGIC and SIGNIFICANT errors.

If you do this I will response to your points immediately and let Rick and HT-Lab determine if your claim is pointless or not, otherwise I will ignore all your later posts on this subject.

9 (nine) years ago I asked you to help me to check the application text for grammar errors and I thank you for your help with paying.

Now it became a patent with all brand new figures and specifications you have never seen it before publication, and all figures, specification, claims for the patent were made by myself.

Weng

 

[Andy Bennet]

On 30/11/2019 03:56, Weng Tianxiang wrote:

On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote:
On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang wrote:
On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Please read my diagrams carefully in my patent and you are familiar with none of what I asked you to check my application for specification and diagrams 9 years ago.
I referenced and commented on the unsubstantiated claim you made in the posting you made in this newsgroup. You have not provided any evidence backing your statement.

I do not see how your re-arrangment of state machines saves power if
this is the fundamental goal.
In FPGA design it is a definate no-no to gate the clock signal into a
F/F, or indeed manufacture a clock signal from a logic expression which
will produce difficult to predict setup and hold times as well as glitches.
The power in a F/F is predominantly driven by the change of state of the
flip flop.
You should only 'gate' the clock into a F/F by using its enable control
line. The F/F remains continuously clocked, but the input of the flip
flop is controlled by the enable to either be the output of the flip
flop or new data.
This then gives predicatable setup and hold times and a glitch free
operation - assuming the enables are synchronous, which is basic design
practise.

AB

 

[Weng Tianxiang]

I do not see how your re-arrangment of state machines saves power if
this is the fundamental goal.
In FPGA design it is a definate no-no to gate the clock signal into a
F/F, or indeed manufacture a clock signal from a logic expression which
will produce difficult to predict setup and hold times as well as glitches.
The power in a F/F is predominantly driven by the change of state of the
flip flop.
You should only 'gate' the clock into a F/F by using its enable control
line. The F/F remains continuously clocked, but the input of the flip
flop is controlled by the enable to either be the output of the flip
flop or new data.
This then gives predicatable setup and hold times and a glitch free
operation - assuming the enables are synchronous, which is basic design
practise.

AB

AB,

Good, a technical and basic question!!!

A F/F saves power if it does not receive clock pulse when its states do not change.

In my design a F/F input pin always has '0' input if it does not change states and I don't know if it saves power.

Please refer to this paper suggested by dlhe in his earlier post and my patent does not have to further explain it. I read the paper only after dlhe suggested and found the paper does many experiments to confirm how it saves power.

The paper has a paragraph "4. Experiment Results" which uses their experiments to show it saves power.

Weng

http://apachepersonal.miun.se/~benoel/download/papers/Asynch_control_FSM.pdf

Asynchronous control of low-power gated-clock finite-state-machines

: ICECS'99. Proceedings of ICECS '99. 6th IEEE International Conference on Electronics, Circuits and Systems

An efficient approach to reduce power consumption in a synchronous Finite-State Machine (FSM) is to de-compose it, according to a partitioning algorithm, to a number of sub-FSMs that interact through some communication signals. Only one sub-FSM is clocked at a time and low power operation is obtained by only clocking the active sub-FSM. In this paper we introduce a new asynchronous communication control for the interacting sub-FSMs, which reduces the total capacitance switched by the system clock. Experimental results show that this leads to significant power savings when the FSM is partitioned into many sub-FSMs.

 

[Richard Damon]

On 11/30/19 3:24 AM, Andy Bennet wrote:

On 30/11/2019 03:56, Weng Tianxiang wrote:
On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote:
On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang
wrote:
On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Please read my diagrams carefully in my patent and you are familiar
with none of what I asked you to check my application for
specification and diagrams 9 years ago.
I referenced and commented on the unsubstantiated claim you made in
the posting you made in this newsgroup.  You have not provided any
evidence backing your statement.

I do not see how your re-arrangment of state machines saves power if
this is the fundamental goal.
In FPGA design it is a definate no-no to gate the clock signal into a
F/F, or indeed manufacture a clock signal from a logic expression which
will produce difficult to predict setup and hold times as well as glitches.
The power in a F/F is predominantly driven by the change of state of the
flip flop.
You should only 'gate' the clock into a F/F by using its enable control
line. The F/F remains continuously clocked, but the input of the flip
flop is controlled by the enable to either be the output of the flip
flop or new data.
This then gives predicatable setup and hold times and a glitch free
operation - assuming the enables are synchronous, which is basic design
practise.

AB

There are FPGAs which provide a 'gated clock' but they do the gating at
the row or region driver level, as that is where you get better power
savings (driving the clock tree is a significant use of power, while
gating at the flip-flop level saves virtually nothing, if it doesn't
cost you due to the extra logic, if it needs a LUT to gate, you have lost)

These gated clock drivers tend to have de-glitching logic on them that
makes them safe to use (gate signal low keeps the output clock from
going high but doesn't force a high output low). This says that you can
save power if you know a whole section won't be changing for awhile, but
unlikely helps on a small state machine that occasionally doesn't
change, as the power in the change prediction logic may cost more than
the savings. Also, since these clock drivers are a limited critical
resource, you likely don't have enough to use it fine grain.

 

[Rick C]

On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote:

On 11/30/19 3:24 AM, Andy Bennet wrote:
On 30/11/2019 03:56, Weng Tianxiang wrote:
On Friday, November 29, 2019 at 2:03:41 PM UTC-8, KJ wrote:
On Thursday, November 28, 2019 at 4:33:59 PM UTC-5, Weng Tianxiang
wrote:
On Thursday, November 28, 2019 at 12:44:48 PM UTC-8, KJ wrote:

Please read my diagrams carefully in my patent and you are familiar
with none of what I asked you to check my application for
specification and diagrams 9 years ago.
I referenced and commented on the unsubstantiated claim you made in
the posting you made in this newsgroup.  You have not provided any
evidence backing your statement.

I do not see how your re-arrangment of state machines saves power if
this is the fundamental goal.
In FPGA design it is a definate no-no to gate the clock signal into a
F/F, or indeed manufacture a clock signal from a logic expression which
will produce difficult to predict setup and hold times as well as glitches.
The power in a F/F is predominantly driven by the change of state of the
flip flop.
You should only 'gate' the clock into a F/F by using its enable control
line. The F/F remains continuously clocked, but the input of the flip
flop is controlled by the enable to either be the output of the flip
flop or new data.
This then gives predicatable setup and hold times and a glitch free
operation - assuming the enables are synchronous, which is basic design
practise.

AB

There are FPGAs which provide a 'gated clock' but they do the gating at
the row or region driver level, as that is where you get better power
savings (driving the clock tree is a significant use of power, while
gating at the flip-flop level saves virtually nothing, if it doesn't
cost you due to the extra logic, if it needs a LUT to gate, you have lost)

These gated clock drivers tend to have de-glitching logic on them that
makes them safe to use (gate signal low keeps the output clock from
going high but doesn't force a high output low). This says that you can
save power if you know a whole section won't be changing for awhile, but
unlikely helps on a small state machine that occasionally doesn't
change, as the power in the change prediction logic may cost more than
the savings. Also, since these clock drivers are a limited critical
resource, you likely don't have enough to use it fine grain.

Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

 

[Richard Damon]

On 11/30/19 9:55 AM, Rick C wrote:

On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote:

There are FPGAs which provide a 'gated clock' but they do the gating at
the row or region driver level, as that is where you get better power
savings (driving the clock tree is a significant use of power, while
gating at the flip-flop level saves virtually nothing, if it doesn't
cost you due to the extra logic, if it needs a LUT to gate, you have lost)

These gated clock drivers tend to have de-glitching logic on them that
makes them safe to use (gate signal low keeps the output clock from
going high but doesn't force a high output low). This says that you can
save power if you know a whole section won't be changing for awhile, but
unlikely helps on a small state machine that occasionally doesn't
change, as the power in the change prediction logic may cost more than
the savings. Also, since these clock drivers are a limited critical
resource, you likely don't have enough to use it fine grain.

Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating.

Microsemi, now part of Microchip. The gating is part of the regional
clock driving tree, so is somewhat limited, but not as limited as the
master clock generators (which also have gating).

 

[Rick C]

On Saturday, November 30, 2019 at 11:33:45 AM UTC-5, Richard Damon wrote:

On 11/30/19 9:55 AM, Rick C wrote:
On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote:

There are FPGAs which provide a 'gated clock' but they do the gating at
the row or region driver level, as that is where you get better power
savings (driving the clock tree is a significant use of power, while
gating at the flip-flop level saves virtually nothing, if it doesn't
cost you due to the extra logic, if it needs a LUT to gate, you have lost)

These gated clock drivers tend to have de-glitching logic on them that
makes them safe to use (gate signal low keeps the output clock from
going high but doesn't force a high output low). This says that you can
save power if you know a whole section won't be changing for awhile, but
unlikely helps on a small state machine that occasionally doesn't
change, as the power in the change prediction logic may cost more than
the savings. Also, since these clock drivers are a limited critical
resource, you likely don't have enough to use it fine grain.

Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating.


Microsemi, now part of Microchip. The gating is part of the regional
clock driving tree, so is somewhat limited, but not as limited as the
master clock generators (which also have gating).

Which products. I was just looking at their site the other day and I didn't see anything remotely new. Maybe I missed this? Or is this not new?

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

 

[KJ]

On Friday, November 29, 2019 at 10:56:36 PM UTC-5, Weng Tianxiang wrote:

1. It became patent US 10482208 since 11/19/2019.

OK, you paid your filing fee and convinced a bureaucrat so why are you going on about it in comp.arch.fpga?

2. If you can pinpoint any unsubstantiated claim from the official US patent, what you make may invalidate the patent.

Why would I care to let you know about that?

3. I welcome your action and have no objection against it, because I believe the state machine's new coding method certainly will be accepted into HDL SOMEDAY, because it generates no burden for coding state machines and finally perfects the work made by a lot of papers one of which has 224 cites,
http://www.scarpaz.com/2100-papers/Low%20Power/00503933.pdf,
and every code designer will benefit on the new coding method.

As I pointed out to you before, because you've chosen to patent, it essentially cannot be accepted into an HDL standard, regardless of the merit.

KJ, please be BRAVE to pinpoint WHICH PAGE, WHICH LINES 哦人WHICH FIGURES have any type of LOGIC and SIGNIFICANT errors.

HAHAHAHA, that would be a paid position, not one that should be done for free. Good try. Just like the one you did earlier in this thread where you encouraged others to be unethical to their own employers in regards to offering a bounty for infringing your patent. Asking others to be unethical is itself unethical, but I don't think you see it that way.

If you do this I will response to your points immediately and let Rick and HT-Lab determine if your claim is pointless or not, otherwise I will ignore all your later posts on this subject.
You don't respond to any points...you reply, but no response. That's why we have these pointless back and forths, I point out your flaws or challenge you to backup your claim with real data and you never come through.

9 (nine) years ago I asked you to help me to check the application text for grammar errors and I thank you for your help with paying.

Grammar errors, right...OooooKkkkk. I provided valid technical feedback because nearly everything you claimed at that time was wrong and I demonstrated it to you with actual designs and reports. Grammar errors...I did do some of that too, but wow.

Now it became a patent with all brand new figures and specifications you have never seen it before publication, and all figures, specification, claims for the patent were made by myself.
I've only been commenting on what you've posted here in this forum. You just can't seem to follow...again

Kevin Jennings

 

[KJ]

On Saturday, November 30, 2019 at 8:09:50 AM UTC-5, Weng Tianxiang wrote:

The paper has a paragraph "4. Experiment Results" which uses their experiments to show it saves power.

Weng

And where are your experimental results that demonstrate something useful compared to current state of the art? That's all I've been asking...for years

Kevin

 

[Richard Damon]

On 11/30/19 1:40 PM, Rick C wrote:

On Saturday, November 30, 2019 at 11:33:45 AM UTC-5, Richard Damon wrote:
On 11/30/19 9:55 AM, Rick C wrote:
On Saturday, November 30, 2019 at 9:16:40 AM UTC-5, Richard Damon wrote:

There are FPGAs which provide a 'gated clock' but they do the gating at
the row or region driver level, as that is where you get better power
savings (driving the clock tree is a significant use of power, while
gating at the flip-flop level saves virtually nothing, if it doesn't
cost you due to the extra logic, if it needs a LUT to gate, you have lost)

These gated clock drivers tend to have de-glitching logic on them that
makes them safe to use (gate signal low keeps the output clock from
going high but doesn't force a high output low). This says that you can
save power if you know a whole section won't be changing for awhile, but
unlikely helps on a small state machine that occasionally doesn't
change, as the power in the change prediction logic may cost more than
the savings. Also, since these clock drivers are a limited critical
resource, you likely don't have enough to use it fine grain.

Who makes these FPGAs? Are these in the typical clock generators most FPGAs have only a handful of? That's still better than no clock gating.


Microsemi, now part of Microchip. The gating is part of the regional
clock driving tree, so is somewhat limited, but not as limited as the
master clock generators (which also have gating).

Which products. I was just looking at their site the other day and I didn't see anything remotely new. Maybe I missed this? Or is this not new?

I use it in the SmartFusion2 and Igloo2 products. I don't think they
hype the feature, so you need to dig into the Macro Function Library
documentation and the Clocking Resources Documentation to see it. All
the global/row global clock buffers have an enable option.

 

[Weng Tianxiang]

And where are your experimental results that demonstrate something useful compared to current state of the art? That's all I've been asking...for years

Kevin

KJ,

Why I don't like to directly answer your questions long time ago, for years, can be found in above question as another example, because your most questions are pointless and make nonsense as this question.

AS A PATENT, DO I NEED TO DO EXPERIMENTS TO DEMONSTRATE THAT MY CIRCUITS WOULD REDUCE POWER ASSUMPTION? A REALLY STUPID QUESTION!!!

As my first post shows that no one except me in the world who suggested or made any hits that any states in a state machine can be divided into groups AT ONE'S DISCRETION to reduce power consumption.

Here is a coding snippet for new method you can immediately understand what will happen for coding a state machine.

type State_Machine_t is (
First_group : (s1, s2, s3),
Second_Group : (s4, s5, s6),
Third_Group : (s7, s8, s9)
);
signal State_Machine, State_Machine_Next : State_Machine_t ;

You can carefully compare my patent with following paper and find what is the essential differences:

Here is a famous paper about the similar method with 244 cites, using probability theory to divide states into group:
http://www.scarpaz.com/2100-papers/Low%20Power/00503933.pdf

The 244 cites itself demonstrate that in academic circle it once was a hot issue and a very important issue.

I fully perfect the method with simplest method and simplest logic!

I not only invent the method, even though it is trivial, but I invent systematic methods on how to implement state division with a set of diagrams. The new systematic methods can be immediately implemented by any synthesizer manufacturers.

I divide all state jumping signals of a state group into 4 categories:

1. Local jumping signal which has its current state and next state within the state group and its current state is different from its target state;

2. Holding jumping signal which has its current state and next state within the state group and its current state is the same as its target state;

3. Entering jumping signal which has its current state not in the state group, but its next state is within the state group;

4. Leaving jumping signal which has its current state in the group, but its next state is not within the group.

The concept is so simple that every experienced designer except you, KJ, who knew the above concept would have ideas on how to generate all related state machine circuits.

Weng

 

[KJ]

On Monday, December 2, 2019 at 11:02:59 PM UTC-5, Weng Tianxiang wrote:

And where are your experimental results that demonstrate something useful compared to current state of the art? That's all I've been asking...for years



Why I don't like to directly answer your questions long time ago, for years, can be found in above question as another example, because your most questions are pointless and make nonsense as this question.

Two things can be concluded from this:
- When you make a claim but you have no evidence to support that claim, you consider the request to provide evidence to support your claim to be pointless and nonsense.
- You don't have any evidence to support your claims

This has been demonstrated to be true here on this thread and just about every other posting you've done in newsgroups in the past.

AS A PATENT, DO I NEED TO DO EXPERIMENTS TO DEMONSTRATE THAT MY CIRCUITS WOULD REDUCE POWER ASSUMPTION? A REALLY STUPID QUESTION!!!
So if I was interested in purchasing the rights to your patent and I asked for your test results that back your claim of reduced power consumption before I would cut you a check, this is how you would respond. That speaks volumes.

You come to this newsgroup and comp.lang.vhdl typically spouting garbage. In a number of cases in the past I've shown your claims to be garbage by providing evidence that completely contradicts your claim. You ignore that evidence but can't refute it. When I ask for your test data that supports your claim, you go off on a rant like you've done here again, because you have nothing.

Why don't you find and post to some 'Snake Oil Salesman' newsgroup instead? Maybe there is a sub-group for rude salesman that would suit you. Looking here for a shill here isn't getting you anywhere.

You have nothing technical to back up anything you say here, and that is likely true for any of your patents as well.

Done with this thread with you. Good luck hawking your patents. You should probably hope that nobody searches your name and runs across your newsgroup postings.

Kevin Jennings