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 42700

Article: 42700
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: "Austin Franklin" <austin@dark87room.com>
Date: Wed, 1 May 2002 02:06:03 -0400
Links: << >>  << T >>  << A >>
Well, I seem to keep answering my own questions...  There is a paper on the
Xilinx web site:

http://www.xilinx.com/partinfo/3volt.pdf

that claims the Spartan output can safely drive a 3.3V device...even without
a series limiting resistor (if used in the default TTL mode).  Hum.
Comments?


"Austin Franklin" <austin@dark87room.com> wrote in message
news:ucv0nihlei4g2e@corp.supernews.com...
> I did check the Spartan vs Spartan XL pinouts...and they are the same
> (except for a few configuration pins), and obviously VCC has to change.  I
> measured the output of a Spartan to the DRAMs, and it was 4V+, so that's
not
> going to work...default is TTL, so I believe this is TTL output.  Looks
like
> I have to change to an XL...  My outputs have to be registered in the IOBs
> too, so that probably precludes my using any I/O open collector type
trick.
>
> Anyone know if the 5V PROMs will work fine with the SpartanXL part?
>
> "Austin Franklin" <austin@dark87room.com> wrote in message
> news:ucutbb7if6khe3@corp.supernews.com...
> > I have to update a board that has a Spartan on it that interfaces to
> memory.
> > The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From what
the
> > specs for the Spartan and memory say, the DRAM inputs to the Spartan
> aren't
> > a problem, but I am concerned about the outputs from the Spartan to the
> > DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns
> of
> > VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no max.
> >
> > Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
> Switching
> > to an XL isn't a really good option, as I do not believe they are pin
> > compatible with their non-XL counterpart (or are they, except for VCC
> > obviously, which is an easy change?) and the PCB routing etc. from the
old
> > design can be used, except for the DRAM to Spartan interface, and 3.3V
> > regulator, which are reasonably easy to re-do...
> >
> > Any experience/input (sic) would be greatly appreciated.
> >
> > Austin
> >
> >
> >
>
>



Article: 42701
Subject: synthesis error
From: Hassan_Mourad@lycos.com (Hassan Mourad)
Date: 1 May 2002 01:43:31 -0700
Links: << >>  << T >>  << A >>
Hi

i am having a problem in synthesing my model

i am using leonardo spectrum for synthesis

well as you all know , in synthesis , initial values of signals ,
variables or ports are ignored if they are assigned other values
within the code.

this is causing my problem , the following is a part of my model code
, and i'll state the problem after it.

Process(clk)
	type enc_array is array (0 to 7) of signed (63 downto 0);
	variable enc : enc_array;
	type dec_array is array (0 to 63) of signed (10 downto 0);
	variable dec : dec_array;
	variable l,w,x,y,s,k,r : integer :=0;
	variable z : integer :=63;
	variable eob,ac : integer :=0;
	Constant ones : signed(9 downto 0):="1111111111";
	Constant zeros : signed(9 downto 0):="0000000000";
	constant dc0 : signed (2 downto 0) :="010";
Begin	 

if load='1' then				
  if clk'event and clk='0' then
  enc(w):= encoded_data;				
  w:=w+1;
  end if;
elsif load='0' then
  if eob = 0 then 
    if clk'event and clk='1' then
      if ac=0 then					
        if z>1 then
          if enc(x)(z downto (z-2))=dc0 then
          dec(y):="00000000000";
          y:=y+1;
          z:=z-3;
          if z<0 then
          z:=63;
          x:=x+1;
          end if;
          end if;
       elsif z<=1 then
         if ((enc(x)(z downto 0))&(enc(x+1)(63 downto 63-(1-z))))=dc0
then
         dec(y):="00000000000";
         y:=y+1;
         z:=63-(1-z)-1;
         x:=x+1;
         end if;
       end if;
     end if;
   end if;
end if;
-------------------------------

ok , here is the problem , since synthesis ignores initial values , z
now is uninitialized , when trying to synthesis a line like >>
enc(x)(z downto (z-2)) , it gives me an error that says error : left
bound of range doesn't evaluate to a constant

and this applys only to all ranges that contains the index z , but not
to the conditions (i.e if z>1 ..... this is accepted for synthesis)

well i know the problem , it is that z must have an initial value ,
but how am i supposed to do so

please if anyone has any idea , reply asap , any help would be
apreciated.

thanx alot

P.S :load is a port defined in my design

Article: 42702
Subject: How can I test a downloaded design?
From: zisisj@yahoo.com (gianzi)
Date: 1 May 2002 01:52:18 -0700
Links: << >>  << T >>  << A >>
Hi all,
I have a Virtex xcv1000 laying on a board, and a Multilinx cable.
Can anyone tell me if there is some way to pass test vectors to a downloaded
design through Multilinx and the software provided by ISE 4.1, and also read
the outputs and save them in a file?
I really need any availiable help with this!

Article: 42703
Subject: Re: synthesis error
From: Alan Fitch <alan.fitch@doulos.com>
Date: Wed, 1 May 2002 10:06:23 +0100
Links: << >>  << T >>  << A >>
In article <253573e8.0205010043.357d8775@posting.google.com>, Hassan
Mourad <Hassan_Mourad@lycos.com> writes
>Hi
>
>i am having a problem in synthesing my model
>
>i am using leonardo spectrum for synthesis
>
>well as you all know , in synthesis , initial values of signals ,
>variables or ports are ignored if they are assigned other values
>within the code.
>
>this is causing my problem , the following is a part of my model code
>, and i'll state the problem after it.
>
>Process(clk)
>       type enc_array is array (0 to 7) of signed (63 downto 0);
>       variable enc : enc_array;
>       type dec_array is array (0 to 63) of signed (10 downto 0);
>       variable dec : dec_array;
>       variable l,w,x,y,s,k,r : integer :=0;
>       variable z : integer :=63;
>       variable eob,ac : integer :=0;
>       Constant ones : signed(9 downto 0):="1111111111";
>       Constant zeros : signed(9 downto 0):="0000000000";
>       constant dc0 : signed (2 downto 0) :="010";
>Begin   
>
>if load='1' then                               
>  if clk'event and clk='0' then
>  enc(w):= encoded_data;                               
>  w:=w+1;
>  end if;
>elsif load='0' then
>  if eob = 0 then 
>    if clk'event and clk='1' then
>      if ac=0 then                                     
>        if z>1 then
>          if enc(x)(z downto (z-2))=dc0 then
>          dec(y):="00000000000";
>          y:=y+1;
>          z:=z-3;
>          if z<0 then
>          z:=63;
>          x:=x+1;
>          end if;
>          end if;
>       elsif z<=1 then
>         if ((enc(x)(z downto 0))&(enc(x+1)(63 downto 63-(1-z))))=dc0
>then
>         dec(y):="00000000000";
>         y:=y+1;
>         z:=63-(1-z)-1;
>         x:=x+1;
>         end if;
>       end if;
>     end if;
>   end if;
>end if;
>-------------------------------
>
>ok , here is the problem , since synthesis ignores initial values , z
>now is uninitialized , when trying to synthesis a line like >>
>enc(x)(z downto (z-2)) , it gives me an error that says error : left
>bound of range doesn't evaluate to a constant
>
>and this applys only to all ranges that contains the index z , but not
>to the conditions (i.e if z>1 ..... this is accepted for synthesis)
>
>well i know the problem , it is that z must have an initial value ,
>but how am i supposed to do so
>
>please if anyone has any idea , reply asap , any help would be
>apreciated.
>
>thanx alot
>
>P.S :load is a port defined in my design

The simplest way is to implement a reset pin. Your code above almost
looks like it is using "load" as a reset. 

Generally, if you use an asynchronous reset, you should write a process
in the style

process(clk, reset)
begin
  if reset = '1' then
    
       -- reset stuff, e.g. z := 63

  elsif rising_edge(clk) then

     -- synchronous actions

  end if;

end process;

You should only have one clock edge per process.

Also I would declare integers constrained, otherwise you are relying on
the synthesis tool to remove unused bits. You can do this like this

variable z : integer range 0 to 63;  -- unsigned 6 bit
variable z2 : integer -32 to 31;     -- signed 6 bit

Think hardware!

regards

Alan


-- 
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                           Email: alan.fitch@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.









Article: 42704
Subject: Xilinx: delete file problem
From: "BÝrge Strand" <borges@ping.uio.no>
Date: Wed, 1 May 2002 12:00:38 +0200
Links: << >>  << T >>  << A >>
Yesterday I downloaded and installed the latest Xilinx WebPack. I also
printed out the "ISE 4 In-Depth Tutorial". So today I sit down and start all
from scratch with vhdl. My first Analyze Hierarcy yields the error message
below.

Is this what is supposed to happen? My installation is plain-vanilla, but I
had to make a bat-file wrapper around the exe file in order to start it with
the proper XILINX variable.

Best regards,
BÝrge Strand



ISE Auto-Make Log File
-----------------------

Updating: Analyze Hierarchy

Starting: 'exewrap -tapkeep -mode pipe -tcl -command
E:/PROGRA~1/XILINX~1/data/projnav/_filesAllClean.tcl _XSTClean.rsp 0'


Creating TCL Process
Cleaning Up Project
deleting directory: ./xst
The tcl interpreter reported the following error when executing the script
E:/PROGRA~1/XILINX~1/data/projnav/_filesAllClean.tcl
error deleting "./xst": permission denied
    while executing
"file delete -force $_Files"
    ("directory" arm line 4)
    invoked from within
"switch -exact $_Type {
         cleanup {
            if [regexp {\*} $_Files junk] {
               catch {glob -nocomplain $_Files} _FileList
      ..."
    ("foreach" body line 4)
    invoked from within
"foreach _line [split [read $_RspFileHandle] \n] {
      set _Type  [lindex $_line 0]
      set _Files [lrange $_line 1 [llength $_line]]
      switch ..."
    invoked from within
"if [catch {open $_RspFile r} _RspFileHandle] {
  puts "Cannot open $_RspFile: $_RspFileHandle"
  set _RetVal 1
} else {
   puts "Cleaning Up Project"
..."
    (file "E:/PROGRA~1/XILINX~1/data/projnav/_filesAllClean.tcl" line
41)Done: failed with exit code: 65535.




Article: 42705
Subject: Re: Xilinx: delete file problem
From: Johann Glaser <Johann.Glaser@gmx.at>
Date: Wed, 01 May 2002 12:16:18 +0200
Links: << >>  << T >>  << A >>
Hi!

> The tcl interpreter reported the following error when executing the
> script E:/PROGRA~1/XILINX~1/data/projnav/_filesAllClean.tcl error
> deleting "./xst": permission denied

I also had this problem when using WebPack. But my scenario was running
W2k inside a vmWare box in Linux and accessing a directory on my host
system from within Windows (via a Samba connection). So I thought this
makes the problem.

I resolved it by deleting this "xst" directory each time before I
implemented (or synthesized, can't remember) the FPGA with my xterm beside
the vmWare window. :-)

Bye
  Hansi

Article: 42706
Subject: Re: Xilinx: delete file problem
From: "BÝrge Strand" <borges@ping.uio.no>
Date: Wed, 1 May 2002 12:46:21 +0200
Links: << >>  << T >>  << A >>
Thanks Hansi

I tried to delete the directory manually (in cmd) and got permission denied.
But after I changed the NTFS file permissions it worked. Synthesize got
quite a bit further now!

What I suspect is that whatever program generates the xst directory does not
give it proper permissions on an NT/2K system. (I run W2K natively.) Do you
know what sets this directory up and what it is there for?

Regards,
BÝrge

"Johann Glaser" <Johann.Glaser@gmx.at> wrote in message
news:aaof81$cb6oa$1@ID-115042.news.dfncis.de...
> Hi!
>
> > The tcl interpreter reported the following error when executing the
> > script E:/PROGRA~1/XILINX~1/data/projnav/_filesAllClean.tcl error
> > deleting "./xst": permission denied
>
> I also had this problem when using WebPack. But my scenario was running
> W2k inside a vmWare box in Linux and accessing a directory on my host
> system from within Windows (via a Samba connection). So I thought this
> makes the problem.
>
> I resolved it by deleting this "xst" directory each time before I
> implemented (or synthesized, can't remember) the FPGA with my xterm beside
> the vmWare window. :-)
>
> Bye
>   Hansi



Article: 42707
Subject: Re: Xilinx: delete file problem
From: "BÝrge Strand" <borges@ping.uio.no>
Date: Wed, 1 May 2002 13:00:40 +0200
Links: << >>  << T >>  << A >>
Come to think of it, I have those files samba mounted too, from a
stand-alone linux file server. (So there's no vmware involved here.)

A fast ls -ld xst says:
drwx------    3 borges   users        4096 May  1 12:39 xst/
This is the same permission that all other files in the directory have. But
when I go back to W2K, select xst, and click properties->security, not a
single permission is marked.

Do you think this could be a Samba problem? It sure makes me curious.

Regards,
BÝrge



Article: 42708
Subject: JTAG programmer (ick!)
From: Russell <rjshaw@iprimus.com.au>
Date: Wed, 01 May 2002 11:31:17 GMT
Links: << >>  << T >>  << A >>
Hi,

I can't get my spartan2 thing to program. Using impact in win2k,
i can get toggles on pin 4 (TMS_IN) of the pc parallel port, but
no other pins toggle (not even pin 3, CLK). I'm using a copy of
a parallel-III jtag dongle. Could it be anything to do with win2k?
I'm using impact in webpack-4.2.

  http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/fig26.htm
  http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/jtg.htm

Article: 42709
Subject: Newbie--Where to start learning?
From: rlpreston@sbec.com (Ren)
Date: 1 May 2002 05:08:50 -0700
Links: << >>  << T >>  << A >>
I am nearly totally new to FPGAs and CPLDs but want to learn how to
program them. Where should I start? What books should I read? Which
manufacturer's products are most suited to a person just starting?

Thanks,
Ren

Article: 42710
Subject: Re: Newbie--Where to start learning?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 1 May 2002 14:59:38 +0100
Links: << >>  << T >>  << A >>
Everyone has their own favorite, but try www.optimagic.com

Ren wrote

> I am nearly totally new to FPGAs and CPLDs but want to learn how to
> program them. Where should I start? What books should I read? Which
> manufacturer's products are most suited to a person just starting?





Article: 42711
Subject: Re: SpartanIIE hold timing
From: "David Frith" <david.frith@ffei.co.uk>
Date: Wed, 1 May 2002 15:19:20 +0100
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3CCF08B1.E0DBA67A@yahoo.com...
> Then I have a couple of problems.
>
> 1) I am using all four of the global clock buffers (in fact I would like
> to use five or six).
>
> 2) Using a clock 90 degrees out of phase would give me an added 2.5nS of
> delay which would delay the data output by 2.5 nS.  This may be
> workable, but if the input clock is also delayed (advanced) by 2.5 nS,
> then it won't work unless the clock is slowed to 12.5 nS.  There is
> already very little margin on the read path.
>

Try this approach :-

Take a single input clock (eg 60 MHz) and feed it to the input of 2 DLL's.

Take the 2x clock output from the first DLL through a global clock buffer
and use this as your DLL feedback and as the 120 MHz FPGA clock to clock out
the SDRAM signals.

Take the 2x clock output from the second DLL through an output buffer and
onto an output pad. Use this clock to clock your SDRAM. Also feed this clock
back into an input pad via a trace on the PCB and use this signal as the DLL
feedback on the second DLL.

Because of this PCB trace, the SDRAM_CLK signal will be advanced from the
internal FPGA clock signal so that you can meet the hold time you require at
the expense of  setup time. Adjust the amount of hold time by the length of
trace but watch you don't have a problem clocking the SDRAM data signals
back into the FPGA.

This uses both DLL's but just one global clock buffer.

Works for us.

Best regards

David Frith,
Principal Engineer,
Fujifilm Electronic Imaging,
Hemel Hempstead, Herts, HP2 7RH. UK.
Email: david.frith@ffei.co.uk
Tel: (+44)(0)1442 343083






Article: 42712
Subject: Re: Availability of XC2S150E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 01 May 2002 10:32:33 -0400
Links: << >>  << T >>  << A >>
I heard back from the Rep today.  Xilinx is giving everyone the same
story.  No XC2S150E parts of any flavor until July.  In fact, I received
an email from someone at Xilinx support saying that this is only an
estimated date and that they won't be setting firm dates until the end
of May.  

All this is after I received a quote from Insight back in March saying I
could have commercial temp parts in 5-6 weeks.  Insight said that got
this info directly from Xilinx.  So I don't understand what happened.  

We have slipped a month on our schedule already due to changes in the
design.  Now we will have to slip another two months, maybe more due to
lack of availability of the Xilinx parts.  



roy wrote:
> 
> Send an order to the rep. instead of the disti. he may be able to expedite.
> I've done this and it sometimes works.
> You also may get access to to the product manager in this way.
> Roy.
> 
> rickman wrote:
> 
> > I have been trying to get my hands on some pieces of XC2S150E-6FG456I
> > for over a month.  I am told that they will not be shipping until June
> > and I need to get about four pieces for prototypes in a month.  I can
> > buy the commercial temp versions, but we need the industrial temp
> > versions for this version of the board.
> >
> > I have tried working with distis and they keep saying that Xilinx won't
> > give them parts until June no matter how much they beg.  I have
> > contacted the rep and they keep talking about placing an order so that
> > it can be expedited.  But what is the point of placing an order if I
> > can't get delivery when I need it?
> >
> > Anyone know how to get your hands on a small number of ES chips prior to
> > the official release?
> >
> > I was able to get some chips from the Coolrunner product manager under
> > these same conditions awhile back.  But I don't have a way to contact
> > the SpartanIIE product manager.


-- 

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

Article: 42713
Subject: Re: simultaneous switching of LVPECL outputs
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 01 May 2002 07:55:38 -0700
Links: << >>  << T >>  << A >>
Bob,

Simple.  The outputs pull all the way to Vcc, and to ground.  The switches are not
current sources at all, but on and off switches with ~ 7 ohms on resistance.  The
current is going to flow through the IO pin, through to the ground connections, and
the Vcco connections.  Just because one is going up when the other is going down
doesn't mean they will cancel:  the delay from the pad to the package pin (25 ps to
125 ps), and to the external resistors is slightly different for each.  The loading
is slightly different on each as a result.  As well, there is a crossover current in
a CMOS output driver that flows from Vcco to ground when switching hi, or low, and
that is unaffected by this arrangement.

So, the lab explains exactly what we expect to happen.

I agree that mysteries are a bad thing, and we always drill down until we explain a
result completely.

Austin


Bob Perlman wrote:

> Austin -
>
> I know they're conventional single-ended I/Os; I thought I made that
> clear in my analysis (I assumed that the drivers both source and sink
> current; real PECL drivers only source current).   I'm not sure why
> you mentioned LVDS drivers, but they also source and sink.
>
> If you're not seeing lower ground bounce for Spartan IIE
> differerential LVPECL in the lab, it would be useful to figure out
> why.  If you're not seeing lower ground bounce, I have to wonder if
> the true and complementary transitions are simultaneous or
> near-simultaneous.  If they're not, that could spell big trouble for
> the receiver.
>
> When lab results are counter-intuitive, it pays to find out why.
>
> Bob Perlman
> -----
> Cambrian Design Works
> http://www.cambriandesign.com
>
> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea
> <austin.lesea@xilinx.com> wrote:
>
> >Bob,
> >
> >These are still plain old single ended IOs, and as measured in the lab, there is
> >virtually no difference in ground bounce from a regular single ended IO.
> >
> >LVDS in Virtex II and Virtex II Pro are current sink and source differential
> >drivers, and there is actually a large benefit from such drivers.
> >
> >Austin
> >
> >Bob Perlman wrote:
> >
> >> Austin -
> >>
> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
> >> <austin.lesea@xilinx.com> wrote:
> >>
> >> >Bob,
> >> >
> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there
> >> >is no benefit from differential switching as regards to ground bounce.  Each
> >> >single ended IO is already switching rail to rail, and driving hard.  Thus
> >> >even though some of the current flows out comes back in on the other pin, a
> >> >lot of current is flowing through power and ground.
> >> >
> >> >Austin
> >>
> >> The original poster wanted to use Spartan IIE which, if I'm reading
> >> the data sheet correctly, supports LVPECL differential outputs
> >> terminated with 100 ohms across the two signals.
> >>
> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
> >> 1.06-1.43V, or~ 1.25V typical.  This means that the current through
> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.
> >>
> >> When the differential signal switches, one driver switches from source
> >> to sink, while the other switches from sink to source.  On the ground
> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while
> >> the other slews from sinking nothing to sinking 8.5mA.  Similar things
> >> happen on the VCC side, except that current is being sourced rather
> >> than sunk.
> >>
> >> Beyond a certain point, the strength of the drivers is moot; the
> >> current into or out of the I/O pin will be limited by the transmission
> >> line impedance.  If we think of the differential lines as two 50-ohm
> >> single-ended lines, the current needed to send a 0.85V delta V down
> >> each line is 17mA, which is exactly the delta you get when you stop
> >> sourcing 8.5mA and start sinking it, or vice versa.
> >>
> >> The balance isn't perfect, but the net di/dt on either the VCC or
> >> ground paths should be considerably less than for single-ended
> >> signals.
> >>
> >> Bob Perlman
> >> -----
> >> Cambrian Design Works
> >> http://www.cambriandesign.com
> >>
> >> >
> >> >Bob Perlman wrote:
> >> >
> >> >> Hi -
> >> >>
> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
> >> >> <hicksthe@egr.msu.edu> wrote:
> >> >>
> >> >> >Hi,
> >> >> >    I am seriously considering using a spartan2e to serve as a clock
> >> >> >distribution generator for a lvpecl clock system.  This clock system
> >> >> >will be driving a total of 17 differential clocks.  When I price the
> >> >> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
> >> >> >me the clock DLL to clean up my system clock.  The question is that I
> >> >> >have a total of 34 output lines that should be switching at the same
> >> >> >time.  The spec says 12 power and ground pairs in the chip and 3
> >> >> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
> >> >> >pair for me.)  How do I split these up over the 12 power/ground pairs?
> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
> >> >> >I get 12 power/ground pairs from these 24 pins?
> >> >>
> >> >> If you're using differential outputs, the power and ground di/dt
> >> >> should be significantly less than what you'd see for single-ended
> >> >> signals.  Assuming that the true and complementary transitions occur
> >> >> in unison, one driver should be increasing its ground or VCC current
> >> >> as the other driver's current is decreasing.  The match isn't perfect,
> >> >> but it should be pretty good.
> >> >>
> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less
> >> >> stringent than the  guidelines for single-ended signals.
> >> >>
> >> >> Bob Perlman
> >> >> -----
> >> >> Cambrian Design Works
> >> >> http://www.cambriandesign.com
> >> >>


Article: 42714
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 01 May 2002 07:59:16 -0700
Links: << >>  << T >>  << A >>
Austin,

I don't suppose you would consider an IBIS simulation?

Call the hotline, ask them to simulate your two chips talking to one another if
you do not have an IBIS simulator of your own.  Or call the Xilinx FAE.  They
all have copies of Hyperlynx. Or, post back here the part numbers of the two
parts that are talking to one another, and if I get a chance, I will simulate it
and post the result.

Austin

Austin Franklin wrote:

> Well, I seem to keep answering my own questions...  There is a paper on the
> Xilinx web site:
>
> http://www.xilinx.com/partinfo/3volt.pdf
>
> that claims the Spartan output can safely drive a 3.3V device...even without
> a series limiting resistor (if used in the default TTL mode).  Hum.
> Comments?
>
> "Austin Franklin" <austin@dark87room.com> wrote in message
> news:ucv0nihlei4g2e@corp.supernews.com...
> > I did check the Spartan vs Spartan XL pinouts...and they are the same
> > (except for a few configuration pins), and obviously VCC has to change.  I
> > measured the output of a Spartan to the DRAMs, and it was 4V+, so that's
> not
> > going to work...default is TTL, so I believe this is TTL output.  Looks
> like
> > I have to change to an XL...  My outputs have to be registered in the IOBs
> > too, so that probably precludes my using any I/O open collector type
> trick.
> >
> > Anyone know if the 5V PROMs will work fine with the SpartanXL part?
> >
> > "Austin Franklin" <austin@dark87room.com> wrote in message
> > news:ucutbb7if6khe3@corp.supernews.com...
> > > I have to update a board that has a Spartan on it that interfaces to
> > memory.
> > > The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From what
> the
> > > specs for the Spartan and memory say, the DRAM inputs to the Spartan
> > aren't
> > > a problem, but I am concerned about the outputs from the Spartan to the
> > > DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns
> > of
> > > VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no max.
> > >
> > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
> > Switching
> > > to an XL isn't a really good option, as I do not believe they are pin
> > > compatible with their non-XL counterpart (or are they, except for VCC
> > > obviously, which is an easy change?) and the PCB routing etc. from the
> old
> > > design can be used, except for the DRAM to Spartan interface, and 3.3V
> > > regulator, which are reasonably easy to re-do...
> > >
> > > Any experience/input (sic) would be greatly appreciated.
> > >
> > > Austin
> > >
> > >
> > >
> >
> >


Article: 42715
Subject: Re: Newbie--Where to start learning?
From: "BÝrge Strand" <borges@ping.uio.no>
Date: Wed, 1 May 2002 17:00:08 +0200
Links: << >>  << T >>  << A >>
I was all new to this too, until yesterday! What I did was download WebPack
from Xilinx and start working on it with the tutorial I found at
http://www.support.xilinx.com/support/techsup/tutorials/index.htm However,
I've found what looks like bugs in the VHDL part of tutorial, and WebPack
does not let you generate cores. But IMHO a slightly flawed tutorial is a
far greater teacher than a perfect one.

Also, getting WebPack started on W2K is a little tricky. I start it from a
.bat file looking like this:
set XILINX=E:\PROGRA~1\XILINX~1
%XILINX%\bin\nt\webpack

Regards,
BÝrge

"Ren" <rlpreston@sbec.com> wrote in message
news:3602cff7.0205010408.103cdaff@posting.google.com...
> I am nearly totally new to FPGAs and CPLDs but want to learn how to
> program them. Where should I start? What books should I read? Which
> manufacturer's products are most suited to a person just starting?
>
> Thanks,
> Ren



Article: 42716
Subject: Re: SpartanIIE hold timing
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 01 May 2002 11:46:29 -0400
Links: << >>  << T >>  << A >>
David Frith wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:3CCF08B1.E0DBA67A@yahoo.com...
> > Then I have a couple of problems.
> >
> > 1) I am using all four of the global clock buffers (in fact I would like
> > to use five or six).
> >
> > 2) Using a clock 90 degrees out of phase would give me an added 2.5nS of
> > delay which would delay the data output by 2.5 nS.  This may be
> > workable, but if the input clock is also delayed (advanced) by 2.5 nS,
> > then it won't work unless the clock is slowed to 12.5 nS.  There is
> > already very little margin on the read path.
> >
> 
> Try this approach :-
> 
> Take a single input clock (eg 60 MHz) and feed it to the input of 2 DLL's.
> 
> Take the 2x clock output from the first DLL through a global clock buffer
> and use this as your DLL feedback and as the 120 MHz FPGA clock to clock out
> the SDRAM signals.
> 
> Take the 2x clock output from the second DLL through an output buffer and
> onto an output pad. Use this clock to clock your SDRAM. Also feed this clock
> back into an input pad via a trace on the PCB and use this signal as the DLL
> feedback on the second DLL.
> 
> Because of this PCB trace, the SDRAM_CLK signal will be advanced from the
> internal FPGA clock signal so that you can meet the hold time you require at
> the expense of  setup time. Adjust the amount of hold time by the length of
> trace but watch you don't have a problem clocking the SDRAM data signals
> back into the FPGA.
> 
> This uses both DLL's but just one global clock buffer.
> 
> Works for us.
> 
> Best regards
> 
> David Frith,

We can't do that because the FPGA is not the source of the clock
signal.  We can delay the clock for use inside the FPGA, but we can't
send a delayed or advanced clock to the SDRAM or the SBSRAM.  

<rant mode on>

I am really ticked off about this and the availability issue on the
XC2S150E.  Xilinx claims to support several dozen IO interface standards
electrically, and then fails to support the most common memory timing
interface in the world.  Instead they criticize the industry use of
input hold times and jump on the high horse of "we don't need no
stink'in input hold times" and we won't provide any output hold times.  

Then on top of it all, while I am trying to expedite the delivery of a
few engineering samples of the XC2S150E in the industrial temp range, I
am told that "BTW, ya know those commercial parts that the distributor
quoted you 6 week lead time?  You won't be getting those any time soon
either".  In fact I received an email from Xilinx support yesterday
saying that they really haven't even made up their minds yet about
delivery schedules and won't until the end of May!!!

<rant mode off (at least in public)>

Let's just say that my schedule is very negatively impacted.  


<rant mode back on>

AND PLEASE DON'T TELL ME I CAN DESIGN WITH THE XC2S200E UNTIL THE
XC2S150E PARTS ARE OUT.  I need to ship boards to a customer and the
lifetime cost of supporting two flavors of FPGA is exceeded only by the
lifetime cost of using the XC2S200E part on all of the boards in place
of the XC2S150E.  

At this point my only alternative is to use the XC2S200E for in house
prototyping, wait for the XC2S150E chips to ship (without even knowing
when that will be) and then finally ship product to our customer at
least two months late.  

I don't know why I ever belive distibution...

<rant mode back off>

At least I have plenty of development time now.   :)

If I weren't such a nice guy, I would have some nasty things to say...


-- 

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

Article: 42717
Subject: Re: Availability of XC2S150E-6FG456I
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 01 May 2002 18:09:09 +0200
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> We have slipped a month on our schedule already due to changes in the
> design.  Now we will have to slip another two months, maybe more due to
> lack of availability of the Xilinx parts.  

Buy a bigger one while you wait?

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

Article: 42718
Subject: usb 2.0 on FPGAs
From: emanuel stiebler <emu@ecubics.com>
Date: Wed, 01 May 2002 10:19:33 -0600
Links: << >>  << T >>  << A >>
Hi,
Anybody out here know about a available PHY for a 2.0 version USB ?
There are enough announcements, but ...

cheers & thanks

Article: 42719
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: "Austin Franklin" <austin@dark87room.com>
Date: Wed, 1 May 2002 12:25:47 -0400
Links: << >>  << T >>  << A >>
 Hi Austin,
Thanks for the offer! It would be great if you could give me a definite
answer!

Xilinx part is XCS30-4PQ240C and the DRAM is a Micron MT 4LC4M16R6TG-6.
There is a 33.2 ohm resistor on the address, RAS and CAS pins. Data pins, OE
and WE are hooked up directly.

Any more info you need, please let me know.

Regards,

Austin

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3CD002C4.F40E80B4@xilinx.com...
> Austin,
>
> I don't suppose you would consider an IBIS simulation?
>
> Call the hotline, ask them to simulate your two chips talking to one
another if
> you do not have an IBIS simulator of your own.  Or call the Xilinx FAE.
They
> all have copies of Hyperlynx. Or, post back here the part numbers of the
two
> parts that are talking to one another, and if I get a chance, I will
simulate it
> and post the result.
>
> Austin
>
> Austin Franklin wrote:
>
> > Well, I seem to keep answering my own questions...  There is a paper on
the
> > Xilinx web site:
> >
> > http://www.xilinx.com/partinfo/3volt.pdf
> >
> > that claims the Spartan output can safely drive a 3.3V device...even
without
> > a series limiting resistor (if used in the default TTL mode).  Hum.
> > Comments?
> >
> > "Austin Franklin" <austin@dark87room.com> wrote in message
> > news:ucv0nihlei4g2e@corp.supernews.com...
> > > I did check the Spartan vs Spartan XL pinouts...and they are the same
> > > (except for a few configuration pins), and obviously VCC has to
change.  I
> > > measured the output of a Spartan to the DRAMs, and it was 4V+, so
that's
> > not
> > > going to work...default is TTL, so I believe this is TTL output.
Looks
> > like
> > > I have to change to an XL...  My outputs have to be registered in the
IOBs
> > > too, so that probably precludes my using any I/O open collector type
> > trick.
> > >
> > > Anyone know if the 5V PROMs will work fine with the SpartanXL part?
> > >
> > > "Austin Franklin" <austin@dark87room.com> wrote in message
> > > news:ucutbb7if6khe3@corp.supernews.com...
> > > > I have to update a board that has a Spartan on it that interfaces to
> > > memory.
> > > > The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From
what
> > the
> > > > specs for the Spartan and memory say, the DRAM inputs to the Spartan
> > > aren't
> > > > a problem, but I am concerned about the outputs from the Spartan to
the
> > > > DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and
15ns
> > > of
> > > > VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no
max.
> > > >
> > > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
> > > Switching
> > > > to an XL isn't a really good option, as I do not believe they are
pin
> > > > compatible with their non-XL counterpart (or are they, except for
VCC
> > > > obviously, which is an easy change?) and the PCB routing etc. from
the
> > old
> > > > design can be used, except for the DRAM to Spartan interface, and
3.3V
> > > > regulator, which are reasonably easy to re-do...
> > > >
> > > > Any experience/input (sic) would be greatly appreciated.
> > > >
> > > > Austin
> > > >
> > > >
> > > >
> > >
> > >
>



Article: 42720
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 01 May 2002 09:29:21 -0700
Links: << >>  << T >>  << A >>
Austin,

Working on it.

I have to figure out how to simulate the 5V driving the 3.3 v part.  It isn't
obvious to me how to do it.  I will figure it out.  It may be the version I have
is the IC Designers verfication version so it doesn't have that feature.  I have
asked for someone who has the full version to get back to me.

If the full version can't do that, I will have to complain to someone.....pretty
basic thing to simulate.

The IBIS file was easy to find for the part, however, on the Micron website.

Austin

Austin Franklin wrote:

>  Hi Austin,
> Thanks for the offer! It would be great if you could give me a definite
> answer!
>
> Xilinx part is XCS30-4PQ240C and the DRAM is a Micron MT 4LC4M16R6TG-6.
> There is a 33.2 ohm resistor on the address, RAS and CAS pins. Data pins, OE
> and WE are hooked up directly.
>
> Any more info you need, please let me know.
>
> Regards,
>
> Austin
>
> "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> news:3CD002C4.F40E80B4@xilinx.com...
> > Austin,
> >
> > I don't suppose you would consider an IBIS simulation?
> >
> > Call the hotline, ask them to simulate your two chips talking to one
> another if
> > you do not have an IBIS simulator of your own.  Or call the Xilinx FAE.
> They
> > all have copies of Hyperlynx. Or, post back here the part numbers of the
> two
> > parts that are talking to one another, and if I get a chance, I will
> simulate it
> > and post the result.
> >
> > Austin
> >
> > Austin Franklin wrote:
> >
> > > Well, I seem to keep answering my own questions...  There is a paper on
> the
> > > Xilinx web site:
> > >
> > > http://www.xilinx.com/partinfo/3volt.pdf
> > >
> > > that claims the Spartan output can safely drive a 3.3V device...even
> without
> > > a series limiting resistor (if used in the default TTL mode).  Hum.
> > > Comments?
> > >
> > > "Austin Franklin" <austin@dark87room.com> wrote in message
> > > news:ucv0nihlei4g2e@corp.supernews.com...
> > > > I did check the Spartan vs Spartan XL pinouts...and they are the same
> > > > (except for a few configuration pins), and obviously VCC has to
> change.  I
> > > > measured the output of a Spartan to the DRAMs, and it was 4V+, so
> that's
> > > not
> > > > going to work...default is TTL, so I believe this is TTL output.
> Looks
> > > like
> > > > I have to change to an XL...  My outputs have to be registered in the
> IOBs
> > > > too, so that probably precludes my using any I/O open collector type
> > > trick.
> > > >
> > > > Anyone know if the 5V PROMs will work fine with the SpartanXL part?
> > > >
> > > > "Austin Franklin" <austin@dark87room.com> wrote in message
> > > > news:ucutbb7if6khe3@corp.supernews.com...
> > > > > I have to update a board that has a Spartan on it that interfaces to
> > > > memory.
> > > > > The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From
> what
> > > the
> > > > > specs for the Spartan and memory say, the DRAM inputs to the Spartan
> > > > aren't
> > > > > a problem, but I am concerned about the outputs from the Spartan to
> the
> > > > > DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and
> 15ns
> > > > of
> > > > > VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no
> max.
> > > > >
> > > > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
> > > > Switching
> > > > > to an XL isn't a really good option, as I do not believe they are
> pin
> > > > > compatible with their non-XL counterpart (or are they, except for
> VCC
> > > > > obviously, which is an easy change?) and the PCB routing etc. from
> the
> > > old
> > > > > design can be used, except for the DRAM to Spartan interface, and
> 3.3V
> > > > > regulator, which are reasonably easy to re-do...
> > > > >
> > > > > Any experience/input (sic) would be greatly appreciated.
> > > > >
> > > > > Austin
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> >


Article: 42721
Subject: Re: simultaneous switching of LVPECL outputs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Wed, 01 May 2002 17:02:20 GMT
Links: << >>  << T >>  << A >>
Austin - 

I think we're going in circles here.  I mentioned in my first post
that the cancellation wouldn't be perfect, but that there would be
some, and that I'd expect it to be significant.

I can agree with your results if:

(a) the true and complement transitions are significantly skewed (bad
news for the receiver) 

(b) crossover current is a significant fraction of the current being
sourced or sunk by the driver through the I/O pin, and lasts for a
significant fraction of the rise/falltime. ( I thought that this
wasn't the case for modern driver designs.  Can you give more
information on duration/amplitude?)

(c) both.

Can you clarify something?  You've said that:
  - driver impedance is 7 ohms
  - drivers switch from rail to rail

How do 7-ohm rail-to-rail drivers connected to 3.3V produce 0.85V
across a 100 ohm load?

Bob Perlman
-----
Cambrian Design Works
http://www.cambriandesign.com

On Wed, 01 May 2002 07:55:38 -0700, Austin Lesea
<austin.lesea@xilinx.com> wrote:

>Bob,
>
>Simple.  The outputs pull all the way to Vcc, and to ground.  The switches are not
>current sources at all, but on and off switches with ~ 7 ohms on resistance.  The
>current is going to flow through the IO pin, through to the ground connections, and
>the Vcco connections.  Just because one is going up when the other is going down
>doesn't mean they will cancel:  the delay from the pad to the package pin (25 ps to
>125 ps), and to the external resistors is slightly different for each.  The loading
>is slightly different on each as a result.  As well, there is a crossover current in
>a CMOS output driver that flows from Vcco to ground when switching hi, or low, and
>that is unaffected by this arrangement.
>
>So, the lab explains exactly what we expect to happen.
>
>I agree that mysteries are a bad thing, and we always drill down until we explain a
>result completely.
>
>Austin
>
>
>Bob Perlman wrote:
>
>> Austin -
>>
>> I know they're conventional single-ended I/Os; I thought I made that
>> clear in my analysis (I assumed that the drivers both source and sink
>> current; real PECL drivers only source current).   I'm not sure why
>> you mentioned LVDS drivers, but they also source and sink.
>>
>> If you're not seeing lower ground bounce for Spartan IIE
>> differerential LVPECL in the lab, it would be useful to figure out
>> why.  If you're not seeing lower ground bounce, I have to wonder if
>> the true and complementary transitions are simultaneous or
>> near-simultaneous.  If they're not, that could spell big trouble for
>> the receiver.
>>
>> When lab results are counter-intuitive, it pays to find out why.
>>
>> Bob Perlman
>> -----
>> Cambrian Design Works
>> http://www.cambriandesign.com
>>
>> On Tue, 30 Apr 2002 14:23:09 -0700, Austin Lesea
>> <austin.lesea@xilinx.com> wrote:
>>
>> >Bob,
>> >
>> >These are still plain old single ended IOs, and as measured in the lab, there is
>> >virtually no difference in ground bounce from a regular single ended IO.
>> >
>> >LVDS in Virtex II and Virtex II Pro are current sink and source differential
>> >drivers, and there is actually a large benefit from such drivers.
>> >
>> >Austin
>> >
>> >Bob Perlman wrote:
>> >
>> >> Austin -
>> >>
>> >> On Tue, 30 Apr 2002 10:01:09 -0700, Austin Lesea
>> >> <austin.lesea@xilinx.com> wrote:
>> >>
>> >> >Bob,
>> >> >
>> >> >Spartan 2 uses external resistor networks to get the LVPECL levels, so there
>> >> >is no benefit from differential switching as regards to ground bounce.  Each
>> >> >single ended IO is already switching rail to rail, and driving hard.  Thus
>> >> >even though some of the current flows out comes back in on the other pin, a
>> >> >lot of current is flowing through power and ground.
>> >> >
>> >> >Austin
>> >>
>> >> The original poster wanted to use Spartan IIE which, if I'm reading
>> >> the data sheet correctly, supports LVPECL differential outputs
>> >> terminated with 100 ohms across the two signals.
>> >>
>> >> The VOH range is 1.92-2.28V, or ~2.1V typical; the VOL range is
>> >> 1.06-1.43V, or~ 1.25V typical.  This means that the current through
>> >> the terminating resistor is approximately (2.1V-1.25V)/100 = 8.5mA.
>> >>
>> >> When the differential signal switches, one driver switches from source
>> >> to sink, while the other switches from sink to source.  On the ground
>> >> side, one driver slews from sinking 8.5 mA to sinking nothing, while
>> >> the other slews from sinking nothing to sinking 8.5mA.  Similar things
>> >> happen on the VCC side, except that current is being sourced rather
>> >> than sunk.
>> >>
>> >> Beyond a certain point, the strength of the drivers is moot; the
>> >> current into or out of the I/O pin will be limited by the transmission
>> >> line impedance.  If we think of the differential lines as two 50-ohm
>> >> single-ended lines, the current needed to send a 0.85V delta V down
>> >> each line is 17mA, which is exactly the delta you get when you stop
>> >> sourcing 8.5mA and start sinking it, or vice versa.
>> >>
>> >> The balance isn't perfect, but the net di/dt on either the VCC or
>> >> ground paths should be considerably less than for single-ended
>> >> signals.
>> >>
>> >> Bob Perlman
>> >> -----
>> >> Cambrian Design Works
>> >> http://www.cambriandesign.com
>> >>
>> >> >
>> >> >Bob Perlman wrote:
>> >> >
>> >> >> Hi -
>> >> >>
>> >> >> On Tue, 30 Apr 2002 11:34:47 -0400, Theron Hicks
>> >> >> <hicksthe@egr.msu.edu> wrote:
>> >> >>
>> >> >> >Hi,
>> >> >> >    I am seriously considering using a spartan2e to serve as a clock
>> >> >> >distribution generator for a lvpecl clock system.  This clock system
>> >> >> >will be driving a total of 17 differential clocks.  When I price the
>> >> >> >LVPECL chips the spartan2e looks very competetive.  Also, it would give
>> >> >> >me the clock DLL to clean up my system clock.  The question is that I
>> >> >> >have a total of 34 output lines that should be switching at the same
>> >> >> >time.  The spec says 12 power and ground pairs in the chip and 3
>> >> >> >simulatneous outputs per pair.  Thus a total of 36 outputs. (one spare
>> >> >> >pair for me.)  How do I split these up over the 12 power/ground pairs?
>> >> >> >I count 16 grounds and 8 VCC0 on the tq144 package (XC2S50E).  Where do
>> >> >> >I get 12 power/ground pairs from these 24 pins?
>> >> >>
>> >> >> If you're using differential outputs, the power and ground di/dt
>> >> >> should be significantly less than what you'd see for single-ended
>> >> >> signals.  Assuming that the true and complementary transitions occur
>> >> >> in unison, one driver should be increasing its ground or VCC current
>> >> >> as the other driver's current is decreasing.  The match isn't perfect,
>> >> >> but it should be pretty good.
>> >> >>
>> >> >> Ask Xilinx for diff pair power/ground guidelines; they should be less
>> >> >> stringent than the  guidelines for single-ended signals.
>> >> >>
>> >> >> Bob Perlman
>> >> >> -----
>> >> >> Cambrian Design Works
>> >> >> http://www.cambriandesign.com
>> >> >>


Article: 42722
Subject: Re: Spartan outputs to 3.3V DRAMs...
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 01 May 2002 10:15:38 -0700
Links: << >>  << T >>  << A >>
Well, I wrote that apper. The idea is that (in TTL output mode only!), there is
no p-channel output transistor pulling to Vcc, but rather an n-channel
transistor. Therefore the output voltage will pull towards a value one threshold
below Vcc, and as it approaches that value, the output will be weak, so it
cannot do any harm to the input it's driving.
This was written before the days of IBIS.
I still stand behind this paper, even if the issue is a bit touchy.

Peter Alfke, Xilinx Applications
==============================
Austin Franklin wrote:

> Well, I seem to keep answering my own questions...  There is a paper on the
> Xilinx web site:
>
> http://www.xilinx.com/partinfo/3volt.pdf
>
> that claims the Spartan output can safely drive a 3.3V device...even without
> a series limiting resistor (if used in the default TTL mode).  Hum.
> Comments?
>
> "Austin Franklin" <austin@dark87room.com> wrote in message
> news:ucv0nihlei4g2e@corp.supernews.com...
> > I did check the Spartan vs Spartan XL pinouts...and they are the same
> > (except for a few configuration pins), and obviously VCC has to change.  I
> > measured the output of a Spartan to the DRAMs, and it was 4V+, so that's
> not
> > going to work...default is TTL, so I believe this is TTL output.  Looks
> like
> > I have to change to an XL...  My outputs have to be registered in the IOBs
> > too, so that probably precludes my using any I/O open collector type
> trick.
> >
> > Anyone know if the 5V PROMs will work fine with the SpartanXL part?
> >
> > "Austin Franklin" <austin@dark87room.com> wrote in message
> > news:ucutbb7if6khe3@corp.supernews.com...
> > > I have to update a board that has a Spartan on it that interfaces to
> > memory.
> > > The memory I have to use is 3.3V LVTT, changed from 5V TTL.  From what
> the
> > > specs for the Spartan and memory say, the DRAM inputs to the Spartan
> > aren't
> > > a problem, but I am concerned about the outputs from the Spartan to the
> > > DRAM.  The DRAM says it can tolerate VCC (3.3V) + .3V, or 3.6V (and 15ns
> > of
> > > VCC + 1.6V).  The TTL output from the Spartan is min 2.4V, with no max.
> > >
> > > Anyone have any experience interfacing a Spartan to a 3.3Vmemory?
> > Switching
> > > to an XL isn't a really good option, as I do not believe they are pin
> > > compatible with their non-XL counterpart (or are they, except for VCC
> > > obviously, which is an easy change?) and the PCB routing etc. from the
> old
> > > design can be used, except for the DRAM to Spartan interface, and 3.3V
> > > regulator, which are reasonably easy to re-do...
> > >
> > > Any experience/input (sic) would be greatly appreciated.
> > >
> > > Austin
> > >
> > >
> > >
> >
> >


Article: 42723
Subject: Duplicating IOB FFs Without I/O Pads Being Inserted in XST
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Wed, 01 May 2002 13:45:07 -0500
Links: << >>  << T >>  << A >>
        Here is a problem I got in which I cannot seem to find an
answer.
Rather than synthesizing my PCI IP core over and over each time I make
modifications to the backend, I will like to instantiate a netlist
version of my PCI IP core from the backend design files to save time.
To do so, I will declare a blackbox on the backend side, and NGDBUILD
will automatically glue the necessary modules together.
The problem I found was, when I synthesize my PCI IP core separately
with "Add I/O Buffers" option of XST unchecked, XST will not duplicate
output and OE (Output Enable) FFs for my design which is expected.
So, to force XST to duplicate output and OE FFs, I decided to reduce
those FFs' max. fanout to 1, and turn on register duplication, which
should result in FFs getting duplicated with only 1 fanout.
A single fanout is a must for those FFs to get pushed into IOBs, but
when I try to restrict the max. fanout to 1, XST seems to get stuck
during a netlist generation part of the synthesis. (At the end.)
After some trials, I noticed that when the max. fanout is 1 for output
FFs, XST will get stuck, but when it is 2, it doesn't seem to get stuck.
For OE FFs, max. fanout of 1 doesn't seem to cause problems.
I can see the results at MAP, but when I check the fanout of those FFs
through Floorplanner (After P&R), the fanout of OE FFs is 2, one going
towards the pin and another one going towards a LUT for data retention
(A feedback path for data retention.), therefore, these OE FFs don't get
pushed into IOBs.
For output FFs, the max. fanout was 2, so they do have 2 fanouts, and
they won't make into IOBs even if IOB = TRUE attribute was added in a
.UCF file.
At least for OE FFs, what I expected was . . . , one of the duplicated
FFs to be used for data retention, and the one will have a single fanout
towards the pin, but it doesn't seem to happen. 
Actually, the duplicated ones have a single fanout, so XST seems to be
following my synthesis constraints to some extent, but it is not totally
following it since I got OE FFs with 2 fanouts.
I wish I can force those duplicated single fanout FFs to go towards the
pin, but it is headed towards some LUT, and attaching IOB = TRUE doesn't
help either.
        Anyhow, has anyone successfully duplicated output and OE FFs in
an HDL-based design when I/O buffers were not inserted?
I am sure what I described here can be done really easily in schematics,
but that is not an option in my case.
I read a posting at news:comp.arch.fpga sometime ago that in
LeonardoSpectrum (I hate that tool because the GUI is so buggy. I have
only tried an Altera OEM version, and not a full version.) to duplicate
a FF to be pushed into an IOB, the fanout has to be 1.
        Going back to the motivation of what I am trying to do, the real
reason I will like to have my PCI IP core in a netlist is because I will
like to attach it to a VHDL-based design, and I hate to have to redo my
PCI IP core in VHDL.




Thanks,



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 42724
Subject: free core DSTN LCD controller VHDL?
From: "Philipper CHAGNY" <philippe.chagny@free.fr>
Date: Wed, 1 May 2002 21:03:35 +0200
Links: << >>  << T >>  << A >>
hi all,

i search a free VHDL core to control a DSTN LCD panel

any idea ?

thank's
Philippe





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