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
Hello all,
I use the startup_virtex primitive in my code to make use the dedicated
reset net in my FPGA. When I didn't use it, my reset signal had 620 fanout
and max pin delay 6ns and now with the startup_primitive instantiation I get
360 fanout but 9.3ns max pin delay. I think something I did wrong because
the delay increased. I looked in xilinx.com for further details but I am
still confused. I have 3 questions:
1) Do I have to use an IBUF for the reset signal before guide it to the gsr
pin of STARTUP_VIRTEX element?
Now I dont use this buffer and when I use it I get an illegal connection
error during translate (the port map seems correct).
U1: STARTUP_VIRTEX
port map (GSR=>reset_int);
U2: IBUF
port map (I=> sys_reset, --the reset pin
O=> reset_int); --IBUF output is input in
startup_virtex
2) Am I obliged to have an asynchronous reset in my Virtex-E design?
Now my reset signal is synchronous.
3) If my reset is asynchronous I only make use the gsr pin of
startup_virtex?
If my reset is synchronous I make use the gsr and the clk pin of
startup_virtex?
Thanks and my best regards,
Harris
Article: 40976There is a brief mention in my Xcell article on digital down conversion in FPGAs (see my website for a link) That article discusses more than just the frequency synthesis. There is more detail and more specifics on the frequency synthesizer part in Austin Lesea's Xcell article: http://www.xilinx.com/xcell/xl31/xl31_32.pdf Kelvin Hsu wrote: > You can browse through www.andraka.com. He has something on CORDIC used in > direct digital frequency synthesis. Does DDS mean direct digital synthesis? > > -- > Email: qijun@okigrp.com.sg > "Mot" <mister_mot@hotmail.com> wrote in message > news:a75cd014.0203190324.46563ed6@posting.google.com... > > Does any of you know some sites where I can view examples of DDS > > inplemented in an FPGA? > > > > thx motArticle: 40977
Hi, I'm developing a design on an APEX20KE in quartus. I have a signal that is mapped to either set or reset signals of flip flops that form a chain. This chain is jtag-controlled, and stores some information about configurable operation modes. That signal is a "load-default-configuration". What I would like to be able to do, is to provide an automatic meaning to do this "default-reset" every time the device has finished a configuration; then, to be able to drive it with a pin. I know there's a pin from the programming port called "CONF_DONE". Do you think I can use that? Thank you LuigiArticle: 40978
Aki Niimura wrote: > Dear Fellow FPGA designers, > > I would like to have your feedbacks / supports. > > Synplicity has released Synplify 7.0.x with lots of enhancements > last November. One of the enhancements is called "Tri-state push thru" > feature. > > The following are excerpts from e-mails from Synplicity > explaining how the feature works: > > >>For example in the verilog code >> >>assign data = en ? data_in : 1'bz; >>always @(posedge clk) >>begin >>q_out = data; >>end >> >>will be implemented with tristate after the q_out flipflop currently ( 7.02 >>) to match simulation. The tristate will be implemented >>before the q_out flip flop with the switch ( 6.2.4 behavior). >> > >>In 6.2.4 we didn't perform Tri-state push through across boundaries >>as like every other Synthesis tool on the market. We (and many >>of our customers) deemed this logically incorrect. We enabled >>Tri-state push thru in 7.0, but some of our customers requested >>a 'compatibility' switch so that our results matched our competition, >>hence the switch in 7.1. >>This switch fixes what we consider to be bad logic and was a >>definite requirement from our customers. >> > > Simply saying, Synplify 7.x will implement the logic differently from > the RTL code you have specified to prevent simulation from causing > a mismatch. This is not a correct statement. The RTL example above when simulated produces a 'Z' state at the output. The change we made was to synthesize hardware that also produces a 'Z' at the output under the same conditions. Tristates are pushed across components if the RTL would have propagated a 'Z' and if the destination is sensitive to the difference between a 'Z' and an 'X'. Usually this is an output port of a module or a node with other tristate drivers. > > I have noticed this new feature because my design becomes 30% larger > and yet slower when I resynthesized my existing design using Synplify > 7.0.2. > > With this feature: 1086LUTs (30.2MHz) <<-- default in Synplify 7.x > W/o this feature : 833LUTs (31.8MHz) > > My design uses tri-state gates to implement a multiplexer with > a large number of inputs efficiently which is a widely used > FPGA technique. I hand-crafted the multiplexer such that speed > and logic size are both satisfied. > Synplify 7.x will implement the multiplexer using LUTs and put > a tri-state gate after the LUTs. (tri-state gate is pushed-thru) We can investigate the QOR impact. It is possible that what we should have done is to leave the mux as a tristate mux, but place an additional tristate driver with appropriate control logic after the flip-flop. > > I thought this feature was creating more harms than goods. > Not only because I'm getting inferior results but also I feel > the synthesis tool should deliver the exact logic which the input > RTL code specified. (Otherwise, FPGA designers can not control > how the logic is laid out.) > > Note: Synplify 7.1 has a switch to select this feature. However > this feature is always turned on by default. > > However, the response I got from Synplicity is quite different > from what I had imagined. After many e-mail exchanges, > Synplicity has notified me their conclusion: > > >>We still strongly feel that disabling the Tri-state push thru by >>default would hurt too many of our customers - who specifically >>demanded this feature. We have accommodated for those customers >>who prefer the legacy implementation by adding the switch. >> >>We have several test designs with test-benches which clearly >>show RTL / simulation mismatches with this switch disabled. >> >>Our senior management strongly believes this decision is correct >>and in-line with our policy of correct logic implementation. >> > > Unfortunately, their conclusion is completely opposite to my > understanding. I'm still not convinced that such logic mapping > is correct. > > Since Synplify is #1 in the FPGA synthesis market, a huge number > of engineers in the world are using Synplify to design FPGAs. > > I would like to ask everyone about this new feature of > Synplify 7.x. If you feel this feature is incorrect and > dangerous (or support Synplicity's arguments), please > send me an e-mail. I will present all e-mails I receive > to Synplicity (both for and against). > > Feedback / support to : synp_petition@usa.net > > I will post the update when I have something to report. > > Thank you for your attention. > Hope I can hear from many of you. > You can forward this to any other newsgroups or your friends > to get more feedbacks. > > Sincerely yours, > Aki Niimura - being a Synplify user since 1999 > > P/S I have created a Web site to list feedbacks I receive. > http://www.petition-synplify.0catch.com > Ken McElvainArticle: 40979
Hello all, I am designing a VIRTEX-II board running at up to 80 MHz. I use the 1M gates FF896 housed devices but prepared the layout for FF1152 6M gates device. There are several parallel operating data paths doing image processing. How should I prepare the 1.5V core voltage? There are operation modes which need some watts. That means, the power supply has to deliver several amperes (voltage drop over layout??). My power source could be 3.3V or 5V of the cPCI backplane. Is a linear converter OK? Is a step down converter recommended? Are there reference designs available on the net? Thank you for your support. Holger VenusArticle: 40980
There are no pin-compatible devices going from one to the other. The good news is that you are only stuck until you respin the board ;-) Greg Otto wrote: > Are there any Xilinx Spartan FPGAs that are pin compatible with Altera 10k50v-208 parts ? I designed a board initially with the 10k50v parts, but I have had so many problems with Altera, so I would like to drop a Xilinx device on the pads instead. Is there any hope, or am I stuck forever with Altera ?Article: 40981
Anybody know where I can get orcad symbols for virtex 2 parts? ChuckArticle: 40982
Yes, Xilinx has a core function that implements a DDS in their ISE 4.1 software. Salman On 19 Mar 2002 03:24:13 -0800 mister_mot@hotmail.com (Mot) wrote: > Does any of you know some sites where I can view examples of DDS > inplemented in an FPGA? > > thx mot -- Salman Sheikh NASA/GSFC Code 564 Greenbelt, MD 20771 301-286-3763 301-286-0220 (fax)Article: 40983
Kevin, Please see embedded responses to the questions you raised. Kevin Brace wrote: > <snip> > I didn't say it in so many words, but I did try open a .wlf file > which supposedly contains already simulated waveform information, but > each time I tried opening it, I also got licensing errors. > Do you know if this feature is disabled only in ModelSim XE-Starter, or > is it disabled in ModelSim XE which is a paid version? I don't know. > <snip description of other licensing stuff> > Your design environment sounds to me that you have access to a > full version at work (Modelsim SE 5.5a), but not at home or for personal > use, so you know something about the limitations of ModelSim XE-Starter. That's correct. > > Is that because of those license lock thing (flexlm) ModelSim uses? (I > guess that is pretty obvious.) > You answered your own question. > Yes, I do understand that the method I used was not a very good > one (Wasn't this method called a golden vector method or something like > that? I believe I read that in Writing Testbenches by Janick Bergeron > some time ago.). > I am still in the process of implementing various features, so I am not > ready to spend serious amount of time in verification at this point, but > I still wanted to do some simple debugging, so that my design works, at > least partially. > After I finish the implementation, I am going to spend much more time in > verification. I don't really want to turn this into a big thread on the pros and cons of waveform comparison as a verification technique so I think I will drop this right here. TomArticle: 40984
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> writes: > I am trying to simulate two designs and compare the waveforms. > Is there a way to do such a thing? Why not instantiate the two DUTs and compare the output cycle by cycle? You could then generate some nets which gets asserted whenever two signals are different. Design Acceleration (now part of Cadence) has a product called comparescan for this purpose. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 40985
Even dropping from 3.3V, you will need a big heat sink if you go the linear route and expect to use any substantial current in the FPGA. Use a switcher. Xilinx recomment the Elantec devices. Other sources include Linear Technology, Texas Instruments, and Maxim. There are others as well. "news.dlr.de" <Holger.Venus@dlr.de> wrote in message news:a77ide$gf$1@news.go.dlr.de... > Hello all, > I am designing a VIRTEX-II board running at up to 80 MHz. > I use the 1M gates FF896 housed devices but prepared the layout for > FF1152 6M gates device. > There are several parallel operating data paths doing image processing. > How should I prepare the 1.5V core voltage? > There are operation modes which need some watts. > That means, the power supply has to deliver several amperes > (voltage drop over layout??). > My power source could be 3.3V or 5V of the cPCI backplane. > > Is a linear converter OK? > Is a step down converter recommended? > Are there reference designs available on the net? > > Thank you for your support. > > Holger VenusArticle: 40986
Hi Rick, Unfortunately I get no data for the speedprint -min options: C:\>speedprint -s 5 -t 70 -v 1.5 -min xc2v6000 >xmin.txt WARNING:PpeedCalc:103 - Speed data not available, we cannot proceed C:\> Do you have any clue for me how to proceed ? ThankX , Nahum. Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3C945CB6.AA6364F0@algor.co.uk>... > Nahum Barnea wrote: > > > Hi Rick. > > ThankX for your answer. > > Can you please elaborate on the 'SPEEDPRINT' utility ? > > Is it a part of the xilinx package ? > > > > ThenkX again. > > Nahum. > > > > > > Its certainly part of the full, paid for, ISE package. I don't know about WebPACK. > > Its documented in the Development System Reference Guide.Article: 40987
Rick, I am very sorry. The demo I first downloaded two years ago allowed me to fiddle with drivers that were in their library, and with trace lengths, and my own circuits. I could not change their libraries, and I could not print the results, or add new IBIS files to the tool, or save the results. It did allow me to enter my own topology, and model it (if the library had the parts I needed already -- which it had a lot of). Sounds like they may have changed it? Any one else able to make the demo do something useful? I won't recommend the demo, but I still recommend the tool itself. Austin rickman wrote: > I tried downloading the Hyperlynx demo and found that it won't let you > do anything at all useful. I can enter my own data, but I can't > simulate it. I can simulate and example file, but I can't change > anything to try to fix problems, or it won't simulate again. This would > appear to be a very useless demo. It is not demoing anything except the > installation, which did go very smoothly. > > Isn't this the tool that you said we could do simple things with? I > thought the main limitation was that data could not be saved or > printed? > > Austin Lesea wrote: > > > > Rick, > > > > Use the fast/strong IBIS corner, and that covers the worst case for > > process/voltage/temperature. > > > > The capactances don't matter all that much (convince yourself by changing them, > > and you will see that the results don't change much at all). > > > > The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix > > SI, and they are right. The sims are not that fussy, and all you need to be sure > > of are the parts and their models, and the PCB impedance and the lengths. > > > > Input models are not fussy either, hence my use of VII for all inputs is probably > > +/- 10% of the real measured result. All CMOS inputs look pretty much the same. > > > > If you have wide buses, then crosstalk is important, and you need a little more > > detail for the geometry. > > > > Austin > > > > rickman wrote: > > > > > Thanks for your comments John. > > > > > > I guess I am a little green with clocks above 50 MHz. I was expecting > > > runs this short to be pretty simple and not to have to do too much to > > > make it work. But with the input from Austin and yourself as well as > > > some others, I do at least plan to take a first pass at a simulation. > > > My main concern is that you have to know a lot of details about the > > > board to run a USEFUL simulation. I have learned a lot from reading > > > some of Bob Pease's articles and I fully realize that a simulation won't > > > do me a lick of good if I don't make all the right assumptions. > > > > > > I have been working on a very tightly packed switching power supply > > > while I am doing the digital stuff and I am finding that I can make it > > > look pretty feasible if I make THESE assumptions and I can make it look > > > pretty impossible if I make THOSE assumptions. I think we won't really > > > know how well it will work until we fire it up on the final board > > > layout. I expect that we will see the same sort of thing with this > > > clock design. > > > > > > I did consider using a zero delay buffer. But this board is very tight > > > for space and I have a hard time justifying it with 1.5 inch traces. > > > But if the simulation shows a problem, of course we will do what we have > > > to. > > > > > > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. > > > This is another difference between the simulation Austin did and what I > > > have. He seems to have used all VII inputs with 10 pF capacitance. > > > > > > It is also not clear to me if the simulations are being done with > > > typical values or worst case values. If typ values are used, then I > > > don't see how the results have any meaning at all. > > > > > > Rick Collins > > > > > > John_H wrote: > > > > > > > > 85 ps per inch works for free space. A better approximation would be 170 ps > > > > per inch for internal traces where the relative permitivity of about 4 for > > > > FR4 material at high frequency gives a good approximation (sqrt(4) for > > > > scaling to free space). The outside traces are a bit faster because they're > > > > propagating through a combination of air and FR4 - I don't have the numbers > > > > handy for those speeds. > > > > > > > > You're right about the stackup being important - the trace widths and plane > > > > spacings need to be well specified by you to get the board house to provide > > > > impedances that won't over/undershoot. A little mistermination is fine - > > > > the mid-transition reversals are what kills; those can occur when the > > > > driver sees a low impedance for much of the risetime but gets the reflection > > > > coming back before the clock's out of the transition region. There's the > > > > beauty of SI - this general info gets applied. > > > > > > > > With everything close and distributed capacitance throughout, you could get > > > > smooth transitions with the star configuration, but it's dependent on the > > > > drivers and input capacitance. > > > > > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > > > delay buffers" are part of the clock management's best application. It's > > > > often better from a debug standpoint to have access to individual > > > > terminations if things go desperately wrong. > > > > > > > > rickman wrote: > > > > > > > > > Austin, thanks for the simulation. > > > > > > > > > > This looks like great data. But I am not sure if you were trying to > > > > > help by doing my simulation for me, or if you were just trying to show > > > > > what the tool can do. > > > > > > > > > > I am not clear about what this is simulating. Obviously you used the > > > > > daisy chain model, but how do you know what to use as a trace impedance > > > > > and where did the delays come from? The preliminary layout I am using > > > > > has the following delays in the daisy chain case, assuming 100pS per > > > > > inch. Is that a valid assumption? > > > > > > > > > > DSP to FPGA 100pS > > > > > FPGA to SDRAM1 50pS > > > > > SDRAM1 to SDRAM2 50pS > > > > > SDRAM2 to SBSRAM 100pS > > > > > > > > > > Don't I need to caclulate the trace impedance from the PCB design > > > > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > > > > layers with a total thickness of 0.062". Of course, I can use wider > > > > > traces for the clock and control which layer they are on. > > > > > > > > > > I would expect these four loads to behave much better than the five > > > > > loads with 200+ pS delays. > > > > > > > > > > If you were just trying to demonstate the tool, that's fine. But if you > > > > > were trying to simulate my case, these are the data that should be > > > > > used. > > > > > > > > > > When I am done my other work today, I will try downloading the software > > > > > and giving it a try this weekend or next week. > > > > > > ...snip... > > > > > > -- > > > > > > 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 > > -- > > 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: 40988
Kevin, It is true that we have a selectable delay in the global clock IOB so we can tweak the delay to guarantee 0 hold time. Lately with the DCM, this is much less important, as we have precise control of the phase, now under user control and fully supported. Austin Kevin Brace wrote: > If ordinary users are discouraged from using this Factory_JF feature in > Virtex-II, how about Virtex/Virtex-E/Spartan-II/Spartan-IIE's ability to > add some extra delay on the global clock buffer? > I believe in bitgen, the user can add extra delay on the global clock > buffer to get some extra setup time, but the problem I have is that the > feature is sort of secret, and only Xilinx knows how to use it. > The default value of that feature in bitgen I believe is 11111 (probably > a binary value). > My guess is that the value 11111 puts the least amount of global clock > buffer delay, and the value 00000 puts the greatest amount of global > clock buffer delay. > Beyond that, I have no idea how the thing works, but putting too much > delay on the global clock buffer will affect Tco, so my guess is that > typically people who use it pick a value somewhere in between that. > Or looking at it differently, changing one of the bit to 0 (like > changing 11111 to 11011) puts certain amount of delay, and more the bits > that are zero (like 10011 or 10001), more the delay on the global clock > buffer. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 40989
Think of a FIFO as a shock absorber, or a rubber band. It allows you to average out the data rates on input an output. That's all. Peter Alfke ==================== Antonio wrote: > I can't understand how a FIFO could work well if it is writed with an > high data rate and it's read with a low data rate, from my point of > view, reallt soon it became full and all the data that continue to be > writed into the FIFO will put away the first data, where's my > conceptual error ?? > > AntonioArticle: 40990
ASIC/SOC 2002 CALL FOR CORPORATE PARTICIPATION AND PAPERS
The annual IEEE 2002 ASIC/SOC Conference is preparing for its 15th confer-
ence in Rochester New York from September 25th through the 28th, and while
last year's conference on September 12th had to be canceled, this year's
conference will be better than ever.
The ASIC/SOC Conference, sponsored by the Institute of Electrical and
Electronics Engineers, covers all aspects of Application Specific Inte-
grated Circuits and Systems on a Chip, and attracts over 200 ASIC/SOC
engineers, researchers, and educators from around the world.
ASIC/SOC offers industry a place to learn about the most current ASIC/SOC
developments and hear leaders in the field, such as Wilf Corrigan the
founder and CEO of LSI Logic, and Hirokazu Hashimoto the President and CEO
of NEC Electronics, address current issues facing the industry.
While ASIC/SOC is an excellent place for engineers to learn about the most
recent engineering developments, it is also an ideal place for companies
to reach a very focused audience about advances in CAD and EDA tools, ASIC
components/boards, equipment, and career opportunities.
Again this year, ASIC/SOC will accept a limited number of Corporate Spon-
sors for coffee breaks, cocktail parties, and our banquet. Sponsors will
appear in the ASIC/SOC published program, appear on the ASIC/SOC web page,
and have the opportunity to exhibit and display posters and distribute
brochures for the entire conference.
If your company is interested in exhibiting at ASIC/SOC 2002 please con-
tact me at the address below or the ASIC/SOC Conference office at
301-527-0900 x104, but either way, please distribute the attached Call for
Papers to your employees world-wide and visit the ASIC/SOC 2002 web page
at http://asic.union.edu.
Sincerely
Dr. Richard Auletta
Publications/Publicity Chair ASIC/SOC 2002
rauletta@orci.com
(303) 530-3640
***********************************************************************
* CALL FOR PAPERS *
* DEADLINE FOR PAPER SUBMISSION: APRIL 12, 2002 *
* *
* 15th Annual IEEE International ASIC/SOC Conference *
* September 25-28, 2002 *
* RIT Inn and Conference Center, Rochester, New York *
***********************************************************************
Driven by the rapid growth of the Internet, communication
technologies, pervasive computing, and wireless and portable consumer
electronics, Systems-on-Chip (SoC) have become a dominant issue in
today's ASIC industry. The transition from traditional Application-
Specific-Integrated-Circuits (ASIC) to SoCs has created new
challenges in Design Methods, Design Tools, Design Automation,
Manufacturing, Technology and Test. The ASIC/SoC Conference provides
a forum for sharing advances in ASIC and SoC technology and
applications. The 2002 Conference will offer three days of technical
papers and a full day of technical workshops. The IEEE Circuits and
Systems Society sponsors the ASIC/SoC Conference.
GENERAL INFORMATION
This year's ASIC/SOC Conference will be held at the Rochester Institute of
Technology Inn and Conference Center. Rochester New York is served by the
Greater Rochester International Airport and is within easy driving distance
of the Buffalo International Airport and most of New England.
Accommodations will be available for $79.00 a night at the RIT Inn.
Rochester, the third largest urban area in New York State, offers a wide
range of cultural, historic, and recreational activities within the relaxed
atmosphere of upstate New York.
TECHNICAL SCOPE
Papers are invited which address new and previously unpublished results in
the following categories or in related areas. Proposals for tutorial
papers, tutorials, workshops, and panel sessions are also invited. The
best paper will be acknowledged with a best paper award.
Applications SoC Specific Design Methodologies
------------------------------------------------------------------------
A1 Communication, Networking, S1 Reusable & Embedded
Internet, e-Business Cores/Macros, Memories
A2 Signal/Image Processing, S2 Technology Independent
Multimedia Methodologies
A3 Portable & Wireless Systems S3 On-Chip Buses for SoC
A4 Wireless/Pervasive Computing S4 Smart Sensors Integration
A5 Consumer and Defense S5 Design of Reconfigurable SoCs
Electronics
A6 FPGAs and Reconfigurable SoCs S6 SoC/IP Validation
A7 Other SoC Applications
Common Design Methodologies Enabling Technologies for SoC
------------------------------------------------------------------------
D1 High Performance, Low Power T1 Embedded DRAMs/Flash Memories
Design
D2 Analog & Mixed-Signal Design T2 Sensors/MEMS
D3 HW/SW Co-Design T3 Deep Sub-micron Technologies
D4 Timing Methodologies, Sync/Async T4 Optical Interconnects
Design, Clocking
D5 Reconfigurable/Scalable Design
Manufacturing Common SoC Issues
------------------------------------------------------------------------
M1 Signal Integrity & EMI C1 Project Management, Distributed
Development Teams
M2 Packaging & I/O Interfacing C2 Intellectual Property, Patent
and Legal Issues
M3 SoC Testing, Power Measurement, C3 SoC Success Stories, Case
Burn-In Studies
M4 SoC Fabrication Technologies C4 Future SoC Trends and Limits
C5 SoC Overview and Tutorial Papers
PAPER SUBMISSION
Electronic paper submission requires a 25 word condensed abstract for the
Advance Program, and the full paper, limited to five double-column IEEE
format pages, including figures and references. Please refer to the
conference web page at http://asic.union.edu for paper formatting and paper
submission as an Adobe PDF file.
ORGANIZING COMMITTEE
General Chair Technical Chair Technical Co-Chair
P. R. Mukund John Chickanosky Dong Ha
RIT IBM Virginia Tech
prmeee@rit.edu chickano@us.ibm.com ha@vt.edu
Pubs/Publicity Chair Steering Committee Chair Workshop Chair
Richard Auletta Thomas Buchner Ram Krishnamurthy
LSI Logic IBM Boblingen Lab Intel Corporation
rauletta@acm.org tbuechner@de.ibm.com ramk@hf.intel.com
DEADLINE FOR PAPER SUBMISSION: APRIL 12, 2002
NOTIFICATION OF PAPER ACCEPTANCE: MAY 31, 2002
FINAL CAMERA-READY PAPERS DUE: JUNE 28, 2002
Please visit the Conference web site at http://asic.union.edu or contact
the ASIC/SoC Conference office at 301-527-0900 x104 for paper submission,
registration, and current conference information.
Sponsored by the IEEE Circuits and Systems Society
************************************************************************
Article: 40991I had to make the same decision 5 days ago and will use the MICREL part: MIC35101-1.5BR It's a LDO regulator that delivers 1.5V @ 5 Amp. Maybe it will also work for you. -ManfredArticle: 40992
What package do you need ? I could provide the Orcad symbol for FG465. -Manfred KrausArticle: 40993
> I am designing a general I/O board with a Virtex II (xcv2V3000 to 8000) and > some memory. I have about 100 spare pins. I have read on the newsgroups > sometime ago that it was good to connect them to ground an to assign a value > to each of them. > Did anybody went through this problem yet ? Leave them open and unconfigured. You may also drive them as outputs with constant levels if you think that would be better. Using them as "auxiliary GND" pins like it was recommended for the good old XC73000 CPLD is not required. > Also, an external clock will be connected directly to the FPGA. The range is > 0-200 MHz. I assume it requires a input filter between the connector and the > FPGA. I thought about a low pass filter with a cut frequency of 200 MHz. > Does it sound good ? Dont use a filter with clock signals, you might not get valid high and low levels any more. The edge of your clock signal will also not be sharp any more. Your clock signal will look like a sine curve. If you use the correct impedance for the termination and the PCB routes everything will be fine. Of course you need connectors that are good for 200MHz. One more thing: if your input clock is garbage, there will be no easy solution to restore it. -Manfred KrausArticle: 40994
Manfred, All good recommendations. I wish to reinforce the comment about sharp transistions on clocks: a sine wave clock is easily influenced by adjacent switching noise, and can lead to excessive jitter. Cross coupling from adjacent pcb traces will cause cross talk induced delay variations (jitter), and any ground bounce from SSOs will also cause jitter. Good signal integrity, using matched IOs to trace impedances, and excellent bypassing are all required. Remember that the period constraint must be reduced by 1/2 of the total peak to peak jitter if you expect to meet your timing. Now that we routinely have clocks of 100 to 300 MHz, the usually ignored jitter is now a significant factor. Austin Manfred Kraus wrote: > > I am designing a general I/O board with a Virtex II (xcv2V3000 to 8000) > and > > some memory. I have about 100 spare pins. I have read on the newsgroups > > sometime ago that it was good to connect them to ground an to assign a > value > > to each of them. > > Did anybody went through this problem yet ? > > Leave them open and unconfigured. > You may also drive them as outputs with constant levels > if you think that would be better. > Using them as "auxiliary GND" pins like it was > recommended for the good old XC73000 CPLD > is not required. > > > Also, an external clock will be connected directly to the FPGA. The range > is > > 0-200 MHz. I assume it requires a input filter between the connector and > the > > FPGA. I thought about a low pass filter with a cut frequency of 200 MHz. > > Does it sound good ? > > Dont use a filter with clock signals, you might not get valid high and low > levels > any more. The edge of your clock signal will also not be sharp any more. > Your clock signal will look like a sine curve. > If you use the correct impedance for > the termination and the PCB routes everything will be fine. > Of course you need connectors that are good for 200MHz. > One more thing: if your input clock is garbage, there will be no easy > solution > to restore it. > > -Manfred KrausArticle: 40995
With my Serial cable (and I think also with my parallel one) I got not only flying leads but also a one-to-one cable. Maybe Xilinx is saving money and doesn't include it any more ? If your board has the corresponding connector (Pin 1 ..6 with pin 3 removed) you can only plug it correctly. -Manfred Kraus William Lenihan <lenihan3we@earthlink.net> schrieb in im Newsbeitrag: 3C96F689.EE3E9DF7@earthlink.net... > > Subject: Parallel Cable III/IV > > These JTAG pods have attachments called "flying leads", where end > #1 is a fixed connector to plug into the pod (i.e., JTAG row of pins) > and > end #2 is the actual flying leads to connect to the target hardware. > > That's great for prototype & engineering development, but for > production, the actual > flying leads @ end #2 can easily be mis-placed by technicians on the > assembly > line. > > Is there any readily available, fixed-connection cables (and mating > sockets) for the Xilinx-programming-pod-2-target-hardware connection? > Or is that some tooling that every customer just has to make on their > own > w/ catalog parts from Newark, Digi-Key, etc., ? > > > > -- > ============================== > William Lenihan > lenihan3we@earthlink.net > ============================== > >Article: 40996
I personally like the LT1764 series part from linear technology. Theron Hicks Manfred Kraus wrote: > I had to make the same decision 5 days ago and will use the > MICREL part: MIC35101-1.5BR > It's a LDO regulator that delivers 1.5V @ 5 Amp. > Maybe it will also work for you. > > -ManfredArticle: 40997
Hi! >> Snag number 1 - Xilinx Webpack does not appear to support the XC4010E >> that is on my Xess board. any helpful advice? > > You could buy the Xilinx Student Edition 2.1i for $55.00. It supports > the XC4000E and XC4000XL series. I am playing with this thought too. Where can I buy this Student Edition here at Austria? Bye HansiArticle: 40998
The conceptual error is that you stop writting to the fifo when it goes full (or almost full). You never allow a write to a full fifo (or a read from an empty fifo for that matter). So in your example, the hi speed device will burst data to the fifo until fifo full, and then go away until the fifo needs more data (usually a fifo almost empty flag, or a 1/2 full flag or something like that). Dan > Antonio wrote: > > > I can't understand how a FIFO could work well if it is writed with an > > high data rate and it's read with a low data rate, from my point of > > view, reallt soon it became full and all the data that continue to be > > writed into the FIFO will put away the first data, where's my > > conceptual error ?? > > > > Antonio >Article: 40999
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag news:fb35ea96.0203190148.770f2b6@posting.google.com... > I can't understand how a FIFO could work well if it is writed with an > high data rate and it's read with a low data rate, from my point of > view, reallt soon it became full and all the data that continue to be > writed into the FIFO will put away the first data, where's my > conceptual error ?? As the other already noted, the FIFO allows a PEAK-data rate adaption, but the AVERAGE data rate must be the same. Imagine you write to the FIFO with 100 MHz 100 words (could by n bit wide) every 1 milisecond. This means you have a PEAK-data raste of 100 MWords/second, but an AVERAGE of only 100kWords/s. SO this means your average read frequency must be a t least 100 kHz (continous reading). But you could also read again in burst at a much higher frequency. A very common example is the FIFO in you RS232 UART in the PC. When running at 115.2kbit/s WITHOUT a FIFO, this means 11520 bytes/s. The processor would be interrupted 11520 times/s to read the received data and evaluate it. Most for the time is wasted with inerrupt handling, the read acces to the UART would only be 1 instruction. With the FIFO, the CPU can wait til 14 or 16 bytes are recieved and the read them in a burst. So the interrupt rate is lowered by the factor 14 or 16. -- MfG Falk
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