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
Jonas Thor wrote: > Hello, > > As far as I know FPGAs have relatively high static power consumption > (a few mA) when comparing with an ASIC. Obvisouly we need more > transistors when implementing the same design in a FPGA than we need > in an ASIC. So the static power should be higher. > > Is this the only reason why FPGAs have a relatively high static power > consumption? > > Thanks, Jonas Thor i have seen fpga currents (actel, quicklogic) that are well under a mA; frequently under 200 uA. one reason for current is that this class of devices (antifuse) has a charge pump to bias on isolation fets. the older devices, early '90s, did have higher static currents, in the 2-3 mA range. rkArticle: 18426
[Snip gripes about not having "up" and pin number info in data book] > >This essential data belongs in the data book, and has been requested over > >and over for at least the last 10 years. [snip] Actually, you want the pin number info in a machine readable format, not in some printed table in the data book. I remember spending an afternoon making and printing my own version of those pictures. With a 3090 and a good printer and 11x17 paper you can just read the pin numbers in the tiny boxes. If we were BSing over a beer, I'd claim that you need to spend some time looking at the fine print anyway. It's not a big deal to make a paper copy while you are at it. You'll probably want it later anyway. Debugging the procedure earlier doesn't cost anything. -- These are my opinions, not necessarily my employers.Article: 18427
Hello Utku, First of all, thanks for you reply. Actually, we do generate the EDIF file from our own HDL tools, that's why you notice the hierarchy naming. We use our HDL for Image Processing operations. It works fine for most of the designs but as the operations get more complex and thus the designs bigger (EDIF files), we have this type of error. I suspect it is an overflow somewhere in Xilinx tools (big String or something like that). From your reply, I gather that may be we have to adopt another naming scheme (a more compact one). Best Regards, Khaled.Article: 18428
On Sat, 23 Oct 1999 10:19:41 -0700, "Haneef D. Mohammed" <haneef@mindspring.com> wrote: >We are pleased to annouce the Beta release of "VHDL Simili" Which VHDL textbook would you recommend, from the list at http://home.korax.net/~telic/books/hdl.htm ?Article: 18429
Ray
Thanks for responding to my posting. This is one of the more intelligent
newsgroups that I surf and I see you adding juicy tidbits quite often.
My application is a Synthetic Aperture Radar (SAR) image formation engine.
The truth is that the algorithm was originally implemented ten years ago in
dedicated hardware with all fixed point arithmetic. Since then however the
computation has been converted to an array of 16 PowerPC compute nodes from
Mercury Computer and all the calculation is done in floating point. Its
unlikely that my customer would consider different numerics because of the
analysis effort.
It is our objective to replace the 16 PowerPC nodes with one 3U cPCI board.
I'm thinking that the Virtex-E parts will give us the size and performance
to do floating point math. The floating point multiplier that I mentioned in
my first posting was done at the RTL level by working on the exponent,
mantissa and sign bits independently. I think this is more or less what you
are recommending nevertheless I always have doubts about the efficiency of
my designs.
Also, along the lines you are suggesting, FFT's can be implemented in block
floating point math where a single exponent is kept for the entire vector of
data in order to preserve dynamic range in what is otherwise a purely
integer operation. My feeling is that my customer would not even go for that
however.
So for now I'll just keep banging away on my basic floating point operations
in RTL. Hopefully I can hook them together at a somewhat higher level later
on. I'm setting up a web page now to publish those building blocks in source
code and I will post the URL here when I have it and I'll send you an email
as well.
Sincerely
Pete Dudley
Ray Andraka <randraka@ids.net> wrote in message
news:3811EEED.F4A47D55@ids.net...
> Does your application really need floating point? If it does, how much of
the
> design really needs to be floating point. For example, it is often useful
to
> separate off the exponent early in the chain, work the significand with
fixed
> point arithmetic and then renormalize, adjusting the exponent at the back
end.
> If you can do that, it saves a ton of hardware and usually reduces the
> truncation noise of floating point designs as implemented on
microprocessors.
>
> The easiest way to synthesize (that I know of anyway) floating point is to
> separately treat the exponent and significand as fixed point values,
pretty
> much as I described above. The degree the two pipelines talk to each
other
> determines how much 'floating point' hardware you have.
>
> If you break the stuff down into components, you can keep it an RTL level,
but
> your performance is likely to suffer unless you do soe floorplanning and
> perhaps some optimization for the placement of the registers to force a
> favorable partitioning of the logic among the LUTs. If this is a one-up
> design, then I'd do it at what I've been calling pipeline level RTL (in
other
> words be explicit as to what logic lies between each register and call out
each
> register in the design) so that you wind up with a synthesized pipeline
that is
> optimum for the device. Then use the floorplanner to place the pieces
> manually. That way there is no level structural instantiation. If it is
a
> piece that is to be replicated many times or is a macro, then spend the
extra
> time structurally building the small pieces so you can RLOC them in place.
See
> the recent posts by myself and Brian Davis on placement from within VDHL
> (hopefully you are using synplicity).
>
> One last thing, if you do the small pieces so that they are scalable, then
> you'll only have to do them once. The upper levels in the hierarchy, for
the
> most part at least, should look pretty much the same whether you are doing
the
> design structurally or at a pipeline RTL level - with the exception of the
RLOC
> attributes you'll be adding for placement.
>
> peter dudley wrote:
>
> > Hello
> >
> > I have a signal processing application that requires a large amount of
> > floating point arithmetic inside a Xilinx Virtex FPGA. Because the
function
> > is rather algorithmic and will require many configurations I want to
design
> > at a very high level.
> >
> > Does anyone know a convenient way to synthesize single precision
floating
> > point multiplications and additions in VHDL? Through my customer I have
> > access to a tool called Cossap from synopsys. Would that tool help?
> >
> > I have hand crafted a VHDL multiplier for the Virtex architecture that
runs
> > at 50MHz with two pipeline registers and two of these will fit into an
> > XCV50. Instantiating these structurally seems awkward for the scale of
> > design work we need to do.
> >
> > Thanks in advance for any ideas.
> >
> > Peter Dudley
> > Arroyo Grande Systems Incorporated
> >
> > Signal Processing in Hardware and Software
>
>
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930 Fax 401/884-7950
> email randraka@ids.net
> http://users.ids.net/~randraka
>
>
Article: 18430Gosh! I didnt even know that there were that many books on VHDL/Verilog. To be honest, I only know 4 of those books (I was actually involved with one of those books) and every one of them had atleast something that I liked. Now that I know that there are that many books, before I make a recommendation, maybe I should get and read a few more of these books. G.S. Vigneault <z180@hotmail.DOT.com> wrote in message news:xDISOHSr6Hmg6rql085uCe5Sr6fL@4ax.com... > On Sat, 23 Oct 1999 10:19:41 -0700, "Haneef D. Mohammed" > <haneef@mindspring.com> wrote: > >We are pleased to annouce the Beta release of "VHDL Simili" > > Which VHDL textbook would you recommend, from the list at > http://home.korax.net/~telic/books/hdl.htm ? > >Article: 18431
peter dudley wrote: > Ray > > Thanks for responding to my posting. This is one of the more intelligent > newsgroups that I surf and I see you adding juicy tidbits quite often. > My application is a Synthetic Aperture Radar (SAR) image formation engine. > The truth is that the algorithm was originally implemented ten years ago in > dedicated hardware with all fixed point arithmetic. Since then however the > computation has been converted to an array of 16 PowerPC compute nodes from > Mercury Computer and all the calculation is done in floating point. Its > unlikely that my customer would consider different numerics because of the > analysis effort. > That's a shame. Unfortunately I run into this mentality more often than I care to admit. You'll get a couple of FP multipliers on a Virtex, but you're not going to really see the processing advantage of the FPGA that way. I've seen extremely few applications that really needed floating point, and usually it was just in one part of the algorithm - averaging over a very large number of pulses with doppler pulse pair processing (weather radar) for example. The thing too is, that you could very likely wind up with less error with a fixed point implementation. That's especially true if you are doing reasonably large FIR filters or correlations. A DA approach performs the multiply-accumulates to the full precision of the inputs, so that the only truncation is in the final output. In your traditional uP solution, each tap is multiplied and accumulated with the other partial results one tap at a time. At each step, there is truncation of the product, and with floating point, the error gets shifted around. > It is our objective to replace the 16 PowerPC nodes with one 3U cPCI board. > I'm thinking that the Virtex-E parts will give us the size and performance > to do floating point math. The floating point multiplier that I mentioned in > my first posting was done at the RTL level by working on the exponent, > mantissa and sign bits independently. I think this is more or less what you > are recommending nevertheless I always have doubts about the efficiency of > my designs. > Take it a step farther. Accept denormalized data in your pipeline where you can. The less interaction you can get away with between the exponent and the significand, the smaller and faster your hardware will be. Specifically, you want to avoid renormalizing as much as you can because the barrel shifts get expensive. Would your customer entertain capturing the original fixed point hardware design? You'd be a lot closer to something reasonable in an FPGA. > Also, along the lines you are suggesting, FFT's can be implemented in block > floating point math where a single exponent is kept for the entire vector of > data in order to preserve dynamic range in what is otherwise a purely > integer operation. My feeling is that my customer would not even go for that > however. > Like I said, what a shame! > > > So for now I'll just keep banging away on my basic floating point operations > in RTL. Hopefully I can hook them together at a somewhat higher level later > on. I'm setting up a web page now to publish those building blocks in source > code and I will post the URL here when I have it and I'll send you an email > as well. > > Sincerely > > Pete Dudley > > Ray Andraka <randraka@ids.net> wrote in message > news:3811EEED.F4A47D55@ids.net... > > Does your application really need floating point? If it does, how much of > the > > design really needs to be floating point. For example, it is often useful > to > > separate off the exponent early in the chain, work the significand with > fixed > > point arithmetic and then renormalize, adjusting the exponent at the back > end. > > If you can do that, it saves a ton of hardware and usually reduces the > > truncation noise of floating point designs as implemented on > microprocessors. > > > > The easiest way to synthesize (that I know of anyway) floating point is to > > separately treat the exponent and significand as fixed point values, > pretty > > much as I described above. The degree the two pipelines talk to each > other > > determines how much 'floating point' hardware you have. > > > > If you break the stuff down into components, you can keep it an RTL level, > but > > your performance is likely to suffer unless you do soe floorplanning and > > perhaps some optimization for the placement of the registers to force a > > favorable partitioning of the logic among the LUTs. If this is a one-up > > design, then I'd do it at what I've been calling pipeline level RTL (in > other > > words be explicit as to what logic lies between each register and call out > each > > register in the design) so that you wind up with a synthesized pipeline > that is > > optimum for the device. Then use the floorplanner to place the pieces > > manually. That way there is no level structural instantiation. If it is > a > > piece that is to be replicated many times or is a macro, then spend the > extra > > time structurally building the small pieces so you can RLOC them in place. > See > > the recent posts by myself and Brian Davis on placement from within VDHL > > (hopefully you are using synplicity). > > > > One last thing, if you do the small pieces so that they are scalable, then > > you'll only have to do them once. The upper levels in the hierarchy, for > the > > most part at least, should look pretty much the same whether you are doing > the > > design structurally or at a pipeline RTL level - with the exception of the > RLOC > > attributes you'll be adding for placement. > > > > peter dudley wrote: > > > > > Hello > > > > > > I have a signal processing application that requires a large amount of > > > floating point arithmetic inside a Xilinx Virtex FPGA. Because the > function > > > is rather algorithmic and will require many configurations I want to > design > > > at a very high level. > > > > > > Does anyone know a convenient way to synthesize single precision > floating > > > point multiplications and additions in VHDL? Through my customer I have > > > access to a tool called Cossap from synopsys. Would that tool help? > > > > > > I have hand crafted a VHDL multiplier for the Virtex architecture that > runs > > > at 50MHz with two pipeline registers and two of these will fit into an > > > XCV50. Instantiating these structurally seems awkward for the scale of > > > design work we need to do. > > > > > > Thanks in advance for any ideas. > > > > > > Peter Dudley > > > Arroyo Grande Systems Incorporated > > > > > > Signal Processing in Hardware and Software > > > > > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka > > > > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 18432
In article <7usqvi$d7e$1@nntp2.atl.mindspring.net>, Haneef D. Mohammed (haneef@mindspring.com) wrote: > VHDL Simili is FREE with no gimmicks/strings attached and > without any limits on the number/size of your > VHDL files, simulation run time, etc. Are you planning on a Linux release? How about source code -- that would really be no-strings-attached. :-) -- David.Article: 18433
> Are you planning on a Linux release? How about source code -- that would > really be no-strings-attached. :-) Linux release? Maybe, maybe soon (no promises). Source-code? Maybe not :-)Article: 18434
The old XC3K devices (and some 4k devices) were static, but the dynamic Icc is still way above an ASIC because of all the extra nodes which are waggling. >Part of it comes from making the transistors 'leaky' so that they can >switch faster. An FPGA could be made with considerably lower power if >the fabrication process were tweaked for power instead of speed, but >they'd be a lot slower, and well, speed sells. Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 18435
Dear Guys, I am thinking of using Xilinx FPGA to implement a DAC. From the provided application notes XAPP154 (9/1999), an RC LPF has to be added. Could any one tell me if such a DAC can performs as well as an ordinary DAC (e.g. Rise/Fall Time, speed...)? Thankx. ChildArticle: 18436
Hi, I have a digital audio design that takes up about 60% of a Xilinx Spartan 30 chip (mixed schematic and VHDL) and I am having what I think are timing problems. I am processing digital audio from two different sources with two complete clock recovery and frame detection circuits and I am switching between the two sources depending on the relative error rates of each channel. The symptom is as follows - sometimes when I change a part of the design and re-compile and re-implement, the design doesn't work properly. Sometimes only one channel will work, and sometimes neither channel will work. I can't seem to narrow the problem down to one specific area of the circuit. My suspicion is that I'm not properly constraining the design for the the right timing relationships. I've put constraints on what I think are the most critical signals but I'm afraid I've not done enough. Does anyone have any suggestions of what might be causing this and what Xilinx tools I should be using to analyze the problem? (I'm pretty much a novice at FPGA design so any thoughts will help...) I appreciate any help you have to offer. AhrenArticle: 18437
As I remember Atmel also makes an In System Programmable (ISP) serial prom.
This would allow you to reprogram the nonvolitile memory right on the board
using some kind of download cable. This is really great for development and
production. I don't remember the part numbers.
Pete Dudley
Ulf Samuelsson <ulf.samuelsson@atmel.spamme.com.not> wrote in message
news:gLMN3.2747$lz4.5538@nntpserver.swip.net...
> You normally have some form of Non Volatile Memory in the system.
>
> At reset, the memory is read into the FPGA configuration bits.
> You may want to have a programmer for the NVM though.
> Atmel has the AT17 series of Flash configurators which is programmed
> using the ATDH2200E programmer also available from Atmel.
>
>
> --
> This is a personal view which may or may not be shared
> by my employer Atmel Sweden
> Ulf Samuelsson ulf 'a't atmel 'd'o't com
>
> Sharad Kumar skrev i meddelandet <38054e0a@apathy.ibsystems.com>...
> >
> >Hi,
> >
> >I am interested in downloading my design in the xilinx netlist file
format
> (.xnf) onto a Xilinx FPGA.
> >I wated to to know what kind of device programmers are available, what
> would be a good option and
> > where I can get more information about it. I am keen to use either the
> Xilinx -4000 series or the
> > Xilinx Virtex series of FPGA's.
> >
> >thanks, sharad
>
>
Article: 18438Get Your ass here And Watch http://www.hardcore.tmfweb.nl/Article: 18439
Matthias Fuchs wrote: > > Hi, > > I made a design with a mixed schematic/abel design entry. I am using > internal tristate busses. Because myinternal bus is not always driven > (by TBUFs), I added internal pullups to set the default level of > undriven busses to high. This works fine, even in the programmed fpga. > The only thing that I worry about are some warnings by the > bit-file-generator: > > WARNING:x45dr:42 - Netcheck: net DOUT<8> has TBUF mode drivers and > pullups, > pullups are not typically requried when TBUF mode, as opposed to > WIRED mode, > drivers are used. > > I got such a worning for every pullup I added ! Can I ignore them ? What > can I do, that these warnings disappear ? There aren't enough resources > left to drive the bus over TBUFs to get an default level/state. > > Thanks for advise > Matthias The warning is telling you that as long as you are not using the bus and tristate drivers as logic elements in a wired or/and configuration there is no need for the pullups. Of course they won't interfere with the operation of the bus, but they consume current and solve no problems. The only possible purpose I can see is that if you are driving an output pin with one of these busses it will follow the pullup when the bus is tristate rather than becoming undefined. The bottom line is that unless you are doing something unusual, there is no need for the pullups, and the warnings can be safely ignored. If anyone knows differently, please comment. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 18440
is the behaviour for strlen(NULL) defined? I tried in comp.lang.c but no answer. http://www.hardcore.tmfweb.nl/ thanxArticle: 18441
Naked Women Wrestling Site http://www.sports.tmfweb.nl/ Wanna have a break?Article: 18442
Matthias Fuchs wrote in message <38104F1C.D332194D@esd.h.uunet.de>... >...There aren't enough resources >left to drive the bus over TBUFs to get an default level/state. Don't forget the left and right edge IOB TBUFs! Jan GrayArticle: 18443
I have a few questions regarding the use of the Altera PCIT1 Core to build a 32-Bit PCI Target Interface. I am hoping that someone who has used the core successfully will be able to answer the following: 1) What global project logic synthesis options did you use for PCIT1 development? 2) How many Design Doctor warnings are common when synthesizing a PCIT1 core design? 3) What sequence did you use to initialize the PCIT1 core? 4) Did you notice any differences between the expected signal timing and the actual signal timing of the PCI Bus Signals? Background: As part of my Ph.D. research, I have been working on a design which incorporates a PCIT1 Core and I have been running into problems getting the design to work on Altera 10K series parts. The design simulates burst transfers successfully (using both functional simulation and back-annotated simulation) but when I download the design to an ARC Board, the design does not appear to work. When I attempt to write to a memory address mapped to the board, my test platform hangs. This indicates to me that the PCI interface starts processing the transaction but never completes processing it. It could be a problem with my application software, my device driver, or my hardware design but I suspect the problem lies in my hardware. The problem is most likely related to my local interface logic or related to my setting of the PCI Configuration Space. It could also be a subtle timing problem. In my simulations, I have noticed that the simulated timing of the devseln and trdyn signals differs slightly from the timing specified in the MegaCore User's Guide and from the timing specified in the PCI System Architecture reference book. Thanks in advance for your comments, Bill. ---------------------------------------------------------------------------- William Bishop, B.A.Sc., M.A.Sc. http://www.pads.uwaterloo.ca/~wdbishop ----------------------------------------------------------------------------Article: 18444
Hi, I am now using Altera's device, who states my design will get better performance if I use its LPM. Later, a engineer from Synplicity told me they do better than Altera's LPM. I got such words in their website. Does anyone has such experience? Will u please share your idea with me? thanks in advance! Regards, Peng Yun -- Posted via Talkway - http://www.talkway.com Exchange ideas on practically anything (tm).Article: 18445
The signal name is too long. delete some of the "1"s . Also, too much hierarchy. In article <7ur32f$i9v$1@news.qub.ac.uk>, Khaled BENKRID <kbenkrid@microsoft.com> wrote: >Hi all, > >I am using Foundation 1.5i software service pack #2. I am >getting the following Map error for some of my big designs: >" >FATAL_ERROR:basnc:basncbel.c:142:0.0 - NC_BEL name > ><inst_1/inst_11/inst_111/inst_1111/inst_11112/inst_111121/inst_1111211/inst_11 >112112/inst_111121121/inst_1111211211/inst_11112112111/inst_111121121111/inst >_1111211211111/inst_11112112111111/inst_111121121111113/inst_1111211211111131 >/inst_11112112111111311/inst_111121121111113111/inst_1111211211111131111/inst >_11112112111111311111/inst_111121121111113111112/inst_1/$I6/inst_1/inst_11/in >st_111/inst_1111/inst_11112/inst_111121/inst_1111211/inst_11112112/inst_11112 >1121/inst_1111211211/inst_11112112111/inst_111121121111/inst_1111211211111/in >st_11112112111111/inst_111121121111113/inst_1111211211111131/inst_11112112111 > 111311/net_11112112111111311_2> is too long Process will terminate. >Please > call Xilinx support." > >I had a look at Xilinx data base but did not find a similar case, sent a >query to Xilinx help, & still waiting! Has anybody experienced such a >problem? >Please help! >Cheers.Article: 18446
> a engineer from Synplicity told me they do better than Altera's > LPM. I got such words in their website. I believe this can only be the case if the LPM is done poorly. My understanding is LPMs are absolutely the best one can do, obviously, if done correctly. It is like writing code in assembly code, vs C code (or any high level language). The best performance can be had by using assembly code, but one can always write bad assembly code...Article: 18447
Matthias Fuchs <matthias.fuchs@esd.h.uunet.de> wrote: >I made a design with a mixed schematic/abel design entry. I am using >internal tristate busses. Because myinternal bus is not always driven >(by TBUFs), I added internal pullups to set the default level of >undriven busses to high. This works fine, even in the programmed fpga. >The only thing that I worry about are some warnings by the >bit-file-generator: > >WARNING:x45dr:42 - Netcheck: net DOUT<8> has TBUF mode drivers and >pullups, > pullups are not typically requried when TBUF mode, as opposed to >WIRED mode, > drivers are used. > >I got such a worning for every pullup I added ! Can I ignore them ? What >can I do, that these warnings disappear ? There aren't enough resources >left to drive the bus over TBUFs to get an default level/state. > >Thanks for advise >Matthias Since these are warnings, the answer is yes you can ignore them, since the chip will work. but .... The pullup will draw extra power in your design whenever you enable a tbuf that drives the tbuf line low. This is why you are getting the warning. Also, you may not know that there is another structure attached to each tbuf line, that guarantees that these lines do not float, and they always have a defined value of 1 or 0 (except for the silly case of you turning on two tbufs, and one drives 0, and the other drives 1). This other structure is called a "weak keeper" and it holds the tbuf line at the value it had before the tbuf was disabled. This means that when you disable a group of tbufs for a bus, the bus holds its previous value. In terms of strength, it goes like this: Tbuf driving low Tbuf driving high Pullup driving high Weak keeper driving previous value. So in your case, when the tbuf is disabled, the pullup wins, and the weak keeper has no effect. If you only care that the line doesn't float, and you aren't trying to use the all '1's pulled up bus for anything, remove the pullups. It will draw less power, and will hold the last value. The weak keepers cant be disabled, but all other drivers can over-ride them. >Rick Collins wrote >The warning is telling you that as long as you are not using the bus and >tristate drivers as logic elements in a wired or/and configuration there >is no need for the pullups. Of course they won't interfere with the >operation of the bus, but they consume current and solve no problems. Right >The only possible purpose I can see is that if you are driving an output >pin with one of these busses it will follow the pullup when the bus is >tristate rather than becoming undefined. not undefined, hold last value. >The bottom line is that unless you are doing something unusual, there is >no need for the pullups, and the warnings can be safely ignored. Agreed. >If anyone knows differently, please comment. Sure :-) Philip FreidinArticle: 18448
the first thing you should do is a static timing analysis. static timing analysis means every possible path (pad to ff, ff to pad and ff to ff) will be checked. if you are using the M1 Foundation Tool of Xilinx than you have a timing analyzer. the timing analyzer uses your timing constraints and reports which paths fails the constraints. you should have timing constraints for every clock and for the delay time at the pads. if you have multiple clocks in your design you should design the crossing from one clock to an other very carefully. this are the general things i can suggest you. -- ------------------------------------------ Kai Troester IMMS - Institut fuer Mikroelektronik- und Mechatronik-Systeme gGmbH Langewiesener Strasse 22 98693 Ilmenau Germany Tel: +49(3677)6783-42 Fax: +49(3677)6783-38 E-mail: kai.troester@imms.de -------------------------------------------Article: 18449
Im wandering, http://www.heemskerk.tmfweb.nl For all you guys
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