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 1 of 2  [1] 2  Next page →

#14934 — GA144 Instruction Timing

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

[toc] | [next] | [standalone]

#14935

rickman <gnuarm@gmail.com> writes:
> 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.

Have you enrolled in the "Arrayforth institute" at the greenarrays web
site?  I haven't, out of distaste for stuff behind registration walls,
but if I were really trying to use the chip the way you are, I suppose
I'd bite the bullet.

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

#14943

On 8/11/2012 8:40 PM, Paul Rubin wrote:
> rickman<gnuarm@gmail.com>  writes:
>> 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.
>
> Have you enrolled in the "Arrayforth institute" at the greenarrays web
> site?  I haven't, out of distaste for stuff behind registration walls,
> but if I were really trying to use the chip the way you are, I suppose
> I'd bite the bullet.

Yes, I did, but it is 100% online and I don't have Internet access 100% 
of the time.  I am at a vacation house where there is no broadcast or 
cable TV, no DSL, barely has cell coverage if I go out on the deck.  I 
have to drive to a convenience store/deli to get my Internet connection. 
  I looked at the first two videos and decided it wasn't worth the 
effort.  Maybe I should spend some more time on it.  It would be nice if 
I could download the videos.

I do get responses when I ask questions, but they are sometimes of the 
form, "we don't do it that way", like when they told me they expect 
users to measure timing on the eval board rather than in the simulator. 
  :(  But they seem to work on the weekends as I got a reply from Greg 
Bailey today saying he would be answering my timing questions but wanted 
to be working on editing the manual as he did it.

I'm not entirely happy with a few of the realizations I've had regarding 
the function of the I/O and communications.  I am trying to use the bit 
17 processor wait function to sync to a fast clock.  I think this may be 
problematic as the edge detection is not inherent, it needs to be coded 
or guaranteed by the code timing.  I expect the suspend is level 
sensitive so that a process that checks the I/O bit, waits, runs and 
checks to wait again has to make sure the bit has already gone low 
first.  Ok for slow clocks, but this can be an issue with faster clocks. 
  It may require NOPs if there are both long and short paths.

Rick

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

#14962

On Sunday, August 12, 2012 6:00:18 PM UTC-5, rickman wrote:

>   I looked at the first two videos and decided it wasn't worth the 
> 
> effort.  Maybe I should spend some more time on it.  It would be nice if 
> 
> I could download the videos.

They're hosted on youtube.  Add this plugin to Firefox and you can
easily download them.  http://www.downloadhelper.net/
 

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

#14978

On 8/14/2012 1:17 PM, johnmdrake@gmail.com wrote:
> On Sunday, August 12, 2012 6:00:18 PM UTC-5, rickman wrote:
>
>>    I looked at the first two videos and decided it wasn't worth the
>>
>> effort.  Maybe I should spend some more time on it.  It would be nice if
>>
>> I could download the videos.
>
> They're hosted on youtube.  Add this plugin to Firefox and you can
> easily download them.  http://www.downloadhelper.net/

Yeah, I must have already downloaded some helper.  I was looking at a 
video that jumped and lurched in the browser and found I had a right 
click menu item to save the bloody video!  Who knew!!!?

Or as those British guys in the ad would say, "BRILLIANT!"

I'll get a lot of use out of this...

Rick

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

#15096

I see Mr Moore has been updating his blog. Here is a direct link to some timing results.

http://colorforth.com/timings.htm

code ns
unext 2.3  

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

#15098

On 8/22/2012 10:11 AM, RR wrote:
> I see Mr Moore has been updating his blog. Here is a direct link to some timing results.
>
> http://colorforth.com/timings.htm
>
> code ns
> unext 2.3

This is a pretty meaningless value if you are trying to time code in a 
real application.  What was the voltage and temperature of the chip? 
Was this chip representative for process variation or was it faster or 
slower than the typical value?

Normally chip makers fully characterize their chips and provide software 
based tools to allow the users to measure timing performance.  GA has 
done a minimal job of this so that you need to instead test your app on 
the eval hardware and use a scope to measure the performance after 
calibrating the hardware against their test suite and statistical data.

Or better yet, don't work on any apps that push the performance of the 
chips.

Rick

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

#15103

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.

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

#15104

I'm not a hardware engineer by any stretch of the imagination, but this being a fully unclocked chip, I would expect that it would excel at problems which don't require a clock inside of the chip.

If I was receiving a signal from another chip or board, I would simply let the outside resource do the timing for me.  I would accommodate the other guy.  I would solve the problem from the bottom up, or in this case, from the real behavior of the outside resource down to me.  The real problem is just keeping up, if you can good, if you can't then you either put more cores onto the problem, or determine that you can't solve the problem.

Not having a clock means that it will not excel at being a clock.  That is good enough for me.  If I require a clock, then I would add one to the motherboard, and then communicate with it once on a loop.

To me the fact that Chuck wrote a clock program for his chip means that he is just being cute.  This is a grid of very simple microprocessors without a clock. Deal with that.

Jason

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

#15110

On 8/22/2012 4:10 PM, Jason Damisch wrote:
> I'm not a hardware engineer by any stretch of the imagination, but this being a fully unclocked chip, I would expect that it would excel at problems which don't require a clock inside of the chip.
>
> If I was receiving a signal from another chip or board, I would simply let the outside resource do the timing for me.  I would accommodate the other guy.  I would solve the problem from the bottom up, or in this case, from the real behavior of the outside resource down to me.  The real problem is just keeping up, if you can good, if you can't then you either put more cores onto the problem, or determine that you can't solve the problem.
>
> Not having a clock means that it will not excel at being a clock.  That is good enough for me.  If I require a clock, then I would add one to the motherboard, and then communicate with it once on a loop.
>
> To me the fact that Chuck wrote a clock program for his chip means that he is just being cute.  This is a grid of very simple microprocessors without a clock. Deal with that.
>
> Jason

I'm not certain who you are addressing, but dealing with multiple 
processors without a clock to synchronize them is not so trivial as you 
describe.

As you say the external interfaces can be clocked by the interface. 
Internally data is used to control timing.  But it can be difficult to 
control timing of these inner nodes.  Parallel paths can be tricky to 
synchronize.

As someone pointed out, companies who have worked with the earlier 
versions of these chips find the floorplanning (which I assumes includes 
an analysis of the timing and synchronization) is more than half the task.

Rick

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

#15116

Jason Damisch <jasondamisch@yahoo.com> writes:
> I'm not a hardware engineer by any stretch of the imagination, but
> this being a fully unclocked chip, I would expect that it would excel
> at problems which don't require a clock inside of the chip.

As I understand it, the GA144 nodes do have clocks.  The chip is
asynchronous in the sense that there is no single clock propagated
through the whole array.  The nodes are instead clocked independently
(ring oscillator in each node), with synchronization through a
mutex-like protocol in the i/o ports connecting nodes.  There is such a
thing as actual asynchronous logic that uses no clocking at all, but it
increases the amount of circuitry a lot and the GA144 doesn't use it.

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

#15128

On 8/23/2012 3:03 AM, Paul Rubin wrote:
> Jason Damisch<jasondamisch@yahoo.com>  writes:
>> I'm not a hardware engineer by any stretch of the imagination, but
>> this being a fully unclocked chip, I would expect that it would excel
>> at problems which don't require a clock inside of the chip.
>
> As I understand it, the GA144 nodes do have clocks.  The chip is
> asynchronous in the sense that there is no single clock propagated
> through the whole array.  The nodes are instead clocked independently
> (ring oscillator in each node), with synchronization through a
> mutex-like protocol in the i/o ports connecting nodes.  There is such a
> thing as actual asynchronous logic that uses no clocking at all, but it
> increases the amount of circuitry a lot and the GA144 doesn't use it.

Not really true in a meaningful sense.  There are multiple paths through 
the F18 with different delays in each path.  There is a matching 
handshake path with a delay that is assured to be longer than the data 
path.  You can call these handshakes clocks if you want, but the main 
point is that there is not ring oscillator that times each node like a 
clock.  I am basing this on what I know about async processors, not any 
direct knowledge of the GA devices.

More significantly, there is no clock distribution network that feeds 
the entire chip with a low skew clock signal.  I recently read that this 
clock tree can easily be 1/3 of the power in the chip... I think that 
was in the latest lecture info from GA now that I think about it.  But I 
got similar info from someone once when we were debating sync vs. async 
devices.

Rick

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

#15134

rickman wrote:
> Not really true in a meaningful sense.  There are multiple paths
> through
> the F18 with different delays in each path.  There is a matching
> handshake path with a delay that is assured to be longer than the data
> path.

AFAIK not.  When you do + on a F18, you are supposed to have a nop in 
the cycle before to let the carry propagate.  I.e. there is no such 
handshake, with the exception of IOs, which do handshake (or rather wait 
for data availability), and that's indeed between two asynchronous clock 
domains.  I have the same architecture description in mind as Paul Rubin 
tells: each core has an independent free-running ring oscillator, which 
stops whenever there's something to wait for (IO).

A global low-skew synchronized clock tree can take a lot of resources, 
depending on how you implement it.  One of the earlier Alphas had indeed 
30% of its power budget in the clock tree.  However, this is no longer 
the case with the way you build gated clock trees today - you can shut 
off parts of the clock tree completely, especially on flip-flops, which 
you clock only when they are supposed to capture new data.

If you don't use gated clocks, you can still have 30% of the power 
consumption in the clock trees today.  Or 90%, if you are idle most of 
the time, and only the clock tree runs.  State of the art is gated 
clocks and turning ring oscillators of when they are not needed.  It's 
not that Chuck does anything particularly advanced here.

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

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

#15208

On 8/24/2012 10:29 AM, Bernd Paysan wrote:
> rickman wrote:
>> Not really true in a meaningful sense.  There are multiple paths
>> through
>> the F18 with different delays in each path.  There is a matching
>> handshake path with a delay that is assured to be longer than the data
>> path.
>
> AFAIK not.  When you do + on a F18, you are supposed to have a nop in
> the cycle before to let the carry propagate.  I.e. there is no such
> handshake, with the exception of IOs, which do handshake (or rather wait
> for data availability), and that's indeed between two asynchronous clock
> domains.  I have the same architecture description in mind as Paul Rubin
> tells: each core has an independent free-running ring oscillator, which
> stops whenever there's something to wait for (IO).

If what you are saying is true, then all instructions would have the 
same timing.  Read the timing info in the docs.  Instruction timings are 
all over the map.  The add instruction requiring a nop cycle is because 
it was designed to run in the same time as the other ALU instructions if 
you know you don't need to wait for the carry, but if you need to wait, 
you add the nop.  Chuck says this in one of his web pages.

The instruction timing is actually rather complex relating to the 
particular instruction along with an adder for each instruction word 
fetch which varies depending on which instructions may have disrupted 
the prefetch.  None of the timings are multiples of a single value which 
is what you would get if it used a single ring oscillator for 
instruction timing.  If this is true, how would they get the variability 
in instruction timing depending on the functions being exercised?


> A global low-skew synchronized clock tree can take a lot of resources,
> depending on how you implement it.  One of the earlier Alphas had indeed
> 30% of its power budget in the clock tree.  However, this is no longer
> the case with the way you build gated clock trees today - you can shut
> off parts of the clock tree completely, especially on flip-flops, which
> you clock only when they are supposed to capture new data.

Gated clocks are only useful for shutting off sections of logic like 
functional blocks, not individual FFs.  I'm not even sure the FFs use 
much power if their outputs aren't changing.  I've never found a source 
for this, but I have seen info on power dissipation in logic and the 
bulk of the power is from the logic between the FFs rather than the FFs 
themselves.


> If you don't use gated clocks, you can still have 30% of the power
> consumption in the clock trees today.  Or 90%, if you are idle most of
> the time, and only the clock tree runs.  State of the art is gated
> clocks and turning ring oscillators of when they are not needed.  It's
> not that Chuck does anything particularly advanced here.

No, power consumption is a well established art.  But you have to admit 
that no one else has the ability to shut off power to a CPU "instantly" 
without program control and start up again "instantly" with virtually no 
power consumption in that process.

Another reason I don't think a ring oscillator is being used is because 
they are essentially analog functions.  When you stop such a circuit the 
voltage drops to ground or rises to the power rail and the next pulse 
will be abnormally long.  Timing based on logic delays doesn't have this 
problem.  The GA144 doesn't have a timing component showing this startup 
delay, at least I think it doesn't.  They have yet to provide answers to 
my questions about the start and stop timing.  They seem to say there is 
no time required, but if processor A executes a 5 ns instruction that 
depends on processor B reading which takes 5 ns, how long does this take 
for the second processor to complete?  What if A waits on B reading how 
long does it take for A to execute?  I wonder if the issues of 
metastability enter into this timing issue and if so, have they have 
been addressed?

Rick

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

#15210

rickman wrote:
> The instruction timing is actually rather complex relating to the
> particular instruction along with an adder for each instruction word
> fetch which varies depending on which instructions may have disrupted
> the prefetch.  None of the timings are multiples of a single value
> which is what you would get if it used a single ring oscillator for
> instruction timing.  If this is true, how would they get the
> variability in instruction timing depending on the functions being
> exercised?

Sounds hellish complicated.  This is really a Chuck Moore design?

> Gated clocks are only useful for shutting off sections of logic like
> functional blocks, not individual FFs.  I'm not even sure the FFs use
> much power if their outputs aren't changing.

Oh yes.  The rule of thumb is that it is power-effective to gate 
individual FFs if they don't switch most of the time, and that it is 
area-effective to gate three FFs with the same condition.  Usually, 
synthesis tools optimize for area, so they don't automatically gate 
single FFs.  The power consumption of a flip-flop without changing the 
output should be around 30% of it changing, so it is only convenient not 
to gate flip-flops which get new data every cycle (new data=50% 
likelyhood to change).  You can't gate them anyways, as their gate would 
be constantly on ;-).

Some people use pulsed latches, where the pulse is generated from the 
clock using small delay elements, and gate the pulse - this reduces both 
area and power, but it is difficult to generate using automated tools.  
The usual way to do it with automated tools is to pre-layout pulse 
generator and flip-flops together, so that the delays work out.  It's 
also complicated to build scan chains of these components, but for 
Chuck, they are perfect.

> I've never found a
> source for this, but I have seen info on power dissipation in logic
> and the bulk of the power is from the logic between the FFs rather
> than the FFs themselves.

If you have a lot of logic, this can be the case (like a multiplier 
array where you have 2n FFs, but n*n gates), but not with simple CPUs 
like Chucks.  There, the overall area and power is dominated by FFs, not 
by gates.  You have a simple ALU connected to T and S, and that ALU is 
smaller than T and S each.  You have a simple incrementer connected to 
P, which is itself smaller than P.  You have some multiplexers to route 
data pathes, but not that many.

> No, power consumption is a well established art.  But you have to
> admit that no one else has the ability to shut off power to a CPU
> "instantly" without program control and start up again "instantly"
> with virtually no power consumption in that process.

Uh, when I did the last project with my b16, I did just the same.  The 
oscillator block was already designed to make this feasible, all I did 
for tuning was to make the first cycle about as fast as all the others 
(it originally was slower, due to some design mistakes).  When you have 
locked PLLs, you can't start and stop them instantly, because they have 
to lock.  But for the kind of embedded work we did, we had a timing 
source from a 32kHz oscillator, and the frequency of the faster 
oscillator didn't have to be precise or locked to anything.

> Another reason I don't think a ring oscillator is being used is
> because
> they are essentially analog functions.

No, a ring oscillator is just a bunch of inverters (odd number), and for 
start/stop, you use a nand or nor gate (depending if you think of it as 
enable or disable signal).

> When you stop such a circuit
> the voltage drops to ground or rises to the power rail and the next
> pulse
> will be abnormally long.

Hehe.  Yes, that's what the original design did.  It can be fixed.  You 
are talking about RC oscillators, not ring oscillators.  The problem 
with RC oscillators is that you have some bias currents which need to 
charge internal capacitors to start up.  The fix is to use capacitors to 
enable/disable to charge them up instantly on turn on (and it also 
silences the circuit immediately at shut-down).  All nodes need to be in 
a defined state in off mode, of course.

> Timing based on logic delays doesn't have
> this
> problem.  The GA144 doesn't have a timing component showing this
> startup
> delay, at least I think it doesn't.  They have yet to provide answers
> to
> my questions about the start and stop timing.  They seem to say there
> is no time required, but if processor A executes a 5 ns instruction
> that depends on processor B reading which takes 5 ns, how long does
> this take
> for the second processor to complete?  What if A waits on B reading
> how
> long does it take for A to execute?  I wonder if the issues of
> metastability enter into this timing issue and if so, have they have
> been addressed?

Given that this clock circuit has at least several "ready" inputs, which 
are chosen depending on the instruction, it's probably not possible to 
create metastability.  All you can get is additional delays, which don't 
hurt.  When you read, you wait for ready (it goes as enable into your 
ring oscillator).  When you have completed the read (input is latched in 
T), then you generate an acknowledge pulse, which clears ready.

When you write, you wait for "not ready", same signal, different level.  
After you transferred the data into the latch, you set ready again with 
a set pulse, which must be longer than the acknowledge pulse (the easy 
way to do this is to give the acknowledge pulse priority, and have the 
set wait until it actually is set).

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

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

#15213

On 8/27/2012 8:45 PM, Bernd Paysan wrote:
> rickman wrote:
>> The instruction timing is actually rather complex relating to the
>> particular instruction along with an adder for each instruction word
>> fetch which varies depending on which instructions may have disrupted
>> the prefetch.  None of the timings are multiples of a single value
>> which is what you would get if it used a single ring oscillator for
>> instruction timing.  If this is true, how would they get the
>> variability in instruction timing depending on the functions being
>> exercised?
>
> Sounds hellish complicated.  This is really a Chuck Moore design?

Why don't you ask Chuck?


>> Gated clocks are only useful for shutting off sections of logic like
>> functional blocks, not individual FFs.  I'm not even sure the FFs use
>> much power if their outputs aren't changing.
>
> Oh yes.  The rule of thumb is that it is power-effective to gate
> individual FFs if they don't switch most of the time, and that it is
> area-effective to gate three FFs with the same condition.  Usually,
> synthesis tools optimize for area, so they don't automatically gate
> single FFs.  The power consumption of a flip-flop without changing the
> output should be around 30% of it changing, so it is only convenient not
> to gate flip-flops which get new data every cycle (new data=50%
> likelyhood to change).  You can't gate them anyways, as their gate would
> be constantly on ;-).

But something has to control that gate.  What does the control?  How 
much power does that use?


> Some people use pulsed latches, where the pulse is generated from the
> clock using small delay elements, and gate the pulse - this reduces both
> area and power, but it is difficult to generate using automated tools.
> The usual way to do it with automated tools is to pre-layout pulse
> generator and flip-flops together, so that the delays work out.  It's
> also complicated to build scan chains of these components, but for
> Chuck, they are perfect.
>
>> I've never found a
>> source for this, but I have seen info on power dissipation in logic
>> and the bulk of the power is from the logic between the FFs rather
>> than the FFs themselves.
>
> If you have a lot of logic, this can be the case (like a multiplier
> array where you have 2n FFs, but n*n gates), but not with simple CPUs
> like Chucks.  There, the overall area and power is dominated by FFs, not
> by gates.  You have a simple ALU connected to T and S, and that ALU is
> smaller than T and S each.  You have a simple incrementer connected to
> P, which is itself smaller than P.  You have some multiplexers to route
> data pathes, but not that many.

That' nice, just wave your hands and the multiplexers go away.  In my 
CPU design for an FPGA the multiplexers dominated the logic far beyond 
the ALU logic which is pretty simple.  In fact, to reduce the 
multiplexer logic I sometimes used adders with a gated input (the fourth 
input on the LUT, so it was free) as multiplexers.


>> No, power consumption is a well established art.  But you have to
>> admit that no one else has the ability to shut off power to a CPU
>> "instantly" without program control and start up again "instantly"
>> with virtually no power consumption in that process.
>
> Uh, when I did the last project with my b16, I did just the same.  The
> oscillator block was already designed to make this feasible, all I did
> for tuning was to make the first cycle about as fast as all the others
> (it originally was slower, due to some design mistakes).  When you have
> locked PLLs, you can't start and stop them instantly, because they have
> to lock.  But for the kind of embedded work we did, we had a timing
> source from a 32kHz oscillator, and the frequency of the faster
> oscillator didn't have to be precise or locked to anything.

If your ring oscillator is as long as the delays through the various 
logic in an CPU then I suppose it stops working like an analog device. 
But then how does this differ from a delay path matched to the logic? 
what makes you think there aren't multiple delay paths matched to the 
different logic paths?


>> Another reason I don't think a ring oscillator is being used is
>> because
>> they are essentially analog functions.
>
> No, a ring oscillator is just a bunch of inverters (odd number), and for
> start/stop, you use a nand or nor gate (depending if you think of it as
> enable or disable signal).

Yes, but when used in a feedback circuit they tend to work like analog 
components.  I suppose if you string a number of them together they 
start to look more digital.  But then that is what a matched delay path 
is, a number of inverters which are built just like your logic path...


>> When you stop such a circuit
>> the voltage drops to ground or rises to the power rail and the next
>> pulse
>> will be abnormally long.
>
> Hehe.  Yes, that's what the original design did.  It can be fixed.  You
> are talking about RC oscillators, not ring oscillators.  The problem
> with RC oscillators is that you have some bias currents which need to
> charge internal capacitors to start up.  The fix is to use capacitors to
> enable/disable to charge them up instantly on turn on (and it also
> silences the circuit immediately at shut-down).  All nodes need to be in
> a defined state in off mode, of course.
>
>> Timing based on logic delays doesn't have
>> this
>> problem.  The GA144 doesn't have a timing component showing this
>> startup
>> delay, at least I think it doesn't.  They have yet to provide answers
>> to
>> my questions about the start and stop timing.  They seem to say there
>> is no time required, but if processor A executes a 5 ns instruction
>> that depends on processor B reading which takes 5 ns, how long does
>> this take
>> for the second processor to complete?  What if A waits on B reading
>> how
>> long does it take for A to execute?  I wonder if the issues of
>> metastability enter into this timing issue and if so, have they have
>> been addressed?
>
> Given that this clock circuit has at least several "ready" inputs, which
> are chosen depending on the instruction, it's probably not possible to
> create metastability.  All you can get is additional delays, which don't
> hurt.  When you read, you wait for ready (it goes as enable into your
> ring oscillator).  When you have completed the read (input is latched in
> T), then you generate an acknowledge pulse, which clears ready.
 >
> When you write, you wait for "not ready", same signal, different level.
> After you transferred the data into the latch, you set ready again with
> a set pulse, which must be longer than the acknowledge pulse (the easy
> way to do this is to give the acknowledge pulse priority, and have the
> set wait until it actually is set).

Saying "wait for ready" doesn't describe the circuit.  If the circuit 
uses FFs I would need to see the circuit to know if it can become 
metastable or not.  If two CPUs are competing for sync, I can see this 
becoming a metastability issue if not done right.

You only describe one possibility, write is done after read.  What if 
the write is done first?  Then, what if they are done simultaneously? 
How is simultaneously defined?  That is the key to whether it can become 
metastable, no?  I don't think this can be analyzed without knowing the 
specifics of the circuit.

Rick

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

#15225

rickman wrote:
> But something has to control that gate.  What does the control?  How
> much power does that use?

You have two choices for a flip-flop: Either gate the clock, or use a 
multiplexer to allow it to keep its data.  The multiplexer is usually 
built-in when you have an "enable" input (that's the standard way of 
doing things for an ungated flip-flop).

The gate itself is just an AND or an OR gate, depending if you gate on 
high or low clock.  Its power consumption is significantly less than a 
flip-flop, which drives two pass gates with the clock signal.  And the 
gate does not only gate one flip-flop (where it is power-efficient, but 
not area-efficient), but several.

> That' nice, just wave your hands and the multiplexers go away.  In my
> CPU design for an FPGA the multiplexers dominated the logic far beyond
> the ALU logic which is pretty simple.  In fact, to reduce the
> multiplexer logic I sometimes used adders with a gated input (the
> fourth input on the LUT, so it was free) as multiplexers.

You have something in real silicon which you don't have in FPGAs: NAND 
and NOR gates with quite a number of inputs.  They are significantly 
better than multiplexer, in so far as you only need to gate the output 
of each of the different pathes, and then OR everything together 
(usually with NAND gates, because you invert the signal before).

The unused paths are gated off, and therefore don't toggle, which means 
almost no power consumption. Yes, it may look like hand-waving, but real 
silicon is significantly different from FPGAs. In FPGAs, you have a 
"free" fast carry chain, which you don't in real silicon.  On the other 
hand, you have much cheaper multiplexers in real silicon.

> If your ring oscillator is as long as the delays through the various
> logic in an CPU then I suppose it stops working like an analog device.
> But then how does this differ from a delay path matched to the logic?
> what makes you think there aren't multiple delay paths matched to the
> different logic paths?

From the look into the documentation, there are not so many different 
delay pathes.  You have your basic ALU operation (1400ps typical), you 
have your instruction prefetch time, your RAM/ROM access time and IO 
access time.  unext/next may have their own path, because there, the 
carry needs to propagate.  It probably looks more complicated on the 
outside.

> Yes, but when used in a feedback circuit they tend to work like analog
> components.  I suppose if you string a number of them together they
> start to look more digital.  But then that is what a matched delay
> path is, a number of inverters which are built just like your logic
> path...

Name it as you like, a bunch of inverters in a cycle is a ring 
oscillator.

>> When you write, you wait for "not ready", same signal, different
>> level. After you transferred the data into the latch, you set ready
>> again with a set pulse, which must be longer than the acknowledge
>> pulse (the easy way to do this is to give the acknowledge pulse
>> priority, and have the set wait until it actually is set).
> 
> Saying "wait for ready" doesn't describe the circuit.  If the circuit
> uses FFs

It won't, it uses RS latches, and it describes the circuit.  You assert 
the set pin, and you can only continue (and then de-assert) when the 
output is 1.  This works both if you feed that into your matched delay 
chains as asynchronous clock, or if you have a synchronous clock.  That 
is when you write to your output port, your delay chain now includes an 
expected state transition from empty to full - you can only write when 
the one-element-fifo is empty, and after you have done that, you need to 
make sure it actually goes "full".

> I would need to see the circuit to know if it can become
> metastable or not.  If two CPUs are competing for sync, I can see this
> becoming a metastability issue if not done right.

The asynchronous FIFO with special care for the full/empty signal to 
prevent metastability is a standard way of having two clock domains 
communicating.  That's exactly what Chuck is using, though his FIFO has 
only one item to buffer (but it still has full/empty states).

> You only describe one possibility, write is done after read.  What if
> the write is done first?

Neither side has to wait for anything in this case.  The write finds an 
empty FIFO, and can proceed immediately.  The read finds a full FIFO, 
and can proceed, too.

> Then, what if they are done simultaneously?

The reader goes into wait when there's nothing to read.  You can't have 
them read and write at the same time.  Either it's full, then you can't 
write, but you can read, or it's empty, then you can write, but can't 
read.  If they are trying at the same time, only one of them can do 
something, the other has to wait.

> How is simultaneously defined?  That is the key to whether it can
> become
> metastable, no?  I don't think this can be analyzed without knowing
> the specifics of the circuit.

Well, yes, but the asynchronous FIFO with special care to full/empty is 
a standard approach.

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

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

#15227

On 8/28/2012 4:07 PM, Bernd Paysan wrote:
> rickman wrote:
>> But something has to control that gate.  What does the control?  How
>> much power does that use?
>
> You have two choices for a flip-flop: Either gate the clock, or use a
> multiplexer to allow it to keep its data.  The multiplexer is usually
> built-in when you have an "enable" input (that's the standard way of
> doing things for an ungated flip-flop).
>
> The gate itself is just an AND or an OR gate, depending if you gate on
> high or low clock.  Its power consumption is significantly less than a
> flip-flop, which drives two pass gates with the clock signal.  And the
> gate does not only gate one flip-flop (where it is power-efficient, but
> not area-efficient), but several.

No, I am asking what controls the gate signal?  That is logic, no?  What 
about its power dissipation?


>> That' nice, just wave your hands and the multiplexers go away.  In my
>> CPU design for an FPGA the multiplexers dominated the logic far beyond
>> the ALU logic which is pretty simple.  In fact, to reduce the
>> multiplexer logic I sometimes used adders with a gated input (the
>> fourth input on the LUT, so it was free) as multiplexers.
>
> You have something in real silicon which you don't have in FPGAs: NAND
> and NOR gates with quite a number of inputs.  They are significantly
> better than multiplexer, in so far as you only need to gate the output
> of each of the different pathes, and then OR everything together
> (usually with NAND gates, because you invert the signal before).
>
> The unused paths are gated off, and therefore don't toggle, which means
> almost no power consumption. Yes, it may look like hand-waving, but real
> silicon is significantly different from FPGAs. In FPGAs, you have a
> "free" fast carry chain, which you don't in real silicon.  On the other
> hand, you have much cheaper multiplexers in real silicon.
>
>> If your ring oscillator is as long as the delays through the various
>> logic in an CPU then I suppose it stops working like an analog device.
>> But then how does this differ from a delay path matched to the logic?
>> what makes you think there aren't multiple delay paths matched to the
>> different logic paths?
>
>  From the look into the documentation, there are not so many different
> delay pathes.  You have your basic ALU operation (1400ps typical), you
> have your instruction prefetch time, your RAM/ROM access time and IO
> access time.  unext/next may have their own path, because there, the
> carry needs to propagate.  It probably looks more complicated on the
> outside.

The instruction prefetch time is itself four different values depending 
on the instruction mix, but I suppose that is one delay that gets 
restarted when the prefetch is restarted.

The point is, the timing is not controlled by a ring oscillator.  Each 
separate delay path has its own timing circuit.

I'm not saying it is complicated.  I believe that was you who said it 
was "hellish complicated".  I'm just pointing out that the B18 does not 
use a fixed period machine cycle.  The machine cycle time is a variable 
and not governed by a ring oscillator.


>> Yes, but when used in a feedback circuit they tend to work like analog
>> components.  I suppose if you string a number of them together they
>> start to look more digital.  But then that is what a matched delay
>> path is, a number of inverters which are built just like your logic
>> path...
>
> Name it as you like, a bunch of inverters in a cycle is a ring
> oscillator.
>
>>> When you write, you wait for "not ready", same signal, different
>>> level. After you transferred the data into the latch, you set ready
>>> again with a set pulse, which must be longer than the acknowledge
>>> pulse (the easy way to do this is to give the acknowledge pulse
>>> priority, and have the set wait until it actually is set).
>>
>> Saying "wait for ready" doesn't describe the circuit.  If the circuit
>> uses FFs
>
> It won't, it uses RS latches, and it describes the circuit.  You assert
> the set pin, and you can only continue (and then de-assert) when the
> output is 1.  This works both if you feed that into your matched delay
> chains as asynchronous clock, or if you have a synchronous clock.  That
> is when you write to your output port, your delay chain now includes an
> expected state transition from empty to full - you can only write when
> the one-element-fifo is empty, and after you have done that, you need to
> make sure it actually goes "full".
>
>> I would need to see the circuit to know if it can become
>> metastable or not.  If two CPUs are competing for sync, I can see this
>> becoming a metastability issue if not done right.
>
> The asynchronous FIFO with special care for the full/empty signal to
> prevent metastability is a standard way of having two clock domains
> communicating.  That's exactly what Chuck is using, though his FIFO has
> only one item to buffer (but it still has full/empty states).
>
>> You only describe one possibility, write is done after read.  What if
>> the write is done first?
>
> Neither side has to wait for anything in this case.  The write finds an
> empty FIFO, and can proceed immediately.  The read finds a full FIFO,
> and can proceed, too.

You need to read up on the F18.  Interprocessor comms is also a sync 
method.  Neither processor will advance until both have completed the 
transaction.


>> Then, what if they are done simultaneously?
>
> The reader goes into wait when there's nothing to read.  You can't have
> them read and write at the same time.  Either it's full, then you can't
> write, but you can read, or it's empty, then you can write, but can't
> read.  If they are trying at the same time, only one of them can do
> something, the other has to wait.

You are thinking of something you may have designed, but you are not 
describing an F18 design.


>> How is simultaneously defined?  That is the key to whether it can
>> become
>> metastable, no?  I don't think this can be analyzed without knowing
>> the specifics of the circuit.
>
> Well, yes, but the asynchronous FIFO with special care to full/empty is
> a standard approach.

What FIFO???  There are no FIFOs in the F18 that I have seen.  Perhaps 
you might read the full data book.  This is not one of your designs. 
This is a Chuck Moore design.

Rick

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

#15230

rickman wrote:
> No, I am asking what controls the gate signal?  That is logic, no? 
> What about its power dissipation?

In a 16 bit processor, your data path is 16 bits.  Your control path is 
1 bit.  Go figure ;-).

>>  From the look into the documentation, there are not so many
>>  different
>> delay pathes.  You have your basic ALU operation (1400ps typical),
>> you have your instruction prefetch time, your RAM/ROM access time and
>> IO
>> access time.  unext/next may have their own path, because there, the
>> carry needs to propagate.  It probably looks more complicated on the
>> outside.
> 
> The instruction prefetch time is itself four different values
> depending on the instruction mix, but I suppose that is one delay that
> gets restarted when the prefetch is restarted.

Yes.

> The point is, the timing is not controlled by a ring oscillator.  Each
> separate delay path has its own timing circuit.

Standard instruction timing is controlled by a ring oscillator.  There 
are some longer delays, which can be described as "separate delay path".  
As you can easily see, these extra delays involve memory, IO or 
next/unext, which has to decrement a counter.

> The machine cycle time is a
> variable and not governed by a ring oscillator.

For ALU and stack instructions, it is.

>> Neither side has to wait for anything in this case.  The write finds
>> an
>> empty FIFO, and can proceed immediately.  The read finds a full FIFO,
>> and can proceed, too.
> 
> You need to read up on the F18.  Interprocessor comms is also a sync
> method.  Neither processor will advance until both have completed the
> transaction.

Oops, yes, seems to be the case.  This doesn't change the architecture 
that much, it just takes the buffer out (less gates), but also this may 
cost performance.

> You are thinking of something you may have designed, but you are not
> describing an F18 design.

Indeed, I wouldn't do that. Decoupling processes improve performance.  
But well, it also means more gates...

The basic principle is still the same, you still use an RS latch to 
communicate, and it still can't go metastable.  The writer can only set 
it, the reader can only reset it when the writer has already set it.  
When they attempt to do this at the same time, there will be a delay 
(the reader must wait for the writer to set this bit).

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

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

#15251

On 8/28/2012 7:41 PM, Bernd Paysan wrote:
> rickman wrote:
>> No, I am asking what controls the gate signal?  That is logic, no?
>> What about its power dissipation?
>
> In a 16 bit processor, your data path is 16 bits.  Your control path is
> 1 bit.  Go figure ;-).
>
>>>    From the look into the documentation, there are not so many
>>>   different
>>> delay pathes.  You have your basic ALU operation (1400ps typical),
>>> you have your instruction prefetch time, your RAM/ROM access time and
>>> IO
>>> access time.  unext/next may have their own path, because there, the
>>> carry needs to propagate.  It probably looks more complicated on the
>>> outside.
>>
>> The instruction prefetch time is itself four different values
>> depending on the instruction mix, but I suppose that is one delay that
>> gets restarted when the prefetch is restarted.
>
> Yes.
>
>> The point is, the timing is not controlled by a ring oscillator.  Each
>> separate delay path has its own timing circuit.
>
> Standard instruction timing is controlled by a ring oscillator.  There
> are some longer delays, which can be described as "separate delay path".
> As you can easily see, these extra delays involve memory, IO or
> next/unext, which has to decrement a counter.
>
>> The machine cycle time is a
>> variable and not governed by a ring oscillator.
>
> 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.

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.


>>> Neither side has to wait for anything in this case.  The write finds
>>> an
>>> empty FIFO, and can proceed immediately.  The read finds a full FIFO,
>>> and can proceed, too.
>>
>> You need to read up on the F18.  Interprocessor comms is also a sync
>> method.  Neither processor will advance until both have completed the
>> transaction.
>
> Oops, yes, seems to be the case.  This doesn't change the architecture
> that much, it just takes the buffer out (less gates), but also this may
> cost performance.

Indeed, performance goes to hell when the processor is stopped, perhaps 
all the way to zero MIPS.  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. 
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?

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


>> You are thinking of something you may have designed, but you are not
>> describing an F18 design.
>
> Indeed, I wouldn't do that. Decoupling processes improve performance.
> But well, it also means more gates...
>
> The basic principle is still the same, you still use an RS latch to
> communicate, and it still can't go metastable.  The writer can only set
> it, the reader can only reset it when the writer has already set it.
> When they attempt to do this at the same time, there will be a delay
> (the reader must wait for the writer to set this bit).

Again, you are assuming.  Do you know what the F18 uses?  How does this 
interact with the other registers in the F18?  How is the delay 
generated when the two are simultaneous?

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.  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.  Hand waving and talking about "basic principles" doesn't 
explain anything.

Rick

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web