[iiv 29]

Всем привет,

 

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

 

Есть оцифровщик, который валит по 8 лвдс на ужасной скорости данные. Надо их собрать и распараллелить, послав по 56 ногам, но, уже в 3.5 раза медленнее. Хочу потренироваться на кошках, то есть, например, на одной терасиковской борде DE2.

 

У оцифровщика есть два клока: фрейм и дата клоки, фрейм работает на частоте Х по двум фронтам, а дата клок - на скорости Х*3.5 по двум фронтам. В пике Х=125МГц, сейчас мои кошки тренируются на Х=800/7МГц, то есть около 114МГц при датаклоке 400МГц.

 

Пытаюсь скомпилить функцию, и не вписываюсь по Fast 1200mV Minimum Pulse Width со слаком в -0.4нс, в Slow все в порядке.

Понимаю, что если уронить частоту до 98МГц, то все получиться, но вдруг можно работать на большей частоте? У меня и так оцифровщик на 125МГц расчитан, и для меня падение с 125 до 98 МГц уже будет существенным. Вдруг я что-то не так делаю, не так с данными по двум фронтам работаю, и что-то не понимаю, посоветуйте, пожалуйтса!

 

module Input(ClkFrame, ClkData, In, ClkFirst, OutData);
input             ClkFrame /*800/7MHz*/, ClkData /*400MHz*/, ClkFirst /*800/7MHz output clock*/;
input      [7:0]  In /* input data on both fronts with 400MHz*/;
output reg [13:0] OutData[0:3] /* output data on both fronts with 800/7MHz */;

// Memory ////////////////////////////

reg  [2:0] ShiftInd[0:7];
reg  [2:0] OutPos;
reg  [1:0] InPos;

reg [55:0] FIFO1[0:3], FIFO2[0:3];
reg [13:0] AllIn[0:7];
reg [55:0] AllInDM[0:3];
reg        OldState0, OldState1;

// Main Activity ////////////////////


initial
begin
   ShiftInd[0]=5;
   ShiftInd[1]=4;
   ShiftInd[2]=1;
   ShiftInd[3]=1;
   ShiftInd[4]=1;
   ShiftInd[5]=1;
   ShiftInd[6]=1;
   ShiftInd[7]=6;
end


always @(posedge ClkFirst)
begin
   OutPos<=OutPos+1;
   {OutData[0], OutData[1], OutData[2], OutData[3]}<=(OutPos[0])?FIFO1[OutPos[2:1]]:FIFO2[OutPos[2:1]];
end


always @(negedge ClkData)
begin
   for(int j=0; j<8; j++)
   begin
     AllIn[j][0]<=In[j];
     for(int i=0; i<14; i+=2)
       AllIn[j][i+2]<=AllIn[j][i];
   end
   if(ClkFrame!=OldState0)
   begin
     OldState0<=ClkFrame;
     AllInDM[0]<={AllIn[0], AllIn[2], AllIn[4], AllIn[6]};
     AllInDM[2]<=AllInDM[0];
   end
end


always @(posedge ClkData)
begin
   for(int j=0; j<8; j++)
   begin
     AllIn[j][1]<=In[j];
     for(int i=1; i<14; i+=2)
       AllIn[j][i+2]<=AllIn[j][i];
   end
   if(ClkFrame!=OldState1)
   begin
     OldState1<=ClkFrame;
     AllInDM[1]<={AllIn[1], AllIn[3], AllIn[5], AllIn[7]};
     AllInDM[3]<=AllInDM[1];
   end
end


always @(negedge ClkFrame) FIFO1[InPos]<=AllInDM[2];


always @(posedge ClkFrame)
begin
   FIFO2[InPos]<=AllInDM[3];
   InPos<=(InPos)?InPos+1:ShiftInd[OutPos];
end
endmodule

 

Спасибо

 

ИИВ

[VladimirB 1]

Всем привет,

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

А вы смотрели, что вам Кактус нагенерил из вашего платформенно-независимого кода?

Найдите в Кактусе аналог ксилинковского FPGAEditor и посмотрите - солидные люди, помнится, мне утверждали, что оно есть в Кактусе.

 

Я обычно, для достижения максимальной производительности хилых спартанов, вручную вставляю IDDR, ODDR примитивы в код.

[vpd 0]

1. С какого перепугу Вы решили, что будет работать на 400 МГц по двум фронтам? Вот где об этом написано в даташите? Если быть более точным, то там совсем другие данные приводятся. Например, о том, что DDR стандарты имеют порядка 200 МГц всего, см. страницу 1-3 книжки по C4.

2. Можно просто устроить ввод данных на высокой частоте, вдвое большей, чем частота линии данных. Тогда задачка будет тривиальной. Вводится поток в регистр сдвига, который потом раз в N тактов переписывается в параллельный регистр, а из него в такой же регистр, но уже тактируемый на уменьшенной частоте. Попробуйте так сделать, результат Вас удивит. Частота IO может быть поднята до 400 МГц запросто для I/O, а для true LVDS аж до 840 МГц, но я не уверен, что на 840 может что-то внутри кристалла дергаться. Но на 400 будет шевелиться все на любом спидгрейде.

[Timmy 1]

Приём данных на такой частоте требует заведения клока через PLL/DLL с внутренним фидбэком в режиме компенсации задержки на clock tree.

Входные регистры обязательно надо описывать через специализированные DDR примитивы. И задать констрейны для setup/hold входных данных. Судя по тому, что Вы получили ошибку только на частоту клока, это сделано не было, иначе ошибок было бы гораздо больше:).

Кстати, если на 4 циклоне, как на третьем, нет встроенных IO DDR регистров, то с вашей задачей он не справится. Из лоукостов на 400 DDR LVDS точно специфицированы Lattice ECP2 и ECP3.

 

[iiv 29]

Дорогие коллеги,

 

спасибо Вам большое, что отвечаете и не оставляете меня одного с этой незадачкой.

 

1. С какого перепугу Вы решили, что будет работать на 400 МГц по двум фронтам? Вот где об этом написано в даташите? Если быть более точным, то там совсем другие данные приводятся. Например, о том, что DDR стандарты имеют порядка 200 МГц всего, см. страницу 1-3 книжки по C4.

 

Я не нашел 200МГц в главе 1-3 по С4, но на странице 359 в таблице 1-24 для моего EP4CE115 со 7-мым спидгрейтом приводится внутренняя частота в 437МГц. Далее на странице 365 в таблице 1-34 частота чесного ЛВДСа для моего кристалла приведена как 402.5МГц. Из этого я сделал вывод, что вытащить параллельно по каждому фронту данные можно хотя бы по 402.5МГц овой частоте, а, если потом демуксить, пайплайнить, то получу то, что мне надо. Действительно, у меня не наблюдается слаков в Slow 0-85С на 402МГцовой частоте по двум фронтам, но есть слак по ШИМу в Fast 0С. Вот это-то мне и кажется странным, так как, как я понимаю, это характеризует что-то, что не проходит по внутренней частоте, но недостаток в знании и пользовании квартусом не позволяет мне определить где именно происходит затык. На частоте в ДДР 344МГц слаков нет вообше, но мне очень хочется работать на большей частоте именно на этом кристале и без привлечения какой бы то ни было дополнительной промежуточной электроники.

 

2. Можно просто устроить ввод данных на высокой частоте, вдвое большей, чем частота линии данных. Тогда задачка будет тривиальной. Вводится поток в регистр сдвига, который потом раз в N тактов переписывается в параллельный регистр, а из него в такой же регистр, но уже тактируемый на уменьшенной частоте. Попробуйте так сделать, результат Вас удивит. Частота IO может быть поднята до 400 МГц запросто для I/O, а для true LVDS аж до 840 МГц, но я не уверен, что на 840 может что-то внутри кристалла дергаться. Но на 400 будет шевелиться все на любом спидгрейде.

убедительно прошу Вас посмотреть внимательнее на то, что у меня в стартовом топике, там именно то, что Вы написали - демукс в 7 раз, передача на 57МГц всего в пайплайн, и вытаскивание данных из пайплайна по 114МГц по широкому каналу.

 

Переписал по совету VladimirB все через мегафункцию altddio_in, к сожалению, с частотой ничего не изменилось, правда уменьшилось использование лутов.

 

Чтоб быть не голословным, аттачу весь проект как есть, возможно, так будет проще показать мою проблему. Вдруг кто-то мне что-то сможет посоветовать, буду Вам премного благодарен!

 

Спасибо

 

ИИВ

 

PS: редактировал, так как забыл аттачмент

[bogaev_roman 0]

К вечеру честно не осилил прочитать такой объем слов...

Я так понимаю, что суть вопроса изначально в том, чтоб принять данные на 800МГц по lvds и дальше их прогнать через DDR по срезу/фронту тактовой 400, а потом каким-то образом дальше обработать? Если так, то я сейчас лопачу данные на 1000МГц и тактовой в 500Мгц правда на стратиксе 4. Для этих целей использую altlvds_in. Все работает вроде без проблем.

Единственное, для сериализации на два я не смог задать сдвиг клока относительно данных, чтоб тактовая попадала точно в окно данных (у меня там нет возможности подстройки) и пошел немного по другому пути. Советую убедиться, что Ваш клок сдвинут относительно данных на 90 градусов на gate моделировании и после компиляции в отчете фиттера не было игнорирования о сдвиге. Задайте в timequest входной клок и убедитесь, что сгенерированный клок от функции altlvds относительно исходного сдинут на 90 градусов...

PS Можно, кстати, и не заморачиваться с моделированем, а просто в timequest в report path проследить задержку от пина данных до ddio и от пина клока до pll а потом от pll до ddio. Чтоб правильно все работало требуется опять же убедиться, что тактовая сдвинута относительно данных на 90 градусов.

Изменено 20 июля, 2011 пользователем bogaev_roman

[iiv 29]

Спасибо Вам, Роман,

за Ваши советы и комментарии!

 

Я так понимаю, что суть вопроса изначально в том, чтоб принять данные на 800МГц по lvds и дальше их прогнать через DDR по срезу/фронту тактовой 400, а потом каким-то образом дальше обработать?

 

примерно да, но с ньюансами, а именно, на 3-ем стратиксе, 3-ем циклоне с 6-ым спидгрейтом - все ок, то есть можно работать на частоте данных 437МГц по обоим фронтам (мне это и надо), а на 4-ом циклоне с 7-мым спидгрейтом квартус ругается на любые частоты выше 344МГц...

 

Про идею со сдвигом - очень классно, что Вы напомнили, спасибо. Так как клок задается вместе с данными, и он уже сдвинут как надо, а мой внутренний PLL клок развязан с ним по FIFO, то проблем, как я понимаю, не должно быть.

 

PS Можно, кстати, и не заморачиваться с моделированем, а просто в timequest в report path проследить задержку от пина данных до ddio и от пина клока до pll а потом от pll до ddio. Чтоб правильно все работало требуется опять же убедиться, что тактовая сдвинута относительно данных на 90 градусов.

 

простите, покорнейше, начинающего, вот попросил я timequest в report path показать задержку от всех пинов лвдса до выхода ddio и получил таблицу: Total, Incr, RF, Type, Fanout.... Скажите, пожалуйста, а где находится эта задержка и туда ли я смотрю?

 

Спасибо

 

ИИВ

[bogaev_roman 0]

вот попросил я timequest в report path показать задержку от всех пинов лвдса до выхода ddio и получил таблицу: Total, Incr, RF, Type, Fanout.... Скажите, пожалуйста, а где находится эта задержка и туда ли я смотрю?

total - суммарная задержка, соответственно можно проследить весь путь сигнала хоть по элементам (location), начинается все с определенного пина, затем проход через ioibuf, затем ddioincell. Ну и цифры там показывают сколько набегает задержек на каждом элементе и их связях. Если считаете, что у Вас изначально тактовая и данные смещены как надо, то задержка до элемента ddio данных и тактовой должна быть примерно одинаковой и так для каждого DDR регистра с погрешностью.

[iiv 29]

Добрый день, Роман,

 

благодарю Вас за, как всегда, исчерпывающие ответы!

 

...Если считаете, что у Вас изначально тактовая и данные смещены как надо, то задержка до элемента ddio данных и тактовой должна быть примерно одинаковой и так для каждого DDR регистра с погрешностью.

 

посмотрел, примерно половина (0.7нс против 1.66) и все одинаково по всем ногам. С этим вроде разобрался, огромное Вам за это спасибо!

 

Остается вопрос, который у меня был изначально - что я делаю не так, что абсолютно одинаковый проект на EP4CE115F29C7 показывает только 344МГц по двум фронтам, в то время как тот же проект без слаков компилится для EP3C25F324C6 на частоте 437МГц. Уж больно большая разница в 25% при переходе с 3 циклона 6-ого спидгрейда на 4-тый циклон 7-мого спидгрейда, которую я нигде не смог подтвердить по документации...

 

Спасибо

 

ИИВ

[des00 25]

Остается вопрос, который у меня был изначально - что я делаю не так, что абсолютно одинаковый проект на EP4CE115F29C7 показывает только 344МГц по двум фронтам, в то время как тот же проект без слаков компилится для EP3C25F324C6 на частоте 437МГц. Уж больно большая разница в 25% при переходе с 3 циклона 6-ого спидгрейда на 4-тый циклон 7-мого спидгрейда, которую я нигде не смог подтвердить по документации...

не пойму вашего удивления, сыклоны 3/4 сделаны на одной архитектуре (лишние 5 нан не в счет) + у с4 меньше питания ядра (помните, что при разгоне процев повышают напряжение) и у альтеры чем меньше цифра, тем быстрее чип (в порядке убывания скорости, в пределах одного семейства c5 > c6 > c7 > c8)