PROP II - Interupts, IO and other Musings

Praxis

Before anyone says yeah I know the Prop II has been discussed before and perhaps even it is too late to throw this in now.

IO Pins:

1. Phase selectable interrupts on IO pins
2. Selectable pull up/pull downs on IO pins
3. Selectable wired-or on DDR set outputs

Interrupts:

1. IO pins (as above)
2. Counters i.e. overflow, match value


I guess I am opening a debate about the virtues of interrupts here[noparse]:)[/noparse]

Ale

Pull-up and pull-downs and wired or are a good idea(tm), but I think they said no.

Interrupts ?, forget them. Anyways you have waitpeq and waitpne.

You have waitcnt... enough to implement an "interrupt" model counter.

With more than one core, processor, cog, you may not need interrupts. Besides... the COG assembly does not provide stack or link(ed) register or hw stack. Those, any of them would be needed. The architecture is different. For interrupts... maybe an ARM or similar processor is better suited (with hig-resolution timers).

Mike Green

There's no debate involved. There are no interrupts.

parsko

Dude, 16 on-board 80Mhz processors!!!

jazzed

What happens when you need the 17th processor? Talk about PropIII?
LMM can fake interrupts required for multi-tasking, but then you run out of memory eventually :<
Prop however convenient is not a general computing solution. If you want that, use another CPU.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Praxis

Yo parkso,

OK there are 16 cogs, for me 8 cogs with faster clock and more memory would be enough.

With that said I like the idea of dynamic cog allocation/deallocation i.e. you need one to do some specific task allocate a cog and then when done it is available again.

Using a cog to look for say a single pin change seems a bit over kill, getting a pin transition change as an interrupt and then allocating a cog to process it, well....
no staking of the main program, parallel processing of the event etc.

Ken Peterson

I've never run into anything that I have done or thought of doing with the Propeller where I wished I had interrupts. Just doesn't seem to me that interrupts would add enough value to the chip to warrant the added complexity.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

parsko

Praxis, it really boils down to your need. If you are conserving power, then allocating cogs to a specific task can be overkill. If your program is HUGE and consumes 15 cogs, then allocating a cog to specific event can be tough. If timing is an issue (starting a cog takes:

at 80 MHz:

• Spin launching an assembler cog takes about 12 uSec.
• Spin launching a spin cog takes about 225 uSec.
• assembler to launch an assembler, and that procedure takes about 110 uSec

then starting a cog specifically for an interupt may be a problem too.

I agree with your request from one standpoint, though. Not many companies have a forum that is monitored so closely by the dude doing the actual design. So, making requests like this normally is moot. Please don't take our attitudes the wrong way, but the interupt thing has been discussed before. Ditto to Ken's post too.

-Parsko

David E.

My only question about the Prop II is when can I buy one.

J. A. Streich

Interrupts were invented as a way to simulate multi-tasking on a single core processor.
When you have 16 cores, the need for hardware interrupts goes away.
If you want interrupts, do it software.
Suppose for instance they could easily give us a 15 cog propII with interupts; what's the difference between that and a 16 core chip where you use one cog into a polling?

parsko

With 16 COG's, you could use 15 of them to do stuff, while saving good ol' number 16 for interrupt polling. I think one could develop an assembly loop that was 65 lines long, that would loop (at 80Mhz) about 300,000Hz. Not many projects need an interrupt that is more accurate than that, right?

Pseudocode

test ina, pin1mask wz
if_z call pin1routine
.
.
.
.
test ina, pin32mask wz
if_z call pin32routine

jump pseudocode

Not sure if that's right, but I think it's pretty close. I think the interrupt issue stems from those that are afraid to learn assembly. I'm not implying anything, as you are simply making a suggestion. But, assembly allows one to write some wicked fast routines that are otherwise impossible in SPIN, at the same speeds. I think that the CASE statement may make this pretty fast in SPIN, but I don't use spin much other than human I/O...

Another benefit is you can create more powerful interupt routines in assembly using the various "conditions" such as WZ, WC IF_Z, IF_NZ, etc... I don't know, really, how a "true" interupt works, as my only real experience is with the Prop, but my take is that interrupts only work on ONE interrupt, and subsequently the ONE with the highest priority, right?

I agree with David E., when can I buy one? According to the powers that be, still another couple years off (2010ish?).

-Parsko

hinv

@praxis, Since I never really got the hang of using those pesky interrupts, with wildly different implementations, on the different chips I programmed, the propeller is WAY cleaner than any other chip I know of. Deterministic timing on a computer! Imagine that! ;^)

@parsko, I wasn't aware that starting a cog in assembly from assembly took longer than spin starting an assembly cog. Why is that?

@jazzed, I think the PropII will be more of a general computing solution. I don't think that the current prop is limited by the lack of interrupts, but for the lack of a memory interface. When you think that a 28 year old Commodore64 has more memory than the Prop1, it makes the general computing paradigm a bit limiting. Even with the P8x32B, the one with 64 I/Os, current generation, you would have enough pins to attach a megabyte or so of memory. Then in my mind, it becomes a general purpose computer! It might be worth while, after the PropII comes out, to go after a die shrunk PropII with 8MB or so of SRAM on chip. That would rock. (and probably cook too) ;^)

Mike Green

Spin launching an assembly cog should take slightly longer than assembly launching an assembly cog. It's pretty much the transfer time for 512 longs from hub to cog which is 16 clock cycles per long or 200ns per long at 80MHz for a total of about 103us. The additional overhead for Spin is the time required to load up the operands for the COGINIT instruction and to execute it, maybe a few microseconds.

Philldapill

@hinv - Whoa... the 64 pin Prop is out or is going to be out soon???

Mike Green

No. There was a message some time ago that the design checking software has a bug in it and chokes on the design of the 64 pin Prop I for some reason. Until there's a fix for the software, the effort has been shelved. It's more useful to put the limited resources into the design of the Prop II.

VIRAND

Has the planned obsolescence of NTSC and maybe VGA signals affected the PropII design?
Is a DVI or HDTV compatible video driver possible?

Perhaps there will be an NTSC to DVI converter chip, just as we use FTDI for USB when we can't use RS-232C anymore.

hippy

I don't think NTSC or PAL are going to disappear any time soon. There are plenty of products which use composite video commercially and domestically which will need to be supported for quite a while.

Ken Peterson

@VIRAND: So far it's only broadcast (i.e., radio waves) NTSC that is going away soon. I'm sure they'll still use NTSC for cable and satellite for some time to come.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

evanh

VIRAND might be right, for the moment displays come with a wide array of inputs but the dropping of analogue inputs could happen rather quickly. At that point anyone still needing these types are going to be in for buying expensive converts.

That said, a big part of the onboard input handling on the back of displays is the scan-converter and that will never be dropped now that the displays are constructed as a grid. The analogue frontends are small-fry in comparison.


Evan

richaj45

I would like to see each COG have more than 512 addressable locations. This would increase the instruction beyond 32-bits so maybe it is not clean but that is what i would like to see change.

cheers,
rich

hippy

I too argued for Cogs over 512 locations long but the only real mechanism for doing that is banked memory. That's complicated in a number of ways, lacks elegance and adds a lot of unnecessary overhead and footprint to the chip to support something which isn't required by most people.

LMM, the Large Memory Model, is the best way to work round the Cog memory limitation. There's a learning curve to that, it doesn't solve all problems, has some of its own, there's currently a lack of tools to make it as easy as it could be, but since understanding its advantages I've given up thinking about having larger Cog memory sizes.

hinv

@hippy: with 64 pins for I/O, for some applications(like frame buffer), adding external memory will be another way to work with larger memories accessible to a cog may be another solution. You can't execute instructions there either, but you could page it in just like in LMM

Some see 512 locations/cog as a great limitation, but there is another way to look at it. How many other processors have 512 32bit registers? 512 Registers WOW. I remember on the 6502, we had only A, X, Y, SP, and PC.
The limitation, of course, is that your instructions have to live there also.

Doug

richaj45

So what is this LMM (Large Memory Model)?

rich

Ken Peterson

richaj45: It's a way of executing PASM instructions directly out of HUB ram. The program in the cog is essentially a small loop that reads instructions using RDLONG one instruction at a time and executes them. The language is slightly modified in order to handle long jumps, etc.

More info:· http://forums.parallax.com/showthread.php?p=615022

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Pyrotom

I think that all of those who want to make the Prop into something more like what they have programmed in the past are missing the whole point of the Prop. Its design from day one was to eliminate the need for interrupts, and to have a very compact, fast, low-power solution for many, many problems. At this Chip and his team have been wildly successful. If you really need interrupts, use a chip with interrupts. If you really need lots of memory, use a chip with a bigger address space, or use the LMM support. But please stop trying to ruin one of the most elegant and revolutionary chips to come along in a long time! Just my two cents.....

hippy

@ rich : There's also a short description of LMM on the Propeller Wiki which is perhaps a more gentler introduction than the deep technical descriptions elsewhere ...

propeller.wikispaces.com/Large+Memory+Model

You can in some ways think of it as a paging mechanism where blocks of code are loaded into the Cog's memory to be executed as and when needed, except where paging brings in a whole block of memory LMM brings in an instruction at a time, executes that, gets the next instruction.

It's also similar to a PC emulator for games console where the PC would be interpreting the instruction set of the CPU the games console used. In this case the LMM interpreter executes a slightly modified Propeller Assembler (PASM) instruction set which means it's got very little overhead and so LMM execution isn't an awfully lot slower than native PASM.