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
A Hush Falls on the Crowded Room, The crowd consists of those engineers that have been working for years on the latest new device.....and their marketing counter-parts. On the screen is projected the new logo, and device name. Angry murmurings are heard. Sounds of surprise. Some approvals "yeah, great!" Someone starts shouting and ranting about Roman numerals vs. Arabic numbers. Someone else whines about the trademark issues. Finally peace settles in, and a compromise is reached. Really a very scarey thing, worse than naming a child. Austin Steve Knapp wrote: > These are the tough decisions decided by marketing people. :-) > > Personally, I liked the idea of a Spartan-Ayeyaiyai! > > Tim wrote: > > > > Steve Knapp wrote > > > --------------------------------- > > > Steven K. Knapp > > > Spartan-3/II/IIE FPGAs > > > --------------------------------- > > > > Why Spartan-3, not Spartan-III? > > -- > --------------------------------- > Steven K. Knapp > Applications Manager, Xilinx Inc. > General Products Division > Spartan-3/II/IIE, Spartan/XL FPGAs > E-mail: steve.knapp@xilinx.com > ---------------------------------Article: 54726
"Robert Finch" <robfinch@sympatico.ca> writes: > > This method is patented. It is impossible to implement the 2 instructions > > (and so the entire instruction set, and so an compatible chip) without > > violating this patent. > > Interesting. I predict a flood of useless, mysterious instructions > incorporated into CPU's so that it's impossible to claim compatibility > without patent violation. Problem here: If they are really useless programmers/compilers will ignore them (see how some x86 instructions are avoided by modern x86 compilers, because they are slow). So an "half compatible" clone without them can still be successfull. So you need to actually find some new way, to solve an problem, that makes it possible to drop the normal instructions that could also solve this problem. Such specialists like allignment handling, or memory management, or interrupt/bus control are candidates for this. Trying to reinvent such wheels, not for more roundness, but just for being different, is not easy, if performance is not to suffer. And of course any new architecture, without existing code libraries (the main reason to clone anything), has to compete. And there open architectures will win easily over such deliberately broken stuff. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith - hardware runs the world, software controls the hardware code generates the software, have you coded today?Article: 54727
"rickman" <spamgoeshere4@yahoo.com> wrote > I recently saw a new product announcement for an *optical* BGA > inspection device. It looks like they use fiberoptics to slip the head > *under* the BGA. They are selling "From $3000". Company is ASG in > Cleveland, OH 216-486-6163, www.asg-jergens.com. A much, (very much) cheaper way to do this is to get a small (5mm or 7mm) right angle total reflection prism and look with you binocular. It's useful for PQFP, TVSOP, etc. as well. MarcArticle: 54728
The FPGA editor isn't really very useful for this. IS there some diagram someone knows of which shows all the connectivity in the Virtex switchblock? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 54729
eric_delage@yahoo.fr (Eric DELAGE) wrote in message news:<75b8d52e.0304110534.edb9d25@posting.google.com>... > > I am wondering if you know any available FPGA devices which are dynamically > > reconfigurable. I am doing a project in the area of evolvable hardware and I > > am looking to buy a board with dynamic reconfigurable FPGAs. > > The Virtex-II FPGA family from Xilinx (http://www.xilinx.com). They > are dynamically as well as partially reconfigurable via the JTAG port > using the IEEE 1149.1/1532 standards or via the traditional > configuration ports. The reconfiguration is however not that flexible > ; you can only re-configure on a column basis. > > Eric Have you ever considered a dedicated processor for dynamically reconfiguring FPGA/CPLD? SystemBIST embedded test and configuration processor seems an interesting product. You may check this web site: www.intellitech.com. AliArticle: 54730
rrr@ieee.org (Rajeev) writes:
> [2] The Spartan-II datasheet (Module 3: DC and Switching > page 3)
> shows the startup current requirement _with_no_reference_ to the
> device size... you'd think there'd be _some_ difference between a
> 2S15 and a 2S200, surely a 2S15 application shouldn't be required to
> design in a 2S200-rated power supply ?
As I understand it, the start-up current requirement is due to internal
buffer contention at power-up, which produces a low-impedance path from
Vccint to GND. So I would expect the current requirement to be a
function of how many buffers in the part can be in contention. Surely
there are more in the larger parts, but the exact numbers for each part
are not obvious from the data sheet.
On 28-Jan-2002, Austin Lesea <austin.lesea@xilinx.com> wrote a reply
in another thread about Spartan II power-up current:
> Smaller parts do require less, and we are in the process of finishing up
> the characterization before we publish it in the datasheet and commit
> ourselves for all future time.
AFAICT the data sheet has never been revised to take this into account.
The last time I inquired about this in the newsgroup, I got no reply.
This would certainly be useful information. I had to use another vendor's
part instead of an XC2S15 recently; if I'd known that an XC2S15 would
reliably start up with a 250 mA current limit, I would have been able to
use it. My own needs are for small volumes, but I expect that Xilinx
must have some large customers that would also benefit from a more
detailed characterization of the power-on requirements.
Eric
Reference:
http://www.google.com/groups?selm=3C55D894.D1BE2375%40xilinx.com
Article: 54731Hi John... Can't you generate both clocks from the same PLL so the edges stay together, and use static timing analysis to handle any clock tree loading skews? I usually do anything to avoid "clock-the-clock" situations. Eric "John_H" <johnhandwork@mail.com> wrote in message news:3E9C1B1F.8020305@mail.com... > Thanks, Ray. > > I used the RLOCs and double-checked the routing to make sure the numbers > were "smallest" and still found myself with almost no margin left over > for input jitter tolerance. The Tcko and any of the Tceck or Tdick or > Tsrck values along with the shortest net I could muster left the 1.8 ns > for 1/4 clock at the hairy edge. I was hoping there was an innovative > approach to avoiding the 1.8ns requirement for a 7.2 ns x1clk. > > - John_H > > Ray Andraka wrote: > > John, You are right ot be concerned about skew between the 1x and 2x clocks. If > > you control placement and are clever about getting direct flip-flop to flip-flop > > connections you can manage to do what you are describing using a falling edge > > sensitive FF in the 2x domain to capture the 1x clock, then take the output of > > the falling edge FF and feed it to a rising edge FF in the 2x domain to time > > align the resulting CE with the 2x clock rising edges. The CE is probably > > inverted WRT to what you wanted at that point, in which case an additional > > rising edge FF will put it right without adding any logic delays in the critical > > timing around the neg edge FF. You'll need to use primitives with RLOCs on them > > to keep the timing tight, and with v4.2 and later tools you need to make sure > > you put the time constraints in for each connection in order to keep the router > > honest (3.3 did a good job of finding the direct connect without having an > > explicit time constraint). > > > > John_H wrote: > > > > > >>Thanks for the message last week, Eric - my newsreader at work isn't > >>100% and I had to read/respond at home. > >> > >>Your comment about only needing two flops is accurate as long as the > >>designer can trust that the x1clk and x2clk domains will always work > >>together as we'd expect where the rising edges are coincident. The > >>reality is that those two edges may be separated by some 100s of ps > >>since the clock net loading can be different between the two domains and > >>input clock jitter to the DLL may translate to the two domains at > >>different cycles. THe former problem is known, I'm only speculating on > >>the latter. Bottom line: I can't depend on the two domains to play nice > >>at the common rising edge, hense the nead to offset things by 1/4 the > >>x1clk (or 1/2 th x2clk). > >> > >>Any further thoughts are appreciated. > >> > >>- John_H > >> > >>Eric Pearson wrote: > >> > >>>"John_H" <johnhandwork@mail.com> wrote in message > >>>news:T9Hka.9$716.2363@news-west.eli.net... > >>> > >>> > >>>>Has anyone figured out a nice, clean method to track which phase of a > >>> > >>>Xilinx > >>> > >>> > >>>>DLL's 1x clock corresponds to a 2x clock cycle? One 2x rising edge > >>>>corresponds to the 1x rising edge, the other 2x rising edge corresponds to > >>>>the 1x falling edge. > >>>> > >>>>When I start getting up in frequencies, the ability to use the 1x clock > >>> > >>>and > >>> > >>> > >>>>inverted 1x clock to generate two signals that I can XOR for a phase is > >>>>compromised. It's not inherently safe to use the 1x edges and 2x rising > >>>>edges as "effectively" the same edge due to clock skews and input jitter > >>>>issues. Using the falling edge of the 2x clock to sample the 1x generated > >>>>signals works, but at the 1/4 period timing budget is too tight at the > >>>>frequencies I'm working. > >>>> > >>>>For those who are Verilog friendly, the code here shows how I would > >>>>"normally" extract the phase without running a clock through a LUT. The > >>>>"negedge x2clk" is where the timing gets tough since the Tcko+Tnet+Tick is > >>> > >>>a > >>> > >>> > >>>>little over the 1/4 period of my x1clk. > >>>> > >>>>always @(posedge x1clk) posTog <= ~posTog; > >>>>always @(negedge x1clk) negTog <= posTog; > >>>>always @(negedge x2clk) rawPhase <= posTog ^ negTog; > >>>>always @(posedge x2clk) phase <= rawPhase; > >>>> > >>>>Is there a cleaner way to figure out the which half of the x1clk I'm in? > >>>> > >>>>Thanks, > >>>>- John_H > >>>> > >>>> > >>> > >>> > >>>It really only takes 2 flops working on rising edge. > >>> > >>>always @(posedge x1clk) Toggle <= ~Toggle; > >>>always @(posedge x2clk) Delayed <= Toggle; > >>>assign Phase = DelTog ^ Tog; > >>> > >>>Eric > >>> > >>> > >> > > > > -- > > --Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com > > http://www.andraka.com > > > > "They that give up essential liberty to obtain a little > > temporary safety deserve neither liberty nor safety." > > -Benjamin Franklin, 1759 > > > > >Article: 54732
Eric, Newsflash: Smaller parts were not smaller for the peak current, just lasted less time. Smaller parts are smaller for the minimum required current. The difference between two already tiny parts is too tiny to spec. In a large part, paths are not all in contention at the same time, as the contention resolves as the power comes on gradually at the speed of light in silicon across the die. As such it is like zipping a zipper really fast for a short zipper, or really fast for a long zipper. The current (force) required is the same, but the time spent zipping is different (total energy is less). Austin Eric Smith wrote: > rrr@ieee.org (Rajeev) writes: > > [2] The Spartan-II datasheet (Module 3: DC and Switching > page 3) > > shows the startup current requirement _with_no_reference_ to the > > device size... you'd think there'd be _some_ difference between a > > 2S15 and a 2S200, surely a 2S15 application shouldn't be required to > > design in a 2S200-rated power supply ? > > As I understand it, the start-up current requirement is due to internal > buffer contention at power-up, which produces a low-impedance path from > Vccint to GND. So I would expect the current requirement to be a > function of how many buffers in the part can be in contention. Surely > there are more in the larger parts, but the exact numbers for each part > are not obvious from the data sheet. > > On 28-Jan-2002, Austin Lesea <austin.lesea@xilinx.com> wrote a reply > in another thread about Spartan II power-up current: > > > Smaller parts do require less, and we are in the process of finishing up > > the characterization before we publish it in the datasheet and commit > > ourselves for all future time. > > AFAICT the data sheet has never been revised to take this into account. > The last time I inquired about this in the newsgroup, I got no reply. > This would certainly be useful information. I had to use another vendor's > part instead of an XC2S15 recently; if I'd known that an XC2S15 would > reliably start up with a 250 mA current limit, I would have been able to > use it. My own needs are for small volumes, but I expect that Xilinx > must have some large customers that would also benefit from a more > detailed characterization of the power-on requirements. > > Eric > > Reference: > http://www.google.com/groups?selm=3C55D894.D1BE2375%40xilinx.comArticle: 54733
Austin Lesea wrote: > > Eric, > > Newsflash: Smaller parts were not smaller for the peak current, just lasted > less time. > > Smaller parts are smaller for the minimum required current. Then I think that's the number Eric was looking for. How much current the FPGA might be able to draw is less important than the required 'hump current' - ie the value below which the device will pause forever. A thyristor model might be usefull (even tho it's not a thyristor effect), these have minimum trigger currents, and a definite hump effect. -jgArticle: 54734
Hi fellows: I want to use the user-defined registers of JTAG on Xilinx FPGA. I view the data sheet of Xilinx Virtex serials that it support two registers of JTAG are USER1 and USER2. I do not know how I can use and configure them on real chip. Thanks VictorArticle: 54735
comparing the spartan2e and cyclone component lines in the 256 pin bga packages , can anyone please tell me advantages in going with the cyclone versus staying with the spartan2e , i don't care minor differences in the ram and i/o but i am interested in significant advanges the cylcone may have, thank you in advanceArticle: 54736
On Wed, 16 Apr 2003 10:43:42 -0700, KB wrote: > On Wed, 16 Apr 2003 08:05:24 -0700, Peter Wallace <pcw@karpy.com> wrote: > >>On Wed, 16 Apr 2003 08:37:09 -0700, KB wrote: >> >>> On Wed, 16 Apr 2003 00:40:46 -0400, rickman <spamgoeshere4@yahoo.com> >>> wrote: >>>> >>>>They only issue I see with BGAs is the requirement for hot air >>>>soldering with BGA while a flatpack can be iron soldered. But you can >>>>do hot air soldering with an inexpensive rework station. >>> >>> In my experience it has not been this simple. I had a multi-thousand >>> dollar hot air system here for a while ... I will not do bga's again >>> in house until I also have the xray equipment to properly QC the bga >>> soldering ... and unfortunately that equipment isn't exactly in my >>> budget. >> >>Hey I've done many 388 and 516 pin BGAs proto cards with nothing but a >>lot of flux and a $79.00 Granger hot air gun, Never had an unsoldered >>pin though I have occasionally had shorts. The shorts were easy to spot >>by sighting along the rows of balls under the BGA (Using a bright light >>and looking edge on) Its not that hard, certainly not a whole lot harder >>than QFPs >> >>Now I wouldn't solder a really large or expensive chip this way, but >>FP256's should be a piece of cake... >> >>PCW > > interesting .. could you describe your technique further ? did you put > down solder paste ? did you hold the chip in position or let it free > float ? etc. when you had a short did you remove the chip and try > again ... I assume they would have to be reballed .... thanks KB I dont use solder paste, the balls have plenty of solder. The real key is that you have an immense amount of surface tension pulling the part down and into alignment. For preliminary alignment I tack some pieces of scrap PCB material on all 4 sides of the BGA with about 5 mills of clearance on all sides. The clearance allows the chip to pull down and center when all the solder balls melt, but not so much side to side slack that the solder balls can reach the wrong pads. Lots of flux is needed to guarantee clean surfaces and prevent oxidation whils soldering. I heat from the bottom until the solder balls melt (this requires some practice) You can tell when the balls are all melted because the BGA will sink down and get "bouncy" The failures I have had from shorts were cured by reheating the card, removing the BGA, and re- soldering a new BGA, I did not try to reccover the old BGA as they were ~$50 chips and not really worth re-balling PCWArticle: 54737
Steve Knapp wrote: > > Unfortunately, Spartan-3 devices are not pin compatible with > Spartan-IIE or Virtex-II families. The good news is that there is > _full_ compatibility within the Spartan-3 family. > ...snip... > > Spartan-3 has a different footprint than Virtex-II because both use a > different die-bonding technology. Virtex-II uses a higher-performance > flip-chip technology. Spartan-3 uses a lower-cost pad ring. Having the > freedom to create a new footprint also allowed us to maximize the number > of single-ended and differential I/O for each package. Steven, I always appreciate knowing the *why* behind decisions. Sometimes I get frustrated seeing a manufacturer do something that seems so "dumb" from a customer's point of view. I understand that that is not always the "best" thing to do when the realities of implementing a product are considered. I am not clear about how the die-bonding technology affects the pin out. I don't' see where the pinouts are so different that the package was flipped (maybe I didn't look hard enough). Is the flip-chip die upside down from the pad ring? If so, couldn't this be compensated for by reversing the images on the die? I know that Xilinx wanted to "optimize" the IO for this design. But sometimes there are significant advantages for the user when they have a wider choice of FPGAs for a given socket. However, the wide range of the Spartan 3 sizes will certainly help deal with that issue. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54738
Hi,everyone now i want to add sdram to my nios system are there any tutorials or examples in website please tell me thanks Regards! moukaiArticle: 54739
Hi CB, The biggest advantages are cost, logic density, and performance. Cyclone is a 0.13u device, architected for low-cost. Spartan-IIE is 0.18u device that recycles the Virtex-E architecture. Cyclone is cheaper for almost all applications -- both companies claim the lowest cost part, but Cyclone is much cheaper per LE. Cyclone goes up to 20K LEs, while Spartan-IIE goes up to 13.8K (or 12K vs 9.6K in a 256-pin package). Cyclone is also MUCH faster, partially due to the process advantage and partially due to a superior architecture. This speed can turn into a cost reduction, since you don't need to buy as fast a speed grade, or you may not need to parallelize your data as much (and hence can fit in a smaller part). That's about it without getting into the details of the features. Regards, Paul Leventis Altera Corp. [This is my spammable email address; I have no affiliation with the University of Toronto besides being a student there] "CB" <cb@hotmail.com> wrote in message news:3e9e18e4.32935894@news.compuserve.com... > comparing the spartan2e and cyclone component lines in the 256 pin bga > packages , can anyone please tell me advantages in going with the > cyclone versus staying with the spartan2e , i don't care minor > differences in the ram and i/o but i am interested in significant > advanges the cylcone may have, thank you in advanceArticle: 54740
Paul Leventis wrote: > > Hi CB, > > The biggest advantages are cost, logic density, and performance. > > Cyclone is a 0.13u device, architected for low-cost. Spartan-IIE is 0.18u > device that recycles the Virtex-E architecture. Cyclone is cheaper for > almost all applications -- both companies claim the lowest cost part, but > Cyclone is much cheaper per LE. Cyclone goes up to 20K LEs, while > Spartan-IIE goes up to 13.8K (or 12K vs 9.6K in a 256-pin package). Cyclone > is also MUCH faster, partially due to the process advantage and partially > due to a superior architecture. This speed can turn into a cost reduction, > since you don't need to buy as fast a speed grade, or you may not need to > parallelize your data as much (and hence can fit in a smaller part). > > That's about it without getting into the details of the features. > > Regards, > > Paul Leventis > Altera Corp. > > [This is my spammable email address; I have no affiliation with the > University of Toronto besides being a student there] > > "CB" <cb@hotmail.com> wrote in message > news:3e9e18e4.32935894@news.compuserve.com... > > comparing the spartan2e and cyclone component lines in the 256 pin bga > > packages , can anyone please tell me advantages in going with the > > cyclone versus staying with the spartan2e , i don't care minor > > differences in the ram and i/o but i am interested in significant > > advanges the cylcone may have, thank you in advance Looks like the EP1C4 is still not out yet. At least it did not show up when I did a web search at Arrow. The approach of providing a smaller part with higher IO count is interesting. It fits my needs very well. But looks like it is yet to come out. Any idea when? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54741
rickman <spamgoeshere4@yahoo.com> wrote: : Looks like the EP1C4 is still not out yet. At least it did not show up : when I did a web search at Arrow. The approach of providing a smaller : part with higher IO count is interesting. It fits my needs very well. : But looks like it is yet to come out. Any idea when? I would appreciate if Manufactures would have a clear statement of the actual cycle in the lifetime for each product: planned, sampling, production, depreciated, eol but I seems to be dreaming... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54742
Ello, I have this 8-bit paralell binary signal I need to read with a LED display, speed is not essential as the ouput is on for as long as I give it the strobe signal. One idea would be to use a Xilinx 9536/9572 (the only two I'm capable of programming) and feeding it to an ICM7212 LED driver. However this is beyond my current skills and I'm wondering if someone has perhaps already done something like this or has a few pointers. The signal in contains the values 256bits and today I use led's for 1-2-4-8-16 etc, so a 3 segment led display would be a great improvement :) I'm only familiar with the schematics design of the xilinx software and know nothing of vhdl programming itself Thanks, //GregArticle: 54743
Hi Rick, Alteras web is stating september 2003 as production release, since all other device in cyclone rolled out on time or ahead of time this date shouldn't be a problem. Another good place for finding avalible qnt. of Altera devices at least in Europe is to check out the EBV home page at www.ebv.com Cheers Fredrik rickman <spamgoeshere4@yahoo.com> wrote in message news:<3E9E41DC.E6F82653@yahoo.com>... > Paul Leventis wrote: > > > > Hi CB, > > > > The biggest advantages are cost, logic density, and performance. > > > > Cyclone is a 0.13u device, architected for low-cost. Spartan-IIE is 0.18u > > device that recycles the Virtex-E architecture. Cyclone is cheaper for > > almost all applications -- both companies claim the lowest cost part, but > > Cyclone is much cheaper per LE. Cyclone goes up to 20K LEs, while > > Spartan-IIE goes up to 13.8K (or 12K vs 9.6K in a 256-pin package). Cyclone > > is also MUCH faster, partially due to the process advantage and partially > > due to a superior architecture. This speed can turn into a cost reduction, > > since you don't need to buy as fast a speed grade, or you may not need to > > parallelize your data as much (and hence can fit in a smaller part). > > > > That's about it without getting into the details of the features. > > > > Regards, > > > > Paul Leventis > > Altera Corp. > > > > [This is my spammable email address; I have no affiliation with the > > University of Toronto besides being a student there] > > > > "CB" <cb@hotmail.com> wrote in message > > news:3e9e18e4.32935894@news.compuserve.com... > > > comparing the spartan2e and cyclone component lines in the 256 pin bga > > > packages , can anyone please tell me advantages in going with the > > > cyclone versus staying with the spartan2e , i don't care minor > > > differences in the ram and i/o but i am interested in significant > > > advanges the cylcone may have, thank you in advance > > Looks like the EP1C4 is still not out yet. At least it did not show up > when I did a web search at Arrow. The approach of providing a smaller > part with higher IO count is interesting. It fits my needs very well. > But looks like it is yet to come out. Any idea when? > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 54744
How much does cost the XC3S-200? U$3.50 for XC3S-50 is not that much competitive. It's half the logic cells (LUT+FF) of the EP1C3, does not have block RAM nor DCM (PLL like) and itīs just 50 cents cheaper!!! Will Xilinx let Altera reign free in this logic range? Luiz Carlos Oenning Martins KHOMP SolutionsArticle: 54745
>>P.S.: Have had a glance at Avalon, AMBA, CoreConnect, but either=20
>>didn't get
>>the features I wanted or was terrified by limitations in license=20
>>matters.
I would be interested to hear what objections you have to Amba or=20
CoreConnect. What features do you want?
--=20
Best regards,
Mit freundlichen Gr=FC=DFen,
Charles Gardiner
-------------------------------------------------------------
Charles Gardiner, B.E.
Siemens AG
Dept: I&S IT PS 8 SBY
Otto-Hahn-Ring 6
D-81730 Muenchen
Email: mailto:charles.gardiner@siemens.com
Phone: Mobile Office +49 151/1210 1903
Fax : Office +49 89/636 44595
Homepage : https://eda-services.mchp8.siemens.de/gardiner
(Siemens Intranet only)
I&S Homepage: http://www.atd.siemens.de/it-dl/eda
Article: 54746> Looks like the EP1C4 is still not out yet. At least it did not show up > when I did a web search at Arrow. The approach of providing a smaller > part with higher IO count is interesting. It fits my needs very well. > But looks like it is yet to come out. Any idea when? Hi Rick, EP1C4 is scheduled for release in September 2003. Given the early or on-time delivery of the other members of the family, this date is pretty solid. Regards, Paul Leventis Altera Corp.Article: 54747
Dear Pramod, Nice to see someone looking at an IIR filter. All too often people go for a big FIR just because it is easy. Let me make it clear that I am at Xilinx so I am bound to say the following things. It will of course read like an advert, but I hope I make some valid comments as well. I wrote a DSP Techniques Course which you can attend. The details of this well attended course are available at the following web address. You can also find out about where the course is being run in a location near you. http://www.xilinx.com/support/training/abstracts/v4/atp-dsp.htm In this course you will discover why it is always important to state the sample rates of your filter as this then raises may questions and observations about the ways in which the design can be implemented efficiently. For example, for a sample rate of 1MHz and a clock rate of 100MHz, each operation has 100 clock cycles to complete. This makes it possible to use bit serial processing techniques for an IIR filter enabling very high precision bit widths in a very small space. You will only tend to hear about these options with Xilinx due to the distributed RAM and shift register options which these FPGAs can offer. Obviously a device that lacks these features will not offer such a wide range of options. Of course it is possible to implement IIR filters right up to full parallel operating well in excess of 160MHz sample rates. As to the degree of truncation which is acceptable in an IIR, this is where modeling is really required. MatLAB (Simulink) and other mathematical packages such as SystemView are really excellent to perform these experiments. The advantage of using MatLab at the moment is that having created your model, it is possible to automatically generate your design using the Xilinx System Generator. It is useful to purchase a card with a device on it from someone like Nallatech where you can continue your filtering and stability experiments and tuning in the real world with real signals. Yours sincerely, Ken ChapmanArticle: 54748
I don't belive this will produce 100% results. Using the same DLL is a requirement to having a chance of working at the high speeds. The "same" edge is not necessarily guaranteed to be sourced from the same input edge through the delay taps to the output. I'd like it if they were such that input jitter won't produce skew between like edges. Without details on the DLL innerds, I can't make that call so I err on the side of caution. The clock skews are accounted for in the static timing analysis for worst case delays. If the longest Tcko, the longest net delays, the worst case Tsu and clock skew don't exceed your budget, the static timing analysis declares that you're "golden." Unfortunately, the "minimum" timing isn't specified. The skew between clocks can result in the earlier clock producing a result before the destination register (and associated clock) is clear of its setup/hold window. We have a guarantee for the same-clock situation where the clock skews are in the range of 10s of ps but not for the different-clock situation where that spread is easily in the 100s of ps. Other users have been bitten by crossing the 1x and 2x domains on the "common" rising edge so I'm trying to avoid that assumption that the edges are safely coincident. . . . I need to revisit my thoughts to see if I considered using latches instead of registers for the negedge x2 sampling of the x1 domain. I might sneak out 100s of ps with latches rather than registers. Eric Pearson wrote: > Hi John... > > Can't you generate both clocks from the same PLL so the edges stay > together, and use static timing analysis to handle any clock tree loading > skews? > I usually do anything to avoid "clock-the-clock" situations. > > Eric > > "John_H" <johnhandwork@mail.com> wrote in message > news:3E9C1B1F.8020305@mail.com... > >>Thanks, Ray. >> >>I used the RLOCs and double-checked the routing to make sure the numbers >>were "smallest" and still found myself with almost no margin left over >>for input jitter tolerance. The Tcko and any of the Tceck or Tdick or >>Tsrck values along with the shortest net I could muster left the 1.8 ns >>for 1/4 clock at the hairy edge. I was hoping there was an innovative >>approach to avoiding the 1.8ns requirement for a 7.2 ns x1clk. >> >>- John_H >> >>Ray Andraka wrote: >> >>>John, You are right ot be concerned about skew between the 1x and 2x >> > clocks. If > >>>you control placement and are clever about getting direct flip-flop to >> > flip-flop > >>>connections you can manage to do what you are describing using a falling >> > edge > >>>sensitive FF in the 2x domain to capture the 1x clock, then take the >> > output of > >>>the falling edge FF and feed it to a rising edge FF in the 2x domain to >> > time > >>>align the resulting CE with the 2x clock rising edges. The CE is >> > probably > >>>inverted WRT to what you wanted at that point, in which case an >> > additional > >>>rising edge FF will put it right without adding any logic delays in the >> > critical > >>>timing around the neg edge FF. You'll need to use primitives with RLOCs >> > on them > >>>to keep the timing tight, and with v4.2 and later tools you need to make >> > sure > >>>you put the time constraints in for each connection in order to keep the >> > router > >>>honest (3.3 did a good job of finding the direct connect without having >> > an > >>>explicit time constraint). >>> >>>John_H wrote: >>> >>> >>> >>>>Thanks for the message last week, Eric - my newsreader at work isn't >>>>100% and I had to read/respond at home. >>>> >>>>Your comment about only needing two flops is accurate as long as the >>>>designer can trust that the x1clk and x2clk domains will always work >>>>together as we'd expect where the rising edges are coincident. The >>>>reality is that those two edges may be separated by some 100s of ps >>>>since the clock net loading can be different between the two domains and >>>>input clock jitter to the DLL may translate to the two domains at >>>>different cycles. THe former problem is known, I'm only speculating on >>>>the latter. Bottom line: I can't depend on the two domains to play nice >>>>at the common rising edge, hense the nead to offset things by 1/4 the >>>>x1clk (or 1/2 th x2clk). >>>> >>>>Any further thoughts are appreciated. >>>> >>>>- John_H >>>> >>>>Eric Pearson wrote: >>>> >>>> >>>>>"John_H" <johnhandwork@mail.com> wrote in message >>>>>news:T9Hka.9$716.2363@news-west.eli.net... >>>>> >>>>> >>>>> >>>>>>Has anyone figured out a nice, clean method to track which phase of a >>>>> >>>>>Xilinx >>>>> >>>>> >>>>> >>>>>>DLL's 1x clock corresponds to a 2x clock cycle? One 2x rising edge >>>>>>corresponds to the 1x rising edge, the other 2x rising edge >>>>> > corresponds to > >>>>>>the 1x falling edge. >>>>>> >>>>>>When I start getting up in frequencies, the ability to use the 1x >>>>> > clock > >>>>>and >>>>> >>>>> >>>>> >>>>>>inverted 1x clock to generate two signals that I can XOR for a phase >>>>> > is > >>>>>>compromised. It's not inherently safe to use the 1x edges and 2x >>>>> > rising > >>>>>>edges as "effectively" the same edge due to clock skews and input >>>>> > jitter > >>>>>>issues. Using the falling edge of the 2x clock to sample the 1x >>>>> > generated > >>>>>>signals works, but at the 1/4 period timing budget is too tight at the >>>>>>frequencies I'm working. >>>>>> >>>>>>For those who are Verilog friendly, the code here shows how I would >>>>>>"normally" extract the phase without running a clock through a LUT. >>>>> > The > >>>>>>"negedge x2clk" is where the timing gets tough since the >>>>> > Tcko+Tnet+Tick is > >>>>>a >>>>> >>>>> >>>>> >>>>>>little over the 1/4 period of my x1clk. >>>>>> >>>>>>always @(posedge x1clk) posTog <= ~posTog; >>>>>>always @(negedge x1clk) negTog <= posTog; >>>>>>always @(negedge x2clk) rawPhase <= posTog ^ negTog; >>>>>>always @(posedge x2clk) phase <= rawPhase; >>>>>> >>>>>>Is there a cleaner way to figure out the which half of the x1clk I'm >>>>> > in? > >>>>>>Thanks, >>>>>>- John_H >>>>>> >>>>>> >>>>> >>>>> >>>>>It really only takes 2 flops working on rising edge. >>>>> >>>>>always @(posedge x1clk) Toggle <= ~Toggle; >>>>>always @(posedge x2clk) Delayed <= Toggle; >>>>>assign Phase = DelTog ^ Tog; >>>>> >>>>>Eric >>>>> >>>>> >>>> >>>-- >>>--Ray Andraka, P.E. >>>President, the Andraka Consulting Group, Inc. >>>401/884-7930 Fax 401/884-7950 >>>email ray@andraka.com >>>http://www.andraka.com >>> >>> "They that give up essential liberty to obtain a little >>> temporary safety deserve neither liberty nor safety." >>> -Benjamin Franklin, 1759 >>> >>> >> > >Article: 54749
Thanks Ben, Sounds like we're seeing similar results. I'm compiling using a C6 grade and my Fmax is about 10MHz lower. I found that eliminating my LogicLock regions sped up the compilation and improved the results. I guess it's true when Altera says you should only use LogicLock if you know what you're doing. Some recent feedback from Altera suggested that LogicLock is more of a benefit on the APEX parts than on the Stratix/Cyclone FPGAs. I'm using a 1.2 GHz Athlon K7 as well... I'm tempted to upgrade to a P4 but I'm not sure what sort of performance boost I'll see when using Quartus... tough call on wether to spend the money. Later! "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> wrote in message news:<bqQma.1696$KF1.81544@amstwist00>... > Hi Jim, > > "Jim M." <jim006@att.net> wrote in message > news:6f3fc0f8.0304141222.15bf1ca8@posting.google.com... > > I recently purchased a NIOS Stratix 1S10 Development Kit from Altera > > and have mixed feelings about Quartus, SOPC Builder, and the NIOS > > Core. (For those poor souls interested, I've included some comments > > at the end of this post... feel free to provide feedback.) > > > > However, here's my question: > > > > What's the maximum clock frequency anyone has achieved using the NIOS > > 3.0 CPU in 32bit mode with the standard peripherals (SRAM, SDRAM, > > Ethernet, PIO, UART, etc. as in the Reference Design provided by > > Altera)? > > The highest frequency I could get within one hour using the standard_32 > reference design was 92-and-a-bit MHz by changing to an EP1S10F780C5, plus > turning some of the logic resynthesis options on. Didn't use any LogicLock. > Fitting time was 15min on a 1.25GHz Athlon Classic, be it with 1Gb of > memory. > > Looking at the timing report (of course I tried to get to 100MHz) I found > that just about all of the slow paths were either in the SDRAM controller or > in the cache. > > Need any further help? > > Best regards, > > > Ben
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