कैसे संश्लेषण के दौरान latches से बचने के लिए

Question

मैं वीएचडीएल का उपयोग करके कॉम्बिनेशन लॉजिक के एक ब्लॉक को डिजाइन करना चाहता हूं, लेकिन कभी-कभी संश्लेषित परिणाम में अनजाने में कुंडी होती है।

सिंथेसाइज़र को लैचिंग से बचाने के लिए मुझे किन कोडिंग दिशानिर्देशों का पालन करने की आवश्यकता है?

उदाहरण: कोड के छोटे सेगमेंट में, अगर मुझे-और स्टेटमेंट्स का उपयोग करना चाहिए?

Comments

अगर कोई मुझे पूछने की कोशिश कर सकता है, तो कृपया मुझे सूचित करें

मुझे यकीन नहीं था कि आपके उदाहरण से आपका क्या मतलब है। कृपया यह सुनिश्चित करने के लिए जांच करें कि रीवॉर्डिंग आपके मूल इरादे से मेल खाती है।

— W5VO

@fatai, मैंने पहले ही टिप्पणी की, meta.stackexchange.com पर उपलब्ध आपके खाते को हटाने की एक विशिष्ट विधि है। मैं उस अंतिम प्रश्न पर जुड़ा था जिस पर मुझे फहराया गया था। साइट पर मध्यस्थों के पास यह शक्ति नहीं है, कभी भी। इसके लिए देव टीम से संपर्क करना होगा।

— कोरटुक

Answer 1

कुंडी से बचने के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि आपके सभी आउटपुट कोड की सभी संभावित शाखाओं में असाइन किए गए हैं।

उदाहरण के लिए,

if a = '1' then
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

एक कुंडी उत्पन्न करेगा, क्योंकि पहली स्थिति में, b (1) का मान निर्दिष्ट नहीं है, इसलिए संकलक ने तय किया कि आप b (1) का पिछला मान रखना चाहते हैं। इसे लिखने का एक तरीका यह है कि एक कुंडी उत्पन्न नहीं होगी:

if a = '1' then
   b <= prev_b;
   b(0) <= '1';
else
   b(1 downto 0) <= "00";
end if;

...

if rising_edge (clk)
    prev_b <= b;
end if;

यहाँ आप स्पष्ट रूप से कहते हैं कि b को पुराने मूल्य को बनाए रखना चाहिए, और फिर नए मान के साथ b (0) को अधिलेखित करना चाहिए।

दूसरा तरीका बा डिफॉल्ट वैल्यू देना है, जैसा कि @ तोमीज का जवाब है।

यदि आप उस कोड को पोस्ट करते हैं जिस पर आपको एक कुंडी मिल रही है, तो हम आपको इसका विशिष्ट कारण खोजने में मदद कर सकते हैं।

Comments

मुझे नहीं लगता कि आपके दृष्टिकोण से b <= bकुंडी बच जाएगी, क्योंकि अभी भी सिग्नल की स्थिति को संरक्षित करने की आवश्यकता है।

— तोमी जुननिला

आप सही हो सकते हैं; मैं बहुत तर्क-वितर्क करने के आदी हूं। मैं संपादित करूंगा।

— fb

Answer 2

यदि आप संयोजन तर्क के लिए प्रक्रियाओं का उपयोग कर रहे हैं (और मैं सिर्फ इस कारण से इसके खिलाफ सलाह देता हूं) तो सुनिश्चित करें कि प्रक्रिया के माध्यम से प्रत्येक पथ हर सिग्नल को कुछ असाइन करता है जो प्रक्रिया ड्राइव करती है। आउटपुट में से कोई भी "अंतिम समय" प्रक्रिया से किसी भी आउटपुट पर निर्भर नहीं हो सकता है।

अन्यथा आप एक कुंडी लगाते हैं क्योंकि अगली बार जब यह प्रक्रिया निर्धारित हो जाती है तो उसे संकेत के मूल्य को रखना पड़ता है जो पिछली बार एक नया मान नहीं मिला था।

मैं विशुद्ध रूप से जुझारू तर्क को निरंतर कार्य के रूप में रखना पसंद करता हूं, और क्लॉक किए गए तर्क के लिए प्रक्रियाओं का उपयोग करता हूं, फिर मुझे कुंडी नहीं मिलती।

Answer 3

कुंडी से बचने के लिए चार नियम:

• संकेतों से मत पढ़ो जो आप लिखते हैं।
• एक सही संवेदनशीलता सूची (सभी संकेत जो आप पढ़ते हैं, संवेदनशीलता सूची में होनी चाहिए)
• सुनिश्चित करें कि सभी संकेत, जो आपके लेखन को हर पथ में असाइन किए गए हैं। (उदाहरण के लिए: if-if-statement की प्रत्येक शाखा में)
• चर का उपयोग करने वाली प्रक्रियाओं के लिए, सुनिश्चित करें कि प्रत्येक चर को पढ़ने से पहले एक डिफ़ॉल्ट मान (दूसरे चर या संकेत में) को शुरू किया जाता है।

इसके अतिरिक्त, यदि आपके पास कई संयोजन प्रक्रियाएं हैं, तो सुनिश्चित करें कि आप एक लूप नहीं बनाते हैं।

कई कोडिंग स्टाइल इन नियमों को पूरा करने में आपकी मदद कर सकते हैं, उदाहरण के लिए @ टॉमिजे के उत्तर में शैली। जैसा कि @ मर्टिन थॉम्पसन बताते हैं, कॉम्बिनेशन लॉजिक से बचने के लिए बेहतर हो सकता है। इसके बजाय हर चीज को एक क्लॉकड प्रोसेस में रखें।

Comments

+1 नियमों का अच्छा सेट। क्या आप इस बात से सहमत होंगे कि आपका नियम # 2 (संवेदनशीलता सूची के बारे में) वास्तव में संश्लेषण और सिमुलेशन के बीच लगातार परिणाम सुनिश्चित करने के लिए महत्वपूर्ण है, लेकिन क्या वास्तव में कुंडी के हस्तक्षेप के बारे में कोई फर्क नहीं पड़ता है?

— रिक

@ एरिक AFIK, इस बात की कोई गारंटी नहीं है कि एक संश्लेषण उपकरण अपूर्ण संवेदनशीलता सूचियों के साथ क्या करेगा। VHDL सिंथेसिस (1076.6-1999) के लिए IEEE मानक में कहा गया है कि: "प्रक्रिया संवेदनशीलता सूची में प्रक्रिया विवरण के भीतर पढ़े जाने वाले सभी संकेत शामिल होंगे। अपूर्ण संवेदनशीलता सूचियों वाली प्रक्रियाएं समर्थित नहीं हैं।" उस ने कहा, मुझे पता है कि कुछ संश्लेषण उपकरण (शायद सभी?) अपूर्ण संवेदनशीलता सूचियों को स्वीकार करते हैं, लेकिन बस संवेदनशीलता सूची को सभी एक साथ अनदेखा करते हैं। यदि आप कठोर IEEE मानक के बजाय उस व्यवहार पर भरोसा करेंगे, तो मुझे लगता है कि आपका कथन सही होगा।

— फिलिप

धन्यवाद, यह सही लगता है, यह मेरे मॉडल को उस मानक के अनुरूप नहीं बनाता है। यह सिर्फ मेरी जिज्ञासा है क्योंकि मैंने अब तक देखे गए सभी संश्लेषण उपकरण संवेदनशीलता सूची की अनदेखी करते हैं, लेकिन मैंने अफवाहें सुनी हैं कि कुछ अनुमान लगा सकते हैं।

— रिक

Answer 4

जैसा कि @fbo और @ मर्टिन थॉम्पसन द्वारा बताया गया है, आपको यह सुनिश्चित करने की आवश्यकता है कि प्रक्रिया द्वारा संचालित प्रत्येक संकेत को प्रक्रिया की प्रत्येक शाखा में कुछ मूल्य सौंपा जाए, और यह मान किसी भी आउटपुट के पिछले राज्य पर निर्भर नहीं होना चाहिए। प्रक्रिया का।

यह सुनिश्चित करने का सबसे आसान तरीका प्रक्रिया की शुरुआत में प्रत्येक आउटपुट के लिए कुछ डिफ़ॉल्ट मान असाइन करना है, उदाहरण के लिए (सह-ऑप्टो फ़ेबो का उदाहरण):

COMBO: process(a)
begin
    b <= (others => '0'); -- Assign default value to b
    if a = '1' then
        b(0) <= '1';
    else
        b(1 downto 0) <= "00";
    end if;
end process COMBO;

Comments

यह एक अच्छी विधि है जिसका मैं अक्सर उपयोग करता हूं। कभी-कभी हालांकि, एक कुंडी चेतावनी आपको संकेत दे सकती है कि आप कुछ बिट्स निर्दिष्ट करना भूल गए हैं, जबकि यह विधि बग को खोजने के लिए कठिन बना सकती है। उदाहरण के लिए, यदि आप एक विस्तृत सिग्नल के सभी बिट्स को अलग-अलग असाइन कर रहे थे, और गलती से मिसकाउंट हो गया।

— fb

केवल एक संयोजन प्रक्रिया में। एक क्लॉक की गई प्रक्रिया में, आप एक फ्लिपफ्लॉप का अनुमान लगाते हैं, जो वास्तव में आप चाहते हैं।

— मार्टिन थॉम्पसन