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 20475

Article: 20475
Subject: Re: Viterbi Dec. in VHDL (on Xilinx XC4000)
From: Marc Reinert <reinert@tu-harburg.de>
Date: Fri, 11 Feb 2000 11:34:56 +0100
Links: << >>  << T >>  << A >>
Thanks for the Link!

I found there VHDL-Listing's for Block codes. Unfortunatly isn't it exactly
what I'm looking for.
What I'm going to build is an encoder/decoder for a convolutional Code.

So I'm still grateful for further information.

Edwin Naroska schrieb:

>
> You may take a look at the following link:
>
>     Viterbi encoder/decoder for the (22,8,6) block code:
>         http://www-ee.eng.hawaii.edu/~pramod/ee628/viterbi.html
>
> --
> Edwin


Article: 20476
Subject: HELP ! Problems in mapping
From: Manan <manan_sanghiNOmaSPAM@hotmail.com.invalid>
Date: Fri, 11 Feb 2000 03:43:40 -0800
Links: << >>  << T >>  << A >>
I am a xilinx user and am having problems in the mapping
stage(the second one) of implementation. actually i dunno
where to keep my "map.exe" file. the problem actually
surfaces in the third stage of the implementation i.e.
routing. if i could somehow figure out where is Xilinx
looking for the map.exe file i could do the needful.

the error message is:

"ERROR:baspw:110 - Cannot find Input file "map.ncd".  Please
verify that your
paths and permissions are properly set for this file."

if any1 has some helpful advice, i will be grateful to the
same.
even if u don't have anything to offer, i thank u
nonetheless for having the patience to read out my problem.

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful

Article: 20477
Subject: XILINX JTAG ID
From: Hans Holm <ff@sigcom.de>
Date: Fri, 11 Feb 2000 12:47:16 +0100
Links: << >>  << T >>  << A >>
Hi Folks

I'd like to load the Boundary_Scan Identification_Register of  my XCS40
into a internal Register of my Spartan itself. Does anyone know how I
can do this during startup?
I don't want to set up a whole JTAG interface.

thanks
ff


Article: 20478
Subject: re: Looking for a small, fast CPU core for FPGA
Date: Fri, 11 Feb 2000 12:07:15 +0000
Links: << >>  << T >>  << A >>

Try the ARC:

http://www.arccores.com/

John

Article: 20479
Subject: Re: HELP ! Problems in mapping
From: "David Hawke" <dhawke@skynow.net>
Date: Fri, 11 Feb 2000 13:29:45 -0000
Links: << >>  << T >>  << A >>
Which version of s/w are you running.
From what you describe it sounds to me that you are running script mode, and
need to verify that your %Xilinx% environment and path is correctly set

Just type 'set' at the prompt to find out.

Map should be in the %xilinx%/bin/nt directory, and produces a map.ncd file
for PAR.

Check the script is not calling it something else...

Hope this helps, if not then open a case with the Xilinx holtine
(hotline@xilinx.com)

Regards,

Dave Hawke
Xilinx UK.

Manan wrote in message <03000ec8.68ccfe94@usw-ex0108-061.remarq.com>...
>I am a xilinx user and am having problems in the mapping
>stage(the second one) of implementation. actually i dunno
>where to keep my "map.exe" file. the problem actually
>surfaces in the third stage of the implementation i.e.
>routing. if i could somehow figure out where is Xilinx
>looking for the map.exe file i could do the needful.
>
>the error message is:
>
>"ERROR:baspw:110 - Cannot find Input file "map.ncd".  Please
>verify that your
>   paths and permissions are properly set for this file."
>
>if any1 has some helpful advice, i will be grateful to the
>same.
>even if u don't have anything to offer, i thank u
>nonetheless for having the patience to read out my problem.
>
>
>* Sent from AltaVista http://www.altavista.com Where you can also find
related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is
Beautiful


Article: 20480
Subject: Re: Simulation problem
From: a@z.com
Date: Fri, 11 Feb 2000 08:37:48 -0500
Links: << >>  << T >>  << A >>
Hi Pradeep,

In line 8 use:

compute:process(xin1,xin2)

compute:process(xin1,xin2) is

and you should be OK.

Catalin


Article: 20481
Subject: Re: Xilinx error message
From: a@z.com
Date: Fri, 11 Feb 2000 08:46:59 -0500
Links: << >>  << T >>  << A >>
Hi Bjorn,

You cannot assign values to the same signal (KLAR) in two different
processes (COUNT_machine and FEMTON_machine). It is like connecting
together the outputs of two flip-flops.

Catalin


Article: 20482
Subject: Re: Master/Serial mode for Virtex
From: a@z.com
Date: Fri, 11 Feb 2000 09:06:37 -0500
Links: << >>  << T >>  << A >>
Tom,

To add a very short conclusion to the very good description made by Rick and

1) Yes, the DONE pins of all dasy-chained FPGAs must be connected together. If
you do not do that, once one FPGA is configured and its own DONE pin goes
high, its DOUT pin (connected to the DIN pin of the next FPGA) becomes a
general purpose I/O and no bitstream will come out of it - all FPGAs
downstream will not configure

2) Yes again, all INIT pins must be connected together. All FPGAs go trough an
initialisation phase (INIT low) and the master must wait for all slaves to
release INIT before starting the configuration. INIT is bidirectional for this
reason. Also holding INIT low during power on or PRGM low puts the FPGA in
JTAG configuration mode

If all slaves are identical you can consider connecting them in parallel to
the master - this will substantially reduce your configuration time (and the
size of your PROM). You still have to tie together all DONE and INIT pins

Catalin

Rickman wrote:

> Tom McLaughlin wrote:
> >
> > All,
> > I've read the Xilinx docs until I can't stand it anymore.  From my
> > building a prototype system that is a chasis system with 17 boards.  We
> > want to put a board in the system that holds the PROMs for the FPGAs as
> > there are several boards that are the same and we don't want to have to
> > put PROMS on the identicle boards.  One board in a set will define the
> > FPGA on that board as the master and the rest will be slave.  We are
> > planning to use the 1800 series proms from Xilinx.  We believe that
> > CCLK, DONE, INIT, DATA, and PROGRAM have to be connected between the
> > master FPGA and the PROM.  Okay, program only if we are going to use it,
> > but we are.  We know that CCLK and DATA have to go to the slaves, but:
> >
> > 1) Does DONE of the slaves have to be connected?
> > 2) Does INIT of the slaves have to be connected?
> >
> > In one diagram, INIT is connected to all of the devices connected and in
> > another only the master.
> >
> > I think we can just put pullups on the DONE signals of the slaves???
> >
> > Can someone explain why INIT is a bidirectional signal???
> >
> > Thanks for the help...anyone done this before???
> >
> > Tom


Article: 20483
Subject: Processing a sdf file
Date: Fri, 11 Feb 2000 14:09:49 +0000
Links: << >>  << T >>  << A >>
Hello,

I am simulating a chip using an IKOS hardware
accelerator.
I have two IKOS boards, each with a capacity of
512K primitives.
Without the backannotation, the chip maps itself
on these two boards, but with the backannotation,
some primitives are missing. This is because
nets delays consume some primitives.

So I am looking for a script able to process a sdf
file in order to merge the
nets delays on the receiving cell delays.

I know this is not clean for spike processing
because the propagation mode on net is transport and
the propagation mode on cell is inertial,
but it is better than nothing.

Regards
Jean-Marc Allard

Article: 20484
Subject: Re: Xilinx Virtex Reset
From: a@z.com
Date: Fri, 11 Feb 2000 09:23:21 -0500
Links: << >>  << T >>  << A >>
Hi Mark,

Hi Rick,

Another often ignored problem with the global async reset is that not only
can your flip-flops start at different clock edges (very bad for finite
state machines) but they can also go metastable if reset is really
asynchronous to clock. A metastable flip-flop connected to more than one
other flip-flop can have different values in different places at the same
time (even worse for FSMs). This problem is also cured by the suggestions

One other often used solution is to pass the asynchronous reset signal
trough at least two flip-flops (making it synchronous and solving the
metastable recovery problem at the same time) and using this signal to
synchronously start the critical flip-flops in your design. The asynchrous
reset can then be safely connected to GSR and reset all flip-flops. This is
very similar to Rick's microcontroller solution except you do not need a
microcontroller.

In all cases making sure that control signals are in their inactive state
during reset is always a very good idea.

Catalin

Rickman wrote:

> Mark Luscombe wrote:
> >
> > Hi,
> >
> > I am trying to work out a satifactory method for resetting a
> > synchronously design Virtex running at 74MHz.
> >
> > Now, the reset signal needs to be synchronised with the 74MHz clock
> > and the propagation delay from this to the CLB and IOB DFFs needs to
> > be less than 13ns to ensure that all registers within the device at
> > reset on the sam clock edge.
> >
> > Xilinx seem to have been telling people not to use the GSR net, as it
> > is too slow, but it does seem a pity not to use it, and use extra
> > routing and CLB inputs for a global reset.
> >
> > It seems as though the STARTUP_VIRTEX component can accept a USER_CLK
> > input, i.e. the 74MHz, so is this a good solution ?
> > Also, this component has a GSR input for an external reset signal,
> > does anybody know if this is also synchronised with the USER_CLK input
> > ?
> > The device is configured in 8-bit parallel with CCLK which is related
> > to the 74MHz.
> >
> > What have other designers done in this situation.
> >
> > Cheers, Mark.
>


Article: 20485
Subject: Re: ROL VHDL operator.. need help!
From: a@z.com
Date: Fri, 11 Feb 2000 09:56:45 -0500
Links: << >>  << T >>  << A >>
Hi Teik-Ming,

There is nothing to stop you defining your own "rol" function if you are
missing a certain flavor. You can call it "rol" to overload the existing
operator or give it a different name.

Catalin

Alan Fitch wrote:

> In article ?Pine.OSF.3.95.1000210225125.25643A-100000@plato.ucs.mun.ca?,
> TeikMing Goh ?ming@morgan.ucs.mun.ca? writes
> ?Hi All,
> ?
> ?Can someone tell me what library I should use in order to use ROL
> ?operation(rotate left)?  I used LIBRARY IEEE, use ieee.std_logic_1164.all
> ?and use ieee.std_logic_arith.all, but I got syntax error on that.
> ?Thank you
> ?
> ?Regards
> ?Teik-Ming


Article: 20486
Subject: xilinx
From: elynum@my-deja.com
Date: Fri, 11 Feb 2000 15:41:36 GMT
Links: << >>  << T >>  << A >>
How would I go about programming 2 xilinx fpga's on a single board?
Would I need 2 separate EEPROM chips(ATMEl) or just one?  How would
I go about doing it with a microprocessor 8051 or 860?  What would I
need to do this?

Sent via Deja.com http://www.deja.com/

Article: 20487
Subject: Re: Master/Serial mode for Virtex
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Fri, 11 Feb 2000 10:41:07 -0600
Links: << >>  << T >>  << A >>
Excellent description.....I wish you would write an app note on
this.....yeah, I've seen the Xilinx app notes, but they are a bit
criptic...at least for me anyway.

Perhaps I didn't describe our design clearly as the responses seemed to
assume we were daisy chaining the FPGAs together.  We are not....at least by
my definition of daisy chaining.  For example, on the PROM board we will have
a PROM that contains a bitstream for the XBAR FPGA only.  There are 9 XBAR
FPGAs all on different boards.  So, we want to program these in parallel with
one being the master and the other 8 being slaves.  If I understand the posts
correctly, INIT and DONE do need to be connected on the slaves as well as the
master.  We will do this same thing with several other FPGAs and are trying
to figure out how many signals will be traveling down the backplane.  If we
could get away with not sending INIT and DONE to the slaves, it would be
best, but I guess not.

We are hoping to use the 1800 series proms from Xilinx, use the JTAG
interface to program the PROMs and kick off the config cycle.  This way we
don't have to socket the PROMs and don't have to pull the boards out when
changing the bitstreams.  Is this nuts or what....probably we should socket
the PROMs just in case.

Any more thoughts???  Thanks again,
Tom


Article: 20488
Subject: Re: Spartan and timing analyzer: clock nets using non-dedicated resources
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 11 Feb 2000 10:03:39 -0700
Links: << >>  << T >>  << A >>
Tom Burgess wrote in message <38A35E12.DE1CC4F8@hia.nrc.ca>...
>The newer parts are amazing all right. Even a slow XLA should give
>12.5 - (1.5 Tcko + 1.5? route + 3.0 Tgls + 0.7 Tecck) = 5.8 ns margin.
>If we were talking about ye olde 4000 series of 5+ years ago, then "worry"
>might have been the right word.

Well, the part I'm using is a Spartan XL-4.  I've decided to not worry about
it!

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

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 20489
Subject: Re: Spartan and timing analyzer: clock nets using non-dedicated resources
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 11 Feb 2000 10:06:44 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote in message <38A33051.7E751035@xilinx.com>...
>
>
>Tom Burgess wrote:
>
>> <snip>. This also applies to Peter's suggestion of distributing a 40 MHz
CE,
>> in which case you have to worry about meeting CE setup times back in the
80 MHz domain.
>> It looks like derived clocks will be much easier to deal with in the
Virtex/Spartan 2 family.
>>
>
>I made the assumption that meeting the 80 MHz set-up time with a global net
( plus divider delay)
>would be no problem.
>One gets spoiled with the newer  parts, like Virtex-E:
>clock-to-Q = 1ns, Tilo = 0.5 ns, Tsu = 1 ns,
>plus of course routing which is also very fast.
>100 MHz designs are not difficult anymore.
>
>And the DLL lets you divide the clock without intoducing any delay between
the two clock domains.
>Neat stuff !

Peter,

Had the Spartan-II been available six months ago when I started down this
route, I would've chosen it!  OK, you just have to add that other voltage
regulator.  That would make three power supplies on the board!

Actually, the reason I did the divide-by-two clock in the first place was
because I put a 32-deep by 16-wide FIFO in the part, and the CORE datasheet
told me that the FIFO wouldn't run at 80 MHz.  And I thought about it some
more, and realized that most of the design didn't need to run at 80 MHz.

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

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 20490
Subject: Re: xilinx
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 11 Feb 2000 10:13:54 -0700
Links: << >>  << T >>  << A >>
elynum@my-deja.com wrote in message <881ajg$c3l$1@nnrp1.deja.com>...
>How would I go about programming 2 xilinx fpga's on a single board?
>Would I need 2 separate EEPROM chips(ATMEl) or just one?  How would
>I go about doing it with a microprocessor 8051 or 860?  What would I
>need to do this?

the Xilinx manuals have a fairly-decent explanation of how to configure more
than one device.

With a serial PROM, one of your devices is the "master," the other is the
"slave."  The configuration pins for each device need to be set
appropriately.  Connect CCLK on the master to CCLK on the slave and the
PROM's clock pin.  The master will source CCLK and accept the PROM's data on
its DIN pin.  The master will shift the data out its DOUT pin, so you should
connect the master DOUT to the slave DIN.  DONEs get tied together and
pulled up.

If you want to configure from a CPU, you'd use the slave parallel mode for
the first chip and slave serial for the second.  Again, see the manual for
the exact interconnects.

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

"Money is property; it is not speech."
-- Justice John Paul Stevens


Article: 20491
Subject: Re: xilinx
From: Jason.Wright@ericsson. (Jason T. Wright)
Date: Fri, 11 Feb 2000 17:26:15 GMT
Links: << >>  << T >>  << A >>
On Fri, 11 Feb 2000 15:41:36 GMT, elynum@my-deja.com wrote:

>How would I go about programming 2 xilinx fpga's on a single board?
>Would I need 2 separate EEPROM chips(ATMEl) or just one?  How would
>I go about doing it with a microprocessor 8051 or 860?  What would I
>need to do this?
>
>
>Sent via Deja.com http://www.deja.com/

It depends on your needs; there are lots of ways to do it.  If your fpgas
are small, you can use one sufficiently large serial (EE)PROM; the first
fpga in series with the other(s) will pass on the data after it has taken
its configuration information.  I've done this in the past where I had ~10
fpgas on one board.  (I had to have several PROMs, but the whole deal was
daisy-chained.)

I haven't used the parallel mode, but I'm sure Xilinx has an application
note on their web site to cover programming via microprocessor.

Jason

Article: 20492
Subject: fpga
From: elynum@my-deja.com
Date: Fri, 11 Feb 2000 19:03:34 GMT
Links: << >>  << T >>  << A >>
Thanks, guys!
What would the benefits be to using a serial eeprom over an
microprocessor or vice versa to program the fpgas?

Sent via Deja.com http://www.deja.com/

Article: 20493
Subject: Re: xilinx
From: elynum@my-deja.com
Date: Fri, 11 Feb 2000 19:37:22 GMT
Links: << >>  << T >>  << A >>
Thanks, guys!
What would the benefits be to using a serial eeprom over an
microprocessor or vice versa to program the fpgas?

In article <38a4455e.1374478796@cnn.exu.ericsson.se>,
Jason.Wright@ericsson. (Jason T. Wright) wrote:
> On Fri, 11 Feb 2000 15:41:36 GMT, elynum@my-deja.com wrote:
>
> >How would I go about programming 2 xilinx fpga's on a single board?
> >Would I need 2 separate EEPROM chips(ATMEl) or just one?  How would
> >I go about doing it with a microprocessor 8051 or 860?  What would I
> >need to do this?
> >
> >
> >Sent via Deja.com http://www.deja.com/
>
> It depends on your needs; there are lots of ways to do it.  If your
fpgas
> are small, you can use one sufficiently large serial (EE)PROM; the
first
> fpga in series with the other(s) will pass on the data after it has
taken
> its configuration information.  I've done this in the past where I
> fpgas on one board.  (I had to have several PROMs, but the whole deal
was
> daisy-chained.)
>
> I haven't used the parallel mode, but I'm sure Xilinx has an
application
> note on their web site to cover programming via microprocessor.
>
> Jason
>

Sent via Deja.com http://www.deja.com/

Article: 20494
Subject: Re: Altera vs Cypress?
From: "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Fri, 11 Feb 2000 20:40:32 +0100
Links: << >>  << T >>  << A >>
Hi,

"Geoffrey G. Rochat" <geoff@pkworks.com> schrieb im Newsbeitrag news:8806th$eaa$1@news.kersur.net...

...
> I tried an early Verilog/VHDL compiler for Max+Plus II from
> Altera several years ago, but at the time it was Not Yet Ready For
> Production.  Things may have changed, but I've not checked.

We are using the VHDL Entry of Max+PLUSII for our designs and
ALTERA's support for VHDL has been extended, but their support
of the VHDL standard has lacks. Some contructs are not usable, so you
have to programm sometimes a workaround.
My latest information is, that ALTERA is doing some renew of their
VHDL tool with better implementation of the IEEE standards.

Greetings from Germany, Carlhermann


Article: 20495
Subject: Re: Master/Serial mode for Virtex
From: a@z.com
Date: Fri, 11 Feb 2000 14:50:00 -0500
Links: << >>  << T >>  << A >>
Hi Tom,

If I understand well your problem all your FPGAs reequire the same bitstream. In
this case you do not have to daisychain them. The FPGA with PROM should be in
master serial mode, all others in slave serial mode. Connect all FPGA INIT pins
together and to the reset pin of XC1800 (add a 4.7K pullup resistor). All PRGM
pins should be tied together (probably to your board master reset). All slave
FPGA CCLK pins and the serial PROM CCLK pin should be tied to the master FPGA
CCLK pin. All FPGA DIN pins (including the master) should be connected to the
serial PROM DOUT pin. The master FPGA DONE pin should be connected to the serial
PROM CE (and another 4.7K pullup resistor). In this case you do not have to tie
all DONE pins together - if you connect an LED and a current limiting resistor to
VCC for each DONE pin you will have an indicator of successful configuration for
each FPGA. You need then only four signals between boards (PRGM, DONE, CCLK and
DIN). The only drawback of this solution is that after configuration DIN and INIT
pins become general purpose I/Os that have limited use because they are connected
between all FPGAs.

This is an unorthodox way to configure multiple identical FPGAs from a singel
serial PROM and is not described in the Xilinx DataBook.

You do not need (or want) a socket for the serial PROM.

Regards,

Catalin

Tom McLaughlin wrote:

> Excellent description.....I wish you would write an app note on
> this.....yeah, I've seen the Xilinx app notes, but they are a bit
> criptic...at least for me anyway.
>
> Perhaps I didn't describe our design clearly as the responses seemed to
> assume we were daisy chaining the FPGAs together.  We are not....at least by
> my definition of daisy chaining.  For example, on the PROM board we will have
> a PROM that contains a bitstream for the XBAR FPGA only.  There are 9 XBAR
> FPGAs all on different boards.  So, we want to program these in parallel with
> one being the master and the other 8 being slaves.  If I understand the posts
> correctly, INIT and DONE do need to be connected on the slaves as well as the
> master.  We will do this same thing with several other FPGAs and are trying
> to figure out how many signals will be traveling down the backplane.  If we
> could get away with not sending INIT and DONE to the slaves, it would be
> best, but I guess not.
>
> We are hoping to use the 1800 series proms from Xilinx, use the JTAG
> interface to program the PROMs and kick off the config cycle.  This way we
> don't have to socket the PROMs and don't have to pull the boards out when
> changing the bitstreams.  Is this nuts or what....probably we should socket
> the PROMs just in case.
>
> Any more thoughts???  Thanks again,
> Tom


Article: 20496
Subject: Re: Spartan and timing analyzer: clock nets using non-dedicated resources
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 11 Feb 2000 21:35:08 +0100
Links: << >>  << T >>  << A >>
"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes:

> Had the Spartan-II been available six months ago when I started down this
> route, I would've chosen it!  OK, you just have to add that other voltage
> regulator.  That would make three power supplies on the board!

Only three? Let me know when you have 5V, 3.3V, 2.5V, 2.05V, 1.8V and
some +/- 12V...

Homann
--
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 20497
Subject: Re: Master/Serial mode for Virtex
From: Tom McLaughlin <tomm@arl.wustl.edu>
Date: Fri, 11 Feb 2000 14:43:19 -0600
Links: << >>  << T >>  << A >>
Catlin,
Thanks for spelling it out for me.  I got this idea from the Xilinx app note,
"XC1800 series of in-system programmable configuration PROMs v1.3."  On page 10 of
the app note in figure 5(a) it shows master mode configuration.   It also shows that
data line and cclk line going to "Optional Slave FPGAs with Identical
configurations."  It doesn't show the other signal connections to the slave FPGAs
this is where my confusion started.

Now, if you look at the app note, "Virtex FPGA series configuration and readback,"
it only shows the master/slave configuration with the FPGAs daisy chained and in
this case DONE, PROGRAM, INIT etc are all tied together.

Anyway, I think I understand now.

Thank you again for all the help.  Sometimes it's better to talk these things out
with someone rather than reading the app notes over and over.

Tom


Article: 20498
Subject: A FPGA hickup
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 11 Feb 2000 21:58:59 +0100
Links: << >>  << T >>  << A >>

Hello,

One of the FPGA we are using (Xilinx, XCV300) sometimes has a small
hickup. I would like to invite your opinion on where I should look
first.

The Design:

A memory controller unit that fetches a packet from the SRAM, feeeds
the apcket into a FIFO. The last byte of the packet is marked with a
special bit. Ojn the others side of the FIFO a packet processor
massages every byte, and puts them back into another FIFO, the last
byte still marked. The memory controller then outputs the result to the memory
again.

The problem:

On _some_ boards, in _elevated temperature_, a problem occur _after a
while_. The output data gets out of sync with the input data, i.e. it
is stored in the buffer that belongs to the output buffer of the
_next_ input packet. This out of synch then continues.

Where to start looking? We suspect an erroneus flag in the FIFO, so
that an extra packet delimiter is inserted in output FIFO.

Some extra info:
Synchronous design, all flops and FIFO on rising edge only.
STA suggest 45 Mhz max freq., but we only run at 33 MHz.
STA reports 96% covered by constraints.
The packet processing half of the design can be with another, similar
entity, and then the problem disappear.
Simulation shows no problem, even after P&R and with SDF.

What do you think? A problem with the part going out of spec? or is it
our VHDL-code that hides some ugly stuff?

Homann
--
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se


Article: 20499
Subject: Re: Master/Serial mode for Virtex
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 11 Feb 2000 13:39:09 -0800
Links: << >>  << T >>  << A >>


Tom McLaughlin wrote:

>   We know that CCLK and DATA have to go to the slaves, but:
>
> 1) Does DONE of the slaves have to be connected?

Yes. XC4000 has a length count at the head of the bitstream, which makes
sure that all devices in a chain become active together.
In a Virtex chain, this same result is achieved by tying all the ( open
drain ) DONE pins together, so the devices become active when the last one
in the chain is ready. DONE is a more important signal in Virtex than it
was in XC4000.

>
> 2) Does INIT of the slaves have to be connected?

Yes, and also to the RESET input of the SPROM.
INIT being Low indicates that the device is not ready to receive CCLK ( or
will not generate CCLK, if a master). It indicates housekeeping and
"housecleaning" activities, like sequential clear of the configuration
store.
As an input, it allows other devices ( by pulling low) to stop the master
from starting CCLK.
As SPROM reset input, it keeps the SPROM reset until the last moment, right
before the beginning of configuration. This avoids any screw-ups even when
Vcc behaves in an erratic way.

>
>
> In one diagram, INIT is connected to all of the devices connected and in
> another only the master.

should be to all devices in the chain, if you really want to be safe.

>
>
> I think we can just put pullups on the DONE signals of the slaves???

One pull-up is enough, but with Virtex you *have* to tie DONEs together (
with XC4000 there is no need )

>
>
> Can someone explain why INIT is a bidirectional signal???

I just did that above.

>
>
> Thanks for the help...anyone done this before???

Yes, your design is not that exotic.
I would, however, suggest to take a careful look at the -potentially very
long- CCLK distribution networks. It *IS* a clock input, and as such very (
*VERY* ) sensitive to double-clocking. Many, if not most, configuration
problems are due to reflections on unterminated and sloppily routed CCLK
line. The driver rise/fall time may be very fast, so use a fast scope...

Peter Alfke, Xilinx Applications