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
I want to program a daisy chain of XC4000, but I'm not sure what pins I must
connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND.
Can you help me?
Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused?
Thanks in advance for your help,
Fernando.
Article: 2051
I am working on a design which requires instantiation of the clock oscillator
in the Xilinx 4K library for Mentor Graphics. I would like to include this
information directly in VHDL without having to use Design Architect create
a top level sheet. Any help whether this can be done would be appreciated.
Thank,
Gerard Williams
(gerard@ee.umr.edu)
Article: 2052Re: cheap (free) fpga design software (VHDL I heard about a new software for Xilinx FPGAs that runs under Windows. The package that works together with Xact consists of design entry and simulation. For upgraders: Orcad and Viewlogic designs can be imported. At the moment I'm waiting for the suggestion of an application engineer who is testing the system right now. As soon as I've results or new infos I'll post a message. By the way: The name of the software is Susicad or Suzicad (or similar) cu DavidArticle: 2053
In article <453tph$drk@hptemp1.cc.umr.edu>, Gerard Williams III <gerard> wrote: > I am working on a design which requires instantiation of the clock oscillator > in the Xilinx 4K library for Mentor Graphics. I would like to include this > information directly in VHDL without having to use Design Architect create > a top level sheet. Any help whether this can be done would be appreciated. > > Thank, Unless I am mistaken, XC4000 does not have a crystal oscillator amplifier inside. XC3000 has it. Or maybe the new family of XC4000 have included it also? I successfully instantiated the clock oscillator on XC3000 before (1 year). The same rule should also apply to including modules generated by the schematic. The trick is, instantiate the oscillator amp in VHDL as a component. Synthesize it (I did it in Synopsys) and get your .xnf netlist. One thing to note, when you instantiate the component, remember to assign pin names (in/out) correspondingly to the names assigned to the macro's. Check the .xnf of your macro (hard or soft). In your case, the macro is gxtl and there is only one pin as the output, O: out std_logic. Merge your netlists. Remember to include the gxtl.xnf file. Then you can have what you want. Good luck! Y. Jason Hou, Qualcomm Inc., yjhou@qualcomm.comArticle: 2054
I have a few samples of MACH-445's, and would like to play with them in practice as well, but I haven't been able to find QFP SOCKETS for them. AMP 100 pin sockects are 4 x 25 pin rows ( square package ) , but AMD MACH 445 has 2 x 30 pin rows and 2 x 20 pin rows ... ( rectangular ) qfp .. If anyone knows any place making sockets for such package, would really appreciate to know who and where ... I just wouldn't like to design a small adapter-board and have the chips soldered just to play with them ... Appreciate your help, Ray SaarelaArticle: 2055
I am begining work on an ultrasound card to be implemented on a PCI card. We would like to find a PCI protoyping card to play with writing and reading a ram and then so we can work out the bugs in an FPGA interface. WE are planning on using the XC4000E series when xilinx comes out with it. However, we would really like a prototyping board that we could begin playing with in the next couple weeks. Under a $1000 would be desired. Thanks WIlliam Eatherton Washington UniversityArticle: 2056
Hi, there. I'm looking for VHDL models for classical Intel peripheral devices. (e.g. 8251,8253,8254,8255,8259,8237) I need VHDL models which will try to create and test large circuits on PLD or FPGA. If you have any suggestions, please contact me at the email addresses below. Thanks. ----- M.Imahashi CyVerse Co.,Ltd. e-mail: imago@leo.bekkoame.or.jp tel: +81-44-888-1944 fax: +81-44-888-1094 ----- Regards.Article: 2057
I notice XsimMake fails when I run it. I changed one thing in a design I'd
simulated and I ran Xmake&XsimMake again. However, Xsimmake failed in Check
program. After I "deltree" the s<design> directory and s<design>.vsm file I
ran XsimMake again. This time the program ended succesfully. Why ?
Of course, I do the Check & Export before running Xmake & Xsimmake.
Regards,
Fernando
Article: 2058In article <453pld$35m@diable.upc.es> <cha> writes: >I want to program a daisy chain of XC4000, but I'm not sure what pins I must >connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND. >Can you help me? > >Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused? > > Thanks in advance for your help, > > Fernando. > To daisy chain XC4000 chips, just take the dout of the upstream chip and connect it to the din of the next chip. connects the dout of the secon chip to din of the third chip, etc. all are fed the same cclk. Do NOT connect the HDC or LDC pins together, as they are outputs with both low and high drive. Connect the program pins together. Init pins can be tied together, and use a single pull up resistor. Done pins can be tied together with a single pull up resistor. (the done pins must be tied together if you will be using cclk_sync or uclk_sync startup modes, see page 2-29 of data book). There is also a less than totaly useful diagram that shows XC3000 devices in daisychain mode on page 2-126 of the data book. Hope this enough info for you (if not, ask for more) Philip FreidinArticle: 2059
In article <454bir$dnk@nnrp1.news.primenet.com> mercure@primenet.com (Ray Saarela) writes: > > I have a few samples of MACH-445's, and would like to play with them > in practice as well, but I haven't been able to find QFP SOCKETS for > them. AMP 100 pin sockects are 4 x 25 pin rows ( square package ) , > but AMD MACH 445 has 2 x 30 pin rows and 2 x 20 pin rows ... > ( rectangular ) qfp .. > > If anyone knows any place making sockets for such package, would > really appreciate to know who and where ... > > I just wouldn't like to design a small adapter-board and have the > chips soldered just to play with them ... > > Appreciate your help, Ray Saarela > > Test sockets for these types of packages are made by Yamaichi Electronics, and probably others. (408) 456-0797 partnumbers are IC51-xxxx-yyy-zzz. Call and get a catalog All the best, Philip FreidinArticle: 2060
Jonathan AH Hogg <jonathan@dcs.gla.ac.uk> wrote:
>it's still early days yet for hardware synthesis. no-one really
>understands what an HDL should look like. an HDL that's based on a
>software language is not a good starting point in my opinion. designing
>software and designing hardware are two different paradigms. since when
>did gate arrays have `for' loops? software is based on control flow,
>hardware is based on data flow.
Many HDLs have been designed "with hardware in mind". Typically they
only support the concurrent ("hardware") domain. Indeed, as "gate arrays
don't have for loops", why should there be a procedural ("software") domain?
Notable exceptions are Verilog and VHDL, that support both the concurrent
and the procedural domain. They are also the most popular HDLs. I believe
that's no coincidence. Although many hardware designers have difficulties in
understanding or accepting it, procedural statements such as for loops are
a great way to describe complex hardware, including combinatorial logic.
Procedural descriptions allow you to describe complicated dependencies
elegantly - but this doesn't prevent a synthesis tool from extracting
the maximal parallelism. These days, many `for' loops actually make it to
gate arrays!
Many people suggest that it is a disadvantage that Verilog / VHDL have
not been designed "with hardware (or synthesis) in mind". Personally,
I believe that this has been a key to their success, because the
language designers were not hindered by prejudices.
Regards, Jan
--
===================================================================
Jan Decaluwe === Easics ===
Design Manager === VHDL-based ASIC design services ===
E-mail: jand@easics.be ===================================
Tel: +32-16-270 400
Fax: +32-16-270 319 Kapeldreef 60, B-3001 Leuven, BELGIUM
Article: 2061In article <453pld$35m@diable.upc.es> , cha writes: >I want to program a daisy chain of XC4000, but I'm not sure what pins I must >connect. I don't know if it's neccesary to connect HDC & LDC to Vcc & GND. >Can you help me? > >Another question: in the slave chips, are the DONE, INIT & PROGRAM pins unused? Dare I just say "Read the databook"? _____________________________________________________________ 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: 2062
In article <44hvo5$l31@su102w.ess.harris.com>, John Noll <jnoll@su19bb.ess.harris.com> wrote: >In article lpo@marina.cinenet.net, kirani@cinenet.net (kayvon irani) writes: >> I'd like to know if any brave designer out there has tried to >> implement an FFT algorithm in an FPGA. Any one has experience >> with Mentor/Synopsys tools that take your algorithms and output >> VHDL synthesizable code? >> >> Regrards, >> Kayvon Irani >> Lear Astronics >> Los Angeles > > >I doubt it seriously. With the largest FPGAs around you would be lucky >to get one decent size >complex multiplier. If you could get a CMPLY to fit in an FPGA with some >room leftover (good >luck) then you could add some logic to read a RAM/PROM for the twiddle >factors and sequence >through the input data. Several passes and you would have an FFT. >I have given it serious >thought in the past as I have built many FFT processing boards and the answer, >so far, has always >been the same: not enough logic in and FPGA to do enough to make it worth >while. I have always >bought an FFT processor - Plessey, Sharp, LSI - there are many different >good options out there >depending on what you need. I have implemented an FFT butterfly in a Xilinx FPGA. The design is based on a DIT butterfly and uses 16 bit words in a bit serial architecture. The initial design was implemented in a XC4010PG191-6. It uses just over half of the 400 available clb's and was placed and routed using the standard Xilinx tools. The maximum clock rate for the butterfly is just over 20Mhz for the -6 grade part. While I am the first to admit that this is not breaking any land speed records, it shows that it can be done with the current technology. I am also looking at several other designs: one that reduces the number of CLB's by sharing some of the delay elements in the complex multipy, one which is a pipelined parallel version and a third which uses a completely different technique to compute the complex multiply. Initial investigation shows that all three designs are capable of fitting comfortably inside a single Xilinx device. Lurch lurch@ee.latrobe.edu.auArticle: 2063
>From: "Michael Pot" <michael@digitech.co.nz> >Organization: Digi-Tech Ltd, Wellington, New Zealand >To: "replys" <comp-arch-fpga@super.org> >Subject: Re:- Powerdown & Xilinx devices > >Hi Folks, > >When we recently needed to look into battery back etc, I searched through >lots of old xilinx manuls, Best of XCELL, & app notes, etc, to gleen more >info. Some of the old writings were quite open about how things were >done and what was going on. Not so much market speak, eh. Anyway, >this is what I concluded:- > >Xilinx once said in the XC2000 & XC3000 days that their powerdown >current was naff all. The function generators still work, so if it >isn't naff all, then make sure the powerdown state of the IOB etc is >not causing contention or oscilation within the device. If you look >at the way the IOB's and CLB flipflops appear to behave to the >configured logic, it is all quite nicely done. They must have given >quite a bit of thought to this in the early days. Xilinx FPGAs (specifically the XC3000 and XC3000A and XC3000L families) have the lowest power down current of any programmable logic device available. The Iccpd spec on page 2-155 of the data book shows 50 to 250 uA depending on product. At the bottom of the page it refers to devices in the range of 1 to 5 uA !!. In a CMOS device that is not switching, the only current drawn is a combination of parasitic leakage current, and circuit elements that have a DC current consumption. In XC3000 the DC current consumptions circuits are: I/Os that drive low into a load that is also passively/actively pulled high I/Os that drive high into a load that is also passively/actively pulled low TBUF lines that are driven low and high simultaneously (design error) TBUF lines that are driven low, and the pullup resistors are enabled Floating internal inputs (quite minimal effect. the purpose of the 'tie' function) Parasitic leakage. Assuming good circuit design, and no outputs driving loads that require DC current, and no TBUF fights, CMOS threshold inputs, a 3020 can have an Icco of 500 uA (page 2-155). Adding TTL threshold inputs bumps it up by a factor 20 to 10mA. This is a clue. When the device is placed in power down mode, the outputs are disabled, all the internal flipflops are reset, and the TBUFs are all disabled. Then if the device is still at 5V, then Iccpd is the parameter that is relevant rather than Icco. If you then lower VCC to as low as 2.3 V, the Iccpd will also drop below the 50 to 250 uA value, but I can't find any values in the data sheet. The 3100 and 3100A parts have a baseline of 8mA (page 2-179), and TTL thresholds adds another 6 for a total of 14mA. The baseline of 8mA is why 3100/3100A powerdown does not make much sense. These parts are much faster than the 3000/3000A, so these extra milliamps might have something to do with it. seems like a good tradeoff to me. > >They also said their configuration RAM was very reliable vs typical >SRAM (Cross coupled invrters, 5K, vs resistor pullup, 5M). The configuration memory cells in all these devices are much more like 74F374 flipflops rather than high density high speed SRAM cells. The cells have not been seen to be effected by alpha particles (page 2-107). Unlike highspeed RAMS, the config cells do not have to be fast, as they are all continuously being read out (to control the chip), so access time is not an issue. The tradeoff here is high reliability and low power consumption vs access speed. > >They state 3100 (and XC4000?) are not suitable for battery back, very >low current applications. Our tests have confirmed this. The >powered down current varies with temperture & probably from device to >device. Have they changed their configruation RAM implementation to >one that uses resistive pullup in order to shrink the die in newer >parts? If so, what type of config RAM does the XC5000 use? The XC4000 and XC4000A only support TTL threshold, and there is the clue in the XC3000 data sheet that this accounts for 6 to 10 mA. The XC4000H and the new XC4000E devices do allow the CMOS input mode, so maybe they are capable of a low power state. The XC5200 has an Icco of 15 mA (XC5200 data sheet, page 25), but also has TTL and CMOS thesholds, so it seems like the XC3100/3100A devices that have both thresholds, but don't have really low Icco. > >Michael > Philip FreidinArticle: 2064
On 8 Oct 1995, Jan Decaluwe wrote: > > Many people suggest that it is a disadvantage that Verilog / VHDL have > not been designed "with hardware (or synthesis) in mind". Personally, > I believe that this has been a key to their success, because the > language designers were not hindered by prejudices. > VHDL was designed with simulation in mind, not synthesis. It is a language for describing behaviour based on an event simulator. It was never designed for automatic generation of hardware. What we would call a specification language not an implementation language. :-jonathan -- Jonathan AH Hogg, Computing Science, The University, Glasgow G12 8QQ, Scotland. jonathan@dcs.gla.ac.uk http://www.dcs.gla.ac.uk/~jonathan (+44)141 3398855x2069Article: 2065
- I'm looking for a lots of large vhdl codes. - I have been develope a partition program runing on FPGA, which place a large circuit into several FPGAs. I feel lack of benchmark circuit because I don't design any circuit, Is there anyone who allow me to use a circuit, written in vhdl, designed by an angel. =) or let me know where can I get some benchmark circuit. ( ftp site list ok! ) The bigger, the better. -- email : kyung@dalab2.sogang.ac.krArticle: 2066
>>>>> "Marcelo" == Marcelo Hoffmann <Hoffmann@sri.com> writes:
In article <Hoffmann-290995100542@bic9.sri.com> Hoffmann@sri.com (Marcelo Hoffmann) writes:
Marcelo> I have been pleasantly surprised with the level of
Marcelo> research activity in the last couple of years on
Marcelo> reconfigurable computing (I went to the 1993 "FPGAs for
Marcelo> Custom Computing Machines Workshop" by the IEEE, and
Marcelo> there was very little work then...), and the growth of
Marcelo> commercial activity. Some folks, directly involved in the
Marcelo> business of making FPGAs, suggest that dynamically
Marcelo> reconfigurable computing components could be a billion
Marcelo> dollar market in 3-4 years...., while we hardly have the
Marcelo> terminology available now...
I would guess that the FPGA business will hit close to a billion this
year, based on past growth. So things on the general FPGA front are
moving along pretty well. We have quite a ways to go in the
reconfigurable computing venue, though. Most of the work that has been
published thus far is reminiscent of the VLSI craze in the 70s and
early 80s where there were many reports of application-specific
hardware. Much of the reported FPGA work is of that variety. This is
to be expected because people are still trying to figure out what is
*possible* with FPGAs. Don't get me wrong, BTW. Good reports of
application-mapping are still very important. What we probably need to
see more of are larger (or, at least complete) applications that are
based on FPGAs. This will give us a better idea of the actual performance
that can be achieved (which is quite good in many cases) and of the
actual costs.
Marcelo> Although I understand the potential of the hardware, what
Marcelo> would it take to make "software" available for these
Marcelo> reconfigurable elements? How do you go about
Marcelo> converting/originating code for hardware that is so
Marcelo> malleable? Is there a way to mix object-orientation,
Marcelo> with reconfigurable computing (specific configurations
Marcelo> for specific objects, that you change on-the-fly??) What
Marcelo> do you optimize: the "hardware," the "software" (terms
Marcelo> which become hard to separate with reconfiguration....)?
Marcelo> Who will develop the compilers, development tools...?
Marcelo> Will there be a "reconfigurable operating system" in the
Marcelo> near future?
Some of the work we are doing in run-time reconfiguration has a
decidedly object-oriented feel to it. I have hesitated to mention
that point though because it sounds too much like marketing hype.
If interested, check out http://splish.ee.byu.edu for some of our
papers. Look at the DISC ones (look at 'em all :-). You can also
check out our bibliography for more information. Most of the references
include abstracts.
Marcelo> Certainly the potential for customized-and-also-flexible
Marcelo> computing engines is very high, but who, and how long
Marcelo> will it take to develop the supporting infrastructure?
As I said there is still much work to be done here. Xilinx seems to be
quite interested in the reconfigurable logic market (whatever that
is). No doubt, if there is a market, they will come :-). Take a look
at the Teramac stuff at HP. They have done an excellent job of dealing
with a lot of the low level issues (place and route, partitioning) in
automated fashion thereby making it much easier to map applications to
hardware. It does not look much like software yet, but they have made
good progress nonetheless.
Marcelo> I am very intrigued by the possibilities of mixing
Marcelo> hardware/software concepts for more cost-effective
Marcelo> computing... Comments??
Some of the hardware-software stuff has been addressed by Ian Page's
group at Oxford. You can get to them from our home page on the
the related links page. Look for Oxford Hardware Compilation Group.
They use a variant of Occam called Handel. Because Occam was based
on CSP, it directly supports concurrency making it suitable for
hardware description at some level.
--
Brad L. Hutchings - (801) 378-2667 - hutch@ee.byu.edu
Brigham Young University - Electrical Eng. Dept. - 459 CB - Provo, UT 84602
Reconfigurable Logic Laboratory
Xref: netcom.com comp.arch.fpga:2208
Article: 2067Apparently still not the types to jump on a bandwagon too soon, View Logic will not be releasing a windows-95 compatible version of the pro-series till at least December. Unfortunately, I learned about this the hard way.Article: 2068
>When we recently needed to look into battery back etc, I searched through >lots of old xilinx manuls, Best of XCELL, & app notes, etc, to gleen more >info. Some of the old writings were quite open about how things were >done and what was going on. Not so much market speak, eh. Anyway, >this is what I concluded:- .. <snip> I would concur - Xilinx have become very conservative compared to the "old days". I guess we all know what the probable reason for this is. I spent a lot of time developing products which used battery backed-up Xilinxs (2018's). During the course of the development, I discovered that it is a far from simple exercise, and that there are many pitfalls which will cause sporadic loss of configuration in the field. This IMO was a result of Xilinx not "thinking it through" quite enough. After we had a working product selling for over a year, Xilinx changed mask on us, and disabled the "disable reprogramme" bit (this prevented "DONE" low from killing the configuration). We found out about this change the hard way (failures in the field) :-( If you are seriously considering a battery backup option, e-mail me & I'll summarise my findings - it is definately possible, but requires a bit more external circuitry than is obvious. ========================= Dave Mould =========================Article: 2069
In article <44cro0$b00@mailman.xilinx> Steven K. Knapp, stevek writes: >>Xilinx 6200 parts which are being introduced this fall/winter are supposed >>to address exactly that situation! i don't know the prices yet. >> >The Xxilinx XC6200 is the first FPGA family optimized for co-processing in >embedded system applications. > >You can find out more information about the Xilinx XC6200 FPGA on the Web at... Apart from the fact that the spec sheet has the diagram many of us put in our codesign papers, we (the public) know virtually nothing about this device. If it is to be released that soon, it is about time Xilinx released some datasheets. Since they haven't, I expect the any forthcoming data to be an anouncement, with the date when both silicon and design tools to be available at a long time in the future. Just think how long it is for 5k2's to be introduced - at the moment I can get hold of the silicon but no tools - and when were they announced? _____________________________________________________________ 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: 2070
[ Article crossposted from comp.cad.synthesis ] [ Author was richard taylor ] [ Posted on Tue, 10 Oct 1995 07:25:58 GMT ] [ Article crossposted from comp.lsi.cad ] [ Author was richard taylor ] [ Posted on Mon, 9 Oct 1995 15:54:32 GMT ] IEE Colloquium. -------------- Verification and Validation of Hardware/Software Codesigns The second one day colloquium in the IEE "Hardware/Software Codesign" series, 'Verification of hardware-software codesigns' is being organised by PG C2 (Hardware and Systems Engineering) and PG C6 (Systems Engineering for Automation) at Savoy Place, London on Tuesday 17 October 1995. Codesign refers to the simultaneous process of designing both hardware and software to meet some specified performance objectives. Unlike more traditional approaches to system engineering where the hardware and software partitions are relatively rigid, codesigns are characterised by flexible partitions that may be shifted to meet changing performance criteria. One consequence of this is that sophisticated and flexible specification, synthesis, verification & validation tools become essential to the design process. The first colloquium in this series addressed current research and practice in the area of partitioning codesigns. The purpose of this colloquium is to examine the verification and validation processes essential for effective hardware-software codesign. Papers being presented at this colloquium address the requirements for verification and validation procedures, formal models for describing codesigns, and practical tools for their realisation. Speakers have been drawn from across Europe. The morning session will concentrate on models and formalisms for codesigns. After lunch, experimental toolsets for design exploration, validation and verification will be presented. The colloquium will conclude with a panel session addressing the practical problems of migrating laboratory tools and techniques to industrial applications. For further details and registration, please contact Claire Coleshill, IEE, Savoy Place, London, WC2R 0BL, United Kingdom. Phone (44) 171 344 5419, Fax (44) 171 497 3633, Email : ccoleshill@iee.org.uk *************** Program ********************** Chair : R Taylor, Hewlett-Packard Laboratories, Bristol, England. 10.00 - 10.30 Registration and Coffee 10.30 - 11.00 T Ismail and A Jerraya, TIMA/INPG Grenoble, France, ``Design Models and Steps for Codesign'' 11.00 - 11.30 R Nicholls, Manchester Metropolitan University, Manchester, ``Verification or Validation of Hardware/Software Codesigns ?'' 11.30 - 12.00 N Jayaramn, University of Westminster, London, ``Verification of Real Time Systems - Issues and Perspectives'' 12.00 - 12.30 J Staunstrup, Technical University of Denmark, Denmark, ``Interface Models in Hardware/Software Codesigns'' 12.40 - 1.30 Lunch 1.30 - 2.00 M Sheeran, Chalmers Technical University, Sweden , S Singh, Glasgow University, Scotland , ``Ruby as a Basis for Hardware/Software Codesign'' 2.00 - 2.30 W Luk and Peter Cheung, Imperial College of Science, Technology and Medicine, London, ``A Toolkit for Exploring Hardware/Software Systems'' 2.30 - 3.00 W Rosentiel, University of T'ubingen and Forshungszentrum Informatik, Germany, ``Source Level Emulation to Bridge the Gap Between High Level Synthesis and Emulation'' 3.00 - 3.30 G Evans and D Morris, UMIST, Manchester, ``Validation and Verification of System Designs using MOOSE'' 3,30 - 3.45 Coffee 3.45 - 4.45 Panel Discussion ``Transferring Laboratory Techniques to Industry, Requirements, Aspirations and Practicality'', Chair : J Harrison, Hewlett-Packard Limited 4.45 Close -- Richard Taylor, __o o __o __o Hewlett-Packard Laboratories, Bristol, UK. `\<, \\_/\_, `\<,-`\<, rwt@hplb.hpl.hp.com O/ O O O O/----/ O phone : +44 (0) 117 922 9545 fax : +44 (0) 117 922 8925 -- Richard Taylor, __o o __o __o Hewlett-Packard Laboratories, Bristol, UK. `\<, \\_/\_, `\<,-`\<, rwt@hplb.hpl.hp.com O/ O O O O/----/ O phone : +44 (0) 117 922 9545 fax : +44 (0) 117 922 8925 -- Richard Taylor, __o o __o __o Hewlett-Packard Laboratories, Bristol, UK. `\<, \\_/\_, `\<,-`\<, rwt@hplb.hpl.hp.com O/ O O O O/----/ O phone : +44 (0) 117 922 9545 fax : +44 (0) 117 922 8925Article: 2071
Ryan, Let me add to your confusion, but from a different perspective - that of a "customer" for graduates from these schools. For the most part, the inputs you have gotten have been good advise. Let me add (or re-emphasize) some general points. 1. Go to a large, well-known school, if possible. One day you will be graduating and the breadth of opportunities (job or grad school) will be greater at a school with a better reputation. Some people may object to this, but, nevertheless, it is a fact. A significant fraction of undergraduates find part time employment in grad research programs, and summer intern jobs. Your chances for this are also greater at a well-known "Research" university. The only two schools you listed which fit into this catagory (no flames, please) are Penn State and Lehigh. 2. Your strong interests in photonics and/or polymers might be difficult to meet in most Materials Sci (or Eng.) curricula. Good polymer schools include MIT, U Mass, VIT and Michigan, in the East. Photonic efforts tend to reside in the EE departments, and mainly in graduate programs. The suggestion to look at Chem E for polymers is a good one. My own experience is that my interests in specialization changed greatly while in school, and even more after going to work. So make certain to get a strong, well rounded undergraduate degree, taking every opportunity to broaden your background with courses in areas such as EE, ChemE, PChem, CompSci, MechE and Statistics. 3. Good luck. Bob Sundahl IntelArticle: 2072
Hello, I want to use programmable logic devices (CPLDs and FPGAs) in my future developments and I need an overview of the market. Is there any program or database out there ? Thanks HansArticle: 2073
In article <45brb1$plq@fnnews.fnal.gov>, husby@fnal.gov says... > >Apparently still not the types to jump on a bandwagon too soon, View Logic >will not be releasing a windows-95 compatible version of the pro-series till >at least December. > >Unfortunately, I learned about this the hard way. Yes, us too. Is there a Viewlogic Users Group out there, so we don't _all_ have to find things out the hard way? It's not as if the documentation's getting better, either.... (Proseries does work under '95 and NT, except for PROSIM, the only tool to use Win32S. Aargh! So close, yet so, so far.... You'll need much patience, some mad dongle-redirecting code, and some more patience. _How_ can it take ProCapture 3 seconds to ask the dongle each time I load a new component? (On a twin P90, running NT 3.51 with 32M Ram) Roll on Workview Office, or is it just going to have all the 'features' that make each day such a joy (ahem...)? Steve, speaking for Steve, not SJ Research.Article: 2074
Do you still have the VHDL code used for the component instantiation? An example would greatly be appreciated.
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