From: Joerg on
Joel Koltner wrote:
> "Joerg" <invalid(a)invalid.invalid> wrote in message
> news:7q2feiF5btU1(a)mid.individual.net...
>> That doesn't sound like a 100% kosher environment to me if it was a
>> serious big system defense project.
>
> Just as a point of reference, we're doing COTS contracts for the
> military indirectly as a sub-contractor, and there's no separation of
> software and hardware people. The pieces we work on aren't classified,
> although for the overall projects some other pieces are.
>

It all depends on the sensitivity and often the size of the project. In
my case I really didn't need to know anything about the antenna or the
transmit section. Also, this was a very long time ago, before the iron
curtain fell.


> We do have a perhaps-slightly-overzealous IT guy who would *love* to
> start spending months implementing very fine-grained controls on who can
> and can't see every file on the server, log in to any given machine,
> etc. if he was just given the go-ahead by management, though. :-)
>

Some of it could make sense. Of course, like everything, this can also
be over-engineered.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
From: krw on
On Thu, 31 Dec 2009 08:59:30 -0800, Joerg <invalid(a)invalid.invalid>
wrote:

>krw wrote:
>> On Wed, 30 Dec 2009 18:09:15 -0800, Joerg <invalid(a)invalid.invalid>
>> wrote:
>>
>>> krw wrote:
>
>[...]
>
>>>> The AB situation was similar but there was no defense work going on
>>>> there. Just a screwy (product) management structure.
>>>>
>>> There I agree with you, that just doesn't make sense.
>>
>> They didn't like my questioning their structure, either. I really
>> wanted to know how the position fit into the structure and what the
>> limits were. I couldn't believe two companies were that screwy. ;-)
>>
>> Where I am now, I'm not "allowed" to do the (embedded) firmware but am
>> expected to do all of the FPGA stuff and most of the analogs. Go
>> figure.
>>
>
>Time to have a friendly chat with the CEO? Maybe a quick lunch together?
>Seriously, they are usually quite glad if an amployee sees a situation
>that is harmful to the company and has a suggestion how to fix it. Heck,
>might mean a free lunch for you :-)

To be honest, I don't like doing code, particularly C. I *hate* C. If
they'd let me use assembler I'd knock of one of their "to do list"
product in my spare time, myself.

>>>>>>> But in a non-defense setting that would make no sense at all.
>>>>>> Even in a defense setting, firmware and hardware sorta go together. I
>>>>>> did both but only because the hardware developer mucked it up so bad
>>>>>> (I found out when I was going through the design trying to figure out
>>>>>> what I had to control). OTOH, the (embedded) firmware people didn't
>>>>>> know too much about FPGA stuff, yet may manager was the OS guy.
>>>>> I had a situation where I got tired and wanted a candy bar. But not this
>>>>> sugary stuff from our machine. So the only way to get a trail mix type
>>>>> of candy bar was to send coins through the internal mail thingie and
>>>>> someone from the other group sent back a candy bar.
>>>> Did they get a cut? ;-)
>>>
>>> No, that could have been construed as bribery since I was not an
>>> employee :-)
>>
>> At LM one of the labs had an under-the-table "canteen service" going
>> in competition with the vending machines. Once every few months they
>> bought pizzas out of the proceeds. I didn't participate much because
>> I didn't have access to the lab. I ate the pizza, though. ;-)
>
>
>We had a doughnut & bagel kitty. The good thing was you contributed only
>when you ate one, so I didn't have to eat the doughnuts which are mostly
>too sugary for my taste.

This under the table thing was in competition with the vending company
(machines right outside the lab). I doubt they'd like the competition
if they knew. There was also a coffee kitty that was in competition
with the cafeteria, but they weren't open all the time. The coffee
kitty wasn't clandestine.
From: krw on
On Thu, 31 Dec 2009 09:42:53 -0800, John Larkin
<jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:

>On Wed, 30 Dec 2009 20:23:23 -0600, krw <krw(a)att.bizzzzzzzzzzz> wrote:
>>
>>Where I am now, I'm not "allowed" to do the (embedded) firmware but am
>>expected to do all of the FPGA stuff and most of the analogs. Go
>>figure.
>
>One nice thing about small companies is that everybody gets to do
>everything. I think that works better. Our newish software engineer
>wanted to design and lay out a display board that he was assigned to
>program, so we let him.

It is a small company (under 100). Firmware and hardware are
separated with a pretty broad line, though.

>We're furnishing a subassembly for one project that's over a year
>late. It's pretty obvious that the not-so-big company is
>compartmentalized unto paralysis.

We were three years late (I got there at the end) on what is now our
main product. TI shares the blame, though. Their DSPs suck and their
support worse. OTOH, one FPGA would have saved at least two years of
grief. ;-)
From: John Larkin on
On Thu, 31 Dec 2009 12:47:13 -0600, krw <krw(a)att.bizzzzzzzzzzz> wrote:

>On Thu, 31 Dec 2009 09:42:53 -0800, John Larkin
><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Wed, 30 Dec 2009 20:23:23 -0600, krw <krw(a)att.bizzzzzzzzzzz> wrote:
>>>
>>>Where I am now, I'm not "allowed" to do the (embedded) firmware but am
>>>expected to do all of the FPGA stuff and most of the analogs. Go
>>>figure.
>>
>>One nice thing about small companies is that everybody gets to do
>>everything. I think that works better. Our newish software engineer
>>wanted to design and lay out a display board that he was assigned to
>>program, so we let him.
>
>It is a small company (under 100). Firmware and hardware are
>separated with a pretty broad line, though.
>
>>We're furnishing a subassembly for one project that's over a year
>>late. It's pretty obvious that the not-so-big company is
>>compartmentalized unto paralysis.
>
>We were three years late (I got there at the end) on what is now our
>main product. TI shares the blame, though. Their DSPs suck and their
>support worse. OTOH, one FPGA would have saved at least two years of
>grief. ;-)

We've considered DSPs, but always wind up doing our serious crunching
in an FPGA. A DSP isn't a very good uP and it isn't a very good FPGA.

John

From: Joel Koltner on
"John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message
news:lnspj5tk7tc2batjfoje5vstjgk034nk0c(a)4ax.com...
> We've considered DSPs, but always wind up doing our serious crunching
> in an FPGA. A DSP isn't a very good uP and it isn't a very good FPGA.

They fill the niche quite nicely for audio or low IF processing though. Hence
the reason they're in every cell phone and most modern commercial radios out
there...

Often you don't really need a very good general-purpose uP if you're
programming in a high-level language anyway. I've often felt the main reason
many designs (like cell phones) had a DSP and a separate CPU (long before you
had web browsers and other things that easily chew up hundreds of MHz of a
general purpose CPU) was that the DSP guys didn't really trsut the CPU guys
not to stomp on their time-critical interrupts and careful static memory
allocations (when you have slightly weird DSPs like the TI ones Keith mentions
that have various sections of memory, some single-ported, some dual-ported,
etc.) and whatnot. :-)

---Joel