Üdv,
Ha csak egyetlen FPGA van a panelen akkor nem csak egy eszköz kellene legyen a boundary scan-ben?
Amúgy a HS2-es kábel tudtommal csak a digilent Adept programmal használható, iMpact-ból csak Parallel cable III (vagy IV) és a JTAG-USB kábel használható, így az iMpact-ban csak "szimulálni" tudod a programozást azzal hogy készítesz egy xsvf fájlt (olyan mintha beprogramoznád a chip-be, csak egy fájlba írja) majd ezt a fájlt megnyitod az Adept-ben (legalább a 2.0-ás verzióban) és úgy programozod az FPGA-ba, legalábbis nekem csak így sikerült felprogramozni egy CPLD-t

elvileg csak egy eszköz kellene legyen a boundary scan-ben.

Adept ben sem látom az eszközt,többszöri probálkozásra jelenik csak meg.

Érdekes, lehet, hogy valami driver hiba... Akábelt felismeri az Adept? Ha nem, akkor valami driver hiányzik, vagy nem érintkezik valahol valami rendesen. Esetleg próbáld másik számítógépen (XP-vel) vagy másik programozó kábellel.

a JTAG HS2 -t felismeri az adept, és az impact is lássa, megpróbálok másik kábelt szerezni

Ha mindkét program felismeri a programozó kábelt akkor szerintem az FPGA-val lehet valami, vagy ott nem érintkezik jól a csatlakozó, esetleg el vannak kötve az adatvonalak.
TMS <-> TMS
TCK <-> TCK
TDI <-> TDI
TDO <-> TDO
Persze ha csak egyetlen eszköz van, mert ha több van akkor az első TDO-ját a második TDI-jére kell kötni és így tovább, míg az utolsó TDO-ját a programozó TDO-ra.
Lehet hogy a programozó nem tud elég áramot szolgáltatni a panelnek amin az FPGA van, s ezért még külön kellene táplálni panelt is.

már próbáltam úgy is, hogy adok tápot az lapnak, de ugyanaz.

Sziasztok!

Létezik valami magyar nyelvű FPGA leírás?
Gugli barátommal már sokat kerestem ez ügyben, de nem nagyon találtam olyat, ami alapján megértettem volna...

PIC-ekhez van ugye a Kónya László féle könyv, amiből tökéletesen érteni a dolgokat, viszont van valami FPGA-khoz is?

Ugyan nálunk az egyetemen oktatják az FPGA-kat, csak nekem jelenleg az a problémám, hogy 3 hetem van arra, hogy leváltsam a PIC-eket az egyik eszközömhöz, és eme 3 hét alatt szeretnék beletanulni ebbe... És ehhez kérnék segítséget.

Köszönettel, László

Hi!
Bocs, hogy ezt írom, de van egy rossz hírem. Három hét alatt "lecserélni" PIC-eket FPGA-ra abszolút kezdőként nem fog menni. Max a haedwar-t fogod tudni, de a Firmware-t nem.
Az FPGA és a PIC vagy bármely más MCU tűz és víz. FPGA-hoz főleg Verilog és VHDL kell, míg MCU-hoz elég a C, arról nem is beszélve, hogy az FPGA másabb gondolkozást igényel, mert ott minden párhuzamosan megy. Arról nem is beszélve, hogy az összes kommunikációs protocolt(SPI,I2C,...,stb.) neked kell leprogramozni, ami kezdőként nem fog azonnal menni.
Jó anyagot magyarul nagyon nehéz lesz találni. Még angolul sem könnyű, mert kétféle programozás van FPGA-hoz. Az egyik szimulálható, de nem "megvalósítható", amvivel sokat nem érsz, de sok könyv meg csak a szimulálhatóról szól.
Ajánlani és Daniel Silage: Embedded Design Using Programmable Gate Arrays c. könyvét tudom. Xilinx Spartan-3E FPGA-t használ és Verilogban szépen sokmindent megmutat. Közel az egyik legjobb, amit eddig találtam, de nehéz a neten megtalálni. Én inkább megvettem külföldről.

Tulajdonképen csak egy 128x32-es fényújságot kellene leprogramozni, de ha tudsz valami PIC-es alternatívát aminek legalább 10KB RAM-ja van, és 20MHz fölött bőven ketyeg, akkor azt szívesen várnám... (Akár AVR is lehet, mert ott nem osztódik a végrehajtási sebesség OSC/4-gyel)
Tudom, nem ebbe a témába tartozik...

Tudom, ez nem FPGA, de erre a kérdésre válaszolok.
Könnyű találni PIC-et 10+KByte SRAM-mal és 20+MHz-vet, csak a 16bit-esek között kell keresgélni. Pl.: PIC24FJ192GA106, ennek 16KByte SRAM-ja van és 70MHz-en tud futni, de ez 3,3V-os. Van még sok másik is, de ez is csak egy példa.
Ha ezzel kapcsolatban akarsz még tőlem kérdezni, akkor azt majd PM-ben. Ne vigyük el a topicot.

Sziasztok! Valakinek van esetleg tapasztalata a ModelSim használatával Windows 8.1-en esetleg? Felinstalláltam, de a File -» New -» Project-re nem történik semmi

Sziasztok!

Egy tapasztalt tippre lenne szükségem, hogy xilinx spartan sorozatból (vagy kisebb is elég tud lenni?) mekkorára lesz szükségem, ha lpddr ramot szeretnék vele kezelni. A "kezelés" jelen esetben azt jelentené, hogy spi buszt kellene még belegyömöszölni (és valami parancsblokk szerkezetet természetesen), hogy felkínálhassam a kapacitást pic/avr ilyesmi kategóriás áramköröknek. Az lpddr-ek, amiket nézegettem, jellemzően 16 bit, 1.8V, ball 60 tok, 208 mhz, a "túloldal" 3.3 vagy 5v-os elektronika.

Ha esetleg próbaboardokat is lehet épelméjű áron találni xilinx + lpddr felszereltséggel, külön öröm lenne számomra. Egyenlőre google pajtást nem tudtam rábírni, hogy ilyesmit kidobjon nekem. Valami nagyon butaságot akarok esetleg?

A tippeket előre is köszönöm.

a xilinx ISE-ben megnézheted, hogy egy adott kód mennyire foglalja le az FPGA-t.

Sziasztok,

Korábban bejegyzésemben írtam, hogy aki ismerkedni szeretne, ráadásul magyarul FPGA-kal és programozásukkal (pl tradicionális HDL leíró nyelvekkel) létezik néhány on-line elérhető jegyzet és segédanyag.

- Bővebben: Link (ez korábban sze.hu oldalán elérhető volt, ez megvásárolható)

- Bővebben: Link

- Bővebben: Link

- Bővebben: Link (kb 65 oldaltól)

Ezek a jegyzetek főként az FPGA-k és HDL nyelvekkel való ismerkedésre jók: szimulálható kódokat mindegyik segítésével lehet írni, FPGA-ra biztosan szintetizálható kódot viszont nem mindegyikkel (legalábbis a példakódok átalakítása nélkül nem).

Részletesebb, és mélyebb szintű leírások viszont angol nyelven adottak (Ashenden, és Pong P. Chu szerzők sorozatait bátran ajánlanám).

üdv
Zsolt

Sziasztok,

csatlakozok az előttem szólóhoz. Kezdőként, 3 hét igen kevés idő, még egy tapasztalt FW-esnek is hogy IP core-okat (pl. VHDL alapú szellemi termékeket) fejlesszen FPGA-ra.

Jó alternatíva az MCU-t kiváltani amennyiban bővebb funkcionalitást, és tetszőleges konfigurálhatóságot szeretnél. Butaság viszont akkor, ha nem kell nagy teljesítmény, és számít a fogyasztás.

FPGA-ra történő fejlesztés lehetőségei (ezek megismerése kb 1-3 hónap, gyakorlással):
- hagymányos HDL (pl. VHDL, Verilog): magas szintű HW leíró nyelvek,
- magas szintű nyelvek: pl C/C++, itt érdemes a Xilinx Vivado HLS programját és annak leírásait megnézni. Vagy esetleg Altera OpenCL-t. Ez mindkettő gyári termék. Emellett vannak más 3rd party C szintézis tool-ok. Pl. Mentor Catapult C, vagy ImpulseC
- még egy lehetőség modell alapú környezetek használata: pl Xilinx+Matlab DSP toolbox, vagy Ni Labview FPGA modul.

A Pong.P.Chu nagyon jó könyveket írt. Van VHDL, Verilog, es Xilinx, valamint Altera környezetekre is. Vannak gyakorolható ingyenes példa kódjai is a weboldalán.

üdv
Zsolt

Egész véletlenül nincs valami epic linkgyűjteményed / ismersz nagyon jó könyvet (akár angol) dinamikus ramokról is?

Az lp sdr-ek energiafogyasztásán vakarom a buksit, hogyan lehet minnél hatékonyabban az autorefresh-t összeegyeztetni időnként memória adatcserével (egész sornyi adatot egyik bank / sor-ból kiolvasni, vagy oda beírni) úgy, hogy még ne legyen adatvesztés. Időarányban elég időt kellene hagyni a ramnak self-refresh-re is, és úgy rángatni ki belőle adatcseréhez, hogy ne kelljen külön burst refresh-t is használnom, hanem csak visszaengedhessem self reshresh módba, és mindezt adatvesztés nélkül. Aztán ha mégsem lehet ilyet még tapasztalati alapon sem, akkor meg abban vagyok benne, hogy soronként nekem kell frissítést programoznom, ami a katalóguslapja szerint nagyon eszi az áramot

Szóval ami okosság van a témában, szívesen elolvasgatnám.

Sziasztok,

Xilinx Spartan sorozatból a Spartan-3E, lehetne használni, egy Xilinx ISE webpack-al. Xilinx memória támogatások:
Bővebben: Link
A -xilinx application note-ok vegen mindig van táblázat az erőforrás foglaltságról.

Az hogy konkrétan mely FPGA-t, attól függ, hogy mennyi logikát fogyaszt a memória vezérlő. Ha megvan a LPDDR HDL kódja, akkor abból már lehet szintézist indítani, ami megbecsüli az előzetes foglaltságot (it még .ucf -et sem kell megadni). A memória vezérlő ált. sok logikát (~1000x CLB, slice) visz el, ha benne lévő esetleg read/write regiszterek némi BRAM-ot fogyaszthatnak el.

Az lpddr 16 adatlába mellett kb mégegyszer ennyi lábra lesz szükséged a memória kezeléséhez (vannak address - lpddrnél ált oszlopcímzők, illetve további control jelek, pl. cs, cke, ck, stb is).


LPDDR max 3.3V legyen, amely IO standard-et támogat a Xilinx is. 5V max csak szintillesztőkkel megoldható.

Ha lenne ingyenes változata az EDK rendszernek azt mondanám, hogy beágyazott rendszerben kellene gondolkodni. Ugyanis van a Xilinx EDK csomagjában IP core-ként SPI vezérlő, és különböző memória vezérlők is.

üdv
Zsolt

Köszönöm a tippeket, szerintem barátkozom majd a webpack-al.



Miért tartod rossz ötletnek az fpga-t, ha számít, hogy ami funkcionalitást megvalósítanék, az lehetőségekhez mérten kíméletes fogyasztással működjön?

Szia.

Nem tudom mire akarod használni azt a ramot és mekkora kapacitása van de nekem ez kicsit ágyúval verébre esetnek tűnik. Miért nem használsz inkább valami jóval olcsóbb és egyszerűbb SPI SRAM-ot (vagy SPI FLASH memóriát)? Én csak abból indultam ki, hogy a mikrovezérlők sebessége messze elmarad attól a ramtól, meg amúgy sem tudsz annyi adatot feldolgozni velük ami megtöltené, ha meg valami komplex dolgot akarsz akkor abból már ki is maradhat a mikrovezérlő, és megoldod csak simán FPGA-val.
Ha minden áron az a ram kell akkor valami gyorsabb mikrovezérlővel (pl PIC32MZ) vagy valamilyen mikroporcesszorral (pl ARM) próbáld

Szia,

Általános célú memóriának kell, gyakorlatilag minden olyan helyre, ahol koncepció hibás elképzeléssel (oké, ezt elismerem) épületgépészet / ingatlan felügyelet / ipari adatgyűjtés területen 7/24 kell működnie egy elektronikának, és garantáltan nem fagyhat le. Még ha alapvető bajok is vannak egy elképzeléssel, az egyetlen igazi gondjuk, hogy kell egy kicsi helyen elférő, viszonylag gyors, nagy kapacitású (32 mega a legalja, ami elég lehet), végtelen sokszor újraírható memória blokk. Töviről-hegyire végigrágtam már minden mást, kezdve a koncepcionális workaroundokkal, és mindig oda lukadok ki, hogy mégis csak lehetőségek, amik mennek kukába, mert nincs hozzá "alkatrész".

Pic nem kezel dinamikus ramot, az mz sem, és az arm procik sem slave eszköznek vannak kitalálva. Addig jók, amíg masternek kell lenniük. Mindig a slave eszközökön ülepszik le az összes real-time kötelezettség. A workaround egy frame-master visszaküldött jelvezeték tudna lenni az spi mellett, de a protokol összességében az jelentőset lassítana. Ha azt csinálnám, végső soron csak félmegoldás lenne, a "valami van, de nem az igazi" esete.

És akkor már csak csöndben teszem hozzá, hogy hiába van ddr support az fpga-khoz, amennyit hallottam fejlesztői eszköz hibákról, meg amilyen problémákkal jár azokhoz hozzá illeszteni, szerintem a vége az lesz, hogy állapotgépenként "fapadosan" kell majd felépítenem egy memória kontrollert, de még azt is meg fogja érni. Jövő nyárra elkészül

Egy tippet szeretnék kérni erről a boardról:
link felirat jön ide, nem az url

Fpga + lpddr ismerkedésre használnám. Ha véletlenül van róla olyan ismeret közkézen, hogy bajok vannak vele, szeretnék tudni róla. Köszönöm.

A fentebb linkelt doksikhoz kérdésem lenne. Az fpga alapvetően párhuzamosan futtat, de a vhdl megoldja valami alsóbb layerbe legyömöszölt - és a szemem elől alaposan elrejtett - állapotgéppel, hogy sorfolytonosan futtasson utasításokat. Például a modulokon belül megadhatok begin / end blokkokat, de azokat egymásba is tudom pakolni, szóval nem egyértelmű nekem: hogyan tudom ránézésre alapból is elkülöníteni a sorfolytonosan futó kód részleteket a párhuzamosan futóktól? Van erre valami alapszabály?

Szia,

VHDL-ben a vezérlés folyam szempontjából alapvetően 2 féle szerkezetet lehet tekinteni:
- párhuzamos vagy más néven konkurrens értékadások (alapból ez történik pl x <= y)
illetve,
- sorrendi, vagy szekvenciális értékadások. Ez utóbbikra találáták ki a folyamatot, process()-et. Process-ben bizonyos vezérlés átadó utasítások, pl if, loop, stb használhatóak.
Processnél a zárójelben lévő szenzitív lista elemeire kell nagyon figyelni, mely jelekre lesz érzékeny az adott szekvenciális rész.
Viszont több process kivülről nézve, egymáshoz képest megint csak parallel módon "fut".

Nézd meg bármelyik, korábban belinkelt VHDL forrást. Keresztes Péter jegyzete hosszasan és szépen tárgyalja.

Állapotgépekhez, azaz FSM-ekhez egy link a sok közül:
http://vhdlguru.blogspot.hu/2010/04/how-to-implement-state-machines...l.html

Remélem h tudtam segíteni.
Zsolt

Spartan-6 LX alapú FPGA board, az áhított LPDDR1 memóriával. USB programozó nem kell hozzá, azt az integrált FTDI chip szerencsére megoldja.
A legújabb Xilinx ISE 14.x is támogatja ezt a családot.

LPDDR1-el (1.8V) van némi tapasztalat, de nincs vele gond˙.
Manapság azért inkább LPDDR2-es (1.2V) memória modullal rendelkező kártyát érdemesebb venni.

Ha student vagy érdemes az 'academy price' linket is megnézni.

Ha engem kérdeztek, akkor érdemesebb egy olyan kártyát venni ma már, amelyen ARM-el integrált FPGA fabric van, pl Xilinx Zynq, vagy Altera Cyclone V SoC.
Több játékteret ad, nemcsak a hagyományos HDL alapú fejlesztésekhez, hanem akár Linux-ot, vagy más real-time OS-t is lehet futtatni az ARM-es processzorokon. Xilinx ISE-ben, vagy akár Xilinx Vivado / HLS-ben is lehet fejleszteni.
Az előbbihez egy relative "jó" árú board:
Parallella board

Még egy dolog,
ha már ilyen szép fába vágtad a fejszédet, hogy mem_ctrl-t fejlesztesz.

http://opencores.org/projects
memory cores.

Érdemes körbe nézni, hátha.

üdv
Zsolt

Köszönöm a tippeket. Igazából még kezdetibb problémáim is vannak. Van a hdl-ek között a vhdl-en túl verilog meg system c is (és még nem tudom, mik). Azon filozom, hogy ami community-je van az fpga-knak, általánosság jelleggel melyiket szeretik jobban a hdl-ek közül ? Arról már találtam blogokat, hogy fsm vs schematic vs fpga editor vs hdl vs mixing all, de hdl-ek egymás közt még kotorászok a blogok között. Ebben a kérdésben személyes vélemények is érdekelnének.

A memory controller végül is hobby project lesz. Szerintem mind meg tudjuk tippelni, nem ez lesz a leggyorsabban kivitelezett project az i.t. történelmében

Míg kotorásztam a blogokban, nagyjából azt találtam, hogy a vhdl / verilog / systemc egy olyan kérdés, amit jobb nem feszegetni, mert flame lesz belőle, kérdés törölve.

Nézegetem az fpga-k adatlapjait, és tervezem, mi mindenre lesz szükségem (feszültség / áram / szűrőkondik). Beleakadtam egy olyanba a tápfeszek között, ami a "Vccaux" nevet viseli. Mind a spartan3 advancedek, mind a spartan6 részéről találtam rá utalásokat, hogy akár 2.5v akár 3.3v alkalmazható rá. Ami mozaikszavakat találtam a kettő lehetőséghez kötve, valahogy egyiket sem érzékeltem olyasminek, amit direkt keresnék. Alacsony frekvenciás digitális ki / bemeneti jeleim lesznek 3.3 és 1.8v-on, valamint differenciális órajel output 1.8v-on a ddr ramnak. Ha kiutálom a 2.5v-os tápot az áramkörömből, és 3.3-at adok neki, milyen mumus támadhat rám váratlanul a sötétből?

Nyelem a doksikat, és beleakadtam ebbe:

UG626 Synthesis and Simulation Guide (2011 october 9)

page 64 alja:

page 65 teteje:


Hosszú Gábor, Keresztes Péter: VHDL-alapú rendszertervezés
(2012)

54. oldal, idézet:


Kissé ellentmondást érzek. Mit kellene gondolnom?

Verilog sokkal egyszerűbb, sokkal érthetőbb egyszerűbb áttekinthetőbb.

Programozni könyvekből nem tanulsz meg, ezt csinálni kell.