Bolja EDA okruženja za hardver i arhitekture događaja

Kada neko traži bolja EDA okruženja , obično misli na dva povezana, ali različita svijeta: s jedne strane, EDA softver za elektronski dizajn (PCB-ovi, integrirana kola, MEMS, itd.); s druge strane, arhitekture vođene događajima (EDA) u području softvera. U ovom članku ćemo jasno i bez nepotrebnog tehničkog žargona spojiti obje perspektive, a istovremeno pružiti detaljne informacije.

Ako ste frustrirani neintuitivnim alatima poput OrCAD-a , imate problema s izvozom Gerbera ili se osjećate preplavljeno kafkijanskim konceptima poput događaja, ovdje ćete pronaći organizirani vodič za alate, koncepte i obrasce koje koriste profesionalci u elektroničkom dizajnu i modernim EDA arhitekturama.

Šta EDA zapravo znači: elektronski dizajn naspram arhitekture događaja

Akronim EDA se koristi u dva različita konteksta i važno ih je odvojiti kako bi se izbjegla zabuna: klasični svijet elektronike, gdje EDA označava Automatizaciju elektronskog dizajna (Electronic Design Automation) , i svijet softverskog inženjerstva, gdje se EDA obično odnosi na Arhitekturu vođenu događajima (Event Driven Architecture).

U oblasti hardvera , EDA alati su programi koje koristimo za dizajniranje šema, PCB-a, pa čak i integrisanih kola . Govorimo o paketima kao što su Altium Designer, KiCad, Eagle, PADS, OrCAD, ili naprednim platformama za analogna, digitalna i integrisana kola sa mješovitim signalima, integrisanim u profesionalne tokove rada sa simulacijom, rasporedom i fizičkom verifikacijom.

U svijetu softvera, EDA se povezuje s arhitekturama vođenim događajima , gdje različite usluge, mikroservisi ili komponente komuniciraju asinhrono razmjenom poruka putem brokera (Kafka, RabbitMQ, itd.). Ovdje su "događaji" poruke koje predstavljaju poslovne događaje i putuju kroz cijelu organizaciju.

Iako su to različite oblasti, obje dijele jednu ideju: oslanjanje na moćne i dobro integrirane alate za upravljanje složenim sistemima (elektronskim ili softverskim) na siguran, skalabilan način i uz najmanje moguće trenje u svakodnevnom radu.

Najbolja EDA okruženja za dizajn PCB-a

U dizajnu PCB-a, uobičajeno je početi s rješenjima poput OrCAD-a i na kraju biti frustriran neintuitivnim radnim procesima, nepredvidivim formatima ili zbunjujućim procesima izvoza Gerbera. Mnogi korisnici zatim traže okruženje koje omogućava dvoslojne dizajne s mogućnošću rasta do složenijih dizajna , dobrom integracijom biblioteka i razumnom krivuljom učenja.

Među najčešće citiranim alatima za ove potrebe su imena poput Altium Designer, KiCad, Eagle, PADS, Proteus i DipTrace . Svaki ima svoj pristup, ali nisu svi na istom nivou. Pogledajmo najrelevantnije karakteristike glavnih okruženja.

Ako ste student, možda se pitate da li AutoCAD nudi išta za elektronski dizajn koristeći akademske licence. Dok Autodesk ima proizvode usmjerene na PCB-ove (poput starijeg Eagle-a integriranog u njihov ekosistem), sam AutoCAD je dizajniran za CAD opšte namjene; ​​nije tipičan PCB EDA i zaostaje u poređenju sa specijalizovanim paketima.

Jasan skok se vidi u alatima dizajniranim od nule za elektronski dizajn, koji integrišu šeme, raspored, simulaciju i generisanje proizvodne dokumentacije u jednom koherentnom okruženju.

Altium Designer: referentno EDA okruženje za profesionalne PCB ploče

Altium Designer se pozicionira kao najkompletnije i najkonzistentnije EDA okruženje za PCB-ove na tržištu za profesionalnu upotrebu. Ideja iza Altiuma je vrlo jednostavna: pružiti vam cijeli proces dizajniranja na jednoj platformi , od shema do proizvodnih datoteka, bez potrebe za prelaskom iz programa u program ili mučenjem s krhkim integracijama.

Njegova osnova je moderna, 64-bitna, višenitna softverska arhitektura sposobna za rukovanje svime, od malih, dvoslojnih projekata do vrlo zahtjevnih višeslojnih ploča s visokom gustoćom komponenti i strogim zahtjevima za integritet signala ili napajanje. Motor je dizajniran da održi performanse čak i sa dizajnom koji sadrži nekoliko hiljada komponenti.

Snaga Altiuma leži u njegovom objedinjenom okruženju za dizajn : svi alati (snimanje shema, simulacija, PCB editor, 3D modeliranje, BOM, proizvodni izlaz itd.) dijele jedan model podataka i konzistentan interfejs. Ovo značajno smanjuje uobičajene greške povezane s fragmentiranim radnim procesima, kao što su neslaganja između shema i PCB-a ili problemi sa sinhronizacijom biblioteka.

Integrisano snimanje i simulacija shema

Funkcija snimanja shema u Altiumu je dizajnirana da omogući čak i korisniku s osnovnim iskustvom da brzo postane produktivan , bez žrtvovanja snage potrebne za napredne projekte. Podržava višekanalne, hijerarhijske i velike shematske dizajne , te vam omogućava da definirate pravila dizajna direktno unutar same sheme.

To znači da se električna, mehanička ili proizvodna ograničenja koja definirate u shemi automatski prenose na dizajn PCB-a , održavajući jedinstvenu tačku istine. Posjedovanje ove centralizirane kontrole otežava "provlačenje" grešaka pri prelasku s logičke na fizičku ravan.

Nadalje, shematsko okruženje dopunjeno je mogućnostima simulacije i analize kola koje omogućavaju validaciju dizajna prije prelaska na fazu planiranja. Dok mnogi početnici rijetko koriste simulaciju, u srednjim i naprednim projektima ona postaje ključni alat za izbjegavanje nepotrebnih iteracija u proizvodnji.

Još jedna vrlo moćna funkcija je aktivni BOM : upravitelj sastavnice materijala koji povezuje vaš dizajn sa stvarnim dobavljačima putem usluga u oblaku, omogućavajući vam da u stvarnom vremenu provjerite cijene, dostupnost i tehničke specifikacije, te na taj način odaberete komponente uzimajući u obzir i tehničke i aspekte isporuke.

Dizajn PCB-a i 3D okruženje

Što se tiče rasporeda, Altium uključuje vrlo kompletan PCB editor, s podrškom za naprednu kontrolu pravila, interaktivno usmjeravanje i potpomognuto automatsko usmjeravanje , te zaista korisno 3D okruženje kada trebate smjestiti ploču u kućište ili koordinirati s mehaničkim timom.

Editor olakšava precizno postavljanje i poravnavanje komponenti, podržavajući različite mreže i ograničenja razmaka kako bi odgovarali vašoj proizvodnoj tehnologiji. Kombinacija potpomognutog ručnog usmjeravanja i alata za automatsko crtanje znatno ubrzava proces, posebno u završnim fazama završetka dizajna.

Nakon što je dizajn finaliziran, Altium generira sve potrebne proizvodne datoteke i dokumentaciju u skupu : Gerberove crteže, bušilice, montažne crteže, specifikaciju materijala, proizvodne crteže itd. Ovo štedi vrijeme i smanjuje vjerovatnoću zaboravljanja bilo kojih ključnih datoteka za postrojenje.

Ukratko, za one koji traže PCB EDA okruženje s razumnom krivuljom učenja, ali profesionalnim potencijalom , Altium Designer se ističe svojom objedinjenom platformom, bibliotekama i alatima za produktivnost.

EDA za integrirana kola, MEMS i miješane signale

Kada pređemo sa svijeta štampanih ploča (PCB) na dizajn integriranih kola (IC) , slika se znatno mijenja. Ovdje više ne govorimo samo o tragovima i kontaktnim površinama na FR4, već o dizajniranju tranzistora, analognih mreža, RF blokova i digitalne logike na siliciju, sa mnogo strožim zahtjevima za preciznost, performanse i verifikaciju.

EDA okruženja za analogne, digitalne ili mješovite signalne integrirane sklopove obično nude kompletan tijek rada, od shematskog snimanja i simulacije do fizičkog rasporeda i verifikacije spremne za proizvodnju (DRC, LVS, parazitska ekstrakcija, itd.). Cilj je da dizajn izađe iz EDA okruženja praktično spreman za proizvodnju.

U domenu analognih i mješovitih signala (AMS), pronalazimo rješenja koja integrišu i prednji (sheme, HDL opis, simulacija mješovitih signala) i pozadinski (fizički dizajn, postavljanje i rutiranje, verifikacija). Ovi tokovi rada omogućavaju upravljanje SoC dizajnom sa milionima portova , kombinujući analogne, digitalne, RF, pa čak i MEMS podsisteme.

Za analognu simulaciju visokog nivoa, alati poput Eldo RF pružaju više načina analize: tranzijentne, AC, šum, analizu specifičnu za RF i napredne opcije modeliranja usmjerene na postizanje visoke tačnosti bez potpunog žrtvovanja performansi tokom simulacije.

U fazi verifikacije i proizvodnje, platforme poput Calibre djeluju kao de facto standard za fizičku verifikaciju i DFM (Design for Manufacturability) optimizaciju. One integrišu provjere pravila dizajna, poređenje šema i rasporeda i analize koje pomažu da dizajn prođe kroz ljevaonicu bez neugodnih iznenađenja u zadnji čas.

Prilagođeni IC-ovi i ugrađeni MEMS-ovi

Moderna EDA okruženja također obuhvataju dizajn mikroelektromehaničkih sistema ( MEMS ) integriranih direktno na čip. Ovi alati omogućavaju modeliranje složenih 3D struktura (senzora, aktuatora, rezonatora itd.), simulaciju njihove fizičke interakcije i njihov zajednički dizajn s blokovima za elektronsko kondicioniranje signala na istom integriranom kolu.

Tipičan tok rada IC+MEMS dizajna obuhvata sve, od definicije arhitekture, shematskog snimanja i simulacije, do fizičkog dizajna i verifikacije da je rezultat proizvodljiv i da ispunjava tehnološka ograničenja . Sve ovo je, naravno, usklađeno sa kompletima za dizajn procesa (PDK) koje isporučuju ljevaonice.

Za digitalnu logiku velikih razmjera, rješenja poput Oasys-RTL-a rješavaju problem sinteze i postavljanja i usmjeravanja na integrirani način. Dizajnirana su za napredne procesne tehnologije, gdje izazov više nije samo uklapanje dizajna u raspoloživi prostor, već balansiranje performansi, potrošnje energije, varijabilnosti procesa i vremena do plasiranja na tržište.

Ovi sistemi fizičke sinteze nude simultanu optimizaciju površine, snage i frekvencije, te pomažu u smanjenju ciklusa iteracije između prednjeg i pozadinskog dijela, što je ključno kada su rokovi za završetak procesa tape-out kratki.

EDA arhitekture (arhitektura vođena događajima) u softveru

Prebacujući se u svijet softvera, akronim EDA je skraćenica za Event Driven Architecture (arhitekturu vođenu događajima ). Ovdje nema traka ili tranzistora: dizajnirani su distribuirani sistemi gdje je srž modela poslovni događaji i njihov tok između servisa.

U EDA arhitekturi, obično se zamišlja skup proizvođača i korisnika događaja povezanih putem brokera poruka . Umjesto direktnih poziva između servisa, ovi servisi objavljuju događaje na magistrali, a drugi servisi se pretplaćuju da reaguju na te događaje.

Moćna ideja nije samo korištenje mikroservisa i asinhrone komunikacije, već dobro modeliranje poslovnih događaja : šta se dogodilo, ko je to uzrokovao, u kojem kontekstu i kakve posljedice to može izazvati u drugim domenima organizacije.

U ovom kontekstu, događaj je svršen čin: nešto što se već dogodilo. To nije zahtjev ili naredba, već potvrda promjene stanja. I ova semantička razlika je ključna za izbjegavanje prekomjernog povezivanja sistema, čak i ako ih tehnički razdvaja broker.

Događaji, naredbe i tipovi događaja

U EDA-i se obično pravi razlika između naredbi i događaja . Naredba je naredba ili namjera: „kreiraj korisnika“, „započni plaćanje“, „otkazi rezervaciju“. Može se izvršiti ili odbiti i usmjerena je jednom logičkom prijemniku koji je sposoban izvršiti tu radnju.

S druge strane, događaj je trag da se nešto dogodilo : „korisnik kreirao“, „uplata prihvaćena“, „rezervacija otkazana“. Nepromjenjiv je, ne može se poništiti i obično se objavljuje tako da svako ko treba može reagovati na taj događaj, a da producent ne zna ko sluša.

Uobičajeno je klasificirati događaje prema njihovoj upotrebi:

• Događaji u domeniOni opisuju relevantne činjenice unutar određenog poslovnog konteksta. Dio su sveprisutnog jezika te domene i obično sadrže sve informacije potrebne za razumijevanje činjenice.
• Obavještenja ili događaji integracijeKoriste se za obavještavanje drugih domena da se dogodilo nešto što bi ih moglo zanimati, obično s minimalnim informacijama (na primjer, identifikatorom) kako se ne bi otkrili interni detalji.
• Prijenos stanja vođen događajemSadrže dovoljno informacija da ih drugi domeni mogu održavati materijalizirane poglede bez potrebe za stalnim vraćanjem na izvor radi konsultovanja podataka.

Izbor jednog ili drugog tipa ima direktan uticaj na stepen funkcionalne povezanosti između domena, na konzistentnost podataka (trenutne naspram eventualnih) i na sigurnost i privatnost informacija koje se dijele.

Prednosti i izazovi arhitektura vođenih događajima

EDA arhitekture su postale popularne jer pomažu u izgradnji fleksibilnijih, skalabilnijih i reaktivnijih sistema nego klasični monoliti ili čak neki mikroservisni pristupi koji su previše fokusirani na sinhrone pozive.

Njegove glavne prednosti leže u razdvajanju : producent događaja ne mora znati ko će konzumirati događaje, već samo gdje će ih reklamirati. Potrošači, sa svoje strane, mogu se pojaviti ili nestati bez potrebe za modifikacijom producenta, sve dok se poštuje ugovor o događaju.

Ovo razdvajanje olakšava nezavisnu skalabilnost : servisi koji objavljuju ili koriste određene događaje mogu se skalirati prema opterećenju, bez potrebe za premještanjem cijelog sistema odjednom. Posebno se dobro uklapa u arhitekture mikroservisa gdje svaki servis ima jasno definiranu svrhu.

Nadalje, sistemi zasnovani na događajima imaju tendenciju da budu vrlo reaktivni : reaguju u milisekundama na promjene koje se dešavaju negdje drugdje u organizaciji, omogućavajući slučajeve upotrebe gotovo u realnom vremenu za praćenje, upozorenja ili analitiku u realnom vremenu.

To nisu sve prednosti: cijena koju treba platiti je obično veća složenost u upravljanju, otklanjanju grešaka i sljedivosti tokova poruka, kao i potreba za rješavanjem eventualne konzistentnosti, redoslijeda događaja i distribuirane uočljivosti.

Ključne komponente EDA platforme

Robusno EDA okruženje, pored servisnog koda, oslanja se na brojne tehničke komponente koje pomažu u upravljanju sistemom i drže ga pod kontrolom kako raste.

U srcu sistema je broker poruka , koji će u mnogim slučajevima biti Apache Kafka u svojoj modernoj verziji bez Zookeepera. Kafka djeluje kao kanal za distribuciju događaja , osiguravajući trajnost, particioniranje radi skalabilnosti, konfigurabilno zadržavanje i efikasne mehanizme potrošnje.

Uz brokera je obično povezan registar shema , kao što je Apicurio, koji pohranjuje definiciju poruka (metapodatke i shemu podataka) i prati njihovu evoluciju tokom vremena , provjeravajući kompatibilnost unaprijed i unatrag.

Za povezivanje eksternih sistema koji izvorno ne "govore događaje", koriste se ulazno/izlazni konektori , koje obično podržavaju Kafka Connect i konektori otvorenog koda poput Debeziuma. Ove komponente vam omogućavaju da izdvojite promjene iz baza podataka , redova čekanja ili naslijeđenih aplikacija i pretvorite ih u događaje ili obrnuto, pošaljete događaje drugim sistemima.

Sliku upotpunjuje modul za upite i obradu toka podataka , koji se može izgraditi pomoću Kafka Streams-ova ugrađenih u servise ili pomoću mehanizama poput Apache Flink SQL-a kada se preferiraju deklarativni upiti nad kontinuiranim tokovima podataka.

Referentni tehnološki stek i uočljivost

Da bi se spriječilo da EDA arhitektura postane neupravljiv haos, bitno je da se o njoj brine od samog početka uz pomoć koherentnog tehnološkog paketa i dobrih praksi uočavanja.

Što se tiče razmjene poruka, Apache Kafka se etablirao kao jedan od vodećih brokera zahvaljujući svom modelu particioniranih tema, izdržljivosti i performansama . U trenutnim vodičima, standardna je praksa rad s verzijom bez ZooKeepera, što pojednostavljuje rad i poboljšava robusnost.

Registracija sheme je dobro pokrivena alatima poput Apicurio-a , koji implementira specifikaciju Schema Registry-ja i omogućava rad s formatima kao što su Avro, JSON Schema ili Protobuf, verzioniranje shema i validaciju poruka u proizvođačima i potrošačima.

Ulazni i izlazni konektori se obično implementiraju preko Kafka Connect-a , dajući prioritet zreloj zajednici ili konektorima otvorenog koda (npr. Debezium za CDC) prije razvoja prilagođenih rješenja od nule.

U sloju observabilnosti , stek u ELK/EFK stilu (Elasticsearch, Logstash/Fluentd, Kibana) omogućava centralizaciju logova , tragova i metrika. U kombinaciji s bibliotekama poput OpenTelemetry, i kod servisa i sam broker mogu se instrumentalizirati kako bi se dobio potpuni uvid u tok događaja.

Dizajn događaja, ugovori i teme

U EDA-i, ključno je uspostaviti jasnu strategiju za dizajniranje događaja i ugovora od samog početka . Ugovor opisuje, s jedne strane, kako se informacije razmjenjuju (kanali, sigurnost, protokoli), a s druge strane, šta se tačno razmjenjuje (polja, tipovi, ograničenja).

Na operativnom nivou, teme ili kanali brokera su definirani , specificirajući ko može objavljivati ​​ili koristiti sadržaj iz svakog od njih, primjenjive sigurnosne politike i konvencije imenovanja. Uobičajena preporuka je povezati određenu vrstu događaja sa svakom temom i izbjegavati "sveobuhvatne" teme.

Praktična konvencija imenovanja može slijediti strukturu tipa <domena>.<poddomena>.<tip>.<klasifikacija>.<naziv> , gdje je naznačen izvorni domen, da li je poruka naredba ili događaj, njena klasifikacija (npr. domena, obavještenje, esct) i specifičan naziv teme.

Sa informativne strane, ugovori se izražavaju putem shema koje definiraju strukturu događaja. Uobičajeno je uspostaviti zajedničku strukturu metapodataka (porijeklo, jedinstveni identifikator događaja, tip, datum u standardnom formatu, mogući identifikatori korelacije ili sljedivosti) i ostaviti dio s podacima specifičan za svaki događaj.

Za potpuni opis asinhronih API-ja i događaja, sve se više koristi specifikacija AsyncAPI , koja djeluje kao asinhroni ekvivalent OpenAPI-ja. AsyncAPI omogućava dokumentiranje kanala, poruka, shema i sigurnosti u dokumentima koje mogu čitati i ljudi i alati.