Будет ли SC_THREAD в SystemC создавать реальный поток?
Я отладил следующий код в Visual Studio 2008 (64-разрядная версия), установив точку останова в начале do_test1 а также do_test2К моему удивлению, код работает в том же потоке sc_main функция.
Я не отлаживал в среде Linux. Однако, ища исходный код, я нашел "pthread.h" был включен в некоторый исходный код библиотеки SystemC.
Вопрос 1: В Windows будет ли SC_THREAD создать реальную тему? Или это всегда в одной ветке sc_main? Если это так, могу я сказать SC_THREAD создает «фальшивый» поток?
Вопрос 2: в Linux, так как "pthread.h" включен, будет SC_THREAD создать новую тему?
Вопрос 3: В Windows и Linux я пропустил некоторые настройки для включения реального потока?
========================================
Следующий код с этого сайта:
http://www.asic-world.com/systemc/systemc_time4.html#Example_:_sc_event
#include <systemc.h>
SC_MODULE (events) {
sc_in<bool> clock;
sc_event e1;
sc_event e2;
void do_test1() {
while (true) {
// Wait for posedge of clock
wait();
cout << "@" << sc_time_stamp() <<" Starting test"<<endl;
// Wait for posedge of clock
wait();
cout << "@" << sc_time_stamp() <<" Triggering e1"<<endl;
// Trigger event e1
e1.notify(5,SC_NS);
// Wait for posedge of clock
wait();
// Wait for event e2
wait(e2);
cout << "@" << sc_time_stamp() <<" Got Trigger e2"<<endl;
// Wait for posedge of clock
wait();
cout<<"Terminating Simulation"<<endl;
sc_stop(); // sc_stop triggers end of simulation
}
}
void do_test2() {
while (true) {
// Wait for event e2
wait(e1);
cout << "@" << sc_time_stamp() <<" Got Trigger e1"<<endl;
// Wait for 3 posedge of clock
wait(3);
cout << "@" << sc_time_stamp() <<" Triggering e2"<<endl;
// Trigger event e2
e2.notify();
}
}
SC_CTOR(events) {
SC_CTHREAD(do_test1,clock.pos());
SC_CTHREAD(do_test2,clock.pos());
}
};
int sc_main (int argc, char* argv[]) {
sc_clock clock ("my_clock",1,0.5);
events object("events");
object.clock (clock);
sc_start(); // Run the simulation till sc_stop is encountered
return 0;// Terminate simulation
}
Решение
нет & Да. Это зависит от конфигурации вашей библиотеки SystemC.
Вы можете настроить SystemC для использования pthread или собственного потока Windows. Поэтому, когда вы компилируете и запускаете свой проект SystemC, он создает РЕАЛЬНЫЕ потоки. Однако по умолчанию в среде UNIX он не будет использовать pthread по умолчанию, поскольку системные вызовы дороги. И SystemC только запускает потоки один за другим независимо от того, как вы настраиваете SystemC для использования собственных потоков pthread или Window. Поскольку он запускает только один поток за раз, использование потока на пользовательском уровне выполняется быстрее, чем другие, поскольку системные вызовы не используются.
Почему SystemC не запускает все потоки расписания одновременно? Это другой вопрос.
Другие решения
Короткий ответ:
Библиотеки потоков, будь то потоки пользовательского уровня (легче и быстрее для переключения контекста) или потоки уровня ядра, не используются для обеспечения реального параллелизма. Скорее, они используются для реализации сопрограммы семантики SC_THREAD процессы.
Длинный ответ:
SystemC имеет 3 типа процессов (то есть единиц параллелизма), наиболее важными из которых являются только два:
SC_METHODs методы (аналогичныеalwaysзаявления в Verilog), что
выполнить в полном объеме в нулевое время когда вызвано событием. Они не могут
использованиеwaitждать промежутка времени или события.SC_THREADs методы (например,initialзаявления в Verilog), что
выполнить только один раз, но они могут использоватьwaitждать конкретного
события или периоды времени, и могут использовать циклы для эмуляцииalways
заявления (так чтоSC_THREADможет потратить время).
С точки зрения реализации, нет проблем с SC_METHODпотому что они похожи на методы, зарегистрированные в ядре SystemC и вызываемые при запуске. Однако для SC_THREADs, хотя они определены как функции-члены, их поведение не похоже на обычные процедуры. Они называются сопрограммы:
Подпрограммы, которые позволяют несколько точек входа для приостановки и возобновления выполнения в определенных местах.
Ядро SystemC не предоставляет реальный параллелизм для системного уровня или моделей RTL. Это только предлагает симулированный параллелизм через процесс конструкции. Поэтому при написании высокоуровневых моделей вам не нужно использовать примитивы синхронизации (например, блокировки или семафоры) для защиты данных, совместно используемых различными процессами, поскольку в любой момент времени выполняется только один процесс, и он не может быть прерван ядро SystemC (выполнение переключается на следующий процесс, готовый к выполнению, только если текущий выполняющий процесс отказывается от управления. Тем не менее синхронизация может использоваться, но SystemC способствует использованию передача сообщений в каналы для общения между процессами. Это является преимуществом, поскольку снижает сложность. Однако есть и недостатки. Модели SystemC выполняются последовательно (не распараллеливаются), поэтому они не используют многоядерные архитектуры для ускорения моделирования. Это горячая исследовательская область, где желательно моделирование.
Во всяком случае, ядро SystemC, таким образом, реализует совместное планирование, где каждый SC_THREAD охотно отказывается от контроля (используя wait) разрешать другим SC_THREAD процессы для выполнения. Если у вас есть бесконечный цикл внутри SC_THREAD процесс, который никогда не откажется от управления, вся симуляция застрянет там, и время симуляции не увеличится. То же самое относится и к SC_METHODs, которые должны возвращаться для восстановления контроля ядром SystemC.
Чтобы реализовать эту стратегию совместного планирования с использованием сопрограмм, используется библиотека потоков (например, pthreads или QuickThread, включенная в исходный код SystemC), чтобы включить SC_THREAD(запускается как потоки), чтобы приостановить себя и позволить ядру возобновить их позже. Читать Эта статья узнать больше об этом.