क्या उन्नत वीएचडीएल कॉन्फ़िगरेशन वास्तविक जीवन में कभी भी उपयोग किए जाते हैं?

Question

वीएचडीएल कॉन्फ़िगरेशन का उपयोग अलग-अलग नामों से और यहां तक ​​कि पूरी तरह से अलग बंदरगाहों के साथ घटकों को घटकों के लिए बाध्य करने के लिए किया जा सकता है। [see this article for more info]

configuration c2 of testbench is 
    for str 
     for dut_inst : dut 
      use entity work.unrelated(rtl) 
       port map(
        port1 => a, 
        port2 => b, 
        port3 => c, 
        port4 => "unused" 
       ); 
     end for; 
    end for; 
    end configuration c2; 

आप में से किसी कभी देखा यह एक वाणिज्यिक परियोजना परियोजना में होने है? एक असंभव असंबद्ध इकाई में छोड़ने का उद्देश्य क्या था? उन्होंने तुरंत तात्कालिकता कोड क्यों नहीं बदला?

मैं काल्पनिक परिस्थितियों को बना सकता हूं, लेकिन मुझे वास्तविक जीवन के उपयोग के मामले में रूचि है।

Answer 1

नहीं, मैंने कभी जंगली में कभी नहीं देखा है।

मुझे लगता है कि कारण यह है कि ज्यादातर लोग (स्वयं शामिल) यह भी नहीं जानते कि कॉन्फ़िगरेशन के साथ ऐसी चीजें संभव हैं।

Answer 2

पोर्ट बाइंडिंग में कभी भी बदलाव नहीं देखा, लेकिन मैंने देखा है कि यह उसी पोर्ट मैप के साथ घटकों के विभिन्न संस्करणों में बाध्य होता है। मैंने देखा कुछ उदाहरण:

• बड़े सिस्टम स्तर सिमुलेशन के निर्माण के दौरान खाली संस्करणों में बाध्यकारी। डिज़ाइन का हिस्सा उन संस्करणों द्वारा प्रतिस्थापित किया गया है जो डिज़ाइन के अन्य हिस्सों का परीक्षण करते समय मेमोरी पदचिह्न को कम रखने के लिए कुछ भी नहीं करते हैं।
• इसी तरह, लेकिन डिज़ाइन के बस बुनियादी ढांचे का परीक्षण करते समय, सरल इकाइयों में बाध्य करें जो "जंगली 'डरावनी तरीके से प्रतिक्रिया देते हैं।
• एक विशेष ब्लॉक के विभिन्न संस्करण जिनमें अलग-अलग डिज़ाइन समझौता होते हैं। जैसे एक बड़ा और तेज़ संस्करण, एक छोटा लेकिन धीमा। तब सिस्टम को एक साथ आने या किसी विशेष एप्लिकेशन के लिए आवश्यकतानुसार क्या किया जा सकता है, इसके आधार पर इसे बदल दिया जा सकता है।

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

Answer 3

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

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

component Dummy is 
end component Dummy; 

में एक घटक और एक उदाहरण परिभाषित

dummy_g : Dummy; 

फिर, FooMachine में संकेत x की एक इकाई परीक्षण में, मैं एक इकाई + वास्तुकला

entity TestDummy is 
    port (
     x : in std_logic 
    ); 
end entity; 

architecture Arch of TestDummy is 
    ... 
end Arch; 

लिखेंगे है

और एक विन्यास

configuration conf of ... is 
... 
    for all : FooMachine 
     ... 
     for all : Dummy 
      use entity work.TestDummy(Arch) 
       port map (x => x); 
     end for; 
    end for; 
... 
end configuration; 

और फिर मैं TestDummy में अपने दावे लिख सकता हूं।

फिर से, मैं अपने यूनिट परीक्षणों को लिखना पसंद नहीं करता, लेकिन ऐसा कई बार हुआ जब यह दुर्भाग्यपूर्ण समस्या का सबसे अच्छा समाधान था।