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
Jecel wrote: > I try to keep a reasonably updated list of such projects at > > http://www.merlintec.com:8080/hardware/31 The commodore 64 clone "C-one" which is in your list is interesting. It has been implemented in an ASIC and has been sold as a commercial product. http://en.wikipedia.org/wiki/C64_Direct-to-TVArticle: 145426
jfh wrote: > Hi; > > We are trying to program a CFI Flash (Numonyx TE28F320J3D75) using the > flash programmer of Quartus II/EDS 9.1. We followed the instructions > given in the User's Guide (from february 2010 !), and the programmer > is reading the CFI table correctly, but when it comes to actual > programming, it stops at 0%, with the following message : > " > Program failed > Error code : 4 in .....nios2flashprogrammer.exe .... > " > In parallel, we have been running read and write tests on the flash > and they are passing. > Thus we suspect that something may be wrong with the flash > programmer... would you have any idea of what we need to check and > what we can do to have a bit more visibility of what's going on ? > > Best regards, > > JF If you've tried all the advice in section 3 (--debug, flash override file etc), perhaps you should follow the last sentence :-) "If you find a CFI-compliant device that does not work with the Nios II Flash Programmer, please report it to Altera Technical Support." regards Alan -- Alan Fitch Senior Consultant Doulos – Developing Design Know-how VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 1AW, UK Tel: + 44 (0)1425 471223 Email: alan.fitch@doulos.com Fax: +44 (0)1425 471573 http://www.doulos.com ------------------------------------------------------------------------ This message may contain personal views which are not the views of Doulos, unless specifically stated.Article: 145427
Daku <dakupoto@gmail.com> writes: > Could some Xilinx ISE guru provide some hints for my problem ? I am > trying to synthesize a simple 4K RAM block with Xilinx ISE. About half- > way through execution, I get an error message, inside a Visual Studio > dialog box, stating that xst.exe ( the Xilinx synthesis executable) > has encountered a problem and would I like to debug ? The Xilinx ISE > is running Can you try synthesizing a much smaller RAM (say 128 words?) Can you post your code? What does the synthesis logfile say? You haven't given us much to go on! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 145428
On 2/8/2010 5:14 AM, rickman wrote: > On Feb 6, 7:37 pm, Symon<symon_bre...@hotmail.com> wrote: >> On 2/6/2010 5:38 PM, rickman wrote: >> >>> I keep asking you if you have done any real analysis or measurements >>> of what you are stating? >> >> > >> >> Well, this was the first time you asked IIRC, but thank you for doing >> so. The answer is "For sure". I've used Hyperlynx and Spice on my >> boards. I guess you have also, or else you would not be able to post >> your opinions without worrying you might giving someone a bum steer. > > So are you going to share the results of these simulations on the vias > you are talking about? > > Sure Rick, let's go through it together with some cheap tools (free!) from t'internet. OK, you can get a nice copy of Spice from here. maybe you already have it. http://www.linear.com/designtools/software/ At the bottom of this post you will find a model of a PCB with a power plane bypass. I've used lumped components to model it. If you cut'n'paste the text into an editor and save it as 'planes.asc' or somesuch, you should be able to load it into the simulator you downloaded. So, if you look at the model, here's what each bit does. V1 DC power supply. L3 Big inductor to represent the PDS supply impedance. C2, R2, L4 model a 0402 1uF bypass capacitor. L4 includes the vias. C4 Models the power plane bypass. No parasitics on this baby! L1 Models the power via and ball from the plane to the FPGA die. C3, R3, L5 model the bypass capacitor on the FPGA BGA package. R1, C1, V2 model a IOB switching with 500ps rise time. Rout=20,Cpin=10p L2 Models the ground via from the PCB plane to the FPGA die. BTW, you can find models of bypass capacitors here:- http://www.murata.com/products/design_support/mcsil/index.html Signals are:- PCB_PWR is the power on the PCB FPGA_PWR is the power on the BGA package. FPGA_GND is the ground on the BGA package. Vout is used to show when the switching happens. (1) If you press the little 'running man' button, a simulation window will appear. You can now click on nets in the schematic. I clicked on FPGA_PWR, FPGA_GND, Vout and PCB_PWR. I also clicked on Windows -> tile vertically to give a nicer picture. Whatever, let's call this experiment 1. OK, we see the power on the BGA is quite well behaved as expected. 60mv of overshoot and ground bounce. (2) So, what happens if we remove the bypass made from the power plane being next to the ground plane, and instead use a ground plane near the surface? If you make the schematic the active window by clicking in it, then click the scissors symbol, then click on C4, that's got rid of the power bypassing. If we right click on L2 and change it to 0.5n, (N.B. don't forget the 'n'!) that's the same as moving the ground plane near to the surface, as the via inductance is reduced by this much. Call this experiment 2. Here we see a little difference. The power overshoot is now a bit bigger, maybe 110mV. The ground bounce is less, about 30mV. (3) If we add another bypass capacitor, using the copy feature (next to the scissors!) to copy L4, R2 and C2, we can do experiment 3. Here we see smaller overshoot, maybe 100mV, showing that if a few bypass capacitors are added we would get back the performance of a 'plane built capacitor'. (4) Let's go back to the original design. If you press F9 enough times you'll undo any changes. Try deleting the 'on BGA' bypass capacitor C3. experiment 4. You will now see much bigger overshoots and ground bounce. That's why the FPGA manufacturers put bypassing on the BGA. (5) OK, back to the original design again with F9. Let's try this. Let's say we only have a small board, a few square inches, and the plane capacitance is only 200pF. Right click on C4 and change it to 200p. Experiment 5. Here we see the potential danger of using a power plane derived bypassing system. The high-Q power plane is resonanting with L1, the via and ball inductance to start an oscillation. With ordinary bypass capacitors only, this doesn't happen as the caps have far less Q. If you remove the 'on-bga' bypassing, C3, you'll see this effect get even worse. I hope this crude model has given you some insight into why I choose to eschew the power plane bypassing idea in the middle of the board, and use ground planes near the surface instead. 1) From experiment 2 we can have less ground bounce by using a ground plane very close to the FPGA. The ground is connected to all the FPGA supplies, not just the Vcco we are simulating here, so is most important. Any ground bounce affects the whole device, core, DCMs, PLLs, everything. Any rises in Vcco overshoot from losing the power plane can be mitigated with more bypass caps as shown in experiment 3. 2) The manufacturers put bypassing on the device for a reason, as we see from experiment 4, and this is highly effective. 3) Power plane bypassing systems can give rise to nasty unexpected resonances unless they are designed very carefully as shown in experiment 5. Using crappy Q bypass capacitors instead precludes this from ever being a problem. I'd appreciate your critique. Thanks, Syms. Model planes.asc :- Version 4 SHEET 1 880 680 WIRE -144 -224 -192 -224 WIRE -16 -224 -64 -224 WIRE 128 -224 -16 -224 WIRE 272 -224 128 -224 WIRE 336 -224 272 -224 WIRE 336 -192 336 -224 WIRE -16 -128 -16 -224 WIRE 336 -96 336 -112 WIRE 528 -96 336 -96 WIRE 560 -96 528 -96 WIRE 336 -80 336 -96 WIRE 336 -80 224 -80 WIRE 336 -64 336 -80 WIRE 224 -48 224 -80 WIRE -16 16 -16 -48 WIRE 128 48 128 -224 WIRE 224 48 224 32 WIRE 336 48 336 16 WIRE -192 80 -192 -224 WIRE 336 128 336 112 WIRE 528 128 336 128 WIRE 560 128 528 128 WIRE 224 144 224 128 WIRE 336 144 336 128 WIRE -16 176 -16 96 WIRE 224 256 224 208 WIRE 336 256 336 224 WIRE 336 256 224 256 WIRE 336 288 336 256 WIRE 528 288 336 288 WIRE 560 288 528 288 WIRE 336 320 336 288 WIRE -192 432 -192 160 WIRE -16 432 -16 240 WIRE -16 432 -192 432 WIRE 128 432 128 112 WIRE 128 432 -16 432 WIRE 256 432 128 432 WIRE 336 432 336 400 WIRE 336 432 256 432 WIRE 256 464 256 432 FLAG 256 464 0 FLAG 528 -96 FPGA_PWR FLAG 528 288 FPGA_GND FLAG 528 128 Vout FLAG 272 -224 PCB_PWR SYMBOL ind 320 -208 R0 SYMATTR InstName L1 SYMATTR Value 1n SYMBOL ind 320 304 R0 SYMATTR InstName L2 SYMATTR Value 1n SYMBOL voltage -192 64 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value 3.3 SYMBOL voltage 336 128 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V2 SYMATTR Value PULSE(0 3.3 0 0.5n 0.5n 9.5n 20n) SYMBOL cap 320 48 R0 SYMATTR InstName C1 SYMATTR Value 10p SYMBOL res 320 -80 R0 SYMATTR InstName R1 SYMATTR Value 20 SYMBOL ind -48 -240 R90 WINDOW 0 5 56 VBottom 0 WINDOW 3 32 56 VTop 0 SYMATTR InstName L3 SYMATTR Value 10µ SYMBOL cap -32 176 R0 SYMATTR InstName C2 SYMATTR Value 1µ SYMBOL res -32 0 R0 SYMATTR InstName R2 SYMATTR Value 0.25 SYMBOL cap 208 144 R0 SYMATTR InstName C3 SYMATTR Value 10n SYMBOL ind 208 -64 R0 SYMATTR InstName L5 SYMATTR Value 0.7n SYMBOL cap 112 48 R0 SYMATTR InstName C4 SYMATTR Value 1n SYMBOL ind -32 -144 R0 SYMATTR InstName L4 SYMATTR Value 0.7n SYMBOL res 208 32 R0 SYMATTR InstName R3 SYMATTR Value 0.25 TEXT -312 -72 Left 0 !.tran 50nArticle: 145429
Hi, i have implemented a BMD design using xapp1052. it is running successfully on a 32 bit machine. but when i run it on a 64 bit machine i am facing a problem the problem is that when i set the register DCSR0 bit 1 and try to read it a blue screen appears with the message "HARDWARE FAILURE" . but on the 32 bit machine this is functioning properly. Please help me if anyone has any idea regarding this issue. Thanks Regards, Usama Bin AslamArticle: 145430
<big snip> > >3) Power plane bypassing systems can give rise to nasty unexpected >resonances unless they are designed very carefully as shown in >experiment 5. Using crappy Q bypass capacitors instead precludes this >from ever being a problem. > >I'd appreciate your critique. > >Thanks, Syms. > <snip> So, are X7R 'crappy' enough Q, or would Y5U be worse/better? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145431
On 2/9/2010 1:26 PM, RCIngham wrote: > <big snip> > >> >> 3) Power plane bypassing systems can give rise to nasty unexpected >> resonances unless they are designed very carefully as shown in >> experiment 5. Using crappy Q bypass capacitors instead precludes this >>from ever being a problem. >> >> I'd appreciate your critique. >> >> Thanks, Syms. >> > > <snip> > > So, are X7R 'crappy' enough Q, or would Y5U be worse/better? > > > --------------------------------------- > Posted through http://www.FPGARelated.com Hi, Off the top of my head, I wouldn't know. Perhaps have a look with this tool that I referenced, Murata's S-parameter and impedance library. http://www.murata.com/products/design_support/mcsil/index.html Off the top of my head I don't think Y5U have any worse Q than other ceramics. They do have terrible temperature issues though. They also lose capacitance all you put more DC voltage onto them. Please report back! Thanks, Symon.Article: 145432
Eric Chomko wrote: > Has anyone created a copy machine of an old system using an FPGA? I Yes, pdp8 :-) But no front panel yet. Just a CPU with BRAM memory and teletype. Passed the CPU maindecs. -- --- http://pdp8.hachti.deArticle: 145433
Hi Brian, thanks for a lot of useful pointers! See my responses below. Brian Davis wrote: > FWIW another of my favorite Impact 10.1 settings is > Edit->Preferences->Configuration Preferences-> > Startup Clock->Automatic Correction I think that's the default in ISE11 now, as it should be. > If your normal method of configuration works fine, I wouldn't > worry too much about curable JTAG issues like that. The thing is that I'm using configuration via SPI flash on this board. I was planning to use indirect SPI programming for initial flashing, but it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then just quits with "Programming failed", without giving any more detail. I suspect this is because the loading of the JTAG->SPI-core fails because of the issue I'm having on this board. If the bitfile shipped with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work on this board. Fortunately, I have a dedicated SPI programming connector on the board as well, so I can use that for flashing. Loading the FPGA through SPI works fine. > I've seen that same sort of problem on a multi-chip V5 > DONE cascade with Impact 10.1: > http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c Only one V5 on this board. > ------------- > > Random debug thoughts: > > Configuration mode > - are the chip mode pins set to JTAG, or another boot mode? > - does changing the mode pins to JTAG affect the problem? Mode pins are set to SPI, but changing to JTAG or master serial makes no difference. > External DONE timing/levels > - what value of pullup do you have on DONE pin? Originally I had the 300 Ohms Xilinx has in their application notes, but I've tried different values up to 10k without success. > - are you using the "drive DONE" bitgen option? Nope, I'll try that tomorrow. But of course I can't change it for the JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate settings like that in an existing bitfile? Theoretically this should be possible by changing some bits and recalculating the CRC, but is this documented somewhere? > - have you tried the 'internal done pipe' bitgen option? Yes, no change. > - what does the DONE risetime look like on the board? > - what happpens if you lower the JTAG clock rate? No change. > - is your DONE LED buffered? ( I've seen some boards with > DONE LED hookups that load down the external DONE signal ) I don't have it buffered, but I have a transistor hooked up to it to light up a LED when donfiguration is done. cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).Article: 145434
I am looking for SoC benchmarks such as VOPD, FFT, MPEG4 for performance evaluation on FPGAs.Article: 145435
On Mon, 8 Feb 2010 21:04:49 -0800 (PST) Daku <dakupoto@gmail.com> wrote: > Could some Xilinx ISE guru provide some hints for my problem ? I am > trying to synthesize a simple 4K RAM block with Xilinx ISE. About > half- way through execution, I get an error message, inside a Visual > Studio dialog box, stating that xst.exe ( the Xilinx synthesis > executable) has encountered a problem and would I like to debug ? The > Xilinx ISE is running > on a XP machine. > Any hints, suggestions would be of immense help. The entire 11.x tool chain has been, in my experience, an unmitigated disaster. You might could try upgrading to the latest version, 11.4. There's a chance it'll fix your problem. Then again, there's a chance that it will create a new, unrelated problem, too. But at least if the problem is moving around you can claim you've got movement on the problem. Xilinx tells me that 12.1 will be better, come April. Now if only all _my_ customers were willing to sit around and wait for two extra months. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 145436
Rob Gaddi wrote:
> The entire 11.x tool chain has been, in my experience, an unmitigated
> disaster. You might could try upgrading to the latest version, 11.4.
> There's a chance it'll fix your problem.
I've had good luck with 10.1.
-- Mike Treseler
Article: 145437On Tue, 09 Feb 2010 09:19:20 -0800 Mike Treseler <mtreseler@gmail.com> wrote: > Rob Gaddi wrote: > > > The entire 11.x tool chain has been, in my experience, an > > unmitigated disaster. You might could try upgrading to the latest > > version, 11.4. There's a chance it'll fix your problem. > > I've had good luck with 10.1. > > -- Mike Treseler So did I, right up until I started a Spartan 6 design. Thus began my life as a tool fighter rather than a logic designer. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 145438
This is becoming a very informative discussion. I have not tried to analyze a complex power distribution system (PDS). Most of the devices I build have modest PDS needs. You didn't go into enough detail on how you picked the values you used. I do not typically use 1 uF caps as decoupling caps. I use either 100 nF or 10 nF or a combination of the two. I see you used a 10 nF cap on the IC. You list the Murata tool as the source of the capacitor parameters, but the values you use for ESR seem very high. With that tool a GRM188R71H103KA01 in the 0603 package gives a series inductance of 0.58 nH and a series resistance of 0.094 at 100 MHz. This frequency is above the self resonant frequency of about 65 MHz, but the impedance is still only 0.23 ohms, same as at about 42 MHz. You also did not include any of the parasitic effects of how the capacitors connect to their substrate. In the case of the board mounted caps, they will have vias connecting them to the power planes. In the case of the caps inside the package, they will also have mounting parasitic effects, even if there are no vias. But none of that really matters. Your circuit is a very poor representation of the real world. That is why it is so important to verify results with real world measurements. Your circuit has several problems. The first is that you only apply a single decoupling capacitor to the board! I may be an advocate of using fewer decoupling capacitors, but I think one is pushing the envelope a bit much. If you gave a reference to finding a value for the inductance of the connection between the power plane and the chip die, it must have been in an earlier post. But most importantly, I am very sure that your model for how the transients are generated is wrong. You show the current path as being from the FPGA power plane directly through the output series resistance and back to the FPGA ground. I am pretty sure that none of the traces on the board (the source of the capacitive load on the output) directly connect to the FPGA ground. You need to put that connection to the board ground, and even then through another package lead. The model of using a signal generator to provide current surges may not be so good as well. This results in currents being drawn between the two FPGA planes. Perhaps I am reading incorrectly that the Vout is an I/O pin and you are only trying to model internal switching transients. The real issue that causes ground bounce (the thing you seem to be most concerned about) is the current required to charge and discharge the board trace and component pin on the other end of that trace. This current will by necessity pass through the two inductors (L1, L2) and will create a lot of bounce that is not mitigated by the on chip capacitor(s). Even if you are looking at the internal switching noise of the IC, you need to model the *entire* PDS, not just one pin or one capacitor at a time. You also need to pick appropriate values for the various components and include all parasitic effects. If you can't do all of that, or even if you can, a simulation doesn't mean squat if it isn't complete. The only way to know if it is complete for something as complex as this is to take measurements of a real design. Rick On Feb 9, 7:18 am, Symon <symon_bre...@hotmail.com> wrote: > On 2/8/2010 5:14 AM, rickman wrote: > > > On Feb 6, 7:37 pm, Symon<symon_bre...@hotmail.com> wrote: > >> On 2/6/2010 5:38 PM, rickman wrote: > > >>> I keep asking you if you have done any real analysis or measurements > >>> of what you are stating? > > >> Well, this was the first time you asked IIRC, but thank you for doing > >> so. The answer is "For sure". I've used Hyperlynx and Spice on my > >> boards. I guess you have also, or else you would not be able to post > >> your opinions without worrying you might giving someone a bum steer. > > > So are you going to share the results of these simulations on the vias > > you are talking about? > > Sure Rick, let's go through it together with some cheap tools (free!) > from t'internet. OK, you can get a nice copy of Spice from here. maybe > you already have it. > > http://www.linear.com/designtools/software/ > > At the bottom of this post you will find a model of a PCB with a power > plane bypass. I've used lumped components to model it. If you > cut'n'paste the text into an editor and save it as 'planes.asc' or > somesuch, you should be able to load it into the simulator you downloaded= . > > So, if you look at the model, here's what each bit does. > > V1 DC power supply. > L3 Big inductor to represent the PDS supply impedance. > C2, R2, L4 model a 0402 1uF bypass capacitor. L4 includes the vias. > C4 Models the power plane bypass. No parasitics on this baby! > L1 Models the power via and ball from the plane to the FPGA die. > C3, R3, L5 model the bypass capacitor on the FPGA BGA package. > R1, C1, V2 model a IOB switching with 500ps rise time. Rout=3D20,Cpin=3D1= 0p > L2 Models the ground via from the PCB plane to the FPGA die. > > BTW, you can find models of bypass capacitors here:-http://www.murata.com= /products/design_support/mcsil/index.html > > Signals are:- > > PCB_PWR is the power on the PCB > FPGA_PWR is the power on the BGA package. > FPGA_GND is the ground on the BGA package. > Vout is used to show when the switching happens. > > (1) If you press the little 'running man' button, a simulation window > will appear. You can now click on nets in the schematic. I clicked on > FPGA_PWR, FPGA_GND, Vout and PCB_PWR. I also clicked on Windows -> tile > vertically to give a nicer picture. Whatever, let's call this experiment = 1. > > OK, we see the power on the BGA is quite well behaved as expected. 60mv > of overshoot and ground bounce. > > (2) So, what happens if we remove the bypass made from the power plane > being next to the ground plane, and instead use a ground plane near the > surface? If you make the schematic the active window by clicking in it, > then click the scissors symbol, then click on C4, that's got rid of the > power bypassing. If we right click on L2 and change it to 0.5n, (N.B. > don't forget the 'n'!) that's the same as moving the ground plane near > to the surface, as the via inductance is reduced by this much. Call this > experiment 2. > > Here we see a little difference. The power overshoot is now a bit > bigger, maybe 110mV. The ground bounce is less, about 30mV. > > (3) If we add another bypass capacitor, using the copy feature (next to > the scissors!) to copy L4, R2 and C2, we can do experiment 3. > > Here we see smaller overshoot, maybe 100mV, showing that if a few bypass > capacitors are added we would get back the performance of a 'plane built > capacitor'. > > (4) Let's go back to the original design. If you press F9 enough times > you'll undo any changes. Try deleting the 'on BGA' bypass capacitor C3. > experiment 4. > > You will now see much bigger overshoots and ground bounce. That's why > the FPGA manufacturers put bypassing on the BGA. > > (5) OK, back to the original design again with F9. Let's try this. Let's > say we only have a small board, a few square inches, and the plane > capacitance is only 200pF. Right click on C4 and change it to 200p. > Experiment 5. > > Here we see the potential danger of using a power plane derived > bypassing system. The high-Q power plane is resonanting with L1, the via > and ball inductance to start an oscillation. With ordinary bypass > capacitors only, this doesn't happen as the caps have far less Q. If you > remove the 'on-bga' bypassing, C3, you'll see this effect get even worse. > > I hope this crude model has given you some insight into why I choose to > eschew the power plane bypassing idea in the middle of the board, and > use ground planes near the surface instead. > > 1) From experiment 2 we can have less ground bounce by using a ground > plane very close to the FPGA. The ground is connected to all the FPGA > supplies, not just the Vcco we are simulating here, so is most > important. Any ground bounce affects the whole device, core, DCMs, PLLs, > everything. Any rises in Vcco overshoot from losing the power plane can > be mitigated with more bypass caps as shown in experiment 3. > > 2) The manufacturers put bypassing on the device for a reason, as we see > from experiment 4, and this is highly effective. > > 3) Power plane bypassing systems can give rise to nasty unexpected > resonances unless they are designed very carefully as shown in > experiment 5. Using crappy Q bypass capacitors instead precludes this > from ever being a problem. > > I'd appreciate your critique. > > Thanks, Syms. > > Model planes.asc :- > > Version 4 > SHEET 1 880 680 > WIRE -144 -224 -192 -224 > WIRE -16 -224 -64 -224 > WIRE 128 -224 -16 -224 > WIRE 272 -224 128 -224 > WIRE 336 -224 272 -224 > WIRE 336 -192 336 -224 > WIRE -16 -128 -16 -224 > WIRE 336 -96 336 -112 > WIRE 528 -96 336 -96 > WIRE 560 -96 528 -96 > WIRE 336 -80 336 -96 > WIRE 336 -80 224 -80 > WIRE 336 -64 336 -80 > WIRE 224 -48 224 -80 > WIRE -16 16 -16 -48 > WIRE 128 48 128 -224 > WIRE 224 48 224 32 > WIRE 336 48 336 16 > WIRE -192 80 -192 -224 > WIRE 336 128 336 112 > WIRE 528 128 336 128 > WIRE 560 128 528 128 > WIRE 224 144 224 128 > WIRE 336 144 336 128 > WIRE -16 176 -16 96 > WIRE 224 256 224 208 > WIRE 336 256 336 224 > WIRE 336 256 224 256 > WIRE 336 288 336 256 > WIRE 528 288 336 288 > WIRE 560 288 528 288 > WIRE 336 320 336 288 > WIRE -192 432 -192 160 > WIRE -16 432 -16 240 > WIRE -16 432 -192 432 > WIRE 128 432 128 112 > WIRE 128 432 -16 432 > WIRE 256 432 128 432 > WIRE 336 432 336 400 > WIRE 336 432 256 432 > WIRE 256 464 256 432 > FLAG 256 464 0 > FLAG 528 -96 FPGA_PWR > FLAG 528 288 FPGA_GND > FLAG 528 128 Vout > FLAG 272 -224 PCB_PWR > SYMBOL ind 320 -208 R0 > SYMATTR InstName L1 > SYMATTR Value 1n > SYMBOL ind 320 304 R0 > SYMATTR InstName L2 > SYMATTR Value 1n > SYMBOL voltage -192 64 R0 > WINDOW 123 0 0 Left 0 > WINDOW 39 0 0 Left 0 > SYMATTR InstName V1 > SYMATTR Value 3.3 > SYMBOL voltage 336 128 R0 > WINDOW 123 0 0 Left 0 > WINDOW 39 0 0 Left 0 > SYMATTR InstName V2 > SYMATTR Value PULSE(0 3.3 0 0.5n 0.5n 9.5n 20n) > SYMBOL cap 320 48 R0 > SYMATTR InstName C1 > SYMATTR Value 10p > SYMBOL res 320 -80 R0 > SYMATTR InstName R1 > SYMATTR Value 20 > SYMBOL ind -48 -240 R90 > WINDOW 0 5 56 VBottom 0 > WINDOW 3 32 56 VTop 0 > SYMATTR InstName L3 > SYMATTR Value 10=B5 > SYMBOL cap -32 176 R0 > SYMATTR InstName C2 > SYMATTR Value 1=B5 > SYMBOL res -32 0 R0 > SYMATTR InstName R2 > SYMATTR Value 0.25 > SYMBOL cap 208 144 R0 > SYMATTR InstName C3 > SYMATTR Value 10n > SYMBOL ind 208 -64 R0 > SYMATTR InstName L5 > SYMATTR Value 0.7n > SYMBOL cap 112 48 R0 > SYMATTR InstName C4 > SYMATTR Value 1n > SYMBOL ind -32 -144 R0 > SYMATTR InstName L4 > SYMATTR Value 0.7n > SYMBOL res 208 32 R0 > SYMATTR InstName R3 > SYMATTR Value 0.25 > TEXT -312 -72 Left 0 !.tran 50nArticle: 145439
Hello, to talk to the SPI flash on the s3e starter kit board, I have some code that invokes the BSCAN_SPARTAN3 primitive and additional sets and locates DAC_CS = AMP_CS = SF_CE0 = FPGA_INIT_B = 1 and AD_CONV =0; NET "DAC_CS" LOC = "N8" ; NET "AMP_CS" LOC = "N7" NET "AD_CONV" LOC = "P11" ; NET "SF_CE0" LOC = "D16" ; NET "FPGA_INIT_B" LOC = "T3"; That way I can talk to the SPI device after loading the bitfile via JTAG. The first SPI access however often fails. After an SPI access through that core, a press on the PROG button of the board still triggers reconfiguration, and the DONE leds still lights up after a short while, but the inital program scrolling the LCD doesn't start. It only starts after repowering the whole board. Any idea on what contention I hit and how I can solve? Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 145440
Allow me to rebut!! On 2/9/2010 5:31 PM, rickman wrote: > This is becoming a very informative discussion. I have not tried to > analyze a complex power distribution system (PDS). Most of the > devices I build have modest PDS needs. Unfortunately, if you use a FPFA with sub ns rise times, you no longer have modest PDS needs. Your preference for a tightly coupled power-ground plane bypassing system could lead to hi-frequency resonances. You might not have these problems, but it's important to do some kind of simulation or calculation to be sure. Remember, the frequency of your signals are not the issue, but the rise times are. > > You didn't go into enough detail on how you picked the values you > used. I do not typically use 1 uF caps as decoupling caps. I use > either 100 nF or 10 nF or a combination of the two. I see you used a > 10 nF cap on the IC. You list the Murata tool as the source of the > capacitor parameters, but the values you use for ESR seem very high. > With that tool a GRM188R71H103KA01 in the 0603 package gives a series > inductance of 0.58 nH and a series resistance of 0.094 at 100 MHz. > This frequency is above the self resonant frequency of about 65 MHz, > but the impedance is still only 0.23 ohms, same as at about 42 MHz. You have the model, I hereby release it to you to butcher in whatever way you choose! > > You also did not include any of the parasitic effects of how the > capacitors connect to their substrate. In the case of the board > mounted caps, they will have vias connecting them to the power > planes. In the case of the caps inside the package, they will also > have mounting parasitic effects, even if there are no vias. > I guess you missed "L4 includes the vias"? I modeled the vias by lumping them into L4. Likewise L5 includes the 'on BGA' inductance. > > But none of that really matters. Your circuit is a very poor > representation of the real world. I can't believe you would slag off my beautifully created design! > That is why it is so important to > verify results with real world measurements. Your circuit has several > problems. The first is that you only apply a single decoupling > capacitor to the board! I may be an advocate of using fewer > decoupling capacitors, but I think one is pushing the envelope a bit > much. If you gave a reference to finding a value for the inductance > of the connection between the power plane and the chip die, it must > have been in an earlier post. Right, as I said it's a crude model, but surely you see it demonstrates the point. I used one bypass cap, but I also used only one IOB, one BGA bypass cap, and one ground and power via on the device. This model is to show qualitative differences, and what general effects our design decisions have. > But most importantly, I am very sure that your model for how the > transients are generated is wrong. You show the current path as being > from the FPGA power plane directly through the output series > resistance and back to the FPGA ground. I am pretty sure that none of > the traces on the board (the source of the capacitive load on the > output) directly connect to the FPGA ground. Right back at you Rick, you are wrong! Look at the datasheet for a modern Xilinx FPGA. I'm looking at DS312, Spartan3E. Look for Cin. That 10pF is there, ON THE DIE, because of the IOB's output FETs. This Spice model is a IOB switching without any attached signal. When the output switches, a 10pF capacitor has to be charged or discharged from the FPGA's PDS through the 20ohms or so output resistance. The model is just fine. > You need to put that > connection to the board ground, and even then through another package > lead. The model of using a signal generator to provide current surges > may not be so good as well. This results in currents being drawn > between the two FPGA planes. Perhaps I am reading incorrectly that > the Vout is an I/O pin and you are only trying to model internal > switching transients. The real issue that causes ground bounce (the > thing you seem to be most concerned about) is the current required to > charge and discharge the board trace and component pin on the other > end of that trace. Not with FPGAs. The Cin is so high, the effect of the rest of the trace isn't necessary to show my point. > This current will by necessity pass through the > two inductors (L1, L2) and will create a lot of bounce that is not > mitigated by the on chip capacitor(s). > > Even if you are looking at the internal switching noise of the IC, you > need to model the *entire* PDS, not just one pin or one capacitor at a > time. You also need to pick appropriate values for the various > components and include all parasitic effects. If you can't do all of > that, or even if you can, a simulation doesn't mean squat if it isn't > complete. I must disagree here also. I think the model does give some insights into the issues that can arise. I'm not looking for accurate numbers, just qualitative comparisons between different methodologies. > The only way to know if it is complete for something as > complex as this is to take measurements of a real design. > > Rick > > People can and do simulate entire PDS systems, sometimes using expensive CAD software like HSPICE or even HFSS or ADS. Anyway, I've finished with this thread. I hope people reading it will take away that simulation is cheap and easy and can give good insights, even with a simplistic model. I hope I've scared a few people with 'power plane resonance' (google it!). I hope I've persuaded a few to route/pour their powers because you don't stand to gain much from tightly coupled planes, indeed you can have nasty problems from them, aside from the logistics of having many power supplies in a modern FPGA design. I hope I've persuaded a few to use more ground planes instead of power planes, and use their ground planes near to the surface and near their signal traces as it's harder to go wrong with this set up. Oh, and I hope that now you've downloaded the simulator, you'll get a lot of good use from it Rick. I hope you'll play around with some of the things you posted and see what effects they have. There's a mailing list for LTSpice, which is easy to find, that is useful for advice. Cheers, Syms.Article: 145441
Symon <symon_brewer@hotmail.com> wrote: (snip) > Sure Rick, let's go through it together with some cheap tools (free!) > from t'internet. OK, you can get a nice copy of Spice from here. maybe > you already have it. > http://www.linear.com/designtools/software/ > At the bottom of this post you will find a model of a PCB with a power > plane bypass. I've used lumped components to model it. If you > cut'n'paste the text into an editor and save it as 'planes.asc' or > somesuch, you should be able to load it into the simulator you downloaded. (really big snip) I think you really need a model of the radial transmission line, which I don't see (but could have missed). See the papers I mentioned in previous posts. -- glenArticle: 145442
On Feb 9, 8:36=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote: > Hi Brian, > > thanks for a lot of useful pointers! See my responses below. > > Brian Davis wrote: > > FWIW another of my favorite Impact 10.1 settings is > > =A0Edit->Preferences->Configuration Preferences-> > > =A0Startup Clock->Automatic Correction > > I think that's the default in ISE11 now, as it should be. > > > =A0If your normal method of configuration works fine, I wouldn't > > worry too much about curable JTAG issues like that. > > The thing is that I'm using configuration via SPI flash on this board. I > =A0was planning to use indirect SPI programming for initial flashing, but > it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then > just quits with "Programming failed", without giving any more detail. > > I suspect this is because the loading of the JTAG->SPI-core fails > because of the issue I'm having on this board. If the bitfile shipped > with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work > on this board. > > Fortunately, I have a dedicated SPI programming connector on the board > as well, so I can use that for flashing. Loading the FPGA through SPI > works fine. > > > =A0I've seen that same sort of problem on a multi-chip V5 > > DONE cascade with Impact 10.1: > > =A0http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a29= 1... > > Only one V5 on this board. > > > ------------- > > > Random debug thoughts: > > > Configuration mode > > =A0- are the chip mode pins set to JTAG, or another boot mode? > > =A0- does changing the mode pins to JTAG affect the problem? > > Mode pins are set to SPI, but changing to JTAG or master serial makes no > difference. > > > External DONE timing/levels > > =A0- what value of pullup do you have on DONE pin? > > Originally I had the 300 Ohms Xilinx has in their application notes, but > I've tried different values up to 10k without success. > > > =A0- are you using the "drive DONE" bitgen option? > > Nope, I'll try that tomorrow. But of course I can't change it for the > JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate > settings like that in an existing bitfile? Theoretically this should be > possible by changing some bits and recalculating the CRC, but is this > documented somewhere? > > > =A0- have you tried the 'internal done pipe' bitgen option? > > Yes, no change. > > > =A0- what does the DONE risetime look like on the board? > > =A0- what happpens if you lower the JTAG clock rate? > > No change. > > > =A0- is your DONE LED buffered? ( I've seen some boards with > > =A0 =A0DONE LED hookups that load down the external DONE signal ) > > I don't have it buffered, but I have a transistor hooked up to it to > light up a LED when donfiguration is done. > > cu, > Sean > > -- > Replace "MONTH" with the three-letter abbreviation of the current month > and the two-digit code for the current year (simple, eh?). FWIW: I spent 3 days debugging an isse (see: "XST is driving me crazy" in this usenet group) that was resolved by adding one more clock to the startup stream. In my configuration, done would go high and all of the combitorial logic would word, but none of the sequential logic would work. One more (extra) CCLK, and everythig went working. G.Article: 145443
Jecel wrote: > On Feb 8, 7:05 am, Gregory Estrade wrote: >> You can add those too : >> http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued >> http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga >> http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga >> >> Someday, I will set up a dedicated page for all these projects :) > > Great! This subject really needs a whole wiki to itself rather than > just a page at a hard to remember address. This is on my "to do" list, > but it will be a while before I get to it. > > -- Jecel "I have discovered a truly wonderful proof of this, but the margin is too narrow to hold it." -- Pierre de Fermat -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145444
Charlie Gibbs wrote: > In article <1bd40ftplw.fsf@snowball.wb.pfeifferfamily.net>, > pfeiffer@cs.nmsu.edu (Joe Pfeiffer) writes: > >> Al Kossow <aek@bitsavers.org> writes: >> >>> Reviving early computing dinosaurs from the surviving DNA is >>> difficult. >> That's a line that deserves to be put above the entrance to a >> computer museum. > > "It's a Unix system! I know this!" -- Jurassic Park > http://www.youtube.com/watch?v=dFUlAQZB9Ng -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145445
In article <hksqmd$arq$1@news.eternal-september.org>, Charles Richmond <frizzle@tx.rr.com> wrote: > Jecel wrote: > > On Feb 8, 7:05 am, Gregory Estrade wrote: > >> You can add those too : > >> http://torlus.com/index.php?2007/12/05/208-oric-in-a-fpga-continued > >> http://torlus.com/index.php?2007/03/19/200-thomson-mo5-in-a-fpga > >> http://torlus.com/index.php?2007/01/31/198-hector-hrx-in-a-fpga > >> > >> Someday, I will set up a dedicated page for all these projects :) > > > > Great! This subject really needs a whole wiki to itself rather than > > just a page at a hard to remember address. This is on my "to do" list, > > but it will be a while before I get to it. > > > > -- Jecel > > "I have discovered a truly wonderful proof of this, but the margin > is too narrow to hold it." -- Pierre de Fermat If only someone had provided him with some butter. -- A computer without Microsoft is like a chocolate cake without mustard.Article: 145446
Hi,
I'm implementing this project where I've to generate higher output clk
frequencies using DCM module. I have used a counter for delay generator,
for propagation delays(Pls suggest if there is any other method). I have
also instantiated the DCM module with an input freq of 50MHz and an output
frequency of 320 MHz. I dont know how to write the test bench for this(or
how to connect the DCM logic to the propagation delays to get higher output
clock frequencies). I'm new to this technology and would highly appreciate
if anyone could help me with this.
the instantiation template is:
dcm1 instance_name (
.CLKIN_IN(CLKIN_IN),
.RST_IN(RST_IN),
.CLKFX_OUT(CLKFX_OUT),
.CLKIN_IBUFG_OUT(CLKIN_IBUFG_OUT),
.CLK0_OUT(CLK0_OUT),
.LOCKED_OUT(LOCKED_OUT)
);
and the counter logic is:
module Counter(Clock, Direction, Count_Out);
input Clock;
input Direction;
output [3:0] Count_Out;
reg [3:0] count_int = 0;
always @(posedge Clock)
if (Direction)
count_int <= count_int + 1;
else
count_int <= count_int - 1;
assign Count_Out = count_int;
endmodule
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 145447Sean Durkin wrote: > >> External DONE timing/levels >> - what value of pullup do you have on DONE pin? > > Originally I had the 300 Ohms Xilinx has in their application notes, > but I've tried different values up to 10k without success. > Values lower than 300 ( down to maybe(?) 100 ohms ) would help if DONE is rising too slow, although 330 should be fine with just one FPGA. What do you measure on the actual board for risetime and high/low voltage levels on the DONE pin ? > >> - is your DONE LED buffered? ( I've seen some boards with >> DONE LED hookups that load down the external DONE signal ) > > I don't have it buffered, but I have a transistor hooked up to > it to light up a LED when donfiguration is done. > Transistors normally fall within my definition of 'buffer' :) Unless a hypothetical assembly house stuffed, say, a 1.2 ohm (1R2) where a one Kohm (102) NPN base resistor was supposed to go, lighting the DONE LED just fine but clamping the DONE voltage seen at the FPGA pin to one VBE drop such that the FPGA thinks DONE never went high. > > The thing is that I'm using configuration via SPI flash on > this board. I was planning to use indirect SPI programming > for initial flashing, but it doesn't work. iMPACT downloads > the JTAG->SPI-core-bitfile and then just quits with > "Programming failed", without giving any more detail. > IIRC I'd get a 'Programming Failed' error box after the 'downloading core' stage was reported in the 10.1 log window, if DONE didn't go high on the board. Not sure it'll help any, but here's another post of SPI related stuff from previous application note trawls: http://groups.google.com/group/comp.arch.fpga/msg/797303edfd4e7cac > > I suspect this is because the loading of the JTAG->SPI-core > fails because of the issue I'm having on this board. If the > bitfile shipped with iMPACT wasn't created with the DONE_cyle:6 > setting, it won't work on this board. > <snip> > > But of course I can't change it for the JTAG->SPI bitfile > shipped with iMPACT. > It is a major nuisance that Xilinx doesn't provide the JTAG-SPI core for iMPACT in either source or black-box synthesizable form. This forces customers to reinvent the indirect SPI FLASH wheel. If you ever need to do this, I'd suggest starting with either the Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI flash eval board example, which demonstrates the V5 logic needed to do user access to the internal configuration logic. Also of note, command line 10.1 PROMGEN has an undocumented-in- the-manuals " -spi " option that will let you generate an .mcs file for SPI proms with the proper bit order. This is quite helpful, for instance, when iMPACT 10.1 crashes and burns each time you try to define a multiboot, multi-FPGA daisy chain SPI PROM from within the iMPACT GUI. BrianArticle: 145448
Hello! Sorry to spam, but this is for a very limited audience. I just placed my crazy expensive Stratix FPGA development board on E-Bay for cheap if anyone is interested. Ebay Item: 200437929577 http://cgi.ebay.com/Stratix-FPGA-PCI-X-or-PCI-Development-Board_W0QQitemZ200437929577QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2eab081669 Thanks! -- AlexArticle: 145449
On Feb 9, 2:10=A0pm, Symon <symon_bre...@hotmail.com> wrote: > Allow me to rebut!! > > On 2/9/2010 5:31 PM, rickman wrote: > > > This is becoming a very informative discussion. =A0I have not tried to > > analyze a complex power distribution system (PDS). =A0Most of the > > devices I build have modest PDS needs. > > Unfortunately, if you use a FPFA with sub ns rise times, you no longer > have modest PDS needs. Your preference for a tightly coupled > power-ground plane bypassing system could lead to hi-frequency > resonances. You might not have these problems, but it's important to do > some kind of simulation or calculation to be sure. Remember, the > frequency of your signals are not the issue, but the rise times are. Yes, I said I have not analyzed a complex PDS myself. But I have seen it done by Lee Ritchey with very informative results. Those results are the basis of what I have been saying here. ...snip... > > You also did not include any of the parasitic effects of how the > > capacitors connect to their substrate. =A0In the case of the board > > mounted caps, they will have vias connecting them to the power > > planes. =A0In the case of the caps inside the package, they will also > > have mounting parasitic effects, even if there are no vias. > > =A0> > I guess you missed "L4 includes the vias"? I modeled the vias by lumping > them into L4. Likewise L5 includes the 'on BGA' inductance. Yes, I missed that. I would like to know where you got your info. Now that you have me interested in this, I would like to understand what you have done. > > But none of that really matters. =A0Your circuit is a very poor > > representation of the real world. > > I can't believe you would slag off my beautifully created design! Lol! > > That is why it is so important to > > verify results with real world measurements. =A0Your circuit has severa= l > > problems. =A0The first is that you only apply a single decoupling > > capacitor to the board! =A0I may be an advocate of using fewer > > decoupling capacitors, but I think one is pushing the envelope a bit > > much. =A0If you gave a reference to finding a value for the inductance > > of the connection between the power plane and the chip die, it must > > have been in an earlier post. > > Right, as I said it's a crude model, but surely you see it demonstrates > the point. I used one bypass cap, but I also used only one IOB, one BGA > bypass cap, and one ground and power via on the device. This model is to > show qualitative differences, and what general effects our design > decisions have. Qualitative is not very useful. Everything has some effect on everything. What is important is how *much* of an effect. There will always be some ground and power noise. It is only a problem when it becomes significant in comparison to the noise margins. Is that not true? By only using one of each item in the design an unrealistic representation of the circuit you are trying to propose. Clearly there are a lot more than 1 board cap and via for each cap on the IC. If I said the caps on the chip will have *no* effect, I did not mean that. I intended to say that they would have no significant effect in the region of interest. Also, without understanding how you came up with the values used in your simulation, I have no way to trust it. > > But most importantly, I am very sure that your model for how the > > transients are generated is wrong. =A0You show the current path as bein= g > > from the FPGA power plane directly through the output series > > resistance and back to the FPGA ground. =A0I am pretty sure that none o= f > > the traces on the board (the source of the capacitive load on the > > output) directly connect to the FPGA ground. > > Right back at you Rick, you are wrong! Look at the datasheet for a > modern Xilinx FPGA. I'm looking at DS312, Spartan3E. Look for Cin. That > 10pF is there, ON THE DIE, because of the IOB's output FETs. This Spice > model is a IOB switching without any attached signal. When the output > switches, a 10pF capacitor has to be charged or discharged from the > FPGA's PDS through the 20ohms or so output resistance. The model is just > fine. Why do you say it is "on the die"? The value of Cin is largely from the pin itself from what I have learned. Perhaps I am wrong, but it makes sense to me that the pin has more capacitance than the transistor on the die, but I may not be right on that. How can you tell this capacitance is of the transistor and not the pin? > > =A0You need to put that > > connection to the board ground, and even then through another package > > lead. =A0The model of using a signal generator to provide current surge= s > > may not be so good as well. =A0This results in currents being drawn > > between the two FPGA planes. =A0Perhaps I am reading incorrectly that > > the Vout is an I/O pin and you are only trying to model internal > > switching transients. =A0The real issue that causes ground bounce (the > > thing you seem to be most concerned about) is the current required to > > charge and discharge the board trace and component pin on the other > > end of that trace. > > Not with FPGAs. The Cin is so high, the effect of the rest of the trace > isn't necessary to show my point. I'm not at all clear on that. The capacitance of the trace is very significant. If you said the trace and other IC pins shouldn't be modeled as a lumped capacitance, I would agree that might be significant, but to say it is not important at all is not obvious without something to support that. > > =A0This current will by necessity pass through the > > two inductors (L1, L2) and will create a lot of bounce that is not > > mitigated by the on chip capacitor(s). > > > Even if you are looking at the internal switching noise of the IC, you > > need to model the *entire* PDS, not just one pin or one capacitor at a > > time. =A0You also need to pick appropriate values for the various > > components and include all parasitic effects. =A0If you can't do all of > > that, or even if you can, a simulation doesn't mean squat if it isn't > > complete. > > I must disagree here also. I think the model does give some insights > into the issues that can arise. I'm not looking for accurate numbers, > just qualitative comparisons between different methodologies. Ok, then I agree that there will be some effect from the on chip caps. But I don't agree that they are useful in reducing ground bounce from I/O switching. > > The only way to know if it is complete for something as > > complex as this is to take measurements of a real design. > > > Rick > > People can and do simulate entire PDS systems, sometimes using expensive > CAD software like HSPICE or even HFSS =A0or ADS. > > Anyway, I've finished with this thread. I hope people reading it will > take away that simulation is cheap and easy and can give good insights, > even with a simplistic model. I hope I've scared a few people with > 'power plane resonance' (google it!). I hope I've persuaded a few to > route/pour their powers because you don't stand to gain much from > tightly coupled planes, indeed you can have nasty problems from them, > aside from the logistics of having many power supplies in a modern FPGA > design. I hope I've persuaded a few to use more ground planes instead of > power planes, and use their ground planes near to the surface and near > their signal traces as it's harder to go wrong with this set up. Oh, and > I hope that now you've downloaded the simulator, you'll get a lot of > good use from it Rick. I hope you'll play around with some of the things > you posted and see what effects they have. There's a mailing list for > LTSpice, which is easy to find, that is useful for advice. > > Cheers, Syms. Yes, I have used this simulator before. But a simulation is only as useful as the circuit being simulated. If you try to simulate a complex PDS without verifying it with measurement, you have no idea if your simulation is correct. I believe the "mailing list" is actually a Yahoo group which is a *great* place to get excellent support. I forget the name of the LT person, but he answers every question he can with patience and never chids no matter how many times that same question has been answered. It would appear that responding to that group is his full time job at LT! I will say that the Ritchey course is full of examples of designers who follow rules of thumb without knowing why or that use an incorrect analysis without ever verifying it with the real world. There are even examples of companies that went out of business because of designers who did not completely understand why their circuits did not work correctly. Maybe I will perform this simulation the way I think it should be done. Then we will see if closely coupled power planes are pointless or not... Rick
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