Saturday, February 20, 2016

OpAmp (virtual) Testing ②

Quick eval. ::
LT1012A
It's either really embarrassing  or super funny that all those macro models use the 1 and the very same input stage (see V4 , oo , vG - values)

it reminds me the university times where 90% of our course copied their essays from higher courser´s -- guess it's a good custom . . . muhahaa

the LT1012 seems to have smth. @ 60kHz ??
LT1122
seems nice ?
LM324.cir
LM324G.asc
. . . it seems that the 2N5087 , 2N5089 are too good to be used here . . .

94.5dB voltage gain @ 1kHz
LM324H.asc
(same as prev.)

79.6dB voltage gain @ 1kHz

perhaps describes the LM324 in certain situations ?
LM324J.asc
(same as pre-prev.)

[Eop]

Friday, February 19, 2016

OpAmp (virtual) Testing LM324 LT1012 LT1122

it looks like the LT1122 goes better for Amplifier-X testing than my prev. preference '1012
and here if why ::
LT1012LT1122





no much difference until here
"we" had to compensate the .CiR model ('s why i preffer the macro 1-s)

! The LT1122 can still handle the mess ?
(supposedly thanks to "fast output settling"? and/or 14x higher band with)

many attempts to reduce output offset (to Zero adj. the Amp.) - or - what was tested ::




the 1-st modification - G ( IS = 3.66mA )

the 2-nd modification - H ( IS= 813µA )

the 3-rd modification - J ( IS = 3.66mA )

onsemi source ( IS = 1.2(3) mA : VS = ±2.5(±15) V : RL = ∞ )

update 2017-09-19
verifying LM324 CLM-s´ variants ....


.... so the operation of G and J ver.-s is somewhat predictable.


[Eop]

Monday, February 15, 2016

((Circus))

This ?? textbook fig. appears to be too common

and misleading

while it's likely used as below


there's no need for comparator per bit if it's (+) INP is connected to somewhere below 1.4V in this example ((this is how you tune such a sh¡t with spice . . . all fun!)) -- shortly put you write your bit by setting global S and Z() while C (EW) E (ER) W (R/) are on their respective LOW level , then enable write by pulling C (of a specific memory cell) to it's HIGH level and after setting time back to LOW -- you read a bit by enabling read (disabling input) by pulling global W HIGH cell specific E HIGH (which requires a 3-rd transistors to be added to both shoulders of this RAM cell (see fig. below) and enabling a level drop dn ((by pulling (((this rebuilt))) E HIGH)) to a global OUTPUT BUS) that sets the MR which in turn is fixed at output register as D0 (for example)



Yes thank you Google's Einsteins for removing my unicode overlines , thank you ((mõned inimesed on ikka sündind idioodid))

 since using PNP read-gate it seems the 3-rd transistors're not required

the plot is basically same than above
-- A , B for monitoring mem-cell's state
-- S , Z set global data
-- SB , ZB , W are respectively D , NOT D , NOT write (they can be global and then we still need a 3-rd tansistors for data read)
-- SB , ZB , E are respectively D , NOT D , NOT read (mem-cell specific)
-- SR , ZR , MR are respectively D , NOT D , D read (all global ((to max number of bits that can be reliably set and read also limited by power consumption (((e.g. the memory block can be suspended to low-power mode - still preserving it's data - while no read write to that area occurs))) )) )


re: about Google's Einsteins -- it appears that when pasting unicode overline to Blogger Editor it shows there - but when you save/publish and then reopen for modification - the unicode overlines won't display in Compose nor HTML view (however they're preserved and after re-save they'll show up in www blog) -- so now i have unicode overlines and CSS ones -- thanks for Google's Einsteins -- who newer take their job seriously (or perhaps someones pet pig programmed the Blogger Editor -- in which case it's to be considered as an achievement !!!)


back to 3+3 transistor (separate RW) RAM


The interesting part of this circus is thus over. It seems the W pin has no much effect (at least with this 2-bit v.) -- it might be reducing errors near max fq. op. . . . perhaps. So the conceptual part is over - the rest is fine tuning and right component + layout selection/dev. . This one is over 1000x slower and inefficient than the commercial FET memories -- the background of this circus is that at the time i attempted to make it run all under 1.2V and it didn't quite work out -- so now "we" used some more realistic voltage levels . . . (end, over & out ×·

[Eop]

Custom 17MHz counter

► revisited some old stuff (BJT-RAM, . . .) that gave a new concept for a TTL counter that required a fast buffer for link up (which i designed) but it appeared to be not fully consistent in a new custom counter . . . so here what "we" came up (put through a fast/minimal testing) ::


the 67MHz inverting buffer


X1 - X6 're the new inverting buffers -- the Y-s 're 7404-s (? @ 37MHz)



the RAM induced concept counter . . . it'll use a lot of power . . .

. . . i guess the LS counters had a frequency lim. @ 6...7MHz the , the 7474 has 25MHz -- so this custom one doesn't quite extend a sh¡t here other than a 2-(now 4-) "inverter" counter design ? (. . . i !guess! the new buffer can be replaced by the 1/6-th of 7404 with minor modifications to this counter circuit - which is a pointless remark - but let's "us" to complete stat.-s as the 3x7400 and 2x7404 (5 IC-s) 'd make 6-bit counter = 3x7474 = 1.5x74193 (← ?? up 2 → 25...32MHz) ? from where i remember "my" 6...7MHz , hm ??? . . . . . . . . . i thought i put a link here for 74193's 30,25,20, or at least 16 MHz scope diagram ► the only thing the Google found was some ancient nasa tech. paper where they used it with 4...5MHz CLK input that is way lower of proposed 25...32MHz . . . whatever)

[Eop]

Thursday, February 11, 2016

found fixed LM324 *component level model bug

i was sampling the VINP incorrect in CLM* dev. module and sure it didn't let the model to be set to make any sense #¤&%!!#!&!%¤/" . . . ok,

-- i especially minimized the (x324x CLM's) offset error but the next test shows it's having the largest one (there might be some known causes to it that i'm not up to check out now . . . ) . . . it also might mean the bias "normalizing" is not what it suppose to in this comparative test (see also: more OpAmp-s compared) ::

 
it's worth to note that although the .CIR models are more simple and (?suppose to be?) faster than the CLM* (.asc subcircuit) -- then my practice shows they actually complicate and/or slow down the simulation?

[Eop]

Wednesday, February 3, 2016

Had 2 modify smth. i call XC trigger

the test (Update @ MMXVI-02-11 to compare with TTL (SN74xx))

the DTL here is other than in prev. post
X-C 3-ger v. P counter (TTL)
the latches tested
X-C 3-ger (TTL)

L→R , U→D -- pulse-counter , JK-trigger , D-trigger , XC-trigger <•> the pulse-counter uses the pulse-RS-trigger which locks it´s INP and OUTP during transition <•> the XC-trigger uses an adittional state buffer to gain better speed
. . . it seems so far the XC-trigger performs the best of it's kind , if it's implemented correct ??

about Blogger editor :: using the <dir> tag blunts the editor (in a Compose view) -- it can´t add lines [Shift]+[Enter] correctly -- nor to style text e.g. [Ctrl]-[B] has no effect inside <dir> in Compose view

[Eop]