Titan is curing

I love PCB-Pool. They send pictures of your PCB during the assembly process (including the two latest pictures below). We will have the boards in our hot little hands early next week.

Figure 1. Top View of Titan

Figure 2. Bottom View of Titan

Titan is public!

I just finished posting rev A of Titan to http://github.com/c-e-s/titan. The rev A release may be found at http://github.com/c-e-s/titan/releases. I will write a longer post for the CES blog explaining the organization of the project. Look for the post in the next few days!

First open source PCB commit

I just posted Enceladus to the CES github account: https://github.com/c-e-s/enceladus.

Enceladus is the 0.1" header break-out board for the expansion headers used on Titan. I ordered this board awhile back. Since it was so simple Enceladus was the perfect board to practice a release. Let me know if anything looks odd since I expect to post rev A of Titan in a few days!

Oh, the lights!

My heart grows three sizes every time I see an FPGA make LEDs blink! This simple project has been checked into CES's github account: https://github.com/c-e-s/ecp5dev_wiggle

I will create new repos under the c-e-s organization as I practice building simple projects using Diamond 3.2 for the Lattice ECP5 PCI Express board.

DDR3 initial route complete!

I finished routing and tuning the DDR3 circuit last night. My branch of the Titan PCB layout is now in Kevin's hands for re-integration into trunk. I'll post some screen caps of the layout when the integration is complete. My next task will be to build a test project for the Lattice's new ECP5 PCI Express Board. When I get it working I'll port the code to Titan and validate our pinout.

Until then, enjoy our latest post at the CES blog: Lattice's ECP5 PCI Express Card

DDR3 data group tuning

I moved half of the upper byte to layer 4 and tuned the tracks. I was shooting to tune each byte to within 100mils, but I ended up beating that without really trying. The lower byte is tuned within 32 mils (see Table 1) and the upper byte is tuned within 21 mils (Table 2).

Figures 1 and 2 (below) show the routes on layers 4 and 6. All of the tracks in the data groups except for the DQS differential pairs are shown; They are routed on layers 1 and 3.

	Pre-tuned length (mils)	Post-tuned length (mils)
D0	859	1205
D1	855	1185
D2	839	1178
D3	934	1210
D4	1027	1204
D5	1187	1187
D6	934	1194
D7	1016	1202
DM0	802	1202
DQS0p	1200	1200
DQS0n	1194	1194

Table 1. Pre and Post Track Lengths for the Lower Byte.

	Pre-tuned length (mils)	Post-tuned length (mils)
D8	962	962
D9	861	981
D10	877	982
D11	975	972
D12	746	961
D13	868	978
D14	803	970
D15	953	973
DM0	888	974
DQS1p	983	983
DQS1n	924	973

Table 2. Pre and Post Track Lengths for the Upper Byte.

Figure 1. Tuned Data Tracks on Layer 6 (Upper Byte and Half of Lower Byte).

Figure 2. Tuned Data Tracks on Layer 4 (Half of Lower Byte).

The PCB layout shown in this post by Custom Embedded Solutions, LLC. is licensed under a Creative Commons Attribution 4.0 International License.

DDR3 data routing for x16 parts

I tried to length match each byte pair last night and immediately ran into troubles. While I had left room to allow for tuning wiggles, it turns out that the mismatch is too great. Figure 1 shows the location of the lower and upper bytes in the route. My goal was to route both of the data bytes on the same layer.

Figure 1. Single Layer Data Route with Bytes Annotated.

Typically, six layer DDR3 routes require four signal layers, one ground plane, and one power plane. So far, I've assumed that if I only used a single DDR3 part I could drop the number of signal layers from four to three by avoiding the connection of control/address signals between each DDR3 IC.

Everything was going great until I started to tune the data bytes. The problem was with the lower byte (D0 to D7). Since the Lattice ECP5 requires that the same DQS group (data byte, strobe, and byte enable) go to the same DQS group on the ECP5, my route groups the bytes together. This is fine for the upper byte, but half of the lower byte (D1, D3, D5, D7, & DM0) have to swing wide to the left to escape the DDR3 IC without crossing the upper byte. This swing horribly mismatches the trace lengths within the byte:

• D0 length: 877 mils
• D1 length: 1371 mils
• D2 length: 861 mils
• D3 length: 1532 mils
• D4 length: 956 mils
• D5 length: 1619 mils
• D6 length: 892 mils
• D7 length: 1460 mils

The average mismatch between odd and even lower byte bits is 599 mils. Figures 2 and 3 show D0 before and after tuning. Since I could only remove 291 mils of mismatch, I'm doubtful that I will be able to tune the lower byte as routed.

Figure 2. Non-tuned D0 Route (Length = 877 mils)

Figure 3. Tuned D0 Route (Length = 1168 mils)

This leaves me with a few ideas about how to proceed:

1. Use a fourth signal layer to route the lower byte. While this doesn't meet my goal for such a simple DDR3 design, it looks like a pretty standard solution.
2. Try to more aggressively select ECP5 DQS groups to route the entire x16 data set. This may be possible because the DQS groups are stacked roughly in pairs of two from the top to the bottom of the ECP5 (per side). This approach might work, but it works heavily against my address/control routing method where I bring all address/control nets in on the top layer.
3. Switch to two x8 DDR3 ICs. With each byte coming from a different IC I can add more vertical space between the parts to ease routing

After taking to Kevin, I've decided to go with option 1 as long as the impact on the rest of the layout is minimal.


The PCB layout shown in this post by Custom Embedded Solutions, LLC. is licensed under a Creative Commons Attribution 4.0 International License.