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
On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote: >Hi, > >I've been working a couple of designs and have heard that "your design >really should be fully contrained" to acheive the best results. Can >someone give me a good definition of what fully constrained means? Are >they implying that I should provide timing contraints for every net in >my design? > Hi - That's what it means to me: every path, "critical" or not, is covered by a timing constraint. In the Xilinx world, it means that, when you run trce (the static timing analyzer) with the -u option, it reports no unconstrained paths. Why would anyone bother constraining paths that are completely non-critical? The idea is to avoid the embarrassing situation where you overlook a single report of a path that doesn't meet timing because it's buried amidst hundreds or thousands of reports of unconstrained paths that don't matter. Constraining all paths also eliminates the possibility of the router creating a very, very long delay on a path where just a long delay would have been OK. Constraining all paths can be something of a pain in the butt, but it's not as bad as it sounds. You can often place constraints on large sets of paths, rather than on individual paths. Take care, Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.cambriandesign.com Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 24801
We have a number of legacy designs that incorporate Xilinx'x XC4000 series device. The new Alliance tools do NOT support the XC4000 series. Any thoughts how I can persuade Xilinx to add XC4000 support to their Alliance tools. Ironically, the data bitstreams generated from the old XACT tools work in both the XC4000 and the new XC4000E series. Xilinx no longer supports the old XACT tools. Seems like Xilinx have left many of their customers in a bind. Thanks in advance..Article: 24802
Multiply by 8x? > The answer is NO. > There are four DLLs in Virtex devices, but to multiply by 2 you need at > least two BUFGs (if the source clock is external, one could be IBUFG). > Because the CLKIN input of CLKDLL must be driven by a BUFG, you can > only drive one more CLKDLL and you are out of BUFGs. Also keep in mind, > that the frequency range for CLKIN of CLKDLL is 25-90MHz and for > CLKDLLHF is 60-180MHz. Don't forget also the fact, that you can only > use BUFGs to connect to CLKDLLs from the same side of the chip. You can (I think, DLL rules are of Super-Byzantine complexity and they add new constraints every 2 months or so) multiply by 2 or 4 on one side of the Virtex and drive the resulting clock out on an OBUF and take it back in on the other side to multiply by 4 or 2. If you use Virtex-E you don't have to use a GCLK pin as a DLL clock input. Watch the phase noise though, the spec is tight and every stage adds some jitter. You may be out-of-spec doing x8. Alun CamdigitalArticle: 24803
Means the same thing to me too, Bob. Well put. Constraining the non-critical paths (like multi-cycle paths, or 'static' signals, like a writeable register) will help routing, as the router will know how hard it has to try on each net. The other advantage of doing complete constraints is you do not need to do timed simulation. Providing your constraints are correct, and your design meets this timing, your functional simulation will give you all the simulation you need. When constraining every net, you can group them, if you have one module that every input or output to/from it have the same time spec, or every one internal to that module, you can use a wild-card timing constraint like FROM:FFS(FRED*):TO:FFS(FRED*) and that will constrain everything in that block to that TIMESPEC. Or, FROM:FFS(FRED*):TO:FFS(*)...etc. Yet another advantage, is you readily know what didn't make timing... Bob Perlman <bobperl@best_no_spam_thanks.com> wrote in article <fd5rps013bckun9rkjbpaobn976vq210ut@4ax.com>... > On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote: > > >Hi, > > > >I've been working a couple of designs and have heard that "your design > >really should be fully contrained" to acheive the best results. Can > >someone give me a good definition of what fully constrained means? Are > >they implying that I should provide timing contraints for every net in > >my design? > > > > Hi - > > That's what it means to me: every path, "critical" or not, is covered > by a timing constraint. In the Xilinx world, it means that, when you > run trce (the static timing analyzer) with the -u option, it reports > no unconstrained paths. > > Why would anyone bother constraining paths that are completely > non-critical? The idea is to avoid the embarrassing situation where > you overlook a single report of a path that doesn't meet timing > because it's buried amidst hundreds or thousands of reports of > unconstrained paths that don't matter. Constraining all paths also > eliminates the possibility of the router creating a very, very long > delay on a path where just a long delay would have been OK. > > Constraining all paths can be something of a pain in the butt, but > it's not as bad as it sounds. You can often place constraints on > large sets of paths, rather than on individual paths. > > Take care, > Bob PerlmanArticle: 24804
Christophe, It seems to be a waste of the resources, not to mention to use of most of the global clock buffers, but there is no rule against cascading X2 DLL's until you run out of routing resources. Resultant output jitter from each stage is not strictly additive (jitter never is, unless you have a poorly designed element). Jitter tends to add as the square root of the sum of the squares (to a first approximation). The input jitter tolerance allows for this kind of cascading. We do try to think of all possible uses, no matter how strange or useless they appear to us initially. My 10 years on the US ATIS T1X1 Committee as a synchronization and timing expert gives me some insight into the problems of phase noise (jitter, wander). Since the DLL has been introduced, we have characterized its ability to track phase buildouts (as in switching between two clock sources of slightly differring frequncies as filtered by a preceding PLL), and looked at its ITU-T Jitter tolerance, jitter transfer, and residual jitter spectral energy (e.g. G823,824, etc) for our telecoms customers. For further details please contact me (email) directly at austin.lesea@xilinx.com. The DLL's span of input/output frequencies is so wide that no equipment exists to make the measurements we require, so we have to do these tests on a case by case basis with highly specialized setups. Customers tend to use many different 'magic' frequencies: 32.768 MHz, 38.88 MHz, 33 MHz, 66 MHz, 100 MHz, 133 MHz, 77.76 MHz, 155.52 MHz, to name only a few. Austin Christophe Heyert wrote: > Hi all, > > I was wondering if it is possible to use the Virtex Dll's to create a > clock multiplied by a factor 8. > The application notes only discuss clocks multiplied by 2 or 4. > Thanks... > > ChristopheArticle: 24805
I run into this from time to time with customers. You can't blame Xilinx for not wanting to re-write the software to support old chips they no longer sell, and haven't in about 5 years. (the M tools are a completely different set of code than the old XACT tools, even to the point that they were done by entirely different groups). That said, Xilinx has been touting one of the benefits of using SRAM based FPGAs in products is that it extended the tail end of the product lifecycle by allowing upgrades to fielded products. Can't do that too well if you don't maintain the tools to modify the design. Basically, that means keeping a machine, the software and the dongles on hand for older designs if you anticipate doing maintenance on them after the chip family expires on the marketplace. The extended lifecycle is real, but it ain't free and it does require you to have some foresight when you archive it as you are now finding out. At some point, it becomes cheaper to spin a new product based on new parts. When that point occurs depends on your threshold of pain. Still, it would be nice for them to continue to make available software along with minor upgrades to allow it to work on current machines (even if in a DOS box). Joe wrote: > > We have a number of legacy designs that incorporate Xilinx'x XC4000 > series device. The new Alliance tools do NOT support the XC4000 series. > Any thoughts how I can persuade Xilinx to add XC4000 support to their > Alliance tools. Ironically, the data bitstreams generated from the old > XACT tools work in both the XC4000 and the new XC4000E series. Xilinx no > longer supports the old XACT tools. Seems like Xilinx have left many of > their customers in a bind. > > Thanks in advance.. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24806
I haven't had any luch making these work, and sure as heck haven't found *ANY*
documentation on them. Bret, care to give use more details, pointers to the
documentation or anything? Can these be put in the netlist instead of in a UCF
(they are next to useless in the UCF)??
in article <394A5A8D.E26477CC@xilinx.com>,
Bret Wade <bret.wade@xilinx.com> wrote:
>Hello Jon,
>
>Version 3.1i supports a BEL constraint for Virtex. Here's and example of
>UCF syntax:
>
>INST inst_name BEL = {F, G, FFX, FFY, XORF, XORG} ;
>
>You use RLOC/LOC/BLKNM etc. to determine the slice used and the BEL
>constraint to determine the BEL within the slice.
>
>Regards,
>Bret
>
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com or http://www.fpga-guru.com
Article: 24807On Fri, 18 Aug 2000 08:27:04 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >eml@riverside-machines.com.NOSPAM wrote: >> >> On Wed, 16 Aug 2000 16:30:45 -0500, Paul Smith <ptsmith@indiana.edu> >> wrote: >> >> >It looks like the Mentor FPGA Advantage suite (Renoir, ModelSim, and >> >Leonardo) will work for me. Anyone out there have experience with this >> >toolset for the Spartan II target? >> > >> >I assume I also need the Xilinx Alliance software? >> >> You can't go wrong with ModelSim and Spectrum but, as for Renoir, >> forget it unless you're a masochist and you've got lots of spare time. >> If you need schematics, try to find a proper schematic tool you can >> fit into your design flow. You'll need Foundation or Alliance as well. >> >> Evan >> >> PS: Ok, Mr. Mentor, that wasn't too bad, was it? I trust you won't be >> mailing me about this.... :) > >I take it from the PS that you have gotten mail from someone at Mentor >about your newsgroup postings? Have you had unpleasant experiences using >the Mentor toolset? Someone complained in comp.lang.vhdl recently that Mentor had tracked him down from a newsgroup posting, and then complained to his employer. Very dubious, to say the least. I haven't personally had any problems. I've got no gripes with the toolset, apart from the one I mentioned above. EvanArticle: 24808
On Fri, 18 Aug 2000 13:10:52 -0700, Bob Perlman <bobperl@best_no_spam_thanks.com> wrote: >On Fri, 18 Aug 2000 17:31:52 GMT, beerbaron@my-deja.com wrote: > >>Hi, >> >>I've been working a couple of designs and have heard that "your design >>really should be fully contrained" to acheive the best results. Can >>someone give me a good definition of what fully constrained means? Are >>they implying that I should provide timing contraints for every net in >>my design? >> > >Hi - > >That's what it means to me: every path, "critical" or not, is covered >by a timing constraint. In the Xilinx world, it means that, when you >run trce (the static timing analyzer) with the -u option, it reports >no unconstrained paths. And remember that, in general, it's not possible to get trce to report "100% coverage" even if there aren't any unconstrained paths. EvanArticle: 24809
Does anyone know how to do floorplanning using the Xilinx Student
Edition software? I am trying to improve the performance of a HDL design I
am working on using an Xess FPGA board.
Thanks,
T.Swift
Article: 24810rickman wrote: > Darren Kuhn wrote: > > > > "Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message > > news:966555960snz@amleth.demon.co.uk... > > > In article <8ngv2n$o0l$1@news.drenet.dnd.ca> > > > qn42@hotmail.com "Darren Kuhn" writes: > > > > > > > > > > I find this all kinda interesting considering I find myself on the > > opposite > > > > end of the scale, if I was to go for an interview I wouldn't be able to > > talk > > > > much about my abilities/areas of work because of the security issues > > > > involved in my present work...and I doubt they would sign a NDA from me. > > > > > > Should you be talking about such issues without authorisation from your > > > current employer? So, if you cannot talk about your current work how do > > > you convince someone else you are worth employing? > > > > > > > I wouldn't know as I haven't been looking for a change of venue. What I do > > know is that I can tell you the software/hardware systems that I work on, > > just not what I do with them. > > I have done a lot of government work over the last 20 years and I have > never been restriced in discussing the technical issues of my job. Only > the application and system level issues which may reveal application > details. > > This is in contrast to the commercial jobs I have had where the high > level stuff is very much open and the details are often confidential. > > To Paul, > Darren said NDA, not NSA ;') > > -- > > Rick Collins > > rick.collins@XYarius.com > > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com Although I empathize with your discomfort about the NDAs, there are many additional issues in interviews and employments that one could be uncomfortable about. The basic result is that if you are interviewing with a well-regarded company, which appears to be the case, this behavior over NDAs will go against your chances of being employed by that company. Frankly, if you are interviewing with good companies, do not worry about it. Expecting your interviewers to hand you documents of what should not be disclosed seems a particularly counter-productive effort. I would say it is a common truism that people in business managment are much more paranoid (whether justified or not) about these things than the typical employee and that NDAs among many other things are merely an expression of that paranoia. There is likely some correlation between high-paying companies and degree of reasonable management paranoia. I.e., economic advantage is, by definition, something that you have that other people do not, and hence these businesses are trying to keep what they have to maximize their economic advantage. The critical period for these kinds of agreements occurs after you have been employed for a while and actually find out the interesting details. If the paranoia holds true-to-form, you may expect additional consideration based on the business' need to minimize the likelihood of your movement to another, say, competing company. But you have to get employed first. You might be God's gift to mankind for your particular skill area, but your attitude seems to be a bit combative and arrogant, and it will restrict your employment opportunities to the less desirable jobs in terms of pay and status. It is a common failing of technical employees. Also, the good jobs will tend to appear early in an interviewing cycle with those less desireable trailing behind. Plus you commonly only get one slim chance with each company. If you actually need a job, you need to stop screwing yourself and get politically savy. And it is quite easy to search the newsgroups by poster name to find out a person's attitudes and opinions. Otherwise, it has been a very interesting thread. Regards, Neil NelsonArticle: 24811
Hal Murray wrote: > > I frequently see comments here about silicon getting faster > so metastability is less of a problem. Is that really correct? > > Are there other mechanisims that work the other way, such as > chips getting bigger and clock cycle times getting shorter? > Have we come full circle with computers? In the 1950's you had large boxes connected with slow cables. The logic in the boxes was tiny but fast. Memory was slow random access or sequential delay line or drum. Word length was long with very simple addressing modes - direct,memory indirect,or stack to a single accumulator. With ps logic and ns routing delays in FPGA's we are back to fast logic but small amounts. Risc archtecture has the style of the early machines with 3 operand fields. Static memory is slow ( compared to the internal speed of the chip). Cache memory loading from dram reminds me of a small drum. Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24812
i'm not sure if the graphical floorplanner is in the student edition or not. If it is, you'll find floorplanner.exe under the bin directory. If it is, then just run floorplanner and have fun. If not, then you'll have to do floorplanning the old fashioned way with graph paper and putting RLOCs in your source or in a UCF (constraints) file. The constraints are documented in the libraries guide in the on-line documentation. "T.SWIFT" wrote: > > Does anyone know how to do floorplanning using the Xilinx Student > Edition software? I am trying to improve the performance of a HDL design I > am working on using an Xess FPGA board. > > Thanks, > > T.Swift -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 24813
"T.SWIFT" <NOSPAMeconspeak@quinnet.com> wrote in message news:QuDn5.558$gM4.197667@dfiatx1-snr1.gtei.net... > Does anyone know how to do floorplanning using the Xilinx Student > Edition software? I am trying to improve the performance of a HDL design I > am working on using an Xess FPGA board. I assume you are using F1.5i. If you use schematics, you can attach RLOC attributes to primitives like FDCE, to gate expressions via an FMAP, and to macros built up of same. Since you use synthesis, you are out of luck. That version of FPGA Express doesn't pass attributes. Later versions (e.g. in F2.1i, e.g. FPGA Express 3.x for some x) do, but they unhelpfully absorb FMAPs (see www.fpgacpu.org/usenet/rope_pushing.html). (Has this been fixed yet?) In the Verilog version of the XSOC/xr16 project (www.fpgacpu.org/xsoc) that is built with XSE F1.5i FPGA Express, I studied the XNF coming out of FPGA Express, observed that registers and RAMs were given repeatable names, and floorplanned those parts of my design using an external UCF file. For example: INST vga_sr_reg<0> LOC=CLB_R14C1; INST vga_pending_reg<0> LOC=CLB_R14C2; INST p_dp_aregs_r0 LOC=CLB_R14C3; INST p_dp_areg_reg<0> LOC=CLB_R14C3; INST p_dp_bregs_r0 LOC=CLB_R14C4; INST p_dp_breg_reg<0> LOC=CLB_R14C4; INST p_dp_a_reg<0> LOC=CLB_R14C5; INST p_dp_b_reg<0> LOC=CLB_R14C6; INST p_dp_dout_reg<0> LOC=CLB_R14C7; INST p_dp_pcs_r0 LOC=CLB_R14C12; INST p_dp_ret_reg<0> LOC=CLB_R14C12; INST vga_sr_reg<1> LOC=CLB_R14C1; INST vga_pending_reg<1> LOC=CLB_R14C2; INST p_dp_aregs_r1 LOC=CLB_R14C3; INST p_dp_areg_reg<1> LOC=CLB_R14C3; etc. for another 200 lines or so. It was a kludge but it helped. This partial floorplanning shaved several ns off the cycle time, but it was still 25% slower than the properly floorplanned schematic version. Unfortunately it is awkward to floorplan synthesized *logic* and to apply timespecs (tpthrus) to certain *nets* that get turned to mush by synthesis. Sometimes you can place the code in question in a separate module, synthesize retaining hierarchy, and then use wildcard 'INST base/mod/* LOC=<range>' to lock a module down to a certain region. Jan Gray Gray Research LLC www.fpgacpu.orgArticle: 24814
On Sat, 19 Aug 2000 15:05:48 -0700, Neil Nelson <n_nelson@pacbell.net> wrote: >Although I empathize with your discomfort about the NDAs, there >are many additional issues in interviews and employments >that one could be uncomfortable about. This is true, of course. However, high tech folks usually aren't lawyers, as well. And I've once experienced what perceptions over an NDA can do to otherwise good relationships in a circumstance where, without the NDA, the results would have been far better for all. NDAs at interview time seem unnecessary to me. There is little reason for this kind of "preemptive salvo" on the part of the potential employer -- since they don't even know the interviewee, yet. They have no evidence that this person has anything other than good intent. And they are perfectly capable of, and should be, of controlling the interview so that their proprietary concerns are not revealed on their first contact. If there is a follow-up, and if they are serious at that point and believe that getting closure necessarily entails a disclosure, they can sit down beforehand and write up a short list of those things they intend to cover that they think is important to help the interviewee make final decisions in their favor. It is good practice, in fact, to think these things out a little beforehand, in any case. And once that thought takes place, it is relatively easy to then transfer that information onto an addendum of an NDA that provides a precise expectation. Precisely written expectations and understandings should be required before signing a legal document, anyway. >The basic result is that >if you are interviewing with a well-regarded company, which >appears to be the case, this behavior over NDAs will go against >your chances of being employed by that company. If that is the only company you intend to pursue, you'd want to do everything in your power to "make them happy." I'm certain that's true. But that is not the place an interviewee should be at, on first contact. They aren't bending over backwards to get approval at any cost. They should be in a position of balanced negotiation. Frankly, I'm sure that Rick Cole is no one's idiot and is not in a position of begging for a handout. He should act as an equal, not a beggar with hat in hand. It is irrelevant if something "goes against your chances." If that's the case, and it may be, it's just not your problem. It's theirs. Once you place yourself in the position of doing whatever it takes to make everyone else happiest without self-regard, you will be a slave. May as well put the shackles on and be done with it. >Frankly, if >you are interviewing with good companies, do not worry about it. There is truth to this. Most good companies aren't going to go "ballistic" over trivia. But I've seen too many times where some within otherwise good companies can easily "get a bee in their bonnet" over some perceived harm where none was likely or intended. And it soured much in the process, where 20-20 hindsight showed me that it was an unnecessary waste. Never underestimate how easily hurt feelings can arise over nothing at all and what irrational actions that pain can engender. There's no real need to start out by creating a vague document that allows such to occur, particularly when there's nothing going on in the interview to require such protections. Don't forget that Rick mentioned that the 1st interviewer noted that they didn't intent to disclose information requiring protection. I believe that, too. But the document could possibly be interpreted by others who weren't present at the interviews, later and in different circumstances, as making Rick out to be a "bad guy." For an initial interview, this kind of creation of risk just isn't needed. At least, I've not seen a case yet in my 30 years experience where I believe so. Perhaps you could make a case for it? >Expecting your interviewers to hand you documents of what >should not be disclosed seems a particularly counter-productive >effort. Why, exactly? They do not have to hand over detailed descriptions of the exact disclosures. But an interviewee has every right to expect a very clear understanding of exactly what a company intends to discuss that it will later consider important, if they should go to court. How can an interviewee properly protect their interests if it isn't spelled out? Can they read minds? No. There is exactly no counter-production in insisting on clarity. I'm speaking from direct experience in these matters, as I suppose you are. But I cannot see why an addendum cannot be prepared, if there is material to protect. In any case, interviewers are in a position of power. They have the attorneys prepare the NDA for their own protection, they are considering the offer of substantial paychecks and this means that they have the potential of significantly directly impacting your life, and they often are vested with far more resources than the interviewee. They may also have proprietary interests to protect, sometimes more than the interviewee does (although I have to say that I've had to prepare documents to protect my own interests before joining companies, as well.) They can afford the bit of thought it takes to provide a fair statement of expectations that are clear enough that the interviewee can properly adhere to them. Blanket statements won't cut it. >I would say it is a common truism that people in business >managment are much more paranoid (whether justified or not) >about these things than the typical employee and that NDAs >among many other things are merely an expression of that >paranoia. There is likely some correlation between high-paying >companies and degree of reasonable management paranoia. I.e., >economic advantage is, by definition, something that you have >that other people do not, and hence these businesses are trying >to keep what they have to maximize their economic advantage. >The critical period for these kinds of agreements occurs after you >have been employed for a while and actually find out the >interesting details. If the paranoia holds true-to-form, you may >expect additional consideration based on the business' need to >minimize the likelihood of your movement to another, say, >competing company. But you have to get employed first. It's also often that, not understanding the technology all that well, they think everything under the sun is theirs and theirs alone and that they have to fight tooth and nail in a competitive arena where all the gloves are off. They are probably right about that part of it. But many business managers have no idea what is "theirs" and what isn't and they think that if anyone decides against them as an employer and then joins one of their competitors, that they must disclose important details as a course of doing their job there. They assume that since they themselves would certainly "do what was necessary" and "cheat and steal", that others would intentionally do so too. Or that if they don't do it on purpose, that they will accidently do it. So they then decide they have to pre-emptively bring suit just to prevent the very employment, to mitigate their risks. It's nasty, the human ability to feel that others are disloyal or out to get you. But it's also not uncommon, it seems. Starting out with a blanket NDA without precision and a clear expression of expectations is a sure fired way to help fire up these feelings at some point. Clarity helps a lot to keep a clearly defined and rather objective set of criteria that both sides can keep to. There is no harm at all in struggling to get that understanding. My own feeling is that the 1st interview is NOT the place for that extra effort, though. Perhaps when the first hurdle is crossed and it's a matter of getting closure on the decision to employ, then the effort is worth doing. But in all cases, precision makes sense. >You might be God's gift to mankind for your particular skill area, >but your attitude seems to be a bit combative and arrogant, and >it will restrict your employment opportunities to the less desirable >jobs in terms of pay and status. I didn't see any arrogance in Rick's comments at all. He was very considerate, in fact. He was watching out for his own interests, a bit, asking for an addendum to be included later. But this is more than reasonable. If it is your belief that an interviewee should be unreasonably deferential, passive, meek, and obsequious, I think you are asking far too much. There is a limit to such pandering. >It is a common failing of technical >employees. There is balance in everything, of course. Some technical employees are as obnoxious as anyone can be. But you don't prejudge them. You let their own characteristics let you know who they are. Same is true for the companies, as well. Some are obnoxious, but you should not start out with a chip on your shoulder when you go in to interview. Each side must let the qualities of the other tell them who they are. Not prejudice. So, it is no more a common failing of technical employees than it is of technical employers. To suggest otherwise, is simple prejudice. >Also, the good jobs will tend to appear early in an >interviewing cycle with those less desireable trailing behind. Plus >you commonly only get one slim chance with each company. So, what are you suggesting? That an interviewee cow-tow and kiss the feet of anyone who deigns to allow them an interview just so they can "get the more desirable jobs?" I'm currently working with a company I like a lot, but where I told the VP of Engineering that so long as she had any control over the projects she wanted me working on, I would refuse to consider working on them. It was the first time in my life where I got to that point, frankly. I'm naturally very easy to get along with and I enjoy what I do a lot, teaching and working with people, and learning from others. No one has ever told me that I'm hard to get along with or that I don't care deeply about their own needs. But she pushed all of my limits and I finally made a decision this wasn't going to continue anymore. It was the right decision, then and after the fact. I got a call from them a few years later, letting me know she had left the company and wondering if I'd consider them. The result is a very good relationship with a deep and mutual respect and an understanding of each other and what we need and care about. One of the better business and personal arrangements I have, now. I'm glad I said something, then. Relationship is everything in business. And signing any random NDA on 1st blush is a way of jeopardizing both existing and future ones almost without a care. I take my relationships far too seriously to just sign such a thing and perhaps later hurt a relationship I already have or may later develop and care about. You have to stand up and not take your relationships in a cavalier, casual and perhaps careless way. Signing blanket NDAs on 1st meeting, signing a visitor's log which effects similar things, is just such carelessness that I'm mentioning. You do such things only in a well considered way. And if a business insists that you act in a hasty, reckless, and irresponsible fashion like that, then an interviewee is only exercising their better concerns by walking carefully into them. Rick acted well, with love and care and concern. Not arrogance as you suggest. I think that same company would want him to act as well if he were an employee but later looking elsewhere. Relationship is everything. And you don't show good concern by showing reckless disregard. >If you actually need a job, you need to stop screwing yourself >and get politically savy. And it is quite easy to search the >newsgroups by poster name to find out a person's attitudes and >opinions. If acting like an obsequious sycophant, fawning for a job, is your idea of being "politcally savy" then I hope fewer are as savy. I don't think anything that Rick Cole said comes even close to reducing his appeal to employers, not here in this thread and certainly not in his other excellent posts. Do you think so? >Otherwise, it has been a very interesting thread. I agree. JonArticle: 24815
[Interesting discussion.] [Beware of signing NDA snipped.] > If the company asked you to describe how, for example, you'd design a > data logger, what comeback would you have if they later used your > ideas in one of their designs? What's the big deal. Let them use your ideas. This is a job interview, right? Aren't you willing to give an hour of free consulting time to somebody in return for a good faith attempt to get to know eachother better? I consider job interviews to be hard work and very important, and that holds for both sides. You are going to be working with eachother, hopefully for a long time. An hour is cheap if you get good information. You might also establish your reputation for future consulting work or meet eachother again later on. If somebody asked me to sign an NDA, I'd try to find out what's going on. Common sense and good faith are probably as important as the legal fine print. If they can't explain why they want you to sign the NDA in ways that make sense, they probably won't be able to explain other policy issues either, and I probably don't want to work for/with them. (I'll take a lot of "trust me on this one" type answers, but only from people who have established that trust over en extended period of time.) If there are legitimate NDA issues involved, I'd probably try to break the interview into two stages - before and after signing the NDA. I'd be willing to make a second trip if the pre-NDA stage looked promising. There are several types of information that can be protected by NDAs. One is schedule and marketing plans - product launch is Oct 12th. Another is stratigic shifts - we are going into the medical business sector. There are also technical ideas. A signed NDA covers the clean/obvious cases - you would be asking for troubles if you sold sensitive information to a competitor. But there is also a lot of good faith involved. The usual paperwork includes something like "until you learn it from other sources". If you know a secret, it's a lot easier to keep an eye out for information that is relevant and/or interpret what you learn correctly. I have asked friends/partners "How much can I tell others? What do you want kept quiet?". One reasonable answer is "nothing/everything", but in that case, they won't get any leads/referals from me. Some technical ideas are patentable. These have to be kept secret until the patent is filed. An NDA for this makes sense, but only if you have to discuss that area. I'd expect most of an interview could avoid discussing patentable ideas. Some technical ideas are just engineering details. There are probably many solutions to the problem, you just have to find one that works well. I'm thinking of a good chip for the job, or a "trick" for clocking, the type of things that get discussed on newsgroups. I'm generally willing to give away my "consulting time" on things like that. It's a way to get to know people and let them get to know you. I'd put the data logger example above into this category - at least the initial BSing about the problem. Silicon Valley is amazingly small at times. The guy you help today might return the favor tomorrow, perhaps with a technical tidbit or perhaps with a lead on a job. Of course, somebody might be trying to rip you off for some free consulting disguised as a job interview. I guess I'm willing to take that risk. It's probably costing them a lot of time and effort to go through their half of the interview process too. -- These are my opinions, not necessarily my employers. I hate spam.Article: 24816
> I, as a customer of Xilinx, care about getting information on metastability. > Crossing clock domains is something that can't be avoided. Should I have told > the salesman when we ordered a small pile of XCV3200E's today that metastability > information is important? Would that help? Me too. And I want the info for worse case conditions, not just typical. I'll take better-than type numbers if things are hard to measure. -- These are my opinions, not necessarily my employers. I hate spam.Article: 24817
I frequently see comments here about silicon getting faster so metastability is less of a problem. Is that really correct? Are there other mechanisims that work the other way, such as chips getting bigger and clock cycle times getting shorter? Can we make a Moore's Law type graph? -- These are my opinions, not necessarily my employers. I hate spam.Article: 24818
On 19 Aug 2000 23:27:42 GMT, murray@pa.dec.com (Hal Murray) wrote: > >[Interesting discussion.] > > >[Beware of signing NDA snipped.] > >> If the company asked you to describe how, for example, you'd design a >> data logger, what comeback would you have if they later used your >> ideas in one of their designs? > >What's the big deal. Let them use your ideas. > >This is a job interview, right? Aren't you willing to give an hour >of free consulting time to somebody in return for a good faith attempt >to get to know eachother better? I think this is an excellent point. The company is distracting otherwise good employees because they need to find other good ones, and the process is a two way street. Both may have something the other wants. If neither side can afford the time to talk, they just shouldn't be talking at all. >I consider job interviews to be hard work and very important, and >that holds for both sides. You are going to be working with eachother, >hopefully for a long time. An hour is cheap if you get good information. Yup! >You might also establish your reputation for future consulting work >or meet eachother again later on. Yes. But don't forget that signing a blank-check NDA may actually cause trouble for a future and more important relationship, where there is only emotional and irrational feelings hurt that could have been avoided. It doesn't usually present a problem, of course. But why sign an imprecise legal document protecting one side and risking feelings of this or some future contact (or past one), all over a 1st interview which may go nowhere? Frankly, I don't need an NDA to prevent me from talking about what I hear in a way that could cause harm. It's not good business, anyway. But if they don't trust my judgement or if they somehow need to be absolutely sure that some things I don't realize should be protected are, in fact, explicitly protected then they probably need to write it down, anyway. Just so I truly do understand. I suspect NDAs may make sense, on the closing interview where an offer will be discussed and considered and where more details may be needed to make a final decision. But by that time, both sides are closer and more effort has been spent and the effort in forging a specific NDA will make more sense to both sides. >If somebody asked me to sign an NDA, I'd try to find out what's going >on. Common sense and good faith are probably as important as the legal >fine print. If they can't explain why they want you to sign the NDA in >ways that make sense, they probably won't be able to explain other policy >issues either, and I probably don't want to work for/with them. (I'll take >a lot of "trust me on this one" type answers, but only from people who >have established that trust over en extended period of time.) Yes. I wouldn't slam my fist on first seeing an NDA. But I would probably look very closely at why, if it came up on a 1st interview. And good sense is good sense. There's no arguing with that. >If there are legitimate NDA issues involved, I'd probably try to break >the interview into two stages - before and after signing the NDA. I'd >be willing to make a second trip if the pre-NDA stage looked promising. Yes. This is an excellent approach and one I've been pushing for, here. <snip> >Some technical ideas are patentable. These have to be kept secret >until the patent is filed. An NDA for this makes sense, but only if >you have to discuss that area. I'd expect most of an interview could >avoid discussing patentable ideas. I'd think the 1st one certainly could! If the company is in the routine business of disclosing their ideas to every applicant on the 1st interview, so that they have to have a visitor's log with an NDA built into every page and where they have all applicants sign a separate one, too -- hehe, they probably aren't keeping any secrets. Just scaring some folks. <snip> >Silicon Valley is amazingly small at times. The guy you help today >might return the favor tomorrow, perhaps with a technical tidbit or >perhaps with a lead on a job. It's small, also in part, because everyone is out for themselves with a fervor and shift jobs almost as they might change dog food brands. Few mentally invest in each other. >Of course, somebody might be trying to rip you off for some >free consulting disguised as a job interview. I guess I'm willing >to take that risk. It's probably costing them a lot of time and >effort to go through their half of the interview process too. Yeah, it's worth the risk. If you can't take that kind of risk, you might as well just stay at home. JonArticle: 24819
"Peter Alfke" <peter@xilinx.com> wrote in message news:399B274C.57D28844@xilinx.com... > > > Renzo Venturi wrote: > > > "Use Actel anti-fuse FPGA... > > > > You forgot the :-) > Otherwise we are going to let out the secret about all the Antifuse FPGAs used > up in the debugging process. :-) > > Peter Alfke > > What a cheap shot Peter! Good designers that follow a disciplined design flow have no problem using Antifuse based FPGAs. It is very unfortunate that the RE-PROGRAMMABLE DESIGN BY THE SEAT OF YOUR PANTS BIGOTs insist that the design community is not good enough to use Antifuse based FPGAs. Fortunately there are many good designers out there using this technology! Perhaps this newsgroup should be renamed comp.arch.XILINX_FPGA, as most of the issues/problems that come up in this group are in regards to Xilinx and not Altera, Actel, Quicklogic, or Lattice/Vantis.Article: 24820
> Recently, we tried it with Virtex parts, and did not immediately get any > meaningful results, so we abandoned the tests for the time being. We > were not able to bring the measuring clock edge close enough to the > first clock. The flip-flops are just too fast in resolving > metastability. Perhaps it's time for a new approach. We've got a lot of smart people here - many are interested in this problem. I think there are two issues. One is social, the other is technical. Here are some technical suggestions/questions: Why can't we use two clocks rather than the rising/falling edge? I assume the problem is that there would be skew within the chip. Can we find a way to correct for that? How about two runs, one with clock A ahead of clock B and the other with clock B ahead of clock A? Can we find a way to collect data faster? There are a lot of FFs in a modern chip. Maybe we could run 100s of copies of Peter's basic circuit. Peter's recipe involved 1 second runs. We could also set things up to run overnight - 10,000 seconds. What sort of clock difference do we need? What sort of delays can we get with a bit of hackery? I'm thinking of tricks like running a signal through a chain of CLBs to make a short delay. Adding or deleting a CLB would make a pretty fine adjustment. I can't quickly find or derive the equations to compute the K1 and K2 type parameters from a pair of Peter's test runs. There are two unknowns and two data points, so it seems like a reasonable match. But suppose you are using two clocks rather than both edges. How well will two clock distribution chains track in a modern chip? Can we correct for any skew with a 3rd data point? (3 unknowns need 3 data points)... Now for some social issues. What can we do to make vendors pay attention to this issue? Is there any good journal that would take a letter to the editor or a short editorial type article? What do ASIC vendors do in this area? Would any of the companies who make FPGA prototyping boards be willing to let this sort of test run overnight and on weekends, perhaps while burning in a board? I'm just fishing for a way to collect a lot more data. It might be neat to see if there are any trends. Is this an appropriate topic for an undergraduate thesis? Anybody know a school that would be interested in this area? Anybody willing to donate a board? Anybody got any other ideas? -- These are my opinions, not necessarily my employers. I hate spam.Article: 24821
> > Renzo Venturi wrote:
> > > "Use Actel anti-fuse FPGA...
> > You forgot the :-)
> > Otherwise we are going to let out the secret about all the Antifuse
FPGAs
> used
> > up in the debugging process. :-)
> > Peter Alfke
*********************************************************
> What a cheap shot Peter!
> Good designers that follow a disciplined design flow have no problem using
> Antifuse based FPGAs.
> It is very unfortunate that the RE-PROGRAMMABLE DESIGN BY THE SEAT OF YOUR
> PANTS BIGOTs insist that the design community is not good enough to use
> Antifuse based FPGAs. Fortunately there are many good designers out there
> using this technology!
> Perhaps this newsgroup should be renamed comp.arch.XILINX_FPGA, as most of
> the issues/problems that come up in this group are in regards to Xilinx
and
> not Altera, Actel, Quicklogic, or Lattice/Vantis.
**************************************************************
These good designers that follow a disciplined anti-fuse design flow
better start getting it EXACTLY correct the very FIRST time, in spite of
design changes mandated by design specification changes. The reason I say
this is because FPGA design jobs are getting so big that they demand BGAs to
handle the extremely large IO. If one of these really good designers does a
BIG job and blows it (not the anti-fuses), it's going to be tough getting
that anti-fuse FPGA BGA off that board and putting another on. It can be
done, but it's a big pain in the pad layout.
Heck, he doesn't even have to blow it. As I said earlier, all that
is needed is a change to the design specification.
So these really good designers either are going to be stuck doing small
FPGA designs or they're going to have to have really good design
specifications, have lots of time to do extremely good simulation up front,
and get everything extremely correct the FIRST time.
It is no wonder that Actel is desperately looking into reprogrammable
parts that seem to be unobtainium.
I agree that this newsgroup is dominated by Xilinx and Altera, but so
is the market pie.
-Simon Ramirez
Article: 24822"S. Ramirez" wrote: > These good designers that follow a disciplined anti-fuse design flow > better start getting it EXACTLY correct the very FIRST time, in spite of > design changes mandated by design specification changes. The reason I say > this is because FPGA design jobs are getting so big that they demand BGAs to > handle the extremely large IO. If one of these really good designers does a > BIG job and blows it (not the anti-fuses), it's going to be tough getting > that anti-fuse FPGA BGA off that board and putting another on. It can be > done, but it's a big pain in the pad layout. I haven't tried them out yet, but there are BGA sockets that fit onto the same pads where you would solder the device. =========================================== > Heck, he doesn't even have to blow it. As I said earlier, all that > is needed is a change to the design specification. That is the biggest reason that I have encountered for device changes with good designers on the job. Hopefully we can all keep the flames toned down just a tad. For the Silicone Valley guys, aren't all of your sales and stock prices up? Take a nice weekend off and relax! :-) rkArticle: 24823
"S. Ramirez" <sramirez@cfl.rr.com> wrote in message news:8mGn5.29521$9T1.222871@typhoon.tampabay.rr.com... > > > Renzo Venturi wrote: > > > > "Use Actel anti-fuse FPGA... > > > You forgot the :-) > > > Otherwise we are going to let out the secret about all the Antifuse > FPGAs > > used > > > up in the debugging process. :-) > > > Peter Alfke > ********************************************************* > > What a cheap shot Peter! > > Good designers that follow a disciplined design flow have no problem using > > Antifuse based FPGAs. > > It is very unfortunate that the RE-PROGRAMMABLE DESIGN BY THE SEAT OF YOUR > > PANTS BIGOTs insist that the design community is not good enough to use > > Antifuse based FPGAs. Fortunately there are many good designers out there > > using this technology! > > Perhaps this newsgroup should be renamed comp.arch.XILINX_FPGA, as most of > > the issues/problems that come up in this group are in regards to Xilinx > and > > not Altera, Actel, Quicklogic, or Lattice/Vantis. > ************************************************************** > > These good designers that follow a disciplined anti-fuse design flow > better start getting it EXACTLY correct the very FIRST time, in spite of > design changes mandated by design specification changes. The reason I say > this is because FPGA design jobs are getting so big that they demand BGAs to > handle the extremely large IO. If one of these really good designers does a > BIG job and blows it (not the anti-fuses), it's going to be tough getting > that anti-fuse FPGA BGA off that board and putting another on. It can be > done, but it's a big pain in the pad layout. > Heck, he doesn't even have to blow it. As I said earlier, all that > is needed is a change to the design specification. > So these really good designers either are going to be stuck doing small > FPGA designs or they're going to have to have really good design > specifications, have lots of time to do extremely good simulation up front, > and get everything extremely correct the FIRST time. > It is no wonder that Actel is desperately looking into reprogrammable > parts that seem to be unobtainium. > I agree that this newsgroup is dominated by Xilinx and Altera, but so > is the market pie. > -Simon Ramirez > > > Simon, All good points. Issues that ASIC designers have faced forever. When companies such as Juniper, RedBack, Nexabit/Lucent, Cisco, etc.... go to the investment community, they are not highlighting their FPGA designs, they are highlighting their ASIC designs. Which only proves that complex designs can be done correctly the first time and EXACTLY correct the very FIRST time. Of course none of this is possible if engineering management does not demand a solid design specification. It is common sense practice for ASIC designs to have a detailed design specification locked down before the design is taped out. I spent 10 years designing ASICs with multiple first pass silicon success. Each of these designs required and had a detailed specification. I then spent 5 years designing FPGAs and PLDs (Xilinx, Altera, Actel, Lattice, AMD), for which management never required any specification at all. I always wrote one, but was later dinged on my performance reviews for having done so. My teams designs also set new company standards for prototype hardware availability to the software team. Sorry, but I think that it is the design engineer's responsibility to ensure that the design has a well defined and locked down specification, before venturing into the design! It is unfortunate that Design management has decided that a specification is not needed for FPGA designs and that designers no longer see the value in a design specification. If your happy with only having two choices when you choose a device for a programmable design, so be it. But I believe that the design community is better served by multiple vendors offering multiple technologies to the design community. I know that the community of designers implementing designs for the space, avionics, military, and medical markets appreciate the fact that they have antifuse technology as a choice. All BGA devices offered by Actel and Quicklogic have a very easy to use socketing solution and with improving technologies for BGA soldering and removal (http://www.zephyrtronics.com/frameset.htm) designers do have workable technology choice and we as a design community need to think twice before discarding this viable technology choice. Yes, Actel is investing in differentiated re-programmable technologies and will deliver them to the design community when they are ready. But they also continue to invest in antifuse technology, because in areas of hi-reliability, design security, and increasing speed demands designers do want a quick turn programmable ASIC solution. Quicklogic also continues to churn out very good differentiated products. Both of these companies continue to survive and turn a profit despite the best efforts of the two titans to discredit and eliminate antifuse technology.Article: 24824
> What a cheap shot Peter! I saw the smilies. Didn't you? Peter's track record here is very good. He's one of the best examples I can think of for a vendor contributing to a newsgroup. I used to follow some network group where somebody from Cisco had a similar reputation. It's pretty easy to spot if you follow a newsgroup for a while. I think he has been very fair when discussing other vendors products. If I've been missing things, please point them out in the future. > Good designers that follow a disciplined design flow have no problem using > Antifuse based FPGAs. > > It is very unfortunate that the RE-PROGRAMMABLE DESIGN BY THE SEAT OF YOUR > PANTS BIGOTs insist that the design community is not good enough to use > Antifuse based FPGAs. Fortunately there are many good designers out there > using this technology! Sounds to me like there are bigots on the other side too. Shouting doesn't make your case any stronger. People build ASICs and fully custome chips too. They are all various points on spectrum of cost, time to market, and speed/size availability space. I admit that I belong to the seat-of-the-pants school, but I'm willing to learn, or at least try. Do you have suggestions for how to design a chip when the specs aren't firm? Being able reprogram a chip after the board has shipped has saved my ass a couple of times. Both quirks involved fuzzy areas in the specs. No amount of testing would have uncovered the problem. (Having another person working on the project and looking at that area might have found them. But I'll bet I could have explained why I had done what I did.) > Perhaps this newsgroup should be renamed comp.arch.XILINX_FPGA, as most of > the issues/problems that come up in this group are in regards to Xilinx and > not Altera, Actel, Quicklogic, or Lattice/Vantis. Perhaps all the good designers are using non-Xilinx chips and don't have any questioms to ask here. ;) I haven't seen any serious complaints about too much Xilinx traffic. I'll be glad to support creating another group if that's a real problem. -- These are my opinions, not necessarily my employers. I hate spam.
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