Перейти к содержанию
    

zvs

Свой
  • Постов

    209
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о zvs

  • Звание
    Местный
    Местный
  • День рождения 11.05.1981

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

2 136 просмотров профиля
  1. Всем доброго времени суток. Прошла информация о том, что Микрон снимает семейства NOR Flash M25P, M25PX, M25PE, M45PE, N25Q, M29EW, M29DW, J3, P30, P33, MT28G, в частности, по поводу M25P40 о замене ничего не сообщается, contact, мол, factory. По датам сказано так: Last Time Buy - март 2018; Last Time Ship - июнь 2021. Время есть, но в связи с этим - вопрос: кто на что перешел, и чем теперь заменять будем?
  2. 2 IZH7IZH Ушло 2 Alll, телеграмма. связи участившимися случаями запросов на наши исходники зпт выкладываю оные паблик моего дропбокса тчк http://dl.dropbox.com/u/41652962/wiznet.zip Кстати, посмотревшим: принимаются критические замечания по коду и работе, ну и прочие там success story разные... :)
  3. Я так понял, что когда говорят aggregate bandwidth, имеется ввиду, что это bi-direction, то бишь суммарная полоса в обе стороны. Я не прав? А вот нам бы надо 20 в одну сторону... Вот мы к такому и пришли Спасибо за предложение, появятся неразрешимые вопросы - напишем. Спасибо, читаем!
  4. Здравствуйте. Общаюсь тут с заказчиком у которого как обычно "ничего пока не известно, но что-то делать надо уже сейчас" и в процессе выдавливания из него хоть каких-то технических параметров получил: - некий оптический интерфейс; - наверное fiber Channel, ("но, ты понимаешь, там еще они сами ничего не знают"); - скорость передачи данных (дословно) 500 МГц, два 16-и разрядных слова. Пересчитываю , получаю 16 Гбит/с. Разглядываю чего умеет FC и вижу, что единственный вариант это 20GFC. Упоминаний о его реализуемости в интернетах вот как-то сходу не нашлось. В основном как-то "future networks of 21 Gbit/s" да "Fibre Channel уже на данный момент работает над эталоном для скорости 20GFC". Соответственно назрели вопросы: 1. 20GFC - жив? работает? Кто-нибудь применял/видел/слышал/читал? 2. Может кто знает какой-нибудь другой вариант интерфейса для пропиха такого (16 Гбит/с) потока данных? Заранее всем спасибо за ответы! Upd. Нашёл у avago вот такое: AFBR-57F5PZ 14.025/8.5/4.25 GBd MMF Transceiver with Digital Diagnostic for Fibre Channel http://www.avagotech.com/pages/en/fiber_op...el/afbr-57f5pz/ Быстрее ничего не нашёл.
  5. Да, правильно http://www.google.ru/search?q=iir+fpga А по поводу коэффициентов Methane вам уже подсказал. :)
  6. Мы её (или она нас???) испробовали уже во всех позициях, поверьте... Резюмирую: проект мы таки завели на 65 МГц, но не на ddio, из чего сделали вывод что благословенные ddio в Arria II GX не работают на частоте 65*12/2 =390МГц. Аналогичная ситуация со стратиксами 3-4 и даже Arria II GZ на частоте 80*12/2 =480МГц DDR, согласно сведениям TQ. А теперь для истории, и вообще, может кому-то окажется полезно, расскажу как завели. Код для десериализатора переписали вот так: module adc_deserializer(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter WIDTH_ADC_DATA = 12;//ширина шины данных АЦП input s_adc_clk; input s_adc_frame; input s_adc_data; output [WIDTH_ADC_DATA-1:0]adc_data; output en_adc_data; reg n_in_rx, in_rx_p, in_rx_n; reg [WIDTH_ADC_DATA/2-1:0]pos_shift_reg, odd_data; reg [WIDTH_ADC_DATA/2-1:0]neg_shift_reg, evn_data; reg en_adc_frame, en_odd_data, en_evn_data; wire s_adc_clk; reg en_adc_data; wire [WIDTH_ADC_DATA-1:0]adc_data; genvar i; generate for(i=0; i<WIDTH_ADC_DATA/2; i=i+1) begin: assign_adc_data assign adc_data[2*i+1:2*i] = {odd_data[i], evn_data[i]}; end endgenerate always @(posedge s_adc_clk) begin pos_shift_reg <= {pos_shift_reg, in_rx_p}; neg_shift_reg <= {neg_shift_reg, in_rx_n}; en_adc_frame <= s_adc_frame; en_odd_data <= en_adc_frame; en_evn_data <= en_odd_data; en_adc_data <= !en_odd_data; if(en_adc_frame && !en_odd_data) odd_data <= pos_shift_reg; if(en_odd_data && !en_evn_data) evn_data <= neg_shift_reg; end//always always @(posedge s_adc_clk) begin in_rx_p <= s_adc_data; in_rx_n <= n_in_rx; end//always always @(negedge s_adc_clk) begin n_in_rx <= s_adc_data; end //always endmodule То бишь сделали двухфронтовый защёлкиватель, но без ddio c реализацией на логике. Кажный канальчик объединили в общий 8-канальный десериализатор: module adc_deserializers(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter NUM_CHANNEL = 8;//Количество каналов parameter WIDTH_ADC_DATA = 12;//Ширина шины данных АЦП input s_adc_clk; input s_adc_frame; input [NUM_CHANNEL-1:0]s_adc_data; output [WIDTH_ADC_DATA*NUM_CHANNEL-1:0]adc_data; output [NUM_CHANNEL-1:0]en_adc_data; adc_deserializer #( .WIDTH_ADC_DATA(WIDTH_ADC_DATA)) adc_deserializer[NUM_CHANNEL-1:0]( .s_adc_clk(s_adc_clk), .s_adc_frame(s_adc_frame), .s_adc_data(s_adc_data), .adc_data(adc_data), .en_adc_data(en_adc_data)); endmodule TQ сказал +------------------------------------+ ; Fast 900mV 0C Model Setup Summary; +------------+-------+---------------+ ; Clock; Slack; End Point TNS; +------------+-------+---------------+ ; clk_480MHz; 0.125; 0.000; +------------+-------+---------------+ +------------------------------------+ ; Fast 900mV 0C Model Hold Summary; +------------+-------+---------------+ ; Clock; Slack; End Point TNS; +------------+-------+---------------+ ; clk_480MHz; 0.135; 0.000; +------------+-------+---------------+ Далее воткнули этот кусочек десериалайзера в общий проект - полезли отрицательные слаки. Из положения вышли, создав для десериалайзера каждого канала Design Partition, и воткнув их Post-fit в основной проект. Запас по слакам стал меньше, но жить тем не менее можно. Спасибо всем, кто пытался помочь!
  7. rezuk, эх, что ж вы мне раньше в ЛС не написали??? Отправил. dde29, ясновидящая Марья передала мне еще не всю силу, поэтому стелепатировать ваш ящик сходу не удалось, а форма отправки е-писем с форума не позволяет прикреплять файлы. ;) Если еще актуально - шлите адрес в ЛС.
  8. Да, проект с одним каналом и pll приаттачил. Изначально смещён. Я дубина, выложил не тот sdc... Поправил в том посте. Теперь понятно? Это говорит TQ, что input_delay применяется к заднему фронту клока. deserializer_ddio_pll.zip
  9. Timmy, да, проверил на EP1AGX20CF484C6 - все прекрасно собирается... ArriaII - такая гадость??? :( All, звиняюсь - в предыдущем посте версия без pll. pll я прикручивал на одноканальный вариант.
  10. Вот, пожалуйста, ddio, 8 каналов, с прикрученной pll'ю... deserializer_ddio_8.zip
  11. Приаттачил к этому посту (TQ8_detail.jpg). Был всегда уверен, что serdes - это некий аппаратный блок и мешать его с обычным LVDS не стоит. В datasheet (p.1-68, table 1-53) сказано что fHSDR максимум 945 Mbps (для не DPA). "For interfacing with non-DPA receivers, the maximum supported data rate is 945 Mbps. Beyond 840 Mbps, PCB trace compensation is required." То бишь на 780 все равно работать должна. Да По крайней мере в Ignored assignments ничего жуткого не написано. Вариант, предложенный Timmy я пробовал, но: 1) 390 никуда не двигал - она вроде как и так должна стоять как положено - первая картинка в первом посте, на всяк случай прикрепил её и к этому посту (AD9272.jpg). 2) Pll использовал в normal mode. 3) Проект с ddio для одного канала. module adc_deserializer(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter WIDTH_ADC_DATA = 12;//ширина шины данных АЦП input s_adc_clk; input s_adc_frame; input s_adc_data; output [WIDTH_ADC_DATA-1:0]adc_data; output en_adc_data; reg [WIDTH_ADC_DATA/2-1:0]pos_shift_reg, odd_data; reg [WIDTH_ADC_DATA/2-1:0]neg_shift_reg, evn_data; reg en_adc_frame, en_odd_data, en_evn_data; wire en_adc_data, in_rx_p, in_rx_n; wire [WIDTH_ADC_DATA-1:0]adc_data; assign en_adc_data = en_evn_data; align_pll align_pll ( .inclk0(s_adc_clk), .c0(pll_adc_clk)); ddr_rx_in ddr_rx_in( .datain(s_adc_data), .inclock(pll_adc_clk), .dataout_h(in_rx_p), .dataout_l(in_rx_n)); genvar i; generate for(i=0; i<WIDTH_ADC_DATA/2; i=i+1) begin: assign_adc_data assign adc_data[2*i+1:2*i] = {odd_data[i], evn_data[i]}; end endgenerate always @(posedge pll_adc_clk) begin pos_shift_reg <= {pos_shift_reg, in_rx_p}; neg_shift_reg <= {neg_shift_reg, in_rx_n}; en_adc_frame <= s_adc_frame; en_odd_data <= en_adc_frame; en_evn_data <= en_odd_data; if(en_adc_frame && !en_odd_data) odd_data <= pos_shift_reg; if(en_odd_data && !en_evn_data) evn_data <= neg_shift_reg; end//always endmodule 4) sdc файл, практически такой же как и раньше (добавлена команда derive_pll_clocks -create_base_clocks) Поправил 12.08.2011 в 15:25 set_time_format -unit ns -decimal_places 3 create_clock -name {clk_480MHz} -period 390MHz -waveform {0.641 1.923} [get_ports {s_adc_clk}] create_clock -name {clk} -period 390MHz derive_clock_uncertainty derive_pll_clocks -create_base_clocks set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_data}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_data}] set_input_delay -max -clock {clk} -clock_fall 0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -min -clock {clk} -clock_fall -0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_frame}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_frame}] Итог неутешительный: (на всякий случай картинку приаттачил к посту TQ_pll_detail.jpg) Все слаки только по сетапу. Вообще мне совсем не понятно отчего ему так поплохело внезапно. bogaev_roman, Timmy, спасибо за участие! :)
  12. Данные разваливаются. Совсем. Например биты 0 и 2 на выходе десериализатора повторяют друг друга от отсчёта к отсчёту. Бит 10 сбивается в случайные моменты. Охотно верю. И у меня на этих частотах все прекрасно. Запас слаков по сетапу 569, по холду 262 в самом плохом варианте. Кстати, для самого быстрого Циклона все собирается (по мнению TQ) и для 65/390 МГц :( Я с него начинал знакомство с TQ, проштудировал внимательно... Вы имеете ввиду вот это? Кстати от компиляции к компиляции слаки меняются, так что тут они уже не те, что были вчера (в первом посте). В datasheet написано вот так: The minimum and maximum specification depends on the clock source (for example, PLL and clock pin) and the clock routing resource you use (global, regional, or local). The I/O differential buffer and input register do not have a minimum toggle rate. You are required to calculate the leftover timing margin in the receiver by performing link timing closure analysis. You must consider the board skew margin, transmitter channel-to-channel skew, and the receiver sampling margin to determine the leftover timing margin. То бишь, не признаются :( В altlvds я сказал какой у меня будет DataRate, какая частота клока, фазовое соотношение между клоком и данными. altlvds на основании этих данных должен завести PLL так, чтобы на ней сделать нужный для защёлкивания данных клок. И она это делает, Modelsim показывает, что данные собираются те, что были выставлены на линию данных...
  13. Timmy, во первых, спасибо! Во вторых, по вашей ссылке сказано: Не совсем понял терминологию. alt_pll может работать в режимах 1) Normal mode—The PLL feedback path source is a global or regional clock network, minimizing clock delay to registers for that clock type and specific PLL output. You can specify PLL output that is compensated. 2) Source-Synchronous mode—The data and clock signals arrive at the same time at the input pins. In this mode, the signals are guaranteed to have the same phase relationship at the clock and data ports of any Input Output Enable (IOE) register. 3) Zero-Delay Buffer mode—The PLL feedback path is confined to the dedicated PLL external output pin. The clock port driven off-chip is phase aligned with the clock input for a minimal delay between the clock input and the external clock output. 4) No Compensation mode—The PLL feedback path is confined to the PLL loop. It has no clock network or other external source. A PLL in no-compensation mode has no clock network compensation, but clock jitter is minimized. 5) External Feedback mode—The PLL compensates for the fbin feedback input to the PLL. The delay between the input clock pin and the feedback clock pin is minimized. Согласно описанию 2-4 не подходят, не так ли? 5 в Arria II GX не поддерживается...
  14. ...продолжение Собрали проект с altlvds, поскольку данные АЦП 12 бит, в SERDES это добро уже не помещается, используем "circuity in logic cells", в качестве клока для altlvds используем сигнал FCO АЦП. module adc_deserializer(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter WIDTH_ADC_DATA = 12;//ширина шины данных АЦП //input n_clr; input s_adc_clk; input s_adc_frame; input s_adc_data; //output s_adc_seal; output [WIDTH_ADC_DATA-1:0]adc_data; output en_adc_data; altlvds_ser altlvds_ser ( .rx_in(s_adc_data), .rx_inclock(s_adc_frame), .rx_out(adc_data), .rx_outclock(en_adc_data)); endmodule Соответствующий SDC файл: set_time_format -unit ns -decimal_places 3 create_clock -name {clk_65MHz} -period 65MHz [get_ports {s_adc_frame}] create_clock -name {clk} -period 390MHz derive_pll_clocks -create_base_clocks derive_clock_uncertainty set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_data}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_data}] set_input_delay -max -clock {clk} -clock_fall 0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -min -clock {clk} -clock_fall -0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_frame}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_frame}] И вуаля! Ничего хорошего так и не случилось: Неужели Arria II GX c таймингами "4" не может принять LVDS сигнал с частотой 390 МГц??? :smile3046: Где мы неправильно задаём констрейны?
  15. У верблюда два горба, потому что жизнь - борьба! Доброго времени суток! Есть проект: Аппаратно: - отладочная плата Arria II GX Development Kit, кристалл EP2AGX125EF35C4ES; - самопальная платка с AD9272 на борту, тактовая 65 МГц. Quartus II version 11 AD9272 по LVDS отдаёт по последовательному каналу данные (s_adc_data). К данным прилагается: DCO (s_adc_clk) - тактовый сигнал (390 МГц) и FCO (s_adc_frame) - кадровая синхронизация (те же 65 МГц). 1. Проект тестовый, простецкий, один канал (из восьми доступных в АЦП), используется altddio_in, сгенерённый Мегавизардом (ddr_rx_in в коде). //altera message_off 10040 module adc_deserializer(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter WIDTH_ADC_DATA = 12;//ширина шины данных АЦП input s_adc_clk; input s_adc_frame; input s_adc_data; output [WIDTH_ADC_DATA-1:0]adc_data; output en_adc_data; reg [WIDTH_ADC_DATA/2-1:0]pos_shift_reg, odd_data; reg [WIDTH_ADC_DATA/2-1:0]neg_shift_reg, evn_data; reg en_adc_frame, en_odd_data, en_evn_data; wire en_adc_data, in_rx_p, in_rx_n; wire [WIDTH_ADC_DATA-1:0]adc_data; assign en_adc_data = en_evn_data; ddr_rx_in ddr_rx_in( .datain(s_adc_data), .inclock(s_adc_clk), .dataout_h(in_rx_p), .dataout_l(in_rx_n)); genvar i; generate for(i=0; i<WIDTH_ADC_DATA/2; i=i+1) begin: assign_adc_data assign adc_data[2*i+1:2*i] = {odd_data[i], evn_data[i]}; end endgenerate always @(posedge s_adc_clk) begin pos_shift_reg <= {pos_shift_reg, in_rx_p}; neg_shift_reg <= {neg_shift_reg, in_rx_n}; en_adc_frame <= s_adc_frame; en_odd_data <= en_adc_frame; en_evn_data <= en_odd_data; if(en_adc_frame && !en_odd_data) odd_data <= pos_shift_reg; if(en_odd_data && !en_evn_data) evn_data <= neg_shift_reg; end//always endmodule Ноги АЦП расставлены самостоятельно, s_adc_sclk заведены на dedicated clock, DIFFCLK, как положено. Выходные отданы на откуп Quartus'у. SDC файл для такого случая "классический", как в "Constraining and Analyzing Source-Synchronous Interfaces", Example 56. Собственно вот он, SDC файл: set_time_format -unit ns -decimal_places 3 create_clock -name {clk_480MHz} -period 390MHz -waveform {0.641 1.923} [get_ports {s_adc_clk}] create_clock -name {clk} -period 390MHz derive_clock_uncertainty set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_data}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_data}] set_input_delay -max -clock {clk} -clock_fall 0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -min -clock {clk} -clock_fall -0.300 [get_ports {s_adc_data}] -add_delay set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_frame}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_frame}] В результате TQ заявляет, что шоколада по холду не будет: 2. Размножаем один канал так, чтобы работали все 8: module adc_deserializers(s_adc_clk, s_adc_frame, s_adc_data, adc_data, en_adc_data); parameter NUM_CHANNEL = 8;//Количество каналов parameter WIDTH_ADC_DATA = 12;//Ширина шины данных АЦП input s_adc_clk; input s_adc_frame; input [NUM_CHANNEL-1:0]s_adc_data; output [WIDTH_ADC_DATA*NUM_CHANNEL-1:0]adc_data; output [NUM_CHANNEL-1:0]en_adc_data; adc_deserializer #( .WIDTH_ADC_DATA(WIDTH_ADC_DATA)) adc_deserializer[NUM_CHANNEL-1:0]( .s_adc_clk(s_adc_clk), .s_adc_frame(s_adc_frame), .s_adc_data(s_adc_data), .adc_data(adc_data), .en_adc_data(en_adc_data)); endmodule Правим SDC, с учётом размножения (показаны изменившие строки) set_input_delay -max -clock {clk} 0.300 [get_ports {s_adc_data[*]}] set_input_delay -min -clock {clk} -0.300 [get_ports {s_adc_data[*]}] set_input_delay -max -clock {clk} -clock_fall 0.300 [get_ports {s_adc_data[*]}] -add_delay set_input_delay -min -clock {clk} -clock_fall -0.300 [get_ports {s_adc_data[*]}] -add_delay Понятное дело, лучше не стало, только теперь еще повылазили слаки для выхода ddio, который захлопывается передним фронтом :( Понятное дело, что если задрать тактовую АЦП до 80 (а нам так и надо) выползают слаки и по сетапу для того же выхода ddio. В реальном проекте, в железе, сигнал действительно рассыпается причудливым образом :( Уважаемые гуру, расскажите, что мы делаем не так и куда, собственно, копать-то? Есть еще идея поиспользовать altlvds в его синтезируемом виде, но уверенности в результате нет. Однако пробовать будем - о результатах отпишусь.
×
×
  • Создать...