Udv.

Köszi a gyors választ.

Ha jól értem amit írsz, akkor nem tudnám megoldani a több száz bit kezelését ezzel a módszerrel egy blokkban. Spartan 3E 500-asban "256x72 (single-port only)" a max. szervezési méret, vagyis a 16K-t 256 darab 72 bites rekeszre tudnám szétszedni. Ha nekem az egyik modulban van 150 bit, akkor a címet is újra kellene számolni.

Lehet, hogy le kell mondanom a full párhuzamos írásról/olvasásról, és egy RAM modult írni a BRAM modul köré. Aztán a GPIO modul, kommunikációs modul, stb. Wishbone buszon keresztül írna/olvasna a BRAM-ból a RAM modul segítségével.

Imi.

Sziasztok!

Találtam valamit:
RS232 syscon

Akit érdekel, ebben RS232 felől lekezel dual port BRAM-ot, ír/olvas/nulláz tetszőleges rekeszeket. A másik oldalról lehet valamilyen proci, vagy egyéb más modul, ami szintén ír/olvas a BRAM-ból.

Imi.

Latom aktiv vagy a temaban.. PicoBlaze felol nem tudsz esetleg valamit, lett tovabbfejlesztese, vagy esetleg jelent meg ujabb ingyenes, hasonloan jol dokumentalt szoft proci Xilinx FPGAhoz? Udv.

Üdv gtk!

PicoBlaze-t nem néztem, igazából nem tudom, hogy miért lenne rá szükségem.
Jelenleg úgy látom, hogy amit nem tudok direkt HW-ből megoldani (vagy nem célszerű, mert mezabálná a teljes FPGA-t), azt a PicoBlaze szerű néhány K-s progit futtatni tudó procival sem fogom tudni megoldani.

Pl.:
- kellene TCP/IP stack, hogy lehessen MODBUS/TCP-t üzemeltetni (MODBUS/TCP-re van GPL-s cucc, használom, jól működik linux alatt)
- valami egyszerű WEB szerver, hogy lehessen állítgatni dolgokat (mondjuk BOA + valami cgi/perl)
- esetleg ssh

Ezeket nyilván sem direkt HW-ből, sem PicoBlaze szerű procival nem lehet megoldani (vagy legalábbis nem célszerű). Ami viszont érdekel, az a MicroBlaze (vagy azzal kompatibilis aeMB vagy OpenFire) proci, amelyen már tudok uClinux-ot futtatni. A linux-ot ismerem, így nyilván ebbe az irányba mozdulnék el, persze vannak egyéb OS-k is, amik MicroBlaze-be tehetők, és van TCP/IP stack-jük, de nem ismerem őket.

Persze tudom, hogy MicroBlaze pénzes, vennem kellene EDK-t ChipCAD-től 145-ért, vagy használom a kompatibilisnek mondott procikat.

MicroBlaze + uClinux 500-as Spartan3E-be is tehető:
Spartan3E (500) + ucLinux (1)
vagy:
Spartan3E (500) + ucLinux (2)

Azt hiszem 97%-ban lefedi, úgyhogy nyilván valami nagyobb FPGA kellene később, de tesztnek jó.

Ha sehogy sem megy a MicoBlaze, akkor opencores.org-on kell keresni uClinux-ot futtatni tudó egyéb procit, ami stable, fejlesztik is, stb.

Még nagyon az elején vagyok, amire érdemben használható lehet a cucc, arra már lesz Spartan6 is, ami "nagy+olcsó" lesz, ezt ígérik.

Imi.

hello

nem kell ezekhez uClinux...

a xilinxnek van egy egyszerű webserveres demoja a spartan 3e 1600-as kithez...

tcp/ip stack van, azzal modbusos vackokat meg tudod csinalni, webserver meg annyira nem bonyolult (plussz van kész kód is hozzá a példában)

Szia.

Köszi, ezt meg fogom nézni.

Imi.

Üdv!

Duál portos BRAM ügyében kérdeznék. Szóval működik a dolog, de a manual szerint ha az egyik oldalról írok egy címre, akkor a másik oldalról erről a címről sem olvasni, sem írni nem lehet ugyanabban az óraciklusban. Na de én ezt nem tudom garantálni, mert a user, hogy épp mikor melyik címet akarja elérni az egyik oldalról, ezt nem tudom szabályozni. Azt javasolja, hogy eltérő órát kell használni, de ha ezeket osztogatom/szorozgatom, akkor a fázisuk X periódusonként ugyanaz lesz, ez így nem jó.

Gtk: mintha a video-s projektednél használtál volna duál port BRAM-ot, gondolom egyik oldalról a proci írta, a másik oldalról meg a video rész olvasta, ott ezt hogy oldottad meg ?

Köszi.

Imi.

Hali !

Eldönteni melyik oldal prioritása magasabb, ennek a hozzáférése előtt bebillenteni egy jelző flaget, ha végzett visszabillenteni. A másik oldal meg ehhez szinkronizálna. Ha megengedhető az alacsonyabb prioritásu oldal várakozása. Én külső SRAM-al csináltam igy a VGA-nál. A CRT oldalnak volt prioritása. A grafikus processeknél meg (amik irtak a SRAM videomemórába) az állapotgép memóriahozzáférés állapotában mindenhol bent volt a várakozás a jelzőbitre, ami engedélyezte a SRAM hozzáférést.
A BRAM dualport olvasás nem okoz ütközést, ha jól rémlik.

Üdv. Zoli

Szia Zoli!

Köszi.

Jobban utánanéztem ennek a dolognak: Bővebben: Link

Tehát ha (feltételek: ugyanaz a CLK, és ugyanabban a CLK periódusban):
- címek egyeznek, mindkettőből olvasni akarsz, akkor nincs probléma
- címek egyeznek, egyikből olvasni, a másikba írni akarsz, ez problémát okoz, de csak akkor ha "NO_CHANGE vagy WRITE_FIRST" beállításban használod egyik vagy másik (vagy mindkettő) oldalt, ha "READ_FIRST"-ben használod, akkor itt sincs probléma
- címek egyeznek, mindkettőre írni akarsz, adatok eltérnek. Ez gond, ezt kell megoldani. Ahogy nálad is, nálam is egyértelműen eldönthető, ki élvez magasabb prioritást.

Ezt találtam ki:



Vagyis a kritikus esetben B-t tiltjuk, az lesz a cellában, amit A akar. Jó ez így ?

A másik, hogy nálad mi értelme volt szimultán 2 oldali írásnak ugyanabba a cellába ?

Üdv.

Imi.

Szia Imi !

Hogy jó e amit leirtál verilogban, azt nem tudom eldönteni, mert én csak VHDL-ül értek .
Csak példaképpen irtam az esetemet, a megoldást illetően. Mivel a külső SRAM nem dualportos nálam, és a CRT fele csak kiolvasás van, igy szimultán irás nem fordulhat elő. A SRAM 2x CRT pixelclock-on megy és egy ciklus a CRT kiolvasás, egy ciklus az irás vagy olvasás a külső eszköznek. Ez lehet az MCU felől ékező cim,adat (videomemóriahozzáférés) vagy egy az MCU felől érkező parancs (+paraméterek) által elinditott process, ami ir vagy olvas a videomemóriából, ha a jelzőbit jelzi, hogy szabad a busz. Szóval ez nem egy dualportos eset. Itt két olvasás is ütközés lenne.
Csak a jelző segitségével megoldható szinkronizációra akartam utalni. De, ha nálad nem gond ha valami kimarad, akkor úgy is meg lehet oldani ahogy irtad.

Üdv. Zoli

Üdv.

Ok, akkor így próbálom meg.

Ezt a sort javítani kell:



Erre:



Imi.

Szia ! Mar nem emlekszem hogy volt-e ezzel problemam. Viszont most nezem a kodot, es: a video ram 4k, vagyis 2x2k block ram osszefuzve. A RAM_0 -nal WRITE_MODE_A => "WRITE_FIRST" WRITE_MODE_B => "WRITE_FIRST" . RAM_1 -nel: WRITE_MODE_A => "READ_FIRST", WRITE_MODE_B => "READ_FIRST" . A proci felol meg inditaskor van egy setup rutin, es csak ezutan ir a video ramba. Ebbol az kov. hogy a ket port eltero cimen van olvasva/irva.

Üdv.

Köszi.

A lényeg hogy kiderült, erre figyelni kell, ha ilyenbe akadunk.

Imi.

Sziasztok !

Van egy VGA TEST VHDL kodom FPGAra (fpgan mukodik), ezt mar regebben at raktam XC9572XL CPLDre. Felre volt teve mert valamiert nem mukodott. Most ujra elokerult.
Ma szkoppal nezegettem es a szinkron es az RGB jelek folyamatosan H szinten vannak. 3.3 V tap ok, 100nf ok, GNDk ok, orajelet megkapja a 25MHz oszcirol. Van amikor csak ugy megjelennek a szinkron es az RGB jelek, de semmivel nem tudtam osszefuggesbe hozni, es inkabb H szinten van mint hogy mukodne. Mi a csoda lehet?

Elfelejtettem irni, hogy a panel hazi, es ket CPLDvel is probalkoztam, eredmeny ugyanaz.

Sziasztok !

Sikerult megoldani a problemat. A reset-re kellett egy lehuzo ellenallas. FPGAnal erre nem volt szukseg, ezert nem is gondoltam korabban hogy esetleg itt lehet a problema.
Namost ezzel kapcsolatosan lenne kerdesem:
Ha XC9572 CPLDnel az IOB-t bemenetnek allitjuk, alapbol milyen szinten lesz a bemenetunk? Lehet ezt allitani UCFbol ?

Üdv.

Úgy tudom, hogy a belső pullup ellenállás SW-ből nem állítható. Amikor a cucc elindul, illetve programozás közben ez aktivizálódik (megelőzve az esetleges lebegést), egyébként nincs bekapcsolva. A DS063 szerint, ha ennek a bemenetnek alacsonynak kell maradnia programozás közben is, akkor kell egy külső pulldown. Egyébként nem írják, hogy lenne bent öntartó (utolsó stabil állapotot tartó) funkció. Vagyis szerintem normál működés közben külső ellenállás nélkül lebeg, lesz ami lesz alapon beáll valami véletlen értékre. Szerintem nem jó ötlet egy kívülről nem meghajtott bemenetet belülről figyelembe venni.

Imi.

Üdv.

Bocs, még valami eszembe jutott:
Ha XC9572-n a GCK/GSR/GTS jeleket általános célra használod, akkor ezek úgy tudom, hogy invertálva jönnek be valamiért.

Imi.

Szia ! Koszi !
FPGAnal valahogy maskeppen lehet a dolog, mert ott nem kellett a VGA_modul_resetre kulso lehuzo ellenallas. Majd alaposabban utanna nezek.. Udv.

Sziasztok
Van valakinek a fiókjában FPGA fejlesztői nyák?
BGA tokos 256 / 320 pines?
De érdekel komplett is.
XC3S400 vagy nagyobb FPG és minimum 90 IO

Üdvözlök mindenkit!

Elkezdtem próbálkozni az Altera cég NIOS II rendszerével. Nekem egy DE1-es fejlesztőkörnyezetem van.
Az alap dolgok jól mennek, csak egy feladatnál elakadtam. Szeretnék a rendszeremhez hozzáadni egy sd kártya modult. Ami alkalmas lenne azt az opencores.org on találtam. A probléma, hogy ez Wishbone buszra tervezték és a NIOS Avalont használ. Azt írják, hogy a kettő nem sokban különbözik. Azzal van a problémám, hogy a verilog nyelvben nem igazodok el. Ha valaki tudna abban segíteni, hogy milyen jeleket keressek a top modulban és azt hogy kell megváltoztatni, azt nagyon megköszönném.
A buszok jelei közti kapcsolat: Bővebben: Link

A segítséget előre is köszönöm!

Tibi

Sziasztok!

Most kezdek ismerkedni a CPLD-kel. Van pár XC9536-om.
Altium DXP-t szeretnék használni. Milyen kábellel tudnám programozni? Kezdésnek egyszerű, házilag elkészíthető érdekelne.

Előre is köszönöm.

USB-s kellene, nincs párhuzamos port a laptopon.
Köszi.

Szia!

Xilinxről nem sokat tudok, csak annyit amennyit az egyik barátom próbálkozott vele. Neki egy Xilinx starter KIT-je van. Próbálta az altiummal összehozni , de sehogy sem sikerült.(Nekem se ment az Alterás cuccal). Úgy oldotta meg, hogy megtervezte altiumban a cuccot, teljesen tesztelésig elment, majd legeneráltatott egy köztes állományt. Ezt a webpack segítségével a gyári kábellel feltöltötte az FPGA-ra.

Ha ez az út a te esetedben járhatónak tűnik, megkérem a srácot nézzen fel fórumra, vagy írja le részletesen mit, hogyan csinált...

Üdv,
Tibi

Üdv.

USB JTAG adapter

Ettől függetlenül miért jó a DXP ? Tud HDL-t, és azt szimulálni ?

Ha nem, akkor szerintem maradj a Xilinx tool-oknál, és persze HDL leíró-val kellene kezdeni, a kapcs. rajzot felejtsd el.

Az impact megy parancssoros módban is, ha a DXP le tudja generálni a BIT file-t, akkor az impact-al be tudod írni (úgy szokták, hogy írnak rá egy batch file-t).

Imi.

Sziasztok!

Valaki próbálkozott már a xilinx FPGA-hoz LPT portos JTAG programozót valamilyen számtech boltban kapható USB-s nyomtató porttal használni? Sajnos igen borsos az ára az eredetinek, és jó lenne ha létezne valamilyen alternatíva.

Szia
Printerportost használom, sajnos laptopról, mert a Vista64-el nem megy, XP-m meg összeesett
De lehet megveszem az USB-s JTAG-et a digilentest.
Szívásmentes...

Tehát most a laptopodon van printerport, vagy USB-s printerportot használsz?
Hát igen, sajnos igencsak drága bármilyen fpga-s panel, és tartozéka. Azon gondolkodok, hogy vajon házilag lehetne-e építeni egy eléggé alap verziót? Elég lenne egy panelra csak az FPGA, táp, órajel, meg a flash neki meg egy rakat tüskesor. (persze a programozó továbbra is bibis).
Az első komolyabb nehézség, hogy a 0.5mm lábtávolságú 144-208 lábú toknak lefotózni a nyákot.... Az első lézernyomtató ami a kezembe került megbukott nyomtatási minőségben (a tok padjei nem különültek el eléggé)...

Hogy epiteni lehet-e,..miert ne lehetne, lattam a neten tobb peldat ra. Ide kapcsolodik: a gyari "Starter KIT" panelok azon tul, hogy nagyon dragak, szerintem csak tanulni jok, mert tele vannak pakolva mindenfele folosleges kiegeszitokkel, es az fpga portokhoz alig lehet hozzaferni. Nekem van SP-3e, de meg is tervezem egy jo ideje hogy sajatot kellene epiteni, mondjuk gyartott panelon, ket retegen, Tobben emlitettek, hogy ket retegen nem lehet,.. egy BGA tokos cuccot boztosan nem, de TQFP -t biztosan igen, es csak ertelmes kiegeszitoket rakni melle, SDRAM, FLASH, tap, orajel, az IOkat meg tuskesorra.

Igazából az a problémám, ha vennék is egy demópanelt, és írnék rá valami kódot, akkor is kész készülékbe bele kell építeni az FPGA-t. Oda nem rakhatok demópanelt.
Szóval most csináltam a egy nyáktervet, amin van 1db TQFP tokos fpga aminek a lábai csak úgy ki vannak vezetve, és megpróbálom valahogy elkészíteni.