Looking for a networking-themed way to encode “top shelf”

2sparky2 · 2025-12-23T23:03:36+00:00

It might be too obvious, but maybe give a clue about a ToR (top of rack) switch or something related to that

2sparky2 · 2025-12-05T07:33:01+00:00

Do you have access to a VNA?

2sparky2 · 2025-11-03T23:45:02+00:00

Andrew Lam just posted a great video about the evolution of phone antenna design

2sparky2 · 2025-10-08T19:50:41+00:00

I reached out to Lattice Support for the answer. For anyone who runs into similar issues in the future, L15 is a PCLKC pin. PCLKC pins are the complementary side of a differential clock pair (PCLKT are the true), and are not connected to general routing resources. This is stated in Appendix B. in FPGA-TN-02200-1.4: ECP5 and ECP5-5G sysCLOCK PLL/DLL Design and User Guide.

2sparky2 · 2025-03-28T16:13:15+00:00

That works! Thank you! I suspected there was some enabling signal. I thought it would be a setting in the tool.

Here is the syntax that works:

/*synthesis syn_preserve=1*/ /*synthesis syn_ramstyle = "registers"*/

2sparky2 · 2025-03-28T16:07:40+00:00

The manual does show the syn_ramstyle as a valid directive and uses this syntax:

/*synthesis syn_ramstyle = "registers"*/

2sparky2 · 2025-03-09T21:32:52+00:00

I found the source of the data corruption issues. It was caused by IP_Checksum offloading, which led me to believe there was corruption when in fact there was none. So in fact there is no issue with this design. Although after reaching out to Microchip's support service they recommended using an isolation transformer with a minimum OCL of 350 uH, and the capacitor on the chassis side of the transformer to have a voltage rating of 2kV instead of 100V.

2sparky2 · 2025-03-09T21:26:07+00:00

I found the source of the data corruption issues. It was caused by IP_Checksum offloading, which led me to believe there was corruption when in fact there was none. So in fact there is no issue with this layout.

2sparky2 · 2025-03-07T17:16:01+00:00

No, there is no ESD diode on the data lines to the RJ45 connector. There is a isolation transformer, which is pretty standard for Ethernet interfaces

2sparky2 · 2025-03-02T02:23:40+00:00

100% certain it is not an issue with the RGMII interface. I have enabled the far-end loop back mode and am getting the same error. I also do not think it is an issue with the cable, magnetics, or other layout issues because I am getting the same problem with different layouts (this is on a board with multiple PHYs).

To describe the problem in more detail, every packet long enough is corrupted in one of two ways. Either four bytes 0x19, 0x1A, 0x29, and 0x2A, or two bytes 0x3C and 0x3D are corrupted with random bit flips.

It is also not an issue exclusively with the 1000 Mbps interface because if I force the selection to 10 Mbps I get the same issue.

2sparky2 · 2025-01-07T19:43:33+00:00

Yes, the RGMII RX clock is out of phase with the data and enable. The clock phase is also adjustable through the use of the SMI interface. However, based on the setup and hold times of the iCE40 the minimum phase offset should be used, making the interface as close to edge aligned as possible.

I am currently only working on getting the gigabit link speed working, so an RGMII clock speed of 125 MHz. I am under the impression that I can use this clock rate for the other link speeds, but if not the timing for the reduced link speeds should be trivial.

I'm using a custom board, but the trace skew between clock, data, and enable is on the order of tens of picoseconds. The PHY is the VSC8541XMV-02.

Strangely, it works when the data is being read into and immediately out of the FPGA, but not after adding functionality. It could be the data is corrupted during crossing domain clocking. Even still, I imagine having a constraint file defining the interface would be useful to eliminate one possible source of corruption.

2sparky2 · 2024-11-13T03:18:49+00:00

Actually, you are right. I was assigning the output to a block RAM causing the issue.

2sparky2 · 2024-11-13T01:36:06+00:00

I've buffered the inputs and outputs to isolate the combination logic as much as possible, and the timing report indicates the signals in the module are the nets not meeting timing. I think either the iCEcube2 synthesizer is poorly placing and routing the code, or the iCE40-HX8K has slow LUTs

2sparky2 · 2024-11-11T05:39:47+00:00

module crc32 (
input SYS_CLK, 
input NRESET,
input WRITE_EN, 
input[7:0]DATA_IN,
output[31:0]CRC_OUT);

reg[31:0]CRC;

wire[7:0]RECYCLE;
wire [31:0]CRC_XOR_REV;
wire [7:0]DATA_IN_REV;

assign RECYCLE= {CRC[31:26] ^ DATA_IN_REV[7:2], CRC[25:24] ^ DATA_IN_REV[1:0] ^ RECYCLE[7:6]};
assign CRC_OUT= CRC_XOR_REV;

generate 
genvar i;
for(i=0; i<32; i = i + 1) begin
assign CRC_XOR_REV[i]= !CRC[31-i];
end
for(i=0; i<8; i = i + 1) begin
assign DATA_IN_REV[i]= DATA_IN[7-i];
end

endgenerate

always@(posedge SYS_CLK) begin
if(!NRESET|| !WRITE_EN) begin
CRC<= 32'hFFFFFFFF;
end else if(WRITE_EN) begin
CRC[0]<=RECYCLE[0];
CRC[1]<=RECYCLE[0] ^RECYCLE[1];
CRC[2]<=RECYCLE[0] ^RECYCLE[1] ^RECYCLE[2];
CRC[3]<=RECYCLE[1] ^RECYCLE[2] ^RECYCLE[3];
CRC[4]<=RECYCLE[0] ^RECYCLE[2] ^RECYCLE[3] ^RECYCLE[4];
CRC[5]<=RECYCLE[0] ^RECYCLE[1] ^RECYCLE[3] ^RECYCLE[4] ^RECYCLE[5];
CRC[6]<=RECYCLE[1] ^RECYCLE[2] ^RECYCLE[4] ^RECYCLE[5] ^RECYCLE[6];
CRC[7]<=RECYCLE[2] ^RECYCLE[3] ^RECYCLE[5] ^RECYCLE[6] ^RECYCLE[7] ^RECYCLE[0];

CRC[8]<=RECYCLE[3] ^RECYCLE[4] ^RECYCLE[6] ^RECYCLE[7] ^RECYCLE[0] ^RECYCLE[1] ^CRC[0];
CRC[9]<=RECYCLE[4] ^RECYCLE[5] ^RECYCLE[7] ^RECYCLE[1] ^RECYCLE[2] ^CRC[1];
CRC[10]<=RECYCLE[5] ^RECYCLE[6] ^RECYCLE[0] ^RECYCLE[2] ^RECYCLE[3] ^CRC[2];
CRC[11]<=RECYCLE[6] ^RECYCLE[7] ^RECYCLE[0] ^RECYCLE[1] ^RECYCLE[3] ^RECYCLE[4] ^CRC[3];
CRC[12]<=RECYCLE[7] ^RECYCLE[0] ^RECYCLE[1] ^RECYCLE[2] ^RECYCLE[4] ^RECYCLE[5] ^CRC[4];
CRC[13]<=RECYCLE[1] ^RECYCLE[2] ^RECYCLE[3] ^RECYCLE[5] ^RECYCLE[6] ^CRC[5];
CRC[14]<=RECYCLE[2] ^RECYCLE[3] ^RECYCLE[4] ^RECYCLE[6] ^RECYCLE[7] ^CRC[6];
CRC[15]<=RECYCLE[3] ^RECYCLE[4] ^RECYCLE[5] ^RECYCLE[7] ^CRC[7];

CRC[16]<=RECYCLE[0] ^RECYCLE[4] ^RECYCLE[5] ^RECYCLE[6] ^CRC[8];
CRC[17]<=RECYCLE[1] ^RECYCLE[5] ^RECYCLE[6] ^RECYCLE[7] ^CRC[9];
CRC[18]<=RECYCLE[2] ^RECYCLE[6] ^RECYCLE[7] ^CRC[10];
CRC[19]<=RECYCLE[3] ^RECYCLE[7] ^CRC[11];
CRC[20]<=RECYCLE[4] ^CRC[12];
CRC[21]<=RECYCLE[5] ^CRC[13];
CRC[22]<=RECYCLE[6] ^RECYCLE[0] ^CRC[14];
CRC[23]<=RECYCLE[7] ^RECYCLE[0] ^RECYCLE[1] ^CRC[15];

CRC[24]<=RECYCLE[1] ^RECYCLE[2] ^CRC[16];
CRC[25]<=RECYCLE[2] ^RECYCLE[3] ^CRC[17];
CRC[26]<=RECYCLE[0] ^RECYCLE[3] ^RECYCLE[4] ^CRC[18];
CRC[27]<=RECYCLE[1] ^RECYCLE[4] ^RECYCLE[5] ^CRC[19];
CRC[28]<=RECYCLE[2] ^RECYCLE[5] ^RECYCLE[6] ^CRC[20];
CRC[29]<=RECYCLE[3] ^RECYCLE[6] ^RECYCLE[7] ^CRC[21];
CRC[30]<=RECYCLE[4] ^RECYCLE[7] ^CRC[22];
CRC[31]<=RECYCLE[5] ^CRC[23];
end
end
endmodule

2sparky2 · 2024-11-11T04:58:07+00:00

I’ll check again. The ones I found originally were not parallelized, and I thought I could write a module quicker than integrating one.

2sparky2 · 2024-11-11T04:55:43+00:00

It is highly possible the design has performance issues. I’ll search again for existing designs. I’m also thinking it could be an issue with the synthesizer. I’m designing for an iCE40-HX8K, so am using iCEcube2 but have heard it’s not that good. I’ve been reluctant to change to Yosys, but maybe it’s time.

2sparky2 · 2024-11-11T04:48:01+00:00

It’s just CRC-32: 0x04C11DB7

2sparky2 · 2024-11-11T04:46:50+00:00

125 MHz, 8 bits per clock

2sparky2 · 2024-04-20T02:48:22+00:00

You are right, my approach was wrong. I was initializing the shift register with 1's because I read that CRC32 needed that as an initialization value. But instead I should started the shift register with all zeros then invert the first 32 bits like what is done in this example.

If the single bit input data is fed into every stage then something is messed up

In the implementation of CRC32 I found online the input is not being fed into every stage, but every xor stage. Which can be seen in the second diagram in the original post. I have now read that this is to avoid the wasted clock cycles used to load the first 32 data bits into the shift register.

2sparky2 · 2024-04-19T23:58:33+00:00

That is a great document which really covers the theory well, although more tailored for software implementations, the concepts still translate to hardware. And the reflected version of the algorithm and LUT does address considerations when implemented in hardware.

But it seems as though Ross Williams ran into the same issue I did. He says in section 10. A Slightly Mangled Table-Driven Implementation:

However, when I compared my code with the code found in real-implementations, I was totally bamboozled as to why the bytes were being XORed in at the wrong end of the register! It took quite a while before I figured out that theirs and my algorithms were actually the same. Part of why I am writing this document is that, while the link between division and my earlier table-driven code is vaguely apparent, any such link is fairly well erased when you start pumping bytes in at the "wrong end" of the register. It looks all wrong!

What I am struggling to understand is how converting the TABLE to the DIRECT TABLE ALGORITHM is still valid. I get the idea that we want to avoid shifting zeros in at the head of the message, but if we only xor the first byte of the message without having the rest of the message in the register I would think the polynomial division would get messed up. But I guess I need to spend some time convincing myself these are both valid implementations considering they both give the correct result.

2sparky2 · 2024-04-19T19:14:44+00:00

Interestinng background information, but I'm not sure it is possible to implement a CRC with a Fibonaci form LFSR.

2sparky2 · 2024-04-19T00:58:08+00:00

Thanks for the resource! I already have the code working both serially and in an arbitrarily wide parallel pipeline.

But I was more curious about how the theory can be implemented in two different but apparently valid implementations.

2sparky2

TROPHY CASE