From Oyvind.Teig@autronica.no Sun Oct 31 15:49:05 2004 From: Oyvind Teig To: java-threads@ukc.ac.uk, occam-com@ukc.ac.uk Date: Mon, 13 Nov 2000 13:59:46 +0100 Subject: Re: CommsTime times? Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Comstime 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. CCSP 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 with select 5. CCSP 386ex 32 MHz, 1 wait cycle, 16 bits bus (VxWorks) PAR in Delta. Pipes instead of channels, coded by Age Stien 11.4474 ms/iteration with select 8.1049 ms/iteration with 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@autronica.no, oyvind.teig@computer.org) @ 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@cs.keele.ac.uk R.Peel@surrey.ac.uk P.S. Does anyone have any huge FPGA chips, plus software, that they would like to donate?? Collaborators welcome, let's start some discussion.