Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SATA analyser на Virtex-II Pro
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
xhdl
Есть задача сделать устройство, которое будет мониторить SATA traffic между хостом и драйвом. Идеально было бы иметь возможность модифицировать данные. Из подручных материалов имеется Virtex-II Pro Evaluation board
http://www.em.avnet.com/evk/home/0,1719,RI...253DEVK,00.html

Я понимаю, что для SATA Virtex-II Pro не самый идеальный выбор (проблемы с OOB signalling), но может у кого-то есть опыт работы с SATA и/или с MGT, или кто-то делал подобное устройство?

Самая первая проблема - как правильно согласовать шину, чтобы Virtex-II Pro не мешал нормальной работе host<->drive?

А может кто-то возьмется сделать такое устройство, естественно не бесплатно?

Regards,

xhdl
VslavX
Цитата(xhdl @ Mar 29 2006, 17:00) *
Есть задача сделать устройство, которое будет мониторить SATA traffic между хостом и драйвом. Идеально было бы иметь возможность модифицировать данные. Из подручных материалов имеется Virtex-II Pro Evaluation board

Собственно SATA потоке осмысленно чего-то поменять вряд ли удасться. ИМХО, если уж реализовывать идею полностью (с подменой данных, а не только монитор), то надо бы сделать свой SATA-девайс, включается вместо иссследуемого, принимает его команды, делает с ними чего надо и транслирует через свой SATA-хост далее на исследуемый девайс. И в обратном порядке. Тут конечно latency вырастет. Зато можно было бы стандартные SATA мосты применить и никаких проблем с шиной не будет. Или нужен полный "stelth mode"?
xhdl
[/quote]
Собственно SATA потоке осмысленно чего-то поменять вряд ли удасться. ИМХО, если уж реализовывать идею полностью (с подменой данных, а не только монитор), то надо бы сделать свой SATA-девайс, включается вместо иссследуемого, принимает его команды, делает с ними чего надо и транслирует через свой SATA-хост далее на исследуемый девайс. И в обратном порядке. Тут конечно latency вырастет. Зато можно было бы стандартные SATA мосты применить и никаких проблем с шиной не будет. Или нужен полный "stelth mode"?
[/quote]

Изначально так и было задумано и подключено (latency здесь не важна), но в просессе выяснялось, что Virtex-II Pro не умеет распонавать OOB последовательность, а она как раз есть COMRESET или COMINIT для драйва или хоста соотв. Поетому я попробовал подключить только одну пару RX на Xilinx на TX драйва, чтобы просто можно было ловить пакеты уже после того, как хост и драйв между собой договорятся. Но несмотря на то что ето не повлияло на работу хоста и драйва, сам Xilinx не может засинхронизироваться на етот stream (RXOUTOFSYC потоянно прыгает и редко бывает 00). Есть подозрения, что ето из-за рассогласованноти линии (1 x TX нагружен на 2 x RX), а как это поправить я не знаю. Может дело в jitter генератора конечно или я здесь что-то совсем упускаю?

А какие есть стандартные SATA мосты?

Regards,

xhdl
VslavX
Цитата(xhdl @ Apr 2 2006, 17:56) *
А какие есть стандартные SATA мосты?

Я имел ввиду "полную высокоуровневую интеллектуальную" виртуализацию smile.gif
Типа имеем цепочку:
- SATA-PATA мост (типа SiI3611 от Silicon Image)
- ПЛИС с PATA девайсом (ну пусть PATA<->PCI)
- процессор с PCI
- SATA-хост (типа SiI3114)
То есть полностью подменяем девайс своей интеллектуально платой.
Но, cудя по Вашему посту, Вам интересно посмотреть на поток на самом низком уровне.
Может быть тут помогут SerDes-ы? Принимаем SATA поток от хоста, преобразуем десериализатором в параллельный код, (10-битовый), работаем в параллельном коде Virtex-om и отдаем его на сериализатор на девайс. И соответственно обратно. То есть подключаемся к линку в разрыв, а не "сбоку", нарушая все согласования. SerDes - можно глянуть тот же SI - SiI2022 и SiI2024.
Можно тогда и ПЛИС-ку попроще, не обязательно VirtexII.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.