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
I just thought I'd ask here while I'm waiting for the webcase registration to go through... I tried installing ISE 6.1i on Linux (RedHat 7.3) yesterday. The install failed, because it said there was not enough disk space. What happened was that it seemed to be picking up the percent available instead of the disk space free. The form showed something like Available disk space 19% K I tried fooling it by aliasing df, assuming that it is running df to find the disk space alias df='/bin/df -P' but that didn't work. I even tried a ghastly combination of tr and cut to remove spaces and cut out the percent available field! That didn't fool it either. Has anyone else encountered this? The only unusual thing about the machine is that we use Xi Graphics DeXTop CDE as the window manager, otherwise it is plain RedHat 7.3, kept bang up-to-date. The other thing I wondered is if the length of the path is important? We install in /export/apps/xilinx61i whereas the default install is /xilinx, so I guess that might be causing the install program to pick the wrong field? regards Alan P.S. As I say, when the webcase registration goes through, I'll report it to Xilinx support as well. -- Alan Fitch Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: alan.fitch@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: 60876
"SneakerNet" <nospam@nospam.org> wrote in message news:<p43cb.157047 > Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in [deleted] USB11T11A FS/LS USB tranceiver usb_phy (opencores) UTMI interface that connects to USB11T11A usb1.1 (opencores) connects to usb_phy (opencores) connects to USB11T1A it is not HID but it will enumerate in hardware iw the USB host will 'see' it, but ther is no host software provide usb (japanase desing) full HID USB core includes USB11T1A model) can directly be connected to usb D+ D- pins! (no tranceiver chip), there is some VB test program to talk to the core (as it is HID peripheral) antti PS I am afraid you have todo some homework :) cant do it for youArticle: 60877
Hi, I am looking for the same, a device to store some data that will be availiable after a reset or power down. The data are not much, ~ 60 KBytes. Have you managed to find anything? Thanks, Christos <Ram> wrote in message news:ee7fac0.-1@WebX.sUN8CHnE... hi, I'm looking for something in which I can store my application data/parameters which will be overwritten if changed and stored for further use. That means I want a device which I can read from and write to without loosing the data on power down. I'm looking for suggestions of any particular manufacturer/family of devices for the same. Thanks and regards RamArticle: 60878
shabana_rizvi@yahoo.com (rider) wrote in message news:<ca3a68c8.0309232334.15e2561a@posting.google.com>... > Hi ! > > Thanks for the great help offered by the group to our FPGA issues. > This time the queries are: > > 1) I am planning to use a LM317(National Semi) Regulator to power my > board having Spartan2 XC2S150 and some other TTL Ics. Would this > regulator be able to provide the required POS current [power on surge > current] for the FPGA? What current rating is recommended? 2A or more? > If this is not good, which regulator would be OK? LM317 is fine, but is kind old style the rating depends on the voltage drop on regulator if the incoming voltage is low then you can use some nice regulators in SOT223 package they are sufficient (but will get a little hot/warm) with LDO regulators check the special required bypass caps! > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. What bypass capacitor ratings would be OK for my > design .01uf would be OK? I use always 0.1 there is not much difference in size or prics its 0603 package always > 3)In XST 5.1i , there is a synthesis option which says "Add I/O > buffers". Does that mean that if i check this option, the XST would > automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my > top-level module ports and i don't have to instantiate these I/O > buffers into my HDL code? correct. anttiArticle: 60879
What more can I say: I lost yahoo now. That virus searches Usenet for email addresses, and then sends thousands of times that microft fix with the worm.Article: 60880
> Not so long ago I was reading about the design of pipelined computers. In > most cases there should be enough logic never to have to worry about hold > time, but in some cases FF's are wired with no logic in between. Then you > might need to add some to be sure. There is also a design for a combination > latch and two level of logic. That helps in allowing faster clocks for the > amount of logic per pipeline stage. Please excuse me if i go somewhat out of the topic this seems somewhat relating to wave pipeline concept used in asics .. just want to know can present fpgas can make use of this kind of pipeline concept ? people have tried this doing manually as google tells me. or the future fpgas plus routing softwares are going to do this stuff automatically. --ykaArticle: 60881
Hi Guys I am trying to read 36 signal one by one from FPGA using different addresses and these signal are of 3 bits length. My address bus is bidirectional (32 bit length)and it's on tristate while not performing read operations. I am using PCI API fucntion to perform open , read and write operations as it is PCI FPGA reconfigurable board having XCV600 device. The values are being read by using SRAM in the board and I am using addresses which are properly mapped to PCI bus and Onboard Memory. Now the problem is that I delebrately make a loop to read the sequence of signal again and again in order to make sure I am reading the correct output every time. But the thing is that in different iteration the values of different signal are not the same. it means that the signal which is being read is changing all the time. But according to simulated desing this is not the case , I must have been reading the correct output everytime . Is there is any design constraint ? My desing has internal clock as well is this is affecting the signal. But in simulation this is not the case . Also one thing more does the VHDL coding style effect the read from FPGA or not. Because in my other desing I have state machine and number of different states in the Process (desing is synchronous) and I am using CASE statement to move from one state to another. When I download this into the chip and when I perform read operation after writing data into the chip I am getting nothing from FPG. If any one can tell me how to stabilize particular signal so that it could to read oout from FPGA. Cheers Help would be appreciated. Rgds IsaacArticle: 60882
Hello, I would like to know if someone have evaluated the performance with FPGA software tools of the new Intel Centrino Processors compared with the Intel Mobile Pentium 4. I would like to buy a portable and I don't know which processor is better (more performance for EDA Tools). I would appreciate any recommendation on Processors and Portable Manufacturers. Thanks a lot and best regards, JaviArticle: 60883
Rick, Fight it as long as you can, but everyone else is using the more advanced tools, and simulating everything (at the companies where they want to be successful on the first pcb turn -- as for the others, I don't hear from them often anymore....). And yes, if you do not pay attention now, you will cause ground bounce (50 - 60 mA of reflection current per IO is possible), and with the Virtex II Pro, and Spartan 3 if the IOs are operated at 3.3V, you may exceed the Abs Max data sheet limits if you do not pay attention to what you are doing. And that will cause a reduction in the 20 year projected lifetime. Below 3.0V, there are no reliability issues to consider, as the clamp diodes are sufficient to protect the IOs. Smaller, faster, less expensive technology from the foundries has some drawbacks: leakage current, and IO robustness at voltages greater than 3.75 volts being two of them. The new tools allow for extraction of all pcb parameters, and easy simulation of all tracks/traces. You can also create a design that is correct by construction: use DCI or series or parallel termination, and make 50 ohm (or whatever) traces. Then you do not have to simulate everything. Or use a standard: HSTL, SSTL, PCI. Then you also don't have to think. But I also simulate to make sure I haven't missed anything. Austin rickman wrote: > Symon wrote: > > > > Hi Rick, > > As a rule of thumb, when the signal's rise time is faster than > > 1/6th the time for the signal to get to the other end of the trace, > > (guess at 170ps/in of track) then you MUST consider the SI > > implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx > > pin, you can have 1 inch of track before you have to worry about > > reflections!) You can find the rise time data in the IBIS files Xilinx > > provides on their website. Remember, the frequency of the signal isn't > > important, it's the rise time. Leave those pins in 'SLOW' mode > > whenever possible! > > But your use of the term "must" is not totally accurate. The numbers > you give are a good rule of thumb for when reflections will be > significant to the signal waveform, but that does not automatically > indicate a problem will be created. A data line can bounce around for > an extra ns or two and won't matter if there is extra time in the > setup. Up until now I have not seen a chip rated to exclude ringing or > overshoot (or undershoot) because of damage. In fact, most data sheets > specifically say that this will not be a problem if it only persists for > a few ns. > > > As Austin says, the simulation tools are a BIG help here. Those > > IC pins drive bloody hard and fast and I would never like to be > > relying on the clamp diodes to save the day, this dumps energy into > > the supplies and Austin is not joking when he says that ground bounce > > is (and will continue to be) a big consideration. There's a reason > > Xilinx have gone to the trouble of putting DCI on their devices! > > I have not heard of ringing being the cause of ground bounce. My > experience has been that ground bounce is caused by the initial current > slug when an output changes state, not the result of a reflection from > the other end. As the numbers that have been posted in this thread have > indicated, the reflection current is much smaller than the initial > slug. > > > The receivers warrant the most attention as they can appear as > > an open circuit, the drivers have low impedance and so limit > > deviations a bit better. It's time to dust off "High-Speed Digital > > Design" for some bed time reading! There's a new edition out I > > believe? (Just found it:- High-Speed Signal Propagation: Advanced > > Black Magic) I also recommend http://www.sigcon.com/ also by Dr. > > Howard Johnson. More v. helpful stuff there for free!! > > HTH, cheers, Syms. > > If I actually have to simulate every signal on the board I am designing, > it may never get done. I think there is something wrong with the idea > that this is a overly complex issue and can't be dealt with in a simpler > manner. Or am I missing something of what you are saying? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60884
1) the LM317 meet sthe datasheet requirements (current and current limiting) 2) use 0.1uF caps. surface mount 0402, or 0406. One each for every power and ground pin pair. X7R material. Keep inductance down to min. Read th SI Central web pages on power distribution systems. 20MHz is not the issue, it is the edge rates. Austin rider wrote: > Hi ! > > Thanks for the great help offered by the group to our FPGA issues. > This time the queries are: > > 1) I am planning to use a LM317(National Semi) Regulator to power my > board having Spartan2 XC2S150 and some other TTL Ics. Would this > regulator be able to provide the required POS current [power on surge > current] for the FPGA? What current rating is recommended? 2A or more? > If this is not good, which regulator would be OK? > > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. What bypass capacitor ratings would be OK for my > design .01uf would be OK? > > 3)In XST 5.1i , there is a synthesis option which says "Add I/O > buffers". Does that mean that if i check this option, the XST would > automatically insert I/O buffers[IBUF,OBUF,IBUFG,OBUFT etc] into my > top-level module ports and i don't have to instantiate these I/O > buffers into my HDL code? > > Thanks > RiderArticle: 60885
>I am looking for the same, a device to store some data that will be >availiable after a reset or power down. >The data are not much, ~ 60 KBytes. How often does your data change and/or how fast do you need to access it? Can you put it in the the back of the chip holding the configuration bits? There are lots of tiny serial (2 wires) flash/eeprom chips available for that sort of thing. Feed "serial eeprom" to DigiKey's search engine for a good start. They are slightly ugly to talk to. Probably easier if you have software to do it. Also, keep in mind what will happen if power goes out during an update. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 60886
rider wrote: > 2)I have a 20MHz clock in my design that is used in some flip flops in > the design. Most of the circuit is combinational and with about 18 > combinational clocks. That is a scary statement. Are you really using 18 clocks driven by combinatorial logic? You must be either very inexperienced, very brave, or very smart. Or perhaps all three. Normal humans stay away from such design methodologies, and use synchronous logic with a minimum of global clocks (preferrably only one). That's better for your health, your sleep, and your sanity... Peter AlfkeArticle: 60887
Antti Lukats wrote: > > Hi Peter, > > this is something, I mean if someone (like you) doesnt hold it back > to say 'no comments' it means something, need to figure out what :) > It just meant that I had read Neil's wide-ranging posting and found it meaningless to answer, because that would just lead to further outbursts. The subjects he brought up have been discussed in this newsgroup ad nauseam... PeterArticle: 60888
Our limited testing has show Linux to be about 10% faster than Windows running PAR. Linux also uses less memory. The average is about 6% less and a few really big designs that run out of memory on Windows XP run fine under Linux. Steve Matt wrote: >Hehe... okay, let me rephrase. Have you noted any performance differences >relative to your Windows experiences? Good and bad. I promise not to call it >a benchmark! ;-) > >I haven't had the opportunity to try the Linux version yet. --Matt > > > >"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message >news:CIWab.308$Ne.985132@newsfep2-win.server.ntli.net... > > >>Hi Matt, >> >>No I haven't (too busy). Also you know what they say about benchmarks >> >> >"Lies, > > >>Damn Lies and Benchmarks :-) >> >>Hans. >> >>"Matt" <bielstein2002@comcast.net> wrote in message >>news:SMPab.521826$YN5.347243@sccrnsc01... >> >> >>>Question... have you done any benchmarks for performance relative to >>>Windows? (Synthesis/Translate/Map/PAR) Same or similar hardware would be >>>best. >>> >>>Thanks in advance! >>> >>>"Hans" <hansydelm@no-spam-ntlworld.com> wrote in message >>>news:1nzab.364$4G3.59567@newsfep2-gui.server.ntli.net... >>> >>> >>>>Try (bash), >>>> >>>>export LD_ASSUME_KERNEL=2.4.1 >>>> >>>>It runs fine on my RH9, >>>>Hans. >>>>www.ht-lab.com >>>> >>>>"Garry Allen" <garrya@ihug.com.au> wrote in message >>>>news:3abc4240.0309181808.3e1b9cbc@posting.google.com... >>>> >>>> >>>>>I am very thankful that Xilinx is now supporting Linux directly in >>>>>ISE6.1. However, out of the box it only directly supports Redhat 7.3 >>>>>and Redhat 8. Has anyone managed to install it under Redhat 9 and >>>>> >>>>> >what > > >>>>>if anything did you need to do to get it to call the glibc libraries >>>>>successfully? >>>>> >>>>>At the moment when I run ./setup, it fails with an error msssage >>>>>stating that it cannot find the glibc libraries. I am unsure if I >>>>> >>>>> >can > > >>>>>run multiple versions of the gcc compiler >>>>>Comments >>>>>Thanks >>>>>Garry Allen >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > >Article: 60889
Hi Rick, OK, I suppose 'MUST' isn't strictly accurate, you might not care whether the design works or not! How about 'SHOULD' instead? ;-) Those signals bouncing back and forth may not affect the circuits functional operation, but what are you gonna do when it happens on a 5 inch, 32 bit data bus and you can't pass the CE/FCC mark tests? Sell it in Elbonia, I guess! As for ground bounce, if those diodes are dumping energy, be sure you've decoupled the Rx IC as well as the Tx one! Generally, it's better not to have to rely on the diodes, don't you think? You end up trading decoupling capacitors for termination resistors. I'm not saying simulate every trace. Simulate one, and layout the rest accordingly, as I think Austin says in a parallel post. Check the PCB layout very carefully, watching out for traces that don't comply with your SI design. I like Austin's idea of adopting a standard (HSTL, SSTL, PCI), makes it easy. cheers, Syms. rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F71115D.9CC86144@yahoo.com>... > Symon wrote: > > > > Hi Rick, > > As a rule of thumb, when the signal's rise time is faster than > > 1/6th the time for the signal to get to the other end of the trace, > > (guess at 170ps/in of track) then you MUST consider the SI > > implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx > > pin, you can have 1 inch of track before you have to worry about > > reflections!) You can find the rise time data in the IBIS files Xilinx > > provides on their website. Remember, the frequency of the signal isn't > > important, it's the rise time. Leave those pins in 'SLOW' mode > > whenever possible! > > But your use of the term "must" is not totally accurate. The numbers > you give are a good rule of thumb for when reflections will be > significant to the signal waveform, but that does not automatically > indicate a problem will be created. A data line can bounce around for > an extra ns or two and won't matter if there is extra time in the > setup. Up until now I have not seen a chip rated to exclude ringing or > overshoot (or undershoot) because of damage. In fact, most data sheets > specifically say that this will not be a problem if it only persists for > a few ns. > > > > As Austin says, the simulation tools are a BIG help here. Those > > IC pins drive bloody hard and fast and I would never like to be > > relying on the clamp diodes to save the day, this dumps energy into > > the supplies and Austin is not joking when he says that ground bounce > > is (and will continue to be) a big consideration. There's a reason > > Xilinx have gone to the trouble of putting DCI on their devices! > > I have not heard of ringing being the cause of ground bounce. My > experience has been that ground bounce is caused by the initial current > slug when an output changes state, not the result of a reflection from > the other end. As the numbers that have been posted in this thread have > indicated, the reflection current is much smaller than the initial > slug. > > > > The receivers warrant the most attention as they can appear as > > an open circuit, the drivers have low impedance and so limit > > deviations a bit better. It's time to dust off "High-Speed Digital > > Design" for some bed time reading! There's a new edition out I > > believe? (Just found it:- High-Speed Signal Propagation: Advanced > > Black Magic) I also recommend http://www.sigcon.com/ also by Dr. > > Howard Johnson. More v. helpful stuff there for free!! > > HTH, cheers, Syms. > > If I actually have to simulate every signal on the board I am designing, > it may never get done. I think there is something wrong with the idea > that this is a overly complex issue and can't be dealt with in a simpler > manner. Or am I missing something of what you are saying? > > > -- > > Rick "rickman" Collins >Article: 60890
Peter Alfke <peter@xilinx.com> wrote in message news:<3F6F1A16.EC328D4F@xilinx.com>... > Lorenzo Lutti wrote: > > > > > > Yes! But be afraid of iMPACT user interface, which is the worst > > nightmare ever invented. I've lost more than ten minutes to understand > > how to use a PROM with iMPACT... > > Lorenzo, you must be pretty smart if you can solve the "worst nightmare > ever invented" in a mere ten minutes... :-) > Peter Alfke Howdy Peter, I interpreted his comment to mean that he wasted ten minutes on just one aspect of the many that form the nightmare that is iMPACT. And I have to agree with him. The tool sure works like it was designed by someone that doesn't actually have to use it more than once or twice. The rest of the Project Navigator (at least on 5.x), while noticably better than iMPACT, is also very disappointing coming from a company that produces such high caliber hardware. Have fun, MarcArticle: 60891
Hi Peter, As an experienced 'Googler' ;-) I found this:- http://portal.acm.org/citation.cfm?id=611840&jmp=indexterms&dl=portal&dl=ACM It's a scalable 2 V, 20 GHz FPGA using SiGe HBT BiCMOS technology based on the XC6k stuff. Any idea of lead time, pricing? Just kidding, are you guys involved in this? A small (say a few thousand gates), superfast CML FPGA would be very useful, probably used alongside a much bigger, standard part. cheers, Syms. p.s. I don't really expect an answer, guess this stuff would be company confidential anyway. Peter Alfke <peter@xilinx.com> wrote in message news:<3F70E37B.875585DF@xilinx.com>... > If you have experience with google you know to put quotation marks > around : "XC6216 datasheet", and, voila, you get just one hit from a > spanish website: > > http://www.ii.uam.es/~laboweb/LabWeb/pdfs/6kconf.pdf > > That's the 72-page data sheet. > Isn't google.com great! > Peter Alfke > ================== > Neil Franklin wrote: > > > > Peter Alfke <peter@xilinx.com> writes: > > > > > > "H.Azmi" wrote: > > > > > > > > Does any body have datasheet for XC6216 ? > > > > My first answer is: look it up on google. You get 747 hits! > > > > Of course that is just pages which have the 2 pieces of text "6216" > > and "data sheet" (or wven "data" and "sheet" separate) on them. Of > > course that does not have to be an data sheet for an 6216. > > > > I once got a copy from: http://www.vcc.com/Papers/6200.pdf (at least > > my bookmarks say that, in Jan 2001). > > > > -- > > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > > Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith > > - hardware runs the world, software controls the hardware > > code generates the software, have you coded today?Article: 60892
Is there one with the IEEE 1284 Core VHDL that is in english? Regards, James "Antti Lukats" <antti@case2000.com> wrote in message news:80a3aea5.0309232339.5e68de5f@posting.google.com... > "James Williams" <james@williams-eng.com> wrote in message news:<bkpq2c$d4aa$1@news3.infoave.net>... > > Hello, > > > > Is it possible to get the IEEE 1284 parrallel core for the ISE Webpack? I > > am just a hobbiest and can't afford to pay thousands for the for release of > > the ISE. I just want to be have to use the 1284 parrallel interface on my > > device. > > http://www.nahitech.com/nahitafu/fpgavhdl/index.html > > there are 2 links to IEEE1284 vhdl for xilinx :) > found it > > google: IEEE1284 FPGA > :) > > anttiArticle: 60893
> It was more obvious to me connecting Qbar to D of the same FF. Then there > is no question about clock skew. That's a good idea too. Whatever works for you. > But if there is clock skew, then even zero hold time isn't good enough. You > can't make it too easy. I was simplifying the example for the sake of making things easier to understand. But you are correct that during real design you need to take clock skew into account. That is one reason why FPGA vendors make great efforts to provide a low skew clock network. I'm sure FPGA software also takes clock skew into account when analyzing a design. > Not so long ago I was reading about the design of pipelined computers. In > most cases there should be enough logic never to have to worry about hold > time, but in some cases FF's are wired with no logic in between. Then you > might need to add some to be sure. Yeah I agree with you that there's usually enough logic so you wouldn't have to worry. And with FPGAs a significant amount of delay comes from the routing. One advantage of having zero hold-time parts is that you can port a proven design to a faster speed grade without having to worry about a hold-time violation. >There is also a design for a combination > latch and two level of logic. That helps in allowing faster clocks for the > amount of logic per pipeline stage. Do you happen to have a URL to that example? It sounds interesting. --VinhArticle: 60894
"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F71B6DF.8885BD55@xilinx.com... [snip] > And yes, if you do not pay attention now, you will cause ground bounce (50 - > 60 mA of reflection current per IO is possible) [snip] Austin, I appreciate your continued push to get us to look at signal integrity more closely but please help me out here. "Ground bounce" that I'm aware of involves shifting voltage reference thresholds - a voltage effect - due to the parasitic inductance of the chip's ground to the board's ground plane. The change in current draw (dI/dt) across the package inductance produces the voltage change. Are you suggesting the voltage effect will be caused by the current change due to reflected energy getting absorbed in the transistors driving those signals to ground? This would make some sense to me though I would expect the current surge to be spread over a much larger time (different open-circuit lengths) than the original current surges that generated the synchronous signals getting the reflection. If my interpretation is not correct and you're suggesting ground-bounce is related to current rather than current-change related voltage, please help me understand. If logic-high reflections are suspected of causing ground bounce, I'd appreciate some elaboration. Is there a path for this current through the ground on-chip? Are the voltage references not entirely ground-referenced? Thanks for your help.Article: 60895
Steve Lass <lass@xilinx.com> writes: > Linux also uses less memory. The average is about 6% less and a few > really big designs that run out of memory on Windows XP run fine > under Linux. Hopefully there will be a 64-bit Opteron version... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 60896
banktrade2002@yahoo.com (Emile) wrote in message news:<952209fb.0309220456.7aae7278@posting.google.com>... > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F6E9D92.98206CA3@yahoo.com>... > > Mikeandmax wrote: > > > > > > cadnewbie found a gem - > > > > > > >Recently came across an old FPGA circuit board, its an ORCA Version > > > >1.0 evaluation module. It looks quite antiquated and came with no > > > >manuals or softwares whatsoever. I am wondering if there are any > > > >softwares out there on the net that I can find for it. Might be able > > > >to put it to some good use if I can find the darn softwares or at the > > > >very least documents, data sheets. Anyone know anything about it? > > > > > > > Don't have a lot of information on what you have in hand - but Lattice is now > > > the company building the ORCA FPGA products, and developing new devices and > > > families based on this technology. > > > The history lesson is a bit long: > > > ATT and Xilinx were once partnered for early XLX FPGAs, with ATT being a > > > foundry source - > > > at some point the partnership dissolved - and ATT created it's own family > > > called ORCA( for Optimized Reconfigurable Component Array) - > > > ATT spun off LUCENT (with microelectronics along for the ride) > > > Lucent spun off AGERE (with microelectronics along, essentially this is AGERE) > > > AGERE sold off the ORCA technology, along with ASIC technology used for > > > high-end SERDES based FPSC, to Lattice Semiconductor. > > > Lattice now builds and develops device families based on the technology > > > acquired. > > > So, I guess check the lattice website, at least you will find the datasheets > > > for the device on the pcb, and software to design and develop these devices as > > > well. > > > Good luck with your project, I would suggest a call to your Lattice FAE - > > > > > > Michael Thomas > > > Lattice SFAE > > > NY/NJ > > > > If you are really interested, I have the old ORCA software for schematic > > entry using Workview (included). It may use a hardware key, I don't > > remember. I must have one around, but it may take a bit to find it. > > The software however, I have handy if you are interested. > > > > But my advice is to toss the board and deny ever having found it. :) > > > > -- > > > > Rick "rickman" Collins > > > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > > removed. > > > > Arius - A Signal Processing Solutions Company > > Specializing in DSP and FPGA design URL http://www.arius.com > > 4 King Ave 301-682-7772 Voice > > Frederick, MD 21701-3110 301-682-7666 FAX > > Just a note to say we have 500 Lucent ORCA FPGAs on consignment sale, > 250 each of the OR2T15 and OR2T40. Any reasonable offer is welcome. > > -Emile Are the OR2T15 and OR2T40 fairly new chips or the obsoleted ones? I guess I don't really care as long as the tools that are available can still program them. If I train yourself with it, that's what really matters for me anyway.Article: 60897
Peter Alfke <peter@xilinx.com> writes: > Neil Franklin wrote: > > > > Peter Alfke <peter@xilinx.com> writes: > > > > > > My first answer is: look it up on google. You get 747 hits! > > > > Of course that is just pages which have the 2 pieces of text "6216" > > and "data sheet" (or wven "data" and "sheet" separate) on them. Of > > course that does not have to be an data sheet for an 6216. > > > > I once got a copy from: http://www.vcc.com/Papers/6200.pdf (at least > > If you have experience with google Of course I know how to use google. My posing an link (which I found via google) should have pointed that out. :-) > you know to put quotation marks > around : "XC6216 datasheet", And that may require typing XC6200 (Xilinx names their data sheets by family) or "data sheet" with an blank in between. And adding pdf at the end reduces clutter also. Still gives 8 pages of hits, most of them clutter (PDFed university papers which refer to the paper version of the data sheet), but with above VCC site still as first. But why about my google experiences, as I evidently ready have already found one? What I was critisizing was your "You get 747 hits!" line, and its style. That number lookes like the result of an typical uninformed searcher, who doesn't know the difference hits vs usefull links. That there are 747 actual usefull hits is something I would not even take into consideration, seeing how few I found 2.5 years ago[1]. [1] Doing historical research into FPGAs. Managed to find CAL1024 and XC6200. But XC2000, the ancester of all, I still have not found anywhere, grrr. And yes, an "obsolete/EOLed products" page on xilinx.com would be nice. Actel has everything back to ACT1 still on their site. That is nice for tracing product evolution, and so designers experience in what needed changing. I suppose we see here the collision of industrial "bury the past mistakes as fast as possible" and academic "publish and learn from past mistakes" style of thinking. Deriding people (and making snotty[2] google remarks fits in that category) in not really fitting with the professional image you are trying to (and usually manage to) hold up. [2] non-snotty is simply making an remark "you can google for that", anything that does not say "I have looked but I am not telling you". Either be helpfull (cut&paste the first link, after claiming to have found 747 fitting links (or is the 747 just a random invented number?). Or simply not search and make no remark (costs you the least time) and leave googling or tips or lecturing on using google to others. I should add, that above criticism in not Peter Alfke specific, nor c.a.f specific, but rather a general observation on reactions to "find something" threads on Usenet. Either be helpfull and search, or preach "go searching yourself" and then don't do (or pretend to do) an search just to spite the original poster. If you intended the "747" as an joke, then it definitely did not come accross. Lacking intonation, Usenet gets interpreted according to the readers estimates of the senders views. And with you known "anti old chips" and "anti open chips" attitide, such an remark comes accross as snotty. > and, voila, you get just one hit from a > spanish website: > http://www.ii.uam.es/~laboweb/LabWeb/pdfs/6kconf.pdf Only one? Hmm, you searched XC6216, while I looked for XC6200 (which I expected the data sheet to have as title (it did), so I found a few more. But nowhere near 747. > That's the 72-page data sheet. Oh, the 1.10 version (april 1997), I only had 1.07 (october 1996). So at least some good came out of giving you an slap. :-) -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 60898
John_H, Take a simple CMOS inverter inside the IC (not part of the IO). Its switching threshold is directly related to its ground reference, and its Vcc reference. Any ground bounce (LdI/dt) or Vcc bounce (same formula) will move ground and vcc around, even in a perfect bypass world, as there is no "C" used in the spelling of "LdI/dt." Basically, assuming perfect bypass caps, a perfect AC short, you still have that damned LdI/dt to deal with, and the only way to deal with it is to reduce L, dI, or increase dt, or don't switch everything at once (switch banks on different phases of the clock). Now add to the dI/dt that comes from switching outputs, you have a transmission line with signals launched from chip 1, towards chips 2, and at chip 2, the overshoot and undershoot of the mismatched signal to the t-line causes the input clamp diodes to become forward biased. Now you have a current, and it is changing, so now there is an additional dI/dt into Vcc, or out of ground at the RECEIVER. From the clamp diodes, this current has to traverse the same path as an output switching current, that is through the various metal layers, and the package, to get to the ground and Vcc planes in the pcb, so LdI/dt appplies for these signals (inputs at chip 2) as well, and because of the mismatch, overshoot and undershoot, you add to the ground bounce/vcc bounce that is from chip 2's outputs. All of this shifts the switching threshold of that poor inverter (in chip 1 or 2), and the result is much more jitter than you suspected was in the design. I have not even taken into account what dI/dt results from the reflected wave as it comes back to the alread ON driver transistor in chip 1 (the TRANSMITTER), and then has to go to/from Vcco and ground, which is another added LdI/dt on top of the previous LdI/dt from the intitial switching of the output transistor (just will make things worse from not being matched)..... To look at currents in a simulation, place a 1 ohm resistor in series with the line, and then you can see just what dI/dt's are happening.....(so every 1mV=1mA) Austin John_H wrote: > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F71B6DF.8885BD55@xilinx.com... > > [snip] > > > And yes, if you do not pay attention now, you will cause ground bounce > (50 - > > 60 mA of reflection current per IO is possible) > > [snip] > > Austin, > > I appreciate your continued push to get us to look at signal integrity more > closely but please help me out here. "Ground bounce" that I'm aware of > involves shifting voltage reference thresholds - a voltage effect - due to > the parasitic inductance of the chip's ground to the board's ground plane. > The change in current draw (dI/dt) across the package inductance produces > the voltage change. > > Are you suggesting the voltage effect will be caused by the current change > due to reflected energy getting absorbed in the transistors driving those > signals to ground? This would make some sense to me though I would expect > the current surge to be spread over a much larger time (different > open-circuit lengths) than the original current surges that generated the > synchronous signals getting the reflection. > > If my interpretation is not correct and you're suggesting ground-bounce is > related to current rather than current-change related voltage, please help > me understand. > > If logic-high reflections are suspected of causing ground bounce, I'd > appreciate some elaboration. Is there a path for this current through the > ground on-chip? Are the voltage references not entirely ground-referenced? > > Thanks for your help.Article: 60899
"Vinh Pham" <vinh-pham@hawaii.rr.com> wrote in message news:tUkcb.1068$5z.548@twister.socal.rr.com... > > It was more obvious to me connecting Qbar to D of the same FF. Then there > > is no question about clock skew. > > That's a good idea too. Whatever works for you. > > > But if there is clock skew, then even zero hold time isn't > > good enough. You can't make it too easy. > > I was simplifying the example for the sake of making things easier to > understand. But you are correct that during real design you need to take > clock skew into account. That is one reason why FPGA vendors make great > efforts to provide a low skew clock network. I'm sure FPGA software also > takes clock skew into account when analyzing a design. > > >Not so long ago I was reading about the design of pipelined computers. > >In most cases there should be enough logic never to have to > > worry about hold time, but in some cases FF's are wired with no logic > > in between. Then you might need to add some to be sure. > > Yeah I agree with you that there's usually enough logic so you wouldn't have > to worry. And with FPGAs a significant amount of delay comes from the > routing. > > One advantage of having zero hold-time parts is that you can port a proven > design to a faster speed grade without having to worry about a hold-time > violation. I think this is what Peter was trying to point out somewhere along the line. > >There is also a design for a combination latch and two level of logic. > >That helps in allowing faster clocks for the > > amount of logic per pipeline stage. > > Do you happen to have a URL to that example? It sounds interesting. It is called the "Earle latch", which seems to find 38 hits on Google. I have no idea if it is at all useful today. Consider that it was in the days when individual transistors were glued onto ceramic chips, with metalized wiring on them. The 360/91 was built with pretty much a discrete version of ECL. The book I have is called "The Architecture of Pipelined Computers" by Peter M. Kogge. Copyright 1981, so you might consider it more of a history book. Still, many ideas from that time are still in use today. -- glen
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