К xc6slx45 подключена SO-DIMM. Один банк полностью отдан под DDR2, соответсвтенно питание банка 1.8V. Сигналы адреса DDR2(16 линий) подключены к другому банку, также к этому банку подключается много еще чего. Соответственно, питание банка 3.3В. Можно обойтись простым резистивным делителем для линий адреса DDR2 (3.3В->1.8V) или что-то "правильнее" требуется?

В spartan-6 аппаратный контроллер памяти, поэтому разводить нужно на строго-определенные ноги. И он, кажется, не поддерживает планки памяти, а только single-chip.

Правильно делать так : запитать оба банка от 1.8в. Продумать вопросы терминации как по данным - там в обе стороны, можно использовать DCI, так и по адресам - там в одну сторону, можно пользовать внешние резисторные сборки.Если вы не знаете что такое termination, то дальше объяснять вообще нет смысла. То что вы предлагаете - колхозное решение, скорее всего работать вообще не будет, либо если будет, то на очень низких частотах.
З Ы А ещё очень полезно иногда заглядывать в референсные дизайны - благо все схемы лежат открыто.

Как правильно делать - это мы знаем Большинство Reference Design - примеры как подключаются single-chip DDR2, но не SO-DIMM. Использовать FPGA типа Virtex 5 - денег столько нет. Ядро работы с SO-DIMM будет свое, сейчас по согласованию сигналов надо определиться. Решение - колхозное, видел подобный образец, на котором удалось получить скорость 8Гбит. Склоняюсь к варианту: оба банка на 1.8В, а остальную периферию согласовывать по уровню 1.8В.

Я бы тоже подстраховался - проще налепить левел шифтеров на медленную периферию, чем рискнуть, решив проблему "колхозно" и в итоге получить нерабочий контроллер DDR.

Немного оффтопа : Я так понимаю, вы собираетесь писать свой "soft" контроллер под 6 спартан, так как встроенный поддерживает максимум 16-битную шину данных, а это не случай SODIMM. Непростая это работа, особенно добиться устойчивой работы в больших партиях и температуре. Где-то на форуме уже пробегала тема о том как сделать софт контроллер под 6 спартан.

KSN
Не понимаю, чем MCB не устраивает?
При тактовой частоте DDR2 в 266 МГц и шине 16 бит (к примеру, MT47H32M16) вполне возможно получить Ваши 8Гбит.
И всё штатными средствами (ug388.pdf, table 1-1).
А у XC6SLX45 аппаратных контроллера как минимум 2.
Да и XC6SLX75 не сильно дороже, а у него уже целых 4 MCB (ug388.pdf, table 1-2).
IMHO, использование штатных средств проще и разработка в целом дешевле. Особенно с учётом времени отладки собственного контроллера.

Под задачу требуется 4ГБ и это мало - говорят программисты, надо еще больше... Не видел single-chip такого объема, пусть даже 2 или 4шт. Есть опасения, что могут быть проблемы с доступностью singe-chip.

О каких программистах речь?
Если на плате есть процессор, подключайте память к процессору. Если нет, то непонятно зачем вам столько памяти. Если опишите что и как вы собираетесь делать, вам, возможно, подскажут лучшее решение.

P.S. Если большая скорость не нужна, подключите sd-карту или nand-flash натолкайте.

KSN
Стало ещё меньше понятно .
Зачем столько памяти цеплять на медленный интерфейс с FPGA? Программистам всегда мало объёма памяти, недостаточно производительности процессора, низкая пропускная способность периферии.
Соглашусь с m-m. IMHO, лучше поставить нормальный процессор с для работы с таким большим объёмом памяти. Пусть даже он только этим и будет заниматься (эдакий сопроцессор памяти).
Мы опытным путём (к сожалению, набив шишек) пришли к выводу, что с точки зрения уменьшения стоимости разработки для мелкосерийных изделий, лучше не экономить на спичках и стараться использовать штатные решения. Поэтому стараемся разбить задачу на логические части (или уровни обработки) и каждому программисту выделить свой процессор (сопроцессор прикладных задач). А обмен между ними можно сделать и на FPGA. Так им проще отлаживать свои части, а нам проще обеспечить им нормальный механизм обмена (поскольку количество данных между сопроцессорами меньше).
P.S. Опять поддержу m-m - если нетрудно и возможно опишите (о общих чертах) задачу. И Вам, возможно, помогут и мы чему-нибудь научимся.

Задача: По TCP/IP принять пакет данных (около 500Мб), сложить его в память, затем в реалтайме раздавать данные по параллельным интерфейсам (от 8 до 16 шт). Пока раздаем этот пакет, принимаем следующий.
Бывают ситуации, когда для раздачи на параллельный интерфейс необходимо сначала принять 3 пакета по TCP/IP. К тому же сейчас уже есть наработки: PCIExpress -> serializer->FPGA->parallel interface, которые легко перенесутся на решение TCP/IP->FPGA(DDR2)->parallel interface

Возвращаясь к сути вопроса. Банки можно запитать от разных преобразователей напряжения и получить необходимые уровни. Резистивный делитель это как-то не очень хорошо. А вот разные преобразователи вполне даже допустимо.

KSN
Тогда ещё два вопроса.
1. Какая установившаяся (пользовательская) скорость передачи данных в параллельные интерфейсы? То есть S = V * N, где S - общая скорость (по Ethernet, видимо), V - скорость по параллельным интерфейсам, N - количество интерфейсов. Учтите, что в TCP/IP есть накладные расходы на передачу сетевого и транспортного уровней. И размер обрабатываемого сетевой подсистемой блока ограничен кадром канального уровня. А там ещё MTU и всё такое. То есть ресурсов на обработку таких кадров может уйти достаточно.
2. А что произойдёт, если вовремя не будет принят следующий 500 Мб-й пакет?

Dmitriyspb
Я так понял, что запитывать банк 1,8 В нехочется, поскольку тогда, как указал Bad0512, придётся налепить левел шифтеров на медленную периферию. Не факт, что это будет проще и дешевле.

З.Ы. А вообще почему XC6SLX45 (мы сами их используем)? Я всё больше в сторону Zynq7000 посматриваю. Очень уж соблазнительная штука.

Не хочется и не хочется. - Сомнительный довод. Вот если бы автор помимо привел бы по этому поводу еще доводы и причины можно было бы отказываться. А так, хозяин - барин=)

Все же, хочу сказать, что реализация soft-ip для обмена с ddr2 - идея не очень правильная. Скорее всего возникнут проблемы с приемом dqs-ов от памяти, поэтому сколько-нибудь приличной скорости достичь будет трудно. Лучше использовать MCB (или брать другой кристал, я бы, на вашем месте смотрел в сторону Artix-7).

А по поводу делителей, анализ signal integrity даст ответ на ваш вопрос.



Я бы, на вашем месте, взял процессор с MAC и DDR интерфейсом и принимал пакеты им. А для раздачи данных поставил простенькую ПЛИС (лишь бы ног хватило).

Я выше написал о потенциальных проблемах с согласованием и как следствие - "звоном" по адресным линиям.Можно попытаться всё это отмоделировать (тоже весьма непростая задача) в Hyperlynx или подобном софте, но результаты всё равно будут отличаться от реальной жизни.