Domanda:
Più chip in uscita su un bus per pochi nanosecondi causeranno danni?
fadedbee
2017-06-26 16:11:45 UTC
view on stackexchange narkive permalink

Sto lavorando a un progetto di CPU home-brew, con il solito mix di EEPROM parallele, RAM statiche e registri, triplicato su un singolo bus a 8 bit.

La mia logica / output-enable per tre chip tristate sul bus di dati è:

  / Ken = / a
/ Ren = / a né / b
/ Uomini = / a né (/ b né / b)
 

Devo preoccuparmi dei pochi nanosecondi durante i quali più di un pin del chip / oe sarà basso, a causa del diverso numero di gate?

La corrente che fluisce da un output elevato di un chip a un output basso di un altro chip per meno di 10 ns causerà danni?

Se avrebbe causato danni, come è stata evitata questa situazione negli anni '70 -'80?

Aggiornamento: i chip sono:

Dai un'occhiata alla curva vtc di un inverter cmos https://courseware.ee.calpoly.edu/~dbraun/courses/ee307/F02/02_Shelley/Section2_BasilShelley.htm c'è un punto in cui sia il pull-up che il pull-i fets down sono attivati, questo accade tutti i giorni.Tuttavia è meglio evitare se puoi.
Cinque risposte:
Graham
2017-06-26 18:45:31 UTC
view on stackexchange narkive permalink

Tipicamente la situazione era evitata dalle uscite a collettore aperto anziché tristate, con una resistenza di pullup a + 5V che completa il circuito. Se un dispositivo riduceva la linea condivisa e l'altro diventava open-collector, la linea condivisa rimarrebbe bassa. Se ci fosse un conflitto solo per un tempo molto breve, questo non causerebbe alcun problema.

Per un esempio pratico, il bus CAN è ampiamente utilizzato nell'industria (in particolare nelle automobili) e funziona esattamente in questo modo. L'uscita di ogni dispositivo è a collettore aperto con un limite di corrente e un dispositivo (e solo uno) contiene il resistore di pullup. In un contesto industriale / automobilistico in cui i dispositivi possono andare male, e i cavi possono anche essere cortocircuitati in alto o in basso, questo garantisce che l'uscita del dispositivo non possa danneggiare un altro dispositivo, comunque vada storto. Inoltre, il driver del bus CAN per ciascun dispositivo monitora il bus per verificare che vada nello stato previsto e segnala gli errori del bus all'applicazione se rileva un conflitto in cui qualcun altro sta calpestando i suoi dati.

In pratica è improbabile che questo danneggi le fiches. Tuttavia fornirà picchi di corrente istantanei sulle uscite in cui alto e basso sono in cortocircuito, il che fa cose spiacevoli alle emissioni EMC. I progettisti degli anni '70 e '80 erano molto meno preoccupati per l'EMC, quindi è probabile che molti circuiti siano usciti dalla porta esattamente con questo problema.

Solo un seguito: i bus CAN hanno spesso una resistenza di terminazione per evitare riflessi.Questo di solito è più importante su cavi più lunghi, ma potrebbe essere importante considerarlo per i bus che operano a frequenze HF +.
Le uscite del bus dati non erano di solito open-collector, ma i driver low-side sui dispositivi NMOS erano molto più potenti dei driver high-side.Ciò è stato compensato dal fatto che la tensione di commutazione era più vicina al rail negativo che a quello positivo.
Dave Tweed
2017-06-26 17:05:11 UTC
view on stackexchange narkive permalink

Esistono diversi modi per creare abilitazioni non sovrapposte per dispositivi bus.Forse il più semplice è aggiungere il segnale dell'orologio stesso alle equazioni.Quindi, solo un dispositivo alla volta è abilitato mentre l'orologio è alto e nessun dispositivo è abilitato mentre è basso.(O viceversa se utilizzi il fronte di salita dell'orologio per acquisire i dati.)

Normalmente, la funzione di abilitazione dell'uscita della maggior parte dei dispositivi è abbastanza veloce che "sprecare" metà di ogni ciclo in questo modo non causa problemi di temporizzazione.Ma se lo fa, una soluzione alternativa è modificare il ciclo di lavoro dell'orologio secondo necessità.

La tua risposta implica che abilita quale sovrapposizione di pochi nanosecondi causerà danni.L'ho letto correttamente?
No, non sto dicendo che ci saranno sicuramente danni fisici, ma dato che la situazione è piuttosto facile da evitare in primo luogo, perché mettere lo stress extra sui componenti?
Grazie per averlo chiarito.Sto cercando di tenere sotto controllo il numero di chip / potrei E ciascuno dei segnali di abilitazione con un clock, ma quello sarà un altro chip e ancora più cavi breadboard.
Hai già un segnale comune `/ a` che va a tutte e tre le abilitazioni in uscita - combina semplicemente l'orologio con quello.Negli anni '80, questo tipo di decodifica sarebbe stato eseguito in un PAL, quindi non ci sarebbe stato alcun costo incrementale per l'aggiunta di un altro segnale a ciascuna equazione.
"/ a" è invertita nel secondo e terzo caso dalla porta NOR.Avrei solo bisogno di OR l'orologio con ciascuno dei segnali, in modo che le abilitazioni siano basse quando sia l'orologio che il segnale originale sono bassi.(Ho scritto erroneamente AND prima.)
Negli anni '70 sarebbe stato utilizzato un chip di decodifica dedicato (ad esempio, 74138/139).Questi generalmente hanno molti ingressi di abilitazione extra, uno dei quali sarebbe usato per questo scopo.
L'aggiunta di un segnale di clock alle equazioni impedirà ai dispositivi di guidare il bus nelle prime fasi del ciclo come potrebbero altrimenti.Ciò potrebbe richiedere l'uso di una velocità di clock inferiore o di dispositivi più veloci di quanto sarebbe altrimenti necessario.
@supercat: Questo è esattamente l'argomento del mio secondo paragrafo.Non era abbastanza chiaro?
@DaveTweed: Avevo iniziato a scrivere di più e poi probabilmente l'ho ridotto troppo.Alcuni dispositivi sembrano essere progettati partendo dal presupposto che il bus sarà già libero prima che venga affermato / OE, e alcuni sembrano essere progettati partendo dal presupposto che diventerà libero man mano che si afferma / OE.Il gating / OE con clock può essere un buon approccio per il primo, ma potrebbe rubare troppo del ciclo di clock per il secondo.Un approccio che sembrerebbe migliore sarebbe quello di utilizzare un "bus keeper" e rilasciare / OE prima di ogni fronte di clock (massimizzando così il tempo disponibile ma prevenendo contese) ma non l'ho visto fare.
@supercat: In effetti, molti dispositivi tristate sono progettati deliberatamente in modo che i tempi di disattivazione nel caso peggiore siano più rapidi dei tempi di attivazione nel migliore dei casi, evitando del tutto il problema.Ma l'OP non ha mai indicato di essere andato a quel livello di dettaglio nella sua analisi.Inoltre, di solito la capacità del bus è sufficiente come "custode" per questa situazione;Neanche per questo ho visto un custode attivo usato.
@DaveTweed: Ciò che rende le cose complicate è combinare parti di "vintage" diversi nello stesso dispositivo.Se si dispone di alcuni dispositivi lenti e alcuni dispositivi veloci, potrebbe essere necessario fornire ai dispositivi lenti un intero ciclo ma ritardare / OE per dispositivi veloci.Su una scheda DSP ho avuto problemi con un vecchio dispositivo che era lento da rilasciare ma aveva driver potenti.L'aggiunta di stati di attesa per gli accessi a quel dispositivo non ha aiutato poiché il DSP lo ha mantenuto abilitato fino all'inizio del prossimo accesso.Quello che ho finito per fare è stato scrivere una piccola routine che potesse entrare nella RAM interna del DSP e accedere solo al dispositivo lento ...
... tramite quella routine, assicurando così che il bus esterno sarebbe inattivo nel ciclo successivo all'accesso lento del dispositivo.È stato un po 'fastidioso, ma ha funzionato.
Marcus Müller
2017-06-26 16:16:25 UTC
view on stackexchange narkive permalink

Se avrebbe causato danni, come è stata evitata questa situazione negli anni '70 -'80?

progettazione manuale che ha compensato il ritardo.

Se ciò causerà danni dipende dalla tua tecnologia, quindi non è possibile fornire alcun consiglio generale;tuttavia, affinché un transitorio di 10 ns abbia effetto, il sistema deve avere una larghezza di banda> 100 MHz, quindi è qualcosa che puoi evitare attivamente.

Ci sarà un clock da 1 MHz e utilizza la logica 74HCxxx a 5v.Niente bloccherà il valore del bus durante questi pochi ns.La mia preoccupazione non è l'esistenza di un transiente, ma se un transiente distruggerà i chip consentendo alla corrente di fluire.
Forse potresti limitare la corrente con una piccola resistenza?
supercat
2017-06-26 21:03:06 UTC
view on stackexchange narkive permalink

Se un dispositivo è progettato per emettere dati nel modo più rapido e forte possibile quando viene affermato / OE, la contesa del bus potrebbe provocare correnti di picco sostanziali che possono causare rumori indesiderati sulle linee di alimentazione anche se non causano danni fisici. D'altra parte, un tale dispositivo può essere in grado di guidare il bus in uno stato valido in meno di mezzo ciclo di clock, nel qual caso il gating / OE con il clock può evitare tale contesa. Alcuni altri dispositivi, tuttavia, non sono in grado di guidare il bus così rapidamente e dovrebbero essere più vicini a un ciclo completo per guidare il bus. I dispositivi che guidano il bus più lentamente, tuttavia, sono meno inclini a far passare una corrente eccessiva durante i periodi momentanei di conflitto tra dispositivi.

Una differenza di due nanosecondi nel momento in cui i dispositivi ricevono i segnali di abilitazione non ha la stessa importanza della tempistica con cui i dispositivi stessi rispondono ai segnali di abilitazione. Se un dispositivo è lento a rilasciare il bus dati, potrebbe essere necessario controllare il suo segnale di gating in modo che venga rilasciato in anticipo per garantire che nel momento in cui un altro dispositivo tenta di guidare il bus, il primo dispositivo avrà smesso di guidarlo.

analogsystemsrf
2017-06-26 20:35:47 UTC
view on stackexchange narkive permalink

Ci sono almeno due problemi qui: sbalzi termici e transitori VDD.

Mettiamo alcuni numeri su questo. Si supponga di transistor con un'estensione di silicio di 20 micron per 20 micron e una profondità di 10 micron. Il volume quindi è 20 * 20 * 10, o 4.000 micron cubici. I bipolari della tecnologia più vecchia, con i collettori sotto la regione dell'emettitore di base, hanno approssimativamente queste dimensioni. Il calore specifico del silicio è 1,6 picoJoules / cubicmicron / ° C. Il nostro dispositivo è 4.000 * 1,6 pJ = 6,4 nanoJoules / ° C. Quanto aumento di temperatura possiamo generare, in 10 nanosecondi di picco termico?

Usa 5 volt e usa 100 milliAmps (un picco piuttosto buono, tra 2 transistor del driver bus opposto). La potenza è di 0,5 watt e l'energia è di 0,5 nanoJoules per nanosecondo. In 10 nanosecondi, l'energia è di 5 nanoJoules.

Ora basta dividere: 5nJ / 6,4nJ == aumento di 0,8 ° C. Si presume distribuito uniformemente all'interno del volume 20 * 20 * 10U. Dato che la maggior parte del volume bipolare è il collettore interrato, "uniforme" è un'ipotesi valida. Quindi 1 ° C è la risposta, per conducente di bus. Se 8 driver sono in un unico pacchetto, cambia il numero di 1 ° C? No, perché le fonti di calore sono distribuite in 8 diverse regioni e il verificarsi di un transitorio è un ciclo di lavoro basso.

Passiamo ora alla seconda questione: il VDD che squilla. I primi circuiti integrati per driver bus contenevano 8 circuiti, con un solo GND e un VDD. Il crollo della ferrovia era un grosso problema. Perché?

Supponiamo 10nS GND + induttanza VDD. Supponiamo di caricare 8 carichi, 50pF ciascuno, con Trise di 10ns. O 2 volt / nanosecondo di risposta.

Dato che 1pF a 1v / ns necessita di 1mA, la nostra singola uscita necessita di 100mA. Le otto uscite richiedono 800 mA. Supponiamo che i picchi di carica aumentino da corrente ZERO a 800 mA, nella metà del tempo o 5 ns. Qual è il rimbalzo del binario?

V = L * dI / dT = 10nH * 0,8 amp / 5 ns = 1,6 volt. Quindi GND aumenta di 0,8 V e VDD scende di 0,8 V.

Poiché ho ipotizzato un impulso di corrente triangolare (in aumento e in diminuzione in 5 ns), la velocità di ricarica è inferiore a quella necessaria.Per soddisfare la temporizzazione dell'impulso di carica completa, dobbiamo raddoppiare le correnti di picco e il rimbalzo diventa 1,6 volt sia per GND che per VDD.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...