Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 160425

Article: 160425
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Sat, 20 Jan 2018 19:20:26 +0000
Links: << >>  << T >>  << A >>
On Fri, 19 Jan 2018 17:42:57 -0500
rickman <gnuarm.deletethisbit@gmail.com> wrote:

   ...

> I think I understand the concept of wave pipelining.  It is
> just eliminating the intermediate registers of a pipeline
> circuit and designing the combinational logic so that the
> delays are even enough across the many paths so the output can
> be clocked at a given time and will receive a stable result
> from the input N clocks earlier.  In other words, the logic is
> designed so that the changes rippling through the logic never
> catch up to the changes created by the data entered 1 clock
> cycle earlier.  Nice if you can do it.

Thanks, interesting, but sounds complex to get reliable
operation. 

> I can see where this would be useful in an ASIC.  In ASICs FFs
> and logic compete for space within the chip.  In FPGAs the
> ratio between FFs and logic are fixed and predetermined.  So
> using logic without using the FFs that are already there is
> not of much value.

Generally true, but

1) You might be able to combine three stages that require 2/3 of
a clock cycle for maximum propagation delay, and get the result
in in the time of two clock cycles. 

2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
each tile can be a latch or a LUT, so flops are not wasted. 

Either way there must be a great deal of complex floor planning
and/or timing constraints needed to make this work. Automating
this would be amazing?

Jan Coombs


Article: 160426
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Sat, 20 Jan 2018 19:16:51 -0500
Links: << >>  << T >>  << A >>
Jan Coombs wrote on 1/20/2018 2:20 PM:
> On Fri, 19 Jan 2018 17:42:57 -0500
> rickman <gnuarm.deletethisbit@gmail.com> wrote:
>
>    ...
>
>> I think I understand the concept of wave pipelining.  It is
>> just eliminating the intermediate registers of a pipeline
>> circuit and designing the combinational logic so that the
>> delays are even enough across the many paths so the output can
>> be clocked at a given time and will receive a stable result
>> from the input N clocks earlier.  In other words, the logic is
>> designed so that the changes rippling through the logic never
>> catch up to the changes created by the data entered 1 clock
>> cycle earlier.  Nice if you can do it.
>
> Thanks, interesting, but sounds complex to get reliable
> operation.
>
>> I can see where this would be useful in an ASIC.  In ASICs FFs
>> and logic compete for space within the chip.  In FPGAs the
>> ratio between FFs and logic are fixed and predetermined.  So
>> using logic without using the FFs that are already there is
>> not of much value.
>
> Generally true, but
>
> 1) You might be able to combine three stages that require 2/3 of
> a clock cycle for maximum propagation delay, and get the result
> in in the time of two clock cycles.

If your stages are only using 2/3 of a clock, you can regroup the logic to 
make it 1 clock each in two stages.  There is supposed to be software to 
handle that for you although I've never used it.


> 2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
> each tile can be a latch or a LUT, so flops are not wasted.

There's your first mistake, no one uses Actel/Microsemi FPGAs.  They long 
for the day they are as big as Lattice, lol!


> Either way there must be a great deal of complex floor planning
> and/or timing constraints needed to make this work. Automating
> this would be amazing?

Isn't that what the OP is claiming?  I'm surprised he could make this work 
over PVT.  The actual stable time has to be on a clock edge, the same clock 
edge under all conditions.  I wouldn't want to try that manually in a simple 
circuit.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160427
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 21 Jan 2018 08:22:45 -0800 (PST)
Links: << >>  << T >>  << A >>
On Saturday, January 20, 2018 at 4:17:02 PM UTC-8, rickman wrote:
> Jan Coombs wrote on 1/20/2018 2:20 PM:
> > On Fri, 19 Jan 2018 17:42:57 -0500
> > rickman <gnuarm.deletethisbit@gmail.com> wrote:
> >
> >    ...
> >
> >> I think I understand the concept of wave pipelining.  It is
> >> just eliminating the intermediate registers of a pipeline
> >> circuit and designing the combinational logic so that the
> >> delays are even enough across the many paths so the output can
> >> be clocked at a given time and will receive a stable result
> >> from the input N clocks earlier.  In other words, the logic is
> >> designed so that the changes rippling through the logic never
> >> catch up to the changes created by the data entered 1 clock
> >> cycle earlier.  Nice if you can do it.
> >
> > Thanks, interesting, but sounds complex to get reliable
> > operation.
> >
> >> I can see where this would be useful in an ASIC.  In ASICs FFs
> >> and logic compete for space within the chip.  In FPGAs the
> >> ratio between FFs and logic are fixed and predetermined.  So
> >> using logic without using the FFs that are already there is
> >> not of much value.
> >
> > Generally true, but
> >
> > 1) You might be able to combine three stages that require 2/3 of
> > a clock cycle for maximum propagation delay, and get the result
> > in in the time of two clock cycles.
>=20
> If your stages are only using 2/3 of a clock, you can regroup the logic t=
o=20
> make it 1 clock each in two stages.  There is supposed to be software to=
=20
> handle that for you although I've never used it.
>=20
>=20
> > 2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
> > each tile can be a latch or a LUT, so flops are not wasted.
>=20
> There's your first mistake, no one uses Actel/Microsemi FPGAs.  They long=
=20
> for the day they are as big as Lattice, lol!
>=20
>=20
> > Either way there must be a great deal of complex floor planning
> > and/or timing constraints needed to make this work. Automating
> > this would be amazing?
>=20
> Isn't that what the OP is claiming?  I'm surprised he could make this wor=
k=20
> over PVT.  The actual stable time has to be on a clock edge, the same clo=
ck=20
> edge under all conditions.  I wouldn't want to try that manually in a sim=
ple=20
> circuit.
>=20
> --=20
>=20
> Rick C
>=20
> Viewed the eclipse at Wintercrest Farms,
> on the centerline of totality since 1998

Rick=EF=BC=8C

SMB stands for Series Master component with Buffering function, one of 2 WP=
C (Wive-Pipelining Component).

I don't understand what you are saying:=20
"Isn't that what the OP is claiming?  I'm surprised he could make this work=
=20
over PVT. "

What do OP and PVT stand for?

My attention on this topic is centered on introduction of my inventions to =
public and asking for their critical comments, challenge or suspicion from =
technical point of view, not specially on whether or not they are useful.

Personally I never have a chance to write a pipelined circuit, not mention =
designing for a wave-pipelined circuit.

What I did is a result of my observation that such an important problem can=
 be perfectly resolved by my insight as a person outside the wave-pipelined=
 design circle, fully based on only one reference=20
[1] IEEE  Transactions on VLSI Systems=20
http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.90.1783&rep=3Dre=
p1&type=3Dpdf .=20

Weng


Article: 160428
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Sun, 21 Jan 2018 16:44:04 +0000
Links: << >>  << T >>  << A >>
On Sun, 21 Jan 2018 08:22:45 -0800 (PST)
Weng Tianxiang <wtxwtx@gmail.com> wrote:

[much irrelevant stuff snipped - please help with this]

> My attention on this topic is centered on introduction of my
> inventions to public and asking for their critical comments,
> challenge or suspicion from technical point of view, not
> specially on whether or not they are useful.

I was unable to quickly understand the "2 fast reading
materials" which you sent me. 

> Personally I never have a chance to write a pipelined circuit,
> not mention designing for a wave-pipelined circuit.

Why do you have patents. A patent should disclose the method of
the novelty, so would need an implementation. Perhaps this is
what I am missing?

> What I did is a result of my observation that such an
> important problem can be perfectly resolved by my insight as a
> person outside the wave-pipelined design circle, fully based
> on only one reference [1] IEEE  Transactions on VLSI Systems
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.1783&rep=rep1&type=pdf .

Perhaps if you follow wave-pipelined techniques to the limit, you
will find yourself looking at asynchronous (or self clocked)
logic. There is also much historical work on this, and it may
be easier to test on FPGA chips[1]. 

Jan Coombs
-- 
[1] or at least drum up some business for Microsemi/Actel

Article: 160429
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: HT-Lab <hans64@htminuslab.com>
Date: Sun, 21 Jan 2018 18:19:55 +0000
Links: << >>  << T >>  << A >>
On 21/01/2018 00:16, rickman wrote:
> Jan Coombs wrote on 1/20/2018 2:20 PM:
>> On Fri, 19 Jan 2018 17:42:57 -0500
>> rickman <gnuarm.deletethisbit@gmail.com> wrote:
>>
>>    ...
>>
>>> I think I understand the concept of wave pipelining.  It is
>>> just eliminating the intermediate registers of a pipeline
>>> circuit and designing the combinational logic so that the
>>> delays are even enough across the many paths so the output can
>>> be clocked at a given time and will receive a stable result
>>> from the input N clocks earlier.  In other words, the logic is
>>> designed so that the changes rippling through the logic never
>>> catch up to the changes created by the data entered 1 clock
>>> cycle earlier.  Nice if you can do it.
>>
>> Thanks, interesting, but sounds complex to get reliable
>> operation.
>>
>>> I can see where this would be useful in an ASIC.  In ASICs FFs
>>> and logic compete for space within the chip.  In FPGAs the
>>> ratio between FFs and logic are fixed and predetermined.  So
>>> using logic without using the FFs that are already there is
>>> not of much value.
>>
>> Generally true, but
>>
>> 1) You might be able to combine three stages that require 2/3 of
>> a clock cycle for maximum propagation delay, and get the result
>> in in the time of two clock cycles.
> 
> If your stages are only using 2/3 of a clock, you can regroup the logic 
> to make it 1 clock each in two stages.  There is supposed to be software 
> to handle that for you although I've never used it.
> 
> 
>> 2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
>> each tile can be a latch or a LUT, so flops are not wasted.
> 
> There's your first mistake, no one uses Actel/Microsemi FPGAs.  They 
> long for the day they are as big as Lattice, lol!

Microsemi has been at the number 3 spot for as long as I use FPGA's (+/- 
28 years starting with Actel's A1010). They are twice as large as Lattice.

Here is a reference:

https://www.eetimes.com/author.asp?doc_id=1331443

Hans
www.ht-lab.com


> 
>> Either way there must be a great deal of complex floor planning
>> and/or timing constraints needed to make this work. Automating
>> this would be amazing?
> 
> Isn't that what the OP is claiming?  I'm surprised he could make this 
> work over PVT.  The actual stable time has to be on a clock edge, the 
> same clock edge under all conditions.  I wouldn't want to try that 
> manually in a simple circuit.
> 


Article: 160430
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 21 Jan 2018 13:24:17 -0500
Links: << >>  << T >>  << A >>
On 1/21/18 11:22 AM, Weng Tianxiang wrote:
> What do OP and PVT stand for?
> 

OP = Original Poster, the person who started the topic

PVT = Process / Voltage / Temperature (I presume)

The issue being that gate delay isn't a hard fixed value, but changes 
slightly (or not so slightly) from device to device and under varying 
operating conditions, which brings in to question the designing of a 
gate tree that presents results stably and reliably two clock cycles 
after application, even with the inputs changing after one clock cycles.

Article: 160431
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 21 Jan 2018 11:15:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Sunday, January 21, 2018 at 8:44:09 AM UTC-8, Jan Coombs wrote:
> On Sun, 21 Jan 2018 08:22:45 -0800 (PST)
> Weng Tianxiang <wtxwtx@gmail.com> wrote:
>=20
> [much irrelevant stuff snipped - please help with this]
>=20
> > My attention on this topic is centered on introduction of my
> > inventions to public and asking for their critical comments,
> > challenge or suspicion from technical point of view, not
> > specially on whether or not they are useful.
>=20
> I was unable to quickly understand the "2 fast reading
> materials" which you sent me.=20
>=20
> > Personally I never have a chance to write a pipelined circuit,
> > not mention designing for a wave-pipelined circuit.
>=20
> Why do you have patents. A patent should disclose the method of
> the novelty, so would need an implementation. Perhaps this is
> what I am missing?
>=20
> > What I did is a result of my observation that such an
> > important problem can be perfectly resolved by my insight as a
> > person outside the wave-pipelined design circle, fully based
> > on only one reference [1] IEEE  Transactions on VLSI Systems
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.90.1783&rep=
=3Drep1&type=3Dpdf .
>=20
> Perhaps if you follow wave-pipelined techniques to the limit, you
> will find yourself looking at asynchronous (or self clocked)
> logic. There is also much historical work on this, and it may
> be easier to test on FPGA chips[1].=20
>=20
> Jan Coombs
> --=20
> [1] or at least drum up some business for Microsemi/Actel

Jam,

I don't think you are right: "Perhaps if you follow wave-pipelined techniqu=
es to the limit, you will find yourself looking at asynchronous (or self cl=
ocked) logic."

I had studied the asynchronous circuit, but found that it is a dead road ba=
sed on its structural inefficiency and current commercial trend. And coding=
 or synthesizing a wave-pipelined circuit has nothing to do with their coun=
terpart for an asynchronous circuit, and the former is much more complex th=
an asynchronous circuit!=20

Synthesizing a wave-pipelined circuit needs much more complex algorithms th=
at have been matured since 1969 based on my observation.=20

My design never considers PVT, it belongs to another specialty field and I =
have zero knowledge on it.

From my point of view building a bridge between a code designer and a synth=
esizer is a very important issue to publicize the technology for wave-pipel=
ined circuits:

in 1980 Intel published and developed 8087 for 32-bit floating multiplier; =
10 and more years later, in 1997 they claimed MMX technology, including a s=
econd version of 64-bit floating multiplier. From my point of view the seco=
nd version of 64-bit floating multiplier using MMX technology is none but a=
 technology using wave-pipelined circuit.=20

Regular engineers never have a chance to implement a wave-pipelined circuit=
 because of the complexity of all related PVT.

But according to my scheme, the most complex part of generating a wave-pipe=
lined circuit is fully left to synthesizer manufacturers and a code designe=
r in HDL only focuses his attention to how to code it with zero knowledge a=
bout how a wave-pipelined circuit is synthesized and generated that hopeful=
ly leads to a situation that any college student with basic knowledge in HD=
L can generate the second version of 64-bit floating multiplier within half=
 an hour.

As far as 2 fast reading materials are concerned, please communicate with m=
e through private email and let me know what you want: specification, drawi=
ng and source code in VHDL. Sorry, I mistakenly thought you were a lawyer, =
not an engineer.

Thank you.

Weng

Article: 160432
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 06:46:31 -0500
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote on 1/21/2018 11:22 AM:
> On Saturday, January 20, 2018 at 4:17:02 PM UTC-8, rickman wrote:
>> Jan Coombs wrote on 1/20/2018 2:20 PM:
>>> On Fri, 19 Jan 2018 17:42:57 -0500
>>> rickman <gnuarm.deletethisbit@gmail.com> wrote:
>>>
>>>    ...
>>>
>>>> I think I understand the concept of wave pipelining.  It is
>>>> just eliminating the intermediate registers of a pipeline
>>>> circuit and designing the combinational logic so that the
>>>> delays are even enough across the many paths so the output can
>>>> be clocked at a given time and will receive a stable result
>>>> from the input N clocks earlier.  In other words, the logic is
>>>> designed so that the changes rippling through the logic never
>>>> catch up to the changes created by the data entered 1 clock
>>>> cycle earlier.  Nice if you can do it.
>>>
>>> Thanks, interesting, but sounds complex to get reliable
>>> operation.
>>>
>>>> I can see where this would be useful in an ASIC.  In ASICs FFs
>>>> and logic compete for space within the chip.  In FPGAs the
>>>> ratio between FFs and logic are fixed and predetermined.  So
>>>> using logic without using the FFs that are already there is
>>>> not of much value.
>>>
>>> Generally true, but
>>>
>>> 1) You might be able to combine three stages that require 2/3 of
>>> a clock cycle for maximum propagation delay, and get the result
>>> in in the time of two clock cycles.
>>
>> If your stages are only using 2/3 of a clock, you can regroup the logic to
>> make it 1 clock each in two stages.  There is supposed to be software to
>> handle that for you although I've never used it.
>>
>>
>>> 2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
>>> each tile can be a latch or a LUT, so flops are not wasted.
>>
>> There's your first mistake, no one uses Actel/Microsemi FPGAs.  They long
>> for the day they are as big as Lattice, lol!
>>
>>
>>> Either way there must be a great deal of complex floor planning
>>> and/or timing constraints needed to make this work. Automating
>>> this would be amazing?
>>
>> Isn't that what the OP is claiming?  I'm surprised he could make this work
>> over PVT.  The actual stable time has to be on a clock edge, the same clock
>> edge under all conditions.  I wouldn't want to try that manually in a simple
>> circuit.
>>
>> --
>>
>> Rick C
>>
>> Viewed the eclipse at Wintercrest Farms,
>> on the centerline of totality since 1998
>
> Rick,
>
> SMB stands for Series Master component with Buffering function, one of 2 WPC (Wive-Pipelining Component).
>
> I don't understand what you are saying:
> "Isn't that what the OP is claiming?  I'm surprised he could make this work
> over PVT. "
>
> What do OP and PVT stand for?

OP means "original poster" and is a common abbreviation in newsgroups.  PVT 
means Process, Voltage, Temperature and are the three main factors causing 
variations in delay times in silicon chip.  If you don't account for these 
effects in your timing calculations you wave pipelining idea won't work.  If 
you aren't aware of this, I suspect you don't really understand how to 
design FPGA devices.  It isn't all text book analysis.


> My attention on this topic is centered on introduction of my inventions to public and asking for their critical comments, challenge or suspicion from technical point of view, not specially on whether or not they are useful.
>
> Personally I never have a chance to write a pipelined circuit, not mention designing for a wave-pipelined circuit.
>
> What I did is a result of my observation that such an important problem can be perfectly resolved by my insight as a person outside the wave-pipelined design circle, fully based on only one reference
> [1] IEEE  Transactions on VLSI Systems
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.1783&rep=rep1&type=pdf .

Then I think you have not solved anything.  The problem with wave pipelining 
is that the timing can vary so much that the output of the combinational 
circuit won't be stable during the clock edges.  If you haven't tested your 
ideas by designing a circuit and running it on an FPGA, you don't know any 
of this will work in the real world.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160433
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 06:53:33 -0500
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote on 1/21/2018 2:15 PM:
> On Sunday, January 21, 2018 at 8:44:09 AM UTC-8, Jan Coombs wrote:
>> On Sun, 21 Jan 2018 08:22:45 -0800 (PST)
>> Weng Tianxiang <wtxwtx@gmail.com> wrote:
>>
>> [much irrelevant stuff snipped - please help with this]
>>
>>> My attention on this topic is centered on introduction of my
>>> inventions to public and asking for their critical comments,
>>> challenge or suspicion from technical point of view, not
>>> specially on whether or not they are useful.
>>
>> I was unable to quickly understand the "2 fast reading
>> materials" which you sent me.
>>
>>> Personally I never have a chance to write a pipelined circuit,
>>> not mention designing for a wave-pipelined circuit.
>>
>> Why do you have patents. A patent should disclose the method of
>> the novelty, so would need an implementation. Perhaps this is
>> what I am missing?
>>
>>> What I did is a result of my observation that such an
>>> important problem can be perfectly resolved by my insight as a
>>> person outside the wave-pipelined design circle, fully based
>>> on only one reference [1] IEEE  Transactions on VLSI Systems
>>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.1783&rep=rep1&type=pdf .
>>
>> Perhaps if you follow wave-pipelined techniques to the limit, you
>> will find yourself looking at asynchronous (or self clocked)
>> logic. There is also much historical work on this, and it may
>> be easier to test on FPGA chips[1].
>>
>> Jan Coombs
>> --
>> [1] or at least drum up some business for Microsemi/Actel
>
> Jam,
>
> I don't think you are right: "Perhaps if you follow wave-pipelined techniques to the limit, you will find yourself looking at asynchronous (or self clocked) logic."
>
> I had studied the asynchronous circuit, but found that it is a dead road based on its structural inefficiency and current commercial trend. And coding or synthesizing a wave-pipelined circuit has nothing to do with their counterpart for an asynchronous circuit, and the former is much more complex than asynchronous circuit!
>
> Synthesizing a wave-pipelined circuit needs much more complex algorithms that have been matured since 1969 based on my observation.
>
> My design never considers PVT, it belongs to another specialty field and I have zero knowledge on it.
>
> From my point of view building a bridge between a code designer and a synthesizer is a very important issue to publicize the technology for wave-pipelined circuits:
>
> in 1980 Intel published and developed 8087 for 32-bit floating multiplier; 10 and more years later, in 1997 they claimed MMX technology, including a second version of 64-bit floating multiplier. From my point of view the second version of 64-bit floating multiplier using MMX technology is none but a technology using wave-pipelined circuit.
>
> Regular engineers never have a chance to implement a wave-pipelined circuit because of the complexity of all related PVT.
>
> But according to my scheme, the most complex part of generating a wave-pipelined circuit is fully left to synthesizer manufacturers and a code designer in HDL only focuses his attention to how to code it with zero knowledge about how a wave-pipelined circuit is synthesized and generated that hopefully leads to a situation that any college student with basic knowledge in HDL can generate the second version of 64-bit floating multiplier within half an hour.

The multiplier is not a good example to use as many FPGAs contain multiplier 
blocks.  But then they are pipelined and so won't work in a non-pipelined 
solution, so maybe you can show your technique even if it has little 
practical value in this case.

The problem is "the most complex part of generating a wave-pipelined circuit 
is fully left to synthesizer manufacturers".  Your method leaves me 
wondering what your software is doing???  Asking the synthesizer companies 
to solve your problems of making it work is a bit of a stretch.  What makes 
you think they will even take on your idea rather than provide their own 
solution.

If your patent only covers the idea of writing simple HDL to describe the 
circuit desired and leaving the implementation details to the synthesis 
companies, I don't think you have actually patented anything.  This part if 
very obvious.  The *real* work is in synthesizing a circuit that will work 
in the FPGA.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160434
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 06:57:04 -0500
Links: << >>  << T >>  << A >>
Richard Damon wrote on 1/21/2018 1:24 PM:
> On 1/21/18 11:22 AM, Weng Tianxiang wrote:
>> What do OP and PVT stand for?
>>
>
> OP = Original Poster, the person who started the topic
>
> PVT = Process / Voltage / Temperature (I presume)
>
> The issue being that gate delay isn't a hard fixed value, but changes
> slightly (or not so slightly) from device to device and under varying
> operating conditions, which brings in to question the designing of a gate
> tree that presents results stably and reliably two clock cycles after
> application, even with the inputs changing after one clock cycles.

MUCH more than slightly.  The numbers I have been told is 2:1 is not 
uncommon.  That's why overclockers can get CPU chips to run *much* faster 
than they are rated.  They provide very excellent cooling, tweak the PSU 
voltage and select their special chips.

This is also why we use synchronous logic with registers for pipelines.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160435
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 07:18:43 -0500
Links: << >>  << T >>  << A >>
HT-Lab wrote on 1/21/2018 1:19 PM:
> On 21/01/2018 00:16, rickman wrote:
>> Jan Coombs wrote on 1/20/2018 2:20 PM:
>>> On Fri, 19 Jan 2018 17:42:57 -0500
>>> rickman <gnuarm.deletethisbit@gmail.com> wrote:
>>>
>>>    ...
>>>
>>>> I think I understand the concept of wave pipelining.  It is
>>>> just eliminating the intermediate registers of a pipeline
>>>> circuit and designing the combinational logic so that the
>>>> delays are even enough across the many paths so the output can
>>>> be clocked at a given time and will receive a stable result
>>>> from the input N clocks earlier.  In other words, the logic is
>>>> designed so that the changes rippling through the logic never
>>>> catch up to the changes created by the data entered 1 clock
>>>> cycle earlier.  Nice if you can do it.
>>>
>>> Thanks, interesting, but sounds complex to get reliable
>>> operation.
>>>
>>>> I can see where this would be useful in an ASIC.  In ASICs FFs
>>>> and logic compete for space within the chip.  In FPGAs the
>>>> ratio between FFs and logic are fixed and predetermined.  So
>>>> using logic without using the FFs that are already there is
>>>> not of much value.
>>>
>>> Generally true, but
>>>
>>> 1) You might be able to combine three stages that require 2/3 of
>>> a clock cycle for maximum propagation delay, and get the result
>>> in in the time of two clock cycles.
>>
>> If your stages are only using 2/3 of a clock, you can regroup the logic to
>> make it 1 clock each in two stages.  There is supposed to be software to
>> handle that for you although I've never used it.
>>
>>
>>> 2) If the Microsemi/Actel Igloo/Smartfusion FPGAs are used then
>>> each tile can be a latch or a LUT, so flops are not wasted.
>>
>> There's your first mistake, no one uses Actel/Microsemi FPGAs.  They long
>> for the day they are as big as Lattice, lol!
>
> Microsemi has been at the number 3 spot for as long as I use FPGA's (+/- 28
> years starting with Actel's A1010). They are twice as large as Lattice.
>
> Here is a reference:
>
> https://www.eetimes.com/author.asp?doc_id=1331443

There's some BS somewhere...

http://www.fpgadeveloper.com/2011/07/list-and-comparison-of-fpga-companies.html

More importantly, look at the numbers in your link.  The Actell/Microsemi 
numbers are going in the wrong direction!  X, A and L are headed upward 
year-to-year and Actel is headed down!

While looking this up I found a link indicating the JTAG interface of the 
ProASIC3 devices has a back door which would allow their security to be 
bypassed.  Security was their claim to fame and this could be a major blow 
to the company.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160436
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 22 Jan 2018 10:39:19 -0800 (PST)
Links: << >>  << T >>  << A >>
> The multiplier is not a good example to use as many FPGAs contain multiplier 
> blocks.  But then they are pipelined and so won't work in a non-pipelined 
> solution, so maybe you can show your technique even if it has little 
> practical value in this case.
> 
> Rick C
>

What I patented in my patents is a method on how to code a wave-pipelined circuit in HDL (not only in VHDL, but all HDLs) by a circuit designer, nothing else. If you slightly change the code, a 64x64 bits floating multiplier can be generated!!!

If anybody uses HDL to code, he has nothing to do with PVT, never put PVT into consideration, not me, not you, nobody does it!!! That is other ones' business.

Based on my method what you need to do is that you just describe the logic for the critical path, and call a library to finish your job, nothing else,  all others are left to Xilinx or Altera to do!

If you are really interested in a real good FPGA example, I recommend you reading following one paper on website:
Wave-pipelined intra-chip signaling for on-FPGA communications
http://www.doc.ic.ac.uk/~wl/papers/10/integration10tm.pdf

There are numerous circuits in FPGA that are worth being the wave-pipelined circuits.

Weng

Article: 160437
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 16:56:59 -0500
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote on 1/22/2018 1:39 PM:
>> The multiplier is not a good example to use as many FPGAs contain multiplier
>> blocks.  But then they are pipelined and so won't work in a non-pipelined
>> solution, so maybe you can show your technique even if it has little
>> practical value in this case.
>>
>> Rick C
>>
>
> What I patented in my patents is a method on how to code a wave-pipelined circuit in HDL (not only in VHDL, but all HDLs) by a circuit designer, nothing else. If you slightly change the code, a 64x64 bits floating multiplier can be generated!!!

I'm not sure what you are talking about.  The code example you gave is 
exactly the same code anyone would write for a multiplier.  The HDL is no 
different.  So how can the patent be about how to code the wave-pipelined 
circuit?  Or did I miss something in the code?


> If anybody uses HDL to code, he has nothing to do with PVT, never put PVT into consideration, not me, not you, nobody does it!!! That is other ones' business.

I have no idea what you are talking about.  HDL is used to design FPGAs and 
ASICs.  Part of that design process is meeting timing.  Someone, somewhere 
has to make the timing work.  The tool vendor provides timing data 
accessible through a timing analysis tool that can be applied to your 
synthesized design.  But if you wish to do wave-pipelined design the logic 
has to be constructed in a way to balance the timing delays so the 
uncertainty at the output of the combinatorial circuit fits within a clock 
cycle *including the variation in timing from PVT*!!!  So it is impossible 
to do wave-pipelined design without considering PVT effects on the timing.

I have no idea what you mean by it "is other ones' business".  This has to 
be defined for a wave-pipelined design to work.  THAT is where the work is, 
not in talking about the HDL which is the same as for a non pipelined design.


> Based on my method what you need to do is that you just describe the logic for the critical path, and call a library to finish your job, nothing else,  all others are left to Xilinx or Altera to do!

Then you have done nothing...


> If you are really interested in a real good FPGA example, I recommend you reading following one paper on website:
> Wave-pipelined intra-chip signaling for on-FPGA communications
> http://www.doc.ic.ac.uk/~wl/papers/10/integration10tm.pdf
>
> There are numerous circuits in FPGA that are worth being the wave-pipelined circuits.

I would like to read your patent to see just what you are patenting.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160438
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 22 Jan 2018 14:39:22 -0800 (PST)
Links: << >>  << T >>  << A >>
On Friday, January 19, 2018 at 8:45:26 AM UTC-8, Weng Tianxiang wrote:
>=20
> 1. If my CPC_1_2 code is presented to a synthesizer, the first question y=
ou may ask is how do you code your WPC (Wive-Pipelining Component). For cla=
rity, I copied the CPC_1_2 code here again.
>=20
> By the way, I claim that nobody can further simplify the CPC_1_2 code to =
deliver full information about a critical path to a synthesizer for generat=
ing a wave-pipelined circuit! If you can, please challenge my claim.=20
>=20
> entity CPC_1_2 is=20
>    generic (  =20
>       input_data_width  : positive  :=3D 64;                  -- optional=
=20
>       output_data_width : positive  :=3D 128                  -- optional=
=20
>    );=20
>    port (=20
>       CLK   :  in std_logic;=20
>       WE_i  :  in std_logic;     -- '1': write enable to input registers =
A & B=20
>       Da_i  :  in signed(input_data_width-1 downto 0);      -- input data=
 A=20
>       Db_i  :  in signed(input_data_width-1 downto 0);      -- input data=
 B=20
>       WE_o_i:  in std_logic;  -- '1': write enable to output register C=
=20
>       Dc_o  :  out unsigned(output_data_width -1 downto 0)  -- output dat=
a C=20
>    );=20
> end CPC_1_2;=20
>=20
> architecture A_CPC_1_2 of CPC_1_2 is=20
>    signal   Ra :  signed(input_data_width-1 downto 0);  -- input register=
 A=20
>    signal   Rb :  signed(input_data_width-1 downto 0);  -- input register=
 B=20
>    signal   Rc :  signed(output_data_width-1 downto 0); -- output registe=
r C=20
>    signal   Cl :  signed(output_data_width-1 downto 0); -- combinational =
logic=20
>    =20
> begin=20
>    Cl    <=3D Ra * Rb;             -- combinational logic output, key par=
t of CPC=20
>    Dc_o  <=3D unsigned(Rc);        -- output through output register=20
>=20
>    p_1 : process(CLK)=20
>    begin=20
>       if Rising_edge(CLK) then=20
>          if WE_i =3D '1' then      -- WE_i =3D '1' : latch input data=20
>             Ra <=3D Da_i;=20
>             Rb <=3D Db_i;=20
>          end if;=20
>          =20
>          if WE_O_I =3D '1' then    -- WE_O_I =3D '1': latch output data=
=20
>             Rc <=3D Cl;=20
>          end if;=20
>       end if;=20
>    end process;=20
> end A_CPC_1_2;=20
>=20
> 2. Assume 3 situations:
> a) If you know that each data needs 5 cycles to pass the 64*64 bits signe=
d multiplexer and the circuit can accept one data per cycle, you should kno=
w how to code the WPC for the circuit. Because we have already assumed that=
 the synthesizer is capable of generating the wave-pipelined circuit for it=
, leaving most difficult task to the synthesizer. By definition a WPC conta=
ins all remaining logic for the circuit except the CPC_1_2.=20
>=20
> b) If you know that each data needs 5 cycles to pass the 64*64 bits signe=
d multiplexer and the circuit can accept one data per 2 cycles, you should =
know how to code the WPC for the circuit.
>=20
> c) If you know that each data needs 5 cycles to pass the 64*64 bits signe=
d multiplexer and the circuit can accept one data per 2 cycles, but the des=
igner wants the circuit to be able of accepting one data per cycle, not one=
 data per 2 cycles, you should know how to code the WPC for the circuit wit=
h 2 copies of critical paths and each alternatively accepting an input data=
 per 2 cycles. Actually all CPCs have 2 types of code patterns, CPC_1_2 is =
one of them and another CPC_3 is slightly complex, but is an off shelf codi=
ng pattern either.In this situation CPC_3 code would replace CPC_1_2 with s=
ame input and output interfaces.
>=20
> Now the problem comes: how do you know all 3 unknown parameters before yo=
u code the WPC for the 64*64 bits signed multiplexer? I think that this is =
the key reason why so many wave-pipelined circuits have been generated, but=
 none of the circuits designers can resolve the 50 years old open problem.
>=20
> And the circuit may, should and can be any type of pipelined circuits!
>=20
> To be continued.
>=20
> Weng

All coding for a wave-pipelined circuit has 3 steps:=20
1. Write a Critical Path Component (CPC) with defined interface;=20

2. Call a Wave-Pipelining Component (WPC) provided by a system library;=20

3. Call one of 3 link statement to link a CPC instantiation with a paired W=
PC instantiation to specify what your target is.=20

Now first it is assumed that CPC_1_2 coding is finished, because when codin=
g a new circuit it is very clear what is to code and the coding of a CPC fo=
r a wave-pipelined circuit never has any problem, leaving all special featu=
res related to critical path to a synthesizer to do, including correcting c=
ritical path unbalance logically.=20

Now second I am trying to code its WPC.=20

When coding the 64*64 bits signed multiplexer, I have listed 3 situations a=
s shown above in each of which there is an unknown constant before coding i=
ts WPC.

In case 1) each data needs 5 cycles to pass the 64*64 bits signed multiplex=
er. The 5 cycles isn't known until a synthesizer has analyzed the critical =
path.

In case b) the circuit can accept a data per 2 cycles.

In case c) multiple copies of a same critical path is 2.

Conventional method is:
fix the number as 3, 4, 5, 6,...then write the WPC code, synthesizer the ci=
rcuit, repeated again if the assumed value fails to generate a wave-pilelin=
ed circuit until it reaches a success, and so on.

I introduce a new concept WAVE CONSTANT:
A constant is defined as a wave constant in a WPC if its constant initial v=
alue is unknown and undetermined when the WPC is being coded, and will be a=
ssigned by a synthesizer after the synthesizer has analyzed the critical pa=
th.=20

In contract with a wave constant A regular constant must be defined with a =
fixed initial value.

And it also requires that the synthesizer must first analyze the CPC, then =
analyze its paired WPC.

By doing so coding a wave-pipelined circuit will never have any problem!

The strange thing here is that a wave constant does not appear in its CPC, =
but the CPC's structure determines its initial value, then the synthesizer =
assigns the determined initial value to the wave constant which appears onl=
y in the paired WPC.

Based on above 3 situations, I introduced 3 wave constants:
a) Series_clock_number is the number of cycles for signals to travel the cr=
itical path.

b) Input_clock_number is the number of cycles, under which the circuit can =
accept one data per Input_Clock_number cycles.

c) Multiple_copy_number is the number of copies of a same critical path in =
order to meet a requirement for the circuit to accept one data per cycle. T=
he requirement is required by a code designer.

By introducing a wave constant concept, code designers can smoothly and ful=
ly describe a wave-pipelined circuit in HDL without manual involvement.

Finally after the 3 WPC were coded, I found that all wave-pipelined circuit=
s are divided into 2 categories and each of 2 categories shares a same WPC =
component without exception. Then the 2 types of WPC can form a system libr=
ary and each of wave-pipelined circuits can call the library, avoiding codi=
ng same logic again and again.

To be continued.

Your comments are welcome.

Thank you.

Weng

Article: 160439
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 22 Jan 2018 15:19:50 -0800 (PST)
Links: << >>  << T >>  << A >>
> But if you wish to do wave-pipelined design the logic=20
> has to be constructed in a way to balance the timing delays so the=20
> uncertainty at the output of the combinatorial circuit fits within a cloc=
k=20
> cycle *including the variation in timing from PVT*!!!  So it is impossibl=
e=20
> to do wave-pipelined design without considering PVT effects on the timing=
.
>=20
> Rick C
>=20

The introduction of 3 link statements is used to inform a synthesizer that =
the CPC must be analyzed and generated as a wave-pipelined circuit instead =
of a regular one-cycle circuit. So the synthesizer would help you to genera=
te logic that would balance the timing among all paths.

Can you do better than what a synthesizer can do?

When inventing, you must be smarter, not limited by what your experience te=
lls you.

Weng


Article: 160440
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 21:35:51 -0500
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote on 1/22/2018 6:19 PM:
>> But if you wish to do wave-pipelined design the logic
>> has to be constructed in a way to balance the timing delays so the
>> uncertainty at the output of the combinatorial circuit fits within a clock
>> cycle *including the variation in timing from PVT*!!!  So it is impossible
>> to do wave-pipelined design without considering PVT effects on the timing..
>>
>> Rick C
>>
>
> The introduction of 3 link statements is used to inform a synthesizer that the CPC must be analyzed and generated as a wave-pipelined circuit instead of a regular one-cycle circuit. So the synthesizer would help you to generate logic that would balance the timing among all paths.
>
> Can you do better than what a synthesizer can do?

I haven't seen what a synthesizer can do.  Does anyone make a synthesizer 
that does this?


> When inventing, you must be smarter, not limited by what your experience tells you.

Uh, if experience tells me something can't be done, why would I try to do 
it?  That's the utility of experience, you don't have to go down every blind 
alley.

I've yet to see the utility in this idea.  I would expect the speed 
improvements to be small, if any and as I've mentioned, unless you get an 
FPGA vendor to modify their chip designs along with the synthesis vendors to 
modify their software, all at no small cost, this will not offer any 
improvement in FPGAs.

Since you have not even taken a look at the issue of making this work over 
PVT variations, I'm pretty sure it is not possible to even make it work in 
today's FPGAs.  There is just too much variation in timing of a single path 
to wave-pipeline even a row of inverters.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160441
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 22 Jan 2018 19:33:43 -0800 (PST)
Links: << >>  << T >>  << A >>
> I'm pretty sure it is not possible to even make it work in today's FPGAs.

If you don't know something, never say that it's impossible, in my point of=
 view, it is beyond your specialty.

> I've yet to see the utility in this idea.  I would expect the speed=20
improvements to be small, if any.

Intel has two versions of 64x64 bits floating multiplier, one used for comp=
atibility with previous 8087 version, and another is version of MMX technol=
ogy, a wave-pipelining technology. Based on web testing bench and Intel's l=
iterature, the wave-pipelined circuit version has 20% speed faster than its=
 8087 counterpart (4 cycle vs. 5 cycles). Additionally power consumption is=
 dramatically reduced. A 64x64 bits floating multiplier has the maximum of =
151 bits in one of 4 middle stages and you may calculate how many bits of r=
egisters have been saved!

> I've mentioned, unless you get an FPGA vendor to modify their chip design=
s along with the synthesis vendors to modify their software, all at no smal=
l cost, this will not offer any improvement in FPGAs.=20

Defining a new part of HDL specially for wave-pipelined circuit in ASIC and=
 FPGA and letting code designers own a corresponding simple and reliable de=
signing method is one thing, and letting synthesizers implement the new par=
t in HDL is another thing, as Jim, the chairman in VHDL, always asks people=
 here to push the synthesizers to implement new part in 2008-VHDL.=20

> I haven't seen what a synthesizer can do.  Does anyone make a synthesizer=
=20
that does this?=20

A synthesizer as a software needs an algorithm to do something fast and acc=
urate, and there have been more than effective 20-30 algorithms over there,=
 many of which were issued patents, a result you can get by simply using Go=
ogle to search for, so it is reasonable that I assumed from the beginning o=
f my project that the technique for synthesizing and generating a wave-pipe=
lined circuit is fully matured now and might have been matured 10-20 years =
ago.

Weng

Article: 160442
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: rickman <gnuarm.deletethisbit@gmail.com>
Date: Mon, 22 Jan 2018 23:01:15 -0500
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote on 1/22/2018 10:33 PM:
>> I'm pretty sure it is not possible to even make it work in today's FPGAs.
>
> If you don't know something, never say that it's impossible, in my point of view, it is beyond your specialty.

FPGAs *are* my specialty.  I think you are showing you know little about 
actually working with FPGAs.  You don't seem to understand that the ratio of 
logic to FFs is fixed in any given FPGA so saving registers is not of great 
value.  You also don't seem to understand that you have too much speed 
variation over PVT to even use wave-pipelining in an FPGA.

Do you understand either of these two issues?  Do you have a way around 
these limitations?


>> I've yet to see the utility in this idea.  I would expect the speed
> improvements to be small, if any.
>
> Intel has two versions of 64x64 bits floating multiplier, one used for compatibility with previous 8087 version, and another is version of MMX technology, a wave-pipelining technology. Based on web testing bench and Intel's literature, the wave-pipelined circuit version has 20% speed faster than its 8087 counterpart (4 cycle vs. 5 cycles). Additionally power consumption is dramatically reduced. A 64x64 bits floating multiplier has the maximum of 151 bits in one of 4 middle stages and you may calculate how many bits of registers have been saved!

This has nothing to do with "FPGAs" which is the target I was referring to.


>> I've mentioned, unless you get an FPGA vendor to modify their chip designs along with the synthesis vendors to modify their software, all at no small cost, this will not offer any improvement in FPGAs.
>
> Defining a new part of HDL specially for wave-pipelined circuit in ASIC and FPGA and letting code designers own a corresponding simple and reliable designing method is one thing, and letting synthesizers implement the new part in HDL is another thing, as Jim, the chairman in VHDL, always asks people here to push the synthesizers to implement new part in 2008-VHDL.

Adding this to the HDL is trivial.  The ENTIRE hard part is getting a 
synthesizer to support this by doing all the hard work.


>> I haven't seen what a synthesizer can do.  Does anyone make a synthesizer
> that does this?
>
> A synthesizer as a software needs an algorithm to do something fast and accurate, and there have been more than effective 20-30 algorithms over there, many of which were issued patents, a result you can get by simply using Google to search for, so it is reasonable that I assumed from the beginning of my project that the technique for synthesizing and generating a wave-pipelined circuit is fully matured now and might have been matured 10-20 years ago.

For FPGAs???

I notice you completely snipped the part about PVT variations in timing 
which very likely will be the stake driven through the heart of this approach.

Bottom line - if wave-pipelining were an advantage in FPGAs or even 
practical with benefit, one of the FPGA companies would be promoting it.  If 
they could get a 20% speed improvement, they would be jumping through hoops 
as it would give them a *huge* competitive advantage over the other FPGA 
companies.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Article: 160443
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Mon, 22 Jan 2018 22:31:31 -0800 (PST)
Links: << >>  << T >>  << A >>
> Bottom line - if wave-pipelining were an advantage in FPGAs or even 
> practical with benefit, one of the FPGA companies would be promoting it.  If 
> they could get a 20% speed improvement, they would be jumping through hoops 
> as it would give them a *huge* competitive advantage over the other FPGA 
> companies.
> 
> Rick C

I appreciate your above paragraph, at least a small step forward!

There are many Indian professors' papers on wave-pipelined circuits for FPGA. Here is one of them: Some Experiments about Wave Pipelining on FPGAs

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.2942&rep=rep1&type=pdf

Weng

Article: 160444
Subject: Clock distribution /Resynchronizing
From: Spehro Pefhany <spehro@gmail.com>
Date: Tue, 23 Jan 2018 08:20:36 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,=20

I would like to create and distribute a master clock and sync pulses to a n=
umber of boxes throughout a system. There will be some skew between the sig=
nals, of unknown sign. Probably the clock will be 24.576MHz and sync will b=
e in the kHz range.=20

At the receiving nodes the clocks have to be de-jittered and preferably the=
 two (or more) signals aligned with each other.=20

Right now it looks to me like the sensible way to do it is to use a zero de=
lay buffer, feed that into an FPGA and clock off both the rising and fallin=
g edges of a single clock signal (or alternatively to use just one edge of =
a two phase clock, but that increases the complexity). The signals are used=
 to clock and synchronize very precise Delta-Sigma ADCs.=20

Is clocking off both edges of an input signal a kosher approach to generati=
ng and relaying clocks? How should this be handled with the dedicated clock=
 input pins?=20

Looking at using a Lattice Mach02.=20

Thanks
--sp

Article: 160445
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: HT-Lab <hans64@htminuslab.com>
Date: Tue, 23 Jan 2018 17:48:22 +0000
Links: << >>  << T >>  << A >>
On 22/01/2018 12:18, rickman wrote:
> HT-Lab wrote on 1/21/2018 1:19 PM:
..
>>>
>>> There's your first mistake, no one uses Actel/Microsemi FPGAs.  They 
>>> long
>>> for the day they are as big as Lattice, lol!
>>
>> Microsemi has been at the number 3 spot for as long as I use FPGA's 
>> (+/- 28
>> years starting with Actel's A1010). They are twice as large as Lattice.
>>
>> Here is a reference:
>>
>> https://www.eetimes.com/author.asp?doc_id=1331443
> 
> There's some BS somewhere...
> 
> http://www.fpgadeveloper.com/2011/07/list-and-comparison-of-fpga-companies.html 
> 
Comparing a blogger article from 2011 who took some NASDAQ vales against 
eetimes which using a marketing survey company results from 2017, good job!

> 
> More importantly, look at the numbers in your link.  The 
> Actell/Microsemi numbers are going in the wrong direction!  X, A and L 
> are headed upward year-to-year and Actel is headed down!
> 
Sure, but Microsemi is still number 3 which was my point. In my day job 
I speak to more companies using Microsemi than Lattice (both dwarf 
against Xilinx and Intel though). That is not to say that Lattice makes 
bad FPGA's it is just that they haven't carved out a particular niche 
area like Microsemi or say Achronix.

> While looking this up I found a link indicating the JTAG interface of 
> the ProASIC3 devices has a back door which would allow their security to 
> be bypassed.  Security was their claim to fame and this could be a major 
> blow to the company.
> 

Made no impact on their business, they are still the number1 company for 
secure/space/avionics FPGA's. Also note ProASIC3 is nearly 10 years old.

Hans
www.ht-lab.com


Article: 160446
Subject: Re: HDL simple survey - what do you actually use
From: HT-Lab <hans64@htminuslab.com>
Date: Tue, 23 Jan 2018 19:30:20 +0000
Links: << >>  << T >>  << A >>
On 10/01/2018 20:29, already5chosen@yahoo.com wrote:
> On Wednesday, January 10, 2018 at 7:33:10 PM UTC+2, Rob Gaddi wrote:
>> On 01/10/2018 06:17 AM, john wrote:
..
>>>
>>
>> VHDL, for both synthesis and testbenching.  Some Verilog sneaks into my
>> design when vendor-provided IP cores only come that way, but I'm
>> read-only on it.
>>
>> -- 
>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com
>> Email address domain is currently out of order.  See above to fix.
> 
> The same here.
> And I don't believe in things like SystemC.

I do.

It is true SystemC is more for the C/C++ aficionados. However SystemC 
has a lot going for it, here are some quick points:

1) You get a simulator and all the support libraries in source for free.
2) If you know VHDL then you can easily program in SystemC (same model 
of signals, processes, variables, delta cycles etc). No horrible 
blocking/non-blocking, wire/reg, race spaghetti.
3) It is easy to learn and you don't have to dive to deep into C++.
4) It is great for behavioural modelling.
5) You can choose from many free and commercial IDE's.
6) There is a free UVM library.
7) It runs on many platforms (you just need a C++ compiler)
8) There is a synthesisable standard (albeit somewhat outdated)
9) There are a number of SystemC translators/synthesis tools available.
10) You can "embed" the OSCI engine into your product (bar the usual 
license agreement)
11) It is relative easy to bolt on any library you like Qt/SDL2.
12) It has the best TLM capabilities (SV uses the same models)
13) It has transaction recordings capabilities (SCV)
14) It has some assertion capabilities (PSL support would be great!)
15) It supports randomisation (like rand in SV) and contains a 
constraint solver.

The free nature of it is both a blessing and a curse. Because it is free 
commercial support is somewhat sluggish (Cadence being the exception). 
There are (AFAIK) no free RTL style IDE's which works as easily as 
VHDL/Verilog on Modelsim/VCS/NCSim/Riviera/etc. Using sc_trace and 
GTKWave is just too painful. There are products like Vista that come 
close but still not as slick as Modelsim. I tried to write something but 
underestimated the amount of free time it takes to create something 
barely usable.

So for pure RTL designs I agree that you can't beat good old VHDL and SV 
(forget about Verilog).

To answer the OP's question, VHDL for design and 
VHDL/SystemC/PSL/FLI/Tcl for testbenches. I do try to keep up with SV as 
a good engineer needs to know both.

Regards,
Hans
www.ht-lab.com



Article: 160447
Subject: Re: My invention: Coding wave-pipelined circuits with buffering function
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 23 Jan 2018 20:10:13 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <93899eff-01a7-4e78-8076-17febc2c8f0c@googlegroups.com>,
Weng Tianxiang  <wtxwtx@gmail.com> wrote:
>Hi,
>
>A wive-pipelined circuit has the same logic as its pipeline counterpart except that the wive-pipelined circuit has only one stage, a critical path
>from the input register passing through a piece of computational logic to the output register, and no intermediate registers.

Weng,

I read along and not commented here.  But I find it's harder to ignore..
I've read up on some of the references you've posted.  I think I've now got
a fairly good idea as to what this wave-pipelining thing is now.  So 
thanks for the refenences.

But you've repeated claimed that your patent doesn't need to deal with PVT
variations - that's a problem for the synthesizer...

PVT variations is the elephant in the room.  It's why wave-pipelining (and
other asynchronous design techniques) have failed to grab any hold outside 
research facilities.  It's a very difficult problem to solve.   And it's 
only getting worse at each lower technology node.

Now some of the papers you cite offer some fairly clever solutions that FPGA
manufactures COULD use to try and enable more wave-pipelined solutions - the
one paper cited referred to small inline PLLs along the switch network to 
allow delays to be more matched.  Interesting solutions.  But one that 
the FPGA manufactures would have to take and implement.  There's nothing
for us end FPGA users to use.  The underlying technology just doesn't enable
end users to use wave-pipelining solutions in todays FPGAs.  Because of the PVT 
variation problem.  (and simply calling it "PVT" variation falsely
implies that just those three variables matter.  There's many, many more
variables that affect the variation distribution)

Now as to your patent claim.  I'm unsure at all what you're trying to claim.
You list as an example a straightforward, and very basic pipelined datapath
example.  One that matches thousands of others already in existance and prior
art.  It's an input pipeline register, and large combinational cloud, and an
output pipeline register.  Described in VHDL.  I fail to see anything at all
novel there.  But you claim that an undescribed, unbuilt tool could then 
take such code and implement a wave-pipeline with it?   That someone else
would have to build?

In another thread you seem to be claiming that the tool could automatically
determing the latency, and/or clock rate and/or "how many waves" are in
flight along the wave-pipeline circuit?  That belies how design is done - it's
putting the cart before the horse.  And is a common misconception of new users to 
FPGAs designing even traditional pipelined design.  

A common question that new users ask is "how fast can I make this pipelined 
design run?".  The experienced designer then answers - that's not how it's done. 
The experienced designer has a specific problem that's trying to be solve - not 
trying to see "how fast it can run".  The designer must guide the tool towards a 
solution with a latency / clock rate / "how many waves" as a design goal up front.
Not a derived solution output from the tool.  The designer must know these up front
so as to design the entire solution.  How does the designer know what 
values are realistic goals?  Experience.  That's engineering.

So, my 3 cents.  Wave-pipelines are in a class of asynchronous design techniques
that's of no use to current FPGA users.  Perhaps if Xilinx or Altera (er, Intel) 
or even some up and coming startup decides to utilize some of the techniques in the 
cited papers, we may see something in the next couple of decades.  Personally, I doubt it.

Regards,

Mark 



Article: 160448
Subject: Re: My invention: Coding wave-pipelined circuits with buffering
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 23 Jan 2018 13:48:33 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Mark,

Good question!

PVT is very complex problem beyond the ordinary people's reach, and I agree your opinion that PVT variations is the elephant in the room! 

Intel MMX technology has been a huge success, achieving 20% faster speed against its pipelined circuit for 64*64 bit floating multiplier! 

What is a technology Intel can do while Xilinx and Altera (Intel) cannot do?

FPGA is none but an ASCI. 

Especially Altera is now part of Intel, if there is a bridge built between a code designer and a synthesizer, Altera absolutely can do it for its FPGA without doubt! That is my opinion.

All coding of my scheme has 3 steps:

1) Write a Critical Path Component (CPC) with defined interface;

2) Call a Wave-Pipelining Component (WPC) provided by a system library;

3) Call one of 3 link statements to link a CPC instantiation with a paired WPC instantiation to specify what your target is.

My scheme separates the critical path from 1-cycle regular logic. WPC is a regular 1-cycle component, link statement is a traditional statement used for special meanings and both of WPC and link statement have nothing to do with PVT. 

Now only CPC component has argument between me and your group with suspicion.

What a synthesizer needs for generating a wave-pipelined circuit is the critical path logic, that is all, in any situation. 

My scheme makes thing simpler: only CPC of a wave-pipelined circuit's 3 parts has to be wave-pipelined. 

As I said before, if anybody uses HDL to code, he has nothing to do with PVT, never put PVT into consideration, not me, not you, nobody does it and full HDL has no grammar on PVT!!! That is other ones' business.

Here is my opinion:
1. PVT is the elephant in the room.
2. Intel MMX technology has been a huge success since 1997.
3. Altera now is part of Intel.
4. FPGA is none but a special ASIC with greater flexibility.
5. I built a bridge between a code designer and a synthesizer.

Now there are 2 suspicions:
1. Can a wave-pipelined circuit be reliably generated and used in FPGA for all FPGA users?

2. Is wave-pipelined circuit useless in FPGA?

I like to tell you 2 stories:
1. Intel is one of companies who own large amount of patents, but Intel has never applied for any patents, and never published any articles on the subject.

2. I learn that Chinese Huawei designs their cell phone chips embedded with the wave-pipelined circuits.

Based on Huawei situation, I think wave-pipelined circuits are broadly used in big companies for their ASIC.

I am trying to find someone in Altera and Xilinx to contact with me and hope he/she gives me an email.

Thank you.

Weng




Article: 160449
Subject: Clock distribution /Resynchronizing
From: KJ <kkjennings@sbcglobal.net>
Date: Tue, 23 Jan 2018 13:52:00 -0800 (PST)
Links: << >>  << T >>  << A >>
A few details are missing from your post, but I'll make some assumptions an=
d go from there.  I'm assuming your 'boxes' are at least physically separat=
e boards or maybe different systems entirely. That means you need to concer=
n yourself with grounding between the two systems which typically then lead=
s to using differential I/O for signaling. If that is the case, then a reli=
able mechanism is to use something like SERDES parts which greatly simplifi=
es the receiving end since the output of the SERIES receiver is a clock and=
 parallel data. Very straightforward.  SERVES is built into some FPGAs as w=
ell as commercial dedicated parts.=20

In general, using both clock edges is not good practice in part because you=
 need to control duty cycle since, unless you use logic and/or flip flops t=
o generate the clock (another typically bad practice), there is no way to m=
ake any adjustments. This recommendation of course does not apply to DDR ce=
lls which are specifically designed for a particular type of net topology t=
hat I doubt you have here.=20

Kevin Jennings



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search