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
Jan Panteltje wrote: > On a sunny day (17 May 2006 11:17:54 -0700) it happened "JJ" > <johnjakson@gmail.com> wrote in > <1147889874.095362.247580@y43g2000cwc.googlegroups.com>: > > >>Still my money is on parallel slower cpus too, but what else would a >>Transputer person say. > > > AMD came out with four core today. .. and for the OP worrying about poor DSP speed, this today from freescale : http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=271356 One of these could allow a design to click-down a V5 size :) On the V5 price scale, this is tolerable.... 10.5MBytes of included RAM solves one big problem, and 4 cores, 1GHz each sound usefull. I think they say ( almost as an afterthought) they have two PowerQUICC cores ? -jgArticle: 102576
This is what I wrote 15 yars ago, and it still applies: "..Note that there can never be a decoding glitch when only one select (address) input changes. (Even a non-overlapping decoder cannot generate a glitch problem, since the node capacitance will retain the previous logic level until the new pass gate is activated a fraction of a nanosecond later) When more than one input changes "simultaneously", the user must analyze the logic output for any possible intermediate address code permutation. If any of them would produce a different output, the user must assume that a glitch might occur. If all of the possible address variations produce the identical output, then the user can be sure that there will be no glich at the output. The designers of synchronous systems generally do not worry about such glitches, since synchronous designs are inherently immune to data glitches, except on clocks and asynchronous Set or reset inputs." I hope this helps Peter Alfke, 15 years later still at Xilinx...Article: 102577
Jan Panteltje wrote: > On a sunny day (17 May 2006 11:17:54 -0700) it happened "JJ" > <johnjakson@gmail.com> wrote in > <1147889874.095362.247580@y43g2000cwc.googlegroups.com>: > > >Still my money is on parallel slower cpus too, but what else would a > >Transputer person say. > > AMD came out with four core today. Yes indeed, just wonder when the x86 folks are going to say a word about || programming the the darn thing. After 2 x86 cores, I suspect most end users are not going to be running enough apps to make any real difference and the folks that will be able to use bigger n multi cores are not enough to justify the push to much higher n cores. A Transputer PE uses 1 BlockRam & 500 odd Luts/FFs and delivers about 100 32b mips using a 300MHz clock. The largest FPGAs can hold >500 BlockRams and perhaps 200 functional PEs leaving the rest for MMUs, would get pretty hot I imagine. But darn, not enough I/Os to make it work. I am glad to see V5 now has 400MHz DDR I/Os for full RLDRAM2 performance, perhaps V6 will keep up with the next bump to 533MHz for RLDRAM3. Ultimately, both FPGAs and massively parallel cpu core arrays are going to end up in the same place, I/O starved at about the same I/O pin frequencies with free computing on the inside either fine, medium or course grained. FPGAs already have tools to manage fine grained concurrency, Transputers used to, and the latter who knows when. John Jakson transputer guyArticle: 102578
Hi John, Thanks for your answer. I think I'll be soon a raggedstone user :-) X.Article: 102579
>> why not just using an existing link layer chip from Philips (if they >> still exist) or TI? > > AFAIR there is only one (very old) chip (TI TSB something) that has > firewire and can connect to an FPGA ... all the others have PCI or PCIe just had a quick look at http://www.semiconductors.philips.com/products/connectivity/1394/index.html The Philips PDI1394L40 is still alive. This one is easily interfaced with an FPGA. We have been quite happy with it. It was also used in a few other commercial audio products, e.g. in Mark of the Unicorn's audio break-out boxes, along with a QuickLogic FPGA and an 8051. The advantage here is, that the chip can easily pass the isochronous data to the FPGA, so that the CPU does not need to handle these at all. This makes sure, that you won't need a lot of MIPS, as the CPU will only handle the asynchronous traffic. Best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felixArticle: 102580
Hi all, Just as the subject says I am looking at what is available besides Xilinx own cores. Basic requirements: Complex in/out Virtex-4 optimized At least 4 channels, 8 is desired (with resource sharing) Higher sample rate: 70 MHz complex Lower sample rate: 300 kHz max to 3 MHz min Thanks, /MikhailArticle: 102581
Kees van Reeuwijk wrote: > Austin Lesea <austin@xilinx.com> wrote: > > > Intel proposes a future with more than 200 x86 cores on one die, with a > > "communications fabric" and many memories. All on one die. Small > > software problem to be solved by the need to have it solved.... > > > > One attendee of the conference (not me!) quipped, "sounds like you are > > describing a FPGA..." > > > > Boy did the presenter get mad! To be ccompared to a lowly FPGA! He was > > spitting venom back at the attendee. "There is no comparison! FPGAs > > are fine grained, and this is not!" > > I'd say the guy has no clue about massive concurrency except in the x86 sense. I'd take the comparison as a complement not an insult. > > Sounds like if that is the only difference, the FPGA wins. Again. > > Except that there is no way to compile standard software to an FPGA, or > even to compile freshly created software in anything near a normal > programming langage. I hope you don't expect that the bulk of > C/C++/Java/C# programmers will learn VHDL or Verilog. > > Of course programming a 200-core x86 processor in C/C++/Java/C# is a > software engineering nighmare too, but with enough coding discipline > there is at least a slim chance that you can get a team of ordinary > programmers to produce working software for it. > > It is very hard to predict what a viable mainstream architecture will > look like in ten years, but unless a lot of work is done to create > better compilers for them, it surely isn't going to be an FPGA. I > wouldn't bet on the 200-core x86 either, but that's because I'm an > optimist. > > In an emergency, I would prefer a 10000-core Transputer to either of > them, even if it would mean resurrecting Occam, but I hope someone can > come up with something more imaginative. How about a hybrid of C++ subset with Verilog subset, ie a process as the object language where processes with interconnects look both like HDL module instance hierarchies (and can be synthesized to hardware) and also look like C classes with event driven ports and OO methods, data. It would need a runtime not much different than a event wheel simulatiuon engine some of which could be right in the cpu scheduler if its hosted on a Transputer. The real irony is that while the Transputer has been gone for what 10 years, a 200 node machine could probably be built in an FPGA right on the edge of thermal, memory issues but lots of smaller FPGAs give many more I/O pins and better heat spreading. The other thing I have been saying for some time is that the sequential cpu has a Memory Wall problem with maybe 1000 clocks per missed cache event while a modern latency hiding Transputer can have relatively SRAM memory like performance using RLDRAM. You replace the Memory Wall for a Thread Wall, not really a wall for CSP people. John Jakson transputer guyArticle: 102582
On a sunny day (Thu, 18 May 2006 07:54:53 +1200) it happened Jim Granville <no.spam@designtools.co.nz> wrote in <446b7f58@clear.net.nz>: >Jan Panteltje wrote: >> On a sunny day (17 May 2006 11:17:54 -0700) it happened "JJ" >> <johnjakson@gmail.com> wrote in >> <1147889874.095362.247580@y43g2000cwc.googlegroups.com>: >> >> >>>Still my money is on parallel slower cpus too, but what else would a >>>Transputer person say. >> >> >> AMD came out with four core today. > >.. and for the OP worrying about poor DSP speed, this today from freescale : > > >http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=271356 > > One of these could allow a design to click-down a V5 size :) >On the V5 price scale, this is tolerable.... > >10.5MBytes of included RAM solves one big problem, and 4 cores, 1GHz >each sound usefull. I think they say ( almost as an afterthought) they >have two PowerQUICC cores ? I am not sure, QUICC I, II, is there a 3? Extra security. The AMD announcement made me think about Sony Cell, if that still is worth it. I have studied the Cell a bit in depth, IBM uses it in servers, but it seems to me AMD is eating parts of the Cell intended market this way.... PowerQuiCC is a PowerPC based system? This AMD move may threaten that too. And Intel is dead already. Bit of-topic though (FPGA). 180$ is a bit much for a settop box processor, ASICS for H264 decoding exists and are coming on the market. Where will it go?Article: 102583
Hi Ed, thank you for your reply and setup suggestions. Unfortunately this only partly addresses my wishes. Just two (and a half) examples: 1) Think about a development board, that connects to a host PC via USB or Ethernet. It would be nice, if a vendor could supply a driver, and integrate the board with Impact. To do so, Impact would need to be able to talk to third party JTAG drivers. As board vendors cannot do this, every vendor is forced to provide his own configuration tool- which is really not the way things should look like. 2) When talking about pin toggling: I am not talking about a few toggle events, which I could do with a GUI. I am looking for an environment, where I can program complex toggle sequences. While I am happy to do the development of the required JTAG library myself, I would need to be able to access the JTAG cable easily. It would be nice to use the existing Xilinx cable- unfortunately the API is not disclosed. 3) Now think about a reason to combine both of the above setups without switching cable hardware, setting jumpers and changing flying leads... Ed, I do understand that this kind of applications is not your primary interest. Still, it does not always help here to try and teach the engineer to do it a different way, as there are probably good reasons, why the engineer wanted to do so. While a technology leader will definitely need to do some evangelism, it is sometimes a nice marketing approach to listen to the customer (even if it is a smaller one). Best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felix > The iMPACT software works with other devices in the chain by allowing > you to > specify a BSDL file for the device when it doesn't recognize it. The > iMPACT > software also allows you to generate arbitrary JTAG sequences in order > to do > anything that you want to do. If you want to generate a program to improve > your ability to do this then run iMPACT in batch/command line mode and have > your program control iMPACT. > > I would also suggest using a product like Universal Scan > (http://www.universalscan.com/) > I've not used it personally, but I did have a conversation with the > principal developer > a few years ago and it seems like a nice light weight tool to do exactly > what you > want to do. I think that it might be Windows only though. > > Or, if the pins that you want to toggle are from a Xilinx device, then I > would > suggest using ChipScope Pro with a VIO (Virtual I/O) core attached to > the pins for > an even simpler product and it includes FPGA configuration capabilities. > ChipScope Pro > does work on Linux. > > Ed McGettigan > -- > Xilinx Inc.Article: 102584
Felix Bertram wrote: > Regarding the future of FireWire: Have you noticed that Apple as one of > the biggest promoters does not seem to invest too much into the future > of FireWire, any longer? All Intel-based Macs only provide FireWire 400, > iPod does not support FireWire any longer. Maybe you should not invest > too much time and money into the bus interface. The new 17" MacBook Pro has FW800. I'd suspect that the replacement for the G5 PowerMacs will have FW800, too. I think Apple looked at what peripherals consumers typically use, and none have FW800 interfaces. Why add an extra interface that won't be used? On the other hand, professional video, audio and graphics people depend on FW800, which is why that interface is included on the "pro" models. -aArticle: 102585
See XAPP575, XAPP807, XAPP719, and XAPP571 for more information about UltraController-II and some of the underlying technology. However, the problem here is much simpler, i.e. a regular EDK design where the code is loaded into the PPC405 caches through proper setup of the linker script and the ACE options file (more details later today). - Peter Antti Lukats wrote: > "Jon Beniston" <jon@beniston.com> schrieb im Newsbeitrag > news:1147889273.909649.117060@i40g2000cwc.googlegroups.com... > >>Peter, >> >> >>>assuming that you are using System ACE CF to configure your Virtex-4 FX >> >>Yep. >> >> >>>can load the boot code directly into the processor caches >> >>Thanks sounds very interesting. Any pointers or app notes on how to do >>this? (Sorry if I'm overlooking the obvious) >> >>Cheers, >>Jon >> > > xil appnotes and ref designs > > pretty cool they use the USR ACCESS JTAG command to create virtual JTAG TAP > master that then connects to the PPC JTAG tap and uses PPC ICE registers to > load the caches. was pretty cool to see that implementation > > look at the ultracontroller II, the thing is all there > > antti > >Article: 102586
Jan Panteltje wrote: > AMD came out with four core today. I don't think so. If they had, it would be featured on their web site somewhere. What they did announce today is the Turion 64 X2 dual core mobile processor. Yesterday they announced energy efficient desktop processors (single and dual core).Article: 102587
On a sunny day (17 May 2006 14:30:35 -0700) it happened Eric Smith <eric@brouhaha.com> wrote in <qhk68kgwzo.fsf@ruckus.brouhaha.com>: >Jan Panteltje wrote: >> AMD came out with four core today. > >I don't think so. If they had, it would be featured on their web site >somewhere. > >What they did announce today is the Turion 64 X2 dual core mobile >processor. > >Yesterday they announced energy efficient desktop processors (single and >dual core). http://www.heise.de/newsticker/meldung/73197 Run it through a translater, it is in German/Article: 102588
Jan Panteltje <pNaonStpealmtje@yahoo.com> writes: > http://www.heise.de/newsticker/meldung/73197 I don't think that qualifies as "came out with". It's just a discussion of a future product. Intel has discussed their quad-core part too. But neither is actually announced.Article: 102589
HWGUI is a Verilog library which generates windows with captions on a VGA display. This uses no microprocessors; a state machine responds to user actions instead. The user interface has a PS/2 mouse input; the user may click any part of a window to bring it to the foreground and may drag windows around the screen. http://www.ccm.ece.vt.edu/~tbflemin/hwgui/hwgui.html An ISE 7.1 project file for the XUP-V2Pro is included.Article: 102590
On a sunny day (17 May 2006 14:44:54 -0700) it happened Eric Smith <eric@brouhaha.com> wrote in <qhmzdg2und.fsf@ruckus.brouhaha.com>: >Jan Panteltje <pNaonStpealmtje@yahoo.com> writes: >> http://www.heise.de/newsticker/meldung/73197 > >I don't think that qualifies as "came out with". It's just a discussion >of a future product. Intel has discussed their quad-core part too. But >neither is actually announced. This is exactly the point. The question is: What will be first in the shops here locally: V5 or AMD 4 core!!!!!!!!!!Article: 102591
Brad Smallridge wrote: > Does any one have any software (or experience) to share (or sell) concerning > bringing a USB2 camera image into a XILINX ML401, ML402, or ML403 board. Hi Brad, We (PetaLogix) have ported the Linux reference drivers for the Cypress chips to the ML40x boards - initially targetting MicroBlaze uClinux but they will work on PPC Linux as well. I have made some early investigations into webcam support for this board, there is a bit of work to be done but the basic Video4Linux layer (V4L) seems to work ok on MicroBlaze. Contact PetaLogix (info@petalogix.com) if you'd like to talk in more detail. Regards, JohnArticle: 102592
This looks cool! Do you have any slice / BRAM utilization info? StephenArticle: 102593
Ed McGettigan wrote: > The iMPACT software works with other devices in the chain by allowing you to > specify a BSDL file for the device when it doesn't recognize it. The iMPACT > software also allows you to generate arbitrary JTAG sequences in order to do > anything that you want to do. If you want to generate a program to improve > your ability to do this then run iMPACT in batch/command line mode and have > your program control iMPACT. Ed ... you missed the point. JTAG is "supposed" to be an open standard interface, usable for a large number of in system interfaces, and Xilinx is turnning it into another proprietay closed interface with VERY limited static sequences exported to the user. Consider that JTAG is the ideal port to introduce a source level debbugger interface into HLL reconfigurable computing netlists, which would require an open interface to plug a gdb/ddd backend onto. Having to create one JTAG chain for Xilinx tools, and one each for other vendors tools, and a separate one for your own debbuging tools is a total crock, and violation of what is "supposed" to be an open interface standard test port. Open source is not about "free", is about the ability to preserve the right and ability to take and modify the tools to do what you need/want, and not be stuck with the bugs and lack of features (because the vendor lacks the resources to do it right) that you need. Or because the vendor obsoleted the product, discontinued support, and orphaned your VERY EXPENSIVE hardware that is only a year or two old (read XC4085XL and XC40150XV reconfigurable computing boards). Xilinx may move rapidly in the market, but products built with Xilinx parts must be supportable for a reasonable life of 7-10 years or more. Current Xilinx polices which violate this sensibility are .... Open source is Xilinx's friend in this respect, and provides a user community supported path to pick up the pieces when Xilinx commits these gross errors in product life support from and OEM and End User perspective. > Or, if the pins that you want to toggle are from a Xilinx device, then I would > suggest using ChipScope Pro with a VIO (Virtual I/O) core attached to the pins for > an even simpler product and it includes FPGA configuration capabilities. ChipScope Pro > does work on Linux. Yet another proprietary expensive tool. Probably only supported on a proprietary platform (Redhat Enterprise). Linux support is not about proprietary RE, it's about supporting Fedora, SuSE, Debian, ubuntu, etc in an "open source" not "free proprietary" way. That can include proprietary binary applications, but properly maintaining open source interfaces and NOT locking other open interfaces like JTAG to also be proprietary in the process. I'm all for proprietary software and products which create pay checks for programmers, but when that is integrated with open source and open interface standards, it should be done in a sensible way that doesn't violate the openness of those standards. Proprietay JTAG interfaces, violates the openness of that standard.Article: 102594
Austin Lesea wrote: > If anyone wants to berate us for their FX experience on V4, please do > (we deserve it). Ok, you asked for it, so here goes: Tsk, tsk, tsk... how could you let Altera get ahead of you this way... ;-) Congrats on the new babies. They look good! Best regards, BenArticle: 102595
In article <e4fi31$etu1@cliff.xsj.xilinx.com>, Ed McGettigan wrote: > Laurent Pinchart wrote: > > That's not the only issue. The main problem is that the Jungo driver is a > > security hole by design: it gives applications access to PCI cards from > > user space without any security check, making it possible for any user to > > read from and write to any memory location. The people who designed such a > > piece of crap should be banned from using computers for the rest of their > > life. > > Can you please cite a reference that documents this issue in detail? And > as I originally requested is there any known exploit that takes advantage > of this, again I need a cite. I looked and I can't find anything other > than comments that are 4+ years old at this time. Sure. Give me access to a PCI bus master (say the IDE) device, and I can splat whatever data it contains (say a binary I compiled) into whatever portion of memory (say kernel address space) I want it to go. Oh, you need a "cite"... Well, if you're in the "know" and understand the implications, the following should make you cringe: http://www.cansecwest.com/speakers.html#duflot > If there is truly an issue here I will look into it further as my group > is one of licensees of Jungo drivers, but so far all I've seen is FUD for > "closed source" code. If I get userland access to poke into I/O or device memory, I will take over your machine. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 102596
Jan, V5 is in ES sampling, which means that the only way to get it is direct from your Xilinx FAE. But, I have checked, and all the parts announced are on the shelf here in San Jose, so supply is not the issue (LX50, LX85, LX110). And, parts had previously gone out to real customers in March, who actually had pcbs, and turned them on, and are using them. So that isn't a problem either (have pcbs, software, parts, and demo bitstreams even if you do not). If you wait for it to be on the shelf at your distributor, perhaps your competition isn't waiting.... Austin Jan Panteltje wrote: > On a sunny day (17 May 2006 14:44:54 -0700) it happened Eric Smith > <eric@brouhaha.com> wrote in <qhmzdg2und.fsf@ruckus.brouhaha.com>: > > >>Jan Panteltje <pNaonStpealmtje@yahoo.com> writes: >> >>>http://www.heise.de/newsticker/meldung/73197 >> >>I don't think that qualifies as "came out with". It's just a discussion >>of a future product. Intel has discussed their quad-core part too. But >>neither is actually announced. > > > This is exactly the point. > The question is: > What will be first in the shops here locally: > V5 or AMD 4 core!!!!!!!!!! >Article: 102597
Ben, Thanks. And, yes, it was painful to trip on V4 FX, but we still beat them with a gigabit transceiver for 90nm....just not by the six months we had intended to originally. Austin Ben Twijnstra wrote: > Austin Lesea wrote: > > >>If anyone wants to berate us for their FX experience on V4, please do >>(we deserve it). > > > Ok, you asked for it, so here goes: > > Tsk, tsk, tsk... how could you let Altera get ahead of you this way... > > ;-) > > Congrats on the new babies. They look good! > > Best regards, > > > BenArticle: 102598
Here is some information on how to get this done. This is tested on a
ML403 board. You might need to make changes for your environment but the
principle is the same.
1. Use Base System Builder and build a design with UartLite, System ACE
CF, and DDR memory. Include the BRAM, we'll use it initially.
2. Build the hardware.
3. Add a software project
- bootloader: the bootloader program that will run out of cache
4. Implement the bootloader (runs out of BRAM by default). Test it on
the board.
5. Now let's move the bootloader application into caches. For that we
create a new linker script with three memory regions:
MEMORY
{
icache : ORIGIN = 0x70000000, LENGTH = 16k - 4
boot : ORIGIN = 0x70003ffc, LENGTH = 4
dcache : ORIGIN = 0x78000000, LENGTH = 16k
}
Separate all the sections into those regions. At this time you have a
real Harvard architecture, i.e. you need to be careful about moving
instructions into the icache and data into the dcache. Rebuild the
bootloader application.
6. Set the XMD Debug Options. In the Advanced Options tab set the icache
to 0x70000000 and the dcache to 0x78000000. Save.
7. Download the bootloader application and run. It now runs out of caches.
The project is attached.
- Peter
.... sorry, no binaries in the archive ....
Article: 102599Thanks for all the responses. I just found out that Sundance DSP is coming out (2-3 months) with a TIM module with: =B7 Base Camera Link interface (video input) =B7 Composite video SDTV/HDTV input/output: YCrCb =B7 VGA (RGB, RGBHV analog output) =B7 DVI (analog and digital video output) =B7 RSL =B7 SHB =B7 Comports =B7 JTAG =B7 USB 2.0 =B7 FireWire (IEEE1394a) =B7 Fully integrated 10BASE-T/100BASE-TX/1000BASE-T Gigabit Ethernet This module will have an XC4VFX60. The Firewire is a separate chip (Texas Instruments TSB43Cx43A "iceLynx-Micro"). Tom
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