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

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

Обещаный кусок кода. Пишу на 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МГц как клок на эти регистры и память.

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




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



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

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

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

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

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

Пока что пара очевидных вещей:
1. Из-за того что вы используете оба фронта тактовой частоты !12PLL.c0 и 12PLL.c0, вы поднимаете рабочую частоту проекта в 2 раза до 144МГц. Если логика получилась разбросана по кристаллу, данные могут не успевать за 144МГц тактовой и вызывать ошибки анализатора. Если возможно, то надо стараться использовать в проекте или блоке только один фронт, тода и разводчику PAR станет легче и вам анализировать проблемы станет проще.

2. Нарисуйте на бумаге диаграммы доступа МК к внешней памяти и проставьте длительности всех сигналов в тактах. Посчитайте на каком такте после начала wr и rd вы записываете или выставляете данные наружу. Очень может быть что придется время удержания wr и rd удлинить в программе МК.

И еще совет - постарайтесь давать сигналам осмысленные имена, иначе никто не захочет разбраться в этой мешанине символов. Глобальный клок просто не может называться 12PLL.c0, это должен быть просто clk, sys_clk или что-то еще с _clk если не лень набирать длинные имена. Сигнал разрешения обработки не должен именоваться !bscnt.PLDCR[0], измените на что-нибудь с _en/ enable.

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

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

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

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

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

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

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

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

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

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

С МК идут как раз выводы 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




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



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



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



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

Это одна из разновидностей всяческого зла...
(если это делать неправильно, а правильно только на DDR триггерах)
И практически всегда внутри проекта можно (и нужно) обойтись одним фронтом.
Не хватает частоты - ставьте PLL x2.

Объяснять не буду, обсуждалось

P.S.
FIFO вас спасет

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

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

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



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

Решал подобную задачку на связке 5576ХС+1986ВЕ91. Быстрее чем на 6 МГц стабильно не работает в принципе. Благо шина 32 бит.