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 All, Its me again, I have looking for a board to buy for 3weeks now, and I think I am inclined towards the XESS Board. I want to hear whether from other users of this board or any other board. My only grim with this board is lack of USB interface and gate_count per $. Other boards I am considering are Digilab2 or Trenz(TE....) Iwould also like to confirm whether FPGA can be programmed via USB/parallel port adapter. Pls Help as I need to get on with things b4 Jul. Cheers. FemiArticle: 44676
The software is something that you need to take special care about. Be sure to save the version that you did your original design with. It is not uncommon that when they "improve" the software to work with the newest family it does not work as well with older families. It is just a matter of economics to the FPGA vendors. They have to focus on selling the newest, biggest, highest profit margin chips. This gets design wins and brings in the most money. Once a chip has a few years on it and it is on the downhill side of the production ramp, the software guys have no reason to optimize the tools for it. Just a fact of life. So cover your rear by keeping back versions of the software. Peter Alfke wrote: > > Theron, before you get all upset: > There is a difference between "available" and "recommended for new > designs". > Xilinx parts have a very long availability lifetime, (check with your > distributor, and watch out for software support which may disappear first, > unless you have the old software installed). > But there is a much shorter time where we recommend any family for new > designs. > The newer families are usually more capable and less expensive, so why > would anybody use the older family for a brand-new design? > Well, Vcc tolerance is one parameter where the old family may be more > desirable... > > Peter Alfke, Xilinx Applications > > Theron Hicks wrote: > > > Picky, Picky... Actually I suspected that was coming. Just as I get a > > handle on a part, they stop recomending it. Actually, two years ago, > > that part was recommended by an apps engineer at a particulr > > distributor. He said that it was more available than the Virtex > > series. I designed it in and now who knows whether I will be able to > > get it in the future. > > > > My newest design uses the Spartan2E. I hope that will be around for a > > while. Working within a university setting is a little different and > > our FPGA boards in the the EDA labs were 4013's until this fall. Now > > they finally "upgraded" to SpartanXL's in Sept of 2001. Oh well... > > > > Ray Andraka wrote: > > > > > Right, but that is not recommended for new designs at this point. > > > > > > Theron Hicks wrote: > > > > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > > > news:3D120F32.7321A03@andraka.com... > > > > > SpartanII and Virtex have 5v tolerant 3.3v I/O. > > > > So does SpartanXL > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email ray@andraka.com > > > http://www.andraka.com > > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759 -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 44677
It would be nice if they at least didn't break existing software when bringing
out the new. For example, if you are doing any floorplanning with RPMs in
Virtex or its derivatives, 4.2 is unusable because of floorplanner problems that
didn't exist in earlier software.
rickman wrote:
> The software is something that you need to take special care about. Be
> sure to save the version that you did your original design with. It is
> not uncommon that when they "improve" the software to work with the
> newest family it does not work as well with older families.
>
> It is just a matter of economics to the FPGA vendors. They have to
> focus on selling the newest, biggest, highest profit margin chips. This
> gets design wins and brings in the most money. Once a chip has a few
> years on it and it is on the downhill side of the production ramp, the
> software guys have no reason to optimize the tools for it.
>
> Just a fact of life. So cover your rear by keeping back versions of the
> software.
>
> Peter Alfke wrote:
> >
> > Theron, before you get all upset:
> > There is a difference between "available" and "recommended for new
> > designs".
> > Xilinx parts have a very long availability lifetime, (check with your
> > distributor, and watch out for software support which may disappear first,
> > unless you have the old software installed).
> > But there is a much shorter time where we recommend any family for new
> > designs.
> > The newer families are usually more capable and less expensive, so why
> > would anybody use the older family for a brand-new design?
> > Well, Vcc tolerance is one parameter where the old family may be more
> > desirable...
> >
> > Peter Alfke, Xilinx Applications
> >
> > Theron Hicks wrote:
> >
> > > Picky, Picky... Actually I suspected that was coming. Just as I get a
> > > handle on a part, they stop recomending it. Actually, two years ago,
> > > that part was recommended by an apps engineer at a particulr
> > > distributor. He said that it was more available than the Virtex
> > > series. I designed it in and now who knows whether I will be able to
> > > get it in the future.
> > >
> > > My newest design uses the Spartan2E. I hope that will be around for a
> > > while. Working within a university setting is a little different and
> > > our FPGA boards in the the EDA labs were 4013's until this fall. Now
> > > they finally "upgraded" to SpartanXL's in Sept of 2001. Oh well...
> > >
> > > Ray Andraka wrote:
> > >
> > > > Right, but that is not recommended for new designs at this point.
> > > >
> > > > Theron Hicks wrote:
> > > >
> > > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > > news:3D120F32.7321A03@andraka.com...
> > > > > > SpartanII and Virtex have 5v tolerant 3.3v I/O.
> > > > > So does SpartanXL
> > > >
> > > > --
> > > > --Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930 Fax 401/884-7950
> > > > email ray@andraka.com
> > > > http://www.andraka.com
> > > >
> > > > "They that give up essential liberty to obtain a little
> > > > temporary safety deserve neither liberty nor safety."
> > > > -Benjamin Franklin, 1759
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 44678In article <afc37o$d16$1@dennis.cc.strath.ac.uk>, aeu96186@yahoo.co.uk says... > > Hello, > > I am just writing a presentation in part of which I explain the benefits of > pipelining in FPGAS - increased clock rates due to short critical paths > means higher bandwidth in terms of spectrum and throughput etc. etc... > > It occurred to me however that, because registers are "free" in Xilinx > slices, why would there ever be a case where we would want to not use the > registers? I know that we might not need to since the required system rate > may be low but that would not stop us from using them? Is it a power > consumption issue? > > So the questions: > > Under what circumstances would it be advantageous to not use the registers? > > Under what circumstances is it unavoidable that we must not use the > registers? > > Thanks for your time, > > Ken It depends on your application but I think in general you want to produce a result in as few clock cycles as possible to minimize latency. Pipes are never always full so latency usually comes into play. -- Rich Iachetta iachetta@us.ibm.com I do not speak for IBM.Article: 44679
rickman wrote: > > The software is something that you need to take special care about. Be > sure to save the version that you did your original design with. It is > not uncommon that when they "improve" the software to work with the > newest family it does not work as well with older families. > > It is just a matter of economics to the FPGA vendors. They have to > focus on selling the newest, biggest, highest profit margin chips. This > gets design wins and brings in the most money. Once a chip has a few > years on it and it is on the downhill side of the production ramp, the > software guys have no reason to optimize the tools for it. > > Just a fact of life. So cover your rear by keeping back versions of the > software. This is good version control practice, and the moves to time-lock software are not likely to help users in this situation. -jgArticle: 44680
Suppose one part of a long logic path takes two levels of logic from input A to register X. Suppose another part of the logic feeding register X takes 14 levels of logic from input B. Pipeling suggests you'd want a pipeline of 2 for the one input and a pipeline of 14 for the other. How do you resolve the difference? Feedback loops are where I need to keep the pipelining to a minimum. Otherwise I manually pipeline my design at many opportune places. - John_H Ken Mac wrote: > Hello, > > I am just writing a presentation in part of which I explain the benefits of > pipelining in FPGAS - increased clock rates due to short critical paths > means higher bandwidth in terms of spectrum and throughput etc. etc... > > It occurred to me however that, because registers are "free" in Xilinx > slices, why would there ever be a case where we would want to not use the > registers? I know that we might not need to since the required system rate > may be low but that would not stop us from using them? Is it a power > consumption issue? > > So the questions: > > Under what circumstances would it be advantageous to not use the registers? > > Under what circumstances is it unavoidable that we must not use the > registers? > > Thanks for your time, > > KenArticle: 44681
John_H wrote: > [snip] > > Feedback loops are where I need to keep the pipelining to a minimum. Otherwise > I manually pipeline my design at many opportune places. I'm currently reading a great book "VLSI Digital Signal Processing Systems" by Parhi, where there are detailed discussions on pipelining, unfolding, folding, and so on. One chapter describes the theoretical basis of pipelining, basically that registers can be inserted across any feed forward cut-set of the signal flow graph - a cut set being a set of edges (wires) that when cut create two disjoint sub-graphs. Sounds complicated but easily illustrated. Feedback complicates this as others have noted, but it can still be used to some extent. It's amazing to me how simple this principle is to apply, and how powerful it is. I went back and looked at some earlier pipelined designs I had done, and saw immediately that I could have made much more efficient use of registers and paths etc to achieve the same results with lower latency and fewer registers. Interesting stuff. Regards, JohnArticle: 44682
Thanks for your input, Rick. I have been able to find out the following: 1) The concept of a library as that in VHDL does not exist in Verilog One can not include the library in the HDL code. 2) All library managment functions are tool specific for Verilog In Aldec, for example, there is a special tab under: Design/Settings/Verilog Libraries through which one can add the precompiled libraries to the design. Regards, Yury Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3D1968C6.50974DA@algor.co.uk>... > Yury wrote: > > > Greetings all, > > in VHDL we have the following way of telling the simulator/synthesis > > tool where to find the description of components that have not been > > explicitely declared within the source code: > > ------------------------------------------- > > library myLibrary; > > use myLibrary.my_package.my_component; > > ------------------------------------------- > > > > How do I do the same in Verilog? > > > > Thanks. > > For simulation with ModelSim I don't need this at compilation time since > I use the -L flags on the simulator startup line to point to the > pre-compiled libs needed to satisfy references. On those occasions where > I want to vary the definitions used for different instantiation of the > same component in the same source I resort to the `uselib directive (but > I think this is ModelSim specific) ? > > For synthesis there are 2 options: > > One way is to add something like this at the end of your source file, > after the last "endmodule": > > `include "<path_to_libfile>/libfile.v"; > > If the components are e.g. Xilinx primitives then your synth tool vendor > should provide "libfile.v", it may depend on the device family. > > The other is simply to add the "libfile" to the list of sources you give > to the synth tool. > > The Verilog `include mechanism is not as flexible since you cannot, > without some difficulty, change the external definitions for the same > component from entity to entity within the same source file, at least for > synthesis ... but then how often is that an actual real life requirement > ?Article: 44683
Using the SCOPE Editor of Synplify Pro 7.1, I can't use two XC_PROPS attributes for the same net e.g. : instance databus_fpga* xc_props maxdelay=1.8ns instance databus_fpga* xc_props maxskew=0.2ns The EDF netlist contains only the last attribute, in this example, the maxskew attribute. If I edit the UCF and add the two constraints, the PAR process will use these two attributes. Anyone have an idea on how to tell Synplify to use multiple constraints for a same net? Thanks!Article: 44684
In article <3D1A4B45.671D8A28@mail.com>, John_H <johnhandwork@mail.com> wrote: >Suppose one part of a long logic path takes two levels of logic from input A to >register X. >Suppose another part of the logic feeding register X takes 14 levels of logic >from input B. > >Pipeling suggests you'd want a pipeline of 2 for the one input and a pipeline >of 14 for the other. How do you resolve the difference? > >Feedback loops are where I need to keep the pipelining to a minimum. Otherwise >I manually pipeline my design at many opportune places. One option is C-slowing, where you interleave C separate computations. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 44685
Marc, I appreciate the question. I forgot the async constraint :(, so my claim to 20 nS for the async reset distribution is suspect. I have not used any user driven asynchronous resets for a few years, and it slipped my mind to add the constraint from the added registered reset input. I'm thinking that if I have a multi-cycle active reset input, that I will not have to enable the reg_sr_q option in the timing analyzer. I noticed on my test case, that the report unconstrained paths did not flag the routed but unconstrained net, yet another phenomenon to investigate. Thanks again and the rest of the newsgroup for their comments. I don't know what the constrained result will be yet. I have to jump thru hoops to get access to the design again ... Fortunately, I believe the five prototype systems are still in house. Newman > > You probably did, but I have to ask... did you have specific > constraints on the resets? I don't believe they are constrained by > your normal clock constraint because the target of the reset net is > async. >Article: 44686
Jim Granville wrote: > > rickman wrote: > > > > The software is something that you need to take special care about. Be > > sure to save the version that you did your original design with. It is > > not uncommon that when they "improve" the software to work with the > > newest family it does not work as well with older families. > > > > It is just a matter of economics to the FPGA vendors. They have to > > focus on selling the newest, biggest, highest profit margin chips. This > > gets design wins and brings in the most money. Once a chip has a few > > years on it and it is on the downhill side of the production ramp, the > > software guys have no reason to optimize the tools for it. > > > > Just a fact of life. So cover your rear by keeping back versions of the > > software. > > This is good version control practice, and the moves to time-lock > software are not likely to help users in this situation. > > -jg I think people have misunderstandings of how the Xilinx software is licensed. I am pretty sure I have read in this newsgroup postings from Xilinx representatives that the Xilinx software will continue to operate after the license has run out. Only the support is ended. Someone please correct me if I am wrong. If Xilinx requires you to migrate to the newer versions of the software, we would have to consider that their products are unsupportable in the long run, and would seriously consider halting all development and move to Altera devices. So please tell me that this is not so. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 44687
I'm pretty sure that all the modern synthesizers will infer the optimum ripple carry using dedicated resources type adders. Synopsys Design Compiler even will if you are using the Xilinx designware libraries. Don't instantiate unless you have no choice, and in this case, you do. Regards kkdeep@mailcity.com (kuldeep) wrote in message news:<a0f016a9.0206242214.8845d5c@posting.google.com>... > Hi, > 1. is there any coding guidelines to use carry chains in xilinx fpga > (Virtex E) or i have to use coregen. > 2. is there any better method of coding a 12 bit adder than using > sum <= input1 + input2 > where sum, input1 and input2 are vectors. > > TIA > regards > KuldeepArticle: 44688
The First IEEE International Conference on Field-Programmable Technology (FPT) Venue: The Chinese University of Hong Kong, Hong Kong 16-18th December, 2002 (Submission Deadline: 15th July, 2002) Final Call for Papers Sponsored by The Croucher Foundation The IEEE Electron Devices Society The IEEE Computer Society The IEEE Hong Kong Section Computer Chapter The Department of Computer Science and Engineering, CUHK The IEEE Hong Kong Section Electron Devices Society CONFERENCE THEME Field-programmable technologies, including complex programmable logic devices and systems containing such components, have become an important topic of research for universities, government, and industry worldwide. Field-programmable devices combine the flexibility of software with the performance of hardware. Their regular structure facilitates rapid improvement in density, capability and speed. Field-programmable systems have a wide variety of applications, such as accelerating computations in molecular biology and medical imaging, low-power control and data processing for palm-size computers, and emulating novel electronic products before manufacture; even advanced microprocessors from Intel and ARM have benefitted from field-programmable hardware emulators. The areas of interest of this conference include the following: * Applications of field-programmable technology: biomedical and scientific computation accelerators, network processors, real-time systems, rapid prototyping, hardware emulation, digital signal processing, interactive multimedia, machine vision, computer graphics, cryptography, robotics, manufacturing systems, embedded applications, evolvable and biologically-inspired hardware. * Design techniques and tools for field-programmable technology: placement, routing, synthesis, verification, technology mapping, partitioning, parallelisation, timing optimization, design and run-time environments, languages and modelling techniques, provably-correct development, intellectual property core based design, domain-specific development, hardware/software co-design. * Architectures for field-programmable technology: field programmable gate arrays, complex programmable logic devices, field programmable interconnect, field programmable analogue arrays, field programmable arithmetic arrays, memory architectures, interface technologies, low-power techniques, adaptive devices, reconfigurable computing systems, other emerging technologies. * Device technology for field-programmable logic: programmable memories including non-volatile, dynamic and static memory cells and arrays, interconnect devices, circuits and switches, emerging VLSI device technologies. SUBMISSIONS The program committee solicits papers describing original research in field-programmable technology, including, but not limited to, the areas of interest indicated above. Papers should be submitted electronically in PDF format, following the IEEE style (http://www.computer.org/cspress/instruct.htm). Full papers should not exceed 8 pages in length, while posters should not exceed 2 pages in length. Submission guidelines and instructions are available from http://www.icfpt.org. A limited number of grants will be available to support attendance at the conference. Questions regarding the FPT conference, including the submission procedure and grants, can be sent to: fpt@icfpt.org DEADLINES and KEY DATES * Submission of papers: 15th July, 2002. * Notification of acceptance: 20th September, 2002. * Final papers & registration due: 18th October, 2002. KEYNOTE SPEAKERS (in alphabetical order) Erik Cleage, Senior Vice President, Marketing, Altera Corporation Michael J. Flynn, Professor of Electrical Engineering, Stanford University Patrick Lysaght, Director, Xilinx Labs Tsugio Makimoto, Chief Technology Officer, Sony Corporation ORGANISING COMMITTEE Philip Leong (Co-Chair), Chinese University of Hong Kong Wayne Luk (Co-Chair), Imperial College, UK S.C. Chan, University of Hong Kong Anthony Fong, City University of Hong Kong Ted Kok, Hong Kong University of Science and Technology Henry Lau, University of Hong Kong Kin Hong Lee, Chinese University of Hong Kong Monk Ping Leong, Cluster Technology Ivan K.H. Leung, Center for Large Scale Computation Kai Wing Tse, University of Hong Kong Yu Liang Wu, Chinese University of Hong Kong Cedric Yiu, Hong Kong Polytechnic University Evangeline F.Y. Young, Chinese University of Hong Kong ADVISORY BOARD Anant Agarwal, Massachusetts Institute of Technology Hideharu Amano, Keio University Jeffrey Arnold, Adaptive Silicon Peter Athanas, Virginia Tech Juergen Becker, Universitaet Karlsruhe (TH) Don Bouldin, University of Tennessee Gordon Brebner, University of Edinburgh Duncan Buell, University of South Carolina Mike Butts, Cadence Design Systems Peter Y.K. Cheung, Imperial College C.S. Choy, Chinese University of Hong Kong Richard Cliff, Altera Andre DeHon, California Institute of Technology Oliver Diessel, University of New South Wales Apostolos Dollas, Technical University of Crete Hossam ElGindy, University of New South Wales Michael Flynn, Stanford University Masahiro Fujita, University of Tokyo Manfred Glesner, Darmstadt University of Technology Yoshiaki Hagiwara, Sony Reiner Hartenstein, University of Kaiserslautern Scott Hauck, University of Washington Jifeng He, United Nations University Xianlong Hong, Tsinghua University Brad Hutchings, Brigham Young University T.T. Hwang, National Tsing Hua University Craig Jin, University of Sydney Patrick Kane, Xilinx Tom Kean, Algotronix David Kearney, University of South Australia Paul Lai, Score Concept Semiconductor Stephen Lai, Solomon Systech Miriam Leeser, Northeastern University Patrick Lysaught, Xilinx Tsugio Makimoto, Sony Bill Mangione-Smith, University of California Los Angeles Oskar Mencer, Bell Laboratories Paul Metzgen, Altera George Milne, University of Western Australia Tulika Mitra, National University of Singapore Toshiaki Miyazaki, NTT Network Innovation Laboratories C.H. Ng, SUGA Electronics Victor Ng, Micom Tech Christof Paar, Ruhr-Universitat Bochum Ian Page, Celoxica Viktor Prasanna, University of Southern California Michel Renovell, LIRMM Jonathan Rose, University of Toronto Martine Schlag, UC Santa Cruz Mark Shand, Compaq System Research Center Satnam Singh, Xilinx Tim Southgate, Altera Thambipillai Srikanthan, Nanyang Technological University Yihe Sun, Tsinghua University Russell Tessier, University of Massachusetts Steve Trimberger, Xilinx Laurence Turner, University of Calgary John Villasenor, University of California Los Angeles Jean Vuillemin, Ecole Normale Superieure John Watson, Quicksilver Steve Wilton, University of British Columbia Weng Fai Wong, National University of Singapore Roger Woods, Queen's University of Belfast Hiroto Yasuura, Kyushu UniversityArticle: 44689
Forgive me if this is a stupid question but I am quite new at the PLD game. I am using the Quartus II web edition and while coding in VHDL, I cannot use while loops. The only type of loop that the compiler seems to be happy with is a for loop. There are also other basic functions that the compiler is not happy with like exit etc. Is this correct? Is Quartus limited to select functions? Is there anything that I can do about it? Thanks for your time RyanArticle: 44690
Hi all, Before being programmed, will a blank CPLD affect the rest of the circuit on a board? What status are all the pins with such a blank CPLD? Cheers. MinlinArticle: 44691
Minlin Fan <minlinf@hotmail.com> wrote: : Hi all, : Before being programmed, will a blank CPLD affect the rest of the circuit on : a board? What status are all the pins with such a blank CPLD? It should be stated in the datasheets... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 44692
Quartus is pretty poor at VHDL synthesis (lots of syntax errors just crash Quartus). Usually I'd recommend using Leonardo for synthesis and Q2 just for Place and route. However I'm not sure if this option is available in the web edition or not. Quartus can't handle user generics, various VHDL constructs and in general synthesises poorly even when it can understand th code. Paul "Ryan" <ryans@cat.co.za> wrote in message news:3d1b38fe.0@obiwan.eastcoast.co.za... > Forgive me if this is a stupid question but I am quite new at the PLD game. > I am using the Quartus II web edition and while coding in VHDL, I cannot use > while loops. The only type of loop that the compiler seems to be happy with > is a for loop. There are also other basic functions that the compiler is not > happy with like exit etc. Is this correct? Is Quartus limited to select > functions? Is there anything that I can do about it? > > Thanks for your time > Ryan > >Article: 44693
Hi, few days ago the oscilator implementation with external RC has been discussed in the list. Now I'd like ask you, if it possible to make the oscilator only with external 32kHz crystal in Xilinx 95xx and CoolRunner series. Thank you. AndrejArticle: 44694
Hi all! I'm not that confident about differential signaling so I'm asking here for advice. I have a radio front-end PCB with two 1-bit outputs, one data signal and one clock signal (about 18 MHz) both have limited sving, Vol = 2.5-0.8 V Voh = 2.5 v Rise and fall times are 30 ns. In a lab setup I need to directly interface the signals to a Virtex-E. The Virtex is on another PCB. I plan to test if I can configure the Virtex-E I/Os as LVPECL and add a 100 ohm termination between one output and Vdd. Should I expect this to work or I am violating the LVPECL specs for the Virtex-E? Note that this is only a lab setup and it only has to work for a few hours ;) Actually it is possible to move some "jumpers" on the radio front end PCB to get full I/O sving. The only problem is that the so called "jumpers" are 0402 zero ohm resistors and I can hardly see those bastards and I would like to avoid resoldering Thanks, Jonas Thor thor(at)sm(dot)luth(dot)seArticle: 44695
newman5382@aol.com (newman) wrote in message news:<e6038423.0206261838.30a18a51@posting.google.com>... > Marc, > > I appreciate the question. I forgot the async constraint :(, so my > claim to 20 nS for the async reset distribution is suspect. I have > not used any user driven asynchronous resets for a few years, and it > slipped my mind to add the constraint from the added registered reset > input. > I'm thinking that if I have a multi-cycle active reset input, that I > will not have to enable the reg_sr_q option in the timing analyzer. > I noticed on my test case, that the report unconstrained paths did > not flag the routed but unconstrained net, yet another phenomenon to > investigate. > Thanks again and the rest of the newsgroup for their comments. I > don't know what the constrained result will be yet. I have to jump > thru hoops to get access to the design again ... Fortunately, I > believe the five prototype systems are still in house. I haven't yet done any comprehensive checking, but just putting NET "*reset*" MAXDELAY = 20ns; TIMESPEC "TS_RESETBRAM" = FROM FFS(*reset*) : TO : RAMS : 20 NS; seems to generate close to what Anyone know of any limitations to these constraints (reasons they won't work or stuff they won't cover)? Fair warning: using something like *reset* will pick up nets that are hidden deep in the design. If timing analyzer stops working after adding this, remove the long lines in the .pcf file that were added by the *reset*. It doesn't handle long net name constraints correctly (a bug report has aleady been filed). Have fun, MarcArticle: 44696
Hi, I have the following problem. After synthesizing a design with leonardo Maxplus is used to place and route the design everything functions as it should. However using the same *.edf file in Quartus after fitting and performing timing analysis the the following message is produced: ->Warning: Circuit may not operate. 1629 non-operational path(s) clocked by clock clk have clock skew larger than the data delay. See the Compilation Report for details. I have tried the solution as Altera has given with setting the LPM memories used to a REGISTERED data in (it was already set to REGISTERED). Anyone any idea how to solve this problem. And why does Maxplus not give any warning/errors..... Kind regards, RolandArticle: 44697
Hi, MAX+plus II only checks for clock skew vs. data delay if you do a timing analysis after compilation or during compilation only when timing constraints were set. The problem also depends largely on placement and it could be that MAX+plus II just chooses a different placement then Quartus, which might be the reason why you don't see the problem in Quartus. If you use global clocks you should not see this message. Probably you're using an internally generated clock that is not using a global net. Depending on the device family you have more or less global resources available that can be driven from inside the chip. In order to achieve this you would either need to instantiate a primitive called "global" or make an assignment "Gloab Signal = On" to the source of your clock. If you ran out of global signals or if they are not available because they are all used by signals from dedicated input pins you can use floorplanning (Cliques or LogicLock). Place all register together that are driven by the clock in question. You might also want to analyze the fanout on the clock in question and check for other high fanout signals in your design. Regards Wolfgang http://www.elca.de "Roland Manders" <roland.manders@philips.com> schrieb im Newsbeitrag news:3d1b1d7b$0$223$4d4ebb8e@read-nat.news.nl.uu.net... > Hi, > > I have the following problem. > > After synthesizing a design with leonardo Maxplus is used to place and route > the > design everything functions as it should. > > However using the same *.edf file in Quartus after fitting and performing > timing > analysis the the following message is produced: > > ->Warning: Circuit may not operate. 1629 non-operational path(s) clocked by > clock clk have clock skew larger than the data delay. See the Compilation > Report for details. > > I have tried the solution as Altera has given with setting the LPM memories > used to a REGISTERED data in (it was already set to REGISTERED). > > Anyone any idea how to solve this problem. And why does Maxplus not give any > warning/errors..... > > Kind regards, > Roland > >Article: 44698
Hey, with Windows I have lowered standards. Six days between reboots is a miracle. By 2006, Windows will have the same stability as Unix circa '75. "Petter Gustad" <newsmailcomp2@gustad.com> wrote in message news:87znxjiaqf.fsf@filestore.home.gustad.com... > "Kevin Neilson" <kevin-neilson@removethistextattbi.com> writes: > > > I know Xilinx says that they don't yet support XP, but I've been using it > > and have had no problems (other than those I would normally have). On the > > contrary, I'm much happier, because instead of rebooting ~6 times per day on > > ME I'm rebooting once every six days. > > Even though SUN's are expensive they are very stable: > > scims:pegu $uptime > 3:28pm up 91 day(s), 39 min(s), 4 users, load average: 1.02, 1.01, 1.01 > > 91 days ago they had to remove the power in the entire office > building. > > > I was struggling with a problem with a faulty BSDL file the other day. > iMPACT crashed and caused Win2k to freeze. I ended up debugging the > BSDL file under Solaris (writing to an SVF file) where impact simply > gave an error and bailed out. At least it didn't crash the OS. > > Petter > -- > ________________________________________________________________________ > Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 44699
I might have to take back my statement. I'm now having problems whereby the placer won't place everything, but the router will go ahead and route the items that were placed (?). I see that everything routed, so I think everything's cool, but upon closer examination I find that everything that was PLACED was routed, but there are still unplaced items. I've been informed (though it hasn't been verified because we upgraded all the workstations in our office to XP) that this only happens on XP. -Kevin "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3D1770B5.11971E9E@yahoo.com... > I am looking at buying a new PC and it is hard to find units that come > with anything other than XP. The Xilinx web site does not say their > tools run under XP. But has anyone tried it? Any word on how well it > works? > > Any word on when Xilinx will be supporting XP? > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAX
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