Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

   Doing things in decimal form maybe looks old fashioned, but it's just a handy smaller size.  For doing the fairly standard carry flag, as in many microprocessors, it's a mess to attempt, directly in optical and multi-digit BUS format.
   Doing a two-digit capable BUS, at 100 individual lines or optical paths, has a counting depth of 100, while the Loop or segment replacing a small loop pass, has a depth of 40.  That way, as long as a counting variable is limited to 40 it will not overflow.  Then, at the bottom of the full pass, the active components (hopefully fast) can do the limit checking using conditional test.
Many cases, a programmer knows where some count is, down through the stack or list, implicitly.  But, for demo purposes let's assume we don't have complete control or predictability, on a count, just only that it won't exceed '40'.
   Those 40 bubbles are not 1 line, but represent a simple run, say less than 10 lines, although could just be 1 line of function.  (Please also see the diagram, having macro-run of 40 little bubble runs, back a few).

[RJSV]

   Doing the way way down functional actions, a 100 line BUS is huge, but the continuous format is interesting and similarly mirrors analog, in positional image view.
   For a Fast Preview, try compress the BUS sizes, to a 'guesstimating' capacity, say at 5 states per BUS word.
Then implement that as co-processing look-ahead, of course using some care with much reduced number capacity.  But might be useful, as super-fast look-ahead at '00' thru '24' range, base 5 radix and all.

[RJSV]

   The fit is not too bad, estimates are a 'cube' at
100 by 100 mm.  Has 250 individual processing elements,...those each being a primitive single digit, and that's on 2 axis, so it's 250 x 250 = 62,500.
   Vertically, it's 40 'bubbles', or they represent the 'Jth' iteration, in a FOR-NEXT LOOP pass
Now, with implicit positioning, the low digit of your iteration count can be left implicit.  The high digit, or 'JH', loop digit, can be decremented, every 10 bubbles, or more informal, is to decrement 4 times, each 'code pass' where that is being done at 40 bubbles per.
   The diagram shows, 4 slices, each can be doing up to approx. 10 lines worth of code.  So...that's an estimate of 400 lines of function, going down thru the 100 layer stack, (likely silicon, at 1 mm thick each).

[RJSV]

A good simple set, for single digit functioning, is shown, having 5 registers, plus another 5 second set.  That way, small routines or segments of code can do roughly 2 moderate tasks, or several simpler
   Often, the upper digit, JH of the loop count 'J', is in right-justified and filled BUS format, ready to go for any analog related use.
As shown, the 2 half's or segments, of processor, can communicate with other 'squares' surrounding, forming crude parallel data network, at least to short distance neighbors (bordering processors).

[RJSV]

   Getting all this to show some function, suppose class 'assignment' is to show the (optical multi-processor), steps, or 'j' iterations, as an analog ramp.
   So, using a Silicon Compiler, the 'Looping' inner code loop, is actually unwound, into 40 separate bubbles, each being 10 lines max , without any real strict reason to be completely repetitive.  Much of that is imposed artificially.
   Looking at diagram, of BUS merging, signal by signal, there is an ideal ratio, about 1 to 10, if horizontal conduit width vs vertical run.  You can see approx that, in one conduit, while when viewing as a whole, from ten line BUS, or at least 9 line, the signal 'run' ratio is closer to 1 to 2...; with the wide, decimal BUS
   BUS Formats, you have to be very flexible, in application of the many.  Some BUS formats wish to self-identity, as 'Base 12, center fill',...so be it.
   Now, those 'j for NEXT' segments have the value incremented virtually, but only in the compiler.  So, for the 'homework' assignment, the low digit implied count value is reversed, for counting downward, in a real register having ten positions (9 for analog weight purposes).
You start at '9', for repetitive ramp outputs, each count value.  So, that happens in every burst or bubble, of up to ten instructions, by compiler inserting the shift-right model, as decrement.
Knowing that value, but still only implicitly, allows you to put a code line, to periodically update the high or second digit.  That saves a ton of hassle, essentially doing the digit to digit carry, explicitly instead of relying on a conditional operation.
Even more of a bonus; the little 1/10 portion split off from upper or 2nd. digit can be used as the light source for the (periodic) reload, of low digit value.  That means laterally transfer, to lower macro-column, and re-define of a lower amplitude standard there.
Picture shows diagram, of Load instruction and vertical to horizontal ratios.

[RJSV]

Diagram of 'Load R with 3'.

[RJSV]

The details, in shifting to do counting ..multi-digit can get lost, between the weeds and alligators, but it's design details like:
   The high or second 'TENS' column digit is decremented first, upon arrival at a roll-over point. That way, that's a count-worth of light amplitude being 'thrown away' that instead can supply, at 10X reduction, the light for the LOAD constant = 9 that initializes the small or 'ONES' digit.
   Diagram showing, how each shift, of the high digit, 'JH', results in that carry or borrow actually, coming out for re-use initializing the lower column

[RJSV]

   More details, on the process of generating a two-digit ramp, counting down (digitally) by way of shifting 'bit flags' so-called because it's not a binary organized BUS.
   (Please also see diagram).  The Fuller view, having a messy set of two BUS passive structure runs, has featured that combiner-redistributer that will produce or source a set of 9 equal-weighted lines, for reinitializing the lower digit, each cycle of decades.
That way, as shown, you go from 31, to 30, to 29; all while properly handling the result to reflect an underflow or borrow, from the 2-digit lower reg. ('JL', held in A1 register, for example).  Upper digit register or virtual register column, is 'JH'.
The separator and diffuser had been mentioned, a while back, for analog.  But...with care, the re-created BUS word can be 'interpreted' in digital terms, by the sensing switches.

[RJSV]

   I figure on the order of 3 pico-seconds, to do the action to shift the BUS, to then compress and redistribute, and finally, to re-enclose or separate the 9 signals...allowing for the re-use by initializing the next set of decrements (shifts), of low digit.
   Full 40 station run, is going to be approx. 2 Ghz rate, of circular calculation sessions.  That's about
500 pico-seconds per loop.  For the case of nesting loops, the For-Next i= 1 to 50, that's a pretty typical outer loop...It's the " j'th " or For-Next j= 1 to 40, that is not really a loop, but a linear bunch of repetitive blocks.
   So, anyway, taking 40 bubbles x 10 lines each, the 500 pico-seconds gets to 500 / 400 or 1.25 pico-seconds per line of 'code'...not bad.
Or, could look at it as, 2 Ghz x 400 lines per pass, or 800 Ghz equiv. doing single integer manipulations.
   That's before accounting for the 62,500 independent processing elements, each with 10 registers.

[RJSV]

   To show the (estimated) run, through a single, 1 mm wafer, perhaps having 100 mm per side, in usable silicon, see diagram.
   Four runs, of ten each will cover the territory, albeit backwards in real registers.  The diagram indicates 4 of those mockup slices, seen in middle rt., the 4 are in series, thru the depth (of the 1 mm wafer).
   You can, at least get a sense for how the count
 run-down, on the larger digit, is sparse, or less frequent, than the low digit, that counts out every 'bubble' there

[RJSV]

   Close-up shows the one bubble, having (up to) ten functional 'code lines', primitives like
   ' Multiply Y1 = Y1 x X1 '.
...or some kind of addition, some diffuser , or BUS splitter of all sorts.
   Notice, this bubble has a decrement, 10 steps out of the 40 available, so in this special case that ramp is getting higher priority, at 25 % of total.

[RJSV]

   Oops, sorry, not quite described right. (This is many new things, at once).
   In the 100 silicon wafers (stacked and aligned), the '40' bubbles of code bursts are interspersed; firstly they have every-other (wafer) but also there is a 'Utility' slice or wafer, every decade, so it turns out there are 4 wafers in every 10 layers, that have the passive BUS manipulating structures (like the shifting).
It's each of those, 40 throughout, but at each burst of ten should be 1 shift (I showed all ten at once, but that's not correct !).
So, with attention to that lower digit 'j' in the For-Next type approach, I had been attempting to show how convoluted or extensive the element count gets,...just to decrement a represented (2 - digit) number.
The decrement is then using 10% or 1 in ten of each bubble.  It got super tedius / boring to draw each if the ten iterations. Actually, in reality those code lines are stretched out, interspersed out into 10X the run shown, (while other functions 'time share'.

[RJSV]

   To employ a little drama, picture shows 10 slices in a wafer, each at 100 microns.
All stretched out, but just one of those, the first paper slip, has a decrement, shown next, but it takes a '39' down to '38', as a first action, in that run of 10.

[RJSV]

Next, here; Picture shows the head of those ten slips, after all ten wafers have been encountered, (at the tenth), this time, the first slot, for the 'j' count-down, is doing a roll-over, '20' down to '19', by explicitly creating a new '9' set of BUS signals, all on.
All this just to show the scale, of having 40 of the wafers giving 10 'instructions' space each.  That's at 100 micrometers per 'instruction', thru the wafer thickness or depth.

[RJSV]

Actually, that last slide bleeds into a couple more slots, in the 10 vertical slots available, owing to the diffuser and re-separator needing another two program steps.

[RJSV]

   For an easy, but fast sawtooth generator, having analog output, this thing does 2 Ghz repetition rate, shown in about 3 full sawtooth waveforms, each completing a cycle in 30 counts, over the 500 picosecond optical loop.  That's 40 samples x 2 Ghz or equiv to 80 Giga samples / sec. counting the extended time the sawtooth stays at zero amplitude, as part of the repeated cycle.
  For questions about speed, consider the two-signal bus line 'reverser' that will create an opposing copy, ON or OFF, each bubble, or (average) at 80 Ghz.  That would actually be at 40 Ghz, as it takes 2 reversals.

[RJSV]

   The time, coursing down thru stack of 100 Silicon wafers, apparently will be:
   400 Terra-hz (Thz), for infra-red 760 nm.
   Then 1,000 cycles of that light spans 760 um, or almost a mm.  So, 1400 cycles gets close, to the
 full 1 mm of a wafer thickness, at IR 760 nm.
Then, at 2.5 Femto-seconds per cycle, (1.0 / 400 x 10 to the 15.), that's:
   2.5 10(-15) X 1400 = 3.5 10(-12) ,
or 3.5 pico-seconds per wafer thickness.

Or, 350 pico-seconds for whole pass, plus 150 for loop recovery, so total is 500 pico-seconds, 10 (-12).
Around a circle shaped path, that's about 3/4 calculating element area and 1/4 is for the recovery and preparation.

[RJSV]

   Happy Holiday!
   Enormous challenge, primitive computational logic, and data transfer layout.  Dentist office chitchat, speculation,...we (self included) had NO CLUE what that's about, aside from visualizing some 'beams crossing'...
   But now, 'enough' engagement to at least be able to vocalize problem (areas) and flesh out some performance limits on the gross or non-quantum effects available.
Currently, examining 'partial rollover' or carry / borrow dynamic, on a 2-digit number, as that is key to effective 'blind' calculating.  (Never making intentional puns, here).  But first, a couple waveform glitches.

   The fast waveform RAMP generation has irregular timed outputs, doing 4 outputs and another 5th time slot without.  Fix for that is to run all the 500 picosecond 'code loops' with regular spaced outputs, instead of skipping.
But a bigger problem showing itself, (viewing slightly older diagram), the 'un-rolled' code loops (using 'j') are rolled out in SPACE,...not time; so you see the repetitions stretched out before you.  Now, with a closed calculation that just spits out one answer at the end, that will work, somehow.  But an analog waveform is a continuous (periodic) output process.
It's as it the 'observer' needs to ride along, at light speed, obtaining each answer on the 'breaking wave', of TIME...(no puns or drama, that's just what it is, today).

[RJSV]

Optical Illusion Teaser, at end, (see photo also).
   Putting out this summary, progress and problems so far.   THEN,...it will be Wednesday,
   PLANES, TRAINS and AUTOMOBILES.
Fun friends, and famulilly !

   The Dividing and multiplying, with various mixing of analog with digital formats, makes interesting tool set, but it was the 'DECREMENT' or integer counting that had surprising results, or partial realizations.
So, in cases of single digit, a multiply, (by 0.8 or by 0.85), serves as substitute for (blind) subtraction, as ratio to 56-1 vs 98-1 as 1 to 50 vs 1 to 100 change.
But a consistent multiply factor (applied blindly to a single digit, 0 thru 9, ) can be optimized for best 'curve' match.
   Using ratiometric (multiply by number between 00 and 99) has a 'residue' that persists, going smaller and smaller.  Another, similar option, uses similar looking operation, but ends up, discrete shifting, completely shifting all empty, due to the physical right shift, of the ten partitioned BUS defined lines.

   But the 'integer' subtraction method gets interesting; instead of usual, roll-over with higher digits that occurs once each ten times, the method, blindly without clue where/when rollover should precisely occur, routine will do, constantly, a '1/10th' rollover, and that is literally done by 'rolling' a one value, every repetition.  That way you still get 10 every 10 times you (decrement).
And while you must 'borrow' from the 'tens' column, a one, and then subtract that, it makes sense to 'JUST DO NOTHING', with low digit, and work on the rest of the task, which is to complete a subtract, of 'one' from the high digit, which represents '10' being moved over, in traditional paper-pencil subtraction protocol.
   The error, however, or mean random error, for a ratio related subtraction, is about in order of one of those (low digit) decrement (virtual decrement).
That's what I've termed an 'Eye for an Eye' type of one for one subtract, by decrement in turn, usually with a zero test for 'j= 0'.  Still not sure about that test, speed wise.
   An alternate way, if For-Next repetitions use a parameter that becomes ineffective, I.E. goes to zero (by discrete shifting), even while the 'loop' continues on, unchecked but also not doing harm...

   A mess, but have to admit; there is enough progress, to be presenting some real snags, areas of frustration (integer-like decrementing), and even an OPTICAL ILLUSION QUESTION:
(PLEASE SEE PHOTO, ENCLOSED).
   Why, when moving head, are those after-images tracked out, from the little light ?  At 232 khz those images, when eyeball 'flicks' around rapidly, those images aren't spaced right, for the speed they supposedly oscillate.

[RJSV]

   The 2-digit format, in a SUBTRACT, or decrement, has some customized features, mainly that the high digit has special limits, (that can't be used in general case, of multiple digits, or floating point style.
So, wishing to avoid any underflow or borrow on case of a 'ones' digit rollover, an actual subtract is done essentially on the high digit,...that being another order of magnitude less than the actual 'tens' column digit.
The usual subtract 1 at once per 10 times is replaced by subtract 0.1 but every time.  That means every time the 2-digit number has to subtract 1.
   It can be confusing, doing this non-standard method, but it helps avoid an underflow situation, on the low digit.  It's all done 'blindly', not knowing which cycle of decrement has an actual low-digit rollover
(from 0 to 9).  The high-digit is only going to really roll-over (underflow borrow) at the very end, of the 2-digit count-down.
Readers can wonder, what about the 'phasing', of roll-overs, where the code running doesn't know, or even worse; actually 'knows' that 9 out of 10 decrements DON'T roll over, but that's O.K.  The subtraction is simply done in different place (high digit), and at ten times less value.  The low-digit, meanwhile, is left untouched...essentially adding a one, each time, as the partial move-over from tens digit, but also then immediately subtracting a one, as the desired function.
Result is just to ignore the low digit, as it is adding 1 and then subtracting 1.
Please also see photo diagram showing the high digit decrement method...in bigger picture meant as portion of a whole complete Word subtracting another Word, like 40-5 = 35 for example.

[RJSV]

  Revisiting for a sec, the light guide conduits, or paths, (pls see diagram) the size of one gate or processing element compares nicely with some wavelengths used.
   Roughly 100 microns across, and approx twice that in run length, you can observe; each of the ten conduits is on order of 10 microns.  That compares with 760 nm wavelength at about 15 full wavelengths; hopefully that's enough to, barely, get up out of heavier quantum or diffraction effects, and more in just simple bulk light mode.

[RJSV]

   O.K. Team,...Listen up:
   We need, (put on your 'M.I.G.A.' hats) we gonna need a re-integerize or re-quantize electronic / optical function.  Something to clear the residue or residual analog error, after a modest sweep doing some increments or decrements.  Right now, it's basically real numbers on each iteration (loop count).
   Arriving at loop 'bottom', after a modest number of decrements, (like 50 decrements of real number), the idea is to trim or clear the residual value, perhaps using a flash compare, rather than full AtoD.
   So a pseudo-integer, like " 41.13 " would be adjusted, to the correct integer form; " 41 ".
A digitally processed integer can be, conventionally, maintained forever, in continuously applied functions as the discrete nature allows for 'perfect' real world continuity.  For example, add + 4 followed by
subtract 4, repeating, is never going to 'drift'.
   So, analog / optical design Engineers; put on your
  'M.I.G.A.' hats; we need a set of terminus processors, very fast, to restore the loop integers, to prepare for another, fast, optical journey, down the 'code stack'.

-- Thanks for reading.
--Rick

[RJSV]

Ah shit, forgot to say;
   M.I.G.A.  (hats) stands for
   'Make Integers Great Again'

[MK14]

Maga Hats:

Make
Autonomous
Gyro-light Optical Digital switchers, Great
Again

[RJSV]

   I like your hat better, mine is too obscure, for general consumption.

   How's about some more criticism, seriously, this thread needs some more reality checking.
From a project management standpoint, I never would have thought the theoretical development would make it THIS FAR, let alone the hurdles ahead.

   MORE criticism, pleaaze. Thanks