Посоветуйте, пожалуйста, как лучше реализовать ATA контроллер, работающий на одной плате с ПЛИС (Virtex-5).
Отдельная микросхема или IP Core?

А какие задачи решает ПЛИС?

На сколько я помню, стандарт АТА - 5 вольтовые уровни. Так что напрямую с ПЛИСа не получится, придется уровни преобразовывать.

ПЛИС управляет потоком данных, которые должны как читаться с HDD, так и записываться на HDD.

Может вы ошиблись с АТА, когда все переходят на SATA?
Про АТА кое-что:
http://www.xilinx.com/publications/xcellon...38_57-iwave.pdf
http://www.opencores.org/?do=project&who=ffr16 -- может поможет
Для SATA и примеры реализации есть:
http://www.xilinx.com/products/design_reso...tocols/sata.htm

Все может и переходят, только ATA можно сделать самому довольно легко или взять на OpenCores, а SATA говорят где-то в человеко-год выходит, и стоит несколько десятков тысяч долларов.

Тогда совсем не понятно, что Вы хотите сделать?
На мой взгляд стоит делать то что будет иметь смысл и через 5 лет, а заниматься ради того что бы через пару лет все переделывать заново - какой смысл? Ну это мой взгляд, Ваше право с ним не согласиться.
А что касательно вопроса непосредственной реализации то, на мой взгляд, лучшим решением будет упаковка в одну ПЛИС всех ваших задач.

Virtex 5 имеет гигабитные трансиверы, так что самая сложная часть SATA уже считай готова. А уже сам протокол реализовать, по-моему, дело нехитрое.

Это вам так на самом деле только кажется. Если бы трансиверы были самой сложной частью в таких протоколах, то Xilinx не стал бы делать аппаратные Ethernet MAC и PCIe Endpoint. А SATA еще чуть ли не сложнее.


Смысл - деньги за пять лет получить не один раз, а два-три.

Я делал на V4. Для согласования ставил 95хх(CPLD), она у меня работала как выходной регистр. Сам автомат делал на Виртексе. Ничего сложного. Обычный, в общем-то , последовательно -параллельный интерфейс.

2 tolik1 - то есть вы использовали 95хх(CPLD) как переходник уровней для PATA-V4 ?

Да. Не очень оптимально, но работает.

А UDMA делали? Для ATA100-133 уже по времянке могут быть проблемы.

Нет. Такого не делал. Писать надо было не быстро, но много.

Здравствуйте.

Забуксовал я что-то на реализации этого контроллера.. Разжился даже ANSI INCITS 397-2005, однако это не помогло..
Винт - HM160HC
Проблема вся заключается в том, что времянку организовываю согласно "Register transfer to/from device timing" для PIO 0, а поведение железяки совсем не по стандарту. Делаю согласно стандарта(после ресета плиски) - "hardware reset protocol", после того как читаю статус и получаю BSY==0, перехожу к стадии идентификации устроства - записываю сначала в Device/Head Register Dev==0, а потом в Device Control Register nIEN ==0 последовательно, после этого записываю в Command Register == EC - то есть комманду идентификации - жду, получаю INTRQ, читаю статус и вываливаюсь по (BSY == 0) & (DRQ == 0)..
Вот интересно- было ли у кого то такое поведение - это где-то чтот опропустил или как ??

И что самое печальное, вот чипскопленая картинка транзакций
Нажмите для просмотра прикрепленного файла
Лапы на вход-выход определены так:

Откуда мусор на ch1_dd_pad_i когда ch1_dd_padoe_o == 1 ??

Если сделать есчё 3 раза ресет плиски - вообсче стадию выхода из "hardware reset protocol" не прохожу уже - BSY == 1 всегда...

Я конечно не гуру верилога и может быть скажу глупость, но написал бы

2 DmitryR - так а разницы никакой нет - по 2001 стандарту он должен был расширить влево моё третье состояние до 16 разрядов. Для успокоения совести всё же пересобрал и залил - поведение идентичное предыдущему..

Смотрите тогда схематику, что после синтеза получилось, там явно что-то упростилось или иным образом раскосячилось.

Смотрю осцилом на лапах, и чипскопом сигналы - что осцил что чипскоп говорят одно и то же - времянка на запись и чтение согласно спецификации - вот это меня и ставит в тупик, на матери винт проверял - в биосе видится, значит IDENTIFY DEVICE проходит всё таки...
Самое подозрительное - это мусор на лапах данных при записи (хотя отчётливо видно из assign-ов, что на них должны быть стабильные данные).

Счас немного модифицировал дизайн для проверки (опустился на самый низ - примитивы прост опроверить)

ch1_dd_padoe_o - беру с кнопки на ПП.
Проверил в технолоджи-мапе как он конструирует это всё (работаю с Xilinx) - через IOBUF - как и должен. На вход IO этому IOBUF заводится шина dd_pad, сигналы на которую выводятся с pad_o через OBUFT. То есть вообсче не к чему придраться вроде бы со стороны плиски (всё как заказывал).

В немодифицированном дизайне конструкция чесная, через IOBUF - как и должна быть, но откуда тогда берётся мусор на линии данных когда я пишу в шину, получается ата-девайс начинает гадить, но с какого это....

Да как же согласно спецификации, когда при ch1_dd_padoe_o=1 на выходе идет мусор?

2 DmitryR - я имел ввиду управляющие сигналы, а данные - их моного - потому их лучше смотреть через чипскоп.. А при ch1_dd_padoe_o=1 на ch1_dd_pad_i мусор может быть только в одном случае - если винт при ch1_diown_pad_o=0(запись параметров в винт) не перестаёт выдавать данные на шину (сам провод проверил - сигнал доходит до шлейфа), что само по себе странно

Пытаюсь сделать софтварный ресет - проходит как когда
Нажмите для просмотра прикрепленного файла
Объяснение этому видими что иногда контроллер винта захватывает корректные данные, иногда нет..Осталось только определить зачем винт на шину выдаёт данные в момент ch1_diown_pad_o=0 (по стандарту в это время ата девайс слушать должен, а не выдавать)..

На будущее, может кому будет полезно - радиоэлектроника- наука про контакты, и с проектированием переходников уровней нужно внимательным быть .
Кстати , может кто посоветует грамотные переходники уровней с 2.5В на 5В, так чтоб 2направленные были (а то один тут уже выбрали ) ?

С 3.3 могу сказать - QS3861. Он в одну сторону будет понижать 5 вольт и обрезать овершуты, а обратно пропускать как есть, благо пятивольтовый вход нормально воспринимает сигналы драйвера 3.3 вольта.

мне нравятся вот эти Dual Supply Translators

http://focus.ti.com/paramsearch/docs/param...AliasId=1100707

использовал SN74ALVC164245

http://focus.ti.com/docs/prod/folders/prin...alvc164245.html

доставал через чип дип

2 des00 - с использованием DIR жизнь становится проще (были заложены эти )

А у меня так ничего и не вышло. Делал самопальный usb-hdd переходник для ATA винта, без UDMA. Удалось даже прочитать его каталог, и файлы киношек с винта вытащить. Но работало нестабильно. Использовал как раз похожие двухуровневые переходники от Ti. И хотя по диаграмме все было верно, никаких там всплесков, но похоже есть еще какие то подводные дела. В результате винт заткнулся причем надолго. Такое впечатление что у было где то наложение выходов друг на дружку во время переключения трансляторов SN74, и в итоге выходные буферы винта перегревались и переставали работать. Где это происходило, в каком месте так и не смог выловить. Общая конструкция была такая. Плата usb, разъем IDE40, шлейф 10см, разъем IDE40, плата трансляторов уровней, разъем IDE40 и шлейф 20см, собственно к винту. Возможно вот эта куча разъемов на пути сигналов сыграла свою роль.
Может у автора такая же штука, сигналы двигаются от чипа к винту очень по разному.

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

Вопрос с буфером решился интересно - отгрызли шлейф по максимуму и удалось стабильно читать, хотя на осциле как всё таки есть кака - стремновато, 100% гарантии что всегда будет приходить/уходить нет изза неё..

И снова здравствуте.

Опять натолкнулся на некоторые трудности. Очень специфический момемент, литературу перерыл, по инету полазил - что-то не нашёл ответа.
Собственно проблема такого плана - есть модуль с машинкой - чтение/запись (объём - 1 сектор).
Читать могу сколько угодно - всё завершается без ошибок. А вот с записью есть некая заковыка - использовал для проверки такую последовательность действий - читаю в блоковую память плиски сектор (512Б), модифицирую, записываю обратно в тот же сектор, читаю - сравниваю. Значит всё шло хорошо до момента 2-го чтения - когда нужно вычитать из сектора то, что модифицировал на предыдущих этапах. Возвращается DRDY == 1 - то есть девайс готов и BSY==0,DRQ==0 - то есть в девайсе произошла ошибка, такое происходит всегда после обрабатывания запроса записи (чтений штук 10 вставлял даже, а между ними запись, или записи 5 штук - именно после первой же записи на следующей любой транзакции получаю BSY==0,DRQ==0).
И что самое интересное - если провести софтварный сброс - и начать заново вышеописанную последовательность действий - всё повторятся по кругу (всмысле ошибка на следующей транзакции после запииси сектора). Чтение же после софтварного ресета показывает немодифицированный блок - что тоже странно , потому как первая процедура записи возвращает статусовый регистр с нормальным завершением.

Код машинки приложил Нажмите для просмотра прикрепленного файла
Писал её по атапи-7 и сравнивал с найденными в инете исходниками для МК - вроде одно и тоже, но отчего то не работает .

Пио0-тайминги делает другой процесс - для него управляющий сигнал - strobe_in/out, сигнал в главную машину что операция закончена - pio_cyc_ok
Нажмите для просмотра прикрепленного файла
...

Во-первых, по описанию я не вижу, чтобы (BSY==0 & DRQ==0) сигнализировало об ошибке.

Затем, вы CRC как считаете? Я тут решил-таки сделать SATA и напоролся, что стандартный Xilinx CRC32 блок считает его как-то неправильно, WebCase на эту тему висит уже 12 дней.

Кейс 13 главной машины

в документе атапи-7 (да и в 5-й версии это же видел): figure 47 - HOST PIO data-In state diagram. Под диаграмой расшифрование стейтов и переходов:





А с этого момента можно поподробнее - зачем в Write Block комманде (блоки в количестве 1) CRC ?
Его же вроде там нет ( по крайней мере в описании к комманде READ SECTOR(S), которая имеет код 20h, и к комманде WRITE SECTOR(S), которая имеет
код 30h, CRC не упоминается) ?

пс
Может там подождать где нужно помимо соблюдения тайминга для пио0 ? или есчё какие нъюансы написанные мелким шрифтом внизу и в другом документе ?

Вкурил, все верно. Посмотрите диаграмму устройства, при каких условиях он может такие сигналы выставлять.

Проверил диаграммы и автомат мой есчё раз - опять ошибок не нашёл

Пробовал читать сразу после получения (BSY==0 & DRQ==0) регистр ошибки - белиберда какая то , всмысле значиние на линии ata_dd не поменялось - такое же как при чтении регистра статуса: 0х5050....
Пока есчё не верю, что так сложно заставить АТА работать ....

Черт, я все время забываю напомнить вам поглядеть сюда.

2 DmitryR - там глядел на основании этого прожекта и построен процесс для ПИО времянок.

Добрый человек подсказал поглядеть сюда http://www.heeltoe.com/software/pdp11/index.html - вроде бы полноценный прожект - залил и проверил.
Постараюсь переделать под V5 и посмотреть как заработает.

пс
Есчё что забавно - идентификация устройства проходит на ура
Файлы прожекта прицепил Нажмите для просмотра прикрепленного файла
Может какой добрый человек посмотрит
(там IDENTIFY_DEVICE в SOFT RESET Machine - всмысле после софт ресета я делаю идентификацию и смотрю чипскопом )

Кстати, никто не проверял http://www.aipst.com/aips7102.tar.gz ? Вроде бы пишут, что нормальная PATA моделька, только полазил я в линухе по этому архиву никаккого файла и близко напимонающего модельку не нашёл (этот товарисч, что её написал, даже синтезируемый сата-девайс выкладывал на форуме хилых)
Только не ясно как её оттуда выколупать

Уважаемый Kuzmi4, а чем собственно закончилась работа и где можно разжиться моделькой PATA?
"Просел" на подобной задаче с единственным отличием в том, что у меня мост PATA->SATA и требования по линейной
скорости записи порядка 130МБайт/с.