/* * _version.h * * Created on: 7. mars 2021 * Author: teig */ #ifndef VERSION_H_ #define VERSION_H_ /* --------- VER COMMITS ------------------------------------------------------------------------------- 18Apr2021 042 Just some more comments and cleaning up. For IEEE-COPA 2021 14Apr2021 041 Import this to xTIMEcomposer and just compile. It's the 8*8 topology that is set up with #defines right now, with the servers being [[distributable]]. See 040 below. See https://www.teigfam.net/oyvind/home/technology/218-ieee-copa-2021-fringe/ 28Mar2021 040 TOP_26_CONFIG == IS_8_BY_8 [[distributable]] certainly works! Sliding of synchronization is done 90 times out of 6089, but lag of printing is plus minus 3. See log "2021 03 28 19.59 log top 26 partly distributed is in synch excerpts" LAG of PRINTING (of plus minus 3) around cycle_cnt 6000 is ok and does not imply sliding of synch! With zero delays the round trip of 64 nodes is 1.32 ms 27Mar2021 039 TOP_26_CONFIG == IS_8_BY_8 [[distributable]] void Server_node_task It runs, but is not synchronized at all == WRONG! See above See log "2021 03 27 21.13 TOP_26_CONFIG IS_8_BY_8 not in synch at all.txt" 21Mar2021 038 Runs: It was not necessary to pass key back and forth, enough to hold it in the servers 20Mar2021 037 Flashed with xflash from Terminal with XCORE-200-EXPLORER.xn modified to: 20Mar2021 036 RUNS TOP_26 only done: Seems like the introduction og key in the interface protocol solved the problem! 19Mar2021 035 STOPS: testing with calculated_new_temp_at_this_cycle_cnt 18Mar2021 034 Runs: (but with some sliding) For some logs, like "2021 03 18 13.56 TOP_26 synch log taken back old cycle_cnt increment places.txt" with 5 secs interval 18Mar2021 033 See "2021 03 18 11.43 TOP_26 synch log.txt" up to 13.39, I had moved context.cycle_cnt++ to after synch, this does not look nice. I'll redo (top_26_xc.h) 17Mar2021 032 Analysed a lot of logs. It's not printing itself. Synchings looks ok. I don't know why we seem to get a sliding into _present_ cycle_cnt of values and thus wrong CONVERGING_VALUE 17Mar2021 031 "2021 03 17 16.34 TOP_26 synch log.txt" and "2021 03 17 16.34 TOP_26 synch log grep.txt" 17Mar2021 030 "2021 03 17 TOP_26 12.28 sliding even if less printing.txt". See VER 028 17Mar2021 029 Several more logs, I see both sliding and fully synchronized: "2021 03 17 TOP_20 11.25 fair synchronized full.txt" "2021 03 17 TOP_21 11.31 fair synchronized full.txt" "2021 03 17 TOP_24 11.44 not combined synchronized fair.txt" "2021 03 17 TOP_24 11.50 partly combined synchronized fair.txt" Same client and server.. "2021 03 17 TOP_25 11.59 sliding.txt" ..file: "top_24_25_xc.h" 17Mar2021 028 "2021 03 17 TOP_26 10.47 sliding excerpt.txt" + "full" see VER 030 16Mar2021 027 CONVERGING_VALUE investigations is TODO=problematic! 16Mar2021 026 New file "top_24_25_xc.h". CONVERGING_VALUE still problematic for TOP_26 15Mar2021 025 I did have problems in my own code! So a race condition of XC/XCore is not likely! 15Mar2021 024 Replaced Client_node_task with a version with client_state, removed a timer and wto guards. 120 bytes less for 4 tasks. But the "race condition"(?) still exists. 14Mar2021 023 For Larry. TOP_25_HAS_1_TILE_016_T0_2N_14CN_NOT_CONVERGING is new and TOP_24_HAS_1_TILE_004_T0_2N_2CN_ETC_MAYBE_CONVERGING new name and file new name: top_24_25_xc.h" 14Mar2021 022 https://www.xcore.com/viewtopic.php?f=26&t=8098 ("Is it possible to get a race condition in clean XC on XCore?") 14Mar2021 021 RETEST_SYNCH_ROOT_DELAY_UNTIL_NEXT_ROUND_US 1 race 13mar2013 020 Added some comments in "top_24_xc.h" 13Mar2021 019 Works like a dream! 13Mar2021 018 xcc1: terminated due to internal unrecoverable error: reported to XMOS 13Mar2021 017 Work fine, before making more function calls 13Mar2021 016 Reported TOP_20_AS_PARTLY_COMBINED==1 to XMOS. Added to issue #84030 "Loacl variable not initialised (correctly)" (19Jan2021) 13Mar2021 015 Even this fails like below, and I have removed the init on context locally, I'm back to where it worked better but it doesn't When I updated DEBUG_PRINTF_BUFSIZE from 300 to 1000 it didn't crash, but no better This and the below was caused by me writing %2 instead of %u (I had experimented with %d) 13Mar2021 014 In top_24_xc.h: Server_node_task: GOES REALLY BAD WITH PRINT_VALUES! EVEN CRASHES. Maybe it's sprintf? 12Mar2021 013 But if I move the [[combine]] tasks to tile[1] it's ok. Even setting on tile[0]: on both pars in TOP_24_HAS_1_TILE_004_T0_4CN_SYNCH_PHASE works! Constraint check for tile[0]: Cores available: 8, used: 3 . OKAY Timers available: 10, used: 3 . OKAY Chanends available: 32, used: 1+. MAYBE Memory available: 262144, used: 41784 . OKAY (Stack: 7372, Code: 31894, Data: 2518) Constraints checks PASSED WITH CAVEATS. 12Mar2021 012 With 2*2 as [[combine]] (it works if not combined on the first two tasks) xrun: Program received signal ET_ILLEGAL_RESOURCE, Resource exception. 0x00041080 in _i.conn_if_t._chan.set_get () 12Mar2021 011 TOP_24_HAS_1_TILE_004_T0_4CN_SYNCH_PHASE seems to run but printing problems 12Mar2021 010 xrun: Program received signal ET_LOAD_STORE, Memory access exception. [Switching to tile[0] core[2] (dual issue)] 0x00040834 in _i.conn_if_t._SServer_node_task_0._c1.set_get (p=0x80020102 "", temp_degC_in=19) at ../src/top_24_xc.h:215 215 case i_conn_0.set_get (const temp_degC_t temp_degC_in) -> temp_degC_t temp_degC_return : { 12Mar2021 009 Put all TOPs out in separate top_..xc.h files xcc1: internal compiler error Failed in /jenkins/RELEASE_14_4/sb/tools_xcc1_c_llvm/FrontEnd/PreCompAnalysis/apply_analysis.cpp, line 795 xf->getSpecializations().size() > (size_t) call->getSpecializationId() 11Mar2021 008 All CONDU_VALS with values 0.04 changed to 0.3 10Mar2021 007 Sent this to Larry, before the commit 10Mar2021 006 TOP_21_HAS_2_TILE_004_T0_4CN_RUNS_FAIR works! Fixed: From Larry 9Mar2021 22.14 (indexing the params from 0,1,2 clock wise to 0:left, 1:vertical, 2:right) The 1.9000 for (0 1):S(1) indicates that the problem I alluded to last time is still there. The calculation of (0 1):S(1) should use wt[i] values equal to 0.050 and 0.075 on incoming temp from [0][0] (i.e. 19.0), and is apparently using 0.025 and 0.075. 09Mar2021 005 DO_PRINT_VALUES is new 09Mar2021 004 Just a commit after mails with Larry. Cleaning of artefacts 09Mar2021 003 Now it seems to work. Observe "TODO" with some constants 07Mar2021 002 Works like xc_test_combinable TOP_20_HAS_2_TILE_004_T0_2N_BY3SUB_T1_2N_BY3SUB_RUNS_FAIR but using float 07Mar2021 001 Initial commit in xTIMEcomposer 07Mar2021 000 Initial */ #endif /* VERSION_H_ */