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 Basically the circuit input and output consist of a decoder and encoder. All the signals are clocked before entering the system. I have done some test today and everything seem to be working fine when I connect the output to the input of the system but when using a GPS system to produced the input datastream, the system decodes it incorrectly. I have measured the signals/datastream produced by the GPS and it seem to be correct but once it enters the system and that is when it all goes wrong. The clock used to produced the trailing edge comes from the GPS system but it isn't the system clock. The GPS clock signal is used for the decoding process. What could be wrong with system? Thanks Paul kayrock66@yahoo.com (Jay) wrote in message news:<d049f91b.0203051241.14abc58d@posting.google.com>... > Maybe you can describe the circuit you're using, but if you're doing > something asynchronous that depends on the relative delays of gates > then all bets are off. When you say this signal is a clock, is it THE > clock for the design, or can you sample it with another higher > freuency clock? > > paul.lee@sli-institute.ac.uk (Paul) wrote in message news:<9aeb7852.0203050323.12f72b04@posting.google.com>... > > Hi everyone, > > > > I'm producing a trailing edge pulse from a clock and passing it > > straight out as an output port for testing purposes but some of the > > pulses are missing when implementing onto a FPGA. It works fine when > > simulating with Modelsim. > > The clock going into the FPGA is correct. > > > > Could it be a metastability issues? > > > > > > Any help will be great. > > > > Thanks > > > > Paul LeeArticle: 40401
Austin Lesea <austin.lesea@xilinx.com> writes: > Martin, > > Nope. > > How about the 2V40? Pretty tiny, cs144 package (smallest)? > I wonder... could I solder onto the balls for prototyping..... Anyone have any ballpark idea how much these devices cost? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 40402
--------------49D5686D91290DAF637EC6CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Colleague,
On behalf of the ICCAD 2002 Executive Committee, we would like to invite
you to participate in the 2002 International Conference on
Computer-Aided Design. ICCAD 2002 has broadened its scope and created a
new subtopic entitled "CAD Problems in Emerging Technologies". More
details on this area and others can be found in the Call For Papers
below or on the ICCAD website at http://www.iccad.com/.
Please note that the prestigious ICCAD William J. McCalla Best Paper
Award, which includes a significant monetary recognition, will be
awarded to recognize one or more outstanding paper submissions.
Best regards,
Larry Pileggi, General Chair
Andreas Kuehlmann, Program Chair
Hidetoshi Onodera, Program Vice Chair
----
CALL FOR PAPERS
THE INTERNATIONAL CONFERENCE ON COMPUTER-AIDED DESIGN
2002
ICCAD is oriented toward Electronic Design Automation professionals,
concentrating on CAD for Integrated Circuit and System Design.
NOVEMBER 10-14, 2002
DOUBLETREE HOTEL, SAN JOSE, CA
AUTHOR'S SCHEDULE:
Deadline for submissions: April 17, 2002
Notification of acceptance: June 28, 2002
Deadline for final version: August 9, 2002
Papers will not be accepted for submission after 5:00 PM
Mountain Daylight time. This deadline is firm and inflexible.
No exceptions will be made.
AREAS OF INTEREST:
Original technical papers on (but not limited to) the following topics
are invited:
1) PHYSICAL DESIGN AND TEST
1. Placement and floorplanning techniques. RTL area estimation.
Partitioning for layout.
2. Timing-driven and noise avoidance routing. Automatic special net
routing. Layout for manufacturability. Routing estimation.
3. Module generation and layout synthesis. Layout migration. Symbolic
design & compaction. Physical design planning. Layout verification.
4. Analog, RF, and mixed signal circuit synthesis, optimization and
layout. Analog, RF and mixed signal simulation techniques. Mixed
technology design simulation (thermal, packaging,
micro-mechanical).
5. Testing. Yield and manufacturability analysis. Fault modeling,
delay test, analog and mixed signal test. Fault simulation. ATPG.
BIST and DFT. Memory, core and system test.
2) SYNTHESIS AND SYSTEM DESIGN
1. Combinational and sequential logic synthesis. Optimization for
area, timing, power. FPGA optimization. Interaction between layout
and logic synthesis. Technology mapping. Asynchronous circuit
design.
2. High-level synthesis. Datapath and control synthesis. Synthesis
with IP libraries and reuse. Estimation and analysis in high-level
synthesis. Memory system synthesis and optimization. HW interface
synthesis.
3. HW/SW co-synthesis. System synthesis. Hardware platform synthesis
and optimization. ASIP synthesis. Core based design. Embedded
software synthesis. HW and SW estimation and analysis. Interface
synthesis.
4. Specification, modeling and validation of embedded systems.
Real-time software and RTOS. System level reuse techniques.
Embedded systems engineering Rapid system prototyping.
3) VERIFICATION, MODELING AND SIMULATION
1. Interconnect parameter extraction and circuit model generation.
Interconnect level analysis. Noise analysis.
2. Gate, switch, and circuit level timing and power analysis.
3. Formal verification techniques. Switch, logic and high-level
simulation and design validation. HW/SW co-simulation.
Combinational and sequential equivalence checking. Model checking.
Theorem proving.
4. CAD problems in emerging technologies. Modeling, simulation and
analysis for new device, circuit and system concepts.
Nanotechnology, molecular and bioelectronics, MEMs, optical and
photonic devices.
One or more of the outstanding submissions will be recognized with the
ICCAD William J. McCalla Best Paper Award.
Proposals for Panel Sessions and Tutorials are also invited. Panel
proposals should be sent to the Vice Chair. Tutorial proposals should be
sent to the Tutorial Chair.
AGAIN THIS YEAR: ICCAD submissions must be made electronically in PDF
format through the ICCAD web site. Reference the ICCAD WEB page for
instructions on electronic submissions: http://www.iccad.com. Please
submit the following in PDF format:
* One pdf file which should contain the complete paper including the
title and abstract. This file should be no more than 8 pages using
proceedings format, double columned, 9pt or 10pt fonts including
figures, tables and references (in the proceedings, four pages are
free of charge and each page beyond four pages is charged $100.00
per page.)
* Papers in the wrong format, exceeding the eight page limit, or
identifying the authors or their affiliations will be rejected
immediately.
* Previously published papers will not be considered; this includes
papers appearing in published workshop proceedings. Papers
presented only orally, or only available via informal distribution
at a workshop or meeting can be submitted for publication at ICCAD.
* Authors should clearly address the significance of their
contribution as part of the paper.
Please direct all correspondence to:
ICCAD Publications Department:
MP Associates, Inc Telephone: (303) 530-4562
5305 Spine Rd., Suite A Fax: (303) 530-4334
Boulder, CO 80301 Email: terri@mpassociates.com
Home Page: http://www.iccad.com
ICCAD Executive Committee:
Rolf Ernst, Past Chair
Lawrence T. Pileggi, General Chair
Andreas Kuehlmann, Program Chair
Hidetoshi Onodera, Program Vice Chair
Majid Sarrafzadeh, Tutorial Chair
Donatella Sciuto, European Representative
Kiyoung Choi, Asia Representative
Georges Gielen, IEEE CASS Representative
Soha Hassoun, ACM/SIGDA Representative
John Darringer, IEEE-CS/DATC Representative
Article: 40403Hi. I would like to use virtex 2 OBUF_LVDCI_DV2_18 output pad in order to drive a clock signal of 250 MHz. Is it possible ? Will I get good clock shape on the board ? How can I verify that I will get good clock shape on the board ? ThankX , Nahum.Article: 40404
I am considering using a lithium battery on a board instead of a config device to enable my Altera FLEX10KA to retain its configuration. Has anyone any idea of the absolute min quiescent current I can expect a 10KA to draw? Thanks, Chris.Article: 40405
As a longtime resident of Toronto, I have to say that the market here is fairly broad, and better than most places. Ottawa is 'silicon valley north' and you can hunt jobs there from here. They look in Toronto for most of their hiring. Ottawa has very high tech firms which used to be desperate for highly specialized skills expecially in silicon and telecommunications, but with Nortel heading down, I would be surprised if the market there is still hot. I can suggest a place where you might get a job fairly easily. Of course, there is a *reason* for this, but I'll gladly take part of your salary for steering you to him. P.S. . I'm suing him for the last two months wages of a seven month contract work effort, so this might help me to balance the books. Just HOW desperate are you??? ;-) "Albert" <wagain@hotmail.com> wrote in message news:f0hh8.26266$eb.1298355@news3.calgary.shaw.ca... > Thank you all of your responses. I am new in Canada, so I cant go to USA > unless getting an offer first. But maybe I should go to Toronto or Ottawa > 'cause somebody says that it is a little easier to find a job there than in > Vancouver. Is there anyone from Toronto or Ottawa? Could you please tell a > little about this kind of job market there? I have no much stuff yet, so I > can move very easily. > > Jay <kayrock66@yahoo.com> wrote in message > news:d049f91b.0203041516.589a1f21@posting.google.com... > > Come on down to the CA (California that is), I have head hunters > > calling all the time... > > > > "Albert" <wagain@hotmail.com> wrote in message > news:<01kf8.239995$I8.48176768@news4.rdc1.on.home.com>... > > > Hi, > > > > > > I have many years of experience on DSP/embedded system and FPGA/CPLD > design. > > > I'm in Vancouver and looking for jobs. If the company you work for has > any > > > opening or you know any job opportunities that my skills fit, and your > > > information finally leads to my job, I will be glad to share half of my > > > first two months' net income to you. I guarantee it. I will be glad to > > > relocate to other cities in Canada. It is double wins, for me, I got a > job > > > and sharing my half of salary to you is absolutely no problem, and for > you, > > > that position you know will doom to be filled by someone finally, why > don't > > > you do me a favor? > > > > > > I appreciate any reply. My email address is: wagain@hotmail.com. > > > > > > > > > Thank you for your time. > > > > > > Albert > > >Article: 40406
Ray Andraka wrote: > It sounds like we are all barking up the wrong tree. The solution is not to > go to more and more memory...There is something to be said about using low > cost PCs...instead, Xilinx needs to get the modular flow working so that one > can truely partition a design and run each partition through the entire > process, including place and route. The individual completed parts can then > be stitched together. Until the modular flow is working though, we are stuck > with the memory limits of the machines we work on. > > Johann Glaser wrote: > Ray, What are the limitations on the modular design flow in real life ? I've looked at it and it seems clumsy and awkward but useable as long as the device density isn't too high, otherwise the limitation to rectangular regions will make layout difficult. It also seems that the new X-Y grid system might make laying out the blocks less fraught ?Article: 40407
The Virtex-II family ( all 11 different devices in 10 different packages, over 30 combinations ) support LVDS on ALL their I/O pins. Isn't that enough for a Diplomarbeit ? Let me know if you need some help (I have been in your shoes...) Gruß Peter Alfke, Xilinx Applications ========================================= msauer@gmx.net wrote: > Hello, > > do you know an FPGA wich supports an LVDS interface? I need one for my > diploma thesis and so far I can find only one from Xilinx and Altera. > Exist any other firms wich have such FPGAs? > Tank your for your answer. > > bye > > martinArticle: 40408
"g. giachella" wrote: > Anyone knows if ISE Webpack supports Virtex QPRO devices ? > I know it supports Virtex II and Virtex E up to 300K gates but what = > about QPRO Virtex ? > > Thanks in advance. From an architecture and software support point of view, there is no difference between the commercial part and its QPRO derivative. Peter Alfke, Xilinx ApplicationsArticle: 40409
Ray explained it very well: You can get any frequency resolution you want, just by making the accumulator big enough. The clock frequency then determines the jitter. It is hard for me to believe that a power supply needs better than 3 ns jitter. The power transistors don't turn on or off that fast. So, 10 to 50 MHz clock frequency can give you extremely fine micro-Hz frequency resolution, with 20 to 100 ns output jitter. And any FPGA or CPLD can do that. Peter Alfke ================================================= "F. Modderkolk" wrote: > I wrote the answers between the lines :) > > "Paul" <nospam@nospamplease.com> wrote in message news:<rjnh8.45999$R16.6385438@news11-gui.server.ntli.net>... > > You'll have to explain further, because to me this all sounds like I don't > > understand your design choice. > > > > Are you planning some complex digital control loops or something? > > Yes, when I change the load at the output of the power supply, the > expected current drops or rises. As a result my output voltage drops > or rise. By chanching the switching frequency, I can deliver more > power at the output. I want the output-voltage to be constant. > > > > If not aren't you just describing a voltage/frequency convertor? > > It's a kind of a voltage/frequency converter only there is no straight > relation, thats why I want to use a DSP or FPGA. I also want to switch > the fets with an delay of 30º in one period. > > > > Are you sure you need 1000th Hz resolution? Aren't variations in your fet > > switching time likely to be greater? > > No I really need that resolution, because between two different > frequencies with a clock of 300MHz is a step of 0.2A. So that's > already quit high, but acceptable. A lower clock is therefor no > option. > > > Why not use a much lower system clock? > > > > Couldn't a single chip VtoF chip do the job? > > > > "F. Modderkolk" <frankmotje@hotmail.com> wrote in message > > news:82eb64d2.0203060324.3b54c594@posting.google.com... > > > I need a digital device in my power supply to switch 6 fet's on and > > > off. The device needs to generate a frequency from the supplied > > > voltage. If the voltage drops, the switching frequency also has to > > > drop and when the voltage rises the frequency has to rise. This way I > > > want to control my output current. the switching frequency of the fet > > > must be between the 100 kHZ and the 300 kHz. To get a good resolution > > > in the different frequencies I want to create, my clock needs at least > > > 300 MHz. The preference is a higher frequency of the clock, because > > > then I can create more switching frequencies so my output control gets > > > better. > > > To create a solutiontion for my problem, I want to use an DSP or FPGA. > > > I don't know what's the best solution. I also have to remind the > > > costs, they aren't allowed to get to high. Because I don't have > > > anything to program the device I also have to buy that. What do you > > > suggest me to use. DSP or FPGA, and witch one? > > > > > > Thanks!Article: 40410
In article <3C85C76F.3B5FA1A5@atoll-net.de>, Lars Rzymianowicz <larsrzy@atoll-net.de> wrote: >Nicholas Weaver wrote: >> The hammer looks like a GREAT solution, assuming Microsoft will >> support it. > >And it will be an even better solution, if M$ software isn't running >at all ;-) Linux for x86-64 is up and running afaik ;-) >And since Xilinx and most other EDA vendors support Linux now, why >step down to the bluescreen? Because they are supporting the tools in WINE, so you keep the windows API and associated limitations. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40411
I am looking for information on PLLs with multiple phase error detectors, in order to achieve mutual clock synchronization between multiple nodes connected together on an E1 physical layer. I am interested in any references that contain information about implementation and stability of systems with mutually synchronized clocks. We would implement this in an FPGA. =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 40412
Here's a couple more: Quicklogic - http://www.quicklogic.com/ Lattice ORCA 4 - http://www.latticesemi.com/products/fpga/orca/orca4/index.cfm msauer@gmx.net wrote: > > Hello, > > do you know an FPGA which supports an LVDS interface? > For my diploma thesis I need one FPGA which has an LVDS interface, so > far I can find onyl one from Xilinx and Altera, there are more firms > which have such FPGAs? > Thank you for your answer. > > bye > > martin -- Tom Burgess Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3Article: 40413
Peter Alfke wrote: > > Ray explained it very well: > You can get any frequency resolution you want, just by making the accumulator big enough. > The clock frequency then determines the jitter. > It is hard for me to believe that a power supply needs better than 3 ns jitter. > The power transistors don't turn on or off that fast. > So, 10 to 50 MHz clock frequency can give you extremely fine micro-Hz frequency resolution, > with 20 to 100 ns output jitter. And any FPGA or CPLD can do that. A SMPS is a little tougher. Think of it as an energy balance system : When regulated, the energy loaded into the inductor balances exactly the energy removed. Energy is time related, & at 300KHz, 3ns is 0.1%, or 1 part in 1000. That's 5mV in 5V. A linear supply can do much better than that. 5mV is fine for PC supply, but the OP must be after something more, or he would not be looking at FPGA's :-) However, you can get 'better than clock' apparent energy resolution, by implementing a PWM = OnTime/TotalTime, and varying both values 98/100 is 98.000% 99/101 is 98.0198% (etc) 100/102 is 98.0392% (etc) Here you see a 0.02% transfer step size, with a clock of 30MHz This needs a table management, and 3uS decision rates, so is still significant silicon. All this to replace a 90c SMPS chip :-) -jgArticle: 40414
The references for stability... shouldn't they be contained in the ITU-T specifications regarding E1 reference timing? The clock distribution schemes, switchover conditions on signal loss, acceptable jitter transfer and tolerance are all part of the CEPT standard. Very constrained. Greg Neff wrote: > I am looking for information on PLLs with multiple phase error > detectors, in order to achieve mutual clock synchronization between > multiple nodes connected together on an E1 physical layer. I am > interested in any references that contain information about > implementation and stability of systems with mutually synchronized > clocks. We would implement this in an FPGA. > > =================================== > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.comArticle: 40415
ISE WebPACK doesn't support Virtex-I (Virtex). Instead, it supports Spartan-II which is virtually identical to lower density Virtex-I. I guess from Xilinx's perspective, people who are going for QPRO parts can easily afford ISE Foundation, so ISE WebPACK doesn't have to support it. Plus, Xilinx probably thinks ISE WebPACK is mainly for students/hobbiests/beginners, and it is not intended for doing a "serious" design that requires QPRO parts. I guess "serious" here means satellite communication or military applications. Kevin Brace (Don't respond to me directly, respond within the newsgroup.) "g. giachella" wrote: > > Anyone knows if ISE Webpack supports Virtex QPRO devices ? > I know it supports Virtex II and Virtex E up to 300K gates but what = > about QPRO Virtex ? > > Thanks in advance.Article: 40416
Is there is absolute maximum voltage specified for the DXP and DXN pins? Thanks!Article: 40417
>Creating testbench in Verilog for me is always time consuming. Is >there any program could help ? It's the TB design methodology! You'll find that transaction based methodology will speed up the process. Read http://members.aol.com/vhdlcohen2/vhdl/veriflang.pdf My last book also provides examples: --------------------------------------------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 * Component Design by Example ", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ------------------------------------------------------------------------------Article: 40418
NRZ is fine if you have exactly the same clock at the transmitting and the receiving end. If there is any question about clock accuracy, then Manchester is much better, since it is kind of self-clocking. But it has far more transitions ( max two per bit, vs max 1 for NRZ). That limits the max bandwidt, but may not be a problem with fibre. 8 or even 4 times oversampling with a free-running receiver clock is ok, provided you have solid signals, and almost no clock frequency uncertainty. Peter Alfke, Xilinx Applications ============================== Roberto Capobianco wrote: > Hi all, > i want to send on fiber a digital pattern of approximately 50 bits with Tbit > = 40ns (25MHz transmission clock). > First question : NRZ or Manchester code ? > Second question: UART and Manchester decoders in FPGA often use 16x > oversampling to sample at mid-bit of data cell. > This is impossible for me. > In the design at http://www.xilinx.com/xcell/xl17/xl17-30.pdf we have a 8x > oversampling manchester decoder > but with my flex (Altera ACEX 1K) is very difficult to have a single global > clock at 200MHz for all. > Exist different ways to realize a good sampling with a low frequency ? > > Thanks. > > -- > Roberto Capobianco > Consorzio RFX - CNR di Padova > C.so Stati Uniti, 4 > 35127 - Camin (PD) > email: capobianco@igi.pd.cnr.it > web: www.igi.pd.cnr.it > tel.: +39-049-8295048 > fax: +39-049-8700718Article: 40419
The performance of MXE can only be quantified in comparison to the MTI versions of Modelsim. 0 - 8,000 HDL statements, runs at ~30% of ModelSim PE performance 8,001 - 20,000 HDL statements, runs at ~10% of ModelSim PE performance over 20,000 HDL statements, ~1% of ModelSim PE performance Also, ModelSim XE can only perform timing simulations on Xilinx products.Article: 40420
On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com> wrote: I have not looked at the CEPT standard. We are using E1 physical layer stuff for a non-telecom application. Does the CEPT standard talk about mutual clock synchronization? If so, I would appreciate a pointer to this standard. I though that E1/T1 systems were typically clocked in a master/slave arrangement, or lived with slips. With regard to stability, I was thinking about the stability of the democratic clock, due to multiple feedback paths to the multiple phase error detectors on each PLL. >The references for stability... shouldn't they be contained in the >ITU-T specifications regarding E1 reference timing? The clock >distribution schemes, switchover conditions on signal loss, acceptable >jitter transfer and tolerance are all part of the CEPT standard. Very >constrained. (snip) =================================== Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 40421
The telecom timing management tends to be a central timing standard with the E1 signals deriving their timing from the reference. This distributed scheme leaves clock management in one central node. When you cross jurisdictions (e.g. France/England interface) you live with slips defined at a maximum rate. What I don't understand (since you are deviating from this standard) is what you gain by trying to "democratize" the independent timing elements. This is such a non-standard approach to my telecom background and to my timing system development in general that I can't make suggestions. What you're looking for, in effect, is to have three independent systems (for instance) come to a compromise on a common frequency so you end up with a very "symmetric" timing scheme? It would be soooo much easier if you chose one element to be the timing master. Greg Neff wrote: > On Wed, 06 Mar 2002 21:08:39 GMT, John_H <johnhandwork@mail.com> > wrote: > > I have not looked at the CEPT standard. We are using E1 physical > layer stuff for a non-telecom application. Does the CEPT standard > talk about mutual clock synchronization? If so, I would appreciate a > pointer to this standard. I though that E1/T1 systems were typically > clocked in a master/slave arrangement, or lived with slips. > > With regard to stability, I was thinking about the stability of the > democratic clock, due to multiple feedback paths to the multiple phase > error detectors on each PLL. > > >The references for stability... shouldn't they be contained in the > >ITU-T specifications regarding E1 reference timing? The clock > >distribution schemes, switchover conditions on signal loss, acceptable > >jitter transfer and tolerance are all part of the CEPT standard. Very > >constrained. > (snip) > > =================================== > Greg Neff > VP Engineering > *Microsym* Computers Inc. > greg@guesswhichwordgoeshere.comArticle: 40422
Kevin Brace wrote: > > Peter Ormsby wrote: > > > > > > Kevin, > > > > You have been exceedingly critical of Altera long before QII v2.0 WE was > > ever released. > > Although, I don't believe I was "exceedingly" critical of Altera > stuff, I was critical of free tools I downloaded from Altera like > LeonardoSpectrum-Altera Level 1 2001.1a.028 which crashed really easily > like when I stopped synthesis by pressing "Stop" button. > Although I have been using Xilinx ISE WebPACK for months, its synthesis > tool (XST) never crashes like that. > Shouldn't I be critical if something crashes so badly like that? > Yes, I use a Windows 98 PC which is known for its legendary instability, > but still XST doesn't crash like that... You can never assume largish software will be bug-free. I find and report bugs in all kinds of apps like mechanical/pcb cad packages, various compilers, etc. You *must* report bugs so that they get included in the next update. Mention you're a newish user so that the bug fixer can ask more relevant details. In the meantime, try to work around the problem. It's rare for the problem to be fatal *and* unavoidable, or it wouldn't be released. It is exceedingly frustrating to find a bug that crashes the app, but as long as it is acknowledged and logged, it makes you feel a little bit better that it'll be fixed some time. If it isn't, then think about switching brands.Article: 40423
I'm sorry, I was hoping to get this out 2 weeks ago. But anyway.... I'm proud to announce the availability of a free, high performance (1.3 Gbps in a Spartan II-100), and compact (<800 CLB slices), Rijndael/AES encryption core optimized for Virtex family FPGAs from Xilinx. It is fully key agile, uses 128b keys, and has a 5 stage pipeline. It is currently only available as a Foundation 4.1 schematic. It is available from http://www.cs.berkeley.edu/~nweaver/rijndael/ Enjoy. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40424
Personally, I prefer to instantiate the BRAM primitives directly rather than using the coregen. That way you lose the extra layer of abstraction, that in this case does little more than make it harder to simulate. If you do use the BRAM generator and select register inputs under the design options, then putting a small combinatorial mux in front of it should put the mux with the registers (at least the last layer of the mux if it is more than 2 inputs). If you are instantiating the BRAMs, then your muxes should be registered. One note of caution: if you are trying to get the most speed, keep in mind that you want the registers as close as possible to the BRAM. Putting muxes with those registers is going to tend to congest the routing there, which may slow your critical BRAM connections. For that matter, it also helps to keep the width of the BRAM relatively small so you don't have a ton of data lines going in and out (especially for dual ports with both ports used in both directions). "H.L" wrote: > Hello Ray, > thanks a lot your post clarified things. > Xilinx Core Generator cant put additional register on the EN signal, so the > only thing is to instantiate a D flip-flop and put it in the right place? > > Regarding my project I have to arbitrate the access in 3 BRAMs (registered > for the reason described above) so I think I must use a MUX_BUS from the > CORE GENERATOR (one MUX_BUS for each BRAM). I will use 3 MUX_BUS with 3 > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE). > If I use non-registered MUXs I think is not good for the following reasons: > 1) The timing analysis will not include them in the period calculation so I > will not be able to see if my FPGA meets the timing constraints > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I > said before I am going to use registered BRAMs do you think that these > registers are capable to cope with the inserted MUXs' combinatorial logic? I > don't know if these MUXs I'll use can be described as "large" or "small" > combinatorial logic. > > So the right thing to do is to use registered MUXs (LUT based only as Xilinx > says)? > > Best Regards, > Harris > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3C824FD0.71540235@andraka.com... > > > > > > "H.L" wrote: > > > > > Hi Ray, > > > I have seen these tips written by you many times in this group. I have > them > > > always as a guide but I want to see if I understand them right. Please > > > correct me where I am wrong: > > > > > > 1) The need for additional registers in DATA_IN and ADDR signals. > > > In BRAMs the EN and WE signals have long set-up times thats why we need > to > > > register the data_in and addr of the BRAM, in this way the addr and > data_in > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period > > > earlier (at 155MHz clock speed that means about 6 ns) the setup-time > for > > > these signals is not violated resulting BRAM to be in the operation mode > we > > > wish (read or write) the moment addr and data_in arrive. > > > > If you look at the data sheet, there are fairly long set-up times on all > the > > BRAM inputs. Routing to the BRAMs also adds to the delay, as does any > > combinatorial logic on these inputs. The idea of putting registers on the > > inputs (which includes the EN and WE inputs) is to minimize the amount of > delay > > added externally to these signals. Your understanding is a bit incorrect, > as > > what you are suggesting is delaying signals to allow a long combinatorial > > delay. That is dangerous, because there is no guarantee on the minimum > delay. > > Instead, what I am suggesting is to remove as much of the delay as > possible > > between the registers driving the BRAM inputs and the BRAM inputs, which > meahs > > avoiding combinatorial logic on these paths, minimizing the fanout of > these > > signals, and physically locating the registers close to the BRAMs. > > > > > > > > 2) The need for floorplanning > > > Xilinx software tool maybe has put the additional registers far from the > > > BRAMs, if this is the case we must manual place them near the BRAM to > > > decrease the propagation delay of the signals. > > > > That is correct. Routing in FPGAs is not just wire, it also consists of > > switches which add to the propagation delay of signals on the connections > > between logic. Manually placing the registers near the BRAM helps to > minimize > > the added delay. > > > > > > > > 3) Tying the WE,EN inputs and contol access through the address when > working > > > at high speeds. > > > Do you mean to keep WE,EN high all the time and when we wish not to use > the > > > BRAMs to write dummy data in some (or just one) specified addresses (or > > > address) reserved for this reason? > > > > That is correct. The set up times for EN and WE are nearly twice the > set-up > > times for address and data, so if we can eliminate these from the equation > we > > can run at a higher clock rate. They can be eliminated by always writing, > but > > directing the writes of invalid data to locations where it does not affect > the > > operation of the design. In the case of FIFOs, you can just park the > write > > address until you have a valid write, since you are presumably not reading > that > > data until it is valid. > > > > > > > > > > > Also I have another one question about BRAMs, Xilinx says that BRAMs' > DATA > > > OUT are already registered. In Xilinx Floorplanner I believe this > register > > > is "inside" the BLKRAM box so no manual floorplanning for the output is > > > needed. You need to manual floorplan (in the same way you do for the > inputs) > > > only if you choose to add an additional output register, correct? > > > > That is correct, the BRAM acts as though it is registered, although I > believe > > the actual implementation has the register on the address, not on the > memroy > > outputs. In any event, the clock to out time is long compared to that of > the > > CLB flip-flops. The system clock rate can be increased by putting an > additional > > register on the BRAM data outputs and placing that register physically > close to > > the BRAM (that register should have no combinatorial logic in front of > it). > > > > > > > > > > > I really appreciate your help. > > > > > > Best Regards, > > > Harris > > > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > > news:3C7FD73D.F6A3109A@andraka.com... > > > > VirtexE BRAMs can be written at 155MHz in any speed grade. To do so, > you > > > will > > > > likely have to put registers near to and with no logic between them > and > > > the > > > > BRAMs. Watch the loading too, routing to more than 1 BRAM for each > > > register may > > > > cause you some heartburn. At higher speeds, you probably should also > > > consider > > > > tying the WE, and ENA inputs active and controlling your access > through > > > the > > > > address registers instead. You'll also need to floorplan the > registers to > > > make > > > > sure they are located physically close to the BRAMs. > > > > > > > > "H.L" wrote: > > > > > > > > > Hi Peter, thanks for your reply > > > > > I was confident of this method's effectiveness but now I am worried > :)) > > > . I > > > > > have already done a timing analysis in the paper and also the > simulation > > > > > waveforms seem promising. > > > > > I didnt understand what do you mean when telling me that one of my > words > > > > > arrives early and the other one late. The transmitter sends to my > FPGA > > > an > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit > > > indicating > > > > > the transmission time period) and of course the 16-bit words that I > have > > > to > > > > > store. Every clock period (~6 ns) I have available in my ports one > > > 16-bit > > > > > word, I register two sequential words from the in port to a 32-bit > > > register > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in > > > another > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made" > > > which > > > > > are the BRAM data_in. All the above operations are in a process that > has > > > in > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz > using > > > the > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are > assigned > > > in > > > > > the falling edge of the 77MHz clock so as to be before the rising > edge > > > (of > > > > > the same clock) where the BRAM samples them. The write operations > are in > > > > > another process with the slow clock in its sensitivity list. > > > > > The timing waveforms of the simulation are the same with the timing > > > analysis > > > > > in paper but does this is a valid hardware design technique? > > > > > Thanks for your time and help! > > > > > > > > > > Best Regards, > > > > > Harris > > > > > > > > > > p.s: thats a small part of my design. I use DLL because other parts > need > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 > MHz > > > and I > > > > > got many timing errors (floorplanning managed to reduce them but > still > > > lot > > > > > of work to be done) > > > > > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > > > > > news:3C7E621F.1E77A244@xilinx.com... > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing > > > > > analysis. You > > > > > > will find that your clock-speed reduction buys you nothing, unless > you > > > > > also > > > > > > double-buffer the data. > > > > > > One of your words arrives nice and early, the other one late. > However > > > you > > > > > clock > > > > > > the BRAM, one of the two words has the same old short set-up > time... > > > > > > Double-buffering would help. But Ray has mentioned some neat > tricks to > > > > > avoid the > > > > > > long set-up time of the control inputs. > > > > > > > > > > > > I will get back with more constructive notes. "Gotta run" > > > > > > > > > > > > Peter Alfke > > > > > > =================== > > > > > > "H.L" wrote: > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want > to > > > store > > > > > then > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) > to > > > > > divide by > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to > > > write in > > > > > the > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one > > > operating > > > > > @ > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit > register > > > and > > > > > the > > > > > > > another one @ 75MHz to write the content of the 32-bit register > in > > > the > > > > > BRAM. > > > > > > > I am thinking to assign the BRAM's signals > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in > > > > > > > the falling edge of the 75MHz clock, the main reason for this is > the > > > > > setup > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns > > > before > > > > > next > > > > > > > rising edge of the clock where BRAM samples its inputs). My > question > > > now > > > > > :) > > > > > > > , if one process uses the falling edge of one clock does this > causes > > > > > > > problems to other processes in the design , e.g to processes > that > > > use a > > > > > > > different clock or to processes using the rising edge of the > same > > > > > clock? > > > > > > > > > > > > > > Best Regards, > > > > > > > Harris. > > > > > > > > > > > > > > -- > > > > --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 > > > > > > > > > > > > -- > > --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 > > > >
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