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

Groups > comp.lang.forth > #34664

Re: GA144 article

Show all headers | View raw

On 8/5/2012 6:50 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Your calculations make no sense to me.  Sorry, but unless you can
>> explain them a bit more I have no idea why you are adding the numbers
>> you are adding.  I'm not even sure what the resulting number is an
>> estimate of.
>
> Simply this.  Reading from a port adds an average amount of time T=X+Y
> to the total runtime of the program.  X is the time for the port read
> itself, typically 3.5ns according to the doc you quoted.  Y is the
> instruction fetch time, that we don't know precisely (averaged across
> the different programs that people would actually write) but about which
> we have some information.  So I tried to estimate it imprecisely.  If it
> makes you feel better, just set Y=0 which means T=3.5 ns.  Remember the
> issue that led to this was comparing wire nodes in a GA144 to routing in
> an FPGA.  I'd like to know how 3.5ns compares to FPGA routing.

I see I let this conversation drop.  I'm not sure I intended to.  If you 
are still interested...

3.5 ns is not a long time for FPGA routing between two registers through 
a couple of logic blocks (not counting the logic).  Routing delay in an 
FPGA varies a lot depending on the length of the route and how many 
switches it has to go through.  If two logic blocks are next to each 
other or you are using a dedicated connection such as a carry chain, the 
routing is sub nanosecond.  Longer routes can be a couple or more ns. 
When the tools route the path between two registers the routing delay 
can be as much as the logic delay.

With floorplanning (hand placement of the compiled logic blocks in user 
specified logic elements) routing delays can be reduced, but only for 
the part of the circuit you are focused on.  I have tried to improve 
timing in one part of a design with floorplanning only to find other 
parts get noticeably worse.  Sort of a squeeze here and it squirts out 
there.

But I'm not sure there is much comparison in any direct way.  The logic 
elements in an FPGA are much smaller than the functions that would be 
implemented in an F18 processor.  If you were designing a very fast 
filter you might have a single multiply in one F18, communicate the 
result to another to implement the accumulate for a MAC 
(multiply/accumulate) function.  In that case the 3.5 ns each for the 
port write/reads would be a small part of the cycle time of a multiply 
operation (about 100 ns).


> Keep in mind also that the F18 node is a tiny microprocessor with a lot
> of gates switching on each instruction (I believe there is an internal
> microtick several times faster than the 700 mhz instruction cycle).
> Every time a gate switches, power is dissipated.  Compare that to FPGA
> routing, which I'd expect to be static (gates configured at
> initialization time then left alone).  So those wire nodes are burning
> more power than FPGA routing too.

Not sure of that, again a bit of apples and oranges.  Routing in an FPGA 
*does* use power.  There are two sources of energy use in an FPGA, 
static and dynamic.  The static power is leakage of the off transistors 
which varies greatly between different product lines.  Dynamic power 
comes from switching and is proportional to the capacitance.  Routing 
has significant capacitance and so uses dynamic power when changing 
state, likely more than the logic.

BTW, I don't think there is a "microtick" in the F18.  I believe it just 
has several delay lines which are tuned to the various functions to 
control the timing of each.  One delay line is used for all the ALU 
operations, another for memory, etc.


> On the other hand, the active nodes do a lot more than an FPGA CLB does,
> so there is a trade-off.

That is a very significant difference.


>> Read the timing section of the GA144 data book, DB002, sec 5.3 Typical
>> Instruction Timings.
>
> Thanks, that's useful info.

I don't know how far you got with that.  I found that if I read it 
multiple times it would become more and more clear.  There is a lot of 
subtle info in it.

-- 

Rick

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

Thread

Re: GA144 article rickman <gnuarm@gmail.com> - 2014-11-27 05:53 -0500

csiph-web