Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #14934 > unrolled thread

GA144 Instruction Timing

Back to article view | Back to comp.lang.forth

Contents

  GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-11 18:54 -0400
    Re: GA144 Instruction Timing Paul Rubin <no.email@nospam.invalid> - 2012-08-11 17:40 -0700
      Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-12 19:00 -0400
        Re: GA144 Instruction Timing johnmdrake@gmail.com - 2012-08-14 10:17 -0700
          Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-15 18:57 -0400
    Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 07:11 -0700
      Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 10:33 -0400
        Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 12:46 -0700
          Re: GA144 Instruction Timing Jason Damisch <jasondamisch@yahoo.com> - 2012-08-22 13:10 -0700
            Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 18:10 -0400
            Re: GA144 Instruction Timing Paul Rubin <no.email@nospam.invalid> - 2012-08-23 00:03 -0700
              Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-23 19:57 -0400
                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-24 16:29 +0200
                  Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-27 18:33 -0400
                    Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 02:45 +0200
                      Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-27 21:41 -0400
                        Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 22:07 +0200
                          Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-28 18:25 -0400
                            Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-29 01:41 +0200
                              Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-29 16:43 -0400
                                Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:13 +0200
                                  Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-30 15:07 -0400
                                    Re: GA144 Instruction Timing Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 23:11 +0200
                                      Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-09-01 15:15 -0400
          Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-08-22 18:05 -0400
            Re: GA144 Instruction Timing RR <freedomspyder@gmail.com> - 2012-08-22 15:46 -0700
    Re: GA144 Instruction Timing rickman <gnuarm@gmail.com> - 2012-09-02 17:21 -0400

Page 2 of 2 — ← Prev page 1 [2]

#15254

rickman wrote:
>> For ALU and stack instructions, it is.
> 
> Ok, what you are calling a "ring oscillator" is a set of gates
> (inverters) with a delay matched to the logic path so that the clock
> delay is assured to be longer than the logic path by some margin.  In
> particular, there are a number of logic paths with a number of
> matching delay paths and the appropriate delay determines the timing
> of the CPU instruction cycle.

I don't see that many.  There is the basic operation ring oscillator, 
there is a RAM/ROM ready signal which tells you when prefetching or 
memory IO is finished, and there is the sync handshake in the IO.  Plus 
the unext/next extra delay.  The CPU is async in the sense that these 
extra delays are waited for asynchronously, instead of e.g. a more 
classic design, where they would be wated for synchronously with the 
ring oscillator.

> The fact that the delay path feeds back onto itself forming a gated
> "oscilator" adds nothing to understanding the function of the circuit.
> The point is that there are a number of different delays matched to
> the logic operation performed.

Actually, all *logic* operations performed have the same delay.  Memory 
operations, control flow, and communication have a different delay.  
Which is usually true even for a conventional design - only that in a 
conventional design, the extra delay is counted in cycles, not in 
picoseconds.  That's because conventional oscillators can not be that 
easily started and stopped as ring oscillators.

> Indeed, performance goes to hell when the processor is stopped,
> perhaps all the way to zero MIPS.

You don't really understand.  Let's say you have two processes 
interlocked by this communication, and depending on the data they get, 
their timing differs - which is quite common if you have some IF clause 
in it.  So when you have a small buffer, the actual usage of both parts 
goes up.  When you have no buffer, it's more predictable, but because 
then, the slower part will always block the faster, it is also slower.

This probably hurts more when you have several nodes to write to - the 
F18s wait for the last reader to suspend for reading, before they can 
continue.

> Yes, I'm pretty sure processor performance
> goes to zero MIPS when the processor is stopped, waiting.  ;) 
> Actually I have tried to ask if there is timing overhead for this sync
> process.

The numbers given in the data sheet are apparently the minimum timing 
for these IO operations, which otherwise would block.

> Or maybe a better way to say it is, what is the "overlap"?  How much
> of the processor A write instruction has executed before and how much
> after
> processor B does its read?  Likewise how much of the processor B read
> instruction has executed before and after processor A does a write?

Yes, that would be nice to know.

> Oh, there are ways to read and write the port without waiting.

Yes?  That's not how I read the documentation.

> Again, you are assuming.  Do you know what the F18 uses?

No.  I'm making intelligent guesses based on how I would design this.  I 
would not design this without any memory, for the reasons mentioned 
before, but the essential circuit part, the wait/release logic, is a 
standard component even when you use a FIFO.

> How does this
> interact with the other registers in the F18?  How is the delay
> generated when the two are simultaneous?

I think you can guess the limitations from reading what happens to 
multiport reads and writes.  In the case of a multiport write (to 
several readers), all the readers must be suspended.  In the case of a 
multiport read (several writers to one reader), only one writer is 
allowed to write at a time - there's no conflict management either.

The multiport writer problem would go away with a FIFO depth one at each 
port (a single latch per bit).  You can also handle the multiport reader 
problem by having a priority (e.g. fetch up first, and the others in 
clockwise order).

The fact that this is a true synchronization point means there is a 
handshake between writer and reader, and that the writer presumes the 
handshake is done when he receives the first answer from one of the 
readers.  Given that Chuck makes things as simple as possible, this 
communication structure would be just the T outputs of the writer, going 
thru multiplexers to the T input of the reader.  The conditions that 
this works is that the reader must have successfully captured the data 
in his T register, before he allows the writer to proceed.

> I'm not at all sure your idea will even allow the circuit to work.
> There are at least three states, IDLE, WRITE and READ.  IDLE is self
> explanitory, WRITE is when the write has happened first and READ is
> when
> the READ has happened first.

No, this thing is a handshake between two nodes, not a state machine - 
you sort-of have these states, but they are implicit.  The two handshake 
signals are "I've something for you" and "Got the message".  Upon 
communication, the two parties wait for "I've something for you" 
(reader), and "Got the message" (writer), and the writer turns on his 
"I've something for you".  The reader only turns on his acknowledge when 
he proceeds operation (read completed), and let it stay until the writer 
deasserts his "I've got something for you".  This signal causes the 
writer to deassert the "I've something for you".

> I'm not going to design this circuit,
> but I expect it takes a bit of work to make sure it doesn't mess up
> with
> pulse overlap.

The two-way handshake itself can be proven to have no such problems.  
However, when you use clocked flip-flops to capture the handshake data 
from another clock domain, you have to make sure that meta-stability 
there isn't a problem (by allowing enough delay for it to settle).  If 
you stop your clock, and allow it only to restart if the signal is 
there, then you don't run into this problem.

A "check that port, and set a bit if there is something ready" operation 
is therefore more likely to go wrong than that complete handshake.

> Hand waving and talking about "basic principles"
> doesn't explain anything.

Oh man, I like to try to point you towards literature where you can read 
these things up.

I'm not drawing the circuit diagrams for you, especially since this is 
usenet, and only ASCII art is allowed.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#15278

On 8/29/2012 8:13 PM, Bernd Paysan wrote:
> rickman wrote:
>>> For ALU and stack instructions, it is.
>>
>> Ok, what you are calling a "ring oscillator" is a set of gates
>> (inverters) with a delay matched to the logic path so that the clock
>> delay is assured to be longer than the logic path by some margin.  In
>> particular, there are a number of logic paths with a number of
>> matching delay paths and the appropriate delay determines the timing
>> of the CPU instruction cycle.
>
> I don't see that many.  There is the basic operation ring oscillator,
> there is a RAM/ROM ready signal which tells you when prefetching or
> memory IO is finished, and there is the sync handshake in the IO.  Plus
> the unext/next extra delay.  The CPU is async in the sense that these
> extra delays are waited for asynchronously, instead of e.g. a more
> classic design, where they would be wated for synchronously with the
> ring oscillator.

We must be talking about different chips.  The GA144 typical instruction 
timings table lists six different instruction time groups not counting 
the prefetch time.  Even if there were only two instruction times, the 
point remains that the timing of the CPU is not controlled by an 
oscillator of any sort regardless of how you choose to name the control 
logic.


>> The fact that the delay path feeds back onto itself forming a gated
>> "oscilator" adds nothing to understanding the function of the circuit.
>> The point is that there are a number of different delays matched to
>> the logic operation performed.
>
> Actually, all *logic* operations performed have the same delay.  Memory
> operations, control flow, and communication have a different delay.
> Which is usually true even for a conventional design - only that in a
> conventional design, the extra delay is counted in cycles, not in
> picoseconds.  That's because conventional oscillators can not be that
> easily started and stopped as ring oscillators.

By "logic" I mean the logic of the computer, not the "logic" instructions.


>> Indeed, performance goes to hell when the processor is stopped,
>> perhaps all the way to zero MIPS.
>
> You don't really understand.  Let's say you have two processes
> interlocked by this communication, and depending on the data they get,
> their timing differs - which is quite common if you have some IF clause
> in it.  So when you have a small buffer, the actual usage of both parts
> goes up.  When you have no buffer, it's more predictable, but because
> then, the slower part will always block the faster, it is also slower.
>
> This probably hurts more when you have several nodes to write to - the
> F18s wait for the last reader to suspend for reading, before they can
> continue.

I don't understand what?  That you can't tell an attempt at humor?


>> Yes, I'm pretty sure processor performance
>> goes to zero MIPS when the processor is stopped, waiting.  ;)
>> Actually I have tried to ask if there is timing overhead for this sync
>> process.
>
> The numbers given in the data sheet are apparently the minimum timing
> for these IO operations, which otherwise would block.

They are the timing for the instructions.  The timings say nothing about 
blocking.  That is what I would like to understand, what happens when 
they are blocked, how the timing divides between before blocking and 
after blocking.


>> Or maybe a better way to say it is, what is the "overlap"?  How much
>> of the processor A write instruction has executed before and how much
>> after
>> processor B does its read?  Likewise how much of the processor B read
>> instruction has executed before and after processor A does a write?
>
> Yes, that would be nice to know.
>
>> Oh, there are ways to read and write the port without waiting.
>
> Yes?  That's not how I read the documentation.

I recommend that you read it again... and again... and again.  That is 
what I did.  It has a lot of subtleties.


>> Again, you are assuming.  Do you know what the F18 uses?
>
> No.  I'm making intelligent guesses based on how I would design this.  I
> would not design this without any memory, for the reasons mentioned
> before, but the essential circuit part, the wait/release logic, is a
> standard component even when you use a FIFO.

Adding a FIFO between processors assumes the processor is the critical 
resource.  One of the big assumptions in the design of this chip is that 
processors are cheap and MIPS are cheap.  Until you do a design with 
such a multiprocessor there is little point is speculating.


>> How does this
>> interact with the other registers in the F18?  How is the delay
>> generated when the two are simultaneous?
>
> I think you can guess the limitations from reading what happens to
> multiport reads and writes.

I'm not talking about limitations.  I'm asking about timing.


>> I'm not at all sure your idea will even allow the circuit to work.
>> There are at least three states, IDLE, WRITE and READ.  IDLE is self
>> explanitory, WRITE is when the write has happened first and READ is
>> when
>> the READ has happened first.
>
> No, this thing is a handshake between two nodes, not a state machine -
> you sort-of have these states, but they are implicit.  The two handshake
> signals are "I've something for you" and "Got the message".  Upon
> communication, the two parties wait for "I've something for you"
> (reader), and "Got the message" (writer), and the writer turns on his
> "I've something for you".  The reader only turns on his acknowledge when
> he proceeds operation (read completed), and let it stay until the writer
> deasserts his "I've got something for you".  This signal causes the
> writer to deassert the "I've something for you".

The states are IDLE, WRITE (waiting for read), READ (waiting for write). 
  What you are describing is a handshake with two signals and four 
states which encompass the three I've identified.  I still see potential 
issues if both handshakes occur a the same time.  Yes, I won't say it 
can't be done, I'm saying it has to be done right, just like any circuit.


>> I'm not going to design this circuit,
>> but I expect it takes a bit of work to make sure it doesn't mess up
>> with
>> pulse overlap.
>
> The two-way handshake itself can be proven to have no such problems.
> However, when you use clocked flip-flops to capture the handshake data
> from another clock domain, you have to make sure that meta-stability
> there isn't a problem (by allowing enough delay for it to settle).  If
> you stop your clock, and allow it only to restart if the signal is
> there, then you don't run into this problem.

I'd like to see that design.


> A "check that port, and set a bit if there is something ready" operation
> is therefore more likely to go wrong than that complete handshake.
>
>> Hand waving and talking about "basic principles"
>> doesn't explain anything.
>
> Oh man, I like to try to point you towards literature where you can read
> these things up.
>
> I'm not drawing the circuit diagrams for you, especially since this is
> usenet, and only ASCII art is allowed.
>

Ok.  Have fun.

Rick

[toc] | [prev] | [next] | [standalone]

#15281

rickman wrote:
> We must be talking about different chips.  The GA144 typical
> instruction timings table lists six different instruction time groups
> not counting
> the prefetch time.

The GA144 timing table lists "logic and stack operations" to have all 
the same timing.  And then, it lists timing for accesses to memory or 
communication ports (which are the same instructions, but they take 
different time), it lists unext/next, and it lists prefetch time, which 
is another memory access.

> Even if there were only two instruction times, the
> point remains that the timing of the CPU is not controlled by an
> oscillator of any sort regardless of how you choose to name the
> control logic.

Well, maybe it isn't.  The way it is described, I would implement it as 
ring oscillator matching the logic, and stop this oscillator each time I 
encounter one of these memory delays - which are the "separate" delay 
paths you mention.  But as you see with prefetch: That separate delay 
path is ignored as long as there are still instructions in the currently 
executed instruction bundle.

>> This probably hurts more when you have several nodes to write to -
>> the F18s wait for the last reader to suspend for reading, before they
>> can continue.
> 
> I don't understand what?  That you can't tell an attempt at humor?

This is actually not that funny.  The way the sync communication is made 
both has an impact on performance as well on correctness (essentially, 
you can't assume that a multi-reader or multi-writer program works if 
you don't meet the very strict design rules).

>>> Oh, there are ways to read and write the port without waiting.
>>
>> Yes?  That's not how I read the documentation.
> 
> I recommend that you read it again... and again... and again.  That is
> what I did.  It has a lot of subtleties.

I've better things to do...

>> I think you can guess the limitations from reading what happens to
>> multiport reads and writes.
> 
> I'm not talking about limitations.  I'm asking about timing.

But as you have written above, the documentation has many subtleties, 
and the limitations give you hints about how it is implemented.

> The states are IDLE, WRITE (waiting for read), READ (waiting for
> write).
>   What you are describing is a handshake with two signals and four
> states which encompass the three I've identified.

Yes, but "encompass" does not mean these states are actually directly 
encoded, or that these three are all possible states.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#15371

I got an email from Greg Bailey answering some of my questions and one 
that caught my eye was about the non-empty unext time.  An empty unext 
is in slot zero, in other words, a spin loop with no other instructions. 
  Non-empty would include other instructions putting the unext in a slot 
other than zero.  I was told the timing of this unext is "roughly" the 
same as the basic opcodes.

I rather puzzled by the use of the word "roughly".  Either it is 
controlled by the same timing path or it is controlled by a different 
timing path.  Either way I would expect it to be appropriately specified.

Rick


On 8/30/2012 5:11 PM, Bernd Paysan wrote:
> rickman wrote:
>> We must be talking about different chips.  The GA144 typical
>> instruction timings table lists six different instruction time groups
>> not counting
>> the prefetch time.
>
> The GA144 timing table lists "logic and stack operations" to have all
> the same timing.  And then, it lists timing for accesses to memory or
> communication ports (which are the same instructions, but they take
> different time), it lists unext/next, and it lists prefetch time, which
> is another memory access.
>
>> Even if there were only two instruction times, the
>> point remains that the timing of the CPU is not controlled by an
>> oscillator of any sort regardless of how you choose to name the
>> control logic.
>
> Well, maybe it isn't.  The way it is described, I would implement it as
> ring oscillator matching the logic, and stop this oscillator each time I
> encounter one of these memory delays - which are the "separate" delay
> paths you mention.  But as you see with prefetch: That separate delay
> path is ignored as long as there are still instructions in the currently
> executed instruction bundle.
>
>>> This probably hurts more when you have several nodes to write to -
>>> the F18s wait for the last reader to suspend for reading, before they
>>> can continue.
>>
>> I don't understand what?  That you can't tell an attempt at humor?
>
> This is actually not that funny.  The way the sync communication is made
> both has an impact on performance as well on correctness (essentially,
> you can't assume that a multi-reader or multi-writer program works if
> you don't meet the very strict design rules).
>
>>>> Oh, there are ways to read and write the port without waiting.
>>>
>>> Yes?  That's not how I read the documentation.
>>
>> I recommend that you read it again... and again... and again.  That is
>> what I did.  It has a lot of subtleties.
>
> I've better things to do...
>
>>> I think you can guess the limitations from reading what happens to
>>> multiport reads and writes.
>>
>> I'm not talking about limitations.  I'm asking about timing.
>
> But as you have written above, the documentation has many subtleties,
> and the limitations give you hints about how it is implemented.
>
>> The states are IDLE, WRITE (waiting for read), READ (waiting for
>> write).
>>    What you are describing is a handshake with two signals and four
>> states which encompass the three I've identified.
>
> Yes, but "encompass" does not mean these states are actually directly
> encoded, or that these three are all possible states.
>

[toc] | [prev] | [next] | [standalone]

#15109

On 8/22/2012 3:46 PM, RR wrote:
> Don't bite my head off. I was just posting the link, as I thought it was relative to your discussion.
>
> Chuck's 'stop watch' routine is interesting in and of itself.

Sorry, that was not my intended tone.  I was just analyzing the facts. 
I didn't mean to seem rude.

The point I was trying to make is that GA does not seem interested in 
making the chip useful for people.  That is why I was asking the 
questions about the conditions of the measurement, to show that much of 
the data available on the chip is not so useful, not to say I didn't 
appreciate your post.

My apologies.

Rick

[toc] | [prev] | [next] | [standalone]

#15111

> Sorry, that was not my intended tone.  I was just analyzing the facts. 
> 
> I didn't mean to seem rude.

no worries rick.. I was just being petulant, and responded childishly.

I'm also frustrated by the dribs and drabs of information coming from Greenarrays. This latest ethercode I linked to, has not even been released afaik.

[toc] | [prev] | [next] | [standalone]

#15401

On 8/11/2012 6:54 PM, rickman wrote:
> Anyone know the timing of a unext instruction when it is looping? I
> think it would just be 2.4 ns with no adder for the instruction fetch
> since there would be no instruction fetch.
>
> The data book talks about the "Empty micronext time" which seems to be
> the time for the unext instruction with no other code in the loop
> regardless of whether it loops or not. They also talk about an empty
> next time, but this is separate from the "non-empty next time" along
> with "jump time". I guess the time for the jump if the code falls
> through would be the same if it aborts the prefetch in all cases even if
> it could take advantage of prefetch.
>
> Funny, every time I look at this chip I learn something new about how it
> works. It would be nice if it were written out clearly enough that I
> didn't need so many passes through the manual.
>
> At least I feel like I am getting somewhere with it.
>
> Rick


I got what I think is the final reply from GreenArrays.  I asked for 
timing data that is not currently available in the data sheets and the 
response was, "there won't be a new model any time soon".

I suppose that if you consider the GA144 to be a software device then 
timing is not really important.  Lots of high end CPUs are not very 
deterministic.  But if you want to use it to control hardware with any 
speed or precision you will find it difficult, at least if you want to 
use the design methods you are used to, data sheet timing data, 
simulator timing results, static timing analysis.  Instead you will need 
to buy an eval board, take your own measurements, then correct them for 
process, temperature and power supply voltage variations.

I've got paying work at the moment so I don't have any more time to play 
with the GA144.  But I may come back to this in a couple of months.  I 
still like the idea of a single chip (plus memory) oscilloscope.  I bet 
it can do the best job of any CPU at that task... if you have the 
stomach for dealing with such an odd chip.

Rick

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web