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

> 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



 

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.

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

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

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

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