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 64325

Article: 64325
Subject: Release of SPARK C-to-VHDL Parallelizing High Level Synthesis tool
From: gupt@hotmail.com (S Gupta)
Date: 28 Dec 2003 11:04:29 -0800
Links: << >>  << T >>  << A >>
We are pleased to announce the release of the SPARK parallelizing high-level
synthesis software tool developed at the Center for Embedded Computer Systems.
SPARK takes the behavior of an application specified in C as input
(with some restrictions) and produces register-transfer level (RTL) VHDL.
SPARK employs several parallelizing compiler, compiler, and high-level
synthesis transformations to generate a scheduled, resource bound data
path along with a FSM controller.  We have benchmarked SPARK on a range
of multimedia and image processing designs and also a case study with
an Intel design.

The download page is at:
http://www.cecs.uci.edu/~spark/download.shtml

This page has SPARK binaries for Solaris and Linux platforms, a User Manual,
and a Tutorial with a MPEG-1 player as an example.

See publications on the SPARK webpage for more details on our work:
http://www.cecs.uci.edu/~spark/publications.shtml

Sincerely

Sumit Gupta, Rajesh Gupta, Nikil Dutt, Alexandru Nicolau

http://www.cecs.uci.edu/~spark
Center for Embedded Computer Systems
University of California, Irvine and San Diego

Article: 64326
Subject: Xilinx Parallel cable
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 28 Dec 2003 12:24:15 -0800
Links: << >>  << T >>  << A >>
Hi

Is there is cheap source or alternative to Xilinx parallel cable ?

Also is it leagal to make my own cable (from the schemetic provided by
Xilinx) and sell it.

Thanks
Sumit

Article: 64327
Subject: Spartan3 prices again...
From: news@sulimma.de (Kolja Sulimma)
Date: 28 Dec 2003 13:57:27 -0800
Links: << >>  << T >>  << A >>
Sorry that I warm up this discussion again, but there was a thread a
while ago on FPGA pricing. Someone complained that he could not get
near the prices listet in the Xilinx press release.
It was concluded that the time factor ("end of 2004") was overlooked
and caused the confusion.

I just stumbled about this press release:
http://xilinx.com/prs_rls/silicon_spart/03141s3_nd.htm

It says:
"Xilinx is new offering Spartan-3 FPGAs with 1 million system gates
for under $12.00*,[...]"
and again a few paragraphs later
"The XC3S50, XC3S200, and XC3S400 Spartan-3 devices with 50,000,
200,000, and 400,000 system gates respectively are available for less
than $6.50*."

well, the footnote axplains that these prices are valid at the end of
2004, but the text says these devices "ARE AVAlLABLE FOR $6.50" and
Xilinx "IS OFFERING NOW FOR UNDER $12"
Does anyone besides me have the feeling that this is not the right
grammar to discribe a situation that is set one year in the future?
Maybe the confusion was intended by the author?

Kolja Sulimma

Article: 64328
Subject: Re: predictable timing for xilinx cpld?
From: guillerodriguez@terra.es (guille)
Date: 28 Dec 2003 14:03:28 -0800
Links: << >>  << T >>  << A >>
Hi Peter,

Thanks for your valuable explanation. Some comments below.

palfke@earthlink.net (Peter Alfke) wrote in message news:<e9ba0b8.0312271425.1639a8ed@posting.google.com>...
> Guillermo, you are concerned about what we call "tracking".
> Almost all timing specs are guaranteed max values.
> The min time is not specified, and a conscientious engineer might be
> tempted to assume zero.
> In reality, it is impossible for a small piece of silicon to be
> simultaneously slow and ultra-fast.

I understand. I just picked 0 ns for lack of a better estimation --
like
the 70% factor you mention below.

> Years ago, I defined a tracking factor: If any parameter is actually
> at its max value (it cannot be any longer), then all other timing
> parameters are between 70% and 100% of their guaranteed max values.
> But if the chip is inherently fast, and is cold, and has high Vcc,
> then all delays will be short, but the above relationship still holds:
> They all track with a max 30% error between them.

I see. That is very useful to know, but even then, wouldn't this mean
that the 5.5 ns value listed in the datasheet is not completely
correct?
i.e. in the Tsu1 calculation, and assuming a worst case scenario, Tin,
Tlogi1 and Tsui would be at their maximum values and Tgck would be 70%
of its maximum value, which would yield:

Tsu1 = 3.3 + 2.5 + 1 - 0.7 * 1.3 = min 5.9 ns approx.

Is this right?

> 
> This method of calculating was unchallenged until recently, when some
> of the FPGA parameters started using soghisticated compensation
> techniques ( like in the DCM) and hardly changed at all, while the
> traditional delays showed their ususal temperature dependence ( +0.35%
> for ever degree C) and voltage dependence ( 1% faster for every 1%
> increse in Vcc ).

So this would mean that the above would not be valid anymore? In this
case, what would be the right thing to do? Should I go back to the 0
ns assumption for all values for which there's no guaranteed minimum?
Or
is there a better way to do it?

> 
> These things cannot be guaranteed in writing, since there always are
> exceptions (metal delays are more stable than transistor delays, etc),
> but they can serve as a guideline. And they have done that over the
> past fifteen years. (You can find these explanations in old Xilinx
> data books prior to 1994.)

Yes, I understand completely.. However I still need to derive some
timing calculations for signals that go through a cpld. At this moment
I don't even know if I can use the external parameters listed in the
datasheet, due to my concerns expressed above. Can you recommend an
approach to this problem?

Your help is appreciated!

Guillermo Rodriguez

> 
> Peter Alfke, Xilinx Applications.
> ========================================
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > Hi Dennis,
> > 
> > Dennis McCrohan <dennis.mccrohan@xilinx.com> wrote in message news:<3FE33379.AD00F1DE@xilinx.com>...
> > > > I'm looking at a design based on a xilinx XCR3256XL cpld. Signals come
> > > > from different devices (e.g. a CPU), go through the cpld, and end on
> > > > the system's expansion bus. I need to derive the timings for all the
> > > > signals on this expansion bus, which depend on the timing of the
> > > > signals at the CPU and on the prop. delays of the cpld.
> > > >
> > > > The datasheet says this device has "predictable and deterministic
> > > > timing". What does this mean exactly?
> > > 
> > > Umm, hmm, I think that may be marketing-speak for "not subject to
> > > variations in routing (wire) delay like those FPGAs".
> > 
> > oops.. then my approach to timing calculations will be wrong..
> > 
> > > > For example, take the pad to pad
> > > > delay, which is specified to be 10 ns for the -10 part. Is this 10 ns
> > > > a maximum value,
> > > 
> > > Yup. See below.
> > > 
> > > > or can I rely in the delay being 10 ns?
> > > >
> > > > e.g. take the following signal from the CPU:
> > > >
> > > > CE0# assert delay from rising edge of CLK:  min 2 ns, typ 8 ns, max 10
> > > > ns.
> > > >
> > > > The CLK signal does not go through the cpld, but CE0# does. The timing
> > > > report indeed says propagation delay for CE0# is 10 ns. Can I assume
> > > > that CE0# at the expansion bus has min 12 ns, typ 18 ns, max 20 ns
> > > > relative to the rising edge of CLK? Or are the figures specified by
> > > > xilinx _maximum_ times only?
> > > >
> > > > Thanks.
> > > 
> > > Unless otherwise noted the times shown in the timing report or datahseet
> > > for our CPLDs would be worst-case values. That means the lowest allowable
> > > operating voltage, hottest allowable temperature, and a device built on a
> > > Friday before a holiday ;-)
>  
> > :)
>  
> > > . Assuming that you stay within the allowable
> > > operating conditions, no device that you get from Xilinx should exhibit
> > > worse delay behavior than this, and the vast majority will be faster.
> > 
> > I see.
> > 
> > But then there's something I don't quite understand. I looked at white
> > paper 122 from Xilinx, ("Using the CoolRunner XPLA3 Timing Model"). There
> > are several examples on how to derive the 'external' timing parameters
> > from the internal parameters. All of these examples seem to assume the
> > internal timing parameters are always fixed values. Take for example, Tsu
> > (setup time for data at pad to clock at pad). This is derived as follows:
> > 
> > Tsu = Tin + Tlogi + Tsui - Tgck
> > 
> > Tin   = Input buffer delay (for data)
> > Tlogi = Internal logic delay
> > Tsui  = Internal register setup time
> > Tgck  = Global clock buffer delay
> > 
> > 
> > The XCR3256XL datasheet says that for a -10 device:
> > 
> > Tin    = max 3.3 ns
> > Tlogi1 = max 2.5 ns (assuming single p-term)
> > Tsui   = min 1.0 ns
> > Tgck   = max 1.3 ns
> > 
> > And indeed the same datasheet says that for 1 p-term, Tsu is:
> > 
> > Tsu1 = 3.3 + 2.5 + 1 - 1.3 = min 5.5 ns
> > 
> > 
> > Now my question is this: If we must take all the internal timing values
> > as worst case values, then the above equation could be wrong. For example,
> > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > 
> > Actually, the correct worst case equation should then be something like
> > this:
> > 
> > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > 
> > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > 
> > Isn't this correct?
> > 
> > Thanks for your help!
> > 
> > Guillermo Rodriguez

Article: 64329
Subject: Re: predictable timing for xilinx cpld?
From: guillerodriguez@terra.es (guille)
Date: 28 Dec 2003 14:13:07 -0800
Links: << >>  << T >>  << A >>
Andy,

Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > Now my question is this: If we must take all the internal timing values
> > as worst case values, then the above equation could be wrong. For example,
> > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > 
> > Actually, the correct worst case equation should then be something like
> > this:
> > 
> > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > 
> > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > 
> > Isn't this correct?
> 
> Perhaps it would be a worthwhile exercise to code up your CPLD, let
> the tools have at it, and see what the static timing analyzer says?

Not a problem, the design is already fully implemented and I do have
the output from the timing analyzer.

However this doesn't help too much, the analyzer internally just uses
the same procedure which is outlined in whitepaper 122 from Xilinx --
i.e. all timings are derived from the internal timing parameters, using
the maximum values for all parameters as listed in the datasheet.

This is how it is documented to work and I've experimentally verified
that it is indeed what it does.

Guillermo Rodriguez

Article: 64330
Subject: Re: Spartan3 prices again...
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Mon, 29 Dec 2003 01:35:14 GMT
Links: << >>  << T >>  << A >>
Hi - 

On 28 Dec 2003 13:57:27 -0800, news@sulimma.de (Kolja Sulimma) wrote:

>Sorry that I warm up this discussion again, but there was a thread a
>while ago on FPGA pricing. Someone complained that he could not get
>near the prices listet in the Xilinx press release.
>It was concluded that the time factor ("end of 2004") was overlooked
>and caused the confusion.

(other stuff snipped)

At best, a press release will give you a (very) rough idea of what
you'll actually end up paying for a part.  Relying on this kind of
information is one step above reading the entrails of chickens.  And
on occasion, I've had *better* results with the chickens.  

If you think there's even a chance that you're going to be designing
in a certain component, get a formal price quote from the salesman,
rep, or distributor.  And if you can't get a quote, maybe you can't
get the part, either.

Bob Perlman
Cambrian Design Works



Article: 64331
Subject: How to use write flash on board?
From: "John" <305liuzg@163.net>
Date: Mon, 29 Dec 2003 13:00:21 +0800
Links: << >>  << T >>  << A >>
Hi,
I have a FPGA connected with a flash rom.
And I want to write data into flash using JTAG from PC.
What should I implement FPGA with? The JTAG state machine?
or others?
Would somebody tell me what to do or give me the example

Thanks and Regards



Article: 64332
Subject: Re: predictable timing for xilinx cpld?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 28 Dec 2003 22:07:07 -0800
Links: << >>  << T >>  << A >>
guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>...
> Andy,
> 
> Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > > Now my question is this: If we must take all the internal timing values
> > > as worst case values, then the above equation could be wrong. For example,
> > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > > 
> > > Actually, the correct worst case equation should then be something like
> > > this:
> > > 
> > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > > 
> > > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > > 
> > > Isn't this correct?
> > 
> > Perhaps it would be a worthwhile exercise to code up your CPLD, let
> > the tools have at it, and see what the static timing analyzer says?
> 
> Not a problem, the design is already fully implemented and I do have
> the output from the timing analyzer.
> 
> However this doesn't help too much, the analyzer internally just uses
> the same procedure which is outlined in whitepaper 122 from Xilinx --
> i.e. all timings are derived from the internal timing parameters, using
> the maximum values for all parameters as listed in the datasheet.
> 
> This is how it is documented to work and I've experimentally verified
> that it is indeed what it does.

So, then, what's your problem?

--a

Article: 64333
Subject: This design contains an RPM macro bm_0 which is to be automatically placed, but it contains TBUF elelements that are not allowed during automatic placement of RPMs?
From: "One Day & A Knight" <kelvin8157@hotmail.com>
Date: Mon, 29 Dec 2003 16:14:58 +0800
Links: << >>  << T >>  << A >>
Hi, there:

I want to know how to fix this kind of problem?


Phase 1.1
ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be
automatically placed, but it contains TBUF elelements that are not allowed
during automatic placement of RPMs.  You must either pick an absolute
   location for the macro using a LOC constraint, or remove the TBUF element
   from the macro.

ERROR:Place:205 - This design contains an RPM macro bm_1 which is to be
   automatically placed, but it contains TBUF elelements that are not
allowed
   during automatic placement of RPMs.  You must either pick an absolute
   location for the macro using a LOC constraint, or remove the TBUF element
   from the macro.

WARNING:Place:204 - Routed macros (nmc's) have been found in this design.
The
   placer will need to verify that routing does not attempt to use already
used
   resources every time these macros are moved.  This may significantly slow
   down run time.  If the macros are designed such that it is impossible to
   place the routed macros in a way that will cause the routing to overlap
then
   set the environment variable "PAR_NOMACROROUTECHECKING" and the placer
will
   run much faster.  The routing will still be checked at the end of the run
and
   if the same routing resourse is required by multiple macros then a fatal
   error will occur.





Article: 64334
Subject: Re: This design contains an RPM macro bm_0 which is to be automatically
From: Sean Durkin <23@iis.42.de>
Date: Mon, 29 Dec 2003 11:58:14 +0100
Links: << >>  << T >>  << A >>
One Day & A Knight wrote:

> Hi, there:
> I want to know how to fix this kind of problem?
> 
> Phase 1.1
> ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be
> automatically placed, but it contains TBUF elelements that are not allowed
> during automatic placement of RPMs.  You must either pick an absolute
>    location for the macro using a LOC constraint, or remove the TBUF element
>    from the macro.
It tells you right there: "You must pick an absolute location for the 
macro"...

Looks like you're using a bus macro here. Those will not be placed 
automatically, you have to position them manually with 
floorplanner/PACE. Or you can just put a corresponding location 
constraint into your .UCF, something like this:

INST "bm_0" LOC = "TBUF_X0Y0" ;

This would place the busmacro with the instance name "bm_0" in the lower 
left corner of the FPGA. Of course you have to do this for every 
instance, with different locations.

Where you have to put it depends on what you want to do with it. 
Usually, you use bus macros to communicate between two modules of a 
design, so you place the macro so it straddles the border between the 
two modules it's supposed to connect.

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Article: 64335
Subject: Re: This design contains an RPM macro bm_0 which is to be automatically placed, but it contains TBUF elelements that are not allowed during automatic placement of RPMs?
From: "A Day & A Knight" <kelvin8157@hotmail.com>
Date: Mon, 29 Dec 2003 21:08:44 +0800
Links: << >>  << T >>  << A >>
Thanks, Durkin.

However that is the thing I don't understand. In my UCF file I put
constraints like these in the UCF file.
1)   INST "bm_0" LOC = "TBUF_X0Y0" ;
2)   INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ;    # Since I use all four
pins.
I tried both cases but I always end up in this error 205, and Xilinx Answers
don't have this error :(

I have another question. How come the XST GUI's Properties ask for a .XCF
file? Is that similar
to .UCF? How do I compile my verilog codes with XST GUI while control the
bus-delimiter with
() instead of the default <>?

Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode,
the UCF is in NGDBuild?
Why so many exceptions and so much inconsistency in ISE 6.1! :(

In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command
line XST to make
sure that the bus delimiter is (), then in commandline to run the NGDBuild
with -uc my_top.ucf...then
return back to GUI to do MAP and P&R...

Only P&R doesn't work!

I think I need to try out the manual placement.

Best Regards,



"Sean Durkin" <23@iis.42.de> wrote in message news:3ff00882$1@news.fhg.de...
> One Day & A Knight wrote:
>
> > Hi, there:
> > I want to know how to fix this kind of problem?
> >
> > Phase 1.1
> > ERROR:Place:205 - This design contains an RPM macro bm_0 which is to be
> > automatically placed, but it contains TBUF elelements that are not
allowed
> > during automatic placement of RPMs.  You must either pick an absolute
> >    location for the macro using a LOC constraint, or remove the TBUF
element
> >    from the macro.
> It tells you right there: "You must pick an absolute location for the
> macro"...
>
> Looks like you're using a bus macro here. Those will not be placed
> automatically, you have to position them manually with
> floorplanner/PACE. Or you can just put a corresponding location
> constraint into your .UCF, something like this:
>
> INST "bm_0" LOC = "TBUF_X0Y0" ;
>
> This would place the busmacro with the instance name "bm_0" in the lower
> left corner of the FPGA. Of course you have to do this for every
> instance, with different locations.
>
> Where you have to put it depends on what you want to do with it.
> Usually, you use bus macros to communicate between two modules of a
> design, so you place the macro so it straddles the border between the
> two modules it's supposed to connect.
>
> --
> Sean Durkin
> Fraunhofer Institute for Integrated Circuits (IIS)
> Am Wolfsmantel 33, 91058 Erlangen, Germany
> http://www.iis.fraunhofer.de
>
> mailto:23@iis.42.de
> ([23 , 42] <=> [durkinsn , fraunhofer])



Article: 64336
Subject: Re: predictable timing for xilinx cpld?
From: guillerodriguez@terra.es (guille)
Date: 29 Dec 2003 05:42:36 -0800
Links: << >>  << T >>  << A >>
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312282207.39878411@posting.google.com>...
> guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312281413.4024503@posting.google.com>...
> > Andy,
> > 
> > Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0312271600.1594f237@posting.google.com>...
> > > guillerodriguez@terra.es (guille) wrote in message news:<5d891e95.0312270821.393d7580@posting.google.com>...
> > > > Now my question is this: If we must take all the internal timing values
> > > > as worst case values, then the above equation could be wrong. For example,
> > > > Tgck is listed as 1.3 ns max, but it could as well be lower... let's say
> > > > it turns out to be 0.3 ns under certain conditions. In that case Tsu1 might
> > > > need to be at least 6.5 ns under the same conditions, rather than 5.5 ns.
> > > > 
> > > > Actually, the correct worst case equation should then be something like
> > > > this:
> > > > 
> > > > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
> > > > 
> > > > With no known value for Tgck_min one would need to assume a minimum 0 ns
> > > > for this parameter, which would yield a worst case Tsu of 6.8 ns.
> > > > 
> > > > Isn't this correct?
> > > 
> > > Perhaps it would be a worthwhile exercise to code up your CPLD, let
> > > the tools have at it, and see what the static timing analyzer says?
> > 
> > Not a problem, the design is already fully implemented and I do have
> > the output from the timing analyzer.
> > 
> > However this doesn't help too much, the analyzer internally just uses
> > the same procedure which is outlined in whitepaper 122 from Xilinx --
> > i.e. all timings are derived from the internal timing parameters, using
> > the maximum values for all parameters as listed in the datasheet.
> > 
> > This is how it is documented to work and I've experimentally verified
> > that it is indeed what it does.
> 
> So, then, what's your problem?

As I said in my first mail, the procedure outlined in whitepaper 122
always takes the maximum value for all internal parameters when deriving
other (external) parameters, which may not be correct in all situations.
See the comments from Peter Alfke too.

Since the analyzer internally just applies the same procedure outlined
in whitepaper 122, the timing report it produces doesn't help.

Guillermo Rodriguez

Article: 64337
Subject: Re: This design contains an RPM macro bm_0 which is to be automatically
From: Sean Durkin <23@iis.42.de>
Date: Mon, 29 Dec 2003 15:35:59 +0100
Links: << >>  << T >>  << A >>
A Day & A Knight wrote:

> Thanks, Durkin.
> However that is the thing I don't understand. In my UCF file I put
> constraints like these in the UCF file.
> 1)   INST "bm_0" LOC = "TBUF_X0Y0" ;
> 2)   INST "bm_0" LOC = "TBUF_X0Y0:TBUF_X0Y7" ;    # Since I use all four
> pins.
> I tried both cases but I always end up in this error 205, and Xilinx Answers
> don't have this error :(
Version 1) should suffice. For each macro there is one pin defined as 
the reference, and that pin is used to place the macro. All the other 
pins of the macro are then fixed, because the routing and placement is 
specified in the macro itself, relative to the reference pin.

Version 2) should give you an error, since TBUF_X0Y0:TBUF_X0Y7 is an 
ambiguous location, so that should not work at all, as I understand it.

Since you don't get an error other than 205 when using version 2, and it 
still says "RPM macro bm_0 which is to be AUTOMATICALLY placed", even 
though you have placed it manually in the .UCF, I suspect that ISE 
doesn't really use your .UCF-file at all.

How did you add the .UCF to your design? You should just add it as a 
source file (just like your verilog source codes), and assign it to your 
top-level design file when asked.

> I have another question. How come the XST GUI's Properties ask for a .XCF
> file? Is that similar  to .UCF?
The .XCF is for synthesis, the .UCF is for mapping and the place and 
route process. In the .XCF you can put special constraints for XST, like 
if it should optimize away equivalent registers, automatically add 
IO-buffers and things like that. The .XCF is for use with XST, 
exclusively and does not work with FPGA Express and other synthesis 
tools (at least as far as I know).

In the .UCF you put more global things, like which IOBs to use, timing 
constraints for your clock signals, area constraints for modules etc., 
i.e. things that relate to the implementation of your design, that is 
mapping, placing and routing. A .UCF can be used with tools from other 
vendoers as well.

> How do I compile my verilog codes with XST GUI while control the
> bus-delimiter with () instead of the default <>?
In Project Navigator, select your top-level design file, right-click on 
"Synthesize", and chose "Properties". After scrolling down (!) you can 
specify the "Bus delimiter" in the "Synthesis Options" tab.

> Also, how come in the GUI, the UCF&XCF is in XST, while in commandline mode,
> the UCF is in NGDBuild?
As I stated above, the .UCF should be added to the design just like your 
verilog source codes, not in the XST settings. It's possible that your 
.UCF is simply ignored when added in the XST settings, which would 
explain your problem.

> Why so many exceptions and so much inconsistency in ISE 6.1! :(
> In my procedure, I have only XST (ISE6.1.03) in my PC, so I used command
> line XST to make
> sure that the bus delimiter is (), then in commandline to run the NGDBuild
> with -uc my_top.ucf...then
> return back to GUI to do MAP and P&R...
> Only P&R doesn't work!
P&R needs a .PCF (physical constraints file) to work. This .PCF is 
generated automatically from your .UCF during mapping. Normally, par 
looks for a file named <your_design>.pcf or <your_design_map>.pcf in the 
working directory, and uses that automatically. If it's not there, it 
tries to place everything itself. I suspect that this is what happens in 
your case. Check and see if a .PCF file is generated somewhere along the 
way.

But I guess if you run the entire flow in the GUI (after changing the 
bus delimiter like described above), everything will work fine 
automatically.

-- 
Sean Durkin
Fraunhofer Institute for Integrated Circuits (IIS)
Am Wolfsmantel 33, 91058 Erlangen, Germany
http://www.iis.fraunhofer.de

mailto:23@iis.42.de
([23 , 42] <=> [durkinsn , fraunhofer])

Article: 64338
Subject: Re: pcix core in XC2VP7
From: Matthias =?iso-8859-1?Q?M=FCller?= <mur@iis.fhg.de>
Date: Mon, 29 Dec 2003 16:28:07 +0100
Links: << >>  << T >>  << A >>
Thank you!
Looks like any user I/O can be used with the pci-x standard.
Have you considered the XAPP653 for over- and undershoot handling?
Xilinx recommends to regulate Vcco to 3.0V for all banks with pci-x standard in order to keep
values within the maximum FPGA specification.

Matthias


Mark Schellhorn schrieb:

> Check out answer record #14965:
>
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14965
>
> The databook I have (older) mentioned some banking restrictions but it looks
> like they have disappeared with newer software.
>
> Make sure you obey the PCI-X trace length restrictions on the card. I would
> establish the orientation of your FPGA on the card and then choose a pinout that
>    lines up with the edge card pins. Worked for me.
>
>     Mark
>
> Matthias Müller wrote:
> > Hello,
> > I'm developing a pcix-card and I will use the PCIX-core from Xilinx in a
> > XC2VP7-5FF896 FPGA. Does anyone know if there is the need for using
> > special pins of the FPGA to connecet  the PCIX-signals to the
> > bus-connector. Or can I use any FPGA-pin for any PCIX-signal?
> > Thank you for answers!
> > Matthias Müller
> >
> > **************
> > Please remove the  *no*spam*  from my email-address, if you want to mail
> > to me!
> >

--
Matthias Müller
Fraunhofer Institut Integrierte Schaltungen  IIS
-Bildsensorik-
Am Wolfsmantel 33
D-91058 Erlangen
Tel:  +49 (0)9131-776-554
Fax:   +49 (0)9131-776-598
mailto:mur@iis.fhg.de        http://www.iis.fhg.de



Article: 64339
Subject: Re: predictable timing for xilinx cpld?
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 29 Dec 2003 18:04:25 -0000
Links: << >>  << T >>  << A >>
>As I said in my first mail, the procedure outlined in whitepaper 122
>always takes the maximum value for all internal parameters when deriving
>other (external) parameters, which may not be correct in all situations.
>See the comments from Peter Alfke too.

>Since the analyzer internally just applies the same procedure outlined
>in whitepaper 122, the timing report it produces doesn't help.

I think this is one of those cases where you have to read between
the lines a bit.

What are you trying to do?  Understand the data sheet or justify
running the chip slightly over spec?

Peter's 70% rule-of-thumb seems like a reasonable estimate.  So the
clock delay can't be much faster than worst case if the rest of the
parameters are all close to worst case.

What can they actually test?  They probably test what you really
want to know rather than the smaller pieces.  If you just want to
run the chip at full speed like everybody else, I'd just go for it.

If you are trying to cheat and push things a bit, please tell us more.

-- 
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: 64340
Subject: Re: LVPECL_33 to LVPECL_25 (virtex-II pro)
From: symon_brewer@hotmail.com (Symon)
Date: 29 Dec 2003 10:46:52 -0800
Links: << >>  << T >>  << A >>
James,
Check out the input common-mode range (Vicm) and differential input
voltage (Vidiff) for LVDSEXT_25. This should meet your requirements
depending on the spec of the LVPECL parts you're using.
Otherwise, you have to resort to level shifting resistors, or level
shifting parts, try Micrel, Maxim, OnSemi etc.
cheers mate, Syms.

"jicho" <jicho@it.co.kr> wrote in message news:<bsgm6j$q69$1@news.hananet.net>...
> Dear all,
> 
> I am trying to use differential LVPECL interface on Xilinx virtex-II pro
> device.
> 
> I have to connect some standard LVPECL(3.3V) signal to virtex-II pro device.
> But I know that Virtex-II Pro devices support only LVDS_25 and LVPECL_25.
> There is no problem with Spartan-IIE or Virtex-II device because they have a
> LVPECL_33 I/O.
> 
> I want to know how I connect between standard LVPECL(3.3V) signal and
> virtex-II pro LVPECL_25 signal in differential manner.
> 
> Could anybody give me some answer ?
> 
> Thanks,
> james.

Article: 64341
Subject: Re: Parallel Cable 4 & Linux
From: Larry Doolittle <ldoolitt@recycle.lbl.gov>
Date: Mon, 29 Dec 2003 19:08:11 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rudolf Usselmann wrote:
> 
> Also, in the answer records, it states the schematic for
> parallel cable 4 is unavailable because it is a "proprietary"
> design. This seems to me really nonsense, you guys make
> money with FPGAs not with cables. releasing the schematic
> will enable users to support them selves when you  guys
> can't. Could you please ask the appropriate people to
> reconsider this choice ?

If you open up the parallel cable 4, you will see it is
built with a big CPLD, so it is clearly a parallel-serial
converter (serializer).  The PC sends in bytes in a
normal "line printer" strobed mode, and the CPLD turns
that into the JTAG data stream.

That said, there's a lot of room for "innovation" (cough,
"problem solving" for us engineers, try telling that to
the lawyers) in how that transaction happens, especially
controlling the JTAG state machine before getting to the
bulk bit transfer mode.

If you can take the performance hit, I recommend you switch
back to Parallel Cable 3, for which Linux drivers are trivial
and widely published.  Also, I can put you in touch with
someone who made an "open source" USB-to-JTAG programmer,
out of an XC2S30 and an FT245B.  Schematics, FPGA code, and
software are published.  Linux drivers are provably possible,
but not demonstrated -- of course, Xilinx packaged software
will probably never support this device.  I personally have
access to one board.  

    - Larry

Article: 64342
Subject: Re: predictable timing for xilinx cpld?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 29 Dec 2003 11:13:07 -0800
Links: << >>  << T >>  << A >>
guille wrote:

 > Tsu_min = Tin_max + Tlogi_max + Tsui_max - Tgck_min
 >
 > With no known value for Tgck_min one would need to assume a minimum 0 ns
 > for this parameter, which would yield a worst case Tsu of 6.8 ns.


Consider using synchronous design techniques
and the fpga's global clock distribution network.

This will allow you to verify timing
without requiring any MIN specifications at all.

In fact, the place and route software
will do this "static timing analysis" for you.

  -- Mike Treseler


Article: 64343
Subject: A difference between VHDL sources working
From: "toomuch" <toomuch@poczta.onet.pl>
Date: Mon, 29 Dec 2003 21:21:55 +0100
Links: << >>  << T >>  << A >>
Hi

Can someone tell me if there is a defference between the following two VHDL
sources working:
1.
process
begin
  wait until C'event and C='1';
  if B='0' then
    Q<=B;
  else
    Q<= A;
  end if;
end process;

2.
process
begin
  if B='0' then
    wait until C'event and C='1';
    Q<=B;
  else
    wait until C'event and C='1';
    Q<=A;
  end if;
end process;


Simulation of this two processes gives different results. Does anybody know
why? Is there a specification discussing those cases?

Thanks for any help




Article: 64344
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Mon, 29 Dec 2003 21:56:13 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Alfke <palfke@earthlink.net> wrote:
: All Xilinx FPGAs have input hysteresis (Schmitt triggered inputs).
: Peter Alfke

Is this hysteresis spec'ed somewhere? 
For example, in ds001 (full Spartan II datasheet) I can't find any occurance
of "hyst".

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 64345
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Mon, 29 Dec 2003 15:34:06 -0800
Links: << >>  << T >>  << A >>
I also could not find the specification ( and there is a limited crew around in
these days).
But I know that the hysteresis depends on the I/O standard and the part family.

If you want to investigate, it's very simple:
Take the input and bring it out, inverted, on a pin that is not adjacent.
Then connect a large resistor from the output to the input ( 10 kilohm ) and
decouple the input to ground with a big capacitor ( 10 nF). Now you have an
oscillator, and the voltage on the input, (i.e. the capacitor) oscillates
between the two hysteresis points.
That's how them old folks used to build oscillators with a 7414...
Happy New Year!
Peter Alfke
==============================



Article: 64346
Subject: Re: A difference between VHDL sources working
From: David R Brooks <davebXXX@iinet.net.au>
Date: Tue, 30 Dec 2003 07:52:42 +0800
Links: << >>  << T >>  << A >>
It's apparent from the code:
Case 1 says "wait for clock, THEN test B and act accordingly"
Case 2 says "Test B, decide how to act, THEN wait for clock"

Also, Case A is synthesisable (being a register with a 2-input mux in
front), case B is probably not synthesisable (ie there is no hardware
equivalent).

"toomuch" <toomuch@poczta.onet.pl> wrote:

:Hi
:
:Can someone tell me if there is a defference between the following two VHDL
:sources working:
:1.
:process
:begin
:  wait until C'event and C='1';
:  if B='0' then
:    Q<=B;
:  else
:    Q<= A;
:  end if;
:end process;
:
:2.
:process
:begin
:  if B='0' then
:    wait until C'event and C='1';
:    Q<=B;
:  else
:    wait until C'event and C='1';
:    Q<=A;
:  end if;
:end process;
:
:
:Simulation of this two processes gives different results. Does anybody know
:why? Is there a specification discussing those cases?
:
:Thanks for any help
:
:


Article: 64347
Subject: Re: LVPECL_33 to LVPECL_25 (virtex-II pro)
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 30 Dec 2003 12:06:48 +1100
Links: << >>  << T >>  << A >>
On 29 Dec 2003 10:46:52 -0800, symon_brewer@hotmail.com (Symon) wrote:

>James,
>Check out the input common-mode range (Vicm) and differential input
>voltage (Vidiff) for LVDSEXT_25. This should meet your requirements
>depending on the spec of the LVPECL parts you're using.
>Otherwise, you have to resort to level shifting resistors, or level
>shifting parts, try Micrel, Maxim, OnSemi etc.
>cheers mate, Syms.

I had a similar problem to the OP.  Unfortunately, no IO standard on
on the (2.5V powered) Virtex2 Pro had a common mode range suitable for
3.3V PECL.

My signal was DC balanced, so I capacitively coupled it from the PECL
to the FPGA, and used DCI to provide the DC bias and termination on
the FPGA side.

Regards,
Allan.

Article: 64348
Subject: Re: A difference between VHDL sources working
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 30 Dec 2003 12:15:33 +1100
Links: << >>  << T >>  << A >>
On Mon, 29 Dec 2003 21:21:55 +0100, "toomuch" <toomuch@poczta.onet.pl>
wrote:

>Hi
>
>Can someone tell me if there is a defference between the following two VHDL
>sources working:
>1.
>process
>begin
>  wait until C'event and C='1';
>  if B='0' then
>    Q<=B;
>  else
>    Q<= A;
>  end if;
>end process;
>
>2.
>process
>begin
>  if B='0' then
>    wait until C'event and C='1';
>    Q<=B;
>  else
>    wait until C'event and C='1';
>    Q<=A;
>  end if;
>end process;
>
>
>Simulation of this two processes gives different results.

Yes.

>Does anybody know why?

Yes.  

1 samples B and A just after the rising edge of C.

2 samples B and A just after the rising edge of C, but doesn't use the
value of B until after the next rising edge of C.

2 is not good coding style.  Don't have more than one wait statement
in a synthesisable process.

>Is there a specification discussing those cases?

Yes.  Try: The VHDL LRM.  Any VHDL text book.  Any VHDL lecture notes.
The VHDL FAQ.  Google.

Regards,
Allan.

Article: 64349
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: Ray Andraka <ray@andraka.com>
Date: Mon, 29 Dec 2003 20:59:17 -0500
Links: << >>  << T >>  << A >>
Quite possible.  A slow moving signal can actually get the input to oscillate
due to the input threshold changing slightly when the input buffer's output
state is changed.  Noise on the reference can also do that if the signal is
hanging around the threshold region.  Put some hysteresis on the input or use a
schmitt trigger to clean it up.

Markus Meng wrote:

> Hi all,
>
> I would like know from the experts if the following behavior is possible
> if the input signal rise is exeeded. Xilinx states in its datasheet it shall
> be
> no more than 250 ns.
>
> If it is for exemaple 350 ns, but still - single pole - monotonic rise time,
> what
> is the internal logic seeing? Is it possible that the transistion
> from "0-1" is being seen as something like "0-1-0-1", or is only a matter of
> power consumption in the CMOS input stage, or even something else?
>
> Best Regards
> Markus

--
--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





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