Jump to content

    

Dantist2k17

Участник
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Dantist2k17

  • Rank
    Участник

Recent Profile Visitors

377 profile views
  1. В моем случае была "свой атмосфера" схема описывалась на verilog, при этом разводилась руками. Была необходимость не плодить модули, а всегда обращаться к одному. О том, что нет информации по окружению пока не сделан полный синтез, я тогда по правде сказать и не задумывался.
  2. Насчет Genus не скажу, в DC делал следующим образом: #register_write current_design register_data characterize reg_dev_low current_design register_write compile_ultra -no_autoungroup #register_data current_design $top_level current_design mem characterize gen_reg[0].register_data current_design register_data set_dont_touch {reg_dev_low reg_dev_most} compile_ultra -no_autoungroup #MEM current_design mem set_dont_touch {gen_reg[*].register_data} compile_ultra -no_autoungroup #fdt current_design $top_level characterize gen_fdt[0].fdt current_design fdt compile_ultra -no_autoungroup #register_synch_negedge current_design $top_level current_design spi characterize synch_ncs current_design register_synch_negedge compile_ultra -no_autoungroup current_design $top_level set_dont_touch {spi/synch_ncs spi/synch_sclk gen_fdt[*].fdt mem} compile_ultra -no_autoungroup Т.е. изначально характеризуем модуль ссылаясь на любой instance, затем делаем этот модуль текущим дизайном и компилируем. А перед синтезом верхнего уровня ставим dont touch. В принципе это тоже самое что посоветовал Alex. Я делал это процессе, не напрягало. Однако, encounter вероятней всего выдаст сообщение о том что netlist не уникален.
  3. Спасибо за проделанную работу, на "кошках" как и вы проделал, все верно отрабатывает. Буду искать где собака порылась.
  4. Будет, но это никак не относится к синтезу в DC без clock tree.
  5. Я работаю в DC 2014.09. От частоты зависимости не наблюдаю, также как и от наличия multicycle_path (схема выглядит примерно одинаково). multicycle_path применился, расчет timing по пути, осуществляется на 4 периодах. Сейчас проделал тоже самое в DC 2010.12 все аналогично, чудес не бывает, видимо что-то делаю не так. Спасибо.
  6. Спасибо, такой подход имеет право на жизнь, однако подобными костылями не хочется пользоваться. Если не смогу разобраться то просто вынесу формирование функции в отдельный модуль при поведенческом описании. На синтез запускаю командой compile_ultra -no_autoungroup -no_boundary_optimization.
  7. multicycle_path по hold_time не указывал, речь идет про логический синтез без clock tree, анализа и оптимизации по времени удержания не происходит
  8. В данном случае без него никак. Если убрать multicycle то логическая схема получается абсолютно такой же как и при его наличии. Я могу заблуждаться, но не могу согласиться с какой-либо оптимизацией по hold time, так как на данном этапе синтеза нет никакого clock tree, идет оценка только по setup time. Логики по входу мало, но она не способна отработать на требуемой частоте за один период, задача из разряда "впихнуть невпихуемое". За недостаток спасибо, на этапе физ синтеза необходимо будет задавать ограничения и на hold. Как я понимаю, задача multicycle указать синтезатору места, в которых у логики есть больше одного такта на обработку, дабы он не занимался оптимизацией там, где это не столь критично (с учетом увеличенных запасов по времени, которые определяются схемотехникой/verilog описанием).
  9. Мне не нравится как он разложил, функционально все верно. Просто в данном случае я очень сильно зажат по быстродействию, и на путь от data_a до data есть multicycle_path которого хватает чтобы получить положительный slack, а по пути от flag до data всего один период, которого к сожалению не хватает при такой результирующей схеме, однако вполне будет хватать если схема будет в таком виде, как я ожидаю увидеть. Я разрабатываю под ASIC, синтез через DC. Добавить в код соответствующие примитивы конечно можно, но хотелось бы поизящней что ли. По-поводу (* keep =1 *) wire flag_f = flag[3] & function; не понимаю что вы подразумеваете под (* keep =1 *), добавлять в код промежуточный wire не пробовал. Спасибо за совет.
  10. Приветствую. Имеется 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, это исправило ситуацию, однако зачем ставить дополнительный триггер, если можно обойтись без него (теоретически). Но на практике это сделать не получается, что посоветуете?
  11. Да спасибо, дошел до этого, опробовал. Не понравилось. Поправил verilog описание и уложился в частоту. Однако ведь можно столкнуться с задачей, когда необходимо разложить по триггерам БОЛЬШОЙ дешифратор, который описан с помощью case. Переписать его как-то алгоритмически не представляется возможным. Как быть в такой ситуации, не сталкивались?
  12. Имеется два вопроса по логическому синтезу. 1. В версии DC E-2010.12 поддерживается команда pipeline_design, которая позволяет "взять" комбинационную схему и "положить" ее на цепочку регистров, обеспечив необходимую частоту работы. В версии DC J-2014.09 такой команды я не обнаружил. Есть ли какая-либо альтернатива? 2. Существует ли команда (подход), которая позволяет сделать нечто подобное из последовательностной схемы? Что есть: триггер 1 - логика - триггер 2. Хочу получить триггер 1 - логика - триггер 3* - логика - триггер 2.
  13. Чего же мне стесняться? Поясните.
  14. Спасибо Вам конечно за отзывчивость. Тем не менее, осадок от общения так себе. Вопрос разрешен.
  15. Да, с этим я разобрался, в блоке always (в первом сообщении) он и описан. Ну да, вполне возможно, при этом возникает вопрос, что передает передатчик в течении 9 тактов (один такт из 10-ти займет бит из PRBS)? А способ разделить 127 бит на n-ое количество слов по 10 бит не представляется возможным. Еще конечно можно передавать по одному биту 10 раз подряд, но какой в этом смысл. Передать можно все что угодно и как угодно, хочется прояснить как правильно и почему именно так. Разобраться не помешает, теоретическая основа в подобных темах весьма туманна.