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
> 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, JonArticle: 79401
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
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
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 StrazzeroArticle: 79404
"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 JonathanArticle: 79405
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: 79406We 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
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 JoergArticle: 79408
"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 FalkArticle: 79409
"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 FalkArticle: 79410
"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
"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 FalkArticle: 79412
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, AnnArticle: 79413
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, AnnArticle: 79414
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, AnnArticle: 79415
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
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
"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
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. -jgArticle: 79419
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 BizjakArticle: 79420
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
"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. BobArticle: 79422
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, 9000Article: 79423
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
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:
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