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 79400

Article: 79400
Subject: Re: Question about microblaze C complier
From: jon@beniston.com (Jon Beniston)
Date: 18 Feb 2005 06:59:10 -0800
Links: << >>  << T >>  << A >>
> Normally C stractures are aligned on a 4 byte addresses boundaries.

For MicroBlaze, maybe.

> But usually in communication application there is a need to parse
> messages buffers with fields that are aligned on a single byte basis.
> I know on other CPUs that there is a #pragma commands that allow a
> definition of structures as "packed".
> 
> Does anyone knows how to define packed structures on Microblaze C
> compiler? 

Probably.

> and if so can you provide an example?

__attribute__((packed))

It's in the GCC manual.

Cheers,
Jon

Article: 79401
Subject: Re: Updated Stratix II Power Specs & Explanation
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 18 Feb 2005 08:11:23 -0800
Links: << >>  << T >>  << A >>
Vaughn,

I am sorry, but you have never run a spice simulation of midox pass 
transistor vs thin ox.

I would refrain from opening mounth and removing all doubt.

Austin

Vaughn Betz wrote:
> Peter,
> 
> Pass transistors are timing critical in FPGAs.  Using a thicker oxide 
> reduces Cox, and transistor drive strength is linearly proportional to Cox. 
> Much like increasing Vt, you can control leakage, but there is a speed cost 
> to be paid.
> 
> Otherwise I agree with everything you said though!
> 
> Vaughn Betz
> Altera
> [v b e t z (at) altera.com]
> 
> 
> "Peter Alfke" <peter@xilinx.com> wrote in message 
> news:1108669563.714735.314660@f14g2000cwb.googlegroups.com...
> 
>>I hope everybody here realizes that there is no trade-off between
>>triple gate oxide and low-k dielectric. They reside on different
>>"floors" of the vertical IC structure.
>>
>>The availability of a third oxide thickness at the transistor level
>>(ground floor) gives the designer the freedom to reduce leakage current
>>in pass transistors (where it does not affect speed) and in
>>configuration memory, where lower speed is actually desirable. We at
>>Xilinx think it is a great tool to reduce leakage current without any
>>performance loss, specially in FPGAs where certain (millions of)
>>transistors would benefit from being slow.
>>
>>Low K dielectric (at the upper floors) hasnothing to do with the
>>transistors, since it is used only in the  layers of interconnect well
>>above the transistors. It is obviously desirable to lower parasitic
>>capacitance, as long as it can be done with good yield and without loss
>>of reliability. Different foundries have different approaches and
>>different attitudes.
>>
>>Thicker high-K dielectric in the gate oxide (ground floor) would
>>actually be desirable, since it would reduce gate leakage current, but
>>it does not seem to be a mature process yet ( I have been told. I'm not
>>an expert).
>>
>>We are all chasing the holy grail of high performance at low (or at
>>least reasonable) static and dynamic power consumption.
>>
>>Peter Alfke
>>
> 
> 
> 

Article: 79402
Subject: Re: Updated Stratix II Power Specs & Explanation
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 18 Feb 2005 08:15:30 -0800
Links: << >>  << T >>  << A >>
Ahhhh,

So I am dealing with a physicist.  They seem to be the only ones that 
think everything is so simple, and models are so perfect.

No wonder we can't seem to communicate.

I will start listening (and responding) when you design a few IC's. 
Then you will have some credibility (with me).

Til then, enjoy your fantasy world,

Austin

Vaughn Betz wrote:

> Austin,
> 
> Nice bafflegab.
> 
> 1.  I have the spec for the dielectric and conductor stack for the 90 nm 
> process we're using in front of me.  I wrote field solvers for my Master's 
> degree and commercially before I saw the light and switched to FPGAs for my 
> PhD.  So I really don't need an "ICDES expert" to explain metal stacks or RC 
> extraction to me.
> 
> 2.  The metal stack is dominated by low-K.
> 
> 3.  Lateral capacitance is reduced by low-K, since you use low-K between the 
> wires on a layer.  Since lateral capacitance dominates in deep submicron 
> (e.g. 90 nm), without doing this, low-K would be fairly pointless.
> 
> 4.  Having "regular k" between metal 1 and the substrate still means even 
> metal 1 gains most of the benefit of low-K, since sidewall (lateral) 
> capacitance dominates, and you use low-K between the metal1 wires.  Plus you 
> reduce the (smaller) capacitance to metal 2.
> 
> 5. Metal resistance does not impact power.  You can prove this fairly simply 
> mathematically.
> 
> 6. Metal resistance impacts speed, although not that much in FPGAs since the 
> wires are rebuffered so often.  However, since delay = RC (lumped 
> approximation), that pesky C is still in there and reducing it gives you a 
> linear speedup on the distributed RC delay of the metal wires.
> 
> 7. The simulations showing what we got from low-K vs. high-K were detailed, 
> and agreed with measured data from the sample chips we ran (yes, we run 
> chips on different variants of the process too).
> 
> Vaughn Betz
> Altera
> [v b e t z (at) altera.com]
> 
> "Austin Lesea" <austin@xilinx.com> wrote in message 
> news:cv2h98$bai2@cliff.xsj.xilinx.com...
> 
>>Vaughn,
>>
>>Well, you certainly have been fooled.
>>
>>See below,
>>
>>Austin
>>
>>Vaughn Betz wrote:
>>
>>>"Austin Lesea" <austin@xilinx.com> wrote in message 
>>>news:cuvptt$baj6@cliff.xsj.xilinx.com...
>>>
>>>
>>>>Vaugn,
>>>>
>>>>Shell and pea game:  no, you do not get the entire benefit of reduced C.
>>>
>>>
>>>The entire benefit would be 19% speed and dynamic power reduction.  As I 
>>>said, we get about 2/3 of that maximum benefit, since not all C is metal 
>>>C, but most is.
>>>
>>>
>>>>Also, not all layer dielectrics are Lo-K.  For example, the clock tree is 
>>>>near the top, where regular dielectric is used, isn't it?
>>>
>>>
>>>We use low-k to near the top of the metal stack.  At the very top, where 
>>>you're routing power and ground, you don't need (or even want it), since 
>>>high capacitance on power and ground is beneficial (helps prevent ground 
>>>bounce & vcc sag).  The vast majority of the switching capacitance 
>>>(clocks, routing, ALMs, MACs, etc.) is in metal surrounded by low-k.
>>
>>I doubt it.  The dielectric above the transistors is regular undoped glass 
>>(SiO2).  K = 4.3.  Then comes the lo-K after M1.  M1 through M5 is all 
>>they can do as lo-K, if they do more, it sufffers major yield and 
>>reliability issues.  Of maybe you haven't noticed the delamination yet?
>>
>>>
>>>>At least, we evaluated both with, and without Lo-K devices (from the same 
>>>>masks and fab), and were surprised to see only a 5% improvement.
>>>>
>>>>Did you do the same experiment?  We were surprised.
>>>
>>>
>>>We simulated everything with and without low-K, and got the ~13% 
>>>improvement
>>
>>Nope.  You did not.  If you did, you would discover that the layer above 
>>the transistors and below metal 1, as well as the upper layers for clocks, 
>>etc. leads to less than expected improvements.  I am pretty sure your 
>>ICDES folks just scaled everything.  It would be a major project to 
>>develop, and QC spice models for both processes, and I seriously doubt 
>>anyone would bother.
>>
>>
>>
>>>I previously mentioned.  I am also surprised you got only 5%.  That is 
>>>certainly well below mainstream for the industry -- if everyone were 
>>>seeing such small gains,
>>
>>which they are.
>>
>> I doubt the fabs and semiconductor equipment vendors would
>>
>>>be pumping billions into developing low-k (and next generation 
>>>extra-low-k) dielectrics.
>>
>>The only folks making money on this are the equipment suppliers.  No one I 
>>know asked for it.  Yes, it can be a major benefit to ASIC, uP, and 
>>perhaps memories.  But, it just isn't doing anything for us.  Now, we will 
>>get lo-K for free, as they have the equipment and process now, butguess 
>>what?  We still do not see more than a 5% improvement from V4 without lo-K 
>>to V4 with lo-K.  Wow, two generations and two sets of side by side lo-K 
>>and regular experiments.
>>
>>Ignorance I guess is bliss.
>>
>>
>>  Sounds like you may have used low-k for only a few metal
>>
>>>layers, so perhaps that explains your disappointing experience.
>>
>>Nope,as I described, the only layers alloed to be lo-K for lifetime 
>>delamination issues and quality are the ones above M1, and below M5. 
>>Anymore than that, and we have see problems with fab process qual (not on 
>>our parts, but their test structures).
>>
>>
>>>
>>>>Turns out, there is a lot more in the equations that just C.
>>>>
>>>>If it was just that simple, extracted simulations in spice would be 
>>>>unneeded.
>>>
>>>
>>>This is backwards.  As metal capacitance has become the dominant 
>>>capacitance, extracting layouts to obtain all the metal parasitics before 
>>>running SPICE has become essential to getting accurate answers.  Go back 
>>>enough process generations and this was less true -- you could write up 
>>>your transistor-level schematic in a SPICE deck, simulate it with no 
>>>thought of metal, and you wouldn't be that far off for most circuits, 
>>>since transistor parasitics dominated.  Now that metal dominates, you 
>>>have to extract layouts to get the metal C or you get bad answers.
>>
>>I can see you really have no clue about where the wire models are going. 
>>How thick is the metal, how thick is the dielectric?  How close are the 
>>wires?  There is R there (and lots of it).  There is C there, too. There 
>>is also side wall C (the sidewalls are regular FSG, or SiO2 -- no lo-K 
>>advantage).
>>
>>Again, you go back and ask if they actually had foundry models for with, 
>>and without, and what the actual stack up was.  One of the biggest 
>>overstatements we have seen recently is all of this nonsense about the 
>>superiority of lo-K.
>>
>>Its nice, don't get me wrong, but don't tout it as a miracle if you have 
>>never proven it is.  You don't know.  We do.
>>
>>Take the time to do it right, or at least study it right.  Get an ICDES 
>>wire model expert to talk to you about where the lo-K is, and isn't.
>>
>>
>>>Vaughn Betz
>>>Altera
>>>[v b e t z (at) altera.com]
>>>
> 
> 

Article: 79403
Subject: Re: Is Altera Cyclone a good choice ?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 18 Feb 2005 08:21:25 -0800
Links: << >>  << T >>  << A >>
Alessandro,

I would request their qualification documents (both process qual, and 
product qual), and arrange to go over them with their Reliability VP or 
director.  Only then can you make an informed decision.

Asking that question here is not going to reveal this information to 
you, only a full reading of the qual reports will supply you with that 
knowledge.

Look for the results of HTOL (high temperature operating life), and how 
they calculate lifetime and wear-out.  Also, number of cycles of 
self-heating and cooling is vitally important, because externally making 
the device hot and cold is not asa stressfull as the device itself 
making itself hot (and cold).

By the way, we would be happy to supply you with that information, and 
discuss it with you for Sprtan 2E, or Spartan 3 (or any other Xilinx 
product).

Austin

Alessandro Strazzero wrote:

> Dear everybody,
> 
> the goal of my post is to collect your opinions about the use of Altera Cyclone
> devices in a rugged environment. I have to design a board which should control
> a chopper based on GTOs. The environment is a railway vehicle and the following
> are the conditions I have to consider:
> 
> - extreme temperature range (-40°C to +85°C)
> - strong mechanical vibrations
> - long life duration (> 25 years)
> - high degree of reliability
> - very low frequency of maintenance
> 
> From the point of view of the design I think Altera Cyclone is the best choise
> for this kind of project beacuse its high flexibility. But I have some doubts
> about its functionality in a rugged environment like above.
> 
> Did you experience the use of Altera Cyclone in a rugged environment ? 
> What are your opinions about my choise ?
> 
> Best Regards
> 
> /Alessandro Strazzero

Article: 79404
Subject: Re: OPB <-> WhishBone wrapper (opb_wb_wrapper at opencores)
From: "Jonathan Dumaresq" <jdumaresq@cimeq.qc.ca_nospam>
Date: Fri, 18 Feb 2005 16:46:15 GMT
Links: << >>  << T >>  << A >>

"Sylvain Munaut" <tnt_at_246tNt_dot_com@reducespam.com> a écrit dans le 
message de news: 42150d44$0$28532$ba620e4c@news.skynet.be...
>
>>>>
>>>>When I look at the system.pbd, I expected to to see a new bus for the 
>>>>wb. But i did'nt see it. I don't know if we need to see it or not.
>>>
>>>No you won't see a new bus. This wrapper just export all wishbone bus
>>>signals as port. Then you need to connect them manually.
>>
>>
>> How can i connect them manualy ?
>
> Use the "Port" tab in the "add/edit cores" dialog windows like what you 
> use to
> connect clock & reset signals together ...
>
> Connect all signals like "wb_stb_i" to the "wb_stb_o" of the other core, 
> pretty
> easy ...
>
>
>
> Sylvain

Yea that is what i have done. I have plugged all the net together and for 
the gpio wb_clk_i  plug to  the sys_clk_s and wb_rst to sys_rst_s.

I have remove the led part of the edk project and want to replace it with 
the wb_gpio. So i have connected all the wire to the real pin on the fpga in 
the ucf file.

Now i woule like to know how can i write to the wb_gpio register.

This is what i think that should be modify:

change the wb_gpio address to 0x2000000 ? or change the wrapper to the 
address of the wb_gpio ?

I probably miss something again or this is suppose to work like i describe ?

regards

Jonathan




Article: 79405
Subject: Using c++ with xilinx EDK tools
From: Stef <stefanoc@comsine.co.uk>
Date: Fri, 18 Feb 2005 17:11:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

We're trying to compile C++ code to run on a xilinx microblaze platform. 
  Most things work OK, but we seem to be failing to use some of the 
standard templates (see code snippet below).

It would appear that none of the string methods are used or functional. 
  Has anyone come across this issue and succesfully found a resolution?

Thanks,

Stef

void string_test()
{
    string str1;
    string *str2 = new string();
    char str3[] = "Hello world\n";
    char *str4 = new char[100];

    str2->assign (str3);
    str1.assign (str3, strlen(str3));

    strcpy(str4, "My world!");

    printf("str1 = %s\n",str1.c_str());
    printf("str2 = %s\n",str2->c_str());
    printf("str3 %s\n", str3);
    printf("str4 [%p] = %s\n",str4, str4);
}

results in the following output:

str1 =
str2 =
str3 Hello world
str4 [0x80032a0c] = My world!

Article: 79406
Subject: Xilinx: Pitfalls of chaining DLLs
From: Stephen Williams <spamtrap@icarus.com>
Date: Fri, 18 Feb 2005 09:19:44 -0800
Links: << >>  << T >>  << A >>

We have a design that uses a chain of DLLs internally. That is,
the output from one DLL is fed to the input of another DLL.
I'm not the designer in this case, but I do want to understand
the implications of this. Can anybody point me to the right APP
notes or search keywords at the Xilinx site for this?

A specific question about the Jitter specification; Does the
DLL *add* jitter to any input clock, or is the output jitter the
max of input and documented output jitter? (This is Virtex-II.)
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Article: 79407
Subject: edk and xilinx multimedia board
From: Joerg Ritter <ritter@informatik.uni-halle.de>
Date: Fri, 18 Feb 2005 19:08:03 +0100
Links: << >>  << T >>  << A >>
Hi,
maybe an faq:

Where is the .xbd file matching the xilinx multimedia board ?
There are some files under <path to edk>/board/Xilinx

./boards
./boards/Xilinx_AFX_V2P_FG456
./boards/Xilinx_AFX_V2P_FG456/data
./boards/Xilinx_AFX_V2P_FG456/data/Xilinx_AFX_V2P_FG456_v2_1_0.xbd
./boards/Xilinx_ML300
./boards/Xilinx_ML300/data
./boards/Xilinx_ML300/data/Xilinx_ML300_v2_1_0.xbd


version used edk6.2
os: linux

Thanks
Joerg

Article: 79408
Subject: Re: binary constant divider theory
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 18 Feb 2005 19:16:20 +0100
Links: << >>  << T >>  << A >>
"SD" <sourabh.dhir@gmail.com> schrieb im Newsbeitrag
news:1108700783.719360.228940@l41g2000cwc.googlegroups.com...
> Falk,
>
> Thanks for the input. What if my design is a pure combination logic
> (unregistered), I mean no clocks. So now whatever the synthesis report
> gives me, is it still way off the mark??

More or less. The problem is, that the timing analyzys after synthesis has
no clue about placement and routing. Yes, it can estimate an average
placement/routing delay, but this is still not really a valueable number. If
you want to know the propagation delay of your logic, use timing constaints
like

TIMESPEC "TS_my_delay"  = FROM PADS TO PADS 20ns;

This will tell te timing analyzer that you  need a combinatorical delay of
20ns or less from all input pads to all output pads.
You can also have a look into the asynchrounous delay report, it listas all
net delays. But can be tricky in a big design.

Regards
Falk




Article: 79409
Subject: Re: Updated Stratix II Power Specs & Explanation
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 18 Feb 2005 19:23:13 +0100
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag
news:cv54b2$pqa1@cliff.xsj.xilinx.com...

> So I am dealing with a physicist.  They seem to be the only ones that
> think everything is so simple, and models are so perfect.

Another round in the eternal battle between theory and practive ;-))

> No wonder we can't seem to communicate.
>
> I will start listening (and responding) when you design a few IC's.
> Then you will have some credibility (with me).
>
> Til then, enjoy your fantasy world,

What is PI?

Mathematican : "Its the Quotient between a circles's circumference and its
diameter with the value 3.1415927blablabla"
Physicist: "Its 3.1415927 +/- 0.000001"
Engineer: "Something around three"

Regards
Falk




Article: 79410
Subject: Re: CRC-4 algorithm using in G.704(&G.706)
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 18 Feb 2005 19:25:50 +0100
Links: << >>  << T >>  << A >>

"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> schrieb im
Newsbeitrag news:8klb11hi4jqsnkaci10im0s5ih31tm8at8@4ax.com...

> >>>Can anyone tell me embedding of SUBJ? I've tried a lot of
> >>>methods(recommendations in G.704(1998&1995); i've read the theory of
> >>>CRC calculating and made some entities but CRC from my E1 tester
> >>>doesn't match with mine. I've tried another tester - no changes).

Do a google search for "CRC explained"

Regards
Falk

P.S. Iam not sure now about the detail of CRC4 in E1, but be aware that some
bit are not included in the calcualtion??!





Article: 79411
Subject: Re: Xilinx: Pitfalls of chaining DLLs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 18 Feb 2005 19:31:11 +0100
Links: << >>  << T >>  << A >>

"Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag
news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...

> We have a design that uses a chain of DLLs internally. That is,
> the output from one DLL is fed to the input of another DLL.
> I'm not the designer in this case, but I do want to understand
> the implications of this. Can anybody point me to the right APP
> notes or search keywords at the Xilinx site for this?
>
> A specific question about the Jitter specification; Does the
> DLL *add* jitter to any input clock, or is the output jitter the

Yes it does. Feed it with a crystal clear clock, and you will get somewhere
+/- 200ps jitter.
Cascading two DLLs is possible and works quite good, at least if your design
has some timing margin. if you multiply a 25 MHz clock to 100 MHz and your
timing analyzer gives you a minimum period of 9.99ns, you dont have enough
timing margin. There is a nice TechXclusive about this very topic from
Austin on the Xilinx website.

> max of input and documented output jitter? (This is Virtex-II.)

Virtex-II is more complicated, since it has the more advanced DCM, which can
do more than simple clock doubling. But every setting om M/N causes
different jitter characterisics.

Regards
Falk




Article: 79412
Subject: Re: Make program stop
From: Ann <ann.lai@analog.com>
Date: Fri, 18 Feb 2005 10:39:53 -0800
Links: << >>  << T >>  << A >>
Hi, I didn't mean stop completely but just stop what it's doing, but now that I think about it, I guess I can just make it output some kind of default value or something. But what about get it to pop up a message "DONE" or "ERROR" or something so that the user can see? Thanks, Ann

Article: 79413
Subject: Re: DNL and INL calculation
From: AL <ann.lai@analog.com>
Date: Fri, 18 Feb 2005 10:43:18 -0800
Links: << >>  << T >>  << A >>
Hi, I am sending an 8 bit ramp to the FPGA, this intepolation stuffs, does anyone have example code or application notes or something or does Spartan3 have this function built in somewhere? Thanks, Ann

Article: 79414
Subject: Re: Help on a FPGA design
From: AL <ann.lai@analog.com>
Date: Fri, 18 Feb 2005 11:24:13 -0800
Links: << >>  << T >>  << A >>
Hi, thanks for all the help. The application on Reconfiguring block of RAMs was very helpful, and also app139. I thought I already have it figured out, but I am running into a weird problem with this bscan_spartan3 module. When I put a constant number into the register and read it back, it works, but when I have that number changed depending on the rising edge of the clock, and a RESET signal or something, it doesn't work anymore. For example, in the following code: always @(posedge CLK_IN) begin					 	if(RESET) 	begin 		num = 20+1; 	end 	else				 	begin 		num = 1+1; 	end It would give me 00010011 or 21 even though the RESET signal has changed. I tried using the CASE statement instead: always @(posedge CLK_IN) begin	 case(RESET) 	2'd0: num = 20+1; 	2'd1: num = 2+2; 	default: num = 3+4; 	endcase end Now it always gives me 00000000 when I tried to read it back. Do you have any idea why? Thanks, Ann

Article: 79415
Subject: Re: PPC 405 in Virtex 2 Pro 30-Turning off "Critical-word first"
From: Nju Njoroge <njoroge@stanford.edu>
Date: Fri, 18 Feb 2005 11:53:38 -0800
Links: << >>  << T >>  << A >>
Thanks Peter. This suggestion worked. For those who are interested, I had
to add my own signal, IP2Bus_RdWdAddr coming from the "user_logic" module
in the slave pcore that intercepted the plb ipif slave signal,
Sl_rdwdaddr[0:3]. I had to set the bits of Sl_rdwaddr[1:3] =
IP2Bus_RdWdAddr. Additionally, I had to delay the signal of
IP2Bus_RdWdAddr by one clock cycle because the PLB  IPIF module asserts
the Read Ack on the PLB bus and Sl_rdwaddr one cycle after the user_logic asserts
IP2Bus_RdAck.
On Thu, 17 Feb 2005, Peter Ryser wrote:

> Nju,
>
> PLBC405DCURDWDADDR[1:3] must be driven to the PPC in the order in which
> you deliver the data.
>
> See the PPC processor block manual for more detail.
>
> - Peter
>
>
> Nju Njoroge wrote:
> > Hello,
> >
> > I'm trying to disable "Critical-word first" loads for cache loads. That
> > is, when the cache is performing a cache refill, it first loads the target
> > data from memory, then loads the remaining words in the cacheline from
> > memory--all as part of a burst transaction. I'm looking for a way to
> > disable this type of cache fill. Instead, I would like the cache to load
> > the cacheline starting from the base address of the cacheline. Any one
> > tried this before? The reference guide claims that the PLB memory
> > controller can send back the data in the order it desires
> > (http://www.xilinx.com/bvdocs/userguides/ppc_ref_guide.pdf, page 146).
> > However, in reality, when my PLB slave pcore sends back the data in order
> > of ascending addresses, the processor assumes that I sent it back the
> > target data first, so it uses the wrong word.
> >
> > Thanks,
> >
> > NN
> >
> >
> >
>
>




Article: 79416
Subject: Re: Xilinx: Pitfalls of chaining DLLs
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 18 Feb 2005 11:56:16 -0800
Links: << >>  << T >>  << A >>
Stephen,

The user's guide details the rules for chaining DLL's and DCM's.

Generally speaking, a chain of two is allowed.

Chains of three are discouraged.

A CLK0, 90, 180, 270, may drive a CLKIN of the second DCM (CLKDV, CLK2X, 
CLKFX of the first stage may have too much jitter for the next stage -- 
if you check, and it is low jitter, then it is allowed).

Austin

Stephen Williams wrote:
> 
> We have a design that uses a chain of DLLs internally. That is,
> the output from one DLL is fed to the input of another DLL.
> I'm not the designer in this case, but I do want to understand
> the implications of this. Can anybody point me to the right APP
> notes or search keywords at the Xilinx site for this?
> 
> A specific question about the Jitter specification; Does the
> DLL *add* jitter to any input clock, or is the output jitter the
> max of input and documented output jitter? (This is Virtex-II.)

Article: 79417
Subject: Re: Xilinx: Pitfalls of chaining DLLs
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 18 Feb 2005 20:21:16 GMT
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:37ms1nF5et71bU4@individual.net...
>
> "Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag
> news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...
< snip >
> > A specific question about the Jitter specification; Does the
> > DLL *add* jitter to any input clock, or is the output jitter the
>
> Yes it does. Feed it with a crystal clear clock, and you will get
somewhere
> +/- 200ps jitter.
<snip>

The term "add" might be misinterpreted here.  If (using exagerated numbers
for illustration) a DLL generates 1 ns jitter and feeds a second DLL capable
of tracking the input jitter and "adding" another 1 ns of jitter, the
resulting jitter should be 1.414 ns, not 2.0.

It's been pointed out on this board before that the DLLs tend to generate
nice jitter spectra rather than the "spikey" results one might expect from a
DDS.  Also pointed out is that the jitter is additive in the sense that RMS
signals are added:  square, add, sqaure root.



Article: 79418
Subject: Re: DNL and INL calculation
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sat, 19 Feb 2005 09:45:46 +1300
Links: << >>  << T >>  << A >>
AL wrote:

> Hi, I am sending an 8 bit ramp to the FPGA, this intepolation stuffs, does anyone have example code or application notes or something or does Spartan3 have this function built in somewhere? Thanks, Ann

You will need to be clearer.
You _do_ have an external Analog To Digital converter, which you are 
trying to test ?

The FPGA itself has NO ADC features, so DNL and INL are meaningless 
applied to a specific FPGA - but you can build an ADC using the FPGA for 
the Digital portions :

** Sigma-Delta ADC with the simple integrator/charge balance/Vref 
devices external
** Successive approximation, needs external Vref, DAC + comparitor
** Fast Tracking ADC - needs external Vref, DAC + comparitor
** Slow Tracking ADC, can use a PWM output, and low pass filter + compatitor

If you want to test an ADC, the simplest way is to wire a better one
in parallel. That way, you can specfiy fractional values for INL and 
DNL. You might also want to specify SFDR - look at other ADC specs.

If your ADC is very high spec, and you cannot find a better one, then
you can use a DAC, or use a PWM DAC in the FPGA, to generate ramps down
to the analog noise floor, and use that to verify your ADC.

-jg


Article: 79419
Subject: Issues with a batch of Virtex-II chips
From: "IgI" <igorsath@hotmail.com>
Date: Fri, 18 Feb 2005 21:55:42 +0100
Links: << >>  << T >>  << A >>
Hi!

I'm using Virtex-II (XC2V1000-FF896-4C) in one of the product which we have
been selling for over 3 years. Recently we got "new" batch of Virtex-II
chips and problems started to arise. So far I have isolated PCBs with three
different batch of Virtex-II chips:

Batch A:
XC2V1000
FF896AFT0301
F1247582A
4C
Philippines

Batch B:
XC2V1000
FF896AGT0409
D2169507A
4C
Taiwan

Batch C:
XC2V1000
FF896AFT0205
F1205613A
4C
Philippines

All the chips in batch A have the suffix AFT301, all the chips in batch B
have the suffix AGT0409,...
PCBs with chips from batch B and C are working fine, on the other hand none
of the 42 PCBs, where chips from batch A are used are working. PCBs are the
same (same revision) for all the products, all other components (ZBTRAMs,
DDR SDRAMS, passive components,....) are the same. All voltages are within
the safe margins, all input clocks are clean. All the affected boards pass
the JTAG test, in other words we didn't find any soldering errors, short
circuits, vias without metallization, wrong resistors or capacitors,
incorrectly oriented diodes or capacitors... or any other error we could
think of. We got all the chips in a sealed package. PCBs were tested at
different temperatures (from 8 degrees Celsius to 46). Only the PCBs with
chips from batch A don't work. Let me explain what precisely is not working.

I'm using 6 DCMs  to generate clocks for ZBTRAM, DDR, System, ConfigBus,...
and two DCMs don't set the locked signal after I release them sequentially
from reset. I don't know if other parts of the design (the parts which don't
use ZBTRAM clock) don't work either, because the missing clock is a fatal
error and I didn't have the time to investigate further in that direction.
Working freq. of ZBTRAM is 120MHz, DDR is working at 166MHz, System at
100MHz, ConfigBus at 10MHz,...

We are currently using ISE 5.2 SP3 for this design. I have verified the bit
stream by reading it back from the chip and it's ok.
Two coworkers, guys from the production and I are working on solving this
problem for the last two days and we are almost out of ideas what else we
could try, except replace the problematic chips with the non-problematic. I
can't use ISE 6.1 or newer because the routing is not successful or ISE
simply doesn't meet the timing constraints (the chip is 99% full).

Have you experienced anything similar in the past? How did you solve the
problem? Do you have any ideas/suggestions what else I could try? I couldn't
find any document on the xilinx web site explaining the detailed chip
signatures. I would like to know, what AFT0301 stands for? Is this the
product date, production line, factory code...? I would like to know, when
the chips have been manufactured (how old are they)?

I guess we'll have a competition in the company next week. And the goal will
be; who can throw virtex-II the farthest... Ok, I'm just joking, but I
needed to vent...argh...


Igor Bizjak



Article: 79420
Subject: Re: Issues with a batch of Virtex-II chips
From: "Vladislav Muravin" <xfilex2003@hotmail.com>
Date: Fri, 18 Feb 2005 16:25:59 -0500
Links: << >>  << T >>  << A >>
Igor,

Vow, this is very similar to what i have experienced a couple of days ago.
I did not try, however, to look for different "batch"s, as you did, because
i think that all of our FPGAs
are XC2V2000/3000 676AGT0405, i think.

So in my design, i am cascading 4 DCMs.
But i am not using their LOCK indication, because i am only interested in
some large fractional M/N frequency synthesis,
and the input frequency is less than 24 MHz
( I assume that you are not using any DCM outputs for input clock less than
24 MHz)

The problem was that the last DCM was not generating the desired frequency,
but exactly either 1/8 or 1/16 of it.
It was looking like the reset was applied for too short period of time (but
it was for more than 3-4 input clocks!)

So this problem was resolved by defining a reset registers for each PLL, and
asserting/deasserting the reset by the software (or some delay implemented
in FPGA by some large counter) in chain.

I assume this is this is different from what you've experienced, but hope
this helps.

Sincerely,



Vladislav Muravin

Senior FPGA Design Engineer

Advantech AMT (Advanced Microwave Technologies)

657 Orly Avenue

Dorval H9P 1G1

Quebec, Canada

Tel: (514) 420-0045 ext. 240

Fax: (514) 420-0073

http://www.advantechamt.com





Finally, i noted that

"IgI" <igorsath@hotmail.com> wrote in message
news:hDsRd.9283$F6.1757212@news.siol.net...
> Hi!
>
> I'm using Virtex-II (XC2V1000-FF896-4C) in one of the product which we
have
> been selling for over 3 years. Recently we got "new" batch of Virtex-II
> chips and problems started to arise. So far I have isolated PCBs with
three
> different batch of Virtex-II chips:
>
> Batch A:
> XC2V1000
> FF896AFT0301
> F1247582A
> 4C
> Philippines
>
> Batch B:
> XC2V1000
> FF896AGT0409
> D2169507A
> 4C
> Taiwan
>
> Batch C:
> XC2V1000
> FF896AFT0205
> F1205613A
> 4C
> Philippines
>
> All the chips in batch A have the suffix AFT301, all the chips in batch B
> have the suffix AGT0409,...
> PCBs with chips from batch B and C are working fine, on the other hand
none
> of the 42 PCBs, where chips from batch A are used are working. PCBs are
the
> same (same revision) for all the products, all other components (ZBTRAMs,
> DDR SDRAMS, passive components,....) are the same. All voltages are within
> the safe margins, all input clocks are clean. All the affected boards pass
> the JTAG test, in other words we didn't find any soldering errors, short
> circuits, vias without metallization, wrong resistors or capacitors,
> incorrectly oriented diodes or capacitors... or any other error we could
> think of. We got all the chips in a sealed package. PCBs were tested at
> different temperatures (from 8 degrees Celsius to 46). Only the PCBs with
> chips from batch A don't work. Let me explain what precisely is not
working.
>
> I'm using 6 DCMs  to generate clocks for ZBTRAM, DDR, System,
ConfigBus,...
> and two DCMs don't set the locked signal after I release them sequentially
> from reset. I don't know if other parts of the design (the parts which
don't
> use ZBTRAM clock) don't work either, because the missing clock is a fatal
> error and I didn't have the time to investigate further in that direction.
> Working freq. of ZBTRAM is 120MHz, DDR is working at 166MHz, System at
> 100MHz, ConfigBus at 10MHz,...
>
> We are currently using ISE 5.2 SP3 for this design. I have verified the
bit
> stream by reading it back from the chip and it's ok.
> Two coworkers, guys from the production and I are working on solving this
> problem for the last two days and we are almost out of ideas what else we
> could try, except replace the problematic chips with the non-problematic.
I
> can't use ISE 6.1 or newer because the routing is not successful or ISE
> simply doesn't meet the timing constraints (the chip is 99% full).
>
> Have you experienced anything similar in the past? How did you solve the
> problem? Do you have any ideas/suggestions what else I could try? I
couldn't
> find any document on the xilinx web site explaining the detailed chip
> signatures. I would like to know, what AFT0301 stands for? Is this the
> product date, production line, factory code...? I would like to know, when
> the chips have been manufactured (how old are they)?
>
> I guess we'll have a competition in the company next week. And the goal
will
> be; who can throw virtex-II the farthest... Ok, I'm just joking, but I
> needed to vent...argh...
>
>
> Igor Bizjak
>
>



Article: 79421
Subject: Re: Xilinx: Pitfalls of chaining DLLs
From: "Bob" <nimby1_notspamm_@earthlink.net>
Date: Fri, 18 Feb 2005 21:27:27 GMT
Links: << >>  << T >>  << A >>

"John_H" <johnhandwork@mail.com> wrote in message
news:07sRd.12$rp4.630@news-west.eli.net...
> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
> news:37ms1nF5et71bU4@individual.net...
> >
> > "Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag
> > news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...
> < snip >
> > > A specific question about the Jitter specification; Does the
> > > DLL *add* jitter to any input clock, or is the output jitter the
> >
> > Yes it does. Feed it with a crystal clear clock, and you will get
> somewhere
> > +/- 200ps jitter.
> <snip>
>
> The term "add" might be misinterpreted here.  If (using exagerated numbers
> for illustration) a DLL generates 1 ns jitter and feeds a second DLL
capable
> of tracking the input jitter and "adding" another 1 ns of jitter, the
> resulting jitter should be 1.414 ns, not 2.0.
>
> It's been pointed out on this board before that the DLLs tend to generate
> nice jitter spectra rather than the "spikey" results one might expect from
a
> DDS.  Also pointed out is that the jitter is additive in the sense that
RMS
> signals are added:  square, add, sqaure root.
>
>

John,

Isn't it true that the peak-to-peak jitter will add linearly? For example,
if you have 100ps of peak-to-peak jitter at the input to a DCM, and the DCM
adds 200ps of (uncorrelated) jitter (peak-to-peak), then the output jitter
of the DCM is 300ps peak-to-peak, correct?

Assuming this is true, then from a meeting-timing-point-of-view, one must
use the additive peak-to-peak jitter in the timing budgets.

Bob



Article: 79422
Subject: Re: 3.3V device programmable with 5V?
From: "vax, 9000" <vax9000@gmail.com>
Date: Fri, 18 Feb 2005 16:29:07 -0500
Links: << >>  << T >>  << A >>
Mouarf wrote:

>> http://toolbox.xilinx.com/docsan/2_1i/data/common/jtg/fig26.htm
>> I build one according to this schematic and it works well with XC95144XL.
> 
> thank you for your experience sharing. Do you know which version this
> cable is? (II, III, IV ?) Does it make some difference in IMPACT?

I don't know. But it works with XC95144XL. There should not be problem with
XC9572XL. I use the latest Xilinx free webpack software (version 6.2?).

vax, 9000

Article: 79423
Subject: Re: Xilinx: Pitfalls of chaining DLLs
From: "Vladislav Muravin" <xfilex2003@hotmail.com>
Date: Fri, 18 Feb 2005 16:35:28 -0500
Links: << >>  << T >>  << A >>
Stephen,

I think Xilinx website and architecture wizard have some sort of DCMs
cascading and jitter calculation approximation.
However, you must take into account that using CLKFX output of one DCM as
CLKIN of another will create problems.
I have used very stable oscillator and i had something like +/- 150 ppm
jitter at the output.

I have been able to cascade 4 DCMs in one chain, but the resulting clock was
purely for internal usage, without going out of FPGA.

What is the application? Is the resulting clock very high or not?


Sincerely,
Vladislav Muravin
Senior FPGA Design Engineer
Advantech AMT (Advanced Microwave Technologies)
657 Orly Avenue
Dorval H9P 1G1
Quebec, Canada
Tel: (514) 420-0045 ext. 240
Fax: (514) 420-0073
http://www.advantechamt.com


"Stephen Williams" <spamtrap@icarus.com> wrote in message
news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...
>
> We have a design that uses a chain of DLLs internally. That is,
> the output from one DLL is fed to the input of another DLL.
> I'm not the designer in this case, but I do want to understand
> the implications of this. Can anybody point me to the right APP
> notes or search keywords at the Xilinx site for this?
>
> A specific question about the Jitter specification; Does the
> DLL *add* jitter to any input clock, or is the output jitter the
> max of input and documented output jitter? (This is Virtex-II.)
> -- 
> Steve Williams                "The woods are lovely, dark and deep.
> steve at icarus.com           But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."



Article: 79424
Subject: Re: Issues with a batch of Virtex-II chips
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 18 Feb 2005 13:44:44 -0800
Links: << >>  << T >>  << A >>
Igor,

Any reason why you haven't open a web-case?  Or called the hotline?

With your "lines down" situation, you should be moved to the head of the 
line, and be given the highest level of service.

Let me know,

Austin



IgI wrote:
> Hi!
> 
> I'm using Virtex-II (XC2V1000-FF896-4C) in one of the product which we have
> been selling for over 3 years. Recently we got "new" batch of Virtex-II
> chips and problems started to arise. So far I have isolated PCBs with three
> different batch of Virtex-II chips:
> 
> Batch A:
> XC2V1000
> FF896AFT0301
> F1247582A
> 4C
> Philippines
> 
> Batch B:
> XC2V1000
> FF896AGT0409
> D2169507A
> 4C
> Taiwan
> 
> Batch C:
> XC2V1000
> FF896AFT0205
> F1205613A
> 4C
> Philippines
> 
> All the chips in batch A have the suffix AFT301, all the chips in batch B
> have the suffix AGT0409,...
> PCBs with chips from batch B and C are working fine, on the other hand none
> of the 42 PCBs, where chips from batch A are used are working. PCBs are the
> same (same revision) for all the products, all other components (ZBTRAMs,
> DDR SDRAMS, passive components,....) are the same. All voltages are within
> the safe margins, all input clocks are clean. All the affected boards pass
> the JTAG test, in other words we didn't find any soldering errors, short
> circuits, vias without metallization, wrong resistors or capacitors,
> incorrectly oriented diodes or capacitors... or any other error we could
> think of. We got all the chips in a sealed package. PCBs were tested at
> different temperatures (from 8 degrees Celsius to 46). Only the PCBs with
> chips from batch A don't work. Let me explain what precisely is not working.
> 
> I'm using 6 DCMs  to generate clocks for ZBTRAM, DDR, System, ConfigBus,...
> and two DCMs don't set the locked signal after I release them sequentially
> from reset. I don't know if other parts of the design (the parts which don't
> use ZBTRAM clock) don't work either, because the missing clock is a fatal
> error and I didn't have the time to investigate further in that direction.
> Working freq. of ZBTRAM is 120MHz, DDR is working at 166MHz, System at
> 100MHz, ConfigBus at 10MHz,...
> 
> We are currently using ISE 5.2 SP3 for this design. I have verified the bit
> stream by reading it back from the chip and it's ok.
> Two coworkers, guys from the production and I are working on solving this
> problem for the last two days and we are almost out of ideas what else we
> could try, except replace the problematic chips with the non-problematic. I
> can't use ISE 6.1 or newer because the routing is not successful or ISE
> simply doesn't meet the timing constraints (the chip is 99% full).
> 
> Have you experienced anything similar in the past? How did you solve the
> problem? Do you have any ideas/suggestions what else I could try? I couldn't
> find any document on the xilinx web site explaining the detailed chip
> signatures. I would like to know, what AFT0301 stands for? Is this the
> product date, production line, factory code...? I would like to know, when
> the chips have been manufactured (how old are they)?
> 
> I guess we'll have a competition in the company next week. And the goal will
> be; who can throw virtex-II the farthest... Ok, I'm just joking, but I
> needed to vent...argh...
> 
> 
> Igor Bizjak
> 
> 



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