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
Hi, I'm using RC1000-PP board , how can I knew the serial number of the RC1000-PP borad ? ThanksArticle: 37101
Rick Filipkiewicz wrote: > > rickman wrote: > > > > > But the FT package is just a lower profile version of the FG package. > > There are a lot of applications where height is very, very important. > > Didn't you go to the web site to find the packaging data sheet? That is > > where I found it. > > > > You're absolutely right. Having a class 1 bad day made me blind (CVS crashed > during an attempted remote checkin and scribbled junk over some files just > after I found what seems to be the recurrence of an old Synplify bug. !? > Should have stopped right there & gone out for a beer or 10). Apologies to > Xilinx. > > I'm trying to imagine an app that needs a ~0.5mm height improvment & can only > think of the reverse side of a PCI card where the max component height is > 0.8'' IIRC. I assume that you mean 0.08". Is that really true? I am used to 0.1" being the "standard" back side height for most boards. Even so, the FG256 is only 0.079" (2 mm). I would bet this is more for PCMCIA, PMC cards or some similar mezzanine application. Anyone know for sure why you need 1.55 mm vs. 2 mm component height (FT vs. FG)? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37102
Falk Brunner wrote: > > "Jan Gray" <jsgray@acm.org> schrieb im Newsbeitrag > news:9u3knp$53a$1@slb4.atl.mindspring.net... > > > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of > different > > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 > > QFP packages. " > > Who wants a PQ208 package? I dont want to build a brick wall ;-) > -- > MfG > Falk I think the idea is that they are not BGAs of any type. Not everyone wants the highest density known to man. Personally I don't think the CS144 package is used on enough parts, and what ever happened to the CS280??? That was one with enough IO to be useful and the open center made routing possible without dozens of inter-pad vias. The FG256 is one bear to route. The CS144 is nice, but not used on enough parts. Likely the cavity size won't let many parts fit inside... Speaking of routing... Anyone know where I can get guidelines for pad and via layout on these parts? I thought Xilinx had a document somewhere, but I can't find it on their web site. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37103
Austin Lesea wrote: > > Rick, > > Now we get into the 'voodoo' part of the analysis. > > With a number of devices in parallel the issue becomes complex. If each > device requires a current based on the voltage it sees across its terminals, > there is some small variation of this voltage to current behavior from die > to die, part to part. There is also some IR drop in each package, and > through the board. > > The text suggests that with four times the current, you will succeed, and > discusses how more than four times is not required even though the peak > current may exceed the minimum required. It does not imply you can use less > than four times the specification. > > No one can say with any certainty that the four parts will power ON with > less than four times the individual ratings, other than: we guard banded > the spec (so the actual current is almost surely less), they won't all > require the current at the exact same moment, any one device will have the > total current available to it if the others are not using it yet (or have > finished using it). > > Austin I must say that this sounds a lot like "voodoo". I am not looking to startup four devices with less than four times Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a lot of time on this and the number is what the number is (until it is some other number which is what I am waiting for). But if a part can start with less current in this situation, why can't it start with less current all the time? Lets consider a completely realistic example. You mention that there is variation between parts and so it is not likely that all four parts will require the full current. But my understanding is that Iccpo is a MIN not a MAX. So if the power supply will provide MORE current, the parts will TAKE it even when ramped within the spec time period. Do I understand the spec and app note on this? So if you have multiple parts in parallel, any one part might have a lower PO impedance than the others and draw a LARGER than Iccpo current. This will leave LESS than Iccpo for each of the remaining devices. If any one of these devices REQUIRE the full Iccpo to come up fully, then that part will not init correctly. Even with a guard band, how can you guarantee that there will not be a problem? It is possible that three of the four devices hog more than their share of the current and the fourth device is the odd man out. Seems likely to me that the odd man will not come up... I don't mean to belabor this point too much. Maybe I should just stop worrying about it until the new numbers are out? > rickman wrote: > > > I just found app note 450 about the Spartan II startup current. > > > > There is one section discussing the power up of multiple FPGAs that > > seems to say that you can get by with less than the specified minimum > > Iccpo. "Assume the supply can source just enough current to meet the > > total minimum POS current requirement (four times the applicable I CCPO > > limit). Each FPGA can be modeled as a very low impedance element during > > power-on. According to this simplified perspective, the power-supply > > sees four low impedance elements in parallel. If one FPGA takes on a > > lower impedance value than the others, it will draw more POS current for > > a shorter time. The other FPGAs accept less current for a longer time. > > After this fashion, all four FPGAs receive the energy they require to > > power-on successfully." > > > > This seems to be a case where some of the FPGAs do not receive the Iccpo > > current and yet still power up correctly. I understand that they take > > longer to bring up, but can't this be done in other cases as well? I > > would expect Iccpo to be a minimum regardless. No? > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37104
This is likely not to be a fruitful debate. I think it has been hashed
here before. But I will be happy to make another round of comments. :)
Neil Franklin wrote:
>
> mrgs1000@yahoo.com (Mark) writes:
>
> > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C065266.E43453F@yahoo.com>...
> > > Neil Franklin wrote:
> > > >
> > > > Hint to vendors: if your part has open source support, it gets more
> > > > recommendations ("take that one, it works"), and you get to sell more
> > > > of them. I principially buy video and ethernet cards after consultion
> > > > the on-line support databases.
> > >
> > > Designers don't EVER want to compromize their choice of chip based on
> > > the tools. That would be more like vacationing in Newark because the bus
> > > is cheaper than taking a plane to the Bahamas!
>
> Which quite a lot of people actually do. Select on price, that is, not
> chose Newark.
But that was my point. By having to settle for a chip that is not what
the designer really wants or needs, he is taking a vacation in a place
where he doesn't even want to be! The economies of FPGA sales (remember
all of this is decided by the profit of the FPGA company, not the
users!) says you cater to your large customers since they make up some
80 to 90% of your profit.
> > > The idea that open source tool support will significantly impact the
> > > sales of FPGA chips is weak at best.
>
> Short term they may not. Think long term: they pull in more beginners,
> and so in time grow the population of FPGA developers, and so allow
> firms to emply more and so make more FPA projects and that sells more
> chips.
That sounds great, but you missed the significance of my example below.
If a high volume user can make $10 more profit on brand R than on brand
P, he will not likely let the tools decide for him. Not with a volume of
100,000 or more units. He will churn the design and crack the whip on
the engineers and get the design cranked out by hook or by crook. Let's
face it, a million here and a million there and pretty soon you are
counting real money :)
The small volume customers don't count. The high volume customers will
ALWAYS pick parts on price, not based on what the engineer LIKES to use.
> > > chips in SPITE of the awful toolset they had to use. This was because
> > > the chip was $10 cheaper than the other brand. It ended up costing them
> > > a lot when they had to make revisions, but this was still the best
> > > solution in terms of PROFIT!!!
>
> If you are at 100'000 or even 1 mio sized series, no doubt this
> holds. But at 100 parts chip cost is not relevant. Tool support is.
At 100 parts, the user is irrelevant. I don't mean to be mean. But I
think both Xilinx and Altera do a pretty good job of supporting the
small customer relative to the amount of profit they generate. Try
getting Lucent (opps Agere) to chat with you about an annual volume of
100 pieces. HA!
> > > > > and new devices are released on a weekly basis. I
> > > >
> > > > So that makes about 2 falimies per year industrywide to support. Or
> > > > simply only support a few of them and only use those.
> > >
> > > But a familiy has some 10 different parts in it.
>
> And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200.
Now you are showing that you have a lot to learn about the problem. I
first heard about 10 years ago that the FPGA companies sell you routing
and throw in the logic for FREE. The point is that way more than half
the chip is routing. WAY, FAR more than half the software is about the
ROUTING, not the CLB. I have written software in school to do logic
minimization and such. The real trick is to efficiently place and route
a part. This is not software you can write in your spare time. But I
would be happy to be proven wrong...
> > > Each of those parts has
> > > many packages
>
> Inserting pin out tables is not that much work.
>
> > > and several speeds. Just getting the speed info (critical)
> > > is not an easy problem to solve. Without vendor support, you would be
> > > very hard pressed for anyone to trust your data.
>
> That may be important for the n*100MHz croud. Not everyone is playing
> up there. Just all the potential sound processing applications, for
> one, 48kHz anyone?
48 kHz x how many channels x how many filter taps etc. Not many designs
DON"T push 100 MHz these days. Even at 50 MHz, you have to count your nS
or you end up with a critical path that doesn't work when the die warms
up to operating temp.
> > > It certainly could be done, but the fact that it has not happened yet is
> > > a good indicator that it is harder than you seem to believe.
>
> So long non-availability of information makes it impossible, any "not
> happened" is 100% explained. Everything else remains speculation until
> that barrier falls.
Only a small part of the process is not documented. That would be the
final step of generating the bit file. As has been pointed out here
before, one of the smaller tasks in designing this sort of software
would be reverse engineering the bit file format. If someone would sign
up to writing a complete, end to end development system, I would happily
spec the bit file for you! Just tell me which part.
> > It’s actually even worse than that. Vendors are constantly
> > re-characterizing the parts and re-releasing updated timing models for
> > previously released parts.
>
> Again only relevant to the top speed crowd.
You are talking about some 80 to 90% of the users, I would bet.
> > This brings up another point, in addition to the place and route
> > tools, you have to also provide the timing analysis tools.
>
> You know how many home/edu people overclock CPUs? Raise frequency until
> crash, than drop by 10% is the sort of algorithm. It is "good enough"
> for the target audience.
Tell me again who is the target audience, hobbiest?
> > It’s true that new families don’t get released often, but
> > when they do, you have to practically throw out your place and route
> > software because the architecture changes are too drastic.
>
> No different from the problems facing the gcc team when supporting
> code generators for new processors. They are presently at well over
> 20 architectures. And yes, some of the code generators suck.
>
> > doing hand placement for critical circuits. When I switched from
> > Virtex E to Virtex II not only was all of my work in Virtex E
> > worthless, it was a hindrance
>
> I doubt that "worthless". As ex-VirtexE-er you surely learned VirtexII
> faster than someone with no experience in placing and so also no
> knowledge what sort of pitfalls to look out for. Reuse of knowledge.
We won't know for sure how complex this task is until someone trys to do
it :)
> > > > Does not look like you are an average user there. :-)
> > >
> > > Actually, I think he is a typical user. I think every place I have
> > > worked has used beta versions of the chips at one time or another.
>
> > To be clearer, I am a typical Tier One user of FPGAs. Meaning that the
> > companies I have worked for are high profile international accounts
> > for the FPGA companies.
>
> Your critique may apply to the situation at top commercial facilities.
> For home/edu (where I am) I would not expect that to be the case.
I would be willing to bet that by the time you got the tools working for
a single chip in a single speed grade in a single package, there will be
two new families from that vendor.
> > know that from a volume standpoint my group uses more FPGAs than any
> > other group.
>
> Present usage. Think a bit further into the future. There are millions
> of future developers out there. Presently they are playing around
> designing websites. What are they going to go into professionally?
> Websites. Now think if a few 10'000 of them were playing around with
> FPGAs. Whom will they be presenting their workforce to in 5 years?
They will use the parts that offer the best value, not the parts the
offer the "coolest" tools.
> > plentiful (no longer NDA) but this group would be limited and most
> > likely restricted to hobbyists, students, and a few niche markets
> > which have little competition.
>
> And that is already usefull.
To the hobbyists! The students get tools for free (as in beer, not
speech) or nearly so anyway.
> > You can choose to debate this, however, the fact such tools
> > don’t exist is pretty good support for my argument.
>
> Nope. Non-existance comes from non-information. Proof for your
> argument will only be available after the information has been
> available for some time and not being used.
I think you have not really looked at the problem to be solved. As I
said above, only the final bit file generation is not disclosed. That
can be reverse engineered. So if anyone were serious about this, it
could be attempted.
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
> - Intellectual Property is Intellectual Robbery
Among your list of avocations do you include FPGA design? Before you get
too excited about the tools, don't you think you should learn from what
has happened to date?
--
Rick "rickman" Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Article: 37105rickman wrote: > > Austin Lesea wrote: > > <snip> > I am not looking to startup four devices with less than four times > Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a > lot of time on this and the number is what the number is (until it is > some other number which is what I am waiting for). But if a part can > start with less current in this situation, why can't it start with less > current all the time? > > Lets consider a completely realistic example. You mention that there is > variation between parts and so it is not likely that all four parts will > require the full current. But my understanding is that Iccpo is a MIN > not a MAX. So if the power supply will provide MORE current, the parts > will TAKE it even when ramped within the spec time period. Do I > understand the spec and app note on this? > > So if you have multiple parts in parallel, any one part might have a > lower PO impedance than the others and draw a LARGER than Iccpo current. > This will leave LESS than Iccpo for each of the remaining devices. If > any one of these devices REQUIRE the full Iccpo to come up fully, then > that part will not init correctly. Even with a guard band, how can you > guarantee that there will not be a problem? It is possible that three of > the four devices hog more than their share of the current and the fourth > device is the odd man out. Seems likely to me that the odd man will not > come up... I think the correct model for this sounds like a giant sea of CMOS gates. Consider a simple inverter : As Vcc ramps, the GATE junction will ramp at appx 50% Vcc, due to the capacitive voltage divider. This means at appx Vcc of 2 x Vth ( or VthP + VthN ), all GATES will be in the transistion from Off/capacitive, to actually functional. In this state, they will draw current, not much each, but there are LOTS of them! ( One million times 1uA -> 1A ) It is mainly a DC effect, but will interact with dV/dT of the supply a little. A Flyback (isolated) switchmode can deliver more current, at lower voltages, but a Series (non isolated) mode switchmode cannot. Given this model. I'm not sure you could rely on a sequential 'different threshold' ramp of multiple FPGAs. If they are all the same Batch/Die, they are likely to be quite well matched. ( Murhpys law.. ) It would seem a power switch is cheaper than a bigger power supply ? Power MOSFETS are getting cheaper and smaller, or a two stage regulator, where the second stage is switched and has access to some energy storage... -jgArticle: 37106
Neil Franklin <neil@franklin.ch.remove> writes: > That may be important for the n*100MHz croud. Not everyone is playing > up there. Just all the potential sound processing applications, for > one, 48kHz anyone? The vendors are giving away decent tools for the low-end FPGAs and CPLDs these days. No excuse for a hobbiest to not be able to make fun stuff in the basement for almost nothing beyond the part price anymore. But heck, if you really want to write an open source tool then go right ahead! How you spend your free time is up to you. Or were you merely complaining that there's no free tool for the newest parts? KellyArticle: 37107
Hi, Hi >Spartan II is 5V tolerant. I confirm that in operating mode, but we phoned with the german support site of XILINX and they tould us following (hopefully correct translated ;-) ---------------SNIP----------------- Q: Might it be possible that Bus- and Control-signals are able to destroy the FPGA, if these peripheral signals are already high when 2.5V and 3.0V of the SPARTAN isn't present yet? A: (application engineer) It's NOT IMPOSSIBLE that something like this occurs, so you should keep the power up sequence 2.5V -> 3.3V -> 5V (peripheral). ---------------SNIP----------------- Matter of fact is, that we DO HAVE dying FPGAs in about 3% of power-on cycles in different applications. But regrettably it's not reproduceable to fix that problem. So, I hope to find someone who had similar experiences and knows what should be implicitly avoided. >The IO's are high impedance to a 5V signal >until it is configured, and under control of the user logic (then it can >be tristate, or drive). > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > >page 1 > >Austin > >Wolfram Sieber wrote: > >> Hi folks, >> does anyone has any experience in SPARTAN II and 5V peripheral >> components? >> Are there any known issues about dying FPGAs which are connected to 5V >> Busses etc. while powering up the system? >> >> I've got the strong feeling that SPARTAN 2 could dy, if the 5V >> components are powered up before the FPGA supply is stable. >> >> Is it necessary to keep the peripherals 'disconnected' while powering >> up? >> >> I'm glad about ANY information and espacially experience on the 5V >> issue and eventually existing power-up sequence constraints. >> >> Thanx in advance >> >> Wolfram >Article: 37108
Good Morning , today I've to talk about a problem with Synflify, I'm a new user of it so maybe it is just a stupid problem, here it is : In my application I've a master clock at 165MHz and 3 derived clock 165/3 , 165/4 and 165/6 , depending on a signal rate_sel I choose by means of a multiplexer which one of the clock to use, the signal at the out of the multiplexer is named clk_div_n . The problem is that I want to put the following constrain : clk -> 165 MHz clk_div_n -> 55 MHz but in the constrain editor after compiling I've only clk signal discovered, for it I've set 165MHz constrain and after compiling again and mapping I've the following result : System clock -> 395 MHz (...what is this) clk -> 87.2 MHz clk_div_n_inferred -> 78.1 MHz so clk_div_n is inferred but there's no way to set the right constrain on it. Can you help me in set the right constrain to Synplify ver 7.02 ?? Thanks AntonioArticle: 37109
sunny <sunrise@sunrise.at> wrote in message news:<ee73541.2@WebX.sUN8CHnE>... > Instead of generating a clock you could generate a clock enable. Thatīs very easy. You only would need two flops, one inverter and one and gate. The enable signals generated by using that circuit has a pulse length of exactly one clock cycle. Just try it Please excuse me sunny but I've not understand what you mean, you know I've thrre clocks and a multiplexer, are you telling me to take away the multiplexer and use 3 clocks with an enable input and a three state output?? Can you also explain me the way this inverter and "and gate" are connected ?? Thanks again and excuse me for my inexperience. AntonioArticle: 37110
Have a look at www.symphonyeda.com where you will find a VHDL simulator called Simili I think there are some graphic Tcl programs that allow you to look at the waveforms, but if you design your testbenched for file IO then you should love this program..... and it is free. -John -- JohnM http://www.calyptech.com "Ed Browne, Precision Electronic Solutions" <ed_b_pes@swbell.net> wrote in message news:05uN7.600$oO4.343960630@newssvr11.news.prodigy.com... > It's appalling that Xilinx would sell a product to design an FPGA/CPLD > without the ability to simulate the design unless you buy a $1000+ > simulator. Neither the free version nor the eval version allows testing on > anything over 500 lines. At that limit on my machine, it simply closes - no > slowing down. > > Does anyone have a lower cost alternative, preferably one that would accept > the HDL bencher output? > > Ed Browne > Precision Electronic Solutions > > "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message > news:3BFA68F1.10118196@egr.msu.edu... > > > > > > Leon Heller wrote: > > > > > Sorry, I've just checked the Xilinx version. It is only for small > designs. > > > > > > -- > > > Leon Heller, G1HSM leon_heller@hotmail.con > > > http://www.geocities.com/leon_heller > > > Low-cost Altera Flex design kit: http://www.leonheller.com > > > > It will work with much larger designs. It just runs slower. > > > > > >Article: 37111
Hi y'all, I am looking for some information on developing hostsoftware for the Ballynuey 2 board. Who can give me information? Can somebody recomend sources in the Net? Best regards and thanx, MartinArticle: 37112
"Stella, Wang Zhanqing" <wangzhan@comp.nus.edu.sg> wrote in message news:191C91BDFE8ED411B84400805FBE794C1C55361F@pfs21.ex.nus.edu.sg... > Hi, I'm using RC1000-PP board , how can I knew the serial number of the > RC1000-PP borad ? The board's serial number is printed on a label on the board. If you mean the revision number, use the 'diag' tool, select your card, and type 'info'. Stephen Melnikoff. -- Stephen Melnikoff - s.j.melnikoff@iee.org Electronic, Electrical and Computer Engineering University of Birmingham, Birmingham, UKArticle: 37113
Kate Meilicke <katem@xilinx.com> wrote: > Put the period on the input clock to the DCM. The Xilinx tools will create > the necessary period constraints for the output clocks of the DCM. I noticed one issue with regard to automatic propagation of timing constraints.. it doesn't seem to work with IBUFGDS components. ie if you put a PERIOD constraint on its input, it won't be propagated to the output. There seem to be some funny rules with regard to propagating TNM properties too. From memory they must be added on the BUFG output, as putting them on the DCM or IBUFG output won't work. Or something like that. cheers Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 37114
rickman <spamgoeshere4@yahoo.com> writes: > I assume that you mean 0.08". Is that really true? I am used to 0.1" > being the "standard" back side height for most boards. Even so, the > FG256 is only 0.079" (2 mm). I would bet this is more for PCMCIA, PMC > cards or some similar mezzanine application. Anyone know for sure why > you need 1.55 mm vs. 2 mm component height (FT vs. FG)? My understanding is that the FT is thinner because it is. Fewer layers in the spackage substrate (2 instead of 4). Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 37115
On 28 Nov 2001 19:37:56 +0100, Neil Franklin <neil@franklin.ch.remove> wrote: >P.S. to the @xilinx.com readers here: the often given reason for >bitstream secrecy was that the PROM->FPGA link allows it to be grabbed >and disassembled. With V2 the DES stuff was implemented to fix that >hole. Is there any chance that the V2 bitstream will one day be publically >(= non-NDA) documented? Perhaps an XAPP for those that want to know? Ah, at last a motivation for this secrecy. I have often wondered why they didn't document it. The best I could think of was to make cloning more difficult. >> IOW, if I wanted to implement >> an open-source synthesis tool, which devices should I target? Again, >> recommendations would be greatly appreciated. > >The nearest I have found is to use Virtex/Spartan-II. For these there >exists JBits. This is an API+library to modify/generate bitsreams. It >is totally low-level (individual CLB features), driven by Java code (so >usable to implement own CAE tools), free (as in beer, not as in speech), >not crippled (such as artificially slowed to make an payware version >attractive), written in Java (runs on Linux and BSD with Sun JDK). Thanks for the pointer. It sounds like the next best thing.Article: 37116
On Thu, 29 Nov 2001 09:47:29 GMT, Reinoud <dus@wanabe.nl> wrote: >Kees van Reeuwijk wrote: >> I understand that the scarcity of such software is partly because >> vendors do not release enough information. > >Exactly. > >> Are there any modern devices for which this information *is* >> available? > >Not really, but there is a workaround (MPGA): > > http://ce.et.tudelft.nl/~reinoud/mpga/README.html Thanks for the pointer, but I'd rather try a non-virtual FPGA first. Neat idea, though :-)Article: 37117
On Thu, 29 Nov 2001 10:21:10 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:
>Neil Franklin wrote:
>>
>> mrgs1000@yahoo.com (Mark) writes:
>>
>> > Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
>> k0l3mmebi1703urlud5e91rou5af@4ax.com>...
>> > >
>> > > I understand that the scarcity of such software is partly because
>> > > vendors do not release enough information. Are there any modern devices
>> >
>> > I would venture to say that the primary road block to open-source
>> > tools is that they are too dificult to support and keep current for
>> > people to do for free.
>>
>> As opposed to tons of video and ethernet chips that the Linux people
>> seem to have no great problem with?
>>
>> Just simply support those chips that members of the open source group
>> use. And the software users then buy those parts.
>>
>> Hint to vendors: if your part has open source support, it gets more
>> recommendations ("take that one, it works"), and you get to sell more
>> of them. I principially buy video and ethernet cards after consultion
>> the on-line support databases.
>
>I think this is where the analogy between standard hardware support
>under a standard OS and FPGA support under a standard tool fails.
>Designers don't EVER want to compromize their choice of chip based on
>the tools. That would be more like vacationing in Newark because the bus
>is cheaper than taking a plane to the Bahamas!
>
>The idea that open source tool support will significantly impact the
>sales of FPGA chips is weak at best. The customers who buy lots of chips
>from the FPGA vendors get free tools and often have an FAE parked in
>their facility. I worked at one place where they still used brand Z
>chips in SPITE of the awful toolset they had to use. This was because
>the chip was $10 cheaper than the other brand. It ended up costing them
>a lot when they had to make revisions, but this was still the best
>solution in terms of PROFIT!!! (brand Z is not meant to be any
>particular company!)
Fair enough, for a volume application.
However, if the FPGA is used for reconfigurable computing, the situation
is different. I'm convinced that the first vendor with both a PCI FPGA
board and an open-source toolset will become extremely popular in hacker
circles. And who knows, it may even become popular in mainstream
computing.
The big FPGA vendors may not be interested in this market, but I'm
surprised that none of the smaller ones has tried this. (Hint, hint :-)
>> > There are lots of flows for design entry and
>> > simulation,
>>
>> Just support those that the present maintainers use. And use those
>> that are supported.
>>
>> > and new devices are released on a weekly basis. I
>>
>> Huh? As far as I see it Xilinx has so far created about 9 families
>> (2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
>> VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
>> (MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
>> in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
>> families (4000 6000). Actel I do not know, as I can not read their
>> website (damn Flash and not HTML alternative). And a few other
>> irrelevant manufacturers.
>>
>> So that makes about 2 falimies per year industrywide to support. Or
>> simply only support a few of them and only use those.
>
>But a familiy has some 10 different parts in it. Each of those parts has
>many packages and several speeds. Just getting the speed info (critical)
>is not an easy problem to solve. Without vendor support, you would be
>very hard pressed for anyone to trust your data.
>
>It certainly could be done, but the fact that it has not happened yet is
>a good indicator that it is harder than you seem to believe.
I consider timing info as just another part of the now-secret device
programming info.
However, for reconfigurable computing applications one *could*
characterize each individual device and use that (with a safety margin,
of course).
Article: 37118Rick, No that is OK. The concern is real, and in fact, we spent a lot of time characterizing this so we could state the spec the way we stated it. Yes, you got the spec right. The current requirement is a current vs time situation. As soon as the minimum is supplied for the required time, it goes away. So if you have a "hog" he gets fed, and gets full first (the more current, the less time), and then the other pigs can get to the trough. Sorry about the analogy. Please contact Kim.Goldblatt@xilinx.com if you want the new numbers, now. Austin rickman wrote: > Austin Lesea wrote: > > > > Rick, > > > > Now we get into the 'voodoo' part of the analysis. > > > > With a number of devices in parallel the issue becomes complex. If each > > device requires a current based on the voltage it sees across its terminals, > > there is some small variation of this voltage to current behavior from die > > to die, part to part. There is also some IR drop in each package, and > > through the board. > > > > The text suggests that with four times the current, you will succeed, and > > discusses how more than four times is not required even though the peak > > current may exceed the minimum required. It does not imply you can use less > > than four times the specification. > > > > No one can say with any certainty that the four parts will power ON with > > less than four times the individual ratings, other than: we guard banded > > the spec (so the actual current is almost surely less), they won't all > > require the current at the exact same moment, any one device will have the > > total current available to it if the others are not using it yet (or have > > finished using it). > > > > Austin > > I must say that this sounds a lot like "voodoo". > > I am not looking to startup four devices with less than four times > Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a > lot of time on this and the number is what the number is (until it is > some other number which is what I am waiting for). But if a part can > start with less current in this situation, why can't it start with less > current all the time? > > Lets consider a completely realistic example. You mention that there is > variation between parts and so it is not likely that all four parts will > require the full current. But my understanding is that Iccpo is a MIN > not a MAX. So if the power supply will provide MORE current, the parts > will TAKE it even when ramped within the spec time period. Do I > understand the spec and app note on this? > > So if you have multiple parts in parallel, any one part might have a > lower PO impedance than the others and draw a LARGER than Iccpo current. > This will leave LESS than Iccpo for each of the remaining devices. If > any one of these devices REQUIRE the full Iccpo to come up fully, then > that part will not init correctly. Even with a guard band, how can you > guarantee that there will not be a problem? It is possible that three of > the four devices hog more than their share of the current and the fourth > device is the odd man out. Seems likely to me that the odd man will not > come up... > > I don't mean to belabor this point too much. Maybe I should just stop > worrying about it until the new numbers are out? > > > rickman wrote: > > > > > I just found app note 450 about the Spartan II startup current. > > > > > > There is one section discussing the power up of multiple FPGAs that > > > seems to say that you can get by with less than the specified minimum > > > Iccpo. "Assume the supply can source just enough current to meet the > > > total minimum POS current requirement (four times the applicable I CCPO > > > limit). Each FPGA can be modeled as a very low impedance element during > > > power-on. According to this simplified perspective, the power-supply > > > sees four low impedance elements in parallel. If one FPGA takes on a > > > lower impedance value than the others, it will draw more POS current for > > > a shorter time. The other FPGAs accept less current for a longer time. > > > After this fashion, all four FPGAs receive the energy they require to > > > power-on successfully." > > > > > > This seems to be a case where some of the FPGAs do not receive the Iccpo > > > current and yet still power up correctly. I understand that they take > > > longer to bring up, but can't this be done in other cases as well? I > > > would expect Iccpo to be a minimum regardless. No? > > > > > > -- > > > > > > Rick "rickman" Collins > > > > > > rick.collins@XYarius.com > > > Ignore the reply address. To email me use the above address with the XY > > > removed. > > > > > > Arius - A Signal Processing Solutions Company > > > Specializing in DSP and FPGA design URL http://www.arius.com > > > 4 King Ave 301-682-7772 Voice > > > Frederick, MD 21701-3110 301-682-7666 FAX > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 37119
Allan, If you think FPGAs are current hogs ..... I saw what the SDRAMs take..... wow! Austin Allan Herriman wrote: > On 28 Nov 2001 08:14:58 -0800, brad@tinyboot.com (Brad Eckert) wrote: > > >At a recent FPSLIC seminar, Atmel's marketing guy mentioned that some > >FPGAs have high startup current (a couple of amps) so their FPSLIC > >would have simpler power requirements than a soft CPU. > > > >Is this still true? I'm looking at a Spartan II XC2S30 or XC2S15 for a > >soft CPU. Even a 1A startup current is a little hard to imagine, since > >you'd expect the logic to start out in a cleared state. > > > >Can anyone tell me what kind of startup current to expect from low > >cost FPGAs like Spartan or ACEX? > > In case anyone thinks this sort of behaviour is new, I recall seeing > an app note in an Intel memory data book from almost 20 years ago that > showed that their (then new) 5V only NMOS DRAM parts would draw lots > of current when the supply voltage ramped up to about 1.5V (IIRC). > > The cause in that case was that the back bias generator for the > substrate hadn't turned on yet, and the leakage current in each fet > was rather large. > > The V-I characteristic was something like: > > ^I > | > | > | . . > | . . . > | . . . > | . . > |. > +------------------------>V > > Regards, > Allan.Article: 37120
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3C06F92D.41D20304@yahoo.com... > I think the idea is that they are not BGAs of any type. Not everyone > wants the highest density known to man. Personally I don't think the Sure, if space is not critical, they are fine and easier to use (layout, probing, manufacturing etc.) > CS144 package is used on enough parts, and what ever happened to the > CS280??? That was one with enough IO to be useful and the open center We used it in one project. . . . caused a lot trouble with the PCB- maker :-( -- MfG FalkArticle: 37121
"Ed Browne, Precision Electronic Solutions" wrote: > > It's appalling that Xilinx would sell a product to design an FPGA/CPLD > without the ability to simulate the design unless you buy a $1000+ > simulator. Neither the free version nor the eval version allows testing on > anything over 500 lines. At that limit on my machine, it simply closes - no > slowing down. > What was appalling was the old Xilinx gate-level simulator. What a POS. Xilinx' primary interest is in selling chips, and to that end, they supply place-and-route tools. The design-entry front-end tools have always been someone else's problem. Consider: The schematic entry used to be that brain-dead Viewlogic "Pro Series" crap. (Before that, you had to supply your own schematic-capture tool!) Synthesis used to be the old Metamor tool, then FPGA Express. If you wanted a better synthesis tool (and you really DO want a better synthesis tool), you've gotta pony up for Synplify or Leonardo. (I haven't figured out where XST fits into all of this.) Only very recently have Xilinx offered an HDL simulation tool, and it's adequate for small designs. But if you're doing Real designs, you're probably using a Real synthesis tool and a Real simulator. -aArticle: 37122
> I bet this is a CRC-32 (or CRC-16) being done on an OC-192 at 10 Gbps. > That is where I saw this done before. The initial signal is bit serial, > but the payload is being processed in an FPGA at about 80 or so MHz in a > 128 bit wide word. Just a guess. > Exactly, OC-192 data that has to be processed 128-bit wide at 90 MHz. Actually, it is an ATM O.191 Test Cell processor, and I cannot afford pipelining at this point. Thanks, OvidiuArticle: 37123
Parts of original thread sniped... > That sounds great, but you missed the significance of my example below. > If a high volume user can make $10 more profit on brand R than on brand > P, he will not likely let the tools decide for him. Not with a volume of > 100,000 or more units. He will churn the design and crack the whip on > the engineers and get the design cranked out by hook or by crook. Let's > face it, a million here and a million there and pretty soon you are > counting real money :) > > The small volume customers don't count. The high volume customers will > ALWAYS pick parts on price, not based on what the engineer LIKES to use. > Rick, you are doing a great job of helping me with this debate, but I can only partially agree here. My experience has been that the only time tools enter into the equation is if they are so buggy and slow that they hinder development. I have abandoned FPGA companies based on this. Aside from that, tools do not factor into my selection process at all. I pick an FPGA based on performance and features first (product performance is more important than cost), familiarity with architecture second (this impacts development time, and therefore time to market), and price 3rd (once you have met the customer requirements, and hit the market window, then you want to increase profit margin). Our difference here is do the fact that I work in telecom on large systems with low volumes and 2 year design cycles. I suspect your product is much more commercial, much higher volume. > > > > And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200. > > Now you are showing that you have a lot to learn about the problem. I > first heard about 10 years ago that the FPGA companies sell you routing > and throw in the logic for FREE. The point is that way more than half > the chip is routing. WAY, FAR more than half the software is about the > ROUTING, not the CLB. I have written software in school to do logic > minimization and such. The real trick is to efficiently place and route > a part. This is not software you can write in your spare time. But I > would be happy to be proven wrong... > In the old days, FPGAs were much simpler. They consisted of a perfectly symmetrical array of identical logic blocks. That is not true anymore. The complexity of these devices has gone up exponentially. CLBs are only a fraction of the issue. Routing is becoming much more complex also. > > That may be important for the n*100MHz croud. Not everyone is playing > > up there. Just all the potential sound processing applications, for > > one, 48kHz anyone? > The only case where timing is not critical is if no one else is using your design...meaning it is just your personal toy. A few levels of logic, and a bad placement can break a 25MHz design in the fastest Virtex E. > > > > It certainly could be done, but the fact that it has not happened yet is > > > > a good indicator that it is harder than you seem to believe. > > > > So long non-availability of information makes it impossible, any "not > > happened" is 100% explained. Everything else remains speculation until > > that barrier falls. > > Only a small part of the process is not documented. That would be the > final step of generating the bit file. As has been pointed out here > before, one of the smaller tasks in designing this sort of software > would be reverse engineering the bit file format. If someone would sign > up to writing a complete, end to end development system, I would happily > spec the bit file for you! Just tell me which part. > Exactly, it is all there, you just have to dig a little. I would add that if you are not good enough to reverse engineer the bit file format, you are not good enough to do the PAR. However, I think Xilinx will give you that also. > > > > It’s actually even worse than that. Vendors are constantly > > > re-characterizing the parts and re-releasing updated timing models for > > > previously released parts. > > > > Again only relevant to the top speed crowd. > > You are talking about some 80 to 90% of the users, I would bet. > > > > > This brings up another point, in addition to the place and route > > > tools, you have to also provide the timing analysis tools. > > > > You know how many home/edu people overclock CPUs? Raise frequency until > > crash, than drop by 10% is the sort of algorithm. It is "good enough" > > for the target audience. > Again, timing is always important, unless you are not an engineer, or you are one those sorry engineers whose designs I have had to fix over and over again, both pre-release and post-release. > > > > It’s true that new families don’t get released often, but > > > when they do, you have to practically throw out your place and route > > > software because the architecture changes are too drastic. > > > > No different from the problems facing the gcc team when supporting > > code generators for new processors. They are presently at well over > > 20 architectures. And yes, some of the code generators suck. > > > > > doing hand placement for critical circuits. When I switched from > > > Virtex E to Virtex II not only was all of my work in Virtex E > > > worthless, it was a hindrance > > > > I doubt that "worthless". As ex-VirtexE-er you surely learned VirtexII > > faster than someone with no experience in placing and so also no > > knowledge what sort of pitfalls to look out for. Reuse of knowledge. > Believe me you don’t do multiple several hundred thousand gate FPGAs without understanding the concept of design reuse. Hard macros fix placement and routing so they are not compatible between families. CLBs, Slices, routing switch boxes, routing channels, CLB orientation, switch box orientation, IOBs, IOB switch boxes...are all different between VirtexE and Virtex II. In addition a few design strategies that helped me VirtexE actually hurt me in Virtex II. I couldnt make progress until I abandoned my old way of thinking. Was it as bad as switching to Altera, no, but it was bad.Article: 37124
This is a multi-part message in MIME format. --------------9E0088D62E0A5D14C6FFAF57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin, You might want to start with Nallatech (www.nallatech.com), since they wrote it! Dave Martin wrote: > Hi y'all, > I am looking for some information on developing hostsoftware for the > Ballynuey 2 board. Who can give me information? Can somebody recomend > sources in the Net? > > Best regards and thanx, > Martin --------------9E0088D62E0A5D14C6FFAF57 Content-Type: text/x-vcard; charset=us-ascii; name="dhawke.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Hawke Content-Disposition: attachment; filename="dhawke.vcf" begin:vcard n:;David Hawke tel;cell:(44) 778 875 5002 tel;fax:(44) 1291 621 541 tel;home:(44) 1291 621 655 tel;work:(44) 870 7350 517 x-mozilla-html:FALSE org:Xilinx UK;Northern European Sales version:2.1 email;internet:dhawke@xilinx.com title:Xilinx Field Applications Engineer adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom fn:David Hawke end:vcard --------------9E0088D62E0A5D14C6FFAF57--
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