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
Hello, I'm posting this question here because I want responses from engineers, so please don't be offended. I want to know what your thoughts are concerning Performance Appraisals at your company, are they beneficial, how are they conducted, and what is the best way go give performance appraisals? Where I work, the manager brings you into their office, starts a series of short questions concerning your family and other things not relating to your job and then finally gives you a pat on the back and says, good job. Not much is really discussed and therefore not really useful. Your comments are welcomed. thanks, joeArticle: 107626
Take a look at Mentor's Catapult C. It translates untimed C models
into synthesizable VHDL or verilog. You must specify the clock period.
It assumes loop iterations take one clock, but individual instructions
do not. You can tell it to unroll loops to perform their statements in
parallel, or partially or fully pipeline the model, with varying clock
cycles per pipe state (i.e. the pipeline need not accept new data every
clock). The nice thing about it is that it takes care of the control
logic to turn the untimed (i.e. one-clock) description into a useable
hardware design that could target a variety of space-performance
trade-offs.
They have a very good interface synthesis approach. They can access
the inputs and outputs in parallel, streaming in order, or pick them
out of an external (to their model, not necessarily to the FPGA) single
or dual port ram. Internal arrays can also be stored in registers or
single or dual port rams. They also assume the whole hardware model
operates with one clock input and one reset input (asynchronous or
synchronous, per your choice).
The bottom line is that you wouldn't use it to design a whole chip,
but you would use it to design a hardware implementation of a software
algorithm. Then the chip designer, using verilog or vhdl, would
develop the rest of the chip around it.
They also provide the hooks for testing the hardware description from
original c code used to test the c model (at the transaction level),
using system-c concurrently with the vhdl or verilog model in modelsim.
In addition, they provide cycle-accurate vhdl and verilog models of the
hardware design. I chastised them on the fact that if they worked on
their synthesizable vhdl, they could use the same code for synthesis
and cycle based simulation (using variables and a single clocked
processes, etc.).
I took a 3 day training class with it a couple of weeks ago, and I, a
die-hard vhdl designer, was impressed!
Andy
Martin Thompson wrote:
> mikegurche@yahoo.com writes:
>
> > Martin Thompson wrote:
> > > mikegurche@yahoo.com writes:
> > >
> > > <snip commentary on variables>
> > >
> > > >
> > > > In synthesis, the problem is normally the abuse of sequential
> > > > statements, rather than the use of variable. I have seen people trying
> > > > to convert C segment into a VHDL process (you can have variables, for
> > > > loop, while loop, if, case, and even break inside a process) and
> > > > expecting synthesis software to figure out everything.
> > > >
> > >
> > > Why not do this? Synthesis software is good at figuring all this
> > > out. If it does what you need it to and meets timing, you're done.
> > > Move on to the next problem.
> > >
> >
> > If the synthesis software is really this capable, there is no need for
> > hardware engineers. Everyone can do hardware design after taking C
> > programming 101 and we all will become unemployed :(
>
> Well, eventually, it's going to happen. We'll be abstracted far
> enough away from the hardware to still be productive.
>
> >
> > Let me give an example. Assume that we want to design a sorting
> > circuit that sorts a register of 1000 8-bit word with minimal
> > hardware.
>
> OK, but I notice you've said minimal hardware there - my point was
> "gets the job done"... maybe I have an enormous FPGA.
>
> > For simplicity, let us use the bubble sort algorithm:
> >
> > n=100
> > for (i=0; i<n-1; i++) {
> > for (j=0; j<n-1-i; j++)
> > if (a[j+1] < a[j]) { /* compare the two neighbors */
> > tmp = a[j]; /* swap a[j] and a[j+1] */
> > a[j] = a[j+1];
> > a[j+1] = tmp;
> > }
> > }
> >
> > The hardware designer's approach is to develop a control FSM to mimic
> > the algorithm. It can be done with one 8-bit comparator in
> > 0.5*1000*1000 clock cycles.
> >
>
> Yes. Maybe in 1 process, and maybe in 2, or maybe three :-)
>
> > If we ignore the underlying hardware structure and just translate C
> > constructs to corresponding VHDL constructs directly (the C
> > programmer's approach), we can still derive correct VHDL code:
> >
> > process(clock)
> > variable a: std_logic_vector(999 downto 0) of
> > std_logic_vector(7 dwonto 0);
> > variable tmp: std_logic_vector(7 dwonto 0);
> > begin
> > if (clock'event and clock='1') then
> > -- register
> > q <= d;
> > a := q;
> > -- combinational sorting circuit based on
> > -- one-to-one mapping of C constructs
> > for i in 0 to N-2 loop
> > for j in 0 to N-2-i loop
> > if (a(j+1) <a(j)) then
> > tmp := a(j);
> > a(j) := a(j+1);
> > a(j+1) := tmp;
> > end if;
> > end loop;
> > end loop;
> > -- result to register input
> > d <= a;
> > end process;
> >
>
> I wasn't suggesting directly mapping C-code to VHDL like this, just that
> the "describe everything to the synthesizer" approach can be a bit
> heavy-handed and time consuming.
>
> > The resulting circuit can complete sorting in one clock cycle but
> > requires 0.5*1000*1000 8-bit comparators. We need a extremely large
> > target device to accommodate the synthesized circuit. It will be very
> > demanding for synthesis software to convert this code into a circuit
> > with only one comparator. I think my job is still safe, for now :)
> >
>
> I don't suggest that the synth *can* make those sort of
> transformations. It doesn't have the constraints currently to know.
>
> As an aside, I think that FpgaC will do it with one comparator and a
> memory, (maybe fpga_toys will chip in here).
>
> In the future, we *will* be moving away from low-level stuff like this
> (personally, I don't think *C* is high enough level, but that's another
> debate :-)
>
> Cheers,
> Martin
>
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html
Article: 107627Joe, The "performance appraisal" is a purely formal game. The only purpose of it is to protect the company from lawsuits. If someone who was let go is considering himself offended and brings the case to the court, then the company will need something in writing to prove their point. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com jjlindula@hotmail.com wrote: > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? > > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. > > Your comments are welcomed. > > thanks, > joe >Article: 107628
"jjlindula@hotmail.com" <jjlindula@hotmail.com> wrote in news:1156965525.874885.19940@m73g2000cwd.googlegroups.com: > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. > If there were something wrong with your performance, this is probably not how the meeting would go. -- Scott Reverse name to replyArticle: 107629
> The "performance appraisal" is a purely formal game. The only purpose of it is to protect the > company from lawsuits. Not if they're done right. While I was at Nortel 8-15 years ago they carried out performance reviews which I have since realised were more useful than most people gave credit for. There were objectives set in agreement with your team leader that could be used to justify training etc. There was also a fairly honest apprisal of your performance against last years targets etc. The targets and objectives were set as much by your own character assesment as your bosses, these had to be agreed. Now, working for myself I know I should be carrying out the same exercise for myself (but never seem to have the time). Nial.Article: 107630
Ray Andraka schrieb: > Antti wrote: > > Hi > > > > if anyone has seen the same or has any ideas how to avoid the issue I > > am faced please help - I am trying to get it solved myself (my deadline > > is today 21:00 german time) but kinda stuck currently. > > > > problem: > > > > Virtex-4FX12 > > 2 DCMs in series > > DCM1 uses only FX output for PPC system clock (to get the clock into > > DLL input range) > > DCM2 generates 3X clock proc clock for PPC > > > > it all works for 360 milliseconds after configuration. then the first > > DCM will remove lock, output stop, everythings stops. the delay 360 > > milliseconds is not dependand on the first DCM clock ratio settings. if > > PPC is held in reset then the DCMs still shut down after the same 360 > > milliseconds. > > > > any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and > > power supply lines but not seeing anything at the time where the DCM > > shut off. > > > > thanks in advance for any suggestions, > > > > Antti > > > > Antti, > > I don't think this is your problem since you said it is the first DCM > losing lock, however check to make sure the jitter out of the first DCM > is within the max jitter input specs for the second DCM. In most cases, > you violate the max jitter spec when trying to drive a second DCM with > the clkfx output of the first. Perhaps you can change it around so that > the first is doing clkx2 and the second is doing the clkfx? Otherwise, > at least check the jitter for your M and D values to satisfy yourself > that the jitter is not too much for the second DCM > > Then again, I'm sure you already know all this ;-) > > Second question: are you using the NBTI macro? I don't know what > changes Xilinx has made to it in the past 16 months. The original > version for the devices that don't have the DCM changes had race > conditions that made it unreliable for higher clock input frequencies, > at least on paper. We had no end of problems getting it to react > properly when starting a clock up after the FPGA had been programmed. > There were several revisions to the circuit since then, but we have not > looked at them here to see if the race problem was addressed or not. We > are leaving the NBTI circuit out for designs that have a crystal on the > board now. Hi Ray, it defenetly is the NBTI macro issue. it seems only to popup in EDK sometimes. So the same DCM that would otherwise work with same connections and settings dosnt any more. Thanks for the jitter warning I will sure theck those issues also if there is any trouble and when doing any new or re-designs. AnttiArticle: 107631
Hello Joe, > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? > > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. > > Your comments are welcomed. > When I had to conduct my first ones I learned from a book: William S.Swan "How to do Superior performance Appraisals Helped me quite a bit and the engineers I gave appraisals later said they liked the style. Appraisals can be very helpful for the career of the person being appraised. If they are done right. -- Regards, Joerg http://www.analogconsultants.comArticle: 107632
jjlindula@hotmail.com wrote: > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? I've worked both sides of the desk since about 1974 when I first became a hiring manager. In organizations larger than a few dozen people, especially those with HR departments, the formal process is necessary to organize and document skill sets and salary administration in a uniform way. Many people have a hard time tooting their own horn, and a good reciprocol review cycle gives the employee a clear time to intiate discussion about new/added responsibilities, promotion goals, and salary goals. Likewise, sometimes marginal performance isn't worth the manager taking you aside and telling you to pull your own weight (or else), but at the review cycle, it's much easier to open the employee up and find out what is causing the weak performance. Be it training, home problems, lack of motivation, lack of respect inside the team, lack of guidance, etc ... all things easier discussed when this process is administered well. The first few places I was a manger, there was zero traning for what was expected, or the gains that could be made organizational if this was done well ... certainly better training can help both side of the desk. > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. Stresses outside of work, affect employee productivity big time. A MH checkup at review is more than useful to understand what is going on in your life that affects your work. I'd say your manager is on the ball, and if anything was wrong, you certainly would have heard about it. It's always a good idea to take your boss to lunch, and talk about the review process from both sides of the desk. You will probably be there sooner than you expect, and having that discussion, can sometimes be a key opening discussion that you are THINKING about your job, and where your advancment will take you. Have Fun! JohnArticle: 107633
Jim Granville wrote: > Ben Twijnstra wrote: >> Jim Granville wrote: >> >>>Any info out yet on what MAX3 looks like ? >>>Does it improve Static Icc, and lack of memory of MAX II, for example ? >>>Smallest devices / largest devices ? >> >> >> Nope - Altera's silicon design team is quite busy with Cyclix III. If you >> have any good suggestions on specs outside the hobby sphere, now might be >> a good time to post them... > > Now there is a strange reply. > Do you mean suggestions on MAX 3, or this Cyclix III ? > If the silicon design team is quite busy, the Architecture team has > therefore finished, and so suggestions are probably too late anyway ? As Aurelian already suggested, I indeed meant Cyclone/Stratix III. I played with the word Stratone, but that sounded way too chemical. From a few presentations I have seen, the Architecture people seem to be pretty much done with the 65nm offerings, so I guess they're now in a position to be retreating into the Stone Age for a few months while focusing on positioning and defining a new instant-on product, probably based on 130nm technology. So, send money, cigars, whiskey and the odd bottle of perfume to 101 Innovation Drive, San Jose, CA, C/O The Max Architecture Team, along with three copies of the requirements for a CPLD for your next killer project and hope they don't just take the goodies and light the cigars with your requirements ;-) Best regards, BenArticle: 107634
Aurelian Lazarut wrote: > Luc, > I think is more like "spartex" or "virtan" in X-world. ;-) > Hmmm... Spandex IV - the stretchable FPGA fabric... ;-) BenArticle: 107635
Austin Lesea wrote: > Antti, > > Yes, it looks like the macro thinks the clock is no present. > > I would open a webcase just so that someone is aware of this. > > Austin From answer record 21435: Disabling Macro Insertion If you can ensure that the clock source for any particular DCM will never stop, the extra logic insertion can be disabled using one of the following two methods: - If none of the DCMs in your design require the clock stop circuitry (i.e., the DCM source clocks will never stop), you can globally disable the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF environment variable. - You can also disable insertion on an individual basis by applying the DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are TRUE and FALSE, where TRUE (the default value) allows MAP to insert the clock stop circuitry, and FALSE disables the logic insertion. You can add this attribute to the HDL design source using the VHDL generic or Verilog defparam, or it can be entered as a synthesis attribute (check with your synthesis tool for the appropriate syntax). When applying this attribute in the UCF file, the syntax is as follows: INST DCM_INST DCM_AUTOCALIBRATION="FALSE"; Insertion of this circuit is not automatic for ISE7.1, only for 8.x, so if you are using 7.1 it isn't putting them in automatically. Also, instantiate the straight DCM, not DCM_standby if that is what you are doing. I haven't revisited the circuit used for the clock detect in the last 12 months or so, but I do know the one in the first release was a demonstration on how not to design a circuit with multiple clocks. We had no end of problems with trying to use it with a 125 MHz input clock.Article: 107636
Antti, Just turn it off, you don't need it. Also in another tech answer, they say the macro requires greater than 200 ms reset pulse! >From an tech answer (#21435): - If none of the DCMs in your design require the clock stop circuitry (i.e., the DCM source clocks will never stop), you can globally disable the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF environment variable. - You can also disable insertion on an individual basis by applying the DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are TRUE and FALSE, where TRUE (the default value) allows MAP to insert the clock stop circuitry, and FALSE disables the logic insertion. You can add this attribute to the HDL design source using the VHDL generic or Verilog defparam, or it can be entered as a synthesis attribute (check with your synthesis tool for the appropriate syntax). When applying this attribute in the UCF file, the syntax is as follows: INST DCM_INST DCM_AUTOCALIBRATION="FALSE"; Austin Antti wrote: > Ray Andraka schrieb: > >> Antti wrote: >>> Hi >>> >>> if anyone has seen the same or has any ideas how to avoid the issue I >>> am faced please help - I am trying to get it solved myself (my deadline >>> is today 21:00 german time) but kinda stuck currently. >>> >>> problem: >>> >>> Virtex-4FX12 >>> 2 DCMs in series >>> DCM1 uses only FX output for PPC system clock (to get the clock into >>> DLL input range) >>> DCM2 generates 3X clock proc clock for PPC >>> >>> it all works for 360 milliseconds after configuration. then the first >>> DCM will remove lock, output stop, everythings stops. the delay 360 >>> milliseconds is not dependand on the first DCM clock ratio settings. if >>> PPC is held in reset then the DCMs still shut down after the same 360 >>> milliseconds. >>> >>> any ideas? what to check? I have Lecroy 2GS/s DSO on some signals and >>> power supply lines but not seeing anything at the time where the DCM >>> shut off. >>> >>> thanks in advance for any suggestions, >>> >>> Antti >>> >> Antti, >> >> I don't think this is your problem since you said it is the first DCM >> losing lock, however check to make sure the jitter out of the first DCM >> is within the max jitter input specs for the second DCM. In most cases, >> you violate the max jitter spec when trying to drive a second DCM with >> the clkfx output of the first. Perhaps you can change it around so that >> the first is doing clkx2 and the second is doing the clkfx? Otherwise, >> at least check the jitter for your M and D values to satisfy yourself >> that the jitter is not too much for the second DCM >> >> Then again, I'm sure you already know all this ;-) >> >> Second question: are you using the NBTI macro? I don't know what >> changes Xilinx has made to it in the past 16 months. The original >> version for the devices that don't have the DCM changes had race >> conditions that made it unreliable for higher clock input frequencies, >> at least on paper. We had no end of problems getting it to react >> properly when starting a clock up after the FPGA had been programmed. >> There were several revisions to the circuit since then, but we have not >> looked at them here to see if the race problem was addressed or not. We >> are leaving the NBTI circuit out for designs that have a crystal on the >> board now. > > Hi Ray, > > it defenetly is the NBTI macro issue. it seems only to popup in EDK > sometimes. So the same DCM that would otherwise work with same > connections and settings dosnt any more. Thanks for the jitter warning > I will sure theck those issues also if there is any trouble and when > doing > any new or re-designs. > > Antti >Article: 107637
> There are companies who use our parts to verify the logic prior to its > placement in an ASIC. Good business, as they buy our largest parts, and > lots and lots of them. > > We make no further effort to help them create ASICs. We appreciate > their use of our parts, even if that use leads eventually to less > business. I did not know this. Perhaps this is an area that Xilinx should look into. Clearly in the future, the automation of ASIC design and manufacturing will dramatically drop and engineers will be looking to ASICs for very small production runs and they will want a seemless migration path. >>> On the other hand, since what we do we consider proprietary, we are not >>> going to share schematics with you. >> >> I understand the importance of proprietary intellectual property, as a >> patent owner, better than most. However, it seems that keeping your >> customers in the dark about what they are programming is >> counterproductive. >> What are Xilinx's real risks? And have they been ripped off in the past? > > Then you can appreciate that customers have trust in Xilinx not to do > anything to make it trivial, or easy, for their clever IP to be ripped > off. I think what we were talking about was the physical aspects of the Xilinx fabric to give engineers the ability to think clearly about what is or could be. Size and shape would be helpfull. I don't suggest that you give away your schematics if you believe that another manufacturer might copy them although I doubt that would happen. If it would help, I can document an example of how the lack of information about the V4 ISERDES has increased my project length by about two months. If anyone at Xilinx is interested in what I have to say that is. > As for being ripped off in the past, we have not been harmed per se, but > customers have been harmed by a company cloning an entire pcb, and then > copying the eproms, and selling that product for less money. I won't > say who did this, as it is all litigated and settled now, and Xilinx > derives benefit because both companies bought our FPGAs (the cloning > company had to, as they had no means to modify or change the design, or > even to fix any bugs). > > This is why today we offer the bitstream decryption features in V2, > V2Pro, V2Pro-X, V4, and now V5. We will do whatever we can to help > protect the customer's investment. > What you refer to as "Keeping our customer's in the dark" is in no way a > hindrance, or a handicap, For example, I look at this slicem and slicel pattern on the editor. I have no historical perspective of how this configuration came about, why they are placed as they are, nor do I have any sense of their real size. I also can not determine what logic they are performing through the editor. All I can do is trace back my signals to the VHDL and guess what the synthesizer has done. It's a big guessing game. How in the dark do you think I am? > as reverse engineering is perfectly legal to > fix a problem, or discover how something works. Most engineers do not want to reverse engineer anything. It's time consuming and not to their immedate goals. > We do not keep our > customer's in the dark for a legitimate reason. > If someone has to reverse engineer something (for example: a soft error > broke their design, which line of VHDL did that bit affect?) we are > happy to work with them to resolve the issue by telling them exactly > what they need to know (in fact, we will parse their design, and use our > tools to discover what they require). I found that the comp.arch.fpga has been far more helpful than anything Xilinx has done. A while ago I went through the process of putting in a case about one of the GUIs that generates BRAM coeffcients and that the GUI bombs with more than 16 or so coefficients. I spent more than a day discovering, isolating and documenting the issue. The engineer told me that the problem would get fixed, but, I never got word back that it did. I feel that the my efforts in reporting this problem are undervalued. You know I picked Xilinx for three reasons over Altera. First, I called Altera support, and could not speak to an engineer, whereas, I was able to speak to someone at Xilinx. Second, the distributors Avnet had a free beginners class and were very helpful. Third, this comp.arch.fpga seemed fairly open and helpful to newcomers. I suggest that Xilinx open up its engineering even further than it has if it wishes to remain the FPGA leader. Brad Smallridge aivision dot comArticle: 107638
jjlindula@hotmail.com wrote: > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? > > Where I work, the manager brings you into their office, starts a series > of short questions concerning your family and other things not relating > to your job and then finally gives you a pat on the back and says, good > job. Not much is really discussed and therefore not really useful. > > Your comments are welcomed. Glowing perfomance reviews and stock options are what companies give valued employees instead of raises. LuhanArticle: 107639
Hi Everybody
I have this problem with my Microblaze. No mater what I do I can not
read a simple data from GPIO (DIP Switches), that are on my Spartan 3E
Starter Kit Board
Here is my code that come out on RS232 terminal with "0" value:
///////////////////////////////////////
// #include definition //
///////////////////////////////////////
#include "stdio.h"
#include "xgpio.h"
#include "xuartlite_l.h"
#include "xbasic_types.h"
///////////////////////////////////////
#define UART_ADDRESS 0x40600000 //XPAR_RS232_UART_BASEADDR
#define LEDS_DEVICE_ID 0x40000000 //LEDS BASE ADDRESS
#define LEDS_DATA_DIRECTION 0x00000000 //LEDS DATA DIR
#define LEDS_CHANNEL 1 //LEDS CHANNEL
#define SWITCHES_DEVICE_ID 0x40020000 //SWITCHES BASE ADDRESS
#define SWITCHES_DATA_DIRECTION 0xFFFFFFFF
#define SWITCHES_CHANNEL 1
///////////////////////////////////////
// MAIN //
///////////////////////////////////////
int main(void)
{
print("\r\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
print("-- BEGIN --\r\n\n");
XStatus status; //Status variable for initialization
print("Initialize Switches ...");
XGpio Switches;
status = XGpio_Initialize(&Switches, SWITCHES_DEVICE_ID);
XGpio_SetDataDirection(&Switches, SWITCHES_CHANNEL,
SWITCHES_DATA_DIRECTION);
if (status == XST_SUCCESS) {
print(" [ OK ]\r\n");
}
else {
print(" [FAIL]\r\n");
return -1;
}
int gpioData;
while (1) {
print("Read Data ");
gpioData = XGpio_DiscreteRead(&Switches, SWITCHES_CHANNEL);
xil_printf(" >> %D\n\r", gpioData);
}
print("\r\n\n-- END --");
}
///////////////////////////////////////
please help me...
Article: 107640Luhan wrote: > > Glowing perfomance reviews and stock options are what companies give > valued employees instead of raises. Good point, Luhan. In the big company, there is a salary schedule: how much is getting paid to a person in this position. There is actually no way for them to give any raise. Also this is how the loafers from HR are making themselves look very useful. VLVArticle: 107641
Hello Luhan, > > Glowing perfomance reviews and stock options are what companies give > valued employees instead of raises. > And stock options can be a darn good thing. It's the American way :-) -- Regards, Joerg http://www.analogconsultants.comArticle: 107642
Brad, I am interested in the V4 ISERDES story. We do review every product release, and try to learn form our mistakes. As we roll out V5, we are doing studies of what went well, and what went not so well with V4. Please email me directly. Do not spend too much time, as I will have to summarize it in order to present it. If I discover that more information is needed, I will come back and ask if you may provide it. I might also discover that this is something that we know about, and already have plans in place not to repeat. Thanks. And if you really do have a question that you feel you need an answer to, do not hesitate to email myself or Peter directly, and ask. We may not want to document absolutely everything (that is impossible), but you may have a very good reason to ask your question. Hotline engineers are required to close with their customers: they are subject to disciplinary action if they do not do their job. If you have a case number, I will follow up (regarding your work which seemed to go nowhere). Thank you for choosing Xilinx, as we recognize you do have other choices. We (Xilinx) do not know how useful comp.arch.fpga really is. Do real customers even read this? For example, if I take the top 25 customers, is even one represented here on c.a.f? Is all we have here the academic and experimental community? Are we preventing our hotline from doing their job (which they can probably do faster and better than Peter or I)? Are we delaying a valid customer response which leads to a solution? Comments such as yours are helpful for use to determine the effort of monitoring c.a.f. Austin Brad Smallridge wrote: >> There are companies who use our parts to verify the logic prior to its >> placement in an ASIC. Good business, as they buy our largest parts, and >> lots and lots of them. >> >> We make no further effort to help them create ASICs. We appreciate >> their use of our parts, even if that use leads eventually to less >> business. > > I did not know this. Perhaps this is an area that Xilinx should look into. > Clearly in the future, the automation of ASIC design and manufacturing will > dramatically drop and engineers will be looking to ASICs for very small > production runs and they will want a seemless migration path. > >>>> On the other hand, since what we do we consider proprietary, we are not >>>> going to share schematics with you. >>> I understand the importance of proprietary intellectual property, as a >>> patent owner, better than most. However, it seems that keeping your >>> customers in the dark about what they are programming is >>> counterproductive. >>> What are Xilinx's real risks? And have they been ripped off in the past? >> Then you can appreciate that customers have trust in Xilinx not to do >> anything to make it trivial, or easy, for their clever IP to be ripped >> off. > > I think what we were talking about was the physical aspects of the Xilinx > fabric to give engineers the ability to think clearly about what is or could > be. Size and shape would be helpfull. I don't suggest that you give away > your schematics if you believe that another manufacturer might copy them > although I doubt that would happen. > > If it would help, I can document an example of how the lack of information > about the V4 ISERDES has increased my project length by about two months. If > anyone at Xilinx is interested in what I have to say that is. > >> As for being ripped off in the past, we have not been harmed per se, but >> customers have been harmed by a company cloning an entire pcb, and then >> copying the eproms, and selling that product for less money. I won't >> say who did this, as it is all litigated and settled now, and Xilinx >> derives benefit because both companies bought our FPGAs (the cloning >> company had to, as they had no means to modify or change the design, or >> even to fix any bugs). >> >> This is why today we offer the bitstream decryption features in V2, >> V2Pro, V2Pro-X, V4, and now V5. We will do whatever we can to help >> protect the customer's investment. > >> What you refer to as "Keeping our customer's in the dark" is in no way a >> hindrance, or a handicap, > > For example, I look at this slicem and slicel pattern on the editor. I have > no historical perspective of how this configuration came about, why they are > placed as they are, nor do I have any sense of their real size. I also can > not determine what logic they are performing through the editor. All I can > do is trace back my signals to the VHDL and guess what the synthesizer has > done. It's a big guessing game. How in the dark do you think I am? > >> as reverse engineering is perfectly legal to >> fix a problem, or discover how something works. > > Most engineers do not want to reverse engineer anything. It's time consuming > and not to their immedate goals. > >> We do not keep our >> customer's in the dark for a legitimate reason. > >> If someone has to reverse engineer something (for example: a soft error >> broke their design, which line of VHDL did that bit affect?) we are >> happy to work with them to resolve the issue by telling them exactly >> what they need to know (in fact, we will parse their design, and use our >> tools to discover what they require). > > I found that the comp.arch.fpga has been far more helpful than anything > Xilinx has done. A while ago I went through the process of putting in a > case about one of the GUIs that generates BRAM coeffcients and that the GUI > bombs with more than 16 or so coefficients. I spent more than a day > discovering, isolating and documenting the issue. The engineer told me that > the problem would get fixed, but, I never got word back that it did. I feel > that the my efforts in reporting this problem are undervalued. > > You know I picked Xilinx for three reasons over Altera. First, I called > Altera support, and could not speak to an engineer, whereas, I was able to > speak to someone at Xilinx. Second, the distributors Avnet had a free > beginners class and were very helpful. Third, this comp.arch.fpga seemed > fairly open and helpful to newcomers. > > I suggest that Xilinx open up its engineering even further than it has if it > wishes to remain the FPGA leader. > > Brad Smallridge > aivision > dot com > > >Article: 107643
Luhan wrote: > Glowing perfomance reviews and stock options are what companies give > valued employees instead of raises. Glowing perfomance reviews are your collaterial for a promotion. Stock options are way far over rated. In 19 out of 20 small to mid-sized companies they are worthless, and maybe worth less than your option price when you can finally cash them out. In larger companies, they might actually be worth something, or a golden handcuff that stops you from advancing faster by changing jobs. Stocks are gambling, and unless you are on top of the market, or extremely lucky, I'd not bet on them even being worth the overtime you might spend to justify them. Raises in almost every company are there for those that show steady improvement in skills at all levels, a strong work ethic, and a stronger interest in being successful and making the company successful. For those companies where this is not true, I'd change jobs, unless you have decided this a comfortable retirement job, AND you have some faith they will let you stay to retirement. Even then, I'd change jobs, because I HATE the lack of challenge in my job.Article: 107644
> Those skinny rectangles around the perimeter are to "clean up" the > boundary > of the device. The device is an array of regular building blocks. Each > building block has programmable logic and routing resources. So what do > you > do with the routing resources at the perimeter of the array? I really don't know. In my good old Atmel days, the express busses were terminated inside a cell somehow. > Clicking on > the routing resources where they enter these skinny rectangles will give > you > the answer. There seems to be a V shape connection between pairs that can be seen by double clicking inside the skinny box, or a cryptic post-place error if you click on the lines, but again, I'm in the dark. Brad SmallridgeArticle: 107645
On Wed, 30 Aug 2006 20:41:25 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:
>Hello Luhan,
>
>>
>> Glowing perfomance reviews and stock options are what companies give
>> valued employees instead of raises.
>>
>
>And stock options can be a darn good thing. It's the American way :-)
Can be, but often aren't. I've seen the existence of stock options
used as an excuse for keeping salaries low ("You'll get rich on the
options!"). All of my Intel options (seven years worth) are
underwater, most by a large enough margin that's there's little hope
that they'll be worth anything before they expire.
The story was similar at my previous company, and it was always
amusing that every time options were granted the stock price went down
a notch. So the options were never worth anything and had an effect
sort of the opposite of incentive (i.e., demoralizing). Once every
few years they'd restructure all the worthless options in order to get
some incentive back, and the stock would just drop further to negate
the new structure. It was comical once you got past the sadness. ;)
So I've got about sixteen years of "stock option incentives" that have
essentially cost me money. :(
Eric Jacobsen
Minister of Algorithms, Intel Corp.
My opinions may not be Intel's opinions.
http://www.ericjacobsen.org
Article: 107646<jjlindula@hotmail.com> wrote in message news:1156965525.874885.19940@m73g2000cwd.googlegroups.com... > Your comments are welcomed. Only ever got one of those. Threw it away unread.Article: 107647
<jjlindula@hotmail.com> wrote in message news:1156965525.874885.19940@m73g2000cwd.googlegroups.com... > Hello, I'm posting this question here because I want responses from > engineers, so please don't be offended. I want to know what your > thoughts are concerning Performance Appraisals at your company, are > they beneficial, how are they conducted, and what is the best way go > give performance appraisals? > My previous company defined "pillars" (personal, technical, career, business ...), career paths (technical, delivery management, project management...) and career levels (1=grad ... 7=MD), and published a document which attempted to define the essence of how a person at level X on path Y behaves in respect of pillar Z. Obviously, the language was a bit vague and hand-wavey in places - but what's the alternative? It's not easy to implement something that's fair and consistent across a company employing thousands worldwide. Staff commented on their own performance against pillars, and agreed objectives. Feedback was received from project managers for whom staff had worked during the year. The pillars provided a framework for the questionnaires which staff and managers had to fill-in. A lot was captured in writing. Everyone had a staff manager with whom all this was reviewed. The staff manager was ultimately the person who scored your performance. It's easy to be cynical on encountering the sort of management-speak in which these things are couched, or else get frustrated - especially if you're an engineer - about the apparent vagueness of the questions, but I always managed to think of something to put in every box eventually!Article: 107648
On Wed, 30 Aug 2006 20:40:26 GMT, in sci.electronics.design Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote: > > >Luhan wrote: > > >> >> Glowing perfomance reviews and stock options are what companies give >> valued employees instead of raises. > >Good point, Luhan. In the big company, there is a salary schedule: how >much is getting paid to a person in this position. There is actually no >way for them to give any raise. > >Also this is how the loafers from HR are making themselves look very useful. > >VLV > > > Then what is the alternative to HR, ( dont ask me, I havent had a "job" in almost 10 years), and I've never worked for a company that had a "modern" HR dept. In those days they where called " personnel" deparments, much more human martinArticle: 107649
On Wed, 30 Aug 2006 13:59:17 -0700, in sci.electronics.design Eric
Jacobsen <eric.jacobsen@ieee.org> wrote:
>On Wed, 30 Aug 2006 20:41:25 GMT, Joerg
><notthisjoergsch@removethispacbell.net> wrote:
>
>>Hello Luhan,
>>
>>>
>>> Glowing perfomance reviews and stock options are what companies give
>>> valued employees instead of raises.
>>>
>>
>>And stock options can be a darn good thing. It's the American way :-)
>
>Can be, but often aren't. I've seen the existence of stock options
>used as an excuse for keeping salaries low ("You'll get rich on the
>options!"). All of my Intel options (seven years worth) are
>underwater, most by a large enough margin that's there's little hope
>that they'll be worth anything before they expire.
>
>The story was similar at my previous company, and it was always
>amusing that every time options were granted the stock price went down
>a notch. So the options were never worth anything and had an effect
>sort of the opposite of incentive (i.e., demoralizing). Once every
>few years they'd restructure all the worthless options in order to get
>some incentive back, and the stock would just drop further to negate
>the new structure. It was comical once you got past the sadness. ;)
>
>So I've got about sixteen years of "stock option incentives" that have
>essentially cost me money. :(
>
>
>Eric Jacobsen
>Minister of Algorithms, Intel Corp.
>My opinions may not be Intel's opinions.
>http://www.ericjacobsen.org
wrong Algorithm maybe?
<sorry>
martin
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