> On 23 Mar 2015, at 12:00 pm, Roland King <r...@rols.org> wrote: > > []
> When you have reached the state that there are no more flags set and no more > changes to propagate, and so the ‘root’ flag is unset, what apart from a user > action would cause changes to start again? There are periodic devices such as clock generators that will flip a state automatically. These vary in time but worst-case would likely be "every cycle". > If nothing, then you stop running at that point until there’s a user action, > and then run until your model says it has no more changes. ie you just run > until everything says it has nothing left to do or you’ve done an entire > cycle through without anything updating and then you stop. Right, that's close to what I have, except that I don't actually stop, I just spin doing nothing (though at present within a timer callback). This is fairly readily changed to experiment with alternative appoaches. But what actual form would a task take that said "loop as many times as necessary until there's no more to do, then finish"? Such as task would need to be created and scheduled on any user input or other automatic change. Problem right now is that the need to evaluate a change arises from within the data model itself - if it's never run, it will never see that change and so will never run... chicken-and-egg. That's why polling works, but I do recognise that's potentially a bad idea. Threaded, it's not too bad, I can use a lock to sleep until the thread is woken by user input on the main thread, but if I run the whole lot on the main thread, I'm not sure how to achieve the equivalent behaviour. I definitely don't want to lock the main thread. > If a component may need many cycles to process a single change in its input > then you probably need two notions, one is ‘my current output value’ and the > other is ‘do I need another cycle’, or ‘please give me another cycle in x > nanoseconds' for each component, you then run the simulation at the time the > first component says it needs something, until everything says it’s complete, > and then you stop. A simulation cycle for a group of devices can't know how many cycles it will need before the state settles - it entirely depends on the circuit built. It may never settle in some cases - a ring oscillator will constantly flip back and forth. Such loops are perfectly allowable in my simulation, but of course they end up cycling endlessly. Each individual device though does evaluate within a singe cycle entirely deterministically - if a state change feeds back to a further input change on that same device, it'll simply wait until a later simulation cycle to deal with it. The timing of that subsequent cycle is handled only at the root level - each individual device doesn't attempt to pass a timing value for its propagation delay - all devices effectively have a fixed delay which is equal to one cycle of the simulation (though it is complicated by the fact that a single "device" may be a complete subsystem with many devices each having their own delay). While that's a huge simplification on what happens in real life circuits, for the type of simulation I want it's perfectly adequate. I'm after functional correctness rather than timing correctness, though the existence of delays is necessary for functional correctness and they do show up in timing analysis (in other words, the delays have to be there, but they don't have to have accurate timing). Just to be clear - I HAVE functional correctness, I just want to make sure it a) plays nice with the OS and b) has high performance. > I assume by the way that none of the available libraries for circuit > simulation do what you want. There’s quite a few of them out there, SPICE and > Tina come to mind but every time I’ve looked I’ve found quite a few. I was interested in the challenge of how to make a decent implementation myself without just buying in that code. SPICE simulates (I believe) down to the actual analogue level of charge-transfer and so forth which is huge overkill for my needs (and likely to be slow). I only need functional simulation to the logic level, so a cycle-based simulator rather than a physics-based one is fine. I did look at a few other implementations but none were actually very good, either disallowing arbitrary feedback loops, or else handling them wrongly, e.g. by detecting an infinite loop after the fact and forcing it to break, rather than accepting that feedback is necessary in real circuits and designing that in. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
