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 Thu, 7 Apr 2005 16:17:10 +0800, "kingkang" <305liuzg@163.net> wrote: >Hi >I wrote a sdram controller which has pass the RTL simulation. >But when it come to the Altera cyclone board,the read/write >data were wrong.I have written sdram with some data,and then >I read the data from sdram.But found the data is not equal to >what have been written into the sdram.One or Some bits have >wrong.It is random bit error!I don't know what's wrong.About >the clock? or board delay? or else?Please help me out! >Thanks and Regards! > Did you set up the right delay for the clock of the SDRAM ? I use a 288 deg phase shift on my pll to feed the SDRAM, at 50 MHz. It can be something else for you thought. That's one of the most important thing. Regards NickArticle: 82151
Quiet Desperation wrote: > Any chance of there ever being an FPGA where one or more of the > SelectRAM blocks is nonvolatile? > > I design a lot of stuff that is programmable and reconfigurable beyond > the FPGAs. I commonly need to store the setting of digital delay chips > and switch settings and other control lines so that a unit powers up > with everything in the state desired by the end user. > > Currently I use little automotive serial EEPROMs, but, dang but it'd be > nice to have a little EEPROM inside an FPGA. Just one 18Kbit block > would do wonders. The Altera MAX II parts can do this. They contain 8kb of flash that can be both read and written by your design to store anything you want. See http://www.altera.com/products/devices/cpld/max2/features/flash/mx2-flash_memory.html for details on how to use it. Vaughn Altera [v b e t z (at) altera.com]Article: 82152
Praveen, Well, the problem is that a SEFI might hit the line which controls the "clean-out" (zeroization of all config and BRAM). If that happens, then basically, the upset has caused the device to re-initialize (or just go stupid). There is no way to prevent this from happening. We are researching how to design so this can not occur, but this is a very tough problem. An event can strike any transistor. uP, ASSP, and ASICs also have SEFI behavior. And yes, theirs is incredibly rare as well. FPGAs are similar in SEFI behavior to all the other devices. Maybe better. I haven't see the SEFI x-section for a Pentium chip. Yes, these SEFI cross sections are incredibly small, and the probability is also small that this happens, but presuming it does happen, there is really nothing at all that you can do (except detect that it happened, and reconfigure the device from scratch). Systems that have to be hardened against SEFI will use a CPLD, or other device, to detect that a SEFI occured, and reconfigure the FPGA. In the time it takes to recongize the SEFI, and reconfigure, all data is lost (unless it is part of a redundant system, which is commonly used for critical applications). In the order of increasing robustness: - no measures taken (susceptible to SEU, and SEFI): the vast majority of all FPGA applications fall into this category, as do ASIC, ASSP, and uP. - use TMR on the user pattern to remove the effcts of SEUs completely, still susceptible to SEFI: a step that gets rid of SEU effects. Also is used in some special ASICs for mil/aero. - scrub the config memory (continually reload the config while operating): used my many space probes, still susceptible to SEU and SEFI, but recovers very quickly, and SEUs do not accumulate leading to an overall availability improvement. This is what the Mars Lander Pryo controller did. The landers themselves just reconfigure once a day (enough to mitigate the effects they anticipated). - scrub and use TMR: now we only have SEFI to worry about. The best choice for getting to the level of reliability where the only thing that can be of any trouble is a SEFI. Good enough for just about anything except where human life is concerned. - readback the config and fix the bits that flipped (use of V4 FRAME_ECC): similar to scrubbing, but faster and less hardware. Same as above non-TMR scrubbing case. - readback and fix config for a TMR design: only SEFIs to worry about. Good for just about anythign excepting a human life. - monitor the device with another device (eg CPLD) for SEFI, reconfigure if a SEFI occurs: used in critical space and avionics. May also be doing TMR, scrubbing, etc. as well. This is still not good enough for a human life situation unless the time to recover is fast enough not to matter. - provide one other FPGA, dual redundant: use of dual rednundant allows for transfer away from a fault, used for even higher availability (each individual unit may be scrubbing, use TMR, etc. There may also be a "voter" to switch between FPGA's in case of SEFI). Almost the highest level of availability, in that we still don't trust even this arrangement for human life situations. It may get used in military systems where the probabvility of death is much much higher than the probability of a systems failure, so added system availability is not needed (a real toght decision, one I gladly don't have to make). - fully duplicated, dual redundant: used by things like commercial airliners, and airports. Two redundant systems that can be selected manually by the air traffic controllers or pilots in the unlikely event that one of the redundant systems fail. Within each redundant system, various levels of protection may, or may not be necessary, since the entire system is duplicated. A system with no scrubbing of the FPGAs, but with many self-checks that are done independent of the FPGA is used in fact in all US and Canadian Airports for all communications between the ground and air, and ground and ground. I designed it. If one redundant unit either detects a failure in itself, or the redundant unit it is paired with detects that its partner has gone stupid, it switches itself in, and the other out in less than 50 ms. If the air traffic controllers can't talk to the airplanes for some reason, they have a manual switch they push to transfer everything over to another set of com links, radios, antennas, etc. AustinArticle: 82153
> I am doing a literature survey on SEFIs in Xilinx FPGAs. Unfortunately, > there are not many papers on this. It might either be because this is > not a major issue or because there is not really much work done. You might find the following interesting/relevant ... (It's just something I came across while Googling) ... http://klabs.org/mapld04/presentations/session_c/4_c144_swift_s.ppt KrisArticle: 82154
Eric Smith <eric@brouhaha.com> writes: > "JJ" <johnjakson@yahoo.com> writes: > > If some processor that is not any way MIPs like can otherwise perform a > > register ld/st for a word on any byte boundary is that a problem, or > > only if the rest of it is MIPs like too. > > It's not the unaligned load/store per se that is patented; many processors > have done that. > > What MIPS invented and patented was the idea that instead of having the > hardware deal with unaligned bus accesses, they require software to > issue *two* instructions to do an unaligned access. One does the > "left part" and one does the "right part" of the word. This must be a misstatement or it's a ridiculous patent. How can a patent be issued for NOT doing something? I can get a patent for an anchor that requires the addition of propulsion and lifting surfaces so that it can fly on its own? There's also the "obvious to anyone experienced with the technology" thing. > The normal MIPS load and store instructions require alignment just as > on most other RISC processors. -- ---------------------------------------------------------------------- Everett M. Greene (The Mojave Greene, crotalus scutulatus scutulatus) Ridgecrest, Ca. 93555 Path: mojaveg@IWVISP.com Murphy's law of aviation and large over-the-road vehicles: Whichever direction you're going, it'll be into a stiff headwind. Murphy's law of farming and earthmoving: Whichever direction you're going, there's a tailwind of the same speed and direction as your movement.Article: 82155
I'd imagine this is mostly the same as or is infact what they got from the Octiga Bay purchase awhile back. The article it self is fluff, but it would be interesting to know what various customers are actually doing with these. Anyone know the price? I wonder though about some applications split between an FPGA and Opterons. If the app doesn't need too much of the Opterons abilities, probably better off using a couple of soft/PPC cpu cores right in the fabric. Now if FPGAs ever get embedded FPUs maybe 1 for every n muls or so, probably would'nt need the external cpu. regards johnjakson at usa dot com transputer2 at yahoo dot comArticle: 82156
I am looking for ADPCM IP core Thanks for helpArticle: 82157
Peter Alfke wrote: > If you use STROBE as a rising-edge clock input, then excessive noise > might be superimposed on its falling edge, such that the falling edge > actually contains a rising edge clock, which would give you weird > timing. > Just a wild guess... > Peter Alfke > Hello Peter, Its DDR scheme. Data is clocked in both on the rising edge and falling edge. My main question is still how slow is too slow? Thanks BrijeshArticle: 82158
Everett M. Greene wrote: > Eric Smith <eric@brouhaha.com> writes: > > "JJ" <johnjakson@yahoo.com> writes: > > > If some processor that is not any way MIPs like can otherwise perform a > > > register ld/st for a word on any byte boundary is that a problem, or > > > only if the rest of it is MIPs like too. > > > > It's not the unaligned load/store per se that is patented; many processors > > have done that. > > > > What MIPS invented and patented was the idea that instead of having the > > hardware deal with unaligned bus accesses, they require software to > > issue *two* instructions to do an unaligned access. One does the > > "left part" and one does the "right part" of the word. > > This must be a misstatement or it's a ridiculous patent. > How can a patent be issued for NOT doing something? > I can get a patent for an anchor that requires the > addition of propulsion and lifting surfaces so that > it can fly on its own? > > There's also the "obvious to anyone experienced with > the technology" thing. > > > The normal MIPS load and store instructions require alignment just as > > on most other RISC processors. It's a poor statement; it's not a ridiculous patent, although, as I have explained before in comp.arch [search: mashey lwl], in retrospect, I'd just as soon we hadn't done it. Even though it was easy at the time [Summer 1985], but turned out to get far less use than we'd expected, at least partly because the rise of RISCs with strict alignment got many people to clean up code. As noted elsewhere, if I were doing it again, I'd probably do something different. The patent is 4,814,976 by Hansen & Riordan. The *point* of the patent was that if you have a straightforward RISC pipeline that supports caches and paged virtual memory, then requiring hardware to do all the work of handling arbitrarily-aligned data [i.e., crossing cache-line or worse, page boundaries] adds *greatly* to the implementation complexity, and one doesn't want to do this. [The implementation penalty for some microcoded CISCs cn be much less.] The MIPS solution was some much simpler hardware (very minimal additions, and nothing tricky] beyond what was there, that allowed compilers to generate code to deal with unaligned accesses that sometimes came up from legacy code without burdening the base hardware design. [This is one of those classic "It takes a bunch of hardware to make this both fast and right, and it means a lot of checking for cases that hardly ever happen, but if the hardware is wrong, the bugs are horrible to find." cases that hardware designers hate.]Article: 82159
Symon wrote: Hello Symon, > Brijesh, > Have you considered using the strobe signal at a latch enable rather than a > clock? Rise time is then unimportant. t\The IOBs' storage elements can be > latches, IIRC. Its DDR scheme so simple Latch scheme wont work, as data is only stable during the rising/falling edge of the strobe. Even otherwise, as I mentioned there are multiple channels and all of them work just fine, except this one. Thats led me to believe its not design problem, but SI issue. > As for pin impedances, you need to use the IBIS files to determine this. Do > you have HyperLynx? Have not really worked with IBIS files. I did peek into IBIS files for the first time and found they do not have a direct number. :-) Don't have HyperLynx, will read up about it. Thanks Brijesh > Cheers, Syms. > >Article: 82160
There is no fundamental limit. A flip-flop will be clocked, even if the clock takes seconds or minutes to rise. But the longer the transition time, the bigger the chance of picking up noise, and creating a double-pulse. And the fact that you use DDR does not invalidate my prvious response. Noise then has a chance to disturb either edge or both. Peter Alfke ============ Brijesh wrote: > Peter Alfke wrote: > > > If you use STROBE as a rising-edge clock input, then excessive noise > > might be superimposed on its falling edge, such that the falling edge > > actually contains a rising edge clock, which would give you weird > > timing. > > Just a wild guess... > > Peter Alfke > > > > Hello Peter, > > Its DDR scheme. Data is clocked in both on the rising edge and falling edge. > > My main question is still how slow is too slow? > > Thanks > > BrijeshArticle: 82161
David wrote: > On Wed, 06 Apr 2005 11:08:53 +1200, Jim Granville wrote: > > > > > I heard that the NIOS II is 'very similar' to MIPS - can anyone who > > knows both cores in detail comment ? > > > > -jg > > I don't know the MIPS in detail (long ago, I read a book on the > R2000/R3000 architecture which I picked up in a second-hand bookshop), but > there are certainly some fundamental similarities. Each is a 32-bit RISC > core, with 32x32-bit registers, orthogonal instruction set, etc. The NIOS > II is a little odd (IMHO) in that it has some registers with dedicated > purposes and supervisor-only access. I think, however, that quite a lot > of 32-bit RISC architectures (ARM, Microblaize) would be "very similar" at > this level. See http://www.altera.com/literature/lit-nio2.jsp. NIOS II is clearly different from MIPS I, but I'd guess that whoever designed NIOS II was quite familiar with MIPS, as a lot of nomenclature (register names, many of the register allocations, some opcode names) are rather MIPS-reminiscent. Of course, lots of ISAs have borrowed from each other, and and ADD is an ADD :-). However, of 32 registers, at least 25 [0-23, 31] are allocated exactly as in MIPS, and generally have same names, even when those aren't obvious. People may recall my comments in the WIZ discussion about wishing not to have done MUL and DIV the way we did in MIPS, but to have done it more like the way Alpha did it later, and NIOS II does that. NIOS II has no (MIPS) LUI instruction, but has ANDHI, ORHI, XORHI. We almost did ANDHI or ORHI (as they subsume LUI, but have other uses), but thought about it a little too late [Summer 1985] to get in. In general, NIOS II feels like a sensible design for a small embedded core, a bit more like MIPS than like any other RISC, but in general, doing things different that in fact match with things that in retrospect, we might well ahve done different.Article: 82162
Kris, Nice ppt presentation. They quote 65 years in orbit around the earth mean time between SEFI. We have published results of heavy ion testing that states we are at (least) 1.5E-6 SEFI/day in earth orbit, which is 1,800 years between SEFI. Not sure where the discepancy comes from. It may be that work was done on commercial parts, instead of using the Qpro series (which has EPI wafers). If you are going to go into space, you are better off using the Qpro devices. http://direct.xilinx.com/bvdocs/publications/ds124.pdf Page 3, Table 3. Not sure that EPI alone would have more than a factor of 2 improvement in upset rate (SEU or SEFI). Could be that the authors of the ppt also divided by 24 (thinking our specification was in hours). That yields a number closer (76 years--but wrong nonetheless). Sea level is ~ 40 times less upsets, so a SEFI at sea level is ~ 7,300 years. We have some customers with more than 250,000 Virtex II's in the field (monitored), and that would mean they would have ~ 35 SEFI's a year. Since they have had far fewer (in fact: none reported), one has to take even this projection as overly conservative for us earthlings on the ground. Also, space based projection of failures use heavy ions, and earth based projections of failures use protons, and neutrons. There is factor of (at least) 1e5 to 1e6 there in terms of the size of the "bullet!" For example, the cross section for a Virtex II memory cell is ~2.283E-14 for neutrons, and is ~8E-8 for a heavy ion. These are from recent tests with neutrons and with heavy ions (Xilinx Radiation Effects Consortium). Sort of like a grain of sand vs. a locomotive engine. This is a good analogy: if you are hit by a train, what do you do? If you are hit by a grain of sand, what do you do? Compare our Xilinx Virtex II FPGA with a popular uP: (for SEFI) http://www.spacemicro.com/services_files/SM_NSREC_Paper_2004.pdf with up to a few SEFI per day (worst case), to one SEFI a year (best case). So the next time you see the "blue screen of death" on your laptop computer, was that a SEFI, or was it Microsquat? AustinArticle: 82163
In article <1112905289.368801.161230@g14g2000cwa.googlegroups.com>, John Mashey <old_systems_guy@yahoo.com> wrote: > >The MIPS solution was some much simpler hardware (very minimal >additions, and nothing tricky] beyond what was there, that allowed >compilers to generate code to deal with unaligned accesses that >sometimes came up from legacy code without burdening the base hardware >design. And the Nick Maclaren comment is that most of those codes are so horrible that they probably aren't getting right answers anyway. I strongly disapprove of fixing up alignment in software - it is much better to diagnose the failure and get the programmer to fix the broken code. Notice that this requires the hardware to do even less :-) Regards, Nick Maclaren.Article: 82164
John Mashey wrote: [re. misaligned load patent] > It's a poor statement; it's not a ridiculous patent, although, as I > have explained before in comp.arch [search: mashey lwl], in retrospect, > I'd just as soon we hadn't done it. Even though it was easy at the time > [Summer 1985], but turned out to get far less use than we'd expected, > at least partly because the rise of RISCs with strict alignment got > many people to clean up code. As noted elsewhere, if I were doing it > again, I'd probably do something different. > > The patent is 4,814,976 by Hansen & Riordan. > > The *point* of the patent was that if you have a straightforward RISC > pipeline that supports caches and paged virtual memory, then requiring > hardware to do all the work of handling arbitrarily-aligned data [i.e., > crossing cache-line or worse, page boundaries] adds *greatly* to the > implementation complexity, and one doesn't want to do this. [The > implementation penalty for some microcoded CISCs cn be much less.] > > The MIPS solution was some much simpler hardware (very minimal > additions, and nothing tricky] beyond what was there, that allowed > compilers to generate code to deal with unaligned accesses that > sometimes came up from legacy code without burdening the base hardware > design. I have never seen either the patent or the relevant MIPS asm code generated, but it seems to me that the hw I'd want would look like this: a) LoadAligned r1=[r0] where any low-order bits in r0 would be ignored. b) either LoadAligned r2=[r0+regsize] or LoadAlignedRight r2=[r0] Both of these would load the next aligned word c) (The somewhat tricky one!) ShiftToAlign r3=r1,r2,r0 which is defined to merge r1 & r2, using the loworder bits from r0 to determine the number of bytes to shift. Since this opcode takes four register operands, I'd suggest forcing the destination to be the same as the low-order source register, i.e.: ShiftToAlign r1=r2,r0 defined as r1 = (r1 >> (r0 & 7)*8) | (r2 << (8-(r0 & 7))*8); Doing it this way makes it easy to process an array of misaligned data, since the second source register is unmodified, so it can be used as the primary (modified) source during the next iteration. Terje -- - <Terje.Mathisen@hda.hydro.com> "almost all programming can be viewed as an exercise in caching"Article: 82165
we are using xilinx xc2v3000 (virtex II) FPGA we are trying to do 42 MACs. right now we are doing the multiplication, followed by the addition. is there an MAC component available that can do this in one clock cycle? -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257Article: 82166
On Mon, 4 Apr 2005 15:49:44 +0000 (UTC), weingart@cs.ualberta.ca (Tobias Weingartner) wrote: >Does anyone have experience with reverse engineering ASIC (black box) >into equivelant FPGA devices (pin equivelant with a sub-board if necessary)? I did a project like this about 8 years ago, except it was ASIC to FPGA to ASIC. The original ASIC was a standard product from a company you know, as in it was a standard product, but they used ASIC design methodology. A data sheet was available, but had insufficient info about behavior for all possible input scenarios. The client was using thousands of these parts per month, and had big expensive boards that they could not respin for a different package. The original ASIC had a package and pinout that did not match any FPGA. The original vendor was surprisingly unhelpful, as no more chips, no hand over of product to one of the after market silicon houses, no willingness to find their design files to help us. We did find an ASIC vendor that could match the package and power, ground, I/O pin requirements. (FPGA on carrier board was also considered but we didn't have the vertical clearance.) I reverse enginered the original part based on the application circuit, the incomplete data sheet, and common sense about how the original (reasonable I hope) designers must have done things. I created an FPGA design. The customer created a very large set of test vectors, and ran it through their system, and recorded the results. I designed a PCB that plugged into a PC, and had a socket for the original ASIC, and the FPGA. I got one of the original ASICs, put it on my board and ran the test vectors from the client against the ASIC, and checked that their result vectors matched. I wrote a test coverage program and ran their vectors through it, and identified what they weren't testing. I wrote a few million more vectors, and ran them through the original ASIC. I updated the test vector set, and the expected response. I wrote an addendum to the data sheet that covered the ommisions and ambiguities. I ran the test vectors against my FPGA design in a simulator and resolved any mis-matches. I then ran the test vectors against my FPGA design. I got the customer to sign off on the results. A new ASIC was designed from the FPGA design. I ran the test vectors against my ASIC design in a simulator. There were no mis-matches. I got the customer to sign off on the results. The new design was sent off to the ASIC vendor, who insisted on adding scan test to the design. Their ATPG program got 93% coverage. My test vectors were about the same size and got 99.8% coverage. The scan test was removed from the design. Chips were fabricated. The new ASICs came back, and I plugged one into my test board, and ran all my test vectors. The chip worked perfectly. The client loaded one of their production boards with the new chips and it worked fine. Philip Freidin Philip Freidin FliptronicsArticle: 82167
I don't buy this argument, at least some of the time. I can think of atleast 1 application in mind which guarantees most accesses not aligned and for which a SW aligned version would be ugly either by doing the align in SW or by accessing sequential bytes. Example parser performing lexing of string matches straight from the lcc compiler by Hanson-Fraser.. In lcc each pattern match is something like this, mostly auto generated for a given dictionary, so for matching "while" if (cp[0]=="while"[0] && cp[1]=="while"[1] && cp[2]=="while"[2] && cp[3]=="while"[3] && cp[4]=="while"[4]) xxxx This obviously requires 5 possible byte matches and 5 conditional branches, and most matches will fail until the right production rule is reached and all matches pass. VC6 compiler produces good code without trying, lots of byte cmp and bxx.pairs In a rewrite I'd would (and do) use if (same5(cp,"while")) xxxx where same5 is an inlined match of 2 longs, at byte offset 0, then 1. Now thats 2 long matches and 2 branches. Now C might have a tiny dictionary of mostly small words but the Verilog language has 200 plus words and many can be as long as 20chars with many words giving false initial matches. So there is an inline sameN as fn() from 1 to 20chars which takes upto 5matches ie 4x less work. Again VC6 produces good asm, nearly 4x less than using byte serial checking. Ofcourse I know this is a problem for RISCs that don't do nonaligned accesses, but I really hate to see code 4x slower even if its probably <1% of the total runtime. Now the cpu has to do a bit more work some of the time as JM pointed out. I few more mostly-unaligned kernals come to mind pretty quickly without thinking too hard, compression etc. I wonder if the RISC criteria for extreme simplicity need to be reexamined when most RISCs are way more complex in other depts that are far less visible to the programmer. regards johnjakson at usa dot com transputer2 at yahoo dot comArticle: 82168
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:42556b03$0$289$cc9e4d1f@news-text.dial.pipex.com... > http://www.fpgajournal.com/articles_2005/20050405_cray.htm Apart from abusing the word 'leverage' as a verb, the article seems big on gas and small on substance. Which is essentially "Cray machines are using Xilinx FPGA as computing engines". BFD. The Sanger Centre has used FPGA solutions to accelerate pattern-matching in DNA sequencing. And that was not rocket science either, as this is essentially comparing a pattern with bits in a shift register.Article: 82169
Brijesh wrote: > Symon wrote: > > Hello Symon, > >> Brijesh, >> Have you considered using the strobe signal at a latch enable rather >> than a clock? Rise time is then unimportant. t\The IOBs' storage >> elements can be latches, IIRC. > > > Its DDR scheme so simple Latch scheme wont work, as data is only stable > during the rising/falling edge of the strobe. > > Even otherwise, as I mentioned there are multiple channels and all of > them work just fine, except this one. Thats led me to believe its not > design problem, but SI issue. I'd look to see why is that channel slower ? Slow edges also mean timing skew. You could also deliberately slow a good one down, to see if that causes similar errors, and slow the poor one a little more, to see if it worsens. -jgArticle: 82170
Dave - I think the CCLK pin is either open or blown out. I changed the FPGA to be Master Serial mode, lifted the CCLK pin at my driver, and powered up. No sign of the FPGA producing a CCLK. Unfortunately, the FPGA is in a BGA package, so I can't examine the pin. I think this expereiment shows either a floating or blown out CCLK pin on the FPGA. :( Thanks for your help. John PArticle: 82171
"johnp" <johnp3+nospam@probo.com> wrote in message news:1112915406.501227.138250@g14g2000cwa.googlegroups.com... > Dave - > > I think the CCLK pin is either open or blown out. I changed the FPGA > to be Master Serial mode, lifted the CCLK pin at my driver, and > powered up. No sign of the FPGA producing a CCLK. Unfortunately, > the FPGA is in a BGA package, so I can't examine the pin. I think > this expereiment shows either a floating or blown out CCLK pin > on the FPGA. :( > > Thanks for your help. > > John P > BGAs are like women -- you can't live with them and you can't live without them. IMHO. BobArticle: 82172
Hello all, I have a question regarding the layout of a BGA packaged FPGA. For the first time I am using multiple ground planes, and I am curious if when routing the ground balls from the BGA package, do I need to have a via that attaches to both ground planes, or is having it attach to one plane directly under the package enough, as long as there are vias elsewhere that tie the two planes together. I would ideally like to use blind vias for the BGA layout so I can get components on the underside of the PCB as well without any through hole vias getting in the way. My satckup is as follows: 1 - signal/components 2 - ground plane 3 - signal 4 - signal 5 - power plane 6- ground plane 7 - signal 8 - signal 9 - power plane 10 -signal I was planning on mounting the caps underneath the BGA package on the underside, again using blind vias so there is more room for signal routing, but I'm considering mounting them around the package on the top side now. 100 MHz is the highest frequency signal anywhere on the board, and most signals are 50 MHz speed (or there abouts). Any comments would be greatly appreciated. Thanks, Jason jberringerNOSPAMatNOSPAMsympatico.ca (remove NOSPAM)Article: 82173
Tobias Weingartner wrote:
>If I had specifications, I'd not waste my time on trying to reverse
>engineer the ASIC. :-)
>
>
>
If you have a working copy of the ASIC, you can develop your own set of
specs based on observations of the ASIC's behavior, no? Granted, it may
take a bit of work to ferret out all the operation, but it is likely
still easier than trying to reverse engineer from masks.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 82174All of this was fairly well-covered in a *1988* comp.arch thread called "RISC data alignment", including the reasons why computer *vendors* were forced to deal with these alignment issues, i.e., IBM (& then DEC VAX) FORTRAN (interaction of EQUIVALENCE & COMMON, INTEGER*2, and sometimes call-by-reference) .
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