Control Processor

[MSimon]

ryip,

Yeah, might have to use analog. In that case I'd use digital to set parameters. If feasible.

Or it may be soldering iron and tweezers time.

I have done a lot of Phase Locked Loop work so frequency control is no problem. I'd definitely do POPS with a PLL. Even if frequencies go up to 100 MHz for POPS, amplitude control should be in the less than 10 MHz range.

BTW RF stuff has advanced amazingly in the last few years. Just about any component you could want is off the shelf.

[ryip]

It's still unclear to me exactly what all the control loops will be.

It'd be useful to enumerate them and get some idea of the requirements for each.

Until we know more about that, it's hard to discuss what we'll need to implement. Still, it's fun to speculate.

-Rae.

[MSimon]

Primary loops:

1. POPS frequency (PLL frequency control, PID amplitude - up to 10 MHz)

2. MSG voltage ( update rate of 30 KHz or less )

3. Electron current (could be POPS controlled - or maybe an arbitrary waveform generator to modulate electron density in conjunction with POPS - up to 500 MHz with arb)

4. Fuel Flow (two integrated loops for dual species fuels - update of 30 KHz or less)

5. Turbo pump control (update rate ~1 KHz)

Coolant flow (for the higher power versions) can be regulated by by looking at the delta T.

There will be other minor controls such as electron gun filament temperature.

And any thing else that might be desirable.

I ran a lot of this down at IEC Fusion Technology. You might want to check there in case I missed anything.

[StevenK]

I think that first of all matters the software that will be in control.
i would sugggest the use of a Real Time Operating System (RTOS) http://en.wikipedia.org/wiki/Real-time_operating_system , so that there should be a guaranteed response time for sprecific events.

Then, having select the appropriate RTOS (and suggested guidelines, although a bit old, could be found here: http://www.rtcmagazine.com/home/article.php?id=100154 ), we will only have to select hardware that is compatible with the specific RTOS - and processing power is not a problem anymore.

By the way, there is considerable movement behind Linux with patches for RTOS http://www.linuxdevices.com/articles/AT8073314981.html , as well as proprietary RTOS based on Linux http://www.lynuxworks.com/rtos/rtos-178.php . This has the advantage of very low cost development environments (based on open source tools), as well as a very large programmer base (based on open source developers), easily reached through the web. Moreover, if the control software is based on open source (or is open source itself), there would be little additional software costs for every implementation.

StevenK

[MSimon]

I think that first of all matters the software that will be in control.
i would sugggest the use of a Real Time Operating System (RTOS) http://en.wikipedia.org/wiki/Real-time_operating_system , so that there should be a guaranteed response time for sprecific events.

Then, having select the appropriate RTOS (and suggested guidelines, although a bit old, could be found here: http://www.rtcmagazine.com/home/article.php?id=100154 ), we will only have to select hardware that is compatible with the specific RTOS - and processing power is not a problem anymore.

By the way, there is considerable movement behind Linux with patches for RTOS http://www.linuxdevices.com/articles/AT8073314981.html , as well as proprietary RTOS based on Linux http://www.lynuxworks.com/rtos/rtos-178.php . This has the advantage of very low cost development environments (based on open source tools), as well as a very large programmer base (based on open source developers), easily reached through the web. Moreover, if the control software is based on open source (or is open source itself), there would be little additional software costs for every implementation.

StevenK

I hate anything that uses C for real time. If you write your software properly (lots of sub-routines) it spends significant time doing stack thrashes. If you don't write it properly (the usual way it is done with C to get speed - debugging is a pain).

I'm kind of old fashioned but if the system is small and the hardware not too complicated I like to roll my own RTOS to get everything optimized.

For things that need a video, and hard drive etc. I like DOS or ROMDOS. It is stable. Simple. Plus you can turn the DOS interrupts off when you have to fly. Windoze is OK for Ethernet Data Collection and Master Control (run/stop).

Did I mention that I LOVE FORTH for bringing up cold iron and debugging hardware? Sun likes it a lot too!

And that little FORTH chip? 24 - 1 GHz (peak) IPS processors. Some of the pins have their own processors assigned and it is all designed for asynchronous operation - i.e. as fast as the actual silicon will run. No worries about overclocking. There is no clock. You can synchronize with other processors and outside events as required.

It is one slick little bugger.

In volume it is expected to cost a couple of bucks. Compare that to Intel or AMD. Peak power at full zip - under a watt. Cooling if required will be minimal. Compare that with the Intel/AMD fan kluges power management schemes etc. Plus the SEAforth chip automatically turns off processors if they are waiting for inputs (hardware/software).

We may not need it, but I sure like the idea of a 24 GHz multi-processor that goes down to under 1 mW when all the processors are idle and up to 1 W when they are all running at full clip. They come in a 81 pin BGA and are tiny. You can fit them in where needed.

In the long run 'C' is a dead end. It was a stupid idea when invented. It is even stupider now.

[MSimon]

I can teach FORTH in a couple of hours. Proficiency in a week. Expert in a year.

I don't give a dam n about installed programmer base.

The very idea is stupid and is holding back improvements in hardware/software.

Plus: I defy you to completely simulate the real time operation of the latest AMD/Intel kluges. No way to test interactions of the hardware/software. With the FORTH chips: no problem. It is because they are butt simple.

Don't even get me started on branch predictions and pipeline thrashes. Cache hits. And all that stupid stuff required to make stupid ideas function on even a minimal basis.

What happens when your AMD gets too hot and you require a burst of sustained speed? Crash. I don't want no darn crashes in my 1 GW power plants. I don't want high speed maneuvers in my destroyers crippled by overheating control chips.

Doing it the way we have always done it because we can get pre-qualified labor is brain dead.

Doing it the way we have always done it because we can get free software is brain dead.

I hate brain dead. With a FOOKIN passion.

Let me just say this: most of the hardware/software in use today spends most of its time doing totally useless crap. TOTALLY USELESS.

[Nanos]

FORTH also gets my vote.

Though I've been a Z80 and 68000 assembler man in the past, I too am not a great fan of overcomplication.

[Indrek]

This is not really on topic but. MSimon, what is this "C" stack thrashing you keep ranting about and how come forth does not suffer from it?

I've worked with a CPU that had no cache and executed code off a ROM chip. It was dead slow. Caches, pipelines, branch predictions, etc. All of that "crap" does not exist to make computers slow but actually to make them faster - it is not a requirement to have them. And we have them because our resources are limited, not because we like complicated systems. If you say your forth chips don't have them then I can't see how they are not dead slow. They may be simple (which can be a good thing) but also dead slow.

All in all your rants mostly don't make any sense to me. Except I also hate brain dead with that f-word passion

I don't really have any experience with forth but from a distance it looks like some strange cross of lisp and basic.

- Indrek

[MSimon]

This is not really on topic but. MSimon, what is this "C" stack thrashing you keep ranting about and how come forth does not suffer from it?

I've worked with a CPU that had no cache and executed code off a ROM chip. It was dead slow. Caches, pipelines, branch predictions, etc. All of that "crap" does not exist to make computers slow but actually to make them faster - it is not a requirement to have them. And we have them because our resources are limited, not because we like complicated systems. If you say your forth chips don't have them then I can't see how they are not dead slow. They may be simple (which can be a good thing) but also dead slow.

All in all your rants mostly don't make any sense to me. Except I also hate brain dead with that f-word passion ;)

I don't really have any experience with forth but from a distance it looks like some strange cross of lisp and basic.

- Indrek

C has a stack where it keeps input parameters the address of the calling routine and the one allowed output parameter ( if you want more output parameters you need temporary or permanent named variables which consume more stack space for the address.

Every time you make use a new subroutine you have to build a new stack frame.

Forth eliminates all those problems by being a two stack machine. One for data and one for return addresses. The data is always where you need it - on top pf the stack. So you have what is called a zero operand machine. You don't have to tell the processor (except occasionally for permanent variables or constants) where to find the data.

You are correct about its written structure - it is a lot like a cross between Lisp and Basic. In fact Lisp maps very well into FORTH.

If that is not clear ask more questions.

I'll also have more in a bit. I'm in the middle of a project.

[MSimon]

Because the FORTH chip has a pipeline only one deep (or zero depending on the instruction mix) you do not need all the pipelines pipeline predictors etc.

[pstudier]

I have programmed in many languages including assembler and FORTH. FORTH code is difficult to read. For example, all the arithmetic expressions are in reverse polish notation. It lends itself well to writing unreadable code.

Any decent Real Time Operating System for an embedded system should be fast enough.

[MSimon]

I have programmed in many languages including assembler and FORTH. FORTH code is difficult to read. For example, all the arithmetic expressions are in reverse polish notation. It lends itself well to writing unreadable code.

Any decent Real Time Operating System for an embedded system should be fast enough.

Obviously you are not a HP calculator fan.

I have had a government inspector who audits 100 or more software programs a year tell me that the code I wrote in FORTH was the most readable he read in a couple of years. in any language.

I wrote it so it reads like English. You can do it if you are sufficiently disciplined. If not, I don't want you on my code writing team. In any language.

As to any RTOS being fast enough. Depends on how fast. If you want mS response times, yeah. I'm thinking of PID loops with 50 to 100nS response times to control electron injection and POPS modulation. Whole 'nother kettle of fish. With some fine tuning I think I could get it down to 10 nS to 20 nS response times.

Know any RTOS that runs on a $2 processor that consumes under 1 W at full clip that can do that? I'll even let you call out the DSP of your choice. I'll even let you give up power or $$.

BTW reverse Polish is the natural order of operands inside the processor.

The processor doesn't do 2 + 2. It does 2 2 +. Because, hardware can't add two numbers until it knows what (where) they are. The more you can think like a processor the easier it is to optimize the code.

Separating data and return stacks inherently gives you a Harvard architecture. Also the zero operand nature of the beast means you can pack more instructions in a LIW. Fewer, external accesses. Which is probably the main bottle neck these days.

And yeah, you are right. Thinking reverse Polish if you are not used to it is hard. Tough.

Let me tell you a little about my project management philosophy:

I have been lead engineer in a number of projects in the $1 to $10 million range from design to schedule(logistics) to implementation. I am also used to working with a small support system i.e. subject to financial controls I have done my own purchasing for various projects. Vendor negotiations etc.

Plus I have a reputation for driving projects to completion including doing miracles with schedules on other people's projects that were terribly out of whack. I can give details and references if you want more information.

Let me also say that I have a rep for being "difficult" because I do not tolerate stupidity or fools gladly. However, that is also the reason I get things done. Also note that I have no problem with ignorance. That can be cured with education.

My main field of expertise is aircraft electrical systems. With a side of fission reactions thanks to the US Navy. (I'm nuclear qualified) I understand the heat transfer problems and can do design in that area or at least supervise it.

===

[Indrek]

C has a stack where it keeps input parameters the address of the calling routine and the one allowed output parameter ( if you want more output parameters you need temporary or permanent named variables which consume more stack space for the address.

Every time you make use a new subroutine you have to build a new stack frame.

Forth eliminates all those problems by being a two stack machine. One for data and one for return addresses. The data is always where you need it - on top pf the stack. So you have what is called a zero operand machine. You don't have to tell the processor (except occasionally for permanent variables or constants) where to find the data.

I understand.

It's true that in C you need to construct the stack but isn't it the same in forth? The subroutine you call expects parameters in a certain order - you have to construct a stack of those parameters in the specified order. Compared to C I see much more juggling with the stack that results in increased program complexity (=more instruction to execute=slower execution) plus it puts more constraints on the programmer. I can see that from the programmer this will also result in a more efficient code as he has to find the best order and way to take arguments to his function. But I wonder what happens if you have lots of arguments but need to access all of them several times - with only operating on a stack that can be a nightmare.

Also I don't like functions that return many parameters (or for the matter pass many of them). In my book functions are instead for modifying memory, and not for returning parameters (and in practice=real world applications most of them are). It's true there are several ways to design a computer architecture, but I believe the current prevalent way is a compromise of the best.

The way I see the stack based systems are slow - memory has to be accessed all the time. Accessing memory is slow. That's why we have registers, caches, branch prediction and random access of the stack. Those tools minimize slow direct accesses to the main memory.

Another common feature of computers is bulk processing of data. That's why we have pipelines. They make the processor slightly slower for the very single operations but for bulk operations (which is the common case) they increase speed.

Your argument about an AMD burning up does not make sense. Just pour liquid nitrogen on it if it heats up, it's cheap and plentiful Real arguments please. Real time reason? Sure.

Managing a project versus the architecture/language used - in my mind those two are entirely different things. More so I think the C vs. Forth discussion is irrelevant - they are both established technologies. Strong management and qualified professionals is what makes a project succeed, not some technological gizmo on its own. I've seen plenty of IT projects fail that stressed technology over process - the weak management's idea is "lets buy some most expensive buzzword-filled 'product' off the street, throw lots of programmers that just graduated high school at it and success is guaranteed".

- Indrek

[MSimon]

Let me mention that apart from my Naval Nuclear training, I'm entirely self taught in electronics, control system theory, processor design, software design, and a couple of other things.

A big help when you get into places where there is no road map.

[MSimon]

Indrek,

The problem in C is reconstructing the stack frame every time you do a new subroutine.

In FORTH you just leave the parameters on the stack and call the subroutine. Other than the initial build no rebuilding is necessary.

If you haven't worked with it, it is very hard to believe. Very hard.

As my friend Jeff Fox said to me after explaining FORTH to a manager with 500 programmers. The manager exclaimed once he got it: "What am I going to do with all my programmers?"

The amount of waste in the software industry is incredible. Hardware too.

What have we been doing: designing hardware that will build the stack frames faster. FORTH is different. Don't build stack frames at all. That is as fast as you can get.

In current processors executing instructions takes multiple clocks. Leading to long pipelines, branch predictors and all that rotten kluge. The way out? Execute all (or almost all) instructions in a single cycle.

Eventually Chuck Moore (the inventor of FORTH) will be recognized for the genius he is. He doesn't think the way every one else does. Which is why most folks can't get it. I'm lucky I learned about FORTH in the 80s when the bare metal guys understood the relationship of the hardware to the software. Now you have hardware designers. And software designers. And the two have hardly any common ground.