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
(not urgent...but if someone has any suggestions I would appreciate it) In the labs here, we have WorkView (not sure which version) on a PC and PowerView (5.3) on a set of Sun's, both liscensed for Xilinx Designs. I'm attempting to do a design on an XC4013, and I entered most of the schematics in on the Suns. Unfortunately, there's an liscence installation problem on the Sun's and I can't get it to compile the design this weekend. I thought no problem, I would just move all my designs over to the PC and finish it off. I can copy all my SYM, SCH, and WIR files over fine, but when I try to open up either the SYM or SCH on the PC, it complains that it doesn't have the liscence. I can create & edit schematics on both the Sun's and the PC's, but the PC won't open the one from the Sun. I've done a couple experiments, where I entered the exact same schematic on both, and then I looked at the schematic text file. The only difference (barring minor coordinate differences for joints and components... I wasn't trying to get them *EXACTLY* the same) was in the second line, the K line. Editing this line on the PC, changing the number or the name resulted in Workview going belly up. Doing the same on the Sun's didn't give any problems. I didn't try to edit a file created on the PC from the Sun, but I suspect that it will also work, because PowerView seems to be more forgiving than WorkView. I've already talked to one of the profs and he figures that we can sit down with the system administrator on Monday or Tuesday to figure out how to get the Sun's up and running, but I'd like to do some work tomorrow. Anyone have any suggestions? If you do, could you please e-mail them as well as post? Our news gateway has been very slow in receiving articles recently, but I do know that outgoing articles are sent just fine. Thanks in advance...Article: 951
In article <GEIRERT.95Mar31161214@villrips.idt.unit.no> geirert@idt.unit.no writes: > >How do I connect an external crystal to a 4000 series Xilinx. >----------------------- > >Hi, I have a few simple questions. I need to connect a crystal (not an >oscilator) to a XC4000. > >The desired frequency is 8Mhz. How should I wire this internally. Can I >take it in through any general purpose i/o pin, feed it through an inverter, >and out through another gp i/o pin back to the crystal. Which side should I >feed to a clock buffer, the in or out side of the inverter, does it matter? >And finally what size resistors and capacitors should I use? > 1) config an inverter between two pins 2) connect crystal between these pins 3) connect a 2.2 Meg Ohms resistor between these pins (parallel to crystal) 4) connect each pin via a capacitor to ground. try values arround 10 to 100 pico farads. 5) play around with the capacitor values until you have a circuit that self starts reliably. 6) I would recomend using the output side of the inverter as the signal to distribute within your design. 7) Read the app note on pages 9-30 and 9-31 > >According to the databook the XC3000 has special support for external >crystals, but this is lacking in the XC4000 series. How come? > In a product that is almost totally digital, the device test issues are such that it is highly desirable for the device to be totally digital. IC testers tend to be either digital, analog, or hybrid. It is hard to justify the expense of supporting analog test for one minor function on an otherwise digital product. Most people have enough trouble with self-starting oscillators that don't, that the oscillator modules are used in new designs much more often than sepparate crystals. The added expense is minimal compared to a design that fails to start up reliably. All the best Philip Freidin fliptron@netcom.comArticle: 952
In article <GEIRERT.95Mar31161214@villrips.idt.unit.no>, geirert@idt.unit.no (Geir Ertzaas) writes:
>
>How do I connect an external crystal to a 4000 series Xilinx.
>-----------------------
>
>Hi, I have a few simple questions. I need to connect a crystal (not an
>oscilator) to a XC4000.
>
>The desired frequency is 8Mhz. How should I wire this internally. Can I
>take it in through any general purpose i/o pin, feed it through an inverter,
>and out through another gp i/o pin back to the crystal. Which side should I
>feed to a clock buffer, the in or out side of the inverter, does it matter?
>And finally what size resistors and capacitors should I use?
>
>
>According to the databook the XC3000 has special support for external
>crystals, but this is lacking in the XC4000 series. How come?
>
>
Hi,
I don't know what is the best way to connect crystal to a XC4000
because XC4000 don't have special support for external crystals.
However, in XC4000, you have internal oscillator that you can use
for your design (Page 2-25 of the Xilinx Programmable Data Book
1994). If you work with schematics editor, use the Xilinx library
OSC4 component. This component provide internal clock signals that
you can use in applications where timing is not critical. The avai-
lable frequencies (8MHz, 500kHz, 16kHz, 490Hz and 15Hz) are process
dependant so the frequencies varies from one FPGA to an other.
If you work in HDL, instanciate also the OSC4 component.
Vincent Rowley
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vincent Rowley Laboratoire de Vision et
Systemes Numeriques
Universite Laval
Cite Universitaire
Quebec, Canada
e-mail: gel101@gel.ulaval.ca G1K 7P4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Article: 953I work as a Design Technologist at a childrens hospital and am currently looking into purchasing a development environment for PLD design. The system must be able to target everything from GAL/PAL's to higher end FPGA's and PLD's. The host environment is Windows (hopefully NT). I have heard of many different packages, but Data I/O's ABEL seems to be the most popular. What systems are available that are truly vendor independent? I have just started looking into the different device families from AMD, Altera, Lattice, and Xilinx, so I haven't really decided on a target family. It has taken much too long to sift through all the strange acronyms. Any suggestions, praises, and horror stories are welcome and appreciated. By the way, I also need a device programmer, so recommendations on that would also be helpful. Thanks in advance. Alex Luccisano Bloorview Childrens Hospital (416) 494-2222 x.347 e-mail: alucci@io.orgArticle: 954
We've finally managed to upgrade from v3.0 of ppr etc to v5.1. I've tried a few example designs on the evaluation board and these work fine. However, the standard way we use Xilinx 4000s is to attach them to a microprocessor system - downloading the Xilinx configuration from the microprocessor. We've been doing this for about two years now, and the code has proved reliable. We extract an C array from the lca file using makebits, makeprom and a few tools of our own. When we do this with the new software, I get the following two problems: 1) We have always had to write an extra byte at the end of the array to kick off the Xilinx. Under the old software if we did not do this, DONE remains inactive. Under the new software, DONE goes active before this byte is written. 2) If I comment out this final byte, the system comes up but does not seem to initialise in the same way - I have yet to look at the system using an analyser, but the first or second time the microprocessor accesses the Xilinx we get a timeout on the handshaking protocol. However, if I continue the remaining accesses are fine. I am most curious about (1). It is possibly (even probably) related to our C array extraction. However, I wondered if anyone else had experienced similar problems when upgrading. Any responses via mail please - I probably won't be able to read news for a week or so. _____________________________________________________________ Dr John Forrest Tel: +44-161-200-3315 Dept of Computation Fax: +44-161-200-3321 UMIST E-mail: jf@ap.co.umist.ac.uk MANCHESTER M60 1QD UKArticle: 955
jkubicky@cco.caltech.edu (Joseph J. Kubicky) writes: > > Now I've only been using the software for a few days, so maybe I > just haven't figured everything out yet, but I think I've been > badly ripped off and I would strongly urge anyone else considering > Abel to exhaust all other options first. > > My first problem has been with the hardware lock. I've never had a problem with the hardware lock. I thought they recently went to a software lock anyway. I doubt this is a widespread problem. > Ok, so I start using it on my laptop. Equation and state-machine > entry is adequate. Hierarchy support is ok. Note all steps are > slow, although this might improve dramatically with more memory. > Simulation is the 'base' $3000 version is limitted to what they > call Equation and JEDEC simulation. Basically you give it test > vectors and it simulates the design to tell you if there's a match. > As near as I can tell, though, there's no ability to do looping or > any conditional stuff in the test vector section which would > greatly simplify testing things like video waveform generators that > have long (around 1000) clock periods. Even the ability to start > the thing somewhere and just let it go for a while and view the output > would be great, but I think that is considered 'Functional Simulation' > and is thus only available via the very expensive Verilog simulator > option. It looks like I could probably do something equivalent if > I enter in a zillion vectors with lots of 'don't cares' on the outputs > (although I haven't tried this yet), but I don't relish the thought > of generating files of 1000 test vectors. If I'm way off base here, > please let me know and I might take some of this back. > 1 - There are examples of looping and other constructs in their (IMHO) excellent documentation. 2 - To generate don't cares in the outputs, just don't include the output in the test vectors. 3 - Here's why I think you're a bit off base. Simulating a PLD is different from simulating an ASIC. You don't need to get it right the first time, so there's no need to exhausively simulate everything. In my experience, about 100-200 vectors is enough for a simple device and 500-1000 for a complex device. That'll find most gross errors and typos. Then debug the rest in the circuit. I know people who don't bother at all with PLD simulation, and they still get their job done. 4 - Remember that the same test vectors are used by the programmer to test the physical part. That affects the simulation philosophy. Physical parts are never in a "don't care" state. > In closing: STAY AWAY FROM DATA I/O, ESPECIALLY ABEL!!! > > I'm using a competitor's part now. I would say from a flexibility, performance, usability, documentation, and support perspective that ABEL is all around superior. It is more expensive, but when you spread out a site-wide license on a workstation over tens of engineers and several projects, the cost is down in the noise.Article: 956
TestArticle: 957
kgold@watson.ibm.com (Ken Goldman) writes:- >3 - Here's why I think you're a bit off base. Simulating a PLD is different >from simulating an ASIC. >You don't need to get it right the first time, I disagree. If you don't get it right first time you are likely to end up with PCB modifications. The approach I take is to perform a 'does it look OK' simulation with the PLD tool and then run extensive worst-case PCB level simulation. Maybe your approach is different because you are only making one-offs, but there are a lot of systems out there that have not been worst-cased. >4 - Remember that the same test vectors are used by the programmer to test >the physical part. That affects the simulation philosophy. Physical >parts are never in a "don't care" state. For production I would strongly recommend automatic test vector generation. We are not happy until we have greater then 98% test cover. T.H.Article: 958
Okay folks I guess someone should address this. I am now a Manufacturer's Rep representing AT&T Microelectronics in Oregon. I used to be an FAE representing one of Neocad's resellers, and I know and respect highly many of the people at Neocad. Before that I was a digital designer for 12 years. This is not an April Fool's Joke. Xilinx HAS indeed purchased Neocad. While I cannot speak for the other FPGA vendors who had been aligned with Neocad; and while my statements are not necessarily AT&T party line, allow me to take my official hat off and state some personal opinions: IMHO: Xilinx has finally admitted what I've been claiming for some time, that Neocad had developed by far the best FPGA place and route tools in the industry. After taking a hard line for years that they wouldn't work with Neocad (the bright folks at Neocad reverse engineered the support for Xilinx with no help from Xilinx, and have been cleaning Xact's clock almost from day one) Xilinx couldn't afford to be handicapped any longer. Xilinx has finally acknowledged that their architectures -- more than anyone else's -- desparately need the superb placement and routing of Neocad. I think this is not even a controversial statement. Have you heard how "good" the 4025 is? AT&T some time ago recognized how good Neocad's stuff was and entered into a series of agreements with Neocad that ultimately secured full source code ownership rights. AT&T has been developing this code with Neocad for some time now, and will be releasing updates on a regular schedule, with some very exciting enhancements to come. In terms of interfering with AT&T's support, Xilinx bought the barn after we'd already taken the horses home. Its too bad that the market will lose the vendor-independent tool that Neocad has been. Many of our customers first discovered how good ORCA was when using Neocad to run benchmarks. Neocad's vendor independence enabled them to compare their designs on other FPGA architectures with AT&T ORCA and as result discovered the strengths of the AT&T ORCA. I'm not aware of a benchmark that ORCA has lost. When you're in that position, comparisons are good! In summary, this is certainly a major change in our market, but AT&T users should have no fear that they will lose this great technology. AT&T has the foundries, the architectures, the tools, the people, and the market momentum to continue to be very succesful in the high-speed, medium to high-density, super routable, low-power FPGA market for some time to come. I hope this answers some questions. For more information contact your local rep. (Okay, maybe my hat did slip back on a little at the end there. ;-) )Article: 959
Hi: I hope that this posting is in the right group... I am designing a prototype board using Altera's Flex 81188 FPGAs and I-Cube's IQ160 FPID (Field Programmable Interconnect Devices). The problem is that these devices do not have a socket to be used with them, thus I have to solder them on the board and this is something I want to avoid at this point of the design. I was told that another company (called Aptix) is also marketting programmable interconnect chips so any information on how to contact them or anything else I should know on programmable interconnect chips would be really appreciated. Thanks, LoucasArticle: 960
In article <D6Hy9p.EB1@oasis.icl.co.uk> trev@ss11.wg.icl.co.uk writes: >I disagree. If you don't get it right first time you are likely to end >up with PCB modifications. I wonder if anyone has stories about pinout changes they would care to share. In my personal experience, I used an Altera 5192 and made some very minor changes (for example, went from 4 2to1 muxes to a quad 2to1 mux) and had serious pinout changes. To their credit, Altera has come to recognize this problem and tout their new 9000 series as being more flexible with regard to pinout changes. I'm not sure exactly what architectural changes they made to accomplish this besides their so called fast track routing scheme. As I will discuss a little later on, routing is not the solution for pinout changes. Has anyone tried the Xilinx 5000 series? The versa ring idea sounds at first like a good idea but the details seem a little less flexible than one might expect. Xilinx makes a big deal about how routable their 7000 series is but I wonder if they are on the right track. Routing is only one part of the picture. These days all CPLDs have a statistically reasonable number of product terms per macrocell with various kinds of product term sharing arrangements. This means that a signal's placement in a particular macrocell is strongly dependent on the number of product terms it and its neighbors use, EVEN IF YOU HAVE 100% ROUTABILITY. If a macrocell is tied to one particular pin, then you've got posible pinout changes when product term usage changes. I am starting to believe that input and output switch matrixes are the best solution to pinout changes. Lattice has this to a limited extent but I have no personal experience with their parts. I have had a fair amount of experience with AMD's Mach4 series and am truly impressed with their flexibility. Lately I have been pre assigning pinouts for PCB layout convenience and fitting is still as easy as pushing the button. Another engineer I know put a very complex design into 3 of the 445 parts and was delighted at how well the parts worked. Disclaimer: this may sound like an ad for Mach4 but I'm simply excited about a part that seems to be in general very well thought out. I used to work at AMD but had nothing to do with the PAL division (aside from using their parts) and have absolutely zero financial interest in the company now. One thing I do find missing in the Mach4 is how to do a programmable address comparator. The Intel Flex/Altera Flash logic series has a very nice address comparator mode. (speaking of Altera, isn't it amazing how of the three parts in their Flash logic series, two of them AREN'T flash logic? I also like the way they can't decide if their Flex8000 logic is FPGA or CPLD.) -- Question Authority, but never shoot back.Article: 961
thomrscott@aol.com (ThomRScott) writes: > ... > In summary, this is certainly a major change in our market, but AT&T users > should have no fear that they will lose this great technology. AT&T has > the foundries, the architectures, the tools, the people, and the market > momentum to continue to be very succesful in the high-speed, medium to > high-density, super routable, low-power FPGA market for some time to come. I have several random thoughts on the subject: 1) How will AT&T support current NeoCad customers? Since we've already bought into Neocad to the tune of $8000 and it's eating a 100 Megabyte hole in my hard disk, will we have to buy another $5000 package from AT&T or will they support our current investment? 2) The market is now open for another multi-vendor FPGA tool. If any company was thinking of entering the market, this would be an excellent time. It also seems like AT&T would want to support that effort, since it keeps the door open for Xilinx cutomers to migrate to the ORCA product. (AT&T is probably prohibited from offering multi-vendor Neocad. If it isn't, then Xilinx shot itself in the foot.) 3) I don't know much about anti-trust laws, but it seems like this is the sort of situation where you would want one: Xilinx eliminates a competitor (Neocad), deals strong blows to three others, and sets the market back by eliminating useful tool (chip-independent design capabiliy). 4) This is the second time this has happened to the folks at NeoCad: The company was founded by the remnants of Cadnetix, which was, arguably, the best PC-board CAD/CAE system available back around 1987. It's competitor, Daizy, was losing market share and tried a hostile takeover of Cadnetix. The companies eventually merged, their products took on the worst features of both companies, and they eventually went down the tubes together. At the time we had about $400K invested in Cadnetix tools.Article: 962
In article <3lrhue$sf6@newsbf02.news.aol.com>, ThomRScott <thomrscott@aol.com> wrote: *Snip!* >code ownership rights. AT&T has been developing this code with Neocad for >some time now, and will be releasing updates on a regular schedule, with >some very exciting enhancements to come. In terms of interfering with >AT&T's support, Xilinx bought the barn after we'd already taken the horses >home. > *Snip!* Only time will tell..... So far from what I've read about this in the April 3rd edition of the Electronic Engineering Times is that AT&T only has the source code, not necessarily the expertise associated with the source. EricArticle: 963
louca@remus.rutgers.edu (Loucas Louca) wrote:
>
> Hi:
>
> I hope that this posting is in the right group...
>
> I am designing a prototype board using Altera's Flex 81188 FPGAs and I-Cube's
> IQ160 FPID (Field Programmable Interconnect Devices). The problem is that
> these devices do not have a socket to be used with them, thus I have to solder
> them on the board and this is something I want to avoid at this point of the
> design. I was told that another company (called Aptix) is also marketting
> programmable interconnect chips so any information on how to contact them or
> anything else I should know on programmable interconnect chips would be
> really appreciated.
>
> Thanks,
>
> Loucas
>
For an alternative, try Ironwood.... they make a plethora
of sockets for various devices, or look in the back of the flex
data book, it lists various manufacturer's of sockets....
Don't use the Altera sockets though.... I nearly lost my hair
using the damn thing.
Wassail,
MjodalfR
Article: 964
from: baykov@cslab.felk.cvut.cz
creating the new group: comp.arch.arithmetic. CORDIC
Dear Colleagues in COMPUTER ARITHMETIC area,
More than thirty five years ago a well-known paper of
JACK VOLDER
"The CORDIC trigonometric computing technique" was published
in IRE Transactions on Computers. Now about 1000 publications
related to this problem were issued.
The research on this subject is being performed in many coun-
tries: Australia, Canada, China, England, Germany, India, Is-
rael, Italy, Japan, Netherland, Romania, the former USSR, Taiwan,
France, Switzerland. Only in the USA similar research is made
in about 15 universities.
Everybody knows that, for instance all the coprocessors INTEL:
8087, 80287, 80387 etc., are based on CORDIC algorithm.
Taking into consideration large domain of Volder's algorithms
and their efficiency for VLSI implementation and for bringing
together researcher's activity in the indicated fields I offer
the creation of the new group:
comp.arch.arithmetic.CORDIC
This new group could coordinate researches in this area, exchange
of new results around the world.
Article: 965
Here is a statement I was given by AT&T ME with regard to the
Xilinx acquisition of Neocad:
(In brief; looks like no problem for ORCA support)
April 4, 1995
Dear Customers:
You may be aware of the recent announcement by Xilinx regarding their
acquisition of NeoCAD. In the fourth quarter of last year AT&T
Microelectronics and NeoCAD entered into a licensing agreement for
development of software to support our ORCA family of FPGAs. In order to be
prepared for any possible scenario, AT&T acquired access to the NeoCAD source
code as part of that agreement. Our CAD development team has been working
with that code, adding new features and enhancements. Under the terms of our
agreement with NeoCAD, AT&T is granted a full license to that source code in
the event NeoCAD is acquired by an AT&T competitor.
We have the source code, the people resources, and the financial commitment
to move forward with ORCA CAD development. For this reason, we feel this
acquisition should be transparent to our customers. AT&T will continue to
provide the highest density, highest-performance FPGAs in the industry. For
example, we'll be moving our ORCA product line to 0.35-micron technology
later this year, providing even higher-density and higher-speed devices.
We ask our customers to please work with us for the next few weeks as we work
through this transition.
Sincerely,
John T. Dickson
Vice President
Integrated Circuits
Background Statement
When AT&T Microelectronics decided not to second source the Xilinx 4000 family
of FPGAs, we accelerated the introduction of the ORCA family. That effort
involved accelerating the time to market for both the hardware and software
solutions.
Our plans required that we develop a CAD tool for the ORCA family within 18
months. At the point of introduction of ORCA, we realized that the NeoCAD
tools would allow us to further accelerate our CAD solution to the market.
In the fourth quarter of last year AT&T licensed the NeoCAD technology, and
has had access to the NeoCAD source code since that time.
The AT&T CAD development team is properly staffed and has been working with
the NeoCAD source code and is prepared to continue to develop the ORCA CAD
solution. AT&T will be providing a Version 7.0 release to its customers which
features support for the 2C04 through 2C26, with a beta patch for the 2C40,
along with other enhancements.
Questions and Answers
1. Can I call AT&T with questions regarding NeoCAD software support?
AT&T has been providing front-line support to our customers and will
continue to do so.
2. Who do I call to report software bugs, and who is responsible for
fixing them?
Our customers can call the AT&T Hotline at 1-800-327-9374 and we will be
fixing all bugs in future releases.
3. Can I still purchase NeoCAD software from AT&T?
Yes, AT&T will be offering all of the ORCA software solutions, including
evaluation copies. The comcodes remain the same but the new name for the
place and route tools is "ORCA Foundry".
4. I purchased the ORCA family module from NeoCAD and have a maintenance
agreement with NeoCAD. Will AT&T support me?
Yes, AT&T will support all customers designing with ORCA regardless of
who they licensed it from.
5. Does AT&T plan to continue to do new product introductions based on the
existing CAD environment?
Yes, as a result of the modular fashion in which NeoCAD has developed
their device-independent software, only 10% of the code is devoted to
any one family module; therefore, it's very easy for AT&T to develop and
introduce a new family module to support future AT&T products and
architectures.
6. How will this acquisition affect the schedules for future ORCA devices
from AT&T?
The NeoCAD tools allow for new devices to be added very quickly because
of the modular approach. Like the 2C ORCA family, AT&T defined the
architecture using AT&T proprietary development tools. The architectural
information was merged into the NeoCAD tool set. The development
methodology will allow for AT&T to quickly bring new products to
market in the same fashion. We will remain on schedule.
7. Why do you think Xilinx pursued this acquisition?
In our opinion Xilinx recognized the superiority of the NeoCAD solution,
much in the same way AT&T did a year earlier.
8. Will NeoCAD continue to offer their device-independent product to the
marketplace?
Contact NeoCAD.
Regards,
Ian Packer.
Bytech Electronics Ltd.
Article: 966trev@ss11.wg.icl.co.uk (Trevor Hall) writes: > kgold@watson.ibm.com (Ken Goldman) writes:- > > >3 - Here's why I think you're a bit off base. Simulating a PLD is > >different from simulating an ASIC. > >You don't need to get it right the first time, > > I disagree. If you don't get it right first time you are likely to end up > with PCB modifications. The approach I take is to perform a 'does it > look OK' simulation with the PLD tool and then run extensive worst-case > PCB level simulation. > Maybe your approach is different because you are only making one-offs, > but there are a lot of systems out there that have not been worst-cased. > I agree that one might occasionally forget an input, but it's been rare for me. And despite my division name, I am designing products. Since time to market is the key, I've found that it's faster to build a board than to spend months developing simulation models. Again. this is for boards with PLD's, not ASICs. Any other opinions. Are others doing full PCB simulation for cards without ASICs? Does it really result in a PCB with _zero_ errors, meaning you go straight to volume production with the first PCB? > >4 - Remember that the same test vectors are used by the programmer to test > >the physical part. That affects the simulation philosophy. Physical > >parts are never in a "don't care" state. > > For production I would strongly recommend automatic test vector > generation. We are not happy until we have greater then 98% test cover. > I agree with the 98% coverage (or better). But I usually try for that at the PCB level, not at PLD programming time. Other opinions. Is it common to use automatic test vector generation for PLD's? Does it find errors that a few hundred hand crafted vectors plus board level test would not find?Article: 967
IMHO vendors should post *pointers* to www sites, ftp sites, etc that have info such as that contained in: > AT&T FPGA #6 - Application Notes Take this for example - instead of just dumping today's special into comp.arch.fpga, post a pointer to a maintained list of FPGA app notes (along with net pointers to other FPGA info). If users *want* dumps of today's special, I suggest AT&T support a list server for FPGAs (like Altera & Xilinx) and post directions on how to sign up. Is there a vendor out there who could take the time to compile a list of net pointers to your FPGA info? If one of you will go first, I suspect others will also follow. This would also help greatly with the newbie questions. --- - Bill Wolf, Raleigh NC - My opinions, NOT my employer'sArticle: 968
In article <D6A8wK.D49@pts.mot.com>, ep520mi@pts.mot.com (MARK INDOVINA Xxxxx Ppppp) writes: |> Does Viewlogic and Xilinx support AIX? I would assume you could easily We have been using Viewlogic's Powerview on RS6k's running AIX for some time. Our machines are not PowerPC based though. -- Tipu ------------------------------------------------------------------------------- Name : Fateh Tipu Tie-Line: 862-1988 Tel: (914) 945-1988 Email : fateh@watson.ibm.com Post : IBM TJ Watson Research Center, P.O. Box 218, Yorktown Heights, NY-10598Article: 969
Hi, Could anyone help me out in simulating designs synthesized using Xilinx Xc4000 target libraries in synopsys? -JatanArticle: 970
In article <jshah.797109300@shazam.cs.iastate.edu>, jshah@cs.iastate.edu (Jatan Shah) writes: |> Hi, |> |> Could anyone help me out in simulating designs synthesized |> using Xilinx Xc4000 target libraries in synopsys? |> |> |> -Jatan |> |> You have any simulation platform in mind? It makes a difference.Article: 971
In <3lrtkp$626@remus.rutgers.edu> louca@remus.rutgers.edu (Loucas Louca) writes: > >Hi: > >I hope that this posting is in the right group... > >I am designing a prototype board using Altera's Flex 81188 FPGAs and I-Cube's >IQ160 FPID (Field Programmable Interconnect Devices). The problem is that >these devices do not have a socket to be used with them, thus I have to solder >them on the board and this is something I want to avoid at this point of the >design. I was told that another company (called Aptix) is also marketting >programmable interconnect chips so any information on how to contact them or >anything else I should know on programmable interconnect chips would be >really appreciated. > >Thanks, > >Loucas > > Aptix is located in San Jose, CA. They make programmable interconnect chips, as well as programmable system prototype boards, for which they support the 81188. They mount the 81188s on small boards which you can plug onto the board. You can also add other functionality to the board (memory, I/O ports, etc). Their phone # is: (408) 428-6200 Their address is: 2890 N. 1st St., SJ, CA 95134 I only know their western region sales manager, Robert Bicsek, and he should be able to tell you who to talk to for the Eastern region. I hope this helps, Kutlu Aricanli FAE Arrow/Schweber, San Jose kutlu@ix.netcom.com (408) 441-9700Article: 972
In article <3lu59n$13hf@watnews1.watson.ibm.com> kgold@watson.ibm.com (Ken Goldman) writes: >Other opinions. Is it common to use automatic test vector generation >for PLD's? Does it find errors that a few hundred hand crafted vectors >plus board level test would not find? I'm not sure what the purpose of test vectors for PLDs is anymore. Back when fuses were one-time things and the chip companies couldn't 100% test them, I suppose the chance of a defective chip was non-zero. With eraseable chips, is this still a problem? Or are we talking about design verification vs manufacturing test? -- Question Authority, but never shoot back.Article: 973
In article <3ldf7p$4cg@hustle.rahul.net>, ASM <someone@somewhere.com> wrote: > >It is now confirmed from reliable sources that Xilinx has taken >over Neocad this week to put an end to the competition for Xilinx >P&R tools. > >-ASM. Hmm, did they merge or did Xilinx eat ( buy ) Neocad??? ...inquiring minds want to know... -- /* Mark A. Indovina, Principal Staff Engineer mark_indovina@pts.mot.com */ /* MOTOROLA Strategic Semiconductor Operation, IC Technology Laboratory */ /* Mail Stop 63, 1500 Gateway Boulevard, Boynton Beach, FL 33436-8292 USA */ /* phone: 1-407-739-2379, fax: 1-407-739-3904 ...just speaking for me! */Article: 974
A note to all......
This is an opportunity for our community to introduce Reconfigurable
Computing to an audience which is diverse and has never heard of
using reconfigurable logic for applications, other than traditional
EDA use. We are looking for a half dozen or so qualified papers to round
out the session. Please contact me with abstract submissions.
_____________________________________________________________________________
CONFERENCE ON
"Using Reconfigurable Technology for Solving
the Computational and Signal Processing Bottlenecks"
This conference is part of SPIE's International Symposium on
INFORMATION, COMMUNICATIONS, COMPUTER &
TECHNOLOGIES, APPLICATIONS, & SYSTEMS
Symposium Chair: Arun Netravalli, VP Research, Bell Labs, AT&T
To be held as part of Photonics East '95
Philadelphia, Pennsylvania USA
22-27 October 1995
(over 5000+ attendees at Boston, Photonics94)
Conference Chair: John Schewel, Virtual Computer Corp.,
Program Committee: Peter Athanas, Virginia Polytechnic Institute
& State Univ., athanas@vt.edu;
Brad Fawcett, Xilinx Corp., brad.fawcett@xilinx.com;
Dave Kolmier, Data I/O Corp., davek@data-io.com;
John Watson, Viatek Corp., jlwatson@aol.com
Reconfigurable technologies are new and valuable tools for the
development and rapid prototyping of future products. With the
ever-changing standards in the marketplace and growing worldwide
competition, one must continually search for methods which
accelerate the time to market. Current reconfigurable hardware
platforms enable the use of this technology for electronic design
in rapid product development and performance acceleration.
This conference will present papers that illustrate applications
and techniques for solving computational and signal processing
bottlenecks using reconfigurable technology in product design
and software acceleration.
Papers are solicited in the following and related areas:
- reconfigurable digital components, and their use in
communications and image processing
- reconfigurable analog components, and their use in
communications and image processing
- applications and platforms utilizing reconfigurable
technology for rapid product development in communications and
image processing
- applications and platforms utilizing reconfigurable
technology for high-speed computing.
John Schewel
E-mail: jas@vcc.com
Fax: 818/342-0240
Phone: 818/342-8294
PHOTONICS EAST DEADLINES
Abstracts - as soon as possible
Manuscripts Due from Authors:
August 1, 1995 (on-site books)
September 25, 1995 (post-meeting books)
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