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 42750

Article: 42750
Subject: Re: usb 2.0 on FPGAs
From: "Felix Bertram" <f.bertram@trenz-electronic.de>
Date: Thu, 2 May 2002 08:53:52 +0200
Links: << >>  << T >>  << A >>
Emanuel,

> Anybody out here know about a available PHY for a 2.0 version USB ?

being a little bit pragmatic (and looking for something slightly different
than what you really want) you may think about the following devices:

*** UTMI transceivers ***
Kawasaki KLK5KUSB200: probably shipping (www.klsi.com)
Cypress EZ-USB-TX2: announced

*** with built-in protocol engine ***
NetChip 2290: shipping
Cypress EZ-USB-SX2: "close to shipping"

*** with protocol engine and processor ***
Cypress EZ-USB-FX2: shipping


Best regards

Felix
_____
Dipl.-Ing. Felix Bertram
Trenz Electronic
Duenner Kirchweg 77
D - 32257 Buende
Tel.: +49 (0) 5223 4939755
Fax.: +49 (0) 5223 48945
Mailto:f.bertram@trenz-electronic.de
http://www.trenz-electronic.de




Article: 42751
Subject: Delivery problems..
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 02 May 2002 07:26:02 -0000
Links: << >>  << T >>  << A >>
>Then on top of it all, while I am trying to expedite the delivery of a
>few engineering samples of the XC2S150E in the industrial temp range, I
>am told that "BTW, ya know those commercial parts that the distributor
>quoted you 6 week lead time?  You won't be getting those any time soon
>either".  In fact I received an email from Xilinx support yesterday
>saying that they really haven't even made up their minds yet about
>delivery schedules and won't until the end of May!!!

Not directed at rickman, but his rant reminded me of an interesting
lesson I learned many years ago.

New job.  I was working on a network board.  The group had a person
in charge of the lab and his job included getting parts for prototype
boards like the one I was designing.

This was back when 4K FIFOs were a big deal and FIFOs were not
yet commodity parts with standard pinouts.

I had a nice stack of data books.  They had various small FIFOs, many
of them marked Advanced or Preliminary (or perhaps wishful thinking).
I wasn't clued into this problem yet so I designed around whatever
seemed best at the time.  As my design was getting more real, I
gave Steve a rough cut at a parts list.  Soon he reported that some
of the FIFOs I'd picked didn't really exist.  No major problem.  I
flipped through the books and found another one.  That one didn't
exist either.

After a couple iterations, Steve came by with a couple of parts in
his hand.  Samples.  This one really did exist.  End of problem.

Ever since that day, "Can you get samples?" was our code word
for "Does it really exist?"  If Steve could get samples, I
was happy using it in a design and he was happy too, knowing
that he wouldn't get stuck trying to locate an impossible part
while everybody was breathing down his neck.

"Samples in hand" has been my rule of thumb ever since.  Several
times I have passed it on to new people.

Of course, it sometimes doesn't work when you are using specialized
parts, like FPGAs and CPUs or big IO chips.  But even then it's a
good flag that you might have problems - an issue to put high on
your potential risk list.


I haven't used bleeding edge Xilinx parts in a long time.  They
used to be pretty good about publishing a what/when availibility
chart in XCell.  I'd be suspicious if my plans didn't mesh with
that chart, especially if I didn't have samples in hand.

Obviously, if you have a good relationship with a vendor or
distributor you can sensibly stick your neck out farther.
But it takes a while to establish that trust.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 42752
Subject: Re: synthesis error
From: Alan Fitch <alan.fitch@doulos.com>
Date: Thu, 2 May 2002 09:01:28 +0100
Links: << >>  << T >>  << A >>
In article <253573e8.0205011258.4a2a8d9c@posting.google.com>, Hassan
Mourad <Hassan_Mourad@lycos.com> writes
>Alan Fitch <alan.fitch@doulos.com> wrote in message news:<h$Zd6gBPA7z8YBum@doulo
>s.co.uk>...
>
>> The simplest way is to implement a reset pin. Your code above almost
>> looks like it is using "load" as a reset. 
>> 
>> Generally, if you use an asynchronous reset, you should write a process
>> in the style
>> 
>> process(clk, reset)
>> begin
>>   if reset = '1' then
>>     
>>        -- reset stuff, e.g. z := 63
>> 
>>   elsif rising_edge(clk) then
>> 
>>      -- synchronous actions
>> 
>>   end if;
>> 
>> end process;
>> 
>> You should only have one clock edge per process.
>> 
>> Also I would declare integers constrained, otherwise you are relying on
>> the synthesis tool to remove unused bits. You can do this like this
>> 
>> variable z : integer range 0 to 63;  -- unsigned 6 bit
>> variable z2 : integer -32 to 31;     -- signed 6 bit
>> 
>> Think hardware!
>> 
>> regards
>> 
>> Alan
>> 
>> 
>
>I still have the same error , is their any constrain that i must know
>about the range of an array ...
>
>i don't know what's wrong
>
>i've tried the tips that Mr. Alan gave , but nothing new 
>
>sincerely
>Hassan

Can you post the error please,

Alan

-- 
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                           Email: alan.fitch@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.









Article: 42753
(removed)


Article: 42754
Subject: Xilinx Download Cable III
From: point308@hotmail.com (Mark McMahon)
Date: 2 May 2002 02:28:34 -0700
Links: << >>  << T >>  << A >>
Hello all, 

I've been trying to make my own Xilinx parallel cable III using the
available schematics. My board is double sided, with a male parallel
connector so I can use any parallel cable.

The differences between my PCB and the original xilinx one are: 
(1) D6, Busy and PE are connected on the board, not at the computer
end of the cable.
(2) The tristate buffer is 74HC125A
(3) The diode are 1N4002, not 1N5817.  

I've tried two different board layouts, both of which work sometimes,
depending on which direction the wind is blowing.
I've tried both linear and switch mode power supplies. 
If anyone else has successfully implemented this design I would
appreciate some pointers in the right direction.

Thanks for your help. 
Mark.

Article: 42755
Subject: Re: JTAG programmer (ick!)
From: "Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de>
Date: Thu, 2 May 2002 11:44:08 +0200
Links: << >>  << T >>  << A >>
Hi,
finally someone who has a quite similar problem with JTAG. :)
I see you try to configure a fpga with a self-build harware and your own
device driver. Thats nearly the same i do.
And my attempts behave strange too.
Apart from the fpga (i use a 800th virtex) and the cable (lately we bought a
PC IV - which is able to simulate the same behaviour
as the PC III), i use W2k too...basically hardly any difference.
I suppose either you made a mistake at your own cable or you forgot to force
a driver pin(e.g. pin 5).

What about sharing our knowledge and cut the problems in half ?


cheers,
Jens



----------------------------------------------------------------------------
-----------------------------------------
Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de>
University of Leipzig
Germany





Article: 42756
Subject: machine constraints for NIOS in gcc?
From: Aki Suihkonen <asuihkon@cc.jyu.fi>
Date: Thu, 2 May 2002 13:00:14 +0300
Links: << >>  << T >>  << A >>
Hello,

Does anyone know how to make nios-elf-gcc to pass parameters
in a specific global register to an exception handler?
I intend to implement the user side of system calls though
#define syscall(p) ({ int _p=(p); asm("trap 5" :: "###" (_p));})
however, I don't know what to write to the '###' field.

Ideas, anyone?





Article: 42757
Subject: Re: Xilinx Download Cable III
From: "Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de>
Date: Thu, 2 May 2002 12:52:36 +0200
Links: << >>  << T >>  << A >>
Hi Mark,

In opposite to you i turned down the idea of making my own parallel cable
III. (i supposed such a influence by the blowing wind :)
I'm more interested in the connection between your computer and your board.
did you attempt to used the JTAG?
did you wrote your own device driver?
My thesis should work should work exactly this way. The JTAG interface
should be used, furthermore the parallel cable IV(which is
compatible to the PC III) should(i like this word...) be used.
Well i wrote the device driver according the circut description of the
xilinx PC III assuming that PC IV use the same pins, but...
but some pins behaves very strange.(maybe influenced by the color of my
shoes :)

so, what about talking about the cable to halve the problems with the cable?


cheers,
Jens



----------------------------------------------------------------------------
Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de>
University of Leipzig
Germany





Article: 42758
Subject: Re: DDR SDRAM Controller
From: kim <kho@<removespam>esko-graphics.com>
Date: Thu, 2 May 2002 03:18:23 -0800
Links: << >>  << T >>  << A >>
quick note :
the samsung DDR k4d263238m supports full page (used in the Xbox console)

Article: 42759
Subject: Re: Availability of XC2S150E-6FG456I
From: rjshaw@iprimus.com.au (russell)
Date: 2 May 2002 04:27:20 -0700
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<aaqifp$lmf$1@newsreader.mailgate.org>...
> I am just wondering, why can't you use XC2S150 instead of XC2S150E?
> Is it possible to replace the 1.8V voltage regulator with a 2.5V one for
> XC2S150?

You could just use a 1N4001 diode in series with the 3.3V supply
to get ~2.5V. My regulator circuit works like that, except it's
using transistors and zeners to do it.

Another way would be to use a more available commercial
temp chip, and test 10 boards at a time in an environment
chamber.

Article: 42760
Subject: Re: Virtex Evolution ( Deltas )
From: news@rtrussell.co.uk
Date: 2 May 2002 12:25:30 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> wrote:

: Changes from Virtex to Virtex-E

: Virtex-E is a minor change, mainly a shrink for higher speed and cost reduction.
: The basic architecture is identical to Virtex, but the family now extends to
: larger sizes.

You don't mention the additional Block RAMs - not a 'minor'
change as far as my applications are concerned !

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

Article: 42761
Subject: Re: SpartanII design considerations...
From: hamish@cloud.net.au
Date: 02 May 2002 13:46:22 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> One problem I had a while ago with a Spartan-II datasheet was it didn't
> say that Spartan-II IOB tri-state buffers are active low or high.

You should have read the libraries guide - it's the data sheet for
the primitives in the library.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 42762
Subject: Re: JTAG programmer (ick!)
From: Werner Dreher <dreher@informatik.uni-tuebingen.de>
Date: Thu, 02 May 2002 16:16:11 +0200
Links: << >>  << T >>  << A >>
Russell wrote:
> 
> Hi,
> 
> I can't get my spartan2 thing to program. Using impact in win2k,
> i can get toggles on pin 4 (TMS_IN) of the pc parallel port, but
> no other pins toggle (not even pin 3, CLK). I'm using a copy of
> a parallel-III jtag dongle. Could it be anything to do with win2k?
> I'm using impact in webpack-4.2.
> 

Hi,

I also use impact of webpack-4.2 to program a xilinx chip with
JTAG. It works fine under win2k. So I suggest your problem would be a
hardware bug.

Good luck!
 Werner

Article: 42763
Subject: Re: simultaneous switching of LVPECL outputs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 02 May 2002 07:31:49 -0700
Links: << >>  << T >>  << A >>
Bob,

The emperor never really had clothes, did he?

We never offered a silicon differential driver until Virtex II.

The LVPECL is a clever use of two single ended drivers, with three external resistors, two
series 100 ohm, and one parallel 187 ohm.

Looks like, smells like, and is two single ended drivers.  Just that simple.  If you want to
point out how the two single ended drivers are not a perfectly balanced, low bounce
differential driver, please do so without implying that someone here in IC design was doing a
lousy job.

Other than that, sounds like we are in "violent agreement."

Austin



Bob Perlman wrote:

> Austin -
>
> I give, I give!  You've managed to convince me that Xilinx has
> designed a differential transmitter that has poor delay matching, lots
> of shoot-through current, high I/O capacitance, and requires three
> external resistors at the driver end.
>
> Nevertheless, I'm sure it's a wonderful driver.
>
> Bob Perlman
> -----
> Cambrian Design Works
> http://www.cambriandesign.com
>
> On Wed, 01 May 2002 12:54:42 -0700, Austin Lesea
> <austin.lesea@xilinx.com> wrote:
>
> > http://www.support.xilinx.com/xapp/xapp133.pdf
> >
> >See page 32 of the pdf file.
> >
> >Austin
> >
> >Bob Perlman wrote:
> >
> >> Austin -
> >>
> >> On Wed, 01 May 2002 11:07:53 -0700, Austin Lesea
> >> <austin.lesea@xilinx.com> wrote:
> >>
> >> >Bob,
> >> >
> >> >Because the LVPECL uses a resitor network to set the levels (r's in series, r's in
> >> >parallel).
> >>
> >> What resistor networks?  The Spartan IIE data sheet says that you
> >> connect 100 ohms across the rails.  Where are the other resistors?
> >>
> >> Bob Perlman
> >> -----
> >> Cambrian Design Works
> >> http://www.cambriandesign.com
> >>
> >> >Also, each IO has the capacitive load of the pin (~ 10 pF) so each IO must charge, and
> >> >discharge that capacitance.  Charging lowers Vcco (Vcco bounce) and discharging raises
> >> >ground (ground bounce).  They don't cancel either.
> >>
> >> >Austin
> >> >
> >> >Bob Perlman wrote:
> >> >
> >> >> Austin -
> >> >>
> >> >> I think we're going in circles here.  I mentioned in my first post
> >> >> that the cancellation wouldn't be perfect, but that there would be
> >> >> some, and that I'd expect it to be significant.
> >> >>
> >> >> I can agree with your results if:
> >> >>
> >> >> (a) the true and complement transitions are significantly skewed (bad
> >> >> news for the receiver)
> >> >>
> >> >> (b) crossover current is a significant fraction of the current being
> >> >> sourced or sunk by the driver through the I/O pin, and lasts for a
> >> >> significant fraction of the rise/falltime. ( I thought that this
> >> >> wasn't the case for modern driver designs.  Can you give more
> >> >> information on duration/amplitude?)
> >> >>
> >> >> (c) both.
> >> >>
> >> >> Can you clarify something?  You've said that:
> >> >>   - driver impedance is 7 ohms
> >> >>   - drivers switch from rail to rail
> >> >>
> >> >> How do 7-ohm rail-to-rail drivers connected to 3.3V produce 0.85V
> >> >> across a 100 ohm load?
> >> >>
> >> >> Bob Perlman
> >> >> -----
> >> >> Cambrian Design Works
> >> >> http://www.cambriandesign.com
> >> >>
> >> >> On Wed, 01 May 2002 07:55:38 -0700, Austin Lesea
> >> >> <austin.lesea@xilinx.com> wrote:
> >> >>
> >> >> >Bob,
> >> >> >
> >> >> >Simple.  The outputs pull all the way to Vcc, and to ground.  The switches are not
> >> >> >current sources at all, but on and off switches with ~ 7 ohms on resistance.  The
> >> >> >current is going to flow through the IO pin, through to the ground connections, and
> >> >> >the Vcco connections.  Just because one is going up when the other is going down
> >> >> >doesn't mean they will cancel:  the delay from the pad to the package pin (25 ps to
> >> >> >125 ps), and to the external resistors is slightly different for each.  The loading
> >> >> >is slightly different on each as a result.  As well, there is a crossover current in
> >> >> >a CMOS output driver that flows from Vcco to ground when switching hi, or low, and
> >> >> >that is unaffected by this arrangement.
> >> >> >
> >> >> >So, the lab explains exactly what we expect to happen.
> >> >> >
> >> >> >I agree that mysteries are a bad thing, and we always drill down until we explain a
> >> >> >result completely.
> >> >> >
> >> >> >Austin
> >> >> >
> >> >> >
> >> >> >Bob Perlman wrote:
> >> >> >
> >> >> >> Austin -
> >> >> >>
> >> >> >> I know they're conventional single-ended I/Os; I thought I made that
> >> >> >> clear in my analysis (I assumed that the drivers both source and sink
> >> >> >> current; real PECL drivers only source current).   I'm not sure why
> >> >> >> you mentioned LVDS drivers, but they also source and sink.
> >> >> >>
> >> >> >> If you're not seeing lower ground bounce for Spartan IIE
> >> >> >> differerential LVPECL in the lab, it would be useful to figure out
> >> >> >> why.  If you're not seeing lower ground bounce, I have to wonder if
> >> >> >> the true and complementary transitions are simultaneous or
> >> >> >> near-simultaneous.  If they're not, that could spell big trouble for
> >> >> >> the receiver.
> >> >> >>
> >> >> >> When lab results are counter-intuitive, it pays to find out why.
> >> >> >>
> >> >> >> Bob Perlman
> >> >> >> -----
> >> >> >> Cambrian Design Works
> >> >> >> http://www.cambriandesign.com
> >> >> >>
> >> >> >> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea
> >> >> >> <austin.lesea@xilinx.com> wrote:
> >> >> >>
> >> >> >> >Bob,
> >> >> >> >
> >> >> >> >These are still plain old single ended IOs, and as measured in the lab, there is
> >> >> >> >virtually no difference in ground bounce from a regular single ended IO.
> >> >> >> >
> >> >> >> >LVDS in Virtex II and Virtex II Pro are current sink and source differential
> >> >> >> >drivers, and there is actually a large benefit from such drivers.
> >> >> >> >
> >> >> >> >Austin
> >> >> >> >
> >> >> >> >Bob Perlman wrote:
> >> >> >> >
> >> >> >> >> Austin -
> >> >> >> >>
> >> >> >> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
> >> >> >> >> <austin.lesea@xilinx.com> wrote:
> >> >> >> >>
> >> >> >> >> >Bob,
> >> >> >> >> >
> >> >> >> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there
> >> >> >> >> >is no benefit from differential switching as regards to ground bounce.  Each
> >> >> >> >> >single ended IO is already switching rail to rail, and driving hard.  Thus
> >> >> >> >> >even though some of the current flows out comes back in on the other pin, a
> >> >> >> >> >lot of current is flowing through power and ground.
> >> >> >> >> >
> >> >> >> >> >Austin
> >> >> >> >>
> >> >> >> >> The original poster wanted to use Spartan IIE which, if I'm reading
> >> >> >> >> the data sheet correctly, supports LVPECL differential outputs
> >> >> >> >> terminated with 100 ohms across the two signals.
> >> >> >> >>
> >> >> >> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
> >> >> >> >> 1.06-1.43V, or~ 1.25V typical.  This means that the current through
> >> >> >> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.
> >> >> >> >>
> >> >> >> >> When the differential signal switches, one driver switches from source
> >> >> >> >> to sink, while the other switches from sink to source.  On the ground
> >> >> >> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while
> >> >> >> >> the other slews from sinking nothing to sinking 8.5mA.  Similar things
> >> >> >> >> happen on the VCC side, except that current is being sourced rather
> >> >> >> >> than sunk.
> >> >> >> >>
> >> >> >> >> Beyond a certain point, the strength of the drivers is moot; the
> >> >> >> >> current into or out of the I/O pin will be limited by the transmission
> >> >> >> >> line impedance.  If we think of the differential lines as two 50-ohm
> >> >> >> >> single-ended lines, the current needed to send a 0.85V delta V down
> >> >> >> >> each line is 17mA, which is exactly the delta you get when you stop
> >> >> >> >> sourcing 8.5mA and start sinking it, or vice versa.
> >> >> >> >>
> >> >> >> >> The balance isn't perfect, but the net di/dt on either the VCC or
> >> >> >> >> ground paths should be considerably less than for single-ended
> >> >> >> >> signals.
> >> >> >> >>
> >> >> >> >> Bob Perlman
> >> >> >> >> -----
> >> >> >> >> Cambrian Design Works
> >> >> >> >> http://www.cambriandesign.com
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >Bob Perlman wrote:
> >> >> >> >> >
> >> >> >> >> >> Hi -
> >> >> >> >> >>
> >> >> >> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
> >> >> >> >> >> <hicksthe@egr.msu.edu> wrote:
> >> >> >> >> >>
> >> >> >> >> >> >Hi,
> >> >> >> >> >> >    I am seriously considering using a spartan2e to serve as a clock
> >> >> >> >> >> >distribution generator for a lvpecl clock system.  This clock system
> >> >> >> >> >> >will be driving a total of 17 differential clocks.  When I price the
> >> >> >> >> >> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
> >> >> >> >> >> >me the clock DLL to clean up my system clock.  The question is that I
> >> >> >> >> >> >have a total of 34 output lines that should be switching at the same
> >> >> >> >> >> >time.  The spec says 12 power and ground pairs in the chip and 3
> >> >> >> >> >> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
> >> >> >> >> >> >pair for me.)  How do I split these up over the 12 power/ground pairs?
> >> >> >> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
> >> >> >> >> >> >I get 12 power/ground pairs from these 24 pins?
> >> >> >> >> >>
> >> >> >> >> >> If you're using differential outputs, the power and ground di/dt
> >> >> >> >> >> should be significantly less than what you'd see for single-ended
> >> >> >> >> >> signals.  Assuming that the true and complementary transitions occur
> >> >> >> >> >> in unison, one driver should be increasing its ground or VCC current
> >> >> >> >> >> as the other driver's current is decreasing.  The match isn't perfect,
> >> >> >> >> >> but it should be pretty good.
> >> >> >> >> >>
> >> >> >> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less
> >> >> >> >> >> stringent than the  guidelines for single-ended signals.
> >> >> >> >> >>
> >> >> >> >> >> Bob Perlman
> >> >> >> >> >> -----
> >> >> >> >> >> Cambrian Design Works
> >> >> >> >> >> http://www.cambriandesign.com
> >> >> >> >> >>


Article: 42764
Subject: Re: Delivery problems..
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 02 May 2002 07:45:22 -0700
Links: << >>  << T >>  << A >>
Hal,

I was burned badly once when I got samples in 1975, and then the company
that supplied them (started with an "F") decided to discontinue the parts.

It all comes down to track record.  And trust.

Not without reason do people ask if there are samples, or if there is yield,
or if the process is reliable.  Many things can, and do, go wrong.  If it
was that easy, there would be a dozen FPGA vendors, and there are not.

As a customer, I would advise you work with the vendor(s), develop lines of
communications at different levels (eg FAE, sales, Manager to Manager, VP to
VP).  That way you can find out what you want to know quickly, and with
confidence.

For our smaller customers, there are people like Peter and myself, who are
always willing and able to help out, and get back with accurate and useful
information.

He and I remember where Xilinx' first customers came from, and we recognize
the strength of innovation in all of those thousands of small start-ups.
Some of them (like Cisco) were so small that at a conference I once helped
organize (Systems Design and Networks Conference, Santa Clara 1988), some
people laughed at their presentation!

Austin


Hal Murray wrote:

> >Then on top of it all, while I am trying to expedite the delivery of a
> >few engineering samples of the XC2S150E in the industrial temp range, I
> >am told that "BTW, ya know those commercial parts that the distributor
> >quoted you 6 week lead time?  You won't be getting those any time soon
> >either".  In fact I received an email from Xilinx support yesterday
> >saying that they really haven't even made up their minds yet about
> >delivery schedules and won't until the end of May!!!
>
> Not directed at rickman, but his rant reminded me of an interesting
> lesson I learned many years ago.
>
> New job.  I was working on a network board.  The group had a person
> in charge of the lab and his job included getting parts for prototype
> boards like the one I was designing.
>
> This was back when 4K FIFOs were a big deal and FIFOs were not
> yet commodity parts with standard pinouts.
>
> I had a nice stack of data books.  They had various small FIFOs, many
> of them marked Advanced or Preliminary (or perhaps wishful thinking).
> I wasn't clued into this problem yet so I designed around whatever
> seemed best at the time.  As my design was getting more real, I
> gave Steve a rough cut at a parts list.  Soon he reported that some
> of the FIFOs I'd picked didn't really exist.  No major problem.  I
> flipped through the books and found another one.  That one didn't
> exist either.
>
> After a couple iterations, Steve came by with a couple of parts in
> his hand.  Samples.  This one really did exist.  End of problem.
>
> Ever since that day, "Can you get samples?" was our code word
> for "Does it really exist?"  If Steve could get samples, I
> was happy using it in a design and he was happy too, knowing
> that he wouldn't get stuck trying to locate an impossible part
> while everybody was breathing down his neck.
>
> "Samples in hand" has been my rule of thumb ever since.  Several
> times I have passed it on to new people.
>
> Of course, it sometimes doesn't work when you are using specialized
> parts, like FPGAs and CPUs or big IO chips.  But even then it's a
> good flag that you might have problems - an issue to put high on
> your potential risk list.
>
> I haven't used bleeding edge Xilinx parts in a long time.  They
> used to be pretty good about publishing a what/when availibility
> chart in XCell.  I'd be suspicious if my plans didn't mesh with
> that chart, especially if I didn't have samples in hand.
>
> Obviously, if you have a good relationship with a vendor or
> distributor you can sensibly stick your neck out farther.
> But it takes a while to establish that trust.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.


Article: 42765
Subject: Re: Xilinx Download Cable III
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Thu, 2 May 2002 17:57:22 +0300
Links: << >>  << T >>  << A >>
I think you should use IN5817 since it is a shottky diode. 1N4002 is a
regular silicon diode. Forward voltage drop over a shottky is around
0.15..0.25 volts while it is 0.55..0.65 volts for a regular diode. And for
voltage detection there are two diodes in series in the programming cable...

--
Tuomo Auer

"Mark McMahon" <point308@hotmail.com> wrote in message
news:f30d4942.0205020128.33e302e4@posting.google.com...
> Hello all,
>
> I've been trying to make my own Xilinx parallel cable III using the
> available schematics. My board is double sided, with a male parallel
> connector so I can use any parallel cable.
>
> The differences between my PCB and the original xilinx one are:
> (1) D6, Busy and PE are connected on the board, not at the computer
> end of the cable.
> (2) The tristate buffer is 74HC125A
> (3) The diode are 1N4002, not 1N5817.
>
> I've tried two different board layouts, both of which work sometimes,
> depending on which direction the wind is blowing.
> I've tried both linear and switch mode power supplies.
> If anyone else has successfully implemented this design I would
> appreciate some pointers in the right direction.
>
> Thanks for your help.
> Mark.


Article: 42766
Subject: Re: XC4000 readback woes
From: Christian Plessl <plessl@remove.tik.ee.ethz.ch>
Date: Thu, 02 May 2002 17:02:48 +0200
Links: << >>  << T >>  << A >>
Hi John.

I had similar problems with instantiating the readback component. It's been 
a while since than, but I think the problem looked about the same. But I 
was using Xilinx Foundation 3.1i at that time, i.e. synthesis was done 
using FPGA Express, not Xilinx XST. Can you have a look at the schematic of 
the synthesized circuit? In my case it was simply broken, the readback 
component was not connected properly. I tried to manually insert buffers to 
prevent the tools from optimizing the readback component away, but I 
couldnt get things right. There were always unconnected ports und nets 
going to nowhere or starting from nowhere. At some point, I gave up trying 
to fix these problems.

If I remember right, the problems were not present in earlier versions of 
the the synthesis software, i.e. the problem was only introduced by the 
installation of a certain service pack. But I'm not sure about that 
anymore..

Xilinx customer support did also send me VHDL code that should work, but 
the problems were the same, also with the Xilinx provided code.

Regards,
 Chris

John Williams wrote:

> Hi,
> 
> I'm using an XC4010E on an XS40 board, and am trying to implement a
> simple parallel cable readback interface.  I've scoured the Xilinx web
> pages, newsgroups, and the web in general, and am having great
> difficulty doing what appears on the surface to be fairly
> straight-forward.  The problem is not the parallel interface, but simply
> trying to instantiate a readback block and get the readback going.
> 
> I'm using FPGA Express under ISE4.2i targetting the XC4010E.
> 
> I've tried using both schematic capture and VHDL, and whatever I do, it
> seems like the readback block is being "optimised out".  I've even tried
> attaching dummy logic to the inputs and outputs to force the signals to
> remain, but it still happens.  There's a Xilinx Answer which proposes
> the following VHDL code to implement readback:
> 



--
Christian Plessl
remove 'remove' from email-address when replying


Article: 42767
Subject: Modelsim testbench problems
From: prashantj@usa.net (Prashant)
Date: 2 May 2002 08:16:19 -0700
Links: << >>  << T >>  << A >>
hi,

I'm using the modelsim version 5.5e supplied with Altera's Quartus II
toolset. I have been trying to write a test bench. My aim is to read a
file with input vectors and assign these vectors to a std_logic_vector
signal. How can I convert a "variable IN_BUF : line" type to a
std_logic_vector signal. I will probably need some conversion
functions, but I don't seem to find anything working. Haven't seen
anything in the documentation either.

I have pasted a part of my code below. Any help would be appreciated.

Thanks,
Prashant

 
LIBRARY ieee;                                               
USE ieee.std_logic_1164.all;                                
USE std.textio.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use ieee.std_logic_arith.all;
USE ieee.std_logic_textio.all;
 
ENTITY mult16x16_tb1 IS
END mult16x16_tb1;
ARCHITECTURE mult16x16_arch OF mult16x16_tb1 IS
-- constants                                                 
-- signals                                                   
SIGNAL t_sig_a : STD_LOGIC_VECTOR(15 DOWNTO 0);
SIGNAL t_sig_b : STD_LOGIC_VECTOR(15 DOWNTO 0);
SIGNAL t_sig_clk : STD_LOGIC;
SIGNAL t_sig_outl : STD_LOGIC_VECTOR(15 DOWNTO 0);
SIGNAL t_sig_outm : STD_LOGIC_VECTOR(15 DOWNTO 0);
 
COMPONENT mult16x16
 PORT (
 a : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
 b : IN STD_LOGIC_VECTOR(15 DOWNTO 0);
 clk : IN STD_LOGIC;
 outl : OUT STD_LOGIC_VECTOR(15 DOWNTO 0);
 outm : OUT STD_LOGIC_VECTOR(15 DOWNTO 0)
 );
END COMPONENT;
BEGIN
 tb : mult16x16
 PORT MAP (
-- list connections between master ports and signals
 a => t_sig_a,
 b => t_sig_b,
 clk => t_sig_clk,
 outl => t_sig_outl,
 outm => t_sig_outm
 );
 
a  : PROCESS
file input: TEXT is in "input.txt";
variable IN_BUF : line;
BEGIN
while not endfile(input) loop
IN_BUF  := NULL;
READLINE (input,IN_BUF);

t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF);-- this is the line that
doesn't seem to work.

WAIT;
end loop;
END PROCESS a;

Article: 42768
Subject: Re: Xilinx Download Cable III
From: Werner Dreher <dreher@informatik.uni-tuebingen.de>
Date: Thu, 02 May 2002 17:25:45 +0200
Links: << >>  << T >>  << A >>
Hi Mark,

two suggestions:
1)
reflexions / overshoots on the wires between your board and
the xilinx chip.
Try with shortest wires as possible.

2)
reflexions on the cable between the computer and your board.
Try with a very short cable.

(I have made a slightly different circuit to program a Xilinx CPLD.)

good luck!
 Werner


Mark McMahon wrote:
> 
> Hello all,
> 
> I've been trying to make my own Xilinx parallel cable III using the
> available schematics. My board is double sided, with a male parallel
> connector so I can use any parallel cable.
> 
> The differences between my PCB and the original xilinx one are:
> (1) D6, Busy and PE are connected on the board, not at the computer
> end of the cable.
> (2) The tristate buffer is 74HC125A
> (3) The diode are 1N4002, not 1N5817.
> 
> I've tried two different board layouts, both of which work sometimes,
> depending on which direction the wind is blowing.
> I've tried both linear and switch mode power supplies.
> If anyone else has successfully implemented this design I would
> appreciate some pointers in the right direction.
>

Article: 42769
Subject: Re: Modelsim testbench problems
From: vhdlcohen@aol.com (VhdlCohen)
Date: 02 May 2002 15:38:30 GMT
Links: << >>  << T >>  << A >>
>LIBRARY ieee;                                               
>USE ieee.std_logic_1164.all;                                
>USE std.textio.all;
>use IEEE.STD_LOGIC_UNSIGNED.ALL;
>use ieee.std_logic_arith.all;
>USE ieee.std_logic_textio.all;

>a  : PROCESS
>file input: TEXT is in "input.txt";
>variable IN_BUF : line;
>BEGIN
>while not endfile(input) loop
>IN_BUF  := NULL;
>READLINE (input,IN_BUF);
>
>t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF);

Instead of: ">t_sig_a <= CONV_STD_LOGIC_VECTOR(IN_BUF);"
Use 
Read(in_buf, t_sig_a); -- THis is from  the std_logic_textio package
Take a look at the boby of the package. 
-------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8 
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------


Article: 42770
Subject: Re: static logic vs LUT
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Thu, 02 May 2002 09:39:34 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------2F361A617593AF48BA959FE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



We had a similar discussion to this over a year ago and it is currently
archieved at the FPGA-FAQ web page at:
http://www.fpga-faq.com/FAQ_Pages/0016_Wired_AND_OR.htm  I certainly suggest
reading this if you are intersted in this subject.  I know synthesis tools are
always improving and I would not be surprised if some are now taking greater
advantage of the carry chain for wide logical functions however I am not aware
of any that currently do.  As seen in that FAQ page, in VHDL, it is not too
difficult to create that structure using some generate statements.  I guess it
would be just as easy to do in Verilog if your synthesis tool supports the 2001
generate constructs (I just heard synplify 7.1 does) however I have not tried
that yet myself (but plan to soon).

If you choose the implementation that uses the carry-chain, you are stuck in a
vertical orientation which generally is more advantagous than detrimental to
most designs.  Most arithmetic functions (adder, subtractor, counter, etc.) that
could feed or be fed to this logical function(s) will be in the same orientation
because of the carry chain.  Just be sure the LSB of the logical function is at
the bottom as most arithmetic functions map to the carry chain in that manner.
In other words, match bus direction.  If for some reason you need a horizontal
orientation, then you are probably better off staying in LUTs however depending
on how wide the function may be, it still might be better to stay on the carry
chain and accept slightly longer routes.


--  Brian




"news.bellatlantic.net" wrote:

> Do any of the tools (either the synthesis or mapping stages) support this,
> or do you have to create instantiations yourself?
>
> BTW this would stack the OR inputs "vertically." if you need them
> horizontal, perhaps the SOP feature would work?  -Stan
>
> "Peter Alfke" <palfke@earthlink.net> wrote in message
> news:3CCB9127.D10CAD92@earthlink.net...
> > Any one LUT takes 4 inputs (any function you want).
> > You can then concatenate LUTs through the carry chain at no extra cost in
> > area, and about 30 ps additional delay per LUT used.
> >
> > Peter Alfke, Xilinx Applications
> > ================================
> > crackeur wrote:
> >
> > > In static logic, to implement a gigantic OR function, one may instead
> stack
> > > up multiple layers of OR gates in order to optimize for performance. How
> > > does
> > > LUT work, is it any different? If I want to implement an OR function
> with
> > > lots of inputs, does LUT do it better, or in otherwords, how does the
> FPGA
> > > compiler optimize this using LUTs?
> > >
> > > Jimmy
> >



Article: 42771
Subject: Re: Availability of XC2S150E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 May 2002 11:57:37 -0400
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
> 
> I am just wondering, why can't you use XC2S150 instead of XC2S150E?
> Is it possible to replace the 1.8V voltage regulator with a 2.5V one for
> XC2S150?
> 
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)

Yes, I can do that if you can provide me with a TMS320C6711B that runs
from 2.5 volts.  :)


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42772
Subject: Re: Availability of XC2S150E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 02 May 2002 11:59:15 -0400
Links: << >>  << T >>  << A >>
ussell wrote:
> 
> Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<aaqifp$lmf$1@newsreader.mailgate.org>...
> > I am just wondering, why can't you use XC2S150 instead of XC2S150E?
> > Is it possible to replace the 1.8V voltage regulator with a 2.5V one for
> > XC2S150?
> 
> You could just use a 1N4001 diode in series with the 3.3V supply
> to get ~2.5V. My regulator circuit works like that, except it's
> using transistors and zeners to do it.
> 
> Another way would be to use a more available commercial
> temp chip, and test 10 boards at a time in an environment
> chamber.

That might be possible, but I am being told that the commercial temp
chips that I expected to be receiving in a few weeks are also not
available until August.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42773
Subject: Re: Availability of XC2S150E-6FG456I
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 2 May 2002 19:04:45 +0200
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:3CD16253.FD3CF44A@yahoo.com...

> > Another way would be to use a more available commercial
> > temp chip, and test 10 boards at a time in an environment
> > chamber.
>
> That might be possible, but I am being told that the commercial temp
> chips that I expected to be receiving in a few weeks are also not
> available until August.

Arent the industrial temp. chips not just the same as the commercial ones,
exept that they are selected to run at higher tmeperatures (slower
transistors) at the same speed as the commercial ones?
So IMHO there are ways to overcome the problem for the prototypes. If your
timing analyzer tells you, a commercial chip runs @ 120 Mhz, this can maybe
translated to 100MHz operation of a industrial version. You could also
tweeak the core voltage to the upper end (+5%) to do you test and "simulate"
the industrial versions. Or just test on lower temperatures, extrapolating
the (unfurunately not available) industrial speed grades.
Yes, this is all a little bit experimental and not fully covered by the
datasheets.
But as Peter said.
"No Guts, no glory"

--
MfG
Falk





Article: 42774
Subject: Re: JTAG programmer (ick!)
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Thu, 02 May 2002 17:05:36 GMT
Links: << >>  << T >>  << A >>
You might try our Hotman product http://www.vcc.com/hmSet1.html  . We've
been working on with the xilinx download cable for a few months and we seem
to be able to configure and readback with no problem. You need to download
the driver from
http://www.driverlinx.com/Software_Products/softwareproducts.htm  You might
just be able use the driver with what you have already written, it seems
very robust.

Steve C



"Jens Frauenschlaeger" <conny@informatik.uni-leipzig.de> wrote in message
news:aar1j7$ln5$1@news.uni-leipzig.de...
> Hi,
> finally someone who has a quite similar problem with JTAG. :)
> I see you try to configure a fpga with a self-build harware and your own
> device driver. Thats nearly the same i do.
> And my attempts behave strange too.
> Apart from the fpga (i use a 800th virtex) and the cable (lately we bought
a
> PC IV - which is able to simulate the same behaviour
> as the PC III), i use W2k too...basically hardly any difference.
> I suppose either you made a mistake at your own cable or you forgot to
force
> a driver pin(e.g. pin 5).
>
> What about sharing our knowledge and cut the problems in half ?
>
>
> cheers,
> Jens
>
>
>
> --------------------------------------------------------------------------
--
> -----------------------------------------
> Jens Frauenschlaeger, <conny@informatik.uni-leipzig.de>
> University of Leipzig
> Germany
>
>
>
>





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