Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote: > A few details are missing from your post, but I'll make some assumptions = and go from there. I'm assuming your 'boxes' are at least physically separ= ate boards or maybe different systems entirely. That means you need to conc= ern yourself with grounding between the two systems which typically then le= ads to using differential I/O for signaling. If that is the case, then a re= liable mechanism is to use something like SEDERS parts which greatly simpli= fies the receiving end since the output of the SERIES receiver is a clock a= nd parallel data. Very straightforward. SERVES is built into some FPGAs as= well as commercial dedicated parts.=20 >=20 > In general, using both clock edges is not good practice in part because y= ou need to control duty cycle since, unless you use logic and/or flip flops= to generate the clock (another typically bad practice), there is no way to= make any adjustments. This recommendation of course does not apply to DDR = cells which are specifically designed for a particular type of net topology= that I doubt you have here.=20 >=20 > Kevin Jennings Hi, Kevin:- Thanks for the response.=20 Communication is via LVDS between boxes over terminated twisted pairs with = isolation at both ends. =20 I'm probably missing something blindingly obvious here (!) but to simplify = it to the essence what I need to do is (re) create a clock and sync signal = at each node that looks like this:=20 https://i.imgur.com/y5oBOO7.png All nodes get the same clock and the sync is simultaneously (before the act= ive clock edge) recognized at each node at the next active input clock edge= with a difference of nanoseconds. =20 The key thing is that the output generated sync signal can't be too close t= o the active edge of the clock. I can't just divide the clock by two to use= all (say) positive edges because then it could end up off between nodes by= half a clock. Lower end standard clock synthesis chips that I've looked at don't guarante= e the phase of the outputs beyond starting them up at the same time, so if = they got out of phase they would never correct themselves.=20 Hopefully that is an adequate description.. I'm trying to create clocks for= external use here. So if the "clock" output in the above timing diagram ch= anges on the rising edge of the system clock (say with a synchronous divide= r) then the=20 sync output must change at least 10ns-15ns before or after the edge (known = one or the other).=20 I took a look at SERDES and they seem to use delay elements rather than alt= ernate clock edges to guaranteed the timing. Also probably overkill for thi= s application which is not much more than a clock divider chain.=20 So I guess that's another option- internal or external delay elements to ad= d up to the worst-case estimated skew + setup time + safety margin=20Article: 160451
> Now as to your patent claim. I'm unsure at all what you're trying to cla= im. > You list as an example a straightforward, and very basic pipelined datapa= th > example. One that matches thousands of others already in existance and p= rior > 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.=20 > Mark Mark, 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. 1. 9,747,252: Systematic method of coding wave-pipelined circuits in HDL.= =20 2. 9,734,127: Systematic method of synthesizing wave-pipelined circuits in = HDL. =20 3. 9,575,929: Apparatus of wave-pipelined circuits.=20 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?=20 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.=20 Reference [1] IEEE Transactions on VLSI Systems=20 > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.90.1783&rep=3D= rep1&type=3Dpdf (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= ."=20 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!=20 > But you claim that an undescribed, unbuilt tool could then=20 > take such code and implement a wave-pipeline with it? That someone else > would have to build? >=20 The father of rocket Dr. Robert H. Goddard (1882=E2=80=931945) successfully= launched his model on March 16, 1926. Two of Goddard's 214 patented invent= ions=E2=80=94a multi-stage rocket (1914), and a liquid-fuel rocket (1914)= =E2=80=94were important milestones toward spaceflight. (Based on Wikipedia) It had been 12 years later that Goddard implemented his patents.=20 > You list as an example a straightforward, and very basic pipelined datapa= th > example. One that matches thousands of others already in existance and p= rior > art. It's an input pipeline register, and large combinational cloud, and= an > output pipeline register. Described in VHDL. =20 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.=20 Based on your and Rick's claims, I think my CPC_1_2 example fully plays its= designed role: how simple it is! WengArticle: 160452
Den onsdag den 24. januar 2018 kl. 01.59.31 UTC+1 skrev Spehro Pefhany: > On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote: > > A few details are missing from your post, but I'll make some assumption= s and go from there. I'm assuming your 'boxes' are at least physically sep= arate boards or maybe different systems entirely. That means you need to co= ncern yourself with grounding between the two systems which typically then = leads to using differential I/O for signaling. If that is the case, then a = reliable mechanism is to use something like SEDERS parts which greatly simp= lifies 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 well as commercial dedicated parts.=20 > >=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 flo= ps to generate the clock (another typically bad practice), there is no way = to make any adjustments. This recommendation of course does not apply to DD= R cells which are specifically designed for a particular type of net topolo= gy that I doubt you have here.=20 > >=20 > > Kevin Jennings >=20 > Hi, Kevin:- >=20 > Thanks for the response.=20 >=20 > Communication is via LVDS between boxes over terminated twisted pairs wit= h isolation at both ends. =20 >=20 > I'm probably missing something blindingly obvious here (!) but to simplif= y it to the essence what I need to do is (re) create a clock and sync signa= l at each node that looks like this:=20 >=20 > https://i.imgur.com/y5oBOO7.png >=20 > All nodes get the same clock and the sync is simultaneously (before the a= ctive clock edge) recognized at each node at the next active input clock ed= ge with a difference of nanoseconds. =20 >=20 > The key thing is that the output generated sync signal can't be too close= to the active edge of the clock. I can't just divide the clock by two to u= se all (say) positive edges because then it could end up off between nodes = by half a clock. >=20 > Lower end standard clock synthesis chips that I've looked at don't guaran= tee the phase of the outputs beyond starting them up at the same time, so i= f they got out of phase they would never correct themselves.=20 >=20 > Hopefully that is an adequate description.. I'm trying to create clocks f= or external use here. So if the "clock" output in the above timing diagram = changes on the rising edge of the system clock (say with a synchronous divi= der) then the=20 > sync output must change at least 10ns-15ns before or after the edge (know= n one or the other).=20 >=20 > I took a look at SERDES and they seem to use delay elements rather than a= lternate clock edges to guaranteed the timing. Also probably overkill for t= his application which is not much more than a clock divider chain.=20 >=20 > So I guess that's another option- internal or external delay elements to = add up to the worst-case estimated skew + setup time + safety margin I'm not sure I understand what it is your are trying to do,=20 but 10ns-15ns is ages so just use a faster clock=20Article: 160453
This post is copied from https://www.reddit.com/r/FPGA/comments/7sgzkr/my_i= nvention_coding_wavepipelined_circuits_with/ > [=E2=80=93]dosidicusGigas 1 point 16 hours ago=20 > I wonder if he already has and this is some crazy attempt to bate people = 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?"=20 > Otherwise what's the motivation anyway?? 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. WengArticle: 160454
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. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160455
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. The EEtimes article, "Guesstimate of final numbers x 1,000,000 (Source: Paul Dillien)" Guessing is usually not an indication of accuracy. >> 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. 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? >> 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. 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 1998Article: 160456
Mark Curry wrote on 1/23/2018 3:10 PM: > 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) 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. > 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? 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. > 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. 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 1998Article: 160457
Weng Tianxiang wrote on 1/23/2018 4:48 PM: > 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. An FPGA is very much NOT an ASIC to the user. The fact that you fail to see this is significant. > 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. 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. > 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. You built a bridge? I think this bridge is not very important, or I should say can be done many different ways. > Now there are 2 suspicions: > 1. Can a wave-pipelined circuit be reliably generated and used in FPGA for all FPGA users? No > 2. Is wave-pipelined circuit useless in FPGA? 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. > 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. Not using FPGAs, right? > 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. 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 1998Article: 160458
Weng Tianxiang wrote on 1/24/2018 9:17 PM: > This post is copied from https://www.reddit.com/r/FPGA/comments/7sgzkr/my_invention_coding_wavepipelined_circuits_with/ > >> [–]dosidicusGigas 1 point 16 hours ago >> I wonder if he already has and this is some crazy attempt to bate people 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?" > >> Otherwise what's the motivation anyway?? > > My motivation is simple: > > 1) Define a new part for all HDL languages dealing with wave-pipelined circuits. > 2) Provide a library for all HDL languages dealing with wave-pipelined circuits. > 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. 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 1998Article: 160459
Spehro Pefhany wrote on 1/23/2018 7:59 PM: > On Tuesday, 23 January 2018 16:52:05 UTC-5, KJ wrote: >> A few details are missing from your post, but I'll make some assumptions and go from there. I'm assuming your 'boxes' are at least physically separate boards or maybe different systems entirely. That means you need to concern yourself with grounding between the two systems which typically then leads to using differential I/O for signaling. If that is the case, then a reliable mechanism is to use something like SEDERS parts which greatly simplifies 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 well as commercial dedicated parts. >> >> 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 to generate the clock (another typically bad practice), there is no way to make any adjustments. This recommendation of course does not apply to DDR cells which are specifically designed for a particular type of net topology that I doubt you have here. >> >> Kevin Jennings > > Hi, Kevin:- > > Thanks for the response. > > Communication is via LVDS between boxes over terminated twisted pairs with isolation at both ends. > > I'm probably missing something blindingly obvious here (!) but to simplify it to the essence what I need to do is (re) create a clock and sync signal at each node that looks like this: > > https://i.imgur.com/y5oBOO7.png > > All nodes get the same clock and the sync is simultaneously (before the active clock edge) recognized at each node at the next active input clock edge with a difference of nanoseconds. > > The key thing is that the output generated sync signal can't be too close to the active edge of the clock. I can't just divide the clock by two to use all (say) positive edges because then it could end up off between nodes by half a clock. I'm a bit confused. You say you want to use both edges of the clock, but that is only for the sync signal and not for the data??? So this is only so you have the ADCs aligned, but they can't align to the wrong edge of the system clock can they? You just need to tell the ADC which clock cycle is the appropriate starting point for the conversion, no? I thought this was typically done with the data path. Data is clocked into the chip at some rate related to the main clock, either the same rate or a divided down rate. The data interface has signals to align to the word and to the left/right words that often go to dual (stereo) devices. If the clock is timed correctly and the data path identified the correct clock cycle to sync to, what else do you need? > Lower end standard clock synthesis chips that I've looked at don't guarantee the phase of the outputs beyond starting them up at the same time, so if they got out of phase they would never correct themselves. What ADC chips are you using? > Hopefully that is an adequate description.. I'm trying to create clocks for external use here. So if the "clock" output in the above timing diagram changes on the rising edge of the system clock (say with a synchronous divider) then the > sync output must change at least 10ns-15ns before or after the edge (known one or the other). > > I took a look at SERDES and they seem to use delay elements rather than alternate clock edges to guaranteed the timing. Also probably overkill for this application which is not much more than a clock divider chain. > > So I guess that's another option- internal or external delay elements to add up to the worst-case estimated skew + setup time + safety margin > > -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160460
> In other words it isn't a problem looking for a solution. The guts of th= e=20 > synthesizer are. Until someone figures out that part, your patent won't= =20 > have much value even if no one challenges it. >=20 > [1] IEEE Transactions on VLSI Systems=20 > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.90.1783&rep=3D= rep1&type=3Dpdf=20 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."= =20 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? WengArticle: 160461
Weng Tianxiang wrote on 1/25/2018 2:23 AM: >> 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. >> > >> [1] IEEE Transactions on VLSI Systems >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.1783&rep=rep1&type=pdf > > 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 wave-pipelining, each group has more or less developed in-house design analysis and optimization tools which enable VLSI design using wave-pipelining." > > The paper also indicates in Table 1 page 142: there had been 30 wave-pipelined 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? Or both? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160462
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? 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? 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..... Hans www.ht-lab.comArticle: 160463
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 1998Article: 160464
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.Article: 160465
On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote: Hi, Rick:- > > > > Communication is via LVDS between boxes over terminated twisted pairs with isolation at both ends. > > > > I'm probably missing something blindingly obvious here (!) but to simplify it to the essence what I need to do is (re) create a clock and sync signal at each node that looks like this: > > > > https://i.imgur.com/y5oBOO7.png > > > > All nodes get the same clock and the sync is simultaneously (before the active clock edge) recognized at each node at the next active input clock edge with a difference of nanoseconds. > > > > The key thing is that the output generated sync signal can't be too close to the active edge of the clock. I can't just divide the clock by two to use all (say) positive edges because then it could end up off between nodes by half a clock. > > I'm a bit confused. You say you want to use both edges of the clock, but > that is only for the sync signal and not for the data??? So this is only so > you have the ADCs aligned, but they can't align to the wrong edge of the > system clock can they? You just need to tell the ADC which clock cycle is > the appropriate starting point for the conversion, no? Yes, that's right. The ADCs have a conversion ready 1024 clock cycles from the sync and it only needs to be read before it's overwritten. But if I distribute n times the clock frequency the divider at each box may have some phase difference from the master. I suppose I could reset the *divider* with the sync pulse and that would ensure (re)synchronization in << 1msec which is probably okay. But if I program it using both edges of the clock, the waveforms look great. > > I thought this was typically done with the data path. Data is clocked into > the chip at some rate related to the main clock, either the same rate or a > divided down rate. The data interface has signals to align to the word and > to the left/right words that often go to dual (stereo) devices. If the > clock is timed correctly and the data path identified the correct clock > cycle to sync to, what else do you need? > > > > Lower end standard clock synthesis chips that I've looked at don't guarantee the phase of the outputs beyond starting them up at the same time, so if they got out of phase they would never correct themselves. > > What ADC chips are you using? ADS1281. The FPGA has a delay function on the inputs but it tops out at a few ns, not enough to cover the maximum skew with cables and isolators involved. > > Rick C > > Viewed the eclipse at Wintercrest Farms, > on the centerline of totality since 1998Article: 160466
Den torsdag den 25. januar 2018 kl. 21.53.00 UTC+1 skrev Spehro Pefhany: > On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote: > > Hi, Rick:- > > > > > > > Communication is via LVDS between boxes over terminated twisted pairs with isolation at both ends. > > > > > > I'm probably missing something blindingly obvious here (!) but to simplify it to the essence what I need to do is (re) create a clock and sync signal at each node that looks like this: > > > > > > https://i.imgur.com/y5oBOO7.png > > > > > > All nodes get the same clock and the sync is simultaneously (before the active clock edge) recognized at each node at the next active input clock edge with a difference of nanoseconds. > > > > > > The key thing is that the output generated sync signal can't be too close to the active edge of the clock. I can't just divide the clock by two to use all (say) positive edges because then it could end up off between nodes by half a clock. > > > > I'm a bit confused. You say you want to use both edges of the clock, but > > that is only for the sync signal and not for the data??? So this is only so > > you have the ADCs aligned, but they can't align to the wrong edge of the > > system clock can they? You just need to tell the ADC which clock cycle is > > the appropriate starting point for the conversion, no? > > Yes, that's right. The ADCs have a conversion ready 1024 clock cycles from the sync and it only needs to be read before it's overwritten. > > But if I distribute n times the clock frequency > the divider at each box may have some phase difference from the master. > > I suppose I could reset the *divider* with the sync pulse and that would ensure (re)synchronization in << 1msec which is probably okay. > > But if I program it using both edges of the clock, the waveforms look > great. > > > > > I thought this was typically done with the data path. Data is clocked into > > the chip at some rate related to the main clock, either the same rate or a > > divided down rate. The data interface has signals to align to the word and > > to the left/right words that often go to dual (stereo) devices. If the > > clock is timed correctly and the data path identified the correct clock > > cycle to sync to, what else do you need? > > > > > > > Lower end standard clock synthesis chips that I've looked at don't guarantee the phase of the outputs beyond starting them up at the same time, so if they got out of phase they would never correct themselves. > > > > What ADC chips are you using? > > ADS1281. > > The FPGA has a delay function on the inputs but it tops out at a few ns, not enough to cover the maximum skew with cables and isolators involved. multiply the clock in the fpga so you have a say 100MHz clock to do the delayArticle: 160467
> 24.576MHz and sync will be in the kHz range. These are relatively low frequencies that can be simply distributed to the = boxes. LVDS is a good choice.=20 > At the receiving nodes the clocks have to be de-jittered and preferably t= he two (or more) signals aligned with each other.=C2=A0 Why? If you can't transmit two signals and receive them at the other end a= nd think that you have to de-jitter them then there is either something you= 're not telling us or you are overthinking this.=20 > Right now it looks to me like the sensible way to do it is to use a zero = delay buffer, feed that into an FPGA and clock off both the rising and fall= ing edges of a single clock signal The sensible thing to me would be to simply transmit and receive and use th= e two LVDS signal pairs directly. In your diagram you show that the sync signal is less than one clock cycle = wide. I would suggest a single clock cycle wide would be better. Have sync = generated on the falling edge (assuming that to be the 'inactive' edge). Th= at meets your other requirement of keeping sync transitions away from the a= ctive edge. > Is clocking off both edges of an input signal a kosher approach to genera= ting and relaying clocks?=20 No. If you don't think you can reliably transmit two signals, then why do = you think you can generate some clock from one of those transmitted signals= ? Explain why the simplest approach of simply transmitting clock and signal d= irectly without anything fancy is not adequate. If you can do that then you= 've described the problem to be solved.=20 Kevin JenningsArticle: 160468
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 <=3D A= which must imitate the behavior as if the data is passing the wave-pipelin= ed circuit correctly. Imitating the wave-pipelined circuit behavior needs several features: a) If wave constant Series_clock_number =3D 5, an input data at 0-th cycle = enters the circuit, it should be latched onto the output register at 6-th c= ycle if output is not blocked. If there is output block asserted by a data = receiver, the situation would dramatically become complex so my new applica= tion 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 c= ircuit 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 si= de can block the circuit from outputting on the output bus and the second v= ersion of WPC has additional buffering function. d) If wave constant Input_cycle_number =3D 1, the circuit can accept one da= ta per cycle. And the circuit can always accept one data per Input_cycle_nu= mber cycles. e) If wave constant Multiple_cycle_number =3D 1, the circuit has one critic= al 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-p= ipelined circuit into 2 sections with an interconnection between them durin= g simulation that will be described shortly: a) Designer provides CPC component as described at the first post, with cor= rect and full information about the critical path, no more no less. b) The hypothetical synthesizer correctly generates the specified wave-pipe= lined circuit. The output data passing through the circuit are always assum= ed correct that must be checked by my simulation and they are what only I h= ave to check! So what I have to do is to guarantee that if the synthesizer does it correc= tly, gets a set of wave constants initial value, then my WPC should work co= rrectly based on the wave constant initial values determined by the hypothe= tical 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 <=3D A. 2) A WPC. It works normally only after the synthesizer will generate correc= t wave-pipelined circuit, because it is the responsibility that my hypothet= ical synthesizer must do! And I never need to confirm whether or not the re= al wave-pipelined circuit works properly, it is other people's business, no= t mine! 3) Link statement is ignored because it is only used to indicate what a syn= thesizer has to do, and the link statement behaviors are reflected in 3 wav= e 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 unn= ecessary and superfluous, because I have assumed that the critical path (th= e wave-pipelined circuit) is always correctly generated, no matter what log= ic 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 wh= at you have thought for critical path under different PVTs, but under diffe= rent combinations of 3 wave constants: Series_clock_number, Input_clock_num= ber and Multiple_copy_number. So I never need to do anything about simulating the real wave-pipelined cir= cuit. 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 =3D 5; Input_clock_number =3D 3; Multip= le_copy_number =3D 1; b) Series_clock_number =3D 5; Input_clock_number =3D 1; Multiple_copy_numbe= r =3D 3; and so on. All 3 wave constants must comply 3 relationships: 1) Series_clock_number >=3D Input_clock_number >=3D 1. 2) Series_clock_number >=3D Multiple_copy_number>=3D 1. 3)Multiple_copy_number =3D 1 if Input_clock_number > 1. 4) Input_clock_number =3D 1 if Multiple_copy_number > 1. In editing...Article: 160469
Spehro Pefhany wrote on 1/25/2018 3:52 PM: > On Thursday, 25 January 2018 01:51:46 UTC-5, rickman wrote: > > Hi, Rick:- > >>> >>> Communication is via LVDS between boxes over terminated twisted pairs with isolation at both ends. >>> >>> I'm probably missing something blindingly obvious here (!) but to simplify it to the essence what I need to do is (re) create a clock and sync signal at each node that looks like this: >>> >>> https://i.imgur.com/y5oBOO7.png >>> >>> All nodes get the same clock and the sync is simultaneously (before the active clock edge) recognized at each node at the next active input clock edge with a difference of nanoseconds. >>> >>> The key thing is that the output generated sync signal can't be too close to the active edge of the clock. I can't just divide the clock by two to use all (say) positive edges because then it could end up off between nodes by half a clock. >> >> I'm a bit confused. You say you want to use both edges of the clock, but >> that is only for the sync signal and not for the data??? So this is only so >> you have the ADCs aligned, but they can't align to the wrong edge of the >> system clock can they? You just need to tell the ADC which clock cycle is >> the appropriate starting point for the conversion, no? > > Yes, that's right. The ADCs have a conversion ready 1024 clock cycles from the sync and it only needs to be read before it's overwritten. > > But if I distribute n times the clock frequency > the divider at each box may have some phase difference from the master. > > I suppose I could reset the *divider* with the sync pulse and that would ensure (re)synchronization in << 1msec which is probably okay. > > But if I program it using both edges of the clock, the waveforms look > great. > >> >> I thought this was typically done with the data path. Data is clocked into >> the chip at some rate related to the main clock, either the same rate or a >> divided down rate. The data interface has signals to align to the word and >> to the left/right words that often go to dual (stereo) devices. If the >> clock is timed correctly and the data path identified the correct clock >> cycle to sync to, what else do you need? >> >> >>> Lower end standard clock synthesis chips that I've looked at don't guarantee the phase of the outputs beyond starting them up at the same time, so if they got out of phase they would never correct themselves. >> >> What ADC chips are you using? > > ADS1281. > > The FPGA has a delay function on the inputs but it tops out at a few ns, not enough to cover the maximum skew with cables and isolators involved. I'm afraid I'm not picturing your system fully. The divider for examplsae, this is the first time you've mentioned it. I worked on an array processor many years ago which distributed high speed signals across a backplane. They distributed the clock via twisted pair which allowed them to adjust the timing by adjusting the length of the wire. This made the machine hard to maintain as every board did not work in every machine. The next generation had serpentine clock traces on the boards with various taps. This allowed the boards to be adjusted to a standard and so interchangeable. That was how they squeezed very last nanosecond from the chips. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998Article: 160470
On 01/10/18 11:32, rickman wrote: > I have used the Lattice XP3 FPGAs in a design I've made a lot of money > from. The parts have gone EOL but Arrow bought some 70,000+ and is > still trying to get rid of them. Seems they over estimated the market. > I had to pay a higher price to them in 2016 than I paid when they were > in production (~$10) but now they are going for around $5-$6 depending > on quantity and they still have 65,000. lol > > How do you like the Lattice tool chain compared to other FPGA vendors?Article: 160471
Hey! Even i am trying to interface adc on Spartan 3e can you help me out with the code as soon as possible!Article: 160472
On 01.02.2018 06:10, jayanth.kalvakuntla1996@gmail.com wrote: > Hey! Even i am trying to interface adc on Spartan 3e can you help me out with the code as soon as possible! > Many people here sure can. Post your code and ask your questions NicolasArticle: 160473
Actually i want the whole code ..if you have it will you post it here it would be helpful for meArticle: 160474
Actually i want the code..if you have it will you post it here it would be helpful!
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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