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
John, The long post in response to mine is honestly the first rather level-headed discourse I've seen from you. Sincere thanks for taking the time to put together a constructive post. Just to clear up the one point you had question about, when I suggested you called their business methods a scam I was referring to your utter disbelief that the EasyPath model made money - that any 80% discount meant that they were dumping parts. Dumping is illegal and any smoke and mirrors that provide dumped parts to customers is a sham. It's my own belief that they have a solid business model with significant ROI without obliterating the margins; the result is more customers using Xilinx in high production with significantly lower per-device infrastructure and support costs. If you already have the silicon and IP, get paid to customize tests, and reduce the cost associated with getting a part out the door, you have great ROI - you've invested very little to support this business model that wasn't already invested. Big, incremental business is tremendous to have. I hope you have the opportunity to get Reconfigurable Computing up to the level of performance and supportability that you envision. It may be a tough road because the market is small. The market may demand the higher premium devices to support the efforts from you and other RC advocates which may get you some attention from strategic marketing folks that help shape the business decisions on development. Unfortunately, Peter and Austin are not Strategic Marketing employees but instead are involved with support of existing and evolving devices that are about to hit the market. This forum has the wrong audience for actively changing where Xilinx is going. I don't fault any one car company for not having the features that I feel would make my driving experience so much better. If I felt strongly about my position, I wouldn't get much activity at the dealership or on the technician's bulletin board where the nitty-gritty details are known to so many. Direct exposure the appropriate Xilinx people is about the only way to truly effect change. This is only my own opinion, of course - I don't pretend to know everything that goes on in the industry but I do have my own perspective. In the corporation I work for, our two dozen or so hardware engineers have had the opportunity to meet with some of the VPs in Xilinx as they give us the direction they see their next products going. We've even had Xilinx CEO Wim Roelandts visit us here in Oregon. If you can get your Xilinx sales engineer and/or FAE to understand your needs and the potential market you feel is there not only for you but for others that could leverage tools and silicon tailored for better RC, you might have a chance to shape the vision of those who shape the direction of Xilinx. As helpful as they are and as respected within their own corporation they may be, the folks who participate in this forum are not the ones who shape the vision - they may have influence, but it's not the influence you need to push for better RC support, tools, or "permission" to do what you feel needs to be done to blaze the trail. I've seen Peter and Austin have troubles when dealing with stubborn people through the limits of the newsgroup. I have troubles with people myself when there's obstinance, dimwittedness, or just plain insulting behavior. I've never had a problem with Peter. When you annoy one of the most level-headed, market-experienced technical people I've had the chance to meet, it's time to reevaluate your own stance. If all your communications were as civil and well considered as the one I'm now responding to, you may have gotten a lot further with the limited influence available through this forum. I wish you luck in your endeavors and hope you have a chance to realize your visions. - John HandworkArticle: 99001
laura_pretty05@yahoo.com.hk wrote: > i mean that pin assignments from the FPGA to the I/O pins at > FLEX_EXPAN_X. You again don't tell us, what synthesis tool you use. Do you expect any useful information about pin assignments without this information? How to make pin assignments is described in the manual of your synthesis tool. Often is is self-explaining - just search the menu of the GUI of your synthesis tool. RalfArticle: 99002
Peter is being diplomatic. He has to. (I liked the comment about SU carbs.) If it's not supported in a recent web-pak, don't use it. $.02Article: 99003
Hello Rob, Dedicated DQ pins on Altera Cyclone II package have very strange placement and I am curious about the reason those pins are called DQ. In other words, does DQ pin have any significant difference from the adjacent non-DQ pin in the same bank on Altera EP2C8F256 package? With best regards, Vladimir S. Mirgorodsky Rob wrote: > The DQS signal is usually associated with a group of data (DQ) pins; so where ever the DQS > singal is you want the associated DQ pins located in close proximity. Also, some DDR2 I/O > standards, like SSTL-18 class II, are only supported on two sides of the chip. > > <v_mirgorodsky@yahoo.com> wrote in message news:1142694593.123202.188480@v46g2000cwv.googlegroups.com... > > Hello group, > > > > I have an issue with porting my high-speed DDR interface to Altera > > Cyclone II device. As far as datasheet says, Altera Cyclone II device > > does not have any dedicated circuitry to support DDR signaling in its > > Input/Output blocks for DQ pins. The only thing present in hardware is > > the clock delay circuitry on DQS pins. All other DDR logic is > > implemented using LUT's and triggers from adjacent Logic Array > > Blocks. So, it seams that we have only DQS pins location fixed, > > whenever all other DDR pins may float within the selected IO bank. Is > > that right? If yes, then what is the reason to denote certain pins on > > the Altera Cyclone II package as dedicated pins for DQ input/outputs? > > > > With best regards, > > Vladimir S. MirgorodskyArticle: 99004
In article <1142667911.725607.103910 @u72g2000cwu.googlegroups.com>, coolsaroj@gmail.com says... > Thank u Isaac.Now u also hav understood that there is no point in > discussing these topics anymore bcoz neither of the generations is > having mutual respects for each other.So burry this topic here itself. > Thank u once again. When you use things like "bcoz" and "u" it makes you look like a damn fool idiot. It's OK to use that stuff when you're text messaging on a cell phone since people understand that it is hard to type and abbreviations make it easier. And it's OK to do it in instant messaging or chat rooms where other people are doing too and it is the accepted way of doing things. But when you are in a newsgroup where everyone else speaks proper english, even people who don't speak english as their native language, it's wrong. It makes you look like your IQ is less than your age. And continuing to argue that it is OK when you are told otherwise makes it look like your IQ is less than your shoe size. Get over it and type proper words if you want anyone to take you seriously and answer your questions. Otherwise we are all just going to continue to laugh at you.Article: 99005
Josh Rosen wrote:
> The tools that you are looking for never existed. The only thing that was
> available at the time were crude schematic entry tools which ran on DOS or
> maybe Windows 3.1, I don't remember which.
I think XACT 5 was dos and 6 was windows.
It was a cruel tool.
Ran for days if you were lucky.
> I wrote my own synthesis tools
> in Gnu Lisp which converted ABEL (a now dead language for PALs) into XNF
> format (the old Xilinx Netlist Format), rather then use the schematic
> tools.
Wow. Sounds like XACT was at least good as a muse.
> Take Peter's advice and get a modern development board.
Yes J.,
either that, or take this break
in the action to learn to code and sim your
design in an HDL. That way you can
check the form, fit and function with
your next device before you buy it.
-- Mike Treseler
Article: 99006Austin, thank you very much for your swift reply. The reason for my initial post was, that I already had a look at the Power Central page and also at all of the Power Partner Websites. As you say there are a number of example designs and products that I could choose from. The difficulties I am having is that there are so many different designs, and I know too little about power supplies in order to make an educated judgement on whats best for me. I am currently in the process of trying to understand some of the designs. Most of the example designs are based on 5V or 3.3V Vin. If I have 11.6V as my main power source, should I step down to 5V first, and use one of the example designs, or would it be better to go from 11.6V to the individual rails directly? Also, is it correct, that with increasing current requirement, there needs to be an inductor? I figured the inductors are the largest parts in the design. thanks greatly for your help. JakobArticle: 99007
Jakob, I would suggest you intially buy a module, or a complete power supply for each required voltage (least expensive option). There are standard modules that take a 12V input. 6, 5, and 3.3 V inputs are more common, however. If you were an experienced power supply designer, I would suggest a fairly standard synchronous rectifier flyback design, with a tapped inductor to provide all your supply voltages at the same time... basically what PC power supplies look like. The power supply is often left for last, and is the most often source of problems, as there are very few individuals left in the world who can actually design switching power supplies. Linear power supplies are completely out of the question for the low core voltages today, as they would be just horribly inefficient. If you want to design power supplies, first read the four or five textbooks out there on designing switching regulators, then get the evaluation kits for a half dowzen different parts. Then learn how to design inductors and power transformers by reading the ferrite core manufacturers guides to using their products. For most engineers, v = -l di/dt is a complete and utter mystery. It is a long road, and you will have many failures (or else you are not learning). If you just wish to use an existing design from a vendor, get their layout for their pcb, and their bill of materials, and copy it exactly on your pcb. And then hope you didn't make any mistakes. Austin Jakob wrote: > Austin, > > thank you very much for your swift reply. The reason for my initial > post was, that I already had a look at the Power Central page and also > at all of the Power Partner Websites. As you say there are a number of > example designs and products that I could choose from. The difficulties > I am having is that there are so many different designs, and I know too > little about power supplies in order to make an educated judgement on > whats best for me. I am currently in the process of trying to > understand some of the designs. > > Most of the example designs are based on 5V or 3.3V Vin. If I have > 11.6V as my main power source, should I step down to 5V first, and use > one of the example designs, or would it be better to go from 11.6V to > the individual rails directly? > > Also, is it correct, that with increasing current requirement, there > needs to be an inductor? I figured the inductors are the largest parts > in the design. > > thanks greatly for your help. > > Jakob >Article: 99008
Rick, I have apologized to you. As for Xilinx management, I am often called before my boss, my boss' boss, and so on, and occasionally talk to Wim. For any number of reasons. I have been advised, admonished, counselled, re-trained, instructed, and so on. I have also been congratulated, celebrated, awarded, and recognized by others for my help and advice. I have no issues or problems with my management, and I value their opinions, and advice. We have vey open communications at Xilinx. As Peter said, Xilinx is not a dictatorship. If you feel I am doing something wrong, then email my boss and make him aware of your concerns. The newsgroup is read by many internally, and I post knowing full well that Wim may be reading it. Fortunate for me, he also has a sense of humor. There are unpardonable sins (for which you are dismissed), and it is very clear what those are. And those all relate to issues that are either ones where you break the law, or are giving away Xilinx IP and secrets. As a member of Xilinx' patent committee (I read every single disclosure) I am extremely sensitive to those issues, and help police our IP. There are also guidelines, and one of my favorites is the customer is number one, top of the list. I created the Xilinx fast action response team procedures for acting on unsolved customer issues, and was the first "Fire Chief." I have been in rooms with CEOs, CTOs, CFOs, and so on. I don't take any disrespect, and I tell the truth. So, just because the customer is number one, doesn't mean I accept disrespect, or abuse. When that occurs, I am not afraid to stop the discussion right there, call "foul", and attempt to get things back on track. And, I do have my own personality, my own sense of humor, and my own way of communicating (and writing). I accept that it may drive some nuts. Again, my apologies. AustinArticle: 99009
Hi, I have a design where I'm trying to test LUT. I have a normal BIST application which has a counter feeding addresses to an LUT. I'm trying to test the LUT for faults basically, so I load in some sort of a test pattern into the LUT. I compare the output of two LUTs to determine if there is a fault. My comparator is also an LUT (since there are 4-inputs, two from the Y and two from the X outputs of a Spartan II slice). What I have noticed is that when I try to implement this design through Xilinx ISE, the MAP process does not consider the LUTs under test and thus removes them from the design. However, for my work, it is imperative that these LUTs not be removed. I tried running the MAP program with the -u option, but that doesn't help either. Has anybody encountered this before? And if so, do you have any suggestions on how to ensure that my circuit-under-test LUTs do not get trimmed?Article: 99010
fpga_toys@yahoo.com writes: > My family is from the show me state .... and I'd like to see the > numbers behind the spin that testing is responsible for a 25-80% > savings over a 50K FPGA order converting to easypath. I work for a fabless semiconductor company (though I'm not speaking for them), and I can confirm that testing is expensive. Sometimes after a product has already been in production for a while, we're able to come up with a new set of test vectors that provides the same coverage in less time, and this *significantly* reduces our costs. Every second a part spends on a tester costs real money, and a big FPGA probably spends a LOT of time on a tester. I'd be surprised if Xilinx didn't employ a fair number of engineers whose entire job is optimizing test vectors for high coverage in short test time. EricArticle: 99011
Jakob wrote: > Hello Everyone, > > I am currently investigating my options for designing the power supply > part for an imaging application. The FPGA that I had in mind, because > of its small footprint and its availibility was the XC3S400. Because I > can't and don't want to make any assumptions about the utilisation of > the device at this point, I will probably have to design for the worst > case. >>From http://www.xilinx.com/products/design_resources/power_central/ I > figured that I will probably need around 3A for the core, something > like 2A for the I/O and a low-ripple 0.3A for the auxilliary rail. > Because I am a software engineer gone electronics, my knowledge on > power supply design is rather limited at this stage. > The device itself will be battery powered at around 11.6V, and I would > like the power supply part to be as small as possible. The efficiency > is also not that crucial, as long as I won't have to provide cooling. > Because its only a prototype cost is not an issue (within reason). Also > I might need to add, that the 11.6V could be quite noisy as there are > DC motors connected to it. My first shot was the TPS75003 from TI as it > has all three rails integrated. However, it only operates on <6.5V Vin. > I've had a look at the other manufacturers and feel a bit lost know. > Because some other parts of my design will also require 5V, should I > step down from 11.6V to 5V and then use something like the TPS75003? Or > would it be better to have four rails all going down from 11.6V. What > are my best options to keep the design small? Which bits do I need to > be careful about? > > Any suggestions on the design or where I could get some additional > information would be greatly appreciated. > > cheers, > > Jakob Austin's suggestions were great. I'd add that if you want to build only a few, the 12V compliant switcher modules for each rail (and a linear for the VCCaux) is a great suggestion. If you want to put together enough devices that 1) you don't want the expense of the modules and 2) you don't want to bring in the expertise for the multi-rail, 12V tolerant optimized design selection then your idea of regulating to 5V and then further to the rails would work nicely; the efficiencies are poorer than direct conversion but there's "ease versus specs" to consider in your situation. The TPS75003 was listed at $25 for an eval board. When I went to buy one, it was $10. So I bought three. You should be able to prototype things pretty quickly.Article: 99012
Yes, Eric, testing is expensive. But the most important savings for EasyPath are not the reduced test times, but rather the much higher yield. The math is really simple: If the "perfect" yield for a specific very large chip is 50%, then if half of the resources are unused and thus need not be tested, the yield will be 75%. If 90% of the resources are unused (happens quite often) and untested, the yield will be 95%. Always assuming random fault distribution. This also shows that EasyPath makes little sense when the fundamental yield is already 80% or higher. Of course there are other cost factors, like packaging, marking, selling etc. But the fundamental idea is really clever. I wish I had thought of it... Peter Alfke, from homeArticle: 99013
sarnaths@gmail.com wrote: > Hi, > What I have noticed is that when I try to implement this design > through Xilinx ISE, the MAP process does not consider the LUTs under > test and thus removes them from the design. > Has anybody encountered this before? And if so, do you have any > suggestions on how to ensure that my circuit-under-test LUTs do not get > trimmed? To "keep" logic from being combined, i.e., to "keep" signals from disappearing, try using the "KEEP" attribute. In vhdl: attribute keep : string; attribute keep of signal_name: signal is "true"; HTH, JohnArticle: 99014
fpga_toys@yahoo.com wrote: > Good points Ray. > John, It appears to me that perhaps you are assuming the yeild is high, more than 50% anyway. What happens to your assumption if the yield is more like, say, 10-20%. It seems to me that the lower the yield, the more attractive easypath becomes, especially if, as Austin indicated, most yield fallout is only one defect. That aside, coming up with an end user test to find and isolate the faults is not as trivial as it may seem. Remember, the LUTs and other assets on the FPGA are only a very small percentage of the total circuit. The lion's share of the chip is dedicated to routing resources, which are a bit harder to test and isolate than the luts are for a time constrained test vector suite. The good news is that it is quite rare for an FPGA that tests 100% good to fail internally in the field, so once defects are mapped, the map should be good from then on. still, developing a set of configurations to test every route, every routing switch box, etc in a device is a daunting task by itself. It is several times harder if you then have to isolate the exact failure. Maybe if you have enough spare cycles in your RC system, you can do that in the background and hope you don't hit a defect in operational builds before the defect map for the system is completed. The current tools make this even harder since the user has little control over the what routing resources are used (there's directed route, but it is tedious to use and is a largely manual effort), and even less control over what routing resources can't be used. Granted, this is a tools issue more than anything else, but the fact remains that with the current state of the tools, I don't see this as feasible right now. Yeah, I know, this supports your contention that the tools should be open. Look at it from Xilinx's point of view though. What is in it for them? More software that would need development and testing, more user support, devices with defects out on the market that could wind up in the hands of people thinking they have zero defect devices, not to mention their increased testing and administration cost to even partially map the defects, or even determine to what degree the part fails. I can see where the cost of doing it could exceed the potential benefit. If it were profitable for them to do it, I'm sure they would be pursuing it. In any event, it is a business decision on their part; one they have every right to make. Anyway, it still seems to me that the amount of extra work to manage parts with defects would cost more than the cost savings in the part prices not just for XIlinx, but also for the end user.Article: 99015
John- Well I can feel the heat building... but I would venture to say that several of the engineering Yahoo Groups, plus my own engineers, have taught me there really is an emerging consistency and 'normalness' to the shorthand. If key tech words, names, and acronyms are misspelled, then yes that's bad and not excusable. -JeffArticle: 99016
Jeff, the "older generation", especially when brought up with a Europen and thus more rigorous education, with Latin and a couple of foreign languages thrown in, finds this kind of misspelling "cancer on the eye", as somebody else mentioned. Personally, I even cringe at "lite" and "thru". So, as long as you guys are interested in learning from us older folks, let's stay with "King's English", or the American derivative. Once we are 6-feet below, you can bastardize the spelling and the language to your heart's content. A few hundred years of literature be damned... Peter AlfkeArticle: 99017
I think I read somewhere that it is possible, but can't find it now... I tried assigning the pins in ucf, but map failed. Can someone point me in the right direction? Thanks, /MikhailArticle: 99018
fpga_toys@yahoo.com wrote: > Good points Ray. > > Ray Andraka wrote: <snip> > > For more mainstream production use, I suggested that the go-nogo > testing of the part look for errors in 16 sub quadrants, and bin parts > failing to each. That would allow purchasing a run of parts which all > had different failures in the same sub quadrant, and the rest of the > die was known good and usable. That is much more manageable, without > creating too many sku's. Yes, getting more managable, and the new Xilinx strip-fpgas could lend themselves to this - but you still need some audit-trail to link the defect to the part = so this really needs FPGAs with fuses. (not many, and they can be OTP, but fuses nonetheless) >>5) Timing closure has to be considered when re-spinning an FPGA >>bitstream to avoid defects. In dense high performance designs, it may >>be difficult to meet timing in a good part, much less one that has to >>allow for any route to be moved to a less direct routing. > > > Certainly. I've suggested several times that RC applications may well > need to actually assign clock nets at link time based on the nets > linked delays, and choose from a list of clocks that satisfy the timing > closure. I have this on my list of things for FpgaC this spring, along > with writing a spec for RC boards suggesting that derived rising edge > aligned clocks be implemented on the RC board covering a certain range > of periods. That would allow the runtime linker (dynamic incremental > place and route) to merge the netlist onto the device, and assign > reasonable clocks for each sub-block in the design. This is necessary > to be able to reuse libraries of netlist compiled subroutines for a > particular architecture, across a number of host boards and clock > resources. > > A very different model of timing closure than embedded designs today. Another path, would be to do runtime checking of results, and have a 'bad answer' system, that remaps the problem to known good ALUs. This would require good intital tester code, which could, as suggested, also run in the downtimes. That way you can use lower yield devices, but not have to know explicitly ( at P&R time ) where the defects are. Of course, a method to tell the P&R to avoid known 'FPGA sectors' would also improve the RC yields, so a two-pronged development would seem a good idea. Perhaps there are features in the new Virtex 5 that would help this ? [Should be a good supply of low yield parts, as they ramp these ! :) ] -jgArticle: 99019
In article <1142667911.725607.103910 @u72g2000cwu.googlegroups.com>, coolsaroj@gmail.com says... > bcoz neither of the generations is > having mutual respects for each other. I would like to add to my previous response that purposely butchering the english language with misspellings like "bcoz," in a forum where proper english is the accepted norm, does not command any respect. Period. Generations have nothing to do with it. I have no problem with people who don't speak english as their native language trying to post in english and doing a bad job of it. After all, I don't speak any other language well enough to even attempt to type out a message such as this in anything but english. I have no problem with the occasional accidental typo. I don't even get worked up about common errors like people who don't understand when to use "then" vs. "than." I usually consider it bad form to correct these sort of things unless you are actually having a discussion about grammar or language or spelling. But nobody, not even non-english speakers, has ever misspelled "because" as "bcoz" unintentionally. And intentional misspelling like this commands no respect. Keep it in your cell phone text messages where there is a good reason for abbreviations.Article: 99020
What are you trying to do? If you're not using the DQ pins for a memory interface then treat them as standard I/O. <v_mirgorodsky@yahoo.com> wrote in message news:1142707551.809050.269660@u72g2000cwu.googlegroups.com... > Hello Rob, > > Dedicated DQ pins on Altera Cyclone II package have very strange > placement and I am curious about the reason those pins are called DQ. > In other words, does DQ pin have any significant difference from the > adjacent non-DQ pin in the same bank on Altera EP2C8F256 package? > > With best regards, > Vladimir S. Mirgorodsky > > > Rob wrote: >> The DQS signal is usually associated with a group of data (DQ) pins; so >> where ever the DQS >> singal is you want the associated DQ pins located in close proximity. >> Also, some DDR2 I/O >> standards, like SSTL-18 class II, are only supported on two sides of the >> chip. >> >> <v_mirgorodsky@yahoo.com> wrote in message >> news:1142694593.123202.188480@v46g2000cwv.googlegroups.com... >> > Hello group, >> > >> > I have an issue with porting my high-speed DDR interface to Altera >> > Cyclone II device. As far as datasheet says, Altera Cyclone II device >> > does not have any dedicated circuitry to support DDR signaling in its >> > Input/Output blocks for DQ pins. The only thing present in hardware is >> > the clock delay circuitry on DQS pins. All other DDR logic is >> > implemented using LUT's and triggers from adjacent Logic Array >> > Blocks. So, it seams that we have only DQS pins location fixed, >> > whenever all other DDR pins may float within the selected IO bank. Is >> > that right? If yes, then what is the reason to denote certain pins on >> > the Altera Cyclone II package as dedicated pins for DQ input/outputs? >> > >> > With best regards, >> > Vladimir S. Mirgorodsky >Article: 99021
MM wrote: > I think I read somewhere that it is possible, but can't find it now... I > tried assigning the pins in ucf, but map failed. Can someone point me in the > right direction? > > Thanks, > /Mikhail Yes you may use an MGT clock as a global clock input. You need to put a LOC constraint on the GT11CLK instance as well as the pins. Then take the column clock and run it through a BUFG, then you can use it as a global clock. Regards, John McCaskillArticle: 99022
austin wrote: > Rick, > > I have apologized to you. I am not the one that you attacked. When I initially said I find your post insulting, I didn't mean it insulted me. I meant that it appeared to be insulting the person you were responding to. What you call gentle poking was really a way of demeaning his comments and attacking him on a personal level without offering a single factual response to his statements. Do you not see what I mean? > As for Xilinx management, I am often called before my boss, my boss' > boss, and so on, and occasionally talk to Wim. > > For any number of reasons. > > I have been advised, admonished, counselled, re-trained, instructed, and > so on. > > I have also been congratulated, celebrated, awarded, and recognized by > others for my help and advice. > > I have no issues or problems with my management, and I value their > opinions, and advice. We have vey open communications at Xilinx. > > As Peter said, Xilinx is not a dictatorship. > > If you feel I am doing something wrong, then email my boss and make him > aware of your concerns. I could care less about your managment of internal affairs. I probably should not have bothered to post since it seems to be falling on deaf ears. I thought you might be interested in how your posts are perceived. But then it is easy to rationalize my complaint as being out of the mainstream as long as you only consider your internal company perspective as mainstream. > The newsgroup is read by many internally, and I post knowing full well > that Wim may be reading it. Fortunate for me, he also has a sense of humor. > > There are unpardonable sins (for which you are dismissed), and it is > very clear what those are. And those all relate to issues that are > either ones where you break the law, or are giving away Xilinx IP and > secrets. As a member of Xilinx' patent committee (I read every single > disclosure) I am extremely sensitive to those issues, and help police > our IP. > > There are also guidelines, and one of my favorites is the customer is > number one, top of the list. I created the Xilinx fast action response > team procedures for acting on unsolved customer issues, and was the > first "Fire Chief." > > I have been in rooms with CEOs, CTOs, CFOs, and so on. > > I don't take any disrespect, and I tell the truth. You may not take disrespect, but you are quick to dish it out. Go back to the post from Metal and your reply and tell me how you expect someone reading it to consider that a respectful post. No, I said that poorly. I don't want to hear from you about it. If you really care about what I am saying, read the post and consider it until you can see why I have posted about it. But you don't need to respond to me here or directly. I am over this and you won't hear from me on this further. > So, just because the customer is number one, doesn't mean I accept > disrespect, or abuse. When that occurs, I am not afraid to stop the > discussion right there, call "foul", and attempt to get things back on > track. > > And, I do have my own personality, my own sense of humor, and my own way > of communicating (and writing). I accept that it may drive some nuts. I don't see how you calling "foul" has anything to do with your reply to Metal and how it appeared disrespectful. You weren't calling foul, you were dismissing his statements as being unimportant enough to even deserve a real reply as well as appearing to insult him on a more personal level. Just look at all the rambling, irrelevant statements you have made in this reply. I think it is clear that you consider your own opinions far more valuable than anyone's comments on how you are perceived. > Again, my apologies. No need to apologize to me. You are just being yourself, right? Enough said. Take my comments or leave them. I don't think I can add anything further that might be useful.Article: 99023
Isaac Bosompem wrote: > Chauhan wrote: > >>Well the above post was adressed not 2 u but 2 JJ definetly.Sorry for >>giving u headache. > > > No offense to you man, but I am a student as well. You must understand > how important it is with communication. I read somewhere that the > biggest problems with engineering grads is that they can not > communicate effectively. This means poor writing or language skills. I > do chat as you do with my friends on MSN, but when I come to post here > I use proper English and sentence structure (well try). Just use proper > structure and think of it as practice for your future career (perhaps > you will stand out from the rest) :). > > Plus a lot of the posters here are from a different generation, it is > likely they will be unable to comprehend what you are saying. > > -Isaac > Isaac, That is excellent advice. It is sad to see people communicating in this sort of abbreviated phonetic street English when they could be developing their basic communication skills, as you suggest. Colonial powers introduced Pidgin English in an attempt to restrict the concepts that could be communicated by the natives. It is tragic to see a version of it so readily adopted by a whole sub-culture. As a person from a 'different generation' I don't agree with you that we are 'unable to comprehend' the texting garbage now used in some postings. I find that it is possible to work my way through this stuff, and that with some effort I can generally work out what the writer is trying to say. The problem is that it is a tedious process, and I am tempted not to bother. This abbreviated English used by these posters does have some benefits to them. It can disguise the fact that they can't spell, it shows that they are 'cool' and it is easier to type, if they are using a cell-phone. When a person posts in this form they are communicating in the way which they apparently find most convenient personally. Unfortunately it appears that they simply can not be bothered communicating in the way which best suits their audience; the people whose help they are seeking. The naive arrogance behind this is a matter of continuous wonderment to me. Regards, JohnArticle: 99024
Thanks John. "John McCaskill" <junkmail@fastertechnology.com> wrote in message news:1142736108.169017.222450@i40g2000cwc.googlegroups.com... > > MM wrote: > > I think I read somewhere that it is possible, but can't find it now... I > > tried assigning the pins in ucf, but map failed. Can someone point me in the > > right direction? > > > > Thanks, > > /Mikhail > > > > Yes you may use an MGT clock as a global clock input. > > You need to put a LOC constraint on the GT11CLK instance as well as the > pins. Then take the column clock and run it through a BUFG, then you > can use it as a global clock. > > > Regards, > > John McCaskill >
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