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
This is a multi-part message in MIME format.
--------------CEFFA3346C3F66A14102E20A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > erika_uk@my-deja.com wrote:
> > > why virtex chips are rectangular and not square
Why not?
Seriously, is there an inherent advantage to the square
for tiling the design space or the wafer? ( I used to wonder
why the chips were not triangular or hexagonal.)
In my work, the rectangle is probably a better shape.
We do image processing, and since the parts still don't
have enough internal ram for a complete frame buffer,
we need to hang external banks of memory. If the processing
is viewed as a pipeline, where the FPGA resident stuff is
on top, and RAM storage is below:
in-->( per/pixel ) ( warping ) ( Feature )
( processing ) ( ) ( Extraction ) --> out
| / \ | / \
| | | |
\ / | \ / |
[ Frame Store 1] [ Frame Store 2 ]
(this is not a real application here, just to illustrate!)
The rectangle is a more natural ( form-fitting) container
for pipelined processes. Think of extending/enlarging the
pipeline...with a rectangle, I/O never gets too far from
the center(line), and I/O grows almost proportional to chip
area. With a square, I/O grows proportional only to square
root of chip area, and the center continually gets farther
from the I/O.
--------------CEFFA3346C3F66A14102E20A
Content-Type: text/x-vcard; charset=us-ascii;
name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
filename="jsmith.vcf"
begin:vcard
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard
--------------CEFFA3346C3F66A14102E20A--
Article: 25701"S. Ramirez" wrote: > > Rick, > Excellent idea to have an app note discussing the differences so that > Virtex savvy engineers can switch over quickly. There has been much > discussion of this on this newsgroup, and I also think it's worthy of an app > note in order to clarify most things that comes up. From what I understand, > here are the differences: > 1) temperature sensitive diodes missing on Spartan II > 2) core (CLB) transistors are 0.18u on Spartan II and 0.25u on > Virtex > 3) Spartan IIs come in limited (read: cheapest) packaging > 4) Spartan IIs are viperware as I write (no need for this > to be in the app note) > Are you listening, Xilinx? > -Simon Ramirez, Consultant > -Synchronous Design, Inc. > > Note: viperware (vïpêr·wär) n. something that will bite you if you design > it in and don't have the parts in hand. I like the viperware definition. But I am not sure you have the transistor size thing right. If I understand it correctly, the semiconductor features are the same as Virtex so that the voltage does not need to be lowered. But the metal pitch is smaller to reduce die size. Not that this is an issue with using the part. I would bet that there are some differences in the internal design of the part. They may be small, but it would be worth an app note to clearly document them *all*! -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 25702
Looking at the V2000E, (80 x 120 array), the amount of actual area taken up by the BlockRAMs is pretty mild, definatly not the 30% required to skew things. I suspect it is just how it is layed out, combined with some asymetries in the routing (the clock lines are vertically arranged). The resulting die is square. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 25703
-- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel Sweden "rickman" <spamgoeshere4@yahoo.com> wrote in message news:39C37C92.FB919779@yahoo.com... > Ulf Samuelsson wrote: > > The it follows logically that the context must be protected from > > another interrupt until the CPU has saved the current context. > > Yet they patent it. Ridiculous..... > > I would like to understand this. You can't patent a concept, how did > they reduce this to practice? If they have no hardware to save context, > what did they patent, the software to save context, disabling interrupts > or what? They have hardware resources for storing the context, but the processor does not no it automatically in a reentrant way. I.E: Pushing return address on a stack while incrementing the stackpointer. Instead the ARM stores the return address in an internal register which is common for all interrupts. It this was the only feature you have a problem. Guess what happens if you get two interrupts? The second interrupt overwrites the internal register. So they disable the interrupt. The core of the patent is that they disable "interrupts" while allowing other exceptions to happen. (Page Fault, Fast Interrupt (which uses a separate register) In my opinion , as long as you decide to do interrupt handling in S/W (which is prior art) and you want to have an exception register and MMU , the rest is obvious. Patent is 5,701,493 > > > In the light of the ARM threats to the "www.open-cores.com" activity it > > would be interesting to see how easy the ARM patents would fall down in > > court...." > > I have not heard of the conflict with ARM. Is there a web page > discussing it? I saw that www.open-cores.com got a threatening letter when they published their FPGA core implementation. -> www.altavist.com ? ARM has sued some U.S. company that cloned the core. They claim they do not violate the patents. > -- > > Rick 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 25704
<default@user.com> wrote in message news:39C2F1C4.6D15B439@user.com...
> Hello, a few months back I purchased an XS40-010XL+ from XESS
> corporation (http://www.xess.com.) The board is populated with an
> 8051uC and Xilinx XC4010XL ("10k system gates") FPGA, with a 128k X 8
> async SRAM chip. The board has its own VGA connector (you are
> responsible for implementing the display controller circuit), a PS/2
> keyboard connector, and standard connector headers giving access to all
> 84 I/O pins of the FPGA.
>
> Initially, the board was great, but I've since discovered 10k gates
> isn't a whole lot at all! So now I'm looking to move up to a larger
> FPGA board.
The Atmel STK40 has 2 x size (AT40K20) and is about $150-200.
Check at www.kanda-systems.com
It has a socket for an AVR (8515) and I think you may be able to put an 8051
there.
No external memory though.
If you wait for a month or two, you may be able to get your hands on the
brand new
FPSLIC demoboard.
I think it will be about the same price and has an AVR integrated w 36 kB of
SRAM.
--
Best regards,
ulf at atmel dot com
The contents of this message is intended to be my private opinion and
may or may not be shared by my employer Atmel Sweden
Article: 25705"S. Ramirez" wrote: > > Nial, snip >< > The real answer to your question, though, is to know the system that > you are working with in order to understand which signals are asynchronous, > which are protocol stabilized, which are skewed relative to your clock, and > which are synchronous. By knowing these parameters, you can take advantage > of the properties of these signals and design a synchronous system that is > reliable and fast. > -Simon Ramirez, Consultant > -Synchronous Design, Inc. Ah, I thought you had some magic technique for guaranteeing that you'd properly received a parallel word that was generated asynchronously with no other info. The only way of doing this I can think of would be to synchronise the input twice and only accept the input when the two values are identical. Nial.Article: 25706
Nial,
Unfortunately, there is no magic in this department. The synchronizing
of asynchronous signals takes clock cycles. Your method takes clock cycles,
as mine does.
The important thing is to recognize when we don't need to synchronize
asynchronous signals, which wastes time and resources.
-Simon Ramirez, Consultant
Synchronous Design, Inc.
> Ah,
>
> I thought you had some magic technique for guaranteeing that you'd
> properly
> received a parallel word that was generated asynchronously with no other
> info.
>
> The only way of doing this I can think of would be to synchronise the
> input
> twice and only accept the input when the two values are identical.
>
> Nial.
>
Article: 25707Hi, Me and some young engineers (students and non-students) like get more practice in digital design by doing a real design. We found that the bluetooth technology is a new technology and may have good future even in a home made systems. Could you please help us on the following questions: 1. Is there any avialable cores for this technology that we can learn from? 2. how large is this core going to be? 3. where can I find information about implementing it? 4. can a group of 3 young engineers work on it? 5. Is ther any possibility to implement a device at home with this core? 6. can we implement it on FPGA? 7. Does it worth the time or should we look for another technology to learn from? Thanks in advance Jamil Khatib Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25708
"K. Orthner" wrote: > > daniel.deconinck@sympatico.ca (Dan) wrote: > >The Spartan II has three sizes that come in the FG456 package: > <snip> > >The Spartan II has three sizes that come in the FG456 package: > <snip> > >Are the footprints interchangable ??? > > I asked this question of Xilinx support, and this was their answer: > > <open quote> > > Hi Kent, > There are actually some minor pinnout differences between the two: > > The Virtex DXN and DXP pins have been replaced w/ STARTUP and PWRDN pins in > the Spartan-II. > > Those are the only differences. > > <close quote> > > ** Note > 1. The pin is called "STATUS", not "STARTUP" in the data sheet > (DS001/03/03/2000). > > 2. /PWDN should be pulled high for normal operation. (So thereis a tiny > PCB change). If you do your board design for SpartanII you can put the matching virtex in its place, as long as you don't use the powerdown feature. Note that in virtex, pulling up that pin has no effect on the temp diode. I've got one customer with his early boards populated with XCV50-4 FG256s and the later ones with XC2S50-5 FG256s. We purposely did the board to accept both. So far the only differences we have noted are the temp diode, which we don't use. Also the spartanII is a little faster than the virtex-4, and the cost is considerably less. We're loading the same bitstream into both parts. > > -Kent -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25709
The best way I've found for general purpose parallel is create one extra signal with a toggle flip flop toggled by writing valid data to a register. On the second clock side, you have a wrtie pulse generator that is triggered when it senses a change in the level on the synchronized flag, and then that is used to transfer the data from the common holding register across the clock domain boundary. It can be pipelined a little, but you do generally still need 2 or 3 clocks on the recieving side per clock on the transmit side. You can put parallel circuits to maintain the data rate. Nial Stewart wrote: > > "S. Ramirez" wrote: > > > > Nial, > > snip >< > > > The real answer to your question, though, is to know the system that > > you are working with in order to understand which signals are asynchronous, > > which are protocol stabilized, which are skewed relative to your clock, and > > which are synchronous. By knowing these parameters, you can take advantage > > of the properties of these signals and design a synchronous system that is > > reliable and fast. > > -Simon Ramirez, Consultant > > -Synchronous Design, Inc. > > Ah, > > I thought you had some magic technique for guaranteeing that you'd > properly > received a parallel word that was generated asynchronously with no other > info. > > The only way of doing this I can think of would be to synchronise the > input > twice and only accept the input when the two values are identical. > > Nial. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25710
Are there any available? -- ============================ Mikhail Matusov Hardware Design Engineer Square Peg Communications Tel.: 1 (613) 271-0044 ext.231 Fax: 1 (613) 271-3007 http://www.squarepeg.caArticle: 25711
Sounds like you didn't pay any attention whatsoever as to the chip architecture, and you attempted to let the tools do everything without any tailoring for a cheaper, faster, better implementation. I routinely utilize upwards of 75% of the resources in Xilinx parts, with some just about reaching 100%. Many of these report equivalent gates numbers that are 120% or more of the nominal gate count, and virtually all are working at the upper end of the speed envelope. Xilinx also provides a saftety net through pin-out compatibility across chip sizes. See my specific comments below My experieince with Altera has been a bit different, as the Altera tools and architecture can make it quite difficult to reach the same level of performance or gate density as I can reach with the xilinx tools/architecture. Duane Hague wrote: > > As always Xilinx feature promises remain very attractive. However, I > have been "burnt" in the past on three projects where Xilinx was used > (one scorched-earth [total project failure] and two roasts[massive > time/cost over-runs]) in about the 1989 thru 1995 time-frames with XC200, > XC3000, & XC4000 chips. In fairness, the two "roasts" occurred when > management allowed a contractor to ignore my design specification > guidelines on the grounds that the contractor knew more then I did! My > basic Xilinx "Lessons Learned" were: > > 1. Chip Selection: Design estimate at 40% or less of chip capacity. Estimate the LUTs needed by knowing how you intend to map the design into the chip. This can be done from a detailed block diagram, and will get you to within +/- 10-15% easily. If you base your chip selection on the fictional "marketing gates", you are quite prone to error as you don't know how that figure was created or what structures were assumed > 2. Chip Speed: Assume design can only achieve 25% of "expected" > relative to chip ratings until proven otherwise. Again, you need to design to the FPGA architecture to get deterministic speeds. XC4000E-2s are/were capable of 66+ MHz with careful design and lots of pipelining Virtex -4 parts ae capable of 133 MHz, and upto 150 MHz with careful layout (for example the 16 bit 16 point 16 point FFT core I will be offering this fall runs in an XCV100-4 at up to 153MHz worst case in its current incarnation). The carry chains are generally the worst case paths. If you know the timing for those, you can determine what the part is capable of. > 3. Timing Simulator: If lucky, your implementated design will only be > 125% of the critical-path timing predicted by the Timing Simulator. Timing simulation is a can of worms. It is quite easy to miss testing of some critical paths based on a poor set of vectors. I advocate a flow using functional simulaton and static timing analysis. That way, you are guaranteed to surface any timing issues,provided you set up your constraints properly (which you must do any way for the router to do its job right) > 4. Never go to Production PCB before the prototype works, "bugfixes" > always seem to require IOB assignments to be "unlocked" before the design > will "re-compile". I've done over 200 FPGA designs, and have NEVER had a pin locking issue. You need to pick your pins intelligently (which can, beleive it or not be done before you do the detailed design), rather than letting the tool shot-gun them whereever it's random seed wants. With newer parts, there is considerably less sensitivity to pin placement than there was with the devices you mentioned, thanks to more plentiful routing resources. > > During this same time frame, I used Altera with no equivalent problems. Altera is better at handling the 'designer' who wants no control over the design, mostly because of its routing sturcture makes it less sensitive to placement of the logic in the FPGA. > I would summerize my experience as: > > **Xilinx promises more, but implementation can only achieve about 40% of > their promises. > > **Altera promises less, but implementation can achieve about 90% of their > promises. > My findings are that Xilinx lets the interested designer get considerably more performance and density than Altera. Again, I think the biggest problem you've had here is that you/your design team has not been designing to the FPGA architecture. Don't despair though, it is a common mistake with fPGAs. You need to do your design using the elements in the package rather than the other way around. If you assigned two people to build a widget out of legos, and gave one a bucket that contained only the basic 2x4 bricks, and the other a bucket that contained mostly those specialized parts, you'd end up with two very diffferent solutions. The same is true of the target technology. > I would be very interested to hear from current Xilinx End-Users > to see if the performance of the current generation of Xilinx > hardware/software is sufficiently improved to revise my lessons-learned > and/or make me willing to again step into a "Xilinx-swamp". > > TIA and Bye while looking forward to an interesting thread. > > PS: I actually designed as well as "monitored" contractors doing design, > so you can flame me as obsolete but hopefully not as ignorant. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 25712
Ray Andraka wrote: > > The best way I've found for general purpose parallel is create one extra signal > with a toggle flip flop toggled by writing valid data to a register. On the > second clock side, you have a wrtie pulse generator that is triggered when it > senses a change in the level on the synchronized flag, and then that is used to > transfer the data from the common holding register across the clock domain > boundary. It can be pipelined a little, but you do generally still need 2 or 3 > clocks on the recieving side per clock on the transmit side. You can put > parallel circuits to maintain the data rate. > Ray, I thought Simon was describing a situation where you have parallel data being generated asynchronously with no other timing or flag info, and thought he had some clever way of ensuring you'd captured the data correctly. I realise that each case needs to be examined and a properly 'safe' interface designed where required. Nial.Article: 25713
gk7eong wrote: > > Hi, yes I will appreciate it if you send the license.dat for ModelSim to me. > > About my school paying for the software? I think it is really fat hopes. The > way things work here is kind of different. =) > Fat hopes, or no fat hopes, Altera have a university program which donates software, and discounts hardware. See http://www.altera.com/html/univ/univ.html for details. Xilinx has a similar program, as do Aldec for their Active VHDL. I don't know about Model Tech. This is vastly superior to hacking disk ids. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 25714
I know it's difficult to predict the power requirements of Xilinx parts, but what's a safe 2.5V regulator to use for the internal supply of a XC2S150? The data sheet is most unhelpful in figuring this out. Since I plan to roll out this product in phases over the next year, I can't say what all my internal logic might be doing down the road, so I'm happy to over-spec the regulator to a reasonable degree. By the way, I'm getting quoted over 10 UK pounds ($14) for the config prom for this puppy (XC18V01S20C). Is there a cheaper way to do this? This prom increases the cost of using a Spartan II by 50%! -- Gary Watson gary2@nexsan.com Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 25715
Rick, OK. You are welcome. Let me see if I can help you with this. For 4K: 1* discharge to less than ~150 mv before staring up again as last configuration doesn't leak away completely and higher start up current results, 2* don't hold off clean-out/configuration with INIT as power on current remains until you let go (unless that is OK with you and your power supply), 3* keep power rising (or at least flat) through the POR region, 4* >2ms and <50ms power on ramp up time recommended (within the data sheet power on ramp up time and current capacity spec). 3&4 apply to Virtex, but not 1&2. Austin rickman wrote: > This is very useful information, thanks. > > I was not asking about the internal design of the two families of parts, > although that would be interesting. I was asking about the functional > difference. In your earlier posts you seem to indicate that there is a > large current draw under a wider range of conditions with the 4K series > than with the Virtex series. This is what I am trying to understand. > > > > > In 4K, holding INIT and preventing clean out does not make the device > > > > HOT -- it may be that the 4K device is in contention from the Vcc not > > > > going down below a few hundred millivolts, and then the Vcc returns, > > > > and the 4K device is in a partially configured state, and drawing > > > > current. So the device is already HOT and getting hotter, and INIT > > > > prevents the clean out. > > > > > > ********************* This bit right here > ******************************** > > > > Again, Virtex, Virtex E, Spartan2 do not have this behavior. The > ********************* This bit right here > ******************************** > > This is the statement I am asking you to clarify. Tell us about the > difference noted above. I do not understand exactly what is different > about the behaviour of the two families of devices. I am not asking you > to explain the internal proprietary design issues. > > I do not agree that there is such a significant difference in the > markets for the Virtex and the Spartan parts. I don't know how you are > targeting your parts, but I can tell you that the users only look at > capability (size) and price. I have no reason to care about what the > intended market for a family of parts is. So with the considerable > overlap in size of the two families (50, 100 and 200K gates), I expect > that I will be using either family depending on my specific needs for > expandability and size. > > So I don't agree that you can just say, that there will only be a small > number of people using the Virtex parts in designs with current limited > power supplies... except for the fact that you won't support them when > used that way. > > Austin Lesea wrote: > > > > Rick, > > > > The increased current draw occurs at about 0.6 to 0.8 Vdc in Virtex. > > > > It occurs at the POR trip point in 4K (see respective data sheets). > > > > The differences between the virtex and 4k power up cleanout circuits are not > > something I can discuss. > > > > While a supply is ramping up, it is driving the filter capacitors to the > > intended output voltage, and the supply is often current limited (can't supply > > any more current than it already is) while doing this, and hence the power ramp > > up time is constrained (i.e. not instant, by I=C*dV/dt). > > > > If I had 2000uF of capacitance, and it rises in 2 ms (typical of a really fast > > power ramp), that is 2.5V into 2,000uF in 2 ms, or I=2.5A. > > > > If I had 2000uF of capacitance, and the device suddenly requires 500 mA, you can > > see what the dV/dt would be. But, nothing is sudden, and the voltage and > > current interact. > > > > Even hot swap PCI has a rise time due to the resistance and inductance of the > > pcb traces to the bypass capacitors of usually no faster than 1 ms. > > > > You can think of Virtex as being a really big non-linear capacitor. It actually > > draws less current as the ramp slows down. This makes this a chicken and egg > > problem: how does the power ramp? Is the part connected? they affect one > > another. We test to make sure that if a power supply could supply no more than > > 500 mA (in Virtex C grade), the device would be ready for configuration and the > > vccint is at the power supply vccint (not sagging, or collapsed). The Virtex > > part may put a flat spot in the ramp up, but that is just fine (we just don't > > like to see it foldback, and dip which is the case with a power supply that is > > arranged for a foldback response -- datasheet recommends against this kind of > > behavior!). > > > > We have noted that if you could only supply 100 mA, the ramp might be really > > long (~100 ms), but the part would clean out, and start to configure. > > > > Virtex is not going to be characterized for low current startup, as most designs > > require more than 500 mA while operating (no market push to do this). > > > > Spartan2 on the other hand will be considered (is now being characterized) for > > lower current startup as the markets are different for the two parts (there is a > > push to do this). > > > > I hope this answers the first question, and I hope you understand that I can not > > discuss the internal circuit design and operation here required to answer you > > second question, > > -- > > Rick 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 25716
I know, I know... The APP158: http://www.support.xilinx.com/xapp/xapp158.pdf may seem like over kill, and maybe it is. But I don't know what YOU are doing, and I don't know what YOUR clock speed is, and I don't know what YOUR IO's are switching, and I don't know if YOU have read a good signal integrity book or any of the app notes, and so on.... so we were ultra conservative! I have seen some spectacular bypass jobs that didn't work because of SSO's and ground bounce (you just can't have every single pin switch 24 mA simultaneously -- read app133). I have also seen some rather poor (in my opinion) bypassing layouts that worked fine because they measured it afterwards and pulled off parts until their noise margin was just under their specification (not my style -- but it works). Anyone interested in APP158 and how to bypass big fast ultra deep sub micron chips is encouraged to email me directly at austin@xilinx.com with their comments. I know I may be opening Pandora's box, but the intent is to understand the real issues, and make it easier to use, so I am ready and willing. We will be re-releasing a re-written and improved app158 soon. Austin "S. Ramirez" wrote: > Dan, > Ignore the previous post. You are using a Virtex XCV600. Xilinx has > an app note that tells you how much decoupling to use. I do not have it in > front of me, but I know that it requires big capacitors, and I think these > big capacitors are overkill. It does require more caps that what you told > us about; however, at the company I work at we collectively decided that > they are not enough. We think that 0.1uF or 0.01uF caps are required for > every pin. This assumes ground and power planes. > Your problem, though, may involve something other than power quality. > I would involve the Xilinx FAE on this one. > -Simon Ramirez, Consultant > Synchronous Design, Inc. > > "Dan" <daniel.deconinck@sympatico.ca> wrote in message > news:8miw5.261590$1h3.5258160@news20.bellglobal.com... > > The decoupling is four .1uF caps. One at each corner of a QP240. I plan to > > make a new PCB with a .1uF at each power pin. > > > > When the device is drawing minimum power, shouldn't four decoupling caps > be > > enough ? > > > > Dan > > > > > > > > > >Article: 25717
Hi - On Mon, 18 Sep 2000 14:15:47 GMT, Ray Andraka <ray@andraka.com> wrote: <stuff deleted> >> 4. Never go to Production PCB before the prototype works, "bugfixes" >> always seem to require IOB assignments to be "unlocked" before the design >> will "re-compile". > >I've done over 200 FPGA designs, and have NEVER had a pin locking issue. You >need to pick your pins intelligently (which can, beleive it or not be done >before you do the detailed design), rather than letting the tool shot-gun them >whereever it's random seed wants. With newer parts, there is considerably less >sensitivity to pin placement than there was with the devices you mentioned, >thanks to more plentiful routing resources. I agree with everything Ray said in his post (except for Altera-specific stuff, of which I have no direct knowledge), but I think that the point he makes above is particularly important because the conventional wisdom is so terrible. In particular, designers seem to take two bad approaches to pin assignment: 1) Arbitrarily assign the I/O pins. This leads to disaster. 2) After trying (1), the designer seeks advice from the FPGA vendor, who usually says, "Never lock down the pins yourself; let the place and route tool do that." This usually leads to disaster, too, only getting there takes a bit longer. The first route may be OK, but as soon as you make a significant design change, oh, boy... The best approach, as Ray suggests, is to pick the pinouts intelligently based on the design. In particular: 1) Figure out how the data/control is going to flow through the device, and assign the pins accordingly. 2) Try to isolate groups of mutually asynchronous signals to avoid noise problems. I do pin assignments on Xilinx devices before place and route, and haven't run into a pinout-related problem yet. Take care, Bob PerlmanArticle: 25718
Altera has just started selling one for $995 with a apex200-1. Go to https://websupport.altera.com/estore/excalibur.asp On Mon, 18 Sep 2000 14:12:22 GMT, "Mikhail Matusov" <matusov@ANNTIsquarepegSPPAMM.ca> wrote: >Are there any available?Article: 25719
Mark Harvey wrote: > > > > > --Yes and no. That somebody is the Xilinx FAE, but we're not talking > about > > him, we're talking about disties. A disty does not need to be involved, > > i.e., register a design, every time. Just ask the direct accounts. > > > > Agreed, but I think this discussion was started by someone who is not a > direct account...or have I misunderstood? Yup -- indirect, and low-volume, too. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25720
This is a more general legal question - but lets say you're given an NDA at an interview, and you write "not signed" as illegibly as possible on the signature line and hand it back as if you signed it. What legal ramifications does this have? TZArticle: 25721
"Michael Rhotert" <mrhotert@t-online.de> wrote in message news:8q2pmd$hcq$11$1@news.t-online.com... > > We are considering moving the fanout functionality inside the > > Virtex, to save on external parts count. The issue I have a > > question about is the following. When one sets up the constraints > > for the P&R tool (Alliance in this case), is there a way of doing > > this so that one can specify the **maximum skew** between any 2 > > clock outputs? In other words, is it possible to fan out a clock > > inside the Virtex for external use and simultaneously approximate > > (dare I say guarantee?) the low skew among all clock outputs that > > is characteristic of an external buffer? > > Maybe you can use the 2x output of the DLL, divide it by 2 in a CLB, and > feed the divided signal to several IOBs with output registers, clocked by > the 2x-clock. > Using this approach, you get multiple low skew signals with the wanted > frequency. > > Michael This is the best approach but the *huge* snag (depending on what you want to do) is that you can't use external feedback to get the external clocks to have zero skew compared to the DLL input clock. The external FB clock must be 2x if you use the DLL 2x output. Read XAPP132 (Virtex DLL app note) *very* carefully. There are loads of rules and a new rule appears every few months. There is an article on how to get low skew with non-clocked outputs which I can't lay my hands on right now. I got it from the Xilinx web site and covers the use of MAXSKEW (Xilinx P&R) and placement out outputs for low skew. Place the outputs near each other along the top or bottom of the device (ie by the long lines) and constrain the skew to whatever you need. The article quoted an example result of 56ps with a constraint of 100ps (I think), though don't bank on getting near this figure. Alun CamdigitalArticle: 25722
I have a letter from Altera that came with their News and Views newsletter. The APEX EP20K1500E has an incredible 416 Kbytes of RAM, far more than the largest Virtex. The letter is from Cliff Tong, Vice President, Corporate Marketing. Altera have now leapfrogged the gate-inflation war with what is obviously a new method of counting bytes. I guess this is 'system' bytes which are almost 8 times the number of actual RAM bytes implemented (416*8/432 = 7.70 according to Altera's web site). Beat that Xilinx. Alun CamdigitalArticle: 25723
I need help in locating multiple Program Marketing Managers for FPGA's. Manugacturing, Vendor or User experience is valid. Other experience such as ASICS is valid and will be considered. Please email resume or inquire to Bob Dosier at jka.rd@icnt.net. Thank you. Bob Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25724
Dear System-Level Chip advocate: If System-Level ICs are important to you, so is this meeting. The annual VSI Alliance Member Meeting in the US will be held in Silicon Valley on October 25. Admission is free to members and non-members The keynote speech will be given by Dr. Wally Rhines, president of Mentor Graphics. There will be important and useful presentations from several major companies on how they are handling the SoC design and development challenges and how they are using VSIA specifications and standards in that process. For more information and the registration form, check the VSIA website at www.vsi.org. · The meeting is at the Santa Clara Marriott Hotel, from 9 till 5. · Continental breakfast and registration from 7:30am. · Lunch served and a cocktail reception at 5pm. · There will be a VSIA orientation meeting at 8am for those not familiar with the Alliance, what all it's all about and how it works. Hope to see you there: Stan Baker VSI Alliance The VSI Alliance is a non-profit consortium of over 160 companies worldwide.
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