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
Hi Tom, why not just using an existing link layer chip from Philips (if they still exist) or TI? This should save you from quite some hassle. The whole concept could look like this: http://www.bertram-family.com/felix/fw_audio.html 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. Best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felix soar2morrow@yahoo.com schrieb: > I am interested in any FPGA cores that implement the IEEE-1394a > FireWire interface. The application is to process images from several > FireWire digital cameras in a hand gesture recognition system. Our > current plan is to dedicate a computer to this task, but it may only be > able to handle 3-4 cameras (we want to have as many as 8, meaning we > may need 3 computers). The actual processing is quite simple and could > be done by a single FPGA. > > So far I have found a core from Altera that does what I need, but I > would prefer a Xilinx core. Any ideas? > > Tom Seim > Pacific Northwest National Laboratory > Richland, WA >Article: 102526
Hi Ed, > It seems like you want to go to whole lot of effort to redo work that > already exists and ships for free. If so, then I guess everyone needs > a hobby to work on. it's good to see that Xilinx monitors this group- and the JTAG topic. When talking about JTAG and using it to configure FPGAs or CPLDs and programming PROMs, you are probably right: Impact is your friend. It will do what you want and there is no need to use any open source solution or program something on your own. BUT: Often my world does not look like this. I have setups that are mixed with chips from other manufacturers. I want to access all of them. I want to do some tests, toggle a few pins, see what happens. And now the pain begins, as I cannot. I cannot just write my own JTAG software, because I cannot access the Xilinx cable. Of course Xilinx is right from a revenue perspective. All these "odd" setups do not generate any revenue for Xilinx. So why should Xilinx support these applications? Because engineers do not want to use two different cables: One for the Xilinx flow, one for the more advanced problems. It is obvious from a technical perspective, that everything that is required is already there. So why should I buy another cable, just to be able to talk to the JTAG chain? This just does not make any sense. OK, still I understand that Xilinx is not really motivated to do so. Probably, the documentation of the cable API will lead to a support night-mare. But again, there are solutions to it. Why not do it the other way around (and keep your driver dongled with Impact)? This is what I would really like to see: - Create a properly documented API to talk to the driver. - Make Impact use this API. - Publish this API. - Allow vendors to integrate their JTAG cables/ solutions with Impact. This solution would probably make a lot of developers and vendors of development boards very happy. Including me. Best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felixArticle: 102527
>>1GHz multipliers would be very hard to >>use if the logic fabric and memories can't keep up in some problems with pipeline techniques, logic fabric can keep up For memories, i am sure u can design 2x faster memories >>do you have >>an application in mind that requires 1GHz multipliers Scientific computation >>The DSP48E is already pipelined. Obviously, adding extra (bypassable) >>pipeline stages within the multiplier would increase the maximum clock >>speed, but it also adds latency and silicon area, and increases power >>consumption. Everything's a tradeoff... Agreed >>Note that there are many enhancements in the DSP48E over the Virtex-4 DSP48 >>block, not the least of which being a larger multiplier (25x18). So a direct >>MHz-to-MHz comparison with the previous generation is not entirely fair. Agreed I am just noticing that moore law is not respected relative to dsp frequency and wanted to know the reason for this(is it technological problems, or strategic problems to satisfy the maximum number of customers) Cheers, ThomArticle: 102528
Hi, I am looking for a small bootloader (small because I'd like it to be in BRAM) that can load a PowerPC ELF file (possibly binary) from a CF card connected via a SystemACE controller and run it. Any recommendations? I've serached through the news group, and it seems like Antti wrote one for MicroBlaze, although the link to xilinx.openchip.org no longer seems to be valid. I've also had a look through xapp482.pdf, but I was hoping someone had already implemented this before :) Cheers, JonArticle: 102529
hi, me Antti yes I wrote some systemace loader that I tested on ML300 loooong time ago some derivate of that is still in use. wasnt very good one, the FAT support was really really minimal :( there should be no problems fitting into brams, but better look at the dosfs that is very small and support FAT pretty completly, changing the sector read for systemace should not be a problem antti I may be able to dig out some of my old code, buts its rather nastyArticle: 102530
We have released a new version of our ISE/WebPACK tutorial that is updated to version 8.1i: http://www.xess.com/appnotes/webpack-8_1-xsa.pdf .Article: 102531
Scope schrieb: > Hi ! > > I would know if , to your mind, it may be possible to implement a 16 bits > Analog-to-Digital Converter on a FPGA ( like a Spartan 3 for example ... ) > . > Any idea is welcome. Search the Xilinx Website for application notes. Or search the USPTO patent database for "Austin Lesea". Kolja SulimmaArticle: 102532
Tom, Moore's Law actually refers to transistor sizes, not clock frequencies. Interconnect delay at these deep submicron sizes has significantly reduced clock frequency scaling - just look at how Pentium frequencies have stopped increasing. Xilinx could significantly pipeline the multiplier to get a much higher clock rate, but, as mentioned previously, keeping it fed with data from the configurable fabric would be difficult at higher frequencies. MathStar has a field programmable array with 1GHz DSP performance, but it's not bit-level configurable. StephenArticle: 102533
I noticed that the CoolRunner (XPLA3) sets all of the pins (at least the ones I can monitor) high during in system programming. Is there a way (programming file) to hold the pins low during programming? Thanks, EliArticle: 102534
Scope <romaingoron@hotmail.fr> wrote: >Hi ! >I would know if , to your mind, it may be possible to implement a 16 bits >Analog-to-Digital Converter on a FPGA ( like a Spartan 3 for example ... ) >. >Any idea is welcome. What's the speed ..? Voltage levels ..? Cost ..? Complexity ..?Article: 102535
Hello,
Iam getting the following hold time violation in my design. Its happen on the
address inputs to a instantiated ram16x1d primitive. Source and desitnation
flipflops are in the same clock domain. There does not seem to be a clock skew
and iam using local clock resources for this clock.
--------------------------------------------------------------------------------
Hold Violations: TS_lp_clkin_p = PERIOD TIMEGRP "lp_clkin_p" 5 ns HIGH 50%;
--------------------------------------------------------------------------------
Hold Violation: -0.089ns (requirement - (clock path skew + uncertainty -
data path))
Source: lp_bus/rx/wr_addr_r[0] (FF)
Destination: lp_bus/rx/l1.2.r.SLICEM_G (RAM)
Requirement: 0.000ns
Data Path Delay: -0.089ns (Levels of Logic = 1)
Positive Clock Path Skew: 0.000ns
Source Clock: lp_bus/rx/lp_clk rising at 0.000ns
Destination Clock: lp_bus/rx/lp_clk rising at 5.000ns
Clock Uncertainty: 0.000ns
Timing Improvement Wizard
Data Path: lp_bus/rx/wr_addr_r[0] to lp_bus/rx/l1.2.r.SLICEM_G
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.313 lp_bus/rx/wr_addr_r[0]
net (fanout=10) e 0.100 lp_bus/rx/wr_addr_r(0)
Tah (-Th) 0.502 lp_bus/rx/l1.2.r.SLICEM_G
---------------------------- ---------------------------
Total -0.089ns (-0.189ns logic, 0.100ns route)
(212.4% logic, -112.4% route)
----------------------------------------------------------------------------------
According to their latest data sheet Tah = -0.29 ns.
But timing analyzer has it as Tah = 0.502 ( positive value)
I get same results on both ISE 7.1.04 and 8.1.03.
What am I missing? With a negative hold time, there should be no hold time
violations.
How do I update the timing models/data?
Thanks
Brijesh
Article: 102536
Stephen Craven schrieb:
> Tom,
>
> Moore's Law actually refers to transistor sizes, not clock frequencies.
> Interconnect delay at these deep submicron sizes has significantly
> reduced clock frequency scaling - just look at how Pentium frequencies
> have stopped increasing.
>
> Xilinx could significantly pipeline the multiplier to get a much higher
> clock rate, but, as mentioned previously, keeping it fed with data from
> the configurable fabric would be difficult at higher frequencies.
Guys, guys. Can you ever get enough? I guess no! :-(
First, clock frequency is not necessary processing power.
Second, 550 MHz isnt a piece of cake, even if there are a few other
fast(er) competitors.
Third, I think that all those fency Pentium/Athlon/Whatever CPUS are
heavy pipelined.
Fourth, blablablablablablablablablablablablablabla
And, Iam not a follower of those stock market philosophy of ever
(exponential) rising profit, or here in the electronic world ever
(exponential) rising processing power/clock frequency. This "law" was
suprisingly valid for a long time, it still can be fullfilled, even with
the great challenges of deep sub-micron technology. But there is an end
to all things.
Remember, the transfer function of a diode is also exponentional over
many decades, until it ends up in smoke.
Regards
Falk
P.S. Reminds me again of some old basic rules for programmers.
1st Your CPU ist always too slow.
2nd You have always too less RAM.
3rd The compiler is lousy.
Article: 102537Eli Hughes schrieb: > I noticed that the CoolRunner (XPLA3) sets all of the pins (at least the > ones I can monitor) high during in system programming. Is there a way > (programming file) to hold the pins low during programming? Those are weak pull-ups. Regards FalkArticle: 102538
All, A recent Intel presentation at an IEEE Workshop admitted that clock frequency has max'd out, and now has to go down (not up) in order to not create heat. We have known that for years now. So has AMD. The only choice is "multi." 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!" Sounds like if that is the only difference, the FPGA wins. Again. Oh, and I can't wait for Intel to stub their toes on that "communications fabric" (left as an exercise for the student). Or the software. I think that we are all dissapointed: no high K gate dielectric, so the supply voltage can't scale anymore, worsening variation in threshold voltages, because not only can you count the layers in the gate dielectric on your fingers, but you can count the ions that got implanted, too. Not only does the source-drain leak when off, but gates leak now (at 65nm and below). A new fab costing 2B$. No clear path for lithography. Good thing we make a standard product, and can afford to keep developing it. ASSP vendors will have to consolodate, and reduce their offerings. Real tough times ahead for some business models. Only place to get the latest IP will be from FPGA vendors.... The future is ~500 MHz, more stuff, and voltages slowly decreasing to 0.8 volts. But, we can still get twice as many transistors per unit area, all the way down to 22nm. And that increases thoughput and processing power. 45nm, 35nm, and then 22nm. Life in the old horse yet. 2B 6 input LUTs in V8? 100 Mb of BRAM? 2,000 DSP processors? Crystal ball is getting very hazy....Aunti Em! Aunti Em! She is holding her head! (apologies to the Wizard of Oz movie). After that, we really are looking for that disruptive technology with which we can make a new FPGA. Now if I could only get those unobtainium wafers to yield.... AustinArticle: 102539
On Wed, 17 May 2006 09:48:44 +0100, Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote: >rickman wrote: >> I don't know about stupid, but I didn't see the equations... :) I >> just used the stated feedback voltage and the resistor ratios to get my >> numbers. I don't know why your numbers are different from mine. What >> equations did you use? I used Vf * (R1+R2/R2), where R1 is the >> resistor that connects to the output voltage and R2 is the resistor >> that connects to ground. > >Ahhh, thanks to your persistence, I have spotted what I was missing. >Yes, indeed, there was a certain amount of stupidity involved, I'd be >the first to admit. The datasheet states a value of Vfb of 1.24V next >to equation 15. Foolishly, I used this, instead of 1.22V as stated >earlier in the datasheet (which I've only just noticed). I assume that >the 1.24V is the upper tolerance bound 1.22V+2% ~ 1.24V. I'm not quite >sure why, it seems a little arbitrary to me to pick one boundary for the >example calculation. Thoughts? > >-- Peter My first thought was a datasheet error, and there it is. Download the latest version of the datasheet. The equation has been corrected. http://focus.ti.com/lit/ds/sbvs052e/sbvs052e.pdf I remember a TI datasheet error for a voltage supervisor, where the timing capacitor equation produced a capacitance value of several Farads. I wish TI put revision histories in their documents. It would be nice to know what else changed... ================================ Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 102540
Jon Beniston wrote: > Hi, > > I am looking for a small bootloader (small because I'd like it to be in > BRAM) that can load a PowerPC ELF file (possibly binary) from a CF card > connected via a SystemACE controller and run it. Any recommendations? > It is fairly straightforward to use xilfatfs (shipped with EDK) to load a file from the CF into memory and transfer control to the loaded program. Just use open/read file library calls. /SivaArticle: 102541
>Guys, guys. Can you ever get enough?
I agree with the sentiment. Most of us aren't pushing the speed of
our devices. We use FPGAs for other reasons.
Of course, there are always "leading edge" applications that need the
highest performance, but it's a small part of the market and a
minority interest.
Unfortunately, speed is the usual news from manufacturers: "This will
run at 800MHz now and 950MHz by the end of next quarter...".
Yawn!
Maybe the speed freaks can form their own newsgroup ("FPGA
overclockers"?) Stand by for photos of water-cooled chips, lit with
blue LEDs.
Article: 102542Laurent 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. 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. Ed McGettigan -- Xilinx Inc.Article: 102543
Felix Bertram wrote: > BUT: Often my world does not look like this. I have setups that are > mixed with chips from other manufacturers. I want to access all of them. > I want to do some tests, toggle a few pins, see what happens. And now > the pain begins, as I cannot. 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: 102544
Hi Siva, Yep, but a bog standard implementation (i.e. just using the standard library code) is going to be 20kB+. I don't have that many block RAMs to play with, so want to create something as small as possible. Cheers, JonArticle: 102545
YiQi wrote: > the problem has solved by adding a extra clock cycle between 4 and 5, > but I still don't understand why that will work. Maybe need to wait > longer for sending the byte. If someone know, please tell me. anyway, > > > thanks Mike~! BTW - In the UARTs I've used (Z8530, 16c450) the UART sets TBE to a 1 when it can accept a byte to be transmitted. >..I still don't understand why that will work Without seeing your code it would be difficult to help you. -DaveArticle: 102546
Peter Alfke schrieb: > Let me explain one reason why distis are reluctant to break a standard > tray of ICs: but how do you think a new project might start? Usually we build something like 2-3 prototypes of one board and implement the design ... this is enough to demonstrate that it's working and we sell the design to someone manufacturing it ... I'm glad that it is not my job to phone the distris and beg for chips ... bye, MichaelArticle: 102547
Felix Bertram schrieb: > Hi Tom, > > 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 bye, MichaelArticle: 102548
Jon, assuming that you are using System ACE CF to configure your Virtex-4 FX device you can load the boot code directly into the processor caches which gives you 16KB of instruction and 16KB of data space. That's enough for the bootloader you describe and you do not even need a single BRAM. - Peter Jon Beniston wrote: > Hi Siva, > > Yep, but a bog standard implementation (i.e. just using the standard > library code) is going to be 20kB+. I don't have that many block RAMs > to play with, so want to create something as small as possible. > > Cheers, > Jon >Article: 102549
dosfs claims to be <4k but I havent checked it with mb-gcc or ppc-gcc antti "Jon Beniston" <jon@beniston.com> schrieb im Newsbeitrag news:1147883675.279132.26480@y43g2000cwc.googlegroups.com... > Hi Siva, > > Yep, but a bog standard implementation (i.e. just using the standard > library code) is going to be 20kB+. I don't have that many block RAMs > to play with, so want to create something as small as possible. > > Cheers, > Jon >
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