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 40975

Article: 40975
Subject: STARTUP_VIRTEX primitive
From: "H.L" <alphaboran@yahoo.com>
Date: Tue, 19 Mar 2002 15:19:41 +0200
Links: << >>  << T >>  << A >>
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: 40976
Subject: Re: DDS in an FPGA
From: Ray Andraka <ray@andraka.com>
Date: Tue, 19 Mar 2002 13:53:15 GMT
Links: << >>  << T >>  << A >>
There 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 mot


Article: 40977
Subject: Signal driven by a "configuration done" event
From: guiducci@cern.ch (Luigi)
Date: 19 Mar 2002 05:54:16 -0800
Links: << >>  << T >>  << A >>
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

Luigi

Article: 40978
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: Ken McElvain <ken@synplicity.com>
Date: Tue, 19 Mar 2002 14:33:30 GMT
Links: << >>  << T >>  << A >>


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 McElvain




Article: 40979
Subject: 1,5V power supply?
From: "news.dlr.de" <Holger.Venus@dlr.de>
Date: Tue, 19 Mar 2002 15:41:30 +0100
Links: << >>  << T >>  << A >>
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 Venus




Article: 40980
Subject: Re: Xilinx : Altera pin compatibility
From: Ray Andraka <ray@andraka.com>
Date: Tue, 19 Mar 2002 14:47:10 GMT
Links: << >>  << T >>  << A >>
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
Subject: virtex 2 orcad symbols?
From: "Chuck" <chuck@sigtek.com>
Date: Tue, 19 Mar 2002 10:05:08 -0500
Links: << >>  << T >>  << A >>
Anybody know where I can get orcad symbols for virtex 2 parts?

Chuck



Article: 40982
Subject: Re: DDS in an FPGA
From: Salman Sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Tue, 19 Mar 2002 10:06:52 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: How do I simulate two separate designs simutaneously in ModelSim XE?
From: Tom Loftus <hdlman@hotmail.com>
Date: Tue, 19 Mar 2002 10:08:49 -0500
Links: << >>  << T >>  << A >>
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.

Tom


Article: 40984
Subject: Re: How do I simulate two separate designs simutaneously in ModelSim XE?
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 19 Mar 2002 16:12:37 +0100
Links: << >>  << T >>  << A >>
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.com

Article: 40985
Subject: Re: 1,5V power supply?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Tue, 19 Mar 2002 15:21:14 -0000
Links: << >>  << T >>  << A >>
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 Venus




Article: 40986
Subject: Re: minimum value for clock to output
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 19 Mar 2002 07:25:21 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: High speed clock routing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 19 Mar 2002 08:19:06 -0800
Links: << >>  << T >>  << A >>
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 FAX


Article: 40988
Subject: Re: [Virtex 2] DCM: "Factory_JF" option box in FPGA editor question
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 19 Mar 2002 08:21:59 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: FIFO general question
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 19 Mar 2002 16:32:25 GMT
Links: << >>  << T >>  << A >>
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 ??
>
> Antonio


Article: 40990
Subject: ASIC/SOC 2002 CALL FOR CORPORATE PARTICIPATION AND PAPERS
From: rauletta@orci.com (Richard Auletta)
Date: 19 Mar 2002 08:40:54 -0800
Links: << >>  << T >>  << A >>
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: 40991
Subject: Re: 1,5V power supply?
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 19 Mar 2002 17:46:41 +0100
Links: << >>  << T >>  << A >>
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.

-Manfred



Article: 40992
Subject: Re: virtex 2 orcad symbols?
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 19 Mar 2002 17:47:47 +0100
Links: << >>  << T >>  << A >>
What package do you need ?
I could provide the Orcad symbol for FG465.

-Manfred Kraus



Article: 40993
Subject: Re: Unused I/Os + External Clock on Virtex II
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 19 Mar 2002 18:03:33 +0100
Links: << >>  << T >>  << A >>
> 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 Kraus



Article: 40994
Subject: Re: Unused I/Os + External Clock on Virtex II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 19 Mar 2002 09:11:58 -0800
Links: << >>  << T >>  << A >>
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 Kraus


Article: 40995
Subject: Re: Xilinx JTAG Cables
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Tue, 19 Mar 2002 18:12:52 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: 1,5V power supply?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Tue, 19 Mar 2002 12:25:11 -0500
Links: << >>  << T >>  << A >>
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.
>
> -Manfred


Article: 40997
Subject: Re: Webpack + XC4000
From: Johann Glaser <Johann.Glaser@gmx.at>
Date: Tue, 19 Mar 2002 18:39:22 +0100
Links: << >>  << T >>  << A >>
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
  Hansi

Article: 40998
Subject: Re: FIFO general question
From: "Dan Kuechle" <danielgk@voomtech.com>
Date: Tue, 19 Mar 2002 11:55:20 -0600
Links: << >>  << T >>  << A >>
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
Subject: Re: FIFO general question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 19 Mar 2002 18:58:59 +0100
Links: << >>  << T >>  << A >>
"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:
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