Как работать с 4-ым циклоном на двух фронтах на высокой частоте? Опции

[iiv]

Всем привет,

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

Есть оцифровщик, который валит по 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

Спасибо

ИИВ

[bogaev_roman]

К вечеру честно не осилил прочитать такой объем слов...
Я так понимаю, что суть вопроса изначально в том, чтоб принять данные на 800МГц по lvds и дальше их прогнать через DDR по срезу/фронту тактовой 400, а потом каким-то образом дальше обработать? Если так, то я сейчас лопачу данные на 1000МГц и тактовой в 500Мгц правда на стратиксе 4. Для этих целей использую altlvds_in. Все работает вроде без проблем.
Единственное, для сериализации на два я не смог задать сдвиг клока относительно данных, чтоб тактовая попадала точно в окно данных (у меня там нет возможности подстройки) и пошел немного по другому пути. Советую убедиться, что Ваш клок сдвинут относительно данных на 90 градусов на gate моделировании и после компиляции в отчете фиттера не было игнорирования о сдвиге. Задайте в timequest входной клок и убедитесь, что сгенерированный клок от функции altlvds относительно исходного сдинут на 90 градусов...
PS Можно, кстати, и не заморачиваться с моделированем, а просто в timequest в report path проследить задержку от пина данных до ddio и от пина клока до pll а потом от pll до ddio. Чтоб правильно все работало требуется опять же убедиться, что тактовая сдвинута относительно данных на 90 градусов.

Сообщение отредактировал bogaev_roman - Jul 20 2011, 17:23

[iiv]

Спасибо Вам, Роман,
за Ваши советы и комментарии!

Я так понимаю, что суть вопроса изначально в том, чтоб принять данные на 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]

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

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

[iiv]

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

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

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

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

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

Спасибо

ИИВ

[des00]

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

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