CommsTime times?

[Oyvind Teig <Oyvind.Teig@xxxxxxxxxxxx>]

Comstime: 

   MISPRINT in yesterday's letter: don't blame
   CCSP for the long times, the figures in point 4 and 5 
   had nothing to do with CCSP. 

-- Fixed 4 and 5:

1. When you compare times, beware of false ComsTimes!
   There is a "false" ComsTime around, with a SEQ in delta!
   I believe that Peter's initial version had PAR, but a 
   lot of times given are with SEQ in Delta!
   (I've even seen Peter use SEQ there!!)

   Suggestion for a rule:
   -----------------------------------------------------
   -- ALL COMSTIMERS SHOULD QUOTE PAR/SEQ IN "DELTA"! --
   -----------------------------------------------------

2. SPoC on a Texas TMS320C32 DSP, 32 bits bus, no wait cycles:
   122 us/iteration (PAR in Delta)

3. SPoC on 233 MHZ PC: 20 us/iteration.
   PAR in Delta.
   Repeat=20000 and Runs=100 to get
   long enough times (as my SPoC's PC TIMER resolution is
   1 ms, but with only 50 interrups per second)
   Debug version under Microsoft Visual C++.
   Quite loaded PC.

4. VxWorks with instead of occam's channels, coded by Age Stien
   Pentium 350 MHz
   (vxSim on WinNT)
   PAR in Delta.
   Pipes instead of channels, coded by Age Stien
   1.3008 ms/iteration with select
   1.0808 ms/iteration without select

5. VxWorks with instead of occam's channels, coded by Age Stien
   386ex 32 MHz, 1 wait cycle, 16 bits bus
   (VxWorks on embedded platform)
   PAR in Delta.
   11.4474 ms/iteration with select
    8.1049 ms/iteration without select

6. Cook & Peel sent a list to this group, 20Apr98, see bottom.
   Excerpt:
     275 MHz FPGA = 25.4ns per iteration.

-- 
Oyvind

@ Oyvind Teig (oyvind.teig@xxxxxxxxxxxx, oyvind.teig@xxxxxxxxxxxx)
@   Navia Maritime AS, division Autronica, 7005 Trondheim Norway 
@   Tel: +47 73 58 12 68, Fax: +47 73 58 10 01
@   http://www.autronica.no/ 
@   Now part of world's largest company in maritime electronics: 
@   http://www.kongsberg.com/
@ Publications at: http://www.autronica.no/pub/tech/rd/index.htm

--
Barry Cook's list to this group, 20Apr98:

Compiling occam into hardware
=============================

Enthused by WoTUG TM21 and spurred on by the news that SGS-Thomson are
stopping manufacture of the transputer, we (Barry Cook & Roger Peel) spent
much of Easter investigating a design methodology to produce a new 
transputer.
To cut a long story short, we wrote a fair bit of the functionality of a
T414
in occam and, having identified the requirements, started to write an
occam-to-FPGA compiler (using an existing occam(3) parser written in Java by
Barry).

So far, we are capable of compiling PAR, SEQ, WHILE TRUE, declarations,
input & output, simple assignments and very simple expressions, and
targeting the PldShell and Abel PLD input languages.  This is enough
to compile Peter Welch's 'commstime' benchmark and to simulate it as if
it was running on real PLD hardware.  Peter argues that commstime executes
eight context-switches per loop; although this is not quite true of the
FPGA (because the latter runs the processes truly in parallel), so we
provide the same figure for this case, too.


The initial performance results (for commstime with parallel Delta) are :

Architecture           Time per loop      Time per context switch    Source

D7205 on T800-20       15049 ns           1881 ns                    RMAP

KROC on SPARC Ultra    approx 2120 ns     265 ns                     PHW

occam on 275 MHz FPGA  25.4 ns            3.2 ns                    BMC/RMAP


Obviously, looping sequential arithmetic code will not realise such
impressive speed gains, but the potential is clear for code where there
is much parallelism, such as where loop unrolling and/or multiple
assignments are used.

Our immediate plans now are to implement the rest of occam, to program 
up a number of demonstrator projects, and to work towards implementing a
complete transputer (it's a plan but it won't happen overnight, time and
funding will be required, term starts next week - that'll kill progress :-( 
).
[Longer term plans are even more exciting - but a way off yet.]

Ideas for demonstrators are welcome - lots of parallelism,
communication, hardware interfacing and minimal arithmetic are probably
best at present.

Barry M Cook,          Roger M A Peel
barry@xxxxxxxxxxxxxx   R.Peel@xxxxxxxxxxxx


P.S.  Does anyone have any huge FPGA chips, plus software, that they
would like to donate??  Collaborators welcome, let's start some discussion.