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
commone wrote: > Ideally,if we physically separate the digital and analog circuits > and power supplies,noise will not couple over a single shared ground > plane. But the noisy digital cicuits will make the ground plane > nosiy.Right? The only way other circuits can make the ground plane noisy is by passing large currents across it. Proper layout of noise generating sections to contain all return currents will keep these current flows contained to areas away from the sensitive circuits. In some cases it can be necessary to place shields over noise generators, or even over sensitive circuits, to improve isolation, and to enclose the currents. JonArticle: 122126
On Jul 19, 4:22 am, "commone" <deche...@yahoo.com.cn> wrote: > > 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. If you have mixed-signal devices--ADCs, DACs--with, say, digital control signals, then a split plane is a real problem if those signals have to cross the split. -aArticle: 122127
On Thu, 19 Jul 2007 17:52:59 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >Hi John, >I know you don't believe the return current stuff, but I found this while >chatting in another thread and thought you'd be interested. >http://www.elecdesign.com/Articles/Print.cfm?AD=1&ArticleID=5944 Mostly bogus. Figure 3 is silly; it neglects the fact that space has a dielectric current, too. A current wavefront doesn't know anything about the generator or anything about its own history. It just sees capacitance in all directions, and the current divides appropriately. And split grounds are feasible on an eval board with one ADC. How about a board with a dozen analog front-ends and a dozen fast ADCs, like this one? http://www.highlandtechnology.com/DSS/V660DS.html It worked first time. > >BTW., I respectfully disagree that "Planes themselves are the best bypass >caps, so we try to not "route" power, but pour it.". The planes give a >little (maybe a few pF) of capacitance that has admittedly very small >inductance associated with it. The plane capacitance is useful at GHz speeds. More importantly, a tight power/ground plane stitches all the bypass caps together, in parallel, in a very low impedance, low-Q structure. I think. >However, the vias and IC packaging band-limit >the power connection to the die, which is where it matters, so that this >'wonder' capacitance does you no good. Furthermore, I find it's easier to >isolate noise between ICs with a routed power scheme. But that's my opinion, >I'm sure your boards work just fine also! :-) Your boards may work perfectly, but mine work twice as perfectly! JohnArticle: 122128
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:j3cv93d772on4k41h6ukte0l9mv3aqgkbc@4ax.com... > On Thu, 19 Jul 2007 17:52:59 +0100, "Symon" <symon_brewer@hotmail.com> > wrote: > >>Hi John, >>I know you don't believe the return current stuff, but I found this while >>chatting in another thread and thought you'd be interested. >>http://www.elecdesign.com/Articles/Print.cfm?AD=1&ArticleID=5944 > > Mostly bogus. Figure 3 is silly; it neglects the fact that space has a > dielectric current, too. A current wavefront doesn't know anything > about the generator or anything about its own history. It just sees > capacitance in all directions, and the current divides appropriately. > Nah, it sees inductance in all directions and generates flux accordingly! ;-) Cheers, Syms.Article: 122129
"Symon" <symon_brewer@hotmail.com> wrote in message news:f7njpp$vqm$1@aioe.org... > > 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? > I think there are 2 cases where the voltage developed between 2 points of a solid gnd plane can be big enough to be a problem: 1. There are huge currents in the system such as when there are electric motors involved; 2. The analog circuit has high input impedance and very sensitive such as the case with pro audio for example. I myself routinely design mixed RF/digital boards and for this purpose I chose to use a single ground plane long ago, however I am not convinced this approach will work well for the 2 cases mentioned above. /MikhailArticle: 122130
I am trying to synthesize a code using ISE which contains a component fifo the fifo code is the following -- synopsys translate_off library IEEE; use IEEE.STD_LOGIC_1164.ALL; library UNISIM; use UNISIM.VCOMPONENTS.ALL; use UNISIM.VPKG.ALL; entity ifo is .................... .............. end ifo ARCHITECTURE st of ifo is ......... ........ end st -- synopsys translate_on If I run the above code using ise it doesnt recognize the component at all. If I remove the line sysnopsys translate_off then it gives me following error Library unit VPKG is not available in library UNISIM any ideas? Thanks -DArticle: 122131
dhruvakshad@gmail.com wrote: > I am trying to synthesize a code using ISE which contains a component > fifo the fifo code is the following > > -- synopsys translate_off > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > library UNISIM; > use UNISIM.VCOMPONENTS.ALL; > use UNISIM.VPKG.ALL; Don't use VPKG, and put the translate_off/on only around the unisim stuff (in this case "synthesis" is a synonym for "synopsys"): library IEEE; use IEEE.STD_LOGIC_1164.ALL; -- synthesis translate_off library UNISIM; use UNISIM.VCOMPONENTS.ALL; -- synthesis translate_onArticle: 122132
Hi to all, I am considering to replace the x16 SDRAM for a x16 DDR2 to gain some bandwidth for a MicroBlaze system. I wonder if someone tested the Xilinx EDK MCH_OPB_DDR2 memory controller core for bandwidth on Spartan3. Looking at the MCH_OPB_DDR2 datasheet It apears that burst reads are not performed every clock cycle?! Is that true? I tested OPB_SDRAM controller at 50MHz and the measured bandwidth is about 60MB/s using burst transfers (poor) and reads are performed every 4th cycle. Another problem with OPB_SDRAM is no support for async clocking so RAM is always clocked at OPB clock. Comments and suggestions welcome, GuruArticle: 122133
> I tested OPB_SDRAM controller at 50MHz and the measured bandwidth is > about 60MB/s using burst transfers (poor) and reads are performed DUHH, no, no, no !!! Use mch_opb_sdram !! opb_sdram is a very simple (slow slow) SDRAM controller that you can use when you want to read a byte or something, nothing more. Try mch_opb_sdram, it supports bursts and plays nice with the xilinx DMA core, you get more bandwidth and it interfaces with the microblaze's cache. Since you apparently have a board with SDRAM, instantiating mch_opb_sdram is easy, and it's a lot faster than opb_sdram. Try it ;)Article: 122134
Hi all, I am considering to replace a SDRAM with a DDR2 on a custom Spartan3E1200 board to gain some bandwidth in a Microblaze system. Currently I am working with OPB_SDRAM core and I am not satisfied with 60MB bandwidth in burst mode (x16 SDRAM and 50MHz clock). It takes 4 cyles to read a word (32bits) and it does not support async clocking, so OPB clock is the same as RAM clock. I wonder what can I expect if I use x16 DDR2 RAM coupled to MCH_OPB_DDR2 (power consumption, bandwidth, problems...). Cheers, GuruArticle: 122135
On 19 Jul., 11:44, "Symon" <symon_bre...@hotmail.com> wrote: > "Antti" <Antti.Luk...@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. No Problems - ;) eh my joke-tolerance is little low lately, and it hasnt been very high ever I suppose AnttiArticle: 122136
On 19 Jul., 23:57, Guru <ales.gor...@email.si> wrote: > Hi all, > > I am considering to replace a SDRAM with a DDR2 on a custom > Spartan3E1200 board to gain some bandwidth in a Microblaze system. > Currently I am working with OPB_SDRAM core and I am not satisfied with > 60MB bandwidth in burst mode (x16 SDRAM and 50MHz clock). It takes 4 > cyles to read a word (32bits) and it does not support async clocking, > so OPB clock is the same as RAM clock. > I wonder what can I expect if I use x16 DDR2 RAM coupled to > MCH_OPB_DDR2 (power consumption, bandwidth, problems...). > > Cheers, > > Guru you may have better luck using DDR memory, the DDR controller is little better in performance then the SDRAM IP core from xilinx. going with DDR2 on S3E I would not advice unless you really know what you are doing (and then you would not ask about it..) AnttiArticle: 122137
Is possible force the assignation of a clock to a pin (non global pin)? (=BFcan i do before synthesize?) On synthesis the clock is put in a global pin, and after that, on compilation, on layout I don't get assign on non global pin. can anybody help me? thanksArticle: 122138
merche wrote:
> Is possible force the assignation of a clock to a pin (non global
> pin)? (=BFcan i do before synthesize?)
>=20
> On synthesis the clock is put in a global pin, and after that, on
> compilation, on layout I don't get assign on non global pin. can
> anybody help me?
>=20
>=20
> thanks
You can assign a signal to a _pin_ when using Designer by including a=20
GCF file which includes a constraint such as:
set_io "100" "my_clock";
However I suspect you're really asking how to specify a global clock=20
buffer for a signal that is not connected to one of the GLB pins?
For that you need to specify the net as a clock in Synplify using an SDC =
file with a constraint such as:
define_clock {n:my_clock} -name {n:my_clock} -freq 10 -clockgroup=20
default_clkgroup_1
This will prevent Synplify from inferring a tree of BFRs on that net,=20
and in turn Designer will then promote the net to using a global buffer=20
to accomodate its high fanout.
Alan
Article: 122139>"Symon" <symon_brewer@hotmail.com> wrote in message >news:f7o30r$itc$1@aioe.org... <snip /> >Check this out >http://www.elecdesign.com/Articles/Print.cfm?AD=1&ArticleID=5944 > >This guys agrees with me! Wooo! >Warning:- Other people may have different opinions! > >Cheers, Syms. > > Interesting article. That one definitely goes into the data bank for future reference. Thanks.Article: 122140
On Jul 19, 11:45 pm, PFC <li...@peufeu.com> wrote: > > I tested OPB_SDRAM controller at 50MHz and the measured bandwidth is > > about 60MB/s using burst transfers (poor) and reads are performed > > DUHH, no, no, no !!! > Use mch_opb_sdram !! > > opb_sdram is a very simple (slow slow) SDRAM controller that you can use > when you want to read a byte or something, nothing more. > Try mch_opb_sdram, it supports bursts and plays nice with the xilinx DMA > core, you get more bandwidth and it interfaces with the microblaze's cache. > > Since you apparently have a board with SDRAM, instantiating mch_opb_sdram > is easy, and it's a lot faster than opb_sdram. Try it ;) PFC, I guess you dont know what is behind these two controllers. The SDRAM controller is the SAME for both of them. The OPB_SDRAM works the same as the MCH_OPB_SDRAM if you connect it only to OPB bus. If you want Microblaze to have a fast access to SDRAM then you use MCH otherwise it is a waste of logic resources. GuruArticle: 122141
> PFC, > > I guess you dont know what is behind these two controllers. The SDRAM > controller is the SAME for both of them. The OPB_SDRAM works the same > as the MCH_OPB_SDRAM if you connect it only to OPB bus. If you want > Microblaze to have a fast access to SDRAM then you use MCH otherwise > it is a waste of logic resources. You made me doubt ;) I had a look again at the timing diagrams of both controllers and here is the explanation : I am using a dual port BRAM. One port is connected to a core I wrote which gets data from the outside world, and writes it to the BRAM. The other port is connected to opb through the appropriate Xilinx core. This is a kind of FIFO. So I wanted to copy data using DMA from BRAM to SDRAM fast in order to empty my FIFO and not hog the OPB bus too much since there are a lot of other stuff running. OPB is 32 bits @ 50 MHz so max bandwidth is 200 MB/s, but in real life it will be lower of course. You say opb_sdram and mch_opb_sdram have the same SDRAM controller core ; I trust you on that, but this isn't my point... the key is how those lock the OPB bus (or not). When doing burst-write to opb_sdram, the OPB bus is locked during almost the entire transaction. However, mch_opb_sdram has a FIFO : it will absorb the OPB burst write, then the OPB bus is free for other stuff while the SDRAM core writes to the memory. Obviously you can't access SDRAM since the controller is busy, but you can still use OPB to access BRAM or other things. Here is how it went with mch_sdram - DMA controller writes a burst to opb_sdram - opb_sdram keeps the OPB bus to itself while it writes to the SDRAM chip - after the write is finished, OPB is now available - DMA controller reads from BRAM - repeat Here is how it went with mch_opb_sdram 1 - DMA controller writes a burst to mch_opb_sdram which fills its FIFO 2 - concurrently : - DMA controller refills its buffer from BRAM via OPB bus which is free - mch_opb_sdram flushes its FIFO to the SDRAM chip 3 - repeat So, if you want to burst data from some OPB peripheral or BRAM to SDRAM, the mch controller will be much faster. DMA copy from SDRAM to SDRAM, or SDRAM reads, won't show much difference though.Article: 122142
miche schrieb: > I also need to multiplex the clock. Thats not an easy question, because switching to an other clock will result in hazards. So the question is: Are hazards at the resulting clock a problem or not? If they are a problem: 1) You might disable the logic while switching to the other clock. 2) You might take care of the hazards and avoid them. If so you need two cross-coupled clock gates (one for each input clock) and the appropriate logic to select one clock AND disable the other BEFORE. If I remember it right, this is possible using 4 latches (plus combinational logic). 1 Latch as clock gate, enabled during the high level of an input clock and 1 latch to release the other clock gate. You will lose some clock pulses, if you use this solution. RalfArticle: 122143
I've been looking at the Spartan 3an's mostly, because of the built-in config flash, but I've yet to settle on them as the preferred chip for my project. As it turns out, another chip I'm wanting to use is bga, and since it's unavoidable I've been looking for the same in the fpga. It would be really nice if there was a bga chip at or around 10-12mm in size... but I can't seem to find any such. Only the larger gate count fpga's are bga package, and most of those seem to come in at around 20mm in size... which means the board I'm working on would be wider than the dip chip that it's replacing. Something I'm willing to live with, but certainly more challenging because the chip is in several machines that each have their own board layout. I might have 2 inches of space below the chip on one machine, but can't even have a quarter inch worth of overhang in that same place on another. Now, I do realize that an especially small package chip means that I won't be able to have a high gate count or as many io pins, but I don't believe my project even needs that. So, does anyone have any suggestions? I'm not married to Xilinx, an Altera or Lattice chip that made things easier here would really rock. Slight topic change: What do you guys think of this board for a learner's first fpga? http://www.digilentinc.com/Products/Detail.cfm?Prod=BASYS&Nav1=Products&Nav2=Programmable It's well within my price range, I could afford more, and I don't want to get something so weak it can't even teach me anything. Is 100 kgates enough to implement an 8bit cpu? Would I be able to implement an ethernet core or usb with it? Etc. Just want an opinion. Thanks, John O.Article: 122144
John, http://www.digilentinc.com/Products/Detail.cfm?Prod=S3EBOARD&Nav1=Products&Nav2=Programmable ($149) Has the kinds of resources that you need to really learn something. This platform is used at many colleges and universities, and there is a lot more "stuff" on the web for this board, than for the tiny little one for $49. The $49 is a good board for prototyping a small design (connect the IOs to your stuff, create the design in the FPGA, test it, etc.). As for a really tiny package, have you looked at CPLD's? Why does it have to be a FPGA if you really don't need much IO, and so few logic elements? AustinArticle: 122145
Some of the Spartan-3 and Spartan-3E chips come in a 8x8 mm CSP package: http://www.xilinx.com/publications/prod_mktg/pn2027.pdf (see last page) /MikhailArticle: 122146
On Jul 19, 12:36 pm, Ben Jackson <b...@ben.com> wrote: > On 2007-07-19, Xilinx User <anonym...@net.com> wrote: > > Is it including `i' in * and then complaining about it? Presumably it is including 'memory' in * and then complaining about it. An entire memory/array is not legal in an event control, so there is justification for complaining. The LRM does not specify how this issue is supposed to be handled. There was plenty of discussion in committee about it, but nothing was ever done about it. Many tools do appear to handle it the way you would want for combinational logic, by making the block sensitive to the entire memory.Article: 122147
On Jul 20, 11:09 am, austin <aus...@xilinx.com> wrote: > John, > > http://www.digilentinc.com/Products/Detail.cfm?Prod=S3EBOARD&Nav1=Pro... > > ($149) > > Has the kinds of resources that you need to really learn something. > This platform is used at many colleges and universities, and there is a > lot more "stuff" on the web for this board, than for the tiny little one > for $49. > > The $49 is a good board for prototyping a small design (connect the IOs > to your stuff, create the design in the FPGA, test it, etc.). > > As for a really tiny package, have you looked at CPLD's? Why does it > have to be a FPGA if you really don't need much IO, and so few logic > elements? > > Austin To be honest, I'm not sure how much logic this needs yet. I'm wanting to do a modest FPU, actually. Probably not even worried about IEEE-754 compliant, just enough to add a few muliplication/division/log instructions to an old 8 bit cpu. I want to put the fpga "in front of" the cpu, intercepting the instructions it reads... if it sees a JSR and then a particular address it will be suspended, and the fpu takes over. Supposedly, the 6502 was only about 5000 transistors, that's what, 2500 gates maybe? It's the cpu I want to augment. But an fpu has to be more complex, right? So I really don't know what I need yet... I'm just guessing that even the biggest cpld isn't quite enough, but that the smallest fpga in any family, even in the more modest ones, will be. And it's kinda moot... I just checked WDC's site, and it looks like the 6502 is available in qfp44 as the smallest, still wider than a 600mil dip. Argh.Article: 122148
On Jul 20, 9:57 am, John Oyler <john.m.oy...@gmail.com> wrote: > I've been looking at the Spartan 3an's mostly, because of the built-in > config flash, but I've yet to settle on them as the preferred chip for > my project. As it turns out, another chip I'm wanting to use is bga, > and since it's unavoidable I've been looking for the same in the fpga. > It would be really nice if there was a bga chip at or around 10-12mm > in size... but I can't seem to find any such. Only the larger gate > count fpga's are bga package, and most of those seem to come in at > around 20mm in size... which means the board I'm working on would be > wider than the dip chip that it's replacing. Something I'm willing to > live with, but certainly more challenging because the chip is in > several machines that each have their own board layout. I might have 2 > inches of space below the chip on one machine, but can't even have a > quarter inch worth of overhang in that same place on another. > > Now, I do realize that an especially small package chip means that I > won't be able to have a high gate count or as many io pins, but I > don't believe my project even needs that. > > So, does anyone have any suggestions? I'm not married to Xilinx, an > Altera or Lattice chip that made things easier here would really rock. > > Slight topic change: What do you guys think of this board for a > learner's first fpga? > > http://www.digilentinc.com/Products/Detail.cfm?Prod=BASYS&Nav1=Produc... > > It's well within my price range, I could afford more, and I don't want > to get something so weak it can't even teach me anything. Is 100 > kgates enough to implement an 8bit cpu? Would I be able to implement > an ethernet core or usb with it? Etc. Just want an opinion. > > Thanks, > John O. The Spartan-3 and Spartan-3E are both listed as coming in a 8mm by 8mm CP132 package. We use a Spartan-3E with a SPI ROM for configuration. The Spartan-3E understands how to configure itself from a SPI ROM, so there is no additional external components required for configuration. To program the SPI ROM, we use JTAG to download a configuration into the Spartan that has a JTAG to SPI ROM bridge in it, then download what we want in the SPI ROM over JTAG. We are using the XC3S100E with a PicoBlaze 8 bit processor in it, plus a MiniSD controller, and it has room to spare. Up to the XC3S500E is listed in the CP132 package, so you would have three FPGA sizes to choose from. Regards, John McCaskill Faster TechnologyArticle: 122149
Hello, I am a newbie in microblaze.I'm trying to implement a basic data reading and writing to bram with microblaze.Can you help me where can i find basic tutorials about that.(more useful tutorials than xilinx page:) ) Best wishes, Fatih Gunes
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