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

    

Dantist2k17

Участник
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник

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

345 просмотров профиля
  1. Спасибо за проделанную работу, на "кошках" как и вы проделал, все верно отрабатывает. Буду искать где собака порылась.
  2. Будет, но это никак не относится к синтезу в DC без clock tree.
  3. Я работаю в DC 2014.09. От частоты зависимости не наблюдаю, также как и от наличия multicycle_path (схема выглядит примерно одинаково). multicycle_path применился, расчет timing по пути, осуществляется на 4 периодах. Сейчас проделал тоже самое в DC 2010.12 все аналогично, чудес не бывает, видимо что-то делаю не так. Спасибо.
  4. Спасибо, такой подход имеет право на жизнь, однако подобными костылями не хочется пользоваться. Если не смогу разобраться то просто вынесу формирование функции в отдельный модуль при поведенческом описании. На синтез запускаю командой compile_ultra -no_autoungroup -no_boundary_optimization.
  5. multicycle_path по hold_time не указывал, речь идет про логический синтез без clock tree, анализа и оптимизации по времени удержания не происходит
  6. В данном случае без него никак. Если убрать multicycle то логическая схема получается абсолютно такой же как и при его наличии. Я могу заблуждаться, но не могу согласиться с какой-либо оптимизацией по hold time, так как на данном этапе синтеза нет никакого clock tree, идет оценка только по setup time. Логики по входу мало, но она не способна отработать на требуемой частоте за один период, задача из разряда "впихнуть невпихуемое". За недостаток спасибо, на этапе физ синтеза необходимо будет задавать ограничения и на hold. Как я понимаю, задача multicycle указать синтезатору места, в которых у логики есть больше одного такта на обработку, дабы он не занимался оптимизацией там, где это не столь критично (с учетом увеличенных запасов по времени, которые определяются схемотехникой/verilog описанием).
  7. Мне не нравится как он разложил, функционально все верно. Просто в данном случае я очень сильно зажат по быстродействию, и на путь от data_a до data есть multicycle_path которого хватает чтобы получить положительный slack, а по пути от flag до data всего один период, которого к сожалению не хватает при такой результирующей схеме, однако вполне будет хватать если схема будет в таком виде, как я ожидаю увидеть. Я разрабатываю под ASIC, синтез через DC. Добавить в код соответствующие примитивы конечно можно, но хотелось бы поизящней что ли. По-поводу (* keep =1 *) wire flag_f = flag[3] & function; не понимаю что вы подразумеваете под (* keep =1 *), добавлять в код промежуточный wire не пробовал. Спасибо за совет.
  8. Приветствую. Имеется verilog, в общих чертах выглядит следующим образом. Исходный код выкладывать не стал дабы не нагружать восприятие. reg [31:0] data_a; reg [31:0] data_b; reg [3:0] flag; //счетчие в коде 1 из N always@(posedge clk or negedge rst) begin if(!rst) flag <= 4'd1; else flag <= flag << 1 | flag[3]; end //данные обновляются раз в 4 такта, т.е. на функцию по факту отводится 4 периода тактовой частоты //о чем я сообщаю синтезатору посредством //set_multicycle_path 4 -end -setup -from {data_a[*]} -to {data[*]} //set_multicycle_path 4 -end -setup -from {data_b[*]} -to {data[*]} assign function = комбинационная функция от(data_a, data_b); always@(posedge clk or negedge rst) begin if(!rst) data <= 1'b0; else data <= data | flag[3] & function; end В результате синтеза получаем следующий путь. flag_reg_0_/C (FDP) flag_reg_0_/Q (FDP) U212/O (NOR3B3) U213/O (O21AI1) U214/O (AND2B2) U5/O (NAN3B1) U215/O (AND2B2) U216/O (OR2) data/D (FDC) Однако по пути от flag до data я планировал увидеть что-то вроде этого. flag_reg_0_/C (FDP) flag_reg_0_/Q (FDP) U212/O (AND2) U213/O (OR2) data/D (FDC) Как я понимаю синтезатор просто замешивает flag_reg в логику формирования функции в процессе оптимизации, вот только с какой целью, делал синтез на разных частотах, результат не меняется, наличие/отсутствие multicycle_path в sdc тоже влияния не оказывает. В данном случае принципиально, чтобы по данному пути было минимальное количество элементов. Пробовал записывать function предварительно в триггер, при этом изменив multicycle_path с 4 на 3, это исправило ситуацию, однако зачем ставить дополнительный триггер, если можно обойтись без него (теоретически). Но на практике это сделать не получается, что посоветуете?
  9. Да спасибо, дошел до этого, опробовал. Не понравилось. Поправил verilog описание и уложился в частоту. Однако ведь можно столкнуться с задачей, когда необходимо разложить по триггерам БОЛЬШОЙ дешифратор, который описан с помощью case. Переписать его как-то алгоритмически не представляется возможным. Как быть в такой ситуации, не сталкивались?
  10. Имеется два вопроса по логическому синтезу. 1. В версии DC E-2010.12 поддерживается команда pipeline_design, которая позволяет "взять" комбинационную схему и "положить" ее на цепочку регистров, обеспечив необходимую частоту работы. В версии DC J-2014.09 такой команды я не обнаружил. Есть ли какая-либо альтернатива? 2. Существует ли команда (подход), которая позволяет сделать нечто подобное из последовательностной схемы? Что есть: триггер 1 - логика - триггер 2. Хочу получить триггер 1 - логика - триггер 3* - логика - триггер 2.
  11. Чего же мне стесняться? Поясните.
  12. Спасибо Вам конечно за отзывчивость. Тем не менее, осадок от общения так себе. Вопрос разрешен.
  13. Да, с этим я разобрался, в блоке always (в первом сообщении) он и описан. Ну да, вполне возможно, при этом возникает вопрос, что передает передатчик в течении 9 тактов (один такт из 10-ти займет бит из PRBS)? А способ разделить 127 бит на n-ое количество слов по 10 бит не представляется возможным. Еще конечно можно передавать по одному биту 10 раз подряд, но какой в этом смысл. Передать можно все что угодно и как угодно, хочется прояснить как правильно и почему именно так. Разобраться не помешает, теоретическая основа в подобных темах весьма туманна.
  14. Все дело в том, что я как раз и занимаюсь аппаратной реализацией TLK2711-SP в составе ASIC. Что вы подразумеваете под сердез, сериализатор? Если да, то согласен, тоже самое обозначено в datashhet файле на TLK2711-SP (страница 13). Однако там прорисована 10-ти битная параллельная шина, которая затем через мультиплексор идет на сериализатор. В том же самом фале в разделе 8.3.5 прописано, что TLP2711-SP имеет 127 встроенных PRBS функций. При этом известно, что аппаратная генерация полинома 1+x^6+x^7 осуществляется на основе 7-ми битного регистра, который генерирует последовательность из 127 чисел (разрядностью 7 каждое). Отсюда и возникли вопросы что из себя представляет PRBS, в процессе просмотра datasheet файлов сформировалось две версии: последовательность из 127 бит или же из 127 7-ми битных чисел. Однако обе они не ложатся на описание TLP2711-SP. Вопрос и заключается, почему считается достаточной? Но это уже факультативный интерес.
  15. Добрый день. Если я правильно понял, то PRBS формируется на основании полинома 1+x^6+x^7, 127 значений. Сам полином генерируется 7-ми битным регистром. Вопрос №1: как правильно применить полученный регистр для тестирования приемопередатчика (при кодирование данных в коде 8b/10b)? Прикрепляю код генератора, в котором представлено два способа формирования выходных данных PRBS, есть ли среди них правильный, какова идеология? module prbs_generator( output [9:0] data_out, input txclk, input prbsen, input rst_n); reg [6:0] register; //Способ №1 -- дополняем до 8 бит а затем пропускаем через кодер 8b/10b, //среди просмотренных функциональных схем приемопередатчиков, кодер на выходе блока генерации PRBS не встерчал coder_8b10b coder ( .data_in({(register[6]^register[5]),register}), .data_out(data_out)); //Способ №2 -- готовый код для передачи assign data_out = {3'd0,register}; //1+x^6+x^7 always@(posedge txclk) begin if(!rst_n) register <= 7'd1; else if(!prbsen) register <= 7'd1; else register <= {register[5:0],(register[6]^register[5])}; end endmodule Вопрос №3: почему для тестирования данного кодирования используется именно такой полином?