Jump to content

    

pavlovconst

Свой
  • Posts

    104
  • Joined

  • Last visited

Posts posted by pavlovconst


  1. 10 hours ago, NStorm said:

    Так ведь есть 1000Base-KX как раз для плат.

    См. 

    802.3ap 2007 1 и 10 Гбит/с (125 и 1250 Мбайт/с) по печатной кросс-плате

    Этот стандарт поддержан в 10GBASE-KR PHY IP Core. Только Stratix V и Arria V

    10 hours ago, Doka said:

    полностью поддерживаю!

    в идеале на кросс-плате д.б. только разъёмы

    ок, понятно

    8 hours ago, _pv said:

    тогда с обратной стороны для питания - да хоть КАМАК :)

    заказчик не поймет :)

    6 hours ago, Zig said:

    развязка просто конденсаторами допустима, если обе физики имеют тип выхода voltage-mode-based

    Спасибо за документ. На каком PHY остановились, если не секрет?

  2. 14 minutes ago, Lmx2315 said:

    И побыстрее интерфейсы используются

    Ну, если брать 10G, то там в рамках стендарта проработан вопрос об использовании в бекплейнах, я про 10GBASE-KR. А вариант с 1G лично мне кажется "колхозным". Может, я не прав.

  3. Здравствуйте!

    Мы проектируем некое модульное устройство - бекплейн, системный модуль и сменные сигнальные модули. На всех модулях будут ПЛИС Cyclone V или MAX 10. 

    Возникло предложение использовать для передачи информации Ethernet - 100Mbps или 1G. MAC уровень в ПЛИС, аппаратные PHY и аппаратный свич в составе бекплейна.

    Оцените, пожалуйста бредовость (или нет) этой идеи. В плюсах я вижу то, что на каждом сигнальном модуле блок Ethernet будет стандартным, сам интерфейс также не нуждается в документировании, минус - за микросхемы PHY нужно платить.

     

    Можно попытался обойтись без PHY - то есть, выводить на бекплейн сигналы RGMII, а свич делать в ПЛИС. Но даже в лучшем случае с каждого модула тогда придется тянуть по 12 линий. Это много.

    Вариант использования SGMII - видимо, не подходит, так как не поддержан в наших ПЛИС и требует дорогих материалов для печатных плат.

     

    Вообще, допустимо ли это - гнать по бекплейну сигналы с выхода PHY? В стандарте подразумевается витая пара. Достаточно ли соблюсти волновое сопротивление, или есть еще требования?

  4. Вот таблицы совместимости серий ПЛИС и версий Quartus - https://fpgasoftware.intel.com/devices/

    Очевидно, что если в Среде Quartus Pro (любой версии) нельзя скомпилировать, скажем, MAx10, то и с сигналтапом работать будет нельзя

  5. @OLD_SHURiK Не понятно... Пожалуйста, пишите подробнее, тогда будет о чем говорить.

    Исходя из схемы я ДОГАДЫВАЮСЬ, что вы хотите пробросить сигналы через MAX, не защелкивая их в ПЛИС. Если да, то зачем вам констрейны? Задержки распространения от этого не уменьшатся, не увеличатся. Если, конечно, МАХ не забит под завязку другой логикой, не показанной на схеме. Будьте готовы снижать частоту SPI, чтобы учесть задержки распространения сигналов.

  6. Если Ква последней версии, то, возможно, не все ошибки уже описаны в интернете. У меня, например, на 19-ом Квартусе не работает мастер DDR3. Есть хотфикс, но я плюнул, пока остаюсь на старой проверенной версии, тем более, что никаких существенных улучшений нет

    То описание, что вы нашли относилось к "Quartus® II software version 14.1 and earlier" :biggrin:

  7. Если я правильно понимаю, отключение внешних модулей - это перекомпиляция? Тогда фиттер может просто сократить за ненадобностью всю логику закриптованного модуля, результаты работы которой нигде не используется.

  8. @syoma Здравствуйте, очень вкусные слова вы пишете =)

    Сделать-то можно, только цель какая? Какую проблему решит 10G по сравнению с существующим дизайном? Может, готовых решений нет потому, что они никому не нужны?

    Я высоко ценю высокотехнологичные, современные решения, но внедрять их без четкого понимания "ЗАЧЕМ?" - не стал бы, при всем уважении...

  9. 16 hours ago, Nick_K said:

    Если конструкция засинтезировалась в кристалле, то какая разница, будете дёргать каждый такт/асинхронно или один раз получите параметры и забудете? Ресурсы то съедены уже.

    Поддерживаю.

    "Отключение" always-блоков, в принципе, сделать можно. С помощью https://ru.wikipedia.org/wiki/Clock_gating Такой прием используется для оптимизации энергопотребления.

  10. Kostochkin, У меня куплена именно такая плата, как в верхнем посте. Неработающих или сбоящих элементов не нашел. 10G через оптику поднимал. Схему и example projects по запросу выслали до покупки.

  11. Здравствуйте, необычный у вас вопрос. Скажите, а вас действительно интересует PALы из 80-x с какой-то практической целью, или вы их выбрали, так сказать, для "начала пути"?

     

    Дело в том, что технологии, которые использовались тогда в программируемой логике были предельно простыми, высокоуровневые примитивы и IP ядра не использовались. Логики в устройстве было крайне мало, поэтому программа состояла, в общем-то, из горстки ANDов и ORов и писалась от руки. Я к тому, что если у вас нет конкретной задачи под конкретный чип из прошлого, пропустите этот этап вообще, полезного опыта он вам не принесет. В наши дни хорошим началом будет что-то на чипе EPM240T100.

     

    Для функционального моделирования VHDL кода отлично подойдет Modelsim. Вы увидите как воздействия на входных портах преобразуются вашей схемой и выдаются на выход. Но привязки к конкретному корпусу и модели чипа там не будет. После моделирования можно будет экспортировать временную диаграмму с выходов схемы в текстовый файл, и его уже скормить какой-то другой программе. Возможно, вам такой способ подойдет...:pardon:

  12. 17 minutes ago, zombi said:

    чего не усложнять? :wacko2:

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

    Самый худший случай, с самыми высокими требованиями к полосе памяти - это когда размер прямоугольников будет равен размеру экранного буфера.

    Такой случай может и маловероятен, но, наверняка, возможен. И память должна такую полосу обеспечивать.

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

    Возможно, при вычитке только части экранного буфера - вы сэкономите "несколько" тактов.Но этот выигрыш будет различным от кадра к кадру. Алгоритм усложнится, количество ресрсов ПЛИС , занятых под задачу, увеличится.

    А преимущества чтения буфера по частям какие? Я не понимаю. Поэтому и предложил не усложнять =)

  13. 5 hours ago, zombi said:

    Пишу прямоугольниками с произвольными XY

    В худшем случае все равно нужно уметь раз за разом вычитывать буфер целиком. Так зачем усложнять алгоритм попытками читать частями?

  14. 49 minutes ago, des00 said:

    ну лень ему писать красиво

    des00, Спасибо за "красивый" вариант, но в целевом проекте все несколько сложнее устроено. Поэтому я и пытаюсь дожать вариант с блокирующими.

    1 hour ago, iosifk said:

    если даже Вы заставите программные инструменты сделать "как надо" сегодня, то через полгода-год появится новая версия софта и возможно проблемы выплывет снова

    Порядок обработки событий планировщиком симулятора, описанный в стандарте, поменяется наврядли =)

  15. 8 hours ago, dxp said:

    почитайте про планировщик виртуальной машины симулятора (по ссылкам выше про это тоже есть), например, тут

    Почитал, и мне даже удалось заставить симулятор сделать задержку в два такта.

    Но такой код, с перемешанными блокирующими и неблокирующими присваиваниями, оставлять в проекте мне было бы стыдно. =(

    module main(
    
      input clk,
      input nrst,
      input [7:0] in_data,
      output [7:0] out_data
    );
    
    reg [3:0] brd_err2 = 0;
    reg [7:0] brd_err2_cntr = 0;
    
    always @(posedge clk) begin
      if( ~nrst ) begin
        brd_err2_cntr[7:0] <= 0;
        brd_err2[3:0] = 0;
      end else begin
        brd_err2_cntr[7:0] <= brd_err2_cntr[7:0] + brd_err2[3] +
                                                   brd_err2[2] +
                                                   brd_err2[1] +
                                                   brd_err2[0];
        brd_err2[3] = in_data[3] || in_data[2] || in_data[1] || in_data[0];
        brd_err2[2] = in_data[4] || in_data[2] || in_data[1] || in_data[0];
        brd_err2[1] = in_data[5] || in_data[2] || in_data[1] || in_data[0];
        brd_err2[0] = in_data[3] || in_data[1];
      end
    end
    
    assign out_data[7:0] = brd_err2_cntr[7:0];
    
    endmodule

     

    2019-09-30 12 34 25.png

  16. 3 hours ago, dxp said:

    Синтез имеет другую исполнительную модель - "тру параллел", там гонок в этом смысле нет.

    Пока что получается, что синтезатор имплементирует код именно так, как задумал разработчик. А симуляторы, для того, чтобы воспроизвести тот же результат, что и в реальности - требуют переписать код и соблюсти много дополнительных условий. Видите ли, у них там "сложная временная модель"... =)

  17. 6 hours ago, lexx said:

    синтезатор предполагает это и адаптирует ваш код

    По каким правилам он "адаптирует"? :shok: И как разработчик должен быть уверен, что при очередной перекомпиляции эта адаптация не приведет к другому результату?

    6 hours ago, lexx said:

    Кстати SystemVerilog и использование always_ff (и так далее) как раз запретят такое применение, с этой точки зрения он более строг, чем чистый Verilog.

    Не заметил. Изначально этот код был написан на SV

  18. one_eight_seven, RobFPGA, Nick_K  Я понимаю, что основной совет - это сделать все присваивания неблокирующими. Всегда тоже так делал. Но вот сейчас столкнулся с ситуацией, когда мне действительно удобнее использовать блокирующее.

    В стандарте есть блокирующие присваивания, так почему я, как разработчик, должен ограничиваться и не использовать максимум выразительных средств языка?

     

    Больше всего я не понимаю, как могут симуляторы и синтезаторы давать различные результаты, если и те, и другие - опираются на один стандарт? Кто виноват в расхождении? Стандарт плохой? Или его имплементации?

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

    А если результаты не совпадают, то зачем вообще заниматься симуляцией?