Path: csiph.com!usenet.pasdenom.info!gegeweb.org!newsfeed0.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Joerg Newsgroups: sci.electronics.design,comp.lang.forth Subject: Re: ball-hours Date: Thu, 16 Oct 2014 13:37:37 -0700 Lines: 123 Message-ID: References: <5sho3adpfhed897nb8jdju99897ouhrvrv@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 91Ith3FhIjyYeFWwv+qgowid/MqKNul+zRSBvgk7JTHlQYdeYv Cancel-Lock: sha1:FpmFAvFmNXaDWnSbMiy7/uoo1nI= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.6.666 In-Reply-To: Xref: csiph.com comp.lang.forth:33955 rickman wrote: > On 10/16/2014 2:21 PM, Joerg wrote: >> rickman wrote: >>> On 10/15/2014 7:12 PM, Joerg wrote: >>>> rickman wrote: >>>>> On 10/15/2014 8:36 AM, Joerg wrote: >>>>>> Problem is, there is no Forth community out here. The last die-hard >>>>>> Forth aficionado I personally met was about 30 years ago in Europe. >>>>> >>>>> I think you may be surprised. I've already heard from three >>>>> programmers >>>>> from the few posts I've made in just three groups. Unless you want me >>>>> to send then directly to you, I am referring them to this thread. >>>>> >>>> >>>> One of them contacted me already. They are sort of local but not really >>>> local-local, like in the same village, down the road from here. We will >>>> have lots of situations such as "Hey, I got stuck with the test rig, >>>> can >>>> you come over real quick?" or "The relief valve over yonder blew a >>>> gasket, can you replace it?". >>> >>> So why aren't you working in the same lab? Then it can be like, >>> "Watson, come here. I want you". >>> >> >> Because as mentioned before if both are consultants it creates >> confidentiality issues. I have only one room (office plus lab) and >> another one mostly used for library and parts storage but not >> acoustically shielded. I often have to hop on GoTo or some other service >> to discuss another client's issue and then I must be alone. Sometimes >> for 1-2h. In contrast to contractors who work one longer assignment at a >> time I always have half a dozen or more active clients. >> >> >>> BTW, if you heard from Charley Shattuck, he is a prominent Forth >>> programmer. He is working with a startup that developed a Forth like >>> CPU with 144 processors with a peak rate of 700 MIPS each. This chip >>> includes 5 ADC and 5 DAC on chip with variable resolution (trade off >>> between speed and resolution, about 15 bits at 48 ksps). You might talk >>> to him about the GA144, it might suit your needs. It's main limitation >>> is each processor has little memory and the I/O is limited. But I don't >>> think you will run out of MIPS. lol >>> >> >> Yes, had an email exchange with Charley. >> >> 144 processors with 700MIPS each would probably require us to also build >> a nuclear power station :-) ... just kidding, I know it's green. > > Each processor is very low power when running flat out, just 5 mW. But > they almost never run flat out. Because they are asynchronous they > spend most of their time stopped when they draw 0.0875 uW, yes, that's > less than a tenth of a uW for each processor or just 12 uW for the whole > chip. The processors respond to stimuli in just nanoseconds, not 100's > or even 10' but single digit nanoseconds. > > Trust me, power will not be a problem with this part. It is a very > different beast to program however. > I wonder how that company is doing. I read about their products years ago but never seen any in schematics and I get to see a lot of new stuff because some of my daily bread is EMC remedy. > >>>>> ... Your other post seemed to be >>>>> talking about bitbanging the I2S port to the CODEC. How does that >>>>> work >>>>> into the 100 MHz need? Bitbanging a serial port of any kind can be >>>>> CPU >>>>> cycle intensive. >>>>> >>>> >>>> Yes, it is a major concern. We might need to hang an FPGA in there at >>>> least for TX, as a buffer, because essentially we are writing sine >>>> waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S >>>> works for us, somehow. Got to find out. >>> >>> ??? >>> >> >> Well, to send out sine waves. No need to necessarily bother a processor >> with that. Or I use a DDS but that can cost in clock synchronicity. > > Every problem in your design is asking for an FPGA. > Possible, but not sure yet. Maybe there is a bigger processor out there with real I2S/TDM and enough support by the manufacturer. > >>> What are the specs you need from the ADC? Do you have numbers and such? >>> I think you mentioned a low drift with temperature. The GA144 would >>> need to be compensated for temperature, but has lots of processing to do >>> that. :) >>> >> >> Five needed in total, 18bits or more, 48ksps, differential inputs, BW >> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled >> via mux and SW-clamping as long as it won't jitter or drift around much. > > "phase jitter issues" and "won't jitter or drift around much" aren't > specs. What I mean is that ADCs on processors generally cannot hold jitter low enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is already a serious challenge. 18 bits of what exactly? I have seen lots of devices with 24 > bits but only 96 dB SNR. Do you need 108 dB SNR? You won't get that > from the GA144 ADCs at 48 kHz. > True 96dB across DC-15kHz would be enough. -- Regards, Joerg http://www.analogconsultants.com/