Здравствуйте!
Являюсь начинающим разработчиком на FPGA. Работаю с ПЛИС Xilinx Spartan 6. Среда разработки ISE 14.7.
Стоит задача: переброс данных из МАС уровня Ethernet в Е1.
Имеется ПЛИС Spartan6 xc6slx150t-2fgg900, PHY Marvell 88E1111, сконфигурированный на работу по оптическому каналу на скорости 1 Gbs, E1 микросхема ds21348, сконфигурированная с NRZE = 1 (не биполярные данные на RPOS и RNEG (TPOS, TNEG), а используются только ноги RPOS и TPOS). Обмен информацией по Е1 организован с помощью HDLC протокола.
Алгоритм работы:
1) полностью принимается пакет с МАС уровня (в буфер), убирается флаг готовности приема данных с МАС уровня;
2) этот пакет передается по Е1 удаленному абоненту, в конце передачи выставляется флаг готовности приема данных с МАС уровня;
3) удаленный абонент, принимая данные по Е1 кладет, их в буфер для передачи в МАС уровень;
4) сразу после окончания приема по Е1 удаленный абонент выдает в МАС уровень принятый пакет.
Используемом соединение: точка-точка, поэтому количество пакетов не очень большое и время между пакетами не превышает времени передачи одного пакета по Е1, следовательно буфер приема данных с МАС уровня не должен переполняться (пока писал, подумал что не плохо было бы все-таки поставить флаг попытки положить данные из МАС уровня в буфер во время передачи по Е1).
Суть вопроса: так как я являюсь начинающим разработчиком на FPGA, я не могу понять почему у меня при разных попытках сборки при малых исправлениях кода (или даже если вовсе код не править) все ведет себя абсолютно непредсказуемо?
Пример: собрал проект, загрузил на плату, смотрю в Wireshark пакеты, приходящие от другого устройства - они абсолютно битые, вовсе не похожи на то, что надо. Запускаю SmartXplorer, выбираю один из вариантов сборки, загружаю на плату, получаю пакеты с битым широковещательным МАС адресом (заместо FF:FF:FF:FF:FF:FF принимается FF:7F:FF:FF:FF:FF или FE:FF:FF:FF:FF:FF), выбираю какой-нибудь другой вариант сборки в результатах SmartXplorer, получаю боле-менее стабильный результат, но есть потери пакетов (каждые 5 секунд высылаю пакет, но, примерно каждые 50 секунд 1-3 пакета теряются).
Части кода, связанные с HDLC и МАС тестировались отдельно, в том числе создавались testbanches. Может что-то в настройках проекта следует указывать или как-то задавать какие-то параметры и флаги портам? Может как-то надо более правильно относиться к тактовым? (Тактовую 2.048 МГц для Е1 получаю простым счетчиком из 32.768 МГц).
В общем, хотелось бы получить какие либо рекомендации по разработке устройств на ПЛИС чтобы не получать непредсказуемого поведения)

Вообще поведение похоже на проблемы с времянкой - на примере широковещательного пакета видно что 1 бит поменялся - обратите внимание на тайминг, констрейнты на клоки и на пины, или проблема с распространением на самой плате< если она кастомная; надеюсь, правильно понял вопрос)
P.S. проверьте флаги достоверности CRC в пакетах, лично мне не очевидно вообще на каком этапе внедряется ошибка, по этому что-то более конкретное не могу посоветовать

Проблемы с времянками имеются. Для гигабитного интерфейса МАС требуется входная тактовая 125 МГц или более. У меня основная тактовая идет от генератора на 48 МГц. С помощью блока PLL_BASE я формирую частоты 64 МГц (для периферии и процессора, которые выращены на этой ПЛИС) и 128 МГц для данного блока. Вот что после сборки мне говорит Timing Analizer про частоту 64 МГц:

Я так понимаю, что данная проблема возникает из-за того, что много блоков (процессор, SPI, пара UART, контроллер памяти) подключено к этой частоте. Есть ли какие-нибудь способы исправить данную ситуацию?

Так и должно быть. Работайте с привязками, читайте документацию.


К тактовым всегда нужно относиться правильно. Про кустарные делители частоты в промышленных решениях забудьте сразу, для этого есть DCM и PLL.


Про это можно целый курс лекций прочитать.


Вам, как минимум, рекомендуют изучить UG612 "Timing Constraints User Guide".
http://www.xilinx.com/support/documentatio...inx11/ug612.pdf


Не может он более 56.8 МГц выдать при таком проекте, изучайте отчеты, смотрите пути.


Есть. Плотно работать с фирменной документацией, там ответы почти на все вопросы.

В стандартной xilinx'овской библиотеке я не нашел делителя тактовой на 16, а счетчик Вы говорите лучше не использовать. Неужели даже для деления на 16 входной тактовой нужно использовать целый блок PLL или DCM? И еще вопрос про тактовые: "Как быть с тактовыми, частота которых не очень высока, например тактовая на интерфейсе I2C?". Неужели даже для таких тактовых нужно использовать глобальные буфера (BUFG) и писать констрейны для них? Просто я Е1 причислял к интерфейсам с низкой тактовой, поэтому не задумывался об констрейнах на Е1.

Я попытался обконстрейнить все, что связано с Е1:

Это для тактовой 32.768 МГц и для входных данных.
А как быть с передаваемыми данными, если тактовую для передаваемых данных вырабатываю я, из 32.768 МГц?

Можно попробовать работать через clock enable, если экономите PLL... Вообще говоря вы же можете посмотреть конкретную цепь, где не сошлась времянка и сделать выводы в каком месте проблема, вполне возможно, что не с констрэйнтами проблема, а с логикой... То что вы перечислили, это не много блоков< если стоит глобальный клоковый буффер

Давая такие советы, аргументируйте. Чем сигнал с выхода триггера, поданный на глобальную линию клока в домен с независимой логикой или с логикой с правильным CDC, отличается от такого же с DCM/PLL?

В 2006 году решил подобную задачу, но на другом наборе микросхем, посмотрите в http://electronix.ru/forum/index.php?showt...16146&st=30

И там же вторая разработка http://electronix.ru/forum/index.php?showt...16146&st=60 где качестве контроллера Ethernet-10/100 использован чип от Micrel KSZ8842-16 MQL. В состав платы входят C8051F123 и XC9572XL

Для гигабитного интерейса обычно нужно не просто более 125 МГц, а ровно 125 МГц. Может быть в Марвелле есть возможность работать на другой частоте, не знаю, я с ним не работал. В любом случае будут вопросы с синхронизацией, или нестандартная частота передачи.

Да, для Marvell нужна частота 125 МГц для работы на скорости 1 Гб/с, а частота 125 МГц или более нужна для МАС уровня, который обрабатывает данные с PHY.

На самом деле МАС эту частоту должен получать от PHY... А уже "внутри" проекта после CDC частота может быть любая...

Судя по постановке вопроса я бы сделал вывод, что глобальная линия использована не была

У меня I2C работает на 125 МГц, а 100(400) кГц идёт как enable.

Для входной тактовой 32.768 МГц был определен тактовый буфер:

Делю входную тактовую счетчиком:

Сейчас добавил еще строчки для выходных тактовых и входной тактовой принимаемых данных:

Вот только все эти входы и выходы на ПЛИС подключены к обычным портам ввода/вывода (не GCLK). Это плохо?

Ставить BUFG на сигналы, которые идут только на выход, смысла нет. Вам надо триггеры CLKOUT_E1 расположить в IOB.

Сделал вот так:

В параметрах Map процесса стоит Pack I/O Registers/Latches into IOBs: For Inputs and Outputs. Этого достаточно чтобы "триггеры CLKOUT_E1 расположить в IOB"? Или следует написать констрейн вида

Я так понимаю что после сборки можно посмотреть лежат ли в IOB эти триггеры в FPGA Editor'e. Только вот я не нашел где...

После добавления строки

процесс Place & Route стал очень долгим и выводится следующее сообщение:

Из-за чего это может происходить?

В принципе должно быть достаточно. Но поскольку в коде триггер описан один, а в FPGA их надо два, возможно, придётся немного пошаманить. Разрешить дупликацию триггеров. Или наоборот: в коде описать два триггера, а синтезатору запретить их объединение.

Можно, конечно, и FPGA Editor, но можно и проще. Смотрите Pinout Report. Там в таблице есть колонка "IO Register".

Изменил констрейн, добавил слово FALLING в конце, так как данные считываются по заднему фронту сигнала. Вроде прошел Place & Route быстренько.

Итак, пока я переписываю проект и упрощаю его чтобы легче было искать ошибки, у меня возникают общие вопросы.
1) Получается, что все тактовые сигналы, которые идут из вне на ПЛИС и синхронизируют логику процессов обмена данными должны быть заведены на GCLK пины ПЛИС. А в проекте на VHDL они должны приниматься во внутренний сигнал через IBUFG. Дополнительно должны быть обконстрейнены данные на выход и на вход (с помощью OFFSET IN и OFFSET OUT), которые зависят от этих тактовых. Возникает следующий вопрос: "Как быть, если входных тактовых слишком много, ведь ресурсы ПЛИС ограничены в плане глобальных тактовых буферов?"
2)

У меня стоит задача разделить частоту 32.768 МГц на 16 и получить частоту 2.048 МГц. Чем же плох делитель частоты с помощью счетчика? Попробовал поработать через clock enable и переписал код вот так:

Правда пока его не проверял, но я не понимаю разницы с делителем, реализованном на счетчике. Может тыкнете меня носом в информацию где можно понять в чем разница?
3) В п.1 я говорил про входные тактовые сигналы. А как быть с выходными тактовыми сигналами? В п.2 я как раз такой сигнал формирую, он служит для синхронизации выходных данных. Нужно ли его как-то обконстрейнить? И, если данный сигнал участвует в процессах формирования и обработки выходных данных, то нужно ли его вешать на глобальный тактовый буфер: ?

Если сигнал заведён на тактовый пин, синтезатор вставляет этот буфер сам. В коде буфер можно не вставлять.

К каждому дизайну индивидуальный подход.

Я тоже. В обоих случаях драйвером сигнала является триггер.

Да. Все сигналы, используемые внутри ПЛИС как тактовые, должны быть заведены на тактовое дерево. Если тактовый сигнал идёт только наружу, использовать буфер смысла нет.

Не то и не там ищете.


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


http://www.xilinx.com/support/documentatio...uides/ug382.pdf
стр. 73
Table 2-7: DCM_SP Attributes
CLKDV_DIVIDE
"Allowable values for CLKDV_DIVIDE include 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5, 5.5, 6, 6.5, 7, 7.5, 8, 9, 10, 11, 12, 13, 14, 15, 16."


Если не сильно углубляться в вопрос, то:
1. Это можно сделать с помощью аппаратного модуля CMT (DCM, PLL), не изобретая велосипед, не тратя ресурсы логики.
2. При использовании DCM/PLL упрощается задача по обеспечению проектных ограничений, так как САПР хотя бы по поводу самопального счетчика-делителя не раскладывает пасьянсы в попытках натянуть сову на глобус.
3. При использовании DCM/PLL вы вряд ли столкнетесь с разваливанием проектов после переразводки и головняком "раньше все работало, а теперь нет".
4. У аппаратного решения есть петля обратной связи (см. Figure 2-2: DCM Functional Block Diagram на стр. 61), которая кроме прочих полезностей предназначена и для "eliminate clock distribution delays".


http://www.xilinx.com/support/documentatio...uides/ug382.pdf

UG382 Spartan-6 FPGA Clocking Resources User Guide
Полезно посмотреть весь документ.
Про CMT, DCM, PLL на стр. 57
Figure 2-2: DCM Functional Block Diagram на стр. 61

Кстати говоря, в Spartan6 есть специальные буферы BUFIO2, которые умеют делить тактовую в 3--8 раз.

Благодарю пользователя BackEnd за развернутый ответ.
Сейчас борюсь с временными констрейнами для гигабитного Ethernet. Очень уж они "жесткие" получаются. Создал маленький проект, в котором используются только сигналы RxD, TxD, RxCLK, TxCLK с PHY микросхемы. В качестве эксперимента завернул данные с приема на передачу через внутренние сигналы. Примерно так:

Задал следующие констрейны:

В таком виде избежать проблем с констрейнами не удалось. Но, используя IODELAY2 на сигналы RxD удалось удовлетворить констрейнам. Но в основном проекте уже так не прокатило, так как там проект большой, задержки больше и уже не удалось найти такой параметр IDELAY_VALUE чтобы все констрейны были удовлетворены.
Вопросы, которые у меня появились в процессе этих манипуляций:
1) Что можно еще предпринять для удовлетворения констрейнам?
2) Когда создавал маленький проект, сначала в ucf файле указал только констрейны, без Location для выводов. Он раскидал все выводы так, как считает нужным. И, в принципе, проект удовлетворил констрейнам даже без IODELAY2. Может быть тогда следует сначала писать проект для FPGA, задавая все констрейны, потом смотреть куда ISE раскидает выводы и потом разводить плату?