Доброго всем времени суток!

Прошу посоветовать методику пред производственной диагностики ПП.
Требуется убедиться в целостности прохождения цифровых сигналов т.к. изделие базируется на базе SoC Cortex-A7 1 GHz и имеет скоростные шины.
Конкретно требуется проанализировать разводку следующих интерфейсов: USB/LAN/SATA
Мне рекомендовали просимулировать в HyperLynx, опыта работы с этим продуктом не имею, да и IBIS модель на данный камень найти не удалось.
Порекомендуйте пожалуйста методику диагностики/симуляции целостности цифровых сигналов, можно ли это сделать в HyperLynx без моделей или каком-либо другом пакете.
Буду очень признателен за любую полезную информацию по теме.

Заранее благодарен!

если у вас xilinx, то смотрите документацию как в vivado экспортировать IBIS-модель на конкретный чип.
если альтера, то всё скачивается с оффсайта.
если чейто ещё, то неплохо бы было сразу писать что за SoC.

нужны IBIS-модели для обоих моделируемых чипов, между которыми у вас "USB/LAN/SATA".
если есть разъемы, то на них нужно тоже иметь модель.


utter nonsense!
ну и что вы будете моделировать без моделей? независимо от среды, гиперлинкс это или ещё что?
может тогда людям стоило бы научиться питаться без еды?

Уважаемый krux,
Процессор - SoC Allwinner A20 processor is a dual-core ARM Cortex-A7
SATA и USB реализованы на боту
Эзернет на чипе rtl8211cl
Перелопатил кучу сайтов/форумов - ну нет модели на этот SoC.
Даже обращался к производителю, ответили что IBIS модели не имеют (это может быть правдой? возможно существуют модели в другом виде и я не так задал вопрос?).
Производитель по идее должен иметь модель, ведь как-то же он тестирует свои чипы или я не прав?
Может быть посоветуете где можно пробовать достать модель?
В общем как я понял без модели мы ничего промодулировать не можем, но каким еще образом можно проверить целостность цифровых сигналов?

Вы можете подключить модель от любой современой FPGA используя ее буферы вместо Soc. Тут смысл в том, что на FPGA модели всегда есть, и раз уж буферы SoC обеспечивают стандарт, и буферы FPGA тоже обеспечивают такой же стандарт, то настроив буферы FPGA на самый жесткий режим, скажем strong, и Ваша плата при этом отработает все как надо, можно быть уверенным что и буферы SoC на такой плате будут работать нормально.

С разъемами примерно такая же ситуация. Берете модель любого SATA разъема который выглядит примерно также как тот, который Вы хотите применить и ставите его в модель печатной платы. Если моделирование пройдет с небольшим запасом, можно быть уверенным что и Ваш разъем будет работать нормально на такой плате.

Благодарю agregat!

Я так понимаю что нужно выбрать наиболее подходящую FPGA на которую есть модель.
Я выбрал Cyclone V SoCs (Обзор SoC), на нее модель как раз есть.
А вот как реализовать нужным образом работу буферов я не понимаю...
Как я говорил с FPGA никогда не сталкивался, если можно в 2-х словах опишите порядок действий.
Спасибо!

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

Если вам нужно промоделировать только интерфейсы нва печатной плате, можно использовать какие-нибудь другую доступную IBIS-модель. Есть опыт работы симулирования интерфейсов (USB,HDMI,DDR3) SoC Cortex-A9 в Sigrity. Там можно IBIS модель контроллера (если нет своей) взять из дефолтного примера, экстрагировать S-параметры (паразиты) своей платы, добавить все в новый проект и все нормально просимулируется. Особенности вашего контроллера нет смысла учитывать, логика всех интерфейсов стандартная. Паразиты корпуса конечно влияют на общую картину, но от другого корпуса вполне подойдут. Тем более вас интересуют возможные косяки вашей ПП, так что можно сделать скидку и поставить идеальные паразиты корпуса и посмотреть как влияют на сигнал только паразиты ПП.

Сообщение отредактировал gerbity - Nov 2 2015, 09:19

Вот тут с Вами не соглашусь... логика, конечно, стандартная. Но реализация драйверов одного и того же стандарта у разных производителей будет совершенно разной. И их ВА-характеристики, а соответсвенно и форма сигналов на одной и той же линии тоже отличаться будет весьма сильно. Вот Вы моделировали DDR3 - посмотрите на сигналы данных в одном и в другом направлении, они весьма заметно отличаются, хотя стандарт сигнала/драйвера один и тот же. Так что тут не соглашусь, как минимум стоит учитывать производителя SoC-a. Можно попробовать взять модель драйвера от другого чипа этого же производителя, если чипы примерно одного поколения и технологии изготовления, но брать модель другого вендора нет смысла - результаты моделирования покажут неизвестно что...

если бы микросхемы разных вендоров вели бы себя "неизвестно как" то кто бы их тогда покупал? Например микросхемы DDR у всех производителей имеют однотипный футпринт как раз для того чтобы можно было практически безболезненно менять одну на другую. Согласен, что будут некоторые отличия, на мой взгляд 10% в худшем случае. В первом приближении этого будет достаточно ,чтобы посмотреть как ведет себя ПП, если она не будет работать с микросхемой одного вендора, то и с другими тоже не будет работать. Моделирование ПП покажет плохие места в топологии, которые и будут ухудшать поведение интерфейса.

Сообщение отредактировал gerbity - Nov 5 2015, 07:21

Ну почему же неизвестно как, известно, из описания в IBIS-модели и известно. Но поверьте, именно по разному себя ведут чипы разных вендоров. Можете это легко проверить: если у Вас есть построенная схема сигнала той же памяти попробуйте поменять в ней модели чипа памяти(там практически на все чипы доступны IBIS-ы) и модели проца(SoC, FPGA). И посмотрите как изменяется сигнал. О 10% речь не идет, там даже форма его будет меняться. Это не меняет факта "попадания" параметров сигнала в рамки требуемого стандарта, но изменения будут и весьма определенные.
С футпринтом Вы правы, есть стандарт и он производителями выполняется, иначе кто купит нестандартные чипы памяти. Но вот реализация драйверов полностью зависит от вендора и как они их реализуют - это закрытая инфа. А разная схемотехника драйверов дает разные формы сигнала.

Из личного опыта: SoC-и от Broadcom разных поколений, HDMI интерфейсы одного стандарта 1.4, формы сигнала совершенно разные, причем настолько, что на одном проце в рамки спецификаций HDMI уложились при дефолтовых настройках PHY, а в другом приходилось подбирать параметры PHY чтобы уложить сигнал в Eye-диаграмму, причем подбирать индивидуально для каждой скорости интерфейса. Так это один вендор, просто разные поколения чипа, но, видимо между ними внесли изменения в схему драйвера и понеслось... Отлаживалось кстати все не на модели, а вживую, на скопе.