Lpc2000

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
> Hi Ken,
> 
> you are correct, our APPS team is reading and posting to this forum. 
> You mentioned:
>  
> * 8-10 address lines
> * 4 chip selects
> * what width of data bus would you expect?
--> 16-bit data bus

> * would this bus be a mux bus (not so much supported in ARM)?
--> No, I believe that you can do this without having to MUX

> assuming a mux bus and only 8-bit data / 8-bit address, 
> * which 12 I/O would you like to be sacrificed for the bus 
interface?
--> As I said, sacrifice the ETM port...almost nobody uses it anyway.

> 
> Our "problem" is that we have too much functionality for the number 
> of pins. Your request is, do not add pins but add functionality!
--> Actually, my request is to reduce the pin count, and a little bit 
of functionality to get a reduced external bus interface with a 
reduced footprint.

> The more we multiplex functionality the more we get complaints along 
> the lines "why did you combine feature A with B and not A with C. 
> 
> * What would be the use of such a bus? Memory mapped I/O? 
--> Yes, a lot of projects my clients work on make extensive use of 
FPGA's with a memory mapped interface.

> 
> My guess is that a non-mux bus would be better suited but adds 
> immediately 8 pins for the bus.
--> Actually 16-pins for the data, and 10+ pins for address and 
control.

> 
> If we would offer a 80-pin or 100-pin device in TQFP or BGA would 
> that be something?
--> An 80-pin TQFP would be ok. However, an 64-pin PQFP is ideal

> 
> Always open to constructive suggestions but I need to know details 
> and what it would be used for, the applications. 
--> As I said, a low chip-count processor core with some modest means 
to do external memory mapped I/O for those FPGA's my clients use. 
Actually, an 8-bit data bus with 10-bits of address with chip selects 
and control would be ok also.

> 
> Thanks for expressing your desires here on this forum, we really try 
> to use all the feedback from here to improve our products according 
> to your, our customer needs.
> 
> btw, did you have a look at the LPC2138 / LPC2136? 
--> Yes...but groan, it did not have provisions for doing memory 
mapped I/O. Yeah....I know I can probably bit-diddle the memory mapped 
I/O and get the thing to work, but usually the HW designers make the 
memory mapped I/O for speed...and bit-diddling just defeats the 
purpose of having a mem-mapped I/O for speed. We also could have 
interfaced the FPGA using the SPI port...but that would have added 
more terms in the FPGA that the HW designers could not spare.