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 39200

Article: 39200
Subject: Virtex-II and SDRAM Controller at 133MHz
From: vchittap@hotmail.com (Venu)
Date: 4 Feb 2002 02:27:53 -0800
Links: << >>  << T >>  << A >>
Hi,

 I am planning to implement a SDRAM Controller to run at 133MHz and I am
 targetting Virtex-II device. It would be of great help to me if people
 can let me know their experiences in this regard . More specifically I 
 am looking for some inputs on the following:
 
 a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a Virtex-II
    device
 b) What is the Max frequency that Xilinx claims in their application-notes
    for SDRAM Controller using Virtex-II

Thanks
Venu

Article: 39201
(removed)


Article: 39202
Subject: Re: MUX seelction question
From: newman5382@aol.com (newman)
Date: 4 Feb 2002 05:15:51 -0800
Links: << >>  << T >>  << A >>
>> architecture demux_3x10_arch of demux_3x10 is
>> begin				  
>> 	process (sel, in_mux, clk)
>> 	begin
>> 		if falling_edge(clk) then		 

> in_mux and sel should not be in the sensitivity list, as your
> process is not sensitive to them (only to the clock).
>
...
>
> Hamish

In a previous thread, someone posted the previous information. 
Apparently you have decided to ignore the comment.

Newman

Article: 39203
Subject: Re: JTAG Boundary Scan with the XDS510
From: "Mark D'Sylva" <noSpam@nospam.com>
Date: Mon, 4 Feb 2002 08:32:48 -0500
Links: << >>  << T >>  << A >>
Sorry if I supplied some incorrect information.   I have a Spectrum Digital
XDS510PP, so I assumed SD designed and manufactured it as a third party
vendor.

Mark

--


"Darrell Grainger" <darrell@cs.toronto.edu> wrote in message
news:Pine.GSO.4.21.0202032101160.13156-100000@qew.cs...
> Actually, Spectrum Digital makes the PP510. The XDS510 is made by
> TI. There is a technical document on JTAG/MPSD that might help. Go to
> dspvillage.ti.com and search for "JTAG/MPSD". There should be a link for
> the Emulation Technical Reference. I'm not sure if this is going to help.
>
> People who make evaluation boards using TI chips have to make their own
> drivers. TI therefore supplies them with an "emulation porting kit". Check
> the dspvillage and you should be able to find something about this as
> well. Hopefully this will give you the information you need if the
> JTAG/MPSD document does not.
>
> On Sun, 3 Feb 2002, Mark D'Sylva wrote:
>
> > TI does not make the XSD510, it is made by Spectrum Digital.  Here a
link:
> > http://www.spectrumdigital.com/
> >
> > Mark
> > --
> >
> >     http://www.dsylva-tech.ca
> >     BMW performance chips for E34 M5 and E36's
> >     Chips for E30 and E34 currently in development!
> >
> >
> >
> > "rickman" <spamgoeshere4@yahoo.com> wrote in message
> > news:3C5D681C.EBD7700F@yahoo.com...
> > > I am designing a line of DSP boards containing FPGAs and a single chip
> > > micro all on the JTAG chain. I want to be able to test the production
> > > boards using JTAG boundary scan. It looks like I can use the XDS510
> > > emulator from TI for emulation. I can also do everything else that I
> > > want to do on this scan chain with the other chips.
> > >
> > > I have been looking for some information on the XDS510 so that I might
> > > be able to use it as my boundary scan hardware. This would make the
> > > testing and interface consistent and simple. But so far I have found
> > > none. TI support is having trouble understanding the question. The
first
> > > line of help seems to focus on their "canned" answers on using the
> > > emulator for code debugging rather than to try to understand my
problem.
> > >
> > > Does anyone have ideas on the best way to use the XDS510 JTAG
connector
> > > on my board for boundary scan testing? Is there sufficient information
> > > on the PC interface to the XDS510 to let me write software to drive
test
> > > vectors into the board? Or are there other XDS510 compatible emulators
> > > that will let me do both code debugging (Code Composer Studio) and
> > > boundary scan?
> > >
> > >
> > > --
> > >
> > > 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
> >
> >
> >
>
> ---
> main(){int j=1234;char t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i=
> "iqgbgxmdbjlgdv.lksrqek.n";char *strchr(const char *,int); while
> (*i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}return 0;}
>



Article: 39204
Subject: Re: RAM question
From: "MANDY & DOUGLAS" <mandy_ridge@prodigy.net>
Date: Mon, 04 Feb 2002 14:04:08 GMT
Links: << >>  << T >>  << A >>
What performance are you trying to achieve?

If RAM performance is the gating factor in your design, try doubling (or
trebling) your memory bus width to get around it - similarly with your logic
if necessary.

"Antonio" <dottavio@ised.it> wrote in message
news:fb35ea96.0202032329.565fd310@posting.google.com...
> In my project I'm using 3 set of values with different dimension, I
> mean 384x12 bits , 512x12 bits and 768x12 bits , to choose between
> them I could use a demux-BLOCKRAM-mux chain or to fit each of these
> block in a zero padded 1024x12 bits and use the addressing
> capabilities of a Virtex BLOCKRAM 3072x16. with very disappoint I
> found that this last solution (implemented with the CORE blockRAM
> single port) may run at a maximum of 60MHZ on a VIRTEX1000BG560-4 and
> 90MHz on
> VirtexE600-6 so my question is :
> 1) is this normal ??
> 2) when I read 300 MHz on FPGA are we talking of a flip flop ??
> 3) this is the most important question :  how can I obtain more to
> solve the same problem with
> the VIRTEXE600-6  ??
>
> Thanks
>
>    Antonio



Article: 39205
Subject: Re: solutions manuals, and no they are not for school
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Feb 2002 14:10:22 GMT
Links: << >>  << T >>  << A >>
For some, understanding of the material is bolstered by working the problems and making sure the results are
the same as the solution.  Many times, all that is needed is to work through one or two problems to make sure
your understanding of the material is correct.

Steve wrote:

> strut911@hotmail.com (strut911) wrote in message news:<4379d3e0.0202031347.599a779f@posting.google.com>...
> > > Interesting post. You want solutions manuals to
> > > help you decide whether to buy a book,...
> > > Well, ... at least you're original.
> > >
> > > [-Rick-]
> >
> > heh. yeah, i never start a design without a spec, and i never go on a
> > long drive without a map. i do buy books without manuals, but if i am
> > trying to learn something new, then i would like some kind of
> > pass/fail criteria to tell me if i am on the right track or not.
> > having a solutions manual will not be the driving force behind buying
> > a book, but it will make me think that i have a decent shot at
> > learning the book material thoroughly, instead of guessing if i am
> > correct on my answers or not.
>
> There's a simple solution. Buy an easier book that you CAN answer the
> questions. Then when you can do that move on to more difficult books.
> Mummy won't hold your hand when you start work so I'd say it'd be
> better if you just had a bit more confidence in your own ability.
>
> Learning by doing is a good way of learning but if you do understand
> the theory not ateempting end of chapter questions won't do that much
> harm.
>
> You can ALWAYS find a book with answers to enough problems if you look
> hard enough.

--
--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: 39206
Subject: Re: ClkEnable vs gated clock
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Feb 2002 14:14:36 GMT
Links: << >>  << T >>  << A >>
 I thought I answered this last week.  The unclocked multiplexer has no registers, so it is not
subject to the period constraint.  Look at the timing report.  It tells you exactly where your
timing problems lie.  If you turn on the trace unconstrained paths option it will tell you which
paths do not have constraints on them.

Antonio wrote:

> I coudn't understand why for a gated clock project I was fighting to
> obtain 150MHz and now with
> the clkEnable version of the same I'm fighting to obtain only 70MHz,
> to what this is due ??
> All suggest me to use clkEnable if there are situation where clock
> enable is not a must, is it
> really necessary in my project where I've a master clock from which I
> obtain 3 derived clock in
> the gated clock version and 3 enable signal (...via a programmable
> counter) in the clock enable
> version. And to put in my thesis and based on your experience please
> add some lines to the following:
>
> ***********************************************************************************************
> Clock Enable Clock Enable Clock Enable Clock Enable Clock Enable Clock
> Enable Clock Enable
> ***********************************************************************************************
>                                          PRO
> P1) Immunity to temperature change
> P2) Only CLK recognized by synthesizer
>
>                                         VERSUS
> V1) slow (.. I don't know why)
> v2) More power dissipated because all the circuit run at f_clk
>
> ***********************************************************************************************
> Gated Clock Gated Clock Gated Clock Gated Clock Gated Clock Gated
> Clock Gated Clock Gated Clock
> ***********************************************************************************************
>
>                                          PRO
> P1) Less power dissipated because not all the circuit run at f_clk
> P2)
>
>                                         VERSUS
> V1) Derived clock not recognized by synthesizer
> v2)

--
--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: 39207
(removed)


Article: 39208
Subject: Re: RAM question
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Feb 2002 16:06:00 GMT
Links: << >>  << T >>  << A >>
The Block RAMs have fairly long tsu, th and tco numbers compared to the
CLB flip flops.  Virtex-4 block RAMs can be made to run at about 125 MHz,
but you need to be careful to register the data, address and controls
going in and out and to physically locate (floorplan) those registers so
that they are situated immediately adjacent to the block RAM.  You can
achieve considerably better performance if you can avoid using the ENA
and WE controls (ie, wire it so that these are constants: you'll need to
use one port as a read port and one as a write port.  Increment the write
address on a valid write and accept garbage at the current address for
invalid writes).  These two controls have very long set up times.  If you
hold the write active, you can write to BRAM in an E-7 device at 240 MHz
with margin left over, however if you qualify the writes with WE, then
your maximum possible performance drops to around 185 MHz.  If you still
need more performance, you'll need to double the width so that two words
get read/written per BRAM clock, then use registers to pack/unpack the
data.


Antonio wrote:

> In my project I'm using 3 set of values with different dimension, I
> mean 384x12 bits , 512x12 bits and 768x12 bits , to choose between
> them I could use a demux-BLOCKRAM-mux chain or to fit each of these
> block in a zero padded 1024x12 bits and use the addressing
> capabilities of a Virtex BLOCKRAM 3072x16. with very disappoint I
> found that this last solution (implemented with the CORE blockRAM
> single port) may run at a maximum of 60MHZ on a VIRTEX1000BG560-4 and
> 90MHz on
> VirtexE600-6 so my question is :
> 1) is this normal ??
> 2) when I read 300 MHz on FPGA are we talking of a flip flop ??
> 3) this is the most important question :  how can I obtain more to
> solve the same problem with
>         the VIRTEXE600-6  ??
>
> Thanks
>
>    Antonio

--
--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: 39209
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Feb 2002 16:08:48 GMT
Links: << >>  << T >>  << A >>


Venu wrote:

> Hi,
>
>  I am planning to implement a SDRAM Controller to run at 133MHz and I am
>  targetting Virtex-II device. It would be of great help to me if people
>  can let me know their experiences in this regard . More specifically I
>  am looking for some inputs on the following:
>
>  a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a Virtex-II
>     device

Should be very easy to hit 133 Hz in VII.  Of course, it depends on your design
expertise, which is why I said "should" not "is".

>
>  b) What is the Max frequency that Xilinx claims in their application-notes
>     for SDRAM Controller using Virtex-II
>
> Thanks
> Venu

--
--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: 39210
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 04 Feb 2002 08:49:20 -0800
Links: << >>  << T >>  << A >>
Ray,

Yup.  133 MHz, 266 Mb/s is a good sweet spot.  At 180 MHz, things start to get more
challenging, and beyond 200 MHz or 400 Mb/s, I wouldn't recommend it.  Just run a
simulation or two there, pick anyones' parts.

That said, you MUST simulate everything.  You MUST extract the pcb traces and simulate
the actual pcb impedances, and devices.  Then when you get the pcb back, it will
perform as expected.

Single ended IO's are at the end of their lives at 200 MHz, and anyone who goes faster
gets into all kinds of horrible signal integrity issues.  It isn't the technology at
all, it is the ability to manage 200 or more single ended signals, all switching, with
cross talk, ground bounce, and all of the other evils of single ended IO's at those
speeds.

TTL begat LVTTL which begat LVCMOS which began GTL which begat GTL+, which begat HSTL
(all four classes, and three voltages), which begat SSTL ..... they are not going to
push that poor LVCMOS output buffer any further (which has not changed much throughout
the above generations).  Our DCI feature is another way to try to get more life out of
single ended IOs.

The next step is LVDS, which takes you to 800 Mb/s or just beyond 400 MHz.

After that comes ..... stay tuned.

Austin

Ray Andraka wrote:

> Venu wrote:
>
> > Hi,
> >
> >  I am planning to implement a SDRAM Controller to run at 133MHz and I am
> >  targetting Virtex-II device. It would be of great help to me if people
> >  can let me know their experiences in this regard . More specifically I
> >  am looking for some inputs on the following:
> >
> >  a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a Virtex-II
> >     device
>
> Should be very easy to hit 133 Hz in VII.  Of course, it depends on your design
> expertise, which is why I said "should" not "is".
>
> >
> >  b) What is the Max frequency that Xilinx claims in their application-notes
> >     for SDRAM Controller using Virtex-II
> >
> > Thanks
> > Venu
>
> --
> --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: 39211
Subject: Destroying a CPLD by JTAG
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 4 Feb 2002 08:50:44 -0800
Links: << >>  << T >>  << A >>
Hi,
We have a board with a Xilinx Virtex-2 FPGA and a 9500XL CPLD on it; they are
chained on JTAG for programming (V-2 first, 9500 second).

We've been happily working with this board, downloading V-2 and programming
the 9500, using the iMpact tool from ISE 4.1 (SP3).

We were synthesizing the CPLD with Synplicity, fitting it with ISE and
programming as needed. One day, we've tried synthesizing the CPLD with XST.
When we've downloaded it (no errors during synthesis or fitting), the CPLD
didn't work.

Since that download, we can't access the V-2 OR the CPLD with iMpact. When
connecting, it recognizes (correctly) only the CPLD; if we try any operation
on the CPLD (erasing, programming or whatever), we get a message "invalid
device ID".

Had anyone encountered this problem? is there any solution except removing the
CPLD and soldering a new one? (get a bigger hammer...)

   Thanks in Advance
   Assaf Sarfati

Article: 39212
Subject: Re: can comparisons glitch?
From: "Bryan" <bryan@srccomp.com>
Date: Mon, 4 Feb 2002 10:27:01 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_005B_01C1AD66.7BD1C8E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does the Coregen async FIFO use Gray-coded counters?  The data sheet =
makes no mention to what is inside the FIFO, just that empty flag is =
synchronous to read clock.

Bryan
  "Peter Alfke" <palfke@earthlink.net> wrote in message =
news:3C5DDBF9.619722AC@earthlink.net...
  Your gut feel is right. 
  There is an exception, though. When you compare two Gray-coded =
counters, you will not get a glitch, since only one bit in each counter =
can change asynchronously. 
  But otherwise, beware! 
  You may want to read 

  http://www.xilinx.com/support/techxclusives/MovingData-techX16.htm 

  Peter Alfke, Xilinx Applications 
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D 
  David Miller wrote: 

    For Virtex style architectures (and probably XC4000), can comparason =

    statements of the form 
    o <=3D (a =3D b) 
    o <=3D (a < b) 

    even when b might be constant, glitch?  ie is it async safe[1]? 

    My gut feeling is that it isn't, even when synthesized to take =
advantage 
    of fast carry chain compares. 

    [1] Ordinarily, this question doesn't come up.  In this case, I am 
    dealing with an external device whose register port is asynchronous. =


    -- 
    David Miller, BCMS (Hons)  | When something disturbs you, it isn't =
the 
    Endace Measurement Systems | thing that disturbs you; rather, it is 
    Mobile: +64-21-704-djm     | your judgement of it, and you have the 
    Fax:    +64-21-304-djm     | power to change that.  -- Marcus =
Aurelius




Article: 39213
Subject: par and carry chains not allowing manual floorplanning
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Mon, 4 Feb 2002 12:28:05 -0500
Links: << >>  << T >>  << A >>
Help!!,
    I am having a continuing problem with manual placing of carry chain
parts via floorplanner.  If I take an already placed design and try to move
parts via floorplanner, the carry chains are not allowed to be moved as they
are RPM's.  The placement is _absolutely_ horrible in some cases.  If I
delete the particular chain and bring it back in I get an even worse
placement.  I can not find a way to unbind the chains.  Xilinx support has a
few suggestions that I cannot seem to get to work for me.
    The one thing that I have noticed is that the carry chains are only
screwed up at the top level of the design.  Unfortunately, if I stick in a
dummy level above the top level, the problem persists at the origianl top
level,  so that doesn't seem to be much help.
    I am considering learning about rloc and similar things.  Can anyone
recomend a good tutorial on the subject?  Or better yet a fix for the real
problem?  I am using ise4.1 on a win2k machine.

Thanks,
Theron Hicks



Article: 39214
Subject: Terabit Networking Forum
From: nurit.eliram@mailandnews.com (Nurit Eliram)
Date: 4 Feb 2002 09:45:26 -0800
Links: << >>  << T >>  << A >>
Hi.
I saw in
http://www.xilinx.com/terabit/index.htm

The Xilinx is member on the "Terabit Networking Forum".

1. Is there any other fpga vendor member in this forum ?
2. What is the official website of the "Terabit Networking Forum" ?

ThankX Nurit.

Article: 39215
Subject: Glitch detect
From: "madhu" <pp_madhavi@yahoo.com>
Date: Mon, 4 Feb 2002 17:57:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hey everyone,
  How can we detect a glitch.
 
  Thank you,
  Regards
 
 Madhu


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 39216
Subject: Re: RAM question
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 04 Feb 2002 10:17:44 -0800
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> The Block RAMs have fairly long tsu, th and tco numbers compared to the
> CLB flip flops.

According to the Virtex-II data published on the web:

set-up time for Address or Data is 0.29 ns in speed grade -6 ( 25% longer in -4)

set-up time for WE is 0.57 ns, and for EN it is 0.95 ns in speed grade -6 (
again +25% in -4)
All hold times are negative or specified as zero.

Clock-to-out is 2.1 ns in -6

So, I don't think the set-up times are the problem. The hold times definitely
aren't.
Clock-to-out and routing are probably the limiting parameters.

Peter Alfke, Xilinx Applications



Article: 39217
Subject: Re: Glitch detect
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 4 Feb 2002 19:57:47 +0100
Links: << >>  << T >>  << A >>
"madhu" <pp_madhavi@yahoo.com> schrieb im Newsbeitrag
news:5c12c6f29f7c638ad46027dc2db1c441.67011@mygate.mailgate.org...
> Hey everyone,
>   How can we detect a glitch.

This depends on many factors. Where do you want to detect the glitch, inside
a FPGA or outside? When outside, use a FAST (500MHz ++) Scope and a good
probe. Forget about this standard 1:10 probe, they are glitch blind. Have a
look at here

www.signalintegrity.com

The is an article about high speed probing (and lot of more good stuff)

If you want to capture a glitch inside, use a FlipFlop. But this works only
if the (assumed glitch free) signal does not change its value (always LOW or
HIGH). If the FlipFlop then toggles, you have a glitch.

--
MfG
Falk





Article: 39218
Subject: Re: par and carry chains not allowing manual floorplanning
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 4 Feb 2002 19:59:24 +0100
Links: << >>  << T >>  << A >>
"Theron Hicks" <hicksthe@egr.msu.edu> schrieb im Newsbeitrag
news:a3mesc$2nln$1@msunews.cl.msu.edu...
> Help!!,
>     I am having a continuing problem with manual placing of carry chain
> parts via floorplanner.  If I take an already placed design and try to
move
> parts via floorplanner, the carry chains are not allowed to be moved as
they
> are RPM's.  The placement is _absolutely_ horrible in some cases.  If I
> delete the particular chain and bring it back in I get an even worse
> placement.  I can not find a way to unbind the chains.  Xilinx support has
a

"UNBIND" is the magic word. Click the carry chain,then click right, you will
find UNBIND in the menu (or maybe in the menu bar, not sure)

--
MfG
Falk





Article: 39219
Subject: Re: can comparisons glitch?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 4 Feb 2002 20:07:54 +0100
Links: << >>  << T >>  << A >>
"Bryan" <bryan@srccomp.com> schrieb im Newsbeitrag
news:3c5ec623$0$7453$4c41069e@reader1.ash.ops.us.uu.net...

>Does the Coregen async FIFO use Gray-coded counters?  The data sheet makes
no mention to what is inside the FIFO, just that empty flag is synchronous
to >read clock.

Sure, it does. Not for addressing the BLOCKRAM, but for transfering the FIFO
counter across the clock domain.

--
MfG
Falk







Article: 39220
Subject: Re: RAM question
From: Ray Andraka <ray@andraka.com>
Date: Mon, 04 Feb 2002 19:29:29 GMT
Links: << >>  << T >>  << A >>
The query was specifically regarding to VIRTEX1000BG560-4 and VirtexE600-6 designs.
In those parts, the setup for ena and we are
double the set-up times for the address and data inputs to the BRAM, and very long
compared to other timing on the chip.  In A virtex E-6 they are 2.5 and 2.2 ns
respectively.  In comparison, the set up times for the data and address inputs for
the BRAM are 1.1 ns.  In my experience, these two signals are usually the worst case
path in regards to using the BRAM at a high clock rate.  To get the best
performance, they do need to be taken out of the critical path, generally by wiring
them to a constant as mentioned.

So with all due respect (and you deserve plenty of that), I think these signals most
likely ARE the limiting parameters!


Peter Alfke wrote:

> Ray Andraka wrote:
>
> > The Block RAMs have fairly long tsu, th and tco numbers compared to the
> > CLB flip flops.
>
> According to the Virtex-II data published on the web:
>
> set-up time for Address or Data is 0.29 ns in speed grade -6 ( 25% longer in -4)
>
> set-up time for WE is 0.57 ns, and for EN it is 0.95 ns in speed grade -6 (
> again +25% in -4)
> All hold times are negative or specified as zero.
>
> Clock-to-out is 2.1 ns in -6
>
> So, I don't think the set-up times are the problem. The hold times definitely
> aren't.
> Clock-to-out and routing are probably the limiting parameters.
>
> Peter Alfke, Xilinx Applications

--
--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: 39221
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 4 Feb 2002 19:33:33 -0000
Links: << >>  << T >>  << A >>

"Ray Andraka" wrote

> Venu wrote:
>
> > Hi,
> >
> >  I am planning to implement a SDRAM Controller to run at 133MHz and I am
> >  targetting Virtex-II device. It would be of great help to me if people
> >  can let me know their experiences in this regard . More specifically I
> >  am looking for some inputs on the following:
> >
> >  a) Is this freq of 133MHZ for SDRAM Controller easily achievable in a
Virtex-II
> >     device
>
> Should be very easy to hit 133 Hz in VII.  Of course, it depends on your
design
> expertise, which is why I said "should" not "is".

And a single SDRAM bank is much easier to analyze and design than
two-bank or four-bank.





Article: 39222
Subject: Re: Destroying a CPLD by JTAG
From: Marcin E. Hamerla <mehamerla@pro.onet.pl>
Date: Mon, 04 Feb 2002 20:40:21 +0100
Links: << >>  << T >>  << A >>
Assaf Sarfati napisal(a):

>Since that download, we can't access the V-2 OR the CPLD with iMpact. When
>connecting, it recognizes (correctly) only the CPLD; if we try any operation
>on the CPLD (erasing, programming or whatever), we get a message "invalid
>device ID".
>
>Had anyone encountered this problem? is there any solution except removing the
>CPLD and soldering a new one? (get a bigger hammer...)

I had the same problem with Altera EPM7128S chip....

-- 
Pozdrowienia, Marcin E. Hamerla

"Nienawidze turystow."

Article: 39223
Subject: Re: Destroying a CPLD by JTAG
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 4 Feb 2002 19:41:40 -0000
Links: << >>  << T >>  << A >>

Assaf wrote

> Hi,
> We have a board with a Xilinx Virtex-2 FPGA and a 9500XL CPLD on it; they are
> chained on JTAG for programming (V-2 first, 9500 second).
>
> We've been happily working with this board, downloading V-2 and programming
> the 9500, using the iMpact tool from ISE 4.1 (SP3).
>
> We were synthesizing the CPLD with Synplicity, fitting it with ISE and
> programming as needed. One day, we've tried synthesizing the CPLD with XST.
> When we've downloaded it (no errors during synthesis or fitting), the CPLD
> didn't work.
>
> Since that download, we can't access the V-2 OR the CPLD with iMpact. When
> connecting, it recognizes (correctly) only the CPLD; if we try any operation
> on the CPLD (erasing, programming or whatever), we get a message "invalid
> device ID".

In my experience, Xilinx FPGA buffers will win most fights; I would
guess that the PAL is toast.

If you got to XST wia the WebPack Project Navigator, IMHO this tool
is far too obscure when it ignores the UCF.  I much prefer the
certainty of a MAKE file : "ngdbuild -uc foo.ucf ......"





Article: 39224
Subject: Xilinx synthesis tools
From: Arvin Patel <apatel@chello.no>
Date: Mon, 04 Feb 2002 19:45:47 GMT
Links: << >>  << T >>  << A >>
Does anyone have any experience with the latest version of
Xilinx XST? I would be interested in any comments on stability
of the tool and of the quality of results.

Does anyone have any comparisons of XST and Synopsys FPGA Express?
I have made some tests and it seems that XST gives slightly
better timing results than FPGA Express.

It seems from earlier postings that many people use Synplify.

Thanks in advance.
Arvin Patel







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