Здравствуйте.
Есть проект с плис Альтеры, к плис подключается нанд-флеш.
Интерфейсные ноги такие:
flash_ALE : out std_logic := '0';
flash_CE_n : out std_logic := '1';
flash_CLE : out std_logic := '0';
flash_DQio : inout std_logic_vector(7 downto 0) := (others => 'Z');
flash_RE_n : out std_logic := '1';
flash_WE_n : out std_logic := '1';

Флешка работает в асинхронном режиме. Максимальная частота дергания ног RE и WE - 50МГц.
На частоте 100МГц организованы циклограммы работы с флешкой.
Ниже прикрепил иллюстрации из даташита.

Сигналы ALE, CLE, CE_n выставляются заблаговременно до начала работы и снимаются через несколько тактов после окончания работы, думаю здесь можно не копать, констрейнами не обвешивать.

Пока пытаюсь рассмотреть этап записи данных.
При записи данных flash_DQio выставляются как выходные сигналы, а внутри флешки защелкиваются по нарастающему фронту flash_WE_n.
Наружу клок никакой не идет.
Длина проводников на печатной плате составляет от 50мм до 100мм, как я понимаю это десятые доли наносекунд, и их можно не учитывать.
Я никак не соображу какие констрейны прописать для этих сигналов flash_DQio и flash_WE_n.


Ну и аналогичная проблема при чтении данных из флешки.
При чтении данных flash_DQio выставляются как входные сигналы, внутри флешки выдача данных начинается через 16нс после прихода спадающего фронта flash_RE_n.
Поэтому внутри плис после формирования спадающего фронта ожидаем данные через два такта частоты 100МГц.
Какие здесь нужно описать констрейны, и нужно ли, ведь все учитывается циклограммой работы?

если все так как вы говорите, то

set_false_path -from [get_ports{flash_*}] -to [all_clocks]
set_false_path -from [all_clocks] -to [get_ports{flash_*}]

+
set_instance_assignment -name FAST_INPUT_REGISTER ON -to flash_xx
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_xx

Спасибо за ответ.
То что вы описали, я понял так: надо квартусу сказать, чтобы он не анализировал пути между клоками и ногами, подкюченными к флешке, то есть не пытался как то оптимизировать/подогнать эти пути, а вместо этого, чтобы он тупо засунул данные ноги в "быстрые регистры".

Я так сделал. Ну с первым то пунктом ни каких проблем.

А вот второй полностью не выполнился.
Прописал следующее:
set_instance_assignment -name FAST_INPUT_REGISTER ON -to flash_RB_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_WE_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_RE_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_WP_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_ALE
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CLE
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE2_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE3_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE4_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE5_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE6_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE7_n
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_CE8_n

set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[0]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[1]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[2]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[3]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[4]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[5]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[6]
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to flash_DQio[7]

Для ALE,CLE,WE,RE,WP квартус написал, что не может упаковать ноду.
Вот для RE:
Warning (176225): Can't pack node flash_RE_n~output to I/O pin
Warning (176260): Can't pack node cpu:cpu_inst|nios_core:...:nand_flash_interface_pm|inner_work_RE_n~_wirecell and I/O node flash_RE_n~output -- one node must be a logic cell and one must be an I/O cell

И после этого частоа 100МГц упала до 93, появилась куча Failling Paths.

Решил откатить все назад: set_false_path закомментарил, FAST_OUTPUT_REGISTER закомментарил.









Вообще проблема с проектом следующая.

К ПЛИС подклено 4 нанд-флеш. Общий объем 128ГБ. Размер старницы 4096Б. Для контроля целостности и корректности записанных и прочитанных данных реализован механизм ЕСС (по Хеммингу) с возможностью обнаружения 1 или 2 ошибок и коррекцией только 1 ошибки на всю страницу. ЕСС пишется в служебную область страницы за 4096 байтом.

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

Так как ЕСС обнаруживает ошибку уже после анализа всей страницы, а не в самый момент ее проявления, то сейчас реализован такой тест: записываю на одну страницу просто счетчик.
Затем вычитываю этот счетчик 1000 раз.
Результат чтения сравниваю с истинным счетчиком.
И так прохожу по всей флешке.
Это позволяет обнаружить ошибку тут же, и вывести ее в сигналтап.

По задумке: если имеются битые ячейки в нанд-флеш, то каждый раз на одних и тех же битых страницах я должен получать 1000 неудачных чтений, если битых ячеек нет - то 1000 удачных чтений.
Я же получаю следующее:
например, 30 страниц может вычитаться удачно, при чтении следующей страницы может быть несколько неудачных чтений из 1000. Потом опять несколько десятков удачных страниц, потом опять - иногда одно не удачное чтение, иногда больше: 2, 35, 259, 957.
Картина все время меняется.

Циклограмма работы с нанд-флеш сейчас отшлифована до идеала, все с хорошим запасом, там где требуется 7нс на предустановку данных на линии, я выставляю за 20нс и тому подобное.
Вот например один из сигналтапов с отловленной ошибкой.



flash_RE - сигнал чтения,
flash_DQio - двунаправленная шина данных, адреса, команд
inner_DQio_in - переименование flash_DQio вне процесса.
out_data - защелкнутые под процессом данные inner_DQio_in.

Опускаю RE, по даташиту максимум через 16нс должны придти данные, они приходят уже через 10 нс,
поднимаю RE, и на следющий такт защелкиваю входные данные inner_DQio_in в регистр out_data.

Из этой картинки видно, что данные должны быть (в hex) : 49, 4A, 4B, 4C, 4D.
А имеем: 49, 4A, 5B, 4C, 4D.

Если посмотреть на шину flash_DQio, то видно что откуда-то появился одиночный импульс в 4 бите flash_DQio[4]. Причем не до и не после этого импульса в этом бите не должно быть высокого уровня большое количество тактов.

Отсюда вопрос, откуда этот импульс взялся?

1. Может ли причиной его появления быть нарушение времянок в ПЛИС?
Если да, то буду дальше копать.

2. Может ли причиной его появления быть какие то внешние факторы: импульсные помехи, что еще (я в этих вопрос не имею достаточного опыта).
Если да, то тогда уже буду отпинывать проблему к разработчикам схемы, платы. Там еще так получается, плисина расположена на отдельной печатной плате, 4 нанд-флешки на другой печатной плате. Эти две платы стыкуются между собой штыревым разъмом HM2J09PE5118N9 и HM2S30PE5101N9
http://www.chipdip.ru/product/hm2j09pe5118n9lf/
http://www.newark.com/fci/hm2s30pe5101n9lf...acle/dp/71K4963
(может это сразу кому-то что-то скажет)

Ой, это на частоте 50МГц? И какой при этом получится hold slack ? Хотя, скорее, на 25МГц, тогда правильно.
Констрейны для записи, может быть, можно и ограничить set_false_path и упаковкой всего в регистры, а для чтения лучше сделать по-нормальному.
потребуются create_generated_clock для RE_n,
set_clock_latency для него же с описанием задержки в PCB(она больше 1 нс),
два set_input_delay между RE_n и DQ для описания t_REA и t_RHOH и
set_multicyle_path для входных регистров(так как они защёлкиваются клоком с частотой выше RE и пропуском тактов).

Пытаться читать через 20 нс после опускания RE_n неправильно, к 16 нс задержки во flash нужно ещё добавить 1.3 нс в PCB и примерно 6 нс в буферах FPGA, в результате промахиваемся. Хотя работать может, так как 16 нс - это максимум.

Из сигналтапа следует, что данные всё-таки были неправильно записаны.

Не понял о каких мегагерцах вы говорите, я хотел сказать следующее: перед тем как щелкнуть передним фронтом WE, т.е. произвести запись данных, по даташиту требуется, чтобы данные на шине были установлены заблаговременно, минимум за tDS = 7 нс для Timing Mode = 5. Я выдерживаю 20нс. После подъема фронта WE также необходимо подержать данные в неизменном состоянии минимум tDH = 5 нс для Timing Mode = 5. Я держу 20нс. Это касается и записи данных, и при задании команды, и при установке адреса. Все с большим запасом, чем требует даташит.


Меня это все вообще пока в ступор вводит. В голове каша.
Поэтому решил убрать все констрейны.
Задержки внутри кристалла для ALE,CLE,WE,RE,CE,DQio почти одинаковы и составляют 5-6нс. Это в ТаймКвесте смотрел через Report Path.
И мне кажется, что если задержки одинаковые, тогда и констрейны никакие не нужны.



Немного не так вы поняли. На том же сигналтапе видно, что между фронтами RE имеется 3 такта частоты по 10нс.
Получается так - опустили RE, через 3 такта подняли RE, через такт защелкнули данные DQ с входа плис в регистр.
Нарисовал картинку, вроде все получается как надо и запас получился 8нс.



На этом рисунке принял следующее: задержка внтури кристлла 6нс, задержки на pcb 2нс.

Или я в чем то ошибаюсь?



Да, но из этой страницы данные читаются много много раз (1000 раз), и как я написал, неправильное чтение может проявиться пару раз на эти 1000, а может вообще не проявиться. Значит в флешке записаны правильные данные.


Может это все таки помехи какие?

В таком случае у вас с циклограммой всё в порядке, и на столь низкой частоте можно обойтись констрейнами по совету des00. Но, обязательно надо запаковать всё в IO регистры. Подозреваю, что управляшки не пакуются в IO регистры потому, что формируются комбинаторной логикой, тогда надо переписать код, чтобы этого не было. Комбинаторное формирование управляшек может приводить к глитчам, которые запросто вызовут нестабильное чтение данных. С этим следует разобраться в первую очередь. Максимальная частота снижается потому, что IO регистры принудительно размещаются далеко от основной корки. Для решения этого вопроса можно, например, добавить в критические пути ещё один слой регистров.