reklama
reklama
reklama
reklama
© Circotasu / Dreamstime Technologie | 03 sierpnia 2011

Biblioteki podzespołów w oprogramowaniu EDA – rozważania

Biblioteki z opisami i modelami symulacyjnymi elementów elektronicznych są kluczowym elementem i najważniejszą częścią oprogramowania do projektowania układów elektronicznych EDA.

Biblioteki z opisami i modelami symulacyjnymi elementów elektronicznych są kluczowym elementem i najważniejszą częścią oprogramowania do projektowania układów elektronicznych EDA. Ich jakość oraz organizacja ma wielki wpływ na czas realizacji projektu, jego spójność, możliwość przeprowadzenia dokładnych i wiarygodnych symulacji oraz w większości przypadków jest powiązana z innowacyjnością tworzonych rozwiązań. Z pewnością ma to też przełożenie pośrednie na koszty prac projektowych. W większości narzędzi projektowych, każda pozycja w bibliotece elementów sprowadza się do przechowywania obrysu obudowy i wyprowadzeń dla projektu płytki drukowanej, symbolu elektrycznego oraz zestawu danych opisujących danych element (wyprowadzenia, model symulacyjny i podobne). Niestety, większość danych zawartych w bibliotekach, jest wprowadzana do baz danych ręcznie, co jest kosztowne, gdyż wymaga zaangażowania i pracy wielu osób. Jest wiele przyczyn, że wykorzystuje się taki archaiczny sposób, niemniej najważniejszym powodem jest brak jakiegokolwiek standardu reprezentacji tych danych, wspólnego dla wszystkich programów typu EDA i CAD. W powołaniu wspólnego formatu danych przeszkadzają rozbieżności w opiniach, jaki kształt i strukturę powinny mieć takie dane, aby były użyteczne dla wszystkich oraz aby w maksymalny sposób poprawiało to efektywność działania oraz możliwości oprogramowania EDA. Poza tym na rynku jest wiele oprogramowania narzędziowego, które ma rozbudowane możliwości w wąskich obszarach, głównie do symulacji obwodów, modelowania 3D i analizy termicznej, które wymagają danych zwykle niedostępnych w bibliotekach oprogramowania EDA. Duże firmy, których oprogramowanie zawiera wiele bibliotek, bazują na charakterystycznych dla siebie, specyficznych rozwiązaniach i formatach danych, które pozwalają im osiągnąć największą wydajność we wszystkich aspektach. Z tego powodu firmy te są niechętne do zmiany używanych metod pracy w trakcie wprowadzania do bibliotek oprogramowania CAD/EDA. Liczba dni roboczych koniecznych na zapanowanie nad wchodzącymi na rynek podzespołami szybko rośnie. Szkoda, że dla każdego elementu wszyscy producenci oprogramowania muszą wykonać razem podobne czynności. Nierzadko ten sam podzespół musi być zapisany w różnych bibliotekach, co dodatkowo komplikuje zagadnienie i zwiększa pracochłonność. W efekcie nakład pracy może sięgnąć godzin na podzespół. Jak wynika z badań ankietowych oraz danych udostępnianych przez producentów oprogramowania EDA średni nakład pracy ludzkiej wymagany do zapisania w bibliotekach nowego nieistniejącego elementu wynosi 2 godziny. Ponieważ z innych badań wynika również, że 20% wpisów dotyczy istniejących podzespołów, dla których dane są jedynie modyfikowane, całość kosztów można uznać za znaczącą. Ręczne wprowadzanie danych wiąże się oczywiście z dużym prawdopodobieństwem popełnienia błędów. Liczba wyprowadzeń wielu układów scalonych przekracza 100, nierzadko w jednej obudowie znajduje się kilka bloków funkcjonalnych, przez co w miarę upływu lat szansę na pomyłkę stale rosną. Wiele decyzji, jak powinien wyglądać schemat blokowy układu oraz rozmieszczenie końcówek na wszystkich stronach, zależy w praktyce od wprowadzającego dane inżyniera i tym samym nawet w obrębie jednej biblioteki dane mogą nie być spójne. Z kolei dane o obrysie obudowy dla programu projektowego płytek drukowanych mogą być wprowadzone niedokładnie, bo zawsze wiążą się obliczeniami matematycznymi w ramach wektorowego modelu obudowy podzespołu. Szansa na zmiany? Mimo, że wydaje się, iż w branży oprogramowania EDA/CAD najłatwiej byłoby uzgodnić wspólny format danych, nadal niewiele się dzieje w tym temacie, gdyż szczegółów i różnic w implementacji pomiędzy jedną firmą a drugą jest bardzo dużo. Wypracowanie kompromisu i uniwersalnego podejścia do standaryzacji akceptowalnego przez wszystkich z pewnością wymagałoby wielu spotkań, uzgodnień i czasu. Dodatkowe komplikacje powoduje fakt, że nierzadko nawet dwa takie same podzespoły od strony funkcjonalnej, rozkładu wyprowadzeń i obudowy są inaczej prezentowane i opisywane w bibliotekach, gdy dane wprowadzały różne firmy lub osoby. Prawie wszystkie te problemy mogą zostać rozwiązane, gdy dane techniczne udostępniane przez wytwórcę zostałyby rozszerzone o kilka ważnych z punktu widzenia twórców oprogramowania EDA/ CAD informacji. Najważniejsze zmiany, które powinny zostać wdrożone to na przykład: • dostarczanie danych w formacie możliwym do przetwarzania automatycznego, • stosowanie symboli i obrysu elementów w formacie standardowym, który mogą wczytać minimum dwa programy dostępne na rynku, • koncentracja na dostarczaniu danych, które mogą zostać w sposób automatyczny przetwarzane, • upewnieniu się, że obrys elementu odpowiada właściwemu rozmiarowi elementu lub jest zgodny z rekomendowanym wyliczeniem wielkości dla modelu wektorowego. • wykorzystywane symbole powinny skupiać się na dokładnym opisie wyprowadzeń, poprawnych oznaczeniach typu i identyfikatorze oraz zapewniać wyraźny podział między miejscem umieszczenia. Zaletami takiego podejścia do zarządzania danymi jest między innymi to, że: • nowe podzespoły, które jeszcze nie pojawiły się w sieci dystrybucji, będą dostępne w bibliotekach oprogramowania EDA znacząco wcześniej, • projektanci zaoszczędzą ogromną ilość czasu i wysiłku, jaki muszą poświęcać na tworzenie własnych opisów symboli w sytuacji, gdy potrzebne dane są już dostępne u producentów elementów. Co więcej, mogą zaoszczędzony czas poświęcić na pracę nad projektem, zamiast angażować się w przetwarzanie danych z kart katalogowych do bazy danych programu projektowego, • precyzyjniejsze i bardziej dokładne dane o elementach w bibliotekach sprawiają, że maleje liczba koniecznych poprawek na etapie prototypu i więcej urządzeń przechodzi przez testy za pierwszym podejściem. Jest zatem bardzo korzystne, aby oprzeć dane projektowe w maksymalnym stopniu na danych pozyskanych bezpośrednio od producenta elementu, niż na informacjach wprowadzonych przez innych użytkowników lub producenta oprogramowania. • wielu producentów oprogramowania może korzystać z udostępnionych przez producenta danych bez konieczności modyfikacji, bez nawet zwykłego dopasowania rysunku obudowy lub symbolu elektrycznego. Możliwe jest też opracowanie automatycznych lub półautomatycznych metod importu danych do bibliotek, co znakomicie przyspiesza ten proces. • wraz ze zmianą standardów projektowania, formatu danych, nadal jest możliwe wykorzystanie danych dostępnych u producenta elementu. • producenci oprogramowania EDA są w stanie skupić swój wysiłek w całości nad tworzeniem oprogramowania, jego wydajności i funkcjonalności, zamiast na wpisywaniu danych do bazy Przedstawiony punkt widzenia staje się coraz bardziej widoczny i bardziej dostrzegalny w branży. Kilku wiodących producentów, w tym National Semiconductor oraz Analog Devices, zaczęło dostarczać dane w neutralnym dla wszystkich producentów oprogramowania inżynierskiego formacie wykorzystywanym przez Ultra Librarian firmy Accelerated Designs. Zmianę tę dostrzegli dystrybutorzy, producenci i inni uczestnicy łańcucha dostaw sygnalizując, że możliwość wprowadzenia danych do programu projektowego w formacie umożliwiającym natychmiastową pracę jest dużą zaletą. Dlaczego zmiany są tak powolne? Trudno znaleźć jakąkolwiek przyczynę, dla której informacja o wyprowadzeniach i funkcjach końcówek układów scalonych i podzespołów, nie może być dostępna w formie czytelnej dla automatycznego przetwarzania, szczególnie, że część producentów dostarcza już takie dane. Niemniej wszystkie z firm, które udostępniają dane przechowują je w różny sposób. Podobne uwagi można mieć, jeśli chodzi o obrys elementu i kontakty elektryczne dla programu do płytek drukowanych. Dzisiaj nie ma wielkich kłopotów, aby przygotować model 3D elementu lub opisać inaczej jego wymiary, niemniej z tradycyjnych kart katalogowych ich automatyczne pozyskanie jest niemożliwe, a ręczne wprowadzanie opisów jest niełatwe i pracochłonne i przez to mało kto jest tym zainteresowany. Wielu projektantów elektroniki wymaga, aby używane narzędzia były w stanie zapewnić możliwość automatycznego prowadzenia ścieżek, układania elementów, a w dalszym kroku symulacji układu. W dalszej kolejności wymaga się, aby program był w stanie kontrolować przestrzeganie reguł projektowych, sprawdzając, czy projekt nie zawiera błędów i jest technologicznie niesprzeczny. Implementacja tych reguł powinna wynikać z danych dostarczanych przez producenta i jest bardzo ważna, gdyż jeśli element zostanie źle dopasowany do dostępnego miejsca, wywołuje to w konsekwencji złe prowadzenie ścieżek i problemy z sygnałami. Podsumowanie Po 30 latach pracy nad projektowaniem płytek PCB, które nierzadko miały tak wyśrubowane wymagania dotyczące upakowania lub gospodarki ciepłem, że poprawny projekt wydawał się niemożliwy, znienawidziłem konieczność uzupełniania danych i poprawy bibliotek, traktując go jako zbędny element mojej pracy. Obecnie poświęciłem się tworzeniu narzędzi projektowych, które mogą pomóc zminimalizować ten wysiłek i uczynić pracę bardziej efektywną, ale nadal, mimo dostępności narzędzi programowych istnieje konieczność utrzymywania aktualnych bibliotek we własnym zakresie. Zmieniające się standardy, wiele różnych narzędzi wykorzystywanych w projektowaniu, wiele nowych produktów pojawiających się na rynku zmusza do takiego działania. Jednak największym problemem jest brak zestandaryzowanych danych od producentów, które można by przetworzyć w sposób automatyczny, dodając je do bibliotek posiadanego oprogramowania. Mam nadzieję, że zanim zakończę swoją pracę zawodową jako projektant, w środowisku nastąpią zmiany i w przyszłości żaden projektant płytek drukowanych nie będzie zaczynał pracy od dodania kilkunastu podzespołów do biblioteki podzespołów. Autorem artykułu jest Frank E. Frank, Accelerated Designs. Rys. 1. Proces tworzenia pliku © Farnell Rys. 2. Diagram przepływu informacji © Farnell Artykuł udostępniony dzięki uprzejmości Farnell
reklama
reklama
reklama
Załaduj więcej newsów
May 28 2020 10:59 V18.6.7-2