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

[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

[iosifk]

..... Пишу на AHDL. Проект достался в наследство. ....

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

После этого можно только одно сказать, что серьезной отладкой проектов Вы заниматься не умеете. Увы!!! И до тех пор, пока не научитесь применять VHDL или Verilog о серьезном подходе к делу можно и не говорить....

[DENth]

После этого можно только одно сказать, что серьезной отладкой проектов Вы заниматься не умеете. Увы!!! И до тех пор, пока не научитесь применять VHDL или Verilog о серьезном подходе к делу можно и не говорить....

Серьезной отладкой заниматься действительно не умею. Не так давно приступил к изучению TimeQuest, ибо надоело, что изменяя код одного подпроекта, отваливается другой. При помощи DesignAssistant постарался убрать часть варнингов, вызванных использованием недопустимых оборотов. Иду по пути совершенствования мелкими шагами. И результат ведь потихоньку да вырисовывается.

А что Вы мне можете рекомендовать? Взяться за изучение Verilog'а? Про него кратко читал. Но было бы лучше, если бы мне объяснили на пальцах - чем в корне он отличается от того же AHDL. На нем проще описать какой-то оборот? Или на нем можно описать то, чего на AHDL не получить никогда? Если то, что я описал допустим в 20 строках кода на верилоге можно описать одним оборотом - ведь не значит, что работать будет по разному? Или как?
Почему серьезный уровень - это только эти языки?

[iosifk]

Серьезной отладкой заниматься действительно не умею. ....Почему серьезный уровень - это только эти языки?

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

Сколько лет проработал в техподдержке, столько не перестаю удивляться, когда получается ситуация такая, как эта...
Все что написано вообще здесь, всё обсуждение выглядит примерно так: "Ставлю компьютер на паровоз, гружу воду и дрова... А он все равно быстрее не идет и КПД не выше 12%... Почему??? Может кран какой до блеска начистить?"

А потому, что в "Гайке М3" написано:
1. Выбираем алгоритм
2. По алгоритму выбираем требования к железу...

Так вот. У Вас алгоритм случайного чтения внешней медленной памяти в программном режиме. В программном! А это значит, принципиально обработка данных сделана медленно...
Вот: "Результат обработки вычитывается МК перебиранием шины адреса условно случайным образом. То есть вычитал тут, прервался, вычитал там, закончил вычитавать из первого места. Пакетной передачи нет, хотя об этом можно подумать."

Память МК - асинхронная, память ПЛИС - синхронная... И Вы синхронную память ПЛИС подгоняете к асинхронному чтению.
А это значит, что за длительность сигнала чтения от МК внутри ПЛИС должно пройти как минимум 3-4 внутренних клока. А иначе синхронная внутренняя память не успеет выдать данные... А в это время МК стоит и ждет... И быстрее этот паровоз не поедет никогда!!! Смотрите минимальную длительность тактовых для памяти, умножайте на латентность по чтению и добавляйте импульсы на прохождение от памяти к выходу... И добавьте сюда время на "разворот шины"... И это будет предел. Все. Больше тут обсуждать нечего...

А если действительно хотите, чтобы паровоз ехал быстрее, то меняйте пункт №1... Подгоняйте режим работы МК к работе синхронной памяти. Включайте ДМА и переходите на пакетное чтение данных. И уже потом, в памяти МК производите обработку данных любым "случайным образом"... Ведь внутреннюю память МК читает на внутренних клоках, а это в несколько раз быстрее...
Для этого меняйте расположение данных в памяти ПЛИС так, чтобы их было удобно качать по ДМА пакетами. Как изменить порядок чтения-записи - я немного написал выше...
Вот только так можно сделать стык с МК быстрым. Другого способа - НЕТ!
А все ковыряния с фронтами, с сигналами и пр. только приведут к потере времени...