Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A

What's new with the new multi-context processor patent ?

http://www.freepatentsonline.com/5872985.html

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Rob Finch wrote:
> What's new with the new multi-context processor patent ?
>
> http://www.freepatentsonline.com/5872985.html

It's a US patent; it doesn't have to have anything new in it. This is
the patent office that has issued 20-odd patents on perpetual motion
machines.

PD
To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

--- In f...@yahoogroups.com, Paul Davis wrote:
>
> Rob Finch wrote:
> > What's new with the new multi-context processor patent ?
> >
> > http://www.freepatentsonline.com/5872985.html
>
> It's a US patent; it doesn't have to have anything new in it. This is
> the patent office that has issued 20-odd patents on perpetual motion
> machines.
>
> PD

So who else has a CPU that runs multiple contexts (programs) through
the pipeline at the same time?
At least that's what it sounded like it was doing... whenever one
context stalls the other can run to keep the CPU doing something all
the time.



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Does he say he has that?
Or is he proposing?
Its sounds relatively abstract
but if he already implemented that - he's all made...

My idea is more along the programmers model of a cubic (6 interfaces to
every neighbouring program step)
multiprocessor, where many processors can execute on the cubespace running
datastreeams through the interfaces
what I'm suggesting is a way of looking the grafts in parallel linear memory
bitrange where any number of but never two neighbouring virtual cubes access
their linear memory in and out 'bitfaces'
reading them and writing them back after executing a number of cycles on
them
The program is the fusemap of the fpga that loans its 'processingtime' to
the virtual cube
The goal is a architecture fit for Finite Elements Modeling

lets look into implementing this folks!
On 11/8/06, James Diffendaffer wrote:
>
> --- In f...@yahoogroups.com, Paul Davis wrote:
> >
> > Rob Finch wrote:
> > > What's new with the new multi-context processor patent ?
> > >
> > > http://www.freepatentsonline.com/5872985.html
> >
> > It's a US patent; it doesn't have to have anything new in it. This is
> > the patent office that has issued 20-odd patents on perpetual motion
> > machines.
> >
> > PD
>
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
> To post a message, send it to: f...@yahoogroups.com
> To unsubscribe, send a blank message to:
> f...@yahoogroups.com
> Yahoo! Groups Links
>
--
-----
Tobias Gogolin
cel. (646) 124 32 82
skype: moontogo
messenger: u...@hotmail.com
[Non-text portions of this message have been removed]


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

James Diffendaffer wrote:

> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.

My life is too short to work out exactly what he was claiming, but it
does appear that the patent covers some form of multithreading (TLP,
thread-level parallelism). IBM started working on TLP in about 1968. H&P
(3rd edition) gives a brief description of the IBM RS64 III/Pulsar as an
example of TLP. This seems to date to about 1999, but H&P claim that the
transistorised TX-2 (1959) could also support multithreading. Intel has
supported multithreading since the Pentium 4, based on an earlier DEC
Alpha. Ask on comp.arch for a more definitive answer.

My 5-minute scan of the patent made me suspect that it was attempting to
claim something specific about the meaning of a 'context', because it
must have been obvious in 1995 that TLP wasn't new. But, as I said, it's
a US patent, so it hardly needs to reflect the state of the art.



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

----- Original Message -----
From: "Tobias Gogolin"
To:
Sent: Thursday, November 09, 2006 8:57 AM
Subject: Re: [fpga-cpu] Re: Multi-context processor
> Does he say he has that?
> Or is he proposing?
> Its sounds relatively abstract
> but if he already implemented that - he's all made...
>
> My idea is more along the programmers model of a cubic (6 interfaces to
> every neighbouring program step)
> multiprocessor, where many processors can execute on the cubespace running
> datastreeams through the interfaces
> what I'm suggesting is a way of looking the grafts in parallel linear
> memory
> bitrange where any number of but never two neighbouring virtual cubes
> access
> their linear memory in and out 'bitfaces'
> reading them and writing them back after executing a number of cycles on
> them
> The program is the fusemap of the fpga that loans its 'processingtime' to
> the virtual cube
> The goal is a architecture fit for Finite Elements Modeling
>
> lets look into implementing this folks!

I was developing transputer-based systems 25 years ago, and was thinking of
designing a very compact hypercube, using chip-on-board technology, which
could be extended to any arbitrary dimensionality. I helped someone port
some FEM software to one of my systems, running on a single transputer. I
don't know if he ever parallelised it.

Leon
--
Leon Heller, G1HSM
Suzuki SV1000S motorcycle
l...@bulldoghome.com
http://www.geocities.com/leon_heller


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Paul Davis wrote:
> but H&P claim that the
> transistorised TX-2 (1959) could also support multithreading.

The TX-2 hardware does support multiple threads (called "sequences"),
but not simultaneity. There is a priority system to arbitrate for use
of the processor.

The PPUs of the CDC 6600 were similar, in that a single physical
processor serviced ten threads in round-robin fashion (known as
a barrel processor).

More recent examples are the Ubicom IP3023 and IP5160
microprocessors, which support multiple threads with provision
for fixed time slices for "hard real time" threads, and round
robin with two priority levels for the remaining threads.
(Disclaimer: I am employed by Ubicom.)

Simultaneous Multi Threading (SMT) has only been offered on
relatively high-end microprocessors, including the DEC Alpha 21264
(unreleased), Intel Pentium 4, and IBM POWER5.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

I wrote:
> Simultaneous Multi Threading (SMT) has only been offered on
> relatively high-end microprocessors, including the DEC Alpha 21264
> (unreleased),

That's a typo. It was to be the 21464. The 21264 was released
but does not have SMT.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Eric Smith wrote:

> (Disclaimer: I am employed by Ubicom.)

You should fix your MX records on ubicom.com - www.ubicom.com is Ok.



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Eric Smith wrote:

> The TX-2 hardware does support multiple threads (called "sequences"),
> but not simultaneity. There is a priority system to arbitrate for use
> of the processor.
>
> The PPUs of the CDC 6600 were similar, in that a single physical
> processor serviced ten threads in round-robin fashion (known as
> a barrel processor).
>
> More recent examples are the Ubicom IP3023 and IP5160
> microprocessors, which support multiple threads with provision
> for fixed time slices for "hard real time" threads, and round
> robin with two priority levels for the remaining threads.
> (Disclaimer: I am employed by Ubicom.)

That reminds me of another example - the Transputer (1982/3?), which had
a more sophisticated (of course, it was nearly 20 years later)
scheduler. This carried on executing a thread until it blocked on an I/O
operation. Actually, perhaps it was less sophisticated - my recollection
is that it was difficult to write code because there was no pre-emptive
scheduling, and you had to manually put in instructions to force a swap.



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Ah, the momories.

I worked with Transputers - I worte an OS for high speed data gathering and control for an automotive application.

The high priority processes would execute until they blocked on IO (channel coms, timer and such). I am not sure how they ordered the high priority processes. The low priority processes would execute if there were no high priority processes able to execute, for a time slice until they blocked. The time slice was round robin scheduled.

In our system, the OS was built from high priorirty processes and the applications ran in one low priority process. We had our own deadline scheduler written in asm within the one low priority process. Took us more effort in getting the info from Inmos than it did to write the scheduler.

Anyway, I guess the transputer was multi-context but only ran one context at a time.

Fun times.
----- Original Message -----
From: Paul Davis
To: f...@yahoogroups.com
Sent: Friday, November 10, 2006 12:32 AM
Subject: Re: [fpga-cpu] Re: Multi-context processor
Eric Smith wrote:

> The TX-2 hardware does support multiple threads (called "sequences"),
> but not simultaneity. There is a priority system to arbitrate for use
> of the processor.
>
> The PPUs of the CDC 6600 were similar, in that a single physical
> processor serviced ten threads in round-robin fashion (known as
> a barrel processor).
>
> More recent examples are the Ubicom IP3023 and IP5160
> microprocessors, which support multiple threads with provision
> for fixed time slices for "hard real time" threads, and round
> robin with two priority levels for the remaining threads.
> (Disclaimer: I am employed by Ubicom.)

That reminds me of another example - the Transputer (1982/3?), which had
a more sophisticated (of course, it was nearly 20 years later)
scheduler. This carried on executing a thread until it blocked on an I/O
operation. Actually, perhaps it was less sophisticated - my recollection
is that it was difficult to write code because there was no pre-emptive
scheduling, and you had to manually put in instructions to force a swap.

[Non-text portions of this message have been removed]


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Hi gang! It's nice to see the old familiar faces, so to speak.

I thought the transputer was not multi-context, but rather only had a few
words (3?) of state in regs and the rest was in on-die SRAM, so context
switches were very fast. Perhaps its just a point of view thing.

The Sun Niagara CMP cores are multi-context and schedule the runnable
threads -- those not blocked on cache misses etc. -- a great latency
tolerance technique.

Other notable multi-context processors included the Xerox Alto, the Denelcor
HEP, the MicroUnity MediaProcessor, and the Tera MTA. The latter had 128
thread contexts per core for latency tolerance sans data caches.

I have designed several unpublished multi-context processors in FPGAs to
various degrees of "finished". BRAMs plus V4/V5 BRAM pipelined output
registers mean you can theoretically clock the BRAMs really quickly...
Multithreading is a promising way to get rid of result mux networks...

You should also check out John Jakson's work.

Cheers,
Jan.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Cray has recently announced the rebirth of the MTA, in the form of custom
AMD-socket-compatible 128-way multithreaded processors dropped into the
XT3's 3D torus interconnect:
http://www.cray.com/products/xmt/

With enough FPGA-based pin-compatible modules, maybe we could build our
own:
http://www.drccomputer.com/pages/modules.html
(yeah, right!)

-Jacob

On Tue, 14 Nov 2006, Jan Gray wrote:

> Hi gang! It's nice to see the old familiar faces, so to speak.
>
> I thought the transputer was not multi-context, but rather only had a few
> words (3?) of state in regs and the rest was in on-die SRAM, so context
> switches were very fast. Perhaps its just a point of view thing.
>
> The Sun Niagara CMP cores are multi-context and schedule the runnable
> threads -- those not blocked on cache misses etc. -- a great latency
> tolerance technique.
>
> Other notable multi-context processors included the Xerox Alto, the Denelcor
> HEP, the MicroUnity MediaProcessor, and the Tera MTA. The latter had 128
> thread contexts per core for latency tolerance sans data caches.
>
> I have designed several unpublished multi-context processors in FPGAs to
> various degrees of "finished". BRAMs plus V4/V5 BRAM pipelined output
> registers mean you can theoretically clock the BRAMs really quickly...
> Multithreading is a promising way to get rid of result mux networks...
>
> You should also check out John Jakson's work.
>
> Cheers,
> Jan.



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Jan Gray wrote:

> I thought the transputer was not multi-context, but rather only had a few
> words (3?) of state in regs and the rest was in on-die SRAM, so context
> switches were very fast. Perhaps its just a point of view thing.

It's 16 years since I looked at this, but I think it was microcoded and
relied on chains of process descriptors and contexts in RAM. So, yes,
it's a question of where you draw the boundaries. But, obviously not
simultaneous (but what is 'simultaneous' anyway? Again, depends on where
your boundaries are drawn).

> I have designed several unpublished multi-context processors in FPGAs to
> various degrees of "finished". BRAMs plus V4/V5 BRAM pipelined output
> registers mean you can theoretically clock the BRAMs really quickly...

How fast? I did some quick research on ASIC RAM cycle times recently to
try to get a ballpark max frequency figure for a new chip. I wanted
2.0ns or better, but could only get 3.0 or 2.5 in the stuff that I have
data on.

But, in an FPGA, the RAM cycle time is presumably not that important.
Aren't the carry chains going to kill you? Or something else?



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

> How fast? I did some quick research on ASIC RAM cycle times recently to
> try to get a ballpark max frequency figure for a new chip. I wanted
> 2.0ns or better, but could only get 3.0 or 2.5 in the stuff that I have
> data on.

> But, in an FPGA, the RAM cycle time is presumably not that important.
> Aren't the carry chains going to kill you? Or something else?

You can do over 300 MHz out of the new BRAMs with the output register
enabled. Other things get in the way up at those speeds.

As for slow adder carry chains, it is possible to ping pong two sets of
adders, each with A and B input registers clocked on altenate cycles, doing
two cycle adds at high speed. It's not area or power efficient, though.

Also interesting is to use the 2 port BRAM as a double clocked
1-cycle-latency 4 port BRAM. Put the multiple thread contexts (register
files) in there. You get 16 sets of 32 registers...

Jan.


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

On Wed, 15 Nov 2006 00:41:16 -0800 (PST), "Jacob Nelson"
said:
>
> With enough FPGA-based pin-compatible modules, maybe we could build our
> own:
> http://www.drccomputer.com/pages/modules.html
> (yeah, right!)
>
> -Jacob
>

Coincidentally, I happen to have one of those modules right in front of
me. Not got to grips with it yet, but the mechanical construction is a
work of art.

Neil


(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )

Isn't that HyperThreading from Intel does?

Nelson

> --- In f...@yahoogroups.com, Paul Davis wrote:
>>
>> Rob Finch wrote:
>> > What's new with the new multi-context processor patent ?
>> >
>> > http://www.freepatentsonline.com/5872985.html
>>
>> It's a US patent; it doesn't have to have anything new in it. This is
>> the patent office that has issued 20-odd patents on perpetual motion
>> machines.
>>
>> PD
>
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
>

To post a message, send it to: f...@yahoogroups.com
To unsubscribe, send a blank message to: f...@yahoogroups.com



(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )