The fact is, I am getting more clarity into the requirement with all the
valuable comments !
im yet to look at jtagwidget..

the "device" intended, must be low cost : just a little more than a wiggler.

ease of use and robustness is important : if it runs off the usb power all
the more better !

finally it must support an entire family of devices with same debug
interface like arm7 series or arm9series  with 14pin or 20 pin etc

the "device" will have highlevel protocol which will translate a single
message into a a set of JTAG commands. that is not simply a data redirector.

i suppose many commercial implementations already do this, but..at low
cost..?

Kind Regards,
Ravishankar

PS: henceforth i have answer from another id...






"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
news:f62a5e$ed9$1@aioe.org...
> "GMM50" <gfm5050@gmail.com> skrev i meddelandet
> news:1183043362.233572.95280@c77g2000hse.googlegroups.com...
> > Altera NIOS with external FLASH and RAM will meet your requirements.
> >
> > George
> >
> >
> And is also going to more expensive, use more power etc.
> Does the Altera FPGAs have a High Speed USB interface?
> Was not aware of that!
>
> -- 
> Best Regards,
> Ulf Samuelsson
> This is intended to be my personal opinion which may,
> or may not be shared by my employer Atmel Nordic AB
>
>
>

"GMM50" <gfm5050@gmail.com> skrev i meddelandet
news:1183043362.233572.95280@c77g2000hse.googlegroups.com...
> Altera NIOS with external FLASH and RAM will meet your requirements.
>
> George
>
>
And is also going to more expensive, use more power etc.
Does the Altera FPGAs have a High Speed USB interface?
Was not aware of that!

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Altera NIOS with external FLASH and RAM will meet your requirements.

George

linnix wrote:
> On Jun 27, 5:00 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>
>>Since you are targeting JTAG, I'd suggest a simple Compression wrapper
>>on the USB link. The JTAG clock data has to be uncompressed, but
>>you can stream the USB data compressed, and that will remove any USB
>>bottleneck. - and it is the long datastreams that will benefit the most
>>from compression.
> 
> 
> It's not always so simple.  I have an ARM chip with a slow Jtag/debug
> wire.  Fast USB datastreams would overrun the ARM state machine.  I
> have to slow down the USB  side just to avoid overrunning the ARM
> chip.

  Of course, I'd expect any half-decent implementation to allow control
of the JTAG clock speed, and to have handshakes so that any JTAG clock 
speed was supported.
  A smarter system might even allow block-setable JTAG speeds, and
even a CPLD to fan-out the JTAG, so that systems might have a FAST and
SLOW jtag branches.

Mostly I was focusing on getting the highest possible streaming speed,
on a std system. Once you have that, it's pretty trivial to slow it down
later :)

-jg

On Jun 27, 5:00 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Ulf Samuelsson wrote:
> > "Ravishankar S" <ravishanka...@in.bosch.com> skrev i meddelandet
> >news:f5tibc$9fb$1@news4.fe.internet.bosch.com...
>
> >>thanks group, once again for the hints:
>
> >>that narrows down my search, since there are a huge number of
> >>microcontrollers out there.
>
> >>linux: now it seems overkill for the application. that's now for sure..
>
> >>AP7000 is not suitable: it has way too many peripherals..and its intended
> >>for multimedia low-power apps, but AVR32UC - microcontrollers seems to be
> >>a
> >>perfect fit. Im yet to look at the ST micro.
>
> > If you want high speed USB (480 Mbps), your selection is limited.
> > If you accept Full Speed USB (12 Mbps), then your next
> > selection criteria should be high speed DMA driven synchronous
> > serial peripherals.
>
> > The Atmel synch serial port peripherals generally run as fast as the CPU
> > core.
>
> Since you are targeting JTAG, I'd suggest a simple Compression wrapper
> on the USB link. The JTAG clock data has to be uncompressed, but
> you can stream the USB data compressed, and that will remove any USB
> bottleneck. - and it is the long datastreams that will benefit the most
> from compression.

It's not always so simple.  I have an ARM chip with a slow Jtag/debug
wire.  Fast USB datastreams would overrun the ARM state machine.  I
have to slow down the USB  side just to avoid overrunning the ARM
chip.

>
> So, target a device with good DMA into largish RAM blocks, and with the
> fastest possible SPI CLK speeds.
> USB -> DMA -> Packed RAM
> PackedRam => CPU Unpack => UnpackedRAM
> UnpackedRAM -> DMA -> SPI/SSC
>
> Ulf can probably help with the details :)
>
> -jg

Ulf Samuelsson wrote:
> "Ravishankar S" <ravishankar.s@in.bosch.com> skrev i meddelandet 
> news:f5tibc$9fb$1@news4.fe.internet.bosch.com...
> 
>>thanks group, once again for the hints:
>>
>>that narrows down my search, since there are a huge number of
>>microcontrollers out there.
>>
>>linux: now it seems overkill for the application. that's now for sure..
>>
>>AP7000 is not suitable: it has way too many peripherals..and its intended
>>for multimedia low-power apps, but AVR32UC - microcontrollers seems to be 
>>a
>>perfect fit. Im yet to look at the ST micro.
> 
> 
> If you want high speed USB (480 Mbps), your selection is limited.
> If you accept Full Speed USB (12 Mbps), then your next
> selection criteria should be high speed DMA driven synchronous
> serial peripherals.
> 
> The Atmel synch serial port peripherals generally run as fast as the CPU 
> core.

Since you are targeting JTAG, I'd suggest a simple Compression wrapper 
on the USB link. The JTAG clock data has to be uncompressed, but
you can stream the USB data compressed, and that will remove any USB 
bottleneck. - and it is the long datastreams that will benefit the most
from compression.

So, target a device with good DMA into largish RAM blocks, and with the 
fastest possible SPI CLK speeds.
USB -> DMA -> Packed RAM
PackedRam => CPU Unpack => UnpackedRAM
UnpackedRAM -> DMA -> SPI/SSC

Ulf can probably help with the details :)

-jg

On Tue, 26 Jun 2007 17:11:31 +0530, "Ravishankar S"
<ravishankar.s@in.bosch.com> wrote:

>Intended application:
>The application is simple debug device which provides a better performance
>and ease of use than Wiggler.  I suppose a microcontroller with built in
>support for configurable I/O should help here.

We built ours
  http://www.mpeforth.com/jtagwidget.htm
using a Philips/NXP LPC2106. Now, we would probably have
started with an LPC2148 or 2368/78 or ST's STR912xxx. No
need for Linux at all.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

> AP7000 is not suitable: it has way too many peripherals..and its intended
> for multimedia low-power apps, but AVR32UC - microcontrollers seems to be 
> a
> perfect fit. Im yet to look at the ST micro.

Note that the AP7000 series has high-speed (480 mbps) USB, whereas the UC3 
series has only full-speed (12 mbps) USB.

Leo Havm�ller. 

"Ravishankar S" <ravishankar.s@in.bosch.com> skrev i meddelandet 
news:f5tibc$9fb$1@news4.fe.internet.bosch.com...
> thanks group, once again for the hints:
>
> that narrows down my search, since there are a huge number of
> microcontrollers out there.
>
> linux: now it seems overkill for the application. that's now for sure..
>
> AP7000 is not suitable: it has way too many peripherals..and its intended
> for multimedia low-power apps, but AVR32UC - microcontrollers seems to be 
> a
> perfect fit. Im yet to look at the ST micro.

If you want high speed USB (480 Mbps), your selection is limited.
If you accept Full Speed USB (12 Mbps), then your next
selection criteria should be high speed DMA driven synchronous
serial peripherals.

The Atmel synch serial port peripherals generally run as fast as the CPU 
core.

> The configurable I/O pins are important since it will deal with JTAG pins.
>
> Also, i think the trend is towards a single chip solution: look at SoC's. 
> it
> may be good from learning point to interface external devices, but for
> prototying its better to have everything on chip. It is also good from EMI
> perspective (Automotive).
>
>
> Kind Regards,
> Ravishankar



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

thanks group, once again for the hints:

that narrows down my search, since there are a huge number of
microcontrollers out there.

linux: now it seems overkill for the application. that's now for sure..

AP7000 is not suitable: it has way too many peripherals..and its intended
for multimedia low-power apps, but AVR32UC - microcontrollers seems to be a
perfect fit. Im yet to look at the ST micro.

The configurable I/O pins are important since it will deal with JTAG pins.

Also, i think the trend is towards a single chip solution: look at SoC's. it
may be good from learning point to interface external devices, but for
prototying its better to have everything on chip. It is also good from EMI
perspective (Automotive).


Kind Regards,
Ravishankar

"PeteS" <axkz70@dsl.pipex.com> wrote in message
news:jfKdnZV6BI6IwBzbnZ2dnUVZ8vmdnZ2d@pipex.net...
> Ravishankar S wrote:
> > Hello group,
> >
> > Im looking for a controller which has the following I/O (and nothing
else)
> >
> > USB 2.0
> > 100Mpps Ethernet
> > A lot of (40) configurable GPIO pins
> > A powerful processing core (> 40 Mhz) which can support RTOS/embedded
Linux.
> > 128K -  512K - 1 MB NOR Flash
> > 16 K - 32- 64K RAM
> >
> > and no other I/O device (except possibly the  venerable old RS-232
serial
> > interface)
> >
> > Searching for oneis tedious. Looking first if there is ready reckoner by
> > anyone..?
> >
> > Is an FPGA more suitable in case there is no microcontroller with such
> > tailored requirements..?
> >
> > Kind Regards,
> > Ravishankar
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> Tedious it may be be, but it is a required learning challenge for the
> designer. If you don't want tedious on occasion, you chose the wrong
> line of work ;)
>
> That said, there's nothing wrong with asking for suggestions, but
> ultimately you will have to choose; and unless you have been through the
> tedium of locating and choosing a processor/controller you will be ill
> equipped for the task.
>
> Cheers
>
> PeteS