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 150475

Article: 150475
Subject: Re: Xilinx news
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 24 Jan 2011 09:49:32 -0800
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner"
<zapwireDASHgroups@yahoo.com> wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:4gcrj690ue2un4cu7d0fen5vjcq43pci6l@4ax.com...
>> The software is the heart of an FPGA company.
>
>Glad to know I'm not the only one who thought the first response to that 
>article:
>
>"Xilinx sell hardware, software especially high level tools is secondary."
>
>...was a bit clueless!

And the bitstream structure is secret, so third parties can't supply
end-to-end software, as far as I'm aware. I bet some small IP house
could do a better job. 

John


Article: 150476
Subject: Re: Xilinx news
From: d_s_klein <d_s_klein@yahoo.com>
Date: Mon, 24 Jan 2011 10:37:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 23, 1:36=A0pm, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:
> On Mon, 24 Jan 2011 08:35:19 +1100, "Phil Allison" <phi...@tpg.com.au> wr=
ote:
>
> ><k...@att.bizzzzzzzzzzzz>
>
> >** You are a total cunthead and a massive liar.
>
> You already said that Phyllis. =A0You're not adding anything to the group=
 now.

This will help deal with Phyllis: <http://groups.google.com/group/
comp.arch.fpga/browse_thread/thread/b633ae5fc3619c99#>

Article: 150477
Subject: Re: Xilinx news
From: Les Cargill <lcargill99@comcast.net>
Date: Mon, 24 Jan 2011 13:50:29 -0500
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On Mon, 24 Jan 2011 09:09:42 +0100, David Brown
> <david@westcontrol.removethisbit.com>  wrote:
>
>> On 23/01/2011 06:10, John Larkin wrote:
>>> On Sat, 22 Jan 2011 23:03:16 -0600, "krw@att.bizzzzzzzzzzzz"
>>> <krw@att.bizzzzzzzzzzzz>   wrote:
>>>
>>>> On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin
>>>> <jjlarkin@highNOTlandTHIStechnologyPART.com>   wrote:
>>>>
>>>>> http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation
>>>>>
>>>>> Yikes, this explains some stuff. I wonder how long it will take to
>>>>> undo the damage.
>>>>
>>>> Damage?  The damage caused by closing a software development lab?
>>>
>>> I meant the damage likely *done* by that lab. We'd been speculating
>>> how Xininx managed to snarl up their software so thoroughly, and
>>> whether they will ever get it fixed. I can't imagine why they'd
>>> outsource something this important to France.
>>>
>>
>> I find it hard to believe that supposedly educated, intelligent and
>> experienced engineers can post such ignorant xenophobic drivel.
>
> Well, two facts exist:
>
> 1. Their software is a nightmare, and it's costing them business
>
> 2. They are dumping the French operation.
>
> The software is the heart of an FPGA company. The very architecture of
> the chip has to be coordinated with possible compiler strategies. The
> idea of outsourcing anything this important to a group 8 or 9 time
> zones away, working in another language, in a country where it's
> almost impossible to fire incompetant workers, where people take long
> lunches with wine and don't work weekends, just amazes me.
>

While there may or may not be a lot of French software workers
out there, I've worked with a handful who were pretty good.

And more than once, I've done things in software to where I *wished*
I'd taken a long lunch, with or without wine. :) Nothing
particularly tragic, there - software is specifically resistant
to both the work ethic and to other input analyses.

>>
>> Xilinx (or rather, their users and customers) have trouble with the
>> Xilinx software because the Xilinx leadership do not prioritise it
>> appropriately, and (apparently) do not listen to or understand the
>> issues customers have with the software.  They alone are at fault.  It
>> could well be that the main management fault was to hire a development
>> team that was not competent to do the development - but the problem is
>> their lack of competence, not their nationality!
>
> I'd have been equally surprised had they outsourced anything this
> core-critical to any other country that far from San Jose. Big
> Software is nearly impossible to manage even without an ocean in the
> way.
>

I'd almost say it's just equally impossible. Hard to say in detail
without specifics. But interfaces are always hard.

>
>>
>> I know that sci.electronics.design is a hangout for mostly geriatric
>> American right-wingers who like to spend their free time blaming the
>> world's ills on "leftist weenies", foreigners, atheists, intellectuals,
>> and other dangerous sub-humans.
>
> Jim isn't typical.
>
> John
>

--
Les Cargill

Article: 150478
Subject: Problem with iMpact
From: ghelbig <ghelbig@lycos.com>
Date: Mon, 24 Jan 2011 10:50:34 -0800 (PST)
Links: << >>  << T >>  << A >>
I think that iMpact is messing with me.

Here's what I do:

1) Create a bit file with ISE 11.5
2) Downloading the bit file to my Virtex-5 via JTAG.  (I'm using a
DLC9G and WinXP)
3) Run a regression test on the system.

If the regression test passes I do the following:

4) Create a MCS file with iMpact.
5) Load the MCS into the attached SPI chip (again, with the DLC9G)
6) Power cycle the board.
7) Re-run the regression test.

Here's my issue:

I have two bit files for this project.  One was created last month,
one was created last week.  The steps above are repeated EXACTLY for
the two bit files.  There are no warnings or errors generated with
steps 2 through 6.

Step 7 fails for one bit file, and passes for the other.  With one bit
file, and chip never leaves the DONE state.  Keep in mind that both
bit files load and run "just fine" when I load them through the JTAG
port.

Has anyone seen this before?  I haven't gotten any help from the
factory yet.

Regards,
G.

Article: 150479
Subject: Phil and Archie?
From: Greegor <greegor47@gmail.com>
Date: Mon, 24 Jan 2011 11:02:02 -0800 (PST)
Links: << >>  << T >>  << A >>
How will any of this ameliorate coprolalia by Phil Allison and Archie?

Article: 150480
Subject: Re: Xilinx news
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Jan 2011 11:51:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 12:21=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Mon, 24 Jan 2011 09:09:42 +0100, David Brown
>
> <da...@westcontrol.removethisbit.com> wrote:
>
> >I find it hard to believe that supposedly educated, intelligent and
> >experienced engineers can post such ignorant xenophobic drivel.
>
> Well, two facts exist:
>
> 1. Their software is a nightmare, and it's costing them business
>
> 2. They are dumping the French operation.
>
> The software is the heart of an FPGA company. The very architecture of
> the chip has to be coordinated with possible compiler strategies. The
> idea of outsourcing anything this important to a group 8 or 9 time
> zones away, working in another language, in a country where it's
> almost impossible to fire incompetant workers, where people take long
> lunches with wine and don't work weekends, just amazes me.

This is probably a discussion to stay out of, but I want to correct a
misapprehension on your part.  I have worked with the French at a
major telecom company and will tell you that they are no more
incompetent or drunk than American workers.  The continent does have a
different work culture in terms of leave.  They get lots more vacation
than we typically do and they manage to get their work done without
working late nights and weekends.

Actually I have always thought it very odd that US workers were
willing to take on the burden of completing projects on time and
budget when they have little or no say in the process of setting those
goals.  Lets face it.  Being willing to work unlimited, unpaid
overtime is something that the majority of workers in the US are
unwilling to do.  For some reason engineers seem to be in a class all
by themselves in that regard here in the US.  What other professions
are willing to do that?


> >Xilinx (or rather, their users and customers) have trouble with the
> >Xilinx software because the Xilinx leadership do not prioritise it
> >appropriately, and (apparently) do not listen to or understand the
> >issues customers have with the software. =A0They alone are at fault. =A0=
It
> >could well be that the main management fault was to hire a development
> >team that was not competent to do the development - but the problem is
> >their lack of competence, not their nationality!
>
> I'd have been equally surprised had they outsourced anything this
> core-critical to any other country that far from San Jose. Big
> Software is nearly impossible to manage even without an ocean in the
> way.

Distance doesn't create problems in management... management creates
problems in management.  I've worked on projects where no two people
were in the same city and they progressed well, except for the
management which kept feeding lies upstream in order to tell them what
they wanted to hear.  I guess one difference is that it is a bit
harder to manage by "walking around", something upper management
should do.  Then they can find out things that they aren't being
told.

But none of this has to do with nationality.

Rick

Article: 150481
Subject: Re: Xilinx news
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Jan 2011 11:53:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 12:49=A0pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner"
>
> <zapwireDASHgro...@yahoo.com> wrote:
> >"John Larkin" <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in mess=
age
> >news:4gcrj690ue2un4cu7d0fen5vjcq43pci6l@4ax.com...
> >> The software is the heart of an FPGA company.
>
> >Glad to know I'm not the only one who thought the first response to that
> >article:
>
> >"Xilinx sell hardware, software especially high level tools is secondary=
."
>
> >...was a bit clueless!
>
> And the bitstream structure is secret, so third parties can't supply
> end-to-end software, as far as I'm aware. I bet some small IP house
> could do a better job.
>
> John

They did, it was called NeoCAD and they were bought by Xilinx!

Rick

Article: 150482
Subject: Re: Xilinx news
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 24 Jan 2011 13:58:56 -0600
Links: << >>  << T >>  << A >>
On 01/22/2011 11:10 PM, John Larkin wrote:

> I meant the damage likely *done* by that lab. We'd been speculating
> how Xininx managed to snarl up their software so thoroughly, and
> whether they will ever get it fixed. I can't imagine why they'd
> outsource something this important to France.
One word, Alcatel.

Jon

Article: 150483
Subject: Xilinx news, David Brown and ""Xenophobia"" (see H1b FRAUD!)
From: Greegor <greegor47@gmail.com>
Date: Mon, 24 Jan 2011 11:59:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 2:09 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> I find it hard to believe that supposedly educated, intelligent and
> experienced engineers can post such ignorant xenophobic drivel.
>
> Xilinx (or rather, their users and customers) have trouble with the
> Xilinx software because the Xilinx leadership do not prioritise it
> appropriately, and (apparently) do not listen to or understand the
> issues customers have with the software.  They alone are at fault.  It
> could well be that the main management fault was to hire a development
> team that was not competent to do the development - but the problem is
> their lack of competence, not their nationality!
>
> I know that sci.electronics.design is a hangout for mostly geriatric
> American right-wingers who like to spend their free time blaming the
> world's ills on "leftist weenies", foreigners, atheists, intellectuals,
> and other dangerous sub-humans.

You left out OUTSOURCING, Downsizing,
dumping out staff en masse and hiring them
all back as contractors to avoid social
responsibilities, Pensions and raiding thereof,
H1b visas and the way corporations take
classes on how to BS around the law
that requires them to hire qualified US people
for the jobs first, etc.  (Where WERE you
back in Jan 2010 when that was discussed?)

I would EXPECT that most US Engineers
would be very well focused on all of those
threats to their livelyhood, wouldn't you??

If you're gonna try this Xenophobia canard
you MIGHT want to WATCH THIS FIRST!
(Even more references at bottom of post)

http://www.youtube.com/watch?v=TCbFEgFajGU

> That's fair enough, within the limits
> of freedom of speech.  It can even be entertaining at times.  But please
> keep that sort of thing within s.e.d. and not serious newsgroups.
>
> Follow-up flames to s.e.d., and leave c.a.f. alone for a possible
> discussion about the actual effect of this news on Xilinx and its customers.

I look forward to you serious discussion and problem resolution.


On Mon, 24 Jan 2011 09:30:17 -0800, "Joel Koltner" wrote:
Glad to know I'm not the only one who thought the first response to
that
article:
"Xilinx sell hardware, software especially high level tools is
secondary."
...was a bit clueless!

On Jan 24, 11:49 am, John Larkin wrote:
And the bitstream structure is secret, so third parties can't supply
end-to-end software, as far as I'm aware. I bet some small IP house
could do a better job.

-----------------------------------








http://groups.google.com/group/sci.electronics.design/msg/3f074e88bda71375

PERM Fake Job Ads defraud Americans to secure green cards for H-1b
workers

http://www.youtube.com/watch?v=TCbFEgFajGU

> Immigration attorneys from Cohen & Grigsby explains how they assist
> employers in running classified ads with the goal of NOT finding any
> qualified applicants, and the steps they go through to disqualify even
> the most qualified Americans in order to secure green cards for H-1b
> workers. See what politicians call a "shortage of skilled U.S.
> workers." Microsoft, Oracle, Hewlett-Packard, and thousands of other
> companies are running fake ads in Sunday newspapers across the country
> each week.

G > Has Obama reversed this fraud?

"Ban"  through a german anonymous remailer motzarella wrote
Ban > Sorry you didn't find a job, but maybe it's because your
Ban > qualification is sub standard. I wouldn't employ a
Ban > complainer like this who blames all those Mexicans for
Ban > taking away engineering jobs.    ciao Ban

Hillary Clinton Pushes For More H1B Visas and OutSourcing   June 2007

http://www.youtube.com/watch?v=UhLBSLLIhUs

Hillary Clinton reaffirms support for more H-1B visas    July 2007

http://www.youtube.com/watch?v=AOW0cUaGWZU

H 1B visa racket busted in US, 11 Indians arrested   Feb 14, 2009

http://www.youtube.com/watch?v=Uaofpy3D-oE

H1-B visa bar disappoints young Indians    Feb 16, 2009

http://www.youtube.com/watch?v=ohaSa_1WZVo

Visa Consultants selling H-1b visas    July 2007

http://www.youtube.com/watch?v=bOqOxYr4F18

WashTech on Microsoft Replacing American Workers   Feb 10 2009

http://www.youtube.com/watch?v=SwnvkK94o3I

Immigration Gumballs   - notice the graphs   Nov 2006

http://www.youtube.com/watch?v=n7WJeqxuOfQ


Article: 150484
Subject: Re: Problem with iMpact
From: Gabor <gabor@alacron.com>
Date: Mon, 24 Jan 2011 12:23:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 1:50=A0pm, ghelbig <ghel...@lycos.com> wrote:
> I think that iMpact is messing with me.
>
> Here's what I do:
>
> 1) Create a bit file with ISE 11.5
> 2) Downloading the bit file to my Virtex-5 via JTAG. =A0(I'm using a
> DLC9G and WinXP)
> 3) Run a regression test on the system.
>
> If the regression test passes I do the following:
>
> 4) Create a MCS file with iMpact.
> 5) Load the MCS into the attached SPI chip (again, with the DLC9G)
> 6) Power cycle the board.
> 7) Re-run the regression test.
>
> Here's my issue:
>
> I have two bit files for this project. =A0One was created last month,
> one was created last week. =A0The steps above are repeated EXACTLY for
> the two bit files. =A0There are no warnings or errors generated with
> steps 2 through 6.
>
> Step 7 fails for one bit file, and passes for the other. =A0With one bit
> file, and chip never leaves the DONE state. =A0Keep in mind that both
> bit files load and run "just fine" when I load them through the JTAG
> port.
>
> Has anyone seen this before? =A0I haven't gotten any help from the
> factory yet.
>
> Regards,
> G.

The first thing I look for is whether the .mcs file was really created
correctly.
I have been burned by the ISE GUI grabbing an existing impact project
that
built a new .mcs file from an old .bit file.

If you look in the directory where the .mcs file was built, there
should also
be a .prm file with the same base file name.  In this file you can see
the
name and modification date of the .bit file(s) that were used in
creating
the .mcs file.

Also I have had some issues with indirect SPI programming using
impact.  However usually these show up as an error when you go to
verify the .mcs file in SPI flash.  When you say "never leaves the
DONE state" do you mean that DONE never goes high?  Or does
DONE go high, but the chip never comes out of reset.  The latter
condition can be bitstream-dependent although I've never seen
this behavior when using Master-SPI config mode.  Just be sure
that you use the default startup clock (CCLK) when you run
BitGen.

-- Gabor

Article: 150485
Subject: Re: Xilinx news
From: upsidedown@downunder.com
Date: Mon, 24 Jan 2011 22:31:04 +0200
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 09:21:27 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>
>I'd have been equally surprised had they outsourced anything this
>core-critical to any other country that far from San Jose. Big
>Software is nearly impossible to manage even without an ocean in the
>way.

If you intend to outsource something, you really must concentrate on
writing sensible _good_quality_ specifications.

With the coders in the next cubicle (at least in the same time zone),
you can always discuss the problems immediately,

With development teams in the Americas, Europe and Asia, the common
real time discussion window is quite limited due to the time zones.

 

Article: 150486
Subject: statement is not synthesizable since it does not hold its value under
From: =?ISO-8859-1?Q?Trygve_Laugst=F8l?= <trygvis@inamo.no>
Date: Mon, 24 Jan 2011 21:32:01 +0100
Links: << >>  << T >>  << A >>
Hello!

I'm trying to get the following snippet to work and I'm 1) wondering 
what's wrong and 2) wondering if I'm going about this the right way.

I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz) 
which control the CPU and the output to the LCD (obviously enough). What 
I want to happen is that the CPU will set trigger on the leading edge of 
the CPU clock and clear it on the falling edge of the LCD clock (which 
should ensure that it has been picked up by the 'main' process).

The error message I'm getting is "statement is not synthesizable since 
it does not hold its value under NOT(clock-edge) condition".

The code:

     trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
     begin
         trigger <= '0';
         if reset = '1' then
             trigger <= '0';
         elsif clk'event and clk = '1' and output_trigger = '1' then
             trigger <= '1';
         elsif clk_200kHz'event and clk_200kHz = '0' then
             trigger <= '0';
         end if;
     end process;

     main: process(...)
         if reset
             ...
         elsif clk_200kHz'event and clk_200kHz = '1' then
             ...
         end if;
     end process;

Article: 150487
Subject: Re: statement is not synthesizable since it does not hold its value
From: Gabor <gabor@alacron.com>
Date: Mon, 24 Jan 2011 12:41:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 3:32=A0pm, Trygve Laugst=F8l <tryg...@inamo.no> wrote:
> Hello!
>
> I'm trying to get the following snippet to work and I'm 1) wondering
> what's wrong and 2) wondering if I'm going about this the right way.
>
> I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz)
> which control the CPU and the output to the LCD (obviously enough). What
> I want to happen is that the CPU will set trigger on the leading edge of
> the CPU clock and clear it on the falling edge of the LCD clock (which
> should ensure that it has been picked up by the 'main' process).
>
> The error message I'm getting is "statement is not synthesizable since
> it does not hold its value under NOT(clock-edge) condition".
>
> The code:
>
> =A0 =A0 =A0trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 =A0trigger <=3D '0';
> =A0 =A0 =A0 =A0 =A0if reset =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '0';
> =A0 =A0 =A0 =A0 =A0elsif clk'event and clk =3D '1' and output_trigger =3D=
 '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '1';
> =A0 =A0 =A0 =A0 =A0elsif clk_200kHz'event and clk_200kHz =3D '0' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0trigger <=3D '0';
> =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0end process;
>
> =A0 =A0 =A0main: process(...)
> =A0 =A0 =A0 =A0 =A0if reset
> =A0 =A0 =A0 =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0 =A0elsif clk_200kHz'event and clk_200kHz =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0end process;

First, I know of no FPGA that has dual-clocked flip-flops available in
the internal
fabric.  So it's no wonder that the code is not synthesizable.

Second, 200 KHz is really slow, so you should probably just sample it
with the
48 MHz CPU clock and use the sampled signal with another flip-flop
delay
to detect edges instead of trying to create a dual-clocked process.

Third.  It's not clear to me that you are taking care of
synchronization properly
here.  If the intent is for a single event on the CPU clock to create
an output
that can be sampled at the falling edge of the 200 KHz clock, then I
don't
see how you will ensure any minimum setup time unless the event was
already somehow synchronous to the 200 KHz clock.

-- Gabor

Article: 150488
Subject: Re: statement is not synthesizable since it does not hold its value
From: =?ISO-8859-1?Q?Trygve_Laugst=F8l?= <trygvis@inamo.no>
Date: Mon, 24 Jan 2011 21:47:26 +0100
Links: << >>  << T >>  << A >>
[Note that I'm quite a newbie to VHDL]

On 1/24/11 9:41 PM, Gabor wrote:
> On Jan 24, 3:32 pm, Trygve Laugstøl<tryg...@inamo.no>  wrote:
>> Hello!
>>
>> I'm trying to get the following snippet to work and I'm 1) wondering
>> what's wrong and 2) wondering if I'm going about this the right way.
>>
>> I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz)
>> which control the CPU and the output to the LCD (obviously enough). What
>> I want to happen is that the CPU will set trigger on the leading edge of
>> the CPU clock and clear it on the falling edge of the LCD clock (which
>> should ensure that it has been picked up by the 'main' process).
>>
>> The error message I'm getting is "statement is not synthesizable since
>> it does not hold its value under NOT(clock-edge) condition".
>>
>> The code:
>>
>>       trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
>>       begin
>>           trigger<= '0';
>>           if reset = '1' then
>>               trigger<= '0';
>>           elsif clk'event and clk = '1' and output_trigger = '1' then
>>               trigger<= '1';
>>           elsif clk_200kHz'event and clk_200kHz = '0' then
>>               trigger<= '0';
>>           end if;
>>       end process;
>>
>>       main: process(...)
>>           if reset
>>               ...
>>           elsif clk_200kHz'event and clk_200kHz = '1' then
>>               ...
>>           end if;
>>       end process;
>
> First, I know of no FPGA that has dual-clocked flip-flops available in
> the internal
> fabric.  So it's no wonder that the code is not synthesizable.

Hm, I though this should synthesize a S/R+reset flip flop but I guess 
because of the 'event it will become clocks instead.

> Second, 200 KHz is really slow, so you should probably just sample it
> with the
> 48 MHz CPU clock and use the sampled signal with another flip-flop
> delay
> to detect edges instead of trying to create a dual-clocked process.

How would that work? It is generated from the 48MHz clock already just 
on the outside of the entity.

> Third.  It's not clear to me that you are taking care of
> synchronization properly
> here.  If the intent is for a single event on the CPU clock to create
> an output
> that can be sampled at the falling edge of the 200 KHz clock, then I
> don't
> see how you will ensure any minimum setup time unless the event was
> already somehow synchronous to the 200 KHz clock.

Hm, I'm not really seeing the problem but that's probably because of my 
lack of understanding. Could you elaborate or show/point me some code 
that does what I want to do? I've been trying to read up on links from 
searches like "clock synchronization" and "clock domains" but haven't 
found something that really applies to my case (and makes sense to me).

--
Trygve

Article: 150489
Subject: Re: Xilinx news
From: Greegor <greegor47@gmail.com>
Date: Mon, 24 Jan 2011 13:17:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 1:58=A0pm, Jon Elson <jmel...@wustl.edu> wrote:
> On 01/22/2011 11:10 PM, John Larkin wrote:
>
> > I meant the damage likely *done* by that lab. We'd been speculating
> > how [ Xilinx ]  managed to snarl up their software so thoroughly, and
> > whether they will ever get it fixed. I can't imagine why they'd
> > outsource something this important to France.
>
> One word, Alcatel.
>
> Jon

History

The formation of Alcatel-Lucent created the world=92s first truly global
communications solutions provider, with the most complete end-to-end
portfolio of solutions and services in the industry.

Alcatel-Lucent combined two entities =97 Alcatel and Lucent Technologies
=97 which shared a common lineage dating back to 1986. That was the year
Alcatel=92s parent company, CGE (la Compagnie G=E9n=E9rale d=92Electricit=
=E9),
acquired ITT=92s European telecom business. Nearly 60 years earlier, ITT
had purchased most of AT&T=92s manufacturing operations outside the
United States. Lucent Technologies was spun off from AT&T.


Article: 150490
Subject: Re: Xilinx news
From: Greegor <greegor47@gmail.com>
Date: Mon, 24 Jan 2011 13:21:12 -0800 (PST)
Links: << >>  << T >>  << A >>
PA > ** You are a total cunthead and a massive liar.

krw  > You already said that Phyllis. =A0You're not adding anything to
the group now.

dsk > This will help deal with Phyllis:

Nah.  Phil is nastier than a hemmorhoid.

From puiterl@notaimvalley.nl Mon Jan 24 13:30:11 2011
Path: unlimited.newshosting.com!s03-b24.iad!npeersf01.iad.highwinds-media.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news3.google.com!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Message-Id: <4d3def63$0$81483$e4fe514c@news.xs4all.nl>
From: Paul Uiterlinden <puiterl@notaimvalley.nl>
Subject: Re: statement is not synthesizable since it does not hold its value under NOT(clock-edge) condition
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Followup-To: comp.arch.fpga
Date: Mon, 24 Jan 2011 22:30:11 +0100
References: <4d3de1c1$1@news.broadpark.no>
Organization: AimValley
User-Agent: KNode/0.10.5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
Lines: 38
NNTP-Posting-Host: 195.242.97.150
X-Trace: 1295904611 news.xs4all.nl 81483 puiterl/[::ffff:195.242.97.150]:45199
X-Complaints-To: abuse@xs4all.nl
Xref: unlimited.newshosting.com comp.arch.fpga:108184 comp.lang.vhdl:38275
X-Received-Date: Mon, 24 Jan 2011 21:31:16 UTC (s03-b24.iad)

Trygve Laugstøl wrote:

> Hello!
> 
> I'm trying to get the following snippet to work and I'm 1) wondering
> what's wrong

The first assignment to "trigger" (right after the "begin") cannot be right.

What you have described here is something like: "reset trigger on any event
on signals reset, clk, clk_200kHz and output_trigger, unless there is a
rising edge on clk while output_trigger is '1'. In the latter case, set
trigger."

If you leave out the first assignment, things perhaps start looking what you
want. If it will be synthesisable, I don't know (I don't do synthesis).

Have you simulated this code at all?

> The code:
> 
>      trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
>      begin
>          trigger <= '0';
>          if reset = '1' then
>              trigger <= '0';
>          elsif clk'event and clk = '1' and output_trigger = '1' then
>              trigger <= '1';
>          elsif clk_200kHz'event and clk_200kHz = '0' then
>              trigger <= '0';
>          end if;
>      end process;
> 

-- 
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

Article: 150491
Subject: Re: statement is not synthesizable since it does not hold its value
From: =?UTF-8?B?VHJ5Z3ZlIExhdWdzdMO4bA==?= <trygvis@inamo.no>
Date: Mon, 24 Jan 2011 22:53:24 +0100
Links: << >>  << T >>  << A >>
On 1/24/11 10:30 PM, Paul Uiterlinden wrote:
> Trygve Laugstøl wrote:
>
>> Hello!
>>
>> I'm trying to get the following snippet to work and I'm 1) wondering
>> what's wrong
>
> The first assignment to "trigger" (right after the "begin") cannot be right.
>
> What you have described here is something like: "reset trigger on any event
> on signals reset, clk, clk_200kHz and output_trigger, unless there is a
> rising edge on clk while output_trigger is '1'. In the latter case, set
> trigger."
>
> If you leave out the first assignment, things perhaps start looking what you
> want. If it will be synthesisable, I don't know (I don't do synthesis).
>
> Have you simulated this code at all?

No, it fails with the error message in the subject.

--
Trygve

Article: 150492
Subject: Re: statement is not synthesizable since it does not hold its value
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Jan 2011 14:00:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 3:47 pm, Trygve Laugst=F8l <tryg...@inamo.no> wrote:
> [Note that I'm quite a newbie to VHDL]
>
> On 1/24/11 9:41 PM, Gabor wrote:
>
>
>
> > On Jan 24, 3:32 pm, Trygve Laugst=F8l<tryg...@inamo.no>  wrote:
> >> Hello!
>
> >> I'm trying to get the following snippet to work and I'm 1) wondering
> >> what's wrong and 2) wondering if I'm going about this the right way.
>
> >> I have two clocks, one CPU clock (at 48MHz) and a LCD clock (200kHz)
> >> which control the CPU and the output to the LCD (obviously enough). Wh=
at
> >> I want to happen is that the CPU will set trigger on the leading edge =
of
> >> the CPU clock and clear it on the falling edge of the LCD clock (which
> >> should ensure that it has been picked up by the 'main' process).
>
> >> The error message I'm getting is "statement is not synthesizable since
> >> it does not hold its value under NOT(clock-edge) condition".
>
> >> The code:
>
> >>       trigger_xfer: process(reset, clk, clk_200kHz, output_trigger)
> >>       begin
> >>           trigger<=3D '0';
> >>           if reset =3D '1' then
> >>               trigger<=3D '0';
> >>           elsif clk'event and clk =3D '1' and output_trigger =3D '1' t=
hen
> >>               trigger<=3D '1';
> >>           elsif clk_200kHz'event and clk_200kHz =3D '0' then
> >>               trigger<=3D '0';
> >>           end if;
> >>       end process;
>
> >>       main: process(...)
> >>           if reset
> >>               ...
> >>           elsif clk_200kHz'event and clk_200kHz =3D '1' then
> >>               ...
> >>           end if;
> >>       end process;
>
> > First, I know of no FPGA that has dual-clocked flip-flops available in
> > the internal
> > fabric.  So it's no wonder that the code is not synthesizable.
>
> Hm, I though this should synthesize a S/R+reset flip flop but I guess
> because of the 'event it will become clocks instead.
>
> > Second, 200 KHz is really slow, so you should probably just sample it
> > with the
> > 48 MHz CPU clock and use the sampled signal with another flip-flop
> > delay
> > to detect edges instead of trying to create a dual-clocked process.
>
> How would that work? It is generated from the 48MHz clock already just
> on the outside of the entity.
>
> > Third.  It's not clear to me that you are taking care of
> > synchronization properly
> > here.  If the intent is for a single event on the CPU clock to create
> > an output
> > that can be sampled at the falling edge of the 200 KHz clock, then I
> > don't
> > see how you will ensure any minimum setup time unless the event was
> > already somehow synchronous to the 200 KHz clock.
>
> Hm, I'm not really seeing the problem but that's probably because of my
> lack of understanding. Could you elaborate or show/point me some code
> that does what I want to do? I've been trying to read up on links from
> searches like "clock synchronization" and "clock domains" but haven't
> found something that really applies to my case (and makes sense to me).
>
> --
> Trygve

Here is how I do it.  I cut this from a program and ripped out all the
other code to just highlight the edge detection.   Replace TT_B2 with
your LCD clock and add your code where indicated.  The function
NegEdge() just ANDs TT_DD with not TT_D to make it clear what the IF
statement is doing.  There will be a delay of one to two clock cycles
from the edge of your slow clock before the code in the IF statement
is executed, but with your app, I expect this doesn't matter.

  CTPData: process (SysClk, SysRst) begin
    if (SysRst =3D '1') then
	  TT_D			<=3D '0';
	  TT_DD			<=3D '0';
    elsif (rising_edge(SysClk)) then
	  TT_D			<=3D TT_B2;
	  TT_DD			<=3D TT_D;
	  -- RD output interface
	  if (NegEdge(TT_D, TT_DD)) then -- falling edge of TT data strobe
		-- This is where you put your LCD code
	  end if;  -- NegEdge(TT
	end if;  -- elsif (rising_edge(SysClk
  end process CTPData;

This approach solves a lot of problems.  It gets rid of communication
issues between clock domains and the two FFs handle metastability
issues, which you can still have even though the two frequencies are
locked, the phase is likely not.  If you really want to be sure of
dealing with meta stability, combine the two delay FFs and register
that.  With only one LUT, 20 ns will be lots of settling time.

Rick

Article: 150493
Subject: Re: Xilinx news
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 24 Jan 2011 14:16:01 -0800
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 13:17:46 -0800 (PST), Greegor
<greegor47@gmail.com> wrote:

>On Jan 24, 1:58 pm, Jon Elson <jmel...@wustl.edu> wrote:
>> On 01/22/2011 11:10 PM, John Larkin wrote:
>>
>> > I meant the damage likely *done* by that lab. We'd been speculating
>> > how [ Xilinx ]  managed to snarl up their software so thoroughly, and
>> > whether they will ever get it fixed. I can't imagine why they'd
>> > outsource something this important to France.
>>
>> One word, Alcatel.
>>
>> Jon
>
>History
>
>The formation of Alcatel-Lucent created the world’s first truly global
>communications solutions provider, with the most complete end-to-end
>portfolio of solutions and services in the industry.
>
>Alcatel-Lucent combined two entities — Alcatel and Lucent Technologies
>— which shared a common lineage dating back to 1986. That was the year
>Alcatel’s parent company, CGE (la Compagnie Générale d’Electricité),
>acquired ITT’s European telecom business. Nearly 60 years earlier, ITT
>had purchased most of AT&T’s manufacturing operations outside the
>United States. Lucent Technologies was spun off from AT&T.

Lucent was briefly in the FPGA business, Xilinx clones I think. So did
the Lucent-Alcatel thing result in Xilinx picking up the French group?

John


Article: 150494
Subject: Re: Xilinx news
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 24 Jan 2011 14:17:47 -0800
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>On Jan 24, 12:21 pm, John Larkin
><jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On Mon, 24 Jan 2011 09:09:42 +0100, David Brown
>>
>> <da...@westcontrol.removethisbit.com> wrote:
>>
>> >I find it hard to believe that supposedly educated, intelligent and
>> >experienced engineers can post such ignorant xenophobic drivel.
>>
>> Well, two facts exist:
>>
>> 1. Their software is a nightmare, and it's costing them business
>>
>> 2. They are dumping the French operation.
>>
>> The software is the heart of an FPGA company. The very architecture of
>> the chip has to be coordinated with possible compiler strategies. The
>> idea of outsourcing anything this important to a group 8 or 9 time
>> zones away, working in another language, in a country where it's
>> almost impossible to fire incompetant workers, where people take long
>> lunches with wine and don't work weekends, just amazes me.
>
>This is probably a discussion to stay out of, but I want to correct a
>misapprehension on your part.  I have worked with the French at a
>major telecom company and will tell you that they are no more
>incompetent or drunk than American workers.  The continent does have a
>different work culture in terms of leave.  They get lots more vacation
>than we typically do and they manage to get their work done without
>working late nights and weekends.
>
>Actually I have always thought it very odd that US workers were
>willing to take on the burden of completing projects on time and
>budget when they have little or no say in the process of setting those
>goals.  Lets face it.  Being willing to work unlimited, unpaid
>overtime is something that the majority of workers in the US are
>unwilling to do.  For some reason engineers seem to be in a class all
>by themselves in that regard here in the US.  What other professions
>are willing to do that?
>
>
>> >Xilinx (or rather, their users and customers) have trouble with the
>> >Xilinx software because the Xilinx leadership do not prioritise it
>> >appropriately, and (apparently) do not listen to or understand the
>> >issues customers have with the software.  They alone are at fault.  It
>> >could well be that the main management fault was to hire a development
>> >team that was not competent to do the development - but the problem is
>> >their lack of competence, not their nationality!
>>
>> I'd have been equally surprised had they outsourced anything this
>> core-critical to any other country that far from San Jose. Big
>> Software is nearly impossible to manage even without an ocean in the
>> way.
>
>Distance doesn't create problems in management... management creates
>problems in management.  I've worked on projects where no two people
>were in the same city and they progressed well, except for the
>management which kept feeding lies upstream in order to tell them what
>they wanted to hear.  I guess one difference is that it is a bit
>harder to manage by "walking around", something upper management
>should do.  Then they can find out things that they aren't being
>told.
>
>But none of this has to do with nationality.
>
>Rick


http://www.eetimes.com/electronics-news/4212317/Xilinx--sales-fall-short-of-estimates

"Xilinx recorded $4.3 million worth of restructuring charges during
the recently concluded quarter. Olson said the charges were greater
than expected because the company is closing its software development
operation in France, where regulations make eliminating jobs
difficult."

John


Article: 150495
Subject: Re: Problem with iMpact
From: ghelbig <ghelbig@lycos.com>
Date: Mon, 24 Jan 2011 14:21:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 24, 12:23=A0pm, Gabor <ga...@alacron.com> wrote:
> On Jan 24, 1:50=A0pm, ghelbig <ghel...@lycos.com> wrote:
>
>
>
>
>
> > I think that iMpact is messing with me.
>
> > Here's what I do:
>
> > 1) Create a bit file with ISE 11.5
> > 2) Downloading the bit file to my Virtex-5 via JTAG. =A0(I'm using a
> > DLC9G and WinXP)
> > 3) Run a regression test on the system.
>
> > If the regression test passes I do the following:
>
> > 4) Create a MCS file with iMpact.
> > 5) Load the MCS into the attached SPI chip (again, with the DLC9G)
> > 6) Power cycle the board.
> > 7) Re-run the regression test.
>
> > Here's my issue:
>
> > I have two bit files for this project. =A0One was created last month,
> > one was created last week. =A0The steps above are repeated EXACTLY for
> > the two bit files. =A0There are no warnings or errors generated with
> > steps 2 through 6.
>
> > Step 7 fails for one bit file, and passes for the other. =A0With one bi=
t
> > file, and chip never leaves the DONE state. =A0Keep in mind that both
> > bit files load and run "just fine" when I load them through the JTAG
> > port.
>
> > Has anyone seen this before? =A0I haven't gotten any help from the
> > factory yet.
>
> > Regards,
> > G.
>
> The first thing I look for is whether the .mcs file was really created
> correctly.
> I have been burned by the ISE GUI grabbing an existing impact project
> that
> built a new .mcs file from an old .bit file.
>
> If you look in the directory where the .mcs file was built, there
> should also
> be a .prm file with the same base file name. =A0In this file you can see
> the
> name and modification date of the .bit file(s) that were used in
> creating
> the .mcs file.
>
> Also I have had some issues with indirect SPI programming using
> impact. =A0However usually these show up as an error when you go to
> verify the .mcs file in SPI flash. =A0When you say "never leaves the
> DONE state" do you mean that DONE never goes high? =A0Or does
> DONE go high, but the chip never comes out of reset. =A0The latter
> condition can be bitstream-dependent although I've never seen
> this behavior when using Master-SPI config mode. =A0Just be sure
> that you use the default startup clock (CCLK) when you run
> BitGen.
>
> -- Gabor

It is the "DONE goes high, but the chip never comes out of reset"
case.  It seems to be bit-stream dependent, I can make good MCS files
from old BIT files.

I'm stumped.  The only thing I can see different in the two cases
(works, does not work) from start to finish is the Verilog code.

G.

Article: 150496
Subject: Re: Xilinx news
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Mon, 24 Jan 2011 23:24:18 +0100
Links: << >>  << T >>  << A >>
Le 24/01/2011 20:51, rickman a écrit :

> This is probably a discussion to stay out of, but I want to correct a
> misapprehension on your part.  I have worked with the French at a
> major telecom company and will tell you that they are no more
> incompetent or drunk than American workers.  The continent does have a
> different work culture in terms of leave.  They get lots more vacation
> than we typically do and they manage to get their work done without
> working late nights and weekends.

Thanks Rick. Working late nights happens sometimes, though.
(and now I'll stay out of the discussion but will keep watching with 
great interest since I happen to be French)

Nicolas

Article: 150497
Subject: Re: Xilinx news
From: Charlie E. <edmondson@ieee.org>
Date: Mon, 24 Jan 2011 15:50:55 -0800
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

<snip>
>This is probably a discussion to stay out of, but I want to correct a
>misapprehension on your part.  I have worked with the French at a
>major telecom company and will tell you that they are no more
>incompetent or drunk than American workers.  The continent does have a
>different work culture in terms of leave.  They get lots more vacation
>than we typically do and they manage to get their work done without
>working late nights and weekends.
>
>Actually I have always thought it very odd that US workers were
>willing to take on the burden of completing projects on time and
>budget when they have little or no say in the process of setting those
>goals.  Lets face it.  Being willing to work unlimited, unpaid
>overtime is something that the majority of workers in the US are
>unwilling to do.  For some reason engineers seem to be in a class all
>by themselves in that regard here in the US.  What other professions
>are willing to do that?
>
this is definitely a sore point for me.  We all have our 'Project from
Hell' and mine involved a French company.  The company that hired me
had a contract to develop and install some new technology.  The
customer hired a French company to verify that we met the contract
requirements.  Now, we were doing things that, to this point, no one
had done before, and the best part was that none of us had ever even
worked in this INDUSTRY before.  We didn't know what couldn't be done!

Now, the interesting thing about the French company, was how they kept
'interpretting' the contract requirements, and asking for tests that I
realized had nothing whatsoever to do with the project we were working
on.  They were taking all our results and technologies, including our
software, and just shipping it to the home office to use in their own
projects!

Now, the real reason it was the project from hell, was that the
management was ALL ex-military.  They had very little technical
expertise, and they seemed to feel that success required only two
things - their orders to get something done, and sufficient effort on
our part to follow their orders.  It was common to work seven days a
week, 10 to 12 hours a day, and they were chewing us out daily that we
were behind schedule!  The truth was, all of the workers were so
burned out that we could barely think, much less be creative and solve
problems as they came up.  I remember coming in one morning, and
noticing a co-worker (who was one of their darlings.  It was rumored
that he worked so late that, when he went home, he slept in his car
because he was too tired to climb the stairs.  He got up at 6, went up
and showered and changed, and then went in to work!) Anyway, I noticed
that he was typing up a test procedure - click... click... click...
click at about one letter a second.  He was dead on his feet, and it
was only 7:30 in the morning!

They laid me off just before the end of the project - I wasn't putting
in enough effort!  I was only working 65- 70 hours a week!
 

Charlie

Article: 150498
Subject: Re: Xilinx news
From: Charlie E. <edmondson@ieee.org>
Date: Mon, 24 Jan 2011 16:06:46 -0800
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:


>Distance doesn't create problems in management... management creates
>problems in management.  I've worked on projects where no two people
>were in the same city and they progressed well, except for the
>management which kept feeding lies upstream in order to tell them what
>they wanted to hear.  I guess one difference is that it is a bit
>harder to manage by "walking around", something upper management
>should do.  Then they can find out things that they aren't being
>told.
>

Actually, distance DOES create problems in management, and modern
management techniques are not very effective.  The ability to manage a
distributed workforce is a very rare talent.  Among the requirements,
is enough technical skill to be able to divide the task into
appropriate pieces, and have the ability to make sure that all the
system requirements are complete, and that they are being met by each
member of the team.

It also requires the right sort of project, where inter-member
interaction is only needed for specific tasks, and not for just
general co-ordination...

Charlie

Article: 150499
Subject: Re: Xilinx news
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Mon, 24 Jan 2011 18:29:22 -0600
Links: << >>  << T >>  << A >>
On Mon, 24 Jan 2011 16:06:46 -0800, Charlie E. <edmondson@ieee.org> wrote:

>On Mon, 24 Jan 2011 11:51:12 -0800 (PST), rickman <gnuarm@gmail.com>
>wrote:
>
>
>>Distance doesn't create problems in management... management creates
>>problems in management.  I've worked on projects where no two people
>>were in the same city and they progressed well, except for the
>>management which kept feeding lies upstream in order to tell them what
>>they wanted to hear.  I guess one difference is that it is a bit
>>harder to manage by "walking around", something upper management
>>should do.  Then they can find out things that they aren't being
>>told.
>>
>
>Actually, distance DOES create problems in management, and modern
>management techniques are not very effective.  The ability to manage a
>distributed workforce is a very rare talent.  Among the requirements,
>is enough technical skill to be able to divide the task into
>appropriate pieces, and have the ability to make sure that all the
>system requirements are complete, and that they are being met by each
>member of the team.

It creates problems but it certainly can be done.  I worked on the processor
Apple used in its G5 PowerMacs.  About a quarter of the processor was done in
Germany, a little in Texas, and we did the rest along with all the chip
integration.  It worked out very well but as you say, the system requirements
were very well laid out and the project was divided by functional unit.

>It also requires the right sort of project, where inter-member
>interaction is only needed for specific tasks, and not for just
>general co-ordination...

That certainly helps.  Basically it's broken down into smaller projects, each
more or less independent.

BTW, we tried to bring on some people in India.  A lot of effort was spent
coordinating the project and no results were ever seen from them.  It takes
the right people, too.



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