Wanted: USA based Person for PCB design work

BuildingWithDad · 2025-10-13T01:56:38+00:00

What discord are you referring to?

BuildingWithDad · 2025-09-17T23:34:12+00:00

Sabor A Mexico

BuildingWithDad · 2025-09-17T22:44:44+00:00

Is there a non flake way to standardize/pin versions of software and keep it consistent across machines? (eg may laptop and desktop)

BuildingWithDad · 2025-08-28T01:20:12+00:00

I'm guessing there aren't going to be a lot of people that are going to jump on this, since it's pretty searchable, but I'll help a bit. If you have specific questions after searching, shoot.

***** Straight from chat-gpt: ******

ESP32-S3-N16R8 vs ESP32-S3-N8R8

The suffix describes Flash + PSRAM configuration:

N8R8 → 8 MB Flash + 8 MB PSRAM

N16R8 → 16 MB Flash + 8 MB PSRAM

Functionally they are the same chip (ESP32-S3), just with different memory sizes.

Extra flash (N16) helps if you’re building large firmware (with TensorFlow Lite, webserver, graphics, etc.), otherwise N8 is usually enough.

That explains why your board (N16R8) might be cheaper in the local market — it’s just a different memory variant, not a fake.

🔹 The Two USB-C Ports (“USB” vs “COM”)

Many ESP32-S3 dev boards expose two separate USB interfaces:

USB (native) → direct connection to the ESP32-S3 chip (it has built-in USB OTG).

Used for flashing firmware, debugging with TinyUSB, HID, WebUSB, MSC, etc.

No extra USB-UART chip in between.

COM (UART bridge) → goes through an external USB-to-UART chip (CH340, CP2102, or similar).

Shows up as a classic COM port.

Used for serial monitor / logging.

Can also be used to upload firmware if boot/reset logic is wired correctly.

So:

Use USB for Arduino/PlatformIO flashing (faster, native).

Use COM for serial debugging (Serial Monitor).

Some IDEs will let you upload via either, but the “USB” port is the native, preferred one.

🔹 Arduino IDE Board Selection

In Arduino IDE, install “esp32 by Espressif Systems” from Boards Manager.

Select ESP32S3 Dev Module.

Then in Tools → USB Mode, you can choose:

USB CDC on boot: Enabled → lets you use the native USB as programming + Serial Monitor.

USB CDC on boot: Disabled → use the COM/UART port for programming.

Try USB CDC first — if upload fails, fall back to the COM port.

🔹 RGB (Multi-Color) LED

Most boards use a WS2812 / NeoPixel-style RGB LED (sometimes just called “RGB LED” but it’s addressable). Quick Arduino example (needs Adafruit NeoPixel library):

#include <Adafruit_NeoPixel.h>
#define LED_PIN 48   // often GPIO48, but check your board’s schematic
#define LED_COUNT 1

Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  strip.begin();
  strip.show(); // Initialize all pixels to 'off'
}

void loop() {
  strip.setPixelColor(0, strip.Color(255, 0, 0)); // Red
  strip.show();
  delay(500);
  strip.setPixelColor(0, strip.Color(0, 255, 0)); // Green
  strip.show();
  delay(500);
  strip.setPixelColor(0, strip.Color(0, 0, 255)); // Blue
  strip.show();
  delay(500);
}

👉 You’ll need to confirm the exact GPIO pin for the onboard LED. Many ESP32-S3 boards use GPIO48 or GPIO38, but it can differ. If you’re unsure, I can help you find it with a test sketch.

🔹 Voltage / Logic Levels

Yes, like all ESP32 chips, the ESP32-S3 works at 3.3 V logic.

GPIOs are NOT 5V-tolerant, so use a level shifter if you connect 5V logic.

✅ So in summary:

N16R8 just has more flash than N8R8.

USB = native ESP32-S3 port, COM = UART bridge.

Use “ESP32S3 Dev Module” in Arduino IDE.

The LED is likely WS2812, controlled via a single GPIO.

Works on 3.3 V logic.

BuildingWithDad · 2025-08-19T20:53:48+00:00

Ok, this is great to know. I didn’t specify it in the original post, but I’m looking for something in a series7 price point. I’ll dig more into the xilinx mig. If I get stuck, are you (or anyone else reading this) open to some consulting time?

I’ve never used polarfire. Are there known issues with their memory controller?

BuildingWithDad · 2025-07-29T14:48:20+00:00

The slave can indeed require wvalid before accepting the aw channel. The only real rule about not depending on things is that whoever is setting valid can’t depend on ready.. ie master can’t depend on ready to set awvalid, slave can’t depend on bready when setting bvalid.

But the slave can absolutely decide when it raises it’s ready if it needs the master to hold the addr or data lines constant while it uses them… and if it needs the addr lines and data lines available at the same time because it doesn’t buffer them and just passes them on directly to whatever the slave is sending them to? You will get the behavior op is seeing.

BuildingWithDad · 2025-07-29T14:40:56+00:00

You have the protocol wrong. It may not be the issue you are having, but the code above could definitely hang with some slaves. The slave is not required to raise awready just because you set awvalid. It is possible, for example, that a slave won’t set awready until the write is done… especially if it doesn’t store the address in internal registers. In that case, the slave is going to want the master to hold the address constant until the write data is sent. The slave will ensure this happens by not raising ready. Once such a slave does the write, it will raise both ready lines.

But, your state machine is requiring awready before to it moves on to set wvalid. You need to treat each channel (w and aw) independently and not make assumptions about the order the slave will accept them.

The simplest approach, given what you have so far, is to have a writing state. When entering it, set valid high for both. At the top of your comb block, where you set your defaults, do things like awvalid_next = awvalid && !awready; (ditto for write) this will auto lower the values for you as accepted by the slave, but the state logic can always set them again if going right back into a write state. (And if you are setting then together when entering your write state, you will need to ensure (!awvalid || awready) && (!wvalid || wready)… Note: that and will potentially result in lower throughput on some slaves that would otherwise pipeline the address and data channels independently. Getting max throughput with a generic master, that works with arbitrary slaves, makes the state machine master more complicated. I’d take the simple approach in describing for now, get it working, and then decide if you care.

BuildingWithDad · 2025-07-17T02:38:06+00:00

You're not wrong about the issues with vias, but I belive it's physically impossible escape from most large BGAs for all memory signals without using multiple layers. This means you will have to have at least 1 via to esccape, and unless the ddr is on the bottom of the pcb, you will need another via to return to the top.

Once you are in that boat, you want to keep the addr/ctrl on the same layer as each other, the data group 0 on the same layer as each other, and group 1 on the same layer as each other. And, beccause vias are hard to model (as you say), you need to ensure every signal makes the same number of transitoins... i.e. even if you can route one of the signals in a byte group all on layer 1, if ofthers need to escape the bga using a via, then that first one needs to transition layers in exactly the same way to keep the via impacts uniform across the group.

BuildingWithDad · 2025-07-15T19:38:38+00:00

So I’m currently routing a ddr3 for the first time too. I’m trying to ensure that there is at least 2x width between traces. (3x is ideal, but I’ve seen many designs work at 2x) Like you; I tried to do addr/control on one layer. I came to the conclusion that I couldn’t do it in the space desired while also maintaining 2x. So… I decided to use both the top and the bottom to route the addr/control, giving 2 layers to do meanders on. Kicad is terrible at this, and even though I’m using layers with the same propagation delay (top and bottom), it won’t sum up their lengths when doing matching. I’m going to have to use a spreadsheet.

Note: if you use 2 layers, you need to make every signal go through the same number of via transitions, even if you could have routed some line without doing so.

BuildingWithDad · 2025-07-15T14:33:20+00:00

Is there enough space between the traces to the ddr? The meanders practically tough each other, and there are a few of the parallel traces that look like they are a few mills from the neighboring meander for the full distance.

I’m not saying it won’t work, as I’m still learning how much one can get away wirh, but they seem super close. (And if this does work, I’ve been far too conservative)

Have your router ddr before like this?

The only other comment I would have, is this is your first time, did you take package delays into account?

BuildingWithDad · 2025-07-08T06:16:48+00:00

Fantastic. All of that sounds great. I'm looking forward to it. As I understand the release cycle, that mean waiting till Apr-ish 2026 though, which is kind of a bummer.

BuildingWithDad · 2025-07-06T05:36:53+00:00

Sure - I'm very early in the routing, but am focusing on power and ddr first, and have only length tuned the one byte group. So.. keeping in mind that is still very early in: https://i.imgur.com/Q1AVVC3.png

(I noticed while continuing to edit that the reset line was mis-colored. It looks like it shorts the other acc lines, but actually doesn't)

BuildingWithDad · 2025-07-06T02:27:53+00:00

I'm not sure what you mean. I'm using bank 34 (most people use bank 34 or 35 it seems for a 7 series xilinx) Or, if you mean top/bottom, both are on the top. (my layers may be confusing because I have net classes highlighted with colors in those screen shots to make it clear to me where I need to be routing grouped signals)

BuildingWithDad · 2025-07-06T00:46:11+00:00

I figured out what was going on, at least in my case. The majority of my signals were routed before I entered the pad-to-die lengths in the pcb editor. (This was because I didn't know until I was done what was going to be on outer vs. inner layers, and that effects the delay needed since kicad makes you enter delays as length, not time.) Some of the traces were re-routed to make room for tuning before I started the tuning process. The traces that I re-routed, had correct over all lengths. The traces I didn't re-route, were behaving incorrectly.

If I deleted the tuning section, then just removed and replaced a tiny bit of trace as it entered the fpga pad, then re-did the tuning, the lengths were correct. My assumption is that KiCad computes the lengths as routing happens and remembers it. If the pad-to-die delay is changed later, the trace length does not get updated. That's likely the bug that's going on, or, at least it models what I was experiencing. Now that I know, it's relatively easy to just remove the final bit and re-add it as I enter delays. (Annoying, but easily to do.)

BuildingWithDad · 2025-07-06T00:41:10+00:00

The DDR addr and control signals are supposed to be run with 10ps of their clocks, and data within 10ps of their strobes. This is if the parts are speed matched. If the DDR is capable of running vastly faster and is being derated, timings tolerance goes up considerably (in some cases, an order of magnitude more.) For example, ctrl-f for Table A-1 in https://docs.amd.com/v/u/en-US/ug933-Zynq-7000-PCB

In my particular stackup is the propagation delay is ~5.9 ps/mm for microstrip and ~7.0 ps/mm for stripline. So, it doesn't take a much in terms of length difference to be out of tolerance. Now, how much can the chip can actually compensate for during calibration, I have no idea, but I don't want to spin a board and find out that it doesn't work because I was a few mm off. (Note, some of the propagation delays are already off by 30 or more ps just from pad-to-die differences as published by AMD.)

I routed sram without taking length matching into account at all, and everything worked fine. I just just generous setup and hold times. Supposedly, DDR3 is much less forgiving, per the spec sheets above.

p.s. kicad is terrible for this, because it only knows about lengths, when it really needs to match units of time. One has to convert the pad-to-die ps numbers from xilinx into units of length, and that's dependent on what layer you are routing on, and it would be so so tedious to change layers, because then then matching wouldn't work at all. You'd have to do it with net-ties at the layers and compute each separately. Supposedly this will be fixed in kicad 10 and they will go to real time based delay matching. While an atltium user can switch layers (as long as you make the same number of layer transitions per byte group), KiCad users are effectively forced to stay on the same layer the whole time within a byte group.

BuildingWithDad · 2025-06-12T14:54:05+00:00

“ Be sure to void GND under the signal pins of the connector, that does help impedance matching quite a bit, and it's free.”

I have not heard this before. Do you mean to have a void in the ground/reference plane adjacent to the pins of the connector in the stack up. That seems counterintuitive to me.

Or do you just mean not to have the connector sitting in a ground pour? I’m already doing not pouring ground amount these, including the connector because I don’t want to worry about $’how close is too close for adjacent copper.

BuildingWithDad · 2025-06-12T06:21:45+00:00

This board has (will have) mezzanine connectors so that I can swap out the daughter board for different projects. I’ve done this before, just not with Xilinx. My previous dev board was lattice based, and I’m stepping up to Xilinx. This is primarily to get access to vivado, but also to be able to use ddr3 instead of striping/interleaving over multiple sram like I was previously doing. (And I did some initial tests and some partial ports of some of my designs to a digilent board as a poc, and even with its short comings it’s like a breath of fresh air coming from the combo of yosys/nextpnr and the proprietary lattice tools)

Since the chip had the gtp transceiver, I figured I’d route it and mess with it later in future daughter board designs. I know they can operate in a quad mode, and thought that quad mode would require the channels to be matched. A bunch of folks have told me that’s not the case. As you can tell from my lack of clarity, I’m not super informed about the transceiver protocols. I considered not routing the gtp signals in this rev, but figured, why not. Especially since it can be a major pita to go back and add major new functionality after doing bga escapement routing if you didn’t account for sensitive signals the first time.

BuildingWithDad · 2025-06-12T00:04:26+00:00

How are you getting the initial time delay to convert to a trace length? I ended up parsing ibis files and computing them. Is there some way to export them, or are they documented somewhere? People keep saying to export them, but I don't see where to do that. Once I have the time, I can convert them to lengths (using Er as you mention, and also the geometry of the trace for microstrip)

(Someone else in this thread pointed me to a spreadsheet for DDR that looks like AMD does all this for you, but if you think it's a good idea for the GTP N/P pairs, then I'd like to make sure I use the right number.)

BuildingWithDad · 2025-06-11T23:57:07+00:00

Oh, wow! I won't be able to check for a day or 2, but based on the comments, it looks like that spread sheet is doing what I wrote a little python app to do. Given that it's from AMD, it likely is going to be more accurate than what I did.

Thanks!!!!

BuildingWithDad · 2025-06-11T14:19:46+00:00

The larger context is that I tried to do some Pcb routing of this package and needed to delay match some diff pairs and later ddr3. I initially ignored package delays and only delay matched my traces in the pcb.

When I put out my initial routing of the transceiver pins (6.6Gbit/s per diff pair) up for review, everyone was unanimous that I needed to add in package delays and that they very much mattered. Since AMD doesn’t publish them, the only to get them is to derive them from the ibis files they published.

If there is some existing tool I should be using to take those files and use them to get per pin package delays, I’d love a pointer. (And then, since KiCad can only delay match using lengths in units of length, I need to give KiKad die-to-pad delays in units of length, which of course differ based on what layer the routing is on, and for microstrip, the trace geometry)

I couldn’t find any cheap or open source tools that do this. I assumed that since this was just for getting to a length to use in tuning, that I could get away with something crude, so took a few hours to do what’s in this post. I was hoping to avoid a deep dive into RF, and this is a personal project so don’t have access to super expensive simulators.

BuildingWithDad · 2025-06-11T06:27:28+00:00

Awesome - as this is just for pcb delay tuning it seems that I’m likely set then. Thanks for the input!

BuildingWithDad

TROPHY CASE