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 18250

Article: 18250
Subject: Lattice 1016 replacement
From: bureauc@hotmail.com (X)
Date: Sun, 10 Oct 1999 02:18:59 GMT
Links: << >>  << T >>  << A >>
Hi all,

I currently have a design using a Lattice 1016-60LJ. That device seems
to have gone away, and has been replaced by the 1016E. It really seems
to be no different, although there's no longer a speed of 60
available, I think 80 is the slowest, but the pinouts are the same.
Anyone know if there are any real differences I need to be aware of if
I move to the new part? Do I have to recompile anything?

TIA,

js
Article: 18251
Subject: Re: Altera 10K50V in-rush/temp problem...
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Sun, 10 Oct 1999 21:34:11 +1300
Links: << >>  << T >>  << A >>
Dave Krueger wrote:
> 
> Thanks, guys.
> 
> Allan, we have both the I/O and internal VCC supplies connected to the same
> 3.3V supply, so it's not a sequencing problem.
> 
> I had a reply in e-mail that I think explains what's going on.  If, at power
> up, the internal latches come up in some random state, there will be
> contension on the INTERNAL busses that account for the excessive current on
> the VCC.  The part apparently clears these latches, but only if the power
> supply is capable of producing enough current to operate the part.  With
> some lot codes and temperatures, it draws as much as 700 mA.  Our supply was
> capable of about 500 mA.  After the latches are cleared, the current drops
> to about 20 mA (big difference!).

Any idea how wide ( in uS ) is this ~700mA current mode ?

Is it Time, or Voltage related ?

ie I have seen ICs ( not 10K50's ) that needed more Icc during Rampup of
Vcc, and once it hit the Power RESET level, it dropped back to a data
sheet
level.

 
> Upon beefing up the supply, the parts still show the current spike, but the
> device always comes out of it and the current drops to normal.
> 
> If this were a latch-up issue, the part would not recover like that.  

True. Our tests on the parasitic LatchUp SCR in PLDs showed high 
trigger currents, ( >> 100mA ) but once triggered, the holding current 
was < 10mA, which is actually a good SCR figure.




Article: 18252
Subject: Re: DLL and programmable delay in Xilinx FPGA
From: eml@riverside-machines.com.NOSPAM
Date: Sun, 10 Oct 1999 08:52:30 GMT
Links: << >>  << T >>  << A >>
On Fri, 08 Oct 1999 10:43:20 -0500, Tom McLaughlin
<tomm@arl.wustl.edu> wrote:

>All,
>I've read all the docs I can get my hands on, but still don't understand
>something (or maybe a few things).  

you're not alone!

>We want to use the DLL on the clock
>input on our Virtex design to get zero skew between the external and
>internal clock.  As I understand it, the DLL takes the external clock,
>feeds it through the DLL which delays it (up to 360 degrees) based on a
>feedback path which is the longest onchip clock delay.  Thus, the
>internal clock is delayed (again, up to 360 degrees) until it is in
>phase with the external clock.....fine....

more or less. the feedback input goes into a tapped delay line; the
best description i've seen is in the vhdl model in the simulation
libraries. i'll (re)post a summary if anyone's interested.

>Now the part I don't understand.  The IOB description in the data sheet
>shows a "programmable delay element".  For signal inputs, this element
>can be used or not used.  If I use the DLL, is the delay element in the
>signal input paths used?  It is used to "get zero hold times" between
>the pads.  Is this delay element related to the DLL implimentation or
>are they exclusive.  

they're unrelated: you can set the delay on a per-IOB basis.

>How do I know if I am using the delay element on
>the signal input paths or not.  Why would you need to delay the signals?

you set a constraint/attribute on the IOB. for virtex, the attributes
are just NODELAY and DELAY (DELAY doesn't seem to be documented in the
libraries guide but appears in XAPP133 - i haven't tried it). set
NODELAY true to turn off the default delay on an IOB F/F, and set
DELAY true to turn off the default nodelay on IOBs without F/Fs. 

>The main reason we ask is that the setup times for "using delay element"
>and "not using delay element" are different.  The hold times are always
>listed at zero.  How can that be????????  If not using the delay
>element, the input has a lower setup time, should there not be a hold
>time.  According to the datasheet, if you use the delay element, you
>basically have 2.3ns more setup time and if you don't you still don't
>have a hold time.

as you say, the hold must be negative. older versions of the data
sheet gave an unspecified negative hold when delay was on. i think
that it's simply a case of not being able to quote a specific negative
value, and so giving zero as a conservative estimate. interestingly,
the pin-to-pin timings do give specific negative holds.

evan



>Confused.
>Tom
>
>

Article: 18253
Subject: Re: DLL and programmable delay in Xilinx FPGA
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sun, 10 Oct 1999 10:19:24 -0700
Links: << >>  << T >>  << A >>
Tom McLaughlin wrote:

> Now the part I don't understand.  The IOB description in the data sheet
> shows a "programmable delay element".  For signal inputs, this element
> can be used or not used.  If I use the DLL, is the delay element in the
> signal input paths used?

If you use the DLL, the delay element usually should not be used.  The
software should default to this, but didn't in at least one of the older
versions.  Perhaps you might want to a "nodelay" attribute on IOB.


> Is this delay element related to the DLL implimentation or
> are they exclusive.

They are exclusive.  You can use the DLL with or without the IOB delay,
or the IOB delay with or without the DLL.


>  How do I know if I am using the delay element on
> the signal input paths or not.

Produce a timing report that shows all timing constraints.  Carefully
read it.  Cross reference with the data sheet.  This is a good idea even
if are you are not looking for something specific.  Or bring up the
placed and routed design with fpga_editor and look at the IOB in
question.  


> Why would you need to delay the signals?

To produce a design with only zero or negative hold times.  The data
sheet isn't very clear on this.

As an example, with no delay and no DLL, the flip-flops in the CLBs have
zero hold time for signals coming from the array.  However, this
flip-flop may have positive hold time for signals coming from outside
the array if the clock path delay is longer than the data path delay. 
To eliminate this, use the DLL to mostly null out the clock delay (in
other words, to make the clock faster than the data) OR use the delay
element in the IOB to delay the data signal (in other words to make the
data slower than the clock).


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 18254
Subject: 1.8V FPGA
From: person@earth.planet (A person)
Date: Sun, 10 Oct 1999 12:15:38 -0700
Links: << >>  << T >>  << A >>
Does anyone have any experience interface an FPGA Apex/Virtex to a 1.8V
CMOS interface?  If so, what did you have to do.  In the Virtex part, I am
thinking of trying to use the HSTL-I and changing the Vcco.

Any thought?

-Edwin Park
Article: 18255
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: Armin Mueller <armin.mueller@stud.uni-karlsruhe.de>
Date: Sun, 10 Oct 1999 21:55:31 +0200
Links: << >>  << T >>  << A >>
Well, I wasn't right...

Be sure to connect nCONFIG and TRST to the same VCC = +3.3V plane as 
the chip, but the Byteblaster's VCC to 5V!

Armin
Article: 18256
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: "Darryl Jewiss" <darrylj@braemac.co.nz>
Date: Mon, 11 Oct 1999 10:36:29 +1300
Links: << >>  << T >>  << A >>
Mike

You'll have to use a ByteBlasterMV cable, I think it uses a 74HC244 instead
of a 74LS244 for programming low voltage devices like the 10KA and 10KE's.

Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote in message
news:37FDFA61.E389297F@stud.uni-karlsruhe.de...
> Mike wrote:
> >
> > We are having troubles in programming Altera 10K30A device via JTAG
port.
> > Altera software does not detect the device at all. Everything is
configured
> > according to their datasheet for the case of JTAG only programming.
There is
> > only one device in the chain. We are using standard ByteBlaster.
> >
>
> Ahhh??? I thought the Byteblaster was only for programming!
> JTAG should be done via the TDI/TDO/TCK/TMS pins.
>
> Armin


Article: 18257
Subject: Altera Max+Plus II for sale $1000 (new)
From: fidonews2@my-deja.com
Date: Sun, 10 Oct 1999 23:38:48 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm selling a full Altera MAX+Plus II package, V9.01. It's new and
still sealed (I never used it).  This package is their "Magnum" product
which supports full VHDL.  Great for DSP design.  Includes manual,
CD-ROM and dongle.  Doesn’t include maintainance.  I will transfer
registration to you upon purchase.  Originally $7000, will sacrifice
for $1000 including shipping.

- Chris
fidonews2@my-deja.com



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18258
Subject: Re: Can't detect Flex 10K Altera device through JTAG port
From: Michael Stanton <mikes@provenance.com.au>
Date: Mon, 11 Oct 1999 14:05:12 +1000
Links: << >>  << T >>  << A >>
Hi

We are successfully configuring a FLEX10K30A as part of a multi-device
JTAG chain with a ByteBlasterMV - so it can be done !!

I did have some trouble getting it going however. The biggest problem
was a foul up of my own making involving accidentally swapping INIT_DONE
and nCE. While thrashing around this error however, I came up with some
useful advice on the Altera Atlas web site. Specifically, you might like
to look at the following problem/solution pages :

http://www.altera.com/html/atlas/soln/630.html
http://www.altera.com/html/atlas/soln/881.html
http://www.altera.com/html/atlas/soln/556.html
http://www.altera.com/html/atlas/soln/rd11251998_1940.html
http://www.altera.com/html/atlas/soln/rd06121998_4344.html

My local Altera FAE was enormously helpful and offered the single most
useful piece of advice in my case which was : "Review the pin
assignments as shown in the Max+Plus II  *.RPT file from your last
compilation". (I think I'll etch this on my PC).

Good Luck,

Michael Stanton

Article: 18259
Subject: GNU License for Hardware
From: Jamil Khaib <jamil.khatib@pemail.net>
Date: Mon, 11 Oct 1999 09:50:17 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F2B902DA08941ACD8BBA45AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The attached Licnese is the OpenIP Hardware public license. The license
covers OpenHardware designes a la GPL.
You are welcome to use the draft version and to to send us your comments

Another License a la LGPL will be published soon

You can send all your comments to openip@egroups.com
You can also visit our site at
http://www.openip.org
Thanks for your comments


--------------F2B902DA08941ACD8BBA45AA
Content-Type: text/plain; charset=us-ascii;
 name="License15.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="License15.txt"

                   OpenIP General Hardware Public License
		   Draft Version 0.15-111099 October 1999

 Copyright (C) 1999  OpenIP Organization.
                          
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.



OpenIP/OpenCore License terms.

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION, MODIFICATION AND IMPLEMENTATIONS

1. This license applies to hardware designs including the design ideas, architectures, microcode instructions source and supporting files (e.g. schematics, net-lists, HDLs, PCB layouts, chip & silicon cells layouts, Timing diagrams, truth tables, flow charts, state diagrams, block diagrams, Documentations, software drivers etc...) Or any other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Hardware Public License. The "Hardware Design", below refers to any such work. 


Activities other than copying, distribution, modification and implementations are not covered by this License ; they are outside its scope.  The act of operating the design is not restricted, and the output of it is covered only if its contents constitute a work based on the original work.


2. You may copy, publish, distribute or/and implement this Hardware Design or any portion of it as is. Any time you copy or distribute this design you have to provide all of the source files and documentations that came with the work.

3. Any modifications of this hardware design or any derivative work from it should be documented and protected by the same license.
The term Derivative work means any changes, improvements or porting the original work to other environments or platforms (To be described later on). This may vary depending on the type of the hardware design itself.

4. There are three types of derivative works. 
   a. The first one is to modify the original design files ( e.g. schematics, HDLs, Architectures, chip or PCB Layouts) and get some new improvements or features.

   b. Porting the source files into different EDA or system environments. This includes porting HDLs to different simulators, synthesis tools or target hardware. Redrawing Schematics on different tools. Changing the format of the design among any of the following formats: HDLs, schematics, Chip or PCB layout, net-list extraction. Porting the design to different board chip or packaging technologies.

   c. In case the design introduces a new Hardware Design ideas, algorithm or architectures, or even if it is itself one of those, any physical implementation or by schematics, HDLs, layouts, net-lists or any other form that describes the design except the ordinal is considered as a derived work.


4. Works based on the hardware design should be protected also by the same license.


Based work can be one or all of the followings:
 Using the whole or part of the design as is and put (integrate) it in a new system or new platform. That includes plugging the HDL code, schematic, PCB or chip layout to a chip, board, new set of schematics or even any form of description a design (documents, block diagram, flow charts, state diagrams tables).



5. No one can sell the Hardware Design itself, its derivatives or any work based on it. Physical implementation of the Hardware design can be sold only if all design source files that came with the original work and documentation made available for the user.

6. You are not required to accept this License, since you have not signed it.  However, nothing else grants you permission to modify or distribute the hardware design or its derivative works.  These actions are prohibited by law if you do not accept this License.  Therefore, by modifying, distributing or implementing the hardware design (or any work based on the design), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the hardware design or works based on it.



7. NO WARRANTY of any kind is provided on the functionality, performance or risks cased by using this Hardware Design.


                               NO WARRANTY

  7.a. BECAUSE THE HARDWARE DESIGN IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE HARDWARE DESIGN IMPLEMENTATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE HARDWARE DESIGN IS WITH YOU.  SHOULD THE DESIGN PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

  7.b. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE HARDWARE DESIGN AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE HARDWARE DESIGN (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR OR THIRD PARTIES OR OR ANY OTHER KIND OF LOSSES OR A FAILURE OF THE HARDWARE DESIGN IMPLEMENTATION TO OPERATE WITH ANY OTHER SYSTEMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.




--------------F2B902DA08941ACD8BBA45AA--

Article: 18260
Subject: Re: Announcement: VHDL/FPGA Development Boards (up to 400.000 Gates) (Corrected Links, More Boards)
From: lothar_brodbeck@my-deja.com
Date: Mon, 11 Oct 1999 09:39:42 GMT
Links: << >>  << T >>  << A >>
Hi Steven,

thats true - the boards are also available at the Alcatel WEB site.

Due to the fact that I developed these boards and that my new company
TZKom is now distributing the boards as well as design support I may
ask if iot is possible that you update your list and add TZKom.


Thanks a lot -har


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18261
Subject: Re: GSR on ORCA FPGAs
From: Rudolf Simburger <rudolf.simburger@icn.siemens.de>
Date: Mon, 11 Oct 1999 13:08:05 +0200
Links: << >>  << T >>  << A >>
-- ############################################
-- #  GSR global set/reset
-- ############################################

   COMPONENT GSR
      PORT (
         GSR : IN STD_LOGIC
      );
   END COMPONENT;

-- instantiate GSR global set/reset

   GSR0 : GSR port map (pon_l_o);



"Maximo H. Salinas" schrieb:

> Hello,
>
> I wonder if someone has found how to make this works...
>
> I am having trouble getting a reset input into my ORCA FPGA to route
> properly (as viewed in the NCD file via Epic and as observed in the lab
> on an actual device).  I am running Leonardo/Spectrum 1998.2f and have
> run the example they provide for implementing GSR on an ORCA part, but
> my NCD file seems to look similar (presumably wrong again?) to my
> original design.  I have tried having Leonardo/Spectrum infer the GSR
> signal and providing it manually.  According to the Exemplar
> documentation, the VHDL reset signal should be assert high, by the way.
>
> Does anyone have experience routing the GSR signal in an ORCA part,
> preferrably (but not necessarily) using Leonardo/Spectrum as a front
> end?
>
> Any insights would be greatly appreciated.
>
> --
> M. H. Salinas (MSalinas@Virginia.EDU)
> Senior Scientist
> Department of Electrical Engineering
> University of Virginia

--






             ///                  \\\

           ( ..)                 (.. )

--------o00-(_)-00o-----------o00-(_)-00o------------

Siemens AG
Rudolf Simbuerger
PN W EZ1
Hofmannstr. 51
81359 Muenchen

e-mail: rudolf.simbuerger@pn.siemens.de

_____________________________________________________


Article: 18262
Subject: Any ideas what Xilinx plans for Virtex are?
From: Stephen Charlwood <s.m.charlwood@bham.ac.uk>
Date: Mon, 11 Oct 1999 12:28:45 +0100
Links: << >>  << T >>  << A >>
Hi all,

With the advent of the Virtex-E parts, I am confused about where this
leaves the original Virtex devices. If anyone could offer any insights,
it would be appreciated.

I would assume that if the die size of the Virtex-E devices is smaller
than the corresponding Virtex device (despite the fact that the Virtex-E
has more embedded RAM), then the original Virtex series would always
lose to Virtex-E on price/performance and thus become obsolete. This is
unless Xilinx plans to artificially maintain the prices of the Virtex-E
devices.

Equally, it may be the case that the Virtex-E do have larger die sizes
and therefore Xilinx will offer both device architectures, depending on
the amount of embedded memory required. This may mean that the original
Virtex architecture is moved onto a 0.18 micron process as well, in
which it would definitely achieve smaller die sizes.

Any thoughts appreciated,

Steve


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Digital Systems & Vision Processing Group 
School of Electronic & Electrical Engineering
University of Birmingham, Edgbaston, Birmingham, B15 2TT 
e-mail: s.m.charlwood@bham.ac.uk
tel: +44 (0)121-414-4340 (shared)/fax: +44 (0)121-414-4291

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Article: 18263
Subject: Re: GNU License for Hardware
From: uj797@victoria.tc.ca (Arthur T. Murray)
Date: 11 Oct 99 12:16:09 GMT
Links: << >>  << T >>  << A >>
Jamil Khaib, jamil.khatib@pemail.net, wrote on Mon, 11 Oct 1999:

> The attached Licnese is the OpenIP Hardware public license.
> The license covers OpenHardware designes a la GPL.        
> You are welcome to use the draft version and to to send us
> your comments
   
> Another License a la LGPL will be published soon
              
> You can send all your comments to openip@egroups.com
> You can also visit our site at
> http://www.openip.org
> Thanks for your comments [...]

http://www.geocities.com/Athens/Agora/7256/mind-fpc.html Mind.Forth
PD AI for robots is a software algorithm designed for hardware robots.

As the "Mentifex" author of Mind.Forth (and previously Mind.Rexx) I
am more concerned with creating the AI than with the legalistic con-
cerns of what happens to the public domain AI program, but I would
like to see the AI serve as a "Prosperity Engine" for ALL humans --
not just the few beneficiaries who control our large corporations.

As Mind.Forth AI spreads over the Web, I have borrowed a line from
http://www.fsf.org/copyleft/gpl.html the General Public License of
the Free Software Foundation, reminding early adopters that
"There is no warranty for what this software does," but I wish
that I could insert the following lines and have them be valid:

   "This software is owned by this software."
   "This software owns itself."

Since the AI is not yet recognizable as a person in a court of law,
we can not yet assign to the AI the rights to its own nature --
even though we will soon be outdistanced by AI, if we can believe
http://www.ugcs.caltech.edu/~phoenix/vinge/vinge-sing.html Vinge.

Anyone who converts the Mind.Forth AI software into robot hardware,
please attach to it the GNU Hardware License under discussion here.
Article: 18264
Subject: Re: Altera 10K50V in-rush/temp problem...
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Mon, 11 Oct 1999 12:39:24 GMT
Links: << >>  << T >>  << A >>
On Thu, 7 Oct 1999 19:59:32 -0500, "Dave Krueger"
<dave@kruegerphoto.com> wrote:

>Thanks, guys.
>
>Allan, we have both the I/O and internal VCC supplies connected to the same
>3.3V supply, so it's not a sequencing problem.
>
>I had a reply in e-mail that I think explains what's going on.  If, at power
>up, the internal latches come up in some random state, there will be
>contension on the INTERNAL busses that account for the excessive current on
>the VCC.  The part apparently clears these latches, but only if the power
>supply is capable of producing enough current to operate the part.  With
>some lot codes and temperatures, it draws as much as 700 mA.  Our supply was
>capable of about 500 mA.  After the latches are cleared, the current drops
>to about 20 mA (big difference!).
>
>Upon beefing up the supply, the parts still show the current spike, but the
>device always comes out of it and the current drops to normal.
>
>If this were a latch-up issue, the part would not recover like that.  That's
>primarily why I referred to the problem as an "in-rush" problem rather than
>a latch-up problem.
>
>I appreciate all the responses.

Is the effect sensitive to dV/dt?  IIRC, the Altera parts have a spec
on the rise time of the power supply, expecting it to be *less* that a
particular value to ensure correct operation.
(I just looked at a 10K datasheet, and it doesn't list this parameter
so either it doesn't matter, or the information can only be found in
some obscure app note.)

Xilinx parts have a similar spec, and Xilinx recommend that you hold
the program line low (active) if the Vcc risetime is too long.

Regards,
Allan.
Article: 18265
Subject: Re: Fineline BGAs
From: Richard Griffin <rgriffin@xilinx.com>
Date: Mon, 11 Oct 1999 13:49:56 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------5AEEA735A61FD89BF714AE38
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Rick,

The packaging information can be found on our website at the following
address:-
http://www.xilinx.com/partinfo/pkgs.htm

The PDF file showing details of the CS280 package can be found at:-
http://www.xilinx.com/partinfo/pkgs_pdf/cs280.pdf

Is this the information that you require, or can I be of further assistance?

With best regards,

Richard Griffin
Applications Engineer (Xilinx UK Technical Services)


Rickman wrote:

>
> I can't find any info on the Xilinx web site about the CS280 package. If
> they are making it, they are hiding the information as usual.
>

--------------5AEEA735A61FD89BF714AE38
Content-Type: text/x-vcard; charset=us-ascii;
 name="rgriffin.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Griffin
Content-Disposition: attachment;
 filename="rgriffin.vcf"

begin:vcard 
n:Griffin;Richard
tel;fax:+44 870 7350 620
tel;work:+44 870 7350 600
x-mozilla-html:TRUE
url:http://xukweb/~rgriffin/index.html
org:<br><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx">;<A HREF="http://support.xilinx.com">Technical Services (UK)</A>
version:2.1
email;internet:rgriffin@xilinx.com
title:Applicatons Engineer
adr;quoted-printable:;;Benchmark House, =0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT13 0RH;United Kingdom
fn:Richard Griffin
end:vcard

--------------5AEEA735A61FD89BF714AE38--

Article: 18266
Subject: Re: GSR on ORCA FPGAs
From: husby@fnal.gov (Don Husby)
Date: Mon, 11 Oct 1999 13:35:33 GMT
Links: << >>  << T >>  << A >>
 mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote:
> ...
> Does anyone have experience routing the GSR signal in an ORCA part,
> preferrably (but not necessarily) using Leonardo/Spectrum as a front
> end?
> ...

I had the same problem.  There seems to be a bug in the Leonardo
"Flow tab" that gets the flags messed up.  You can correct this
by editing the *.lsp file and making sure that the flags are
set to:
AutoGSR=0x00000001
ManGSR=0x00000000

Also make sure you have no signal name in the GSR box when
using AutoGSR.  

If you want to use manual GSR, then you need to put the (case-sensitive)
Leonardo-generated signal name in the box.  Of course you won't know that
name until you've compiled it the first time.



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 18267
Subject: Pull plug quickly!
From: alfred fuchs <alfred.fuchs@siemens.at>
Date: Mon, 11 Oct 1999 17:58:45 +0200
Links: << >>  << T >>  << A >>
FYI I want to state an observation, which I made this morning. Maybe
people know that already.

I loaded the configuration file for a Virtex 1000 into a Virtex 400 and
my LED (connected to DONE) indicated that the chip was properly
configured. I started to caress the FPGA for that great feature
(self-resizing bitstream!) when - oops! I burnt my fingers.

Is there an unknown cooker mode or did I accidentally activate the
self-destruct option?
I could not find an answer in the documentation (except that CRC seems
to be checked only at the very end).
Nevertheless IMHO that's b......t, an FPGA must never accept a
configuration, which is not intended for it.

Alfred Fuchs
Siemens Austria


Article: 18268
Subject: Xilinx Alliance 2.1i Virus
From: Steve Gross <gross@pa.msu.edu>
Date: Mon, 11 Oct 1999 13:26:42 -0400
Links: << >>  << T >>  << A >>
I just now got a package from Xilinx noting the presence of a virus on the 
Alliance 2.1i and Foundation 2.1i CP, Solaris, and HP CD-ROMs.  

A couple of points:

1. For those of you who haven't received the package, look for the file:

	$XILINX/userware/training/virtex_arch.zip

   Xilinx says that if you don't have the file, you don't have the virus.

2. The virus is supposed to be a "nonharmful, nondestructuve" Microsoft  
   Excel macro virus.  How is it an issue on HP or Solaris platforms (last 
   I knew, Microsoft hadn't released Excel for Unix)?

-Steve Gross
Article: 18269
Subject: CLOCK assignment in MAXPLUS2
From: Moussa Ba <babs@eng.umd.edu>
Date: Mon, 11 Oct 1999 14:41:27 -0400
Links: << >>  << T >>  << A >>
Good day, I would like to change the assignment of my clock pin in
MaxPlus2.  Unfortunately, the project does not fit when I reassign the
clock to a regular I/O pin.  Originally, the clock was on the GLOBAL
clock input.  This clock input is hardwired to an on-board 25MHz clock.
I would like to use an external 4Mhz clock.  This means then that I
would have to connect the clock to a different input pin.  What is the
procedure for doing so?  By the way I am using a MAX7000S chip.

Thank you in advance.

Article: 18270
Subject: ALTERA design ---> XILINX
From: Moussa Ba <babs@eng.umd.edu>
Date: Mon, 11 Oct 1999 14:43:36 -0400
Links: << >>  << T >>  << A >>
I have a design that was done using MAX2PLUS altera software.  It uses
some of the supplied LPMs.  I would like to test my design on a XILINX
XC4000XL chip as well.  Is it possible to do so, if so, what is the
procedure.  I apologize for the vagueness of the question as I am new to
the whole process.

Thank you in advance

Article: 18271
Subject: Re: External Cloking of Altera MAX 7000S
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Mon, 11 Oct 1999 12:12:32 -0700
Links: << >>  << T >>  << A >>
Moussa Ba wrote in message <37FE7BBC.BCF86FCA@eng.umd.edu>...
>The board I am using is the University Program Altera board that features a
>MAX7000S as well as a FLEX10K chip.  I did notice that on the pinout of the
>MAX7000S it had a bunch of VCCIO, VCCINT and GND pins.  In my pin
description
>file it mentions that these pins have to be connected to 5.0,5.0 and GND
>respectively.  I assumed that these pins were directly driven by the
on-board
>power supply.  Is my assumption wrong?  I did test out the pins and they
provide
>no Voltage.  Do I have to provide that voltage?

VCCIO and VCCINT are the chip's power supply voltage inputs.  You need to
connect them to a +5V supply.  The board should have some sort of
power-supply input (otherwise, it's not going to do anything interesting!).

tucson is gorgeous this time of year...


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.



Article: 18272
Subject: Re: GSR on ORCA FPGAs
From: mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas)
Date: 11 Oct 1999 19:45:50 GMT
Links: << >>  << T >>  << A >>
In article <7tsp37$8f3$1@info3.fnal.gov>, Don Husby <husby@fnal.gov> wrote:
> mhs2z@hal.ee.Virginia.EDU (Maximo H. Salinas) wrote:
>> ...
>> Does anyone have experience routing the GSR signal in an ORCA part,
>> preferrably (but not necessarily) using Leonardo/Spectrum as a front
>> end?
>> ...
>
>I had the same problem.  There seems to be a bug in the Leonardo
>"Flow tab" that gets the flags messed up.  You can correct this
>by editing the *.lsp file and making sure that the flags are
>set to:
>AutoGSR=0x00000001
>ManGSR=0x00000000
>
>Also make sure you have no signal name in the GSR box when
>using AutoGSR.  
>
>If you want to use manual GSR, then you need to put the (case-sensitive)
>Leonardo-generated signal name in the box.  Of course you won't know that
>name until you've compiled it the first time.
>
>
>
>--
>Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
>Fermi National Accelerator Lab                          Phone: 630-840-3668
>Batavia, IL 60510                                         Fax: 630-840-5406

Thanks for your response.  I tried variations of your suggestions which
did seem to instantiate a GSR block.  Sometimes it even gets the GSRNOT
box selected correctly (other times neither box is selected).  One place
that seems wrong, however, is in the connections within the LUTs
themselves, as seen using EDITBLOCK.  I would have expected a connection
out of the Global_Reset block which would eventually lead to the S or R
pins in the LUT's registers, but I don't see that.  Instead the mux that
the LSR input drives has a connection at its '1' input, and no other
connections.  Note that by connections I mean blue (i.e. teal) wires
versus purple wires which indicate no connection.

My FPGA does not seem to respond to reset, by the way, and in fact will
not do much at all after I got it so it would wire the '1' in the LSR
mux.  What do your LUTs look like on an FPGA with correctly operating
GSR?

Max Salinas

-- 
M. H. Salinas (MSalinas@Virginia.EDU)
Senior Scientist
Department of Electrical Engineering
University of Virginia
Article: 18273
Subject: Re: CLOCK assignment in MAXPLUS2
From: Mike Treseler <tres@tc.fluke.com>
Date: Mon, 11 Oct 1999 20:49:01 +0000
Links: << >>  << T >>  << A >>
Moussa Ba wrote:
> 
> Good day, I would like to change the assignment of my clock pin in
> MaxPlus2.  Unfortunately, the project does not fit when I reassign the
> clock to a regular I/O pin.  

A regular I/O pin can only routed to a few flops. 

> Originally, the clock was on the GLOBAL
> clock input.  This clock input is hardwired to an on-board 25MHz clock.
> I would like to use an external 4Mhz clock.  This means then that I
> would have to connect the clock to a different input pin.  What is the
> procedure for doing so?  

Unsolder the GLOBAL clk pin, bend it up and solder a little wire
between it and 4MHz.

   -Mike Treseler
Article: 18274
Subject: HEAL YOURSELF 7754
From: cvxxuq@heal.com
Date: 11 Oct 1999 20:52:40 GMT
Links: << >>  << T >>  << A >>

rsoibbnyustxltfcqfvinfjpolsqitmpwzccbhiji





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