[Manian]

سلام
بچه ها من رشتم سخت افزاره (یعنی زیاد از نرم افزار سر در نمیارم). ما برای طراحی دیجیتال از زبون Verilog استفاده می کنیم که معروفه به HDL (Hardware Description Language) . این زبون یه قابلیت به نام PLI (Programming Language Interface) داره که میشه تابع های C (به فرمت فراخوانی C) رو توش استفاده کرد. این توابع رو باید با shared object یا dll به سیمولاتور بفرستیم. حالا من می خواهم یه GUI رو توی verilog بیارم که از کاربر یه سری ورودی بگیرم و نتایج رو همزمان رو خروجی نمایش بدم. حالا مشکل اینه که این توابع وقتی صدا زده میشن باید تموم شن و block نشن ولی مثلا GTK روی دستور gtk_main() متوقف میشه و تابعی که اون رو استفاده کرده block میشه. در واقع من دوست دارم با یه تابع توی shared-object اول یه پنجره درست کنم و با توابع دیگه همون shared-object از پنجره استفاده کنم (مثلا روش یه چیزی بنویسم).نمیدونم تونستم منظورم رو برسونم یا نه؟ :?:

یه مثال از VPI/PLI که بالا گفتم:http://vast.uccs.edu/vast/verilogvpi.html

[Saied]

سلام
ببینم اصلا چه لزومی داره از GUI استفاده کنید؟ شما بایستی سیگنال هایی که می خوای به عنوان ورودی سیستم استفاده کنی از ماجول اصلی بکشی بیرون. بعدش یک test bench می نویسی و تو اون سیگنالها رو مقداردهی می کنی یا اگه تعدادشون زیاده و test bench بزرگ میشه مقادیر رو می ریزی توی یک فایل و زمان شبیه سازی از اون فایل می خونی. همین!
البته این کار تو ابزارهای مختلف فرق می کنه. چمی دونم مثلا تو modelsim این جوری بود که شما بایستی یک ماجول test bench می نوشتی، از ماجول اصلی توش instance می گرفتی و تو یک بلوک initial میومدی سیگنال ها رو مقدار می دادی و نتایج رو از simulator می گرفتی.
مثلا تو ابزارهای Altera و Xilinx مثل Quartus برای altera نیازی به نوشتن test bench هم نیست و بایستی یک wave form تعریف کنی و توش سیگنال ها رو مقدار دهی کنی.
اگه بتونی بگی که GUI رو دقیقا برای چی می خوای امیدوارم بتونیم بهتر کمکت کنیم ولی قطع بر یقین با همین چیزی که بهت گفتم مشکل حل خواهد شد.

[Manian]

سلام
Saied جان تقریباٌ درست میگی در حالت ساده من یه test-bench برای طرحم مینویسم و بهش یک سری ورودی خروجی میدم و wave های خروجی رو نگاه میکنم اگه design بزرگتر بود میشه test-bench رو کمی automatic کرد یعنی خودش یک سری ورودی درست کنه خروجی رو هم مقایسه کنه اگه مقادیر خروجی با مقادیر مورد نظر متفاوت بود خطا تولید کنه. نوشتن test-bench های پیچیده با verilog معمولاٌ کار سختیه ولی با C یا زبانهای دیگه راحتتره. من علاوه بر این میخواهم شبیه سازی interactive باشه یعنی بتونم به عنوان کاربر ورودی اعمال کنم و خروجی مدار رو مشاهده کنم شاید یه مقدار فانتزی به نظر برسه ولی برای تست مدار روش جالبیه!

اگه بتونی بگی که GUI رو دقیقا برای چی می خوای امیدوارم بتونیم بهتر کمکت کنیم ولی قطع بر یقین با همین چیزی که بهت گفتم مشکل حل خواهد شد.

شاید مسخره به نظر برسه ولی این کار رو میخوام برای پروژه آزمایشگاه معماری انجام بدم برای این پروژه ما باید کیبورد ( PS/2 ) و مونیتور رو به FPGA وصل کنیم و براش یه Application درست کنیم مثلاٌ یه بازی ساده! حالا من میخواهم اگه بشه یه GUI برای Monitor درست کنم که مونیتور رو شبیه سازی کنه و یه GUI هم برای کیبورد که هر وقت کسی دکمه ها رو زد ورودی به مدار اعمال شه! ما توی آزمایشگاه روی FPGA های Altera کار میکنیم یعنی همون طور که گفتی با Quartus ولی من برای کار با verilog از کامپایلر Icarus که یه کامپایلر و شبیه ساز اوپن سورسه استفاده میکنم.

[Saied]

من علاوه بر این میخواهم شبیه سازی interactive باشه یعنی بتونم به عنوان کاربر ورودی اعمال کنم و خروجی مدار رو مشاهده کنم شاید یه مقدار فانتزی به نظر برسه ولی برای تست مدار روش جالبیه!

ببین می خوام خودت به این نتیجه برسی که اون جور به قول خودت interactive چیز زیادتری بهت نمیده و اصلا در مقوله design سخت افزار ارزشی نداره. در حقیقت همین verification به سبک test bench هم interactive هست و درستی مدار رو نشون میده.
ببین یه design که حالا یا در مرحله simulation است یا اینکه واقعا به صورت سخت افزاری پیاده شده از component هایی تشکیل شده دو حالت دارند: یا combinational هستند یعنی تا شما سیگنال ورودی رو بذاری حالا با یه تاخیری خروجی رو می بینی یا sequential یعنی شما تا ورودی رو می ذاری و سیگنال های کنترلی رو فعال می کنی تو چند تا clock cycle بعد با عوض شدن state مدار خروجی رو می بینی (حالت سوم هم احتمالا asynchronous ها هستند که بین دو حالت قبلی قرار می گیرند و مقوله جدیدی نیستند). بنابراین چیزی که سخت افزار دوست داره ببینه اینه که سر زمان مناسب سیگنال های ورودی و کنترلی issue بشن. در حقیقت اون جور interactive بودن برای شما یک مزیت است ولی برای hardware اصلا مفهوم نداره.
البته می تونم حدس بزنم که شما چطور به این تناقض رسیدید و می تونه این باشه که Hardware Discription Language ها رو به صورت زبان های برنامه سازی می بینید در صورتی که این طور نیست و اینا همون طور که از اسمشون برمی اد desription language هستند نه programming language یعنی فقط می تونند یک سیستم رو توصیف کنند.
اینکه شما دوست داری سیستم ات با کاربر interactive باشه خیلی خوبه ولی ربطی به مقوله hardware نداره و لزومی هم نداره که design پیچیده تر بشه. شما design ات رو جلو ببر. verification و timing و optimization رو انجام بده حالا اگه دوست داری interactive باشه باید یک سیستم دیگه design کنی که اون سیستم رابط بین کاربر و سخت افزار باشه. مثلا می تونه بنا به کاربرد یک میکرو یا یه DSP یا یه CPU یا یه FPGA/CPLD باشه یا اینکه اصلا نرم افزاری باشه.
امیدوارم منظورم رو متوجه شده باشی.

شاید مسخره به نظر برسه ولی این کار رو میخوام برای پروژه آزمایشگاه معماری انجام بدم برای این پروژه ما باید کیبورد ( PS/2 ) و مونیتور رو به FPGA وصل کنیم و براش یه Application درست کنیم مثلاٌ یه بازی ساده! حالا من میخواهم اگه بشه یه GUI برای Monitor درست کنم که مونیتور رو شبیه سازی کنه و یه GUI هم برای کیبورد که هر وقت کسی دکمه ها رو زد ورودی به مدار اعمال شه!

اتفاقا ما حدود ۲ سال پیش یک سری مسابقه داشتیم به نام FPGA-Contest که دقیقا کارمون همین بود و بایستی یک بازی خیلی ساده که با کیبورد و مونیتور بود پیاده سازی می کردیم. فایل هاش رو اگه پیدا کنم در اختیارت می ذارم. البته اون موقع چون FPGA به فراوونی الان نبود و خیلی گرون بود ما اون طرح رو روی CPLD های ذاقارت دانشگاه پیاده کردیم. احتمالا شگفت زده میشی از الگوریتم هایی که پیاده کردیم تا کل design رو 64K macrocell بکنیم. چیزی که تو دنیای امروز با این FPGA های پرقدرت و البته ارزونی که داریم کاملا احمقانه است.
ببین اخه برای چه می خوای مونیتور رو شبیه سازی کنی یا از تولکیت های گرافیکی مثل gtk استفاده کنی. (این هم از اون حرف ها بود gtk مستقیما روی FPGA). شما وقتی مونیتور رو به بورد و متعاقب اون به FPGA وصل می کنی عملا به تک تک پیکسل های مونیتور دسترسی داری و هرچی که می خوای می تونی روش بکشی. من نمی فهمم چرا می خوای شبیه سازی کنی وقتی واقعیت جلوی چشمت هست!
اگر می خوای از تولکیت ها استفاده کنی مقوله اش یه کم فرق می کنه و بیشتر میره در وادی Embedded Systems . نمی خوام این بحث بیشتر از این طولانی بشه اگه خواستی راهنمایی ات می کنم.
ببخشایید طولانی شد.

[Manian]

سلام

Saied جان با حرفات تا حدی موافقم ولی ما تو design مراحل مختلفی داریم یه موقع داریم در حد RTL-Level طراحی میکنیم که برامون پارامتر های زمان و توان و ... مهمه حالا ممکنه یه وقت بخوایم functionality رو تست کنیم یا طرح رو مدل کنیم. صد در صد شکل شبیه سازی در مراحل مختلف فرق داره چون هم ابزارهامون فرق داره هم هدفمون.
شاید یه شبیه سازی interactive با gui در نگاه اول زیاد بدرد نخوره ولی ممکنه بتونه به طراح کمک کنه برای اینکه کل طرحش رو در حال اجرا ببینه.

البته می تونم حدس بزنم که شما چطور به این تناقض رسیدید و می تونه این باشه که Hardware Description Language ها رو به صورت زبان های برنامه سازی می بینید در صورتی که این طور نیست و اینا همون طور که از اسمشون برمی اد description language هستند نه programming language یعنی فقط می تونند یک سیستم رو توصیف کنند.

نه من مشکلی با Verilog ندارم این چیزی که من میخواهم یه پوسته برای شبیه سازی مدارمه. این امکان که simulator های verilog برای وصل کردن C به verilog میدن فقط به درد شبیهسازی و verification میخوره نه برای طراحی و کار نوشتن test-bench رو حسابی ساده میکنه.

شما design ات رو جلو ببر. verification و timing و optimization رو انجام بده حالا اگه دوست داری interactive باشه باید یک سیستم دیگه design کنی که اون سیستم رابط بین کاربر و سخت افزار باشه

این کاری که دوست دارم انجام بدم در واقع میشه اون رو در مرحله verification در نظر گرفت ولی برای مراحل timing و Optimization باید از روش های دیگه استفاده کرد!

همون لینکی که در پست اول فرستادم توش یه همچین کاری کردن. یه sensor برای پردازش تصویر با verilog طراحی کردن بعد برای تستش در واقع از C استفاده کردن. یه shared-object نوشتن که یه عکس jpeg رو از هارد میخونه و به verilog میده و یه برنامه دیگه که فریم فریم اون رو نشون میده حالا فکر کن اگه این امکان نبود و قرار بود مثلا دستی تو test-bench از روی یه فایل بخونی و نتایج رو هم مثلا از رو waveform نگاه کنی چه قدر مشکل بود! (البته قبول دارم که interactive لازم نیست باشه) حالا اگه پردازش قرار بود روی فیلم انجام بشه که دیگه بدتر(کاری که یکی از دوستام قراره انجام بده و یه مدار برای DeNoising طراحی کنه) . در مورد interactive بودن هم یه جورایی تو بازی به درد میخوره . اگه تو بخوای عملکرد بازیت رو تست کنی اگه سیستم interactive باشه راحت بازی میکنی (ولی فکر نکنم با سرعت شبیه سازی بشه بازی کرد :cry: ) ولی اگه interactive نباشه باید یک سری ورودی به جای کابر درست کنی بعد به مدار بدی وبا خروجی ها مقایسه کنی . بازم میگم این کارا فقط برای تست عملکرده نه طراحی یا timing و غیره...

[Saied]

من احساس می کنم تعارضی که بین نظرات ما وجود داره برخاسته از سلیقه های ماست. بنده به شخصه ارزش و اهمیتی که برای simulation سخت افزار قایلم در حد همون simulation هست نه بیشتر. مهم ترین دلیلش می تونه تجربه باشه. علاوه بر این time to market اصلا اجازه نمیده که بخوایم به این نازک کاری ها فکر کنیم. و نکته اصلی اینه که اصلا simulation کجا و سخت افزار واقعی کجا؟ این قضیه ممکنه توی طراحی های RTL یا Behavioural که بر روی این IC های reconfigurable مثلا همین FPGA ها پیاده سازی می شوند پیش نیاد به این معنی که نتایج شبیه سازی معمولا با نتایج واقعی می خونه ولی مثلا برای یه مدار انالوگ ASIC که قراره در سطح ترانزیستور در فلان تکنولوژی نانو پیاده بشه چطور؟ تجربه نشون میده حداقل در 99% پروژه های VLSI نتایج شبیه سازی و device واقعی یکسان نیست. یعنی مثلا شما میشینی با SPICE یه مدار رو تحلیل می کنه و ولتاژ و جریان ها و gain و ... هزار جور پارامتر دیگه رو در میاری ولی نتایج خود IC یه چیز دیگه رو نشون میده. چرا؟ مثلا ممکنه فلان پدیده فیزیکی اتفاق افتاده الکترون ها به جای اینکه مثل بچه ادم از این مسیر برن تونل زدن و از یک مسیر دیگه رفتن و کل معادلات رو بهم ریختن.
به نظر من یه همچین دلایلی باعث میشه که ارزش simulation کم باشه و بیشتر تست رو بر روی خود سخت افزار انجام بشه که 100% محیطش event-based و interactive هست.

[Manian]

ولی نتایج خود IC یه چیز دیگه رو نشون میده. چرا؟

سلام برعکس حرف شما برای طراحی IC به جز روشهای Simulation ما هیچ روش دیگری در دست نداریم چون هرگونه خطایی در طراحی IC که بعد از ساخت مشخص بشه معمولاٌ دها هزار دلار هزینه داره بدتر از هزینهٔ ٬fabrication زمانیه که این وسط از دست میره که فکر کنم حدود یکی دو ماه باشه (همون time-to-market که بهش اشاره کرده بودی). برای همین٬ سعی میشه مدل هایی که توی Spice برای simulation استفاده میشه خیلی دقیق باشن و حتی المکان شبیه مدل واقعی باشه یادمه وقتی ما تو spice روی تکنولوژی 65nm (شاید هم 45nm بود) کار میکردیم برای هر ترانزیستور حدود ۲۵۰ پارامتر وجود داشت (البته ما فقط دو سه تا شون رو تنظیم میکردیم)! البته برای طراحی مدارهای دیجیتال که امروزه ملیونها ترانزیستور دارن نمیشه از simulation به دقت spice استفاده کرد (چون حجم محاسبات خیلی زیاده) به همین دلیل اول میان Standard-cell درست میکنن و با spice سیموله میکنن. بعد این standard-cell ها رو تو design به صورت RTL سیموله میکنن که خیلی سریع تره.

[Saied]

به کل از بحث اصلی دور شدیم.

سلام برعکس حرف شما برای طراحی IC به جز روشهای Simulation ما هیچ روش دیگری در دست نداریم

بنده منظورم نیست که simulation بی ارزش یا کم ارزش است. گفتم توی پروسه طراحی و ساخت IC مرحله کوچیکی هست و باید سریع ازش رد شد (چون معمولا زیاد بهش باز می گردیم). خوب معلومه اولین قدم پیاده سازی نشستن پشت ابزار شبیه سازی هست. روی صحبت من با طراحی هایی هست که تست شون تو مرحله شبیه سازی OK هست و داره به درستی کار می کنه. اون وقت شما همون چیزی رو که نتایج شبیه سازی اش کاملا درسته میارید روی IC در 99% موارد کار نمی کنه. نمونه سطح بالاش همون بازیه که گفتم. کل کار طراحی رو در 2 روز انجام دادیم و در شبیه سازی هم کاملا درست کار می کرد ولی وقتی روی CPLD اوردیم اشتباه کار می کرد. بیش از 10 روز طول کشید تا تونستیم باگ هاش رو روی سخت افزار واقعی برطرف کنیم.

چون هرگونه خطایی در طراحی IC که بعد از ساخت مشخص بشه معمولاٌ دها هزار دلار هزینه داره

یعنی چی؟ یعنی هر چی ما طراحی کردیم و خواستیم یک نمونه فیزیکال هم ازش داشته باشیم باید ده ها هزار دلار هزینه کنیم ؟ اگه تکنولوژی ASIC منظورته که همچین هزینه ای وجود نداره و اگه هم وجود داشته باشه می ارزه. فرضا اگه 20 تا IC هم خراب بشه نهایت میشه 1 میلیون دلار ولی وقتی به تولید انبوه می رسه چند صد میلیون دلار سود برمی گردونه که عملا هزینه ای نیست. اگه تکنولوژی FPGA منظورت باشه که قابل پاک کردن هست و عملا هزینه ای نداره. برای همینه که همه دارن به سمت FPGA ها تمایل پیدا می کنند.

بدتر از هزینهٔ ٬fabrication زمانیه که این وسط از دست میره که فکر کنم حدود یکی دو ماه باشه (همون time-to-market که بهش اشاره کرده بودی).

مساله بعدی همون time to market هست . فکر می کنی چرا شرکت های غولی مثل اینتل دارن از اون معماری سنتی CISC شون دست می کشن و به سمت RISC تمایل پیدا می کنن؟ یکی از دلایل مهمش اینه که همین زمان های fabrication و تست های فیزیکال رو کمتر کنن. چون layout کلی RISC خیلی خیلی سریعتر نسبت به CISC از کارخانه تولید IC بیرون میاد.
در مورد FPGA هم که program کردنش هزینه زمانی ناچیزی می بره.

برای همین٬ سعی میشه مدل هایی که توی Spice برای simulation استفاده میشه خیلی دقیق باشن و حتی المکان شبیه مدل واقعی باشه

در مورد مدل های فیزیکال نمی خوام بحث کنم ولی این رو مطمئنم قبول داری که مدل یک دقت داره و تکنولوژی های جدید لزوما با مدل های قبلی سازگار نیستند. اگه سازگار بودن دیگه احتمالا علم الکترونیک بایستی متوقف میشد دیگه. ولی این مدل ها بی ارزش هم نیستند. طراحی ای
که در simulation مشکل داره صددرصد توی فیزیکال هم مشکل داره.

خیلی از بحث اصلی دور شدیم. کلا به بیراهه رفتیم. ولی حرف های جالبی مطرح شد. ممنون :wink:

[Saied]

البته برای طراحی مدارهای دیجیتال که امروزه ملیونها ترانزیستور دارن نمیشه از simulation به دقت spice استفاده کرد (چون حجم محاسبات خیلی زیاده) به همین دلیل اول میان Standard-cell درست میکنن و با spice سیموله میکنن. بعد این standard-cell ها رو تو design به صورت RTL سیموله میکنن که خیلی سریع تره.

این تیکه رو اصلا ندیدم!
دقیقا همین طوره. دقت standard-cell ها واقعا بالاست. ولی به قول خودت نمیشه یک مدار رو که یک میلیارد ترانزیستور داره رو شبیه سازی کرد. میشه همین ایده RTL و در چند سال اخیر Behavioural یا system level که مثلا از HDL هایی مثل SystemC و VHDL استفاده می کنند. خودت حتما با اینا سروکار داشتی و احتمالا میدونی دقت شبیه سازی و سنتز شون چقدره

[Manian]

خیلی از بحث اصلی دور شدیم. کلا به بیراهه رفتیم. ولی حرف های جالبی مطرح شد. ممنون

منم ممنونم خیلی بحث خوبی بود ولی به قول خودت خیلی از بحث اصلی دور شدیم! (البته منم اون کار رو بیخیال شدم .امروز تو آزمایشگاه٬ رو FPGA تقریباٌ جواب گرفتیم دیگه بی خیال جنگولک بازی شدم!!! :lol: )! نظرتون چیه یه تاپیک بزنیم و درباره open-source EDA tools و Open-Cores و کلاٌ ابزار های طراحی دیجیتال آزاد صحبت و تبادل نظر کنیم؟؟؟

[Saied]

نظرتون چیه یه تاپیک بزنیم و درباره open-source EDA tools و Open-Cores و کلاٌ ابزار های طراحی دیجیتال آزاد صحبت و تبادل نظر کنیم؟؟؟

خیلی خوبه . البته من فکر کنم چیزی تو چنته داشته باشم که بتونم برای دیگران بگم.