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 Monday, April 7, 2014 1:34:07 PM UTC-4, Carl wrote: > What the discussion boils down to is if functional models may behave like > this. If the answer is yes, there should be a general design practice, th= at=20 > should always be used when interfacing to RTL logic or functional models = you=20 > haven't developed yourself. - May they, 'yes' - Should they, 'no' - Design practice to add delays should be applied when using models that ha= ppen to need it. Since most do not, applying it to all models that you hav= en't developed is a waste. > I see from the discussion that the arguments regarding this differs. My= =20 > original post suggested me leaning towards the Xilinx primitive being fla= wed,=20 > and also after having taken in the arguments above, this is still my opin= ion.=20 Submit a bug report. > One effect of the user being required to hold inputs active any longer (s= ay,=20 > adding 'after 1 ns' to any interfacing logic signals) would be a (sometim= es)=20 > significant increase of simulation time.=20 Whether this is true or not depends on how you work around the problem. A = simulator will schedule a signal change to occur at a certain time. Whethe= r that time is on the next simulation delta or 1 ns into the future doesn't= change the fact that a new event will need to be evaluated at *some* time = in the future. Now it could come down to how you implement that delay: 1. x <=3D y after 1 ns; -- Should not produce extra signal activity 2. x <=3D y0; y0 <=3D y after 1 ns; -- Will produce extra signal activity #1 is how you would likely tend to implement the delay if you put it at the= source where I suggested it belongs which has tracability back to specific= ations. #2 is how you would likely tend to implement the delay if you see the sourc= e as being pristine and you just want to add a delay line. > One of the powers of functional simulations are that any changes only hap= pens=20 > on the clock flanks, and changes around the clock flanks being separated = only=20 > by deltas, not by time. (Remember, VHDL signals are expensive in this reg= ard.=20 > Reducing signal changes means everything to efficient simulations.)=20 Not sure what functional simulators you're talking about here. Modelsim ce= rtainly doesn't work this way (i.e. changes only happen on the clock edges)= . Changes on any signal cause events to be scheduled on others. Kevin JenningsArticle: 156451
On 4/7/2014 4:45 AM, HT-Lab wrote: > On 03/04/2014 14:01, Carl wrote: >> Hi, >> >> This question deals both with an actual problem, and with some more >> conceptual thoughts on simulation deltas and how an RTL entity should >> behave with regards to this. >> >> This post regards the case of a simulation with ideal time - that is, >> no delays (in time) modelled, rather trusting only simulation deltas >> for the ordering of events. >> > > You might extract some useful info from this discussion: > > http://verificationguild.com/modules.php?name=Forums&file=viewtopic&t=537 > > Delta delays avoid a lot of simulation nasties like race conditions but > still suffers from some real world implementation issues as you have > discovered. I would not class this as a problem with delta delays. The problem is the design of a module which fails in ordinary usage. I remember learning a long time ago that you *never* run the clock through anything that will delay it more than the data, including delta delays. Obviously the designer of the Xilinx module forgot that rule and added logic to the clock path that needs to be compensated for in the data paths to any sequential elements on that delayed clock. Just as adding delay to a clock in a real world design can cause the design to fail, adding delta delays to a clock in a functional simulation can cause the design to fail in simulation. -- RickArticle: 156452
Hi Chris, Chris Higgs <chiggs.99@gmail.com> wrote: [] > In my own experience, I've found it's far easier to lead by example > than battle the internal corporate structure - I soon got tired of > arguing! Leading by example is certainly far more powerful than arguing, I agree. The problem is that in an environment where your hours are counted for each activity you are carrying on it becomes obvious that I should take all these activities back home and do them on my 'spare' time. The good thing is that I find these activities quite amusing and enjoy a lot in building these kind of environment. > If the company is wedded to out-dated version control software I'll > still use git locally. There are often wrappers[1] that make > interfacing easy. I'll run GitLab to provide myself a nice HTTP > code/diff browser etc. If there's no bug-tracker(!!) I'll use GitLab > issues to track things locally. I'll certainly give a shot to git-svn, as far as code/diff browsing, I'm far too used to emacs and I consider html browsing quite cumbersome (no keyboard bindings! How can you live without key bindings!). We do have bugzilla but people are not using it effectively so there's not really a list of bugs, rather a list of 'actions' which are assigned to a specific person. In this way you have no chance to check what bugs other people have and you cannot even contribute to them (I know it sounds pretty silly!). > If the company has no regression, I'll > run a Jenkins server on my box. If tests aren't scripted, I'll spend > some time writing some Makefiles. If the tests aren't self-checking, > I'll gradually add some pass/fail criteria so the tests become useful. > I'll then start plotting graphs for things like simulation coverage, > FPGA resource utilisation etc. using Jenkins. This is my secret plan indeed, but you need to be careful though, you do not want to step on somebody else's foot! Moreover I'm not specifically asked to do so, therefore I need to sneak these activities in the middle of my 'official' ones. > > Unless you're working in an extremely restrictive environment with no > control over your development box, none of this requires sign-off from > the powers that be. You'll find other developers and then management > are suddenly curious to know how you can spot only a few minutes after > they've checked something in that the resource utilisation for their > block has doubled... or how you can say with such confidence that a > certain feature has never been tested in simulation. Once they see > the nice web interface of Jenkins and the pretty graphs, understand > the ease with which you can see what's happening in the repository, > they'll soon be asking for you to centralise your development set-up > so they can all benefit :) At least I managed to install a vbox on my windoz station and now I'm practically behind my fence ;-) > PS apologies for breaking the cross-post again... curse GG news.individual.net charges you 10$ a year... A reasonable price to get rid of GG!Article: 156453
> > What the discussion boils down to is if functional models may behave li= ke > > this. If the answer is yes, there should be a general design practice, = that=20 > > should always be used when interfacing to RTL logic or functional model= s you=20 > > haven't developed yourself. >=20 > - May they, 'yes' > - Should they, 'no' > - Design practice to add delays should be applied when using models that = happen to need it. Since most do not, applying it to all models that you h= aven't developed is a waste. I intended "should" rather than "may" so I'm with you here. > > One effect of the user being required to hold inputs active any longer = (say,=20 > > adding 'after 1 ns' to any interfacing logic signals) would be a (somet= imes)=20 > > significant increase of simulation time.=20 >=20 > Whether this is true or not depends on how you work around the problem. = A simulator will schedule a signal change to occur at a certain time. Whet= her that time is on the next simulation delta or 1 ns into the future doesn= 't change the fact that a new event will need to be evaluated at *some* tim= e in the future. Now it could come down to how you implement that delay: >=20 > 1. x <=3D y after 1 ns; -- Should not produce extra signal activity > 2. x <=3D y0; y0 <=3D y after 1 ns; -- Will produce extra signal activit= y >=20 > #1 is how you would likely tend to implement the delay if you put it at t= he source where I suggested it belongs which has tracability back to specif= ications. >=20 > #2 is how you would likely tend to implement the delay if you see the sou= rce as being pristine and you just want to add a delay line. >=20 My mental picture was that there is a significant difference of signal chan= ges separated by delta's versus changes separated by time - in terms of sim= ulation performance. However, I was probably wrong here and after having co= nsidered it I no longer see no good reason why there should be such a difff= erence. > > One of the powers of functional simulations are that any changes only h= appens=20 > > on the clock flanks, and changes around the clock flanks being separate= d only=20 > > by deltas, not by time. (Remember, VHDL signals are expensive in this r= egard.=20 > > Reducing signal changes means everything to efficient simulations.)=20 >=20 >=20 > Not sure what functional simulators you're talking about here. Modelsim = certainly doesn't work this way (i.e. changes only happen on the clock edge= s). Changes on any signal cause events to be scheduled on others. Yes of course; I don't mean the _simulator_ has any influence on this. But = the user can, for a simulation run, make sure changes only appear on clock = flanks (within delta's). But this of course depends on the design simulated= and the stimulus.Article: 156454
I got a spreadsheet from Altera that lists the on-chip power supply bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of 501 nF. I was told that these caps are on-chip, not in-package. Is that possible? 501 nF on an FPGA chip? -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 156455
On 04/08/2014 01:25 PM, John Larkin wrote: > > > I got a spreadsheet from Altera that lists the on-chip power supply > bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 > listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of > 501 nF. I was told that these caps are on-chip, not in-package. > > Is that possible? 501 nF on an FPGA chip? > > Maybe attached to the top of the die with micro-C4s. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.netArticle: 156456
In article <esb8k9p3f1v40o1qmisrc8n9qptft26sll@4ax.com>, John Larkin <jlarkin@highlandtechnology.com> writes: >Is that possible? 501 nF on an FPGA chip? If nothing else, I'd be very syspicious of any claims with that level of accuracy. My guess is a typo. How big is the die? How thin would the insulator have to be? -- These are my opinions. I hate spam.Article: 156457
On Tue, 08 Apr 2014 12:43:50 -0500, hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: >In article <esb8k9p3f1v40o1qmisrc8n9qptft26sll@4ax.com>, > John Larkin <jlarkin@highlandtechnology.com> writes: > >>Is that possible? 501 nF on an FPGA chip? > >If nothing else, I'd be very syspicious of any claims with >that level of accuracy. My guess is a typo. > >How big is the die? How thin would the insulator have to be? I did a crude measurement of some of the balls on the FPGA, and estimated capacitances in the 10s of nF. That surprised me. -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 156458
On Tue, 08 Apr 2014 13:39:31 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote: >On 04/08/2014 01:25 PM, John Larkin wrote: >> >> >> I got a spreadsheet from Altera that lists the on-chip power supply >> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >> 501 nF. I was told that these caps are on-chip, not in-package. >> >> Is that possible? 501 nF on an FPGA chip? >> >> > >Maybe attached to the top of the die with micro-C4s. > >Cheers > >Phil Hobbs Yeah, there could be discrete caps under the lid. But 32 of them? It doesn't look like there are caps on/in the BGA carrier, which appears to be a 12-layer PCB. https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/3.jpg https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/6.jpg https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/GX95_caps.pdf Cool, however they do it. Every chip should have internal bypasses. -- John Larkin Highland Technology, Inc jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 156459
On Tue, 08 Apr 2014 12:43:50 -0500, Hal Murray wrote: > In article <esb8k9p3f1v40o1qmisrc8n9qptft26sll@4ax.com>, > John Larkin <jlarkin@highlandtechnology.com> writes: > >>Is that possible? 501 nF on an FPGA chip? > > If nothing else, I'd be very syspicious of any claims with that level of > accuracy. My guess is a typo. > > How big is the die? How thin would the insulator have to be? I vote for a typo. 501 and not 500 or 502? Or 480 or 520? They probably meant 1nF, or perhaps "5 delete" turned into "50" in front of a 1. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 156460
On 04/08/2014 02:16 PM, John Larkin wrote: > On Tue, 08 Apr 2014 13:39:31 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 04/08/2014 01:25 PM, John Larkin wrote: >>> >>> >>> I got a spreadsheet from Altera that lists the on-chip power supply >>> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >>> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >>> 501 nF. I was told that these caps are on-chip, not in-package. >>> >>> Is that possible? 501 nF on an FPGA chip? >>> >>> >> >> Maybe attached to the top of the die with micro-C4s. >> >> Cheers >> >> Phil Hobbs > > Yeah, there could be discrete caps under the lid. But 32 of them? Well, that would give you the least inductance, for sure. > > It doesn't look like there are caps on/in the BGA carrier, which > appears to be a 12-layer PCB. > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/3.jpg > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/6.jpg > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/GX95_caps.pdf > > Cool, however they do it. Every chip should have internal bypasses. They used to sell DIP sockets with built-in bypass caps....which unfortunately had about an inch of lead length. Cheers Phil Hobbs > > -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.netArticle: 156461
Le Tue, 08 Apr 2014 10:25:23 -0700, John Larkin a écrit: > I got a spreadsheet from Altera that lists the on-chip power supply > bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 > listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of > 501 nF. I was told that these caps are on-chip, not in-package. > > Is that possible? 501 nF on an FPGA chip? When I designed 10 years ago the DUT power supply of an ATE family that's now testing all the processors that you're using I was given a 400nF figure. This cap was necessarily on chip since we were directly testing the wafer. -- Thanks, Fred.Article: 156462
Le Tue, 08 Apr 2014 16:09:49 -0400, Phil Hobbs a écrit: > On 04/08/2014 02:16 PM, John Larkin wrote: >> On Tue, 08 Apr 2014 13:39:31 -0400, Phil Hobbs >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>> On 04/08/2014 01:25 PM, John Larkin wrote: >>>> >>>> >>>> I got a spreadsheet from Altera that lists the on-chip power supply >>>> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >>>> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >>>> 501 nF. I was told that these caps are on-chip, not in-package. >>>> >>>> Is that possible? 501 nF on an FPGA chip? >>>> >>>> >>>> >>> Maybe attached to the top of the die with micro-C4s. >>> >>> Cheers >>> >>> Phil Hobbs >> >> Yeah, there could be discrete caps under the lid. But 32 of them? > > Well, that would give you the least inductance, for sure. > For the extreme case you can have both: embedded into the silicon plus additional under the lib. The big processors are given for something like 100A/ns which you can't get with if you don't have that two level bypass to supplement the usual board level bulk... -- Thanks, Fred.Article: 156463
Den tirsdag den 8. april 2014 22.09.49 UTC+2 skrev Phil Hobbs: > On 04/08/2014 02:16 PM, John Larkin wrote: > > > On Tue, 08 Apr 2014 13:39:31 -0400, Phil Hobbs > > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > > > >> On 04/08/2014 01:25 PM, John Larkin wrote: > > >>> > > >>> > > >>> I got a spreadsheet from Altera that lists the on-chip power supply > > >>> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 > > >>> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of > > >>> 501 nF. I was told that these caps are on-chip, not in-package. > > >>> > > >>> Is that possible? 501 nF on an FPGA chip? > > >>> > > >>> > > >> > > >> Maybe attached to the top of the die with micro-C4s. > > >> > > >> Cheers > > >> > > >> Phil Hobbs > > > > > > Yeah, there could be discrete caps under the lid. But 32 of them? > > > > Well, that would give you the least inductance, for sure. > > > > > > > > It doesn't look like there are caps on/in the BGA carrier, which > > > appears to be a 12-layer PCB. > > > > > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/3.jpg > > > > > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/6.jpg > > > > > > https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/GX95_caps.pdf > > > > > > Cool, however they do it. Every chip should have internal bypasses. > > > > They used to sell DIP sockets with built-in bypass caps....which > > unfortunately had about an inch of lead length. > That was kinda hard to get around since someone for some reason had decided to put gnd and vcc at opposite ends of the chips -LasseArticle: 156464
In comp.arch.fpga John Larkin <jlarkin@highlandtechnology.com> wrote: > I got a spreadsheet from Altera that lists the on-chip power supply > bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 > listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of > 501 nF. I was told that these caps are on-chip, not in-package. > Is that possible? 501 nF on an FPGA chip? The common method of marking capacitors, similar to the resistor stripe code, is two digits and an exponent of 10 in pF. Otherwise, the traditional tolerance for IC components was about 20%. (The ratio of parts on the same chip is much closer.) Otherwise, the dielectric strength of SiO2 is about 25 MV/m (or 25V/um). At 1V you might make a capacitor at 40nm thickness. The relative dielectric constant is close (enough) to 1. Epsilon nought is about 9pf/m. C/A=epsilon nought/d=225pf/mm^2. So, about 2mm^2 would be enough. If you could do it with a reverse biased pn junction, and I will guess that you can't, the relative dielectric constant of Si is 11.7. Device on a chip are isolated by reversed biased pn junctions to the substrate. There should be a charge pump to get the substrate enough negative. (Remember when chips had a -5V power supply?) The capacitance, then, to the substrate through the reverse biased junction, depends on the thickness of the depletion region, which depends on the doping. Normally, you want that as low as possible, though. -- glenArticle: 156465
On 01/04/2014 15:43, Brane2 wrote: > Dne ponedeljek, 31. marec 2014 16:56:03 UTC je oseba rickman napisala: > >> Not sure what you think of as "insane" prices. What FPGAs do you find >> >> much lower than $10 at quantity 1? > > > I don't remeber exact numbers, but I remmeber that prieces were unusually high. > So I checked their prices for MachXO2, which I could compare to Mouser's and from this I concluded that main reason is Digikey's higher provisions, not Lattice's pricing policy. > The MachXO2 has some neat hard coded blocks, worth it to you if they are worth it to you ;-) The PLL is particularly flexible, with register access to many parameters. And there's hard coded support for I2C and SPI. We use XO2s in a Raspberry Pi expansion card, not unusually difficult to design. XO3 is clearly having a few neonatal problems, as always in this industry, so they have launched those parts with a lot of commonality with the XO2 as the XO3L range. My take is that the XO3L is most relevant to really big volumes - it doesn't have a compelling low-volume advantage over the very similar XO2. The bigger XO3 parts (XO3H?) should implement the extra stuff that they forgot to remove from the XO3L data sheet ;-)Article: 156466
Dne torek, 08. april 2014 23:30:49 UTC je oseba Tim napisala: > XO3 is clearly having a few neonatal problems, as always in this > > industry, so they have launched those parts with a lot of commonality > > with the XO2 as the XO3L range. <SNIP> > The bigger XO3 parts (XO3H?) should > > implement the extra stuff that they forgot to remove from the XO3L data > > sheet ;-) I was checking around for higher end of XO3 and was told that Lattice is about to introduce new Sapphire series with HW mult, SERDES etc in May. It's not 100% clear whether this is simply "XO3H" or are they talking about "FPGA, formerly known as ECP4" Both could make sense. 3Gb/s SERDES is getting old, so it would be nice to have it available as an option in cheap MachXO and faster 6Gb/s version in ECP4/Sapphire. OTOH, they might want to ephasize that Sapphire is simply XO3 that went throgh extreme heat treatment, just as they make Synthetic sapphire (Al2O3). ;o)Article: 156467
On 4/8/2014 5:59 PM, langwadt@fonz.dk wrote: > Den tirsdag den 8. april 2014 22.09.49 UTC+2 skrev Phil Hobbs: >> On 04/08/2014 02:16 PM, John Larkin wrote: >> >>> On Tue, 08 Apr 2014 13:39:31 -0400, Phil Hobbs >> >>> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>> >> >>>> On 04/08/2014 01:25 PM, John Larkin wrote: >> >>>>> >> >>>>> >> >>>>> I got a spreadsheet from Altera that lists the on-chip power supply >> >>>>> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >> >>>>> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >> >>>>> 501 nF. I was told that these caps are on-chip, not in-package. >> >>>>> >> >>>>> Is that possible? 501 nF on an FPGA chip? >> >>>>> >> >>>>> >> >>>> >> >>>> Maybe attached to the top of the die with micro-C4s. >> >>>> >> >>>> Cheers >> >>>> >> >>>> Phil Hobbs >> >>> >> >>> Yeah, there could be discrete caps under the lid. But 32 of them? >> >> >> >> Well, that would give you the least inductance, for sure. >> >> >> >>> >> >>> It doesn't look like there are caps on/in the BGA carrier, which >> >>> appears to be a 12-layer PCB. >> >>> >> >>> https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/3.jpg >> >>> >> >>> https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/6.jpg >> >>> >> >>> https://dl.dropboxusercontent.com/u/53724080/Parts/BGAs/GX95_caps.pdf >> >>> >> >>> Cool, however they do it. Every chip should have internal bypasses. >> >> >> >> They used to sell DIP sockets with built-in bypass caps....which >> >> unfortunately had about an inch of lead length. >> > > That was kinda hard to get around since someone for some reason had > decided to put gnd and vcc at opposite ends of the chips > > -Lasse > That just created a whole new market for the Rogers Q-cap (TM). Those caps were big flat things the size of the socket with leads on opposite corners to match the TTL pinouts. You could also use them under an IC without a socket by sharing the same component holes. As for on-BGA caps, your X-Ray inspection will show these quite nicely. -- GaborArticle: 156468
On 4/8/2014 2:23 PM, Tim Wescott wrote: > On Tue, 08 Apr 2014 12:43:50 -0500, Hal Murray wrote: > >> In article <esb8k9p3f1v40o1qmisrc8n9qptft26sll@4ax.com>, >> John Larkin <jlarkin@highlandtechnology.com> writes: >> >>> Is that possible? 501 nF on an FPGA chip? >> >> If nothing else, I'd be very syspicious of any claims with that level of >> accuracy. My guess is a typo. >> >> How big is the die? How thin would the insulator have to be? > > I vote for a typo. 501 and not 500 or 502? Or 480 or 520? They > probably meant 1nF, or perhaps "5 delete" turned into "50" in front of a > 1. > Or possibly the value from the part number, which is in pF. Two digits plus the number of zeroes to add, i.e. 501 would mean 500 pF. That would be rather small for core supply hold-up, though. -- GaborArticle: 156469
On 4/8/2014 9:49 PM, Brane2 wrote: > Dne torek, 08. april 2014 23:30:49 UTC je oseba Tim napisala: > >> XO3 is clearly having a few neonatal problems, as always in this >> >> industry, so they have launched those parts with a lot of commonality >> >> with the XO2 as the XO3L range. > > <SNIP> > >> The bigger XO3 parts (XO3H?) should >> >> implement the extra stuff that they forgot to remove from the XO3L data >> >> sheet ;-) > > > I was checking around for higher end of XO3 and was told that Lattice is about to introduce new Sapphire series with HW mult, SERDES etc in May. > > It's not 100% clear whether this is simply "XO3H" or are they talking about "FPGA, formerly known as ECP4" That will be easy to tell. The XPx and XOx lines have on board flash. The ECPx line is only RAM based. I believe the XPx line is based on the ECPx devices with the flash added as a RAM shadow. They load a lot faster than the X and A parts. I get the impression they won't be coming out with an XP3 line just like they don't have an ECP4 line. From what was said earlier in this thread Lattice wants to stop going head to head with X and A and is shooting for a different market where having the most advanced process technology is not such a big advantage. That may be a niche market for now, but I expect it has legs. > Both could make sense. > > 3Gb/s SERDES is getting old, so it would be nice to have it available as an option in cheap MachXO and faster 6Gb/s version in ECP4/Sapphire. What exactly would be the market for these smaller chips with high end SERDES? > OTOH, they might want to ephasize that Sapphire is simply XO3 that went throgh extreme heat treatment, just as they make Synthetic sapphire (Al2O3). ;o) -- RickArticle: 156470
Dne sreda, 09. april 2014 04:58:36 UTC je oseba rickman napisala: <SNIP> > That will be easy to tell. The XPx and XOx lines have on board flash. > > The ECPx line is only RAM based. I believe the XPx line is based on the It will be easy to tell, but I was trying to _predict_ , which is at this point more like guess. ;o) > From what was said earlier in this thread Lattice wants to stop going > > head to head with X and A and is shooting for a different market where > > having the most advanced process technology is not such a big advantage. > > That may be a niche market for now, but I expect it has legs. > Yes, but as said, main Lattice's strategy is to use one process. They were at 65nm for MachXO2 and ECP3 Now that they bought SIliconBlue, they had to allocate 40nm production capacities somewhere for ice40. Since 40nm has advanced to sweet spot for clients like Lattice, they started working on 40nm XO2 low cost successor - XO3. So they made density jump like XO-XO2 to something like 3x and added MIPI, 3G SERDES etc. And now seems good point to renew ECP3, if X and A have left enough space for it. To me it seems this might be the case. If they decided to "change gear" with ECP3, then they will probably upgrade SERDES, few other bits and add density or two at high end. And probably lower price points for same densities. If they can sell ECP3 now, they should be able to sell such updated 40nm ECP4. <SNIP> > What exactly would be the market for these smaller chips with high end > SERDES? If you mean ECP4, they are not that small. They are reaching densities and packages where SERDES doesn't lift the price that much any more. If you mean XO3, you musundeestood me. XO3 is to get 3G SERDES. What would be the point ? Some cheap/er low-volume peripherals for PCIe, maybe SATA etc.Article: 156471
On 4/9/2014 2:11 AM, Brane2 wrote: > Dne sreda, 09. april 2014 04:58:36 UTC je oseba rickman napisala: > > <SNIP> >> That will be easy to tell. The XPx and XOx lines have on board flash. >> The ECPx line is only RAM based. I believe the XPx line is based on the > > It will be easy to tell, but I was trying to _predict_ , which is at this point more like guess. ;o) Can't say I follow what you mean. What are you trying to predict exactly? >> From what was said earlier in this thread Lattice wants to stop going >> head to head with X and A and is shooting for a different market where >> having the most advanced process technology is not such a big advantage. >> That may be a niche market for now, but I expect it has legs. ...snip... > > If they can sell ECP3 now, they should be able to sell such updated 40nm ECP4. It is not are they selling ECP3, the question is how many new design wins? That is what FPGA vendors live and die by. They know that for each generation they have a window of opportunity to lock in some large fraction of their business for this line. Those days for ECP3 are over. So the question is can they make money on ECP4 or has that ship sailed? >> What exactly would be the market for these smaller chips with high end >> SERDES? > > If you mean ECP4, they are not that small. They are reaching densities and packages where SERDES doesn't lift the price that much any more. > > If you mean XO3, you musundeestood me. XO3 is to get 3G SERDES. > What would be the point ? Some cheap/er low-volume peripherals for PCIe, maybe SATA etc. I am taking Lattice at their word that they intend to focus on the mobile market with smaller, more cost effective devices with lower power consumption. I fail to see where high speed SERDES fit in with that strategy. Can you use generic SERDES for these interfaces? I remember reading some time back that the SERDES in Xilinx chips could not be used for SATA, not because of speed limitations, but because the SERDES is not compatible. I know little about SATA but it seems like a signficant oversight to me. -- RickArticle: 156472
On 09/04/2014 03:25, John Larkin wrote: > > > I got a spreadsheet from Altera that lists the on-chip power supply > bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 > listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of > 501 nF. I was told that these caps are on-chip, not in-package. > > Is that possible? 501 nF on an FPGA chip? > > Sounds quite likely. The original DEC Alpha CPU had about 100nF on die, and that was in the 90s. Decoupling capacitors normally use gate oxide as the dielectric, so on more modern processes the capacitance could be greater. They might not use the thinnest gate oxide for the capacitors these days as the leakage current per area starts to get quite large with very low voltage transistors. When using place and route tools to generate logic layout from the verilog, you can set up the tools to not leave blank spaces in the layout where no gates would fit, but to put in a decoupling capacitor cell instead. Because it is embedded within the logic it helps more than a big lumped capacitor off at the edge of the logic. If necessary, you can even tell the tools to put in a certain quantity of capacitors within the logic layout even if it would have been able to pack the logic a bit more densely without. If the package has bondwires (or comparable series inductance in the power supply pins), then these can resonate with the on-chip decoupling, to form a parallel resonant circuit that presents the chip circuitry with a very high impedance at some RF frequency. In order to avoid this effect, I used to simulate with the package model and I would break the decoupling capacitor into smaller banks and put series resistors of various values in series with some of the banks of capacitors, so that the Q is low and the impedance is reasonable at all RF frequencies of interest. ChrisArticle: 156473
On 04/09/2014 08:59 AM, Chris Jones wrote: > On 09/04/2014 03:25, John Larkin wrote: >> >> >> I got a spreadsheet from Altera that lists the on-chip power supply >> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >> 501 nF. I was told that these caps are on-chip, not in-package. >> >> Is that possible? 501 nF on an FPGA chip? >> >> > > Sounds quite likely. The original DEC Alpha CPU had about 100nF on die, > and that was in the 90s. Decoupling capacitors normally use gate oxide > as the dielectric, so on more modern processes the capacitance could be > greater. They might not use the thinnest gate oxide for the capacitors > these days as the leakage current per area starts to get quite large > with very low voltage transistors. > > When using place and route tools to generate logic layout from the > verilog, you can set up the tools to not leave blank spaces in the > layout where no gates would fit, but to put in a decoupling capacitor > cell instead. Because it is embedded within the logic it helps more than > a big lumped capacitor off at the edge of the logic. If necessary, you > can even tell the tools to put in a certain quantity of capacitors > within the logic layout even if it would have been able to pack the > logic a bit more densely without. > > If the package has bondwires (or comparable series inductance in the > power supply pins), then these can resonate with the on-chip decoupling, > to form a parallel resonant circuit that presents the chip circuitry > with a very high impedance at some RF frequency. In order to avoid this > effect, I used to simulate with the package model and I would break the > decoupling capacitor into smaller banks and put series resistors of > various values in series with some of the banks of capacitors, so that > the Q is low and the impedance is reasonable at all RF frequencies of > interest. > > Chris Just out of curiosity, which tools exist/do you use to go from verilog/VHDL to layout? PereArticle: 156474
On 09/04/2014 17:50, o pere o wrote: > On 04/09/2014 08:59 AM, Chris Jones wrote: >> On 09/04/2014 03:25, John Larkin wrote: >>> >>> >>> I got a spreadsheet from Altera that lists the on-chip power supply >>> bypass caps on an Arria II GX95 FPGA. I was kind of shocked to see 32 >>> listed capacitors, most around 1 nf, but a Vcc_core (0.9 volt) cap of >>> 501 nF. I was told that these caps are on-chip, not in-package. >>> >>> Is that possible? 501 nF on an FPGA chip? >>> >>> >> >> Sounds quite likely. The original DEC Alpha CPU had about 100nF on die, >> and that was in the 90s. Decoupling capacitors normally use gate oxide >> as the dielectric, so on more modern processes the capacitance could be >> greater. They might not use the thinnest gate oxide for the capacitors >> these days as the leakage current per area starts to get quite large >> with very low voltage transistors. >> >> When using place and route tools to generate logic layout from the >> verilog, you can set up the tools to not leave blank spaces in the >> layout where no gates would fit, but to put in a decoupling capacitor >> cell instead. Because it is embedded within the logic it helps more than >> a big lumped capacitor off at the edge of the logic. If necessary, you >> can even tell the tools to put in a certain quantity of capacitors >> within the logic layout even if it would have been able to pack the >> logic a bit more densely without. >> >> If the package has bondwires (or comparable series inductance in the >> power supply pins), then these can resonate with the on-chip decoupling, >> to form a parallel resonant circuit that presents the chip circuitry >> with a very high impedance at some RF frequency. In order to avoid this >> effect, I used to simulate with the package model and I would break the >> decoupling capacitor into smaller banks and put series resistors of >> various values in series with some of the banks of capacitors, so that >> the Q is low and the impedance is reasonable at all RF frequencies of >> interest. >> >> Chris > > Just out of curiosity, which tools exist/do you use to go from > verilog/VHDL to layout? > > Pere I never drove those tools, I was mostly doing analogue stuff. I think it is a multi-stage process, the first stage could use "design compiler" from Synopsys, and then there are various other programs involved in the physical placement and timing verification which I don't really know about. Sorry I don't know the names of them. I know these were very expensive, presumably because they could save a significant percentage of the chip area, which translates into a significant amount of money saved on production. Chris
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