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
"Ralf Hildebrandt" <Ralf-Hildebrandt@gmx.de> wrote in message news:5g6nfuF3d3hceU1@mid.individual.net... > devices schrieb: > > > I chose the simple following example (perhaps > > too simple or too specialized). Here's a flip > > flop with an enable pin: > > > process (clk) > > begin > > if (clk'event and clk='1') then > > > > if (ce = '1') then > > q <= d; > > end if; > > > > end if; > > end process; > > For most target libraries this will result in a D-Flipflop and a > multiplexer controlled by ce. The multiplexer selected d or q as input > to the D-FF. > > > > - FIGURE B > > > > +---------------------+ > > | _ | > > | | \ +--------+ | > > +--|0 | | | | > > | |---|In Out|--+-> q > > d--|1 | | | > > | / | FF | > > - +-|> | > > | | +--------+ > > | | > > ce clk > > That is correct. > > > > 1) If Figure B holds true, does it ALWAYS > > go like this? > > Yes. Because you did not model a latch. > > A latch is a storage element. A D-latch has an enable signal and a data > input. > > process(en,data) > begin > if (en='1') then > latch<=data; > end if; > end process; > > > The process you have written first could be changed into: > > process (clk) > begin > if (clk'event and clk='1') then > q<=q_next; > end if; > end process; > > process(ce,d,q) > begin > if (ce = '1') then > q_next<=d; > else q_next<=q; > end process; > > This describes the same behavior. As you can see, there is always a > value assigned to q_next. This means: no storage needed. Thanks for your reply. In any case, avoiding the double branch is what i was looking for. I wanted to omit the "else" and safely hand data to a flip flop.Article: 122076
On Sun, 15 Jul 2007 12:08:22 +0200, "Antonio Pasini" <removethis_antonio.pasini@alice.it> wrote: >Done something similar some time ago, to save some flash space for bitsream >on a relatively small micro. > >Check this thread on this newsgroup: > >http://tinyurl.com/2xkt52 > >or search with google groups for "compressing Xilinx bitstreams, some test >data". > >There are some measures from my real design, and a link to the source code. > >Please share your results with the group! > OK, we have a company-standard rom-builder program that gobbles up S28-format uP code and Xilinx .RBT files and builds binary rom images, sort of a barbaric linker. I modified it to accept a /RLL switch, to do essentially the same thing as your code (but recoded it in PowerBasic!) It's byte oriented, and whenever I see a 0 byte, I output it and count the total number of 0's in the run, then poke that count into the next output byte. A single input 0 then becomes two bytes (0,1) and a run of 100 zeroes becomes two bytes, (0,100). Nonzero bytes just get shipped out unchanged. I added 32 extra zero bits at the end (0,4) because the chips seem to like that, and then (0,0) as the end-of-file marker, to tell the uP config code when to quit. We also added a /FILL switch to load unused image bytes with all 1's, to make eprom programming a bit faster. A relatively simple VME interface chip, an XC3S200, crunches to 0.23 of the original size, over 4:1 compression. A fairly hairy 8-channel massively pipelined DDS synthesizer in an XC3S1500, using lots of resources, compresses to 0.43. If we initialize the block rams, it's more like 0.46. We could also RLL the 0xFF bytes, but that would help only marginally. We have come up with some trickier dictionary-based algorithms, but the RLL ratios are much better then we need at present, so we'll just go with this. Runtime unpacking and config bit-banging should be fast. When we see a null byte, we can hop to a brute-force routine that reads the next byte and bangs out up to 2040 zero bits as fast as it can wigwag the CCLK port bit. It should be much faster than the old loop, which just shifted all the data bits out. Thanks, JohnArticle: 122077
I wrote: > If they're running on the same clock, you are likely to see an > obvious pattern to the bits, especially if they are the same length > LFSRs. Mark McDougall wrote: > What if their periods are all relatively prime? That will certainly help. Perhaps that will be satisfactory; I'm not really sure. Worth a try.Article: 122078
To all,
I just happened to be at Mathworks today and was reading the help files
on the Filter HDL coder. I have also been using the Xilinx Sysgen and
Simulink to try to model a filter I generated in the Xilinx Core Generator.
So far I'm not too happy with the Sysgen implementation and it's link to the
Modelsim simulator. I've had to jump through a lot of hoops just to get the
model of the filter to run and the model runs fairly slow. It also is
impossible to match what I get out of the filter in Simulink to what I get
when I simulate my VHDL/core directly from Modelsim/ISE. I can not get the
Simulink model to run at more than a 1 MHz maximum clock rate. When I run it
at that rate what occurs in a few microseconds in the VHDL simulation take
milliseconds in Simulink time and it takes a long bit of real time to run
those few milliseconds of simulation. I'm currently taking a course on
Simulink but the support for the Xilinx Blockset seems to be lacking.
Perhaps I'll be enlightened tomorrow but I'm having my doubts.
I am interested in the VHDL coder simply because it produces a VHDL
module that looks like it is fairly easy to understand and should be easy to
instantiate and simulate. None of the clock rate issues etc. that seem like
a snakepit in the Simulink/SysGen method. I'm still keeping an open mind but
as the previous poster stated everything cost big bucks via Mathsoft. The
SysGen is fairly cheap but you also need the Signal Processing and
FixedPoint Blocksets and also the equivalent toolboxes to do anything
worthwhile, at least in my case. We are about to buy more licenses of
Matlab/Simulink and Xilinx tools so I have to make up my mind soon. It takes
awhile to evaluate these things and who has that much time? I do like
working with the fixed point toolbox and blocksets because it makes it
easier to track the binary point of the data. I haven't done that much with
fixed point so maybe it just seems good because I'm a novice at it. Most of
my designs are just moving data in and out in different formats/rates etc.
I'm trying to use FPGAs to do filtering but right now most of that is done
in floating point sw on Origin supercomputers.
I'll read more on it tomorrow.
My 2 cents.
CTW
<richng01@gmail.com> wrote in message
news:1184646939.646245.256940@o11g2000prd.googlegroups.com...
> Hi all,
> Anyone know the differences between Xilinx System Generator and
> Simulink HDL Coder?
> Thanks a lot.
>
> Richie
>
Article: 122079On Wed, 18 Jul 2007 09:42:47 -0700, Lue.Her@gmail.com wrote: >Greetings, all, > >I have read through many postings about bypass/decoupling capacitors >for Xilinx FPGAs at comp.arch.fpga. It seems to me common >"solution" (there are many, I'm sure) to use at most 10 or 20 caps for >the entire FPGA, of one value of one size (i.e.: 0.1 uF or 0.33 uF >capacitor, 0603 package, perhaps). I guess I just want a quick a dirty >suggestion of what best to do (in terms of bypass caps) for this >board. It's goal is to be a small board (current size is 2 by 5 inches >or less) and only has the most basic components: two SRAM modules, an >EEPROM module, power regulation via a TPS75003, an oscillator, and a >few miscellaneous components (LEDs, etc.) with the rest of the free >pins on the Spartan 3 (PQ208 package) becoming User I/O pins. > >The goal is to be as small as possible, and the board will be used by >students (like myself) on projects as an alternative to a >microprocessor solution (though the Spartan-3 will likely be >configured with Microblaze). Also, right now I'm limiting myself to >just four layers, with the one inner layer as a GROUND plane and the >other as a VCCO plane. I doubt we'll use the board for really high- >speed projects (in the gigahertz range...), but regardless I still >have doubts as to what caps to use. > >I know there are many, many postings of similar topics as this one but >I just need confirmation that I can "get away" with using as few >bypass caps as possible. There are discussions relating to more >advanced electrical concepts that I do not fully understand, and some >real-world experience and recommendation concerning my board setup and >chip selection would be greatly appreciated. > >Thanks. >Lue Her >University of St. Thomas (St. Paul, MN) 6 layers would make life a lot easier, one ground plane and two power planes. One power plane can be 3.3 volts, and the other can be split 2.5 and 1.2, one island inside the FPGA and a big pour outside. That leaves three signal layers, and you can route signals on the 2.5/1.2 layer too, once you make the FPGA happy. Two more layers won't cost much more. We ususlly use 4 caps per supply per FPGA, 0.33 uF 0603. Never had a problem, even in systems where we measure jitter in picoseconds. Use more if it makes you feel better, but they won't change anything. For fun, lay out a board with more caps and depopulate it until something malfunctions. Write a paper. JohnArticle: 122080
Your running disparity is the most likely culprit. I believe you are encoding the D20.3 symbol with either positive or negative disparity and then using the opposite to encode the D23.3 symbol. Colin Hankins "damc4" <damc4@gmx.de> wrote in message news:1184709128.113196.283690@m37g2000prh.googlegroups.com... > Hello, > > I run into a problem/bug where I currently don't see a solution, > probably somebody can give me some hints. > > I encoded data frames with 8B/10B, filled the gaps between the data > with K28.5 characters and then transmitted the data stream via a > serial line. > On the receiver side I did the same backwards and run their into a > problem: > The serial data stream of the following bytes (0x6E, 0x74, 0x77, 0x65 > or D14.3, D20.3, D23.3, D5.3) contains a bit sequence that is > identical to the K28.5 character and therefore my receiver recognises > also this K char instead of the intended data byte. > > What is going wrong here or what kind of mechanism do I forgot to > implement? > Any ideas or help is very welcome! > > Best Regards, > > Damc >Article: 122081
On Jun 1, 1:27 am, ashes....@gmail.com wrote: > On Jun 1, 2:54 pm, ashes....@gmail.com wrote: > > > > > > > On May 22, 3:50 am, Ligeti <jlls...@gmail.com> wrote: > > > > Hello > > > I get the same problem working with Spartan 3 and Virtex II Pro, it > > > started when I was trying the ISE 9.1i Quick Start Tutorial (am new to > > > ISE in general), when it comes to pin assigning the pins, PACE gives > > > me this message: > > > "PACE was unable to parse the HDL source file 'C:\...\counter.vhd' " > > > and after that PACE shows this (whatever you call it): > > > > Loading device for application Rf_Device from file '3s200.nph' in > > > environmentC:\Xilinx91i. > > > ERROR:HDLParsers:3562 - pepExtractor.prj line 1 Expecting 'vhdl' or > > > 'verilog' keyword, found 'work'. > > > > I searched and search, and the only result was this topic ... so I > > > sent an Email to mludwig hoping that he knows by now an answer for > > > this, but he didnt answer me :-( > > > So I am trying to refresh the topic ... Thats all for the moment, > > > thank you! > > > > note: sorry for my bad English. > > > The problem is in the pepExrtractor.prj file that ISE generates before > > calling Pace. I dont know what generates this file, but in a project > > that is OK the file does not exist. If you delete it, ISE just > > regenerates it. I am sure if you can fix the generation of this file > > all problems will go away! The contents of this file looks like: > > > work C:/Repository Working Copies/Link_Peak_and_Hold/ > > top_level_schematic.vhd > > > Notice the 'work' keyword it is complaining about at the start... > > OK HERE IS THE ANSWER ... IF THERE ARE SPACES IN THE DIRECTORY NAMES > IN THE PATH THEN THIS PROBLEM AOCCURS. Make sure all directory names > right back to the root directory have no spaces ... sheesh, that took > some working out!!! Thanks for all the useful information on the > diagnostic code xilinx!!!- Hide quoted text - > > - Show quoted text - Thank you so much. I've been trying fo hours to figure this one out. WHY isn't this mentioned anywhere by Xilinx...Article: 122082
Hello Every1! I am facing one problem and would like to seek help from you people. We have designed one board where "EPF10K30ATC" FLEX10K family FPGA and serial PROM "EPC2LC20" are being used. When we started testing our board, we supplied power to board and was trying to observe whether JTAG(Byte Blaster cable) is working or not? To our surprise, power was coming to each point of board,JTAG 10 pin connector, EEPROM and even to power pins of FPGA , but still when we clicked on programmer(of Quartus II , ver 6.0) it gave the error " Can't scan device, can't access JTAG chain". Then we checked with another board, there the device was being detected.So it was assured that byteblaster cable is working properly. Can any1 here help me out regarding this. This seems to be wiered problem but still not able to solve out. Thanks and regards SRIArticle: 122083
On Jul 17, 8:51 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > "fazulu deen" <fazulu.v...@gmail.com> wrote in message > > news:1184682844.113055.232750@g37g2000prf.googlegroups.com... > > > Hai, > > > I need to know how to generate buffer descriptor file? > > > regards, > > fazal > > The question "I need to know something?" is usually accompanied by a > surprised look, often before an exam. > > Do you know what a buffer descriptor file is? > Do you know what it's used for. > I sure don't. > > A register map, on the other hand, could be called a register description > file or a port map and describes the details of the registers within a > system typically hooked up to one bus (processor bus perhaps) and describes > the controllability and observability of the design. > > 1) get a clue, 2) clue us in on your needs if they ARE needs that should be > addressed by people who work regularly with FPGAs. > > Ask a good question and you'll get actual answers. > - John_H I have to generate buffer descriptor with all its fields like transfer size,host address and destination address.my question was how to generate it?Article: 122084
Actually, I will split several ground planes for several parts of the whole
circuit. Among that, I plan to give a isolated planelet to FPGA PLL
(Cyclone II ep2c35).
Of course, I know the advantage of a integral gnd plane,but in a real
design that is not easy to achieve. In a mixed signal design, if you keep
the single gnd plane integral, that will be a disaster for the analog
circuit.
Leon('commone' :))
>"commone" <dechenxu@yahoo.com.cn> wrote in message
>news:ouqdnVr3XZ86sAPbRVn_vgA@giganews.com...
>>
>> I am designing a board. I splited the ground plane into one analog
plane
>> and one digital plane.
>>
>Why did you do that? It's almost certainly a very bad move indeed. You
>should have one ground plane. You can separate power planes in to
>mini-planes, that's fine. Connect power planes together with ferrites,
>that's fine also. However, the ground plane should stay as one plane.
>HTH., Syms.
>
>
>
Article: 122085Hello Every1! I am facing one problem and would like to seek help from you people. We have designed one board where "EPF10K30ATC" FLEX10K family FPGA and serial PROM "EPC2LC20" are being used. When we started testing our board, we supplied power to board and was trying to observe whether JTAG(Byte Blaster cable) is working or not? To our surprise, power was coming to each point of board,JTAG 10 pin connector, EEPROM and even to power pins of FPGA , but still when we clicked on programmer(of Quartus II , ver 6.0) it gave the error " Can't scan device, can't access JTAG chain". Then we checked with another board, there the device was being detected.So it was assured that byteblaster cable is working properly. Can any1 here help me out regarding this. This seems to be wiered problem but still not able to solve out. Thanks and regards SRIArticle: 122086
Hi all, i am using chipscope for checking the behavior of the internal signals, i have a problem my differential clock and data input is coming form the other board. i am just taking the differnential clock and making into single ended clock usign IBUFGDS and then taking that internal single ended clock signal for data processing. what i wnated to make sure is that clock is pure clock sicne i am recieving form the external board. so that while processing with the input data the it must be synchronous and meet all the setup and hold time volation. so i wnated to view it in chipscope. but i am unable use this clock internal signal while i am inserting for "chipscope pro inserter" for clock port and i wnated to see the datain (its also the internal signal form the differntial signal) whether it is meeting the constraints. how can i specify them in the chipscope inserter. what kind of signal i should make as trigg ports. thanks regard srikArticle: 122087
On 18 Jul., 01:23, Tommy Thorn <tommy.th...@gmail.com> wrote: > On Jul 17, 4:21 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > Hi > > > I just burnt my fingers trying to lift off the Xilinx Spartan 3A > > Starterkit > > the all corner with power supplies is extremly hot - I wonder if that > > is > > normal or not. > > > I already own 3 FPGA boards designed by Digilent with burned in Power > > supplies > > so I am little worried that I may get a 4th one into my collection of > > "dead digilent garbage" :( > > > The board was powered maybe 3 minutes and FPGA was configured with > > original bitstream > > for the dataflash programming, and yes incoming power is 5V not 9 > > > Any ideas? Should I be worry? The power supply IC are so tiny that it > > is defenetly not possible > > to mount any heat sink on them :( > > FWIW, my Spartan-3E 1600 kit from Digilent had a burning hot power > regulator (just short of smoking). Digilent swapped the board for one > that didn't do that, but was otherwise identical. I suspect there > might be something wrong with yours. > > Tommy- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - this is what I wanted to hear. yes looks like many different digilent board have power supply issues. Antti PS to Symon - I am doing "hard" since 1979, and doing not muchelse than FPGA hardware lately, so I did reall get insulted by your suggestion.Article: 122088
Is possible force the assignation of a number pin (no global pin) to a clock? (=BFcan i do before synthesize?) On synthetize put me the clock in a global pin, and before that, on compile, on layout I don't get assign on different normal pin. can anybody help me? thanksArticle: 122089
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1184832283.783273.250120@z24g2000prh.googlegroups.com... > > PS to Symon - I am doing "hard" since 1979, and doing not muchelse > than FPGA hardware lately, so I did reall get insulted by your > suggestion. > Antti, Wow, you're easily insulted. I apologise. The joke was meant to be that everyone on this board knows you're an excellent engineer, but even the best engineers burn their fingers now and again. However, I'll not try and joke with you again. Syms.Article: 122090
In modelsim Actel, when I do the post layout simulation, I have a lot of warnings. =BFhow i can take off the vitalglitch error (no the glitch) to can see other errors? I have other warning in the .log but i don't see that in the simulation. =BFcan i trust in this simulation? Warning: */DFF SETUP High VIOLATION ON D WITH RESPECT TO CLK; # Expected :=3D 0.8 ns; Observed :=3D 0 ns; At : 179.2 ns thanks.Article: 122091
"commone" <dechenxu@yahoo.com.cn> wrote in message news:2vadnSdtCPV3YAPbRVn_vgA@giganews.com... > Actually, I will split several ground planes for several parts of the > whole > circuit. Among that, I plan to give a isolated planelet to FPGA PLL > (Cyclone II ep2c35). > Of course, I know the advantage of a integral gnd plane,but in a real > design that is not easy to achieve. In a mixed signal design, if you keep > the single gnd plane integral, that will be a disaster for the analog > circuit. > Hi Commone, Let's just make sure we're talking about the same thing. The ground plane is the one that attaches to all the GND pins, right? Zero volts, 0V. You are wrong* to split this plane(s). I agree that you can, and maybe should, split the power planes, the ones that carry the supply voltages, i.e. 3.3V, 1.2V etc. However, if you split the ground planes you are in a world of pain when signals cross from one plane to the next. Their reference changes and the return current path has to go through one of your ferrites. Let me put it this way. If you design with one ground plane for all the circuit, exactly what is the mechanism for noise coupling from one area to another through this plane? Assume that the power supplies for each section are suitably isolated. Finally, why don't you go and look at some mixed signal IC manufacturers and have a look at their demo boards. They don't split ground planes. You will find some old app notes that claim split planes are good, but the boards they make don't have these splits. HTH., Syms. *There are very rare cases where the ground plane needs to be split, usually involving isolation requirements. When this happens it's very difficult to design properly.Article: 122092
[snip /] > >I have to generate buffer descriptor with all its fields like transfer >size,host address and destination address.my question was how to >generate it? > > You will need to supply a lot more context before there is any significant probablility of a useful answer. For example: - what sort of system/network? - what tools is this 'buffer descriptor' aimed at?Article: 122093
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:vvet935t6s89tn6pkqo9m220mdl52ccnnt@4ax.com... > On Wed, 18 Jul 2007 09:42:47 -0700, Lue.Her@gmail.com wrote: > > > 6 layers would make life a lot easier, one ground plane and two power > planes. One power plane can be 3.3 volts, and the other can be split > 2.5 and 1.2, one island inside the FPGA and a big pour outside. That > leaves three signal layers, and you can route signals on the 2.5/1.2 > layer too, once you make the FPGA happy. Two more layers won't cost > much more. > Hi John, If I had six layers, I'd make 2 and 5 ground planes. Then when signals via from one side to the other, their impedance to the ground plane stays pretty much the same, provided you use a ground via near to the signal via. This is also true of LVDS pairs, as the P and N signals are usually poorly coupled to each other, but strongly coupled to ground. Route the powers on one of layer 3 or 4. > > We ususlly use 4 caps per supply per FPGA, 0.33 uF 0603. Never had a > problem, even in systems where we measure jitter in picoseconds. Use > more if it makes you feel better, but they won't change anything. > > For fun, lay out a board with more caps and depopulate it until > something malfunctions. Write a paper. > > John > Right, it's hard to get bypassing wrong. If you cover the board in bypass caps it'll work just fine, but it'll cost you. Beware, the via holes you have to drill to connect them can be more expensive than the parts. I would suspect that in a 'real' system, the removal of bypass caps will probably cause some analog part of the board to fail before the FPGA. The switching noise from the FPGA can spread back through the power network more easily as bypassing is reduced. Cheers, Syms.Article: 122094
> I have other warning in the .log but i don't see that in the > simulation. ¿can i trust in this simulation? Simulators do have bugs, but in general you should trust the simulator more than your own newly developed code. > Warning: */DFF SETUP High VIOLATION ON D WITH RESPECT TO CLK; > # Expected := 0.8 ns; Observed := 0 ns; At : 179.2 ns Pretty clear description, you're violating the setup time of the flip flop. In post-route simulation this is frequently caused by having a design input signal transition at the wrong time relative to the clock or if you are trying to run the design at a clock speed faster than the design can handle (i.e. timing analysis indicates a max frequency of 95 MHz and post route-sim is running the clock at 100 MHz. In any case, it is pointless to try to run a post-route sim before you have completed static timing analysis of your design. Also make sure that your testbench code is transitioning the design inputs at a time relative to the clock that meets the setup and hold time requirements as computed by static timing analysis and not just at 'the rising edge of the clock'. KJArticle: 122095
>i've synthesized or1200 and it consumed 3920 slices and 7258 LUT's >which are beyond what is available with my xilinx device with 400K >gates. (I followed instructions ghiven in "openrisc-HW-tutorial- >Xilinx.pdf".) Why does this take this much of resources? is it >possible to reduce this to an acceptable level? (by removing some >stuff). > > From reading the output listings of the Xilinx tools, has it used the devices on-chip RAM blocks, or has it inferred flip-flop-based registers? If the latter, then you need to do the tutorial again, and correctly this time... What part are you targetting?Article: 122096
> However, if you split the ground planes you are in a >world of pain when signals cross from one plane to the next. Their reference >changes and the return current path has to go through one of your ferrites. > I will keep the digital signals not overlap the analog plane and the analog signals not overlap the digital plane. Will the digital return current go into analog plane and where is the volt drop across the FB? If you do want to mix the digital and analog traces in the same area, noone can do anything to save the analog circuits. > >Finally, why don't you go and look at some mixed signal IC manufacturers and >have a look at their demo boards. They don't split ground planes. You will >find some old app notes that claim split planes are good, but the boards >they make don't have these splits. > >HTH., Syms. > >*There are very rare cases where the ground plane needs to be split, usually >involving isolation requirements. When this happens it's very difficult to >design properly. > http://www.analog.com/en/content/0,2886,761%255F795%255F97529%255F0,00.htmlArticle: 122097
Hi, I think in this case you haven't started the simulation with the delay file. When doing post layout simulation, the netlist will have checks for hold and setup timings and without any net delays, you will most likely get this kind of errors. If you just do "vsim" then you will not get any delay file into which could explain your warning messages. You have to add "-sdfmax <filename>" if you want to run with max delays which is the normal case. You can find more on how to do VITAL/verilog timing simulations in the modelsim manual. Hope this helps Göran "merche" <dorama2@gmail.com> wrote in message news:1184839086.171005.210120@m3g2000hsh.googlegroups.com... In modelsim Actel, when I do the post layout simulation, I have a lot of warnings. ¿how i can take off the vitalglitch error (no the glitch) to can see other errors? I have other warning in the .log but i don't see that in the simulation. ¿can i trust in this simulation? Warning: */DFF SETUP High VIOLATION ON D WITH RESPECT TO CLK; # Expected := 0.8 ns; Observed := 0 ns; At : 179.2 ns thanks.Article: 122098
"commone" <dechenxu@yahoo.com.cn> wrote in message news:qd-dnZ9nU5sQ1ALbRVn_vgA@giganews.com... >> However, if you split the ground planes you are in a >>world of pain when signals cross from one plane to the next. Their > reference >>changes and the return current path has to go through one of your > ferrites. >> > I will keep the digital signals not overlap the analog plane and the > analog signals not overlap the digital plane. Will the digital return > current go into analog plane and where is the volt drop across the FB? > If you do want to mix the digital and analog traces in the same area, > noone can do anything to save the analog circuits. > I agree, you need to keep analog components away from fast switching digital ones. However, there's no need to cut the ground plane up to achieve this. It makes it complicated, and much more likely to go wrong. > > http://www.analog.com/en/content/0,2886,761%255F795%255F97529%255F0,00.html > Right, I see this a lot. They say "It may also be beneficial to use separate ground planes for the analog and the digital circuitry.", but then singularly fail to say what these benefits are. The reason they don't explain this is because there are almost no benefits, only drawbacks. I ask you again, presuming you physically separate the digital and analog circuits and power supplies, how does noise couple over a single shared ground plane? HTH., Syms.Article: 122099
> Right, it's hard to get bypassing wrong. If you cover the board in byp= ass > caps it'll work just fine, but it'll cost you. Beware, the via holes y= ou > have to drill to connect them can be more expensive than the parts. > I would suspect that in a 'real' system, the removal of bypass caps wi= ll > probably cause some analog part of the board to fail before the FPGA. = The > switching noise from the FPGA can spread back through the power networ= k = > more > easily as bypassing is reduced. > Cheers, Syms. Hm, I'm wondering about something... Someone talked about vias and caps and being careful about not "slottin= g = the ground plane"... what does this mean ? (or was it slitting ?) Was it this : http://home.peufeu.com/nik/fpga/board_v03/slit.png (top =3D bad, bottom =3D good) ? (I try to leave enough space between my vias so that the copper pour = can... well, pour itself). Or does it mean something else ? Also, well, on my FPGA each power pin has its own decoupling cap on the= = bottom of the PCB below the FPGA, each cap has + and GND connected to th= e = appropriate planes with vias. Question : I can also connect all the caps in parallel using traces. Is= = this harmful, good, or useless ? Like this : http://home.peufeu.com/nik/fpga/board_v03/decoupling.png Top : caps' GND connected to the plane by vias + paralleled using a tra= ce Bottom : caps' GND only connected through vias to the plane PS: I checked ; I can't use BGA packages because the min via = restring/drill of the PCB fab I plan to use is too large. But it's not = that expensive and the PCBs are electrically tested... Thanks ;)
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