This should be a real screamer:
http://www.intellasys.net/index.php
24 core processor
24 GIPS (that is Giga instructions/second) peak.
10 MHz to 50 MHz PID loops should be possible.
2 18 bit A/D built in
2 9 bit D/A built in
Low power, low cost.
Control Processor
Hello MSimon,
I had a look at the SEAforth 24A ... nice. But the compiler will be a real work of art ... and programming using a threaded model will be necessary. The Cell processor (PS3 etc) is of a similar pattern.
I was not able to ascertain if it uses a BGA pinout (if so a SMT facility would be needed to assemble boards) ... for the big boys, there's no problem; for the small people SMT assembly lines are priced out of reach. It might be that Intellasys will provide eval kits to let the hoi polloi try them out ... now that would be good.
Regards,
Tony Barry
I had a look at the SEAforth 24A ... nice. But the compiler will be a real work of art ... and programming using a threaded model will be necessary. The Cell processor (PS3 etc) is of a similar pattern.
I was not able to ascertain if it uses a BGA pinout (if so a SMT facility would be needed to assemble boards) ... for the big boys, there's no problem; for the small people SMT assembly lines are priced out of reach. It might be that Intellasys will provide eval kits to let the hoi polloi try them out ... now that would be good.
Regards,
Tony Barry
If it is BGA there are sockets. If it is a flat pack or j lead type it can be hand assembled - if you are careful.
I have hand assembled some very small stuff.
From the description I think it is either an 84 lead or 144 lead package. Just before BGA array size.
I'm trying to get data sheets. And stuff.
BTW the compiler is already available. You can test it out. Also a simulator.
This is strictly a preliminary effort. PC 104 - if it is fast enough is to be preferred.
However, if we need some real horsepower for very fast loops I wanted to be prepared.
Note that you have to define what each core does. The compiler doesn't assign any cores. You have to determine the architecture you want in advance.
I have hand assembled some very small stuff.
From the description I think it is either an 84 lead or 144 lead package. Just before BGA array size.
I'm trying to get data sheets. And stuff.
BTW the compiler is already available. You can test it out. Also a simulator.
This is strictly a preliminary effort. PC 104 - if it is fast enough is to be preferred.
However, if we need some real horsepower for very fast loops I wanted to be prepared.
Note that you have to define what each core does. The compiler doesn't assign any cores. You have to determine the architecture you want in advance.
It is an 81 pin BGA. So we will need a socket.
Or - development boards will be available at the end of 3Q 007.
You know what that means. End of 1Q 008.
Soon enough. It won't be needed until 1Q 009 at the soonest.
I have actually worked with a single core version of this chip so any one who wants help:
Ask Away
Which includes learning the FORTH language.
Simon
Or - development boards will be available at the end of 3Q 007.
You know what that means. End of 1Q 008.
Soon enough. It won't be needed until 1Q 009 at the soonest.
I have actually worked with a single core version of this chip so any one who wants help:
Ask Away
Which includes learning the FORTH language.
Simon
Thanks for the info ... I have not worked with devices that clock at GHz rates. I tend to avoid RF where I can 
and try to keep it well contained.
What application do you see the device as being used for within the polywell project?
I did a little bit with Forth a very long time ago ... as I recall, it was a plugin board for the ISA bus, which gave some ridiculously high instructions/sec ...
Regards,
Tony Barry
and try to keep it well contained. What application do you see the device as being used for within the polywell project?
I did a little bit with Forth a very long time ago ... as I recall, it was a plugin board for the ISA bus, which gave some ridiculously high instructions/sec ...
Regards,
Tony Barry
I can see it controlling the electron gun grids. Realistically running a PID loop at a 1 MHz to 5 MHz range (you have to read the fine print). Still way above the 5 to 10 KHz rate of a PC104. Plus the PC104 is not as deterministic.tonybarry wrote:Thanks for the info ... I have not worked with devices that clock at GHz rates. I tend to avoid RF where I can :) and try to keep it well contained.
What application do you see the device as being used for within the polywell project?
I did a little bit with Forth a very long time ago ... as I recall, it was a plugin board for the ISA bus, which gave some ridiculously high instructions/sec ...
Regards,
Tony Barry
Getting a good feel for what can be done will take a while. The chip has lots of quirks.
I don't think having enough processing power to control the reactor is going to a problem of any significance. Monitoring and controlling complex parameters at high rates isn't exactly mysterious anymore. It is being done as we speak in thousands of different applications.
Focus on the control algorithms--the software. The processing hardware should come off-the-shelf. Otherwise it is wasting money.
Focus on the control algorithms--the software. The processing hardware should come off-the-shelf. Otherwise it is wasting money.
Thoth,
It was exactly the algorithm question that led me to the processor question.
At this point there are a number of independent variables that operate on a number of time scales with one resultant.
The question then becomes how do you get this lash up under control?
The answer is to control each parameter at a different time scale and use feed forward to damp out some of the transients.
A lot more will have to be known about reactor dynamics to get all this running smoothly.
My job (self-assigned) is to anticipate the problems and have solutions in hand when/if they come up.
My other job (self-assigned) is to stamp out ugly programming languages and bloated processors.
Fortunately the two tasks coincide for me in this project.
No doubt if I get to work on this I will be assigned different directives. In the mean time I'm free to go ahead in any direction I see fit.
BTW any questions or inputs on the actual control problems would be appreciated.
It was exactly the algorithm question that led me to the processor question.
At this point there are a number of independent variables that operate on a number of time scales with one resultant.
The question then becomes how do you get this lash up under control?
The answer is to control each parameter at a different time scale and use feed forward to damp out some of the transients.
A lot more will have to be known about reactor dynamics to get all this running smoothly.
My job (self-assigned) is to anticipate the problems and have solutions in hand when/if they come up.
My other job (self-assigned) is to stamp out ugly programming languages and bloated processors.
Fortunately the two tasks coincide for me in this project.
No doubt if I get to work on this I will be assigned different directives. In the mean time I'm free to go ahead in any direction I see fit.
BTW any questions or inputs on the actual control problems would be appreciated.
And as long as I'm on the subject.
"C" is an abomination for real time control.
Stack frame thrashing is a waste.
Limitations on parameter passing are stupid.
Plus it reads ugly. Its pointer notation induces mistakes. You can't write it so it reads more or less like natural language.
Let me tell you of an experience I had with a DoD inspector many years ago who was looking at code for different projects to see how it met DoD standards and to look at maintainability questions.
The inspector said the code from my group was the first time in a number of years he had seen code that was understandable just by reading it. What good is that? It makes maintenance by people not famiiar with the code much easier.
It is the secret of FORTH. You program with words.
Plus the object oriented constructors are much easier to understand than the "C++" abominations.
No casting problems. Bits are bits.
====
Let me add that "C" is not very amenable to mechanization. FORTH is. As the processor we are discussing shows.
If the particular processor we are discussing is not good enough, I can design others in FPGA. Another hobby of mine.
"C" is an abomination for real time control.
Stack frame thrashing is a waste.
Limitations on parameter passing are stupid.
Plus it reads ugly. Its pointer notation induces mistakes. You can't write it so it reads more or less like natural language.
Let me tell you of an experience I had with a DoD inspector many years ago who was looking at code for different projects to see how it met DoD standards and to look at maintainability questions.
The inspector said the code from my group was the first time in a number of years he had seen code that was understandable just by reading it. What good is that? It makes maintenance by people not famiiar with the code much easier.
It is the secret of FORTH. You program with words.
Plus the object oriented constructors are much easier to understand than the "C++" abominations.
No casting problems. Bits are bits.
====
Let me add that "C" is not very amenable to mechanization. FORTH is. As the processor we are discussing shows.
If the particular processor we are discussing is not good enough, I can design others in FPGA. Another hobby of mine.
Now now. Dissing languages are we? Be careful, I can give you run for your money in this subject. Your post almost seems as if begging for a flame. I resists. So far.
Better tell us. What motivates such processing power? And what processes (in detail) do you intend to control and at what timescales ? I like powerful computers as much as anyone *drool* but...
- Indrek
Better tell us. What motivates such processing power? And what processes (in detail) do you intend to control and at what timescales ? I like powerful computers as much as anyone *drool* but...
- Indrek
I like processor/language flame wars as much as any one: flame away.Indrek wrote:Now now. Dissing languages are we? Be careful, I can give you run for your money in this subject. Your post almost seems as if begging for a flame. I resists. So far.
Better tell us. What motivates such processing power? And what processes (in detail) do you intend to control and at what timescales ? I like powerful computers as much as anyone *drool* but...
- Indrek
Not much else to do until the results of the experiment are in. LOL
The need for high speed control may present itself in electron density control. Or POPS power. POPS frequency will be handled by a PLL. Or we may have to use an FLL (some times called the huff and puff system). The reason for using a FLL is that it can operate on very long time scales (seconds) if the oscillator is stable.
So what do we have to control? (MSG = magnetically shielded grid)
POPS Frequency - it must stay matched to actual conditions. Ion velocity (MSG voltage) being the most important variable once reactor fuel and size is determined.
POPS Power - it must not break the electron magnetic confinement.
there may be other restrictions (unknown at this time).
MSG voltage - needs to be kept at the resonance peak of pBj to maximize reaction rates and minimize Bremss. Another PLL operating at a frequency of 1/10th POPS or less might work.
Electron injection - may require POPS frequency modulation and high speed adjustment to maintain well depth at the proper level.
Gas Injection - the reactor volume will hold at least several seconds of fuel. It may only need to be controlled on short time scales and low volumetric rates for test reactors. I calculate (ROM) that about 10 cc per second of Hydrogen will need to be delivered to a working pBj reactor.
A working D-D reactor might require about the same rate.
Go down to 1 watt and you need to deliver 1 E-7 cc/second.
At 1 mw it would be 1 E-10 cc/second.
It would be nice to control gas densities on 100 uSec or less time scales. A residual gas analyzer (RGA) might be helpful in this area. So that gas density and not power out was used to control gas feeds.
Here is a nice explanation of Huff and Puff:
http://hanssummers.com/radio/huffpuff/m ... /index.htm
this link is even better;
http://hanssummers.com/radio/huffpuff/index.htm
*
Control implies diagnostic information. What kinds of sensors do you envision as part of the control loop? I would hope the system is large enough that time scales will be long and control will be easy. Just because we can control things in the gigahertz doesn't mean we should design a power system that requires that kind of control.
In terms of programming, I like C, assembler and VHDL. It depends on what I need to control and how fast the response time of the device in question has to be. And what platform it's on. And how many people are involved.
The whole point of different languages is that they all solve different problems and are optimized for specific applications. LISP is about as horrible as COBOL for any application I've worked on, but they each have their proper place.
I can't stand FORTH myself, but it's certainly a very useful language for control systems.
When I need speed, I use either a DSP and assembler, or an FPGA and VHDL. My philosophy is that you build the hardware to suit the problem. But that's just me.
In terms of programming, I like C, assembler and VHDL. It depends on what I need to control and how fast the response time of the device in question has to be. And what platform it's on. And how many people are involved.
The whole point of different languages is that they all solve different problems and are optimized for specific applications. LISP is about as horrible as COBOL for any application I've worked on, but they each have their proper place.
I can't stand FORTH myself, but it's certainly a very useful language for control systems.
When I need speed, I use either a DSP and assembler, or an FPGA and VHDL. My philosophy is that you build the hardware to suit the problem. But that's just me.
I like assembler too!
The chip I have chosen has as its assembly language FORTH.
I like zero operand processors and Harvard architecture.
Speeds things up a lot compared to stack thrashing in C. Stack thrashing in C is just a killer for real time. It is a built in time waster.
Assembly language is fun! It does not document well.
Most of the FORTH I have ever written is undocumented. Why? The code speaks for itself. AS I said above. I got good marks from the DoD for it.
It does take a different mind set to do FORTH well.
FORTH encourages programming in small fragments (good factoring) the way they teach you "should" program in school. Why aren't most "C" programs well factored? Stack thrashes on context change are expensive. Subroutines in FORTH only cost you a CALL and a RETURN (on some FORTH processors even the return is free).
In C there is a major conflict between good programming style and speed.
========
The most pressing need for speed will be electron density controls. Controlling them on mS time scales may not be fast enough.
Feedback would be gamma ray detector, and residual gas analyzer (RGA) for pBj.
Adding neutrons for D-D. Neutrons may also work for the full scale pBj.
The gamma ray detector might have a pulse height discriminator.
======
I worked on a project that used a FORTH processor. The gentleman who spearheaded the effort left the project and they decided to convert to "C" because good FORTH coders are hard to find.
Totally crippled the processor which was already 10% too slow for the code as written.
A second processor would have been a real help, but the chip designers made no allowance for such a grafting.
The company is no longer in business.
You really have to delve into processor design to see what an elegant solution FORTH is. Generally software guys don't do that and hardware guys don't understand software problems. I was fortunate to get in on microprocessors when an intimate knowledge of both was required.
I can guarantee 5 M PID loops a second. With some fine tuning something like 10 M to 50 M should be possible.
I'm not saying any of this will be necessary. I just want to be ready if it is.
The chip I have chosen has as its assembly language FORTH.
I like zero operand processors and Harvard architecture.
Speeds things up a lot compared to stack thrashing in C. Stack thrashing in C is just a killer for real time. It is a built in time waster.
Assembly language is fun! It does not document well.
Most of the FORTH I have ever written is undocumented. Why? The code speaks for itself. AS I said above. I got good marks from the DoD for it.
It does take a different mind set to do FORTH well.
FORTH encourages programming in small fragments (good factoring) the way they teach you "should" program in school. Why aren't most "C" programs well factored? Stack thrashes on context change are expensive. Subroutines in FORTH only cost you a CALL and a RETURN (on some FORTH processors even the return is free).
In C there is a major conflict between good programming style and speed.
========
The most pressing need for speed will be electron density controls. Controlling them on mS time scales may not be fast enough.
Feedback would be gamma ray detector, and residual gas analyzer (RGA) for pBj.
Adding neutrons for D-D. Neutrons may also work for the full scale pBj.
The gamma ray detector might have a pulse height discriminator.
======
I worked on a project that used a FORTH processor. The gentleman who spearheaded the effort left the project and they decided to convert to "C" because good FORTH coders are hard to find.
Totally crippled the processor which was already 10% too slow for the code as written.
A second processor would have been a real help, but the chip designers made no allowance for such a grafting.
The company is no longer in business.
You really have to delve into processor design to see what an elegant solution FORTH is. Generally software guys don't do that and hardware guys don't understand software problems. I was fortunate to get in on microprocessors when an intimate knowledge of both was required.
I can guarantee 5 M PID loops a second. With some fine tuning something like 10 M to 50 M should be possible.
I'm not saying any of this will be necessary. I just want to be ready if it is.
I don't know if you have looked deeply into SEAforth, but you actually build the processor to solve the problem. However, you build it in software out of a sea of processors. Much the same way as an FPGA is a sea of gates.
If the processors are very fast compared to the system you want to control it makes life very simple.
The PID loop I envision will require at least 3 multipliers. Each will run in parallel to speed up the process. If I need 10 multipliers they are there.
In fact if I used 4 processors for each multiply they could probably be done in 25 "ns" cycles or so. Add another 25 nS to finish the job that gets you up to 20 M PIDs a second. 10 million for sure.
There may be other tricks. Depending.
The most important thing is to keep everything close - processors, sensors, actuators. Radiation flux will be a problem next to the reactor.
If it is the Harris RTX 2000 might be good. It is space qualified and still used by NASA. Or a space/radiation qualified FPGA might be in order.
If the processors are very fast compared to the system you want to control it makes life very simple.
The PID loop I envision will require at least 3 multipliers. Each will run in parallel to speed up the process. If I need 10 multipliers they are there.
In fact if I used 4 processors for each multiply they could probably be done in 25 "ns" cycles or so. Add another 25 nS to finish the job that gets you up to 20 M PIDs a second. 10 million for sure.
There may be other tricks. Depending.
The most important thing is to keep everything close - processors, sensors, actuators. Radiation flux will be a problem next to the reactor.
If it is the Harris RTX 2000 might be good. It is space qualified and still used by NASA. Or a space/radiation qualified FPGA might be in order.
I do asseembler too (mainly Atmel AVR these days). You're right - it's not self documenting, and it lacks some of the refinements of hgher level languages that make coding less buggy (i.e. local vs global variables) ...
But this Forth chip sounds good. I am uncertain about putting it next to the reactor though. This sounds like it's begging for radiation induced errors.
If we must run it nearby, can we put it in a box that will keep the nasties out?
Regards,
Tony Barry
But this Forth chip sounds good. I am uncertain about putting it next to the reactor though. This sounds like it's begging for radiation induced errors.
If we must run it nearby, can we put it in a box that will keep the nasties out?
Regards,
Tony Barry