Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hello, I am developing a partial reconfigurable system and one of the requirements of my system is that one needs to read and update the contents of the BRAM using the ICAP port. My question is that if I configure Xilinx BRAM for a data width greater than 1, say 8 then will all the 8 bits corresponding to the particular byte be in the same BRAM configuration frame? or will they be distributed among multiple frames? If so are there any equations that indicate how the 8 bits within the required byte are distributed in the configuration bit stream. I read XAPP 151 but that does not give any information in this regard. Though it provides equations for finding the location of a particular bit based on the bit index there is no mention about the bit indices for the 8 bits within the byte. Thanks HarishArticle: 77351
hi I need to start working on a xilinx virtex II pro board in a few days. I am new to fpgas. Could someone please suggest some manuals and links to get started. Regards AkshayArticle: 77352
Joel,
The second process is a combinatorial process. All signals must be
assigned a value for all conditions, or a latch is generated, which presumes
that the value of the last condition should be kept in the absence of a new
assignment.
e.g.
when Request_Bus =>
if( data_valid = '1') then
req <= '1';
Next_State <= Write_Memory;
else
-- will generate latch for req because if data_valid = '0', there is no
value assigned inferring that it should keep the last value( i.e. a latch)
Next_State <= Request_Bus;
end if;
Some people, including myself will default statements before the case
statement to abbreviate the number of lines used.
-- default statements
req <= '0';
case Current_State is
-- etc.
-- Hope this helps
Newman
"Weddick" <weddick@comcast.net> wrote in message
news:qdWdnRLZ1KoryEbcRVn-oQ@comcast.com...
>I am kind of new to FPGA and VHDL. I took the intro to VHDL class at
>Xilinx and the instructor keep saying that latches should be avoided.
>Unfortunatly either I was a sleep or he didn't explain very well on what
>causes a latch to be generated in a design. Attached is part of a design I
>have been playing with. As can be expected it generates latches and the
>Synthesis tool generates a lot of warnings. If some one could look over
>the code and let me know were I have gone wrong?
>
> Thanks,
> Joel
>
>
Article: 77353Hi, When I try to install SysGen6.2, the following error message appeared. >> setup Welcome to the Xilinx System Generator Version 6.2 Installer. ??? Error: ")" expected, "identifier" found. Did anyone have this experience before? or any idea to solve this problem? Many thanks, Terrence P.S. Matlab Environment ------------------------------------------------------------------------------------- MATLAB Version 6.5.0.180913a (R13) MATLAB License Number: 60557 Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 2) Java VM Version: Java 1.3.1_01 with Sun Microsystems Inc. Java HotSpot(TM) Client VM ------------------------------------------------------------------------------------- MATLAB Version 6.5 (R13) Simulink Version 5.0 (R13)Article: 77354
Daniel wrote: > Hi, > > We are doing a large V2P design with some blocks requiring very tight timings. Up to now we run the design through par and then used the ngc file to guide for the critical routed nets and placed components. > > This is not really convienient since it doesnt allow us to separate the different blocks easily. > > I wonder now which of the following flows might be the best solution for us: hardmacro, incremental or modular design. > > We need to have fixed routings and placement. Is this possible with all flows? > > Are those flows stable for large design (V2P70 which will get at least 60-70% of usage) > > Thanks for your help > > Best regards Daniel Rather than using a hard macro, I suggest combining the use of an RPM macro with the Directed Routing feature. This gives you all of the control of the hard macro with none of the drawbacks. IMO, hard macros should now only be used to force configurations that MAP won't accept. That and for Partial Reconfig bus macros I suppose. BretArticle: 77355
Thanks for the explaination. I seem to recall something about this from my class. I guess I should have taken better notes. Joel "newman5382" <newman5382@yahoo.com> wrote in message news:obKCd.179982$8G4.153844@tornado.tampabay.rr.com... > Joel, > The second process is a combinatorial process. All signals must be > assigned a value for all conditions, or a latch is generated, which > presumes that the value of the last condition should be kept in the > absence of a new assignment. > > e.g. > when Request_Bus => > if( data_valid = '1') then > req <= '1'; > Next_State <= Write_Memory; > else > -- will generate latch for req because if data_valid = '0', there is no > value assigned inferring that it should keep the last value( i.e. a latch) > Next_State <= Request_Bus; > end if; > > Some people, including myself will default statements before the case > statement to abbreviate the number of lines used. > > -- default statements > req <= '0'; > case Current_State is > -- etc. > > > -- Hope this helps > > Newman > > > "Weddick" <weddick@comcast.net> wrote in message > news:qdWdnRLZ1KoryEbcRVn-oQ@comcast.com... >>I am kind of new to FPGA and VHDL. I took the intro to VHDL class at >>Xilinx and the instructor keep saying that latches should be avoided. >>Unfortunatly either I was a sleep or he didn't explain very well on what >>causes a latch to be generated in a design. Attached is part of a design >>I have been playing with. As can be expected it generates latches and the >>Synthesis tool generates a lot of warnings. If some one could look over >>the code and let me know were I have gone wrong? >> >> Thanks, >> Joel >> >> > >Article: 77356
I wrote: > I have a cost-sensitive application for which the LM317S looks to be > much less expensive than using fixed-output LDO regulators, e.g., > $0.58 for the LM317S vs. $4.45 for an LP3881ES-1.2 for Vccint. "alexi" wrote: > First, you seem to be comparing LP3881 in qty.1 with LM317 in Qty.100. You're right, I goofed. I meant to use the Digikey qty. 100 price of $2.581 rather than the qty. 1 price. Still, that's a big difference. > Alternatively, you can take a look at Sharp regulators PQ012FZ series. > Digi-Key sells them for $.66 in qty.100 Thanks for the tip. That's definitely an attractive price. I was hoping for a single stage 5V to 1.2V regulator, but the max Vin of the Sharp is 3.7V. Still, I can afford to use a higher current rating on my 3.3V regulator and do it in two stages. EricArticle: 77357
"Brian Davis" <brimdavis@aol.com> writes: > - The "A" variants of the LM317 have better reference specs > ( 1.262 V max at Tj = 25C, 1.270 V over -40 to +125 C ) > - also, see the very latest S3 errata for brand new VCCINT > ramp rate and supply sequencing requirements Thanks for bringing those facts to my attention. Looks like the LM317A may be viable. Though the Sharp regulators Alexi mentioned are quite attractive too. I like the SC-63 package dimensions better than the SOT263, though either will be OK for this design. > The UPS package was delivered to you on April 23. > Some 8+ months later, I'm still waiting for payment or > a response to any of my subsequent e-mails. My apologies, I haven't seen the email, though I did receive the package. I will find your postal address in my email records and mail you the money tomorrow.Article: 77358
<rjs@friend.ly.net> schrieb im Newsbeitrag news:1104607525.385297.51090@z14g2000cwz.googlegroups.com... > Hello, > > I have a need for something faster than a microcontroller and decided > on using logic IC's to do it. Well I don't need to say why I next > decided to use programable logic instead. I've have never used a PLD > before. After visting Xilinx web site I ordered the CPLD Design Kit to > get started. > > Lets see know, all I have to do is program my logic schematic into one > of these CPLD devices! Wow, after that I might find the state machine > entry of intrest. And... after I'm an advanced user I could learn a new > language called VHDL. Now wait a minute... How come the Xilinx tutorial > starts with the advanced VHDL first? OK, I'll skip over to the next > tutorial "State Machines". Well, I don't need that yet. OK, the next > tutorial uses schematic entry. Oh no, this tutorial requires the > previous tutorials. It seems to me that Xilinx has it all backwards on > how one starts using programable logic for the first time. > > Next I bought a book on ebay "Digital Electronics - Using the Xilinx > XC95108 CPLD" copyright 2001. This is perfect!! Its first CPLD example > uses a 3 input AND gate and a 3 input OR gate. The problem is that it > uses Xilinx foundation 1.5 which is nothing like ISE 6.3i that I have. > So my question is where can I get Xilinx foundation 1.5 ??? > Hello, 1.) on our pages You will find some Xilinx CPLD related example designs, see "eMOD-d" (CPLD) and "eLABbase" (FPGA), including schematics and VHDL code, starting with AND and OR, FlipFlop, switch debouncing, ending up in building a 24h RTC with a 9572xl. Sources are free for none commercial use. http://www.seng.de/eLab_applications_.html 2.) On our dlk / eLAB - link database You will find links to CPLD / FPGA / VHDL / IP-cores / tools / 8051 / AVR ..... topics http://www.seng.de/dlk_database.html with best regards, Peter Seng ############################# SENG digitale Systeme GmbH Im Bruckwasen 35 D 73037 Goeppingen Germany tel +49 7161 75245 fax +49 7161 72965 eMail p.seng@seng.de net http://www.seng.de #############################Article: 77359
"Ulf Samuelsson" <ulf@atmel.nospam.com> schrieb im Newsbeitrag news:340jn7F3afkaeU2@individual.net... > > why JTAG??? For configuring CCLK, DATA and Done are all You need. > > - no special knowledge about JTAG (just a Xilinx/Altera/Xxx data sheet) > > - no special knowledge about USB and OS (comes from FTDI) > > > > If debug or CPLD´s come into discussion things may be different.... > > > > You do not need to run a special programming application with the ARM based > solution. > From your application that generates a bitstream, you define the location > of the > saved file to be on the flash disk. > Lose one step in the development process = faster turnaround time. > > The FTDI solution is faster and easier to implement, but this is much > nicer... > I think that the configuration of the FPGA will be much faster as well. > > > > -- > Best Regards, > Ulf Samuelsson ulf@a-t-m-e-l.com > This is a personal view which may or may not be > share by my Employer Atmel Nordic AB > > Hello, the ARM based "solution" may be very interesting and demanding but original question (thats how I understood) was for a (simple) solution, just for configuring an FPGA. NOT FOR HAVING THE BEST AND POWERFUL AND GENERAL "POWERUSER-SOLUTION" FOR JTAG TOPICS. But maybe i´m wrong... with best regards, Peter Seng ############################# SENG digitale Systeme GmbH Im Bruckwasen 35 D 73037 Goeppingen Germany tel +49 7161 75245 fax +49 7161 72965 eMail p.seng@seng.de net http://www.seng.de #############################Article: 77360
Hi Akshay, Xilinx web-site is the best resource : There are two manuals you will have to refer at the minumum : 1) Virtex II pro data sheet http://direct.xilinx.com/bvdocs/publications/ds083.pdf 2) ISE tool documentation for place and route Of course this is just to get your feet wet - FPGAs are beasts and designing with them is an art (not to scare you though). Regards, PurveshArticle: 77361
On 4 Jan 2005 10:25:48 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >I find it amazing and disturbing that people have the audacity to ask >for help and favors from this newsgroup, without giving their name, >their affiliation, or at least the reason for their question. So do I. However, it's also fair to point out that courtesy and other nuances are hard to do at all, and yet harder to do well, when you're working in a second language as so many posters are. Perhaps anonymity provides a way to side-step that problem, and perhaps we should instead measure courtesy by the appropriateness and inherent interest of the problems offered. It's also worth remembering that conventions of courtesy and urbanity are fairly uniform across most of Europe, and at least mutually recognisable across the Atlantic, whereas I suspect things are markedly different on the Pacific rim. Peter is a European who's been long-term resident in the USA and can be courteous in at least three languages; I'm an old-fashioned Brit whose attempts at courtesy often are taken for pomposity in the USA, and whose civility stretches to only one and a half languages. I'm in a poor position to complain. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 77362
@Bret Thanks for the suggestion. Didnt know that its possible to fix the routing also within RPM macros. Are RPM macros usefull for design modules as large as my one (376 CLB Slices (752 FlipFlops, 260FG's), 8BRAMs and 1GlobalBuffer) or does this lead to problems with performance or even unstable workflows? How fix is the routing "fixed" with directed routing in the later PAR of the whole design? Is it possible that the router changes anything? Best regards DanielArticle: 77363
On 4 Jan 2005 20:30:31 -0800, "Harish" <harish.vutukuru@gmail.com> wrote: >Hello, > >I am developing a partial reconfigurable system and one of the >requirements of my system is that one needs to read and update the >contents of the BRAM using the ICAP port. My question is that if I >configure Xilinx BRAM for a data width greater than 1, say 8 then will >all the 8 bits corresponding to the particular byte be in the same BRAM >configuration frame? or will they be distributed among multiple frames? >If so are there any equations that indicate how the 8 bits within the >required byte are distributed in the configuration bit stream. > >I read XAPP 151 but that does not give any information in this regard. >Though it provides equations for finding the location of a particular >bit based on the bit index there is no mention about the bit indices >for the 8 bits within the byte. > >Thanks >Harish Why not just generate 2 streams with different initialised content and compare them ?Article: 77364
> Are newsgroups fostering the death of civility ? I am not going to comment about newsgroups in general, but I know for sure what 'comp.arch.fpga' is fostering. I have been reading the group for a few years, and I have learnt a lot of things that would have been impossible to learn without the group. I am no longer a beginner, but I am far away from the point I can contribute with anything useful. Actually I am afraid I will never reach that point, the group is always way ahead. Politeness, civility should be of concern to all of us, not related to this group I think, but to this world we are building (or we are allowing others to build) Beleive me, I have teenager children :) The previous comments about the first-second-etc language and social conventions are well to the point. Josep DuranArticle: 77365
Thanks for the suggestions ! I am using a spartan 2E so i guess that DCM is not an option for me. Currently, which also works, I am using an area constraint to put the logic closer to one pin than the other. In this way everything is "schedules" as i want to. I was hoping for a similiar and cleaner result by using some kind of timing constraint. I imagine that this constraint would accept a minimum of delay compared to another signal. If this delay after synthesis is not met i would expect that aditional logic is place between pad and signal to delay the logic. Thanks all for your input ! With regards, Michel Bieleveld.Article: 77366
Hello everyone. I have been having some trouble with iMPACT 5.1i and I was hoping that someone would recognize the problem and be kind enough to help me. I am using a 3rd party Parallel Cable III from Digilent, and I cannot get the iMPACT software to use the Parallel port. When I invoke "Cable Setup..." I get the messages: Connecting to cable (Parallel Port - LPT1). Checking cable driver. Driver Version = 212. LPT port is already in use. Cable connection failed. // *** BATCH CMD : setCable -port LPT0 // *** BATCH CMD : setMode -bs => The parallel port is set up for Bidirectional mode in the BIOS. The system is a laptop running Windows 2000. The Xilinx software fileset.txt and install.log appear to be OK, and I do have windrvr.sys and xpc4drvr.sys present in the WINNT/system32/drivers folder. I know this has to be something fairly basic, but after a lot of experimenting I just can't seem to figure out what is wrong. I have searched the web and the Xilinx web site but there doesn't seem to be anything that resembles the problem I am seeing. Has anyone seen this before? I tried disabling the LPT port in the device manager, but that didn't seem to make any difference. Thanks in advance for any replies. I read this group regularly and find it to be one of the most interesting and informative groups on Usenet. Ewan D. Milne Egenera, Inc. milne@egenera.comArticle: 77367
Following up on this old thread: http://groups-beta.google.com/group/comp.arch.fpga/msg/b7abbb85cd4b93ba Good News of the day: Xilinx has now published SSO guidelines for the leaded S3 packages! Bad News of the day: Xilinx has now published SSO guidelines for the leaded S3 packages! Summary ( see DS099-3, v1.5, page 24 ): - high speed output standards are severely restricted for PQ/TQ/VQ parts - in a PQ208, typical LVCMOS outputs are limited to 2-4 pins per bank in SLOW mode, FAST mode is even more limited. ( e.g. LVCMOS33/SLOW/12 mA limit of 4 per bank in PQ208 ) LVDS SSO weirdness: The strangely low SSO limitations on those spiffy current-mode LVDS output drivers are still there for all Spartan-3 packages, including the BGA parts. Answer Record 19972 used to say: "Because the Spartan-3 LVDS driver is very balanced, its switching causes a negligible amount of transient current. As a result, SSOs are not a problem." Now it says: "Because the Spartan-3 LVDS driver is very balanced, its switching causes a negligible amount of transient current. As a result, SSOs are typically not a problem in the smaller device/package combinations. However, SSO does become a concern with the larger device/package combinations so please be aware of the SSO guidelines for Spartan-3." But oddly, the Virtex2 LVDS SSO Answer Record #13572 still says LVDS SSO's are "not a problem" ... so, has the LVDS output driver design changed drastically from V2 to S3 ? BrianArticle: 77368
Ewan,
it seems that you are forcing (in batch mode) to run to LPT0 and the
cable is attached to LPT1
// *** BATCH CMD : setCable -port LPT0
Aurash
Ewan D. Milne wrote:
>Hello everyone.
>
>I have been having some trouble with iMPACT 5.1i and I was hoping
>that someone would recognize the problem and be kind enough to help me.
>
>I am using a 3rd party Parallel Cable III from Digilent, and I cannot
>get the iMPACT software to use the Parallel port. When I invoke "Cable
>Setup..." I get the messages:
>
>Connecting to cable (Parallel Port - LPT1).
>Checking cable driver.
>Driver Version = 212.
>LPT port is already in use.
>Cable connection failed.
>// *** BATCH CMD : setCable -port LPT0
>// *** BATCH CMD : setMode -bs
>=>
>
>The parallel port is set up for Bidirectional mode in the BIOS.
>The system is a laptop running Windows 2000. The Xilinx software
>fileset.txt and install.log appear to be OK, and I do have windrvr.sys
>and xpc4drvr.sys present in the WINNT/system32/drivers
>folder.
>
>I know this has to be something fairly basic, but after a lot of
>experimenting I just can't seem to figure out what is wrong. I have
>searched the web and the Xilinx web site but there doesn't seem to be
>anything that resembles the problem I am seeing.
>
>Has anyone seen this before? I tried disabling the LPT port in the
>device manager, but that didn't seem to make any difference.
>
>Thanks in advance for any replies. I read this group regularly and
>find it to be one of the most interesting and informative groups on
>Usenet.
>
>Ewan D. Milne
>Egenera, Inc.
>milne@egenera.com
>
>
>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 77369Peter Alfke wrote: > Many of us love to help and explain, but I do not like to be taken > advantage of in a totally impersonal way... > Are newsgroups fostering the death of civility ? > Peter Alfke Hi Peter, I agree with all that has been posted here. I find that society as a whole is traversing down this path; not just the newsgroups. This feeling of entitlement these days, where everyone should, "help me because I deserve it" is extremely annoying. Demanding help and requesting it are two very different animals. That being said, I must say that I can't tell you how much I appreciate your level of professionalism and willingness to help. On many occasions, your thorough answers to other posters (be it ignorant / insolent / or otherwise) have answered my questions as well. Many thanks from an engineer out in here in New Hampshire USA. Warmest regards, Ian. (yes, my real name)Article: 77370
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag news:qh3bxh6ega.fsf@ruckus.brouhaha.com... > Is there any reason why using an LM317S adjustable linear regulator with > 1% resistors wouldn't be satisfactory for the Spartan 3 power supplies, > particularly Vccint and Vccaux? > > I have a cost-sensitive application for which the LM317S looks to be > much less expensive than using fixed-output LDO regulators, e.g., > $0.58 for the LM317S vs. $4.45 for an LP3881ES-1.2 for Vccint. I don't like LDO's and try to avoid them for several reasons: price, performance, availability, standardization. My approach is to build a "custom" LDO with a OPAMP (TLC272), a SI2302 (Power Fet), voltage divider to set the output to the desired voltage, a resistor and capacitor for compensation. A reference voltage is already there (from a TPS5120 DC/DC controller). It's very cheap, but needs a few more components. It gives good transient response for the 1.2V Spartan supply, and good analog performance for the 2.5V supply to the DCM's in my case. But going with a LM317 should be good also, not demanding so much "analog" design. Raymund HofmannArticle: 77371
For what it's worth, this group seems much more polite (and informative) than many I read. I'm not a big fan of public rudeness, but there is something important about the empowerment of anonymity that allows people to say things they might not otherwise say. I have been on the receiving end of rude posts, but at least I don't have to guess how they feel! I'm reminded of the bar car on a train trip to Mardi Gras. There was a mask that folks passed around and whoever put it on did a show for the car. Some of the quietest folks had pretty wild acts! Without the mask, how would we see the show? Chris Peter Alfke wrote: > I find it amazing and disturbing that people have the audacity to ask > for help and favors from this newsgroup, without giving their name, > their affiliation, or at least the reason for their question. > > How would you react if somebody you had never seen before just barged > into your home or office and asked for a favor, without introducing > himself or explaining the reason for his question ? > > Many of us love to help and explain, but I do not like to be taken > advantage of in a totally impersonal way... > Are newsgroups fostering the death of civility ? > Peter AlfkeArticle: 77372
Hi. I'm looking for information on Xilinx's original HardWired family, which were litteral replacements for FPGAs, rather than gate arrays. As I understand it, they were configured with a single via layer, and had timing matched paths. If anyone has old app-notes, data sheets, or other relavent info on the original family of parts, please e-mail me a copy. Thanks, Bill Cox bill@viasic.comArticle: 77373
Brian, A few hopefully useful comments below, Austin Brian Davis wrote: > Following up on this old thread: > http://groups-beta.google.com/group/comp.arch.fpga/msg/b7abbb85cd4b93ba > > Good News of the day: > Xilinx has now published SSO guidelines for the leaded S3 packages! Yes, long in coming, it is good to have SSO guidelines. More below. > > Bad News of the day: > Xilinx has now published SSO guidelines for the leaded S3 packages! The guidelines let a designer know when too many IOs switching will either cause an adjacent output signal to falsely assume the wrong state (bounced to a 1, or to a 0 when it was a 0 or a 1), or when an adjacent input that is quiet is bounced into the wrong state. In almost all cases, the LVCMOS input levels for a 1.5V LVCMOS input is the worst and most sensitive input, as we must assume that you may have a 3.3V IO bank adjacent to a 1.5V bank, and may have the worst case combination of victims and aggressors. You may need to have even more margin, or you may not need the margin suggested, depending on the IO standards and voltages chosen. SSOs also affect (cause) the jitter on data and clock signals, so any design with little or no margin becomes incredibly sensitive to SSOs. Jitter, is the end result of all sins of poor, or no SI engineering. We also have to assume some kind of series inductance for the customer pcb for ground and power pins. If it is less, the performance is better. If it is more, the performance is worse. I believe we assume 500 pH for each power and ground (1uH total in the power and ground circuit series L from the PCB). If the package is 300 pH, then the contribution from the package is not much. But, if the package is another 1 uH, then the ground bounce almost doubles! Hence the reason why these packages are not well suited to anything that creates di/dt (see next comment in line). Slow attribute IOs, LVDS, low current IOs, are all much friendlier (to the package and its environment). > > Summary ( see DS099-3, v1.5, page 24 ): > > - high speed output standards are severely restricted for PQ/TQ/VQ > parts The added package inductance for these packages leads to this obvious result. As Lpkg got larger, V = -Ltotal * di/dt got larger, too. > > - in a PQ208, typical LVCMOS outputs are limited to 2-4 pins per > bank in SLOW mode, FAST mode is even more limited. > ( e.g. LVCMOS33/SLOW/12 mA limit of 4 per bank in PQ208 ) > > LVDS SSO weirdness: > > The strangely low SSO limitations on those spiffy current-mode > LVDS output drivers are still there for all Spartan-3 packages, > including the BGA parts. > > Answer Record 19972 used to say: > > "Because the Spartan-3 LVDS driver is very balanced, its switching > causes a negligible amount of transient current. As a result, SSOs > are not a problem." This is only true if the driver is driving a true differential load (NOT two separate 50 ohm signal leads!!!). As most differential trace runs are not perfectly balanced, and not perfectly differential (they have coupling to ground), we also have to start assuming standard pcb trace routes are used.... > > Now it says: > > "Because the Spartan-3 LVDS driver is very balanced, its switching > causes a negligible amount of transient current. As a result, SSOs > are typically not a problem in the smaller device/package combinations. > However, SSO does become a concern with the larger device/package > combinations so please be aware of the SSO guidelines for Spartan-3." Sort of like saying: "we are ususally OK, but some folks have had a less wonderful experience, and maybe if you have a lot of them, you should simulate the SI." Not much different that my usual stance: simulate, simulate, simulate. > > But oddly, the Virtex2 LVDS SSO Answer Record #13572 still says > LVDS SSO's are "not a problem" ... so, has the LVDS output driver > design changed drastically from V2 to S3 ? No, the S3 differential IOs are quite the same as V2 and V2P. Answer records are not automatically corrected when things change. They get reviewed on a cyclic basis (they in effect 'time out' and have to be reviewed). Even when an answer record 'times out' it is not always caught as being out of date. I will forward this to the group involved. There are over 10,000 current answers .... If you have a question about an answer record, please send it to the hotline (or post it here). They are quite excellent at keeping track of a massive amount of information, and also keeping it up to date. Thanks! > > Brian >Article: 77374
http://www.google.com/search?hl=en&q=hardwire+xilinx&btnG=Google+Search Yielded a wealth of information. We had three different versions of hardwire (to my recollection): the first was simple via (?) layer to connect memory cells to 1's and 0's which had no area advantage over a regular FPGA, the second was a relayout with less area still programmed by a single layer, and the last version was more like a standard cell ASIC flow. All had incredible problems, as they were no different than an ASIC! If a mistake was made by the customer, it had to be changed, and fab'd again. If the timing was different (which it always was), the customer would either have to make changes, or the part would have to get changed yet once again. Since the hardwire parts ran in separate wafer lots, they had all the problems of ASICs: process variation, lot to lot differences, infrequent fab cycles, poor yield, etc. etc. etc. That is why EasyPath(tm) is sooo attractive to us. Been there, done that. http://www.xilinx.com/prs_rls/silicon_vir/0312_v2propricing_final.htm There is a real obvious reason why we abandoned HardWire: it led nowhere. The total Structured ASIC business (the new fancy name for this business) was about 68 million US$ in 2003 (from a survey). It is estimated to be about 900 million US$ by 2007 (from the same survey). I don't believe these numbers at all (I think they are too large). Financial folks have also passed the business by as a "non-starter." Split among 10+ competitors, it is a pretty uninteresting business model to go after, especially since looks like 10+ tom cats fighting over one mouse .... one mouse at a time! I get much more excited about things like: http://www.xilinx.com/prs_rls/silicon_vir/0413790nmmilestone.htm Austin Bill Cox wrote: > Hi. > > I'm looking for information on Xilinx's original HardWired family, > which were litteral replacements for FPGAs, rather than gate arrays. > As I understand it, they were configured with a single via layer, and > had timing matched paths. > > If anyone has old app-notes, data sheets, or other relavent info on > the original family of parts, please e-mail me a copy. > > Thanks, > Bill Cox > bill@viasic.com
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