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

Groups > comp.lang.forth > #15254

Re: GA144 Instruction Timing

Show all headers | View raw

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/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web