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
One suggestion ( for cases of blind desperation ) is to cool the FPGA ( and perhaps also the RAM) down , well below freezing. This makes the chips much faster, and might make the error occur more often, and thus more easy to analyze. Higher Vcc has the same effect. A very fast 'scope ( and scope probe ) might also show potential clock ringing, reflections, Vcc dips etc. "A 1 MHz clock does not a slow chip make" :-( Peter Alfke, Xilinx Applications ====================================== david garnett wrote: > The BurchED Spartan board is only two layer, and has what seems to me is a > fairly poor power/ground layout - I would be much happier to see a real > ground 'plane' at least under the chip. Perhaps your problems are related - > things happen really fast inside something like a Spartan II and if your > decoupling is not perfect ... > Dave > > [ In other respects I think that the board is useful and very good value for > money - but if I were laying it out I'd have a solid ground under the chip > proper, with all chip grounds connected directly to it, and then place > decoupling caps round the edge of the chip on the underside, preferably > connecting to a VCC power 'plane' directly under the ground 'plane', giving > very short decoupling track lengths.] > > Dave > > "Steven Derrien" <sderrien@irisa.fr> wrote in message > news:3B697EF9.E5BDF155@irisa.fr... > > Hi, > > > > We are curently trying to port the XR16/Xsoc project (www.fpgacpu.org) > > to a VHDL targeted to the BurchEd Spartan II board > > (http://www.burched.com) > > > > We plan to make our work freely available, but are currently stuck on > > a problem. The design is a 16 CPU-SOC which interfaced to a parallel > > port. > > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > > > Thanks, > > > > StevenArticle: 33701
david garnett wrote: > > The BurchED Spartan board is only two layer, That's good to know. If it were me, I'd do at least four layers - top and bottom for signal, middle two for VCC and GND. -andyArticle: 33702
Steven Derrien wrote: > We have somes on-chip blockrams which serves as ROM, and off-chip > asynchronous > SRAM whiwh serves as main memory. Our problem is that we get frequent > errors when accessing the off-chip SRAM banks. Generally a single bit > wrong in a 16 bit data word every 200-300 access. > > All simulation (RTL,gate-level,post place and route) went fine. > Right now, our system is clocked at 1Mhz far below its maximum > frequency. > Besides, the SRAM Write Enable command output signal is registered > (although not in a IOB register) to avoid glitches which could cause > wrong write operations. > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > config) > > We have been beating our heads on this problem for almost a week now, > are there any experts around there to offer some tips/ideas/advices ? In addition to registering the write enable, I'd register the SRAM data and address busses, too. Many years ago, as a "green" engineer, I was bitten by an extremely weird problem similar to yours: I was writing to a Xicor NovRAM from an 8051 via an Altera EPLD. The EPLD (among other things) had a mux that drove the RAM address lines (one source was the 8051, the other was "something else"). Initially, I did not register the address outputs, and the thing would not work -- corrupted data. Looking at it on a logic analyzer, and a fast digitizing 'scope, showed me that I was meeting setup requirements by a WEEK (well, you know what I mean). After about a week of flattening my forehead against various hard structural objects, I asked another engineer what I was doing wrong. The first question he asked: "Are your outputs synchronous?" The answer, of course, was no. He said, "Register the address outputs." I did so, and everything was hunky AND dory. I would also use the IOB registers. You'll get "highly-similar" clock-to-out times for all of your signals. Why aren't you putting the write enable register in an IOB? They're free, ya know. The other obvious thing is to make sure that you're meeting setup and hold requirements around the SRAM write enable. Check your simulation model. -andyArticle: 33703
Martin Schoeberl wrote:
>
> > Interesting. I thought LPM was just an altera thing for AHDL. Are
> > all device and tools vendors supporting LPM libraries?
> >
> > I guess its ok to use LPM functions in brand-neutral code then?
>
> I also thought that's good news. But I tried today to use LPMs
> in Xilinx WebPack but it's not supported:
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=
> 1&getPagePath=5163
>
> So again two versions for A and X.
That depends.
A vendor-independent design flow requires a
vendor-independent synthesis tool.
Software vendors make money by fitting generic
code into as many devices as they can.
Device vendors make money by keeping customers
using their devices.
Xilinx WebPack is fine for certain Xilinx
devices, but it's unreasonable to expect much
support for device independence from that tool.
If all the vendors provided full
support for a standard like LPM, the designer's
lives would be simpler, and FPGAs would become
even more of a commodity
--Mike Treseler
Article: 33704"Sune G. Krohn" wrote: > > I can't get a signal out of Xilinx Virtex-II 2V100 and 2V40 with a correct > duty cycle. > > I only see this problem in 1.5 and 2.5 voltages mode. > > I also see the problem on Xilinx Virtex-II Evaluation Kit with a 2V40. > > As output I use OBUF_LVCMOS15_F_16 for 1.5 V and OBUF_LVCMOS33_F_16. > > With a frequency about 100MHz is the duty cycle about 35/65. In the test I > run the clock through a FF to make a 50/50 duty cycle and with no luck. > > It is always the high pulse that a shorter than the low, even if I invert > the signal. > > We have asked Xilinx's Technical Support Office United Kingdom every day for > two weeks and they can't answer the question they just ask irrelevant > questions. For instance, they ask my to do an IBIS simulation on their > Evaluation Kit with their chip. What's the signal's load? That's why they want you to do an IBIS sim... -andyArticle: 33705
Manoj K Krishnan wrote: > > Iam trying to build a ROM and RAM module using Xilinx Foundation > series 3.1i (VHDL coding) I tried using Core Generator to generate a > Distributed Memory block. But unfortunately the memory was not properly > generated. It works sometimes but fails sometimes. I tried calling Xilinx > custommer support. I came to know that they have some problem with the > core generator software. > > Can anyone suggest me a way to build a ROM and RAM using VHDL coding. Iam > not very particular about using core generator. All I need is to build a > ROM and a RAM which is generic in nature. Get a Real synthesis tool (Synplify or Leonardo) and infer the RAMs. The Core Generator simulation models are broken. -andyArticle: 33706
emanuel stiebler wrote: > > Hi, > > Anybody here uses an ATMEL serial EEPROm as a configuration > PROM for a SPARTAN XC40 device ? > > Which one ? > Problems ? > Hints ? I used one: the 1 Mb part. Works fine. I'm not sure if they're any cheaper than the Brand X parts. MAKE SURE YOU DO NOT ORDER THE "A" PART! (And don't let your purchasing department helpfully substitute it, either). In this case,"A" == "Altera," not "better/faster." As Felix says, watch out for reset/OE polarity, since by default it's the "wrong way" for the Xilinx FPGAs. -andyArticle: 33707
atif wrote: > > Hi ppl, > > I am trying to build a parallel port to PC card interface for a > student project. I have a few problems and I will appreciate any help > about them. > > 1) When reading data from the memory card, I have to make the OE > (output enable) signal low a setup time after I make the read address > valid. How can I get this delay using HDL code? I don't have a clock > that I can use for this purpose. You're hosed. Go back to your schoolbooks and read up on "Synchronous design." You'll want a clock. Trust me. > 2) Some of the pins connected with the PC card control signals have to > be open drain with pullup resistor (>10 k). I am not sure how get that > in a Xilinx 4000 series FPGA. The data sheet says I can get an open > drain output by using a tri state ouput buffer(OBUFT), with its input > connected to ground and enable pin to the output signal. Seems to me > that in this case, I will have to use external pull up resistors (not > really interested in doing this). Or can I connect PULLUP at the > output of the buffer? Can I use the BUFOD (open drain buffer) with a > PULLUP as output buffer? Any other ways of doing this? Use the OBUFT as they describe, and use external resistors. The PULLUP isn't strong enough. Resistors are cheap. Many large FPGA designs have to have external passives. That's the way it is. > 3) For Global Set/Reset, the manuals say I have to use the INIT > attribute to specify the locat set/reset state of each ff. Where do I > set this INIT attribute....in the schematic or in the code? How? for > example, following is the general structure of my code > process(clk, reset) > begin > if reset='1' then > x<='0'; > y<='1'; > elsif rising_edge(clk) then > -- stuff > end if; > end process; > What do I have to do so that x and y are reset and set > respectively(using GSR). > Note that the 4000E series that I am using does not seem to have a > STARTBUF module. In has a STARTUP module, which has GSR input, but no > GSR output (as in STARTBUF). Thus using this module will set/reset the > flip flops according to the INIT attribute. I'm not sure which version of Xilinx' tools you're using, but if you code each and every flip-flop in your design with the same exact reset signal, you don't have to do anything to init the flops. GSR will be inferred by the synthesis tool, and your registers will be set or cleared as indicated by your "if reset = '1' then ..." statement. So, don't worry about INIT, don't worry about STARTUP, just make sure you reset all of your flops. Yes, it would be nice if Xilinx updated their docs once in a while. -andyArticle: 33708
"Andy Peters > > Steven Derrien wrote: > > > We have somes on-chip blockrams which serves as ROM, and off-chip > > asynchronous > > SRAM whiwh serves as main memory. Our problem is that we get frequent > > errors when accessing the off-chip SRAM banks. Generally a single bit > > wrong in a 16 bit data word every 200-300 access. > > > > All simulation (RTL,gate-level,post place and route) went fine. > > Right now, our system is clocked at 1Mhz far below its maximum > > frequency. > > Besides, the SRAM Write Enable command output signal is registered > > (although not in a IOB register) to avoid glitches which could cause > > wrong write operations. > > > > All IOB are configured with SLOW slew-rate and drive 12mA (default IOB > > config) > > > > We have been beating our heads on this problem for almost a week now, > > are there any experts around there to offer some tips/ideas/advices ? > > In addition to registering the write enable, I'd register the SRAM data > and address busses, too. Many years ago, as a "green" engineer, I was > bitten by an extremely weird problem similar to yours: I was writing to > a Xicor NovRAM from an 8051 via an Altera EPLD. The EPLD (among other > things) had a mux that drove the RAM address lines (one source was the > 8051, the other was "something else"). Initially, I did not register > the address outputs, and the thing would not work -- corrupted data. > Looking at it on a logic analyzer, and a fast digitizing 'scope, showed > me that I was meeting setup requirements by a WEEK (well, you know what > I mean). After about a week of flattening my forehead against various > hard structural objects, I asked another engineer what I was doing > wrong. The first question he asked: "Are your outputs synchronous?" > The answer, of course, was no. He said, "Register the address outputs." > I did so, and everything was hunky AND dory. I'll try to do that, thanks. > I would also use the IOB registers. You'll get "highly-similar" > clock-to-out times for all of your signals. > > Why aren't you putting the write enable register in an IOB? They're > free, ya know. yep, this is just because the register is in a inner edif module and apparently the map -b does not manage to put it it in the IOB, but that's to check again. > > The other obvious thing is to make sure that you're meeting setup and > hold requirements around the SRAM write enable. Check your simulation model. Setup and hold should be OK (WE is active for a clock cycle aka for 1000 ns) > > -andy Thanks again stevenArticle: 33709
What is the CAE library used for? I generated an EDIF file on my sun workstation from cadence and then put it through the Xilinx's design manager (alliance) on my PC but it generates errors stating some components are not expanded. Do I have to install the CAE library on the sun's machine and reference to this library when I try to generate the EDIF with cadence or synopsys? What kind of setup and environment (libraries) do I need to install to have a design flow such that I can generate an EDIF from cadence or synopsys on sun's machine and then pass the EDIF to xilinx's design manager on a PC? Your help is much appreciated!!!!Article: 33710
Steven Derrien wrote: > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) > Yes, unfortunately it is. Signal integrity problems are instigated by a signal edge, often a clock edge, and the time distance until the following edge is usually of no consequence. Therefore, signal integrity problems are as bad and devious at 1 MHz, as they are at 100 MHz. It's the inherent speed of the device that matters, not the clock rate of the application. This bites the designer of slow systems so badly, when he uses simple instruments, limited board-layout skills etc, but then inserts these very fast modern chips that can react to a 1-ns blip. A 250-MHz scope does not even show this blip... Peter Alfke, Xilinx ApplicationsArticle: 33711
Yep, that's what I do. For high clock rates, you may find that you need to locate the registers at the point of crossing in the same CLB (opposite slices), as you reduce the allowed prop times. Falk wrote: > Ok, I think the easiest and safest solution is a synchronizing FF working on the other (here the falling) edge. > Thanks a lot for the warning and advice. > > Regards > Falk -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33712
Yes. The problem is in the di/dt caused by very fast edges on the signals. You can help it out some be selecting the low slew rate drive and setting the output currents at the lowest possible values consistent with what you are driving. You can also intentionally skew outputs if you have a higher clock available to minimize the number of outputs changing at once. Steven Derrien wrote: > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33713
May be it is an off topic post, but I liked to have some feedback about that. I posted it on comp.arch.arithmetic, so far I have not see much action there. Well, in any case I am intended to implement it on a FPGA. :-) ---------------------------- Hi again guys! I have N1=1/25 that can be aproximated by 41/1024 where the error is around .000039 then we do: If x is w=8 bits wide (unsigned)and its maximum accumulated error is .00996 N1approx: x*N1 ~ x(<<5 + <<3 + 1)>>10 needing only one(1) w+5(because higher hardwired SLL)+ 1 (to account the 1 for the Carry-in) bits ADDER, then we apply a the 10-SRL(harwired). NOTE that dividing x(max) by 25 will require at least 4 bits; and another 5 bits after the radix-point to account for the accuracy of 41/1024. Do anyone has a more creative way to implement that? NOW I have another similar case: N2=1/24 ~ 85/2048 I have been trying to develop a similar method but it will require more H/W, wider ADDERs and having a bigger accumulated error. Thinking again, here is were I need the creative solution. ;-)Article: 33714
"Steven Derrien" <sderrien@irisa.fr> wrote in message news:3B698F7B.73A2211A@irisa.fr... > ground 'plane' at least under the chip. Perhaps your problems are related - > > things happen really fast inside something like a Spartan II and if your > > decoupling is not perfect ... > > Is this also a strong issue when the system is clocked below 1MHz ? > (sorry I have very little knowledge of PCB layout issues) Absolutely ! - what matters is that lots of things change state on the clock edge, and for these changes to take place currents must flow - possibly quite a lot of current, although for a very short time. If the ground/vcc connections present any significant impedance, then different parts of the chip will find themselves with different ground/vcc levels during the changes, and just about anything could happen ! Depending on what you are doing in the fpga, everything will settle in a few tens of nanoseconds - so, providing your clock is slow enough to let this happen plus a bit, the clock speed will not have a great effect - except to make the fault occur more often, which is often a help in tracking it down ! My experience is that, even with a very fast scope, it is very difficult to observe ground bounce type faults directly - you certainly see all sorts of bouncing and glitches, but they are often caused by probing problems ... > > > Thank you, > Steven >Article: 33715
> Setup and hold should be OK (WE is active for a clock cycle aka for 1000 > ns) Registering the WE, Data Bus, and Address Bus is a very good idea. Also make sure that you send the Address Bus and Data Bus out to the SRAM at least one clock cycle before you assert the WE. Also, hold the Address Bus and Data Bus at least one clock cycle after clearing WE. You don't want to send the Address, Data, and WE on the same clock edge or clear them on the same clock edge. Good Luck, ShaneArticle: 33716
If you have plenty of time you can do a real "shift and subtract" divider or the approximated "shift and add" multiplier with the 1/n multiplicand using a serial shifter for an arbitrary value. If you need the value in one clock cycle you can use discreete adders. In the case of 85/2048 (55/800 hex)you can add x+4x(=5x) then add the result 5x+16*5x(=85x) to get your raw result. The last adder is larger than the 1/25 example but you need it for the accuracy. Does a true divider just not work for you because of the delay? jdiaz_pr wrote: > May be it is an off topic post, but I liked to have some feedback > about that. I posted it on comp.arch.arithmetic, so far I have not see > much action there. > > Well, in any case I am intended to implement it on a FPGA. :-) > > ---------------------------- > Hi again guys! > > I have N1=1/25 that can be aproximated by 41/1024 where the error is > around .000039 then we do: > > If x is w=8 bits wide (unsigned)and its maximum accumulated error is > .00996 > > N1approx: x*N1 ~ x(<<5 + <<3 + 1)>>10 needing only one(1) w+5(because > higher hardwired SLL)+ 1 (to account the 1 for the Carry-in) bits > ADDER, then we apply a the 10-SRL(harwired). NOTE that dividing x(max) > by 25 will require at least 4 bits; and another 5 bits after the > radix-point to account for the accuracy of 41/1024. > > Do anyone has a more creative way to implement that? > > NOW I have another similar case: N2=1/24 ~ 85/2048 > I have been trying to develop a similar method but it will require > more H/W, wider ADDERs and having a bigger accumulated error. > > Thinking again, here is were I need the creative solution. ;-)Article: 33717
"it sumulates it with no err"... The simulator simulates your design with results you anticipate but... "it doesn't give me the right value for ma[]"... the simulator or the resulting design? If it's the simulator, this is where you start "drilling down" into the design to look at the signals that go to the ma[] registers - the d input, the clock, the reset. If your simulator says your results are not as expected, start looking at the individual nodes that aren't behaving correctly and eventually you'll find the trouble. Abhimanyu Rastogi wrote: > Yes i did....and it simulates it with no err or warnings..... > but....it doesn't give me the right values for ma[] .... which should be > the same as upad[].... that i'm feeding in thru the simulator..... instead > it gives me some odd values for ma[] ... > > Could that be due to the clk.... or some delay... cuz... upad[] is an > INPUT and ma[] is a dffe variable... so does that matter?? > > Abhimanyu Rastogi > Russell Shaw <rjshaw@iprimus.com.au> wrote in message > news:3B68A427.47ED3915@iprimus.com.au... > > I can't see a problem. Have you fed it thru the maxplus2 simulator? > > > > Abhimanyu Rastogi wrote: > > > > > > Hi all, > > > I haveing some trouble with this code I wrote... > > > > -- > > ___ ___ > > / /\ / /\ > > / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ > > /__/ / Victoria, Australia, Down-Under /__/\/\/ > > \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ > > \__\/ \__\/Article: 33718
Dave Feustel wrote: > Does the Flexlm licensing and license validation procedure actually > *work* on Windows 2000? I can testify that validation works on win2k. My license server is elsewhere on the network. I assume you have set a path for LM_LICENSE_FILE or MGLS_LICENSE_FILE (Start, Settings, ControlPanel, System, Advanced, Environment . . .) --Mike TreselerArticle: 33719
Hi folks,
I'm using a DLL in a SpartanII design and have discovered with lab
experimentation that lo and behold, the /4 output lags the edge of the x1
output by about 1ns. I'm certain that I'm using the DLL correctly (BUFGs on
both outputs, feedback comes from BUFG'd x1 output) and I imagine that the
phase difference is due entirely to loading differences since the /4 clock
is *much* more heavily loaded than the x1 clock.
So, given that we're kind of stuck with this (what's the point of BUFG's
anyway if this happens?) how can I design with this? Will the Design Manager
(using 3.1) check for setup problems? Any design tricks that the gurus can
share on this matter?? Safety precautions I can add to the UCF file??
Thanks!!
Cary McCormick
Article: 33720Here is the simple rule for 5-V parts: If Voh min is specified as 2.4 V, then it is a TTL-like "totem-pole" structure with an n-channel pull-up transistor, and the real Voh will be one threshold below Vcc, i.e. around 3.7 V. To get a higher Voh, use an external pull-up resistor. If Voh min is specified as 3.5 to 4.0 V, then it really is a true CMOS output with a p-channel pull-up, and the unloaded Voh is identical with Vcc. Lower-Vcc standards ( 3.3, 2.5, 1.8, 1.5 V) have always true CMOS outputs ( unless they are open-"collector", like GTL.) PECL and differential standards like LVDS are a different matter. Peter Alfke, Xilinx Applications ==================================================== Victor Schutte wrote: > TTL compatible outputs. You might even go as high as 3.7V. Open drain should > even be worse. Try pull-up resistors (e.g. 4k7 to VCC), especially when > your pin fans out to active high inputs. Remember that the TTL high level is > about 2.4V and that it should work in most cases.Article: 33721
VeriLogger Pro is available on PC for $3000. You can download an eval copy from the location below: -- For a FREE evaluation of Timing Diagrammer, WaveFormer, VeriLogger, or TestBencher Pro, visit our web site: http://www.syncad.com ****************************************************************** SynaptiCAD, Inc. Sales: (800) 804-7073 P.O. Box 10608 Support: (540) 953-3390 Blacksburg, VA 24062-0608 Fax: (540) 953-3078 ftp: www.syncad.com email: sales@syncad.com "Dave Feustel" <dfeustel@mindspring.com> wrote in message news:9jugr9$5vr$1@slb4.atl.mindspring.net... > Modelsim licensing refuses to work on my computer. > > What alternatives to Modelsim are there for Verilog simulation > on Windows 2000? > > Thanks. > >Article: 33722
Wow. Bite my head off. I think there's some confusion on the tools. I'm sorry I didn't specify I waas speaking of Quartus. Unless you're designing MAX3000 or MAX7000, there's no reason to be using MAX+PLUS II anymore. In any case, the default behaviour "out-of-the-box" for Quartus is to have the unused pins configured as inputs (tristated). You don't need to delve into the menus if you don't want to. Is that nice enough default behaviour? I was just trying to show you how to change the default settings if you wanted to. Too much information, I guess. -Pete- <martin.j.thompson@trw.com> wrote in message news:u7kwmft3s.fsf@trw.com... > Falk <> writes: > > > So what the hell means > > > > - as output, driving an unspecified signal???? > > > > I've also seen the same behaviour that Nial describes elsewhere in > this thread... threw us off track for a *long* while. We now make a > point of explicitly defining the state of all pins, used or unused. > > > Is there any use for that?? My opinion is, that the software has to > > keep its hands of the pins, unless I tell them to do other. So unused > > pins should be tristated by default (not after you set a tiny switch > > hidden deep down in the 10th option menu :-( > > > > Not nice default behaviour IMHO! > > Cheers, > MartinArticle: 33723
I don't know DLL and BUFG count around where you're working, but how about slaving the 1x clock to the /4 ? It'll take some rethinking to get the whole system to come back and align, but if your feedbacks are what give you the edge matching, you need the heavily loaded net in the feedback path. Good luck! Cary McCormick wrote: > Hi folks, > I'm using a DLL in a SpartanII design and have discovered with lab > experimentation that lo and behold, the /4 output lags the edge of the x1 > output by about 1ns. I'm certain that I'm using the DLL correctly (BUFGs on > both outputs, feedback comes from BUFG'd x1 output) and I imagine that the > phase difference is due entirely to loading differences since the /4 clock > is *much* more heavily loaded than the x1 clock. > So, given that we're kind of stuck with this (what's the point of BUFG's > anyway if this happens?) how can I design with this? Will the Design Manager > (using 3.1) check for setup problems? Any design tricks that the gurus can > share on this matter?? Safety precautions I can add to the UCF file?? > Thanks!! > > Cary McCormickArticle: 33724
david garnett wrote: > > "Steven Derrien" <sderrien@irisa.fr> wrote in message > news:3B698F7B.73A2211A@irisa.fr... > > > ground 'plane' at least under the chip. Perhaps your problems are > related - > > > things happen really fast inside something like a Spartan II and if your > > > decoupling is not perfect ... > > > > Is this also a strong issue when the system is clocked below 1MHz ? > > (sorry I have very little knowledge of PCB layout issues) > > Absolutely ! - what matters is that lots of things change state on the clock > edge, and for these changes to take place currents must flow - possibly > quite a lot of current, although for a very short time. If the ground/vcc > connections present any significant impedance, then different parts of the > chip will find themselves with different ground/vcc levels during the > changes, and just about anything could happen ! > > Depending on what you are doing in the fpga, everything will settle in a few > tens of nanoseconds - so, providing your clock is slow enough to let this > happen plus a bit, the clock speed will not have a great effect - except to > make the fault occur more often, which is often a help in tracking it down ! > > My experience is that, even with a very fast scope, it is very difficult to > observe ground bounce type faults directly - you certainly see all sorts of > bouncing and glitches, but they are often caused by probing problems ... It would be interesting to know what the inductance is of the chip bond wires. That way, the layout person could determine how long they could leave pwr/gnd tracks without much effect relative to the bond-wires.
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