Интерфейс между МК и ПЛИС, Использование интерфейса внешней памяти Опции

[DENth]

Уважаемое сообщество! Есть следующий вопрос по взаимодействию ПЛИС и МК:
Имеем ARM7 LPC2468 и ПЛИС Cyclone 2. ПЛИС подключена к контроллеру внешней памяти ARMа. Данный интерфейс предназначен для работы с асинхронной памятью. Относительно ПЛИС сигналы Write, Read с МК асинхронны. На МК и ПЛИС поступает частота с единого генератора - 12Мгц, но в МК она перемножается до 72МГц - частота ядра. Длительность сигналов контроллера внешней памяти зависит от этой частоты. Частота 72МГц на ПЛИС не идет. Вопрос - как обеспечить максимальное быстродействие между МК и ПЛИС?

Read и Write пропускаю через два последовательных триггера для исключения метастабильного состояния. Но как поступать дальше? Использовать их для тактирования внутренних цепей ПЛИС для записи или чтения состояния регистров и памяти вроде как нельзя. Нужен явный клок. Но его нет с МК.

Сейчас получилось сделать так: стробирую эти сигналы внутренней частотой 72МГц, сформированной на PLL ПЛИС. Получаю сигнал длительностью один период частоты 72МГц. Этот сигнал подаю как сигнал разрешения на внутренние цепи. А клок 72МГц как клок на эти же цепи. Все работает. Но если в МК ускорять работу по этому интерфейсу, то всё перестает работать. Видимо пока я синхронизирую Read, Write внутри ПЛИС, МК уже захлопывает данные, а ПЛИС их еще не успела выставить. Стробировать большей частотой не получается, начинает ругаться временной анализатор.

Как сделать правильно?

[DENth]

Обещаный кусок кода. Пишу на AHDL. Проект достался в наследство. Изначально был написан так, что сигналы read, write МК шли непосредственно на клоковые входы регистров. Но поскольку это не верно, я решил все переделать. Однако, МК остался подключеным к ПЛИС по интерфейсу внешней памяти. Да и чего-нибудь более подходящего я всё равно найти не смог.

readflag_=rd;
readflag_.clk=12PLL.c0;

readflag[0]=readflag_;
readflag[0].clk=12PLL.c0;
readflag[1]=readflag[0];
readflag[1].clk=12PLL.c0;

rdx=!(!readflag[0] and readflag[1] and !bscnt.PLDCR[0]);
rdx.clk=!12PLL.c0;

-- где rd - сигнал read на ножке. readflag_, readflag[0] - D-триггеры для борьбы с метастабильностью. 12PLL.c0 - 72МГц;
-- rdx - результирующий строб длительностью 1 период 72МГц, !bscnt.PLDCR[0] - сигнал из подпроекта, разрешающий обработку.

writeflag_=wr;
writeflag_.clk=12PLL.c0;

writeflag[0]=writeflag_;
writeflag[0].clk=12PLL.c0;
writeflag[1]=writeflag[0];
writeflag[1].clk=12PLL.c0;

wrx=!(!writeflag[0] and writeflag[1] and !bscnt.PLDCR[0]);
wrx.clk=!12PLL.c0;

-- аналогично с записью

a_[]=a[];
a_[].clk=!12PLL.c0;
a_[].ena=latch_wr or latch_rd;

latch_rd=!readflag[0] and readflag[1];
latch_wr=!writeflag[0] and writeflag[1];

-- защелкивание адреса


дальше rdx и wrx поступают на все регистры и память ПЛИС в качестве сигналов разрешения. А 72МГц как клок на эти регистры и память.

Поясните мне мои ошибки, пожалуйста!

Я говорю про второй пример. Использую на практике несколько лет. На частотах до 100 МГц включительно. Еще ни разу не сбоило. При одинаковых частотах входного и внутреннего доменов - стабильность (и корректность) от сдвига фаз не зависит. Попробуйте сами.

DENth я похожую задачу делал для связки ЦСП от TI со Спартаном 3. Работало на частоте шины (между ними) 85 МГц. Представьте свою часть кода.

Смотрел-смотрел, но так толком и не смог понять. Не обучен я к сожалению ни VHDL ни Verilog'у. Еще с универа все проекты выполнялись на AHDL. А на работе, так получилось, что доставшиеся проекты также были на AHDL. Стимула для изучения других языков не было пока. Каюсь, надо совершенствоваться. Пока же я прошу Вас описать код более доступно, если это не очень трудно.

Это Вы неправильно поняли...
Обычно обмен данными производится пакетами, которые пишутся в ПЛИС подряд. Или из ПЛИС данные читаются подряд, а не в произвольном порядке...
А вот команды управления пишутся и читаются по "одиночным" адресам, но зато это делается относительно редко....
Вы сейчас хотите от асинхронного чтения-записи в ПЛИС перейти к синхронному...
Ну или по-другому... Если раньше, при записи МК выставлял данные и WR, то ПЛИС во время длительности WR успевала выработать свой внутренний строб и захватить данные... И под каждый цикл Вам нужны были и адрес и данные...
Теперь будет так; на входе по записи данных надо ставить регистр и в него под WR защелкивать данные. После чего МК идет дальше... А ПЛИС в это время делает CDC, т.е. от признака "была запись" формирует строб на системной частоте и системным же клоком под два такта делает запись в синхронное внутреннее ОЗУ. Под первый такт защелкивается адрес, а под второй - данные... Ну или если брать память "как есть", то ей скармливаются данные и адрес и сигнал разрешения... А дальше можно сделать так, чтобы при следующей записи адрес внутри ПЛИС инкрементился бы сам... Для этого из МК надо передавать признак "первая запись или последующие". Обычно для этого дополнительно берут старший разряд адреса. Скажем память на 10 адресов, тогда 11-й адрес - это тот самый признак.
Вот тогда первое слово на запись идет с признаком начала адреса пакета. При записи никакой дополнительной нагрузки на МК нет...
А при чтении - то же самое, но "в другую сторону"... Сначала запись с признаком адреса. данные игнорируются. Пауза между записью и первым чтением должна быть не менее латентности памяти в ПЛИС... Ну и дальнейшие чтения идут подряд. При этом регистр адреса в ПЛИС должен быть с постинкрементом. Следовательно, при пакете данных в 32 слова, получим только одну дополнительную запись. Т.к. она запись устанавливает регистр адреса...

А если и дальше идти по этому пути, то шину адреса можно мультиплексировать с данными, т.к. при чтении одна из этих шин все равно "отдыхает"...

Архитектура нашего проекта выполнена таким образом, что обмен производится практически произвольно. МК пишет в регистры управления данные, означающие режим работы и запуск той или иной операции, будь то чтение или запись в ОЗУ ПЛИС. ПЛИС в зависимости от состояний регистров выполняет обработку. Результат обработки вычитывается МК перебиранием шины адреса условно случайным образом. То есть вычитал тут, прервался, вычитал там, закончил вычитавать из первого места. Пакетной передачи нет, хотя об этом можно подумать.

Сообщение отредактировал DENth - Sep 1 2013, 17:22

[olegras]

... сигналы read, write МК шли непосредственно на клоковые входы регистров. Но поскольку это не верно ...

Это как раз верно. В Вашем случае ПЛИС для МК должна эмулировать поведение статического ОЗУ.
Будем двигаться поэтапно. Перечислите какие конкретно выводы EMC МК подключены к ПЛИС и как Вы их в ПЛИС обзываете.

[DENth]

Это как раз верно. В Вашем случае ПЛИС для МК должна эмулировать поведение статического ОЗУ.
Будем двигаться поэтапно. Перечислите какие конкретно выводы EMC МК подключены к ПЛИС и как Вы их в ПЛИС обзываете.

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

С МК идут как раз выводы wr - строб записи и rd - строб output enable. Но они не заведены на пины глобал клок ПЛИС. А также шина адреса [15..0] и шина данных [7..0]. Всё с точностью как описано в куске кода, который я привел выше. Выбор такого метода был вызван исходя из того, чтобы анализатор смог выдерживать временные ограничения.

Временные ограничения описал следующим образом:

create_clock -name {12mhz} -period 83.333 -waveform { 0.000 41.666 } [get_ports {12mhz}]
derive_pll_clocks
set_multicycle_path 2 -from [get_registers {a_[*]}] -to [get_registers {*}] -setup
set_multicycle_path 2 -from [get_registers {a_[*]}] -to [get_registers {*}] -hold

В LPC нельзя добавить тактов (ожидания) при записи, чтении? И сигнала WAIT не имеется?

Задача - увеличить насколько возможно частоту обращений МК к ПЛИС в единицу времени. Эта величина задается некими переменными внутри МК, такими как WAITRD, WAITOEN, WAITWR и WAITWEN. А если их менять в меньшую сторону, то уменьшается и длительность самих стробов чтения/записи. При этом ПЛИС уже перестает успевать выставлять данные для МК и всё прочее. Вопрос мой был в том, как правильно описать взаимодействие МК и ПЛИС, так как сейчас нет уверенности, что всё сделано правильно. Хочется выжать из обмена еще чуточку =)

По идее период тактовой с PLL при таком дизайне д.б. как минимум вдвое выше чем время активности wr, rd
Вы пробовали асинхронно обмениваться (без тактирования)? т.е. например по низкому уровню сигнала записи (не по фронту)ШАД защелкивается в буферном регистре, по высокому уровню сигналы с выхода буферного регистра передаются уже далее в модуль обработки. Для чтения - наоборот.

Длительность wr, rd с МК составляет несколько периодов частоты 72МГц, но сколько точно, програмист МК сказать не смог, из временных диаграмм МК этого тоже не видно. Асинхронно обмениваться пробовал. С этого все начиналось. Но только если я Вас правильно понял. Не совсем понятно, как сделать обработку не по фронту? Защелкивание в буфер ведь должно происходить по какаму-то клоку? Внутреннему?

Потому что МоделСим не понимает AHDL... А дальше читайте "Краткий Курс", главу про отладку...

Продолжаю работать пока на Квартусе 9.1, благо там есть waveform editor, на конечном этапе использую SignalTap. Этого пока достаточно. Моделсим пока освоить не удалось. В том числе и из-за незнания VHDL.

Вот только так можно сделать стык с МК быстрым. Другого способа - НЕТ!
А все ковыряния с фронтами, с сигналами и пр. только приведут к потере времени...

Спасибо за дельные советы! Придется пересмотреть подход к архитектуре.
Но сразу же возник маленький вопрос - наш МК поддерживает работу с динамической памятью. А ПЛИС может "стать" этой самой SDRAM? Ответ на этот вопрос я не смог найти. Все доступные IP функции как я понял реализованы для связи ПЛИС с физической SDRAM.

[olegras]

Что-то я запутался. То есть у Вас когда то была одна плата (наследство), на которой wr и oe МК были заведены на клоковые входы ПЛИС (это один подход к взаимодействию). Теперь у Вас другая плата, на которой эти же выходы МК заведены на IO ПЛИС (это совсем другой подход к взаимодействию) и Вы планируете остановиться на этой плате. Насчет плат я правильно понял? Или Вы связали два кита (т.е. есть возможность заводить МК на произвольные пины ПЛИС)? Просто хочется понять на чем Вы остановились чтобы двигаться дальше.

[DENth]

Что-то я запутался. То есть у Вас когда то была одна плата (наследство), на которой wr и oe МК были заведены на клоковые входы ПЛИС (это один подход к взаимодействию). Теперь у Вас другая плата, на которой эти же выходы МК заведены на IO ПЛИС (это совсем другой подход к взаимодействию) и Вы планируете остановиться на этой плате. Насчет плат я правильно понял? Или Вы связали два кита (т.е. есть возможность заводить МК на произвольные пины ПЛИС)? Просто хочется понять на чем Вы остановились чтобы двигаться дальше.

Не-не-не... Я видимо запутал Вас тем, что не совсем правильно объяснил. Прошу простить. Я имел ввиду не то, что стробы wr и oe заводились на клоковые входы, а то, что в редакторе назначений им был присвоен Global Clock. Регистры на входах пинов wr и oe, а также адресные a_[] были назначены fast input регистрами. Все выводы МК в итоге на IO ПЛИС. Плата сейчас на этапе корректировки. Можно переподключить. Это может на что-то повлиять?

У 573 регистра, например, нет никакого клока.

Ушел гуглить описание сего девайса...

[olegras]

Для Вашего МК (по даташиту) я бы делал так (пока в общих чертах, завтра если будет время - постараюсь набросать):
на внешних портах ПЛИС имеем
- we, заводим на клоковый вход регистра записи (данные и адрес записи, МК -> ПЛИС);
- bls (один из них, скорей всего младший), заводим на клоковый вход регистра чтения (данные и адрес чтения, ПЛИС -> МК);
- oe заводим на управление двунаправленой шиной данных, и на вход разрешения регистра чтения (а может и записи);
- двунаправленную шину данных;
- шину адреса;
- cs (а вдруг Вы не к ПЛИС обращаетесь?).
Внутренним клоком стробируем выход регистра записи и вход регистра чтения (формируем "свои" регистры в клоковом домене);
на внутренних портах этого модуля имеем (выход - в логику ПЛИС, вход - от логики ПЛИС) сигналы в домене своего клока:
- собственно сам внутренний клок ПЛИС (вход);
- адрес записи (выход - адрес, по которому произошла запись);
- сигнал, говорящий о факте записи (выход, выставляется при записи);
- данные записи (выход);
- адрес чтения (выход - адрес по которому МК собирается прочитать из ПЛИС, может объединим с адресом записи);
- сигнал, говорящий о факте чтения (выход, выставляется при чтении);
- данные для чтения (вход, выставляется ПЛИС по адресу чтения).
Повторюсь - пока это в общих чертах. Вы тоже подумайте. Вам достаточно этих сигналов?
В любом случае таймингами EMC МК придется поиграться - обычная процедура при связках двух камней.

[DENth]

Для Вашего МК (по даташиту) я бы делал так (пока в общих чертах, завтра если будет время - постараюсь набросать):
на внешних портах ПЛИС имеем
- we, заводим на клоковый вход регистра записи (данные и адрес записи, МК -> ПЛИС);
- bls (один из них, скорей всего младший), заводим на клоковый вход регистра чтения (данные и адрес чтения, ПЛИС -> МК);
- oe заводим на управление двунаправленой шиной данных, и на вход разрешения регистра чтения (а может и записи);
- двунаправленную шину данных;
- шину адреса;
- cs (а вдруг Вы не к ПЛИС обращаетесь?).
Внутренним клоком стробируем выход регистра записи и вход регистра чтения (формируем "свои" регистры в клоковом домене);
на внутренних портах этого модуля имеем (выход - в логику ПЛИС, вход - от логики ПЛИС) сигналы в домене своего клока:
- собственно сам внутренний клок ПЛИС (вход);
- адрес записи (выход - адрес, по которому произошла запись);
- сигнал, говорящий о факте записи (выход, выставляется при записи);
- данные записи (выход);
- адрес чтения (выход - адрес по которому МК собирается прочитать из ПЛИС, может объединим с адресом записи);
- сигнал, говорящий о факте чтения (выход, выставляется при чтении);
- данные для чтения (вход, выставляется ПЛИС по адресу чтения).
Повторюсь - пока это в общих чертах. Вы тоже подумайте. Вам достаточно этих сигналов?
В любом случае таймингами EMC МК придется поиграться - обычная процедура при связках двух камней.

Про we и bls согласен. Но заводить ли "oe" отдельно? Для выбора направления шины данных на выход из ПЛИС мне кажется можно использовать тот же bls. Задержка распросранения этого сигнала внутри ПЛИС позволит, думаю, выдержать требования по удержанию данных на шине для МК (перед переходом в третье состояние). К тому же из PDF на МК для себя сделал заключения, что сигналы bls и oe практически идентичны друг другу.
CS в данном случае не требуется. На шине сидят только МК и ПЛИС.
Дальше уже не совсем прозрачно - операция чтения/записи будет происходить за один цикл МК? И требуется ли подавать We и bls на клоковые пины ПЛИС?