আপনি কি নিশ্চিতভাবে জানেন আপনার RISC-V RTL-এ কোনো বিস্ময় নেই?

RISC-V RTL ডিজাইনের আপেক্ষিক অভিনবত্ব এবং জটিলতার পরিপ্রেক্ষিতে, আপনি একটি বাণিজ্যিকভাবে সমর্থিত কোর কিনছেন বা একটি জনপ্রিয় ওপেন-সোর্স অফার ডাউনলোড করছেন না কেন, আপনার শেষ-প্রোডাক্টে অনাকাঙ্ক্ষিত চমকের ছোট কিন্তু শূন্য ঝুঁকি রয়েছে। উচ্চ-থেকে-নিম্ন সম্ভাবনার জন্য, বিবেচনা করুন:

• একটি অদ্ভুত-এখনো-সম্পূর্ণ-সম্ভাব্য কর্নার-কেস বাগ উপস্থিতি
• বাগগুলি "ভিতরে" কাস্টম নির্দেশাবলী যা আপনি বা আপনার বিক্রেতা আপনার অ্যাপ্লিকেশনের জন্য তৈরি করছেন
• একটি কাস্টম নির্দেশের "প্রান্তে" বাগগুলি - যেমন, নির্দেশ সঠিকভাবে কার্যকর হয়, কিন্তু এটি কোনওভাবে মেশিনটিকে একটি দূষিত অবস্থায় ছেড়ে দেয়
• সম্পর্কিত: নথিভুক্ত এবং/অথবা খারাপভাবে নির্দিষ্ট করা নতুন বৈশিষ্ট্য যা অজান্তেই ডিজাইনে গর্ত খুলে দেয়
• দূষিত ট্রোজান যুক্তি গোপনে একটি সরবরাহ চেইন আক্রমণের মাধ্যমে ঢোকানো হয়েছে

সাধারণ প্রশমন পন্থা

স্বাভাবিকভাবেই, প্রতিরক্ষার প্রথম লাইন হল আগত বা উন্নয়নশীল RTL কোডের বিশেষজ্ঞ পরিদর্শন। স্পষ্টতই, এটি করা উচিত; তবে এটি সমানভাবে সুস্পষ্ট হওয়া উচিত যে এই কৌশলটি - যেমনটি তারা গাণিতিক জগতে বলে - "প্রয়োজনীয় তবে যথেষ্ট নয়" (এমনকি যদি আপনি প্রফেসর প্যাটারসন নিজেই আপনার কোড পর্যালোচনা করেন)।

প্রতিরক্ষার পরবর্তী লাইন হল সিমুলেশন-ভিত্তিক পদ্ধতির প্রয়োগ: নির্দেশ সেট সিমুলেশন (ISS), পরিপক্ক সোনালী মডেলের সাথে আপনার DUT-এর স্বয়ংক্রিয় তুলনা, DUT RTL সিমুলেশনের জন্য সীমাবদ্ধ-এলোমেলো UVM টেস্টবেঞ্চ এবং এমনকি হার্ডওয়্যার-সহায়ক এমুলেশনে বাস্তব বিশ্বের উদ্দীপনা পাইপ করা। DUT এর। আবার, এই পন্থা সব মূল্যবান এবং করা উচিত; কিন্তু তারা সকলেই একই ত্রুটিতে ভুগছে: তারা উদ্দীপনা তৈরির উপর নির্ভর করার কারণে তারা সহজাতভাবে অসম্পূর্ণ। উদাহরণস্বরূপ, সাপ্লাই চেইন আক্রমণের চরম-কিন্তু সম্ভাব্য ক্ষেত্রে, ট্রোজান লজিক বিকাশকারী ইচ্ছাকৃতভাবে সিগন্যালিং এবং ডেটার একটি ট্রিগারিং ক্রম তৈরি করেছে যা সম্ভবত সবচেয়ে সৃজনশীল হোয়াইট হ্যাট হ্যাকার দ্বারা সনাক্তকরণ থেকে রক্ষা পাবে। এবং অবশ্যই, কার্যকরী বাগগুলি লুকিয়ে থাকার জন্য প্রাকৃতিকভাবে ঘটে যাওয়া এনট্রপি ব্যবহার করার নিজস্ব উপায় রয়েছে।

মূল কথা হল আপনার RISC-V RTL যে কোনও প্রাকৃতিক বা দূষিত বিস্ময় মুক্ত কিনা তা সম্পূর্ণরূপে নিশ্চিত হওয়ার একমাত্র উপায় হল নকশা যাচাই করার জন্য সম্পূর্ণ, আনুষ্ঠানিক পদ্ধতি প্রয়োগ করা।

কাজ করার চেয়ে সহজ বলেছেন, তাই না?

হ্যাঁ এবং না: 14 বছর আগে, এই ধরণের বিশ্লেষণ শুধুমাত্র পিএইচডি-স্তরের গবেষকরা তাদের নিজস্ব হাতে তৈরি প্রোগ্রাম ব্যবহার করে সম্ভব ছিল। কিন্তু 2008 সাল থেকে, সরঞ্জাম এবং কৌশলগুলি এমনভাবে তৈরি করা হয়েছে যে যে কেউ আনুষ্ঠানিক যাচাইকরণের মূল বিষয়গুলি এবং IEEE স্ট্যান্ডার্ড সিস্টেম ভেরিলগ অ্যাসারশনস (SVA) লেখার সাথে পরিচিত তারা দ্রুত এখানে আবেদন করতে এবং সফল হতে পারে৷

একটি তিন পর্যায়ের আনুষ্ঠানিক-ভিত্তিক প্রক্রিয়া

প্রস্তাবিত আনুষ্ঠানিক-ভিত্তিক প্রবাহটি নিম্নরূপ প্রকাশ পায়:

1. একটি আনুষ্ঠানিক টেস্টবেঞ্চ তৈরি করুন যা DUT স্পেসিফিকেশনকে "মডেল" করে
2. DUT এর বিরুদ্ধে চালানোর জন্য ইনপুট সীমাবদ্ধতা এবং চেকগুলি সংজ্ঞায়িত করুন
3. বিশ্লেষণ চালান

ধাপ 1 - একটি আনুষ্ঠানিক টেস্টবেঞ্চ তৈরি করুন যা DUT স্পেসিফিকেশনকে "মডেল" করে

এই পদ্ধতির ভিত্তি হল বৈশিষ্ট্যগুলির একটি সেট লিখতে যা আপনার RISC-V ডিজাইনে প্রতিটি নির্দেশের আচরণকে উপস্থাপন করে। কাজটি হল IP-এর আউটপুট এবং অভ্যন্তরীণ স্থাপত্য অবস্থার উপর প্রদত্ত নির্দেশের প্রভাব ক্যাপচার করা (RISC-V বিশ্বে, এটি হল প্রোগ্রাম কাউন্টার (PC) এবং নিবন্ধন ফাইল (RF)) যে কোনও প্রদত্ত নির্বিচারে দীর্ঘ ইনপুট সিকোয়েন্সের জন্য। এটি অপারেশনাল এসভিএ নামক IEEE SVA-তে একটি উদ্দেশ্য-নির্মিত এক্সটেনশন ব্যবহার করে করা হয়। সংক্ষেপে, এটি একটি লাইব্রেরি যা আনুষ্ঠানিক-ভিত্তিক প্রসেসর যাচাইকরণ সরঞ্জামের সাথে পাঠানো হয়েছে; এবং যাচাইকরণ প্রকৌশলীর দৃষ্টিকোণ থেকে, এটি পরিচিত SVA কোডের একটি স্বজ্ঞাত উপসেটের মতো দেখায়। চিত্র 1 জেনেরিক গঠন দেখায়:

সম্পত্তি নির্দেশ_A; // ধারণাগত অবস্থা t ##0 ready_to_issue() এবং // ট্রিগার t ##0 opcode==instr_A_opc বোঝায় // ধারণাগত অবস্থা t ##0 ready_to_issue() এবং // মেমরি ইন্টারফেস আউটপুট // পরবর্তী নির্দেশ পড়ুন t ##0 imem_access(instr_A_opc) এবং // ডেটা লোড/স্টোর t ##1 dmem_access(instr_A_opc) এবং // আর্কিটেকচারাল রেজিস্টার t ##1 RF_update(instr_A_opc) এবং t ##1 PC_update(instr_A_opc) এন্ডপ্রোপারটি 

চিত্র 1: একটি প্রসেসর নির্দেশের স্পেসিফিকেশন ক্যাপচারিং অপারেশনাল SVA কোডের কাঠামো। [১]

চিত্র 1 উল্লেখ করে, এর বাম-পাশে নিহিত (কোডের অংশ উপরে মূলশব্দ বোঝা) সনাক্ত করে যখন মেশিনটি একটি নতুন নির্দেশ জারি করার জন্য প্রস্তুত এবং নির্দেশ জারি করা হচ্ছে। দাবীটি স্থাপত্য রাজ্যের বর্তমান মানগুলিকে ক্যাপচার করে এবং অন্তর্নিহিততার ডানদিকে (কোডের অংশ) নিচে মূলশব্দ বোঝা), তাদের পরবর্তী মান প্রমাণ করে।

অতিরিক্তভাবে, প্রসেসরের আউটপুটগুলি সঠিক প্রমাণিত হতে হবে — এই ক্ষেত্রে নির্দেশটি প্রত্যাশিত ডেটা এবং নির্দেশ মেমরি অবস্থানগুলিতে অ্যাক্সেস করে কিনা তা নিশ্চিত করতে। এই দাবিটিও প্রমাণ করে যে মেশিনটি পরবর্তী চক্রে একটি নতুন নির্দেশ জারি করতে প্রস্তুত। নির্দেশের ক্রম থেকে একটি নির্দেশের যাচাইকরণ দ্বিগুণ করার জন্য এটি অত্যন্ত গুরুত্বপূর্ণ যা এটি একটি অংশ হতে পারে। উদাহরণস্বরূপ, নির্দেশ A সঠিকভাবে কার্যকর করতে পারে, কিন্তু মেশিনটিকে একটি দূষিত অবস্থায় রেখে যেতে পারে। এই ভ্রান্ত অবস্থার কারণে পরবর্তী নির্দেশনা B-এর নিজস্ব কোনো দোষ ছাড়াই ভুল ফলাফল তৈরি হতে পারে। তাই, অপারেশনাল এসভিএ পদ্ধতির সাথে, দাবী যাচাইকরণ নির্দেশনা B পাস হবে, যখন দাবী যাচাইকরণ নির্দেশনা A ব্যর্থ হবে (যেখানে পড়া এবং লেখার মেমরি অপারেশনগুলি বেশ কয়েকটি চক্র স্থায়ী হতে পারে)।

নীচের লাইন: অপারেশনাল এসভিএ কোডে আর্কিটেকচারাল স্টেটগুলির প্রতিনিধিত্বকারী ফাংশনগুলিকে অবশ্যই বাস্তবায়ন সংকেতগুলিতে ম্যাপ করতে হবে এবং প্রসেসরের মাইক্রোআর্কিটেকচারকে প্রতিফলিত করতে হবে৷ RF-এর স্থিতি, উদাহরণস্বরূপ, ফরোয়ার্ডিং পাথগুলি সক্রিয় করার উপর নির্ভর করতে পারে৷ [১]

[দ্রষ্টব্য: আপনি যারা সিমুলেশন বা আনুষ্ঠানিক কার্যকরী কভারেজের সাথে পরিচিত তাদের জন্য, সম্পূর্ণতার এই ধারণাটি কাঠামোগত কভারেজ মেট্রিক্সের উপর নির্ভর করে না, বা একটি কার্যকরী কভারেজ মডেলের জন্য মেট্রিক্স তৈরি এবং সংগ্রহের উপর নির্ভর করে না। পরিবর্তে (এবং অবশিষ্ট পদক্ষেপ এবং ফলাফলের থেকে একটু এগিয়ে থাকা), এখানে বিশ্লেষণ আউটপুট সমস্ত বৈশিষ্ট্যের জন্য সম্পূর্ণ প্রমাণ পাওয়ার বিষয়ে। সম্পূর্ণ প্রমাণগুলিও স্পষ্টভাবে দেখায় যে অন্য কোনও কার্যকারিতা নেই — যা অনির্দিষ্ট বা অপ্রত্যাশিত ছিল (বিশেষ বা কোডিং বাগ), বা দূষিতভাবে সন্নিবেশিত — যা এই বৈশিষ্ট্যগুলির সেট দ্বারা ক্যাপচার করা হয়নি। রিফ্রেসিং, এই পদ্ধতিটি সম্পূর্ণ আনুষ্ঠানিক বিশ্লেষণের ফলাফল দ্বারা যাচাইকৃত 100% "পরীক্ষা পরিকল্পনা কভারেজ" অর্জনের বিষয়ে - যেখানে গাণিতিক প্রমাণের চেয়ে "সম্পূর্ণ" কিছুই নয়!]

ধাপ 2 - ইনপুট সীমাবদ্ধতা সংজ্ঞায়িত করুন এবং DUT এর বিরুদ্ধে চালানোর জন্য চেকগুলি

প্রতিটি নির্দেশের জন্য স্পেসিফিকেশন বৈশিষ্ট্যের পরিপূরক করার জন্য, পরবর্তী ধাপ হল ইনপুট সীমাবদ্ধতা এবং কোনো অতিরিক্ত আউটপুট চেক সংজ্ঞায়িত করা। আবার, অপারেশনাল SVA নিযুক্ত করা হয়, যেখানে ব্যবহারকারী এখন আইনি ইনপুট এবং অবৈধ সংকেত উভয়কে সংজ্ঞায়িত করার জন্য একটি "সম্পূর্ণতা পরিকল্পনা" নির্দিষ্ট করে যা DUT-এর উপেক্ষা করা উচিত। চিত্র 2-এ দেখানো উদাহরণ অনুসারে, তিনটি বিভাগ রয়েছে: সংকল্প অনুমান, সংকল্প প্রয়োজনীয়তা এবং সম্পত্তি গ্রাফ।

সম্পূর্ণতা প্রসেসর; determination_assumptions: // INPUTS নির্ধারিত (imem_data_i); নির্ধারিত(dmem_valid_i); যদি (dmem_valid_i) নির্ধারিত হয়(dmem_data_i) endif; determination_requirements: // আউটপুট নির্ধারিত (imem_read_o), যদি (imem_read_o) নির্ধারিত হয়(imem_addr_o) endif; নির্ধারিত (dmem_enable_o); যদি (dmem_enable_o) নির্ধারিত (dmem_rd_wr_o), নির্ধারিত (dmem_addr_o) endif; // আর্কিটেকচারাল স্টেটস নির্ধারিত (পিসি); নির্ধারিত (আরএফ); সম্পত্তি_গ্রাফ: সমস্ত_নির্দেশ := নির্দেশনা_না_একটি, নির্দেশনা_যোগ_এ, নির্দেশনা_উপ_এ, [...] সমস্ত_নির্দেশ -> সমস্ত_নির্দেশ; শেষ সম্পূর্ণতা; 

চিত্র 2: শর্তাধীন সংকল্প অনুমান এবং প্রয়োজনীয়তা সহ একটি সম্পূর্ণতা পরিকল্পনার উদাহরণ।

সম্প্রসারিত:

• "সংকল্প_অনুমান" ইনপুট মান সীমাবদ্ধতার জন্য একটি অভিনব নাম
• "সংকল্প_প্রয়োজনীয়তা" হল সংকেতগুলির একটি সংজ্ঞা যা অবশ্যই যাচাই করতে হবে (প্রসেসরের আউটপুট সংকেত এবং স্থাপত্য অবস্থা উভয়ই)
• "প্রপার্টি_গ্রাফ" বিভাগটি ধাপ 1 এ তৈরি করা সমস্ত বৈশিষ্ট্যের সাথে এই ফাইলটির একটি বাঁধাই।

আমরা এই মুহুর্তে কোথায় আছি তা পুনর্নির্মাণ করা: ধাপ 1-এ আপনি তৈরি করেছেন কার্যকরভাবে DUT-এর একটি চক্র-নির্ভুল মডেল যা সর্বকালের এবং সমস্ত ইনপুটের জন্য সত্য প্রমাণিত হতে হবে; ধাপ 2-এ আপনি সীমাবদ্ধতা এবং কোন বিশেষ আচরণের সন্ধান করতে সেট আপ করেন। এগুলি একসাথে যোগ করুন, এবং কার্যত আপনার কাছে একটি আনুষ্ঠানিক টেস্টবেঞ্চ রয়েছে যা চালানোর জন্য প্রস্তুত!

ধাপ 3 - বিশ্লেষণ চালান

সমস্ত আনুষ্ঠানিক সরঞ্জামের লক্ষ্য হল সম্পূর্ণরূপে প্রমাণ করা যে সমস্ত বৈশিষ্ট্য সর্বকালের জন্য এবং সমস্ত ইনপুটগুলির জন্য সত্য। RISC-V প্রসেসর যাচাইকরণের ক্ষেত্রে, টুলটি প্রমাণ করতে কাজ করে যে যেকোন নির্বিচারে দীর্ঘ ইনপুট সিকোয়েন্স নির্দিষ্ট অপারেশনাল SVA-এর একটি অনন্য সিকোয়েন্সের সাথে মিলিত হতে পারে যা আউটপুট এবং আর্কিটেকচারাল স্টেটের মানগুলির পূর্বাভাস দেয়।

এবং এটি ঠিক কি ঘটে। যদি স্পেসিফিকেশন এবং DUT-এর মধ্যে আচরণের মধ্যে কোনো পার্থক্য ধরা পড়ে, তাহলে আনুষ্ঠানিক টুলটি একটি "কাউন্টার উদাহরণ" তরঙ্গরূপ সরবরাহ করে যা সঠিকভাবে ইনপুট সংকেত এবং ডেটার সিরিজ দেখায় যা স্পেসিফিকেশন লঙ্ঘন করতে পারে। উপরে যেমন উল্লেখ করা হয়েছে, এই ধরনের ব্যর্থতা নির্দেশের RTL লজিকের অভ্যন্তরীণ অংশে বা "হ্যান্ডঅফ লজিক"-এ পাওয়া যেতে পারে যা পরবর্তী আইনি শাখা/নির্দেশকে টেনে আনে।

যেভাবেই হোক, যখন এই সমস্যাগুলি স্থির করা হয় এবং টুলটি সমস্ত বৈশিষ্ট্য প্রমাণ করে, ফলাফলগুলি সত্যিই "সম্পূর্ণ" — অর্থাৎ, আপনি গাণিতিকভাবে নিশ্চিত হতে পারেন যে কোনও RTL কোডিং ত্রুটি নেই — আনুষ্ঠানিক বিশ্লেষণ আক্ষরিক অর্থেই প্রমাণ করেছে যে কোনও ত্রুটির অনুপস্থিতি !

ফলাফল

প্রথমত, উপরে উল্লিখিত হিসাবে, বছরের পর বছর ধরে অনেক প্রসেসর ডেভেলপার এই প্রবাহ থেকে উপকৃত হয়েছে [২], [৩], [৪]।

এই পদ্ধতিটিকে RISC-V এর সাথে পরীক্ষা করে, আমার সহকর্মীরা জনপ্রিয় রকেট চিপ ওপেন-সোর্স কোর ব্যবহার করে একটি কেস স্টাডি করেছেন। বিশেষত, RV64IMAFDC – sv39 vm কনফিগারেশন পরীক্ষা করা হয়েছিল। এটি একটি 64-বিট প্রসেসর কোর যার একটি 39-বিট ভার্চুয়াল মেমরি সিস্টেম [5] এবং এক্সটেনশন, যেমন সংকুচিত এবং পারমাণবিক নির্দেশাবলী [6]। এই ওপেন-সোর্স, RISC-V ISA বাস্তবায়ন একটি পাঁচ-পর্যায়ের, একক-ইস্যু, ইন-অর্ডার পাইপলাইন ব্যবহার করে যাতে বিভাজন বা ক্যাশে মিস করার মতো দীর্ঘ-বিলম্বিত নির্দেশাবলীর জন্য আউট-অফ-অর্ডার সমাপ্তি হয়। কোরটি "মিসা" রেজিস্টারের শাখার পূর্বাভাস এবং রানটাইম পরিবর্তনকেও সমর্থন করে, এটি নির্দিষ্ট নির্দেশ সেট এক্সটেনশনগুলি বন্ধ করার অনুমতি দেয়।

যদিও রকেট চিপের এই স্ন্যাপশটটি ব্যাপকভাবে যাচাই করা হয়েছে এবং একাধিকবার টেপ করা হয়েছে, চারটি পূর্বে অজানা, কর্নার-কেস, সন্দেহজনক আচরণ চিহ্নিত করা হয়েছিল এবং রকেট কোর RTL বিকাশকারীদের কাছে রিপোর্ট করা হয়েছিল। এই সমস্যাগুলি ([7], [8], [9], এবং [10]) শুধুমাত্র এই নিবন্ধে বর্ণিত সম্পূর্ণ আনুষ্ঠানিক যাচাই পদ্ধতির পদ্ধতিগত প্রয়োগের মাধ্যমে আবিষ্কৃত হয়েছে।

বিশেষভাবে [১০] সম্পর্কে বিশদভাবে — আরটিএল-এ একটি অ-মানক নির্দেশনা CEASE (Opcode 10x0) আবিষ্কার: স্পষ্টতই রকেট চিপ দল তাদের ডকুমেন্টেশনে পিছিয়ে পড়েছিল (এবং তারা GitHub পুল অনুরোধ ফাইল করার সাথে সাথেই এটি ঠিক করেছিল)। বৃহত্তর বিষয় হল যে এটি প্রমাণ করে যে একটি সম্পূর্ণ নির্দেশ বাস্তবায়নের জন্য প্রয়োজনীয় লজিক — কোডের কয়েক ডজন লাইন এবং সংশ্লেষিত, স্থাপন করা এবং রাউটেড লজিকের অনেকগুলি গেট — ভিজ্যুয়াল পরিদর্শন, RTL সিমুলেশন, গেট লেভেল সিমুলেশন, সমগ্র ব্যাক-এন্ড বাস্তবায়ন প্রক্রিয়া, এবং ল্যাবে হার্ডওয়্যার প্রোটোটাইপ!

কিন্তু এই প্রবাহের কর্মক্ষমতা সম্পর্কে কি?

প্রথমে, আসুন "পারফরম্যান্স" এর বৃহত্তর অর্থ সম্বোধন করা যাক। রকেট চিপ ডিজাইনের অভিনব প্রকৃতির কারণে, এই কেস স্টাডির জন্য আমাদের আনুষ্ঠানিক যাচাইকরণ অনুশীলনকারীদের পুরো টেস্টবেঞ্চ এবং সীমাবদ্ধতাগুলি বিকাশ করতে প্রায় 20 ইঞ্জিনিয়ারিং-সপ্তাহ লেগেছিল। যাইহোক, আরও কাঠামোগত, বাণিজ্যিক আইপিতে এই প্রবাহের পূর্বের অ্যাপ্লিকেশনগুলি সাধারণত এই সময়ের একটি ভগ্নাংশ গ্রহণ করেছে। স্বাভাবিকভাবেই, পুরো আনার প্রক্রিয়াটি আরও দ্রুত হবে যত বেশি স্থিতিশীল এবং পরিপক্ক বৈশিষ্ট্যগুলি, DUT RTL কোডটি কতটা ভালোভাবে নথিভুক্ত এবং পাঠযোগ্য, এবং প্রশ্নোত্তরের জন্য ডিজাইন ইঞ্জিনিয়ারদের কাছে আপনার কতটা অ্যাক্সেস রয়েছে।

একবার এনভায়রনমেন্ট সেট আপ হয়ে গেলে, প্রাচীর-ঘড়ির রানটাইম ছিল 2 ঘন্টা — অর্থাৎ, সীমাবদ্ধ-র্যান্ডম RTL সিমুলেশন এবং এমনকি হার্ডওয়্যার-সহায়তা যাচাইকরণ থেকে আপনি যুক্তিসঙ্গতভাবে আশা করতে পারেন তার চেয়ে অনেক কম। এছাড়াও, মনে রাখবেন যে এই বিশ্লেষণের ফলাফলগুলি সমস্ত ইনপুট এবং সর্বকালের জন্য বৈধ — এক কথায়, সেগুলি সম্পূর্ণ [১১]।

সারাংশ

এই নিবন্ধে উপস্থাপিত সম্পূর্ণ, আনুষ্ঠানিক-ভিত্তিক প্রসেসর যাচাইকরণ পদ্ধতিটি IEEE SVA, অপারেশনাল SVA-তে একটি এক্সটেনশন ব্যবহার করে, আনুষ্ঠানিকভাবে যাচাই করতে যে একটি RISC-V ISA ফাঁক এবং অসঙ্গতি থেকে মুক্ত। সীমাবদ্ধ-এলোমেলো সিমুলেশন টেস্টবেঞ্চ, এমুলেশন, বা ফিজিক্যাল প্রোটোটাইপিংয়ের বিপরীতে, বৈশিষ্ট্য এবং সীমাবদ্ধতার সম্পূর্ণ সেটটি সম্পূর্ণরূপে অনেক ধরনের RTL ত্রুটি সনাক্ত করে, সেইসাথে অপ্রমাণিত বা খারাপভাবে নির্দিষ্ট কোড এবং দূষিত ট্রোজানের উপস্থিতি সনাক্ত করে।

তথ্যসূত্র

1 – 2019 GOMACTech Conference, Albuquerque, NM, 28 মার্চ, 2019: ট্রোজান-মুক্ত বিশ্বস্ত আইসি, ডেভিড ল্যান্ডোল, ইত্যাদির জন্য RISC-V প্রসেসর আইপিগুলির সম্পূর্ণ আনুষ্ঠানিক যাচাইকরণ।

2 – DVCon 2007: TriCore2 এবং অন্যান্য প্রসেসর, Infineon Gmbh-এর সম্পূর্ণ আনুষ্ঠানিক যাচাইকরণ।

3 - 51^st ডিজাইন অটোমেশন কনফারেন্স (DAC): ওয়ানস্পিন টুল ব্যবহার করে রেনেসাস MCU ডিজাইন প্ল্যাটফর্মে আনুষ্ঠানিক যাচাইকরণ প্রয়োগ করা হয়েছে

4 – DVCon Europe 2019: স্বয়ংচালিত DSPs, Bosch Gmbh এর পরিবারের সম্পূর্ণ আনুষ্ঠানিক যাচাইকরণ।

5 – RISC-V নির্দেশনা সেট ম্যানুয়াল, ভলিউম II: প্রিভিলেজড আর্কিটেকচার, ডকুমেন্ট সংস্করণ 1.10।

6 - https://github.com/freechipsproject/rocket-chip [এক্সেস করা হয়েছে ডিসেম্বর 20, 2018]

7 – DIV নির্দেশনা ফলাফল ফাইল নিবন্ধন লিখিত না
https://github.com/freechipsproject/rocket-chip/issues/1752

8 - JAL এবং JALR নির্দেশাবলী বিভিন্ন রিটার্ন পিসি সংরক্ষণ করুন
https://github.com/freechipsproject/rocket-chip/issues/1757

9 - অবৈধ অপকোড পুনরায় প্লে করা হয় এবং অপ্রত্যাশিত পার্শ্ব প্রতিক্রিয়া সৃষ্টি করে
https://github.com/freechipsproject/rocket-chip/issues/1861

10 – অ-মানক নির্দেশনা CEASE (Opcode 0x30500073) RTL এ আবিষ্কৃত, https://github.com/freechipsproject/rocket-chip/issues/1868

11 – ভেরিফিকেশন হরাইজনস ব্লগ, আপনি কিভাবে বলতে পারেন যে আনুষ্ঠানিক যাচাইকরণ সম্পূর্ণ?, জো হুপসি III
https://blogs.sw.siemens.com/verificationhorizons/2021/09/16/how-can-you-say-that-formal-verification-is-exhaustive/

সূত্র: https://semiengineering.com/do-you-know-for-sure-your-risc-v-rtl-doesnt-contain-any-surprises/