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
Randy I am presuming you are meaning physically small and from some of the other messages in the various. A part tp look at is the XC3S500E in the CPG132 package. You can see an example of this on our Craignell1 product http://www.enterpoint.co.uk/component_replacements/craignell.html. A XC3S500E has 36 multipliers that will run in the 100-200Mhz area. The XC3SD3400A is also physically small in the CSG484 package. You can see that on our monster Merrick1 and it has 126 multipliers available. Going up the cost scale there also some small Virtex parts. Spartan-6 is new and only certain parts like the XC6SLX16 are shipping. The CSG324 package we that we use in our Drigmorn3 ihttp://www.enterpoint.co.uk/drigmorn/drigmorn3.html s a very nice size and will give you 32 multipliers to use. The XC6SLX45 in the same package will give 58 multipliers. The XC6SLX150 in the CSG484 package isn't far off being available and will offer 180 multipliers. There are many other solutions from Xilinx and other vendors but I would need to know more of the application to be more accurate. John Adair Enterpoint Ltd.- Home of FPGA HPC solutions. On 27 Mar, 03:39, Randy Yates <ya...@ieee.org> wrote: > Hi, > > I'm looking for a device that will perform something on > the order of hundreds of millions of 12x12 multiplies > per second, and I need it small. I only need about > 30-40 pins of I/O. > > Is the Xilinx CoolRunner series completely out of the > picture? Any suggestions would be appreciated. > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi= ng, > Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i= n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th= e Music*, ELOArticle: 146751
Webpack supports up to and including the XC6SLX75 according to http://www.xilinx.com/publications/matrix/Software_matrix.pdf. John Adair Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Development Board. On 27 Mar, 00:05, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 26, 4:26=A0pm, Aditi <aditi...@gmail.com> wrote: > > > Hi, > > > I am using the XC6SLX9 FPGA in my new design. > > I would like to know what version of XILINX ISE is required for > > Spartan-6 series? =A0Can Webpack work with > > Spartan 6? > > > Thank you, > > Aditi. > > The ISE 11.5 Webpack version supports most of the Spartan-6 devices > including the XC6SLX9. > > Ed McGettigan > -- > Xilinx Inc.Article: 146752
John_H <newsgroup@johnhandwork.com> wrote: > On Mar 26, 11:39?pm, Randy Yates <ya...@ieee.org> wrote: >> I'm looking for a device that will perform something on >> the order of hundreds of millions of 12x12 multiplies >> per second, and I need it small. I only need about >> 30-40 pins of I/O. (snip) > How do you expect to get hundreds of millions of operands onto > and off the chip through 30-40 IO? That would be worth knowing, otherwise we have to guess. I think you can do I/O at 200MHz through many current FPGA, so he could do one multiplier at 200MHz. Maybe he doesn't need all the product bits, so 36 I/Os. My guess, though, is a digital filter doing a succession of multiplies and adds, in which case the I/O rate could be much lower. A systolic array multiplier in FPGA logic, latched at every step, would be very fast and you get pretty many of them on even a small FPGA. That is, not even using the block multipliers. -- glenArticle: 146753
Short is always good but often more important at these speeds is difference in length or propagation time. Keeping the skew down between signals allows the use of of a single clock shifting mechanism to make capture on return relatively simple to implement and even to make a auto training mechanism. One triick for these types of devices is to have a clock loop driven by an I/O and returned by a different I/O. This gives something that can be used as part of a timing lock loop but tracks changes in the device I/O for voltage and temperature etc.. John Adair Enterpoint Ltd. - Home of Raggedstone2. The Spartan-6 PCIe Development Board. On 26 Mar, 21:13, radarman <jsham...@gmail.com> wrote: > This isn't strictly a FPGA question, but I figured someone here might > be able to point me in the right direction. > > I am designing a board with an Altera EP3C40 in the 240-pin QFP and a > Cypress CY7C1792 static SRAM in the 100 pin QFP. I would like to > operate the SRAM at 200MHz, so I know the routing needs to be somewhat > careful. (I'm internally "dual-porting" the SRAM, and each port needs > to run at 100MHz) > > Right now, I have the SRAM on the flip-side of the board from the > FPGA. The RAM has a rectangular footprint, which means that some of > the traces are proportionally longer than others, but the routing is > fairly tight, with traces between 250 and 750mils. Naturally, every > signal is going through a via in this design, but the vias are > literally right next to the pad, so the top-level trace is practically > non-existent for most signals. > > The questions are, > 1) Do I need to further tighten these up? I have some room left under > the SRAM to lengthen traces (not much, but I might could improve the > delta by 10-20%), > 2) Should I try to make the clock line equal the longest non-clock > signal, or leave it at its natural length, which is about midway > (400mil point-to-point)? > 3) With the traces this short, does it still make sense to source > terminate the clock? I'm guessing yes, but the density is getting > pretty high around this thing. > > I've only done one other "high speed" design, with a Gig-E PHY, but I > was able to get all of the signals to within +/- 5 mils on that board. > It's also not entirely tested yet, so before I spin another board > running even faster, I'd like to get it right. > > Note, this is a personal project, so I'm trying to avoid BGA's. > > Thanks!Article: 146754
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > John_H <newsgroup@johnhandwork.com> wrote: >> On Mar 26, 11:39?pm, Randy Yates <ya...@ieee.org> wrote: > >>> I'm looking for a device that will perform something on >>> the order of hundreds of millions of 12x12 multiplies >>> per second, and I need it small. I only need about >>> 30-40 pins of I/O. > (snip) > >> How do you expect to get hundreds of millions of operands onto >> and off the chip through 30-40 IO? > > > That would be worth knowing, otherwise we have to guess. > > I think you can do I/O at 200MHz through many current FPGA, > so he could do one multiplier at 200MHz. Maybe he doesn't > need all the product bits, so 36 I/Os. > > My guess, though, is a digital filter doing a succession > of multiplies and adds, in which case the I/O rate could > be much lower. A systolic array multiplier in FPGA logic, > latched at every step, would be very fast and you get pretty > many of them on even a small FPGA. That is, not even using > the block multipliers. Hey glen! Nice to see you here! Sorry, I didn't mean to ignore your (valuable) suggestions. I've heard the term "systolic array." I guess I'm gonna have to learn about them now. :) That is, if John's lookup table approach won't work - that would be the best, and since the input data is just two bits, it'll probably be the way to go. -- Randy Yates % "With time with what you've learned, Digital Signal Labs % they'll kiss the ground you walk mailto://yates@ieee.org % upon." http://www.digitalsignallabs.com % '21st Century Man', *Time*, ELOArticle: 146755
Symon <symon_brewer@hotmail.com> writes: > On 3/27/2010 2:07 PM, Randy Yates wrote: >> >>> The coolrunner most probably won't do you any good. There are no >>> embedded multipliers and no storage beyond the macrocells (at least >>> per my recollection). >> >> That was my feeling too, but I wanted to get a more professional >> opinion. > > Hi Randy, > > I don't have much experience of CPLDs, but you may well be able to get > the multiplier performance you need. Even though a CPLD probably won't > have dedicated multipliers, there's more than one way to skin a > cat. Check out distributed arithmetic solutions. > > http://www.andraka.com/distribu.htm > > Also, you mention FEC. This might use up a fair chunk of hardware, but > again you can serialise it, if timing permits. > > As for your size requirements, I thought the smallest Coolrunner was > 6x6 = 36mm², too big for your spec. I was being very loose on the size spec. In fact I don't really (and my customer doesn't) really have a hard requirement on it, other than this, the D/As, a PIC, and other support stuff has to fit on a 2.5-in diameter PCB. -- Randy Yates % "Rollin' and riding and slippin' and Digital Signal Labs % sliding, it's magic." mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Living' Thing', *A New World Record*, ELOArticle: 146756
Randy Yates <yates@ieee.org> wrote: (someone wrote) >> As for your size requirements, I thought the smallest Coolrunner was >> 6x6 = 36mm?, too big for your spec. > I was being very loose on the size spec. In fact I don't really (and > my customer doesn't) really have a hard requirement on it, other than > this, the D/As, a PIC, and other support stuff has to fit on a 2.5-in > diameter PCB. You could use a soft processor, such as picoblaze in a Spartan, instead of the PIC. You might do with less 'support stuff' if some of that could go in the FPGA. -- glenArticle: 146757
On Mar 26, 12:49=A0am, whygee <y...@yg.yg> wrote: > Hi, > > Amal wrote: > > Try CVS and get a snapshot of the sources. =A0You can look at the > > sources here: > > >http://cvs.savannah.gnu.org/viewvc/?root=3Dvhdl-posix > > thanks, > > Any news from the author ? > Has anybody used, ported or modified this recently ? > This may sound curious or stupid but I need > exactly these functionalities today, > but they are written for an old Modelsim and I use GHDL :-/ > If I can avoid reintenting the wheel, I'll save a lot of time... > > regards, > > > -- Amal > > yg > > --http://ygdes.com/http://yasep.org I am not sure about the author and who maintains this. But you can easily port these to SystemVerilog DPI if you can afford mixed language simulation. -- AmalArticle: 146758
On Mar 28, 2:07=A0am, Randy Yates <ya...@ieee.org> wrote: > > It's a SOQPSK modulator, so the input data is 2 bits per baud. OK, > that takes 2 bits. The output is 14-bit I/Q. Ok, thats total 30 bits. > Add a few for control. Done. You still have not stated the actual IP and OP data rates, and the maths-ops needed per delivered output. Will you be using BGA, or is this QFP and maybe single-row QFN ? -jgArticle: 146759
-jg <jim.granville@gmail.com> writes: > On Mar 28, 2:07 am, Randy Yates <ya...@ieee.org> wrote: >> >> It's a SOQPSK modulator, so the input data is 2 bits per baud. OK, >> that takes 2 bits. The output is 14-bit I/Q. Ok, thats total 30 bits. >> Add a few for control. Done. > > You still have not stated the actual IP and OP data rates, and the > maths-ops needed per delivered output. 20 Mb/s input (2 bit samples, at 10 Mb/s), 80 M 14-bit samples/s output each for I and Q. > Will you be using BGA, or is this QFP and maybe single-row QFN ? Prefer to avoid BGA. -- Randy Yates % "Maybe one day I'll feel her cold embrace, Digital Signal Labs % and kiss her interface, mailto://yates@ieee.org % til then, I'll leave her alone." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELOArticle: 146760
On Mar 26, 11:28=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > I'm a little surprised that there are no cares about clock versus data > from others. =A0CARE! > Guess you didn't read my post where I detailed the estimate of skew to be ~5% of the timing budget (round trip delay)...and as I said, worth keeping track of, but likely to be far overshadowed by clock to output and setup time requirements. Actually I had originally computed it at half that percentage, twas using 10ns rather than 5 ns clock period. > Your synchronous SRAM doesn't have a DLL like SDRAMs. =A0There's one > clock that you provide, nothing provided back. > Just like most synchronous logic...back in the old days...one clock, nothing fancy. > The amount of length matching required is determined by your timing > budget. =A0You NEED to put together a timing budget to make sure your > clock and data are related better than second cousins once removed. > To quote Eric Bogatin, "plug in the numbers". The largest length difference between clock and data as reported by Radarman is 350 mils which is approximately a 60 ps built-in skew...clock to output delays and setup time requirements of the devices will be the primary concerns since they will be roughly an order of magnitude larger. Even differences in the delay caused by differences in the capacitive loading would probably be more important than the PCB copper delay differences. Kevin JenningsArticle: 146761
On Mar 27, 5:09=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Mar 26, 11:28=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > > I'm a little surprised that there are no cares about clock versus data > > from others. =A0CARE! > > Guess you didn't read my post where I detailed the estimate of skew to > be ~5% of the timing budget (round trip delay)...and as I said, worth > keeping track of, but likely to be far overshadowed by clock to output > and setup time requirements. =A0Actually I had originally computed it at > half that percentage, twas using 10ns rather than 5 ns clock period. > > > Your synchronous SRAM doesn't have a DLL like SDRAMs. =A0There's one > > clock that you provide, nothing provided back. > > Just like most synchronous logic...back in the old days...one clock, > nothing fancy. > > > The amount of length matching required is determined by your timing > > budget. =A0You NEED to put together a timing budget to make sure your > > clock and data are related better than second cousins once removed. > > To quote Eric Bogatin, "plug in the numbers". =A0The largest length > difference between clock and data as reported by Radarman is 350 mils > which is approximately a 60 ps built-in skew...clock to output delays > and setup time requirements of the devices will be the primary > concerns since they will be roughly an order of magnitude larger. > Even differences in the delay caused by differences in the capacitive > loading would probably be more important than the PCB copper delay > differences. > > Kevin Jennings I have already added a series termination resistor, since it really isn't that big a deal. I pretty much figured it would be necessary, and a 0402 is certainly doable. I'll just have to squeeze it in among all the bypass caps. (normally, I use the back of the board for bypass caps, but the SRAM is sitting right under the FPGA) Also, I have a global clock input nearby I could bring a feedback clock in on. (nearby being the same bank) The clock is sourced by a PLL in the FPGA. The master oscillator is 100MHz, which I double to create the SRAM clock. I'm assuming the idea here is that instead of simply connecting the feedback to the output at the FPGA, I loop the signal back from the SRAM clock input, and use that as the feedback instead? I apologize if that's a stupid question. I'm more of a VHDL/Verilog modeler than a board designer - I'm trying to get my feet wet in hardware.Article: 146762
On Mar 26, 5:12=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Mar 26, 4:14=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > I disagree. =A0In many FPGA projects, speed is the reason for doing > > the project. =A0Many things can be done on existing processors, but > > not quite fast enough. =A0The primary goal, then, is to design > > the logic to be fast. =A0In the case of pipelined arrays, one > > might need to maximize speed/cost, which is, again, a logic > > design problem. =A0 > > > There are also many problems where speed isn't so important. > > Well, to be fair, the discussion about speed was about CMOS design, > and transistor-level CMOS is a different skill than digital design > (although it often resides in the same individual). > > But to your point about FPGAs, I agree that an "FPGA designer" often > needs to be acutely aware of how to make things go fast in an FPGA > (which is often more a matter of being willing to experiment, and > certainly doesn't require the same low-level hardware understanding as > dealing with domino logic does). =A0Where I work, we build real chips, > but emulate them in FPGAs. =A0Gates are so cheap these days, and the > real silicon is so fast, that my mantra to the digital designers is > always to make it work well and fast in the FPGA, and the chip will > take care of itself. =A0If you code in a fashion that is designed to be > highly optimized for real silicon, sure you might save a milli-cent > per chip, but if you weren't able to emulate it at speed (or even if > you were able to emulate it at speed, but only through heroic work by > the FPGA emulator guy and multiple 30 hour PAR sessions), that could > cost you a lot more than your putative savings. > > Regards, > Pat Thomas, 1. Speed is the life of a digital design. 2. When dealing with FPGA, I know how a logic design affects its speed by counting how many number of inputs are there for a logic equation, no more than that. 3. When dealing with modern more than 1GHz ASIC, all logic may be implemented as a domino logic which has nothing to do with how a non- domino logic is compiled by a compiler. In both situation, one doesn't have to know how a non-domino logic is compiled. For example, it is to determine if a 32-bit data is a data zero by following equation: IsZero <=3D a1 or a2 or ... or a31; A digital circuit designer for either FPGA or modern more than 1GHz ASIC doesn't have to understand how the logic is compiled by a compiler: IsZero <=3D (a1 or a2 or ... or a4) or ... (a30 or a31); or IsZero <=3D (a1 or a2 or ... or a3) or ... (a28 ... or a31); The book: Logical Effort: Designing Fast CMOS Circuits (The Morgan Kaufmann Series in Computer Architecture and Design) by Ivan Sutherland, Robert F. Sproull, and David Harris (Paperback - Feb. 16, 1999) tells that when 4 inputs of OR gates may be the fastest. The information is really useless. WengArticle: 146763
On Mar 27, 6:09=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > Guess you didn't read my post where I detailed the estimate of skew to > be ~5% of the timing budget (round trip delay)...and as I said, worth > keeping track of, but likely to be far overshadowed by clock to output > and setup time requirements. =A0Actually I had originally computed it at > half that percentage, twas using 10ns rather than 5 ns clock period. Sorry, I thought you were suggesting the FPGA internal clock that feeds the IOB that feeds the SRAM was all that was needed. The 5% budget does not include the uncertainties for the path from FPGA internals to the outside world. I'm happy to see that radarman's looking to match those delays (and hopefully put together the full timing budget!). > Just like most synchronous logic...back in the old days...one clock, > nothing fancy. You've got to get fancy if you can't make the clocks behave. The SRAM has nice Tsu/Th and Tco values published relative to the external clock. The delays in the FPGA are a little more unbalanced despite the femtoscopic sampling window at the input register. Getting the DLLs to shift the right way to line up the small valid window from the SRAM is a female dog. If *you* can get the FPGA's Tco and Tsu/Th to balance properly for the SRAM interface (using those persnickety single-ended IO standards) then I have my hat off to you in a deep bow with respect.Article: 146764
hi ! Amal wrote: > I am not sure about the author and who maintains this. But you can > easily port these to SystemVerilog DPI if you can afford mixed > language simulation. no thanks, I stay with VHDL :-) > -- Amal yg -- http://ygdes.com / http://yasep.orgArticle: 146765
Peter <peter@peter2000.co.uk> wrote > >http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=290416326824 > A few hours to go :)Article: 146766
I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator that already has a high (baseband) sample rate - around 40-80 MHz. What kind of (single-bit) output rate can you get with a CPLD or FPGA device? -- Randy Yates % "Remember the good old 1980's, when Digital Signal Labs % things were so uncomplicated?" mailto://yates@ieee.org % 'Ticket To The Moon' http://www.digitalsignallabs.com % *Time*, Electric Light OrchestraArticle: 146767
On 3/28/2010 1:31 PM, Randy Yates wrote: > I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator > that already has a high (baseband) sample rate - around 40-80 MHz. > > What kind of (single-bit) output rate can you get with a CPLD or FPGA > device? Hi Randy, You should read the datasheets, or narrow down exactly want you want. There are many different types of output on these parts. Your question is like, "I want to drive from "A" to "B". How fast can a car or motorcycle go?". HTH, Syms. p.s. >200Mbps for single ended CMOS outputs. ;-)Article: 146768
"Symon" <symon_brewer@hotmail.com> wrote in message news:honos0$dkk$1@news.eternal-september.org... > On 3/28/2010 1:31 PM, Randy Yates wrote: >> I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator >> that already has a high (baseband) sample rate - around 40-80 MHz. >> >> What kind of (single-bit) output rate can you get with a CPLD or FPGA >> device? > > Hi Randy, > You should read the datasheets, or narrow down exactly want you want. > There are many different types of output on these parts. Your question is > like, "I want to drive from "A" to "B". How fast can a car or motorcycle > go?". > HTH, Syms. > > p.s. >200Mbps for single ended CMOS outputs. ;-) > > 11.3Gbps on Stratix IV GT PCML outputsArticle: 146769
On 03/26/2010 12:00 PM, Jason Thibodeau wrote: > On 03/25/2010 11:24 PM, David Wiltshire wrote: >> On Mar 26, 6:06 am, Jason Thibodeau<jason.p.thibod...@gmail.com> >> wrote: >>> Is it possible to get a detailed report out of XST, listing the gates it >>> has optimized out of a design? XST is removing some gates that I >>> specifically put into a design, and I want to prevent this. I can use >>> the XST constraints file, but I'd like to see exactly what it is doing. >>> >>> Googling hasn't turned up much, yet. >>> >>> Thanks >>> -- >>> Jason Thibodeau >> >> Not that I'm experienced but whenever I've seen a similar question >> (missing logic) it's been optomised out because you haven't connected >> the output to anything. Try connecting it to a pin out (even if >> that's not where you want it eventually) and see if it turns up. >> >> Dave > > Yes, I ran across that and I connected the output. Only the last gate in > the design is being synthesized. All the other gates, which connect to > it, are being optimized out. > I'd like to bump this. Any word on how Ic an stop it from optimizing my required logic away? Why wouldn't Xilinx just allow me to turn off optimization? -- Jason ThibodeauArticle: 146770
On Mar 28, 2:31=A0pm, Randy Yates <ya...@ieee.org> wrote: > I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator > that already has a high (baseband) sample rate - around 40-80 MHz. > That's a very bad idea. For your sort of application homemade delta-sigma DAC can't match combination of price, SNR, SFDR and power provided by something like AD9754. > What kind of (single-bit) output rate can you get with a CPLD or FPGA > device? > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Remember the go= od old 1980's, when > Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0things were so uncomp= licated?" > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% 'Ticket To The Moon'http://w= ww.digitalsignallabs.com% *Time*, Electric Light OrchestraArticle: 146771
On Mar 27, 9:22=A0pm, radarman <jsham...@gmail.com> wrote: > > I have already added a series termination resistor, since it really > isn't that big a deal. <snip> > Also, I have a global clock input nearby I could bring a feedback > clock in on. (nearby being the same bank) If you're going to feed the clock back, then you'll want to parallel terminate to ground rather than series terminate at the source. Series termination makes the edge look good at the end of the run, intermediate places along the net look like a step half way up and a plateau and then another step up when the reflection comes back. By feeding the clock back, the SRAM will now be right in the middle of the net rather than at the end and will not have a clean edge (the clean edge will be back at the FPGA where the terminator is located). When you parallel terminate to ground, the signal looks the same virtually everywhere on the net. Again, depending on the edge rates of the FPGA, your runs are short enough that you might not need any termination, so allowing for a terminator is cheap insurance...but you want to have the right insurance. Kevin JenningsArticle: 146772
On Mar 28, 1:22=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > plateau and then another step up when the reflection comes back. =A0By > feeding the clock back, the SRAM will now be right in the middle of > the net rather than at the end and will not have a clean edge (the > clean edge will be back at the FPGA where the terminator is located). > Oops, strike the "where the terminator is located" part. Was trying to say that the series terminated clock would be clean at the input pin on the FPGA where it comes back in...NOT at the FPGA output pin where the terminator is located, that would be the location of the worst case plateau. In any case, at the SRAM, which is at the halfway point in the clock net, there will be a plateau. How big of a plateau depends on the edge rate of the FPGA output pin. Kevin JenningsArticle: 146773
On 3/28/2010 5:51 PM, Michael S wrote: > On Mar 28, 2:31 pm, Randy Yates<ya...@ieee.org> wrote: >> I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator >> that already has a high (baseband) sample rate - around 40-80 MHz. >> > > That's a very bad idea. > For your sort of application homemade delta-sigma DAC can't match > combination of price, SNR, SFDR and power provided by something like > AD9754. > I'm pretty sure on price and power (I assume efficiency?) his solution does match your suggested alternative given that, from details in his previous postings on this newsgroup, the FPGA/CPLD device is a sunk cost. I agree with your other acronyms though! Cheers, Syms.Article: 146774
On 3/26/2010 9:13 PM, radarman wrote: > > I've only done one other "high speed" design, with a Gig-E PHY, but I > was able to get all of the signals to within +/- 5 mils on that board. When you did this, you took into account the different flight times in the packages themselves, I hope! For sure the leadframes don't have matched lengths on the signals from the die to the PCB pad. In summary, what the other guys said, 6 inches a ns! Cheers, Syms.
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