BusyBuilder wrote:


PLEASE on please, can we see some real microcontroller marketing and a real product roadmap very very very soon? I'm a rabid fan but I feel that my love for Zilog is unrequited.

Just going back to where all this recent discussion started, my previous company had an annual software and hardware release cycle. To allow time for customer input, R&D, test and production lead times, they would publish a rolling roadmap quarterly that was made available to customers via the sales/ marketing channels.

This roadmap would show (per product):

- Long term plans (2-3 years +) with a wishlist of features and functionality
- Short term plans (1 year+) that would show a firm (beta) list of features and functionality
- Current (next 12 month) delivery with final features and functionality
- An obsolescene list for the entire roadmap (hardware and software)

Customers would be welcome to comment on the roadmap (within set timeframes) and those features that were seen as beneficial (not just popular) would be incorporated into the roadmap with sufficient leadtime to incorporate them into the release cycle. Customers would also have sufficient knowledge of products going obsolete to work out alternatives.

Seeing all the great ideas coming out of this discussion, it should not be too difficult for Zilog to produce a "straw man" roadmap as a starting point for each of their product lines and release it via these forums or their website document repository. Set up a roadmap comment topic in the forums and use it to garner input. Close inputs "x" months before finalisation to work out costs, schedule and effort and which features make it into the final list. Release this list in the next roadmap issue and then go into the development and release cycle.

The more information that is out there about Zilog products and their future would make it easier to make decisions about using Zilog.

Here here!

Better yet, let's see some chips, app notes, sample code, etc. flowing again!!

Tom Ormiston wrote:
Our product roadmaps are generated from customer and market requirements. The more we can hear from our customers about how we can help them solve their struggles the better our roadmaps can target what our customers need.
Zilog has been hearing from us for 3+ years now. By now shouldn't you know our requirements?

when my distributor tells us we should not use Zilog microcontrollers for new designs that says the industry perception is that Zilog is not serious about the microcontroller business.

To put it bluntly the time for words is past we are hoping to see silicon action. Not Zdots, all that does is tell us you are competing with your silicon customers. And not "we are releasing new products blah blah blah" mysteries.Not another Zdot which tells me no new silicon.
We need convincing proof that Zilog/IXYS will be making new microcontrollers. We need a microcontroller silicon product roadmap and a no-excuses attitude from Zilog that the silicon will be built. Does anyone else agree?

This is weird - everyone is mentioning things you'd like to see, and these exact issues have been in my development notebooks for 6-7 years already! It's like Zilog's customers are of (more or less) one mind!

I'm a small-time developer/designer/inventor, and it's really surprised me that the problems I've been working around are the same as most of these much more important developers, even if not all at once!

As a small developer/designer, I can heartily second most of the suggestions already listed. To be specific :
- More UARTS.
With GPS, a debug TTY channel, telemetry, I'm running out of serial ports. Even with multiplexing, I can't do it in one chip. Or else, go back to the KIO days, and provide an integrated support chip with 8 UARTS, 4 SPI, and 2 I2C. It can map anywhere in available IO space and should hook into the interrupt system seamlessly. (Sorry, I'm showing my age now).

- Wider voltage support on all I/O pins.
Small developers generally start with 5V or 3V3 through-hole design support, most of which is still 5V or 3V3. I don't mind putting in pullups and signal conditioners for output, as long as the input pins are TRULY 5V tolerant!

- More and MUCH larger timers.
16-bit resolution at higher clock speeds means much more software to write to handle rollovers, short-term events, and (especially) long-term timing. I don't know if a 64-bit timer is practical, but I can think of at least 20 uses in my current designs. If Zilog can do a timer daisy-chain (for linked 8/16/24/32-bit timer "collections"), that would kill at least 3 birds with one bit of silicon.

- More onboard flash/SRAM.
Nearly every design I start with the eZ80F91 has automatically included external flash ROM and SRAM (a la the dev modules), to the point where I just cut and paste the external memory into every new project. It would seem to make more marketing sense for Zilog to include this on-die, and stay way ahead of the pack.

- PWM fixups.
After 8+ months, I'm still waiting for a response on the PWM selection bug in the F91 core. Luckily for me, that project is waiting for more customer input. Otherwise I'd dump the eZ80F91 and go with ARM.

- "Black Box" ADC.
If every competitor can provide a range of ADC modules for nearly every competing (and even non-competing) core types, with a selection of sample rates, channel counts, and bit depths, the eZ80 line is looking pretty 1950's. The Zilog ADC modules I've tried to design with all require major support code to get a simple ADC value, which adds development time and sucks up bandwidth.

- Get back in touch with your most valuable resource - us people with no life!
As one example, I'm trying to understand why, as a ZDS user who's offered multiple suggestions and bug reports on the ZDS IDE over nearly a decade, I'm in the dark when it comes to learning about new releases of the IDE. Why aren't Zilog investing in us developers by keeping us informed about new releases of the development environment "asynchronously"? It's quite frustrating (and somewhat bizarre) for us to learn about new dev software releases in an off-topic forum like this, instead of a newsletter (and I've only ever received one of those!).

Why frustrated? Well, while I don't have a LOT of bandwidth, I'd be delighted to help test new releases on a variety of hardware (32 and 64-bit) on a variety of OSes. Obviously, the previous releases weren't able to be thoroughly tested (otherwise I wouldn't have found a dozen bugs, issues, mistakes, errors, snafus, gotchas, or oopses in the first week of using the new release!), so why not use the immense loyalty and synergy that's out here to bulletproof the software?

- Please, please fix the frustrating Zilog website and the problems associated with the new web infrastructure.
I'm another one of those customers who have repeatedly raised the major problems with the new site, particularly the massive problems with finding a) any information about current silicon, b) related information (errata, whitepapers, examples), and c) where to go next.

Right now, I have around 300 Zilog PDFs on my main system that I downloaded before the website "upgrade". That way, I can find the information I need without trying to fit my square peg requirements into the round hole search tool. That's just one example of how much more difficult it is to keep current with Zilog. Compare and contrast that with Atmel, Microchip, NXP, ST, heck, even Parallax.

The difference between new online chipmakers and Zilog's current website is a bit like the analogy between making it as easy as possible to compare, evaluate, trial, and test any part from any product family from most of your competitors' websites, (which is like walking into a Toys R Us store for silicon!), and going in to one of those old engineering companies where you had to have the correct 28-digit part number up-front, which you hand over the sterile counter, and a very old man would climb off his chair, go through a swinging door to a room where all you can see are walls filled with white boxes, and return minutes later with a part that doesn't quite fit because you used the new numbering scheme instead of the old numbering scheme. In one store, you walk out with an arm full of product and support hardware, in the other you're lucky if you can find the original search ticket you came in with. Bad analogy, but it's all I can come up with right now...

I get the very strong impression that Zilog/IXYS is actually in the business of proving it's still in the business. That works great for investors, but not so much for your customers. I think most folks in these forums have given Zilog a great opportunity of proving itself. We've also been incredibly patient as the takeover munges up the company from the inside. It would seem to be the opportunity of the decade to take on board what your developers are saying (for free!) and reconnect with us.

I really would like to know what Zilog are producing in the next 6-8 months - and I'm not talking wishlist/roadmap, I'm referring to engineering specs, release dates, and evaluation kits, not investorspeak news releases. I appreciate hearing that there are plans, but after so many months of silence, it's not a lot to go on with...

At least treat us like developers, distant technical associates, or even Z80 architecture evangelists, instead of end-users.

I HTH.

Peter Naus wrote:

- More and MUCH larger timers.
16-bit resolution at higher clock speeds means much more software to write to handle rollovers, short-term events, and (especially) long-term timing. I don't know if a 64-bit timer is practical, but I can think of at least 20 uses in my current designs. If Zilog can do a timer daisy-chain (for linked 8/16/24/32-bit timer "collections"), that would kill at least 3 birds with one bit of silicon.


This suggestion has a low silicon cost, so has to be a no brainer.
32 bits makes sense, with maybe a 2^N prescaler, and a simple means to cascade.

I'd need examples of where > 32 bits is important : 2^32 is 42+ seconds from a 100MHz clock ?

My favourite would be a Reciprocal Counter Ready timer, which allows Capture from TimerOut, and a /2^N Pin divider, that
sets the capture rate. With a Pin-Mux like an Analog Channel.


- More onboard flash/SRAM.
Nearly every design I start with the eZ80F91 has automatically included external flash ROM and SRAM (a la the dev modules), to the point where I just cut and paste the external memory into every new project. It would seem to make more marketing sense for Zilog to include this on-die, and stay way ahead of the pack.


This suggestion has a high cost impact, so needs care. It also thins-out product R&D, as each big jump needs a new tapeout.

I think these days QuadSPI gives a very useful way to soften the code ceiling. Newest announced NXP cores support this, so it is one place Zilog could get topical.

SPI ports with FIFOs are also another appeal of 32 bit uC, and I see a trend for a UART block to have SPI as an option.
(once you have FIFOs that makes sense, and gives users freer mix of Serial Types.

FractionalBAUD USART/SPI/QuadSPI would be the 'serial building block'

Peter, you bring up a good point. Zilog: Pay attention: I too have never used the ez80F without external Ram + Flash, the chip by itself doesn't have enough of either. That might be something to think about as a good varient: Just get rid of the on-chip RAM and Flash because there isn't enough to be useful for larger projects (Or don't worry about adding more on-chip memory). We're always going to add at least 512k of fast ram no matter what, and we'll always have at least a few MB of external flash, so you might think about a variant that has more chip devoted to a good selection of FIFO'd comms (UARTS/SPI/I2C) and useful timers, and that will be expected to use external parallel memory anyway. If people need QuaiSPI memory, then there should be a dedicated SPI block for that purpose in mind.

I wouldn't worry about on-chip ADC's myself, for what I typically need these would need to be 14 or 16 bits, and I've never seen any on-chip ADC on any MCU that has a low enough noise level to be reliable. It seems to be easier, cheaper and more reliable to mount the I2C / SPI ADCs on a quiet section of the PCB where it can have its own quiet power and ground plane. That's what we've done with the existing ez80's and it works well.

So I think what everyone is asking for at this point is more serial comms with FIFO's, and bigger, faster timers for sure.