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
Jack, Some parts come out quickly, others less so. Most of that is driven by market forces (where are the orders coming from?). If you want a 2V1500, you can use the 2V2000 (or 2V3000) until the 2V1500 is ready. I am sure that our sales partners would arrange something to make it worth your while. Part of our success is having a wide range of parts that overlap in package and IO so that customers can optimize their choice of part once they get into production. The announcement of the agreement with IBM, the licensing of the Mindspeed serdes, the 405PPC(tm IBM), etc. all make for good press. The rollout of the Virtex II Pro to the first beta customers happened roughly 12 weeks before the silicon was due to fab out. That way folks could start designing in the product. The rollout of the technology makes it seem like the parts were announced, but that is linked to the first datasheet that gets posted, not when we talk about .13u core technology (1/31/02 date on datasheet, ES parts shipped in March, 2002). To announce a product 6 months before it gets here is just fine. If you can deliver. I do congratulate Altera on their delivery of Stratix, which was on time, and maybe a little bit ahead of time for the first sample. Good work. Sometimes it all comes together. Now comes the hard part: all of the family members that follow. I intend to be accurate, and fair (and use facts). As for defensive? Absolutely. Part of a good defense is a good offense, as well. And introducing Virtex II Pro and then extending the family to some 10 devices sounds pretty good to me (2Vp2 to 2VP100). Austin Jack wrote: > Sounds like you're being defensive, Austin. Announcing product before > it is available? Xilinx does this all the time. When did you first > start talking about Virtex-II Pro? I think I saw articles about two > years ago. I don't think this is a bad thing, necessarily. It is nice > to know what is coming in advance; design cycles are shorter in FPGAs > but they still aren't instantaneous. > > However, what about the 2V1500 I was told would be available by June > (2001)? I think it just came out this August (2002). This is a > little more design time than was necessary, don't you think? > -Especially if you were counting on that June'01 delivery. I believe > this was also the case with the 2V2000. > > http://www.xilinx.com/prs_rls/vtx2ship.htm > "The first members of the Virtex-II family... are sampling now with > the rest the family sampling by mid 2001." > > Jack > > Austin Lesea wrote: > > I will reiterate something Peter has said once before: Altera has announced that they will have (note use of the future tense) .......Article: 47426
ESD mitigation can be a difficult science. An ESD discharge to the board can cause power supply spikes or dips, transients on clock or other critical signals and so on. Often it can be hard to identify the exact mechanism that is causing the disruption, and may be easier to protect the entry point better. You might consider contacting someone who specializes in it such as Mike Violette of Washington Laboratories, Ltd in Gaithersburg Md. Jim Granville wrote: > Jeremie WEBER wrote: > > > > > You need to determine if this is Config stream corruption, or > > > Logic-state engine corruption - it sounds like the latter. > > > > No, it is the logic state. All state machine are not a problem because all > > states are checked and it always come back to a known state. But I use a ram > > block wher all my datas are stored and this one seems to be corrupted. > > A reset ( of my design, not of the chip itself ) could make the system > > working but it not occurs. > > If you do not have a manual reset, I would add one, to confirm the > system can re-init ( ie FPGA config latches, and logic state engines > are all intact ) > > > > > > The design needs to have recovery schemes for this. > > > > Any advice on it ? > > If you are confidant your state engines recover, then once data > corruption > occurs, you will need to 're-init', rather like a uC WDOG. > > Of course, recognising the data is corrupt is not trivial in itself :) > > In a FPGA, if you have RAM to spare, you could try parity, or Error > Correcting storage. > ECC can flag a fix, so you can track errors under test. > > If the data is corrupted outside the ECC realm ( eg at 'instant of read' > ) > then you cannot so easily error detect. > > > > As ESD levels ramp, there will be a range where corruption occurs, > > > but damage does not. Ramp it more, and damage starts... > > > > Honestly, the Spartan IIE is quite robust to ESD. Our test has been made > > with 5kV ESD and with a kind of home made ESD Generator ( a piezzo gas > > lighter ;-) ) wich seems to be higher than 5kV because the board does not > > crash anymore at 5kV and crash with our home made ESD Generator ! > > This is quite an aggressive ESD test, so it's no surprise to see > some effect. > The ESD ratings on chips are damage only, no-one promises > to keep the device operational as well :) > > - jg -- --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, 1759Article: 47427
Using power planes is just a rule of thumb; its the EASIEST way of guaranteeing a low impedance supply path. But depending on the size of your design, the number of outputs you switch at once, and other things, isn't not entirely necessary. On a 2 layer board you can do a copper pour of ground after you route it, while its not as good as full plane its better than just routes. You can route your supply pins with wide traces, and before routing anything else, bypass every supply pin as close to the pin as you can. Use an on board supply. If your design fits on an 8000 family part, then your talking about a really tiny design, so it will be a small part in any family. Regards Jarmo <jarmoma@REMTHIS.mail.student.oulu.fi> wrote in message news:<Pine.GSO.4.44.0209251113310.11071-100000@paju.oulu.fi>... > Hey > > I want to make Printed Circuit Board (PCB) for Altera Flex 8000 family. > Problem is that I don't find any datasheet telling me how to do the > powering for the Altera. Should I add decoupling capasitors and what > values they should be? > > Is there internal clock in Altera or should I add a crystall to my PCB? > > If you are wondering why I want to use OLD Altera Flex 8000, because I > want to add only 2 layers to my PCB. I think that new Alteras need > separate power and ground layers, so 2 layers is not enough. > > is there some websites/tutorials how to do PCBs for FPGAs? > > - Jarmo > jarmoma@mail.student.oulu.fiArticle: 47428
The package is a really a small part of the cost of these chips. The die are very large (and hence the circumfrence and associated I/O ring), so I/O is cheap and easy to add, so they do. A smaller package pin count, while technically producable, may only reduce the cost a few percent. In contrast, on a small high yield die, package cost can be a big part of the cost, but we're in the opposite end of the spectrum with FPGAs. So if the cost is nearly the same for a high or low I/O package, the only advantage is ease of assembly for a larger pitch part. Products that use FPGAs tend to be low volume, high value, so theres not much pressure to have a lower tech soldering process either. So these are some of the reasons people end up doing like use and using 40% of the pins in an 1152 pin package. > We are constantly bumping up against the largest device in a cost > effective package. IE, we definitely would move to using a larger > Virtex-II (XC2V4000) if it were available in anything smaller than an > expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA > package]. I realize Xilinx probably has their reasons for the > offerings they have (most likely thermal?), but if they could overcome > that, it'd be easy money for them, cause I'll bet there are others out > there in the same boat as us. > > Same went for the Virtex-E... the 600E was the largest you could get > in a reasonable cost/size package. The XCV812EM was available, but > not competitively priced. We would have used a large device if Xilinx > had offered it in a FG676. Instead, in both the Virtex-II and > Virtex-E, we get to play roulette with MAP and PAR, constaintly > bumping up against random timing violations that differ from run to > run. > > Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or > actually, just a 3000 with more LUTs, not more BRAM's]? > > MarcArticle: 47429
Dan, We use a development board from Insight Electronics. The board is available for XC2VP4/P7 Virtex II-pro devices. You can purchase the board online on their web site : http://www.insight-electronics.com. Marty. "Dan" <hombecker1962@hotmail.com> wrote in message news:f6989659.0209242140.845a696@posting.google.com... > Is anyone aware of current development boards and software packages > available for the Virtex II Pro series with the embedded power pc > processor (namely one or two). I'm not having much luck finding them. > I know it's a very recent product, and I think this is one of my > problems. > > Thanks, > DanArticle: 47430
The spartan II is a Virtex I and there is no "clear program memory" command in the command set. They do have this in the Virtex II though. However since the configuration files genereated by Impact are full configurations you should be able to write over a configuration with no problem. This must be a software bug. You can try and download Hotman from our web site it is not as "automatic" as impact so it does not have some of the bugs. Steve www.vcc.com > I sincerely hope this posting helps some future poor sap(s) from > wasting as much time as I did.Article: 47431
Hello folks, I generated 2 filters using coregen - a singlerate and an interpolated filter with the following common params: coefficients: "1,3" (3 bits, signed, non-symmetric, fixed, optimisation switched on) input: 1 bit unsigned parallel implementation with registered output Zero Packing Factor = 4 for the interpolated filter. Both filters take 9 slices on a xc2v40-fg256-5 using ISE 4.2.03i. My question relates to why these filters should be the same size (in slices) when the interpolated filter does "more". Here are the mapping stats for both: Singlerate: Number of Slices: 9 out of 256 3% Number of Slices containing unrelated logic: 0 out of 9 0% Number of Slice Flip Flops: 11 out of 512 2% Total Number 4 input LUTs: 4 out of 512 1% Number used as LUTs: 3 Number used as Shift registers: 1 Number of bonded IOBs: 11 out of 88 12% Interpolated: Number of Slices: 9 out of 256 3% Number of Slices containing unrelated logic: 0 out of 9 0% Number of Slice Flip Flops: 11 out of 512 2% Total Number 4 input LUTs: 5 out of 512 1% Number used as LUTs: 3 Number used as Shift registers: 2 Number of bonded IOBs: 11 out of 88 12% Looking at the post place and route floorplans of both, what jumps out is that the singlerate case has 7 flip-flops being used on their own in slices without the LUT (as an FG or an SRL16) whereas the interpolated case has only 6 flip-flops on their own in slices. It seems that, for the interpolated case, adding the 3 sample delay between the filter taps (done with 3 SRL16s for the 3-bit signal) simply means that coregen makes more efficient use of the logic - i.e. instantiates 1 less flip-flop on its own. It also seems that SRL16s are always mapped together with a flip-flop by the tools (is this the case?) - presumeably with the flip-flop taking the last delay of an N bit delay with the SRL16 doing N-1 delays (N <= 16) - is this right. Surely, then coregen could do a better job (i.e. less slices) of the singlerate case since the interpolated filter simply requires more logic? Or, could the slice cost of the singlerate case be reduced through some clever manual floorplanning? I realise that this post is a little hand-wavy and that you might not be able to give me some categoric answers but I would appreciate your thoughts/experience in these areas - even if you do put it all down to tool "black magic" ;-) . Thanks for your time, KenArticle: 47432
I'd expect balance concerns if the terminations weren't symmetric around Vtt. Are you using the recommended SSTLII style terminations? Beyond that, the signal routing is the next point that would concern me. The two signals should be routed together to avoid skews and - to some extent - keep the differential voltage signal coupled between the traces. If the pair is on the same layer, the routing can be kept to a minimum of skew. A coworker just pointed out (as I was looking at the DDR routing I have) that a pair is fine on two symmetric internal layers between planes as long as they have the *same* routing - the differential energy is vertical in the board. Since you have a board that you're trying to get to "work," if the signals are indeed suffering from different routings, you might be able to compensate by playing with the termination values, both the series resisters and the Vtt resistors. The lag you measured - is this rising CLK and falling CLK* relative to a reference? If it's CLK destination relative to CLK source and CLK* destination relative to CLK* source, there are severe layout issues. If the "lag between the two clocks" is the asymmetry, you might want to check (if possible) the real delay from source to destination. Good luck. John Daae wrote: > I have implemented a DDR SDRAM controller in a VIRTEX II but I have problems > balancing the clock / not clock to the DDR Sdram. The design work with no > errors, but the switching where the clk and not clk intersect is outside the > DDR Sdram specification (MICRON specify that the intersction between the two > clock should always lie within the 1.05-1.45 voltage range. This is observed > using a ocsilloscope with active probes. > > The two clock are generated be dual-data rate FFDs as follow (the CLK and > nCLKcomes from a DCM with duty-cycle correction set): > > --------------------------------------------------------------------------- > -- > -------------------------------------------------------------------------- > --- > -- SDRAM clock generation > -------------------------------------------------------------------------- > --- > -------------------------------------------------------------------------- > --- > clk_gen : > FDDRRSE port map ( > Q => ddr_clk, > D0 => '1', > D1 => '0', > C0 => clk, > C1 => nCLK, > CE => '1', > S => '0', > R => '0'); > > nCLK_gen : > FDDRRSE port map ( > Q => ddr_CLK180, > D0 => '0', > D1 => '1', > C0 => clk, > C1 => nCLK, > CE => '1', > S => '0', > R => '0'); > > ---------------------------------------------------------------------------- > ---------------- > > Using 1.25V as a reference, the lag between the two clocks seen on the PCB > is as follow: > > 128 ps using SSTL2_II > 327 ps using SSTL2_II_dci > 618 ps using SSTL2_I > 1364 ps using SSTL2_I_dci > > Obviously the latter standards have lower drive capability and thus slower > slopes and thereby more lag between the clocks. > > But I think there must be a lag between the clocks before the actual drivers > which I cannot account for. I have inspected the FDDRRSE in the FPGA Editor > a find that there is no delay difference between the clocks into the clock > pins. So WHAT causes the difference? > > ANY IDEAS ANYONE? > > Thanks > > JohnArticle: 47433
--------------C52BA1F100BFC43FEDF15FD6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jérémie, Many years ago I hired an ESD expert to teach me how to find, and fix ESD problems in a system. I will describe what he did. He came in with a roll of aluminum foil. He wrapped the entire system in foil (cables and all), and then zapped it. If it failed, he said that the problem was probably nearly hopeless, and would require a lot of time and experimentation, as the system was hyper-sensitive. It passed, so I was happy to have gotten past the first hurdle. He then unwrapped just the cables, and let them hang out. He zapped it, and it failed (processor reset). We then had to place small capacitors, zeners, or resitive diode networks on all interfaces to all cables. We did that over two weeks, and then he came back. The unwrapping continued. We opened up the keyboard area. We zapped it, and it failed. Again we went through all interconnections to the keyboard, and protected them. Then it passed. We then unwrapped everything down to the metal box (chassis). We zapped it and failed. It turns out that a screw every 3" (~75 mm) to a sheet metal lip that had an over-lap will limit the electric charge from racing through the slot, and upsetting 5V logic. Maybe you would need to place the screws at 2" intervals now.... (The ESD discharge can be modeled as a traveling wave over any surface: a sheet of charge that goes over, around, and through any aperture at the speed of light with a frequency range into the 10's of GHz). So, a month later, some money and a few dozen R, C and diodes, and a roll of aluminum foil later, we had 12KV human body model ESD protection capability. By the way, after we did the ESD, we also passed FCC/VDE for EMI/RFI. If you do a good job on one, you also solve the other. I recommend hiring the consultant to do this for you the first time. After that, it is embarrasing to have to hire them again unless you just can't find the last sneaky places where ESD is getting into your system, Austin "Jérémie WEBER" wrote: > I have a problem with a design ( 200k spartan II E ) that fail when an > Electrostatic discharge occurs. > > I presume that some flip-flop are reseted but not all. That means that my > design fail and is unstable. > > I have set some hardware things to avoid a large part of this problems but > when it occurs I always fail. > > Have you got any Idea to secure the FPGA design itself ? > > Regards. > > Jérémie WEBERArticle: 47434
Keep in mind that the lower-cost devices such as the Spartan-IIE (and the Cyclone?), the package *is* a significant portion of the overall cost, not single digit percent. In the enormous xc2v6000, it's hard to imagine how any package would impact the price. I've been buying the bigger devices for pin count with low logic utilization in my current designs compared to the telecom centric stuff I was doing a few years back where I/O wasn't a big concern. It takes all kinds... Jay wrote: > The package is a really a small part of the cost of these chips. The > die are very large (and hence the circumfrence and associated I/O > ring), so I/O is cheap and easy to add, so they do. A smaller package > pin count, while technically producable, may only reduce the cost a > few percent. In contrast, on a small high yield die, package cost can > be a big part of the cost, but we're in the opposite end of the > spectrum with FPGAs. > > So if the cost is nearly the same for a high or low I/O package, the > only advantage is ease of assembly for a larger pitch part. Products > that use FPGAs tend to be low volume, high value, so theres not much > pressure to have a lower tech soldering process either. > > So these are some of the reasons people end up doing like use and > using 40% of the pins in an 1152 pin package. > > > We are constantly bumping up against the largest device in a cost > > effective package. IE, we definitely would move to using a larger > > Virtex-II (XC2V4000) if it were available in anything smaller than an > > expensive 1152 pin flip chip package [or the monster 40x40 1.27 mm BGA > > package]. I realize Xilinx probably has their reasons for the > > offerings they have (most likely thermal?), but if they could overcome > > that, it'd be easy money for them, cause I'll bet there are others out > > there in the same boat as us. > > > > Same went for the Virtex-E... the 600E was the largest you could get > > in a reasonable cost/size package. The XCV812EM was available, but > > not competitively priced. We would have used a large device if Xilinx > > had offered it in a FG676. Instead, in both the Virtex-II and > > Virtex-E, we get to play roulette with MAP and PAR, constaintly > > bumping up against random timing violations that differ from run to > > run. > > > > Anyone else in the same boat, wishing there were an XC2V4000-FG676 [or > > actually, just a 3000 with more LUTs, not more BRAM's]? > > > > MarcArticle: 47435
Hal Murray wrote: > What's magic about a toggle switch? I thought they all bounced too. > > Are you thinking of SPDT kicking an R-S type FF? Yes, exactly. The storage device can be a latch, even be a cross-coupled set of inverters, in which case you need only one I/O pin. You just yank that pin to Vcc or to ground. High instantaneous current, but only for a nansecond or two. Contact bounce is irrelevant in that case Peter AlfkeArticle: 47436
In article <3D91F52F.A89F0BBA@mail.com>, John_H <johnhandwork@mail.com> wrote: >Keep in mind that the lower-cost devices such as the Spartan-IIE (and the >I've been buying the bigger devices for pin count with low logic utilization >in my current designs compared to the telecom centric stuff I was doing a >few years back where I/O wasn't a big concern. One observation is that they are still using perimiter pads on these parts, so that upping the IO beyond a certain point necessitates a bigger die. I'd personally like to see an area pad FPGA, where some of the logic blocks are replaced with pads, so we wouldn't have these issues. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47437
I am very interested in programming and running the fpgas from a microcontroller. Does anyone know where I can find a good book or tutorial on the net? Know any good evaluation/proto boards? Thanks --DaveArticle: 47438
There is many ways you can do it. Xilinx has published multiple detailed appnotes on this. Here are some of them: http://www.xilinx.com/xapp/xapp058.pdf http://www.xilinx.com/xapp/xapp176.pdf http://www.xilinx.com/xapp/xapp188.pdf http://www.xilinx.com/xapp/xapp098.pdf I believe Altera has similar information for their chips... /Mikhail "David Horner" <dhorner@med-web.com> wrote in message news:b67cf57a.0209251129.129fc6f1@posting.google.com... > I am very interested in programming and running the fpgas from a microcontroller. > > Does anyone know where I can find a good book or tutorial on the net? > > Know any good evaluation/proto boards? > > Thanks > --DaveArticle: 47439
I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block Multipliers. I'm looking at the Post-Place-and-Route Static Timing Analyzer. I added output registers on the block RAMs to bring the Min Period down from 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers (Tmult=4.121ns plus 2 nets plus FFin/outs). Is this it, or is there anything I can do to make it faster in this speed grade ? I don't want to increase the multiplier latency, as I'm working with an iterative algorithm and the multiplier output gets fed back to the input. Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041 ns. How is this possible ? Thanks, -rajeev-Article: 47440
Kon-nichi-wa, Spartan-II's I/Os configured in LVTTL accept 5 volts, drive more than 2.4 volts (at Vcco=3.3 volts) then it works with 5 volt PCI bus. (with right design ^_^;) But Spartan-IIE, Virtex-E and later FPGAs are not for 5 volt compliance. Good Luck! -- ------------------------- DOHI, Yutaka mailto: y_dohi@hotmail.com http://www4.justnet.ne.jp/~dohi/ "Jamba" <xxxx@supereva.it> wrote in message news:wvek9.140505$ub2.3069274@news1.tin.it... > > > I have to mount a spartan II fpga ( 3.3 volt ) with an 5 volt interface pci > 32 bit. > How is it possible? > > Thanks, J > >Article: 47441
From previous experience with the xilinx tools at my compagny, if you delete the files generated by the place&route tool when you want to rerun the flow, it makes the P&R faster and gives better results. This is due to the P&R tool taking old files as a "reference", just like reentrant routing. I did not follow what Xilinx had to say about it but I would be curious to know. Dali Clyde R. Shappee wrote: > No, the design is only half empty (optimist!). > > What I have learned today is that the place and route tool is passing constraints onto the Xilinx flow, > and this has been probably constraining the design where it should not be so stringent. > > I had some help today from a resource that is getting me on my way to properly constraining the design. > > It does appear that the varying number of logic levels is coming from the Xilinx P/R and not the > synthesis tool. > > Clyde > > Marc Randolph wrote: > > >>"Clyde R. Shappee" <clydes@world.std.com> wrote in message news:<3D910893.3ACBCF64@world.std.com>... >> >>>Hello, all, >>> >>>I am working a design with the Xilinx Spartan IIe, using ISE 4.2 sp3, >>>Sinplicity 7.1 for synthesis. >>> >>>My design is relatively minimally constrained and meets static timing. >>>In my report I see 8 levels of logic associated with my system clock. >>> >>>Today, I removed some unused logic, and reduced the length of some shift >>>registers in my design, dropping about 32 flip-flops. >>> >>>Now the design fails to make static timing and the number of levels of >>>logic associated with my clock has gone up to 12! >>> >>>What is at work here? >>> >>>Is the synthesis tool shooting me in the foot, or is it in the Xilinx >>>tool, or my constraints. >> >>Howdy Cylde, >> >>Is this device pretty full? We've only run into this type of problem >>when things are pretty packed. >> >>When this occurs, our typical mode of operation has been to do a >>multi-pass place and route if it is close to meeting timing (say a >>timing score of under 10000). One of the passes will usually hit on >>an overnight session. >> >>If the timing is further out than that, we just continue improving the >>code where we can (often times in areas completely unrelated), and the >>next time around, it often meets timing, or gets very close (and will >>meet with a multi-pass session). >> >>Good luck, >> >> Marc > >Article: 47442
I would look in the file generated by your synthesis tool (edif for synplicity) because that's where the nets are named with such generic names. Then you can then look at the net drivers. What you can do also is to ask the synthesis tool to preserve hierarchy so you can locate the net into a module easily. Dali David R Brooks wrote: > Running the Xilinx ISE 4.2i tools, I get a warning > ERROR:NgdBuild:455 - logical net 'N812' has multiple drivers > > Now the meaning is obvious enough, but the problem is, how to locate > this net (it is a synthesiser-generated name) in the hierarchy. The > tools don't give any indication where it is located. It is a large > project, with over 40 VHDL design elements in a deep hierarchy. > > A search of the output files shows none of them contain this string, > except the NGD log, which only contains the error as above. > > This error causes no post-synthesis VHDL file to be generated, else > one could search that file for the net. > > Any ideas? >Article: 47443
Rajeev wrote: > <snip> > Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041 > ns. How is this possible ? How wide is your multiplier, both operands and the result? Fewer than 18-bit-wide operands improve the through-delay. Peter Alfke-Article: 47444
--------------9E61DE124A94F663DF680181 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Much like my experiences. He also had a box of all sorts of ferrites with him, and in my case he stuck around until we got the system passing. Austin Lesea wrote: > Jérémie, > > Many years ago I hired an ESD expert to teach me how to > find, and fix ESD problems in a system. > > I will describe what he did. > > He came in with a roll of aluminum foil. > > He wrapped the entire system in foil (cables and all), and > then zapped it. If it failed, he said that the problem > was probably nearly hopeless, and would require a lot of > time and experimentation, as the system was > hyper-sensitive. > > It passed, so I was happy to have gotten past the first > hurdle. > > He then unwrapped just the cables, and let them hang out. > > He zapped it, and it failed (processor reset). > > We then had to place small capacitors, zeners, or resitive > diode networks on all interfaces to all cables. We did > that over two weeks, and then he came back. > > The unwrapping continued. We opened up the keyboard area. > > We zapped it, and it failed. > > Again we went through all interconnections to the > keyboard, and protected them. Then it passed. > > We then unwrapped everything down to the metal box > (chassis). We zapped it and failed. > > It turns out that a screw every 3" (~75 mm) to a sheet > metal lip that had an over-lap will limit the electric > charge from racing through the slot, and upsetting 5V > logic. Maybe you would need to place the screws at 2" > intervals now.... > > (The ESD discharge can be modeled as a traveling wave over > any surface: a sheet of charge that goes over, around, > and through any aperture at the speed of light with a > frequency range into the 10's of GHz). > > So, a month later, some money and a few dozen R, C and > diodes, and a roll of aluminum foil later, we had 12KV > human body model ESD protection capability. > > By the way, after we did the ESD, we also passed FCC/VDE > for EMI/RFI. If you do a good job on one, you also solve > the other. > > I recommend hiring the consultant to do this for you the > first time. After that, it is embarrasing to have to hire > them again unless you just can't find the last sneaky > places where ESD is getting into your system, > > Austin > > "Jérémie WEBER" wrote: > >> I have a problem with a design ( 200k spartan II E ) >> that fail when an >> Electrostatic discharge occurs. >> >> I presume that some flip-flop are reseted but not all. >> That means that my >> design fail and is unstable. >> >> I have set some hardware things to avoid a large part of >> this problems but >> when it occurs I always fail. >> >> Have you got any Idea to secure the FPGA design itself ? >> >> Regards. >> >> Jérémie WEBER > -- --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, 1759Article: 47445
It sounds like his image is too big to do a corner turn in on-chip memory. Without doing clever things he pretty much is stuck with single word writes. Fortunately, he doesn't have to live with that. Rather than reading linearly, you can be a little cute about how the writes are done so that the data stored in the memory is a transformation 'halfway between' the row ordered and the column ordered image. The sole purpose of doing that is to be able to use some small bursts in order to hide the active commands. Using auto precharge alleviates the need for an explicit precharge command, but you do still have to be careful to allow enough time for the precharge, active and the minimum times between. With 4 banks, I think you can get there with a burst size of 4, and perhaps 2 if the cas latency is 2. It is going to take a bit of playing with the address order on both read and write, plus a smallish reordering buffer on both the read and write paths to make it happen. "A. Nelson" wrote: > I have an odd problem that I'd like anyone's opinion on. > > I have a data stream, that I'd like to write into SDRAM (I'm writing my own > controller, so I can do it any way I'd like). However, I don't want to > write across a row (like you're supposed to do, so you can take advantage of > bursting), but rather across a column. > > This means that every word would go to a different row. So, every word > would require a full write cycle (active, write, precharge). This is far > too slow. > > So, I got the idea of "bursting" across the banks (which allows for 4 > writes, before a precharge), like this: > > (A=Active, W= write, P = precharge, r=row, b=bank, c=column) > > A (r 0, b 0), W (c 0, b 0), A (r 0, b 1), W (c 0, b 1), A (r 0, b 2), W (c > 0, b 2), A (r 0, b 3), W (c 0, b 3), P > > then > > A (r 1, b 0), W (c 0, b 0), A (r 1, b 1), W (c 0, b 1), A (r 1, b 2), W (c > 0, b 2), A (r 1, b 3), W (c 0, b 3), P > > and so on (with the required NOPs, to meet timing). > > I was also considering doing all the actives, then writes, then precharge > (A, A, A, A, W, W, W, W, P). > > Any other suggestions? -- --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, 1759Article: 47446
YOu get a bit more by carefully placing the flip-flops around the multiplier so that each gets a direct connect to the multiplier rather than having to go through extra pips to get there. You'll have to go into the FPGA editor to figure out where those need to go. THere may be an app note on the xilinx website detailing that placement for max performance, I know it had been talked about. Rajeev wrote: > I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block > Multipliers. I'm looking at the Post-Place-and-Route Static Timing Analyzer. > > I added output registers on the block RAMs to bring the Min Period down from > 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers > (Tmult=4.121ns plus 2 nets plus FFin/outs). > > Is this it, or is there anything I can do to make it faster in this speed > grade ? I don't want to increase the multiplier latency, as I'm working with > an iterative algorithm and the multiplier output gets fed back to the input. > > Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041 > ns. How is this possible ? > > Thanks, > -rajeev- -- --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, 1759Article: 47447
Oh, one more thing. you could use a pair of multipliers and interleave them so that you get two products per clock. Rajeev wrote: > I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block > Multipliers. I'm looking at the Post-Place-and-Route Static Timing Analyzer. > > I added output registers on the block RAMs to bring the Min Period down from > 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers > (Tmult=4.121ns plus 2 nets plus FFin/outs). > > Is this it, or is there anything I can do to make it faster in this speed > grade ? I don't want to increase the multiplier latency, as I'm working with > an iterative algorithm and the multiplier output gets fed back to the input. > > Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041 > ns. How is this possible ? > > Thanks, > -rajeev- -- --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, 1759Article: 47448
XAPP200 speaks to this issue, as regards getting the balance right *within* the chip. It shows one clock phase generated from the DLL, and a simple inverter used to generate the other. So the flow is: DLL --+---------- OBUF --> clk | +-- INVT -- OBUF --> clkb This works, because the inverter is pulled into the output block. Assuming you have placed the outputs in adjacent pads (in XAPP200: NET ddr_clkb LOC = E28 ; NET ddr_clk LOC = C30 ; ), the wire-delay to the pads must be equal, as it is the same wire. The extra delay from the buried inverter is apparently negligible. "John Daae" <john.daae@datarespons.no> wrote: :I have implemented a DDR SDRAM controller in a VIRTEX II but I have problems :balancing the clock / not clock to the DDR Sdram. The design work with no :errors, but the switching where the clk and not clk intersect is outside the :DDR Sdram specification (MICRON specify that the intersction between the two :clock should always lie within the 1.05-1.45 voltage range. This is observed :using a ocsilloscope with active probes. : :The two clock are generated be dual-data rate FFDs as follow (the CLK and :nCLKcomes from a DCM with duty-cycle correction set): : : ---------------------------------------------------------------------------Article: 47449
Reference : http://www.xilinx.com/xapp/xapp636.pdf Ray Andraka wrote: > YOu get a bit more by carefully placing the flip-flops around the multiplier so > that each gets a direct connect to the multiplier rather than having to go > through extra pips to get there. You'll have to go into the FPGA editor to > figure out where those need to go. THere may be an app note on the xilinx > website detailing that placement for max performance, I know it had been talked > about. > > Rajeev wrote: > > > I'm dealing with timing on a 300-slice design with 2 block RAM and 2 block > > Multipliers. I'm looking at the Post-Place-and-Route Static Timing Analyzer. > > > > I added output registers on the block RAMs to bring the Min Period down from > > 9.6ns to 7.8ns, now my slowest paths are internal to the Block Multipliers > > (Tmult=4.121ns plus 2 nets plus FFin/outs). > > > > Is this it, or is there anything I can do to make it faster in this speed > > grade ? I don't want to increase the multiplier latency, as I'm working with > > an iterative algorithm and the multiplier output gets fed back to the input. > > > > Also, I've seen variations on the _internal_ path delays from 7.827 to 8.041 > > ns. How is this possible ? > > > > Thanks, > > -rajeev- > > -- > --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
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