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
formatting link
There are numerous circuits in FPGA that are worth being the wave-pipelined circuits.
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?
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.
Then you have done nothing...
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
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.
deliver full information about a critical path to a synthesizer for generat ing a wave-pipelined circuit! If you can, please challenge my claim.
A & B
A
B
a C
A
B
r C
logic
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.
d multiplexer and the circuit can accept one data per 2 cycles, you should know how to code the WPC for the circuit.
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.
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.
All coding for a wave-pipelined circuit has 3 steps:
Write a Critical Path Component (CPC) with defined interface;
Call a Wave-Pipelining Component (WPC) provided by a system library;
Call one of 3 link statement to link a CPC instantiation with a paired W PC instantiation to specify what your target is.
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.
Now second I am trying to code its WPC.
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.
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.
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.
I haven't seen what a synthesizer can do. Does anyone make a synthesizer that does this?
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
If you don't know something, never say that it's impossible, in my point of view, it is beyond your specialty.
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!
s along with the synthesis vendors to modify their software, all at no smal l 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 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.
that does this?
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.
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?
This has nothing to do with "FPGAs" which is the target I was referring to.
Adding this to the HDL is trivial. The ENTIRE hard part is getting a synthesizer to support this by doing all the hard work.
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
Comparing a blogger article from 2011 who took some NASDAQ vales against eetimes which using a marketing survey company results from 2017, good job!
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.
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.
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.
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:
PVT is the elephant in the room.
Intel MMX technology has been a huge success since 1997.
Altera now is part of Intel.
FPGA is none but a special ASIC with greater flexibility.
I built a bridge between a code designer and a synthesizer.
Now there are 2 suspicions:
Can a wave-pipelined circuit be reliably generated and used in FPGA for all FPGA users?
Is wave-pipelined circuit useless in FPGA?
I like to tell you 2 stories:
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.
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.
Please check if any of my claims 1 are innovative and non-obvious, two basi c requirements for each of them to be qualified for a patent.
9,747,252: Systematic method of coding wave-pipelined circuits in HDL.
9,734,127: Systematic method of synthesizing wave-pipelined circuits in HDL.
9,575,929: Apparatus of wave-pipelined circuits.
They are publicly available.
Simply saying, the idea that designer provides all necessary information of a critical path to a synthesizer and leaves all complex analysis, except a shared code library, to the synthesizer to finish is brand new idea and it self an innovative and non-obvious subject for patents!
Have you seen the idea before?
Do you agree with the simply saying?
My simpler and fully automatic methods indicate a road to synthesizer vendo rs on how to generate a wave-pipelined circuit even though my hypothetical synthesizer is not available now that is not a requirement for a patent to be issued.
Here is the proof as how people before my inventions did for the subject: r eference number: 228, the most authoritative paper before and after its pub lication on how generating a wave-pipelined circuit. Reference [1] IEEE Transactions on VLSI Systems
rep1&type=pdf (1998) at page 142 below table 1 indicates that "Last, due to a lack of commercial tools that are directly applicable to designs using wave-pipelining, each group has more or less developed in-house design ana lysis and optimization tools which enable VLSI design using wave-pipelining ."
The problem here is not that were people unable to generate a wave-pipeline d circuit, but that people lack a HDL standard to govern the industry to do the business.
And my inventions fill the gap!
The father of rocket Dr. Robert H. Goddard (1882?1945) successfully launched his model on March 16, 1926. Two of Goddard's 214 patented invent ions?a multi-stage rocket (1914), and a liquid-fuel rocket (1914) ?were important milestones toward spaceflight. (Based on Wikipedia)
It had been 12 years later that Goddard implemented his patents.
th
rior
an
I claim 2 methods for coding and synthesizing wave-pipelined circuits on ho w to code and generate a wave-pipelined circuit, not the CPC_1_2 code itsel f which is used here only to demonstrate how simple it is to use the method s.
Based on your and Rick's claims, I think my CPC_1_2 example fully plays its designed role: how simple it is!
to 'steal' the idea? Otherwise what's the motivation anyway??
Actually I have some difficulty understanding his words "if he already has and this is some crazy attempt to bate people to 'steal' the idea?"
My motivation is simple:
1) Define a new part for all HDL languages dealing with wave-pipelined circ uits.
2) Provide a library for all HDL languages dealing with wave-pipelined circ uits.
3) Make code designer coding a wave-pipelined circuit as simple as coding a regular 1-cycle circuit.
4) Replace a pipelined circuit with its wave-pipelined circuit counterpart for most situations or as much as possible.
This paper starts off with a fallacy, "the minimum clock period is not limited by the longest path, but by the difference between the maximum and minimum path delays, plus the clock skew, the rise/fall time, and the setup/hold time of the I/O registers [14]."
The problem is that PVT must also be considered. If you design to the typical numbers and your path delays allow you to have five stages of pipeline between two registers, you are counting on the data clocked into the input FFs at time T to result in stable data presented to the output FF at time T+5*tck where tck is the clock period. If the delay changes from one chip to another or from one time to another (because of voltage or temperature changes) then that stable period will move and no longer happen at T+5*tck.
The authors construct a circuit. "The circuit worked up to 64 MHz (measured), with five waves inside it: more than seven times the speed predicted by the timing analyzer tool. The highest operation band was very narrow: just 1 MHz."
1 MHz means it will not work at all if the delays change by less than 2% which is guaranteed with minimal changes from PVT.
This is what happens in the real world.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
So who don't you trust, the blogger or NASDAQ? It would be easy enough to verify the numbers. But if you don't believe the company's stock reports then I don't know what to tell you.
The EEtimes article, "Guesstimate of final numbers x 1,000,000 (Source: Paul Dillien)" Guessing is usually not an indication of accuracy.
I don't believe the numbers because it is Microsemi saying what is in that group while the earlier numbers were for the company as a whole. It would appear that Paul Dillien then massaged the numbers to try to extract the "FPGA" content for all five companies, so who knows how good the data is?
Yep, they have their foot in the door and if it slips out we no longer can make a fair amount of military gear. No, they aren't going to abandon the devices because of the security problems. But the military market is slow to move and the blow can still be coming. It only requires an alternative that doesn't have that problem. I just found it interesting that the company included a back door and pretended it didn't exist. Back doors are the heart of so many security issues.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
One interesting suggestion in the Boemo paper was the mention of passing the clock through logic with similar delay to the data, essentially self clocking of the output registers. Yes, that gets past much of the issue of timing variability from PVT (not sure what the others are) but now you have an input and output that are asynchronous with one another. It's hard to work with such clock domains. Just ask anyone who has tried to design an async device.
I think his claim is about the three "link" statements that I can't actually see in the code example he provided. It is not clear what those three link statements do, but I suspect it is very obvious that they are needed once you dig into the concept. But patents have been granted on what would seem to be obvious to someone exploring the field, but that is not the same as obvious to someone knowledgeable in the field if it is new work. Many patents in the FPGA world appear to be obvious, but since it is new the first one to see it is obvious gets the patent.
I agree. The fact that we keep getting references to research papers shows a lack of understanding of how any of this might be applied.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
An FPGA is very much NOT an ASIC to the user. The fact that you fail to see this is significant.
Yes, when designing with synchronous logic, the PVT issue goes away because it is already factored into the MAX delays. In synchronous logic ONLY max delays are used and so already considers PVT without any extra work.
Wave pipelining needs to consider the max and min delays. As you say this has nothing to do with writing HDL, but the point is writing HDL is not sufficient to deal with the problem of PVT variation widening your timing window so as to make wave pipelining impossible in many cases.
You built a bridge? I think this bridge is not very important, or I should say can be done many different ways.
No
It might work for a two stage pipeline using just input and output registers since this would give the widest tolerance of delay variation. But what is the value? It ignores one stage of free registers at some expense since in a general case LUTs will need to be added to equalize path delays.
Not using FPGAs, right?
Good luck. If you find a way to deal with the PVT issues, I bet they will beat a path to your door. Coming up with the idea of using "link" statements isn't likely to get a phone call in my opinion. :)
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
There is no doubt in my mind that this looked like a valid patent to the examiner. I don't know if a company would prefer to challenge the validity of the patent or just pay a limited royalty. The issue is whether this is not obvious to anyone skilled in designing software for FPGA or ASIC design. It sure seems obvious to me. Mostly it hasn't been mentioned because it is *not* the part of the wave-pipelining design process that constitutes a problem.
In other words it isn't a problem looking for a solution. The guts of the synthesizer are. Until someone figures out that part, your patent won't have much value even if no one challenges it.
On the other hand it might just make you rich.
--
Rick C
Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998
Reference [1] (1998) at page 142 below table 1 indicates that "Last, due to a lack of commercial tools that are directly applicable to designs using w ave-pipelining, each group has more or less developed in-house design analy sis and optimization tools which enable VLSI design using wave-pipelining."
The paper also indicates in Table 1 page 142: there had been 30 wave-pipeli ned circuits before the paper was published and it was 20 years ago.
So I don't know who is right? You, a newbie in 3 days in the field, or the professor author is right?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.