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
Hal, Here's my best guess for why an anti-fuse FPGA could have lower dynamic power (I don't know if this is the case): If I recall correctly, anti-fuse FPGAs can do some forms of switching with direct metal-to-metal connection through anti-fuse vias. In an SRAM FPGA, all switching must be done through SRAM-controlled multiplexors & buffers. The additional switches in a given route increase the C and (maybe) add more crow-bar current during switching. Also, many of the transistors in the muxing fabric are off during operation. So you've got more transistors (higher static power) and more dynamic power. - PaulArticle: 61451
>I overuse the syn_keep attribute and I hate the idea of instantiating >LUTs. My Carnot skills aren't exactly used regularly. Are Carnot skills needed? I can generally count to 4. A 4 input LUT can implement any function of 4 inputs. -- 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: 61452
"Ken Land" <kland1@neuralog1.com> wrote in message news:<vnqtu2fqaeqhcd@news.supernews.com>... > I would tackle it one .h file at time. Do a search and make sure you don't > already have the required header files, but your compiler search path is not > including their location. Then, if you don't have them, start copying them > over from the working systems. Or possibly do a search on sourceforge, etc. > > You could also post the particular header filenames here with for better > help. > > Ken Thanks a lot, Ken. I tried to copy all header files needed by the library into nios-gnupro/nios-elf/include folder when the compiler asking for those files. After I'd done that, a lot of errors appeared. It seem like the library files for multi-precision arithmetic is not supported by GNUPro compiler. Is there any other multi-precision arithmetic library files available for GNUPro compiler?Article: 61453
yes, i think so. I am not familiar with spartan. but I wonder there should be some IP core in it like vertex 2 pro so that you can use softcore too. This is not a real strong version. I believe it is just a the basic core of linux which will be no more than hundreds of k( maybe even less). Since I do not use linux, I never tried to spend too much time to study this. But as far as I can understand, it is not even as strong as avmon( the software I had mentioned). I don't think you can monitor the board on it or use it to do any real job unless you rebuild it. Basically, it is just a demo. for the 2nd question, no you don't need to. It support both pci and pci-x, which means 32-bit is just fine. But you may meet some voltage problem as i had met. But we can discuss that later when you get the board and unluckily meet that, too :P And for my question, do you have any clue how to establish that in general?? please give me some hints. It really bothers me a lot now. And by the way, I stupidly used one of my real email address last time. and I received lot of idiot messages. any solutions to that. what the hell!!!!!!!!:-( "Mancini Stephane" <nospam@nospam.nospam> wrote in message news:<pan.2003.10.03.13.20.33.631867@nospam.nospam>... > Thanks a lot for your responses but I still don't understand some points. > For example, what do you mean whan you say there's a linux core running on > the spartan ? Doas it mean that there a soft CPU wich runs linux ? > > About you P.S, it's exactly what we want to do. > > Could you also tell me if the PCI bus is 32 or 64 bits ? > Do I have to buy a PC with a 64 bit PCI slot ? > > Regards, > > Stephane > > > > > > On Tue, 30 Sep 2003 15:22:12 -0700, Heng Tan wrote: > > > Hi,there > > I received my avnet VirtexII Pro development kit(XC2VP7) this month. I > > know it is somehow different from the evaluation board(stronger in > > general). But I guess I can try to give some premitive views. And > > right now, since I am still a newbie on this board, the information I > > gave may not be accurate. > > > > 1.In the flash memory of the development board, there already stores a > > linux core there, which will run on the spartan(the pci bridge) when > > power up. you can use a serial cable to connect with a host pc and use > > a hypertermianl program to watch. The flash also installed some other > > applications which will help you monitor the board like avmon. I can't > > provide further details right now since my work are usually done in > > windows > > > > 2.I already installed the board into a pci slot and used it. So the > > answer to the second question is yes.( although it took me more than a > > week to contact avnet engieer and figure out some tedious technique > > detail. The documment coming with the board is not that helpful.) > > There is a tool called PCIutility which can help you to debug the > > board and download the file. However all these work are finished under > > the 3rd party driver (jungo or to say windriver). So as far as I know, > > probably only on windows. > > > > 3.I havn't test the memory speed yet. So I can't tell whether there is > > a bottleneck yet.( you need to write your own project both hd and sw > > to contol all types of the memory) > > > > 4. with the pciutility I mentioned above, yes you can program the FPGA > > through PCI. > > > > 5. you can connect it to a host pc not simply a monitor. > > > > Hope it is helpful to you. > > > > P.S. Do you know whether it is possible to feed input to the FPGA on > > board from a PC and read output to the PC?? If so, how?? I need to > > implement an algorithm and now stuck here. I mean write your own API > > instead of using some tools. > >Article: 61454
Marc Guardiani <marc@guardiani.com> wrote in message news:<5T2fb.20355$541.16572@nwrdny02.gnilink.net>... > What OS are you using? Xilinx dropped NT support with version 5.1i (even > though it worked). Now with 6.1i I can't get Impact or Core Generator to > run. > XP Home. I have since been advised to turn off virus scanning (McAfee in my case) during installation. I have done this, resulting in mixed success. Now the project nav starts ok, but if I try to launch coregen it fails. I have gone thru NUMEROUS uninstalls/installs with 2 different computers running 2000 and XP Home without success. I did an install on a virgin laptop running XP PRO w/o problems. I am in touch with tech support and will advise on the outcome. TomArticle: 61455
"Jon Elson" <jmelson@artsci.wustl.edu> wrote: > I guess you are talking about raster-scan displays without a pixel to pixel > frame buffer behind it, and not about vector-drawing displays (like an > oscilloscope in X-Y mode). > > Interesting theoretical enterprise, but I really don't see the point. And you wouldn't outside of a contextual reference frame that allowed you to understand where/why this might be important. It's a very narrow field of application. Not mainstream at all. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61456
Martin, Looked at the spec's of the EDP100. Looking very nice indeed.. So to convert the HDSDI into DVI you would need a deïnterlacer and a frame rate converter. Guess that's where your 4 framestores come from. If you don't mind, I'd like to know how many fieldstores are actually used in the deinterlacer. Normally, you'd need two stores for doing the frame rate conversion (double buffered). So that would leave you with 2 stores left to do deinterlacing which allows for some nice 3field algorithms. sorry to go off topic with this.. I'm just curious since I'm roughly in the same business. regards, Jan "Martin Euredjian" <0_0_0_0_@pacbell.net> schreef in bericht news:d_3fb.8955$N67.802@newssvr27.news.prodigy.com... >>>>>> insane quote removed by archive managerArticle: 61457
"Jan" wrote: > Looked at the spec's of the EDP100. Looking very nice indeed.. So to convert > the HDSDI into DVI you would need a deïnterlacer and a frame rate converter. ... > If you don't mind, I'd like > to know how many fieldstores are actually used in the deinterlacer. I can't get into the internals at that level as some things must remain proprietary. I'm sure you understand. The de-interlacer uses some conventional algorithms and a couple of not-so-standard techniques. Keep in mind, this is a monitoring device, and, as such, it tries very hard to not modify the incoming HD stream too much. Some de-interlacing techniques produce great looking pictures that are highly synthetic. That's OK if you are building a deinterlacer for a system that will then have to process the image further or for something like home TV. Probably no OK for professional use. At least that's my approach. Seems to work. > I'm just curious since I'm roughly in the > same business. Can you elaborate? Privately would be OK, of course. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61458
Hi I am a relative "n00b" with regard to FPGA-programming, but I'm currently working on a Rijndael-implementation on a APEX1A dev.board. And I have run into some problems. I want to put my top-level design together from several smaller building blocks, that I want to design, compile, simulate and "forget". So when I need them later on, I'd like to simply import them into my design. The only way I have managed to do this so far, is to copy the design- files from their original location, and into my new project directory. And this clearly isn't very efficient or simple. I know there has to be a simpler and better way, but I haven't benn able to figure it out yet. So all suggestions would be greatly appreaciated. -"Panic"Article: 61459
Maybe so. Hart to tell at this point. Certainly the material in the book would open the door to very interesting and useful discussion of advanced topics, none of which were explored, some were recited, others skipped over. I think there are two groups within your company that might need a flame (not a match) lit under their chairs: web design and education/documentation. The website can be incredibly retarded and just not up to par with what good website design folks can do today. Sure, it's expensive to hire these heavy hitters, but Xilinx can afford it. I only have one sample of the education group's output and, as you learned, they didn't put on a good show as far as I am concerned. I think there are huge gaping holes in the available documentation and devices are getting increasingly more complex. I think there's a need to address this --by experts, not fresh grads-- and it's not being done. Some of these topics might include floorplanning, design optimization, timing optimization, FPGA Editor, design flow optimization and automation (XFLOW, scripting, command-line tricks, etc.). I'm not talking about being able to download a document describing the various available timing constraints, for example, but a practical, in-the-trenches set of docs treating these topics in order to support designers in both adopting and succesfully utilizing these devices in an already difficult marketplace. Within the next few months I'll probably have a need to hire a couple of FPGA/Embedded guys, and the realization that I can't seem to rely on even sending them to a manufacturer-provided course in order to enhance their ability to generate accurate designs that perform well is what triggered some of my concern. Still, this is not a Xilinx putdown but rather costructive criticism. I love the chips and will probably continue to use them for a long time. I have over half a dozen high-performance imaging products in the works and, at this point, all of them have Xilinx FPGA's in them. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F7DB8E8.A11339E0@xilinx.com... > Martin, > > I am sorry you had a bad experience. > > I will ask about it. I had heard from others that this particular course was a > good one (some of my own staff have taken it), so I am hoping that your > experience was not the course, but perhaps the instructor (still unfortunate, > and not acceptable). > > Austin > > Martin Euredjian wrote: > > > I recently took the "Advanced FPGA Implementation (v6)" Instructor-Led > > Course and came out of it with a fair bit of dissappointment. I don't want > > to engage in Xilinx-bashing but it bothers me that the course was simply not > > worthy of the title it was given. > > > > The only reason I might get something out of it will be because I will pour > > over the 500 page book on my own and experiment for many, many hours. The > > class boiled down to a bunch of slides (a very small subset of the book, > > maybe 20%) being read out loud with a degree of re-interpretation. The labs > > were based on an obscure design that was not introduced at all. So, all you > > could do in the alloted time was type from the book like a robot and move > > on. No real learning took place there. > > > > I took the course because, after a two-year effort --starting from scratch-- > > to learn FPGA's, I thought that an advanced course taught by an expert in > > the field would be a great way to take my skills up a notch or two. I > > needed to get to that proverbial last few percent and, frankly, I also felt > > stuck with regards to timing optimization, floorplanning and other advanced > > areas. I thought that an "advanced" course would be taught by a peer who'd > > offer the sort of insight that only comes from significant experience in the > > field and, yes, inside information. That is certainly not what happened. I > > can read slides just as well as the next guy. I don't need to pay $1,000, > > travel and burn two days' work to endure that experience. > > > > So, I wonder. Was this a fluke? Are the other coursed different, better, > > worst? Are Altera's courses better? It seems that Xilinx contracts out the > > trainig to a third party (a company called "Technically Speaking". I heard > > that Altera chooses to use insiders. Is this true? Does it make a > > difference? > > > > Thanks, > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Martin Euredjian > > > > To send private email: > > 0_0_0_0_@pacbell.net > > where > > "0_0_0_0_" = "martineu" >Article: 61461
Well, I think there's a very important distinction that needs to be understood. The "intro" or "beginner" classes can probably be taught by just about anyone who passes the cold mirror test and is a decent teacher (although my preference would be to have an experienced individual instead). However, the minute you characterize a class as "Advanced" you better get a guy who's had some skin in the game for a while and can truly shed some light on some of the dark corners of these technologies. I think all of you guys (meaning FPGA companies) have had it good. Engineers bust their butt's digging and experimenting and figuring things out...digging for information that you should be providing. I hope things change before we get to the 100 million gate devices, 'cause the real cost of designing with these chips is being borne by the OEMs that pay for these individuals to (through no fault of their own) put a lot more hours into a project than might be required with a higher quality of documentation. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Jesse Kempa" <kempaj@yahoo.com> wrote in message news:95776079.0310031106.71c90277@posting.google.com... > > So, I wonder. Was this a fluke? Are the other coursed different, better, > > worst? Are Altera's courses better? It seems that Xilinx contracts out the > > trainig to a third party (a company called "Technically Speaking". I heard > > that Altera chooses to use insiders. Is this true? Does it make a > > difference? > > To answer your question about Altera: Yes, we do have a dedicated > training department with teachers who do the classes at customer > sites. I understand that our distributor Arrow also leads traning > events. For special workshops and things like that (such as the SOPC > World events going on now or other internal training events), other > Altera employees specializing in that area may present. Occasionally > we have had third parties present *on their specific product*, such as > those who do synthesis tools. > > Here's a link to the Altera Training homepage: > https://buy.altera.com/etraining/etraining.asp > > Hope this helps, > > Jesse Kempa > Altera Corp. > jkempa at altera dot comArticle: 61462
There's one thing Zeidman mentions that I feel very strongly about. In fact, I've been repeating a phrase very similar to the one he used in the article for about four years now: WE NEED BETTER TOOLS. I sincerely think that FPGA manufacturers need to figure out a way to get out of the tool business and pour their resources into making better chips. Open it up to the masses. The first company to do that is bound to take a big huge bite out of the other's market share simply because of all the tools that will be offered by the engineering community. There's probably a ton of very capably and creative guys out there who are ready, eager and able to create wonderful new --and very powerful-- tools with which to craft designs. Instead, we are gang-chained to the vision and approach offered by the vendors. Well meaning as they might be, I doubt that any real progress will come out of their shops. Just incremental improvements, but that's it. For example: Why is it that I can't use a farm of twenty PC's to compile a complex design quckly? When your very survival as a business is predicated upon how well your product performs in a free market, the best tools tend to float to the top and others fizzle. No FPGA manufacturer's survival, at the current stage of things, depends on the quality of their tools. As long as they are adequate engineers make them work. What us end-users want are the chips, so we put-up with whatever we are forced to use in order to put the chips on our boards. If a better tool appeared we'd probably drop the current offerings in a nanosecond. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "jakab tanko" <jtanko@ics-ltd.com> wrote in message news:bljsjs$4me$1@news.storm.ca... > A good read for anyoane interested in FPGA > http://www.embedded.com/showArticle.jhtml?articleID=15201141 > --- > jakab > >Article: 61463
hmurray@suespammers.org (Hal Murray) wrote in message news:<vnsdiro5e8e272@corp.supernews.com>... > >I overuse the syn_keep attribute and I hate the idea of instantiating > >LUTs. My Carnot skills aren't exactly used regularly. > > Are Carnot skills needed? I can generally count to 4. A 4 input LUT > can implement any function of 4 inputs. Do you realize how patronizing your response was? Please, quickly give the appropriate INIT for a LUT4 where the desired output is &(in[3:1]^~in[2:0]) Since you can count to 4, this should be simple. Can you guarantee that other engineers looking at your code later will understand what you're trying to do? With Regards, John_HArticle: 61464
"Vinh Pham" <a@a.a> wrote in message news:<XBnfb.23230$Ak3.11431@twister.socal.rr.com>...
> But something is nagging me. Can't your xnor/and scheme be implemented in
> two levels of LUTs without the need of a MUXF5? I must be missing
> something, or maybe the problem is the synthesizer isn't mapping it that
> way?
>
> The first level LUTs would implement (output = (bit0 xnor bit1) and (bit1
> xnor bit2)). You'd have four LUTs in the first level, then the second level
> LUT would AND all of them together.
The implementation can, indeed, be as you imagine. No nagging
necessary. Your earlier pseudocode did just what you're suggesting
here. One of the reasons I went with the MUXF5 was that the primitive
doesn't need the syn_keeps that I use to coerce the synthesis into
thinking how I want; a LUT savings is nice though at a slight cost in
delay if I want the combinatorial output. But your discussion makes
me wonder if the Xilinx AND3 primitive will work just as well. I'll
test it out when I get back to work. Comparing the implementations
below, the only advantage to "mine" is one fewer LUT.
Maybe the synthesizer will let this stay. I don't have to define
intermediate variables to syn_keep and I don't need nested loops.
Since I don't need to use the xnors, I don't even need to comment the
code any more than usual.
generate
for( h=0; h<8; h=h+1 )
begin : run
AND4 y ( .O(yours[h])
, .I0( bytesPlus1[h*8+2:h*8+1] == bytesPlus1[h*8+1:h*8+0] )
, .I1( bytesPlus1[h*8+4:h*8+3] == bytesPlus1[h*8+3:h*8+2] )
, .I2( bytesPlus1[h*8+6:h*8+5] == bytesPlus1[h*8+5:h*8+4] )
, .I3( bytesPlus1[h*8+8:h*8+7] == bytesPlus1[h*8+7:h*8+6] )
);`
AND3 m ( .O(mine[h]),
, .I0( bytesPlus1[h*8+3:h*8+1] == bytesPlus1[h*8+2:h*8+0] )
, .I1( bytesPlus1[h*8+6:h*8+4] == bytesPlus1[h*8+5:h*8+3] )
, .I2( bytesPlus1[h*8+8:h*8+7] == bytesPlus1[h*8+7:h*8+6] )
);`
end
endgenerate
Thanks for keeping me thinking.
- John_H
Article: 61465Where are you coming from? Are you a software or hardware guy? Hobby or professional use? Some useful books/references (sorry, I'm Xilinx/Verilog-centric): Real World FPGA Design with Verilog by Ken Coffman Verilog Designers Library by Bob Zeidman Verilog HDL Synthesis by Bhasker Verilog HDL Primer by Bhasker If you can find it in the Xilinx website: "Programmable Logic Design Quickstart Handbook" The Xilinx education portal can be useful while getting started. http://www.xilinx.com/univ/ Get a simply dev board, like the Avnet Virtex II eval board. Spend cubic hours playing with it. Read the data book for the device you are using. Print out a pile of application notes and make sure you understand them on paper. Then, if your board will support it, try to implement. The subject is wide and deep. I'd recommend getting a real tangible sense of what it is all about before considering taking any classes (if that's something you are considering). One of the toughest things to understand is that logically correct code (no bugs from a software standpoint) is not necessarily equal to a working device. Pick a simple project and try your hand at it. Start with something as simple as sending the output of an eight bit counter to a set of LED's. Then, using the same design, you might want to explore clocking and clock synthesis options. You might want to then move on to using parts of the same design to also create something like a pulse-width-modulator. These are just some ideas. One bit of advice probably worth a ton: Don't even bother with chips until you know your simulator intimately. In fact, don't even buy a dev board until you've explored creating and simulating a bunch of little designs. As your designs get larger the realities of current technology are that you'll need to rely on simulation in order to get any productivity out of the process (as well as good design verification, etc.). These are just a few random points. There's a lot more others can contribute. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Robert Monsen" <postmaster@BulkingPro.com> wrote in message news:bI1eb.631002$YN5.453735@sccrnsc01... > Looking for useful books, articles, and development kits for FPGA > development, and perhaps some war stories about coming up to speed on these. > > TIA > > Regards, > Bob Monsen > > >Article: 61466
I agree with Martin! I can't speak for the classes, but the rest is definitely true. I hope someone at Xilinx is listening. There is no doubt (at least in my mind) that Xilinx has some great FPGAs, etc. The software seems to be fairly well done, although it could use some improvement. The area of improvement is in simple, useable documentation. If I need to check three or for different areas for a full picture of what it taakes to get a job done, can you at least create a link between the areas. Xilinx could save a bundle in tech support, if they would just improve the documentation. It might even get them a few more customers. It generally is not a good idea to PO the customer. (Usually Xilinx does not do that.) Theron Hicks Martin Euredjian wrote: > Maybe so. Hart to tell at this point. Certainly the material in the book > would open the door to very interesting and useful discussion of advanced > topics, none of which were explored, some were recited, others skipped over. > > I think there are two groups within your company that might need a flame > (not a match) lit under their chairs: web design and > education/documentation. > > The website can be incredibly retarded and just not up to par with what good > website design folks can do today. Sure, it's expensive to hire these heavy > hitters, but Xilinx can afford it. > > I only have one sample of the education group's output and, as you learned, > they didn't put on a good show as far as I am concerned. > > I think there are huge gaping holes in the available documentation and > devices are getting increasingly more complex. I think there's a need to > address this --by experts, not fresh grads-- and it's not being done. > > Some of these topics might include floorplanning, design optimization, > timing optimization, FPGA Editor, design flow optimization and automation > (XFLOW, scripting, command-line tricks, etc.). I'm not talking about being > able to download a document describing the various available timing > constraints, for example, but a practical, in-the-trenches set of docs > treating these topics in order to support designers in both adopting and > succesfully utilizing these devices in an already difficult marketplace. > > Within the next few months I'll probably have a need to hire a couple of > FPGA/Embedded guys, and the realization that I can't seem to rely on even > sending them to a manufacturer-provided course in order to enhance their > ability to generate accurate designs that perform well is what triggered > some of my concern. > > Still, this is not a Xilinx putdown but rather costructive criticism. I > love the chips and will probably continue to use them for a long time. I > have over half a dozen high-performance imaging products in the works and, > at this point, all of them have Xilinx FPGA's in them. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu" > > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3F7DB8E8.A11339E0@xilinx.com... > > Martin, > > > > I am sorry you had a bad experience. > > > > I will ask about it. I had heard from others that this particular course > was a > > good one (some of my own staff have taken it), so I am hoping that your > > experience was not the course, but perhaps the instructor (still > unfortunate, > > and not acceptable). > > > > Austin > > > > Martin Euredjian wrote: > > > > > I recently took the "Advanced FPGA Implementation (v6)" Instructor-Led > > > Course and came out of it with a fair bit of dissappointment. I don't > want > > > to engage in Xilinx-bashing but it bothers me that the course was simply > not > > > worthy of the title it was given. > > > > > > The only reason I might get something out of it will be because I will > pour > > > over the 500 page book on my own and experiment for many, many hours. > The > > > class boiled down to a bunch of slides (a very small subset of the book, > > > maybe 20%) being read out loud with a degree of re-interpretation. The > labs > > > were based on an obscure design that was not introduced at all. So, all > you > > > could do in the alloted time was type from the book like a robot and > move > > > on. No real learning took place there. > > > > > > I took the course because, after a two-year effort --starting from > scratch-- > > > to learn FPGA's, I thought that an advanced course taught by an expert > in > > > the field would be a great way to take my skills up a notch or two. I > > > needed to get to that proverbial last few percent and, frankly, I also > felt > > > stuck with regards to timing optimization, floorplanning and other > advanced > > > areas. I thought that an "advanced" course would be taught by a peer > who'd > > > offer the sort of insight that only comes from significant experience in > the > > > field and, yes, inside information. That is certainly not what > happened. I > > > can read slides just as well as the next guy. I don't need to pay > $1,000, > > > travel and burn two days' work to endure that experience. > > > > > > So, I wonder. Was this a fluke? Are the other coursed different, > better, > > > worst? Are Altera's courses better? It seems that Xilinx contracts out > the > > > trainig to a third party (a company called "Technically Speaking". I > heard > > > that Altera chooses to use insiders. Is this true? Does it make a > > > difference? > > > > > > Thanks, > > > > > > -- > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > Martin Euredjian > > > > > > To send private email: > > > 0_0_0_0_@pacbell.net > > > where > > > "0_0_0_0_" = "martineu" > >Article: 61467
Austin,
>
>First, I checked the IBIS model in Hyperlynx v7, and it works fine.
>
That's good news; was that a coupled-line simulation in BoardSim
of a fast driver whacking a LVDS_25_DCI input? Or, an uncoupled
LineSim model with a V2 for both driver and receiver?
I don't currently have access to Hyperlynx or the problematic
design files (previous employer), but as I recall it was v7-beta
with which I had encountered problems.
>
>Next, the driver for LVDS is required to have a 100 ohm drive impedance. If
>you use a device that does not comply to this, then you most definitely can
>and will get reflections shot back to the input.
>
>I can not comment on parts that do not meet the LVDS specifications
>when connected to the FPGA: that requires some engineering (as always).
>
That's quite a stretch: blaming the hypothetical faults of the
driver for not correcting the known sins of the receiver...
Please re-read my original post, and notice that when I mentioned
the impact of the large C_COMP values in the presence of a high
speed driver, I used the phrase "requires external back termination
and/or input matching".
Firstly:
Yes, a perfect 100 ohm transmission line back terminated with
a perfect 100 ohm source impedance can completely absorb the
large reflection generated by a highly capacitive input.
Personally, I prefer not to generate (or propagate) such massive
ringbacks in the first place.
Secondly:
To the best of my recollection, the output impedance specified
by the original LVDS spec was fairly broad- in the presence of a
50%-60% ringback, another 40% re-reflection can be significant.
Thirdly:
Although the original LVDS specification did not directly
specify a max Cin value, newer specifications such as
HyperTransport do; for example, HyperTransport requires a
maximum 2pf (single-ended) Cin for receivers rated > 800 Mbps.
Fourthly:
Left uncompensated, the reflections created by a large input
capacitance can render the part useless for multidrop topologies.
The back propagation of the reflection makes the signal on the
line unusable except at the die input ( ignoring here any
reflections off any mid-stream taps, which would be just as bad.)
Before you attack a multidrop system as being a special case,
let me point out that the simple act of probing the line will
create a multidrop system out of a point to point link.
Also, in most high speed systems, there is a need to monitor
the link in some fashion, either as part of a system jitter/skew
or setup/hold verification, or perhaps a non-intrusive signal
tap for operational monitoring.
This is often done by placing a passive resistive coupler
in-line with the signal, or perhaps probe pads for one of the
low-loading differential active probes.
If the tap is placed close to the highly capacitive receiver
input, the ringback can leave the differential signal in limbo
at the probe point ( both inputs within the differential Vih/Vil
hysteresis switching threshold ) until the reflected pulse has
passed; if you place it farther up the line, the reflection can
re-clock the probe, or interfere with the next incoming bit.
Fifthly:
You seem to be suffering from a bad case of input capacitance
denial here- admit that the V2 LVDS inputs are far from perfect
for 840 Mbps operation, and put that energy to use identifying
the problem to your customers, and explaining how to work around
it, instead of propping up your straw men.
At no point have I claimed that the V2 inputs are unusable,
but only that, in the presence of high speed drivers, extra
engineering effort needs to be expended to both understand the
impact of the V2 input capacitance on the interconnect, and
find a work-around that is appropriate for the design at hand.
>
>I have received back confirmation that the issues are being worked on from
>the support group, and I also notified the apps folks about some kind of app
>note for use of the LVDS DCI feature, since it is not as clean as the
>internal solution (in Virtex II Pro).
>
Might I suggest splitting that into two app notes: one explaining
the various DCI problems in general (they affect more than just the
LVDS_25_DCI standard), and another for the particular quirks of high
speed differential signaling with a V2.
>
>Not ignored at all.....
>
Where did I say that?
However, since you bring it up, I might point out that the wheels
of documentation update at Xilinx seem to grind quite slowly - what
prompted me to write up my original post was noticing last week,
5-6 months after informing Xilinx of the DCI power problem, that
Answer Record 15633 STILL had that worthless 62.5 mW number with
no mention of the ~200 mW per bank VRP/VRN overhead.
Brian
Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F7DA078.521C7B51@xilinx.com>...
> Brian,
>
> First, I checked the IBIS model in Hyperlynx v7, and it works fine.
>
> Next, the driver for LVDS is required to have a 100 ohm drive impedance. If
> you use a device that does not comply to this, then you most definitely can
> and will get reflections shot back to the input.
>
> I can not comment on parts that do not meet the LVDS specifications when
> connected to the FPGA: that requires some engineering (as always).
>
> I have received back confirmation that the issues are being worked on from
> the support group, and I also notified the apps folks about some kind of app
> note for use of the LVDS DCI feature, since it is not as clean as the
> internal solution (in Virtex II Pro).
>
> Not ignored at all.....
>
> Austin
>
> Brian Davis wrote:
>
Article: 61468Martin Euredjian wrote: > > There's one thing Zeidman mentions that I feel very strongly about. In > fact, I've been repeating a phrase very similar to the one he used in the > article for about four years now: WE NEED BETTER TOOLS. > > I sincerely think that FPGA manufacturers need to figure out a way to get > out of the tool business and pour their resources into making better chips. > Open it up to the masses. The first company to do that is bound to take a > big huge bite out of the other's market share simply because of all the > tools that will be offered by the engineering community. There's probably a > ton of very capably and creative guys out there who are ready, eager and > able to create wonderful new --and very powerful-- tools with which to craft > designs. Instead, we are gang-chained to the vision and approach offered by > the vendors. > > Well meaning as they might be, I doubt that any real progress will come out > of their shops. Just incremental improvements, but that's it. For example: > Why is it that I can't use a farm of twenty PC's to compile a complex design > quckly? > > When your very survival as a business is predicated upon how well your > product performs in a free market, the best tools tend to float to the top > and others fizzle. No FPGA manufacturer's survival, at the current stage of > things, depends on the quality of their tools. As long as they are adequate > engineers make them work. and if they are in-adequate, engineers choose another vendor - so FPGA vendors are actually VERY dependant on tool quality. > What us end-users want are the chips, so we > put-up with whatever we are forced to use in order to put the chips on our > boards. If a better tool appeared we'd probably drop the current offerings > in a nanosecond. It depends very much where in the tool chain you mean. For front end, silicon independant compilers/simulators, then there is scope for any tool chain to create a connectivity file. What you need here is enough competent designers, with enough spare time.... For back end tools, and some IP generators, that have to map closely to the silicon, then it is not practical to 3rd party that. Tools would come out MUCH later, or the silicon would have to 'freeze' features. If there are features you want to see, then talk with the FPGA vendors.... -jgArticle: 61469
>Do you realize how patronizing your response was? > >Please, quickly give the appropriate INIT for a LUT4 where the desired >output is > > &(in[3:1]^~in[2:0]) > >Since you can count to 4, this should be simple. >Can you guarantee that other engineers looking at your code later will >understand what you're trying to do? Sorry. I wasn't trying to be an asshole. I thought you were into trying to partitioning logic into LUTs in some sneaky way. I assumed software is smart enough to compute an INIT string from a logic equation. The old Xilinx tools could do that for 3000 series parts. Has that fallen through the cracks with the newer software? -- 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: 61470
"Jim Granville" wrote: > and if they are in-adequate, engineers choose another vendor - so FPGA > vendors are actually VERY dependant on tool quality. I don't think you got my point. Tools today are adequate. And that's it. Without competition the rate of progress is slow. So everyone deals with it and life goes on. But, you only have one choice per vendor. So, as long as the pain/results threshold is on the correct side of the scale, vendors are safe and few are going to switch chips and redo complete designs just 'cause of the tools. In some companies managers would let an engineer pop a blood vessel before incurring the additional cost of a redesign just 'cause the FPGA guy is complaining. If there was real competition things would be different. Take hierarchical floorplanning, for example. Badly needed. Nowhere in sight. Or more intelligent routers. Or RPM's that contain more than just placement. How about parallel processing (network-based, bunch of cheap computers) to speed up compile runs that take too long? How about better design entry environments (recent thread about editors is one example). Or better documentation. Etc., etc. Take something like Xilinx's Incremental flow. Sounds great, but, if you instantiate a module more than once you can't use that approach on it. Why? And, depending on how which documents you read, it doesn't work with submodules in a hierarchy, only modules instantiated in the top level. If this is the case, why? I have a fair degree of certainty that an independent developer would not take this approach, cause the competition would tear them to shreads. An open market and real competition would no doubt result in a quantum leap in FPGA design tool quality. I have no doubts about this. The problem is that the critical bits of info are not available for anyone to even attempt to generate their own bit files. Compare the FPGA world to the embedded/C world. Most microcontroller manufacturers' compilers stink. There are a number of great compilers and design environments out there available from various companies. Some are wonderful. Some are not. Others are free. And, of course, there are those that are too expensive. But, you have choices, and companies dedicated to that small segment of the business have proven that they can do a better job than the chip manufacturers. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 61471
Boy, how long have you been in the business? The tools these days are excellent. That's not to say they can't be improved, because they can. I recall hand routing fpga designs and thinking I was in 7th heaven. But, then, I have done designs with hand drawn schematics and wire-wrapped TTL logic (I had a drafting board & machine until a couple of years ago).Article: 61472
20+ years. I go back to hand-drawn schematics and wire-wrapped boards as well. Had lots of fun designing boards the size of pizza boxes with loads of TTL chips. Don't be fooled by shinny GUI's. Today's tools are adequate. Not sure I'd call them good. I have a feeling they need to (and could/should) be substantially better. And I simply don't think that sole-sourcing is the way to go. Not any more. That's all. -Martin "Tom Seim" <soar2morrow@yahoo.com> wrote in message news:6c71b322.0310042218.5ca0dfba@posting.google.com... > Boy, how long have you been in the business? The tools these days are > excellent. That's not to say they can't be improved, because they can. > I recall hand routing fpga designs and thinking I was in 7th heaven. > But, then, I have done designs with hand drawn schematics and > wire-wrapped TTL logic (I had a drafting board & machine until a > couple of years ago).Article: 61473
crob <crob714@yahoo.com> wrote in message news:cb769f6b.0310031119.75684510@posting.google.com... > Make sure all unused pins are "As Inputs Tri-Stated". This is done in > the Settings-> Device ->Device & Pin Options > I think having the default "As output, driving ground" causes problems > on the development board, because some of the unused pins may be > connected to other things such the recofiguration signal to the Max > Device (active low). > I have burned myself plenty of times on this. > --Chris Aye, this is explicitly mentioned in the tutorial (Cyclone). Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 61474
Hi, I'm not sure if this is the best place to ask, but anyway, does anyone know of any free software that draws timing diagrams? Thanks, Michael.
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