Zilog enters the 16-bit market. Again.

My first exposure to microprocessors came through the use of the Zilog Z80 chip. It was hard to do any work with small computers in the late 1970s and NOT use the eight-bit Z80; they were relative cheap, easy to build circuits with, and simple to program. Many hardware and software engineers, including myself, cut our teeth on Z80 assembly. Early microcomputers, like the Radio Shack TRS/80 and numerous CP/M boxes, used the Z80 before the IBM PC came out and redefined the landscape around Intel’s x86 family.

But Zilog, what have you done for us lately? Not much, given the company’s recent financial woes — millions of dollars of losses every quarter. While the company still sells variations on its newer eight-bit Z8 microprocessor, it also offers other stuff like infrared controllers. Even so, the breadwinner is the Z8, which includes onboard flash memory, perfect for embedded microcontroller applications.

Zilog has lived in an eight-bit world for 30 years. Yes, the company has attempted to break out of the eight-bit box before, such as with the short-lived 16-bit Z280 and 32-bit Z380 processors from the early 90s. But they just didn’t go anywhere.

Flash forward (so to speak) to 2006. One month ago, the company dumped its chairman/CEO, Jim Thorburn, who had been in place for five years, appointing an interium CEO while beginning a search for a permanent replacement. And now it has released a new 16-bit platform, called ZNEO.

ZNEO looks like an interesting chip, and a possible upward migration path from the Z8 microcontroller. It has fast zero-wait-state internal flash memory, in a variety of sizes ranging from 32KB up to 128KB: that’s a lot of space in the embedded market. Plus, it has a math engine that can do 8, 18, and 32-bit operations.

Clearly, the ZNEO project is going to be critical for Zilog, as the firm struggles to survive. It’s a chicken-and-egg situation: Zilog needs new customers and design wins in order to get its finances in order. But will embedded developers, who perhaps rely upon the company as a provider of tried-and-tested commonity chips, want to base their future products on an unproven platform from an trouble supplier? Time alone will tell, but I have my doubts.

Z Trek Copyright (c) Alan Zeichick

The Itanium Solutions Alliance…

Tomorrow I’m heading up to San Francisco for the second day of the Intel Developer Forum. I’ve received many meeting invitations for IDF, but have been struck by the paucity of news or announcements that would apply to software developers. The bulk of the third-party announcements have focused on storage and wireless networking. As Intel gets farther from its roots in CPUs and developer tools, the less relevant much of their ecosystem becomes, at least for me.

One of today’s announcements, one of the few that I found interesting, involved the use of dual-core processors in embedded applications. Dual-core processing will have a significant impact on the embedded/device development market, which has traditionally deployed single processors with single cores. In a hard real-time environment, using a high-end RTOS from companies like Wind River or Green Hills, or one of the hardened versions of Linux, applications must be both tight and deterministic. How well will that play in a dual-core environment, where you have multiple hardware that threads that won’t be synchronized? It should be less of a problem than with dual discrete CPUs — but it’s going to be in issue nonetheless. I look forward to learning more.

Something that I don’t particularly want to learn more about is what’s happening with the Itanium processor, which could be fairly characterized as an increasingly niche product. Sure, the vertical scalability of a high-end Itanium 2 processor can be impressive, but the world belongs to the 32-bit and 64-bit x86 processors from Intel and AMD. While RISC will still play a role, particularly with Sun’s SPARC processors, Itanium is destined to remain the poor stepchild, relegated to specific applications, like big honkin’ databases. And there’s nothing that the Itanium Solutions Alliance — a vendor consortium set up by Intel to promote the processor — has done to change my mind about that.

Z Trek Copyright (c) Alan Zeichick

Cyberfortress vs. low-hanging fruit

My 9/21/06 “Zeichick’s Take” about automotive security brought several letters-to-the-editor, one of which made an excellent point that applies well in the physical security world, but which in my opinion falls down in cybersecurity.

Steve Brewin wrote,

“Apparently the vast majority of crime is committed by amateurs chancing on an easy opportunity. The simple lock removes the easy opportunity, amateurs will look elsewhere. Professionals play for much higher stakes and while they can easily bypass such simple security mechanisms, the probability of an attack from them is massively less. Most targets are not worth their time. For most, the cost of installing systems capable of thwarting their attacks is disproportionate to the risk.

The insurance assessor explained that while most viewed their offer as a marketing exercise, their statistics told them that the discount they were offering was small compared to what they expected to save in the cost of claims alone.“

That’s very true. Professionals can unlock cars, remove The Club, jimmy house doors open, even break a laptop security cable with a small bolt cutter. So can a determined amateur, who can pick up the right tools, or practice simple techniques. But what about the casual amateur? The kid walking through the parking lot who sees an brand-new iPod sitting in a car? For that kid, a locked door may sufficient to make him move on.

In other words, if someone is bound a determined to steal YOUR things, locks probably won’t help. But if they’re just looking to steal SOMETHING, they’ll pick the lowest-hanging fruit. Your security system simply ensures that your fruit isn’t the lowest-hanging target.

But that falls down when it comes to cybersecurity — because of the shotgun approach. Even the most casual script kiddies use sophisticated ports scans, SQL injection, worms and other automated techniques. Those are the equivalent of trying to break into every car in the parking lot simultaneously. I’m not sure that hoping that someone else’s computer is a lower-hanging target is enough. It’s unfortunate, but our neworks, servers, desktop AND applications have to become fortresses. At every layer of the stack, we’re being targeted.

Z Trek Copyright (c) Alan Zeichick

2007 editorial calendars are up!

(Cue the trumpet sound effects) The 2007 editorial calendars for SD Times and Software Test & Performance are now avialable.

For those of you who don’t follow such things, a magazine or newspaper’s editorial calendar provides insight into some of the feature articles that the publication will cover during the next year. It’s traditional for them to come out in September or October. Edit calendars often also provide information for advertisers regarding the cutoff dates for reserving ad space and for delivering ad materials. Edit calendars are used by writers, advertisers, and corporate communications professionals.

It’s important to note that edit calendars are always subject to change without notice. While we do our best to predict the long-lead stories for our publications, software development is a fast-evolving industry. So, you might want to bookmark the editorial calendars, and check back every few months to see if they’ve changed.

There’s one 2007 edit calendar still to come, for Eclipse Review. We’ll post that in a few weeks.

Z Trek Copyright (c) Alan Zeichick

Eclipse bugs resolve later…or never

One of the challenges for any software development project — whether enterprise or for-sale, open source or not — is what to do about all those pesky defects that nobody’s going to fix. Why aren’t they going to be fixed? It might be that they’re not a show-stopper, or that there are other priorities, or there’s no easy fix, or simply that nobody wants to do it.

Every non-trivial software project has bugs that won’t be fixed. Sometimes you know that it’s not going to be fixed, and at other times, everyone has the best of intentions, but it just never gets done.

One of the benefits of most open source projects is transparency. Take Eclipse, which uses a public bugzilla feed to let users and contributors report defects. When defects are reported, often they’re resolved, but sometimes they’re marked RESOLVE LATER. Does that mean that the issue truly will be resolved later, or as some people suppose, is that a polite euphemism for RESOLVE NEVER?

Let’s face reality: Not every bug is going to be fixed. Yes, it would be nice to have less ambiguity, and to know, for certain, that a specific bug is going to be (or not going to be) addressed. But at least with a system like the RESOLVE LATER system, you can see if action is being taken or not. With non-open-source projects, or OSS projects that take place with less transparency than Eclipse, bug reports go into a black hole.

By contrast, with commercial software, a bug will only be fixed if the software owner sees the business value of fixing it. While I agree that RESOLVE LATER is suboptimal, it’s easy enough to see that a bug that’s been ignored for months or years isn’t going to be addressed. And that’s valuable information.

Z Trek Copyright (c) Alan Zeichick

Goodbye, Patricia

The HP spying investigation is getting stranger by the day. When the company reported that its chairwoman, Patricia Dunn, was going to step down as of January, many of us knew that wouldn’t hold — she had to go, and she had to go now. Only a few days later, after more revelations, she resigned effective immediately on Sept. 22.

But what about the new chairman, CEO Mark Hurd? He’s presided over a remarkable turnaround; HP’s fortunes and reputation have improved tremendously since he took over from the disastrous Carly Fiorina. It would be a significant blow to HP were he to be forced out due to this scandal — but that’s a real possibility, given numerous reports that Hurd was in the loop regarding Dunn’s espionage on board members and journalists.

Indeed, as reported in this Fortune story published that same day, Hurd admits to having known that HP was involved with questionable activities. Isn’t it his job to intervene? It doesn’t look good for Hurd, and it doesn’t look good for HP.

Z Trek Copyright (c) Alan Zeichick