Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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: 42702Hi 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
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
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: 42705Hi! > 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 HansiArticle: 42706
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 > HansiArticle: 42707
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ørgeArticle: 42708
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.htmArticle: 42709
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, RenArticle: 42710
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
"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 343083Article: 42712
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 FAXArticle: 42713
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
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
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, > RenArticle: 42716
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 FAXArticle: 42717
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.seArticle: 42718
Hi, Anybody out here know about a available PHY for a 2.0 version USB ? There are enough announcements, but ... cheers & thanksArticle: 42719
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
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
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
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
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: 42724hi 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:
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