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 64300

Article: 64300
Subject: Re: Parallel Cable 4 & Linux
From: russelmann@hotmail.com (Rudolf Usselmann)
Date: 26 Dec 2003 02:00:34 -0800
Links: << >>  << T >>  << A >>
Steve Lass <lass@xilinx.com> wrote in message news:<bs79d2$84a1@cliff.xsj.xilinx.com>...
> ISE 6.2i will support the Parallel 4 cable on Linux.


Thats great. So what am I supposed to do in the mean while ?

Shut down my company until you guys make your software work
with your hardware ?

Seriously, this is a real problem, and nobody seems to have
a solution. I tries modifying the software in app 058, but
that also needs a PC piece of SW to translate svf to xsvf
files.

Can you, Steve, or somebody else at Xilinx provide a Linux
version (or source code) for the svf to xsvf translator ?

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 ?

Do you have a date for 6.2i (patch?) ?

Thanks,
rudi               
========================================================
   ASICS.ws   ::: Solutions for your ASIC/FPGA needs :::
..............::: FPGAs * Full Custom ICs * IP Cores :::
FREE IP Cores -> http://www.asics.ws/  <- FREE EDA Tools

Article: 64301
Subject: Re: Hyperthreading vs. Dual proc
From: "Alex Gibson" <me@privacy.net>
Date: Fri, 26 Dec 2003 23:32:53 +1100
Links: << >>  << T >>  << A >>

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:H1ZFb.1797$oA5.541@newssvr25.news.prodigy.com...
> Apparently there's something called "Pentium4 Extreme"?
> Are marketing guys making it confusing on purpose?
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian

Yes, they took a xeon, and put it in a p4 package
to try and counter the athlon 64.
Mainly to make sure they stay ahead in the bench tables on the
various games web sites.

Can only be run in single proccessor system.

Alex Gibson



Article: 64302
Subject: Re: Anyone has the AMD flash AM29LV800B verilog model?
From: newhand@edacn.net (Newhand)
Date: 26 Dec 2003 05:35:17 -0800
Links: << >>  << T >>  << A >>
"Lost Temper" <305liuzg@163.net> wrote in message news:<bsgr23$1dpt$1@mail.cn99.com>...
> Hi
> I can't find the verilog model for AM29LV800B in www.amd.com.
> Please send me the model.
> Thanks and Regards

Hi, man! You can ask AMD for it. I think it is free to use.

Article: 64303
Subject: Re: FPGA SRAM
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Fri, 26 Dec 2003 10:30:56 -0800
Links: << >>  << T >>  << A >>
Sorry to disappoint you:
The XC2S300E has 16 BlockRAMs, each of which has 4096 bits, for a total of 64K
bits.
There are also over 6000 Look-Up Tables, each of which can be configured as a
16-bit RAM.
If you need 8 megabytes of RAM, you have to go off-chip. This applies to any
FPGA from any manufacturer. FPGA chip area is too precious for such large
memories.
Peter Alfke, Xilinx
===================================
Carlos wrote:

> Hi,
>
> Does anyone know how much SRAM is available on the XILINX XC2S300E SPARTAN
> IIE FPGA?  Am I right in thinking it's 8096K Bytes?  I'm planning on using
> the RAM32X1S module, I was wondering how many can I have inside a single
> FPGA.
>
> Thanks for any help,


Article: 64304
Subject: FPGA SRAM
From: "Carlos" <Carlos@no_spam.com>
Date: Fri, 26 Dec 2003 12:41:37 -0800
Links: << >>  << T >>  << A >>
Hi,

Does anyone know how much SRAM is available on the XILINX XC2S300E SPARTAN
IIE FPGA?  Am I right in thinking it's 8096K Bytes?  I'm planning on using
the RAM32X1S module, I was wondering how many can I have inside a single
FPGA.

Thanks for any help,



Article: 64305
Subject: EDK oddity
From: wpiman@aol.com (MS)
Date: 26 Dec 2003 13:03:52 -0800
Links: << >>  << T >>  << A >>
So I have a Memec P7 evaluation board with the EDK and a Parallel 4
download cable.  We are doing something very basic here to just get
our feet wet.

All we are doing is writing to the UART a simple hello world program. 
We wrote some C code, and then stepped through the base system builder
using this board.  We went thru all the steps in the EDK and
downloaded right from the EDK to the board.  Hooked up Hyperterm and
viola- there was hello world.  Hit reset on the board and there it was
again.

So far so good.  Then I figured I would go into the debugger and check
out the SDRAM.  Run XMD- connect to the debugger and write to the
SDRAM.  The values do not stick.  Odd.

So I exit the debugger completely and simply hit the reprogram button
in EDK.  It says it downloaded the bit file but now hello world
doesn't work.  I am simply reprogramming the FPGA here.  It doesn't
work.  I reset the program, the PC, the eval board, everything.  It no
longer works.  I cannot get hello world to work again.  I do a make
clean in EDK (both HW and SW).  Nothing.

So I reprogram the FPGA and connect with the debugger.  Now the
program does not work- but I can write to the SDRAM locations and they
stick.

I repeated this a couple of times.  If I build a system from scratch
it will work.  If I use one after I download and open the debugger- it
does not work.

I attempted to trace the program- but my SW guy is on holiday.  It
craps out on some MTCTR instruction.  Some special purpose register
move thing.

Our FAE is stumped to.  Anyone seen anything like this?  I would
thing- reprogram the bit file into a UART that has been reset- you
should be good.  Apparently, not in this case.

Thanks,
MS

Article: 64306
Subject: Re: Xilinx Johnson counter Verilog example bug?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Dec 2003 13:51:53 -0800
Links: << >>  << T >>  << A >>
Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<bsa1a102rfm@enews3.newsguy.com>...
> The Verilog they provided is (just counter section within an always @ 
> (posedge clk) begin procedural construct):
> 
> //Counter section:
>     if(run) begin
>        if(dir) begin
>           q[3:1] = q[2:0];	//Shift lower bits (Left Shift)
>           q[0] = !q[3];		//Circulate inverted MSB to LSB
>        end
>        else begin
>           q[2:0] = q[3:1];	//Shift upper bits (Right Shift)
>           q[3] = !q[0];		//Circulate inverted LSB to MSB
>        end
>     end

Jeez.  More blocking assignments in clocked always blocks!  Further
proof of my assertion that models and examples are built by a
company's most junior engineers, and that the companies involved don't
bother checking anything before throwing it up on the web.  The only
possible explanation is that they just don't care.

If we can't trust the examples, how can we trust the post-P&R
simulation models?

--a

Article: 64307
Subject: Re: Spartan3 availability
From: Ray Andraka <ray@andraka.com>
Date: Fri, 26 Dec 2003 17:16:45 -0500
Links: << >>  << T >>  << A >>
I'm speaking of density on the device scale.  I agree, if you look just at the M512, then you
have a denser filter than if you look at the equivalent number of LUTs.  When you look at the
device scale, you don't have very many M512s relative to the number of LUTs.  I am familiar with
the Stratix, and did a careful comparative analysis for one of the FPGA vendors between tbe
Stratix and Virtex architectures.  That vendor also was not aware of all that could be done with
the SRL16.

Also, yes, you would use it in the widest configurations to get the most efficient use.  As a
32x16 you are effectively equivalent to 30 SRL16s plus a 16 bit adder.  With DA, you only use
one shift-accumulate after summing all of the partial products.  In the limit, using SRL'16s you
use 2 LUTs per coefficient bit for every 4 taps (one lut for the DA LUT, one for part of your
partial adder).  In equivalent terms, the M512 replaces about 46 LE's in a non-programmable DA
filter.  Additionally, you'll still need your tap delays, which means either additional memories
or flip-flops in the LEs.  My point is for a given marketing gate sized device, you can get a
considerably larger DA filter in a device with SRL16's than you can in a device with M512's at
the current M512 to LUT densities.

Michael S wrote:

> Ray Andraka <ray@andraka.com> wrote in message news:<3FE9C209.66051EED@andraka.com>...
> > A DA LUT contains all the possible sums of the input taps, which for a serial filter is
> > one tap per address bit.  As you increase the number of taps, the corresponding table size
> > grows exponentially.  With LUTs, you get 4 taps per LUT (which you can do with LE's
> > provided you don't need to reload the LUTs).  If you have to reload them, then using an
> > M512 only gives you 9 taps per M512, and each M512 is associated with a number of LABs,
> > each containing 10 LEs.  Thus the density of a reloadable DA LUT using the DA_LUTs is
> > considerably lower than what you'd get if using LEs.
> >
>
> There are two possibilities:
> 1. I am totally clueless about DA.
> 2. You have never read Stratix datasheet and have no idea what is
> M512.
> Understandably, I prefer the 2nd option.
>
> Nobody in his right mind will use M512 for DA in 512x1b configuration,
> like you suggest. The natural configuration would be 32x16b or 32x18b.
> In such configurations one M512 provides 25% more DA bandwidth than 16
> (or 18, depending on required precision) SRL16 cells. So we can say
> that one M512 replaces 20 (or 22.5) SRL16 cells. Additionally, each
> shift-accumulate block is amortized over 25% more taps, providing
> additional space saving.
> Taking all this into account, I don't believe that M512 is less dense
> than SRL16. Less available - probably yes, but not less dense.

--
--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: 64308
Subject: Anyone has the AMD flash AM29LV800B verilog model?
From: "Lost Temper" <305liuzg@163.net>
Date: Fri, 26 Dec 2003 16:19:33 -0800
Links: << >>  << T >>  << A >>
Hi
I can't find the verilog model for AM29LV800B in www.amd.com.
Please send me the model.
Thanks and Regards



Article: 64309
(removed)


Article: 64310
Subject: Bus delimiter in iseWebPACK 4.2
From: "Kelvin, Chee" <kelvin8157@hotmail.com>
Date: Sat, 27 Dec 2003 22:29:58 +0800
Links: << >>  << T >>  << A >>
Hi, there:

I want to know whether the -bus_delimiter () work in XST.exe under ISE
WebPack 4.2?
Does a delimiter () work with my verilog source codes?

In my design, I need to instantiate some vendor's NMC macros, in the macros,
the bus delimiter is ().
NGBuild gave me an error as follows:

ERROR:NgdBuild:76 - File "D:\iir\iir/iir.nmc" cannot be merged into block
   "u_iir_0" (TYPE="iir") because one or more pins on the block, including
pin
   "IN<3>", were not found in the file.  Please make sure that all pins on
the
   instantiated component match pins in the lower-level design block
   (irrespective of case).  If there are bussed pins on this block, make
sure
   that the upper-level and lower-level netlists use the same bus-naming
   convention.

I could not find the "Bus demiliter" option in the Synthesize->Properties,
so I used commandline mode.
The XST.exe doesn't give me error for my -bus_delimiter () but it put it in
"Other Options"...I wonder
whether this option is working or not.

Best Regards,
Kelvin




Article: 64311
Subject: Re: predictable timing for xilinx cpld?
From: guillerodriguez@terra.es (guille)
Date: 27 Dec 2003 08:21:39 -0800
Links: << >>  << T >>  << A >>
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: 64312
Subject: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: "Markus Meng" <meng.engineering@bluewin.ch>
Date: Sat, 27 Dec 2003 20:52:35 +0100
Links: << >>  << T >>  << A >>
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



Article: 64313
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: jim granville <no.spam@designtools.co.nz>
Date: Sun, 28 Dec 2003 09:46:13 +1300
Links: << >>  << T >>  << A >>

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?

  Both.
Slow slew IPs will certainly increase the power, due to more time in the
linear region.
They can also cause double clocking, and you can get some feel for this
by adding some finite ground bounce.
eg  a 3.5V slev in 350ns is 10V/us, or 100mv in 10ns.
Thus, if a consequent OP,( or many buried nodes ) change within 10ns,
and this causes 100mv of ground movement, then you get double-clocking
effects.
Hysteresis will help, but does _not_ guarantee to eliminate this - it 
gives a threshold to the tolerable system bounce.
Carefull design is still needed to ensure you stay comfortably under
that.

What Hysteresis _does_ reduce greatly, is threshold oscillation - the 
effect where the CMOS inverter chain actually oscillates whilst in the 
linear region - this oscillation is typ very fast, above the clock
MAX, but it can cause strange effects in even 'unrelated' logic.
  Mention this to a digitial designer, and mostly you get a blank stare :)

-jg



Article: 64314
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: palfke@earthlink.net (Peter Alfke)
Date: 27 Dec 2003 14:07:13 -0800
Links: << >>  << T >>  << A >>
"Markus Meng" <meng.engineering@bluewin.ch> wrote in message news:<3fede218_1@news.bluewin.ch>...
> 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

In the absence of noise ( if there were such a condition), there is no
limit to the rise/fall time, but you would still have to face the
large timing uncertainty.

For combinatorial inputs, there never is a transition-time limit ( but
you have to live with the timing uncertainty...)
For clocks, any transition time of more than 10 ns is objectionable,
since it can result in double-triggering caused by ground-bounce and
general noise in the system (plus the timing uncertainty).

The suspected increase in power consumption is really insignificant,
less than 5 mA during less than 10% of the transition time. No big
deal.

Peter Alfke, Xilinx Applications

Article: 64315
Subject: Re: predictable timing for xilinx cpld?
From: palfke@earthlink.net (Peter Alfke)
Date: 27 Dec 2003 14:25:54 -0800
Links: << >>  << T >>  << A >>
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.

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.

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

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

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: 64316
Subject: Re: Anyone has the AMD flash AM29LV800B verilog model?
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 28 Dec 2003 00:26:20 +0100
Links: << >>  << T >>  << A >>
"Lost Temper" <305liuzg@163.net> writes:

> I can't find the verilog model for AM29LV800B in www.amd.com.

Try to find a compatible Fujitsu flash model at:


http://www.fujitsu.com/services/microelectronics/product/memory/flash-sim-model/vhdl/casestudy_pdt-memory-flash-sim-vhdl_1.html


AMD and Fujitsu flash are now called Spansion (www.spansion.com).

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 64317
Subject: Re: predictable timing for xilinx cpld?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 27 Dec 2003 16:00:11 -0800
Links: << >>  << T >>  << A >>
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?

--a

Article: 64318
Subject: Re: advantages of ethernet MAC ip core
From: "John" <305liuzg@163.net>
Date: Sun, 28 Dec 2003 15:30:02 +0800
Links: << >>  << T >>  << A >>
Hi,
"Marc" <damc4@gmx.de> wrote in message
news:cf0ec8fc.0312210240.54c85860@posting.google.com...
> Didn't you mean this OpenCores project?
>
> http://www.opencores.org/projects/ethmac/
>
> It is an Ethernet MAC using the MII interface to connect to every PHY you
want!
> I used the core in Altera FPGAs and have had no problems with it.

Which PHY did you use?
I have LAN91C111 but don't know whether it can be used only as the PHY!?

Regards

>
> Regards,
> Marc
>
> e-mail: Marc dot Colling at MaCo-Engineering dot de
>
>
> "John Retta" <jretta@rtc-inc.com> wrote in message
news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>...
> > That is correct.  No Phy.  My mistake in original email.
> >
> > --
> > Regards,
> > John Retta
> >
> > email : jretta@rtc-inc.com
> > web :  www.rtc-inc.com
> >
> >
> > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
> > news:3FDF7EEB.7060509@flukenetworks.com...
> > > John Retta wrote:
> > > > You can remove the cost variable from the equation.
> > > > Check www.opencores.org.  They offer open source code
> > > > for numerous cores, including a MAC PHY
> > >
> > > I found the MAC, but the only PHY listed is for USB.
> > >
> > >
> > >    -- Mike Treseler
> > >



Article: 64319
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: jim granville <no.spam@designtools.co.nz>
Date: Sun, 28 Dec 2003 20:57:05 +1300
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> In the absence of noise ( if there were such a condition), there is no
> limit to the rise/fall time, but you would still have to face the
> large timing uncertainty.
> 
> For combinatorial inputs, there never is a transition-time limit ( but
> you have to live with the timing uncertainty...)

This is true only for an ideal (viz : non real, 0nH ) device.
If transistion oscillations occur (and they are common on
non schmitt, CMOS chained inverter structures), then
even combin IPs can affect other seemingly unrelated logic.

-jg


Article: 64320
Subject: Re: advantages of ethernet MAC ip core
From: damc4@gmx.de (Marc)
Date: 28 Dec 2003 03:34:08 -0800
Links: << >>  << T >>  << A >>
Hi John,

the LAN91C111 has an external MII interface and it seems to be
possible to disable the internal PHY (and use this MII for an external
PHY). If it works also the other way round I have no idea, never tried
it.

I used the folowing PHYs together with the OpenCores MAC: Broadcom
BCM5201, AMD AM79C874 NetPHY, National Semi DP83865.

What kind of hardware do you use?

Regards,
 Marc

e-mail: Marc dot Colling at MaCo-Engineering dot de



"John" <305liuzg@163.net> wrote in message news:<bsm116$n39$1@mail.cn99.com>...
> Hi,
> "Marc" <damc4@gmx.de> wrote in message
> news:cf0ec8fc.0312210240.54c85860@posting.google.com...
> > Didn't you mean this OpenCores project?
> >
> > http://www.opencores.org/projects/ethmac/
> >
> > It is an Ethernet MAC using the MII interface to connect to every PHY you
>  want!
> > I used the core in Altera FPGAs and have had no problems with it.
> 
> Which PHY did you use?
> I have LAN91C111 but don't know whether it can be used only as the PHY!?
> 
> Regards
> 
> >
> > Regards,
> > Marc
> >
> > e-mail: Marc dot Colling at MaCo-Engineering dot de
> >
> >
> > "John Retta" <jretta@rtc-inc.com> wrote in message
>  news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>...
> > > That is correct.  No Phy.  My mistake in original email.
> > >
> > > --
> > > Regards,
> > > John Retta
> > >
> > > email : jretta@rtc-inc.com
> > > web :  www.rtc-inc.com
> > >
> > >
> > > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
> > > news:3FDF7EEB.7060509@flukenetworks.com...
> > > > John Retta wrote:
> > > > > You can remove the cost variable from the equation.
> > > > > Check www.opencores.org.  They offer open source code
> > > > > for numerous cores, including a MAC PHY
> > > >
> > > > I found the MAC, but the only PHY listed is for USB.
> > > >
> > > >
> > > >    -- Mike Treseler
> > > >

Article: 64321
Subject: Re: advantages of ethernet MAC ip core
From: "John" <305liuzg@163.net>
Date: Mon, 29 Dec 2003 00:17:46 +0800
Links: << >>  << T >>  << A >>
Hi
I am working with Altera Nios Kit with LAN91C111!
Regards

"Marc" <damc4@gmx.de> wrote in message
news:cf0ec8fc.0312280334.409afc93@posting.google.com...
> Hi John,
>
> the LAN91C111 has an external MII interface and it seems to be
> possible to disable the internal PHY (and use this MII for an external
> PHY). If it works also the other way round I have no idea, never tried
> it.
>
> I used the folowing PHYs MAC: Broatogether with the OpenCores dcom
> BCM5201, AMD AM79C874 NetPHY, National Semi DP83865.
>
> What kind of hardware do you use?
>
> Regards,
>  Marc
>
> e-mail: Marc dot Colling at MaCo-Engineering dot de
>
>
>
> "John" <305liuzg@163.net> wrote in message
news:<bsm116$n39$1@mail.cn99.com>...
> > Hi,
> > "Marc" <damc4@gmx.de> wrote in message
> > news:cf0ec8fc.0312210240.54c85860@posting.google.com...
> > > Didn't you mean this OpenCores project?
> > >
> > > http://www.opencores.org/projects/ethmac/
> > >
> > > It is an Ethernet MAC using the MII interface to connect to every PHY
you
> >  want!
> > > I used the core in Altera FPGAs and have had no problems with it.
> >
> > Which PHY did you use?
> > I have LAN91C111 but don't know whether it can be used only as the PHY!?
> >
> > Regards
> >
> > >
> > > Regards,
> > > Marc
> > >
> > > e-mail: Marc dot Colling at MaCo-Engineering dot de
> > >
> > >
> > > "John Retta" <jretta@rtc-inc.com> wrote in message
> >  news:<N2QDb.7879$0s2.2125@newsread2.news.pas.earthlink.net>...
> > > > That is correct.  No Phy.  My mistake in original email.
> > > >
> > > > --
> > > > Regards,
> > > > John Retta
> > > >
> > > > email : jretta@rtc-inc.com
> > > > web :  www.rtc-inc.com
> > > >
> > > >
> > > > "Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
> > > > news:3FDF7EEB.7060509@flukenetworks.com...
> > > > > John Retta wrote:
> > > > > > You can remove the cost variable from the equation.
> > > > > > Check www.opencores.org.  They offer open source code
> > > > > > for numerous cores, including a MAC PHY
> > > > >
> > > > > I found the MAC, but the only PHY listed is for USB.
> > > > >
> > > > >
> > > > >    -- Mike Treseler
> > > > >



Article: 64322
Subject: Virtex-II Pro and DDR2 SDRAM differential IO
From: blake@go.ru (bob)
Date: 28 Dec 2003 08:31:59 -0800
Links: << >>  << T >>  << A >>
I'm doing a Virtex-II Pro design that uses DDR SDRAM SODIMM modules as
data storage. There's a possibility (because DDR and DDR2 SODIMMs are
footprint compatible) to support the upcoming DDR2 modules in this
design too.

Now, there's a problem: DDR2 SDRAM supports the use of differential
signaling on data strobe lines (DQS). However, these signals are still
1.8V SSTL. Virtex-II Pro device (or maybe ISE software) seem not to
support differential SSTL IO.

So, the question is: do the specific hardware resources in Virtex-II
Pro exist to support DDR2 differential IO, or, if not, that are the
possible workarounds for this besides from just not using the DDR2
differential IO at all?

Regards,
Bob

Article: 64323
Subject: Re: [Spartan-IIE] Exeeding max. input rise/fall time of signals ??
From: palfke@earthlink.net (Peter Alfke)
Date: 28 Dec 2003 09:57:39 -0800
Links: << >>  << T >>  << A >>
All Xilinx FPGAs have input hysteresis (Schmitt triggered inputs).
Peter Alfke

jim granville <no.spam@designtools.co.nz> wrote in message news:<N%vHb.14744$ws.1502122@news02.tsnz.net>...
> Peter Alfke wrote:
> > In the absence of noise ( if there were such a condition), there is no
> > limit to the rise/fall time, but you would still have to face the
> > large timing uncertainty.
> > 
> > For combinatorial inputs, there never is a transition-time limit ( but
> > you have to live with the timing uncertainty...)
> 
> This is true only for an ideal (viz : non real, 0nH ) device.
> If transistion oscillations occur (and they are common on
> non schmitt, CMOS chained inverter structures), then
> even combin IPs can affect other seemingly unrelated logic.
> 
> -jg

Article: 64324
Subject: Re: VHDL-Xilinx-Simulation (signal not connected to port) ?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Sun, 28 Dec 2003 10:37:22 -0800
Links: << >>  << T >>  << A >>
Jarek wrote:

> How to simulate (observe) signals not connected to port (Xiilinx ISE
> WebPack-ModelSim XE).
> For example signal counter in project test.vhd.

To see the waveform "counter", try this:

vsim testbench -do "add wave sim:/testbench/uut/*; run 4 uS;"

To use "counter" in a testbench, you can package it,
or bring it out to a port,
or use modelsim signal spy.


          -- Mike Treseler




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