Our needs are:
1. We really need full compatibility with 5V, if possible - especially for industrial stuff. The ez80F91 claimed to have 5V tolerant pins, which was completely bogus. The chip needs to play well with 5V parts, if not run on 5V. Every pin.

2. Lots more memory. Right now we add 512k RAM and 4MB flash, doubled as to provide backup memory in case the primary fails. I would vote for a CPU that is designed for this from the get-go.

3. Lots of UART / SPI / I2C with at least 512 byte buffers for both Xmit and Receive. Right now we have to do this by hanging I2C uarts on the chip, but it sure would be nice to have at least 1 or two more of everything. Like some of the ARM's: 4 Uarts, 2SPI, 2 I2C.

4. Give us a very deterministic interupt system - In other words, when that int hits, I want to know that we'll be in the interuppt routine in precisely x clock cycles. Not a range of possible clock cycles, but an exact number.

5. As Jim said, faster clock would be good. But NOT if that means a reduction of reliability.

6. Think about a product that has to run 24/7/365 for 25 years without failure, and design a controller for that. Assume that tech support calls cost 100X what the product costs. Assume the product is going to Mars. Think that's silly?? Try having your products running on an oil platform in the Gulf of Mexico, and a helicopter flight + a tech to go out and replace a circuit board runs about $75k~100k. The PC board costs $1k. Do the math. That's what I deal with every day.

7. You don't get to cover up problems with an Errata sheet, or expect your customers to find every problem for you. That's Zilog's job, as much as practical.

8. Open source stack that is simple yet robust - it doesn't have to have every bell and whistle. It just has to work, solidly. You guys build the silicon and give us an IDE and some sample code. We'll take it from there. One of the things Zilog missed when they went away from ZTP 1.34 is they were trying to follow the crowd and add FTP, file managers, etc. The best thing about the simpler form of the stack is that you can offer a web-based GUI that is fairly hacker-proof, and is perfect for a network-enable appliance. In other words there is NO FTP service to hack into - and the html pages are rolled up into C code. The Zilog stack has another advantage: it boots nearly instantly, and is faster and cleaner than most embedded Linux systems - plus it doesn't take all afternoon to compile like some of the ARM / Cortex CPU's we've seen.

I guess in short my request is to go for reliablity, operation in harsh environments, and reliability. Oh, and did I say reliability??

I would vote for this also: 8 Bits is really OK for a lot of apps. I seen a lot of companies go under spending huge sums of money on 32-bit dev systems, and its really not that necessary in every case.

John Anderson wrote:

2. Lots more memory. Right now we add 512k RAM and 4MB flash, doubled as to provide backup memory in case the primary fails. I would vote for a CPU that is designed for this from the get-go.

5. As Jim said, faster clock would be good. But NOT if that means a reduction of reliability.


The problem here, is more memory costs, and not everyone wants maximum memory...
Hence my suggestion to support Execute from Quad SPI.

Just to clarify, the clock speed I mentioned, was on the QuadSPI, not the CPU core.
The CPU could stay ~ 50MHz core speed. (which is mostly Flash dictated).
Finer time granularity on timer and SPI should not affect reliability.

I see this mentioned re the new NXP 1800 : The micro can also execute code directly from the SPI flash albeit at 40 Mbyte/s transfer rates. - so this is coming. You would still have faster jumps in local FLASH, but keep that area for important code.


3. Lots of UART / SPI / I2C with at least 512 byte buffers for both Xmit and Receive. Right now we have to do this by hanging I2C uarts on the chip, but it sure would be nice to have at least 1 or two more of everything. Like some of the ARM's: 4 Uarts, 2SPI, 2 I2C.


Those are large buffers! That gets costly in chip area, if they are dedicated, but perhaps a shared memory area, that supported both FIFO and quasi-dual port memory would mean the memory is not lost to some users, and allows more flexible size choices ?


4. Give us a very deterministic interrupt system - In other words, when that int hits, I want to know that we'll be in the interrupt routine in precisely x clock cycles. Not a range of possible clock cycles, but an exact number.


Some chips are starting to do this. ( I think the M0?) - but not so easy to retrofit.
Simplest might be a tiny monostable timer, that starts on Pin/Event, and delays the entry as needed on faster opcodes ?.
{Small, and safely backward compatible.}

I think this deterministic need, is also the thrust behind dual-cores and multiple-threaded cores.

RE: UART buffers: That's just my wish list <Grin>. 64 byte or 128 byte buffers are Ok if we can get them, and that's fairly common on the external UARTS. We really want to get rid of the external UARTS if we can. But we're still running out of buffer space on occasion - Bigger is better. It is absolutely critical that we don't have a buffer over-run, and we're not always able to grab chars from four different UARTS fast enough to store in SRAM buffers, and that's why hardware buffer would be so helpful.

RE: Clock speed. If we can have a faster clock for like what you describe for SPI flash etc. That brings to mind another need: having a fine-grain timer (or two or three) with perhaps a PLL-boosted clock would be very handy for the apps we have. We do a lot of work processing GPS PPS signals, and in our products everything is synced to the true GPS second, so we tend to have bursts of extreme activity right around once per second. Some of the processing is offloaded onto a separate processor, but it would be nice to see new capabilities in an ez80F91-like chip.

adding an update to SPI SRAM, this from Cypress
Cypress is launching a new second generation serial nvSRAM in Q3’10. This device, available in densities from 64Kbit to 2Mbit, will support both SPI and I2C interfaces. Some of the key features of the product :

· Low active and standby current
· New deep sleep mode
· 40MHz and 104MHz SPI interface
· Upto 3.4MHz I2C interface
· 1.8V IO interface
· Standard SOIC8 package
· Integrated RTC
· Multiple voltage options
· And much more.

which adds to the OnSemi/Microchip SPI SRAM points of 32KB.

Cypress do not explicitly mention QuadSPI, but the 104MHz is a QuadSPI speed point.

These are nvSRAM, so have a price premium, but do show where the market is heading.

This would mean multiple QuadSPI ports make sense, and allow easy expansion of both Code, and Data.
HW that allowed Execute from SPI, and some FIFO/DP-RAM method, would also allow easy SW access of the slightly slower off chip Data memory.

John Anderson wrote:

RE: Clock speed. If we can have a faster clock for like what you describe for SPI flash etc. That brings to mind another need: having a fine-grain timer (or two or three) with perhaps a PLL-boosted clock would be very handy for the apps we have. We do a lot of work processing GPS PPS signals, and in our products everything is synced to the true GPS second, so we tend to have bursts of extreme activity right around once per second. Some of the processing is offloaded onto a separate processor, but it would be nice to see new capabilities in an ez80F91-like chip.

Can you clarify how a fine gran timer helps here ? - if you are launching software, how does timing finer than opcodes help ?

I've seen them targeting PWM generation, where they allow fine control of higher switching speeds.

Being able to capture time to a fine granularity, would also be great for external monitor/sensor interfaces, but that is less common.
(it would also allow precise calibration against things like GPS pps)
viz a ~208MHz PLL (2x 104MHz SPI) to 32 bit timer capture, plus a 32 bit compare, would allow slice/dice of that second, into very precise chunks.

Without going into extreme detail - That's exactly what we do - processing GPS PPS timestamps, and we really do need something on the order of say a few tens of nanosec or better. Our GPS receivers are say within+- 10nSec, and we need to interpolate timestamps down to max practical resolution. The GPS receivers give use the PPS signal, of course, as well as a nanosec correction. Then we take that info and tune our master backup oscillators to be inline with the GPS second, to some part in 10E-13, and that removes the GPS jitter. So we're timing lots of events in the system, and everything in the system has a backup signal. We're not using the ez80F91 to generate the timing pulses directly, but its in control of the oscillators, dividers and interpolators that make the thing work.

Like I said, today I can use a 100Mhz, 32 bit timer because that's exactly what we've had to build in external circuitry - and we are timing events from a few tens of nanoseconds to say 10~15 seconds apart. And if I were designing a chip I could easily use at least 2 if not 4 of these, and being able to combine two or more into a single 64 bit unit would be very useful also. Running these from an external 200~250Mhz source would be a plus, but not sure if this is possible on the MCU silicon.

I'm asking for say 4 UARTS because that's what were using today - managing 2 or 3 GPS receivers, handling external I2C UARTS, and external processors via SPI. We always can use an extra UART / SPI / I2C. 2 UARTS ain't enough these days. And if we can get to 400 to 1Mbaud on the UARTS thats even better yet - like the Cortex-M0 designs.

For our designs we'd still use the parallel RAM / Flash memory at zero wait states, because we interface with other circuitry in a DMA arrangement that is already parallel.

If it is planned to use external faster memory on the SPI bus, I would suggest that it be its own dedicated peripheral.

Otherwise we'll take all the timers, memory and serial comms you can shoehorn in.

We don't expect EVERYTHING we need to be on one chip, but it should be designed so its easy to add on as required. For instance say 4 or 8 more \CS lines would be handy. Or the idea of a dedicated SPI line for external memory is a good one. Or perhaps a dedicated I2C / SPI port for adding extra UARTS, etc.

Just feedback from the trenches.