From: Joerg on 31 Dec 2009 14:18 John Larkin 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. > > 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. > Had this one happen at a company, a mid-size one and otherwise rather efficient: "But we don't have a scope that would do that, do you know a place where we can rent one for a couple days?" ... "I do but I think Mr.So-and-so at your company has one." ... "Can I put you on hold for a minute?" ... "Sure." ... <soothing music> ... "Dang, indeed, he does!" -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: krw on 31 Dec 2009 14:20 On Thu, 31 Dec 2009 10:55:25 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >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. An FPGA isn't a very good DSP, either. Like everything in life, the appropriate tool depends on the task.
From: krw on 31 Dec 2009 14:23 On Thu, 31 Dec 2009 11:02:11 -0800, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"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. :-) The real problem was the DMA that couldn't. It's still a nightmare, though after a dozen levels of work arounds it sorta works. At least we can catch it and reset, when it doesn't.
From: Joel Koltner on 31 Dec 2009 14:36 "krw" <krw(a)att.bizzzzzzzzzzz> wrote in message news:2eupj5hvs6f57rvju6495mi4fo0ri53gh9(a)4ax.com... > The real problem was the DMA that couldn't. It's still a nightmare, > though after a dozen levels of work arounds it sorta works. At least > we can catch it and reset, when it doesn't. Wow. I would have definitely jumped to at least a different flavor of the same DSP (with working DMA) in such a case! But I realize that with your hardware and firmware guys separated that's probably not so trivial to do... Having used TI DSPs myself and heard the experiences of others, I'm starting to think that Analog Devices deserves another look... (even though it's pretty unlikely we'll stray from TI in the immediate future...)
From: krw on 31 Dec 2009 14:41
On Thu, 31 Dec 2009 11:36:30 -0800, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"krw" <krw(a)att.bizzzzzzzzzzz> wrote in message >news:2eupj5hvs6f57rvju6495mi4fo0ri53gh9(a)4ax.com... >> The real problem was the DMA that couldn't. It's still a nightmare, >> though after a dozen levels of work arounds it sorta works. At least >> we can catch it and reset, when it doesn't. > >Wow. I would have definitely jumped to at least a different flavor of the >same DSP (with working DMA) in such a case! There are none. The chips, of the same vintage design, are identical. The newer ones *should* have it fixed, but no guarantees. >But I realize that with your hardware and firmware guys separated that's >probably not so trivial to do... It's not trivial to get management to open a nest of working snakes, either. >Having used TI DSPs myself and heard the experiences of others, I'm starting >to think that Analog Devices deserves another look... (even though it's pretty >unlikely we'll stray from TI in the immediate future...) Good idea. AIUI we looked hard at ADI before settling on TI. The tipping point was G729 support. That part has never caused any grief. The hardware sucks, though. Oh, and I forgot to mention TI's documentation. Ack! |