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
Hello again The programmable logic data book (1998) explains that in more detail on page 4-315 to 4-318, but not down to the level where each bit in the data frame is explained. That is probably a big secret. At least to me it is. I agree that it would be interesting to know, though. /Thomas Anthony Tekatch wrote: > > Hello, > > That file only shows how the preamble data is generated. I would like to > know how to construct the entire configuration data block (something that > the Foundation software does). > > In article <39B37AB7.3730F97B@emw.ericsson.se>, Thomas Karlsson > <thomas.karlsson@emw.ericsson.se> wrote: > > Hi, > > > > I think this appnote might be what you are looking for > > > > http://www.xilinx.com/appnotes/bus_conf.pdf > > > > Thomas > > > > Anthony Tekatch wrote: > >> > >> Which Xilinx APP note/pdf shows the details of the Configuration Data > >> for the XC3000A series? > >> > >> I would like to dynamically program that device with a microprocessor. > >> > >> Thanks in advance.Article: 25276
Hi Richard, All I can say is that the problem does not remain in 3.1i, which improves par times enormously! Johan, email vhdl_ninja@yahoo.com news@rtrussell.co.uk wrote: > > The problem of very slow routing of PWR/GND nets is > supposed to be fixed in 2.1i Service Pack 6, but I > am still suffering from it (running the Unix tools > on a Sun Ultra 10 workstation). An XCV600 is taking > about 8 hours to build, of which over 7 hours is the > PWR/GND routing (all signals are successfully routed > in under 40 minutes). Does the problem remain in SP6, > or is this a specific issue related to the use of the > Unix version ? > > Richard. > http://www.rtrussell.co.uk/Article: 25277
Ray, With the cost of the larger SRAM devices (XCV1000 and up) I have seen several customers recently who have chosen to socket the SRAM BGA devices (Xilinx/Altera) to allow the devices to be reused. IMHO this makes sense in a prototype environment. If a proto board has to be scrapped or has out-lived it's usefullness, at least the cost of the parts can be recovered. It's a trade-off between the removal and re-balling of the device versus a socket. If a high quality socket is used this is a reasonable trade-off. The BGA sockets I've seen are better than the QFP sockets and tend to induce very few problems when properly used. I believe if you look back into this thread, this reasoning is consistent with the original posters thinking. Daniel Elftmann Actel Area Technical Manager (ATM that does not dispense cash, except to my wife) "Ray Andraka" <ray@andraka.com> wrote in message news:39B2D090.455347C7@andraka.com... > Why would you do this on an SRAM based FPGA? The socket just adds one more > thing that can go wrong, and nothing sucks quite as much as socket induced > problems. With the SRAM based parts, just make sure you leave a way to laod a > program in directly instead of in a PROM or buried in the processor ROM build. > > "Nicholas C. Weaver" wrote: > > > > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>, > > John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: > > >Ben, > > > > > >thanks, but I have a situation where all the data must be available to > > >the core algorithm at once, and, besides, I'd lose pins faster than > > >I'd gain them if I were to partition things into multiple chips. > > > > > >This chip has to be connected to nine 12-bit flash ADCs, two big banks > > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core > > >algorithm must do massively nasty pipelined parallel stuff on the ADC > > >data streams at 60 MHz or so. > > > > One suggestion: BGA sockets. Several manufacturers make BGA > > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which > > will fit various FPGAs. They have the nice property of they also BGA > > mount, with an identical profile, so you can use a socket during > > development and then solder down the parts when the board goes into a > > higher level of production. > > -- > > Nicholas C. Weaver nweaver@cs.berkeley.edu > > -- > -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 or http://www.fpga-guru.comArticle: 25278
>>From the apps I've dealt with, by the time you finish playing with the prototype, the part prices are a fraction of what you paid for them, and the extra debug time due to one faulty socket more than pays for that part. Besides, with SRAM based devices, you can often reuse a prototype on the next project at least for early development. Elftmann wrote: > > Ray, > > With the cost of the larger SRAM devices (XCV1000 and up) I have seen > several customers recently who have chosen to socket the SRAM BGA devices > (Xilinx/Altera) to allow the devices to be reused. IMHO this makes sense > in a prototype environment. If a proto board has to be scrapped or has > out-lived it's usefullness, at least the cost of the parts can be recovered. > It's a trade-off between the removal and re-balling of the device versus a > socket. If a high quality socket is used this is a reasonable trade-off. > The BGA sockets I've seen are better than the QFP sockets and tend to induce > very few problems when properly used. > > I believe if you look back into this thread, this reasoning is consistent > with the original posters thinking. > > Daniel Elftmann > Actel Area Technical Manager (ATM that does not dispense cash, except to my > wife) > > "Ray Andraka" <ray@andraka.com> wrote in message > news:39B2D090.455347C7@andraka.com... > > Why would you do this on an SRAM based FPGA? The socket just adds one > more > > thing that can go wrong, and nothing sucks quite as much as socket induced > > problems. With the SRAM based parts, just make sure you leave a way to > laod a > > program in directly instead of in a PROM or buried in the processor ROM > build. > > > > "Nicholas C. Weaver" wrote: > > > > > > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>, > > > John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: > > > >Ben, > > > > > > > >thanks, but I have a situation where all the data must be available to > > > >the core algorithm at once, and, besides, I'd lose pins faster than > > > >I'd gain them if I were to partition things into multiple chips. > > > > > > > >This chip has to be connected to nine 12-bit flash ADCs, two big banks > > > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core > > > >algorithm must do massively nasty pipelined parallel stuff on the ADC > > > >data streams at 60 MHz or so. > > > > > > One suggestion: BGA sockets. Several manufacturers make BGA > > > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which > > > will fit various FPGAs. They have the nice property of they also BGA > > > mount, with an identical profile, so you can use a socket during > > > development and then solder down the parts when the board goes into a > > > higher level of production. > > > -- > > > Nicholas C. Weaver > nweaver@cs.berkeley.edu > > > > -- > > -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 or http://www.fpga-guru.com -- -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 or http://www.fpga-guru.comArticle: 25279
3.1 does seem to fix that problem. One bugger with 3.1 is if the placement isn't going to meet timing, it spends an awful long time trying a little harder before it gives up. That's a bit of a bugger if you are trying to push something to see how fast it'll go as opposed to meet timing for a particular target. If your placement makes meeting timing relatively easy, the tool runs very quickly...I've got a very full 97%)XCV400 that's placing and routing in under 5 minutes, with all the datapahth stuff but not control logic floorplanned. Johan Petersson wrote: > > Hi Richard, > > All I can say is that the problem does not remain in > 3.1i, which improves par times enormously! > > Johan, > email vhdl_ninja@yahoo.com > > news@rtrussell.co.uk wrote: > > > > The problem of very slow routing of PWR/GND nets is > > supposed to be fixed in 2.1i Service Pack 6, but I > > am still suffering from it (running the Unix tools > > on a Sun Ultra 10 workstation). An XCV600 is taking > > about 8 hours to build, of which over 7 hours is the > > PWR/GND routing (all signals are successfully routed > > in under 40 minutes). Does the problem remain in SP6, > > or is this a specific issue related to the use of the > > Unix version ? > > > > Richard. > > http://www.rtrussell.co.uk/ -- -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 or http://www.fpga-guru.comArticle: 25280
> The programmable logic data book (1998) explains that in more detail on > page 4-315 to 4-318, but not down to the level where each bit in the > data frame is explained. I do not have any printed manuals and cannot find that one on their web site. > That is probably a big secret. At least to me it is. I agree that it > would be interesting to know, though. I certainly hope it's no secret.. I'm sure there must be a market for programming the devices from uP generated data rather than predefined layouts. I have a "support" request in to Xilinx, hopefully I'll get an answer shortly and post the results here. AnthonyArticle: 25281
Elftmann wrote: > > Ray, > > With the cost of the larger SRAM devices (XCV1000 and up) I have seen > several customers recently who have chosen to socket the SRAM BGA devices > (Xilinx/Altera) to allow the devices to be reused. Sorry to jump in here, but do you have any prices for the bigger BGA sockets ? The last time I checked ( two years ago) the sockets were MUCH more expensive than the parts. cheers, emanuelArticle: 25282
Looking for simulation model (VHDL) for 8101 or 8104 Regards RonArticle: 25283
Hello, does somebody have experience about using the tool Statecad from VSS ? Is ist suitable for more complex design and why there is no affordable version for students?? Thanx for more Danijel Sebalj, HamburgArticle: 25284
This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a very low price froma customs auction. They are new but come without any waranty. I will buy 50 or so for myself, but I will happily take your orders and buy more for $5 a piece plus international shipping (and customs to some countries) 10 Pieces minimum. Please send me your orders via email with your full email and postal address. CU, Kolja Sulimma Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25285
Johan Petersson <Johan.Petersson@uab.ericsson.se> wrote: : All I can say is that the problem does not remain in : 3.1i, which improves par times enormously! Actually it turns out that the problem I am having is related to the use of very large numbers of SRL16 shift- registers, which is resulting in over 25000 VCC routes! I have confirmed that the problem is just the same in 3.1i; it is described at support.xilinx.com thus: "Currently map generates a GLOBAL_LOGIC1 and GLOBAL_LOGIC0 signal to drive constants onto the F & G inputs of LUT RAM used in the SRL library element. The extreme number of VCC loads that can occur in such designs will often lead to excessive router run time as well as poor circuit performance due to route congestion." The solution recommended is to add the environment variable XIL_MAP_NOSHIFTONES, but when I do this 'bitgen' aborts with over 25000 errors telling me that the F and G inputs are not connected! If I ignore these errors (bitgen -d) the device doesn't work, exhibiting all the symptoms of the shift- registers not operating correctly. Richard. http://www.rtrussell.co.uk/Article: 25286
Hi Ray, I agree 100% about the long routing times when you have a "bad" placement. A good idea to avoid that situation is to run the par with the -n 0 flag which tells it to perform loads and loads of place'n'route runs with different -t values. There is also a flag that disables the router so that you can let the placer run with different "cost table entries" as a background job - when the check sum is low enough you kill the bastard and run with -t x, no -n and WITH the router enabled....... I don't remember the name for the "disable router" flag :) Finally you can tell the router explicitly how many iterations to run. If you constrain it with for example -i 1, it will only run one iteration regardless of how ugly the placement might be! There is always much to discuss about FPGA's, isn't it!!?? Regards, Johan Petersson, Engineering Manager, Wireless Digital Intelligence ltd, Sweden email (private) vhdl_ninja@yahoo.com :) Ray Andraka wrote: > > 3.1 does seem to fix that problem. One bugger with 3.1 is if the placement > isn't going to meet timing, it spends an awful long time trying a little harder > before it gives up. That's a bit of a bugger if you are trying to push > something to see how fast it'll go as opposed to meet timing for a particular > target. If your placement makes meeting timing relatively easy, the tool runs > very quickly...I've got a very full 97%)XCV400 that's placing and routing in > under 5 minutes, with all the datapahth stuff but not control logic > floorplanned. > > Johan Petersson wrote: > > > > Hi Richard, > > > > All I can say is that the problem does not remain in > > 3.1i, which improves par times enormously! > > > > Johan, > > email vhdl_ninja@yahoo.com > > > > news@rtrussell.co.uk wrote: > > > > > > The problem of very slow routing of PWR/GND nets is > > > supposed to be fixed in 2.1i Service Pack 6, but I > > > am still suffering from it (running the Unix tools > > > on a Sun Ultra 10 workstation). An XCV600 is taking > > > about 8 hours to build, of which over 7 hours is the > > > PWR/GND routing (all signals are successfully routed > > > in under 40 minutes). Does the problem remain in SP6, > > > or is this a specific issue related to the use of the > > > Unix version ? > > > > > > Richard. > > > http://www.rtrussell.co.uk/ > > -- > -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 or http://www.fpga-guru.comArticle: 25287
Hi Danijel, I have not used the tool you mention. But if you want something that is "state of the art" for student prices I would like to recommend you to visit www.xilinx.com where you can get Modelsim - for free. In my opinion, Modelsim is the best simulator around these days. You'll also get lots of backend things for CPLD's and Xilinx own synthesis tool from xilinx.com. I haven't tested their synthesis tool myself, but from what I have heared it's GOOD except for that it doesn't understand all of the synthesizable subset of VHLD. I don't think that it understands RECORDs for example. If you want a true state of the art synth. tool for FPGAs for free, I would recommend you to go to www.exemplar.com and get the evaluation copy (1 month) of Exemplar Logics Leonardo Spectrum. Good luck with your project, /Johan, Engineering Manager WDI ltd, sweden email: vhdl_ninja@yahoo.com Danijel Sebalj wrote: > > Hello, > > does somebody have experience about using the tool Statecad from VSS ? > Is ist suitable for more complex design and why there is no affordable > version for students?? > > Thanx for more > > Danijel Sebalj, HamburgArticle: 25288
Not that I'm going to buy any, but you missed a very important part of the part number...the speed grade. That is a single digit stamped on the device in a different ink than the base part number. So what is a very low price? For a reference point, these are equivalent, but possibly slower speed, to a Spartan XCS30. kolja@prowokulta.org wrote: > > This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a > very low price froma customs auction. > They are new but come without any waranty. > > I will buy 50 or so for myself, but I will happily take your orders and > buy more for $5 a piece plus international shipping (and customs to some > countries) > 10 Pieces minimum. > > Please send me your orders via email with your full email and > postal address. > > CU, > Kolja Sulimma > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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 or http://www.fpga-guru.comArticle: 25289
Hi Hannah, There is a USELOWSKEWLINES command that you put in the .ucf . There is also some way (i don't remember what it is called) to constrain the skew on a wire - it might be set maxskew = xxx :) I have used that stuff with Leonardo Spectrum without problem. The thing is that the par router will take MUCH longer time to complete if you use the set maxskew constraint, but maybe you can live with that. What I would do myself is to put 'par ... -i 200 ..." as a background job with those constraints and see how far you can get with your favourite placement :) Good luck, Johan P, WDI ltd Sweden email vhdl_ninja@yahoo.com Hanna Bruno wrote: > > The problem faced here, was that the non global clock net was being split into 4 > groups. The synthesis tool must have done this and the resulting routing seemed > to have skew between the 4 clock groups. The FAE said that there is a constraint > that can be added in 3.1i to use low skewlines, I have to try that yet and > prevent the synthesis tool from splitting the net. > > Thank you for your comments Jamie. > > HannahArticle: 25290
It's not so much the "bad" placement that gets me, most of my stuff is floorplanned to try to get the most speed and density practical. In my cases it is a deliberate overconstraining to keep the router from doing dumb things when I am trying to evaluate what a particular structure is capable of. A good example is in the layout an evaluation of the 16 point FFT core I plan to offer this fall. Without constraints, the router does a fairly poor job, turning in max frequencies around 85 MHz in a -4 part, but with an aggressive constraint it does much better, better than 133 MHz. This is a 100% floorplanned design. Once I know what the design will do when the router takes a long time, backing off on the constraint to soething that is really close but not exceeding that number router takes only a minute or two instead of the better part of an hour. Johan Petersson wrote: > > Hi Ray, > > I agree 100% about the long routing times when you have a "bad" > placement. > A good idea to avoid that situation is to run the par with the -n 0 flag > which > tells it to perform loads and loads of place'n'route runs with different > -t values. > > There is also a flag that disables the router so that you can let the > placer > run with different "cost table entries" as a background job - when the > check sum > is low enough you kill the bastard and run with -t x, no -n and WITH the > router > enabled....... I don't remember the name for the "disable router" flag > :) > > Finally you can tell the router explicitly how many iterations to run. > If you > constrain it with for example -i 1, it will only run one iteration > regardless > of how ugly the placement might be! > > There is always much to discuss about FPGA's, isn't it!!?? > > Regards, > Johan Petersson, > Engineering Manager, > Wireless Digital Intelligence ltd, Sweden > > email (private) vhdl_ninja@yahoo.com :) > > Ray Andraka wrote: > > > > 3.1 does seem to fix that problem. One bugger with 3.1 is if the placement > > isn't going to meet timing, it spends an awful long time trying a little harder > > before it gives up. That's a bit of a bugger if you are trying to push > > something to see how fast it'll go as opposed to meet timing for a particular > > target. If your placement makes meeting timing relatively easy, the tool runs > > very quickly...I've got a very full 97%)XCV400 that's placing and routing in > > under 5 minutes, with all the datapahth stuff but not control logic > > floorplanned. > > > > Johan Petersson wrote: > > > > > > Hi Richard, > > > > > > All I can say is that the problem does not remain in > > > 3.1i, which improves par times enormously! > > > > > > Johan, > > > email vhdl_ninja@yahoo.com > > > > > > news@rtrussell.co.uk wrote: > > > > > > > > The problem of very slow routing of PWR/GND nets is > > > > supposed to be fixed in 2.1i Service Pack 6, but I > > > > am still suffering from it (running the Unix tools > > > > on a Sun Ultra 10 workstation). An XCV600 is taking > > > > about 8 hours to build, of which over 7 hours is the > > > > PWR/GND routing (all signals are successfully routed > > > > in under 40 minutes). Does the problem remain in SP6, > > > > or is this a specific issue related to the use of the > > > > Unix version ? > > > > > > > > Richard. > > > > http://www.rtrussell.co.uk/ > > > > -- > > -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 or http://www.fpga-guru.com -- -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 or http://www.fpga-guru.comArticle: 25291
I've ran into this one first in v3.1. You can get around it by explicitly defining logic_1 and logic_0 signals. for smaller groups of SRL16's. You may need to put the appropriate attributes on the instances to keep them from beig eaten in synthesis. news@rtrussell.co.uk wrote: > > Johan Petersson <Johan.Petersson@uab.ericsson.se> wrote: > > : All I can say is that the problem does not remain in > : 3.1i, which improves par times enormously! > > Actually it turns out that the problem I am having is > related to the use of very large numbers of SRL16 shift- > registers, which is resulting in over 25000 VCC routes! > I have confirmed that the problem is just the same in > 3.1i; it is described at support.xilinx.com thus: > > "Currently map generates a GLOBAL_LOGIC1 and GLOBAL_LOGIC0 > signal to drive constants onto the F & G inputs of LUT RAM > used in the SRL library element. The extreme number of VCC > loads that can occur in such designs will often lead to > excessive router run time as well as poor circuit performance > due to route congestion." > > The solution recommended is to add the environment variable > XIL_MAP_NOSHIFTONES, but when I do this 'bitgen' aborts with > over 25000 errors telling me that the F and G inputs are not > connected! If I ignore these errors (bitgen -d) the device > doesn't work, exhibiting all the symptoms of the shift- > registers not operating correctly. > > Richard. > http://www.rtrussell.co.uk/ -- -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 or http://www.fpga-guru.comArticle: 25292
Tomasz Brychcy wrote:
Hi,
do you really have to use Write2CWR as an asynchronous reset??
If you can live with having the Write2CWS acting on the negedge CLK,
it will be very easy I believe:
always @(negedge CLK or posedge YourGlobalReset) begin
if(YourGlobalReset)
YourGlobalReset_Action :)
else if (Write2CWR)
OUT=OUT_mode_after_CWR;
else
OUT=OUT_mode;
end
This code should hopefully synthesize to what you intended only that
changes in Write2CWR will affect your design on the good old clock edge.
If you HAVE to use exactly what your code does timingwize you could use
a
gated clock of course - but you should generally be rather careful with
gated
clocks and keep an eye on how your tool implements them. Advice is to
constraint
them carefully in the x.ucf (if you are using Xilinx that is :) )
Good luck,
Johan P,
WDI ltd Sweden
mailto: vhdl_ninja@yahoo.com
>
> Hello,
>
> Why the code below is incorrect to synthesis for FPGA Express:
>
> always @(negedge CLK or posedge Write2CWR)
>
> if (Write2CWR)
> OUT=OUT_mode_after_CWR;
> else
> OUT=OUT_mode;
>
> Error during synthesis is:
>
> Sequential mapping has detected that the cell '/ver1-optimized/OUT_reg' uses
> both the asynchronous 'set' and 'clear' pins.
>
> What should I correct in this code?
>
> With regards
>
> Tomek
>
> T.Brychcy@ime.pz.zgora.pl
--
APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS
Article: 25293Hello, I use PADs software (PowerPCB) to design my PCBs (PADS logic for schematic entry) for Xilinx designs. It takes a lot of time to create PCB decals and gate decals. I have several to swap. I am looking for the gate and PCB decal for a XCV150-nFG456t ( where n is any speed grade, t is any temp grade) I have the following available for swap: XC3195-nPG233t XC30(30|40)([A])-nPC84t XCS(20|30|40)-nPQ208t XCV(50| upto 300)-nPQ240t XC5210-nHQ304t XC5204-nTQ144t Sincerely Daniel DeConinckArticle: 25294
Right, As Ray points out, your big-big gate array will be very cheep when you have finished prototyping unless you are about to release your product very soon. Virtex2 is coming in newer process from UMC - I don't think the 0.18/0.22 will be expencive in a couple of months. Try to speek to your favourite Xilinx person about their plans! By the way, have you concidered to put the "slow" things (microprocessor) inside the FPGA as well? Xilinx have an agreement with IBM - which will lead to PowerPC cores for Virtex2 if I remember the press release correctly. Also the Virtex2 devices are rumored to have a much more aggressive memory to gate ratio - so maybe some of your memory could fit into the gate array as well! Good luck with the thing your designing! Regards, Johan, mailto: vhdl_ninja@yahoo.com Ray Andraka wrote: > > From the apps I've dealt with, by the time you finish playing with the > prototype, the part prices are a fraction of what you paid for them, and the > extra debug time due to one faulty socket more than pays for that part. > Besides, with SRAM based devices, you can often reuse a prototype on the next > project at least for early development. > > Elftmann wrote: > > > > Ray, > > > > With the cost of the larger SRAM devices (XCV1000 and up) I have seen > > several customers recently who have chosen to socket the SRAM BGA devices > > (Xilinx/Altera) to allow the devices to be reused. IMHO this makes sense > > in a prototype environment. If a proto board has to be scrapped or has > > out-lived it's usefullness, at least the cost of the parts can be recovered. > > It's a trade-off between the removal and re-balling of the device versus a > > socket. If a high quality socket is used this is a reasonable trade-off. > > The BGA sockets I've seen are better than the QFP sockets and tend to induce > > very few problems when properly used. > > > > I believe if you look back into this thread, this reasoning is consistent > > with the original posters thinking. > > > > Daniel Elftmann > > Actel Area Technical Manager (ATM that does not dispense cash, except to my > > wife) > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:39B2D090.455347C7@andraka.com... > > > Why would you do this on an SRAM based FPGA? The socket just adds one > > more > > > thing that can go wrong, and nothing sucks quite as much as socket induced > > > problems. With the SRAM based parts, just make sure you leave a way to > > laod a > > > program in directly instead of in a PROM or buried in the processor ROM > > build. > > > > > > "Nicholas C. Weaver" wrote: > > > > > > > > In article <QpOyOTTKnsWfbM=MacxXqtYEDVgb@4ax.com>, > > > > John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: > > > > >Ben, > > > > > > > > > >thanks, but I have a situation where all the data must be available to > > > > >the core algorithm at once, and, besides, I'd lose pins faster than > > > > >I'd gain them if I were to partition things into multiple chips. > > > > > > > > > >This chip has to be connected to nine 12-bit flash ADCs, two big banks > > > > >of SRAM, a 68332 uP (to do the slow stuff!) and the PCI bus. The core > > > > >algorithm must do massively nasty pipelined parallel stuff on the ADC > > > > >data streams at 60 MHz or so. > > > > > > > > One suggestion: BGA sockets. Several manufacturers make BGA > > > > sockets, semi-custom jobs, around $50 each (minimum quantity 5) which > > > > will fit various FPGAs. They have the nice property of they also BGA > > > > mount, with an identical profile, so you can use a socket during > > > > development and then solder down the parts when the board goes into a > > > > higher level of production. > > > > -- > > > > Nicholas C. Weaver > > nweaver@cs.berkeley.edu > > > > > > -- > > > -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 or http://www.fpga-guru.com > > -- > -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 or http://www.fpga-guru.com -- APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTSArticle: 25295
Hi, My advice would be to try Leonardo Spectrum and Synplify. I have not used Synplify, but I have very good experience from using Exemplar Logic Leonardo with Xilinx FPGAs (mainly virtex things) There is an evaluation copy available for 1 month usage if you visit www.exemplar.com good luck, Johan P, mailto:vhdl_ninja@yahoo.com Christian Mautner wrote: > > On Tue, 29 Aug 2000 18:09:48 -0700, Andy Peters <@> wrote: > > > >Check in the FPGA Express constraints GUI, and make sure you didn't set > >that attribute to FALSE there. Also, *never* forward-annotate timing > >constraints from FPGA Express (that is, one of the FPGA Express options > >is "Export Timing Constraints"). That puts lots of constraints into > >your EDIF that don't need to be there, especially when most of your > >constraints will be covered by a simple PERIOD attached to the clock. > > > > You should try FPGA Express 3.4. Much improvement there, they create now a > *.ncf file, and don't put the timing constraints in the edif file anymore. > And, they use simple PERIOD statements in the ncf file. I define (most) timing > constraints in fexp (in tcl, not in the GUI, of course), and I am quite > satisfied. > > chm. > > -- > cmautner@ - Christian Mautner > mail.com - Vienna/Austria/EuropeArticle: 25296
In article <Ef+nOWncm0n9eQJ6FlkHRIdiJ15y@4ax.com>, John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote: > Well, I want to do a really cool image-processing gadget, and I'll > need an FPGA with 300 I/O pins or so. Peter Alfke was kind enough to > send me a couple of sample Xilinx BGA parts. I showed them to my > manufacturing people and actually escaped with my life. > > So, if any of you have experience with BGAs, I'd appreciate some help: > > 1. Is it necessary to go with gold-plated (or maybe bare copper) pads > to ensure planarity? Anybody having success with regular FR-4, > solder-coated SMOBC stuff? > > 2. Assuming I send the boards out for assembly, I'd still like to > verify that all the BGA soldering is intact. I could code up a special > FPGA design to just configure the chip as a lot of I/O latches, and > then run test patterns (from the uP that configures and supervises the > FPGA). Clearly, I can detect shorts between pins this way. Any ideas > on how to detect open ball-to-PCB solder joints? > > 3. What sorts of PCB line/spacings are needed for something like a > 460-ish pin 1.27 mm BGA? > > 4. Any other advice or cautions? > > Thanks, > > John > > John, I have been working with 356 pin PBGAs for the past 4 years, and what a relief it has been. You should be able to non solder mask defined pads in most cases without any difficulty on standard FR4 copper type boards. I have never worked with thinner than 1/2 oz. copper, but I know of folks that have. The coplanarity issue is likely only to be an issue with extreme board flex (i.e.: imbalance in the internal copper layers of the board). I have never seen a board yet that had such coplanarity problems. By the way coplanarity is just as big an issue if not bigger with QFP style parts since the points of contact are actually spread further from the device centroid. BGAs are to some degree self centering after placement during reflow. One must use a convection type reflow as the contacts are hidden. The biggest thing that MUST happen to ensure your success, is to get a BGA competent contract manufacturer to not only place the BGA resonably accurately, but also to inspect the solder balls prior to placement. I have seen a few cases where solder ball deformation has caused a short under the part to an adjacent solder ball. The other thing they must check for is missing or insuficient solder balls, which will lead to open circuits. XRAY inspection will allow the CM to check for proper ball colapse and to check for adjacent ball shorting. If they have the capability to perform other angles, additional solder joint information can be gleaned, such as cold solder, bubbles, etc.. I would not let any of this scare you, I have seen more problems with QFP style packages, than with BGAs. As for the joint testing, JTAG is a great help if your particular part has it, if not, one can often emulate it in different ways with minimal effort. I have used JTAG whenever, and wherever possible, and it has been a BIG benefit. Your CM may even have an ICT that is JTAG compliant and can do this testing for you. I appologize for the overly verbose and poorly spelled response. Ben Stelle Design Engineer Trilithic, Inc. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25297
Besides the speed grade that RA pointed out, you also forgot to tell everyone what country you are in. In other words, what is considered international shipping? -Simon Ramirez, Consultant Synchronous Design, Inc. <kolja@prowokulta.org> wrote in message news:8p2f92$347$1@nnrp1.deja.com... > This Saturday I can get up to 720 Pieces XC4013XL-PQ208CFN9925 for a > very low price froma customs auction. > They are new but come without any waranty. > > I will buy 50 or so for myself, but I will happily take your orders and > buy more for $5 a piece plus international shipping (and customs to some > countries) > 10 Pieces minimum. > > Please send me your orders via email with your full email and > postal address. > > CU, > Kolja Sulimma > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. >Article: 25298
Hi, I'm interested by pictures compressions, if someone know how to do a DCT into an FPGA i take all what you have !! ThxArticle: 25299
Hi, I'm interested by pictures compressions, especially DCT, and if someone know how to do a DCT into an FPGA, i take all what you have !! Thx SEB
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