Programmazione CPLD EPM1270

[BIGMUFF]

@legacy

Ciao.

Guarda.... il costruttore mi ha chiesto 60 euro a scheda.

Che io mi ricordi la CPLD su farnell (o rs?) dovrebbe stare sui 27 euro e le ram sugli 8 euro l'una(sono 2).

Io credo che sia decisamente troppo. Ho deciso di resuscitare il progetto solo perche' avevo gia' pronte le librerie e gli esempi per fare un lavoro a breve e sarebbe costato troppo sviluppare tutto da zero.
Secondo me, per quello che conta la mia opinione, buttando tutto su una fpga con le ram interne al chip l'accrocco potrebbe costare un terzo di 50 euro, montaggio compreso e si potrebbero aggiungere un sacco di cose in piu'(tanti PWM, semplici DSP, DDS,etc...)
Tra l'altro ho in cantiere un soft-processor da 8 bit(quasi completamente funzionante) che potrebbe anche vanificare l'uso di un uC esterno.

Se qualcuno fosse interessato all'accrocco possiamo aprire un altro topic e lavorare insieme a fare qualcosa di decente e utilizzabile a basso costo. Unica richiesta e' mantenere il nome originale dell'ogetto.

Sarebbe veramente una bella palestra e mi permetterebbe(molto egoisticamente) di sperimentare il lavoro di squadra.

Ciao

a presto

Massimo

[deluca]

@bigmuff
Che architettura il soft-processor a 8bit?

Nome originale del progetto? quale sarebbe?

[legacy]

In effetti ad es con una fpga s3e-500 ha almeno 32Kbyte di BRAM usabili in gruppo da 4Kbyte cad, anche se ti costa il fastidio - parlo della app finale, in sviluppo a me piace fare bootstrap da jtag - della bootstrap flash esterna, che nel caso, a volte costano tanto, mentre le CPLD sfruttano la flash interna.

Le interfacce ram esterne poi pagano lo scotto del bus asincrono, a meno di andare su DDR, che invece paga lo scotto del complexity sul PCB sopratutto dalla DDR2 in poi. Poi son gusti ed esigenze, a me personalmente, se non ho abbastanza BRAM interna (p.e. sulle s3e-100, dei macinini piccolissimi), allora piace la SRAM, anche perche' … volendo la posso tamponare modi Non Volatile storage di battaglia, mentre con la BRAM di una fpga … togli Vcc ed hai perso tutto.

Cmq, non mi sembra troppo eccessivo come costo-finale, certo dipende cosa ti fornisce, ma se il tizio ti monta ed assembla il tutto fornendoti un buon PCB allora ci sta'. I service si fan pagare, e chi oltre al PCB fornisce materiale e/o assembla (p.e. saldatura e pulitura) si fa pagare ancora di più. E' anche la differenza tra un PCB home made ed un prodotto.

Io pero' non sono un fan dei SoC, preferisco i CHIP ASIC, sopratutto oggi che un ARM costa nulla, al limite poi attorno gli si infila una fpga modi periferica, ma avere a che fare con un SoC a me, personalmente, se deve essere hobby, allora non piace.

edit: mi ha anticipato deLuca, stessa domanda

Ma per curiosita' che SoC hai in mente ? Che architettura ? Per caso Z80 ? Ultimamente va di moda resuscitare vecchie arcade machine (probabilmente retaggio delle vecchie sale gioco) che se non ho capito male hanno ROM proprio per Z80.

[BIGMUFF]

Ciao,

Sono un po' in imbarazzo e chiedo scusa per l'ignoranza.
Il 70% dei termini tecnici e dei nomi usati da legacy non li conosco(ragazzotto di campagna sono).

Per rispondere a entrambe :

Il soft-core a 8 bit ha la famosa architettura "BOH".

Nel senso che ho preso l'instruction set del PIC16f84, l'ho potato un pochino ed ho tenuto solo le istruzioni fondamentali per risparmiare logica disponibile e ne ho qaggiunte un paio o forse piu' per i salti condizionati senza dover per forza andare a vedere lo status register del micro via software.
Ho aggiunto uno stack hardware(32 byte) per le chiamate a funzioni(ma si puo' usare anche per stoccare dati), ma non ho seguito nessun progetto gia' fatto, anche perche' ci ho provato a prendere spunto da qualcosa di gia' fatto e non ci ho capito niente.
Il nome dato al core e' : Nikita (il nome di mio figlio).
Al 90% i soft-processor non si fanno come li ho fatti io. Probabilmente esiste qualche documento accademico che suggerisce come strutturare il tutto ed evitare sprechi. Ripeto....il mio e' un percorso totalmente personale ed empirico perche' non ho trovato nessuno con cui condividere queste esperienze in passato. Sarebbe veramente bello se io riuscissi ad allinearmi con voi(e a vedere da come mi avete gia' aiutato...mi aiuterete anche in questo argomento).

E' tutto sviluppato in data-flow

Comunque qualche info sul processorino :

- in un cyclone II di quelli che sto usando (ep2c8t144c8n) di questi micro ce ne entrano 4-5
- set istruzioni da 15 bit(14 non ce l'ho fatta)
- registri ALU da 8 bit + carry
- memoria programma 1KByte(ma al momento vede solo 256 byte)
- memoria variabili 1KByte(ma al momento vede solo 256 byte)
- stack 32 Byte(questi li vede tutti )
- 4 cicli di clock per istruzione(tutte le istruzioni, anche i salti)
- velocita' massima testata 75 MHz su Cyclone II. (75/4 MHz e' la frequenza di esecuzione delle istruzioni)
- generatore video composito TV con uscita monocromatica sia testuale(60x60) che grafica (240X480X b/n)
- uart fino a 250Kbaud (ma allo stato odierno ho qualche problema in ricezione, ogni tanto riceve caratteri sbagliati)
- set istruzioni asm copiato a microchip ma non compatibile con in linguaggio macchina(si puo' rimediare)
- font caratteri inclusi nel chip e rubati al commodore 64 con aggiunte e potature per aggiungere nuovi caratteri
- per il momento ha solo una PORTA di PIN, solo in uscita


prossimamente posto qualche foto dello screenshot

@Deluca

Professore, le ho scritto in privato

Ciao

Grazie

Massimo

[legacy]

Anche S-VHS ? Bello!

Dovresti dare un nome a quella ISA, chesso' … (2) "myE8", ma se ha una ISA simile al (1) si puo' modificare un assembler per (1) per fargli sfornare oggetti e/o binari adeguati per (2), almeno per avere un compilatore asm a portata di mano. Quello per picoBlaze (come complessita' e dimensione della ISA siamo circa vicini al (1)) p.e. e' talmente scarno e scomodo che un po' tutti stanno facendo a gara per migliorarlo.

(1) PIC16f84
(2) "my8" aka "my easy 8 bit CPU"

[deluca]

Carissimo Massimo,
l'idea di aprire un topic relativo allo sviluppo condiviso di IP-core non sarebbe una cattiva idea.
Ti invito ad introdurre l'argomento e vedrai, se a qualcuno interesserà, che non rimarrai da solo.

Cmq NIKITA mi piace sarebbe come dire NIK Italiano o meglio ancora se calza a pennello qualche acronimo per NIK.

[BIGMUFF]

@Legacy

Si puo' fare veramente?
Costringere un compilatore a generare codice per un micro molto differente da quello per cui e' nato?
Se fosse cosi' si andrebbe veramente alla grande!

Ciao

Massimo

[peter90]

salve a tutti
scusate ma questa cosa mi sembra inverosimile.
come farebbe un compilatore per pic16 a compilare per avr atmega o cose di questo genere

ciao

[legacy]

Certo che si può fare, ma ti sto dicendo, si prende lo scheletro di un compilatore assembly per PIC16f84 e lo si modifica per supportare una ISA molto simile, ovvero la tua, anzi, se mi dici come e' fatta la tua ISA, o quanto e' diversa da un PIC16f84, posso anche essere + specifico sulle modifiche.

[legacy]

salve a tutti
come farebbe un compilatore per pic16 a compilare per avr atmega o cose di questo genere

Volendo si può fare anche questo, e l'hanno fatto in Dalsemi con la tecnologia jump51 (1999), ovvero un "coso" che si prende in ingresso bytecode per ISA picoJava1 (oggi nota come WABA), lo disassembla, e lo riconfeziona per 8051 (nel caso specifico per 80C390/80C400), e lo stesso dicasi per aggeggi simili che fanno altrettanto da python-byte-code a … machine specific code. Pero' sono aggeggi che funzionano SOLO sotto particolari condizioni al contorno, p.e. funzionano tanto meglio quanto + il codice originale e' a salti relativi, e cmq aggeggi che a me non piacciano particolarmente perche' funzionano come deasm del sorgente, e retarget del target, cosa che non e' detto che tiri fuori codice funzionante (capita che non lo sia, ci sono casi in cui non lo e') e/o ottimizzato, difatti e' caduto in disuso nel 2005.

[legacy]

news ?