Are Propeller inputs synchronized? If so, centrally, or cog-by-cog?
Phil Pilgrim (PhiPi)
Posts: 23,514
I don't know if this exact question has ever been answered explicitly, so here goes:
····Are the Propeller's inputs centrally synchronized to the system clock?
····In other words, will two cogs reading the same asychronous input on the
····same system clock edge always see identical logic levels?
In logic design, if an input feeds two or more gates, it needs to be synchronized to a single system clock, so the entire logic array sees the same data. (Synchronization also helps to eliminate metastable states.) The same applies to Propeller inputs in relation to cogs. The answer to this question will determine whether the synchronization is done internally or has to be done explicitly, whether in software or by a counter, which would use up an extra pin.
Thanks,
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
····Are the Propeller's inputs centrally synchronized to the system clock?
····In other words, will two cogs reading the same asychronous input on the
····same system clock edge always see identical logic levels?
In logic design, if an input feeds two or more gates, it needs to be synchronized to a single system clock, so the entire logic array sees the same data. (Synchronization also helps to eliminate metastable states.) The same applies to Propeller inputs in relation to cogs. The answer to this question will determine whether the synchronization is done internally or has to be done explicitly, whether in software or by a counter, which would use up an extra pin.
Thanks,
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
All individual COGS run obviously·on the same system clock. And as I understood it from another recent discussion -·the execution phases in these COGS can be out of sync by any number of system clocks. Each COG samples the INA pins at its own, during the source operand fetch, at the rising of the system clock in that same COG (see the new datasheet 1.1 for a better explanation of the pipelined instruction execution). Assuming a 80MHz sysclock, the execution of the source stage of the instruction (in the pipeline) in different COGS can be offset·in 12.5ns increments, compared to other COGs.
So - one COG might sample one particular input pin at a certain moment in time, another· 12,5ns later, a third 25ns later etc... ASSUMING you have not synced these COGS by waiting on transitions on a certain common pin for those than need to be synced. Or used any other ways to sync them. Additionally HUB accesses and WAITPxx instructions waiting fo other pins might ruin this syncronisation.
Please correct me an also apologize me if I'm wrong. I also try to understand these "hidden" details. This is - as you also have found - not very explicitly documented.
Christian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!
Post Edited (godzich) : 11/18/2008 9:36:39 PM GMT
If I understand your answer correctly, the input structure is more like the one on the left below than the one on the right. Correct?
If so, two cogs reading the same pin on the same system clock edge could conceivably read different values, since the input is not centrally synchronized. The difference could arise from slightly different thresholds for the input registers and/or from clock skew between cogs.
The structure on the right would be more difficult to route, however, since each pin would have to have two traces (sync'd input + output) going to each cog instead of just one. So it's not hard to understand why it wasn't done that way. [noparse][[/noparse]See subsequent post below.]
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 11/18/2008 11:27:01 PM GMT
I think that whats actually going on is that the left structure is used but that there are one or more inverters which buffer the input for distribution across the chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
The circuit on the left side is the better representation of the way the prop reads one input pin. Probably the sysclk goes to ALL flipflops, but they have additionally an enable-input that is used to select at what sysclock edge each sampling flip-flop samples the input pin.
The circuit on the right would not necessarily help, atl east in situations were the two COGs runs with an 25 ns clock skew (or more) between the source fetch execution stages...
If you want two COGs to really sample a common input pin (or a group of pins) simultaneously (at the very same sysclk rising edge), then you must ensure that these COGs run BOTH EXACTLY with the pipeline stages synced. There might be several ways of doing this, but executing a WAITPxx instruction in all COGs to be synced (and monitoring the SAME pin), would bring them into sync. To keep them in sync you should be careful not to ecexute instructions that need other than 4 sysclocks to execute. And independent of this, since your input to the pin to be sampled is probably NOT synded to the sysclk, there is no guaranteed setup and hold times for these input flipflops in paralelle, so even if clocked about almost simultaneously, there is no guarantee that two COGs will see the same locig level at each clock. You could work around this by adding external flipflops, that are fed with the sysclk. The sysclk is not directly available but might be possible to re-aynthesize in a COGs timer, using the PLL and divide the output. The phase relationship between this external sysclk and the actual internal sysclock is not straightforwar to find out.
Again, please remember that I still do assumptions, but think that I'm not too far away from the truth. Would be nice·if someone from Parallax could confirm this for you. Hoping for more such technical information to be added in the upcoming manual version - without delaying its publication - that is [noparse]:)[/noparse]
Christian
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The future does not exist - we must invent it!
Post Edited (godzich) : 11/18/2008 10:22:28 PM GMT
I neglected to consider the ORed outputs, which entails two traces for each pin anyway. So the effect of a pre-sync on routing would be nil.
I agree that differences would be extremely rare. In the worst case, a counter with feedback could be employed to provide an additional level of synchronization on an otherwise unused pin.
Christian,
Yes, I understand about syncing the pipelines. My questions/comments all pertain to the situation where they are synced. Any skews I refer to would be in the sub-5ns range.
-Phil
Addendum: Another way of phrasing my original question would be: "Will two cogs waiting on an input with identical WAITPEQs always restart on the same system clock edge?" This, more than any other syncing issue, may be crucial to the Propeller's success in dealing with high-speed inputs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Post Edited (Phil Pilgrim (PhiPi)) : 11/18/2008 10:25:33 PM GMT
I don't think you can count on that if only because of the propagation time across the chip. It would be rare for a signal to start just before a system clock edge such that the system clock would occur as the signal is propagating across the chip (buffers and all), but it could happen and your code would have to be written to work in that situation.
Yep, I agree — unless there exists a central synchronization stage. In my schematic I showed clocking on the falling system clock edge so as not to introduce a one-clock delay. Chip or Beau could confirm or deny the presence of such a mechanism definitively. But I think it could be inferred by clocking the chip externally at a slow speed and measuring how far in advance of a rising system clock an input must occur to be recognized. That would reveal whether any synchronization is being done. I may try that just out of curiosity. But, based on Paul's surmisal, I really don't expect to find such a mechanism.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!