Доброго всем дня.
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); и даёт дополнительную, но необязательную по хэндбуку задержку.
Кто поможет, как завести трансмиттер.
Цитата
Кусок инициализирующего кода:
Вы в курсе, что ваш инициализирующий код
не синтезируемый? Или вы трансмитер исключительно в Modelsim'е проверяли?
Postoroniy_V
May 20 2011, 09:53
Цитата(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 сгенерёный, я бы попробовал.
Цитата(XVR @ May 20 2011, 11:43)

Вы в курсе, что ваш инициализирующий код не синтезируемый? Или вы трансмитер исключительно в Modelsim'е проверяли?
да, пока только в симуляции.
Цитата(Postoroniy_V @ May 20 2011, 13:53)

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

Там только квартусовое всё. Скрипты под симулятор не успел написать, пользовался NativeLink.
warrior-2001
May 20 2011, 12: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.
Цитата(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.
и самое печальное, что эти сигналы поданы, а выход печален. он есть, это последовательность нулей и единиц, кодирующая ту или иную константу. константа меняется, если менять задержки сбросов.
Пытаюсь играться с ALTGX дальше.
Затягиваю tx_digitalreset вверху надолго, RX инициализируется, опускаю tx_digitalreset. RX показывает смену символов (8b/10B) , в т.ч. COMMA (K28.5) и установку в очередной раз константы.
Прочитал ещё раз handbook, выяснил, что для симуляции рекомендуется не использовать некоторые сбросы, например, gxb_powerdown. Там целая статья на тему - чем отличается поведение в симуляции от реальности. Забавно правда?
Предчувствую необходимость написания очередного письма в Альтеру.
Вообще, странно. RX, более сложная половина трансивера, работает вроде нормально, а TX - заметно более простая часть - никак не сделает то, что от неё требуется.
А подскажите, как эту хрень вообще моделировать?
Можно в моделсиме посмотреть временные диаграммы, готорые генерит ALTGX по дифф.линии? И можно ли завести TX на RX в тестбенче?
Цитата(torik @ May 23 2011, 14:17)

А подскажите, как эту хрень вообще моделировать?
Можно в моделсиме посмотреть временные диаграммы, готорые генерит ALTGX по дифф.линии? И можно ли завести TX на RX в тестбенче?
да, внешний тестбенч файл (внешний, т.к. его компилирует не ква, а симулятор) может соединять всё, что угодно. диф.линии там генерятся, и видны прекрасно. более того, их можно руками генерить/анализировать.
warrior-2001
May 23 2011, 10:50
Если есть возможность - попробуйте то же самое, но на более старых версиях квартуса. У меня 10.1 - полёт нормальный. И на модели и в железе всё работает.
Да снёс недавно уже.
Там ещё есть странная вещь. Есть такая фича как RX local divider. По handbook'у она доступна в 30- 50- и 75-тысячниках. По квартусу - в 50, 75 и 110-тысячниках. Опять расхождение. Убедился, что оба квартуса в этой ситуации ведут себя одинаково - стёр более старый.
К тому же в 11.0 обещали точную тайминг модель 4-х циклонов GX.
Разобрался. Полез уже во внутренности 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
Aug 18 2011, 05:23
Здравствуйте.
А Вы пробовали симуляцию приемопередатчика "Gate Level Simulation"?
У меня в "RTL Simulation" вроде всё работает, в "Gate Level" сигнал "busy" не уходит в 0...
В результате, логика (моя) не выводит из ресетов приемник, он естественно не работает.
Передатчик работает нормально.
mekashikuta
Aug 19 2011, 04:46
Доброе утро ! Пытаюсь заставить заработать Arria II. Подаю сигналы сброса в той же последовательности что и было сказано выше, однако на выходе ресивера имею константу 16'h9C9C. В том случае если увеличиваю длительность tx_digitalreset и сбрасываю его одновременно с rx_digitalreset, то на модели начинает работать, в плате нет. если управлять tx_digitalreset по описанию в handbook, то даже на модели вижу на выходе rx_dataout 16'h9C9C. Мб кто нить сталкивался с этим ?
Цитата(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
Aug 23 2011, 14:32
Насколько я понял из описания, правда у меня частный случай, а именно сата интерфейс, то там придется еще самому реализовывать автомат OOB состояний. никто с этим не сталкивался ? и в моем случае к сожалению даже на модели одним gxb_powerdown уж точно не обойтись. сейчас ситуация такая, что трансивер не выходит из состояния rx_locktorefclk по причине отсутсвия активного сигнала rx_signaldetect.
Причем основная головоломка в том, когда именно начинать разворачивать времянку OOB поледовательности. на данный момент самым логичным кажется вариант сразу после того как отпускается rx_analogreset.
Putnik
Aug 25 2011, 12:34
разгребаю DEMO SATA проект(приаттачен) c диска к SATA/SAS Daughter Card, насколько понимаю собран он из периферийных блоков для ниоса, но без ниоса.
но самое интересное, в файле 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). Почему так, хоть убейся не понятно, эти параметры больше нигде не используются
nios_bts_port_core.v находится по маршруту \pld\bts\bts_com\lib\hw\ports\
Цитата(mekashikuta @ Aug 23 2011, 18:32)

Насколько я понял из описания, правда у меня частный случай, а именно сата интерфейс, то там придется еще самому реализовывать автомат OOB состояний. никто с этим не сталкивался ? и в моем случае к сожалению даже на модели одним gxb_powerdown уж точно не обойтись. сейчас ситуация такая, что трансивер не выходит из состояния rx_locktorefclk по причине отсутсвия активного сигнала rx_signaldetect.
Причем основная головоломка в том, когда именно начинать разворачивать времянку OOB поледовательности. на данный момент самым логичным кажется вариант сразу после того как отпускается rx_analogreset.
Я думаю, обмен начинается после rx_signaldetect.
mekashikuta
Aug 31 2011, 10:37
Вот пока что не удается rx_signaldetect без реализации OOB заставить шевелится ((
mekashikuta
Sep 21 2011, 12:45
Кстати никто не знает что за патч такой version 10.1 Patch 0.63 for Windows (.exe) на официальном сайте не дает возможности его скачать, пишет что нет такой странички.
Shivers
Sep 21 2011, 16:11
Может, ктонибудь знает, мне квартус 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: Нашел ошибку в подключении портов, вопрос снят.
Цитата(mekashikuta @ Sep 21 2011, 16:45)

Кстати никто не знает что за патч такой version 10.1 Patch 0.63 for Windows (.exe) на официальном сайте не дает возможности его скачать, пишет что нет такой странички.
Где-то находился на оф.сайте, непомню где именно.
mekashikuta
Oct 12 2011, 13:51
При компилировании проекта, когда начинает работать 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
Oct 18 2011, 10:24
Пытаюсь смоделировать работу 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
Блин, стоило только написать пост как через минуту нашел досадную опечатку

Вопрос снят.
spectr
Oct 18 2011, 11:37
Удалось все завести. Теперь такой вопрос - может ли ALTGX выдавать данные вперемешку с embedded-клоком? Пока на выходе (tx) что вижу только данные.....
То есть хотелось бы что-то вроде данных, обрамленных старт-стоповыми битами, являющимися emb-клоком... Он такое сумеет? Насколько я понял, нет и придется как-то делать это самому. Но могу ведь ошибаться )
Еще один вопрос вдогонку:
Приемник трансивера настроен на выделение клока из данных (CDR-mode). Каким образом надо подмешивать в данные этот клок? Старт-стоповые биты или как-то еще? Пока что не очень понятно как он выделит такт из потока данных...
spectr
Oct 19 2011, 14:23
Кто работал с этой коркой, подскажите как можно красиво из положения:
На вход идут 12-битные данные (10 бит данные, обрамленные старт-стоповыми битами), однако ALTGX умеет принимать только 8, 10, 16 или 20 бит.
Сейчас пытаюсь сделать следующим образом: трансивер настроен на 16 бит и синхронизацию по определенному коду.
Внешним устройством перед началом передачи данных отсылается синхронизирующий код, после чего начинается передача данных.
Далее по идее достаточно из 16-битного выхода трансивера выковыривать нужные биты. Но проблема в том, что 12 битные данные "плывут" внутри 16-битного выхода, т.е. каждый раз нужно брать разные биты из этой шины. Как можно здесь поступить?
spectr
Oct 20 2011, 08:46
Решил эту проблему следующим образом: накапливаю в буфер по 3 16-битных слова, после чего выдаю 40 бит данных. Этот принцип - следствие того, что 16*3=48 и 12*4=48. Такое соотношение позволяет передавать данные "фреймами" по 48 бит. Но т.к. в данных есть старт-стоповые биты (по 2 бита на каждые 12), то истинных данных в итоговом фрейме будет 40 бит.
Однако, обнаружилась следующая проблема: шина rx_dataout "плывет"... Пока не могу понять что является причиной этого поведения. Неверно настроено ядро, неверно формирую вход или же нужно дополнительно делать какую-то следящую за этим "уплывом"логику? У кого какие мысли? Картинку прилагаю. На ней красной линией показано направление сдвига данных... Собственно, сейчас только оно все портит...
Нажмите для просмотра прикрепленного файла
warrior-2001
Oct 20 2011, 09:51
Цитата(spectr @ Oct 20 2011, 12:46)

...
Однако, обнаружилась следующая проблема: шина rx_dataout "плывет"...
Советую покурить доки. Помочь должны сигналы rx_patterndetect, а так же ключевые слова Word Aligner и Byte Ordering Block.
spectr
Oct 20 2011, 12:50
Доки курю, но пока не все непонятно.
Упростил проект: перевел трансивер в 8-битный режим, оставил только тупой счетчик - та же фигня...
Что интересн, стробы syncstatus и patterndetect появляются, word aligner выравнивает данные как надо но через какое-то время данные все равно плывут (картинка аналогична приведенной постом выше).......
Я так понимаю, тут даже Byte Ordering не поможет, поскольку ему надо будет как-то следить за этим уплывом.....
spectr
Oct 21 2011, 11:43
Удалось стабилизировать ситуацию следующим образом: в качестве генератора быстрого клока внешнего устройства использовал 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?
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.