Whither the 100mHz SX?
CounterRotatingProps
Posts: 1,132
Dear Parallax:
It's not difficult to image that the 100mHz was·dropped when the product line was·taken over from Scenix.
Yet the·dies·are still around?
Hypothetically, at least, could the SX100 be made again?
Just curious (and hungry for speed), thanks
Howard in Fla
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Post Edited (CounterRotatingProps) : 8/22/2008 8:04:46 PM GMT
It's not difficult to image that the 100mHz was·dropped when the product line was·taken over from Scenix.
Yet the·dies·are still around?
Hypothetically, at least, could the SX100 be made again?
Just curious (and hungry for speed), thanks
Howard in Fla
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Post Edited (CounterRotatingProps) : 8/22/2008 8:04:46 PM GMT
Comments
I believe there were no special chips made... just testing of batches, and some were better than others, and those could be rated as such. Probably most current production will hit 100 MHz, but will be quite fussy about voltge and layout.
I have run standard chips at well over 100 actually, but not recently. I can have a go in a few days to see what the current performance is.
Cheers,
Peter (pjv)
Peter is correct - there are two production wafers for the SX (48/52 and the 20/28) and there were no unique wafers made for higher speed operation. What Scenix did, however, was test specific packaged die at 75 and 100 MHz. My understanding is that some sections of a wafer are routinely of higher quality and that those die were tested and rated at higher speed on the packaging company's machines. So, you could simply run these at 75 MHz without much issue and perhaps even 100 MHz if you want to.
What you can count on with the SX line is consistency in production, longevity in supply, and good support from Parallax with nice tools, compilers and tutorials.
Ken Gracey
Parallax, Inc.
Thanks much for bringing me up to speed, so to speak [noparse]:)[/noparse]
pjv> I can have a go in a few days to see what the current performance is.
Great! And - if it's not too much to ask - it would be helpful to learn how you clock them, as I'd probably get the components and layout wrong the first go round!
How do you actually test the performance; do you have a canned routine?
KG> What you can count on with the SX line is consistency in production, longevity in supply, and good support from Parallax with nice tools, compilers and tutorials
Yes! In the last months, I have reviewed many flavors of MC's --- there are indeed well founded reasons why I keep coming back here, echoing what others have said in recent threads.
This is probably pushing the good support threshold: is there any possibility that the QA routines you all use to exercise the chips could be published? As the SX's are very reliable, releasing these test routines shouldn't have adverse consequences for Parallax, I think. Even if a few chips failed, they are so inexpensive, that the failure would be financially moot for the user. Yet the feedback you'd have could be valuable, if a batch turned out to have issues. Also, releasing the QA test bed code would have a some educational benefit for users. We'd get to see code for basically ALL of the significant functions of the chip - assuming it's tested that way. Or, if it's only time/temp/voltage sensitive sections of the chip that really need to be checked, we'd see what area's to watch out for when we push the speed up. Then there's the human error factor: If my code fails, and I'm convinced that the routines are flawless :-P - then it must be the 'darned' chip failing. Roll in the QA test code for a quick, and likely humbling, reality check.
* Thanks * again - especially for your time and attention,
cheers,
Howard in Florida ~~
~~~ ... with my CPU up on blocks in case the water comes in ... ~~~
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
The current batch of SX48's on PROTO 48 boards run happily at 104 MHz, clocked with the SX-Key.
At that speed their temperature climbs quickly to over 120C
Unfortunately I don't have the time right now to do more extensive testing.
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log
Do any of you kind folks happen to know the Parallax part number for the 100 mHz oscillator/resonator Parallax (used to?) sell ?
I searched all over the store with no luck... maybe they're not carrying it anymore?
Darn ... was in the middle of doing an order!
thanks,
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
As to a heatsink, I've used two methods: 1) bond an aluminum finned heatsink to the chip with J-B Weld (metal-filled epoxy), and 2) a product from Bergquist called "Gap Pad", sandwiched between the SX and a larger sheet of aluminum.
-Phil
Indeed, at that speed without a heat sink, I figured the SX could double as a mini toaster!
Here's another heat sink trick·- when you're in a pinch and have no sink around.
For TO-3 packaging, for example, cut thin slices of thin aluminum from cookie can lids (or whatever).
Stack them together in a sandwich, holding with a vise grip or vise, drill a hole same size as that in the TO-3 case.
Take the stack, goop on some compound and pop-rivet to the TO-3 case.
Spread the top of the stack apart, like the fronds of a palm leaf:
·[url=]\\||//[/url]
·· \|/
·· |||
··· |
Mount the case as normal - takes a bit of real estate above the case, but works amazingly well.
Your epoxy idea is cool (pun intended
fins:· |||___|||
····· ···· ____······ <- epoxy and gap pads.
SX:······/////
Keep it cool!
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Post Edited (CounterRotatingProps) : 5/17/2009 8:01:33 PM GMT
going to try the 75mHz TTL osc. Parallax offers first
p#: 252-00005
then try the faster osc. but I'm not sure how to select the right one ... a few NOOB questions here:
Did look through a number of Digikey possibilities - how much do the uA and the capacitance ratings matter?
As long as it can drive the SX with room to spare, that's OK, right?
The capacitance affects the frequence stability, I assume, but I'm not sure what the match-up tolerences can be... any suggestions?
(The clock won't be used for timing-critical stuff... just want it to go really fast [noparse]:)[/noparse]
thanks for your assistance!
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Just curious - what project are you doing that needs a 100 MHz SX chip?
Thanks,
PeterM
I'm experimenting with the limits of my sanity. [noparse]:)[/noparse])
seriously though, am trying to understand just what the SX can do at this level sustained over long periods. Have several projects that could use it to control other controllers and analog switches - for instrument control and higher speed data gathering. I know there are other options, but the SX is so much easier for me to code (thanks to the good SX/B folks!) that I'm finding more and more generic uses for it.
PJV mentions above (8/08) that batches have worked at 104 MHz --- it seems to me an SX at that speed starts to be in the realm of mc's that normally run that fast and up, but are harder to code (for me at least) .
I'd like to know how well it can bit-bang, do ISR's, and run modest supervisory code all at once at the 75 - 110 MHz range ... in otherwords, what can I throw at it before it starts to loose it's marbles? I think it could do FFT on some data that I have (it's low bandwidth) ... that code is just a big fast loop that crunches incoming samples through a transform and out, looking for a "hit". DSP chips are overkill for this. (Yes, a propeller might be a better option.) Other than for setup, I can't have a PC connected to this thing run/monitor this low-level stuff.
Someone here (don't have the link handy) did a Propeller-like setup using SX's - one of the things I'd like to try for the instrument control above is using a 75-100 mHz'er to control and sample other SX's running at more sane speeds. A 'round robbin' if you will. When a data hit happens, it needs to toggle some analog switches and a few bus controllers fast to sync without loosing a beat.
There's probably a more eloquent way to do these things, but I like the brute force method - more hardware, less code. Sorry if this sounds vague - I'm not intentionally keeping it secret, just takes too long to explain... I will be posting my test results and some of the stuff we come up with.
Do you think I'm asking for stability problems at this upper limit?
thanks for your interest!
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Have at it!
I think SX's are great..... you absolutely can squeeze a lot out of a little.
As far as multiple processors are concerned, I currently have a project running (actually well over 5 years now) in Taiwan where over 200 SXes are in lock-step with each other within one instruction at 50 Mhz. So what you are trying to do is certainly possible.
Insanity? BAH! Just dream as wild as you can, then just go do it!..... it's all possible (except for that which isn't)
Cheers,
Peter (pjv)
> 200 SXes are in lock-step with each other within one instruction at 50 Mhz.
Interesting. Well, if you have 200@50, then I can certainly do 16 or 32 @100 !
At the higher speed (and properly cooled of course), do you think the chip might start to exhibit internal timing problems?
thanks for the reply,
cheers,
Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
Okay, you big tease, what in the world are those 200 SX's controlling? [noparse];)[/noparse] I was happy to get several lighting controllers working happily together on an RS-485 buss, but none of the processors are in "lock step" with each other.
Whadda you bet he says, "each one controls 200 more!"
<rimshot>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Buzz Whirr Click Repeat
So 100+mhz with a heatsink shouldn't be an issue...
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Now I'm really wondering how far the SX speedometer goes before it pegs, and the needle bends...
This is a tad silly (cost wise), but what could it really do if it had a peltier on top? Silly because obviously there are other MC's in the MHz range running at low power.
--- this is kind of like making a VW bus drive at 120 MHP with a full load [noparse]:)[/noparse])
Still, it never hurts to know the limits of anything you're using.
What's the farthest you've pushed an SX?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
I have experienced clocking at least one of them at 110 MHz, but they are very fussy about the shape and amplitude of the clock and the supply voltage. Certainly not reliable. And at that most peter out before that..... 105 seems to be the limit. This is externally clocked. What it can do with its own oscillator I have not tried.... to tough (impossible?) to get fundamental frequency elements at those speeds. If I recall correctly, there are some SAW resonators available at 70+ MHz, but can not remember seeing any at 80.
Cheers,
Peter (pjv)
The sytem with all the SXes is a water distribution control system in Taiwan, distributed over one central and 7 regional sites running on Solaris on SUN Sparc stations. Over the years our folks have written well over a million lines of C,/C+ and assembler code for our SCADA system..... about 200 man years by now. And that is not the bloat-ware that gets generated by the likes of Windows environments of today; each line was hand-crfted so to speak.
The SXes run about 100 displays in a mimic panel at the central, and are driven from interfaces connected to the Sparc. The rest of the SXes are operating in a high speed data collection bus, and those each talk at 10 Mbits/second to other SXes lower down the chain, and are also synced to lock-step.
Pretty amazing those small chips. At 50 MHz, they can work quite a bit of magic!
Cheers,
Peter (pjv)
Seriously, that is an impressive-sounding project!
-Phil
you know, I never once clicked on that little "Clock" icon in the IDE --- AND I skipped over the section in the manual about it.
DOH !
So here's the dummy question for the day:
Does the clock slider, or manual entry box for speed, actually OVERRIDE what's in the DEVICE and/or FREQ directives in the source? (I'm using an SX-Key.)
I've been hacking on this a while, but the IDE/Assembler is telling me I'm feeding it contradictory info --- and when I don't change the source, and just bump the slider up to 100 MHz (GO BABY GO!) it doesn't seem to change speed.
I can edit the source - and the speed that way - just as you'd expect. Or leave stuff out of the source so that it defaults as it should to 50MHz.
But my Gas Pedal Clock Slider No Worky.
What am I doing wrong?
thanks a 100 Meg for the help
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
When you select "clock" under the "RUN" tab, or the Clockface icon, the SX-Key provides the system clock, and both the slider and textbox are active. You cannot have an other oscillator or resonator installed wile doing this.
Cheers,
Peter (pjv)
right, I always make sure the osc/resonator is pulled before the key goes on...
but it still is not changing speed when I move the slider --- should this work?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
It won't change the speed in the debugger, only when running the program in standalone mode but with the SX-Key providing the clock. In other words, you have to program using Run->Program, not Run->Debug, then you have to open the clock dialog (make sure the "On" checkbox is checked), at which point you should be able to change clock speed to your heart's content.
Thanks,
PeterM
Everything's got its oddities, eh? Didn't realize that I couldn't debug and change the speed too. I'll give that a try.
cheers,
Howard
my SX @ 110MHz:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No matter how much you push the envelope, it'll still be stationery.
Post Edited (CounterRotatingProps) : 6/2/2009 6:21:35 PM GMT
I'm new to sxb.
I'm working on an interface to my pc now, but chains
Peter Could you or some one give me a good link to info on "locking-step"
Thanks,
5ms
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?
Well, there are numerous ways to tackle lock-step operation, and the approach I used was to permit short bursts of 10 Mb/s data transfer between these devices.
As I typically run my SX's at 50 Mhz, (don't like external oscillators, and faster resonators are not in my parts bin) this implies one data bit per 5 clock cycles. Experience has tought me that even by interleaving code, 5 per bit is about the practical limit. So the data format can be whatever suits the application... I chose something similar to standard asynchronous 8 bit communication but without the standard start bit. I presumed that if the processors were all in lock-step, there was no need to search for a start bit as we already would know when the data would be coming, and we could just "blindly" pull in the databits.
Here is what I did, and it works great..... but before others take issue with my approach, let me state there are numerous ways, and depending on your application, my method may not be optimal.
As most folks know, I'm a very strong proponent of real time operating system for the SX, and like to have minimum code in the interrupt. Typically only set a flag, but in this case we will need some more. All units run under interrupt control with a·1 uSec tick, and all timed events are driven from that tick. Choose one SX to be the 'Master', and slave all others to that.
So what the trick is here, is to synchronize the processors to the Master, and to keep them in sync, and derive all data communication timing, and for that matter all other timing, relative to the syncing event. This kind of makes the sync process (a Sync Pulse really) a 'super start bit'. So how do you do that ? very simple really. Let the Master issue a Sync Pulse at a repetition rate sufficiently often so that the clock on each Slave does not drift more than a fraction of one clock before the next Sync will arrive. Usually this can be 100 or 200 clocks with resonators; with crystals it can be much longer. So pick 100 clocks... a 2 uSec Sync rate at 50 MHz.
Now, for top performance what is critical here is for the Slaves to always catch the leading (or trailing) edge of the Master's Sync pulse. This must be done by sampling the Sync line with 3 consecutive INSTRUCTIONS that each capture the level of the line so that those can be interpreted as: 000 for 'early'; 001 for 'leading'; 011 for 'trailing'; and 111 for 'late'. Sync exists when the state is either leading or trailing... an uncertainty of one instruction. All states other than 'leading' and 'trailing' are deemed a loss of sync and are ignored.
If the Sync bit is connected to an end bit of an input port, say RA.0, then the three consecutive instructions that will capture the edge with 1 instruction resolution could be:
mov w, >> RA the rotate pulls bit0 into the carry
mov w, RA the move pulls bit0 into w
snb RA.0 the skip tests bit0 for its level and the instruction following could be a setbit
Once the three consecutive samples are captured, one would effectively 'build' the 3 bit state, and decisions can be made what to do next based on the results.
On a 'no sync' early or late condition, do nothing and allow the slave to stay in a 'hunt' mode and drift in time relative to the Master.... the difference in clock speeds will determine how long before the next sync pulse is encountered.
On a leading (001) condition, adjust the interrupt return value for retiw such that the next interrupt (hence the next set of 3 samples) occurs 1 cycle later. That would then cause the next samples to be 011.
On a trailing (011) condition, adust the interrupt return value such that the next 3 samples occur 1 cycle earlier; thus expecting 001
The Slave will now continually bounce back and forth between these two states, and is now considered to be in 'LOCK', all with just this tiny bit of overhead of sampling and determining the correction.
What you now do with the Slaves in their free time is up to you, but you can be assured that all synced Slaves will be locked to the leading edge of the Master's sync pulse, +/- 1 cycle.
As a further thought about the 3 consecutive samples, I have NOT tried but expect it would work to have the right hand 3 bits of the port configured as out, out, in, and simply do 3 consecutive left shifts to capture the 3 levels of bit0.
I hope this gives you some insight.... there is a lot more to what my needs were, but this will get you going.
Have fun.
PostEdit.... for convenience·initially choose·the interrupt rate to be the same as the 2 usec sync rate. This can be altered later when your application gets specified.
Cheers,
Peter (pjv)
Post Edited (pjv) : 6/13/2009 5:48:53 PM GMT
thanks for the detailed description. As soon as I get my next Propeller board, I'm going to try your technique using it as the master driving several SX slaves. Still not clear on the "interrupt rate to be the same as the 2usec rate", but will likely understand it once the breadboard's loaded and coded.
On a tangent - have you (or anyone) tried driving the slave's CLOCK/OSC input directly with a faster sync pulse (acting like the osc/resonator) to make it truely synchronous? (I'm just speculating --- don't know if that's even a practical method, or what electrical interface would be needed.)
thanks again,
-Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Got Electrons?