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
Hi, This is the flow of my board. FPGA -> transmitter -> back to FPGA. So the FPGA generates a ramp and sends to the transmitter, the transmitter transmit the ramp back to the FPGA, we are doing this to test the transmitter. So what kind of ADC do I need to build? I am new at this DNL and INL stuffs. The ramp is just 8 bits 0 to 255 generated by an 8 bit counter. Thanks, AnnArticle: 79426
Vladislav Muravin wrote: > 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. Unfortunately, our engineer did exactly that: a DCM (used to be a chain of DCMs) multiplies a PCI 33MHz clock up to 100MHz and sends it off the chip. The return 100MHz clock is connected to another DCM which is used as an internal 100MHz clock phased with the SDRAMS. -- 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: 79427
Am I the only one who keps getting lame "contact your local FAE" answers all the time? Even when asking them why the NIOS2 subscription information on the personalized "mysupport" website has vanished they suggest to contact my local FAE... My local FAE knows for sure why Altera changed the website!! rickArticle: 79428
"Jedi" <me@aol.com> wrote in message news:oQtRd.529$kG2.33@read3.inet.fi... > Am I the only one who keps getting lame "contact your local FAE" answers > all the time? > > Even when asking them why the NIOS2 subscription information > on the personalized "mysupport" website has vanished they > suggest to contact my local FAE... > > My local FAE knows for sure why Altera changed the website!! > > > rick > Hi rick, After getting the worst online and phone support for years, we finally got into the local FAE loop. Now we get all the great support we need! My recommendation it to stop fighting it and go with the system. I think a lot of engineers (like me) would prefer online support, but once you get to know your FAE(s) it's great. I noticed the great decline in the Nios2 info on Altera's website as well, but I can say we have a new local Nios dedicated FAE. His existence and story says that Nios2 and SOPC are being developed stronger than ever. It's all being more tightly integrated with QII. I hope so. We're finally working through all the kinks to ship a real NiosII based product. I'd like to do more now. KenArticle: 79429
Hi all, I want to have a suggestions about some interesting projects to handle in an ML310 board with a Virtex2Pr. I have a very good nowledge of VHDL, C, and digital signal processing. I want to play arroud this board but i don't have any idea about and build some IP. Ultimetly i want to evolve to a Hardware freelancer developper. Thanks for ur suggestionsArticle: 79430
According to the Altera NIOS docs there are premade .sof config files for flashing an own image onto a cyclone ep1c20 NIOS board. But none of the premade restore/flash design images work with the nios2 flash programmer...also not when make a new one from scratch with this mk_target_board script. Any hints or someone has a working .sof for ep1c20 NIOS kit? thanx in advance rickArticle: 79431
Hello all, I am looking for a source( website/book) that has some good information on vhdl coding guidelines for synthesis/efficiency. I "googled" but didnt find any good info (except for the synplify manual). ThanksArticle: 79432
>From an Xilinx Engineer: Sorry to hear that you are still having issues with the fifo behavioral model. We have seen cases of this type of behavior where testbenches create a clock by forcing the transitions, rather than actually creating a clocked process. Example: clk <= '1'; data <= 1; wait for 20 ns; clk <= '0'; ... When you generate a clock this way, the simulator has no way of knowing if the data or the clock happened first, and so this can cause problems. Recoding the testbench in a synchronous manner has always seemed to fix this type of issue. If that is not it, we have also seen one case where the behavioral model behaves incorrectly (a different type of race condition), and and we have fixed it for the Fifo Generator v2.1 release scheduled in April. We have a patch available today that I can provide you if it would help. If you send me your test design, I can get a hotline case open for you and provide the design to our applications support team so they can try the patch and ensure that it does indeed solve the issue you are seeing.Article: 79433
"Ann" <ann.lai@analog.com> wrote in message news:ee8bf07.3@webx.sUN8CHnE... > 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 On what? It's an FPGA - it has wires going in and wires coming out. If you've turned it into something fancy that can output to a screen (or printer, serial port or whatever) then the answer depends on how you did that. If you're running a verilog simulator, there will probably be calls you can make - but I don't think I've ever used them so I can't remember what they are (I'm sure I'll regret that when it gets asked in my exams, but there we go) Alun HarfordArticle: 79434
"Bob" <nimby1_notspamm_@earthlink.net> wrote in message news:35tRd.2922$x53.1388@newsread3.news.atl.earthlink.net... > > "John_H" <johnhandwork@mail.com> wrote in message > news:07sRd.12$rp4.630@news-west.eli.net... <snip> > > 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 It's not true that peak-to-peak jitter values add linearly for guassian distributed phase noise. If you have two sinusoidal jitter modulations (the "spikey" jitter spectra I referred to above) with unrelated frequencies, those will add linearly. Gaussian jitter is a statistical number. If the peak-to-peak is specified at 6-sigma (which it often is) the probability is 0.00034% that either jitter value is at its peak. The probability that *both* values are at their peaks is below 0.000000000012% which is way beyond a 6-sigma spec for the additive values. Square, add, square-root. It's power, not voltage.Article: 79435
"sam" <sams235@gmail.com> wrote in news:1108769727.400663.195580 @l41g2000cwc.googlegroups.com: > Hello all, > > I am looking for a source( website/book) that has some good information > on vhdl coding guidelines for synthesis/efficiency. I "googled" but > didnt find any good info (except for the synplify manual). > > Thanks > > Try the Xilinx "Synthesis and Simulation Design Guide" at http://toolbox.xilinx.com/docsan/3_1i/pdf/docs/sim/sim.pdf. We also sell Sundar Rajan's "Essential VHDL" book which considers these topics: http://www.xess.com/prod013.php3. -- ---------------------------------------------------------------- Dave Van den Bout XESS Corp. PO Box 33091 Raleigh NC 27636 Phn: (919) 363-4695 Fax: (801) 749-6501 devb@xess.com http://www.xess.comArticle: 79436
Hi Rick, If you're using the Altera Nios Cyclone 1C20 development board, the .sof's for programming flash are pre-built and tested as part of the Nios II installation; the mk_target_board script is only for developing a custom board once you've moved on from using the dev. board. You might verify that in your design, the proper board selection is specified in the 'board component' selection in the main SOPC Builder display; the flash programmer later looks at this setting to figure out which .sof to send down for flash programming. Beyond that I have to suggest that you provide more information on the problem. Perhaps visit www.niosforum.com as well. Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 79437
Hello,
how fast a Nios processor can be if embedded
in a speed grade 6 Cyclone FPGA? What is the
approximate maximum reachable clock frequency?
Best regards
Piotr Wyderski
Article: 79438"John_H" <johnhandwork@mail.com> wrote in message news:uyvRd.13$rp4.632@news-west.eli.net... > "Bob" <nimby1_notspamm_@earthlink.net> wrote in message > news:35tRd.2922$x53.1388@newsread3.news.atl.earthlink.net... > > > > "John_H" <johnhandwork@mail.com> wrote in message > > news:07sRd.12$rp4.630@news-west.eli.net... > <snip> > > > 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 > > It's not true that peak-to-peak jitter values add linearly for guassian > distributed phase noise. > If you have two sinusoidal jitter modulations (the "spikey" jitter spectra I > referred to above) with unrelated frequencies, those will add linearly. > > Gaussian jitter is a statistical number. If the peak-to-peak is specified > at 6-sigma (which it often is) the probability is 0.00034% that either > jitter value is at its peak. The probability that *both* values are at > their peaks is below 0.000000000012% which is way beyond a 6-sigma spec for > the additive values. Square, add, square-root. It's power, not voltage. > > Yeah, I guess it's just a matter-of-degree as to how you treat it. It depends on how long between logic errors is acceptable. If probability strikes then you're not going to meet timing -- even if it's once in a blue moon. I hear that in V7 of the Xilinx software, they will be changing they way that jitter sources' effects are combined. From what I've heard, V6 adds them rms'ish. V7 will not, but I don't have the details. We think we're getting screwed by the way that V6 is treating this matter. We're having to over-specify our jitter in order to stop the runtime errors we're seeing. However, to be fair, the way that they add jitter in V6 may not be the only source of our problem (but we think it's part of it). BobArticle: 79439
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote in message news:cv63gb$to$1@news.dialog.net.pl... > Hello, > > how fast a Nios processor can be if embedded > in a speed grade 6 Cyclone FPGA? What is the > approximate maximum reachable clock frequency? > > Best regards > Piotr Wyderski > If you're asking how fast your application can run then you better test it on an actual Cyclone. You can get a Nios to run 140MHz out of onchip ram, but each memory access will cost you at least 5 clocks. Running out of sdram can be had at 110MHz, but memory accesses will set you back 11+ clocks per. Also, watch out for bit shifts. They can take 1 clock per bit on the Cyclone. To overcome these limitations we upgraded our application to a StratixI to get 1 clock bit shifts and wrote a Custom Instruction to bypass the Avalon Bus and read mem in 2 clocks. (writes are always fast) Now our app cooks. KenArticle: 79440
Thanks Dave!Article: 79441
Kenneth Land wrote:
> If you're asking how fast your application can run then you better test it
> on an actual Cyclone.
Unfortunately, I have no working hardware yet, so I cannot
test it. To clarify my requirements: I am going to perform
digital signal processing on a data stream. There is no need
for rapid control flow branching, everything can be pipelined.
16--20 bit fixed-point arithmetic is enough. I need a FIR
block, as fast as possible, and an interface to SDRAM,
only capable of performing pseudo-DMA burst transfers
(say, one M4K RAM block at a time). The NIOS CPU will be
responsible for quite simple things: synchronization of the
hardware "coprocessors" (the FIR block, a TDMA interface to
an AC-97 codec, NCO, parallel interface to a USB2.0 coupler
etc.), filter coefficient computation (off-line, can be slow),
CF card data transfer handling. I wolud like to perform
some complex operations using NIOS, e.g. div, sqrt etc.,
so the CPU should be as fast as possible, but not faster
-- there's no need for a Stratix device. :-)
No direct communication between NIOS and SDRAM is
necessary, a user-controlled "data cache" in the internal
memory banks is enough.
BTW, I'd like to connect a 16Mbit 70ns parallel (1M x 16) FLASH
memory chip to the FPGA. Where should I connect it? Can it
share the lines with the SDRAM interface (+ a simple address
decoder)?
> You can get a Nios to run 140MHz out of onchip ram, but each
> memory access will cost you at least 5 clocks. Running out of
> sdram can be had at 110MHz, but memory accesses will set you
> back 11+ clocks per.
But it is fully pipelined, isn't it?
Best regards
Piotr Wyderski
Article: 79442Hi again, Is this just to test the function of the transmitter/reciever? Bit error rate might be a better measurement for what you are testing. If so I might suggest a simple Psudo Random Pattern Generator with the same PRPG on the reciever. You can build this in the FPGA with fairly simple logic and it will give you a quick data error rate measurement. Use the first data byte received as the initial load for the PRPG receiver and then just count the number of bytes received and the number of miscompares. Your system error rate is simply the bad samples / total samples. You could fix the total samples to make the math easy and just count the number of failing samples. FPGA PRPG source --> Transmitter --> Receiver --> FPGA PRPG compare and count mismatches Load the starting seed into the source PRPG and shift through the pattern as many times as you need for your fail rate calculation. On the transmit side: 1. Load initial seed 2. Transmit sample 3. Shift PRPG 4. Jump to step 2 On the receive side: 1. Wait for first sample 2. Load first sample into the PRPG seed 3. Shift PRPG 3. Wait for next sample 4. Compare sample to PRPG current state 5. Inc fail count if mismatch 6. Jump to step 3 The only drawback is if the first sample is bad all the following samples will fail. You could get fancy and reload the seed on the receiver if some number of samples fail in a sucession. Expect to cycle through a few million samples depending on your transmitter speed and requirements. For some devices we look for bit error rate in the 1e10 range (<10 fails in 1e10 samples.) statisticly we try to run until you get at least 100 fails. This may be done with and without any error correcting (ECC) you might be using to check the raw vs corrected results. Would something like this do what you are looking for? +Bart On Fri, 18 Feb 2005 14:11:08 -0800, AL wrote: > > >Hi, This is the flow of my board. FPGA -> transmitter -> back to FPGA. So the FPGA generates a ramp and sends to the transmitter, the transmitter transmit the ramp back to the FPGA, we are doing this to test the transmitter. So what kind of ADC do I need to build? I am new at this DNL and INL stuffs. The ramp is just 8 bits 0 to 255 generated by an 8 bit counter. Thanks, AnnArticle: 79443
"Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote in message news:cv68m5$48l$1@news.dialog.net.pl... > Kenneth Land wrote: > >> If you're asking how fast your application can run then you better test >> it >> on an actual Cyclone. > > Unfortunately, I have no working hardware yet, so I cannot > test it. To clarify my requirements: I am going to perform > digital signal processing on a data stream. There is no need > for rapid control flow branching, everything can be pipelined. > 16--20 bit fixed-point arithmetic is enough. I need a FIR > block, as fast as possible, and an interface to SDRAM, > only capable of performing pseudo-DMA burst transfers > (say, one M4K RAM block at a time). The NIOS CPU will be > responsible for quite simple things: synchronization of the > hardware "coprocessors" (the FIR block, a TDMA interface to > an AC-97 codec, NCO, parallel interface to a USB2.0 coupler > etc.), filter coefficient computation (off-line, can be slow), > CF card data transfer handling. I wolud like to perform > some complex operations using NIOS, e.g. div, sqrt etc., > so the CPU should be as fast as possible, but not faster > -- there's no need for a Stratix device. :-) > > No direct communication between NIOS and SDRAM is > necessary, a user-controlled "data cache" in the internal > memory banks is enough. > > BTW, I'd like to connect a 16Mbit 70ns parallel (1M x 16) FLASH > memory chip to the FPGA. Where should I connect it? Can it > share the lines with the SDRAM interface (+ a simple address > decoder)? > >> You can get a Nios to run 140MHz out of onchip ram, but each >> memory access will cost you at least 5 clocks. Running out of >> sdram can be had at 110MHz, but memory accesses will set you >> back 11+ clocks per. > > But it is fully pipelined, isn't it? > > Best regards > Piotr Wyderski > dma's with the supplied SOPC dma peripheral is fast. It's latency aware and we can dma in and out of it in as fast as one clock per word. The data master of the Nios is not latency aware and even hand assembly coded back to back reads to sequential addresses in sdram will be no faster than 11+ clocks per read. So heres the answer: dma's, and all writes are fast. Avoid non-dma reads whenever possible. Originally for my app we dma'd an external fifo into sdram buffers for processing. We got that xfer down to one clock per 32 bit word, but the 11 clocks to get each word out to process it killed us. The solution was a custom instruction that can read the fifo in 2 clocks, process it, then write the result to an sdram buffer. (remember writes are fast) buffers are eventually dma'd from sdram to USB2.0 controller. Hope this helps. KenArticle: 79444
> I am sorry, but you have never run a spice simulation of midox pass > transistor vs thin ox. I am sorry Austin, but how exactly is it that increasing oxide thickness does not decrease transistor speed? Increased tox = decreased beta = decrease Ids. And the Vt increases with tox too, unless you adjust the implant levels for those transistors (at the expensive of another mask and processing step). If there were truely no speed implications of using thicker oxide transistors, we'd all be using thick oxide transistors everywhere and bragging about are "Single Gate Oxide" technologies!. There are places where slower transistors (be it longer gates, higher Vt, or thicker oxide) are more tolerable than others. For example, the configuration rams (no impact on speed). Are the pass gates one of those places? Maybe -- depends on speed vs. leakage goals and the exact result you get from your sim. Arguing that there is no speed loss and no complexity increase whatsoever though is silly. Regards, Paul Leventis Altera Corp.Article: 79445
> ( I assume that you are not using any DCM outputs for input clock less than > 24 MHz) 10MHz clock is generated externally. > 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. Each DCM has it's own reset line connected to reset register and is asserted/deasserted by software. Thanks for sharing you experience, Igor Bizjak > 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 with in > > 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: 79446
I googled "verilog stop" and quickly came back with $stop. (Note: I
haven't used verilog [much] in about 8 years. Been using the other major
HDL.) E.g.,
http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_top.html
I don't know if verilog has a direct equivalent to VHDL's "report" and
"assert" commands, but I'm sure you could work something out with one of the
following (from that link):
$display("text_with_format_specifiers", signal, signal, ... );
Prints the formatted message once when the statement is executed during
simulation. A newline is automatically added to the text printed.
$write("text_with_format_specifiers", signal, signal, ... );
Like $display statement, except that no newline is added.
$strobe("text_with_format_specifiers", signal, signal, ... );
Like the $display statement, except that the printing of the text is delayed
until all simulation events in the current time step have executed.
Jason
"AL" <ann.lai@analog.com> wrote in message news:ee8bf07.1@webx.sUN8CHnE...
> Thanks glen for the response, but what about making the program stop
> completely and pop up a message that says something like "ERROR", is there
> a way to implement that? I have tried using "disable" but that won't
> compile, I think it was unsupported or something. Thanks, Ann
Article: 79447No, there isn't any reason, I simply forgot. We had to solve the problem the fastest we could, because the customers are waiting for the products. And the fastest way was to exchange the chips with the "good" ones. I still have 5 PCBs with problematic chips. We will analyze them further on Monday. If we don't come up with some reasonable explanation, I will open a web-case. Igor Bizjak "Austin Lesea" <austin@xilinx.com> wrote in message news:cv5nkc$qgu1@cliff.xsj.xilinx.com... > 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 > > > >Article: 79448
Paul, Xilinx of course does not use thick oxide willy-nilly. As you would agree, there are many (millions of) transistors in the configuration latches where slowness is goodness (helps SEUs for example). And I am also convinced that thick oxide does not slow down pass transistors that are controlled by static configuration cells, while passing fast signals. These are circuits that do not exist in "normal" ICs, but are prevalent in FPGAs. Thus Xilinx can take advantage of it, to reduce leakage current. Altera has poo-poo'ed it, but that would never stop us.. :-) The battle of: "I have a PhD, therefore I know better", vs "I have 23 years of experience in telecom" is getting a bit long in the tooth. I could throw in my "over 40 years of digital design experience" as if that would impress anyone. (Although it really does help with some perspective...) We will keep the community interested with additional stories about performance and power consumption. And I will keep fighting marketing BS wherever it comes from. I might also hint at our next web-seminar about signal integrity. How a fairly clean on-chip signal can get corrupted when it reaches the pc-board, and what Xilinx has done to improve that situation. You can hear that on Tuesday March 1: "Signal Integrity and how it is affected by FPGA packaging". With real-life examples and screen-shots. Knocks your socks off ! Oscilloscopes have come a long way... Peter AlfkeArticle: 79449
Hi Peter, > And I am also convinced that thick oxide does not slow down > pass transistors that are controlled by static configuration cells, > while passing fast signals. I haven't heard any electrical reason expressed as to why this would be so. Besides, simple logic tells me that this cannot be the case -- if there was no speed impact to using thicker oxide transistors, you wouldn't bother with a "medium" oxide device and would instead go thick oxide in these particular circuits. > The battle of: "I have a PhD, therefore I know better", vs "I have 23 > years of experience in telecom" is getting a bit long in the tooth. I > could throw in my "over 40 years of digital design experience" as if > that would impress anyone. I agree 100% -- how does one's experience, position or such change the quality and content of the arguments they present? Besides, my lack of (figurative) gray hairs puts me at a distinct disadvantage in this arena! Regards, Paul Leventis Altera Corp.
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