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 60800

Article: 60800
Subject: Re: Synchronous counter enable pulse length
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 22 Sep 2003 17:32:31 -0700
Links: << >>  << T >>  << A >>
With all due respect, I have a different explanation of hold time. It is
based on the mismatch between data and clock delay in the master latch:
If the data delay is longer than the clock delay, there is a set-up
time, but no hold time ( negative hold time)
If the clock delay is longer than the data delay, there is a hold time
requirement, but no set-up time.

The difference between data and clock delay moves the data capture
window. For a given circuit, temperature and voltage, this window is
extremely small ( see the metastability tests, which demonstrate a
sub-femtosecond window).
For reliable operation, the manufacturer specifies a worst-case window
of set-up + hold time.
All smart chip manufacturers try to err on the side of zero or negative
hold time, and accept the corresponding larger set-up time.
An unduely large set-up time sacrifices max clock rate. 
A positive hold time can mean unreliable operation at any speed.  :-(

Peter Alfke

Andrew Paule wrote:
> 
> Hold time is a quantum statistical thing - thermal trip of a balanced
> pair.  Been through this in this newgroup before.
> 
> Andrew
> 
> Glen Herrmannsfeldt wrote:
> 
> >"Tom Derham" <tderham@NOSPAM.ee.ucl.ac.uk> wrote in message
> >news:bkn1gm$d00$1@uns-a.ucl.ac.uk...
> >
> >
> >>I am using one counter to trigger a second counter.
> >>The first counter is loadable but typically runs for a long time ('count'
> >>
> >>
> >is
> >
> >
> >>28 bit).
> >>This counter keeps running, and each time it terminates, produces a pulse.
> >>This pulse is used to trigger the second counter, which typically runs for
> >>much less time ('count' is 8 bit).  This counter produces output 1 while
> >>
> >>
> >it
> >
> >
> >>is counting, then returns to 0 until it is retriggered by the pulse from
> >>
> >>
> >the
> >
> >
> >>first counter.
> >>The whole design is synchronous (running of a single clock at 100 MHz),
> >>using Webpack on Spartan IIE.
> >>
> >>Question: how long must the pulse from the first clock be, to ensure that
> >>
> >>
> >it
> >
> >
> >>triggers the second clock?  As I see it, if it is one clock cycle long,
> >>
> >>
> >then
> >
> >
> >>the second clock should trigger on the next clock rising edge (providing
> >>
> >>
> >the
> >
> >
> >>sum of clock propagation and the 2nd clock flip-flop setup is less than
> >>
> >>
> >one
> >
> >
> >>clock cycle)... but functionally the pulse will fall back at the moment it
> >>is triggered (one cycle later), so will only work if the hold time of the
> >>flip-flop is less than the clock propagation.
> >>Is this safe?  Does the pulse need to be longer?  Will the simulation
> >>
> >>
> >tools
> >
> >
> >>realise if there is a problem here?
> >>
> >>
> >
> >The problem should be exactly the same as that in building the synchronous
> >counter in the first place.
> >
> >I still remember from many years ago, that the 74LS74 has 0 hold time, but
> >the 7474 has a positive hold time.  You can make T flip-flops by connecting
> >Qbar to D on a 74LS74, but not (reliably) on a 7474.  Most likely even one
> >level of logic in between would be enough, though.
> >
> >The LSB of a synchronous counter would normally have the shortest feedback
> >path.   That would be the first place to look.
> >
> >As I understand it, FPGA's are usually designed so that in a synchronous
> >design you don't have to worry about hold time, though possibly setup time.
> >It might be that it is not possible to make a feedback path short enough,
> >even if the FF itself has a positive hold time.
> >
> >Now, some people might design a synchronous counter with a clock input from
> >the TC pulse of another synchronous counter.  That would not qualify as
> >synchronous logic, and could cause timing problems.
> >
> >-- glen
> >
> >
> >
> >
> >
> >

Article: 60801
Subject: Re: LUT and Registers in Xilinx Virtex 2
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 23 Sep 2003 10:33:11 +1000
Links: << >>  << T >>  << A >>
On Mon, 22 Sep 2003 21:54:16 +0000, Julien Eyries
<NOeyries.SPAMjulien@wanadooPLEASE.fr> wrote:

>Hello all,
>
>     I have one question about usage of LUT and Registers in Xilinx 
>Virtex 2 FPGA:
>
>     if, inside a slice, the LUT is consumed by some logic product, but 
>not the corresponding register, is this register available for other use
>(for example, registering signal coming from an other slice) ?  or is it
>disabled for the whole design ? does it depend on the compilation tool ?

It is available for other purposes.  Look at the picture of the
internals of a slice in the V2 data sheet.

If you are using less than 99% of the slices in the FPGA, map (which
is responsible for assigning logic to slices) will not put unrelated
LUTs and FFs into the same slice.
(See the map report for the amount of "unrelated logic packing".)
This explains why you can keep adding logic to your design, but the
slice utilisation stays at 99%.
Map tries to avoid unrelated logic packing because this tends to make
the later placement pass much more difficult.

Does this waste slices?  Sure, but what else are you going to do with
them?

Regards,
Allan.

Article: 60802
Subject: Re: Synchronous counter enable pulse length
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Tue, 23 Sep 2003 01:37:23 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F6F949F.E7846BD0@xilinx.com...
> With all due respect, I have a different explanation of hold time. It is
> based on the mismatch between data and clock delay in the master latch:
> If the data delay is longer than the clock delay, there is a set-up
> time, but no hold time ( negative hold time)
> If the clock delay is longer than the data delay, there is a hold time
> requirement, but no set-up time.
>
> The difference between data and clock delay moves the data capture
> window. For a given circuit, temperature and voltage, this window is
> extremely small ( see the metastability tests, which demonstrate a
> sub-femtosecond window).
> For reliable operation, the manufacturer specifies a worst-case window
> of set-up + hold time.
> All smart chip manufacturers try to err on the side of zero or negative
> hold time, and accept the corresponding larger set-up time.
> An unduely large set-up time sacrifices max clock rate.
> A positive hold time can mean unreliable operation at any speed.  :-(

I don't know that it was every explained why, but there have been
descriptions of the Cray-1 that included PC board traces taking extra long
paths, like zig-zags, to lengthen the propagation time.  It may have been to
match hold time.

-- glen



Article: 60803
Subject: Re: Synchronous counter enable pulse length
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Tue, 23 Sep 2003 01:43:32 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F6F9240.E1B74AB5@xilinx.com...
> Here are some practical points.
> For all but the most extremely fast applications ( say up to 200 MHz),
> synchronous counters are built using a global clock, and the bult-in
> free ripple carry structure, which of course determines a max frequency
> (where the ripple carry can still meet the set-up time requirements of
> the MSB.) Decoding TC can be quite tricky, that's why I suggested the
> digital differentiator which actually detects TC+1.

Maybe I misunderstood the application.  I had thought it was a divide by N
counter, where at some count value the counter is reloaded with the initial
value, and at the same time the second counter is started.

Now that I think about it, you should get the carry out from the MSB when
the counter is about to wrap.  That would seem easier than detecting other
values, and can be used as the load input for both.

-- glen



Article: 60804
Subject: Re: Xilinx S3 I/O robustness question
From: symon_brewer@hotmail.com (Symon)
Date: 22 Sep 2003 18:55:40 -0700
Links: << >>  << T >>  << A >>
Hi Austin,
       Agreed, the simulation is best way! My fag-packet calculation
was a worst case scenario, but still didn't exceed the specification.
Just wanted to confirm to myself there's no problem at the driver end,
and that this talk of using 3V VCCO instead of 3.3V was not needed to
be heeded! (At least for driver pin reasons.)
       I imagine your simulation gets a lower value for the reflection
amplitude because the IBIS model includes rise time information and
chip capacitance, rather than variation of the transistors' impedance.
(But I'm willing to be shot down in flames!!) My calculation assumed
instant (worst case) rise time. How long was your lossless t-line? Was
the flight time longer than the rise time of the signal? (Time for
signal travel is about 180ps/in, typically.)
       So, thanks for doing the simulation, I don't suppose you'd
publish the results just to put this one to bed for good?
            cheers, Syms


Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F6F5B7D.7059DDE5@xilinx.com>...
> Symon,
> 
> As if often the case, if you do not run a simulation, you will not get results that are
> even close to the truth (by guessing at what is happening).
> 
> With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back
> at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx).
> 
> Why does this not scale exactly as you state?  Because the ON resistance of the
> transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground.
> 
> So, unless you simulate the actual circuit, you will not get the actual result.
> 
> Austin
> 
> Symon wrote:
> 
> > Hi Peter,
> >       If the pin has 10 Ohms of drive impedance the initial sent pulse
> > will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
> > Ohms driver drives a 50 Ohm line. The reflected signal from the
> > unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
> > then increases the voltage at the pin to 3.667, as it's driven from 50
> > Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
> > absolute maximum rating of 3.75V. Hooray!
> >       As you say, this calculation disregards the attenuation due to
> > the trace propagation function, which will further reduce the
> > amplitude of the pulse as it travels back and forth down the
> > transmission line(pcb trace). This is caused by skin effect and stuff.
> > I guess you could also reduce the drive strength of the pin from the
> > default 12mA, to increase the source impedance.
> >        The receiver pin is the one that gets the big hit.
> >         cheers, Symon.
> >

Article: 60805
Subject: USB 1.1/2.0 Implementation
From: "SneakerNet" <nospam@nospam.org>
Date: Tue, 23 Sep 2003 15:01:35 +1200
Links: << >>  << T >>  << A >>
Hi All

Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in Altera
Device. If yes, can you pls start me off. I'm not able to make any progress
in this. I have found couple of sites in ths area, but always end towards a
brick wall.

Help Pls

Cheerio



Article: 60806
Subject: Re: Xilinx S3 I/O robustness question
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 23 Sep 2003 05:26:25 -0000
Links: << >>  << T >>  << A >>
>       The receiver pin is the one that gets the big hit.

So how bad is that hit?  How good are the protection diodes?

If the clamp diodes are any good they will reduce the reflection
and make things easier back at the transmitter.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 60807
Subject: Re: Synchronous counter enable pulse length
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 23 Sep 2003 05:36:32 -0000
Links: << >>  << T >>  << A >>
>All smart chip manufacturers try to err on the side of zero or negative
>hold time, and accept the corresponding larger set-up time.

Is there anything in the physics that encourages this?

My reading is that it simplifies the software.  If the
hardware guys will promise that the prop time is
enough to cover the hold time plus clock skew, then
the software doesn't have to check that case.

>An unduely large set-up time sacrifices max clock rate. 
>A positive hold time can mean unreliable operation at any speed.  :-(

Only if the software doesn't check for that case.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 60808
Subject: DCM virtex 2 doesn't lose lock
From: "Bram van de Kerkhof" <bvdknospam@oce.nl>
Date: Tue, 23 Sep 2003 08:17:33 +0200
Links: << >>  << T >>  << A >>
Hi,

I have a design that transmits data trough a cable and sends the clock
along. At the receiver side
the clock is going trough a dcm when i disconnect the cable the dcm doesn't
lose his lock (somtimes it does).
there is some rubbisch in the hanging cable (status bit is toggling)

what could be the problem. the rubbisch in the cable  is not good enough to
filter a clock out of it. Even if
there is no rubbisch the lock doesn't dissapear (have measured it)

Yours Bram


--
==================================================
Bram van de Kerkhof

OCE-Technologies BV
Building 3N38

St. Urbanusweg 43,
Venlo, The Netherlands
P.O. Box 101, 5900 MA Venlo
==================================================
Direct dial : +31-77-359 2148
Fax           : +31-77-359 5473
==================================================
e-mail       : mailto:bvdk@oce.nl
==================================================
www        : http://www.oce.nl/
==================================================



Article: 60809
Subject: Re: Italy is out of FPGA world?
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Date: 22 Sep 2003 23:19:50 -0700
Links: << >>  << T >>  << A >>
"Valeria Dal Monte" <aaa@bbb.it> writes:

> Some days ago Xilinx did workshops in many european states.
> Why Italy was excluded?
> 

A few years ago Peter Alfke told me that Italy represents a rather
small share of the European market for Xilinx. I guess that's the reason...

-Arrigo

Article: 60810
Subject: Re: Xilinx Parallel Cable 4 (PC4) and Platform Flash JTAG
From: antti@case2000.com (Antti Lukats)
Date: 22 Sep 2003 23:35:05 -0700
Links: << >>  << T >>  << A >>
Chen Wei Tseng <chenwei.tseng@xilinx.com> wrote in message news:<bkn59c$ki52@cliff.xsj.xilinx.com>...
> Antti,
> 
> iMPACT does allow user to download, verify, get device ID via JTAG. For 
> other functions such as EXTEST, INTEST, etc, you can shift in such 
> instructions with iMPACT's Debug Chain functionality. This feature 
> allows you to move through the 16 TAP controller states and shift in TDI 
> data.
> 
> With 6.1i iMPACT you'll be able to genrate and program the Xilinx part 
> with SVF (via inbuild XSVF player function).
> 
> If iMPACT isn't detecting the Parallel Cable for you, please see Xilinx 
> solution 15742 for debugging tips and contact the Xilinx hotline support 
> for further issues.
> 
> Regards, Wei
> Xilinx Applications
> 
> Antti Lukats wrote:

Dear Xilinx Applications!

thank you for the answer, but it is no anser actually, - see
using ISE 5.2, if I want to play a STAPL file that programs a 2MB
Flash connected to a Xilinx FPGA how do I do it with Cable IV?
Answer is I CAN NOT.

With Cable III there there are no problems, I just execute the STAPL
with a STAPL player and its all done.

Your answer about using 'Debug Chain Functionality' is really really stupid!
As far as I can see it is only possible todo it in iteractive mode.
To programa 2MB flash, it takes maybe over 10,000,000,000 transactions
on JTAG port (depends on chain lenght) if I do it manually by clicking
on buttons in iMpact - ridiculuous.


if new iMpact allows SVF playback its a little bit help, but iMpact
is really really a nighmare (as others on this list have said also)

thanks for your time (well, you get paid for it)

antti lukats
PS my statement stays: Cable IV is not useable for Boundary Scan.

PPS if you now say I a stupid and should read iMpact manual, then
FYI I am not and I just did:

"bsdebug [-start] [-reset] [-stop] [-tms 0|1] [-tdi
0|1] [-tck <number>] [-loop <number>] :Executes the

Boundary-Scan Debug instruction which shifts in the instruction
and data values specified by -tms and -tdi."


There is no way to capture TDO !!!!! 
what means the debug chain batch command can not be used for boundary scan.

Article: 60811
Subject: Re: USB 1.1/2.0 Implementation
From: antti@case2000.com (Antti Lukats)
Date: 22 Sep 2003 23:37:03 -0700
Links: << >>  << T >>  << A >>
"SneakerNet" <nospam@nospam.org> wrote in message news:<fIObb.156268$JA5.3828849@news.xtra.co.nz>...
> Hi All
> 
> Has anyone successfully implemented USB 2.0 or USB 1.1 protocol in Altera
> Device. If yes, can you pls start me off. I'm not able to make any progress
> in this. I have found couple of sites in ths area, but always end towards a
> brick wall.

if you dont say what your problem is how could one help?
the USB cores available are working out of box for Xilinx, for altera
you need to change the technology dependant portions and it should
again work.

antti

Article: 60812
Subject: Re: Synchronous counter enable pulse length
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Tue, 23 Sep 2003 07:40:55 GMT
Links: << >>  << T >>  << A >>

"Hal Murray" <hmurray@suespammers.org> wrote in message
news:vmvmv083cu824@corp.supernews.com...
> >All smart chip manufacturers try to err on the side of zero or negative
> >hold time, and accept the corresponding larger set-up time.
>
> Is there anything in the physics that encourages this?

Before FPGA's, when gates and FF's were wired together, hold time would
limit what you could wire together.  My previous example, the common 7474
dual D flip-flop with the Qbar output to the D input would, technically
fail.  (I don't know if I ever tried it.)  74LS74 had a 0 hold time.

> My reading is that it simplifies the software.  If the
> hardware guys will promise that the prop time is
> enough to cover the hold time plus clock skew, then
> the software doesn't have to check that case.
>
> >An unduely large set-up time sacrifices max clock rate.
> >A positive hold time can mean unreliable operation at any speed.  :-(
>
> Only if the software doesn't check for that case.

Only if you can guarantee that the software check works for all voltages and
temperatures at which the device might run.

Ony might hope that they scale the same, but I don't know that it is
guaranteed.

-- glen



Article: 60813
Subject: Added Keyboard controller to C-NIT
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 23 Sep 2003 01:00:51 -0700
Links: << >>  << T >>  << A >>
I have added a keyboard controller to my soc implementation.

http://www.c-nit.net

Sumit

Article: 60814
Subject: FPGA RESEARCH FSK
From: haythamazmi@hotmail.com (H.Azmi)
Date: 23 Sep 2003 01:38:14 -0700
Links: << >>  << T >>  << A >>
Hi guyes
  If any body interested in FSK modem based on FPGA PLZ 
  contact me : www.hazmi.itgo.com 
  Thanks ,
  Haytham

Article: 60815
Subject: Re: Regarding XC6216
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 02:19:57 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3F6F1C81.16801DD9@xilinx.com>...
> My first answer is: look it up on google. You get 747 hits!
> Question: Do you need any more?
> The parts do not exist anymore, so why do you need the data sheet?
> 
> Peter Alfke, Xilinx
> 
> "H.Azmi" wrote:
> > 
> > Hi guyes ,
> >          Does any body have datasheet for XC6216 ?

Hi Peter,

there are people who would like to have XC2616, I actually tried
to buy XC6216 development board at ebay (Ray Andraka was selling)
but I was too late :(

as much as I know XC6216 is the only Xilinx device that has full public
bitstream documentation (or had at least) also for XC6216 there is
free JERC6K JBits system inclusive Java sources still downloadable
from xilinx download site :)

so there are historic and educational reasons to have XC6216, if
I would have that board would use it for P&R tool testing, as
bitstream is known and array is relativly simple.

antti

Article: 60816
Subject: Re: Using LUTs for array of coefficients
From: Tullio Grassi <tgrassi@cut_here.mail.cern.ch>
Date: Tue, 23 Sep 2003 11:39:32 +0200
Links: << >>  << T >>  << A >>
On 18 Sep 2003, Bob wrote:

> Hello Jake/Ray
> 
> I appreciate two esteemed people like yourselves offering me your
> advice.
> 
> I would rather infer than instantiate (if that doesn't sound too
> rude).
[cut]

I suspect that inferring vendor-specific embedded primitives
(like LUTs, RAM, etc) is one of the few situations where
logic simulation is not reliable, as the implementation
depends a lot on the translator.
At least I had problems with xilinx BRAM that I could
explain only in this way.
Try at least one post-PAR simulation to see if the
LUT behaves as you expect in all operating modes.

Tullio
Univ. of Maryland



Article: 60817
Subject: Re: Synchronous counter enable pulse length
From: Rene Tschaggelar <some@know.me>
Date: Tue, 23 Sep 2003 09:46:04 GMT
Links: << >>  << T >>  << A >>
John_H wrote:
> "Rene Tschaggelar" <some@know.me> wrote in message
> news:da916fbbcc79413230e067ade436a0d4@news.teranews.com...
> 
>>Tom Derham wrote:
>>
>>>[snip]
>>>Question: how long must the pulse from the first clock be, to ensure
> that it
>>>triggers the second clock?  As I see it, if it is one clock cycle long,
> then
>>>the second clock should trigger on the next clock rising edge (providing
> the
>>>sum of clock propagation and the 2nd clock flip-flop setup is less than
> one
>>>clock cycle)... but functionally the pulse will fall back at the moment
> it
>>>is triggered (one cycle later), so will only work if the hold time of
> the
>>>flip-flop is less than the clock propagation.
>>>Is this safe?  Does the pulse need to be longer?  Will the simulation
> tools
>>>realise if there is a problem here?
>>You can delay the output signal with another FF and 'OR' its input and
> output.
>>That gives you another clock cycle in length.
> 
> Rene, wouldn't this enable the second counter twice?


I'd run a simulation on that and only extend the pulse if required.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Article: 60818
Subject: Location constraint
From: Matthias =?iso-8859-1?Q?M=FCller?= <mur@iis.fhg.de>
Date: Tue, 23 Sep 2003 11:50:40 +0200
Links: << >>  << T >>  << A >>
Hello,
I'm working on a project with XC2V2000 and ISE4.2.
Does anyone know, if there is a location constraint to locate a SINGLE
PROCESS on a certain quadrant or slice-range?
Thank you,
Matthias


Article: 60819
Subject: PPC access to PROM using Virtex @ pro
From: ramnathanm@yahoo.com (Ram)
Date: 23 Sep 2003 03:54:11 -0700
Links: << >>  << T >>  << A >>
Hi, 
  I am trying to use the embedded ppc in Xilinx Virtex 2 pro FPGA to
reconfigure the same.
I have gone thro the embedded design applications , xapp 058, xapp503.
As I see, those applications had external processors, but what i am
trying to achieve is store  bit files in PROM , boot with a file ,
later, access the other file from PROM and reconfigure the entire
device.
It seems, System ACE Cf is a promising solution to this.
But I need help on how to interface PROM with PPC , I am having Xilinx
HW AFX prototye demo board, xc2vp4, ff672 -6 package.
the board has couple of 4MB PROM's which i need to access from PPC.
If not, i have one 8MB SRAM which can be configured using the EDK
tools.
To put it short, I am trying to load bit streams on the fly by
configuring PPC

I would appreciate any advice and help

Early thanks for the time spend to reply.
Ram
University of Oklahoma

Article: 60820
Subject: Re: Transistor count
From: "Simon Peacock" <nowhere@to.be.found>
Date: Tue, 23 Sep 2003 23:02:55 +1200
Links: << >>  << T >>  << A >>
You missed the point.. I'm the engineer who has to deal with his Boss
quoting specs which I know are out moded
was just mentioning the problem as I have come across this before.. You and
I both know that a single FPGA is far more reliable than 500 transistors..
Just sometimes the piece of paper is the piece of paper.. and unless you
find a standards organisation willing to certify a new, better method, you
get left with more paper ...then, of course, you have to convince my boss
:-)  but at the moment we usually don't both with reliability reports..
there are just usual design practices used to keep the reliability as high
as possible... like don't use a 5V cap on a 5V rail :-)
Am not designing for space or aircraft so I have that luxury.

Simon


"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F6F09E4.5865169E@xilinx.com...
> Simon,
>
> That is for the lazy folks:  if you know the reliability (from studies,
> manufacturers data, etc.) you can choose to replace the "count method"
with the
> real data (wow, what a concept!).
>
> The "count method" is there as a last resort, if there is no other way to
gauge
> reliability.  Once you see the count method numbers, it should send you
> screaming to get the real data.  The standards bodies know this, and
understand
> this, it is just that lazy engineers just keep filling out the forms as if
they
> were still designing in 1968 ....
>
> Our reliability group is happy to provide the latest and most up to date
> reliability information for completing these studies properly (per the
> standard).  Please make the request thru the hotline.
>
> Austin
>
> Simon Peacock wrote:
>
> > I think that's because one of the standards counts transistors in its
MTBF..
> > so a PAL is more reliable than an FPGA but less reliable than an HC00.
> >
> > Simon
> >
> > "Peter Alfke" <peter@xilinx.com> wrote in message
> > news:3F6B9895.CB08B483@xilinx.com...
> > > I think the answer is " more than 100 million, but less than 300
million".
> > >
> > > We are caught between embarrassment: "that's how many we need"  and
> > > pride: "that's how good we are, to be able to make and sell that many
> > > for a reasonable price".
> > >
> > > An then there still are some people who really and seriously (!) think
> > > they can calculate device reliability and MTBF from the total number
of
> > > transistors. These guys do not seem to die out, even though we have
told
> > > them, and proven to them, again and again, that such calculations are
> > > utter nonsense.
> > >
> > > So Ray is right, you would need another seven or eight fingers...
> > > Peter Alfke
> > > ========================
> > > Ray Andraka wrote:
> > > >
> > > > More than you can count on both hands and feet, even if you count in
> > binary
> > > > :-)
> > > >
> > > > Arnaldo Oliveira wrote:
> > > >
> > > > > Hi!
> > > > >
> > > > > Could someone tell me how many transistors are integrated on the
> > XC3S5000
> > > > > Spartan-3 device?
> > > > > Thank You.
> > > > > Arnaldo.
> > > > >
> > > > > --
> > > >
> > > > --
> > > > --Ray Andraka, P.E.
> > > > President, the Andraka Consulting Group, Inc.
> > > > 401/884-7930     Fax 401/884-7950
> > > > email ray@andraka.com
> > > > http://www.andraka.com
> > > >
> > > >  "They that give up essential liberty to obtain a little
> > > >   temporary safety deserve neither liberty nor safety."
> > > >                                           -Benjamin Franklin, 1759
>



Article: 60821
Subject: Re: PPC access to PROM using Virtex @ pro
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 05:55:52 -0700
Links: << >>  << T >>  << A >>
ramnathanm@yahoo.com (Ram) wrote in message news:<380c480e.0309230254.138b85@posting.google.com>...
> Hi, 
>   I am trying to use the embedded ppc in Xilinx Virtex 2 pro FPGA to
> reconfigure the same.

what you want is notreadily available
SystemACE CF is a real cool solution, but you cant use that 
the config PROM could theoretically be reprogrammed by the same FPGA it
does configure but this is a realy dangerous technic, if something goes
wrong then the system fully dead.

Atmel FPSLIC appnote descibes similar thing, the FPGA+CPU are booted
from config memory then the configuration memory is reprogrammed using
config interface (in that case I2C). then its rebooting with new
configuration. similar could theoretically work on Xilinx FGPA and config
but you would need to use JTAG interface to reprogram the platfrom flash.

as of reconfig from ram, etc, read the threads about partial reconfig.

antti

Article: 60822
Subject: Re: Added Keyboard controller to C-NIT
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 05:58:27 -0700
Links: << >>  << T >>  << A >>
do_not_reply_to_this_addr@yahoo.com (Sumit Gupta) wrote in message news:<ae680d56.0309230000.265514b4@posting.google.com>...
> I have added a keyboard controller to my soc implementation.
> 
> http://www.c-nit.net

download of cpu.v and soc.zip are bad links http: 404 not found
please fix

antti

Article: 60823
Subject: Re: Location constraint
From: antti@case2000.com (Antti Lukats)
Date: 23 Sep 2003 06:14:51 -0700
Links: << >>  << T >>  << A >>
Matthias Müller <mur@iis.fhg.de> wrote in message news:<3F701770.AD2A812@iis.fhg.de>...
> Hello,
> I'm working on a project with XC2V2000 and ISE4.2.
> Does anyone know, if there is a location constraint to locate a SINGLE
> PROCESS on a certain quadrant or slice-range?
> Thank you,
> Matthias

I guess you have to wrap the process into single module and constrain
that module

antti

Article: 60824
Subject: Re: Transistor count
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 23 Sep 2003 10:36:58 -0400
Links: << >>  << T >>  << A >>
Glen Herrmannsfeldt wrote:
> 
> "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
> news:3F6F09E4.5865169E@xilinx.com...
> > Simon,
> >
> > That is for the lazy folks:  if you know the reliability (from studies,
> > manufacturers data, etc.) you can choose to replace the "count method"
> with the
> > real data (wow, what a concept!).
> >
> > The "count method" is there as a last resort, if there is no other way to
> gauge
> > reliability.  Once you see the count method numbers, it should send you
> > screaming to get the real data.  The standards bodies know this, and
> understand
> > this, it is just that lazy engineers just keep filling out the forms as if
> they
> > were still designing in 1968 ....
> 
> There is a story I heard some years ago, related to statistical physics, but
> it should work for any statistics problem.  A person was told that the
> probability of a bomb being on an airplane was 1 in 1000, but the
> probability of two bombs was 1 in 1000000.  To be safe, he always brought
> his own bomb on the plane.   (I think those are the numbers in the story,
> which has no relation to any real planes or real bombs.)
> 
> The important thing in a large number of problems is statistical
> independence.   When all the transistors on a single chip are made at the
> same time, using the same process, the probability of one failing is not
> statistically independent of another failing.   A bad batch of any of the
> chemicals that go into the processing, various mechanical problems that
> could occur, or any number of other events tend to affect all the
> transistors on a chip equally.  Without statistical independence any count
> based method will fail, just like in the bomb story.

That would be true for some failure modes due to incorrect
construction.  But there is a very low failure rate due to "wear" of the
semiconductor.  This would include electro-migration, void migration and
a host of other effects I don't remember.  If you have a failure rate
per transistor for a given process, then counting transistors can be
applied to these failure modes.  The question is whether these modes are
significantly more or less likely to make the chip fail than other
external failure modes like the PSU overvolting or someone dropping a
hammer on the chip.  

-- 

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



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