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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 26125

Article: 26125
Subject: Re: Xilinx Licensing.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 05 Oct 2000 00:12:53 +0100
Links: << >>  << T >>  << A >>


Not forgetting of course the Elite Edition. Don't know what they'll call the version needed for the next
range of huge parts - Annointed ? Maybe, following Douglas Adams,

``The Edition that is to come after me whose very command line flags I am unworthy
  to enumerate''



Article: 26126
Subject: Re: Whoa, Noise on a digital output pin?, and Minor rant on XC9500 S/W, was Re: Simon,Floating Inputs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 05 Oct 2000 13:03:40 +1300
Links: << >>  << T >>  << A >>
Jens Konig wrote:
> 
> Hey, I know those spikes on signals simply routed 1to 1 through XC9572. They're coming from (that's what I think) crosstalk on the chip from other signals. This is fact since Xilinx changed from ASJ9745 to AEM9917 (new Mask+Manuf). Seems like having many bad sideeffects also.

 Can you clarify this some more ?
Is it just visible, or causing actual downstream disturbance ?

 It is not uncommon for LOGIC devices to have light Voh pullups, and
thus 
visible cross talk/ Vcc common mode noise effect 'grass' on the HI
levels, 
but they should be well clear of the LOGIC thresholds.
 The edges, and Vol levels should be much cleaner.

-jg

Article: 26127
Subject: Re: Boundary Scan and LVDS in Virtex E
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 05 Oct 2000 10:01:53 +0900
Links: << >>  << T >>  << A >>
Hi, Gabriel,

> The question is for Boundary Scan Test. Each pin of an LVDS Signal
> is connected to an independant BS cell. So It seems like it will be
> a problem to read or drive an LVDS Signals in Boundary Scan mode
> since the datasheet says that "Boundary-scan operation is
> independent of individual IOB configurations". Note that we aim at
> develloping extended test and that the FPGA will be connected to a
> LVDS to LVTTL buffer which is not JTAG compliant.
>  So Is it possible to perform a Boundary Scan Test with LVDS Signals
> ?  And if yes how ?

As I understand it, it *is* possible . . . you simply set your pair of
output pins such that one of the is logic '1', and the other one is
logic '0'.  And then you invert them both.  This gives you two
differential logic levels.

If I'm not mistaken, LVDS is 2.5v logic; I beleive that during the
JTAG test the LVDS outputs will be the same as the Vccio pins for that
I/O bank, so you should be safe there, too.

Warning: You are going to run into a problem if your LVDS signals are
AC-coupled.  JTAG is inherently slow; I find that our JTAG clock is
between 1 MHz and 5MHz maximum.  Consider that you have to shift in
data for each pin of the FPGA every time you change the JTAG output
pins, then you can only toggle the output pins at a frequency less
than (1~5MHz / Pin Count).  I'm guessing 15 KHz maximum.

Hope this helps.  -Kent

Article: 26128
Subject: Re: DLL unlocking
From: "S. Ramirez" <sramirez@deleet.cfl.rr.com>
Date: Thu, 05 Oct 2000 01:04:24 GMT
Links: << >>  << T >>  << A >>
Allan,
     It sounds as if you are operating at the limits of the speed-power
curve on the device.
     Concerning the DLL losing lock but the LOCKED output not being
deasserted, I remember a while back when I started using Virtex parts and
DLLs that a Xilinx person (perdaughter? :) ) told me that the LOCKED output
was only deasserted when the RESET input was asserted.  I didn't use LOCKED
and I didn't have the problem that you're having or similar problems, so I
never investigated this further.  But I couldn't help but wonder why the
LOCKED signal couldn't represent the true status of the DLL.  Maybe they
have changed this function, maybe not, but you might want to ask your
favorite Xilinx person if you have to assert the RESET input to deassert the
LOCKED signal.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


> Has anyone else seen this phenomenon, or have some idea as to the cause?
> I can understand that the DLL might lose lock due to noise, but why
> wouldn't the locked output be deasserted?
>
> Thanks,
> Allan.
>



Article: 26129
Subject: Re: Xilinx Licensing.
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 05 Oct 2000 10:16:31 +0900
Links: << >>  << T >>  << A >>
I guess it's safe to say then that nobody can help explain hings to me?

That's an excellent idea to have a Product selection Matrix.  For each 
device, include Packages, Max IO's, Compatable ROMs (see below), and 
software license features.  But if we end up with an "annointed" version,
you do now that it' sonly a matter of time until you can get the "annointed
professional" version.  when "Annointed Pro" comes out, they're preoaobly 
re-release "Annointed" as "Annointed Student Edition".  (Would that be 
"Accolade Edition"?)

Isn't this Time Based License scheme still shiny new?  And they're 
discarding it already?

On a related note (in that it's something else from Xilinx that I don't 
understand), can anyone guide me as to PROMs?

The XCV-150 and the XC2S-150 are bitstream-compatable, right?
Does this imply that they can use the same PROMs?

This is the information that I have from the xilinx website.  Note the conflicts.

Document #    Device     Required Size    Suggested PROM     PROM Size
ds030.pdf     XC2S150    1'040'128        XC17S150XL         ?
ds073.pdf     XCV150     1'040'096        XC17V01            1'679'360
ds027.pdf     XCV150     1'041'128        XC1701L            1'048'576
fpga5b.htm    XCV150     1'038'944        XC1701L

Does anyone know the size of the Spartan-II ROM listed above, and whether or not 
I can use it with the Virtex?

Thanks.

-Kent

Article: 26130
Subject: Re: Category : virtex e I/O bank contention
From: nishioka@my-deja.com
Date: Thu, 05 Oct 2000 01:17:43 GMT
Links: << >>  << T >>  << A >>
Xilinx 3.1i service pack 3 mentions a problem where the clamp diodes are
enabled for LVCMOS2 and LVDS when they should not be.
http://support.xilinx.com/techdocs/9922.htm

This might be your problem.

Alan Nishioka
alann@accom.com


In article <ee6e2e2.-1@WebX.sUN8CHnE>,
  "Pauric Hennessy" <pauric.hennessy@ashling.com> wrote:
> I'm currently using a virtex e device  with  bank 2 VCCO= 3.3V and all
other banks connected to 2.5V.
> I've got LVDS receivers powered off 3.3V connected to banks 4 and 5.
3.3V levels are thus supplied on  these banks.
> After configuration I see that the 3.3V rail is supplying  a portion
of the power to the 2.5V rail throuht some unknown path.Currently I'm
powering the 3.3V rail and 2.5V rail off a current limited bench supply.
Eventually the current drawn from the 2.5v bench supply reaches 0mA and
can be removed from the equation- 2.5V being maintained by the 3.3V
supply through some unknown path.
> With my LVDS bank disabled and all outputs <0.8V then the 2.5V rail is
ok. However enabling the 32 outputs of the LVDS sets them to 3.3V and
this gets passed on to the LVCMOS2 i/ps on the FPGA. In this scenario
the 2.5V rail rises to 2.8V.
> The FPGA's are still functioning and performing as designed- but I
need to know what is going on here-  are my devices damaged? Are there
clamp diodes on LVCMOS2 i/ps that allow 3.3V to migrate onto the 2.5V
rail!!
> Has anyone else haqd a similar experience.
> rgds
> Pauric
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26131
Subject: Re: Category : virtex e I/O bank contention
From: nishioka@my-deja.com
Date: Thu, 05 Oct 2000 01:34:24 GMT
Links: << >>  << T >>  << A >>
Upon further investigation, it looks like this bug/fix applies only to
virtex and not to virtex-E.

Alan Nishioka


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26132
Subject: 3DES VHDL
From: Michael Fluet <mfluet@wpi.edu>
Date: Wed, 04 Oct 2000 23:09:36 -0400
Links: << >>  << T >>  << A >>
I am doing a project using hardware encryption and am looking for 3DES
VHDL open source.  If anyone knows where this is available, please
advise.  Thank you.

Michael Fluet
mfluet@wpi.edu

Article: 26133
Subject: Re: Simon , decoupling caps
From: "Martin.J Thompson" <Martin.J.Thompson@trw.com>
Date: Thu, 05 Oct 2000 07:35:45 +0100
Links: << >>  << T >>  << A >>
Hi Austin,
>
>The subject of bypass gets re-hashed on a fairly regular basis.  This article is useful as it is accurate as far as it goes.
>

Indeed it does!  For those who haven't found it and are interested in these areas, I find the signal integrity reflector talked about earlier in this thread very helpful.

>In an FPGA, where we don't have a clue what you, the customer, are going to do, bypassing takes on a much more difficult task.
>

Yep!

>One approach is to concern yourself with the determination of how much current is required at each possible frequency, and the resulting bypass reactance vs. 
>frequency, and then design a series of capacitance networks (capacitors of differring values and types) to cover the reactance vs frequency desired.
>i.e. less than 2 ohms from 0 to 1 GHz.  You are still guessing at the peak current with this method, as you note in your comments.
>
>The "switched capacitance approach" used by me and others is another solution.  For example, if the amount of capacitance switched by the IO's is X pF, then if I 
>want less than 4% dV/dt (~150mV noise), I need to have 25 times X pF to bypass that one IO.  Still a guess as to the peak currents, but perhaps an
>overly conservative guess.
>

Interesting, I haad pondered using this approach also.  Do the results not end up the same though as they are both estimating a worst case peak current?

>Now IO's don't actually switch capacitance (the loads may be inductive, resistive, or capacitive due to the transmission line and its length on the PCB).  As such, 
>the switched C approach is an estimate of a worst case.  Add up the residual C of the points driven, not including the t-lines (t-lines are NOT
>capacitors at the edge rate, nor the data rates).  T-lines transform the impedance at one end to the other end.  A capacitive load may look inductive if the length is 
>1/4 wave for the frequency dominant in the edge.
>
>This may still be a 10X over estimate, as package C includes the t-line of the package (again not a capacitor).  Driving a bank of parallel connected IC's (RAM's) 
>does look like a big C.
>

Agreed!

<Core bypassing>
>Often forgotten is that the die has capacitance itself in the structures (self-bypassed) for both the core and the IO's.  So does the multi-layer laminate packaging.  
>That is why a 0.1uF cap still works after all these years.  The local capacitance is small, but highly effective at the edge rates of the logic
>or IO.  It is the 'refilling' of this internal capacitance that the external capacitors must accomplish.
>

This was somethig I was going to bring up. Is there any way that we can get useful information on this to aid our calculations?

<snip - but agreed!>


>Simultaneous switching outputs are to be floor-planned because if all of the outputs of a bank all go from a 1 to a 0 on a a clock edge, you will most definitely 
>collapse the on-chip Vcco!  See the SSO guidelines which define the most outputs allowed in the best bypassing case.
>

Unfortuanatly I am in Altera land, and I haven;t seen any app notes yet from them.  If only they could be persuaded to contribute in this forum!  I am getting increasingly fristrated with the lack of support I feel from Altera at times!

>In our appnote 158 (re-write due to be released perhaps this week), we make a point of recommending a number of large capacitors precisely because we don't 
>know what the frequency distribution is, and you probably are not sure either.
>

If you do know the frequency distribution - as I do to a large extent in my application - there are even more sums to be done!  Or I can play safe and whack a number of large caps down :-)

Martin



TRW Automotive Advanced Product Development,         
Stratford Road, Solihull, B90 4GW. UK
Tel: +44 (0)121-627-3569 
mailto:martin.j.thompson@trw.com




 Sent via Deja.com http://www.deja.com/
 Before you buy.

Article: 26134
Subject: Re: 3DES VHDL
From: "Mike Johnson" <mikej@freeuk.com>
Date: Thu, 5 Oct 2000 09:22:05 +0100
Links: << >>  << T >>  << A >>
des core at www.free-ip.com

Mike Johnson
Michael Fluet <mfluet@wpi.edu> wrote in message
news:39DBF0F0.DC4D32F3@wpi.edu...
> I am doing a project using hardware encryption and am looking for 3DES
> VHDL open source.  If anyone knows where this is available, please
> advise.  Thank you.
>
> Michael Fluet
> mfluet@wpi.edu



Article: 26135
Subject: Re: 3DES VHDL
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 05 Oct 2000 10:12:28 GMT
Links: << >>  << T >>  << A >>
On Wed, 04 Oct 2000 23:09:36 -0400, Michael Fluet <mfluet@wpi.edu>
wrote:

>I am doing a project using hardware encryption and am looking for 3DES
>VHDL open source.  If anyone knows where this is available, please
>advise.  Thank you.
>
>Michael Fluet
>mfluet@wpi.edu

Hmmm... guess it beats traffic lights. David Kessner has done a VHDL
DES core at www.free-ip.com/DES/index.html. A colleague of mine had a
go at putting it on an ORCA, and came to the conclusion that it was
much bigger than it needed to be, though he may have been wrong (I
wasn't allowed to look at it). It's not 3DES, and the work necessary
in selecting and implementing a 3DES mode is more or less as much as
doing the basic DES algorithm. David has a simulation on the site, but
you'll need something heavier-duty if you want to prove that it's
actually DES (get the FIPS test suite).

Evan 

Article: 26136
Subject: Re: DLL unlocking
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 05 Oct 2000 10:18:32 GMT
Links: << >>  << T >>  << A >>
On Thu, 05 Oct 2000 01:04:24 GMT, "S. Ramirez"
<sramirez@deleet.cfl.rr.com> wrote:

>Allan,
>     It sounds as if you are operating at the limits of the speed-power
>curve on the device.
>     Concerning the DLL losing lock but the LOCKED output not being
>deasserted, I remember a while back when I started using Virtex parts and
>DLLs that a Xilinx person (perdaughter? :) ) told me that the LOCKED output
>was only deasserted when the RESET input was asserted.  I didn't use LOCKED
>and I didn't have the problem that you're having or similar problems, so I
>never investigated this further.  But I couldn't help but wonder why the
>LOCKED signal couldn't represent the true status of the DLL.  Maybe they
>have changed this function, maybe not, but you might want to ask your
>favorite Xilinx person if you have to assert the RESET input to deassert the
>LOCKED signal.

I'd be very surprised if this was the case. It's not how the
simulation model works (for Virtex, don't know about Virtex-E), so it
wasn't the intention.

Allan:

> Has anyone else seen this phenomenon, or have some idea as to the cause?
> I can understand that the DLL might lose lock due to noise, but why
> wouldn't the locked output be deasserted?

The only gotcha I can think of is that the lock output will remain
asserted if the input clock stops, but this doesn't seem to be your
problem. Are you sure the input clock is still running? I'd be
inclined to check the DLL connections on FPGA Editor to make sure that
it's wired up the way you think it is.

Evan

Article: 26137
Subject: Xilinx BoardScope
From: Hchen <>
Date: Thu, 5 Oct 2000 04:08:42 -0700
Links: << >>  << T >>  << A >>
I could not run Boardscope with the -board parameter except -Demo The command line of Boardscope is "java RunBoardScope -<Board>" For -board parameter, there are several options: Demo, PametteVDC, pamettevdc800, rc1000pp, Custom,etc. 

But I only could run Boardscope with -Demo. When I selected other options, I got the following error message: 

"Could not load librar PVDCStubs UnsatisfiedLinkException: java.lang.UnsatisfiedLinkErro: no PvdcStubs in java.library.path" 

How can I solve it? Thanks!

Article: 26138
Subject: Re: Pwr/Gnd ( again)
From: erika_uk@my-deja.com
Date: Thu, 05 Oct 2000 12:08:03 GMT
Links: << >>  << T >>  << A >>
In article <39DB4538.BBE59824@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> If I understand you right, you are suggesting you use an IOB to
generate the
> logic 0 or logic 1 signal?  If that is the case, then I am assuming
you are
> doing so by either externally tying the pin, or internally using the
pad pull-up
> and leaving the pin floating.  In either case, you tie up the pin so
it can't be
> used for something else.  Where many designs are already pin limited,
I don't
> think it makes sense to use an IOB for a function that can be
accomplished
> better by a core cell.  I then mentioned an exception might be if you
used an
> unbonded pin as the generator, since those IOBs are otherwise
unusable anyway.

Thanks Ray for the reply

This what i meant.I don't see that "sacrifying" two IOBs  will cause a
problem, especially for one input data - one output design as is the
case for most of (my)applications.

Actually, I am working in modular design, I always wonder how times i
have to  duplicated the VCC and GND. This has really an effect if i
want to generated a high level description for my deisgn. so i told
let's connect the VCC and GND to the IOB. doing so, my high level
description could be written easier...

any comment from the xilinx people...

Regards

--Erika

>
> erika_uk@my-deja.com wrote:
> >
> > any more explanation,ray, i don't see really what do you mean
> >
> > In article <39DA4D27.D380F6E8@andraka.com>,
> >   Ray Andraka <ray@andraka.com> wrote:
> > > SO you are using up a pin to get your fixed logic '1' or '0' ????
> > Perhaps from
> > > an unbonded pin...
> > >
> > > erika_uk@my-deja.com wrote:
> > > >
> > > > hey,
> > > >
> > > > Sourcing a GND and VCC was an issue weeks ago in this news
group.
> > > >
> > > > Xilinx claims that the Virtex is rich in terms of routing
> > ressources,
> > > > so why not source the Pwr and Gnd wires from the IOB?
> > > >
> > > > I know a friend who does so in the xc4k, is it not possible in
> > virtex ?
> > > >
> > > > --Erika
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Before you buy.
> > >
> > > --
> > > -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  or http://www.fpga-guru.com
> > >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> -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  or http://www.fpga-guru.com
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 26139
Subject: Re: DLL unlocking
From: news@rtrussell.co.uk
Date: 5 Oct 2000 12:18:56 GMT
Links: << >>  << T >>  << A >>
bob elkind <eteam@aracnet.com> wrote:
: In any case, this is a real quick check which gives unambiguous results.
: Regardless of which way the test ends up, you've learned something about
: the problem.

I agree it's a quick test, but I'm not so sure about
"unambiguous".  The problem I was having, which turned
out to be nothing to do with timing (it was caused by
crosstalk into the JTAG inputs), also went away (or was
substantially reduced) by freezing the chip.  I assume
the temperature change affected logic thresholds.

Richard.
http://www.rtrussell.co.uk/


Article: 26140
Subject: Re: Amplify experience, was: FPGA Express strikes again! Xilinx response
From: Jamie Lokier <spamfilter.oct2000@tantalophile.demon.co.uk>
Date: 05 Oct 2000 15:04:59 +0200
Links: << >>  << T >>  << A >>
Ray Andraka writes:
> ... doesn't require my customer to have the extras to support the design.

Is it principally due to $$$, or training & tool familiarity?
Specifically, if there was a really good GPL synthesis tool (no license
fee + you have the source), and the tool suited your style of work,
would you use it for customer project?  Or would there still be a
significant non-technical barrier for use of a new tool?

I was talking to an Altera FAE who felt that going into competition with
Synplicity on synthesis via the GPL route would be no good because
customers are far too reluctant to switch tools.  I suspect $$$ may have
something to do with this though.  Any well put together tool should do
its best to fit in with the customer's existing tools.

(The Altera connection was because the FAE thought Synplicity had access
to low-level FPGA data that even he did not have, and despite saying
that Altera are 100% a hardware company they still won't be making it
easy for third parties to develop good bitstream-level optimisers).

-- Jamie

Article: 26141
Subject: Re: Pwr/Gnd ( again)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Oct 2000 13:45:37 GMT
Links: << >>  << T >>  << A >>
You normally shouldn't have to be defining vcc and ground.  putting a '1' or '0'
on the right side of your assignments should let the tools do it.  For example:


	std_logic_signal<='1';
	slv_signal<="1000111";


or in a component instantiation:

	u1:fdc port map(
		C=> clk,
		D=> flip_flop_d,
		CLR=>'0',
		Q=> flip_flop_Q);

In this way, the tools will automatically create at least 1, and probably
several each of '1' and '0' generators in the interior of the array.  The
reason, again, this was a topic of discussion a while back was that there was a
bug in the xilinx mapper that assigned all the SRL 16 address inputs to one set
of generators, which for designs using a large number of these could put too
many loads on one generator (a real problem for the '0' generators since each
lut has a weak pullup on it.  It also can have the effedt ocongesting routing.

Speficially instantiating a single '1' or '0' source carries with it the
potential for ovrlaoding the source and congesting routing as well.  There can
never be too many IO pins.  If you have some unused, it makes sense to make
judicious connections with those to facilitate an easier debug, or to make your
board more flexible so that it might be used in othr applications.  Also, be
aware that using a bonded IO and it's internal pullup for this leaves an avenue
to introduce emi into your design, as you have a fairly high impedance antenna.



erika_uk@my-deja.com wrote:
> 
> In article <39DB4538.BBE59824@andraka.com>,
>   Ray Andraka <ray@andraka.com> wrote:
> > If I understand you right, you are suggesting you use an IOB to
> generate the
> > logic 0 or logic 1 signal?  If that is the case, then I am assuming
> you are
> > doing so by either externally tying the pin, or internally using the
> pad pull-up
> > and leaving the pin floating.  In either case, you tie up the pin so
> it can't be
> > used for something else.  Where many designs are already pin limited,
> I don't
> > think it makes sense to use an IOB for a function that can be
> accomplished
> > better by a core cell.  I then mentioned an exception might be if you
> used an
> > unbonded pin as the generator, since those IOBs are otherwise
> unusable anyway.
> 
> Thanks Ray for the reply
> 
> This what i meant.I don't see that "sacrifying" two IOBs  will cause a
> problem, especially for one input data - one output design as is the
> case for most of (my)applications.
> 
> Actually, I am working in modular design, I always wonder how times i
> have to  duplicated the VCC and GND. This has really an effect if i
> want to generated a high level description for my deisgn. so i told
> let's connect the VCC and GND to the IOB. doing so, my high level
> description could be written easier...
> 
> any comment from the xilinx people...
> 
> Regards
> 
> --Erika
> 
> >
> > erika_uk@my-deja.com wrote:
> > >
> > > any more explanation,ray, i don't see really what do you mean
> > >
> > > In article <39DA4D27.D380F6E8@andraka.com>,
> > >   Ray Andraka <ray@andraka.com> wrote:
> > > > SO you are using up a pin to get your fixed logic '1' or '0' ????
> > > Perhaps from
> > > > an unbonded pin...
> > > >
> > > > erika_uk@my-deja.com wrote:
> > > > >
> > > > > hey,
> > > > >
> > > > > Sourcing a GND and VCC was an issue weeks ago in this news
> group.
> > > > >
> > > > > Xilinx claims that the Virtex is rich in terms of routing
> > > ressources,
> > > > > so why not source the Pwr and Gnd wires from the IOB?
> > > > >
> > > > > I know a friend who does so in the xc4k, is it not possible in
> > > virtex ?
> > > > >
> > > > > --Erika
> > > > >
> > > > > Sent via Deja.com http://www.deja.com/
> > > > > Before you buy.
> > > >
> > > > --
> > > > -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  or http://www.fpga-guru.com
> > > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > --
> > -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  or http://www.fpga-guru.com
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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  or http://www.fpga-guru.com

Article: 26142
Subject: Re: Xilinx par tool version 3.2i triggers wine bug
From: anders@netinsight.se (Anders=?iso-8859-1?q?_Bostr=F6m?=)
Date: Thu, 05 Oct 2000 13:53:22 GMT
Links: << >>  << T >>  << A >>
>>>>> "AB" == Anders Boström <anders@sid.netinsight.se> writes:

 AB> I've been running the win32-version of Xilinx P&R tools successfully
 AB> under wine for quite some time. Unfortunately , the latest version, 3.2i
 AB> (aka. 3.1i sp3), seem to trigger a bug in wine.

 AB> I'm running Debian potato, and have tried both the standard potato
 AB> version of wine, 20000109, and the current woody version,
 AB> 20000909. Both crashes repeatably at the same place, see below for
 AB> details.

I can happily announce that this issue is solved, mostly thanks to
Andreas Mohr and James Abbatiello! Wine release 20001002
includes a fix for the heap-bug that Xilinx P&R tools trigger in older
versions.

Everybody running Xilinx P&R tools under wine should upgrade to
release 20001002.

/ Anders

Article: 26143
Subject: Re: Xilinx Licensing.
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 05 Oct 2000 10:45:16 -0400
Links: << >>  << T >>  << A >>
Was this the super computer talking? Or Marvin the paranoid android?


Rick Filipkiewicz wrote:
> 
> Not forgetting of course the Elite Edition. Don't know what they'll call the version needed for the next
> range of huge parts - Annointed ? Maybe, following Douglas Adams,
> 
> ``The Edition that is to come after me whose very command line flags I am unworthy
>   to enumerate''

-- 

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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 26144
Subject: Re: Xilinx BoardScope
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Thu, 05 Oct 2000 09:06:34 -0600
Links: << >>  << T >>  << A >>
Hchen wrote:
> 
> I could not run Boardscope with the -board parameter except -Demo The command line of Boardscope is "java RunBoardScope -<Board>" For -board parameter, there are several options: Demo, PametteVDC, pamettevdc800, rc1000pp, Custom,etc.
> 
> But I only could run Boardscope with -Demo. When I selected other options, I got the following error message:
> 
> "Could not load librar PVDCStubs UnsatisfiedLinkException: java.lang.UnsatisfiedLinkErro: no PvdcStubs in java.library.path"
> 
> How can I solve it? Thanks!

Do you have one of these other boards?  If not, you will get the error,
unless you run BoardScope in demo mode.  I admit, its not like the
worlds most graceful failure, or clearest error message.  But note, once
you are in 'demo' mode, you can then load up the simulator, and emulate
the device you eventually want to target.
In general, you are better to write to jbits@xilinx.com with problems
like this.  
Phil
-- 
---------------------------------------------------------------------
 __
/ /\/  Dr Phil James-Roxby         Direct Dial: 303-544-5545
\ \    Staff Software Engineer     Fax: Unreliable use email :-)
/ /    Loki/DARPA                  Email: phil.james-roxby@xilinx.com
\_\/\  Xilinx Boulder                 
---------------------------------------------------------------------

Article: 26145
Subject: Re: Xilinx Licensing.
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 05 Oct 2000 08:13:20 -0700
Links: << >>  << T >>  << A >>


bob elkind wrote:

> <snip>

> Would anyone in X-land care to alpha-test a software product selection
> matrix chart to this newsgroup ?  Guaranteed we are a friendly and
> technologically sophisticated test group!  (does the smiley face go here?)
>
> -- Bob Elkind
>

Good suggestion, and I will try to collect ( or, better yet, get somebody to
collect ) this information. I published a chip overview in the recent edition
of our XCell magazine, and I want to publish a similar overview of our
software poducts.
Please hang in there...

Peter Alfke, Xilinx Application


Article: 26146
Subject: Re: pci host
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Date: Thu, 05 Oct 2000 16:14:03 +0100
Links: << >>  << T >>  << A >>
Daniel Nilsson wrote:
> 
> Hi. I wonder what it would take to make a sharc dsp to pci controller (I
> only need very basic pci functionality, enough to control a pci ethernet
> card, with dma).

PLX or AMCC make the stuff you need...

http://www.plxtech.com/
http://www.amcc.com/

Regards,

Iwo

Article: 26147
Subject: Re: DLL unlocking
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 05 Oct 2000 10:03:59 -0700
Links: << >>  << T >>  << A >>
Allan,

The LOCKED output may transition LOW on losing LOCK, and then anomolously go
HIGH again, even though the DLL is not in the LOCK state anymore.

This is a known behavior that has been addressed in future devices.  It will
not be addressed in the present devices, as this can be worked around by
logic that latches a LOW if LOCKED is ever LOW.

Causes of this are that the input jitters more than about 700 ps from one
edge to the next.  To determine that your input is 'clean' may require
careful jitter analysis.

It is also true that if the clock is lost for any reason, or an input clock
edge is missing, the DLL will behave as you state.

We recommend that the DLL be reset once the clock input signal is known to
be stable.

As to the influence of other nodes switching, if the input jitter is already
marginal, and internal switching occurs, there is some small amount of added
jitter do to all of the logic bouncing around.  This may be sufficient to
then break lock more frequently.  Observation of SSO guidelines, proper SI
engineering, proper bypass capacitor selection, etc. are all required to
keep the logic clean and working.

We have switched entire banks of IO's from 1's to 0's, and switched all
other global clock resources at unrelated rates to analyze the self jitter
contributions of the device.

Please send me an email at austin@xilinx.com if you are interested in a
particular case,

Austin

Allan Herriman wrote:

> Hi,
>
> I have a problem with a Virtex-e part that has symptoms very similar to
> those described in the recent thread "Virtex 'shutdown' phenomenon"
> initiated by Richard Russell.
>
> In my case however, a DLL stops producing a clock after a few seconds to
> a few minutes.  The "locked" output of that DLL remains high, even
> though the input clock is still present.
> Other DLLs (running at lower rates) on the same chip continue to produce
> clocks.
>
> This problem doesn't happen if the clock is less than 130MHz, and
> happens regularly above 150MHz.
> It seems to happen more often if data signals on the fpga are toggling.
>
> Once the DLL stops, the part has to be reloaded to get it to work again.
>
> The connections are basically identical to XAPP 132 Figure 9 "Standard
> DLL Implementation" (except that a DLLHF has been used, and that the
> reset input of the DLL is connected to gnd).
>
> The clock input is HSTL_I, and is clean.  The reference voltage is
> correct and is also clean.
>
> Has anyone else seen this phenomenon, or have some idea as to the cause?
> I can understand that the DLL might lose lock due to noise, but why
> wouldn't the locked output be deasserted?
>
> Thanks,
> Allan.


Article: 26148
Subject: Re: Whoa, Noise on a digital output pin?, and Minor rant on XC9500 S/W,
From: "John L. Smith" <jsmith@visicom.com>
Date: Thu, 05 Oct 2000 10:04:23 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------4E3D14C6D0CA5B341159C5B3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jens,
   Are you reasonably sure it is not ground bounce, or very high
frequency junk on input? Got a good ground plane, good vias to it,
and well placed de-coupling caps? How large (how much energy is
in) are the spikes you are seeing?

I am annoyed with 9500 parts (I'd like them a lot if they didn't
have these mysterious time-wasting problems), would like to see
some note from Xilinx on what may be any issue with them.
Otherwise, they're outta here for all new designs (and possibly
some older ones). Unfortunately, we are not a mega-purchaser
of these. If you've got their attention on this, could you
forward any response from them to the group?

  Mistakes happen, properly one owns up to them. I think Xilinx
continues to have the most advanced FPGA parts, wish they would
devote such caring expertise to the CPLD side.

Jens Konig wrote:
> 
> Hey, I know those spikes on signals simply routed 1to 1
> through XC9572. They're coming from (that's what I think)
> crosstalk on the chip from other signals. This is fact
> since Xilinx changed from ASJ9745 to AEM9917
> (new Mask+Manuf). Seems like having many bad sideeffects also.
--------------4E3D14C6D0CA5B341159C5B3
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;fax:858-457-0888
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;11776
fn:John L. Smith
end:vcard

--------------4E3D14C6D0CA5B341159C5B3--

Article: 26149
Subject: Final word on the inverted RAM write clock problem
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Thu, 05 Oct 2000 10:19:03 -0700
Links: << >>  << T >>  << A >>
It turns out that there's no falling-edge triggered write-clock RAM in
the Spartan/XL libraries, and it seems as if the synthesis tools know
that and are unable to come up with a reasonable workaround.

A Xilinx tech-support guy has just informed me he has requested that a
RAM16X1D_1 (falling-edge triggered clock) element will be added to the
Spartan libraries.  When that will occur is anyone's guess, but it's
progress!  Hopefully, the synthesis tools will realize that such a
library element exists and use it!

The suggested work-around was to do a black-box instantiation of the RAM
and clock inverter, and the map and P&R tools should do the right thing.

Turns out that my workaround was somewhat easier:  this clock signal
comes from another board via differential drivers/receivers.  I simply
swapped the hot and cold wires where they come into the board via the
backplane. :)

Oh, yeah, I bit the bullet and will be ordering Synplicity.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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