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
Can we stop this thread, and stop flogging Austin?
The tone has not gotten any better as time went on.
I have been aware of this problem for 15 years, and have made repated
suggestions, but I have never really followed through. Ideas are a dime
a dozen, execution is what counts!
I will be more forceful, and you guys have given me good ammunition.
I know a neat solution, and I will be more tenacious this time.
Peace !
Peter Alfke
rickman wrote:
> Austin Lesea wrote:
> > Rick,
> >
> > OK. I never complained about the engineers who use our parts. I
> > pointed out that there are those who just don't seem to be doing their
> > jobs (IMHO).
>
> "I am apalled that people who call themselves 'engineers' (not
> referring
> to you, of course) would completely ignore physics, and continue to act
> as if there is no such thing as signal integrity, and continue to waste
> their company's money by not doing something that they should be doing
> (not just for CCLK, but all the other IO pins on the package, too)."
>
> I would say that claiming to be "apalled" about engineers who use your
> parts is "complaining". If not, what *do* you call it?
>
>
> > And I do not know everything. In fact, I have already posted that I
> > know very little: I poll others here at Xilinx prior to my responses.
> > I am flattered that you thought I actually come up with all of this all
> > on my own!
>
> I think I have a good handle on what you do and don't know. It is the
> way you present it that "impresses" me.
>
>
> > And, I do suggest that a little SI goes a long way. When was the last
> > time you tried HyperLynx? With the little I know, even I can use it easily.
>
> I used it on my last board. I find that it is *not* easy to use
> because it depends on having good info and I have little reason to
> believe many of the device models I have to work with. This was
> discussed in a recent class I took and many of the participants and the
> instructor all agreed that many BSDL files contain errors.
>
>
> > Anyway, thanks for reminding me of the dual speed modes. I recall a
> > terrible customer issue that involves the dual speed use, where the low
> > speed worked fine, and the high speed did not. Why? No SI engineering.
> > So they built it in slow mode, and then changed to fast bitstreams for
> > production.
> >
> > Results: line down, and plane flights for all the designers ("How could
> > you do something so stupid!"). Maybe one disaster is insufficient to
> > kill a good feature?
>
> If your customer does not understand the implications of using the high
> speed, why did they attempt it and why, oh why would Xilinx then feel
> it was a bad feature??? It almost sounds like you are trying to
> protect your customers from themselves by removing useful features.
>
>
> > OK, I have said I am going back and discuss a more forgiving input with
> > designers, and I have said SI is a good thing, and saves money.
> >
> > Please don't put words in my mouth, (or ideas in my head that I never
> > could possibly have had -- I am just not that smart!)
>
> I could never put words in your mouth. I don't think there is any more
> bandwidth left... ;^)
Article: 108801Peter Alfke wrote: > Can we stop this thread, and stop flogging Austin? > The tone has not gotten any better as time went on. > I have been aware of this problem for 15 years, and have made repated > suggestions, but I have never really followed through. Ideas are a dime > a dozen, execution is what counts! > I will be more forceful, and you guys have given me good ammunition. > I know a neat solution, and I will be more tenacious this time. > Peace ! > Peter Alfke Peter, Thank you, I had wanted to say something similiar, this harping was seeming too personal + counterproductive. It says a lot to me and other engineers that Xilinx engineers are participating in these newsgroups. Bitching at them isn't going to give them or similiar engineers from other companies a big incentive to stick around. Xilinx is a business, they're doing pretty well so they must be doing something right. Nobody's perfect, businesses included. Maybe they're doing the best they can trying to maximize everyone's satisfaction with their products, with limited resources and budget. I'm a relative newcomer myself so didn't really think it was my place to lecture. Sorry if this email sounds like one. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108802
David Ashley wrote: > Peter Alfke wrote: > > Can we stop this thread, and stop flogging Austin? > > The tone has not gotten any better as time went on. > > I have been aware of this problem for 15 years, and have made repated > > suggestions, but I have never really followed through. Ideas are a dime > > a dozen, execution is what counts! > > I will be more forceful, and you guys have given me good ammunition. > > I know a neat solution, and I will be more tenacious this time. > > Peace ! > > Peter Alfke > > Peter, > > Thank you, I had wanted to say something similiar, this harping > was seeming too personal + counterproductive. > > It says a lot to me and other engineers that Xilinx engineers are > participating in these newsgroups. Bitching at them isn't going to > give them or similiar engineers from other companies a big incentive > to stick around. > > Xilinx is a business, they're doing pretty well so they must be > doing something right. Nobody's perfect, businesses included. > Maybe they're doing the best they can trying to maximize > everyone's satisfaction with their products, with limited resources > and budget. > > I'm a relative newcomer myself so didn't really think it was my > place to lecture. Sorry if this email sounds like one. > > -Dave The lecture is no problem, but it is not uncommon for people to go off on Austin. In fact that seems to be a pattern here. Austin says some things that are either rude, arrogant or just plain wrong and people respond appropriately. Then either Peter comes to his rescue asking that we "restore civility" without ever asking Austin to cool his jets or once in awhile someone else chirps in that they "value" Austin's input in this group. I don't for a minute doubt that Austin makes valuable contributions here. But he is subject to the same treatment as anyone else. If he comes across badly, it can be pointed out to him. I don't consider this to be personal because I would reply likewise to anyone else who posts in the same manner. Often it seems personal just because while most people will respond by acknowledging when they were wrong, that does not seem to happen in this case. Actually the stuff you find in this group is *very* tame compared to many of the newsgroups. After all, this *is* the Internet. Sometimes I wonder why representatives from Altera don't post more often, but that likely has to do with the businesslike manner they ususally have. They prefer not to get into public debates with representatives from Xilinx I think.Article: 108803
Rickman, I just want to stop the endless repetition. Anything that needed to be said, has been said. Let's not have another thread that regurgitates the same stuff ad infinitum... Peter Alfke ========== rickman wrote: > David Ashley wrote: > > Peter Alfke wrote: > > > Can we stop this thread, and stop flogging Austin? > > > The tone has not gotten any better as time went on. > > > I have been aware of this problem for 15 years, and have made repated > > > suggestions, but I have never really followed through. Ideas are a dime > > > a dozen, execution is what counts! > > > I will be more forceful, and you guys have given me good ammunition. > > > I know a neat solution, and I will be more tenacious this time. > > > Peace ! > > > Peter Alfke > > > > Peter, > > > > Thank you, I had wanted to say something similiar, this harping > > was seeming too personal + counterproductive. > > > > It says a lot to me and other engineers that Xilinx engineers are > > participating in these newsgroups. Bitching at them isn't going to > > give them or similiar engineers from other companies a big incentive > > to stick around. > > > > Xilinx is a business, they're doing pretty well so they must be > > doing something right. Nobody's perfect, businesses included. > > Maybe they're doing the best they can trying to maximize > > everyone's satisfaction with their products, with limited resources > > and budget. > > > > I'm a relative newcomer myself so didn't really think it was my > > place to lecture. Sorry if this email sounds like one. > > > > -Dave > > The lecture is no problem, but it is not uncommon for people to go off > on Austin. In fact that seems to be a pattern here. Austin says some > things that are either rude, arrogant or just plain wrong and people > respond appropriately. Then either Peter comes to his rescue asking > that we "restore civility" without ever asking Austin to cool his jets > or once in awhile someone else chirps in that they "value" Austin's > input in this group. > > I don't for a minute doubt that Austin makes valuable contributions > here. But he is subject to the same treatment as anyone else. If he > comes across badly, it can be pointed out to him. I don't consider > this to be personal because I would reply likewise to anyone else who > posts in the same manner. Often it seems personal just because while > most people will respond by acknowledging when they were wrong, that > does not seem to happen in this case. > > Actually the stuff you find in this group is *very* tame compared to > many of the newsgroups. After all, this *is* the Internet. > > Sometimes I wonder why representatives from Altera don't post more > often, but that likely has to do with the businesslike manner they > ususally have. They prefer not to get into public debates with > representatives from Xilinx I think.Article: 108804
The Altera 2C8 that is on that board is relatively small. I have not found an accurate size for Leon but it is likely to use a large percentage of that chip. There also appears to be a very limited I/O capability in/out of the FPGA. Both factors will limit any SOC projects. If it is mainly a FPGA you want out of a board then there is a list of boards here http://www.fpga-faq.com/ including our own products. This list isn't totally comprehensive but is the best I have seen in one place. Alternatively tell the group what attracts you to the board you started looking at and someone may suggest a better match for your requirements. John Adair Enterpoint Ltd. ziggy wrote: > Ran across this board the other day, was wondering if anyone has any > experiences with it, good or bad. > > Also, not really being too experiences in sizing yet, would something > like this be big enough for a complete system, using a leon sparc or > similar sized core? > > it seems to have the basic features i want, ethernet, vga, serial, ram, > reasonable cost, etc.. But if it is too small to be useable for SOC type > projects, it wont help me much. > > http://www.embeddedarm.com/epc/ts7300-spec-h.htmArticle: 108805
Uwe We should have our Darnaw1 and Craignell1/2 products on release soon to offer easy prototype of Spartan-3E parts all the way up to XC3S1600E. Final check of them is on my current list of things to be done. John Adair Enterpoint Ltd. Uwe Bonnes wrote: > Antti Lukats <antti@openchip.org> wrote: > > "ziggy" <ziggy@fakedaddress.com> schrieb im Newsbeitrag > > news:ziggy-E12AF3.19422315092006@news.isp.giganews.com... > > > Ok, so a link to these people came across my mail box today. and its > > > supposedly a Open Source 64bit sparc core.. > > > > > > Anyone that has seen this before want to comment? > > > > > > Oh, and the little piece of hardware they show on their pages, anyone > > > know what that is and where it came from? > > > yes it s OpenSparc > > > I tried with ISE but only got portability error, so you possible need > > synplify if targetting Xilinx > > > the piece of hardware pictured is ir-relavant, it is I think what the > > authors think a picture of something that is understood as hardware > > Any idea at what FPGA class this design is targeted? Anything available > PQ208 package? > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108806
Did you mean the Tarfessock1? We have slipped a little due to the amount of customer work that has come in over the summer but will like be available in approximately 3-4 weeks. Our main limitation is the arrival of the cardbus frames and covers which we are waiting for. Darnaw1 and Craignell1/2 are roughly on the same timescale. All of these designs are looking very good and I'm pleased with the results that our team of engineers have achieved. Generally everything that we said we were aiming for has been achieved in each of these designs. John Adair Enterpoint Ltd. google@gornall.net wrote: > Paul wrote: > > Digilent sells a USB JTAG cable. The downside is it isnt compatible > > with Xilinx drivers, so you have to download and use the digilent load > > software. This adds an extra step to the process, although ExPort (the > > digilent software) will download the BIT file into the FPGA fine, you > > have to take some additional steps to get an SVF file out of your MCS > > file for the PROM, the load the PROM from the digilent software from > > the SVF. > > > > > > John_H wrote: > > > I've been using the Xilinx Platform Cable USB for some time. They now have > > > a second generation out there with lower power *and* is lead free. I only > > > wish I could have multiple USBs connected at once since my Xilinx Spartan3E > > > starter kit board has a "built-in" platform USB cable that just needs a > > > standard USB cable to connect to my system. So nice. > > Cheers, both :-) > > I've ordered one of the Xilinx USB ones. $150 for a cable seems ... > overkill ... but I guess it'll work with just about all the devices I > use from now on (still waiting for the Darnaw1 :-) Anything for a > simple life :-) > > Simon.Article: 108807
Hi, the original announcement is at the bottom of the thread there http://www.mikrocontroller.net/forum/read-9-411815.html#new or the direct download link http://www.mikrocontroller.net/attachment.php/418674/Ssfp16_1.0.zip all the documentation is in german only at the moment, but it should be still useable - the download archive includes vhdl files example toplevel and ucd for Digilent S3 starterkit assembler (with C sources) simulator (in java) script to use data2mem for rom initialization documentation there is no ISE project, so new project must be made, then just add all vhdl files. on my test build the UCF caused errors on timing constraints and bram loc constrains, after removing them the build was succesful. for succesful data2mem script merging the UCF-BMM must match or the data2mem will not be able to init the bitstream correctly so that may have to be fixed manually, otherwise is the project ready to go for S3 starterkit. and size - just for testing I synthesized for S3-50: used slices 43% not bad for an 16 bit processor. AnttiArticle: 108808
John_H wrote: > Symon wrote: > >> Martin, >> You can only use certain I/O standards with specific Vccos. If you >> want to change voltage, you must change both the I/O standard and >> Vcco. Read the manual about the I/O banking rules. >> HTH, Syms. > > > > To expand a little, if you have an output buffer powered by 2.5 volts, > how do you expect the FPGA to get up to 3.3V? Thanks to you and others for your quick reply. I think I understand now what confused me first, but it would be nice if you could tell me if I am right on this: If Vcco is connected to 2.5 V, is it then impossible to get down to 1.5 V output level by using LVCMOS15? (I do not want to output 1.5 V in my final design. Using LVCMOS15 was an experiment to see whether I can alter the output level at all. Although I understand that I cannot produce any higher level than Vcco, my assumption was that producing a lower level is possible. Since the level did not change to 1.5, this experiment led me to the conclusion that Vcco is not the cause of the problem, and that something went wrong with the toolchain, but I'm no longer sure about this). Thanks, Martin GeisseArticle: 108809
Martin Geisse schrieb: > John_H wrote: > > Symon wrote: > > > >> Martin, > >> You can only use certain I/O standards with specific Vccos. If you > >> want to change voltage, you must change both the I/O standard and > >> Vcco. Read the manual about the I/O banking rules. > >> HTH, Syms. > > > > > > > > To expand a little, if you have an output buffer powered by 2.5 volts, > > how do you expect the FPGA to get up to 3.3V? > > Thanks to you and others for your quick reply. I think I understand now > what confused me first, but it would be nice if you could tell me if I > am right on this: If Vcco is connected to 2.5 V, is it then impossible > to get down to 1.5 V output level by using LVCMOS15? > > (I do not want to output 1.5 V in my final design. Using LVCMOS15 was an > experiment to see whether I can alter the output level at all. Although > I understand that I cannot produce any higher level than Vcco, my > assumption was that producing a lower level is possible. Since the level > did not change to 1.5, this experiment led me to the conclusion that > Vcco is not the cause of the problem, and that something went wrong with > the toolchain, but I'm no longer sure about this). > > Thanks, > Martin Geisse the output level will match the actual VCCIO on that bank, no matter the IOSTANDARD setting. AnttiArticle: 108810
On 16 Sep 2006 14:05:55 +0200, "Symon" <symon_brewer@hotmail.com> wrote: >"Brian Drummond" <brian_drummond@btconnect.com> wrote in message >news:3fong21thj450qaqdharsmgkcjv7oiedhk@4ax.com... >> On 15 Sep 2006 14:38:26 +0200, "Symon" <symon_brewer@hotmail.com> wrote: >> >>>Read the >>>manual about the I/O banking rules. >>>HTH, Syms. >> >> There are quite a lot of manuals, and quite a lot of reading... >> sometimes even finding what you want in all the available literature is >> quite an achievement. >Hi Brian, >You're right, the Xilinx literature can be an insomniac's delight! >In this case however, the data is right where you'd expect it. Get DS083, >the VII-Pro datasheet, under functional description, FPGA, IOBs, there's a >table called 'Supported Single-Ended I/O Standards.'. A little below that is >a whole section called 'I/O Banking'. >HTH, Syms. Thanks! Glad it sometimes works... Actually I confess to having reached the download stage on DS083 several times on several different issues, and been told the file already exists... you'd think I'd learn! Now if only the support database was searchable for INFO:XST:1943 and other obscure messages. Such as WARNING:Xst:638 and 1303, which translate to "KEEP attribute detected; deleting signal anyway" without giving a clue about the problem... - BrianArticle: 108811
I checked on the web page for the Xilinx tools and this is what I found... "The memory requirements for both RAM and hard disk space will vary depending on your target device family and size as well as the unique characteristics of your design. " Anyone have an idea of how much hard drive space is needed for the full toolset? I don't get why they don't provide some sort of figure either a base or a maximum. I guess if you have to ask, you don't have enough space?Article: 108812
Understod. Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim, >> >> We also have customers who know SI, and perhaps end up with a resistor >> for proper termintion. >> >> But I will mention it. > > > And remember to point out, that all the SI engineering in the world, > and termination resistors, will not solve the problem of slow edges : > sometimes the devices that drive the CCLK might be a uC and it might > have deliberately slowed edges for EMC reasons (more common these > days..) That is why you need a Schmitt! > > -jg >Article: 108813
Rick,
I suspect we will continue to agree to disagree,
Thanks for your comments,
Austin
rickman wrote:
> Austin Lesea wrote:
>
>>Rick,
>>
>>OK. I never complained about the engineers who use our parts. I
>>pointed out that there are those who just don't seem to be doing their
>>jobs (IMHO).
>
>
> "I am apalled that people who call themselves 'engineers' (not
> referring
> to you, of course) would completely ignore physics, and continue to act
> as if there is no such thing as signal integrity, and continue to waste
> their company's money by not doing something that they should be doing
> (not just for CCLK, but all the other IO pins on the package, too)."
>
> I would say that claiming to be "apalled" about engineers who use your
> parts is "complaining". If not, what *do* you call it?
>
>
>
>>And I do not know everything. In fact, I have already posted that I
>>know very little: I poll others here at Xilinx prior to my responses.
>>I am flattered that you thought I actually come up with all of this all
>>on my own!
>
>
> I think I have a good handle on what you do and don't know. It is the
> way you present it that "impresses" me.
>
>
>
>>And, I do suggest that a little SI goes a long way. When was the last
>>time you tried HyperLynx? With the little I know, even I can use it easily.
>
>
> I used it on my last board. I find that it is *not* easy to use
> because it depends on having good info and I have little reason to
> believe many of the device models I have to work with. This was
> discussed in a recent class I took and many of the participants and the
> instructor all agreed that many BSDL files contain errors.
>
>
>
>>Anyway, thanks for reminding me of the dual speed modes. I recall a
>>terrible customer issue that involves the dual speed use, where the low
>>speed worked fine, and the high speed did not. Why? No SI engineering.
>> So they built it in slow mode, and then changed to fast bitstreams for
>>production.
>>
>>Results: line down, and plane flights for all the designers ("How could
>>you do something so stupid!"). Maybe one disaster is insufficient to
>>kill a good feature?
>
>
> If your customer does not understand the implications of using the high
> speed, why did they attempt it and why, oh why would Xilinx then feel
> it was a bad feature??? It almost sounds like you are trying to
> protect your customers from themselves by removing useful features.
>
>
>
>>OK, I have said I am going back and discuss a more forgiving input with
>>designers, and I have said SI is a good thing, and saves money.
>>
>>Please don't put words in my mouth, (or ideas in my head that I never
>>could possibly have had -- I am just not that smart!)
>
>
> I could never put words in your mouth. I don't think there is any more
> bandwidth left... ;^)
>
Article: 108814In article <1158478826.601785.144780@b28g2000cwb.googlegroups.com>, "John Adair" <g1@enterpoint.co.uk> wrote: > The Altera 2C8 that is on that board is relatively small. I have not > found an accurate size for Leon but it is likely to use a large > percentage of that chip. > > There also appears to be a very limited I/O capability in/out of the > FPGA. > > Both factors will limit any SOC projects. > > If it is mainly a FPGA you want out of a board then there is a list of > boards here http://www.fpga-faq.com/ including our own products. This > list isn't totally comprehensive but is the best I have seen in one > place. > > Alternatively tell the group what attracts you to the board you started > looking at and someone may suggest a better match for your > requirements. > > John Adair > Enterpoint Ltd. > > ziggy wrote: > > Ran across this board the other day, was wondering if anyone has any > > experiences with it, good or bad. > > > > Also, not really being too experiences in sizing yet, would something > > like this be big enough for a complete system, using a leon sparc or > > similar sized core? > > > > it seems to have the basic features i want, ethernet, vga, serial, ram, > > reasonable cost, etc.. But if it is too small to be useable for SOC type > > projects, it wont help me much. > > > > http://www.embeddedarm.com/epc/ts7300-spec-h.htm Tks, ill steer clear due to its size. I have learned to recognize xilinx sizes, but not altera. If it wont comfortably fit a leon ( the largest plan i have ) + support cores then it wont be of much good even if it did have ethernet and CF. ( plus the standard, VGA, serial, ram ) While asking the group sounds like a good idea, the last time i tried something like that around here i was told to goto hell and do it myself.Article: 108815
Antti wrote: > [...] > > the output level will match the actual VCCIO on that bank, > no matter the IOSTANDARD setting. > > > Antti Okay, thanks a lot for your help! MartinArticle: 108816
In article <1158485668.999811.326430@e3g2000cwe.googlegroups.com>, "Antti" <Antti.Lukats@xilant.com> wrote: > Hi, > > the original announcement is at the bottom of the thread there > > http://www.mikrocontroller.net/forum/read-9-411815.html#new > > or the direct download link > > http://www.mikrocontroller.net/attachment.php/418674/Ssfp16_1.0.zip > > all the documentation is in german only at the moment, > but it should be still useable - the download archive includes > > vhdl files > example toplevel and ucd for Digilent S3 starterkit > assembler (with C sources) > simulator (in java) > script to use data2mem for rom initialization > documentation > > there is no ISE project, so new project must be made, then just add all > vhdl files. on my test build the UCF caused errors on timing > constraints and bram loc constrains, after removing them the build was > succesful. > > for succesful data2mem script merging the UCF-BMM must match or the > data2mem will not be able to init the bitstream correctly so that may > have to be fixed manually, otherwise is the project ready to go for S3 > starterkit. > > and size - just for testing I synthesized for S3-50: > used slices 43% > not bad for an 16 bit processor. > > Antti Any ETA on translations for us over here in the us that never learned another language?Article: 108817
On 2006-09-17 01:03:05 -0700, "John Adair" <g1@enterpoint.co.uk> said: > Did you mean the Tarfessock1? > > We have slipped a little due to the amount of customer work that has > come in over the summer but will like be available in approximately 3-4 > weeks. Our main limitation is the arrival of the cardbus frames and > covers which we are waiting for. No, I meant the Darnaw1 (S3S1200E module, yes ?) - it's for a different project than the V4FX board :-) > Darnaw1 and Craignell1/2 are roughly on the same timescale. I'm assuming the casual mention of a completely unknown (at least to me, and I can't find it on your site :-) board is a marketing ploy designed to tease out the question: "What is Craignell1 and 2 ?". Ok then [grin], dish! SimonArticle: 108818
On Sat, 16 Sep 2006 15:51:46 -0700, Austin Lesea <austin@xilinx.com> wrote: >Jim, > >We also have customers who know SI, and perhaps end up with a resistor >for proper termintion. > >But I will mention it. > >Thank you, > >Austin I have one board with six Xilinx chips and two SPI chips (a temperature sensor and an eeprom) sharing one CCLK/SPI clock source, all driven by a port pin on a microprocessor. The parts are all over the board, so neither source nor load termination are practical without adding a multi-output clock buffer and star-routing the CCLKs. What a pain. So the easiest answer is to add a TinyLogic schmitt chip adjacent to each Xilinx. Xilinx could add that functionality internally for about a millicent. The two SPI chips, of course, already have schmitts on their clock inputs. JohnArticle: 108819
"rickman" <gnuarm@gmail.com> wrote: >I checked on the web page for the Xilinx tools and this is what I >found... > >"The memory requirements for both RAM and hard disk space will vary >depending on your target device family and size as well as the unique >characteristics of your design. " > >Anyone have an idea of how much hard drive space is needed for the full >toolset? I don't get why they don't provide some sort of figure either >a base or a maximum. I guess if you have to ask, you don't have enough >space? Count on 1GB of hard drive space for the Xilinx ISE software. A P4 with 512MB memory is enough. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108820
Nico Coesel wrote: > "rickman" <gnuarm@gmail.com> wrote: > > >I checked on the web page for the Xilinx tools and this is what I > >found... > > > >"The memory requirements for both RAM and hard disk space will vary > >depending on your target device family and size as well as the unique > >characteristics of your design. " > > > >Anyone have an idea of how much hard drive space is needed for the full > >toolset? I don't get why they don't provide some sort of figure either > >a base or a maximum. I guess if you have to ask, you don't have enough > >space? > > Count on 1GB of hard drive space for the Xilinx ISE software. A P4 > with 512MB memory is enough. I got it to work with about 4 GB of free disk space after it failed with over 2 GB of free space. I watched the HD usage as it installed and the high water mark seemed to be about 3.25 GB. The final storage used is about 2.25 GB. This was WebPack ver 8.1.Article: 108821
John Larkin wrote: > On Sat, 16 Sep 2006 15:51:46 -0700, Austin Lesea <austin@xilinx.com> > wrote: > > >Jim, > > > >We also have customers who know SI, and perhaps end up with a resistor > >for proper termintion. > > > >But I will mention it. > > > >Thank you, > > > >Austin > > I have one board with six Xilinx chips and two SPI chips (a > temperature sensor and an eeprom) sharing one CCLK/SPI clock source, > all driven by a port pin on a microprocessor. The parts are all over > the board, so neither source nor load termination are practical > without adding a multi-output clock buffer and star-routing the CCLKs. > What a pain. So the easiest answer is to add a TinyLogic schmitt chip > adjacent to each Xilinx. Xilinx could add that functionality > internally for about a millicent. The two SPI chips, of course, > already have schmitts on their clock inputs. Why is a schmitt trigger input an automatic cure for SI issues? All this would do is to raise the bar for the amount of noise on the signal, it does not remove the need to consider SI. If the concern is the reflections and improper termination of transmission lines, I would expect to see ringing much greater than the small margin added by a schmitt trigger. But if the edge rate of the driver is low, then you can live a happy life without the schmitt trigger. Of course even ringing is typically a short lived transient. So if the buffers are rather slow, they may be acting as a low pass filter which is what Xilinx has said they don't want to do to the CCLK input so it can work with high data rates. I guess I am saying that although it would be nice if the CCLK input had a schmitt trigger input (and was 3.3 volt), you can't expect that to solve SI issues without giving them further consideration!Article: 108822
stanIam wrote: > Regarding the Fairchild Symbol IIr computer, and other obsolete > architectures, I suggest reading the old book (out of print) > by: Dan Siewiorek, G. Bell, A. Newell, "Computer Structures: > Principles and Examples", printed in 1982 by McGraw Hill. There is a link to an online version of this book (and lots of other interesting material) near the bottom of http://research.microsoft.com/~gbell/CyberMuseumPubs.htm -- JecelArticle: 108823
rickman wrote: > John Larkin wrote: > >>On Sat, 16 Sep 2006 15:51:46 -0700, Austin Lesea <austin@xilinx.com> >>wrote: >> >> >>>Jim, >>> >>>We also have customers who know SI, and perhaps end up with a resistor >>>for proper termintion. >>> >>>But I will mention it. >>> >>>Thank you, >>> >>>Austin >> >>I have one board with six Xilinx chips and two SPI chips (a >>temperature sensor and an eeprom) sharing one CCLK/SPI clock source, >>all driven by a port pin on a microprocessor. The parts are all over >>the board, so neither source nor load termination are practical >>without adding a multi-output clock buffer and star-routing the CCLKs. >>What a pain. So the easiest answer is to add a TinyLogic schmitt chip >>adjacent to each Xilinx. Xilinx could add that functionality >>internally for about a millicent. The two SPI chips, of course, >>already have schmitts on their clock inputs. > > > Why is a schmitt trigger input an automatic cure for SI issues? All > this would do is to raise the bar for the amount of noise on the > signal, it does not remove the need to consider SI. If the concern is > the reflections and improper termination of transmission lines, I would > expect to see ringing much greater than the small margin added by a > schmitt trigger. But if the edge rate of the driver is low, then you > can live a happy life without the schmitt trigger. Of course even > ringing is typically a short lived transient. So if the buffers are > rather slow, they may be acting as a low pass filter which is what > Xilinx has said they don't want to do to the CCLK input so it can work > with high data rates. > > I guess I am saying that although it would be nice if the CCLK input > had a schmitt trigger input (and was 3.3 volt), you can't expect that > to solve SI issues without giving them further consideration! because it is not always a reflection/SI issue ( as I pointed out to Austin, and I believe he is passing onto the design team ) As the FPGAs get ever-faster, they get LESS tolerant of slow edges, and even small ground bounce on a slow esge, can double clock. [and uC often have deliberately slow edges, for EMC reasons] A number of (bad) things can occur with slow edges. Very slow edges can cause input buffer oscillation, but even 'moderately slow' edges effectively amplify ground/Vcc bounce. viz: If the clock is not well clear of the threshold, by the time the current spikes start, you can get double clocking (and thus unreliable config). John has simply added a device that fixes a real design problem. Note that he mentions the other SPI devices DO have schmitt clocks ? -jgArticle: 108824
On 17 Sep 2006 11:37:44 -0700, "rickman" <gnuarm@gmail.com> wrote: >John Larkin wrote: >> On Sat, 16 Sep 2006 15:51:46 -0700, Austin Lesea <austin@xilinx.com> >> wrote: >> >> >Jim, >> > >> >We also have customers who know SI, and perhaps end up with a resistor >> >for proper termintion. >> > >> >But I will mention it. >> > >> >Thank you, >> > >> >Austin >> >> I have one board with six Xilinx chips and two SPI chips (a >> temperature sensor and an eeprom) sharing one CCLK/SPI clock source, >> all driven by a port pin on a microprocessor. The parts are all over >> the board, so neither source nor load termination are practical >> without adding a multi-output clock buffer and star-routing the CCLKs. >> What a pain. So the easiest answer is to add a TinyLogic schmitt chip >> adjacent to each Xilinx. Xilinx could add that functionality >> internally for about a millicent. The two SPI chips, of course, >> already have schmitts on their clock inputs. > >Why is a schmitt trigger input an automatic cure for SI issues? All >this would do is to raise the bar for the amount of noise on the >signal, it does not remove the need to consider SI. If the concern is >the reflections and improper termination of transmission lines, I would >expect to see ringing much greater than the small margin added by a >schmitt trigger. But if the edge rate of the driver is low, then you >can live a happy life without the schmitt trigger. Of course even >ringing is typically a short lived transient. So if the buffers are >rather slow, they may be acting as a low pass filter which is what >Xilinx has said they don't want to do to the CCLK input so it can work >with high data rates. > >I guess I am saying that although it would be nice if the CCLK input >had a schmitt trigger input (and was 3.3 volt), you can't expect that >to solve SI issues without giving them further consideration! I give everything consideration; I'm an engineer, not an "engineer." And I do understand things like termination, reflection, and noise, and I do routinely use pre-layout tools and a 20 GHz TDR system to find out what's actually going on with my PCB designs. The issue is that as FPGAs get faster, relatively slow (as in 7 ns "TTL" edges) spend a lot of time close to the logic decision point of the CCLK input circuits, and noise margin gets tiny when the CCLK input gets picky about sub-ns-scale wiggles. A low edge rate becomes yet another hazard, not a fix. One of our boards wouldn't configure because we had about 100 mv p-p crosstalk (from some VME bus signals) getting into a slow CCLK edge. If a single uP pin drives a CCLK net, the signal may go in different directions, requiring multiple terminations, and most uP port pins can't drive loads like that. If it's a single trace that daisy-chains through multiple chips, the lump-loaded trace impedance gets very low, and again it's hard to get a legal drive, and one can expect ugly plateaus and rings on the mid-rise. And even if the termination thing is resolved, slow edges have bad noise margins when driving very fast gates that have no hysteresis. Adding hysteresis would allow me to use slow edges and tolerate quite a bit of noise and crosstalk, and that opens up a lot of design options. SI doesn't mean that every signal is ns-fast, impedance matched, and terminated. It means that every signal works. If CCLK is a very fragile input, we can drive it, but it takes more parts, more analysis, and more PCB real estate to make it reliable, and Xilinx could make it much easier if they cared to. And heaven help the kids who connect CCLK to a PC parallel port through a cable, and never get Xilinx chips to come up. They aren't the best prospects as repeat customers when they graduate and start designing in earnest. "Oh we tried Xilinx and WebPack for our senior project, but we never got the damned things to configure, so we used Altera." John
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