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

Groups > comp.lang.forth > #15371

Re: GA144 Instruction Timing

Show all headers | View raw

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.
>

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