Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Трансмиттер ALTGX выдаёт константу
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
myq
Доброго всем дня.

Cyclone IV GX, q11.0 + modelsim
ALTGX: Basic mode, 3 gb/s, 8b/10b, 16bit, transmitter+receiver, 1 lane.

Сначала не заводился ресивер, выяснилось, что reset'ы всем подблокам ALTGX надо слать не одновременно, а в хитрой последовательности, указанной в handbook.

Но, когда ресивер заработал, выяснилось, что трансмиттер шлёт константу в коде 8b/10b, т.е. битовую последовательность равную одному и тому же значению до кодирования, при этом я передаю реально - значение счётчика, т.е. должно меняться, но не меняется.

Один дизайнер уже сталкивался с этим на Alteraforum.com ему помогла доп. задержка между взведением pll_locked и сбросом tx_digitalreset (хотя эта задержка не требуется по хэндбуку).
Я пошёл дальше и игрался с задержкой вплость до огромной - 3000 тактов на частоте 75 МГц, результата нет.
Пробовал и RTL и Timing симуляцию.

Ссылка на кросспост - http://www.alteraforum.com/forum/showthread.php?p=119921 там моё сообщение третье.

Кусок инициализирующего кода:

Код
initial begin
        gxb_powerdown <= 0;
        pll_areset <= 0;
        rx_analogreset <= 0;
        rx_digitalreset <= 0;
        tx_digitalreset <= 0;
        
        #10000 gxb_powerdown <= 1;
        pll_areset <= 1;
        rx_analogreset <= 1;
        rx_digitalreset <= 1;
        tx_digitalreset <= 1;
        
        #1000000    pll_areset <= 0;
        gxb_powerdown <= 0;
        wait( pll_locked) repeat( 300) @ (posedge tx_clkout);
        tx_digitalreset <= 0;
        wait( ~busy) repeat( 3) @ (posedge tx_clkout);
        rx_analogreset <= 0;
        wait( rx_freqlocked) #4000000 rx_digitalreset <= 0;
    end


Строчка wait( pll_locked) repeat( 300) @ (posedge tx_clkout); и даёт дополнительную, но необязательную по хэндбуку задержку.

Кто поможет, как завести трансмиттер.
XVR
Цитата
Кусок инициализирующего кода:
Вы в курсе, что ваш инициализирующий код не синтезируемый? Или вы трансмитер исключительно в Modelsim'е проверяли?
Postoroniy_V
Цитата(myq @ May 19 2011, 22:15) *
................


wait( pll_locked) repeat( 300) @ (posedge tx_clkout); Почему тут юзается tx_clkout? ведь там фиг знает что может быть..
tx_digitalreset <= 0;
wait( ~busy) repeat( 3) @ (posedge tx_clkout);
rx_analogreset <= 0;
wait( rx_freqlocked) #4000000 rx_digitalreset <= 0;
end

вы бы прицепили gxb сгенерёный, я бы попробовал.
myq
Цитата(XVR @ May 20 2011, 11:43) *
Вы в курсе, что ваш инициализирующий код не синтезируемый? Или вы трансмитер исключительно в Modelsim'е проверяли?


да, пока только в симуляции.


Цитата(Postoroniy_V @ May 20 2011, 13:53) *
вы бы прицепили gxb сгенерёный, я бы попробовал.


цепляю весь тестовый проект, ноу хау в нём никакого нет, только донт-ноу хау sm.gif

Там только квартусовое всё. Скрипты под симулятор не успел написать, пользовался NativeLink.
warrior-2001
cal_blk_clk
pll_inclk
tx_datain : (xx:0)
tx_digitalreset : (0:0)
tx_clkout : (0:0)
tx_dataout : (0:0)
- вот тот минимум сигналов, который позволяет работать с трансмиттером. Данные на tx_datain : (xx:0) нужно обязательно синхронизировать частотой tx_clkout : (0:0)!
А вот pll_locked : (0:0) может и не появляться. Его наличие зависит от значений скорости канала и cal_blk_clk. Иногда pll просто не используется и на выходе pll_locked : (0:0) всегда ноль.
Так что ошибочно ждать этого сигнала всегда. Лучше на него не завязываться вовсе, а использовать pll_locked любой внешней pll.
myq
Цитата(Postoroniy_V @ May 20 2011, 13:53) *
wait( pll_locked) repeat( 300) @ (posedge tx_clkout); Почему тут юзается tx_clkout? ведь там фиг знает что может быть..

с одной стороны после pll_locked там уже не абы-что, а с другой - это же просто пауза, нам подходит любой клок, по которому можно сделать паузу. эта пауза не требуется по хэндбуку, но она помогла в похожей ситуации юзеру с alteraforum

Цитата(warrior-2001 @ May 20 2011, 16:28) *
cal_blk_clk
pll_inclk
tx_datain : (xx:0)
tx_digitalreset : (0:0)
tx_clkout : (0:0)
tx_dataout : (0:0)
- вот тот минимум сигналов, который позволяет работать с трансмиттером. Данные на tx_datain : (xx:0) нужно обязательно синхронизировать частотой tx_clkout : (0:0)!
А вот pll_locked : (0:0) может и не появляться. Его наличие зависит от значений скорости канала и cal_blk_clk. Иногда pll просто не используется и на выходе pll_locked : (0:0) всегда ноль.
Так что ошибочно ждать этого сигнала всегда. Лучше на него не завязываться вовсе, а использовать pll_locked любой внешней pll.

и самое печальное, что эти сигналы поданы, а выход печален. он есть, это последовательность нулей и единиц, кодирующая ту или иную константу. константа меняется, если менять задержки сбросов.
myq
Пытаюсь играться с ALTGX дальше.
Затягиваю tx_digitalreset вверху надолго, RX инициализируется, опускаю tx_digitalreset. RX показывает смену символов (8b/10B) , в т.ч. COMMA (K28.5) и установку в очередной раз константы.
Прочитал ещё раз handbook, выяснил, что для симуляции рекомендуется не использовать некоторые сбросы, например, gxb_powerdown. Там целая статья на тему - чем отличается поведение в симуляции от реальности. Забавно правда?
Предчувствую необходимость написания очередного письма в Альтеру.

Вообще, странно. RX, более сложная половина трансивера, работает вроде нормально, а TX - заметно более простая часть - никак не сделает то, что от неё требуется.
torik
А подскажите, как эту хрень вообще моделировать?
Можно в моделсиме посмотреть временные диаграммы, готорые генерит ALTGX по дифф.линии? И можно ли завести TX на RX в тестбенче?
myq
Цитата(torik @ May 23 2011, 14:17) *
А подскажите, как эту хрень вообще моделировать?
Можно в моделсиме посмотреть временные диаграммы, готорые генерит ALTGX по дифф.линии? И можно ли завести TX на RX в тестбенче?


да, внешний тестбенч файл (внешний, т.к. его компилирует не ква, а симулятор) может соединять всё, что угодно. диф.линии там генерятся, и видны прекрасно. более того, их можно руками генерить/анализировать.
warrior-2001
Если есть возможность - попробуйте то же самое, но на более старых версиях квартуса. У меня 10.1 - полёт нормальный. И на модели и в железе всё работает.
myq
Да снёс недавно уже.
Там ещё есть странная вещь. Есть такая фича как RX local divider. По handbook'у она доступна в 30- 50- и 75-тысячниках. По квартусу - в 50, 75 и 110-тысячниках. Опять расхождение. Убедился, что оба квартуса в этой ситуации ведут себя одинаково - стёр более старый.
К тому же в 11.0 обещали точную тайминг модель 4-х циклонов GX.
myq
Разобрался. Полез уже во внутренности ALTGXа. Оказалась банальная опечатка в тексте тестбенча.

Офф.
- Но по ALTGX-ам вопросы ещё остаются. При включении режима SSC, хватит ли полосы захвата PLL на полосу SSC ( до -0.5% от частоты) ?
- SSC доступно только в 30k, 50k, 75k (как по хэндбуку) или для 50, 75, 110, как и RX local divider (как по квартусу) ?
- В Arria II GX, похоже, нет этих RX local divider, можно ли делать Speed Auto-Negotiation без переконфигурирования PLL ?
Будем разбираться.

Спасибо за советы всем, кто отвечал.
Koluchiy
Здравствуйте.

А Вы пробовали симуляцию приемопередатчика "Gate Level Simulation"?
У меня в "RTL Simulation" вроде всё работает, в "Gate Level" сигнал "busy" не уходит в 0...

В результате, логика (моя) не выводит из ресетов приемник, он естественно не работает.
Передатчик работает нормально.
mekashikuta
Доброе утро ! Пытаюсь заставить заработать Arria II. Подаю сигналы сброса в той же последовательности что и было сказано выше, однако на выходе ресивера имею константу 16'h9C9C. В том случае если увеличиваю длительность tx_digitalreset и сбрасываю его одновременно с rx_digitalreset, то на модели начинает работать, в плате нет. если управлять tx_digitalreset по описанию в handbook, то даже на модели вижу на выходе rx_dataout 16'h9C9C. Мб кто нить сталкивался с этим ?
myq
Цитата(Koluchiy @ Aug 18 2011, 09:23) *
Здравствуйте.

А Вы пробовали симуляцию приемопередатчика "Gate Level Simulation"?
У меня в "RTL Simulation" вроде всё работает, в "Gate Level" сигнал "busy" не уходит в 0...

В результате, логика (моя) не выводит из ресетов приемник, он естественно не работает.
Передатчик работает нормально.



Gate-level не пробовал. С тех пор много воды утекло. Altera выпустила Errata: Отказ от SSC -> отказ от 3-х протоколов, в том числе и нужный мне. Мы заказали Arria 2 GX младшую. Будем с ней играться.

Цитата(mekashikuta @ Aug 19 2011, 08:46) *
Доброе утро ! Пытаюсь заставить заработать Arria II. Подаю сигналы сброса в той же последовательности что и было сказано выше, однако на выходе ресивера имею константу 16'h9C9C. В том случае если увеличиваю длительность tx_digitalreset и сбрасываю его одновременно с rx_digitalreset, то на модели начинает работать, в плате нет. если управлять tx_digitalreset по описанию в handbook, то даже на модели вижу на выходе rx_dataout 16'h9C9C. Мб кто нить сталкивался с этим ?


Я из описания понял, что для работы в железе достаточно дёргать только общую gxb_powerdown и всё (в отличии от симуляции).
Сами ещё не пробовали, плату делаем под Аррию как раз.
mekashikuta
Насколько я понял из описания, правда у меня частный случай, а именно сата интерфейс, то там придется еще самому реализовывать автомат OOB состояний. никто с этим не сталкивался ? и в моем случае к сожалению даже на модели одним gxb_powerdown уж точно не обойтись. сейчас ситуация такая, что трансивер не выходит из состояния rx_locktorefclk по причине отсутсвия активного сигнала rx_signaldetect.

Причем основная головоломка в том, когда именно начинать разворачивать времянку OOB поледовательности. на данный момент самым логичным кажется вариант сразу после того как отпускается rx_analogreset.
Putnik
разгребаю DEMO SATA проект(приаттачен) c диска к SATA/SAS Daughter Card, насколько понимаю собран он из периферийных блоков для ниоса, но без ниоса. cranky.gif

но самое интересное, в файле nios_bts_port_core.v подцепляются конструкцией generate if относительно 2-х параметров (component_type && serial_channels) блоки altgx и altgx_reconfig
Но!!! параметры определены component_type = XCVRS и serial_channels = 6, а квартус цепляет другие блоки с параметрами (component_type == "S4GX_HSM_XCVR") && (serial_channels == 4). Почему так, хоть убейся не понятно, эти параметры больше нигде не используются smile3046.gif

nios_bts_port_core.v находится по маршруту \pld\bts\bts_com\lib\hw\ports\
myq
Цитата(mekashikuta @ Aug 23 2011, 18:32) *
Насколько я понял из описания, правда у меня частный случай, а именно сата интерфейс, то там придется еще самому реализовывать автомат OOB состояний. никто с этим не сталкивался ? и в моем случае к сожалению даже на модели одним gxb_powerdown уж точно не обойтись. сейчас ситуация такая, что трансивер не выходит из состояния rx_locktorefclk по причине отсутсвия активного сигнала rx_signaldetect.

Причем основная головоломка в том, когда именно начинать разворачивать времянку OOB поледовательности. на данный момент самым логичным кажется вариант сразу после того как отпускается rx_analogreset.


Я думаю, обмен начинается после rx_signaldetect.
mekashikuta
Вот пока что не удается rx_signaldetect без реализации OOB заставить шевелится ((
mekashikuta
Кстати никто не знает что за патч такой version 10.1 Patch 0.63 for Windows (.exe) на официальном сайте не дает возможности его скачать, пишет что нет такой странички.
Shivers
Может, ктонибудь знает, мне квартус 11.0 SP1 постоянно вываливает ошибки:
Critical Warning: GXB Central Management Unit (CMU) <Instance specific to your design> is not connected to a GXB reconfig logic block, but the RX offset cancellation feature requires that it must be
ошибка вроде как описана здесь сайт альтеры , но решение мне не помогает.

В кратце, моя ситуация: startixIV, пытаюсь вставить в проект мегафункцию altgx в режиме 4x. После прочтения солюшна догадался сконфигурить и добавить в проект мегафункцию altgxreconfig, в минимальной конфигурации (reconfig_to / from gxb и reconfig_clk), и подключил порты. Но, не помогает, выдает тот же критикал ворнинг.
Ошибки вываливаются в количестве 8 штук - на 4 ресивера и 4 трансивера


Upd: Нашел ошибку в подключении портов, вопрос снят.
myq
Цитата(mekashikuta @ Sep 21 2011, 16:45) *
Кстати никто не знает что за патч такой version 10.1 Patch 0.63 for Windows (.exe) на официальном сайте не дает возможности его скачать, пишет что нет такой странички.


Где-то находился на оф.сайте, непомню где именно.
mekashikuta
При компилировании проекта, когда начинает работать quartus_asm выдает такую инфу "Info: Command: quartus_asm --read_settings_files=off --write_settings_files=off PROJECT -c PROJECT
" . Складывается такое впечатление что квартус ассемблер не подчитывает установки в файле *.qsf, не подскажете возможно ли из оболочки включить какую нибудь настройку, чтобы команда выполнялась вот таким вот образом :"quartus_asm --read_settings_files=on --write_settings_files=off PROJECT-c PROJECT"? Заранее всем огромное спасибо.
spectr
Пытаюсь смоделировать работу ALTGX в моделсиме.

Компилируется успешно, но при симуляции vsim почему-то выдает ошибку что не видит следующие порты:
Код
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'rx_digitalreset' not found in the connected module (4th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'rx_analogreset' not found in the connected module (5th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'tx_digitalreset' not found in the connected module (6th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'gxb_powerdown' not found in the connected module (7th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'pll_powerdown' not found in the connected module (8th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'pll_locked' not found in the connected module (14th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'rx_pll_locked' not found in the connected module (15th connection).
#         Region: /tb/transceiver
# ** Error: (vsim-3389) d:/projects/fpga/arria_gx/testbench/tb.v(73): Port 'rx_freqlocked' not found in the connected module (16th connection).
#         Region: /tb/transceiver
# ** Fatal: (vsim-3365) d:/projects/fpga/arria_gx/testbench/tb.v(73): Too many port connections. Expected 11, found 19.


В мегавизарде, в сгенерированных им файлах все эти порты присутствуют, но симулятор их в упор не видит..... Что я делаю не так?
П.С.: до этого удавалось запустить симуляцию (но в тот раз перечисленные порты как раз были отключены в мегавизарде).

Все библиотеки и файлы обновляются - проверял, удалял, перегенерировал уже по сто раз.
Симуляцию запускаю вот так:
Код
vsim -L altera_mf -L lpm -L sgate -L arriaii_hssi lib/work.tb




Блин, стоило только написать пост как через минуту нашел досадную опечатку sm.gif Вопрос снят.
spectr
Удалось все завести. Теперь такой вопрос - может ли ALTGX выдавать данные вперемешку с embedded-клоком? Пока на выходе (tx) что вижу только данные.....

То есть хотелось бы что-то вроде данных, обрамленных старт-стоповыми битами, являющимися emb-клоком... Он такое сумеет? Насколько я понял, нет и придется как-то делать это самому. Но могу ведь ошибаться )



Еще один вопрос вдогонку:
Приемник трансивера настроен на выделение клока из данных (CDR-mode). Каким образом надо подмешивать в данные этот клок? Старт-стоповые биты или как-то еще? Пока что не очень понятно как он выделит такт из потока данных...
spectr
Кто работал с этой коркой, подскажите как можно красиво из положения:

На вход идут 12-битные данные (10 бит данные, обрамленные старт-стоповыми битами), однако ALTGX умеет принимать только 8, 10, 16 или 20 бит.
Сейчас пытаюсь сделать следующим образом: трансивер настроен на 16 бит и синхронизацию по определенному коду.
Внешним устройством перед началом передачи данных отсылается синхронизирующий код, после чего начинается передача данных.
Далее по идее достаточно из 16-битного выхода трансивера выковыривать нужные биты. Но проблема в том, что 12 битные данные "плывут" внутри 16-битного выхода, т.е. каждый раз нужно брать разные биты из этой шины. Как можно здесь поступить?
spectr
Решил эту проблему следующим образом: накапливаю в буфер по 3 16-битных слова, после чего выдаю 40 бит данных. Этот принцип - следствие того, что 16*3=48 и 12*4=48. Такое соотношение позволяет передавать данные "фреймами" по 48 бит. Но т.к. в данных есть старт-стоповые биты (по 2 бита на каждые 12), то истинных данных в итоговом фрейме будет 40 бит.

Однако, обнаружилась следующая проблема: шина rx_dataout "плывет"... Пока не могу понять что является причиной этого поведения. Неверно настроено ядро, неверно формирую вход или же нужно дополнительно делать какую-то следящую за этим "уплывом"логику? У кого какие мысли? Картинку прилагаю. На ней красной линией показано направление сдвига данных... Собственно, сейчас только оно все портит...

Нажмите для просмотра прикрепленного файла
warrior-2001
Цитата(spectr @ Oct 20 2011, 12:46) *
...
Однако, обнаружилась следующая проблема: шина rx_dataout "плывет"...


Советую покурить доки. Помочь должны сигналы rx_patterndetect, а так же ключевые слова Word Aligner и Byte Ordering Block.
spectr
Доки курю, но пока не все непонятно.

Упростил проект: перевел трансивер в 8-битный режим, оставил только тупой счетчик - та же фигня...
Что интересн, стробы syncstatus и patterndetect появляются, word aligner выравнивает данные как надо но через какое-то время данные все равно плывут (картинка аналогична приведенной постом выше).......
Я так понимаю, тут даже Byte Ordering не поможет, поскольку ему надо будет как-то следить за этим уплывом.....
spectr
Удалось стабилизировать ситуацию следующим образом: в качестве генератора быстрого клока внешнего устройства использовал ALTPLL. Все заработало - ALTGX детектит нужный паттерн и замечательно синхрится.

Однако, меня мучает вопрос - почему же, когда я генерирую частоту самостоятельно (речь идет о тестбенче), то приемник трансивера, такое ощущение, что срывается. ALTPLL генерирует частоту более точно, чем я?

До ALTPLL данные выдавал так (эмуляция внешнего устройства):
Код
    parameter data_rate = 792; // Mbps
    parameter data_period = (1 / (data_rate * 1e6)) * 1e9;

    task send_word;
        input [15:0] data;
        begin
                            rx_datain = data[0];
            #data_period    rx_datain = data[1];
            #data_period    rx_datain = data[2];
            #data_period    rx_datain = data[3];
            #data_period    rx_datain = data[4];
            #data_period    rx_datain = data[5];
            #data_period    rx_datain = data[6];
            #data_period    rx_datain = data[7];
            #data_period;
        end
    endtask

    // send sync pattern
     send_word(8'h 6f);
     send_word(8'h 14);

    // send data
    forever begin
        send_word(cnt);
        cnt = cnt + 1;
    end



Сейчас же делаю так (эмуляция внешнего устройства):
Код
    always @(posedge rx_clkout) if(rx_syncstatus & rx_patterndetect) rx_enapatternalign <= 0;

    fastpll fastpll
        (
            .inclk0     (pll_inclk), // pll_inclk_freq = 79.2
            .c0         (fast_clk),  // pll_inclk * 10
            .locked     ()
        );

    always @(posedge pll_inclk) begin
        cnt <= cnt + 1;
    end

    always @(posedge fast_clk) begin
        fast_bit_cnt <= fast_bit_cnt + 1;
        fast_reg <= cnt[fast_bit_cnt];
    end


В чем тут принципиальная разница? Такое ощущение что раньше выход трансивера плыл, потому что медленно плыл поток сериализованных данных на входе трансивера. Но я пока не могу понять как мне увидеть где сидит эта разница между моим (очевидно косячным кодом) и ALTPLL?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.