Привет всем.
Ситуация такая, есть PCB такого расклада, описаны общие шины
1. CPU(data[31..0],addr[24..0])
2. FPGA(data[15..0], addr[24..0])
3. SDRAM1(data[15..0], addr[15..0])
4. SDRAM2(data[31..16], addr[15..0])
5. FLASH (data[15..0], addr[24..1])

Нужно описать rules для Specctra чтобы скажем один участок цепей
например data[15..0] from CPU to SDRAM1,FLASH был по одним правилам, скажем daisy chain
с определенным выравниваем длины, а другой участок data[15..0] from data[15..0] from CPU to FPGA с другим выравниванием.
2. Что в этом случае делать, т.к. data[31..16] содержит только 2 компонента, а data[15..0] все пять,
и не будет ли проблем, и нужно ли 31..16 выравнивать до той же длины как 15..0, ведь на шине данных любой компонент может являться источноком сигнала... оправданно ли использование chain подключений ?

Давайте с понятиями для начала разберемся - daisy chain - это тип топологии, означает последовательный обход приемников(хотя возможны варианты).Поэтому если Вы хотите, чтобы цепи шли последовательно через все описанные точки, то такую топологию точно нужно задавать.
Чтобы задать разные правила на разных участках - создайте группы и включите в них нужные участки(через fromto). Выравнивание для групп нормально делается.
Насчет топологии - вопрос в частотах. Если все это медленное(20-40МГц), то будет работать и последовательная шина. А если в районе 100МГц или выше, скорее всего не получится. Уже писали об этом - для быстрых шин с несколькими источниками лучше применять топологию звезды, возможно с согласованием в ее центре, возможно с выравниванием длины лучей. Задать звезду для спекктры можно опять же через группы, только ее центр определить через виртуальные пины. А остальные группы соответственно как ВП-ЦПУ, ВП-ФПЖА, ВП-СДРАМ и т.д.

Нажмите для просмотра прикрепленного файла
что касается chain, вот с этим у меня вопрос и возникает. Я как раз пытаюсь по DES_DO.zip понять как это описывается, т.е. создание групп. Но там все очень жестко, чуть ли не через номера пинов. А что нибудь типа (net ADDR* (fromto U1 U2)) нету ?
по поводу идеологии, то на грани... 100 МГц как раз и есть. Вот я картинку приаттачил, может посоветуете чего. Идеология как раз как в первом сообщении, смотря слева первый SDRAM data[31..16], второй data[15..0]/ А где можно посмотреть пример с виртуальными пинами ?

Знакомое название архива, только не помню, что я туда ложил и для какого проекта. А группы действительно в спекктре описываются жестко. Мне тоже как-то хотелось попроще делать, но то ли не разобрался как, то ли невозможно, то ли не работает... уже не помню. Поэтому описывал как есть. А вообще - открывайте мануал, смотрите описание команд, и пробуйте писать. По паре-тройке цепей, чтоб результат был нагляднее. Я именно так пробовал. А то если все сразу скопом прописать, то потом непонятно где логика сбойнула, и почему получается совсем не то, что ожидалось.
Насчет проекта - тяжело без понимания сказать, но я бы попробал ФПЖА подключить к процу отдельным интерфейсом. Наверняка у проца есть что-нибудь последовательное и скоростное. Вот его бы и задействовал. Тогда на шине остались бы только памяти, а так точно системы работают.

Большое спасибо за пинки в нужную сторону. Сегодня попробывал реализовать виртуальные пины на шине адреса. Нет слов, просто ЧУДОВИЩНАЯ разводка. Но правильная с точки зрения длин проводов.
Короче, долго всматриваясь в топологию, стало понятно, что FPGA не укладывается в нормальную шину, она рвет всё и вся, при этом отстоит от процессора на максимальное расстояние. Скорее всего будет сделано подключение по скоростному SPI, спасибо за совет.

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

0xFF: Процессор, как я вижу, EP931x? Нет у него скоростного SPI, к сожалению.

Крамольный вопрос: а ручками дня за четыре сделать не проще? Да и качество априори выше. Платочка-то, простая...

Да, всё верно, это 9315. Насколько я понял из мануала, есть SSP (он же SPI), до 2 МБит/сек. Для тех целей которые возлагаются на FPGA (цифромолотилка), вполне достаточно


Было сделано в Спектре, зачищено руками, затем посмотрен репорт по длинам связей и стало понятно что вероятны сбои на шине данных при работе на высоких тактовых sdram. может я конечно ошибаюсь, с арм-шиной имею дело первый раз и поэтому пытаюсь перестраховать. Во всяком случае, просто "разводку" получить достаточно легко, хорошую - трудно. И именно поэтому я пытаюсь узнать принципы разводки для такой нестандартной шины, где нагрузка на нижней половине шины больше в 2 раза и длинней в 1.5, чем на верхней

Мануал советую изучить максимально тщательно, чтобы не было мучительно больно потом.
Возможно, что для общения с FPGA больше подойдет I2S (у него нормальные каналы DMA + можно гибко установить тактирование).
А загрузка FPGA как организована?


Тут полностью солидарен с коллегой HardJoker'ом - руками в той же Specctr'е все сделать гораздо проще. Расстановка у Вас не очень удачная, но при нормальных нормах проблем не будет.

Могу ошибаться, но всецело доверять проверке целостности сигналов опрометчиво. Особенно после прочтения материалов по измерительным осциллографам LeCroy на www.prist.ru. Попалась статейка по сравнению результатов симуляции и физических измерений высокоскоростных сигналов. Если по памяти, расхождения порядка 30% амплитуды.

P.S. если не найдете, ссылку постараюсь при случае запостить. Интересно, полагаю, будет многим

статей там много, какая из них?
(хорошо бы ссылку )

Похоже что надо всё-таки вешать камень на шину, исходя из потенциальных требований к изделию. Вы же знаете, как иногда бывает, идеология устройства меняется на ходу. И пока можно что-то изменить, надо это делать. По поводу загрузки камня. Я так понял, что вы SSP (SPI) применяете как раз для этого, т.е. последовательную память вешаете прям на D0 камня, ну и клок тоже, а остальное - программно. Хорошее известное решение. Только надо порядок битов менять на обратный в прошивке

Я вообще последовательную память не использовал: прошивка для FPGA лежала в NOR flash процессора, загрузка через SSP.

Возможные варианты передачи данных на шине:
CPU <-> SDRAM - 100 МГц
CPU <-> FPGA - =< 30 МГц
CPU <-> FLASH - =< 30 МГц

Если взять топологию последовательного обхода и высокоскоростную часть шины отделить последовательными резисторами (~ 50 Ом стоят между SDRAM и FPGA с FLASH)???

Моделить нужно, но по идее должно получиться.

Моделил... У нас уже работает такая штука, но ещё не уверен насколько хорошо. Есть эффект : толи в софте толи в железе. Экспериментировать ещё предстоит....

Ещё вопрос: где-то на форуме проскакивало (не помню где), что
.... подверг анализу данное утверждение про клоковый сигнал и .... пришел к противоположному выводу (по крайней мере для процессора S3С2440). Нужно просто взять временные диаграммы этого процессора и скоррелировать их с временными диаграммами SDRAM - памяти с учётом задержки распространения сигнала по линии. Если хотите попробовать - лучше начинать с диаграммы однократной записи в память.

Причём, если уж выравнивать сигналы, то надо выравнивать по длине шину данных и шину адреса, а также вспомогательные сигналы, которые тоже стробирует SDRAM.