## Re: [Ktechlab-devel] Elements

 Re: [Ktechlab-devel] Elements From: P Zoltan - 2010-04-01 08:32:53 ``` A quick reply to the last part: On Thu, 01 Apr 2010 07:01:05 +0200, Alan Grimes wrote: > > Another important consideration regarding that class is the > implementation of the very important tri-state logic... In my opinion, the tri-state logic outputs could be modeled in a very similar way to the normal logic outputs, but with a variable (low or very large) output resistance. The simulator should be able to determine if the logic configuration is correct (one output driving more inputs), or not (more outputs connected). In the case of correct configuration, the simulation would be done in digital domain; if it's not, the output impedance of the logic should be considered, and the node should be an analogic one. In the case of tri-state logic, if we want to simulate the circuit in a physically accurate way, the nodes where tri-state logic is corrected, should be always analog. A faster method would be to test for each node if the logic outputs connected to it have the "correct" configuration (one low impedance and all the other are high), and if that's the case, threat the node as it would be digital. This might cause discontinuities in the voltage on the node (in real world thing like that don't happen). What do you think? ```

 [Ktechlab-devel] Elements From: Alan Grimes - 2010-04-01 05:02:26 ```The git fanatic threatened to ask a question about the relationship between components and elements the other day but didn't follow through. I'll go ahead and answer anyway. I've learned a great deal about elements during my time trying to get various features of ktechlab to work in a more elegant and efficient way. The existing elements can be defined as "Anything that is required to simulate an analog component". When digital circuits must directly drive/be driven by analog circuits, logicIns and logicOuts are used. The existing component classes that simulate things have two basic types, Switches which, as they are now, change the topology of the circuit. and logic elements, which implement a logical operation directly. (as it is not practical to do so in the analog simulation.) There are probably others which I have forgotten. -- haven't used the program in a while. What I've learned is that elements should only be irreducible units of electronics. (see wikipedia entry on circuit elements to which I contributed...) There are some other useful abstract circuit elements that might also be implemented. A new layer of abstraction should be introduced between components and elements called "component model" or something. I don't wish to specify anything about how this should be implemented at this time. What it would do is compose physically realistic models from the abstract elements and, possibly some secret sauce. In all cases complex components will be modeled as their simplified equivalent circuit even if a more direct solution is known. This is because the abstract models often only cover the area of nominal device operation and it is important to have a model that contains the information required to be reasonably accurate even out of that range. This approach should help solve the glitches I'm currently seeing and remove some of the problems seen in the current logic-out implementation. (which is only somewhat less wrong than the earlier version.).. Another important consideration regarding that class is the implementation of the very important tri-state logic... -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. ```
 Re: [Ktechlab-devel] Elements From: P Zoltan - 2010-04-01 08:32:53 ``` A quick reply to the last part: On Thu, 01 Apr 2010 07:01:05 +0200, Alan Grimes wrote: > > Another important consideration regarding that class is the > implementation of the very important tri-state logic... In my opinion, the tri-state logic outputs could be modeled in a very similar way to the normal logic outputs, but with a variable (low or very large) output resistance. The simulator should be able to determine if the logic configuration is correct (one output driving more inputs), or not (more outputs connected). In the case of correct configuration, the simulation would be done in digital domain; if it's not, the output impedance of the logic should be considered, and the node should be an analogic one. In the case of tri-state logic, if we want to simulate the circuit in a physically accurate way, the nodes where tri-state logic is corrected, should be always analog. A faster method would be to test for each node if the logic outputs connected to it have the "correct" configuration (one low impedance and all the other are high), and if that's the case, threat the node as it would be digital. This might cause discontinuities in the voltage on the node (in real world thing like that don't happen). What do you think? ```