New coding method for a state machine in groups in HDL

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

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

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

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

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

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.

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

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

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

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