Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 40400

Article: 40400
Subject: Re: FPGA problems
From: paul.lee@sli-institute.ac.uk (Paul)
Date: 6 Mar 2002 08:48:44 -0800
Links: << >>  << T >>  << A >>
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 Lee

Article: 40401
Subject: Re: V-II DCM options
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 06 Mar 2002 16:57:07 +0000
Links: << >>  << T >>  << A >>
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/conekt

Article: 40402
Subject: ICCAD 2002 Call for Papers
From: ICCAD Conference <info1@iccad.com>
Date: Wed, 06 Mar 2002 09:07:42 -0800
Links: << >>  << T >>  << A >>

--------------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: 40403
Subject: max frequency of obuf_lvdci_dv2_18
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 6 Mar 2002 09:24:35 -0800
Links: << >>  << T >>  << A >>
Hi.
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
Subject: Using a battery instead of Config device
From: chrisjc31415@yahoo.co.uk (Chris Cowdery)
Date: 6 Mar 2002 09:28:14 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: share two months salary with you if you have job information
From: <istjohn@spamcop.net>
Date: Wed, 06 Mar 2002 18:14:47 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: exceeding 2GB limits in xilinx
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 06 Mar 2002 18:18:47 +0000
Links: << >>  << T >>  << A >>


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
Subject: Re: FPGA wich supports LVDS
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 06 Mar 2002 11:02:09 -0800
Links: << >>  << T >>  << A >>
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
>
> martin


Article: 40408
Subject: Re: QPRO Virtex
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 06 Mar 2002 11:07:02 -0800
Links: << >>  << T >>  << A >>


"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 Applications



Article: 40409
Subject: Re: FPGA or DSP in a power supply?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 06 Mar 2002 11:18:43 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: exceeding 2GB limits in xilinx
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Wed, 6 Mar 2002 19:32:49 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.edu

Article: 40411
Subject: Mutual Clock Synchronization
From: Greg Neff <gregeneff@yahoo.com>
Date: Wed, 06 Mar 2002 14:44:15 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 40412
Subject: Re: FPGA which supports LVDS
From: Tom Burgess <tom.burgess@nrc.ca>
Date: Wed, 06 Mar 2002 12:42:06 -0800
Links: << >>  << T >>  << A >>
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 6K3

Article: 40413
Subject: Re: FPGA or DSP in a power supply?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 07 Mar 2002 09:54:59 +1300
Links: << >>  << T >>  << A >>
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 :-)

-jg

Article: 40414
Subject: Re: Mutual Clock Synchronization
From: John_H <johnhandwork@mail.com>
Date: Wed, 06 Mar 2002 21:08:39 GMT
Links: << >>  << T >>  << A >>
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.com


Article: 40415
Subject: Re: QPRO Virtex
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Wed, 06 Mar 2002 15:15:05 -0600
Links: << >>  << T >>  << A >>
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
Subject: Virtex-II : Temperature Sensing Diodes
From: Cindy <cindicater@hotmail.com>
Date: Wed, 6 Mar 2002 13:33:32 -0800
Links: << >>  << T >>  << A >>
Is there is absolute maximum voltage specified for the DXP and DXN pins?

Thanks!

Article: 40417
Subject: Re: How to create testbench (Verilog) easily ? Any tools ?
From: vhdlcohen@aol.com (VhdlCohen)
Date: 06 Mar 2002 21:47:12 GMT
Links: << >>  << T >>  << A >>
>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
Subject: Re: Fast transmission
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 06 Mar 2002 14:12:28 -0800
Links: << >>  << T >>  << A >>
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-8700718


Article: 40419
Subject: Re: MXE 5.5e speed
From: Cindy <cindy.kao@xilinx.com>
Date: Wed, 6 Mar 2002 14:57:37 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Mutual Clock Synchronization
From: Greg Neff <gregeneff@yahoo.com>
Date: Wed, 06 Mar 2002 18:19:46 -0500
Links: << >>  << T >>  << A >>
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.com

Article: 40421
Subject: Re: Mutual Clock Synchronization
From: John_H <johnhandwork@mail.com>
Date: Wed, 06 Mar 2002 23:50:32 GMT
Links: << >>  << T >>  << A >>
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.com


Article: 40422
Subject: Re: Quartus II 2.0 fast fit option
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Thu, 07 Mar 2002 00:48:48 GMT
Links: << >>  << T >>  << A >>


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
Subject: Announcement: Freely Available Rijndael Core for Virtex FPGAs.
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 7 Mar 2002 02:11:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.edu

Article: 40424
Subject: Re: Rising and falling edge of a clk
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Mar 2002 02:23:23 GMT
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search