ST-20: what is it?
Jakob Engblom
actually is? Information is pretty scarce on the web, but it seems to
be something they got when acquiring Inmos, so it could be a late
relative of the transputer. A manual indicated that it has only six
registers and works in a stack configuration with three of them, which
I think I recognize from the transputer programming model. Anyone with
better data on this processor? Especially its history and current use?
J.C.Hi...@lboro.ac.uk
It is indeed the transputer. I think the ST20 was an integer-only variant
initially available in the ST20450 but intended mainly as a core for set-
top box chips.
Given the way the ST20 line has disappeared from the ST website I guess
the entire product line was dropped. If memory serves the transputer line
(except for the core) was given a last shipment date of the end of 1999.
A random reference: http://wotug.kent.ac.uk/parallel/transputer/
Julian
Jakob Engblom
> Given the way the ST20 line has disappeared from the ST website I guess
> the entire product line was dropped. If memory serves the transputer line
> (except for the core) was given a last shipment date of the end of 1999.
But funnliy, there are press releases from 2001 announcing new
integrated chips called things like the STi5516 containing the ST20
core. So it might not be completely dead yet.
john jakson
Look again in comp.arch.transputer, there is still a little activity
left and Ram probably has the docs on his site. The last I looked, I
believe the poor thing had all but 1 link cut off having been replaced
by traditional serial ports more familiar to the punters. Not only
that, all the amazing terminology that explained why the Transputer
was so revolutionary was stripped out of the last docs reducing it to
something unrecognizable from the better days.
All is not lost, I am working on something myself for FPGA, it will be
awhile though.
Richard Ingram
Nope still in almost all STB/DVD chipsets, press cutting for Omega STi5517
appeared March 25th, 2003. With the following snippet "the ST20 CPU speed has
been increased to 180MHz." And the following note at the bottem "An
enhanced ST20 32-bit RISC CPU with a 180MHz clock, 8Kbytes of instruction
cache, 8Kbytes of data cache and 8Kbytes of embedded SRAM."
Basically only in SoC or ASIC's now.
Richard.
Richard Ingram
Download this PDF http://us.st.com/stonline/books/pdf/docs/4942.pdf it has
sections on the ST20CPU.
Richard.
John Dyer
wrote:
Its very much alive and well, more than 7 million were made last year,
with nearly all of them winding up in Satellite pay tv set-top boxes.
It is based on the T450 transputer, which was aquired by SGS-Thompson
when they took over Inmos several years ago. It still has the same
hardware/software model as the transputer, but its used as a
stand-alone RISC processor. ST have enhanced the core by ramping
up clock speed, adding cache and several DMA channels to make
it quite a high performing core.
More recently it has been integrated into a single vlsi chip along
with the mpeg2 decoder and other elements of a digital tv receiver
eg STi5510, 5512, 5516, 5518 etc however its starting to struggle
with the demands of "middleware" such a "opentv".
The same chipsets are also used in DVD players.
With the move to set-top boxes becoming more than just tv decoders
ie 3d etc ST have signed an agreement with Hitachi to make the
SH4 SuperH risc processor, now called the ST40, and which we
may see being used in boxes in the near future!
Brian Drummond
>ja...@virtutech.com (Jakob Engblom) wrote in message news:<80c81770.03052...@posting.google.com>...
>> >
>> > Given the way the ST20 line has disappeared from the ST website I guess
>> > the entire product line was dropped. If memory serves the transputer line
>> > (except for the core) was given a last shipment date of the end of 1999.
>>
>> But funnliy, there are press releases from 2001 announcing new
>> integrated chips called things like the STi5516 containing the ST20
>> core. So it might not be completely dead yet.
>
>Look again in comp.arch.transputer, there is still a little activity
>left and Ram probably has the docs on his site.
<blink> there's a comp.arch.transputer?
Time to refresh my newsgroups list...
- Brian
Dave Hansen
<br...@shapes.demon.co.uk> wrote:
[...]
><blink> there's a comp.arch.transputer?
Not last time I checked. Perhaps he meant comp.sys.transputer?
Regards,
-=Dave
--
Change is inevitable, progress is not.
Rupert Pigott
news:3ed5e9c7...@news.xtra.co.nz...
> On 28 May 2003 04:12:06 -0700, ja...@virtutech.com (Jakob Engblom)
> wrote:
>
> >Does anyone know what the ST Microelectronics ST20 processor/core
> >actually is? Information is pretty scarce on the web, but it seems to
> >be something they got when acquiring Inmos, so it could be a late
> >relative of the transputer. A manual indicated that it has only six
> >registers and works in a stack configuration with three of them, which
> >I think I recognize from the transputer programming model. Anyone with
> >better data on this processor? Especially its history and current use?
>
>
> Its very much alive and well, more than 7 million were made last year,
> with nearly all of them winding up in Satellite pay tv set-top boxes.
>
> It is based on the T450 transputer, which was aquired by SGS-Thompson
> when they took over Inmos several years ago. It still has the same
Corr blimey, that was '92 ! The thick end of Several. :)
Cheers,
Rupert
Bill Giovino
event think about programming it in assembly. It sells mainly in set-top
boxes, mostly in captive applications.
If you want to learn more about the transputer, ask ST for an old INMOS
application note called "Lies, Damned Lies, and Benchmarks"
- Bill Giovino
http://Microcontroller.com
"Jakob Engblom" <ja...@virtutech.com> wrote in message
news:80c81770.03052...@posting.google.com...
Rupert Pigott
news:2Mecnb2M059...@comcast.com...
> Yep, it's a Transputer which is a stack-based (what???) architecture.
Don't
> event think about programming it in assembly. It sells mainly in set-top
LOL, the HLL gestapo still 'trollin around ? Personally
I *liked* transputer assembly, found it very easy after
the "no, you don't really have registers, you have a
stack" head adjustment.
> boxes, mostly in captive applications.
> If you want to learn more about the transputer, ask ST for an old INMOS
> application note called "Lies, Damned Lies, and Benchmarks"
That rings a bell. Can't remember for the life of me
how it went though.
Cheers,
Rupert
john jakson
> event think about programming it in assembly. It sells mainly in set-top
> boxes, mostly in captive applications.
>
> If you want to learn more about the transputer, ask ST for an old INMOS
> application note called "Lies, Damned Lies, and Benchmarks"
>
> - Bill Giovino
> http://Microcontroller.com
>
>
>
Would that be at
http://129.215.101.90:1001/publications/PICTworkingpapers/WP13.pdf
Jan C. Vorbrüggen
> I *liked* transputer assembly, found it very easy after
> the "no, you don't really have registers, you have a
> stack" head adjustment.
Yup, same here. Doing instruction scheduling in your head while taking
care of the stack dependencies was fun.
Jan
Bill Giovino
> "Bill Giovino" wrote...
> > Yep, it's a Transputer which is a stack-based (what???) architecture.
> > Don't event think about programming it in assembly. It sells mainly in
set-top
>
> LOL, the HLL gestapo still 'trollin around ? Personally
> I *liked* transputer assembly, found it very easy after
> the "no, you don't really have registers, you have a
> stack" head adjustment.
Eh, as for me, I prefer assembly, but back when I was with ST as an FAE for
this stuff I didn't want to be put in a position where I had to debug
someone's stack-based code.
It was actually part of a much larger plan, you see, which included me
getting home every day by 6:00pm...
CBFalconer
Writing stack based code for any machine is a matter of mindset.
If you resolve the idea that routines are to be re-entrant, it is
necessary for any machine. It helps to have an assembler that can
keep track of the stack level for you, and to write a few macros.
The result will remind you of Forth, except there is only one
stack.
One useful macro is "psh(reg) = push reg; lvl = lvl + 1" and the
corresponding pop. Now you can do things like initializing local
variables with:
mvi reg, 0
psh reg;
v1 set lvl
psh reg
v2 set lvl
....
and stack level checks such as
if lvl ne mark
.error stack fouled
endif
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Bernd Paysan
> Writing stack based code for any machine is a matter of mindset.
> If you resolve the idea that routines are to be re-entrant, it is
> necessary for any machine. It helps to have an assembler that can
> keep track of the stack level for you, and to write a few macros.
> The result will remind you of Forth, except there is only one
> stack.
On the transputer, there are several things that make live easy: First, the
stack is only three elements deep, no deep shuffling possible. Second, the
stack has to be considdered empty at branches (task switches are allowed at
branches, and the task switcher doesn't save the stack). And third, there's
a workspace pointer, which can be used like a register bank.
On the other hand, I don't understand what's difficult with stacks. I
learned Forth in a few days when I was 16, and even my first program made
excessive use of the stack (from what I considder sane today).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
CBFalconer
>
... snip ...
>
> On the other hand, I don't understand what's difficult with
> stacks. I learned Forth in a few days when I was 16, and even
> my first program made excessive use of the stack (from what I
> considder sane today).
PICs are another story, because they don't have the capability,
but my 8080, z80, x86 assembly code tends to be very easy to use,
because I tend to write with all parameters passed in registers
and outputs defined as registers, with no other registers altered,
and the net stack undisturbed in general. There will often be a
good deal of pushing and popping within the routine. For the x86
I greatly miss the xthl (or EX (sp),hl) instruction. As an
example, code like the following is common:
;
; cr/lf to file bx^, set al to lf. Carry for error.
crlf: mov al,cr
call couta
jc retn
mov al,lf
; " "
; (a) to file bx^ when ready, Carry for error
couta: push ax
couta1: call fready
jz couta1
pop ax
jc retn
; " "
fputa: etc etc.
and there may be a whole collection of things that index on bx to
access the appropriate file, that being the point where things
become non re-entrant. Things like arithmetic packages remain
pure and re-entrant.
Of course I haven't written any great amount of assembly code for
these things in the past dozen years. :-) (Maybe 2 dozen).