Electronics > Microcontrollers
100MHz Serial Data Injector
bauto601:
Hello everyone,
For a project i'm in need of something that's a bit unusual i think. I've built an AMD Slot-A to Socket-A adapter but it seems like i have to change the CPU configuration that's sent from the Northbridge to the CPU on startup. The configuration is hardcoded into the chipset and can't be changed by bios unfortunately.
The signal consists out of 33 bits that are serially sent to CPU, synchronized to the PLL clock input of the CPU. This PLL clock runs at 100MHz, here is a scope shot of the signal:
(this signal decodes to: start bit - 001101100000010010000001001100010)
The signal transfer begins with a start bit (1), i'm thinking about to inject my own serial code after this start bit. Using the start bit as a trigger to intercept the package and replace it with an adjusted package. I was thinking about using a microcontroller for this but i'm unsure if there's even one that's fast enough to transmit data at this frequency. Do you guys have any ideas how/if this could be done? :)
mon2:
Use a FPGA (recommended; Gowin or Efinix - low cost kits from Amazon / Aliexpress - Sipeed, etc.) or consider the RP2040 state machine. Otherwise, a microcontroller will not be fast enough.
bauto601:
--- Quote from: mon2 on May 31, 2023, 06:14:51 pm ---Use a FPGA (recommended; Gowin or Efinix - low cost kits from Amazon / Aliexpress - Sipeed, etc.) or consider the RP2040 state machine. Otherwise, a microcontroller will not be fast enough.
--- End quote ---
The RP2040 looks like a relatively obtainable option. Well documented and cheap, i'm going to give it a go with this one :-+
PCB.Wiz:
--- Quote from: bauto601 on May 31, 2023, 05:56:44 pm ---The signal transfer begins with a start bit (1), i'm thinking about to inject my own serial code after this start bit.
--- End quote ---
How many bits do you need to change, and how close are they to the start bit ?
It's hard enough to generate a 100MHz stream, let alone trying to 'switch live'.
You may be better to generate the whole bit stream, and inject all of the non-zero bits, start bit included.
A FPGA/CPLD looks easier to do this, than a MCU, as you need to sample on this clock, and control the phase of output, relative to that clock.
Is that 1V/div, so 1.5V logic ?
bauto601:
--- Quote from: PCB.Wiz on May 31, 2023, 11:02:09 pm ---
--- Quote from: bauto601 on May 31, 2023, 05:56:44 pm ---The signal transfer begins with a start bit (1), i'm thinking about to inject my own serial code after this start bit.
--- End quote ---
How many bits do you need to change, and how close are they to the start bit ?
It's hard enough to generate a 100MHz stream, let alone trying to 'switch live'.
You may be better to generate the whole bit stream, and inject all of the non-zero bits, start bit included.
A FPGA/CPLD looks easier to do this, than a MCU, as you need to sample on this clock, and control the phase of output, relative to that clock.
Is that 1V/div, so 1.5V logic ?
--- End quote ---
I'll give a bit more context: This signal is used for the transfer of the CPU configuration data on startup, after that it isn't used for data transfer anymore but the signal will be asserted when the pc enters sleep mode and such. The signal is only driven in a single direction, from the northbridge to the CPU. It's part of the power management system, so it must keep functioning even after the data transfer. The signal doesn't seem to be timing sensitive, a delay of a couple of clock cycles won't be a problem. The signal is skew sensitive though, it must be closely aligned to the clock signal. The clock signal comes from the motherboard PLL and can fluctuate a bit between 99.5~100.5MHz, when overclocking an increase to 110~115MHz can be expected.
The signal voltage depends on the CPU Vcore voltage, which is around ~1.65v but can be increased to higher levels when overclocking. So it would be nice if there is a small operating range (something like 1.60~1.80v) in order to make room for finetuning the CPU performance. Overclocking capabilities will be a requirement for this project since the CPU will be fairly limited by the relatively low bus speed. (the cpu's that run in this adapter normally run at a 166~200MHz bus speed and have to use a fairly high multiplier to reach their rated clock speed with this 100MHz bus)
After the start-bit, the 21st bit needs to be changed from 0 to 1 which enables the Push-Pull databus drivers on the CPU. Without enabling these drivers, the CPU won't communicate. (ask me how i know...) I guess this is a legacy option from the Slot-A platform which used open-drain drivers. Which is why this bit is set to 0 on these older motherboards.
My idea is currently to implement a RP2040 into the signal path as following:
Northbridge -> RP2040 -> CPU
The RP2040 will read the signal each clock cycle on an input-pin and forwards it to an output-pin, functioning as a passthrough. The first time it detects a logic high (1, the start bit) it will still be passing through the received signal but it will start counting the clock cycles. Once it reaches bit number 21 it will always output a logic high (1) for that single clock cycle thus enabling the PushPull bit in the serial signal. After that it will function as a simple passthrough again. I don't know if this is completely possible in the way i described it with the PIO functionality of the RP2040. I'm currently trying to understand how they work and how they have to be programmed.
The second challenge will be the variable voltage level of the signal. I saw in the datasheet that the RP2040 has a dedicated voltage input pin for the digital IO. This pin could be connected to the Vcore of the CPU, this way the output voltage of the RP2040 will track the Vcore voltage. The RP2040 also has an internal register to adjust the logic IO voltage threshold for 1.8v operation, i'm hoping that this will suffice for 1.65v signals. The core of the RP2040 can be fed with 3.3v, that voltage is available on the adapter fortunately.
The last challenge would be the timing/skew alignment. I'm hoping that the RP2040 isn't too picky about using an external clock signal. In that case i can use the outgoing clock signal from the AMD CPU (which is also used in the scope shots) for clocking the RP2040. This way it should be skew-aligned nicely and adaptive to CPU bus frequency changes.
Does this sound attainable to you guys? Or am i grossly overestimating the capabilities of the RP2040 here? :-//
EDIT:
I see that the external (GPIO) clock input is rated for a maximum frequency of ~50MHz. For some testing work i could probably overclock the RP2040 to ~400MHz such that the maximum clock skew is only 1/4 of a clock cycle. A nicer solution would probably be to put a 1/4 clock prescaler on the output clock of the AMD CPU and feed the 25MHz clock signal to the clock input of the RP2040...
Navigation
[0] Message Index
[#] Next page
Go to full version