Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 107625

Article: 107625
Subject: Performance Appraisals
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: 30 Aug 2006 12:18:45 -0700
Links: << >>  << T >>  << A >>
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: 107626
Subject: Re: Style of coding complex logic (particularly state machines)
From: "Andy" <jonesandy@comcast.net>
Date: 30 Aug 2006 12:23:11 -0700
Links: << >>  << T >>  << A >>
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: 107627
Subject: Re: Performance Appraisals
From: Vladimir Vassilevsky <antispam_bogus@hotmail.com>
Date: Wed, 30 Aug 2006 19:28:50 GMT
Links: << >>  << T >>  << A >>
Joe,

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
Subject: Re: Performance Appraisals
From: Scott Seidman <namdiesttocs@mindspring.com>
Date: 30 Aug 2006 19:32:40 GMT
Links: << >>  << T >>  << A >>
"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 reply

Article: 107629
Subject: Re: Performance Appraisals
From: "Nial Stewart" <nial@nialstewartdevelopments.co.uk>
Date: Wed, 30 Aug 2006 20:36:46 +0100
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Virtex-4FX DCM autoshutdown failure, any suggestions
From: "Antti" <Antti.Lukats@xilant.com>
Date: 30 Aug 2006 12:58:23 -0700
Links: << >>  << T >>  << A >>
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: 107631
Subject: Re: Performance Appraisals
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Wed, 30 Aug 2006 20:08:36 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 107632
Subject: Re: Performance Appraisals
From: fpga_toys@yahoo.com
Date: 30 Aug 2006 13:09:55 -0700
Links: << >>  << T >>  << A >>

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!
John


Article: 107633
Subject: Re: Spartan-4 ?
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 30 Aug 2006 22:14:27 +0200
Links: << >>  << T >>  << A >>
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,



Ben


Article: 107634
Subject: Re: Spartan-4 ?
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 30 Aug 2006 22:20:08 +0200
Links: << >>  << T >>  << A >>
Aurelian Lazarut wrote:

> Luc,
> I think is more like "spartex" or "virtan"   in X-world.  ;-)
> 

Hmmm... Spandex IV - the stretchable FPGA fabric... ;-)


Ben


Article: 107635
Subject: Re: Virtex-4FX DCM autoshutdown failure, any suggestions
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Aug 2006 16:20:51 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Virtex-4FX DCM autoshutdown failure, any suggestions
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 30 Aug 2006 13:23:59 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Question on Virtex-4 CLB
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 30 Aug 2006 13:28:03 -0700
Links: << >>  << T >>  << A >>

> 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: 107638
Subject: Re: Performance Appraisals
From: "Luhan" <luhanis@yahoo.com>
Date: 30 Aug 2006 13:31:31 -0700
Links: << >>  << T >>  << A >>

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.

Luhan


Article: 107639
Subject: xgpio_DiscreteRead
From: "jerzy.zielinski" <jerzy.zielinski@gmail.com>
Date: 30 Aug 2006 13:34:58 -0700
Links: << >>  << T >>  << A >>
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: 107640
Subject: Re: Performance Appraisals
From: Vladimir Vassilevsky <antispam_bogus@hotmail.com>
Date: Wed, 30 Aug 2006 20:40:26 GMT
Links: << >>  << T >>  << A >>


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





Article: 107641
Subject: Re: Performance Appraisals
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Wed, 30 Aug 2006 20:41:25 GMT
Links: << >>  << T >>  << A >>
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.com

Article: 107642
Subject: Re: Questions
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 30 Aug 2006 13:54:55 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Performance Appraisals
From: fpga_toys@yahoo.com
Date: 30 Aug 2006 13:55:55 -0700
Links: << >>  << T >>  << A >>

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
Subject: Re: Question on Virtex-4 CLB
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 30 Aug 2006 13:58:56 -0700
Links: << >>  << T >>  << A >>
> 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 Smallridge 



Article: 107645
Subject: Re: Performance Appraisals
From: Eric Jacobsen <eric.jacobsen@ieee.org>
Date: Wed, 30 Aug 2006 13:59:17 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Performance Appraisals
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Wed, 30 Aug 2006 21:00:16 GMT
Links: << >>  << T >>  << A >>

<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
Subject: Re: Performance Appraisals
From: "Andrew Holme" <andrew@nospam.com>
Date: Wed, 30 Aug 2006 22:03:52 +0100
Links: << >>  << T >>  << A >>

<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
Subject: Re: Performance Appraisals
From: martin griffith <mart_in_medina@yahoo.esXXX>
Date: Wed, 30 Aug 2006 23:04:29 +0200
Links: << >>  << T >>  << A >>
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


martin

Article: 107649
Subject: Re: Performance Appraisals
From: martin griffith <mart_in_medina@yahoo.esXXX>
Date: Wed, 30 Aug 2006 23:07:56 +0200
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search