Slashdot Mirror

"since it can't predict the future"

Actually, it can predict the future! The sensing microphones are closer to the noise source than the cancelation speaker, so they receive the noise before the speaker has to generate it. At 340 m/s, 1 foot is about 0.1 milliseconds "into the future"; most speakers have a decent frequency response in the range of 1 kHz (1/0.1 msec) and could easily respond in time.

Like the poster above said, it looks like it uses 8 noise-sensing microphones, 8 speakers, and then 8 microphones in the quiet zone to measure the sucess of the speakers and automatically make adjustments.

In a 3d world, these sense microphones are essential because they are used to compensate when the environment changes. Stand up, and it needs to compensate. Move a chair, it does, too.

It looks like the system would try to minimize the noise at these 8 places, and not worry about everything else. I'm guessing that these 8 microphones would have to be in relatively open air (kindof like your head is when you walk around - not in corners), and not near any local noise sources (such as the fan on yuor computer). Or, they may be built into the device, on a framework attached to the speakers and the front microphones.

The TI 320c32 is a decent floating point processor - 20-30 MIPS / 40-60 GFLOPS. But, (IHALEWD - I have a little experience with dsps), I don't think it's enough horsepower to entirely model a room and do super-sophisticated stuff, but it looks like it would generally get good results.

Automatically adjusting filters are neat - they can be tuned relatively easily, and since a large number of coefficients, they can describe some pretty complicated behaviour without a lot of programming. Of course, AFAIK, they assume linearity; if the air conditioner vibrations rattle a coffee cup on your desk, that's non-linear and probably won't get fixed.

And, of course, this system may require some sort of calibration -- like a firecracker that you light near the noise source. (ok, maybe just something that makes test tones or a sharp snap). The microphones can get a picture of the room by listening to all the reflections (and by knowing what the initial sound was).

I Wonder when they will start making some games for Texas Instrument's line of calculators. If the TI-92 can do multivariable calculus, it should be able to play some really decent games. Doom anyone?

I Wonder when they will start making some games for Texas Instrument's line of calculators. If the TI-92 can do multivariable calculus, it should be able to play some really decent games. Doom anyone?

The rage is back... TI-92+ from Texas Instruments. Although the TI-92 has been around for a couple years now, and the TI-92+ was an updated version release sometime thereafter. They are still end-of-1990s, early 2000s time products.

I use my thumbs for everything on there unless I am taking a test and I have the calculator set down on a surface, then I'll use my fingers for typing things in. And then there's the keyboard. It is rather small and cramped, but you are still able to type moderately well on it without a whole lot of practice. The thumb is the one-and-only space bar machine for typing here still.

The audio fidelity on the whole is as good as can be expected. We all know what MP3 encoding does to your tunes if you have a reasonable speakers

All mp3 decoders are not created equal and I sure wish reviewers would dig a little deeper. If they go beyond navigation and I/O features and cover audio quality, it's typically only to mention background hum or hiss or a wimpy headphone amplifier.

mp3 at high bitrates created with a competent encoder (LAME is one) can sound pretty good. Decoding with cheap 16 bit DSPs such as the TMS320C54x used in the Rio One is hard to do-- you have to watch out for error accumulation (e.g. please round to zero instead of simply truncating).

If you don't believe me that decoders differ, consider these tests of PC decoders. Unfortunately, no one seems to do such detailed testing on embedded decoders.

I'm giving my Rio One to my nephew who will be so thrilled to have it that if he hears the high-frequency errors on playback of middlin' bitrates (192kbps), he probably won't mind.

I don't know what I'm going to replace it with, though. I know I shouldn't expect much out of a $80 player powered from on AA cell, but there's no guarantee that a $400 Rio Riot or iPod will be glitch-free: they might have spent the whole power and cost budget on LCDs, hard drives and amortizing development.

A StrongARM-based PocketPC might be the answer- plenty of horsepower to run less compromised 16 bit decoder or even a 24 bit or floating point one. It should also be able to decode ogg vorbis....

By the way, instead of reasonable speakers, I'm using a good pair of headphones. Much more bang for the buck when it comes to revealing audio defects, though the Sonys tend to be a bit shrill (well the older V6s that I have) for long-term listening. These are the same model we used when I was at E-mu for all normal testing. The only thing more revealing was the elements from a good pair of Sennheisers in a set of noise protection muffs to cut background noise by 23dB. Also, some of the ATC guys have Grado electrostatics.

In this case, it was being used as the starting term in a polynomial evaluation for Chien Search. I just looked at the code, and the constant is not quite 1, but rather 0x01010101 (because the code is SIMD-optimized, and is doing the same computation in parallel on four different bytes in one word).

In this context, I would've named the constant something like "ones", or "one", or maybe even k01010101, rather than a five-syllable name. (Rarely do you need the word 'constant' in a variable name, and 'one' and 'unity' are usually synonyms.) In fact, many of the variables in that file could've been given more terse, yet more descriptive names. I'm firmly convinced it's an art.

Of course, I suppose you could go the other way and have all 2 thru 4 letter variable names, as I did in the IDCT (same page as above). Of course, in that case, I was mostly using the names that Chen used in his paper on the IDCT. (I implemented Chen's decomposition of the 8-pt IDCT.) For other things, though, I have no qualms calling a rounding term rnd or an input pointer i_ptr. Calling it inputPointer is a waste of my 80 columns.

After half a decade of IT work, somebody out there would have half a clue as to what they're doing.

You would think somebody out there would say, "Hey! I wonder what would happen if we, like, promoted someone who knew what they were doing, or something?"

Wouldn't that be more intelligent, from a company's standpoint? Promote them, before they get so fed up and leave to start their own company--and become your competitor.

Hell, it's been working for TI for about a hundred years (hmm, TI = IT backwards...).

miyax :)

Where does linux fit in to all this?

Let the karma whoring commence! :-)

They already have Linux running on these, on both the ARM and the C55x DSP cores that comprise the OMAP chip. They even share the same process space, so you can initiate/control/kill processes on the DSP from the ARM. This is being done by a third party company called RidgeRun Unfortunately, the OMAP version is not quite out yet it seems, but they have versions out for ARM + C54x DSP.

Read this PDF for more technical info.

Compilers are gcc in the case of the ARM, and the TI proprietary compiler for the DSP (ported to Linux). Debugger in both cases is GDB.

Mechanik

Disclaimer: I am a TI employee.

Other OMAP-related products:

MICROSOFT AND TEXAS INSTRUMENTS INTRODUCE WINDOWS-POWERED SMARTPHONE 2002 AND OMAP(TM) REFERENCE DESIGN

New 2.5G Reference Design Combines Strengths of Smartphone 2002 Software and TI's OMAP Processors to Enable Rich Voice and Data-Capable Phones in Small, Sleek Form Factor

You can read the full article at http://focus.ti.com/docs/pr/pressrelease.jhtml?pre lId=sc02025.

I also suspect that many other products will begin to appear similar to this new Jornada and SmartPhone. You can probably sign-up to be notified on ti.com (Texas Instruments' website).

EricKrout.com :: A Weblog On Crack (updated daily)

I'll save you the trouble and place a direct link to the OMAP page at TI.

I don't buy it. You should be able to do a pretty decent job, even on the fly. Otherwise Transmeta wouldn't have even half a chance. As it is, they're doing pretty good -- maybe not bleeding edge performance, but very acceptible for running essentially "JIT x86". Transmeta and Itanium both are VLIW machines, and so it's reasonable to expect the hurdles involved aren't gigantically different.

Granted, to get ultimate performance out of Itanium, you need to jump through some fiery hoops. (I program a VLIW machine at my day job, so I'm familiar with VLIW's quirks.) But to get "pretty good" performance, it's not too bad. And that's what JIT needs. There's lots of low-hanging fruit.

Another thing you fail to take into account is that dynamic compilers have many opportunities to improve on the generated code that static compilers lack. (That was the primary insight of the Dynamo project I linked before.) For Itanium, this is especially true -- a dynamic compiler could get feedback information on which loads miss the cache, which branches are mispredicted, etc. and twiddle the code appropriately. A static compiler would just have to guess, or accept profile information from previous runs.

1958 - TheThe integrated circuit

I bet even your toaster has an IC in it :) (and don't say "how useless is that?", because my toaster makes some pretty good toast exactly how I like it every time). Most of your modern conveniences owe their existence to this fantastic idea. One thing you're failing to mention are advances on those pre-1946 concepts (IC is an extrapolation on the transistor).

1983 - PCR

It's rather difficult to study genetics without large quantities of DNA. Along with this tech there is gel electrophoresis that you use to analyze your strands.

1984 - RouterNeed I say more? Would we be on the 'Net right now without it?

There is just too much to list, but these were some of my favorites. You get the picture. There are some others, like the Operating System, where would you be without that? Or the C Programming Language as another, or high level languages in general.

I think an important point here is that the presentation talked about advances in areas where there's not much room for advancement. Trying to make any major improvements in "word processor technology" is pretty futile.

Mike

TI's OMAP chip does this today. Yawwwn.

Info here...

It will be interesting to see how OFDM does in the 2.4GHz band (and don't forget that CCK isn't the only coding specified by 802.11b, PBCC is also specified as an option at 5.5 and 11Mbps, and although this is not widely available yet, it gives better range than CCK).

Last time i checked the C67 series power consumption was not exactly in the portable player category - 420 mA typical supply current for a C6711. The fixed-point equivalent (same instruction set - but no float support) C6211 only uses 270 mA typical - Floating point costs current. The same ratio is true for almost any DSP family. This is why portable device manufacturers still use fixed-point DSPs to a great extend - people tend to like longer battery lifetime (why do you think that TIs low power flagship C55x is only available in a fixed-point version ?). Price is not the only parameter here.

Last time i checked the C67 series power consumption was not exactly in the portable player category - 420 mA typical supply current for a C6711. The fixed-point equivalent (same instruction set - but no float support) C6211 only uses 270 mA typical - Floating point costs current. The same ratio is true for almost any DSP family. This is why portable device manufacturers still use fixed-point DSPs to a great extend - people tend to like longer battery lifetime (why do you think that TIs low power flagship C55x is only available in a fixed-point version ?). Price is not the only parameter here.

*cough* Those are TI DSPs in those Nokia phones.

Download the TI 92 SDK here.

This is all documented in the book "the Chip" by T. R. Reid, which I literally have on my desk as I write this. It is briefly summarized here:

In those days, electrical engineers were aware on the potential of digital electronics, however, they faced a big limitation known as the "Tyranny of Numbers." This was the metaphor that described the exponentially increasing number of components required to design improved circuits, against the physical limitations derived from the number of components that could be assembled together. Both, Kilby at Texas Instruments, and Noyce at Fairchild Semiconductor, were working on a solution to this problem during 1958 and 1959.

[First Integrated Circuit] The solution was found in the monolithic (meaning formed from a single crystal) integrated circuit. Instead of designing smaller components, they found the way to fabricate entire networks of discrete components in a single sequence by laying them into a single crystal (chip) of semiconductor material. Kilby used germanium and Noyce used silicon.

The problem was that transistors still had to be interconnected to form electronic circuits, and hand-soldering thousands of components to thousands of bits of wire was expensive and time-consuming. It was also unreliable; every soldered joint was a potential source of trouble. The challenge was to find cost-effective, reliable ways of producing these components and interconnecting them.

The Tyranny of Numbers was quite real, and occupied minds for most of the 50s. The solution of this basic and fundamental problem made possible the computer age. They are probably as important as the binary logic that runs on them.

You can also read more about this on the Texas Instrument Website.

So I went though all the domains, and noticed that only z.com seems to be a functioning website (redirects to Nissan's website.)

Since you also mentioned two-letter domain names in your post as being verboten, what about Hewlett-Packard or Texas Instruments? (You need the "www." in front of them, though, to access their websites. General Motors, OTOH, works without the "www.")

The last time ternary logic came up, I was disappointed to see no proposed schematics. Now there are schematics, but I'm still disappointed. One thing is that they designed with bipolar transistors rather than CMOS -- you cannot put more than a few thousand bipolar transistors on one chip without serious heatsinking... Beyond that, these designs lack quite a lot in speed, power consumption, and reliability as compared to even the 7400-series of TTL bipolar logic chips of the late 60's. And the first one I looked at doesn't even work.

Their ternary inverter is simply a two-transistor inverting _analog_ amplifier running on +/-3V supplies. If the input is -, Q2 turns on, bringing the base of Q1 low, turning Q1 off, so R2 pulls the output (which isn't explicitly shown) to the + rail. If the input is +, Q2 is off, and apparently this circuit depends on leakage to then bias Q1 on. This brings the output almost to the - rail. So it would work as a binary inverter. It's not nearly as good as a
TI 7404 (see page 2). The major difference is that R2 was replaced by a transistor, which turns on for high. This speeds up the low-to-high transition, since you get the full output current of the transistor until the output node is charged up. It also saves power, because one
output transistor is always off and the other always on, so when not switching only leakage currents flow at the output. (This two transistor output is called a "totem pole", and CMOS similarly depends on transistor pairs, one always off so little current flows.) Two more intermediate transistors are added, to control the top transistor on the totem pole and to reduce the resistor count. (On-chip, resistors are not cheaper than transistors.) But if you used it as a binary circuit, trinary.cc's inverter is basically the stripped-down ancestor of the 7404 circuit.
As a trinary circuit, it also has to take a 0V input and output 0V. This inverter does not do this reliably. It probably could be made to work by adjusting the resistor values until 0.0V in gave 0.0V out, but warm or cool the transistors a few degrees, and the amplifier bias will shift so that the output swings to the + or - rail. When you are trying to put the mid-level through it, you are running it like an analog amplifier, and analog amplifiers are unstable without negative feedback.

Nor would adding a few transistors and a negative feedback loop to stabilize it make it work well enough. A trinary inverter should take an input that is not right at any logic level, decide which level is closest, and output the corresponding nomimal voltage. For highs and lows (2 and 0), it does that, since it pins the output to the opposite rail. But even if you can be sure that 0.0V in = 0.0V out, with a circuit that is basically an analog amp, -0.1V in will give more than +0.1V out. So a chain of gates would allow the logic levels to get worse at each gate, until the mid-level became misinterpreted as + or -. To restore the mid-level would take a much more complicated circuit. I lay no claims to being a good designer at the transistor level, but I can't see any possibilities that are not nearly twice as complex as the corresponding binary circuits.

Not as stupid as it sounds...

The Avigo PDA by Texas Instruments had something like this - You had big on-screen buttons like "ABC", "DEF", etc. and you just tapped the set that had the letter you wanted. I.E. If you wanted to type "Hey" you'd tap GHI, DEF, WXYZ. And the Avigo would try to figure it out based on a list of words it knows matching that pattern, its context, etc.

It sounds silly, but it really does work, despite the "guessing" that's involved. I used my Avigo for well over two years, and 90% of the time it got the words right. And if not, I could teach it new words. I liked it a LOT better than Graffiti on the Palm that ended up replacing my beloved Avigo. Graffiti is okay, but honestly, there really are better solutions, and the Avigo's was one of them. If this "air keyboard" works as well and on similar principles, then I think it will be a decent alternative to Graffiti just because of that.

That's the one thing I miss about that little machine, it's a shame it didn't creep over into the PalmOS arena. Here is a screen shot of the on-screen keyboard for the Avigo, and a brief description of it.

Disclaimer: I work for Texas Instruments.

I don't know how familiar you are with Code Composer Studio, but it sounds pretty much like what you're looking for. It is TI's debugger for their Digital Signal Processors. You can either run your DSP software on real DSP silicon, or you can run it on a simulator that runs on the host computer. If you needed to capture data or pipe it to another program, you could then stream out blocks of memory to a file. Of course, this all requires you to be able to write DSP code :-)

There is also a free 30 day evaluation copy that you can order. Simulator only, but otherwise fully functional. If you can do all of your work in 30 days, this might be all you need :-)

There is special pricing for universities. They get the software are very reduced rates.

The software listed on the website is for the PC, and runs on Windows. It is not really advertised to the mass market, but there is a version for Solaris as well. If you wanted to get a hold of that, you might be able to, but you'd have to do a lot of pestering. That product is Code Composer Studio for Solaris 1.1

It is not out of the realm of possibility for Linux or HP-UX versions of the software to be released as well, if it is perceived that there is enough interest. If you want it, start pestering people :-)

Mechanik

Disclaimer: I work for Texas Instruments.

I don't know how familiar you are with Code Composer Studio, but it sounds pretty much like what you're looking for. It is TI's debugger for their Digital Signal Processors. You can either run your DSP software on real DSP silicon, or you can run it on a simulator that runs on the host computer. If you needed to capture data or pipe it to another program, you could then stream out blocks of memory to a file. Of course, this all requires you to be able to write DSP code :-)

There is also a free 30 day evaluation copy that you can order. Simulator only, but otherwise fully functional. If you can do all of your work in 30 days, this might be all you need :-)

There is special pricing for universities. They get the software are very reduced rates.

The software listed on the website is for the PC, and runs on Windows. It is not really advertised to the mass market, but there is a version for Solaris as well. If you wanted to get a hold of that, you might be able to, but you'd have to do a lot of pestering. That product is Code Composer Studio for Solaris 1.1

It is not out of the realm of possibility for Linux or HP-UX versions of the software to be released as well, if it is perceived that there is enough interest. If you want it, start pestering people :-)

Mechanik

I think one could easily build an MPEG-4 encoding cluster. Since the system is in an aircraft aluminum box anyways, it's not like you would be making it much less portable, especially considering the size and complexity of the camera in the first place.

Just use some PC/104 or similar embedded technologies to build a cluster that does realtime MPEG-4 encoding. Or even better, use some of TI's new high-speed Digital Signal Processors (I have one sitting on my desk that runs approx. 2.4 GIPS and cost here is a company that has already done an embedded MPEG4 encoder for videophone apps...

You mean like Texas Instrument's TMS320C80 DSP?

optimized for a general-purpose instruction set and geared towards SISD integer instructions, with each processor running its own instruction stream with its own control flow.

So it seems like it can do everything a DSP can vis a vis hardware-level parallelism, plus some things that are hard for SIMD-style DSPs. Which is faster, 25 SISD processors sharing an address space, or one SIMD processor which can operate on 25-ary vectors? Multiple SISD cores seem to win, I think, though they may be harder to program for.

Ask a DSP processor to play chess, and it'll crawl.

The main bottleneck in chess program is a game tree search. Tree searches are inherently parallelizable, and there are, in fact, very good algorithms for doing them on SIMD processors.

Normally, devices read data on a bus by sampling and holding. But with asynchronous clocks, there is no way to make sure that all the bits on the bus switch at the same time to assure that all devices meet their specified setup and hold times. This can lead to a state whether a bit is neither 1 or 0 but metastable for a short time, after which random noise from outside the flip-flop flips the bit to a 1 or 0. You also get "glitches," or the result of doing logic on the result of a "hazard" or race condition. Designers of asynchronous have to work very carefully to eliminate metastability and glitches.

Try one of these to change 12V into 5v instead of the free-built-in-coffee-warmer 7805. They generally do not need a heat sink. It'll set you back $20, though. They also have higher current units, but they aren't drop-ins (space permitting) for the 7805. You can buy them at Digi-Key.

With ADSL you have a box installed somewhere that has a connections for your DSL equipment and a second connection for your other telephony stuff. This box isolates the telephony stuff from the actual phone line...

This is the so-called splitter.

...so that they don't change the characteristics of the cable between your house and the exchnage, and thus the line characteristics need only be check when your equipment is installed.

Untrue. Line characteristics are also affected by weather, temperature, and potentially by changes in service to other people in your area.

G-Lite works by have a DSP in the ADSL gear continuously measure the line characteristics and take action accordingly, this removes the need for a wall box (reducing installation time and cost) at the expense of needing a bit more computing power in the ADSL modem.

Untrue, at least to the extent that this processing burden is unique to G.lite. "Regular" ADSL also has a DSP that performs the same function. (Hey, I work for a DSP company that sells a ADSL chipset that's used in both....) Now, it's come to my attention that the term "G.lite" is no longer widely used. It's officially known as ITU G.992.2, and most places don't bother to tell you what particular flavor ADSL you're running -- they'll just tell you a bandwidth number. Wheee.... The main point is that it's splitterless at the consumer's end of the line.

The main reason I say G.lite has lower computational requirements (at least, in steady state), is that the data rate is lower. Since at least some portion of the processing cost is proportional to the data rate, this makes sense. Much of the front end work that processes the analog data of the wire stays pretty much the same, though, as I understand it. Those pieces work at symbol rate, which I believe is fixed. The way bandwidth is varied is by varying the number of bits per symbol.

Now as for changing line characteristics: The line characteristics of a full-rate ADSL line and of a G.lite line both drift over time. A DSL modem needs to track these changes and incrementally update its mathematical model of the line. If too large of a change occurs, the DSL modem needs to re-train (just like a voiceband modem does) to get back on track. This is true for both ADSL and G.lite. A G.lite modem is simply much more likely to need to retrain due to wild changes in loading. Because retraining is an "exceptional" event though, and because the whole modem focuses on retraining rather than transmitting data during the training process, this cost is not added on top of your normal communication processing requirements.

In practice, I understand G.lite and full rate DSL are very similar in processing burden, and that the main difference is in how they're tuned. Full rate DSL is tuned for high speed transmission, at the expense of making retraining more expensive (since it doesn't expect to retrain often, as you mention). G.lite runs somewhat slower, but offers fast retrain to handle interruptions on the line, and also to offer lower-power modes that basically "hang up" the modem. The drawback is that you don't get as much bandwidth to play with.

With ADSL you have a box installed somewhere that has a connections for your DSL equipment and a second connection for your other telephony stuff. This box isolates the telephony stuff from the actual phone line...

This is the so-called splitter.

...so that they don't change the characteristics of the cable between your house and the exchnage, and thus the line characteristics need only be check when your equipment is installed.

Untrue. Line characteristics are also affected by weather, temperature, and potentially by changes in service to other people in your area.

G-Lite works by have a DSP in the ADSL gear continuously measure the line characteristics and take action accordingly, this removes the need for a wall box (reducing installation time and cost) at the expense of needing a bit more computing power in the ADSL modem.

Untrue, at least to the extent that this processing burden is unique to G.lite. "Regular" ADSL also has a DSP that performs the same function. (Hey, I work for a DSP company that sells a ADSL chipset that's used in both....) Now, it's come to my attention that the term "G.lite" is no longer widely used. It's officially known as ITU G.992.2, and most places don't bother to tell you what particular flavor ADSL you're running -- they'll just tell you a bandwidth number. Wheee.... The main point is that it's splitterless at the consumer's end of the line.

The main reason I say G.lite has lower computational requirements (at least, in steady state), is that the data rate is lower. Since at least some portion of the processing cost is proportional to the data rate, this makes sense. Much of the front end work that processes the analog data of the wire stays pretty much the same, though, as I understand it. Those pieces work at symbol rate, which I believe is fixed. The way bandwidth is varied is by varying the number of bits per symbol.

Now as for changing line characteristics: The line characteristics of a full-rate ADSL line and of a G.lite line both drift over time. A DSL modem needs to track these changes and incrementally update its mathematical model of the line. If too large of a change occurs, the DSL modem needs to re-train (just like a voiceband modem does) to get back on track. This is true for both ADSL and G.lite. A G.lite modem is simply much more likely to need to retrain due to wild changes in loading. Because retraining is an "exceptional" event though, and because the whole modem focuses on retraining rather than transmitting data during the training process, this cost is not added on top of your normal communication processing requirements.

In practice, I understand G.lite and full rate DSL are very similar in processing burden, and that the main difference is in how they're tuned. Full rate DSL is tuned for high speed transmission, at the expense of making retraining more expensive (since it doesn't expect to retrain often, as you mention). G.lite runs somewhat slower, but offers fast retrain to handle interruptions on the line, and also to offer lower-power modes that basically "hang up" the modem. The drawback is that you don't get as much bandwidth to play with.

(xDSL is an Alcatel technology)

I assume you mean "ADSL" rather than "xDSL", as there are several technologies to which the term "xDSL" refers (HDSL, SDSL, and ADSL, for example), many of which appear to have in common only the fact that they send Digital signals over the Subscriber Line.

Could you please cite some references to support the assertion that "ADSL is an Alcatel technology", or explain what you mean by "ADSL is an Alcatel technology" if you don't mean to imply that Alcatel invented ADSL? I have seen, in several places (admittedly, the ones I found were all from companies in the USA, so perhaps they're all part of the plot to discredit Alcatel), claims that, in fact, ADSL was originally conceived by Bellcore, and, in this Texas Instruments application report (see section B.3. "History of ADSL standards"), a claim that "the DMT line-coding technique was developed around 1987 as a result of the research performed by Professor John M. Cioffi at Stanford University".

Perhaps Alcatel is the main manufacturer of ADSL equipment, and they may have contributed a lot to the development of ADSL technology, but I've yet to see any indication that they invented ADSL, or even DMT, so it does not appear to be an "Alcatel technology" in the sense that they are the originators of ADSL.

This story is only an attempt to break the image of company in USA. In fact all that thing was cleverly prepared : the "hacker" that discovered it made a public advertisement whereas, for security, usually people who found security holes are asked to contact the company first in order to avoid crackers take advantage of the information. Moreover he contacted some friends and the media even before the post on the Internet.

Indeed? Are you asserting that this is part of some plot by competitors to discredit Alcatel? If so, do you have any evidence to support that assertion? (There wasn't anything in the transfert article making any such claim.)

I am a DSP software applications-type person at a certain large DSP vendor. While I don't work in the broadband access group, I still get to occasionally implement the crazy algorithms that deal with the reflections, noise, and other crap that DSL has to put up with.

So, no, I'm not a phony. (And BTW, I believe SDSL and ADSL and all the other xDSL family connection types have to put up with the same annoyances unless you get fresh copper laid just for you. If you get a "dry pair" that's already in the ground, you still may have stubs, wire-gauge differences and distance-related signal attenuation to contend with. Thankfully, you do still miss out on repeaters (which I forgot in my post above), loading coils, and voice-band filters.))

BTW, I also wouldn't be surprised if telcos in the US just have crappier infrastructure overall than our Canadian neighbors. Partly because (in some areas) the infrastructure is as old as the hills and hard to get to to replace it all, and partly because the telcos (and big business in general) are in bed with the US Gov't. :-P Other contries have decent communication infrastructure, why not us?

I've noticed that the US has a tendency to not embrace new technology as quickly, as long as businesses can still milk $$ out of the current technology. Fun, fun... I suspect it's that sort of thinking that's left the US with a rotting, aging, non-DSL-friendly POTS network, little ISDN to speak of, and a country that 1/2 to 1 full step back from most of the world in deployed wireless technology. Whoo hoo!

Intel has often claimed that the 4004 was the first CPU chip. And it's generally accepted as fact.

However, it's not.

TI unveiled one in 1970. I can't even remember the part number because it didn't get any popularity, but itwas basically the entire CPU board from a TI minicomputer compressed onto one chip.

The patent wasn't issued until 1973.

"Texas Instruments invented the integrated circuit, microprocessor and microcomputer. Being first is our tradition."

- TI Product Manual

Fact: Texas Instruments makes more chips every day than Frito-Lay.

Fact: Texas Instruments made the first 16-bit CPU chip, too - the TMS9900. It was used in TI-99/4A home computers and Patriot guided missiles.

Fact: Most TI stuff is built to almost military specs: the home computer's cards were cased in cast aluminum.

Intel is just an annoying little upstart, and the Pentium 4 is merely the continued evolution of the 4004, which was merely a hand calculator chip.

Oh, yeah, and TI did that, too, also in 1971. Only, I'd submit that Intel didn't complete the job, the 4004 required support ICs. TI's didn't.

Intel has often claimed that the 4004 was the first CPU chip. And it's generally accepted as fact.

However, it's not.

TI unveiled one in 1970. I can't even remember the part number because it didn't get any popularity, but itwas basically the entire CPU board from a TI minicomputer compressed onto one chip.

The patent wasn't issued until 1973.

"Texas Instruments invented the integrated circuit, microprocessor and microcomputer. Being first is our tradition."

- TI Product Manual

Fact: Texas Instruments makes more chips every day than Frito-Lay.

Fact: Texas Instruments made the first 16-bit CPU chip, too - the TMS9900. It was used in TI-99/4A home computers and Patriot guided missiles.

Fact: Most TI stuff is built to almost military specs: the home computer's cards were cased in cast aluminum.

Intel is just an annoying little upstart, and the Pentium 4 is merely the continued evolution of the 4004, which was merely a hand calculator chip.

Oh, yeah, and TI did that, too, also in 1971. Only, I'd submit that Intel didn't complete the job, the 4004 required support ICs. TI's didn't.

Aren't corporations supposed to be more focused on doing business than suing?

For what it's worth, I hope RAMBUS loses this particular battle, even if it isn't likely. The Motley Fool posted an article a while back predicting the success of RAMBUS based on these patents. Hardware patents can be as harmful to the industry as software--it's a hot issue right now, and some people are trying to do something about it already.

So what should be done with patents? I haven't really heard a good solution yet. Most solutions either favor the corporations (and lawyers) or they throw out the entire system, innovation to be done at your own risk. Is there a middle ground?

Tim

The TI-89 has a Motorola 68000 processor at 10 or 12 MHz. See the TI calculator processor chip and speed FAQ.

And next time, don't correct someone when you don't know what the hell you're talking about.

In my day job, I'm occasionally charged with the task of writing code that takes our processor architecture to the limit. We're talking every cycle count, codesize is important, and functionality must not be overly compromised. I've been fairly proud of most of my results, and I think they're quite beautiful examples of what can happen when you first design a well-thought-out piece of functionality, and then optimize it to the hilt.

In my application space, this is appropriate. I'm coding for a DSP, and the functions I'm coding are individual DSP processing steps. These are nice, separable functions that some would have us implement directly in silicon. My job is to show them that a programmable processor can do the job.

The following links show some of these "DSP kernels" that I am especially fond of. In my opinion, this code is actually fairly well structured for assembly code. All of the hardware registers have been abstracted behind .asg directives, so that they can be given human-readable names. These names relate back to the C code description of the function (which is also provided in a comment block attached to the code). As an added bonus, comments throughout the code explain the numerous optimizations.

• IEEE-1180 Compliant Inverse Discrete Cosine Transform.
• Forward Discrete Cosine Transform.

In a different realm, I have a mix of beautiful and ugly code for an entirely different platform. Recently, I've written a Falling Tetrominoes Game for Intellivision named 4-Tris. The assembly code for this game is rather clean and heavily documented. The game actually implements a lightweight task scheduler and then builds the game on top of that as a series of event handlers. Of course, there are some definitely UNbeautiful bits around the edges. There's a Pong game hidden in there that's written as nearly complete line-noise. Also, the song format compiler is an absolute hackish mess.

So, it's safe to say that my code runs the gamut from clean and clear to nearly line-noise.

BTW, for those who are interested, I also have a Monitor Program that I wrote for the 8051/8052 microcontroller. I can't decide if it's ugly or beautiful. The problem here is that the architecture itself is downright ugly, but some of the optimization tricks in the code are either beautiful, insane, or par for the 8051 course. :-) At the very least, I consider it ugly compared to 4-Tris and the DCTs above, so...

In my day job, I'm occasionally charged with the task of writing code that takes our processor architecture to the limit. We're talking every cycle count, codesize is important, and functionality must not be overly compromised. I've been fairly proud of most of my results, and I think they're quite beautiful examples of what can happen when you first design a well-thought-out piece of functionality, and then optimize it to the hilt.

In my application space, this is appropriate. I'm coding for a DSP, and the functions I'm coding are individual DSP processing steps. These are nice, separable functions that some would have us implement directly in silicon. My job is to show them that a programmable processor can do the job.

The following links show some of these "DSP kernels" that I am especially fond of. In my opinion, this code is actually fairly well structured for assembly code. All of the hardware registers have been abstracted behind .asg directives, so that they can be given human-readable names. These names relate back to the C code description of the function (which is also provided in a comment block attached to the code). As an added bonus, comments throughout the code explain the numerous optimizations.

• IEEE-1180 Compliant Inverse Discrete Cosine Transform.
• Forward Discrete Cosine Transform.

In a different realm, I have a mix of beautiful and ugly code for an entirely different platform. Recently, I've written a Falling Tetrominoes Game for Intellivision named 4-Tris. The assembly code for this game is rather clean and heavily documented. The game actually implements a lightweight task scheduler and then builds the game on top of that as a series of event handlers. Of course, there are some definitely UNbeautiful bits around the edges. There's a Pong game hidden in there that's written as nearly complete line-noise. Also, the song format compiler is an absolute hackish mess.

So, it's safe to say that my code runs the gamut from clean and clear to nearly line-noise.

BTW, for those who are interested, I also have a Monitor Program that I wrote for the 8051/8052 microcontroller. I can't decide if it's ugly or beautiful. The problem here is that the architecture itself is downright ugly, but some of the optimization tricks in the code are either beautiful, insane, or par for the 8051 course. :-) At the very least, I consider it ugly compared to 4-Tris and the DCTs above, so...

With all the wild speculation going on around here, I thought it might be worth throwing some actual links in here to real information.

• Itanium Processor Family Home -- has links to all sorts of IA-64 material.
• The IA-64 Architecture Specifications and Guides -- lots of good documentation links.
  • Architecture Software Developer's Manual Vol 1, rev 1.1: Itanium (TM); Application Architecture
  • Architecture Software Developer's Manual Vol 2, rev 1.1: Itanium (TM); System Architecture
  • Architecture Software Developer's Manual Vol 3, rev 1.1: Itanium (TM); Instruction Set Reference
  • Architecture Software Developer's Manual Vol 3, rev 1.1: Itanium (TM); Processor Programmer's Guide
• And don't forget Itanium[TM] Processor Microarchitecture Reference.

I haven't read all of these myself, but I have poured over the details that are most relevant to my work. :-)

Have fun.

Tee hee! Actually, it's kinda interesting, speaking of 4GB RAM, the next workstation I'm scheduled to get at work will have ~4GB RAM in it, and two happy UltraSPARC III CPUs in the ~800MHz range. Whee! (And to think those US IIIs came out of our fab just up the street! Whoo hoo!) The design jobs that run on my workstation really use that much RAM too. They're not my jobs though -- I'm a software guy. All our workstations are in a load-sharing queue, offering gobs of MIPS for crunching all of design's jobs day in and day out. I can kick the jobs off my node during the day as needed, though, which is nice, especially on my current workstation which only has a half-gig of RAM.

As for light, content-free entertainment, you can get that anytime by setting your threshold to -1. I find it rather amusing. :-)

It was supposed to be the first mass-market VLIW chip, though Transmeta beat them to it.

Erm, and how exactly do I program Transmeta's VLIW assembly language? What's that? I can't? Although Transmeta's TMxxxx family of CPUs uses a VLIW architecture presently, nothing constrains them to a particular VLIW instruction set or even to be VLIW on future parts, since the only interface they expose is their emulation of the x86 instruction set. They may as well have a little hamster running in his wheel in there -- as long as it cranks out x86, it won't change the instructions you program it with. (The hamster might not be as fast as the VLIW, though. ;-)

So, with that in mind, I'd say that Itanium will probably be the first mass market VLIW-like programming platform. Of course, TI's TMS320C6000 DSP was probably the first volume-shipping VLIW-on-a-chip, even if it wasn't targeted at the desktop market. The old Multiflow and Cydra machines of yore never quite got that small.

It looks like PCs are hard to beat. Here's a claim of a Fraunhofer encoder at 10X real time on a 500 MHz Pentium3. Maybe it's vapor, but if it's real it's certainly a lot faster than LAME 3.87 (beta) when I tried it on a 800 MHz machine (Lame ran at approx 2X using "-V 3"). I recall hearing claims of LAME doing real time on a 266 MHz PC... maybe it does with different settings.

I also want to hear Sony's SACD: like 2.4Mhz sampling rate, but 1 bit.

The bitrate is only 50% higher than a CD's bitrate (1.5Mbit/sec), so don't go creaming in your pants just yet.

The main difference the 1 bit/sample makes in this case is that your bandwidth theoretically stretches to a much higher (and quite ridiculous) 1.2MHz. Of course, the SNR is really, really low at 1.2MHz. For such a system, the effective dynamic range (and SNR) is inversely proportional to the frequency. You'll gain high-end range at the expense of high-end precision and range. Assuming they use something like sigma-delta demodulation to decode this into listenable audio, you also lose dynamic range over most of the listening band due to the concept of "slope overload".

(ObDisclaimer: That is, if I remember my signal processing courses from school correctly. I may program DSPs for a living, but that's because I'm a good coder, not because I was good with DSP theory. Most of what I do is other engineering, not actual signal processing.)

Urgl... the link got bogarted. Again, that's a deeply pipelined CPU. To give you an idea of how deeply pipelined it is, a "Load Word" instruction takes five cycles, meaning I issue the "Load Word", wait four cycles, and then I get to use the result. :-)

Latency is important to the extent that it limits bandwidth. As other posters point out, modern CPUs have many mechanisms for dealing with latency to a certain extent. (Some, such as Alpha, go to Herculean extremes with a gigantic reorder buffer and a cache which allows four or five outstanding misses to pend while still allowing hits in the cache.)

In the end, the raw amount of work performed is measured in terms of bandwidth. To process N items, you need to touch N items, and how quickly you touch those N items is expressed as bandwidth.

As a person who programs a deeply pipelined CPU, I can attest that latency can affect some algorithms (especially general purpose control algorithms) more than others, since it limits how quickly you can process a given non-bandwidth-limited task. However, for raw calculation (eg. all those graphics tasks and huge matrix crunching tasks the numbers folks like to run), those tasks are fairly latency tolerant and just need bandwidth.

This is why number-crunching jobs might work well with, say, RAMBUS, but desktop jobs might work better with DDR SDRAM, even if the two are at the same theoretical bandwidth node.

Although I must say, there is something to be said for that, er, sophisticated-looking keyboard. (Maybe this is it.)

Seriously, one of the major selling points for the VAIO series has been (no, not the easy-to-pronounce name) its very high-tech, executive look. Business users and geeks alike are proud to be carrying these little gems of late-twentieth-century innovation. The iBook is less popular with professional users for these very reasons, but (1) it is still quite popular on account of its design, which is more whimsical but still very sophisticated; and (2) its target demographic has never been professional users.

This design, however, feels very much like the shiny plastic vacuum cleaner sitting in my closet. Sure, it works, but it's flimsy; the plastic handle flexes under applied torque, and the little plastic "accents" are starting to fall off. The iBook may "look like a toy", but I fear the new VAIOs may "look cheap like a toy."

This is TI's "Digital Light Processing" system. It is indeed very cool: It's a direct digital output device, there's no DAC or pixel drivers required. That's because it's really just a video RAM with a set of MEMS mirrors which rock back and forth on a duty cycle proportional to the "on-ness" of a particular pixel. They ysed to have a site explaining in detail at www.ti.com/dlp (Warning - I haven't checked this link to see if it still works, since Netscape is acting flaky and I want to get through this post.)

I looked at this technology a few years ago, and all the better portable "LCD" projectors out now are actually DLP units. There is *no* visible separation between pixels, unlike LCD or other systems, and the brightness is incredible - easily viewable in a daylit room.

At one point a year or two ago, the TI web site said that Nokia was planning a (40-ish inch) DLP-based TV, which while not a flat panel, was still planned to come in at only about a foot deep. I don't know what happened to this product, but it looks like Samsung beat tehm to that form factor with their new FLCD TV.

(I do know that TI had real problems in getting the DLP chips to scale up in resolution - they were stuck at 6x4 and 8x6 for a long time... (Yes, that's 640x480 and 800x600, really - it's a common abbrev. in the laptop business...)

How many times have you been looking at old code and thought "What were they smoking when they wrote this?"

Actually, I think that very often when I look at my own code. I don't smoke in the traditional sense, though. The most that happens is that smoke starts curling out of my ears after a few Venti coffees from the local Starbucks.

The kind of coding I do, though, is prone to these sorts of questions. :-)

And yes, it's supposed to look like that.

• The device will almost definitely run WinCE as its OS. I have no idea why, and there's no reason from the company (or for the company to do so, aside from mad development cizash from Microsoft). Don't get your hopes up, though. I have a WinCE device (that I got for free, heh-heh) and it's not THAT bad. Just expensive.
• Everything has a "futuristic look" these days. Palm V, i-Opener, iMac, et cetera. This is HP's answer to TI's translucent color slide cases. Knee-jerk reaction.

Somewhat related: Digital Light Processing.
--