From f1d67cfe5fac36147bac55245e592de765384094 Mon Sep 17 00:00:00 2001 From: David Allemang Date: Mon, 22 Jun 2026 17:32:41 -0400 Subject: [PATCH] wip tileset explanation --- content/interference-fixes.typ | 90 ++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/content/interference-fixes.typ b/content/interference-fixes.typ index 47e6286..f8e43af 100644 --- a/content/interference-fixes.typ +++ b/content/interference-fixes.typ @@ -1,9 +1,99 @@ +#import "/lib.typ": todo + = Preventing Interference +The protocols as described are very sensitive to the exact timing that the EID counter is +incremented. The fundamental cause for all types of interference is that we spawn a reference and +measurement item with too much delay, and some unexpected entity (or entities) spawn in-between. To +mitigate interference, then, we need that window to be *as short as possible* while still allowing +us to spawn transmission entities in that window. + == Tilesets +The fundamental principle here is to use tile-tick priority (TTP) to set a global order. See +Charlie's great video on TTP for details. #todo[link video] + +The core principal is that repeaters have higher priority than other components. For example, if a +repeater and comparator are scheduled to activate in the same tick, the repeater always (with one +exception, if the comparator faces into a diode and the repeater does not) activates before the +comparator does. By choosing a regular building pattern, we can avoid this exception entirely. + +// Among repeaters, they activate in the order in which they were scheduled. And among comparators, +// they activate in the order in which they are scheduled. But every repeater activates before any +// comparator (aside from that one exception). This gives us a *stable sort* which we can use to +// globally define update order with arbitrary precision. + === Binary +The simplest tilesets are made entirely of comparators and 2gt repeaters. Repeaters activate before +comparators, so if we think of it like sorting words alphabetically, we can identify repeaters with +"A" and comparators with "B". + +So, suppose we have a "binary tileset" that is 2gt long. There are two options, A and B. If we +alphabetize these, we see the A (repeater) always executes before the B (comparator). With such a +short tileset, that seems trivial; things get more interesting as we add more elements. + +``` +<-- +cmp (B) +rep (A) +``` + +Now let's use 2 components for a 4gt tileset. There are now four options, AA, AB, BA, BB. We can +alphabetize these and see the order. + +``` +<------ +cmp cmp (BB) +cmp rep (BA) +rep cmp (AB) +rep rep (AA) +``` + +To break this down: the bottom two (AA, AB) end in repeaters, so they must come first. Among those, +(AA) comes first. Among the top two (BA, BB), (BA) comes first. It's standard alphabetizing. Just as +the order of the alphabet creates an ordering over all words, the ordering of the comparator and +repeater creates an ordering of all tilesets. + +The 6gt tileset. There are now eight options. + +``` +<--------- +... +``` + +As the tilesets get larger, it's less useful to lay out the entire tileset and more useful to find +the next and previous lanes. + +For example, take this 7-diode tileset. + +``` +cmp rep rep cmp rep cmp cmp +<-------------------------- + B A A B A B B +``` + +We can easily find the next lane by thinking of this not as a *word* but as a *number*. We have two +options, and one is greater than the other. + +``` +cmp rep rep cmp rep cmp cmp +<-------------------------- + B A A B A B B + 1 0 0 1 0 1 1 +``` + +We can think of this tileset as a 7-bit binary number, in this case the value 75. We can find the +next lane by simply incrementing by one. + +``` + 1 0 0 1 0 1 1 (75) + + 1 + 1 0 0 1 1 0 0 (76) +<-------------------------- +cmp rep rep cmp cmp rep rep +``` + === Lexicographic === Mixed Priority Jamming