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
I was just wondering if also other peoples in this group get private mails from Aman Mediratta, asking for technical support with EDK, etc. For me it looks like he is mass-mailing his support-questions. Also a way to get support... I would call it "support-spam". (I tried to shortly explain him that there are newsgroups for this yesterday, just to get another mail today). ThomasArticle: 88776
"Thomas Entner" <aon.912710880@aon.at> schrieb im Newsbeitrag news:4311c25c$0$27166$91cee783@newsreader01.highway.telekom.at... > I was just wondering if also other peoples in this group get private mails > from Aman Mediratta, asking for technical support with EDK, etc. For me it Me too ;-) > looks like he is mass-mailing his support-questions. Also a way to get > support... I would call it "support-spam". (I tried to shortly explain him > that there are newsgroups for this yesterday, just to get another mail > today). The road to wisdom is long and full of stones. Regards FalkArticle: 88777
>>I was just wondering if also other peoples in this group get private mails >>from Aman Mediratta yep, me too.Article: 88778
Thanks, I'll train my spam-filter ;-) Thomas www.entner-electronics.com "Falk Brunner" <Falk.Brunner@gmx.de> schrieb im Newsbeitrag news:3ne289F13ae5U1@individual.net... > > "Thomas Entner" <aon.912710880@aon.at> schrieb im Newsbeitrag > news:4311c25c$0$27166$91cee783@newsreader01.highway.telekom.at... >> I was just wondering if also other peoples in this group get private >> mails >> from Aman Mediratta, asking for technical support with EDK, etc. For me >> it > > Me too ;-) > >> looks like he is mass-mailing his support-questions. Also a way to get >> support... I would call it "support-spam". (I tried to shortly explain >> him >> that there are newsgroups for this yesterday, just to get another mail >> today). > > The road to wisdom is long and full of stones. > > Regards > Falk > >Article: 88779
Thomas, I was wondering about that. I call it the "student surprise" issue. The student suddenly realizes they have to do work, and then go about trying to find out how to get it done. This is my standard reply: "Aman, Specifically, you need to join the university support forum: http://www.xilinx.com/univ/profsupport.htm This page is for university and school students, and their questions. It is a separate and complete support system. http://toolbox.xilinx.com/cgi-bin/forum is a list of useful forums we sponsor, and newsgroups that might be helpful. Although it mentions comp.arch.fpga, I suspect you will get better help from one of the targeted forums (embedded processors looks appropriate). The questions you are asking are all typical of systems archectecture. To architect a system, one has to balance all of the advatages and disadvantages of each architecture, and strike the balance that satisfies the requirements. In fact, you should devote time, energy, and document the process of architecting the system for your advisors in your report or thesis. It is a valuable part of demonstrating that you can actually engineer something in the future. These things may be answered in part for you, but you will have to do the real work of assembling the alternatives (on paper) and evaluating the pros and cons, and then making the choices, and then doing the work. You have some idea what is involved (ie DLL's), but you have not mapped out all the potential solutions. The forums may provide you with others who have DLLs, or have done what you want to do already. In very general terms, if the solution can be directly mapped to the logic of the FPGA, that is always the simplest and most direct solution. The 405PPC is useful when you don't have room for the logic (some runs slow, and can be mapped to the processor - in effect the reverse of C to gates, gates back to C). The "ultracontroller" is an IP core we provide which is very good for this, as you need no operating system, or bus structure, or in fact, anything at all to just run some C code and provide solutions for your problems. http://www.xilinx.com/bvdocs/appnotes/xapp672.pdf Good luck, Austin" You have my permission to notify any student that there is a whol eother world of support out there, designed just for them, and then mark them as spam, and continue with your own work. The nect generationn of Xilinx FPGA users is important to us for the future, but folks on this newsgroup are important to us RIGHT NOW for the designs they are doing. Thanks for letting us all know we have a more creative than usual student out there... Austin Thomas Entner wrote: > I was just wondering if also other peoples in this group get private mails > from Aman Mediratta, asking for technical support with EDK, etc. For me it > looks like he is mass-mailing his support-questions. Also a way to get > support... I would call it "support-spam". (I tried to shortly explain him > that there are newsgroups for this yesterday, just to get another mail > today). > > Thomas > >Article: 88780
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. Thanks, Andrew.Article: 88781
robin.bruce@gmail.com wrote: > Regarding x86 vs FPGA for double-precision floating-point arithmetic: > > Good points about the relative performances, but you need to look at > more than the peak FLOPs/s to do a comparison between the > architectures. Non-trivial double precision algorithms running on > microprocessors can use anything between 5 and 90 % of their peak > FLOPs/s. Floating-point algorithms are typically memory bound for > microprocessors. FPGAs on the other hand are typically bound by peak > FLOPs/s. FPGAs are able to significantly outperform modern > microprocessors on memory bandwidth sensitive double precision > operations. Microprocessors still beat FPGAs for non-memory bound > operations because they have higher peak FLOPs/s, but this situation > won't last. Peak FLOPs/s for FPGAs are set to exceed those of uP's in > the not too distant future. To chase the increases in peak FLOPs/s on > microprocessors you need ever more complex memory hierarchies, while in > FPGAs it looks like it will be some time before such techniques will be > needed to get the most out of the floating-point units. Some thoughts I think that both FPGAs and Multi cpus could go through some serious evolution and end up much closer to the same spot. FPGAs will obviously get some FPU capability sooner or later and be able to cross over current single threaded cpus but maybe one day high end cpus will get some FPGA capability too (inside not outside, but at 1/10th the clock or so). Single cpus will give way to Multis, ever so slowly programmers are going to learn to deal with concurrency, many will need a big wallop to the head before they get a real clue. We have already been there (transputers, occam ->HandelC there is a large body of knowledge on how to do parallel SW well but most choose to ignore it). Now if cpu guys really get moving away from x86 backwards compatibility, we could see much more massive reduction in complexity of cpus which immediately makes space for many more simple cores which would put them far ahead again of FPGAs in FP. But the world is addicted to x86 compatibility (for no good reason IMHO) except of course in the embedded space where FPGAs are, so this will remain the domain of Clearspeed and a few other massive cpu-count on a chip vendors. If two guys sharing an apartment, one at say I/A/I, one at say A/X had a clean sheet to design new massively multi cpu on a chip and again for FPGA with cpu components like FPU, we would end up in a more similar place. Both will be memory IO bound since either can use the same near 1000 pin packages. Cpus though have traditionally used el cheapo junk DRAM with massive SRAM caches to make up for the low speed, turning 100ns into 1ns BUT only for highly localised codes. Use a semi random no to index large array bigger than L2 and fastest cpu in the world reduces to a few Mips. FPGA guys such as Ray and many others here are far more familiar with space time trade off, some times less is really more if you can go serial faster, and far easier to P/R. This leads to use of exotic memories where needed, if you want more memory IO to speed up the application, we have RLDRAM, FCDRAM, QDR SRAM with orders more useful bandwidth than SDRAM with effective issue rates closer to the cpu L2 SRAM caches (ie 2.5ns RLDRAM). I think if X or A were seriously going to put significant nos of FPUs in the fabric, also put in ready to use memory controllers that can match the speed of these memories. Right now RLDRAM moves at 400MHz but FPGAs can only drive them at 300MHz and next year Micron promises 533MHz sub 2ns issue rates. Rambus too has amazing IO rates but useless latencies. It would be neat to see an FPGA actually drive the fastest memories out there while watching cpus miss their TLBs and pass through the OS and DRAM to get data. If you combine these memories with ready to use highest speed mem interface and FPUs in fabric in quantity to make up for clock speed, then things get interesting. An FPGA will limit density of FPUs to something like 1 every 4 BlockRams or 4 18.18 muls. On the cpu side, a cluster of cpus will be limited to the relative cost of FPU v whole superscaler+cache+TLB+ stuff. If cpus continue to use the current model of shared cache models they will lose the race eventually and deservedly so even with a 10x clock speed advantage. If cpu designers also look more deeply at using high issue rate DRAMs (<3ns) with multi threading to hide the relatively small left over latency (20ns and falling), then cpus will likely get the upper hand, but I don't see such a radical change there. I will be presenting such a processor (Transputer) design though at cpa2005 in a few weeks. If I could influence FPU development, I might suggest a more humble approach, build a std double capable IEEE unit around a single 18b mul and do it serially, clocks don't matter, wires do. Most of the cost is in the mul array, it can be used for both int or real use. The controller logic to do this in FPGA fabric eats up resources no end but a slow but steady serial FP controller might not use so much logic. Anyway as hard logic its no doubt 20x smaller and can be disabled out. Now if every 18.18 mul is 20% more expensive and can be enabled as a serial real math unit thats very valuable on a fine grain and if there were upto 500 of them they can be ganged more practically in the time line than space area. I would hate to have to deal with P/R for a real 64 bit engine that would be available in the wrong place. just my 2 bits johnjakson at usa ... transputer2 at yahoo ...Article: 88782
In article <desmbt$i07$1$8302bc10@news.demon.co.uk>,
Andrew Holme <andrew@nospam.com> wrote:
[...]
>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.
If you have other signals running through the CPLD, part of the problem
could be crosstalk. Power supply noise will also show up as a jitter.
There seems to be a bad solder joint in the upper left corner.
Check the LM78M05 for oscillations. We don't see the traces hooking up the
bypasses on it.
You also have to be careful when making things like flip-flop phase
comparitors inside the MAX series. When I made one, I had to add some
extra logic after the flip-flops so that the "both" state of the flip-flop
pair was used to gate off the output. I think the CLRN timing was the
problem bit once I got it working, I stopped looking for the root cause.
IIRC:
BothLatch = (UpFlipFlop # DownFlipFlop) & BothLatch
# UpFlipFlop & DownFlipFlop;
Up = UpFlipFlop & !DownFlipFlop & !BothLatch;
>
>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.
>
>Thanks,
>Andrew.
>
>
--
--
kensmith@rahul.net forging knowledge
Article: 88783Me too... "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:3ne289F13ae5U1@individual.net... > > "Thomas Entner" <aon.912710880@aon.at> schrieb im Newsbeitrag > news:4311c25c$0$27166$91cee783@newsreader01.highway.telekom.at... >> I was just wondering if also other peoples in this group get private >> mails >> from Aman Mediratta, asking for technical support with EDK, etc. For me >> it > > Me too ;-) > >> looks like he is mass-mailing his support-questions. Also a way to get >> support... I would call it "support-spam". (I tried to shortly explain >> him >> that there are newsgroups for this yesterday, just to get another mail >> today). > > The road to wisdom is long and full of stones. > > Regards > Falk > >Article: 88784
On 25 Aug 2005 10:27:17 -0700, "dlharmon" <harmon.darrell@gmail.com> wrote: >+<CMOS wrote: >+<> im looking for some advice/information on how to interface spartan3 >+<> FPGA with TTL and CMOS chips. >+<> does anybody know any ways to solder CLCC (CMOS image sensor ) at home? >+<> >+<> >+<> Thank you >+< >+<As far as interfacing chips goes, just make sure the bank voltage >+<matches the IO standard you want to use. Take a look at the datasheet >+<for what the FPGA supports. You will most likely be using LVCMOS33 for >+<most of your IO. The spartan 3 does not have 5V tolerant IO, so if you >+<have any 5V logic, you will need translators. >+< >+<To solder the CLCC, you probably can just use your iron and a lot of >+<flux. I like this method better than using a toaster oven since you can >+<add parts one at a time and test. See >+<http://dlharmon.com/solder/smd.html I only use a toaster oven for BGA. >+< >+<Darrell Harmon ******* I have had very good sucess with SMD soldering using a 4 inch square hot plate. Set it for about 225 C, I also had the advantage of having 3 inch square alumina ceramic substrate material to set on the hot plate to aid in sliding the pcb off. jamesArticle: 88785
Hallo,
I have made a small microcontroller based on microblaze.
I have copied into lmb bram a bootloader which copies my software into
external ram and then points to that address.
Here the bootloader code:
#define ADDRREAD 0x1
int main (void) {
int (*func_pointer) ();
prom_read(ADDRREAD);
func_pointer = XPAR_SRAM_256KX32_MEM0_BASEADDR;
func_pointer();
return 0;
}
After doing this, the memory location where bootlader is, will be cancelled
automatically and used for other instructions/datas?
Many Thanks
Marco
Article: 88786And me too. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Thomas Entner" <aon.912710880@aon.at> wrote in message news:4311c25c$0$27166$91cee783@newsreader01.highway.telekom.at... >I was just wondering if also other peoples in this group get private mails >from Aman Mediratta, asking for technical support with EDK, etc. For me it >looks like he is mass-mailing his support-questions. Also a way to get >support... I would call it "support-spam". (I tried to shortly explain him >that there are newsgroups for this yesterday, just to get another mail >today). > > Thomas >Article: 88787
>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.... Can you measure the raw oscillator output? It may not be as good as you expect. Many low volume oscillators now use a PLL. They program the dividers rather than grind the crystal to get custom frequencies. I'd expect that numbers like 10 MHz would have enough volume so that they would avoid the PLL but maybe it's cheaper to have one production setup and use it for the common frequencies too. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 88788
I would suggest inserting a 100 ohm resistor between C3 and C7 and placing a 100uF capacitor in parallel with C7. The noise on the output of U4 is just as critical as the noise on the + input of U3. You may also want to add an RC filter on the output of U5 before feeding it to U6. Daniel Lang "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. > > Thanks, > Andrew. > >Article: 88789
On 28 Aug 2005 08:54:43 -0700, "JJ" <johnjakson@yahoo.com> wrote: >Now if cpu guys really get moving away from x86 backwards >compatibility, we could see much more massive reduction in complexity >of cpus which immediately makes space for many more simple cores which >would put them far ahead again of FPGAs in FP. But the world is >addicted to x86 compatibility (for no good reason IMHO) except of >course in the embedded space where FPGAs are, so this will remain the >domain of Clearspeed and a few other massive cpu-count on a chip >vendors. Actually I don't think this is an issue anymore. These days the ISA management is really a small portion of a CPU implementation. Take a look at the following picture http://www.chip-architect.com/news/Opteron_Instr_Cache.jpg and decide for yourself how much area you would save if you replaced the x64 decoder with a mips 64 style decoder. The rest of the die is mostly cache and integer and fp alus which you'd need anywhere.Article: 88790
On Sun, 28 Aug 2005 15:55:42 +0200, "Thomas Entner" <aon.912710880@aon.at> wrote:
>I was just wondering if also other peoples in this group get private mails
>from Aman Mediratta, asking for technical support with EDK, etc. For me it
>looks like he is mass-mailing his support-questions. Also a way to get
>support... I would call it "support-spam". (I tried to shortly explain him
>that there are newsgroups for this yesterday, just to get another mail
>today).
>
>Thomas
I get these ALL the time. Often these newbies don't even know about usenet
and news groups. I direct them to this page:
http://www.fpga-faq.org/FAQ_Posting.htm
===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
Article: 88791mk wrote: > On 28 Aug 2005 08:54:43 -0700, "JJ" <johnjakson@yahoo.com> wrote: > > >Now if cpu guys really get moving away from x86 backwards > >compatibility, we could see much more massive reduction in complexity > >of cpus which immediately makes space for many more simple cores which > >would put them far ahead again of FPGAs in FP. But the world is > >addicted to x86 compatibility (for no good reason IMHO) except of > >course in the embedded space where FPGAs are, so this will remain the > >domain of Clearspeed and a few other massive cpu-count on a chip > >vendors. > > Actually I don't think this is an issue anymore. These days the ISA > management is really a small portion of a CPU implementation. Take a > look at the following picture > http://www.chip-architect.com/news/Opteron_Instr_Cache.jpg and decide > for yourself how much area you would save if you replaced the x64 > decoder with a mips 64 style decoder. The rest of the die is mostly > cache and integer and fp alus which you'd need anywhere. While the significance of any ISA implementation starts to shrink in comparison to the caches, that is exactly the point I was making. The caches are the way to make huge slow memory seem faster through ever more complexity in the cpu design though every comp arch trick in the book. In the end you only get 1 or 2 cpus for now (at 2-3GHz though) hanging on to the caches coat tails. Notice the Itanium is also almost entirely cache too and thats why it is also lower cost than most would expect since the SRAM is repairable while cpus are not. Again if you build single threaded architectures (any ISA will do), you end up with something like an Opteron/G5 cache hierarchy. If you go to highly threaded cpus and matching highly interleaved memory architectures, the threading on both side allows the latencies to more or less match for very much simpler cpu designs. In effect DRAM can replace cache as long as the issue rate compares with L2 access rates and it now does with RLDRAM and as long as the latency hiding is in the same ballpark as the reduced DRAM latency. In return you can use lots of small latency hiding cpus but one must now deal with lots of threads something that some people know what to do with. johnjakson at usa ..Article: 88792
Why doesn't Xininx include a simple programmable bus manager like Mr. Moore's 25X for fabrication efficiency or application development? a reference url, http://groups.google.com/group/comp.arch/msg/414981c0fe44fe89?dmode=source&hl=en mawArticle: 88793
Hello Andrew, > 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. ... Check its data sheet. If it doesn't have any noise specs on there get a better one. Or better yet, roll your own. CTS is a good source though. > http://www.holmea.demon.co.uk/Frac2/Main.htm How are the Altera GND pins connected to the plane? I can't see any connections. If that is via traces that's the first easy thing to fix. Look at your VCC. Switch the scope to AC and crank it way up. When called out to clients that is were I found the main contributors for phase noise. Video line sync, RAM banking spikes, whatever, it all ended up adding a little AM modulation to the logic output stages which in turn causes jitter. Sometimes others thought now I'd gone crazy: It often helps to take a very good comm receiver, put on tight fitting headphones and listen to your signals. Both sidebands plus wide open w/o IF filter. Often that revealed the tiny telltale "weeeee" or "rat-tat-tat". A spectrum analyzer on the pins and also on VCC can help as well. Then there is the usual, such as 0.01uF caps tightly fitted from VCC pins (all of them) to the ground plane. Also, check what else is happening in the FPGA. As Ken wrote this could cause crosstalk, especially if other outputs are heavily loaded or must drive longer traces. Regards, Joerg http://www.analogconsultants.comArticle: 88794
Hi everyone, Sorry if this topic has come up before - I have read numerous threads on this newsgroups regarding this topic, however, I cannot seem to piece together a straight answer. Basically, I would like to boot up my NIOS processor from an EPCS device upon powerup. Since my current board doesn't have any parallel flash, I thought adding an SPI flash onto extra pins could be done instead, provided I wrote some custom code to bootload from that. Then I learnt that their EPCS devices are the same thing as the ST micro Flash devices :) So now, my question is, I have a 64Mbit flash device from STMicro. Can I use this too bootload my FPGA and NIOS processor?? I have read some application notes, particularly: http://www.altera.com/end-markets/refdesigns/sys-sol/indust_mil/ref-asmi.html And this seems great and all, however, I can only select EPCS1 and 4 from SOPC builder in the ASMI interface. Any easy way to do this?Article: 88795
Andrew,
>
> Does anyone know what sort of performance can be expected
> from a CPLD in this regard?
>
Asides from the supply/clocking suggestions already made,
I'd also add the following caution: the output stages of most
programmable digital parts are not intended for producing
clean reference signals to a PLL used for low-noise RF signal
generation.
A few times over the years that I've considered doing this,
the first thing I've done is build something like a pulse output
divide-by-ten in the intended technology, driven the part with an
oscillator having known phase noise, and looked at the divider output
on both a spectrum analyzer & phase noise measurement system.
Most of the programmable parts I've measured have had output spurs
50-60 db down that vary strongly in frequency with supply voltage,
and can cross over the intended output frequency, making it impossible
to keep them out of the loop BW. ( also, the crud in the output
spectrum will generally behave differently with an even duty cycle
output than for a pulse output divider )
other (hastily conceived) random thoughts:
- what's the noise floor of your spectrum analyzer at 1 KHz?
- try using a surplus ocxo for your 10 MHz source
- if you disable the uC/SRAM, and implement a fixed divide entirely
internal to the CPLD, does the noise get any better?
have fun,
Brian
Article: 88796On 28 Aug 2005 16:49:15 -0700, "JJ" <johnjakson@yahoo.com> wrote: >Again if you build single threaded architectures (any ISA will do), you >end up with something like an Opteron/G5 cache hierarchy. If you go to >highly threaded cpus and matching highly interleaved memory >architectures, the threading on both side allows the latencies to more >or less match for very much simpler cpu designs. In effect DRAM can >replace cache as long as the issue rate compares with L2 access rates >and it now does with RLDRAM and as long as the latency hiding is in the >same ballpark as the reduced DRAM latency. In return you can use lots >of small latency hiding cpus but one must now deal with lots of threads >something that some people know what to do with. > the problem with highly threaded cpus is that they are not very good at running wordprocessors, spreadsheets and fpga p&r tools and that's where most cpus are used so the two cpu developers put most of their money into developing slightly threaded architectures with full multi-cores instead of smt. if you noticed the new multi-core i86 implementations don't support ht anymore. another reason this idea is not very easy to implement is that regardless what's happening with power on 90nm and lower processes, speed still counts and embedding dram on a high speed logic process is a big problem. if and when a new memory structure comes out which can be embedded in logic process and as inexpensive as 1t+1c dram, i am sure isa architects will look at highly threaded cpus again but probably not before then. also keep in mind that developing cpus is a very expensive endevour and anyone who is not developing an x86 compatible one seems to be giving up including intel. i expect sun will drop sparc pretty soon and intel will drop itanium too; moving their itanium developers to xeon projects doesn't bode too well which is for the better as we won't have to deal with a completely proprietary, fully moated with patents isa.Article: 88797
does any one know where to find some example projects for spartan 3 starter board for digilent. CMOSArticle: 88798
Hi,
I have been trying to debugg a simple "hello world" program running in
an Altera Cyclone device with Nios 32 (including OCI-Core) via JTAG. I
can use serial comms for the upload but I need the serial
communications available during execution. The problem is that the JTAG
upload gives me the following error:
# 2005.08.29 13:34:24 (*) nios-init-mdi -i
WARNING: Do not attempt to use Quartus to re-program your device while
GDB/Insight is connected. (See nios_readme.txt for details.)
# 2005.08.29 13:34:24 (*) nios-gdb-server --ocibase=0x00100000
--tcpport=2342&
# 2005.08.29 13:34:24 (*) downloading m.out (please be patient)
# 2005.08.29 13:34:24 (*) nios-elf-gdb --command=/tmp/m_setup.gdb
# [nios-gdb-server] nios-gdb-server starting up
# [nios-gdb-server] accepting gdb connection
# [nios-gdb-server] connecting to OCI, ocibase 0x00100000
# [nios-gdb-server] ...using ByteBlaster (altlpt1)
# [nios-gdb-server] mdi error: found 0 devices instead of 1
# [nios-gdb-server] failed to connect
Any ideas why my ByteBlaster is not connecting? I have no problem using
the same LPT1 connection for uploading .sof files using the Quartus II
"Programmer" tool.
Thank you very much in advance.
/evan
Article: 88799mk wrote: > the problem with highly threaded cpus is that they are not very good > at running wordprocessors, spreadsheets and fpga p&r tools and that's > where most cpus are used Actually, that's rather to generous to us fpga p&r users. If instead you do take a minute to look at the kind of benchmarks that are always put forward to test the latest iteration of x86, you'd find predominately parallel friendly workloads (eg. anything "multimedia" and to a moderately degree games). Spreadsheets are inherently not parallel hostile and performance of wordprocessors are not really an issue. I believe John's point was that the x86, RISC, and all the rest of the inheriently sequential architectures will never scale and we should abandon them. It's an old war cry that we've been hearing on and off for decades, but recent Hotchips 17, not least David Kirk's keynote, really felt like the wind of change. Power efficiency has become a mainstream concept and it will slowly but surely require us to change our ways. Back in the real world, John, people have sizable investments in existing (x86) software which aren't going away anytime soon, but the change is coming: on-chip multi cores, Cell, xbox-360, Niagria. Eh, isn't this the "Not enough parallelism in programming" on comp.arch? What has this got to do with "Best FPGA for floating point performance" :-) Tommy
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