1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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.


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.


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

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