Посоветуйте, пожалуйста, как лучше реализовать 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 всегда...