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 1 Feb 2006 13:27:32 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >> 3) It's a more useful metric than 'gate count' when comparing to ASICs >> and other FPGA vendors. >I violently disagree! Steady on! >FPGA chip size is inevitably larger than an ASIC of comparable >functionality, but the FPGA offers so many advantages that often >compensate for its larger size. >And FPGAs are made in large volume, and are reconfigurable, ASICs are >much smaller volume per design. etc Well-known arguments... I'm not complaining about FPGAs; horses for courses. My point is that I know, to a fairly high degree of precision, what I can fit on a square mm of process X. However, I have very little, if any, idea of what I can fit on a square mm of an FPGA. All I have are your marketing gate counts, and I can't turn those into areas anyway. Your gate counts aren't the same as any other vendor's gate counts, and your gate counts will change between devices and generations anyway. The only hard metric is die size. If I know that I can implement something on a 50 mm2 ASIC, but that would take a 250 mm2 FPGA from one vendor, and a 400 mm2 FPGA from another vendor, then that would be interesting, and maybe even useful.Article: 96301
John, The per ball current limit is more than 250 mA. There are thousands of bumps per die to the package, so no problem there. The package power and ground planes are solid copper sheets. If you have ~160 Vccint pins (for a ff1760 package). That is > 40 amperes. At 1.2 volts, ~ 50 watts. I just don't think the package, resistance, bumps, balls, silicon, is going to be the weak link. The weak link here is the design engineer. Did they provide a good enough power distribution system? Did they engineer enough cooling? Our FPGAs will do a lot: you need to know how best to use them if you want to squeeze this kind of power out of them. I think it would require a liquid cooling solution. AustinArticle: 96302
Hello, Sometime back there was a question on the comp.arch.fpga about interfacing a PLB master pcore with the PLB DDR controller (see below for thread or check this out: http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/72bc1bce10a2a4ac/adc03dda153a66c8?lnk=st&q=Sl_rearbitrate&rnum=1&hl=en#adc03dda153a66c8). Recently, I have set-up a simulation environment in which my master pcore talks a PLB DDR controller (instead of a PLB BRAM). My master pcore issues 384 writes to the PLB DDR controller, then it reads from the locations it wrote. My master pcore successfully completes all 384 writes, then it starts the reads. On the 109th read, it encounters the exact same problem as described in the posting. Anyone encountered this issue and fixed it? I have been avoiding using PLB_DDR in simulation, but I have some apps that use too much memory and cannot fit in the conventional PLB BRAMs. Thanks, NNArticle: 96303
On 1 Feb 2006 14:32:24 -0800, "sandi" <sandipon.basu@gmail.com> wrote: >Hi, >Please let me know - what is the advantage of fully specifying don't >care conditions? >-Sandi I can only immediately think of one advantage, which is that a formal equivalence tool will then be able (or better able, anyway) to compare two netlists from different synthesisers. There are disadvantages, of course, which will normally outweigh this.Article: 96304
Jim Granville wrote: > But you would not use 6 mil, 1.2 oz traces, in something you KNEW was > going to the corners, would you ? > Via escapes can be much wider than that, and you can always add multiple > thermal vias, to your PCB... My PCB's yes ... the question is just what is the construction and limits of Xilinx's package pcb that acts as the carrier for the die. > OK - So we accept that the extreme case ceiling is going to be 'C > detemined ( rather than simple Max_MHz ). > That means you design the system with the most aggressive thermal, and > current policies you can afford. Do we? There have been some pretty strong statements here it's only a thermal limit. > Then, you test it - and have sensors that mean you can run to the > envelope edges ? So you test it with 10 lots of chips that all happen to have process variences to support a higher current profile. Then start building with a lot of chips that are at the other extreme ... say etching took the traces 20% under at spots due to photomasking failures ... but well inside the PCB mfg's stated tollerances for the build quote. I've always been uncomfortable with doing designs that way. Trail and error is not s substitute for engineering. > If you can then prove that the 'C is leaving a lot of MHz behind, in > working, real case, designs - then Xilinx will probably be > quite interested in finding better thermal package solutions. > > Intel spends a LOT of money on thermal and current aspects. I'm not sure that's the case, but there are nagging questions pointing that way with some experience, the current lack of hard data and trying to make conservative design assessments. It may simply come down to their using the old rules of thumb that only 15-25% of the design will be active, and scaling needed resources to that number. When I was doing the XC4VLX200 design last year the local FAE was dead sure that I only needed to use power estimator numbers in that range. A number of demonstration programs hit older XCV2000e's and XC2V6000's a lot harder ... like packing them with RC5 cracking engines, or distributed arithmetic engines. I was off by a factor or 3-5 on power estimates. RC may tend to push the active design portion of the chip to numbers near 100%, and with it much higher toggle rates than a typical hardware controller design.Article: 96305
Dear comp.arch.fpga'rs, Lattice Semiconductor went live with the company's first moderated support forum this week. We seeded the threads with our most popular FAQs and will continue to add to it over the new few weeks. I think you'll find some good content there already - so it's worth a look. Like other company sponsored forums registration is required to post and it will be moderated for quality and manners. So while you won't be able to flame us or anyone else at will there's still a good chance your questions, suggestions, concerns are going to get some attention from the factory. We hope it will complement comp.arch.fpga and provide richer content for designers using Lattice digital, mixed-signal, software, and IP products. http://www.latticesemi.com/support/forums.cfm Thanks in advance for visiting, Troy Scott Lattice SemiconductorArticle: 96306
Austin Lesea wrote: > Our FPGAs will do a lot: you need to know how best to use them if you > want to squeeze this kind of power out of them. I think it would > require a liquid cooling solution. My cooling solution has been water or phase change on high density designs for a couple years, with heat exchangers directly attached/integral to 1/4" or 3/8" milled copper plate heat sinks spaning 16 to 64 parts per board. Air just can not carry enough heat away in dense designs. Thanks for the specific data on the per pad currents. Did I misscount the VccInt pads? I only get 140 on the 1513 package listed as the only option for the LX200. That would lower the dynamic power limit from 50W to about 44W by your numbers.Article: 96307
actually a bit lower than 44W if the worst case design current is fixed at 250ma/pad during clock current peaks, and the average current is lower.Article: 96308
Peaks are ~ 10X average, with no issue in current handling. With that much stuff switching, I doubt seriously you would see any real narrow peaks. The clock is spread out over 2 ns of distance/speed of light on chip, and the switching is as well. You can not get the whole core to "switch at once." It just is not physically possible. Now, since you have just learned (from Xilinx) how we do all the deep sub micron engineering so you do not have to, I will submit my bill and we can move on to more interesting topics? AustinArticle: 96309
Typically FPGA BGAs have a central square of balls which are all connected to ground. What is the current wisdom on how to hookup the PCB tracking for the central ground matrix. The simplest, and lowest inductance, seems to be to put down a solid square of copper covering the central ground ball pads, and pepper the square with ground vias. But that looks like the dreaded 'Solder Mask Defined' pads. Is it better to go with individual NSMD pads, tracking, and vias? Thanks.Article: 96310
fpga_toys@yahoo.com wrote: > Jim Granville wrote: > >>But you would not use 6 mil, 1.2 oz traces, in something you KNEW was >>going to the corners, would you ? >>Via escapes can be much wider than that, and you can always add multiple >>thermal vias, to your PCB... > > > My PCB's yes ... the question is just what is the construction and > limits of Xilinx's package pcb that acts as the carrier for the die. I thought these top end FPGA's, were flip-chip, no bondwires stuff ? -jgArticle: 96311
MikeJ wrote: > Ray, one thought - > I recently had to modify my romgen program (www.fpgaarcade.com) which > produces init strings and generics with a conversion function much as you > suggest. > However the Synplicity tool uses a different attribute style to Mentor's > Precision. I discovered that Synplicity at least will produce the correct > block ram init strings with only the generic set - no synthesis attributes > required. > > About time too .... > /Mike > Mike, Yes, it is true if you use the synplify and mentor attributes. Instead, you can set them up as user attributes using the Xilinx attribute name (INIT_XX=) so that it is tool agnostic. That indifference to which tool it is used on is also why I haven't been taking advantage of Synplicity's (pretty much still unique) ability to infer the attributes from the generics.Article: 96312
fpga_toys@yahoo.com wrote: > Jim Granville wrote: > >> I'd also route an IO pin, to the 'Smart PSU', that outputs a divided >>ring oscillator, so you can also track an actual freq-capable point. >>[ you _will_ want to overclock this, sometimes :) ] > > > I've been a little gun shy of leaving several fast ring oscillators > running on Virtex parts since taking out two consecutive XCV800's that > way a couple years ago, my lab desktop board after a client returned a > dead board having done the same. It wasn't even that warm at the heat > sink. I've never been sure if that was just a freak, or something to > worry about. > > I asked the local FAE about it last year when doing the first XC4VLX200 > design and kinda got a shrug and strange look of disbelief. After that > I've been more careful to keep toggle rates closer to the chip's stated > max clock rate. Interesting - plausible, if they were 'several'. The type of ring Osc I expected was not "many of the fastest", but one, designed to be longer and slower - you are trying to get a physical verify of the silicon/process/temp/vcc ability, and you want to avoid local heating. -jgArticle: 96313
Austin Lesea wrote: > With that much stuff switching, I doubt seriously you would see any real > narrow peaks. > > The clock is spread out over 2 ns of distance/speed of light on chip, > and the switching is as well. Yeah ... for LX200's certainly true. With just the Tckskew for the LX200 being 1.2ns, 500Mhz/2ns would yield a fairly smooth distribution. Small parts don't have that problem, and would tend to cluster around clocks more, as the skew is about the same as a LUT delay. But likewise, because of the skew, a large RC design with a single clock would be forced down below 200Mhz on an LX200, and the clustering is likely to reappear in the first 1.5ns of the clock period. > Now, since you have just learned (from Xilinx) how we do all the deep > sub micron engineering so you do not have to, I will submit my bill and > we can move on to more interesting topics? Hmm ... I missed that full lesson ... shucks :( Anyway yes ... you have been far more helpful than others I've asked. And while it's not at the detail I would like, I can live with the general validations for today.Article: 96314
Jim Granville wrote: > I thought these top end FPGA's, were flip-chip, no bondwires stuff ? They are. but instead of mounting the chip on the pad side of the pcb carrier, they are solder bump (AKA very small balls) mounted to the other side of the pcb carrier and use vias to get to the BGA pads on the other side. The bump pitch is much tighter than the BGA pitch, and it allows them to have more pwr/gnd bumps/pads than are on the other side for the pcb BGA. And as Austin pointed out, it allows them to use a multilayer pcb carrier to have pwr/ground planes in the carrier pcb to spread out the current more evenly, and probably act better as a bonding side heat sink. This also means that the "trick" of issolating a VccInt and Ground pair doesn't actually measure the die voltage, but the pwr/gnd plane of the carrier, and there will still be a voltage drop from the via, traces and pads to the bumps.Article: 96315
Tim,, That is so last year. Howard Johnson showed that the loops need to be made small. As it turns out all ranks of connections inside the square carry no current at all. Solve Maxwell's equations, and surprise! So, alternative power and ground is the best. That is what our SparseChevron(tm) is all about. Austin Tim wrote: > Typically FPGA BGAs have a central square of balls which are all connected > to ground. What is the current wisdom on how to hookup the PCB tracking for > the central ground matrix. > > The simplest, and lowest inductance, seems to be to put down a solid square > of copper covering the central ground ball pads, and pepper the square with > ground vias. But that looks like the dreaded 'Solder Mask Defined' pads. Is > it better to go with individual NSMD pads, tracking, and vias? > > Thanks. > >Article: 96316
Ben,
I used a DDS LogiCORE to generate the sine (and cosine) and then a pair
of two-complementor LogiCORE to handle the BPSK; you wire the data value to
the BYPASS pin. Works like a champ.
Marty
martin dot ryba (at) verizon dot net
"Ben Marpe" <Ben.Marpe@gmx.de> wrote in message
news:1138801274.996807.307800@g49g2000cwa.googlegroups.com...
Hi everybody,
I'm trying to implement a BPSK modulation.
A sin waveform has to be generated at a given frequency (1MHz) with
phase offset (binary PSK i.e. 180°) when transition occures on a data
wire.
Is there any "simple" LogiCORE with BPSK functionality available for my
Xilinx Spartan-3 - Board ?
My attempt would be a LUT in BRAM - but do I have to fill its content
manualy ? The LUT content (e.g. 16bit) could drive a DAC.
On the other hand, If I'm forced to use a external DAC, I might use a
DDS (e.g. AD9834) with all BPSK functionality on chip... ?!?
I'm interested in your ideas and suggestions !
Bye, BEN
Article: 96317Possibly both missing the point. Usually the central ground matrix is for thermal conduction to the ground plane. Check with your assembly service, but usually placing a solid plane under the BGA with solder mask defined openings will adversely affect soldering. We usually use etch at about the pad size going diagonally to one via per pad. No thermal relief where the via attaches to the ground plane(s). Central ground balls in these packages do carry DC current, but were placed where they are for better thermal conduction to a central die. Generally many more signal return grounds appear in the outer sections of the same BGA's. Also check with the chip manufacturer for possible application information. I've also seen BGA packages with a single heat slug on the bottom requiring a special pad and solder paste pattern (Broadcom Gig ethernet PHY). A BGA that has sufficient thermal conductivity to the top surface usually works best with a heatsink rather than using the circuit board for heat spreading (Xilinx flip-chip metal top packs). Regards, Gabor austin wrote: > Tim,, > > That is so last year. > > Howard Johnson showed that the loops need to be made small. > > As it turns out all ranks of connections inside the square carry no > current at all. Solve Maxwell's equations, and surprise! > > So, alternative power and ground is the best. > > That is what our SparseChevron(tm) is all about. > > Austin > > Tim wrote: > > Typically FPGA BGAs have a central square of balls which are all connected > > to ground. What is the current wisdom on how to hookup the PCB tracking for > > the central ground matrix. > > > > The simplest, and lowest inductance, seems to be to put down a solid square > > of copper covering the central ground ball pads, and pepper the square with > > ground vias. But that looks like the dreaded 'Solder Mask Defined' pads. Is > > it better to go with individual NSMD pads, tracking, and vias? > > > > Thanks. > > > >Article: 96318
I put these conditions in different always and if-else-if statements, will
design compiler & ISE be smart enough to recognise them and reduce
hardware cost accordingly?
I had a tendency to write the conditions with a wire & assign statement
e.g.:
wire cond1; assign cond1 = pop && (process == 8'h25) || kick;
but if synthesizers handles these, then it will save me some thinking.
always @ (posedge clk)
begin
if (pop && (process == 8'h25) || kick)
whatever <= asdf;
else if (pop1 && (process == 8'h25) || kick1)
whatever <= asdf1;
else if (pop2 && (process == 8'h25) || kick2)
whatever <= asdf2;
end
always @ (posedge clk)
begin
if (pop && (process == 8'h25) || kick)
whatever1 <= asdf3;
else if (pop1 && (process == 8'h25) || kick1)
whatever1 <= asdf4;
else if (pop3 && (process == 8'h25) || kick3)
whatever1 <= asdf5;
end
Article: 96319Paul, I hear you, and I have no reason to sound defensive. But your idea just does not work. And will never work. Some areas of an FPGA chip are every bit as efficient as an ASIC, sometimes even more so. Using a better and newer technology (90 nm), certain sections in FPGAs are more compact than ASICs using their 130 or 150 nm technology, because ASICs usually cannot afford state-of-the-art technology. Our BlockRAMs are efficient building blocks, so are the PowerPCs, and the multipliers, and the clock managers, and the input SERDES, and some other dedicated circuits. But then you have the configurtion storage and the generous interconnect structure that ASICs either avoid or can do more frugally. There is no factor that you can use.There is no 1:1 or even 1:n. And there never will be. Your complaint about gate counts is widely shared, but if you just treat it as number, you can very well compare FPGAs against each other, even between manufacturers. The error will mainly be due to variing percentage usage of the efficient block I mentioned above. You will never be able to say that x square mm of Xilinx, or y square mm of Altera equals z square mm of a certain gate array. So why go to the frustrating exercise? You have to dig far deeper to do an evaluation. And to top it of: the FPGA vs Gate Array choice is mainly not based on area, but rather on total cost. We will never run out of silicon, but the ASIC fan may run out of money... Peter Alfke, from home.Article: 96320
Hi. Quick question for you all.
I have a 20MHz FPGA clock and I have some very low frequency periodic
actions to take care of so I want to generate an approximate 10Hz clock
to give to the modules that need it so they don't need their own big
wide counters.
module slowclk(input clk, output slowclk);
reg [19:0] cnt = 29'h0;
assign slowclk = cnt[19];
always @(posedge clk)
cnt <= cnt + 20'h1;
endmodule
If I have a module that uses both the full speed and the slow speed
clocks, can I use the clk and slowclk together without problems? Let
me give you an example:
... in the mixed clock module:
always @(posegde slowclk)
x <= expression
always @(posedge clk)
if (x)
do_something;
else
do_something_else
I believe that as the clocks are in-phase there's no problem. Just
wanted to check with the experts.
The target is a Spartan3 FPGA and ISE7.1i reports:
WARNING:Route - CLK Net:slowclk_blk/cnt<19>
may have excessive skew because 1 NON-CLK pins
failed to route using a CLK template.
**************************
Generating Clock Report
**************************
+---------------------+--------------+------+------+------------+-------------+
| Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max
Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| CLK_i_BUFGP | BUFGMUX7| No | 366 | 0.191 |
0.792 |
+---------------------+--------------+------+------+------------+-------------+
| slowclk_blk/cnt<19> | BUFGMUX3| No | 24 | 0.181 |
0.786 |
+---------------------+--------------+------+------+------------+-------------+
... which looks good to me.
Advice welcome.
Thanks.
Paul.
Article: 96321On 1 Feb 2006 11:01:23 -0800, fpga_toys@yahoo.com wrote: > >Allan Herriman wrote: >> Is it difficult to measure typical values of the voltage drop on >> actual hardware though? Just set some outputs to be CMOS highs and >> lows and measure their voltage at some convenient spot on the board. > >Measuring VccInt from an I/O pad? ... some trick? No, but you can measure the GND voltage on the die that way. That's half the answer you want. Allan.Article: 96322
On 1 Feb 2006 14:30:14 -0800, cs_posting@hotmail.com wrote: >Ray Andraka wrote: > >> Alternatively, you could generate ascii binary in your external >> application and past that into an array of bit_vectors directly. > >This is where I like verilog's include directive... no pasting >required. ... until you need two instances of the same module with different INIT values. You can't (for example) have a parameter select different INIT values. `include happens at compile time. Deferring this until elaboration time would be much more useful (for some applications). YMMV. Regards, AllanArticle: 96323
On Wed, 01 Feb 2006 11:27:40 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >Hi, > >We have several products that use S3's, with a number of fpga pins >connected to dipswitches. The dips switch to ground, and we program >the fpga's to provide internal resistive pullups. > >Some small part of the time, at random, one (typically) pin will fail >to pull up, and we have to replace the fpga to fix it. > >Anybody else observe this? I don't have the datasheet in front of me, but I believe that Xilinx do not guarantee a minimum pullup current, merely that the pin will be pulled up if it has no external load. You have an external load. They used to guarantee a minimum of 25uA (for 3.3 or 5V parts?), but presumably they droppped this specification because of designers forgetting about leakage currents on their boards (or more likely, leakage currents into tri-state outputs on other chips). In your case, the failure is likely to be because of leakage currents on your board (due to insufficient cleaning) or perhaps capacitvely coupled crosstalk (if the problem is transient in nature). Moral: read and understand the datasheet, and use pullup resistors where they are needed. Regards, AllanArticle: 96324
Allan Herriman wrote: > > ... until you need two instances of the same module with different > INIT values. You can't (for example) have a parameter select > different INIT values. > > `include happens at compile time. Deferring this until elaboration > time would be much more useful (for some applications). > YMMV. > > Regards, > Allan That's an advantage of VHDL. I regularly put the parameters into a generic as an integer array so that I can have multiple instances of the same component with different init data. Doing that in verilog requires a pre-processor to parse out those and rewrite it into inline instances with different names. Kind of awkward if you ask me. If you don't want to paste, you can always write your other application so that it writes out a complete file containing a VHDL package that has the constants declared in it. Then you just need to include that package in a library statement at the top of your VHDL code. This is handy if you have something that is going to get updated often enough that pasting in presents too great an opportunity of screwing it up. Also good for throwing code over a wall.
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