Author Topic: #455 – Bill and Dave’s Excellent Equipment  (Read 4634 times)

0 Members and 1 Guest are viewing this topic.

Offline thinkfat

  • Supporter
  • ****
  • Posts: 2110
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
#455 – Bill and Dave’s Excellent Equipment
« on: August 20, 2019, 10:57:02 am »
Around minute 35 or so the topic of botched silicon comes up, I have an interesting story to share myself:

Around 2003 or so I was working for Archos, you may or may not know them, they pioneered portable media players in the early 2000's. During that time I was working on a prototype of what would later become the PMA430, which was a PDA/Media player with a 30GB hard drive and running Qtopia and a couple of media players apps which were made by Archos themselves.

It was decided that we'd use a top-notch brand new Digital Media chip from TI and we should receive early silicon samples soon. The SoC combined a DSP and some application specific accelerators that would aid in media playback and recording and an ARM9 core that we intended to run Linux on.

So the chips show up together with a beautiful EVM and we put them into the socket and start porting the Linux kernel and it just won't run! As soon as the MMU was turned on, hell broke loose and the kernel would crash and never actually make it into userspace. And since the architecture was new and we had to write a good amount of code to support timers and interrupt controller and control caches and whatnot, we were looking for errors we might have made ourselves.This went on for weeks.

Finally, we receive an errata sheet for the chip and guess what, the silicon was buggy! There was a timing problem with the ARM9 and the MMU and when a TLB miss happened and the MMU had to do an actual table walk to calculate the address translation, the translation result would not be ready when the ARM9 core needed it, but the ARM9 would not stall but just execute code from random places! And apparently the bug was so severe that TI decided to not fix it and just advised to use the MMU only with 1:1 virt-to-phys translation so that the data cache could be used. Of course you cannot run Linux on that.

So that was that, we had to abandon the chip and that caused a lot of grief later on because of course the product was on the roadmap and had to be done. The solution that we developed was a hell of a contraption: Of course there was nothing on the market or on the horizon even that would match the spec of the original chip and so we decided to go for a two-chip solution.

There was a new digital camera chip, also from TI, which would match the multimedia specs of our original target chip but it only had an ARM7 as an application CPU. But it had an external memory bus which you could hook up to another CPU like NOR flash and then parts of the chip were externally accessible. The new chip was not available yet but we had an EVM for the previous chip of the same family, the DSC25, so we started with that one. There was access to the memory of the DSP and control registers and so you could load programs into the DSP from the application CPU and boot the DSP and feed it with a MPEG video stream and it would spit out decoded video frames to an external DRAM. As the application CPU we wanted to use some Samsung ARM9 chip, I think it was the S3C2410 or something. That didn't go well with TI because they wanted a full design win and offered us the OMAP5910, which was normally off-limits for us as it was from their mobile division which would not talk to us. So I hooked up the two EVMs, DSC25 and OMAP, with a ribbon cable, manually soldering all the address and data lines of the memory busses, and of course I did it twice because I didn't realize that the external bus of the camera chip didn't have A0. And then we went on writing the software and integrating the video codecs and making good progress, things were looking good again.

Eventually we get an EVM with the new camera chip, I think it was the TMS320DM270, also early silicon, with a register manual entirely in Japanese, and we look at the data sheet and there's the next shock: We could not access the DSP and the DRAM! Apparently the access method we intended to use was only available on the DSC25 and it was gone now on the new chip and when we discussed the architecture with the TI FAEs nobody bothered to tell us! All that was left was access to the internal memory of the ARM7, a low-bandwidth read/write peephole into the DRAM and a higher-bandwidth burst-access module where you could bulk-update the DRAM with a somewhat decent speed but you could not read it! Which was pretty bad, considering that we needed fast access to the decoded video frames which the application CPU, the OMAP, would have to display at 640x480, 30fps or so.

The solution we came up with was to hook up the LCD to the camera chip instead of the OMAP, write a small program for the ARM7 core on the camera chip that would operate as a broker between the OMAP and the DSP, drive the LCD, do the blitting of the video frames etc and establish some control protocol where the OMAP would write commands into the internal memory of the camera chip and the program on the camera chip would execute them. And of course Qt would have to be modified to use the camera chip as a framebuffer, which was a nightmare in itself - you may remember what I wrote about the "missing" A0 line: the memory addressing was strictly in 16 bit quantities, so to modify a single byte (pixel) you had to read the 16 bit word that contained it, modify it and write it back, all access through the memory peephole the camera chip offered. You can imagine the performance we got out of that.

Another minor problem was that we needed to hook up a 30GB hard drive to the OMAP, which, being a mobile phone chip, could not directly interface. Fortunately, PATA hard drives could be hooked up to a general-purpose memory bus with a bit of glue logic and if you connected the IORDY signal of the drive to the WAIT input of the OMAP, the memory bus would stall until the drive was ready to perform the access. Unfortunately, the OMAP's memory bus would also lock up hard if the WAIT input was pulled at the wrong moment and only a power cycle would get it going again, which didn't really help.

Nevertheless, eventually we pulled it off and the product was released in 2005. It wasn't a huge success, though, which is not really surprising if you look at its history.
Everybody likes gadgets. Until they try to make them.
The following users thanked this post: reboots

Offline bsfeechannel

  • Super Contributor
  • ***
  • Posts: 1654
  • Country: 00
Re: #455 – Bill and Dave’s Excellent Equipment
« Reply #1 on: August 21, 2019, 05:18:27 am »
I agree with Dave (from 46 to around 50 min.): the reverse italics on Rigol equipment show a complete disregard with the user interface. It seems an unimportant detail but for the attentive designer it's clear that, whoever did it, they had no idea what they were doing.

Years ago I read the eye-opening "Dont Make Me Think" by Steve Krug.

It is a guide to web page design for intuitive navigation. But its principles can very well be adapted to any user interface design.

Chris should read it.

Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo