Public

Thread: PRBS31 implementation

60 Discord messages from 📐 - Designing/🕰️-analog/threads/prbs31-implementation.md.

Category: 📐 - Designing Parent channel: #🕰️-analog Thread ID: 1513236128239456406

Messages: 60

message-1513236133138399433

2026-06-07T17:40:08.708+00:00 — RebelMike (@rebelmike)

Content

Repo here: https://github.com/MichaelBell/prbs31

Embeds

<details> <summary>Embeds data</summary>
[
  {
    "color": "#1E2327",
    "description": "Quick implementation of PRBS31. Contribute to MichaelBell/prbs31 development by creating an account on GitHub.",
    "fields": [],
    "images": [],
    "inlineEmojis": [],
    "thumbnail": {
      "height": 600,
      "url": "2026-06_media/prbs31-2A6E7",
      "width": 1200
    },
    "timestamp": null,
    "title": "GitHub - MichaelBell/prbs31: Quick implementation of PRBS31",
    "url": "https://github.com/MichaelBell/prbs31"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513236181247197275

2026-06-07T17:40:20.178+00:00 — RebelMike (@rebelmike)

Content

Realised we should probably go to a thread to reduce spam
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513236602556649633

2026-06-07T17:42:00.626+00:00 — namibj

Content

yeah thread good.

And no, I am after a power-of-two number of outputs per cycle, probably 32.

Reactions

<details> <summary>Reactions data</summary>
[
  {
    "count": 1,
    "emoji": {
      "code": "thumbsup",
      "id": "",
      "imageUrl": "2026-06_media/1f44d-27259.svg",
      "isAnimated": false,
      "name": "👍"
    },
    "users": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike"
      }
    ]
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513237060817784944

2026-06-07T17:43:49.884+00:00 — namibj

Content

the fastest data latches are planned to be quarter the output baudrate; the VCO is supposed to run at half the output baudrate
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513237359955808256

2026-06-07T17:45:01.204+00:00 — namibj

Content

I'll know more about what those mean in GHz in a few hours when I have drawn some cells and did a bit of PEX on them to see what GBW I can hope for once I include the need for loads and at least some amount of routing parasitics.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513237596396847144

2026-06-07T17:45:57.576+00:00 — namibj

Content

the PRBS has to in all cases reliably keep up with the baudrate though.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513237748490829894

2026-06-07T17:46:33.838+00:00 — namibj

Content

basically up to where it produces substantial BER at the output data bit latches or such
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513238140599537695

2026-06-07T17:48:07.324+00:00 — namibj

Content

I _think_ I can hope for approximately 15 Gbit/s tops, I _hope_ 10GBASE-KR is decently practical to hit with some amount of margins overall.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513238369168265267

2026-06-07T17:49:01.819+00:00 — namibj

Content

Faster would require inductive peaking throughout many parts of the serializer and I do not have infrastructure for planning/simulating the interactions of so many inductors in close proximity.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513238613356445776

2026-06-07T17:50:00.038+00:00 — RebelMike (@rebelmike)

Content

OK, I'll keep one more bit to give you the 32 bits.

This is using Tholin's 3v3 library, clock report says fmax of 348MHz at the worst corner.  So that hopefully won't bottleneck you.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513238881703559358

2026-06-07T17:51:04.017+00:00 — namibj

Content

(I can get about 28 GHz GBW out of the transistors and I only "need" 1.12x the bitrate to theoretically make it behave.... but it'd be unusable without a decent bit of inductive peaking around the final MUX's.)
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513239093088354334

2026-06-07T17:51:54.415+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1513236128239456406",
  "guildId": "1361349522684510449",
  "messageId": "1513238613356445776"
}
</details>

Content

How pessimistic is that estimate?
I'm aiming for the tt corner btw.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>

message-1513239402007101703

2026-06-07T17:53:08.067+00:00 — RebelMike (@rebelmike)

Content

I would normally say fairly pessimistic, though Tholin's library is not well characterised so it's all a bit finger in the air!  nom_tt_025C_3v3 is saying 460MHz
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513239660829343745

2026-06-07T17:54:09.775+00:00 — namibj

Content

ohhh yeah those numbers I like a good deal more.
I assume it could be told to be somewhat faster if that's put as a constraint? Just in case the serializer predictions come to desire a bit more.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513239852311773397

2026-06-07T17:54:55.428+00:00 — namibj

Content

also notably I don't care about how it gets initalized it just can't be all-0's.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513240033073692905

2026-06-07T17:55:38.525+00:00 — RebelMike (@rebelmike)

Content

I can ask but given how simple everything is I don't know whether that would actually change anything.  Removing `en` would probably help if you don't need it.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513240036454301757

2026-06-07T17:55:39.331+00:00 — namibj

Content

wait
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513240183108141277

2026-06-07T17:56:14.296+00:00 — namibj

Content

that code snipped you gave me there, in #🕰️-analog , that only computes one bit per cycle.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513240455037452413

2026-06-07T17:57:19.129+00:00 — namibj

Content

I don't need enable the clock feed to that section is from the serializer anyways; what it would possibly want/need is selecting the user input of the digital tt mux instead
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513241088234885120

2026-06-07T17:59:50.095+00:00 — namibj

Content

This is iirc not the right view of the polynom, but it's an LFSR with vaguely similar tap structure in some view and the correct output width:

```verilog
module prsg31_stream32 (
    input  wire        clk,
    input  wire        rst,   // synchronous, active-high
    input  wire        en,
    output reg  [31:0] out
);

    reg [31:0] lfsr;

    always @(posedge clk) begin
        if (rst) begin
            lfsr <= 32'hffff_ffff;
            out  <= 32'hffff_ffff;
        end else if (en) begin
            lfsr[31:16] <= lfsr[30:15] ^ lfsr[27:12];
            lfsr[15:4]  <= lfsr[14:3]  ^ lfsr[11:0];
            lfsr[3:1]   <= lfsr[2:0]   ^ lfsr[30:28] ^ lfsr[27:25];
            lfsr[0]     <= lfsr[30]    ^ lfsr[12];

            out[31:16]  <= lfsr[30:15] ^ lfsr[27:12];
            out[15:4]   <= lfsr[14:3]  ^ lfsr[11:0];
            out[3:1]    <= lfsr[2:0]   ^ lfsr[30:28] ^ lfsr[27:25];
            out[0]      <= lfsr[30]    ^ lfsr[12];
        end
    end

endmodule
```
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513241737231990994

2026-06-07T18:02:24.828+00:00 — RebelMike (@rebelmike)

Content

Ah, you want 32 cycles per clock?  That makes sense.  I hadn't found a spec - just read wikipedia 😄
It's possible this does the right thing: https://github.com/mgwang37/PRBS/blob/master/Verilog/prbs_generator.v#L336-L372

Embeds

<details> <summary>Embeds data</summary>
[
  {
    "color": "#1E2327",
    "description": "Pseudo-Random Binary Sequence. Contribute to mgwang37/PRBS development by creating an account on GitHub.",
    "fields": [],
    "images": [],
    "inlineEmojis": [],
    "thumbnail": {
      "height": 600,
      "url": "2026-06_media/PRBS-D9579",
      "width": 1200
    },
    "timestamp": null,
    "title": "PRBS/Verilog/prbs_generator.v at master · mgwang37/PRBS",
    "url": "https://github.com/mgwang37/PRBS/blob/master/Verilog/prbs_generator.v"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "inlineEmojis": [
      {
        "code": "smile",
        "id": "",
        "imageUrl": "2026-06_media/1f604-BF863.svg",
        "isAnimated": false,
        "name": "😄"
      }
    ]
  }
}
</details>

message-1513241949010919534

2026-06-07T18:03:15.32+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1513236128239456406",
  "guildId": "1361349522684510449",
  "messageId": "1513241737231990994"
}
</details>

Content

I sent you spec from the 802.3
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>

message-1513242377861730455

2026-06-07T18:04:57.566+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1513236128239456406",
  "guildId": "1361349522684510449",
  "messageId": "1513241737231990994"
}
</details>

Content

see DM btw for link
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>

message-1513242610729222425

2026-06-07T18:05:53.086+00:00 — RebelMike (@rebelmike)

Content

Thanks - got it.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513243046370869258

2026-06-07T18:07:36.951+00:00 — RebelMike (@rebelmike)

Content

I need to go get some food and stuff, I'll be back later.  But theoretically that shouldn't slow things down too much I think, just increase area a bit.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513244446907433111

2026-06-07T18:13:10.865+00:00 — namibj

Content

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "Screenshot_2026-06-07-20-13-00-12.jpg",
    "fileSizeBytes": 424433,
    "id": "1513244446437933086",
    "url": "2026-06_media/Screenshot_2026-06-07-20-13-00-12-64BD7.jpg"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513244660301041756

2026-06-07T18:14:01.742+00:00 — namibj

Content

This would be the "alternative" pattern genrator thing that would be of some amount of applicable relevance; I don't think it'll be easier/cheaper/faster to do, though.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513245061993730359

2026-06-07T18:15:37.513+00:00 — namibj

Content

I'd guess one could hard-set the input to be `1` and then it might not need explicit initializing.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513245266617176295

2026-06-07T18:16:26.299+00:00 — namibj

Content

as it might not be vulnerable to lock itself up as the left XOR would act as an invert instead between the output of the right XOR and the input to S0
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513251969949634863

2026-06-07T18:43:04.498+00:00 — namibj

Content

Basically I'm not that worried that LFSR thing can keep up, it's more that the optional direct input serialization would need to be combined in a way that's not a slowdown.

And there's some control bits that need to be provided latched (clock glitches expected if that glitches) to notably adjust the VCO's loads for slow mode. The partial positive feedback has to cause sufficient differential amplitude at the reduced tail current.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513252212808224940

2026-06-07T18:44:02.4+00:00 — namibj

Content

But as I said this isn't needed until I have enough progress to suggest that I can get the serializer made in time.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513258597445013704

2026-06-07T19:09:24.616+00:00 — namibj

Content

Though, the one notable thing, if you could provide some insight on how large it would be to provide two shifted versions of the parallelized bitstream of whatever is fed to the serializer, for a total of 3 copies that are spaced exactly 1 bit, with two of them optionally inverted, plus some about 10 control bits, that'd be great to know.

The final outputs from the digital section to the serializer will be SDR clocked and need to be provided as pairs of `bit[I]`/`not(bit[I])` because they are consumed by differential current mode logic.

If it's not too expensive to do those couple control bits and the two optionally-inverted (that'd be control bits that stay in the digital section) single-bit-each shifted stream copies, it might even be realistic to do a 3-tap FIR TX EQ.

If it's easy to do those copies I would do them at a faster stage of the MUX as it would be cheaper than so many wide slow speed MUXes to collect them all up to some decent speed.
Like, at 8-wide perhaps.
Note that we don't have flip flops but we do have two nice symmetric clock phases and the latches we have freely allow phase selection.
And MUX2 are also fast and fairly cheap.
Especially if their select inputs are driven by CMOS voltage levels.
And ofc data inversion is literally free because it's just crossing the wires.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513270802328588358

2026-06-07T19:57:54.487+00:00 — RebelMike (@rebelmike)

Content

For the shifted version - that should just be wires (plus maybe remembering a couple of bits?), and XORs for the optional inversions are not huge.  The main area will be all the flops for the final output from the digital section, I'm not sure what width you're aiming that to be but with 3 versions each in +/- pairs that's going to be the majority.  Switching those for latches could help but you'd need the input to the latch to be stable for half the clock cycle so it might reduce fmax.
I'm not sure what you mean by ~10 control bits - what are they controlling?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513271017466892471

2026-06-07T19:58:45.78+00:00 — namibj

Content

Oh I thought the inversion would be after the storage of the flop.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513271337076920374

2026-06-07T20:00:01.981+00:00 — namibj

Content

The 10 control bits would depending on being set or not either connect a tail current cell to a current mirror gate voltage or disconnect from there and instead clamp to GND.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513271455490768916

2026-06-07T20:00:30.213+00:00 — namibj

Content

they'd be setting drive current for the non-main taps
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513272032429871307

2026-06-07T20:02:47.766+00:00 — namibj

Content

If it's possible to do that cheaper after the initial like 2 layers of CML MUX (32->16->8->shift_spawn->4->phase_align->4->MUX2->amplifier->MUX2->PA)
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513272113555836969

2026-06-07T20:03:07.108+00:00 — namibj

Content

the numbers are parallel latch quantity for a single output tap
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513274329922801836

2026-06-07T20:11:55.531+00:00 — RebelMike (@rebelmike)

Content

Inversion after the flop makes sense, just need to be careful with asymmetric delay.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513274760534950009

2026-06-07T20:13:38.197+00:00 — namibj

Content

to an extend, I guess...
It'd get latched up pretty much right away though, the one benefit could be if cheap to provide half of them synchronized to the other clock edge to skip a second latch on the CML side to shift appropriately.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513274917984927934

2026-06-07T20:14:15.736+00:00 — namibj

Content

I'm bad at estimating the gf180mcuD logic density  for now at least
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275327252791426

2026-06-07T20:15:53.313+00:00 — namibj

Content

and I've not yet figured out how complex it'd be to do the shifted version at the 8-wide stage in CML instead.
Gates to use are level sensitive latches, MUX2, and BUF. Inversions are free.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275408278097990

2026-06-07T20:16:12.631+00:00 — RebelMike (@rebelmike)

Content

I got some CI set up, and implemented the 32 iteration unroll thing: https://github.com/MichaelBell/prbs31/actions/runs/27103395235
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275456768708628

2026-06-07T20:16:24.192+00:00 — namibj

Content

if you say it's not expensive and will be straight-forward to do I'll just keep that in mind.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275692606029845

2026-06-07T20:17:20.42+00:00 — RebelMike (@rebelmike)

Content

You can pretty easily play with that to see what's what, librelane should size the block appropriately.  Doing the unroll made basically no difference to size or speed
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275746087604477

2026-06-07T20:17:33.171+00:00 — namibj

Content

I just know that last time I tried to understand I kinda got a headache instead of a solution.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275830791307555

2026-06-07T20:17:53.366+00:00 — namibj

Content

C.f. this as reference:

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 411613,
    "id": "1513275830430601378",
    "url": "2026-06_media/image-23FA8.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513275953286217912

2026-06-07T20:18:22.571+00:00 — namibj

Content

I'm not doing latches at the C2 clock though, that's MUX2/BUF instead
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513276152163340531

2026-06-07T20:19:09.987+00:00 — namibj

Content

and due to that I can't use this architecture of cooking up a total of 4 taps for nearly free
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513276935621316679

2026-06-07T20:22:16.778+00:00 — RebelMike (@rebelmike)

Content

Interesting - I think I see where you're going - I see why you want the offset streams
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513277321182969937

2026-06-07T20:23:48.703+00:00 — namibj

Content

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 111140,
    "id": "1513277320897626282",
    "url": "2026-06_media/image-E4F36.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513277500514635928

2026-06-07T20:24:31.459+00:00 — namibj

Content

those are example settings for the 3 taps btw
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513279823915778088

2026-06-07T20:33:45.401+00:00 — namibj

Content

https://people.engr.tamu.edu/spalermo/ecen689/lecture7_ee720_eq_intro_txeq.pdf  page 16 tooo
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513280160617463899

2026-06-07T20:35:05.677+00:00 — namibj

Content

can't paste any more screenshots for some reason idk why that's broken, locks my brwoser up for 20 seconds each time I even try
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513282421800566946

2026-06-07T20:44:04.785+00:00 — namibj

Content

ahhh this works at least

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 767012,
    "id": "1513282421725073558",
    "url": "2026-06_media/image-EE1CA.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513282441375387869

2026-06-07T20:44:09.452+00:00 — namibj

Content

shows the massive difference
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513310123911680160

2026-06-07T22:34:09.483+00:00 — namibj

Content

https://people.engr.tamu.edu/spalermo/ecen689/low_power_link_lee_jssc_2000.pdf [Lee JSSC 2000]
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1513315213510705162

2026-06-07T22:54:22.938+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1513236128239456406",
  "guildId": "1361349522684510449",
  "messageId": "1513276935621316679"
}
</details>

Content

If you can tell(/soon show how) doing it at an 8-wide moment would be practical, I'd be quite ears. The 8:4 mux that comes after would want half the input latches at one clock phase and the other half at the inverted clock phase, basically having the input latches transparent exactly while that input side isn't selected by the single-wide MUX2 that particular latch is feeding into.

Unfortunately the slower clocks won't be too edge-aligned to the faster ones as they're just made from a pair of latches with opposing clocks who's data is fed back to each other.
I think there'll be easy opportunity to at least mint quadrature for some deserving applications as we might as well tap both latches of such a DIV2.

Boosting the amplitude into the clock of the primary (fastest) DIV2 is expected to be quite important to make it reliable; the only other place where a 2-level MCML gate (2 series nmos sitting on the tail current source, before the steered tail current gets to see the load resistors) has to operate that fast is the final MUX2 that immediately feeds into the pre-driver (a buffer chain culminating in the digitally-selected-tail-current output driver for that tap; it's basically just a differential pair with the (pull-up) loads being off-chip).
And those MUX2 there are fed by boosted MUX2 not by weakly regenerating latches.

Like, those second-to-last MUX2 probably get the privilege of quadrature clocks and an output booster (just a single buffer) that should conspire to provide just enough hold time for the final MUX2 to not really feel that.
Though I'd probably have to... ehhhh as annoying as it feels, it's probably gonna have to be some semblance of a C4 architecture, now that I manage to fully grasp [Lee JSSC 2000] just having flipped the selection and the data transistor levels by splitting the lower ones in two to move all fan-out the the very bottom.

Solves the issue of needing aligned quarter and half rate clocks, by instead using quadrature quarter-rate clocks directly.

I guess the good thing is that _technically_ that input-multiplexer itself architecturally doesn't actually need to provide current gain to work.
So ensuring it's fed strong and the output is aggressively pre-amplified before it hits the controlled output current PA, should probably suffice to make it work.
No more latches driven with what's a DDR clock w.r.t. the output.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>

message-1516087645065842688

2026-06-15T14:31:02.13+00:00 — namibj

Content

@RebelMike Ok I got time off until the deadline.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>

message-1516660954140643459

2026-06-17T04:29:09.665+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1513236128239456406",
  "guildId": "1361349522684510449",
  "messageId": "1513276935621316679"
}
</details>

Content

Figured out how to do it "scalable" for the C4 architecture....

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "mux_tree-C4_for_FIR.png",
    "fileSizeBytes": 296824,
    "id": "1516660953888850001",
    "url": "2026-06_media/mux_tree-C4_for_FIR-3BCD7.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-06_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-06_media/49aaff687e56f04e7bbdedf0077bab75-7DDB4.png",
        "color": null,
        "discriminator": "0000",
        "id": "691780627338625077",
        "isBot": false,
        "name": "rebelmike",
        "nickname": "RebelMike",
        "roles": []
      }
    ]
  }
}
</details>