HT-Lab wrote on 1/25/2018 5:36 AM:> On 25/01/2018 06:01, rickman wrote: >> HT-Lab wrote on 1/23/2018 12:48 PM: >>> 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! >> >> 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. > > I don't know what to tell you either, do you know what the NASDAQ value > represent? Do you think that Lattice only makes FPGA's?Who said they were using the market cap for the capacity? Companies make reports every quarter. They make very complete reports annually. Lying in these reports is a crime. The information you want is in these reports. The only issue is what exactly is being reported. The Intel info is most likely from then annual report, but there is a lot more to parse and wade through.> Do you think that > the stock price for the whole company is good indicator on how many product > they sell in a particular group against a survey company that goes out into > the industry to find that answer? Do you think eetimes (which has covered > electronic news for the past 50 years) is a fake news site with no editorial > fact checking?You seem to be getting emotional about this. I should believe one set of numbers over another because eetimes is older?> But lets take your argument and check the stock prices, go to the Nasdaq > website and look at the market value of Lattice (LSCC) against MicroSemi > (MSCC) and for good measures Xilinx (XLNX), you will be surprised how well > Microsemi is doing (even I was). Have a look at the stock prices for the > last 5 years, Microsemi is outperforming all of them including Xilinx! > Lattice seems to be steady at around 20-40% (well below Microsemi). Lattice > has not made any significant changes in the past 5 years. There was a > negative dip in 2016 which I assume was caused when Lattice agreeding to be > acquired by a Chinese equity firm (subsequently blocked by Trump). > > So, making statements like "no one uses Actel/Microsemi FPGAs..." shows you > work in an isolated bubble. If you like Lattice FPGA's than fine, no > argument from me, but don't use it to justify something you clearly know > nothing about. > > Back to work.....Yes, but next time try not reading what I haven't written. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
My invention: Coding wave-pipelined circuits with buffering function in HDL
Started by ●January 10, 2018
Reply by ●January 25, 20182018-01-25
Reply by ●January 25, 20182018-01-25
On 1/25/18 12:49 AM, rickman wrote:> Weng Tianxiang wrote on 1/23/2018 1:31 AM: >>> 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 >> > > 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. >The other way of stating the requirement, using words like those given, is that you need to look at the difference of the minimum delay over PVT of the longest path to the maximum delay over PVT of the shortest path (plus the other factors). The problem of course is that due to the amount of variation in delay over PVT is large enough that you have negative margin, and of course, measuring A unit at A value of PVT, can well give you much better margins than if you need to account for PVT. One option that might be able to help here is to try and automatically adjust the clock to adjust for changing PVT, at which point you only need to worry about the delta over the part, and the accuracy you could determine the right frequency to run.
Reply by ●January 26, 20182018-01-26
Hi, Actually I don't do anything with Matlab and other advanced tools. You have to fully understand my scheme: my design has nothing to do with a real wave-pipelined circuit, NEVER! So there is nothing you have to simulate in Matlab and other advanced tools at all! In my simulation I even use a direct connection without any logic: C <= A which must imitate the behavior as if the data is passing the wave-pipelined circuit correctly. Imitating the wave-pipelined circuit behavior needs several features: a) If wave constant Series_clock_number = 5, an input data at 0-th cycle enters the circuit, it should be latched onto the output register at 6-th cycle if output is not blocked. If there is output block asserted by a data receiver, the situation would dramatically become complex so my new application pays special attention to it with specification of 81 pages, 48 claims and drawings of 24 pages! b) A valid data output appearing on the output bus lasts one cycle if the circuit is allowed to output. c) In my first version of WPC source code in VHDL, there is no blocking on the output bus. For the second version of WPC source code in VHDL output side can block the circuit from outputting on the output bus and the second version of WPC has additional buffering function. d) If wave constant Input_cycle_number = 1, the circuit can accept one data per cycle. And the circuit can always accept one data per Input_cycle_number cycles. e) If wave constant Multiple_cycle_number = 1, the circuit has one critical path. And the circuit always has Multiple_cycle_number of critical paths. Very simple. The reason is that I divide the scheme for generating a wave-pipelined circuit into 2 sections with an interconnection between them during simulation that will be described shortly: a) Designer provides CPC component as described at the first post, with correct and full information about the critical path, no more no less. b) The hypothetical synthesizer correctly generates the specified wave-pipelined circuit. The output data passing through the circuit are always assumed correct that must be checked by my simulation and they are what only I have to check! So what I have to do is to guarantee that if the synthesizer does it correctly, gets a set of wave constants initial value, then my WPC should work correctly based on the wave constant initial values determined by the hypothetical synthesizer for the WPC. My scheme has 3 parts of code: 1) A CPC, CPC_1_2 is one of 2 CPCs with simplest logic C <= A. 2) A WPC. It works normally only after the synthesizer will generate correct wave-pipelined circuit, because it is the responsibility that my hypothetical synthesizer must do! And I never need to confirm whether or not the real wave-pipelined circuit works properly, it is other people's business, not mine! 3) Link statement is ignored because it is only used to indicate what a synthesizer has to do, and the link statement behaviors are reflected in 3 wave constant initial values. Here are their interconnections: CPC --> Critical path(s) --> 3 wave constant initial values --> WPC What I have to check is whether the input data is equal to output data! Any logic operation between input data and output data in my simulation is unnecessary and superfluous, because I have assumed that the critical path (the wave-pipelined circuit) is always correctly generated, no matter what logic function between input data and output data is. My responsibility has 3 points: a) My scheme works. Absolutely! b) My 2 WPCs work normally on all conditions. The all conditions are not what you have thought for critical path under different PVTs, but under different combinations of 3 wave constants: Series_clock_number, Input_clock_number and Multiple_copy_number. So I never need to do anything about simulating the real wave-pipelined circuit. NO, NEVER! NEVER! NEVER! Here is how I do my simulation in a VHDL-2002 simulator: 1. What I have to simulate is to use different sets of 3 wave constant values to test whether or not my 2 WPC components are correct, that is all. for example: a) Series_clock_number = 5; Input_clock_number = 3; Multiple_copy_number = 1; b) Series_clock_number = 5; Input_clock_number = 1; Multiple_copy_number = 3; and so on. All 3 wave constants must comply 3 relationships: 1) Series_clock_number >= Input_clock_number >= 1. 2) Series_clock_number >= Multiple_copy_number>= 1. 3)Multiple_copy_number = 1 if Input_clock_number > 1. 4) Input_clock_number = 1 if Multiple_copy_number > 1. In editing...
