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
Hi, Thanks for the info. Can you give the location to find more info. on your board that you are talking about. -----Original Message----- From: Dave Vanden Bout [mailto:devb@xess.com] Posted At: 16 January 2000 07:48 Posted To: comp.arch.fpga Conversation: FPGA + ethernet Subject: Re: FPGA + ethernet David Barcelo wrote: > Does anyone know of an FPGA board with one (or even better, two) ethernet > ports? If not, how about a programmable router? > > Please email if you know of any. > Thanks, > -Dave Our XSV series of boards has a single Ethernet port. The PHY chip is an LXT970A and then a Virtex FPGA supplies all the higher-level MAC functions.Article: 19901
This is a multi-part message in MIME format. --------------EF4780E717CCCAA6E3B6C663 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit #YEO WEE KWONG# wrote: > Hi, > > Thanks for the info. Can you give the location to find more info. on > your board that you are talking about. Just go to www.xess.com and look in the catalog for the XSV Board. Click on the catalog link to see a preliminary picture of the board. There is also a link to the preliminary manual. You should also check the list of boards at www.optimagic.com to see if there are other boards with Ethernet links on them. > > > > Does anyone know of an FPGA board with one (or even better, two) > ethernet > > ports? If not, how about a programmable router? > > > > Please email if you know of any. > > Thanks, > > -Dave > > Our XSV series of boards has a single Ethernet port. The PHY chip is an > LXT970A > and then a Virtex FPGA supplies all the higher-level MAC functions. --------------EF4780E717CCCAA6E3B6C663 Content-Type: text/x-vcard; charset=us-ascii; name="devb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave Vanden Bout Content-Disposition: attachment; filename="devb.vcf" begin:vcard n:Vanden Bout;David tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;28560 fn:Dave Vanden Bout end:vcard --------------EF4780E717CCCAA6E3B6C663--Article: 19902
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BF60A7.EED8D67A Content-Type: text/plain #YEO WEE KWONG# wrote: > Hi, > > Thanks for the info. Can you give the location to find more info. on > your board that you are talking about. Just go to www.xess.com and look in the catalog for the XSV Board. Click on the catalog link to see a preliminary picture of the board. There is also a link to the preliminary manual. You should also check the list of boards at www.optimagic.com to see if there are other boards with Ethernet links on them. > > > > Does anyone know of an FPGA board with one (or even better, two) > ethernet > > ports? If not, how about a programmable router? > > > > Please email if you know of any. > > Thanks, > > -Dave > > Our XSV series of boards has a single Ethernet port. The PHY chip is an > LXT970A > and then a Virtex FPGA supplies all the higher-level MAC functions. ------ =_NextPart_000_01BF60A7.EED8D67A Content-Type: text/x-vcard; name="devb.vcf" Content-Disposition: attachment; filename="devb.vcf" Content-Description: Card for Dave Vanden Bout begin:vcard n:Vanden Bout;David tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;28560 fn:Dave Vanden Bout end:vcard ------ =_NextPart_000_01BF60A7.EED8D67A--Article: 19903
Ray Andraka wrote: > Many > many years ago I tried using a blinking incadescent lamp (you know, the kind > with the bimetallic strip in it) to generate a random gate for a counter to > get random numbers (this was in the mid '70's). > > Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a > > counter or linear shift register until the pin goes high sometime > > after powerup (or after being pulled low tristate-wise.) Another proposal: Use a "radio" Nearly everywhere you will have a strong MF radio station thus you get a strong signal. Use a triggering input and sample only now and then (below speach frequency).Article: 19904
Hi, We need to define a design flow and projects definitions for open hardware designs something like what companies are doing. For example at the beginning they study the market and check what is missing then starts defining the project and the spec then the reset of design flow something like top down or down top flow and many kind of documentation should be considered scheduled and followed in particular order and how the project is divided into smaller parts and so on. What do you suggest for these kind of projects? For more information and discussions pls. join us at OpenIPCore mailing list Thanks Jamil Khatib OpenIP Organization http://www.openip.org OpenIPCore Project http://www.openip.org/oc OpenCores Project http://www.opencores.orgArticle: 19905
I have searched the net for a viterbi decoder implementation ( vhdl source for FPGAs). I could not found any resources for free. VHDL codes for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much expensive. So, why is this staff so expensive? I mean viterbi decoders are widely used and someone can easily find a cheap decoder IC. Can somebody explain the reason? Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the incoming data rate (kbits/s or Mbit/s)the main factor. I have found many C codes for viterbi decoders. How can I use them to translate to VHDL or Verilog for FPGAs? Thanks a lot Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19906
arsh@x-stream.se wrote: > Dear All! > > I wonder if anyone know which FPGAs can be partly reprogrammable, so > that one may reconfigure a part of the device while the rest of the > device is still functioning. Has anyone of you any experience from this. > > Also I wonder if anyone knows what kind of research is being done in > this area. Has anyone considered the concept of self-modifying blocks > in FPGAs. You can visit my page to check about self-modiying logic at http://www.geocities.com/SiliconValley/Pines/6639/fpga > > Any information is greatly appreciated! > > Regards, > > Arvind Shah > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 19907
Hello Ray,
Ray Andraka wrote:
> The sequence repeats after 2^(n-1) counts for a
> maximal length sequence. See xilinx application note xapp052 for more
> details on implementation and description of the counters. The
> distribution of the output is uniform, with a slight bias due to the all
> '1's state being an illegal state of the LFSR counter.
>
> Note, that these really only produce one random bit per clock, as the
> remaining bits are time delayed copies of the first bit.
A few things on the subject can be noted:
Many LFSRs use only XOR gates to generate the pseudorandom sequences and in
this case, the all-0 state becomes the illegal state (thus resulting in the
2^n - 1 states); if all 2^n states are desired, then either the number of
bits used in the LFSR may be increased by one (then of course, states will
occur twice in a complete cycle) or a NOR may be done with every bit but the
MSB, then XOR'ed with the feedback (which is usually taken on the MSB).
Xilinx app note 052 shows a LFSR structure known as "type 1", where the XOR
(and other logic) gates introducing the pseudorandomness are not part of the
shift register itself; there is another structure called "type 2" which
respects the same polynomial expression but the XOR gates are placed
*within* the shifting path.
Type 2 LFSR will produce the same states but in a different order that will
eliminate the "time-delayed copy of the first bit" effect. Visually, they
look much more "random" than type 1 LFSRs since the variations occur on
multiple bits. Additionally, the combinatory delay introduced by type 2
LFSRs is usually much lower; the only delay introduced is the delay through
only one XOR.
Regards,
Etienne.
--
______ ______
*****/ ____// _ \_\*************************************************
* / /_/_ / /_/ / / Etienne Racine, Hardware Designer *
* / ____// __ /_/ Visual Systems Engineering *
* / /_/_ / / /\ \ \ CAE Electronics Ltd. *
*/_____//_/_/**\_\_\*************************************************
Article: 19908Engineering time to develop, verify and support a core is not insignificant. Consider what the cost would be for you to roll you own and use that as a measure of the core's real cost. I think with that in mind, even at the prices you cite, the cores are a bargain. That is assuming they are fully verified on the target architecture, and that they come with some semblance of support. The FPGA cores business is a tough business to make money in, for some reason people expect the cores to cost next to nothing, and yet perform better than anythng they could develop in house. What you are buying with a core is time to market, and possibly design expertise you don't have in house. Bottom line is you gets what you pays for. mehmeto@my-deja.com wrote: > I have searched the net for a viterbi decoder implementation ( vhdl > source for FPGAs). I could not found any resources for free. VHDL codes > for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much > expensive. So, why is this staff so expensive? I mean viterbi decoders > are widely used and someone can easily find a cheap decoder IC. Can > somebody explain the reason? > Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the > incoming data rate (kbits/s or Mbit/s)the main factor. > I have found many C codes for viterbi decoders. How can I use them to > translate to VHDL or Verilog for FPGAs? > > Thanks a lot > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -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: 19909
Quite true. In Xilinx FPGAs, and other places where you might use a small memory as a circular queue, the type 1 is more advantageous since there are fewer places you need access to the shift register. In many FPGAs, a two input logic function has the same delay as a four input function, so the speed difference is non-existant. The sequence produced by the type 2 is the same as the sequence generated by type 1 if you were to invert some of the outputs from the type 1 LFSR, so while the output of a type 2 may appear more random, adjacent bits still have a hig degree of correlation. Etienne Racine wrote: > Hello Ray, > > Ray Andraka wrote: > > > The sequence repeats after 2^(n-1) counts for a > > maximal length sequence. See xilinx application note xapp052 for more > > details on implementation and description of the counters. The > > distribution of the output is uniform, with a slight bias due to the all > > '1's state being an illegal state of the LFSR counter. > > > > Note, that these really only produce one random bit per clock, as the > > remaining bits are time delayed copies of the first bit. > > A few things on the subject can be noted: > > Many LFSRs use only XOR gates to generate the pseudorandom sequences and in > this case, the all-0 state becomes the illegal state (thus resulting in the > 2^n - 1 states); if all 2^n states are desired, then either the number of > bits used in the LFSR may be increased by one (then of course, states will > occur twice in a complete cycle) or a NOR may be done with every bit but the > MSB, then XOR'ed with the feedback (which is usually taken on the MSB). > > Xilinx app note 052 shows a LFSR structure known as "type 1", where the XOR > (and other logic) gates introducing the pseudorandomness are not part of the > shift register itself; there is another structure called "type 2" which > respects the same polynomial expression but the XOR gates are placed > *within* the shifting path. > > Type 2 LFSR will produce the same states but in a different order that will > eliminate the "time-delayed copy of the first bit" effect. Visually, they > look much more "random" than type 1 LFSRs since the variations occur on > multiple bits. Additionally, the combinatory delay introduced by type 2 > LFSRs is usually much lower; the only delay introduced is the delay through > only one XOR. > > Regards, > > Etienne. > -- > ______ ______ > *****/ ____// _ \_\************************************************* > * / /_/_ / /_/ / / Etienne Racine, Hardware Designer * > * / ____// __ /_/ Visual Systems Engineering * > * / /_/_ / / /\ \ \ CAE Electronics Ltd. * > */_____//_/_/**\_\_\************************************************* -- -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: 19910
In article <tUL80GAvG+f4EwE7@matter200.demon.co.uk>, dmac <dmac@cutme.matter200.demon.co.uk> wrote: > > Hi all, > > I support Peter's position that junction temperature is the real > measurement point. It's the silicon that howls and dies when it gets too > hot, not the air just above the case, so for me I want to know params at > junction temps not air temps. BTW, which ambient are we talking about > here, the one 1mm, 10mm or 50mm from the chip body, the fan exhaust > temperature or etc, etc. > > Working from the case temp is, i think, the most accurate way of > assessing thermal & tech params and Xilinx support that by publishing > appropriate thermal figures. The current data book has figures for both > theta-jc and theta-ja on all packages so junction temps are easy to > calculate. Alternatively, by placing a low mass probe on the case you > can find out what the junction is doing and measure the cooling > effectiveness of airflow or increased heatsinking. > > I feel that ambient temp reporting is just so much finger in the air, > it's valid for the precise conditions used in the test and no <real> > other. > > Dave McLeod > > -- > dmac > Again, I agree that the junction temperature is the correct way to rate an FPGA. I am not trying to argue that Xilinx should specify parts using ambient temperature, because it is obvious that the power dissipation is unknown by Xilinx. The point that I was trying to make is that the 15 degree margin assumed by the timing specifications (relative to normal rated ambient operating temperature ranges) can easily be exceeded by an FPGA with a fast clock. As a result, the engineer is responsible to know what the junction temperature is. The real question is how to do this with a high level of confidence. How many FPGA's do you have to measure, and from how many lots, before you can say that you have adequately characterized power consumption and thermal performance for any given design? What is the correct measurement point on each package for the theta JC? Does device orientation affect the specifications or readings? What effect does PCB construction have? How much margin needs to be applied to account for tolerance in theta JC and theta JA specifications? Can we take reliable temperature measurements using input ESD protection diodes? I'm sure that Xilinx has a complex and proprietary methodology for establishing timing specifications based on characterizing devices under carefully controlled conditions. The problem is that this methodology does not extend into the field, where the application junction temperature has to be known and characterized. I'm not saying that this is the responsibility of Xilinx, but it sure would be nice if Xilinx would provide a guideline or methodology, including measurement points and recommended apparatus, in order to help engineers close the loop. -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19911
Greetings This is semimonthly announcement of Verilog FAQ. Verilog FAQ is located at http://www.angelfire.com/in/verilogfaq/ Alternate Verilog FAQ is an attempt to gather the answers to most Frequently Asked Questions about Verilog HDL in one place. It also contains list of publications, services, and products. Alternate Verilog FAQ is divided into three logical parts. Part 1 : Introduction and misc. questions Part 2 : Technical Topics Part 3 : Tools and Services What's New section outlines the changes in different versions and announcements. Links connects you to related informative links in internet. Your suggestions to make this FAQ more informative are welcome. Rajesh Bawankule (Also Visit Verilog Center : http://www.angelfire.com/in/rajesh52/verilog.html ) Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19912
My Xilinx distributor screwed up and I'm in desperate need of a Xilinx Virtex FPGA for a prototype so I can procede with de-bug. Earliest Xilinx says they can get me one is Feburary something. Full part number is XCV400-6FG676C although faster speeds (-5 or -4) or indistrial would be ok. Need one or two IC's. They must be new, never mounted, and in vaccume packing. Please respond via email: dan_kuechle@i-tech.com Thanks DanArticle: 19913
Mehmet(?), This stuff is expensive because staff is expensive :-). Design, implementation and verification of such a core takes time and on top of that such cores are valuable to the buyers so the price. You can take the C code and write verilog yourself too or hire me to do it ;-) mehmeto@my-deja.com wrote: > I have searched the net for a viterbi decoder implementation ( vhdl >source for FPGAs). I could not found any resources for free. VHDL codes >for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much >expensive. So, why is this staff so expensive? I mean viterbi decoders >are widely used and someone can easily find a cheap decoder IC. Can >somebody explain the reason? > Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the >incoming data rate (kbits/s or Mbit/s)the main factor. > I have found many C codes for viterbi decoders. How can I use them to >translate to VHDL or Verilog for FPGAs? > >Thanks a lot > > >Sent via Deja.com http://www.deja.com/ >Before you buy. muzo Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)Article: 19914
Greg Neff wrote: > <snipped from his *excellent* post which was a bit too long to quote> > > Can we take reliable temperature measurements using > input ESD protection diodes? > I've done some experiments along these lines and have to say that it's pretty tricky to get believable measurements. Some notes: 1) The small changes in diode voltage drop due to temperature are hard to measure accurately in a high-noise environment. Using an input diode, either the power or ground rail are part of the measurement circuit, and they have their own noisy voltage drops due to bond wire resistance etc. The 2-wire connection used on Virtex, Pentium, etc. is MUCH better. Better yet would be an on-chip temperature-to-digital (pulse width or frequency) converter like the Maxim 6576/77 parts. 2) At least for the (non-Xilinx) chip I was playing with, the resistance in series with the protection diode had a fairly large temperature coefficient, opposite in sign from the diode, thus reducing the voltage swing over temperature even further. 3) Relating the diode measurement to the actual junction temperature requires calibrating the part - I used a water bath, gradually raising it to boiling while taking measurements. This is awkward. 4) Another experiment involved painting thermochromic liquid crystals (they change color with temperature) onto the die of a de-lidded device. It was easy to see large temperature gradients across the chip, and quite easy to see hot spots, making me a bit pessimistic about the usefulness of a single point measurement, especially when taken at the edge of the die (usually the coolest part). My worry about hot spots is that usual high-speed FPGA design practice requires that the highest speed stuff be packed together in a small area, with lower-speed logic spread out over the remainder of the chip. If the heat spreading is poor, some areas could get very hot indeed. What we need is a temperature sensor per CLB which can be read while the part is operating, and of course some way to feed the results back into the place and route software to spread things out without violating timing constraints :) 5) I'll skip my regular (yearly?) rant about the lack of accurate power estimation tools (like for example PowerMill, etc.) for FPGAs. And then if they did exist, I'd be moaning about the cost. Better leave it alone ... Oh, here's a PowerMill description: http://www.synopsys.com/products/etg/powermill_ds.html regards, Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 19915
In article <85rla5$722$3@jetsam.uits.indiana.edu>, Greg Alexander <galexand@sietch.bloomington.in.us> wrote: >I agree 100% with what you have to say about open source there. Open >Source is the embodiment of the "okay, it's just a hack, but it works and >that's good enough for me, and nobody else has written it, so let's submit >this for mass distribution" design methodology. It works, and there's >nothing stopping a random third party from going back and cleaning it up, >but it certainly doesn't guarantee any better code than popular commercial >design methodologies. It does, however, provide a limiting function; if the code is bad, it will be much more likely to get fixed, much sooner. Also, as a prospective user, you can, if you really want, hire a good programmer to spend a day skimming the code and give you a pretty good feel for the quality of the code; you don't just have to look at a rigged demo and wonder. -s -- Copyright 1999, All rights reserved. Peter Seebach / seebs@plethora.net C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon! Consulting & Computers: http://www.plethora.net/ Get paid to surf! No spam. http://www.alladvantage.com/go.asp?refid=GZX636Article: 19916
Hi, I was cleaning up my hard disk and accidentally deleted all Translogic's .ini files (menu.ini, eale.ini. ease.ini etc). Can anybody send me his .ini files of HDL ENTRY ver 4.0x ? They should be the same. best regards, Dave Man Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19917
Don't forget the built in OSC that has a very poor tempco. You could possibly substitute the internal OSC for the RC discussed below. Dave Decker (I have only one h in my emal adr) >snip >Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a >counter or linear shift register until the pin goes high sometime >after powerup (or after being pulled low tristate-wise.) Use an X7R >cap, which has a terrible TC. If the RC time constant is long, the >result (PRN reg contents, or some counter LSBs) is fairly random. > >Refinement: depending on some number of LSBs of the prievious timeout, >reset the cap using a reset time scale that results in only partial >discharge, then repeat the charge time thing. Serious chaos theory >results, and something like real randomness can be had for just the >price of one RC. > >John > >== > >A little nonsense now and then, >is cherished by the wisest men. > >- Willy WonkaArticle: 19918
Hi all, My current FPGA design is based on Altera Flex 10k. I'm designing using VHDL & schematics. However it seems that Max+plus2's VHDL compiler is not strong enough. It can't do things like triggering up and down on the same signal on 2 separate different processes. I tried xilinx foundation series's vhdl compiler (synopsis??) & synplify and it works. Why is it that max+plus2 is so much expensive than foundation series by xilinx but the vhdl compiler is so weak? I saw that there are quite a number of VHDL tools (compiler & simulator & analysis tools) ard... synplicity, viewlogic, exampler, leonardo, modelsim, synopsis, cadence.... Among all, i have used synplicity and found that it is cheap and fast.. for those who have tried the rest before, can you pls give a short review of it in terms of ...the COST, speed, compatibity, powerful... ?Anyone has any preference, pls feel free to share... Thank you!! MKArticle: 19919
Call for Papers
The Second NASA/DoD Workshop on Evolvable Hardware
July 13 - 15, 2000
Silicon Valley, California, USA
http://ic.arc.nasa.gov/ic/eh2000
Sponsored by:
National Aeronautics and Space Administration (NASA)
Defense Advanced Research Projects Agency (DARPA)
Hosted by:
NASA Ames Information Sciences and Technology Directorate
JPL Center for Integrated Space Microsystems (CISM)
Evolvable hardware is an emerging field that applies simulated
evolution to the design and adaptation of physical structures,
particularly electronic systems. The Second NASA/DoD Workshop on
Evolvable Hardware (EH-2000) will bring together leading researchers
and technologists from academia, government, and industry to discuss
advances and the state-of-the-art in this field.
Evolvable hardware techniques enable self-reconfigurability and
adaptability of programmable devices and thus have the potential to
significantly increase the functionality of deployed hardware systems.
Moreover, these techniques have the potential to reduce costs by
automating numerous design and optimization tasks encountered in
engineering design.
A focus of this year's workshop is on real-world applications of
evolvable hardware. Current application areas include adaptive and
reconfigurable computing, circuit and antenna design, and evolutionary
robotics. Evolvable hardware methods could also be effective in
dealing with increased complexity and reliability requirements in
areas such as sensors, MEMS, biomolecular design, quantum computing,
and nanoelectronics.
Topics to be covered include, but are not limited to:
- Evolutionary hardware design (including mechanical and robotic
systems, electronic circuit synthesis)
- Real-world applications of evolvable hardware
- Co-evolutionary methods
- Online and offline evolution methods
- Hardware/software co-evolution
- Testbeds and evolutionary design automation tools
- Self-repairing hardware
- Self-reconfiguring hardware
- Embryonic hardware
- Morphogenesis
- Novel devices and hardware platforms suitable for evolution
- Adaptive hardware, adaptive computing
- Adaptive flight hardware
Important Dates:
Submission deadline: March 17, 2000
Author notification: April 17, 2000
Camera ready manuscript deadline: May 15, 2000
Workshop: July 13-15, 2000
Submission of Papers:
Please see the workshop web page at http://ic.arc.nasa.gov/ic/eh2000
Chair: Jason Lohn, NASA Ames Research Center
Co-Chair: Adrian Stoica, Jet Propulsion Laboratory
Program Co-Chairs:
Silvano Colombano, NASA Ames Research Center
Didier Keymeulen, Jet Propulsion Laboratory
Program Committee:
Leon Alkalai, Jet Propulsion Laboratory (USA)
Forrest H Bennett III, FX Palo Alto Laboratory (USA)
Neil Bergmann, Queensland University of Technology (Australia)
Hugo de Garis, Starlab (Belgium)
Stuart J. Flockton, University of London (UK)
Terry Fogarty, South Bank University (UK)
David B. Fogel, Natural Selection, Inc. (USA)
James A. Foster, University of Idaho (USA)
Pauline Haddow, Norwegian University of Science and Technology (Norway)
Inman Harvey, University of Sussex (UK)
Hitoshi Hemmi, NTT Communication Science Labs (Japan)
Tetsuya Higuchi, Electrotechnical Laboratory (Japan)
Lorenz Huelsbergen, Bell Labs, Lucent Technologies (USA)
Alan Hunsberger, National Security Agency (USA)
Rich Katz, NASA Goddard Space Flight Center (USA)
John Koza, Stanford University (USA)
Daniel Mange, Swiss Federal Institute of Technology (Switzerland)
Pierre Marchal, Swiss Center for Electronics & Microtechnology (Switzerland)
Meyya Meyyappan, NASA Ames Research Center (USA)
Julian Miller, University of Birmingham (UK)
Masahiro Murakawa, Electrotechnical Laboratory (Japan)
Jordan Pollack, Brandeis University (USA)
Edward Rietman, Lucent Technologies (USA)
Eduardo Sanchez, Swiss Federal Institute of Technology (Switzerland)
Moshe Sipper, Swiss Federal Institute of Technology (Switzerland)
Adrian Thompson, University of Sussex (UK)
Anil Thakoor, Jet Propulsion Laboratory (USA)
Benny Toomarian, Jet Propulsion Laboratory (USA)
Annie Wu, University of Central Florida (USA)
Ricardo Zebulum, Jet Propulsion Laboratory (USA)
Steven Zornetzer, NASA Ames Research Center (USA)
In Cooperation With:
Numerical Aerospace Simulation (NAS) Systems Division, NASA Ames
Computational Sciences Division, NASA Ames
Integrated Product Team, NASA Ames
Research Institute for Advanced Computer Studies (RIACS)
For further information please check the workshop web site or contact:
Jason Lohn
NASA Ames Research Center
MS 269-1
Mountain View, CA 94035, USA
jlohn@ptolemy.arc.nasa.gov
Tel: +1 (650) 604-5138
Fax: +1 (650) 604-3594
Article: 19920In the new world of SOC and design reuse the IP cores should be able to interface to each other easily. Some companies are trying to define their own cores interfaces and sometimes do not publish it. So we need to have a free open standard for cores interfaces that may be become more powerfull and usable for all designers Do you have any comments how to start defining these interfaces? all what I know that there are two types Bus style or point-to-point style but I do not know the advantages of each type. If you are intrested in defining this kind of interfaces please join us at openipcore project Thanks Jamil Khatib OpenIP Organization http://www.openip.org OpenIPCore Project http://www.openip.org/oc OpenCores Project http://www.opencores.orgArticle: 19921
Does anybody know which ASIC vendors - if any - have dual-port independently clocked RAM macros that match the Virtex's Block RAMs ?Article: 19922
One of the things I considered was looking at the phase of the internal oscillator compared to an external clock, which would be random even with the same conditions, and would have a pretty much uniform distribution. To do this, you need a fairly slow external clock (or divided clock), and after the FPGA is configured count the number of cycles of the internal oscillator until a specific transition of the external clock. The slower the external clock with respect to the oscillator, the better the resolution. Of course, for a slow clock, you want that independent of the time you start configuration or the variance will again be small. In any of these methods, the value obtained should be used as an initial seed to a digital PN sequence generator so that the distribution of your RN is controllable, even if the seed is not nicely distributed. Dave Decker wrote: > Don't forget the built in OSC that has a very poor tempco. You could > possibly substitute the internal OSC for the RC discussed below. > > Dave Decker > (I have only one h in my emal adr) > > >snip > > >Connect an RC (pullup to Vcc, cap to ground) to a pin and spin a > >counter or linear shift register until the pin goes high sometime > >after powerup (or after being pulled low tristate-wise.) Use an X7R > >cap, which has a terrible TC. If the RC time constant is long, the > >result (PRN reg contents, or some counter LSBs) is fairly random. > > > >Refinement: depending on some number of LSBs of the prievious timeout, > >reset the cap using a reset time scale that results in only partial > >discharge, then repeat the charge time thing. Serious chaos theory > >results, and something like real randomness can be had for just the > >price of one RC. > > > >John > > > >== > > > >A little nonsense now and then, > >is cherished by the wisest men. > > > >- Willy Wonka -- -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: 19923
Michel, Thanks for the pointer to my article. The direct URL is http://www.ednmag.com/ednmag/reg/1999/052799/11cs.htm. Michael, make sure you also check out the website-only addendum to the article (link in 'at a glance' section), and you might also find my '98 benchmarking of various synthesis tools to be of interest (http://www.ednmag.com/ednmag/reg/1998/091198/19df2.htm and http://www.ednmag.com/ednmag/reg/1998/050798/10df_01.htm) >Michael, > > there was an article in EDN - May 27, 1999 - called Lies, >damn lies and Benchmarks pag. 54 >author: Brian Dipert http://www.ednmag.com > >The article should still be on their website! If you cannot locate it, I >will post it on request by e-mail. >(look at: http://www.ednmag.com/ednmag/verticalmarkets/PLD.asp ) > > >regards, > >Michel HEUTS >WMU Belgium > > > >"Michael Eisenring" <eisenring@tik.ee.ethz.ch> wrote in message >news:387C9D45.D0EAC273@tik.ee.ethz.ch... >> Hi to everybody >> >> Does somebody know a library of FPGA benchmarks used for >> research? >> >> I would be pleased if I got to know where to look for it. >> >> Thanks. >> Michael > Brian Dipert Technical Editor: Memory, Multimedia and Programmable Logic EDN Magazine: The Design Magazine Of The Electronics Industry http://www.ednmag.com Contributing Editor; CommVerge Magazine http://www.commvergemag.com 1864 52nd Street Sacramento, CA 95819 (916) 454-5242 (voice), (916) 454-5101 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** mailto:bdipert@NOSPAM.pacbell.net Visit me at http://members.aol.com/bdipertArticle: 19924
Arvind, Check out my reconfigurable logic article at http://www.ednmag.com/ednmag/reg/1999/080599/16df2.htm. Feedback as always appreciated > > >arsh@x-stream.se wrote: > >> Dear All! >> >> I wonder if anyone know which FPGAs can be partly reprogrammable, so >> that one may reconfigure a part of the device while the rest of the >> device is still functioning. Has anyone of you any experience from this. >> >> Also I wonder if anyone knows what kind of research is being done in >> this area. Has anyone considered the concept of self-modifying blocks >> in FPGAs. > >You can visit my page to check about self-modiying logic at >http://www.geocities.com/SiliconValley/Pines/6639/fpga > >> >> Any information is greatly appreciated! >> >> Regards, >> >> Arvind Shah >> >> Sent via Deja.com http://www.deja.com/ >> Before you buy. Brian Dipert Technical Editor: Memory, Multimedia and Programmable Logic EDN Magazine: The Design Magazine Of The Electronics Industry http://www.ednmag.com Contributing Editor; CommVerge Magazine http://www.commvergemag.com 1864 52nd Street Sacramento, CA 95819 (916) 454-5242 (voice), (916) 454-5101 (fax) ***REMOVE 'NOSPAM.' FROM EMAIL ADDRESS TO REPLY*** mailto:bdipert@NOSPAM.pacbell.net Visit me at http://members.aol.com/bdipert
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