RoadRunner

Всем доброго времени суток. Пытаюсь сейчас переделать xcvr example для Cyclone 10 GX c 1G на 10G. В проекте изначально были Tranceiver PHY Reset Controller, Native PHY и ATX PLL. На вход ATX PLL подавалось 125 Ггц, на выходе она давала 625 Ггц для tx_serial_clk Native PHY. rx_xdr_refclk того же Native PHY тактировался входными 125 Ггц. И все работало: в Tranceiver ToolKit передатчик передавал, приемник принимал через loopback на плате.Чтобы переделать все на 10G, в настройках Native PHY я включил пересет 10BASE-R, входной клок переделал на 156.25, чтобы на выходе ATX PLL давала 5156.25. rx_cdr_refclk переделал на 322.265625 (10312.5/32) Для этого добавил fPLL,которая из 156.25 делает 322.265625 В результате передатчик работает, а приемник - не лочится ни по reference clock, ни по recovered clock. Смотрю все так же в Tranceiver ToolKit. Посоветуйте, что может быть не так?

Всем доброго времени суток. Задача такая: надо частоту avalon-MM интерфейса контроллера памяти установить в районе 100 Мгц (плюс/минус 10Мгц). Т.е. это частота, с которой логикой планирую писать и читать туда. Проблема в том, что на ките с которым в данный момент работаю (CYclone 10 GX Development Kit), частота входного для памяти клока pll_ref_clk = 21,186 МГц (другие клоки не подключишь - Квартус ругается). При этой входной частоте большой получается частота работы чипа памяти (932 МГц) и как следствие генерируемая частота для тактирования логики emif_user_clk = 932/4 = 233 МГц. Понизить бы ее как-нибудь до 100 МГц. Такая скорость работы чипа мне тоже ни к чему. В предыдущей версии мегафункции DDR3 контроллера был отдельный тактирующий вход для avalon-MM интерфейса. Можно было emif_user_clk понизить на сколько хочешь через внешнюю PLL, завести на этот вход и всю приходящую на него логику. В версии 19.2 такого тактирующего входа у avalon-MM интерфейса я пока не нашел. Т.е. получается, что avalon-MM тактируется напрямую emif_user_clk и это не изменить, а стало быть и приходящая на него логика тоже должна им же тактироваться. И частоту эту ни понизить, ни повысить. Или я что-то неправильно понимаю и есть какие-то возможности? Подскажите, кто знает. Спасибо.

Всем доброго времени суток. Возникла необходимость сделать пакетный уровень для физического канала lvds. В принципе Ethernet полностью подходит, за исключением того, что он довольно громоздкий и, возможно, поддерживают много фич, особенностей, которые мне и не понадобятся. Соответственно, естественным образом возникают вопросы, что оставить, а что нет. Конкретный вопрос у меня в данный момент такой: какой смысл заполнять пространство между пакетами такими на мой взгляд нетривиальными последовательностями, как /K28.5/D5.6/ (IDLE1) и /K28.5/D16.2/ (IDLE2) ? По документации IDLE1 всегда инвертирует диспаритет, а IDLE2 оставляет его без изменения. Т.е. насколько я понимаю, IDLE1 используется для установления диспаритета в отрицательное значение по окончании пакета, если это необходимо, а IDLE2 передается далее, чтобы держать постоянным это значение. Вопрос, зачем? Почему это важно? Почему не менять диспаритет (как обычно это происходит при передаче данных в пакете), передавая, например, /K28.1/ в качестве idle-сигнала?

Понятно) Спасибо.

Всем доброго времени суток. Начал переносить с 13-ого Квартуса на 17-ый и наткнулся вот на такой сюрприз: нет LPM_CONSTANT. Причем в 17.1 Standart Edition она осталась. Исчезла только в Pro. В коде то я ее заменю, разумеется, но она мне нужна для отладки: для ввода значений через In-System Memory Content Editor. Не посоветуете, как из положения выйти?

Вопрос еще вот какой возник. Какая задержка передачи и приема у встроенных в ПЛИС трансиверов, кто-нибудь измерял?

11x11 может и втисну) Но лучше с запасом взять: там ширина всей платы то максимум 15 мм должна быть. У четвертого циклона видел 8x8 мм. Вот это было бы идеально.

Так там еще внешняя память SDRAM к нему, Ethernet-коммутатор, АЦП. Один коммутатор только греется как кипятильник и жрет соответственно. Не знаю, правда, сколько будет жрать ПЛИС с почти гигабитным трансивером, пусть и встроенным. Но пока прихожу к выводу, что стоит эту версию попробовать. Помучаю Custom PHY с требуемым кабелем, посмотрю, что получится. О результатах отпишусь. Всем спасибо за соображения. Да, я и хочу только ПЛИС и АЦП оставить. Так в идеале по энергопотреблению и должно получиться. А основной вопрос сейчас: можно ли обойтись тупо SerDes-ом или придется юзать трансивер с его примочками. Использование трансивера конечно несколько сужает выбор микросхем. Может даже Cyclone IV придется взять, т.к. у пятых со встроенными трансиверами корпуса больно большие. А Вы на ALTLVDS_RX делали или сами на сдвиговых регистрах и PLL? Какая длина LVDS-линии была? 8 - это фактор десериализации? Т.е. по линии 3,6 ГГц шло?

Так я правильно понимаю, что это тот же самый альтеровский встроенный в cyclone трансивер просто для протокола PCI? Там тоже клок с данными замешивается, кодирования делаются т.д. Я внутренние встроенные альтеровские блоки имел ввиду, когда писал dedicated tranceiver в первом посте. Не внешние микросхемы.

Я только не понял, за счет чего он позволяет достичь существенно больших скоростей, чем обычный LVDS по той же витой паре?

Так я и думаю, какой поставить :biggrin: Пока еще никакого нет. Пока вообще все на Blackfin пашет. А в плане PCIe.. я конечно с ним не работал и наверняка чего-то не знаю, но он у меня ассоциируется с чем-то большим и распараллеленным типа слота в системном блоке под видеокарту :biggrin: А у меня то тут четыре витые пары на прием/передачу и плата с пол спичечного коробка) Ну короче, я вообще себе это не представляю)

А SDI зачем? Может просто с сериализатора ПЛИС по диф.выходу подать и все. Он (эквалайзер) уже характеристики линии передачи улучшит. Так-то привлекательное решение, особенно если учесть, что эти эквалайзеры можно просто добавить к стандартному решению в случае чего. Да, многовато конечно. Хотя у меня текущая версия платы около 1 Ватта жрет) Но именно поэтому щас и ломаю голову, как уменьшить, где урезать. А тут на прием-передачу сразу около 0,25 Вт тогда уйдет только на эквалайзеры. Но как дополнительное улучшение, если позволит энергобюджет, очень заманчиво.

Про эквалайзеры я как-то запамятовал. Хорошо, что напомнили. Но скорее всего придется обходиться средствами ПЛИС и минимальной аналоговой обвязкой. Может кстати фильтры аналоговые поставить. Насколько я понимаю, аквалайзинг же тоже аналоговая фильтрация, просто с примочками еще какими-нибудь. Так они АЧХ линии и выправляют. А так платы с жесткими требованиями по размерам и энергопотреблению. Т.е. всякие дополнительные микросхемы, особенно габаритные и жрущие, не приветствуются)) По этой еще причине вариант с трансивером проигрывает: микросхемы cyclone v с трансиверами по размеру больше. Не, собственные генераторы на всех платах разумеется есть, что приемных, что передающих. Они(платы) вообще все одинаковые будут приемо-передатчики. Только эти генераторы должны еще синхронность работы АЦП обеспечить, поэтому не должны уплывать друг относительно друга по частоте. Точные цифры допустимого рассинхрона сейчас не помню, завтра напишу. А на Fiber Channel надо глянуть, спасибо.

А хороший кабель - это какой?

Да, нашел в описании на Cyclone такое. Спасибо за информацию. Хочется упростить физический интерфейс, от PHY/свичей избавиться. Во-первых, едят много. Во-вторых, большие потери и задержки накапливаются при соединени многих элементов друг за другом гирляндой. С потерями, строго говоря, не все ясно, возникают ли они из-за некачественной линии или непосредственно в свиче. Есть подозрение, что второе. Собственно, я щас эту систему и переделываю с Ethernet на более простой физический интерфейс. Под определенный кабель делаю - четыре витых пары. Для полного дуплекса. Я не могу выбрать произвольный, какой хочу. На худой конец и 500 Мбит сгодится. 1000 - это уж задача максимум)

Да, забыл написать, синхронизацию плат планируется делать через этот самый интерфейс передачи данных. Т.е. есть одна плата, задающая клок, а другая (другие) цепляют клок от нее. Таким образом вариант с отдельной линией под клок тут идеально устраивает. В то же время трансиверы выделяют клок из линии данных, который потом по идее доступен для использования в ПЛИС. Но это на бумаге опять же, в теории. Хочется узнать, что там на практике. Трансивер, судя по первому знакомству, - штука довольно громоздкая с кучей функций, кодирований и т.д., да еще и "черный ящик", во внутренности которого, если глюкнет, даже осциллографом не подоткнешься для отладки. Другое дело, если без этих сложностей не обойтись. Например, то же кодирование 8B/10B, которое опционально есть в трансивере, постоянку в линии убирает, что возможно уменьшит энергопотребление. Но я пока это смутно себе представляю. Если вы datasheet на трансивер имеете ввиду, то да, тут тоже вопрос: там в настройках можно выставить минимальную скорость 800Мбит/с. Есть также пересет с настройками на 600 с копейками. Почему такая граница снизу на скорость, и чем она определяется, мне тоже непонятно.

Всем доброго времени суток. Собственно, нужно наладить прием/передачу по LVDS между двумя платами с Cyclone V. Скорость до 1 Гбит/с, расстояние до 20 метров. Мне видятся два варианта: - использовать Dedicated Tranceiver. Будет одна витая пара. Тут проблема в том, что для меня это зверь неизвестный и неизвестно сколько там будет глюков и подводных камней при его отладке. В этой связи хотелось бы послушать опытных в его использовании людей. - прокинуть две витые пары под данные и под клок. Использовать либо готовое решение сериализатора/десериализатора в виде мегафункций ALTLVDS_TX/RX, либо самому это сделать на обычной внутренней PLL (ALT_PLL) и сдвиговых регистрах. Мне больше всего нравится последний вариант - сделать все самому - по причине его прозрачности для меня как для разработчика. И если уж в этом случае исправлять глюки, то в основном свои, а не альтеровских разрабов. Вопрос в том, насколько это вообще реально, нормально выделить и подстроить под данные клок PLLкой на приемной стороне без применения оптимизированных dedicated блоков на таких скоростях и расстояниях. Буду благодарен за советы.

Да, действительно, после предварительного стирания командой Sector Erase 0x20 все заработало. Большое спасибо за помощь!)

Я только стер всю флеш командой Bulk Erase. Думал, что этого достаточно. Я вообще не думал, что это необходимо - в доке вроде указаний на то, что обязательно стирать перед записью нет. Там только везде напоминают, что Write Enable надо выставить. Попробую стереть предварительно, отпишусь, что получится. Спасибо за совет.

Всем доброго времени суток. Работаю с N25Q256 по интерфейсу SPI extended. Идентификатор микросхемы командой READ ID считывается верно. Пытаюсь записать/читать в память. Для этого ставлю выставляю бит Write Enable в статусном регистре. Проверяю - бит установлен. Пишу массив из 32-х байт по нулевому адресу. Последующее считывание статусного регистра показывает, что бит занятости (busy) устанавливается на какое-то время, т.е. команда выполняется. После того, как бит занятости сбрасывается, пытаюсь считать эти же 32 байта по нулевому адресу. Считываются нули. Собственно в этом и проблема. При этом, если перед командой чтения, проверить статусный регистр, то выяснится, что бит Write Enable там уже сброшен. Как будто его нужно выставлять перед каждой записью. Можно было бы предположить, что после команды записи, SPI перестает правильно все читать: и статусный регистр, и данные. Но при этом команда READ ID правильно считывает идентификатор девайса, т.е. она не поломалась. В общем такие пироги. Буду благодарен за помощь в разрешении вопроса.

У меня пока демо-версия на 20 дней (я про TOPjtag)

Я лажанулся с питанием. USB-Blaster нормально работал с альтеровской плис, потому что там на разьеме уже было питание 3.3 V. На разьеме JTAG Blackfin у меня не было питания - я почему-то сдуру подумал, что питание у USB-Blasterа свое)) В общем, подключил 3.3 V c платы на пин USB-Blasterа VCC - все заработало Спасибо, навели на мысль))

Всем доброго времени суток. Кто-нибудь пробовал делать boundary scan Blackfin-процессоров? Пробую использовать программу TOPjtag c Altera USB-Blaster - пишет, что не может найти JTAG-chain, т.е. как будто вообще устройства не видит. Буду признателен за любую информацию по подключению к JTAG-интерфейсу Blackfin.

Интересно, чем все закончилось)) А то у меня аналогичные проблемы с этим гребаным датчиком (hts221): передаю ему b"10001111" после чего перевожу линию данных на прием, генерю 8 импульсов SCK и ожидаю на шине данных 0xBC. Вместо этого там плавно нарастающий сигнал, который читается как 0xFF. Плавно нарастающий сигнал - это скорее всего колебания напряжения в третьем состоянии (десятые доли вольта), т.е. датчик просто отсутствует как драйвер, как будто неживой. У кого нибудь вообще есть положительный опыт использования этого датчика в режиме SPI?

Народ, кто пробовал, отпишитесь по времени компиляции, есть существенные изменения?