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

[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

[vladz]

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

Пока что пара очевидных вещей:
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.

[Victor®]

Пока что пара очевидных вещей:
1. Из-за того что вы используете оба фронта тактовой частоты ....

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

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

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