[Shivers 0]

совершенно не верно

 

RTL описаная на языке никак не синтезируется - можете описать RTL на SystemC и скомпилировать С++ - что, С++ знает что-то про вентили и триггеры :)

 

то есть HDL это обычный (но параллельного исполнения) язык, который компилируется в инструкции процессора так же как и любой процедурный (типа С)

 

Инструкции процессора и пресинтез - в моем понимании одно и то же, применительно к симуляторам. Но отличие от простого компилятора Си есть однозначно, не даром подключение С++ библиотек делается через дополнительные модули навроде PLI. Кроме того, если посмотрите внимательно, каждый симулятор сначала делает elaborate во внутреннюю библиотеку, и лишь оттуда производит моделирование. Если вам угодно, можете считать это обьектами, а я предпочитаю думать что это техн. либа )

 

если дизайн синтезирован в некую GTECH библиотеку (а покажите мне FPGA-шный струмент, который умеет выдавать GTECH подобные RTL-и)

то и берутся ячейки этой GTECH-ной библиотеки, описанные на HDL

Верилог после квартуса представляет собой нетлист на базе библиотеки мегафункций. Чем вам не GTECH либа? Мегафункции могут быть как поведенческими, так и синтезируемыми (к примеру, encrypted).

 

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

но при этом задержки в нем равны 0

смысла в такой симуляции мало, но идет она значительно быстрее

есть так называемая задержка delta или delta cycle (которая не имеет никакого отношения к timescale), с которой происходят 0 задержки - то есть события происходят последовательно, но время не увеличивается - см. описание дельта цикла в той же википедии - в SV он вообще в стандарте описан, в Verilog|VHDL есть "неявное" понимание

Дельта цикл я и имел ввиду, хотя мало что знаю как он учитывается/ рассчитывается при моделировании. Но на вейвформе он выглядит как очень маленькая задержка на входах/выходах элемента; я считал ее равной 1 timescale, возможно что ошибался. Надо запустить моделирование и проверить. Но что точно - эта дельта не равна нулю в моделировании, много раз видел эту задержку на вейвформе.

 

...

смысл в цитируемой книжке в том, что навороты SV позволяют работать с другой абстракцией, не RTL, а уровнем транзакций TLM

предполагается, что TLM оно для гораздо более сложных узлов, чем RTL (ну например на TLM можно описать всю систему с какими-нибудь USB/Ethernet-ами, а RTL например, какой-нибудь арбитр шины)

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

поэтому применять эти UVM-ы к gate level-у просто бессмысленно, но можно

 

спасибо за внимание :)

И все же, в цитате явно сказано следующее: STA не осуществляется временным моделированием. TLM здесь не причем.

 

имхо

[yes 7]

STA первая буква S означает статический, то есть ни о каком временном моделировании вообще говорить нельзя

 

еще понимание перевода :) можно дополнить: в аннотированных нетлистах может, например, проверяться работа с внешней памятью, где описаны задержки в модели этой памяти, то есть что внешняя шина на реальном устройстве успевает (хотя STA и констрейны с этой задачей справляются тоже)

 

а квартус помоему умеет только post-map и post-route нетлисты выдавать, технологической библиотеки нет (только для рисования RTL)

 

----------------

 

а со временем симуляции - почитайте, поэкспериментируйте, в верилоге например есть такая конструкция #0, что она означала бы если бы "время всегда шло"

у ncsim-а сделано более наглядно - там можно смотреть временную шкалу, но если хочется - то можно и событийную, которая в "мгновенная", а на временной желтыми точками помечается

 

[topor_topor 0]

Как моделируется нетлист? Точно также, только библиотека подключается внешняя (к примеру, альтеровская). Задержки на каждом вентиле также будут равны 1 timescale. Но! для нет листа есть еще sdf файл, подгрузив который, мы получаем не синтетические задержки (1 timescale), а реальные, экстрагированные из флорплана (quartus).

Таким образом, разницы нет - что использовать RTL, что нетлист с sdf, моделирование работает одинаково, а значит и тестбенчу должно быть без разницы.

Позволю себе немного Вас поправить....

Задержки на каждом вентиле будут равны НЕ 1 timescale, а той величине которая описана в Verilog модели гейта..

 

1) Если в этой модели нет таймингов, а просто написано напр. asign Q=A&B - то вы правы, будет 1 дельта задержка, как и в обычном RTL описании.

 

2) Если эта модель гейта более умная (что обычно и есть) то там указаны реальные задержки напр. #5; asign Q=A&B - что значит задержку Q на 5 timescale;

 

3) Verilog имеет весьма продвинутые конструкции для задания всяких задержек в модели гейта\модуля.

Вот напр. можна так в верилоге задать сетап тайм:

$setup  (posedge A[0],  posedge RD, READ_SETUP_TIME,    NOTIFY );

 

4) Чтобы сработал SDF, модель гейта должна быть правильной!

вот напр. правильная AND модель:

   
module AND2 (A, B, Q);

   input     A, B;
   output    Q;

// Function Q: (A*B)
   and       i0  (Q, A, B);

// timing section:
   specify

      (A +=> Q) = (0.02, 0.02);
      (B +=> Q) = (0.02, 0.02);

   endspecify
endmodule

 

5) Если не грузить SDF то задержки будут такие как указаны в моделях гейтов.

Если загрузить SDF, то задержки из него "перепишут" задержки из модели гейта п.4) и плюс появятся задержки в цепях межсоединений.

Если модели гейтов описаны в стиле 1-3) то задержки в гейтах (A to Q напр.) не перепишутся, а только появятся задержки в цепях.

 

 

 

-------------

STA - Static Timing Analysis

Статический Временной Анализ - фактически, проверка того что требования по setup\hold таймингам выполняются на каждом флопе.

 

Проверяются ли setup\hold таймы при симуляции нетлиста?

Да, если эти тайминги есть в Verilog модели флопов. И даже независимо от того есть ли SDF или его нет. См. выше.

 

=======================

Задержки в SDO не нулевые

Результат тот же задержек нет

 

1) почему файл имеет росширение SDO а не SDF?

2) Покажите Verilog модель вашего тригера.

3) Где нет задержки - на выходе тригера относительно клока (C to Q) или на межсоединениях гейтов (from GATE1.Q to GATE2.IN)?

 

=====================

Конечно-конечно.. непременно прочту..

 

Но вот у меня простой вопрос:

 

Есть функциональное описание модуля и testbench для его тестирования.

Я пишу sdc для модуля, где, например, описываю multi-cycle paths.

Я хочу проверить работоспособность netlist c sdf.

 

Могу ли я это сделать, если testbench использует UVM?

Смешались в кучу кони, люди.....

1) SDC - надо для STA. Тесбенчи тут непричём.

2) проверить работоспособность netlist c sdf вы можете и с помощью тесбенча писаного в среде UVM.

Только надо UVM тесбенч (впрочем, как и простой Verilog тесбенч) писать так, чтобы он был совместим именно с нетлистом, а не RTL.

Ну там пути к сигналам соответствовали нетлисту, а-то их синтезатор любит переименовывать....

[FatRobot 3]

Ответов много, все они прекрасные, не лишены здравого смысла и богатейшего опыта. Спасибо.

 

Теперь по поводу вот этого:

1) SDC - надо для STA. Тесбенчи тут непричём.

 

Видимо в этой формулировке таится какая-то бездна смысла, которую я пока не способен осознать, т.к. упрямо использую sdc еще на этапе синтеза.

 

Но все же я повторю вопрос, расширив возможности для ответа:

какими способами можно проверить правильность задания неочевидных ограничений (SDC)? как простой пример: multicycle path: как подтвердить предположение о том, что указанный путь действительно multicycle и у него такие параметры?

 

из того, что мне известно: прогнать testbench на netlist'e с задержками (SDF) для углов.

 

Есть еще варианты?

 

 

 

 

[Shivers 0]

2Fat Robot

sdc это констрейн для правильного синтеза схемы, а также для STA. Для временного моделирования эти констрейны не нужны.

Проверкой мультициклов можете считать отсутствие violation при моделировании ) Если они действительно нужны там, где вы их указали. К примеру, если у вас путь триггер-триггер должен проходиться за 1 такт, а вы указали мультицикл 2, то с большой вероятностью после синтеза этот путь будет длиннее периода клока - вывалится violation

[FatRobot 3]

 

Вообще-то мой вопрос был: "есть ли еще варианты?", а не "кто сумеет повторить мной написанное другими словами?"

 

Но все равно спасибо.

 

2Fat Robot

sdc это констрейн для правильного синтеза схемы, а также для STA. Для временного моделирования эти констрейны не нужны.

Проверкой мультициклов можете считать отсутствие violation при моделировании ) Если они действительно нужны там, где вы их указали. К примеру, если у вас путь триггер-триггер должен проходиться за 1 такт, а вы указали мультицикл 2, то с большой вероятностью после синтеза этот путь будет длиннее периода клока - вывалится violation

 

[Shivers 0]

 

Насчет SDO - альтеровский софт делает файл с таким расширением еще со времен MAX. Исторически сложилось;по содержанию это обрезанный SDF.

[seldim 0]

Код делителя следующий

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;


ENTITY div IS        
    
    PORT
        (
            data_in1            : IN    STD_LOGIC_VECTOR (19 downto 0);
            data_in2            : IN    STD_LOGIC_VECTOR (15 downto 0);
            clk                : In     STD_LOGIC;
            data_div_50        : out    STD_LOGIC_VECTOR (19 downto 0)
        );
    END div;

ARCHITECTURE arhitektura OF div IS

signal data1                    : integer range 0 to 1048575;
signal data2                    : integer range 0 to 65535;
signal data_div                : integer range 0 to 1048575;

    BEGIN

    process (clk)
        begin
            if clk' event and clk = '0' then
                data1 <= conv_integer (data_in1(19 downto 0));
                data2 <= conv_integer (data_in2(15 downto 0));
            end if;
        end process;

Data_div_50 <= CONV_STD_LOGIC_VECTOR(data_div, 20);
    END arhitektura;

 

Код теста :

USE cycloneive.cycloneive_components.all ; 
USE ieee.std_logic_1164.all ; 
USE ieee.std_logic_textio.all ; 
USE ieee.std_logic_unsigned.all ; 
USE std.textio.all ; 
ENTITY proba_div_tb  IS 
END; 

ARCHITECTURE proba_div_tb_arch OF proba_div_tb IS
  SIGNAL \Out\   :  std_logic_vector (19 downto 0) ; 
  SIGNAL d2   :  std_logic_vector (15 downto 0)  := X"0000"; 
  SIGNAL CLK   :  STD_LOGIC  :='0'; 
  SIGNAL \in\   :  std_logic_vector (19 downto 0) := X"00000"; 
  COMPONENT divider  
    PORT ( 
      \Out\  : out std_logic_vector (19 downto 0); 
      d2  : in std_logic_vector (15 downto 0); 
      CLK  : in STD_LOGIC; 
      \in\  : in std_logic_vector (19 downto 0) ); 
  END COMPONENT; 
BEGIN
  DUT  : divider  
    PORT MAP ( 
      \Out\   => \Out\  ,
      d2   => d2  ,
      CLK   => CLK  ,
      \in\   => \in\   ); 



clk <= not clk after 500 ns;
d2 <= X"0248" after 1200 ns;
\in\ <= X"5aaaa" after 1200 ns;

END;

Автоматически делитель реализован скорей всего на огромной комбинационной логике и задердки должны быть несколько наносекунд. Но задержки упорно не подключаются.

[topor_topor 0]

Видимо в этой формулировке таится какая-то бездна смысла, которую я пока не способен осознать, т.к. упрямо использую sdc еще на этапе синтеза.

 

из того, что мне известно: прогнать testbench на netlist'e с задержками (SDF) для углов.

 

Есть еще варианты?

 

1) а где-же есчё использовать SDC как не на этапах SP&R (синтез плейс роут)?

Но функционально, увы при помощи SDC ничего не верифицировать, вот поэтому и непричём тесбенчи.

Вы кстати верифицируете ваш RTL до синтеза?

2) Ваш вариант правильный. Вот только не надо путать функциональную верификацию логики и проверку правильности SDC.

3) Есчё варианты есть... В смысле верификации SDC. Кое чё может Cadence Conformal.

он напр. проверяет SDC констрейны разных модулей на непротиворечивость.

 

[xvr 12]

Что то в вашем 'делителе' отсутствует собственно деление. А data_div вообще никуда не подключен. У вас точно код такой?

 

[topor_topor 0]

Автоматически делитель реализован скорей всего на огромной комбинационной логике и задердки должны быть несколько наносекунд. Но задержки упорно не подключаются.

Повторю вопрос:

1) Покажите нетлист.

2) Покажите Verilog модель (библиотеку) тех комбинаторных элементов в которые синтезился ваш делитель.

3) Где нет задержки - между входом-выходом гейтов, в соединениях между гейтами, между входом-выходом модуля?

[seldim 0]

Уберал коменты и зацепил непосредственно деление.

 

data_div <= (Data1 / Data2);

 

Не понимаю где должны быть задержки. Это исходный код. Квартус производит компиляцию и предлагает два вида симуляции RTL и Gate. Я откуда могу знать через сколько вентилей он протаскивает сигналы и какая задежка там будет?

 

Я понял что все задержки описываются в в SDO файле который подключается в Квесте при симуляции в разделе SDF. SDO файл генерит сам Квартус.

 

И что это за Verilog модель где ее взять?

Изменено 15 марта, 2013 пользователем seldim

[topor_topor 0]

Я понял что все задержки описываются в в SDO файле который подключается в Квесте при симуляции в разделе SDF. SDO файл генерит сам Квартус.

И что это за Verilog модель где ее взять?

А что вы симулите-то с SDF? Случайно не VHDL описание приведённое в примере выше? У вас нетлист вообще есть?

[FatRobot 3]

Я не вполне понимаю, откуда у Вас впечатление, что я хочу что-то верифицировать с помощью sdc.

 

Я хочу проверить правильность самого sdc и использовать для этого тотже модный UVM-testbench, что и для функциональной верификации. Возможно с каким-то минимальными доработками и с учетом того, что в качестве DUT в этом случае будет netlist с sdf. Это когда для проверки sdc требуется пройти как минимум синтез. По этому вопросу досужих мнений здесь много (даже модель драйвера и времени симуляции обсудили богато), а вот ответа типа: "я так делал, все нормально, нужно учитывать то-то и то-то" почему-то я в явном виде не встретил. Начинать такую масшатбную суету без уверенности в том, что не придется писать 2 testbench'a (один для RTL, а другой для netlist c sdf) у меня ни задора, ни ресурсов нет. Лучше уж по-старинке.

 

По поводу возможной проверки sdc до синтеза: я посмотрю возможности Conformal. Спасибо.

 

Но функционально, увы при помощи SDC ничего не верифицировать, вот поэтому и непричём тесбенчи.

Вы кстати верифицируете ваш RTL до синтеза?

 

[seldim 0]

Я симулирую то, что Квартус передает в Квестасим совмесно с тестовым файлом VHDL, который формирует клок и входные данные. И что вы понимаете под нет листом? RTL?

 

Нетлист при запуске симулятора через квартус передается в Квесту автоматически если Вы имеете в виду VHO файл и с ним производится симуляция. Нетлист приводить не имеет смысла он огромен. И думаю что он правильный.