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
You can easily accomplish the digital requirements in an FPGA. The problem comes with the analog. You either need 1) a 24:1 analog mux or 2) 24 channels of slope circuitry and comparator. I would NOT recommend using the FPGA inputs as precision comparators. Multichannel A/D converters are available off-the-shelf but 24 channels may be hard to accommodate in fewer than 3 devices at a cost you would like. Check out Analog Devices at analog.com or some of you other "favorite" analog houses. "Hw" <localhost@com.com> wrote in message news:hNKQe.7129$UE2.2122@tornado.socal.rr.com... > Hi. > > I need to digitize an array of signals (24) with minimum 8-bit > resolution, with < 2ms conversion time. Signals are single-ended 0 to > 5V. I am trying to keep costs low, therefore I am trying to avoid > multiple A/Ds and/or complex multiplexing situations. > > I know of the "slope" A/D technique of charging a capacitor or the > sigma-delta technique of using a PWM DAC and a comparator to form an > A/D. > > Would it be possible to get the speed I want using either of those > techniques with an FPGA? > > Thank you. > H.Article: 88826
John_H wrote: > You can easily accomplish the digital requirements in an FPGA. > The problem comes with the analog. > > You either need 1) a 24:1 analog mux or 2) 24 channels of slope circuitry > and comparator. I would NOT recommend using the FPGA inputs as precision > comparators. What about using a differential input of the FPGA ? SylvainArticle: 88827
"Andrew Holme" <andrew@nospam.com> wrote in message news:devuni$a0t$1$830fa17d@news.demon.co.uk... <snip> > I'm using a Marconi 2382 spectrum analyzer. At current levels, I can see it > no problem wthout any special test setup. If I get another 10 or 20 dB > improvement, then I'd need a more sophisticated method. You're taking the bandwidth into account? Usually spectrum analyzers like to report in dBm - bandwidhts need to be considered along with slopes to determine "real" dBc/Hz or dBc/sqrt(Hz). <snip> > > Have you tried integer-N values with higher comparison frequencies? > I've tried 100 KHz and 500 KHz comparison frequencies. You might find a trend in noise improvement as you increase the comparison frequency, averaging the effect of nonlinearities of the system. By doing your initial investigation at integer-N values, the spurs that "should" be filtered out aren't a concern in wideband noise measurements. Only when you know what to expect at higher frequencies can you figure out what an ideal reference frequency may be. I consider the biggest advantage to using fractional-N synthesis (particularly with programmable logic) is the high comparison frequencies used to get the desired ratios. If you're using a 10 MHz oscillator, use that value undivided and check the 20 MHz performance with a VCO divide-by-2. Step back to 19.8 MHz with the fractional 1.98 value and see if there's noticeable degredation from the noise shaping for close-in phase noise. > Yesterday, I thought the phase noise might be due to the reference or the > PFD, and when I estimated the dBc/Hz at the PFD, I thought the numbers were > poor. Now, I'm not so sure the CPLD is the biggest problem. I think I may > just need better power supply filtering after the monolithic regulators. You noted an improvement going from 100k to 500k comparison frequencies. If power-supply noise were dominant, I wouldn't expect to see that 13 dB change in phase noise. <snip> > What sort of PFD did you have in mind? For my own synth design, I'd like to use a clock generator with integrated PFD/VCO with good characterization so I know what to expect when running 50 MHz (or similarly large) reference frequencies. The MiniCircuits devices are great to prototype with or do one-off pieces of test gear, but when going for those kinds of designs the actual AD9901 might be the most productive way to go. The integrated PFD/VCO devices tend to generate much higher frequency VCOs internally (to be entirely on the silicon) but are often divided down internally to give a "usable" output frequency. I think the part I was looking at most recently (because of the integrated, programmable loop filters) was an idt device - the part number eludes me at the moment (some of this research is at home). With an appropriate clock generator (ideally single channel), the reference frequency from the fractional-N generator can internally go through an integer-N multiply to get to the desired output frequency. All the intelligence in in the FPGA/CPLD, all the analog precision is in the clock generator.Article: 88828
Sylvain Munaut skrev: > John_H wrote: > > You can easily accomplish the digital requirements in an FPGA. > > The problem comes with the analog. > > > > You either need 1) a 24:1 analog mux or 2) 24 channels of slope circuitry > > and comparator. I would NOT recommend using the FPGA inputs as precision > > comparators. > > What about using a differential input of the FPGA ? > > > > Sylvain I believe someone has a patent on that, I'm not sure how good they work but for 8 bits it may be good enough -LasseArticle: 88829
<langwadt@ieee.org> wrote in message news:1125355980.290728.181820@o13g2000cwo.googlegroups.com... > > Sylvain Munaut skrev: > > > John_H wrote: > > > You can easily accomplish the digital requirements in an FPGA. > > > The problem comes with the analog. > > > > > > You either need 1) a 24:1 analog mux or 2) 24 channels of slope circuitry > > > and comparator. I would NOT recommend using the FPGA inputs as precision > > > comparators. > > > > What about using a differential input of the FPGA ? > > > > > > > > Sylvain > > I believe someone has a patent on that, I'm not sure how good they work > but for 8 bits it may be good enough > > -Lasse 20 mV for 1 LSbit for 8 bits at 5V may be workable but are the inputs happy with 5V swing? The slope method I recall cahrged a cap up from 0V from a voltage-controlled current source for a fixed time and back down to 0V from a fixed constant-current source. The count gave the A/D value. The 0V could be moved to a nice Vref level. The charge-up voltage could be large and resistor-limited to the FPGA so the out-of-range high voltage (limited by the I/O protection diode) always gives a good high result and the finish/end crossover is well within the specified ranges. The problem still remains: 24 channels of analog MUX or 24 channels of slope circuitry.Article: 88830
John_H wrote: > You're taking the bandwidth into account? Of course. I'm subtracting 10dB for 10Hz RBW. > You noted an improvement going from 100k to 500k comparison > frequencies. If power-supply noise were dominant, I wouldn't expect > to see that 13 dB change in phase noise. No, there was no difference, no 13dB change. That was my point.Article: 88831
Hi, There are two main fpga manufacturers, Xilinx and Altera...The documentation provided with their free development tools have everything you need.A good start is to learn vhdl, then download xilinx ISE7 ,then read the VHDL techniques in XST(synthesis tool) documentation ..then download a datasheet of the target device (Spartan 3, Virtex,..etc) ..then write code and compile and see how it's synthesized and how the resources are used...Article: 88832
Hi all, I am a beginner to the field of fpga. My friend at col exposed me to this and I do find the idea worth exploring. Can anyone plz share his(er) experiences regarding getting started and familiarized with the field. Any help will be highly appreciated. Thanks Nitin. nitins_delhi@yahoo.comArticle: 88833
Andrew Holme wrote: > Thanks to all for the suggestions. <snip> > This gives 20nV/sqrt(Hz). Since U4 output is a 50% duty cycle square > wave(XOR PFD), presumably I would still only need 40nV/sqrt(Hz) on the > regulator output? Is 40nV/sqrt(Hz) at 1 KHz credible for a 78L05 with 100n > + 10n hanging off its output? Once you have cleaner supply filtering to the 1G125, you could try different Phase comparitors : eg a HC4046/7046, then try the same logic inside the CPLD. Gives you ideas, and also a comparison point. Simple XOR detectors have poor PSRR, as you note, and also low phase gain. Better synthesisers use charge balancing, or a combination of detectors / gains. Good designs also avoid a complete null, on phase match, to avoid dead-zones, on their charge balancing detectors. If you are looking for absolute best performance, also look at doing a balanced (Push-Pull) Phase Det - that gives better PSR. -jgArticle: 88834
Hello Andrew, > Yesterday, I thought the phase noise might be due to the reference or the > PFD, and when I estimated the dBc/Hz at the PFD, I thought the numbers were > poor. Now, I'm not so sure the CPLD is the biggest problem. I think I may > just need better power supply filtering after the monolithic regulators. So just hang the analyzer onto the VCC and look. But ease it onto the rail slowly and don't power cycle the board while probing. Else you might fry its input. Regards, Joerg http://www.analogconsultants.comArticle: 88835
Simon Peacock wrote: > well its an interesting follow on... the more cores.. the better the > floating point.. I think that's the aim here... but I'm surprised no one has > mentioned the cell... it has 9 processors on board. IBM has just posted more info on this, as they 'open' it up. Good info on opcodes, but hard to find real speed specs, or price / package options.... IIRC an earlier release also mentioned some programmable fabric linking these cores [so they did not need to get it quite so 'right first time'] but not sure if that info will be avaialble to end users. So, perhaps a FPGA _and_ a Cell :) ? -jgArticle: 88836
> I need to digitize an array of signals (24) with minimum 8-bit > resolution, with < 2ms conversion time. Signals are single-ended 0 to > 5V. I am trying to keep costs low, therefore I am trying to avoid > multiple A/Ds and/or complex multiplexing situations. > > I know of the "slope" A/D technique of charging a capacitor or the > sigma-delta technique of using a PWM DAC and a comparator to form an > A/D. > > Would it be possible to get the speed I want using either of those > techniques with an FPGA? FPGA usually do not contain comparator inputs which you need for a slope conversion. How about using a cheap ADC plus a few low cost 8:1 muxes (74HC or CD series)? Regards, Joerg http://www.analogconsultants.comArticle: 88837
"CMOS" <manusha@millenniumit.com> wrote in message news:1125292691.124584.29570@f14g2000cwb.googlegroups.com... > does any one know where to find some example projects for spartan 3 > starter board for digilent. > CMOS > http://www.xilinx.com/products/boards/DO-SPAR3-DK/reference_designs.htm can also easily adapt a lot of the examples on www.fpga4fun.com and http://www.xess.com/ho03000.htmlArticle: 88838
Hw wrote: > Hi. > > I need to digitize an array of signals (24) with minimum 8-bit > resolution, with < 2ms conversion time. Signals are single-ended 0 to > 5V. I am trying to keep costs low, therefore I am trying to avoid > multiple A/Ds and/or complex multiplexing situations. > > I know of the "slope" A/D technique of charging a capacitor or the > sigma-delta technique of using a PWM DAC and a comparator to form an > A/D. > > Would it be possible to get the speed I want using either of those > techniques with an FPGA? Silicon Labs have small uC that can do 32 Channel ADC, in 12 bit or 8 bit : they are 2.5V Max IP, so you'll need 2:1 dividers. Any FPGA solution will not be very pin or external component efficent. The FPGA can easily do the PWM / Counter side of any ADC, but you need external divider, signal conditioning, and integration. Most vanilla is a R-C-R charge balancing system,[needs 48 pins] but that would struggle to give 8 bits, and be prone to FPGA supply noise. Adding external analog SW will improve PSRR, and an external comparitor would improve precision, but you can see on 24 channels, you are quickly past a single chip uC..... -jgArticle: 88839
Marc: Thanks for the input. I found the problem. Too many late nights. Sometimes a good nights rest can give you a fresh start. Take care, rob "Marc Randolph" <mrand@my-deja.com> wrote in message news:1125156887.905188.68700@z14g2000cwz.googlegroups.com... > > Rob wrote: >> I'm trying to implement a SERDES interface within a Cyclone device. I've >> set it up using a PLL, DDIO, a couple of shift registers, and some output >> DFF's. I'm seeing some timing issues. How do you compensate for shift >> (between the data clock and the serial data) that is caused due to the >> time >> the PLL takes to lock to the incoming clock? >> [...] > > Howdy Rob, > > Your question doesn't make sense to me. The clock should be running > continuously while you want to transfer data, so it only has to lock > once (or at least, once in a blue moon). And once it is locked, the > PLL generally removes any "shift" (aka propagation delay) associated > with using the PLL or global clock network, creating the proper > alignment to sample incoming data. > > I'm sure Altera has some appnotes on doing stuff like this. Ah, here > is but one: > > http://www.altera.com/literature/an/an356.pdf > > Also, what do you mean that you're seeing timing issues? Timing > issues, to me, invokes images of having too many levels of logic to fit > within a clock period (or in some cases on a V4, any levels of logic > :-). That is a completely independent issue from the PLL alignment or > locking. > > Have fun, > > Marc >Article: 88840
hi, im wondering whether there is a point in using 8087 Math Co-Processor in this FPGA Age? CMOSArticle: 88841
i've worked thru all of the openrisc HW and SW steps. everything went well, or at leas seemed to. however, when i startup the jp1 utility, it connects to my board (xupv2) but the "Read" and "Expected" numbers to do match at all. the HW doc says if this happens to "check the onchip-ram module", but doesnt give any more details. i'm looking for some hints... thanks jeff # ./jp1 xpc3 9999 Connected to parallel port at 378 Dropping root privileges. Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 4000000c ppc = 40000024 r1 = 00000005 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 4000000c ppc = 40000024 r1 = 00000008 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 40000024 ppc = 40000020 r1 = 0000000b Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 40000020 ppc = 4000001c r1 = 00000018 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 4000001c ppc = 40000018 r1 = 00000031 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 40000020 ppc = 4000001c r1 = 00000032 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 40000010 ppc = 4000000c r1 = 00000063 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 40000024 ppc = 40000020 r1 = 00000065 Read npc = 00000100 ppc = 00000104 r1 = 00000000 Expected npc = 4000000c ppc = 40000024 r1 = 000000c9 result = 5eadeccd Dropping root privileges. JTAG Proxy server started on port 9999 Press CTRL+c to exit.Article: 88842
"Andrew Holme" <andrew@nospam.com> wrote in message news:desmbt$i07$1$8302bc10@news.demon.co.uk... > The dividers and the phase detector of my experimental frequency > synthesizer > are implemented in a 15ns Altera MAX7000S CPLD. I've tried different > multiplication factors (kN) to see how the close-in phase noise varies. > At > a 1 KHz offset, I get: > > -82 dBc/Hz for N=198 (VCO=19.8 MHz, comparison freq = 100 KHz) > -95 dBc/Hz for N=39 (VCO=19.5 MHz, comparison freq = 500 KHz) > > Calculating the equivalent phase noise at the PFD: > > -82-20*log10(198) = -128 dBc/Hz > -95-20*log10(39) = -127 dBc/Hz > > Given the 5:1 ratio of comparison frequencies, at a guess, I'd expect > these > to differ by 13 dB if the noise was mainly due to a fixed amount of time > jitter at the PFD. > > I'm using a 10 MHz canned crystal oscillator, which I'm dividing down > (inside the CPLD) to obtain the reference frequencies. I've read these > are > good for at least -130 dBc/Hz (before dividing down) so I'm a bit > dissappointed with my noise levels. Maybe it got a bit too hot when I > soldered it to the ground plane! I must try another.... > > Googling for "altera cpld jitter" doesn't turn-up much, and they don't > mention jitter in the datasheet. Does anyone know what sort of > performance > can be expected from a CPLD in this regard? I don't know if the CPLD, or > my > circuit lash-up is the root cause. > > A full write-up of the project can be found at > http://www.holmea.demon.co.uk/Frac2/Main.htm It has a fractional-N > capability, but noise-levels are the same in integer-N mode with the > external RAM disabled. I'm not sure why you think you should be seeing a 13dB difference at the input. If I can make some gross assumptions here, I'm going to assume that your system is second order, highly overdamped (the poles are widely separated), and that the bandwidth, even at the 100kHz update rate, is much greater than 1kHz. Then, if your dominant noise source is at the reference input, the gain from input to output close to the carrier is N. If your dominant noise source is at the VCO input, the gain close to the carrier is N/(Kd*R). In both cases, you have a gain of N. Looking at your data, I see that if the noise at 1KHz offset is constant, whether it's at the reference input or the VCO input, the noise should change by about 14dB. You're measuring 13dB instead of 14dB... so, what's the problem? -- Mike --Article: 88843
Thanks, Marc and Mike, for your responses. Marc, practially all of those links you listed (some i had not found on my own, thanks again), talk about RAM, and write coherency etc. As i only need a ROM, these are non-issues for me. Mike, your option "2" is what I am doing right now, and I do have BRAMs to spare so this is sufficient for now, as i am using the larger FPGA for prototyping, but the rest of my design is so small that just cause of the BRAM problem I will have to keep using this much more expensive FPGA. If i can use a dual proted BRAM, then i can use the smaller cheaper one. I guess I can just go ahead and instantiate the BRAM blocks manually to solve that problem. >From both of your responses, I guess the consensus that can be derived is there is no portable way to infer a dual ported ROM. Is this true for VHDL as well? I was hoping that some newsgroup members who work at one of the synthesis tool-vendors would have some suggestions? -AbhishekArticle: 88844
"Joerg" <notthisjoergsch@removethispacbell.net> a écrit dans le message de news: 7dOQe.798$Kk1.512@newssvr19.news.prodigy.com... >> I need to digitize an array of signals (24) with minimum 8-bit >> resolution, with < 2ms conversion time. Signals are single-ended 0 to >> 5V. I am trying to keep costs low, therefore I am trying to avoid >> multiple A/Ds and/or complex multiplexing situations. >> >> I know of the "slope" A/D technique of charging a capacitor or the >> sigma-delta technique of using a PWM DAC and a comparator to form an A/D. >> >> Would it be possible to get the speed I want using either of those >> techniques with an FPGA? > > FPGA usually do not contain comparator inputs which you need for a slope > conversion. How about using a cheap ADC plus a few low cost 8:1 muxes > (74HC or CD series)? > > Regards, Joerg > > http://www.analogconsultants.com Yes Joerg, or a cheap ADC (or a small microcontroller with ADC) and an external 32 channels mux (available from Analog Device, ADG731, for $4,5 / 1k, probably far less than an FPGA... Friendly yours, -- Robert Lacoste ALCIOM - The mixed signal experts www.alciom.comArticle: 88845
"c d saunter" <christopher.saunter@durham.ac.uk> skrev i meddelandet news:dehvgq$p56$1@heffalump.dur.ac.uk... > John, > I had a look at the Broaddown2 module, and one item I couldn't see was > a user Flash device - although the platform flash can be used for user > data it's sometimes convenient to have a physically seperate flash, and > these days you can get some large storage, physically tiny SPI devices. > The AT45DB642D has 64 Mbit in an SO-8 pinout, so that should fit nicely. Should be available in a few weeks. One nice function I have been thinking of is to have a small controller with USB interface and USB Mass Storage Adapter code. You can get some fast small single chip ARM/Flash devices with USB interface that could download the bitstream to a FAT file system in the dataflash, and then program the FPGA at boot, or when the bitstream is downloaded. The user could then just drag and drop the bitstream to your board to reconfigure the board. > Also as an asside, I was interested to see your note on the US & UK export > regulations - can you expand any details on that? Top Secret pinout on the > edge connectors :-) or regulations on the FPGA? > > Regards, > Chris > -- A. P. RichelieuArticle: 88846
On Tue, 30 Aug 2005 09:46:33 +0200, "A. P. Richelieu" <a.p@richelieu.com> wrote: > >"c d saunter" <christopher.saunter@durham.ac.uk> skrev i meddelandet >news:dehvgq$p56$1@heffalump.dur.ac.uk... >> John, >> I had a look at the Broaddown2 module, and one item I couldn't see was >> a user Flash device - although the platform flash can be used for user >> data it's sometimes convenient to have a physically seperate flash, and >> these days you can get some large storage, physically tiny SPI devices. >> > >The AT45DB642D has 64 Mbit in an SO-8 pinout, so that should fit nicely. >Should be available in a few weeks. I prefer the SGS-Thomson serial flash (M25P series) - simpler and cheaper than the Atmels last time I looked. Also second-sourced by SST.Article: 88847
I am attempting to simulate a very basic system built with Xilinx EDK 7.1.02i, using VHDL. After generating the ModelSim specific compiler scripts, I can execute a do system.do, which works okay, but when I execute the vsim system command I get the following results. I have had similar problems when trying to do a Verilog/VHDL mixed simulation system. Looking around on the Xilinx web site, I see that someone else has had a similar problem (http://toolbox.xilinx.com/cgi-bin/forum?50@233.ec6BaE6ihO8.4@.ee8f9bc), but I did not see any responses or suggestions. Any help would be appreciated. Thanks, Brian ------------- ModelSim> vsim system_conf system # vsim system_conf system # Loading c:\Modeltech_6.1a\win32/../std.standard # Loading c:\Modeltech_6.1a\win32/../ieee.std_logic_1164(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.vcomponents # Loading c:\Modeltech_6.1a\win32/../std.textio(body) # Loading c:\Modeltech_6.1a\win32/../ieee.vital_timing(body) # Loading work.system_conf # Loading work.system(structure) # Loading work.microblaze_0_wrapper(structure) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.microblaze_isa # Loading c:\Modeltech_6.1a\win32/../ieee.std_logic_arith(body) # Loading c:\Modeltech_6.1a\win32/../ieee.std_logic_unsigned(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.microblaze_types(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.microblaze(imp) # Loading c:\Modeltech_6.1a\win32/../ieee.numeric_std(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.decode(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.prefetch_buffer(imp) # Loading c:\Modeltech_6.1a\win32/../ieee.vital_primitives(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.vpkg(body) # ** Warning: (vsim-3479) Time unit 'ps' is less than the simulator resolution (1ns). # Time: 0 ns Iteration: 0 Region: /system/microblaze_0/microblaze_0/decode_i/prefetch_buffer_i/using_fpga/prefetch_buffers__0/srl16e_i # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.srl16e(srl16e_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.muxcy_l(muxcy_l_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.xorcy(xorcy_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fds(fds_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fdr(fdr_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.lut4(lut4_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.lut3(lut3_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fdrse(fdrse_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fdre(fdre_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fdse(fdse_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.data_flow(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.register_file(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.register_file_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.ram32x1d(ram32x1d_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.operand_select(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.operand_select_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.muxf5(muxf5_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fde(fde_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.lut2(lut2_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.alu(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.alu_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.mult_and(mult_and_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.shift_logic_module(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.shift_logic_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.mul_unit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.mult18x18s(mult18x18s_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.result_mux(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.result_mux_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.fd(fd_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.zero_detect(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.msr_reg(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.msr_reg_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.pc_module(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.pc_bit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.byte_doublet_handle(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.data_read_steering(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.mux4_8(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.mux2_8(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.dopb_interface(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.muxcy(muxcy_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.opb_data_mux(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.iopb_interface(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.debug(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.address_hit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.address_data_hit(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.fsl_module(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/microblaze_v4_00_a/.instr_mux(imp) # Loading work.mb_opb_wrapper(structure) # Loading c:\Modeltech_6.1a\win32/../ieee.std_logic_signed(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/proc_utils_v1_00_a/.conv_funs_pkg(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.opb_arb_pkg(body) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_v20_v1_10_c/.opb_v20(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.srl16(srl16_v) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.or_gate(imp) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.opb_arbiter(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.opb_arbiter_core(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.watchdog_timer(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.control_register_logic(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.priority_register_logic(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.priority_reg(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.arbitration_logic(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/opb_arbiter_v1_02_e/.park_lock_logic(implementation) # Loading Z:/simlib/EDK7.1.2_mti_se_nt/EDK_Lib/proc_common_v2_00_a/.or_bits(implementation) # ** Fatal: INTERNAL ERROR in reset_trigger_process(). # Time: 0 ns Iteration: 0 Process: /system/mb_opb/mb_opb/opb_arbiter_i/opb_arbiter_core_i/multi_master_gen/park_lock_i/grant_gen__1/reggrnt_gen/reggrnt_process File: C:/EDK/hw/XilinxProcessorIPLib/pcores/opb_arbiter_v1_02_e/hdl/vhdl/park_lock_logic.vhd # FATAL ERROR while loading design # Error loading designArticle: 88848
More likely the programmers have to learn how to think parallel.. then write a compiler that thinks parallel.. then learn to write games parallel.... stuff hardware guys have done for years.. but not your normal programmers vision But the possibilities are good.. and the processor is cheap... :-) I think it will catch on.. to a point where PC games will suffer... but it will start to infect PC's soon enough Simon "JJ" <johnjakson@yahoo.com> wrote in message news:1125315898.748183.133480@o13g2000cwo.googlegroups.com... > > Simon Peacock wrote: > > well its an interesting follow on... the more cores.. the better the > > floating point.. I think that's the aim here... but I'm surprised no one has > > mentioned the cell... it has 9 processors on board. > > > > Simon > > > > > Well I will see the Cell architects at CPA2005. They will describe the > Cell communications architecture to a group of people most interested > in parallelism and some might be esp interested in FP performance too. > > My own view is the Cell is one way forward but not the way I would > prefer. Its really one magnificent core surrounded by 8 lesser slaves > (as much as I know). The gaming world may have a much harder time > exploiting those slaves than IBM might wish, but then that would be > true for almost any multi processor, I still remember driving (game) > cars into and out of walls, their physics isn't all that good. > > In the end, I think the memory model comes 1st, the FPU and the rest > follows on. > > John >Article: 88849
Does anyone know of another FPGA (other than Virtex series from Xilinx) that has an embedded processor comparable to the PowerPC 405 as well as 3Gbps Serdes?
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