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
Has anybody ever used the on-chip-oscillator of a Xilinx ? (XC400E) I tried to use the vhdl-entities osc5 and osc4, but after synthesis (with leonardo) no adequate library could be found to simulate the design. Has anyone some hints, how I could manage the problem ? Sandra Dominikus.Article: 17226
Jim, It appears the answer is, some Xilinx parts are PCI compliant in this regard, and some aren't. Certainly, the 4k series doesn't, and I would venture to guess the regular Spartan doesn't either. And given that, they would not be fully PCI compliant. I hate having a client tell me 'but so and so FPGA company said these parts are fully PCI compliant' when they aren't, which has been the case in the past (with more than one FPGA company). I don't know if you have this 'discussions' item (VCCIO pins/clamp diodes) added to the Xilinx PCI compliance chart(s), but it may be good to do so if it isn't. Any comment on 5V PCI compliance on newer lower voltage parts? Since there are almost (if any) no 3.3V PCI x86 systems, and that is sure to continue for 3-5 years or more (ISA IS 18 years old...), this may create a problem in the 'near' future.... Regards, Austin Jim McManus <jim.mcmanus@xilinx.com> wrote in article <3786F30C.87E29858@xilinx.com>... > Austin Franklin wrote: > > > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but > > at > > > > least you can choose a technology part (3.3 or 5V) that meets your > > > > application. > > > > > > Technically we do. Allow me to explain. > > > > This is from PCI-Spec 2.2: > > > > “While there are multible buffer implementations that can achieve this dual > > environment compliance, it is intended that they be dual voltage buffers; > > i.e., capable of operating from either power rail. They should be powered > > from “I/O” designated power pins on PCI connectors that will always be > > connected to the power rail associated with the signaling environment in > > use.” > > > > I'm not saying it wouldn't work just fine, but technically, according to > > this quote from the PCI spec, if you don't provide clamp diodes (under any > > voltage) and I/O designated power pins, I believe that would not meet this > > part of the spec. > > Allow me to further elaborate on this subject. My PCI spec quotation > from yesterday was the footnote to this section you just mentioned. But > let's dig a little deeper into this: > > From the V2.2 PCI Spec, page 120 (5 V signaling): > "Inputs are required to be clamped to ground. Clamps to the 5V rail are > optional, but may be needed to protect 3.3V input devices." > > We don't need this upper clamp to protect our newer 3.3 V devices; the > zener diode handles the protection aspect in XLA, SpartanXL, and Virtex > families. We did need additional protection in older XL family since it > lacked the zener diode. Xilinx's solution for this was the XLT family, > which was an XL device with these upper clamps bonded out directly. The > key issue here is to protect the device from the high overshoots seen on > the unterminated 5 V PCI bus. We do this in every 3.3 V (and 2.5 V) > family we support with PCI. > > Since upper clamps are optional, we can be compliant to the 5 V PCI spec > without them. The complaint lodged against some of the PCI devices was > the lack of a clamp diode in a 3.3 V environment, not the lack of a > clamp in a 5 V environment. Remember the upper clamps serve a different > purpose depending on the environment: > > 5 V - device protection > 3.3 V - signal integrity > > Keep in mind that we are not a universal PCI device as most people think > of universal PCI devices; we are either a 5 V PCI device or a 3.3 V PCI > device, but not both at the same time. We will never need to be both at > the same time, since we can only be plugged into one bus at a time. We > are fully 5 V compliant when a 5 V bitstream is loaded and we are > plugged into a 5 V PCI bus, and we are a fully compliant 3.3 V PCI > device when a 3.3 V bitstream is loaded and we are plugged into a 3.3 V > bus. As I mentioned, the user is responsible for loading the appropriate > bitstream. If he does not do this (e.g. loads a 3.3 V bitstream while > plugged into a 5 V PCI) then it will fall out of compliance. > > If the user does this as recommended, his board will be > indistinguishable from a board that has a device that can be both 3.3 V > and 5 V at the same time. If looked at from this point of view, the > board really is universal, and will pass any tests that a universal > device can pass. The signaling environment will never change on the fly; > the card must be removed from the bus and plugged into another bus to > change the environment. The card will always have the chance to load the > correct bitstream. > > > Jim McManus > Xilinx PCI Applications Engineer >Article: 17227
FPGA 2000
Call for Papers
Eighth ACM International Symposium on Field-Programmable Gate Arrays
Monterey, California
February 10-11, 2000
Submissions Due: October 1, 1999
The annual ACM/SIGDA International Symposium on Field-Programmable
Gate Arrays is the premier conference for presentation of advances in
all areas related to FPGA technology. For FPGA 2000, we are
soliciting submissions describing novel research and development in
the following (and related) areas of interest:
* FPGA Architecture: Logic block & routing architectures, I/O
structures and circuits, new architectures, Field-Programmable
Interconnect Chips and Devices (FPIC/FPID), Field-Programmable Analog
Arrays (FPAA).
* CAD for FPGAs: Placement, routing, logic optimization, technology
mapping, system-level partitioning, logic generators, testing and
verification. CAD for FPGA-based accelerators.
* Applications: Innovative use of FPGAs, exploitation of FPGA
features, novel circuits, high-performance and
low-power/mission-critical applications, DSP techniques, uses of
reconfiguration, FPGA-based cores.
* FPGA-based computing engines: Compiled accelerators, reconfigurable
computing, adaptive computing devices, systems and software.
* Rapid-prototyping: Fast prototyping for system level design,
Multi-Chip Modules (MCMs), logic emulation.
Authors are invited to submit PDF of their paper (12 pages maximum) by
October 1, 1999 via E-mail to hauck@ee.washington.edu. Notification
of acceptance will be sent by November 17, 1999. The authors of the
accepted papers will be required to submit the final camera-ready copy
by December 1, 1999. A proceedings of the accepted papers will be
published by ACM, and included in the Annual ACM/SIGDA CD-ROM
Compendium publication. Address questions to:
Scott Hauck
Program Chair, FPGA 2000
Dept. of EE, University of Washington
Box 352500
Seattle, WA 98195-2500
Phone: (206) 543-2150
Fax: (206) 543-3842
Email: hauck@ee.washington.edu
General Chair: Steve Trimberger, Xilinx
Program Chair: Scott Hauck, U. of Washington
Finance Chair: Sinan Kaptanoglu
Publicity Chair: Herman Schmit, Carnegie Mellon
Program Committee:
Miron Abramovici, Lucent David Lewis, U. of Toronto
Ray Andraka, Andraka Consulting Fabrizio Lombardi, Northeastern U.
Mike Bershteyn, Quickturn Wayne Luk, Imperial College
Michael Butts, Synopsys Margaret Marek-Sadowska, UCSB
Jason Cong, UCLA Jan Rabaey, UCB
Eugene Ding, Lucent Jonathan Rose, U. of Toronto
Carl Ebeling, U. of Washington Martine Schlag, UCSC
Reiner Hartenstein, U. Kaiserslautern Herman Schmit, Carnegie Mellon
Scott Hauck, U. of Washington Tim Southgate, Altera
Brad Hutchings, BYU Russ Tessier, U. Mass. - Amherst
Sinan Kaptanoglu, Actel Steve Trimberger, Xilinx
Tom Kean, Algotronix John Wawrzynek, UCB
Martin Wong, UT at Austin
Sponsored by ACM SIGDA, with support from Xilinx, Altera, Actel,
Lucent, Vantis and Cypress.
Please visit the web site <http://www.ece.cmu.edu/~fpga2000> for more
information.
Article: 17228Jim, The informaton about universal PCI cards is helpful. Is there an easy way to switch between 3.3V and 5V configuration bit streams when a serial EEPROM is used to hold configuration data? Would this scenario work and be PCI compliant for a Spartan XL universal card: Always load the 3.3V configuration from an on-board serial EEPROM. If the environment is determined to be 5V (via query over the bus), reconfigure the device over the PCI bus with the 5V configuration bit stream. Jim McManus wrote in message <37859390.7AF23A76@xilinx.com>... >Austin Franklin wrote: >> The PLX has the best DMA (burst master) system of the three. If you use >> the Xilinx core, you will have to develop your own burst master, which is a >> difficult task at best. The old AMCC chips were dogs, and I haven't tried >> any of the new ones. > >Xilinx supplies with the LogiCORE PCI design a reference synthesizable >bridge design that simplifies this task. The synthesizable bridge design >gives you an example of how to do a DMA with R/W FIFOs, doorbells, >mailboxes, target transaction ordering, etc. > >> Be careful with the latest PLX chip though (9054) if you need to use 5V >> PCI. It does not provide any VCCIO pins, and that is in direct violation >> with the PCI spec, especially since it is a 3.3V chip, used in a 5V PCI >> system. If your PCI voltage is the same as the voltage of the chip, that >> is fine. >> >> Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but at >> least you can choose a technology part (3.3 or 5V) that meets your >> application. > >Technically we do. Allow me to explain. > >The problem that is plaguing some universal PCI devices is the >requirement for upper clamp diodes in the 3.3 V environment. If these >clamps are missing, the device may not be compliant in a 3.3 V >environment. If they are tied permanently to the 3.3 V rail, then they >lose 5 V tolerance. In traditional ASIC thinking, since the devices >aren't configurable, the solution is to bondout the upper clamp diode >and the system designer then ties this to Vio. If Vio is at 5 V, the 5 V >overshoot (as much as 11 V for 11 ns!) is clamped to something less than >what would damage the device. If Vio is 3.3 V, the clamps for signal >integrity are there as required by the spec. And the drive strength of >the I/O buffer would be derived from this "Vccio". WIth FPGAs, we do >thing differently, but still achieve compliance. > >From the PCI V2.2 Spec, page 114: >> While the primary goal of the PCI 5V to 3.3V transition strategy is >> to spare vendors the burden and expense of implementing 3.3V parts >> that are "5V tolerant," such parts are not excluded. If a PCI >> component of this type is used on the Universal board, its I/O buffers >> may optionally be connected to the 3.3V rail rather than the "I/O" >> designated power pins; but high clamp diodes must still be connected >> to the "I/O" designated power pins. (Refer to the last paragraph of >> Section 4.2.1.2. - "Clamping directly to the 3.3V rail with a simple >> diode must never be used in the 5V signaling environment.") Since the >> effective operation of these high clamp diodes may be critical to both >> signal quality and device reliability, the designer must provide enough >> extra "I/O" designated power pins on a component to handle the current >> spikes associated with the 5V maximum AC waveforms (Section 4.2.1.3.). > >Several things to note here: >1. 3.3 V devices that are 5 V tolerant are allowed. This would include >Xilinx FPGAs that supply 3.3 V to the I/O cells. The Xilinx XLA, >SpartanXL, and Virtex families fall into this category. >2. Connecting the I/O cell to the 3.3 V rail is allowed. >3. The upper (high) clamp diode has to be tied to the I/O power. Xilinx >handles this through a bitstream configuration; either the upper diode >is tied to the 3.3 V rail, or it's floating. Since not using the upper >clamps is allowed in a 5 V environment, this meets the PCI spec. We >don't lose 5 V tolerance because the diode can be disconnected. >4. The overshoot for 5 V PCI has to be handled so that the device is not >damaged. In 3.3 V devices, the thinner oxide layers can't withstand the >11 V overshoot. We handle this by a zener diode in the I/O structure >that clamps the voltage to an acceptable level. > >So the real question here is how would one handle, in a compliant >manner, the requirements for a universal PCI card with an FPGA? To do a >universal PCI card, Xilinx requires loading of a different bitstream >depending on the bus signaling level. > >When plugged into a 5 V PCI bus, a 5 V bitstream must be loaded. This >will have the clamps disconnected and the 5 V drive strength enabled. >This is fully 5 V PCI compliant. > >Likewise, when plugged into a 3.3 V PCI bus, a 3.3 V bitstream must be >loaded. This will have the clamps enabled and the 3.3 V drive strength >enabled. This is fully 3.3 V PCI compliant. > >While this is not a universal card in the usual sense of the term, it is >completely compliant in either environment. The user does have the >responsibility of insuring that his design loads appropriate bitstream. >This is done by monitoring the PCI bus Vio pin with a comparator and >some external logic. This could be as simple as using the comparator to >drive an address line on a parallel PROM. > >And while we're discussing universal PCI cards, here is something to be >aware of. As we go to smaller device geometries, specifically 0.18u, 5 V >PCI tolerance will start to disappear. Since FPGAs tend to be produced >for upwards of ten years and standard chips only 2-4 years, shortly the >only way to do a 5 V or universal PCI card may be an FPGA (at 0.22u or >larger). If you are planning on extended production of your 5 V or >universal PCI card, this should be considered. > > >Jim McManus >Xilinx PCI Applications EngineerArticle: 17229
: > Does anyone have recommendations to find benchmark circuits for : > FPGA - preferrably in VHDL ? : > : > Thanks in advance. : > : > email: csoolan@dso.org.sg : I've been thinking about this for sometime myself. Gate counts and speed are : two areas where it's hard to get *OBJECTIVE* data on FPGA devices. : The problem with benchmarks is that most circuits seem to specialize in certain : types of logic (gates, multiplexors, three-state buses, RAM, etc.). No matter : what you use, somebody will complain that it doesn't represent what they're : trying to benchmark. The same thing happens with computer : benchmarks. This is a problem across the board in CAD. For that reason, we've been working to improve the status of benchmark circuits that are available to researchers and customers. We currently have a "vertical" benchmark available on our web page. It is a 24-bit DSP with memories, multipliers, control, big adders, and all sorts of other structures. I believe that it really pushes ASIC Synthesis and P&R tools. It should also push FPGA tools, but we haven't yet tried it. I think the distinction with our benchmark is that we give away lots of different representations (RTL, gate-level, switch-level, and geometry). This allows you to test your flow from any starting point. In addition, we have a fairly extensive functional testbench. All of this can be found by following the "benchmarks" link from: http://www.ece.cmu.edu/~ceda (The current URL will be updated soon, so please bookmark the CEDA site only.) Please let us know if you have any questions, or just let us know that you're using this productively. We'll be putting a number of other designs on this site in the coming year, including an ARM-like core, a programmable FIR filter, and a picoJava processor. (BTW, Sun is now releasing their picoJava and SPARC cores under a license that allows you to use them for benchmarking. Might also be useful to you.) Herman ------------------------------------------------ Herman Schmit, Ph.D., Assistant Professor Department of Electrical and Computer Engineering Carnegie Mellon University 5000 Forbes Ave., Pittsburgh PA 15213 Tel: (412) 268-6470 FAX: (412) 268-3204 email: herman@ece.cmu.eduArticle: 17230
Hi, I have wrote a memory cores for single and dual port memory in VHDL, Please I need your comments on them. You can find the cores at http://www.geocities.com/SiliconValley/Pines/6639/openip/projects.html Thanks in advanceArticle: 17231
Responsibilities ASIC design and development, for Data Communications and Networking Applications. Requirements - Knowledge of Ethernet, Ethernet Switching, SONET and ATM. - BSEE (or higher), with at least 8 years experience in digital hardware development. - 3+ years recent ASIC and/or FPGA development. - 2+ years with VHDL or VERILOG RTL development - Verification and simulation - Logic synthesis. - Timing Analysis Tools: - Synopsys Design Compiler. - Model Technology - Viewlogic - Xilinx Foundation tools - Altera MaxPlusII We are located in Burlington, MA on Route 128 (I95) and offer competitive salaries. Principals only. Email your resume to arnaud@ecla.comArticle: 17232
As long as we're bringing up early patents on reconfigurable computing, I wrote a patent, US5796623: "Apparatus and method for performing computations with electrically reconfigurable logic devices", which, while issued in 1998, has a priority date of October 5, 1988, since its reconfigurable computing material appeared in the disclosure of its parent, US5036473. I don't own these patents (I wish I did!), and I don't work there anymore. But if we're collectively assembling a historical record, please let me bring up this early work. As for the reality of reconfigurable computing, I generally agree with the opinions posted here by Steve Casselman, Tom Kean, Ray Andraka, Don Husby and Brad Hutchings. It is a new way to compute, it has great power in the areas it's well suited for, and, like anything else in this world, you have to work hard to make it pay. Here are links to the patents I mentioned: <http://www.patents.ibm.com/details?pn=US05796623__> <http://www.patents.ibm.com/details?pn10=US05036473> --Mike PS: US5036473 just stood up again after an infringement trial in the US District Court, following earlier trials at the ITC: <http://www.cadence.com/press_box/na/pr/1999/06_23_99.html> Steven Casselman wrote: > My patent predates Gilsons. > My priority date is July 29, 1992 > http://www.patents.ibm.com/details?pn=US05684980__&language=en > his is > http://www.patents.ibm.com/details?pn10=US05361373 > Dec 11 1992. > Brad Taylors' (gigops) priority date is Nov 5 1992 > http://www.patents.ibm.com/details?pn=US05603043__ > Which also predates Gilson.Article: 17233
--------------6D54F6F333EFFBCF3DF85963 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am trying to place and route a design (targeted for a Xilinx VIRTEX part) using Xilinx Design Manager. The output signals are registered, and have a fanout of 1 so that they can be pulled into the IOB's. I confirmed using EPIC that these flops are correctly placed in IOB's when the "-pr b" MAP directive is used during place-and-route. The problem I am facing now is that once I floorplan individual modules within my design, their output flops are moved to CLB's instead of IOB's. In this example, if I specify the location attributes for module1 in the ucf file, all the output flops which are directly connected to the PADS will be located in CLB's instead of IOB's (something I don't want). # Flooplan constraints (or location attributes) INST "*module1*" LOC="CLB_R1C19:CLB_R18C48"; I tried using the INST <FF_instance_name> IOB = TRUE attribute in my ucf file, but it doesn't fix the problem. Any workaround to this problem will be highly appreciated. Regards, Philemon --------------6D54F6F333EFFBCF3DF85963 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> <FONT FACE="Courier New,Courier"><FONT SIZE=-1>Hi,</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>I am trying to place and route a design (targeted for a Xilinx VIRTEX part)</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>using Xilinx Design Manager.</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>The output signals are registered, and have a fanout of 1 so that they can be pulled</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>into the IOB's. I confirmed using EPIC that these flops are correctly placed in IOB's</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>when the "-pr b" MAP directive is used during place-and-route.</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>The problem I am facing now is that once I floorplan individual modules within my</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>design, their output flops are moved to CLB's instead of IOB's.</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>In this example, if I specify the location attributes for module1 in the ucf file, all the output flops which are directly connected to the PADS will be located in CLB's instead of IOB's (something I don't want).</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1># Flooplan constraints (or location attributes)</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>INST "*module1*" LOC="CLB_R1C19:CLB_R18C48";</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>I tried using the INST <FF_instance_name> IOB = TRUE attribute in my ucf file, but it</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>doesn't fix the problem.</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>Any workaround to this problem will be highly appreciated.</FONT></FONT><FONT FACE="Courier New,Courier"><FONT SIZE=-1></FONT></FONT> <P><FONT FACE="Courier New,Courier"><FONT SIZE=-1>Regards,</FONT></FONT> <BR><FONT FACE="Courier New,Courier"><FONT SIZE=-1>Philemon</FONT></FONT></HTML> --------------6D54F6F333EFFBCF3DF85963--Article: 17234
Philemon, I've noticed EXACTLY the same problem. Unfortunately, I don't have a solution either. Have you also noticed bidirectional registered signals do use the FFs in the IOBs? I've spoken to Xilinx support about this issue several times, but the best answer I've gotten is to wait for the latest release. WWArticle: 17235
Hi In the OpenIP project we are working to collect open HW designs that can be made public and used by any one specially HDL cores. So please if you know any free core, free design or even if you have any idea about what type of cores are needed Please email me @ khatib@ieee.org or our mailing list @ openip@egroups.com visit our temporary site at http://www.geocities.com/SiliconValley/Pines/6639/openip Thanks in advanceArticle: 17236
Hello.
I'll like to syntesize a digital modulator within a Xilinx XC5202
fpga, since I purchased a few ago the Foundation package to
learn and homebrewing.
The diagram of what I intend to do, could be something like:
phase_offset============== ______ __________
_______________ | | | | |
| _________ | | ====>|Sin(x)|=>| |=>Real
V | | | V | |______| |Complex |
freq=>(+)=>|Phase_acc|='>(+)=>| ______ | |
|_________| | | | |Multiplier|
====>|Cos(x)|=>| |=>Img
|______| |__________|
^ ^
mod. a b
I've working the phase accumulator yet.(It's the easier, I know)
My question is about how to syntesize the Sin and Cos functions
without a lookup table to save the external ram I will need.
Also I will need a complex multiplier to mix both vectors,
and don't know how to make it. So I'm requesting help, or
any pointer to where could I find it.
Thanks.
73's de Luis
mail: melus@esi.us.es
Ampr: eb7gwl.ampr.org
http://www.esi.us.es/~melus/ <- Homebrewed Hardware Projects with PCBs
Article: 17237I installed a Leonardo Spectrum network license on our NT server about 1 week ago. Since then, the license server daemon dies about once a day with the following message: 0:14:08 (exemplard) Hostid has changed, probably because a dongle was removed 0:14:09 (exemplard) shutting down Anyone seen anything like this? Exemplar technical support has no suggestions. There are 2 other keys on the parallel port: Aldec and Pspice. The Exemplar key has a flexID of 8-****, the Aldec key has a 7-****. Everyone says that these should all be compatible. The cleaning lady is not pulling off the keys in the middle of the night. -- Don Husby <husby@fnal.gov> Phone: 630-840-3668 Fermi National Accelerator Lab Fax: 630-840-5406 Batavia, IL 60510Article: 17238
I had a similar problem with an Aldec dongle. Aldec replaced the dongle and things have been fine since. Don Husby wrote: > I installed a Leonardo Spectrum network license on our NT server about 1 week ago. > Since then, the license server daemon dies about once a day with the following > message: > > 0:14:08 (exemplard) Hostid has changed, probably because a dongle was removed > 0:14:09 (exemplard) shutting down > > Anyone seen anything like this? Exemplar technical support has no suggestions. > > There are 2 other keys on the parallel port: Aldec and Pspice. > The Exemplar key has a flexID of 8-****, the Aldec key has a 7-****. > Everyone says that these should all be compatible. > The cleaning lady is not pulling off the keys in the middle of the night. > > -- > Don Husby <husby@fnal.gov> Phone: 630-840-3668 > Fermi National Accelerator Lab Fax: 630-840-5406 > Batavia, IL 60510 -- -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: 17239
Mike Butts wrote: > As long as we're bringing up early patents on reconfigurable > computing, I wrote a patent, US5796623: "Apparatus and method > for performing computations with electrically reconfigurable > logic devices", which, while issued in 1998, has a priority date > of October 5, 1988, since its reconfigurable computing material > appeared in the disclosure of its parent, US5036473. > Well Tom pointed out that there is one more patent with a priority date of Sep. 11 1985 http://www.patents.ibm.com/details?pn10=US04935734 Its Kenneth Austin at Pilkington. The '85 date was the foreign application priority date. -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 17240
Greetings, My name is Asher and I have a question about how to do pin assignments for the Altera VHDL compiler. I have an output called "angle_output" defined as follows... " PORT ( angle_input : IN STD_LOGIC; clr_angle : IN STD_LOGIC; angle_output : OUT INTEGER RANGE 0 TO 255 ); " I would like to map all eight pins individually to specific pins on my FPGA board. Could someone please tell me how to do this for the Altera Max+PlusII compiler? NOTE: I already understand how to do this for single pins like "angle_input" and "clr_angle"... just not the multiple outputs defined on one line... Best regards, >Asher< <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>> Asher C. Martin 805 West Oregon Street Urbana, IL 61801-3825 (217) 367-3877 E-MAIL: martin2@acm.uiuc.edu http://fermi.isdn.uiuc.edu telnet://fermi.isdn.uiuc.edu ftp://feynman.isdn.uiuc.edu <<=>>=<<=>>=<<=>><<=>>=<<=>>=<<=>>Article: 17241
Hi, I am looking for a ISA PnP core, for an FPGA. We are currently using a commercial ISA PnP chip but they require another EPLD to interface into fix up the signals so we can use them. So any news on a ISA PnP core, either commercial or Free. Thanks in advance. Robert Morse -- ++++++++++++++++++++++++++++++++++++++++ + Robert Morse + + rmorse@rmsun.linxnet.com + ++++++++++++++++++++++++++++++++++++++++Article: 17242
Jim McManus wrote: > > Austin Franklin wrote: > > > > Technically, the Xilinx part doesn't meet PCI VCCIO spec either....but > > at > > > > least you can choose a technology part (3.3 or 5V) that meets your > > > > application. > > > > > > Technically we do. Allow me to explain. > > > > > > The problem that is plaguing some universal PCI devices is the > > > requirement for upper clamp diodes in the 3.3 V environment. If these > > > clamps are missing, the device may not be compliant in a 3.3 V > > > environment. If they are tied permanently to the 3.3 V rail, then they > > > lose 5 V tolerance. In traditional ASIC thinking, since the devices > > > aren't configurable, the solution is to bondout the upper clamp diode > > > and the system designer then ties this to Vio. If Vio is at 5 V, the 5 V > > > overshoot (as much as 11 V for 11 ns!) is clamped to something less than > > > what would damage the device. If Vio is 3.3 V, the clamps for signal > > > integrity are there as required by the spec. And the drive strength of > > > the I/O buffer would be derived from this "Vccio". WIth FPGAs, we do > > > thing differently, but still achieve compliance. > > > > This is from PCI-Spec 2.2: > > > > “While there are multible buffer implementations that can achieve this dual > > environment compliance, it is intended that they be dual voltage buffers; > > i.e., capable of operating from either power rail. They should be powered > > from “I/O” designated power pins on PCI connectors that will always be > > connected to the power rail associated with the signaling environment in > > use.” > > > > I'm not saying it wouldn't work just fine, but technically, according to > > this quote from the PCI spec, if you don't provide clamp diodes (under any > > voltage) and I/O designated power pins, I believe that would not meet this > > part of the spec. > > Allow me to further elaborate on this subject. My PCI spec quotation > from yesterday was the footnote to this section you just mentioned. But > let's dig a little deeper into this: > > From the V2.2 PCI Spec, page 120 (5 V signaling): > "Inputs are required to be clamped to ground. Clamps to the 5V rail are > optional, but may be needed to protect 3.3V input devices." > > We don't need this upper clamp to protect our newer 3.3 V devices; the > zener diode handles the protection aspect in XLA, SpartanXL, and Virtex > families. We did need additional protection in older XL family since it > lacked the zener diode. Xilinx's solution for this was the XLT family, > which was an XL device with these upper clamps bonded out directly. The > key issue here is to protect the device from the high overshoots seen on > the unterminated 5 V PCI bus. We do this in every 3.3 V (and 2.5 V) > family we support with PCI. > > Since upper clamps are optional, we can be compliant to the 5 V PCI spec > without them. The complaint lodged against some of the PCI devices was > the lack of a clamp diode in a 3.3 V environment, not the lack of a > clamp in a 5 V environment. Remember the upper clamps serve a different > purpose depending on the environment: > > 5 V - device protection > 3.3 V - signal integrity > > Keep in mind that we are not a universal PCI device as most people think > of universal PCI devices; we are either a 5 V PCI device or a 3.3 V PCI > device, but not both at the same time. We will never need to be both at > the same time, since we can only be plugged into one bus at a time. We > are fully 5 V compliant when a 5 V bitstream is loaded and we are > plugged into a 5 V PCI bus, and we are a fully compliant 3.3 V PCI > device when a 3.3 V bitstream is loaded and we are plugged into a 3.3 V > bus. As I mentioned, the user is responsible for loading the appropriate > bitstream. If he does not do this (e.g. loads a 3.3 V bitstream while > plugged into a 5 V PCI) then it will fall out of compliance. > > If the user does this as recommended, his board will be > indistinguishable from a board that has a device that can be both 3.3 V > and 5 V at the same time. If looked at from this point of view, the > board really is universal, and will pass any tests that a universal > device can pass. The signaling environment will never change on the fly; > the card must be removed from the bus and plugged into another bus to > change the environment. The card will always have the chance to load the > correct bitstream. > > Jim McManus > Xilinx PCI Applications Engineer Jim, Perhaps I am missing something, but I don't see where you explain how you meet the spec in a 3.3v signalling environment. From your description, it would appear that you are required to clamp inputs to 3.3v with diodes. Do you in fact do that? You indicate that a separate bitstream is required for 5v vs. 3.3v operation, but you don't indicate what is different about the bitstream or how compliance is maintained in the 3.3v environment. Can you explain this in more detail? -- 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: 17243
Don Husby wrote: > > I installed a Leonardo Spectrum network license on our NT server about 1 week ago. > Since then, the license server daemon dies about once a day with the following > message: > > 0:14:08 (exemplard) Hostid has changed, probably because a dongle was removed > 0:14:09 (exemplard) shutting down > > Anyone seen anything like this? Exemplar technical support has no suggestions. > > There are 2 other keys on the parallel port: Aldec and Pspice. > The Exemplar key has a flexID of 8-****, the Aldec key has a 7-****. > Everyone says that these should all be compatible. > The cleaning lady is not pulling off the keys in the middle of the night. > > -- > Don Husby <husby@fnal.gov> Phone: 630-840-3668 > Fermi National Accelerator Lab Fax: 630-840-5406 > Batavia, IL 60510 This type of mysterious problem is why I don't like using dongles. They have been around for quite some time and they have always caused problems as far as I can tell. Originally most of the problems had to do with incompatibilities with other devices hanging on the parallel port or with other dongles. More recently there are problems with various operating systems and software. But my biggest complaint with these dongles is that they cost so much! If you buy a $10,000 software package and you lose the 2" square dongle, you have just lost $10,000. Anything I own that is that small and that expensive, I keep in a safe deposit box at my bank! At one point I would buy the software, then buy the crack for the key just so that I didn't lose my investment if something happened to the key. Funny, because that is exactly how they market the cracks. I haven't looked into cracks for any of the software I currently own because none of it uses a dongle for licensing. But that is by choice. I won't buy any dongle licensed software if I can help it. -- 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: 17244
Hi everybody, I am trying to implement with Viewlogics FPGA Express a mixed design (schematic/VHDL) in an ACTEL FPGA without success. What is the right way to implement: a) - generate an EDIF netlist from VHDL design with FPGA Express - invoke EDIF netlist reader to build *.wir file - build schematic and symbol from *.wir file with ViewGen - implement symbol (with hidden VHDL design) in topdesign (schematic) - export EDIF netlist - invoke ACTEL Designer b) (do it the XILINX way) - generate symbol from VHDL design (e.g. VHDL2SYM.exe) - implement symbol (with hidden VHDL design) in topdesign (schematic) - invoke fepreproc to build *.edn - start FPGA Express (New Project with schematic (*.edn) and vhdl (*.vhd) files) - export EDIF netlist from optimized chip -> this works (fine?) for Xilinx designs but for ACTEL designs this EDIF netlist is empty accept some general things c) forget mixed design Way a) seems untypical for me! What is wrong in b) Waiting for answers, Ingo.Article: 17245
Hi. I would like to read the impression of people who used Virtual CPU of SUMMIT design. ThankX, Yoram Stern. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.Article: 17246
Asher C. Martin wrote in message <378C20DF.9B936EF8@acm.uiuc.edu>...
>Greetings,
>
>My name is Asher and I have a question about how to do pin assignments
>for the Altera VHDL compiler. I have an output called "angle_output"
>defined as follows...
>
>"
> PORT
> (
> angle_input : IN STD_LOGIC;
> clr_angle : IN STD_LOGIC;
> angle_output : OUT INTEGER RANGE 0 TO 255
> );
>"
>
>I would like to map all eight pins individually to specific pins on my
>FPGA board. Could someone please tell me how to do this for the Altera
>Max+PlusII compiler?
>
>NOTE: I already understand how to do this for single pins like
>"angle_input" and "clr_angle"... just not the multiple outputs defined
>on one line...
Change your declaration of angle_output to STD_LOGIC_VECTOR(7 downto 0).
Now you'll have eight obvious ports you can use to map to the pins you
desire.
Of course, you'll have to tweak your code. you can have a signal internal
to your architecture called angle that's declared as integer range 0 to 255
and do all operations on the integer, and you need to convert it to
STD_LOGIC_VECTOR only when driving the output:
angle_output <= ConversionToSLV(angle);
where the function ConverstionToSLV() should be replaced by whatever
function you'd use to convert integers to SLVs. I'm not sure what Altera's
compiler uses for that. RTFM.
hope this helps,
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao.edu
"You want partial credit? You build bridge, bridge falls down - no partial
credit."
-- Dr A. Chang, professor of Mechanical Engineering at Stevens Institute of
Technology
Article: 17247On Tue, 13 Jul 1999 20:21:44 GMT, husby@fnal.gov (Don Husby) wrote: >I installed a Leonardo Spectrum network license on our NT server about 1 week ago. >Since then, the license server daemon dies about once a day with the following >message: <snip> Couple of ideas. 1 - BIOS power saving? One of my colleagues remembers Dells doing stuff with parallel ports. Long shot, but possible. 2 - I experienced some jitters with a DELL myself (my new laptop actually), but tracked it down to LMGRD possibly throwing some wobblies if a single license file has multiple hostid's mentioned in it. Therefore separate your license files and concatenate your LM_LICENSE_FILE (if not done already) 3 - I presume the port just has the dongles - no printers please. 4 - Install latest Dallas Drivers and Sentinel Drivers from the web. 5 - Use the latest lmgrd (6.1e?) I think Spectrum still ships with 5.12b 6 - If all else fails, try to unify _all_ your license to one hostid, be it either the Dallas or Sentinel. Cheers Stuart An employee of Saros Technology: Model Technology, Exemplar Logic, TransEDA, Renoir. www.saros.co.ukArticle: 17248
Let's see. Aldec, modelsim, synplicity, viewlogic and altera all use dongles. I guess you must be doing all your work on Foundation? Unfortunately, in this business, dongles are a fact of life. I've currently got a string of 9 of them on my system :-( Rickman wrote: > > > This type of mysterious problem is why I don't like using dongles. They > have been around for quite some time and they have always caused > problems as far as I can tell. Originally most of the problems had to do > with incompatibilities with other devices hanging on the parallel port > or with other dongles. More recently there are problems with various > operating systems and software. > > But my biggest complaint with these dongles is that they cost so much! > If you buy a $10,000 software package and you lose the 2" square dongle, > you have just lost $10,000. Anything I own that is that small and that > expensive, I keep in a safe deposit box at my bank! > > At one point I would buy the software, then buy the crack for the key > just so that I didn't lose my investment if something happened to the > key. Funny, because that is exactly how they market the cracks. I > haven't looked into cracks for any of the software I currently own > because none of it uses a dongle for licensing. But that is by choice. I > won't buy any dongle licensed software if I can help it. -- -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: 17249
Stuart Clubb wrote: > On Tue, 13 Jul 1999 20:21:44 GMT, husby@fnal.gov (Don Husby) wrote: > > >I installed a Leonardo Spectrum network license on our NT server about 1 week ago. > >Since then, the license server daemon dies about once a day with the following > >message: > > <snip> > > Couple of ideas. > > 1 - BIOS power saving? One of my colleagues remembers Dells doing > stuff with parallel ports. Long shot, but possible. > > 2 - I experienced some jitters with a DELL myself (my new laptop > actually), but tracked it down to LMGRD possibly throwing some > wobblies if a single license file has multiple hostid's mentioned in > it. Therefore separate your license files and concatenate your > LM_LICENSE_FILE (if not done already) > > 3 - I presume the port just has the dongles - no printers please. > > 4 - Install latest Dallas Drivers and Sentinel Drivers from the web. Some software won't work with the latest sentinel driver...notably viewlogic WVO 7.5 > > > 5 - Use the latest lmgrd (6.1e?) I think Spectrum still ships with > 5.12b > > 6 - If all else fails, try to unify _all_ your license to one hostid, > be it either the Dallas or Sentinel. > > Cheers > Stuart > An employee of Saros Technology: > Model Technology, Exemplar Logic, TransEDA, Renoir. > www.saros.co.uk -- -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
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