Can port "b" be used for intercog sync signals?

[CJ]

scenario:

say cog3 is waiting for its sync on b5
master cog0 raises b5 to signal cog3 to run its course and go back to sleep

end scenario

is it possible?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

[Jon Williams]

I think maybe.· I ran this quick test and the A16 LED flashes as expected:

PUB main

· dira[16]~~
· repeat
··· !outb[0]
··· outa[16] := outb[0]
··· waitcnt(clkfreq + cnt)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[cgracey]

The OUTB and DIRB registers in each COG are just RAM (until a Propeller with a B port is made). They have no connectivity outside the COG. I would advise against using them as RAM, though, since this would create future compatibilty problems with 64-I/O Propeller chips.

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


Chip Gracey
Parallax, Inc.

[Tracy Allen]

But Chip, they are not just RAM, right, they are I/O registers that connect between the COGs? So in the example Jon posted, if I want to or need to use an I/O pin to pass data or sync between COGs, I might as well use a portb bit. If ever I upgrade to a 64-pin version, I could still perhaps need to dedicate that pin to the purpose. In the meantime, it is a free channel.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

[cgracey]

They are just RAM, local to the COG. There is no connection beyond the COG. Once we make a 64-pin chip, we will add a ton of wiring and logic, and I/O pads to realize the functionality you're talking about. Right now, it's just a humble COG RAM register with no special attributes.

Tracy Allen said...
But Chip, they are not just RAM, right, they are I/O registers that connect between the COGs? So in the example Jon posted, if I want to or need to use an I/O pin to pass data or sync between COGs, I might as well use a portb bit. If ever I upgrade to a 64-pin version, I could still perhaps need to dedicate that pin to the purpose. In the meantime, it is a free channel.

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


Chip Gracey
Parallax, Inc.

[Jon Williams]

That explains why I couldn't get my CTR demo working with one of the "b" pins. Right? I mean we can read the bits from outb, etc, but waitpeq and waitpne will not work because of the lack of logic connecting the port b RAM to the outside world.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

[CJ]

I was thinking it might be like the BS2P where the register and IO were there but not hooked up to the outside world.

thanks for clearing it up

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

[tperkins]

You realize Chip, you may be randomly kissed on the street by uC programmers when the portb package is shipping. Right?

Yours, TDP

[cgracey]

Huh? How come?

tperkins said...
You realize Chip, you may be randomly kissed on the street by uC programmers when the portb package is shipping. Right?

Yours, TDP

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


Chip Gracey
Parallax, Inc.

[tperkins]

Chip, it's a wonderful thing. For example, it makes multiplexing a 32bit porta access out to 32bit memory (and other 32bit peripherals) a very high speed affair, quite like a DMA on a PC--and there's still enough pins on the 32bit portb when you do it you won't necessarily loose access to I2C or other serial (bit-bang) peripherals. With 32 I/O's, it seems like we can't quite get all the 32 bit potential out of it, with 64 I/O pins though..heh heh...you've got a Supersonic Propellor.

You've made a 32bit general purpose processor available for $3.57/ in small quantities*, and it can be programmed much more easily for dedicated parallel processing than the parallel CPUs of a Bewulf cluster. The clock speed is low by a factor of 50 (how much can that go up ?). *I'm assuming 1 for coordination and 7 effective per die. This thing can get huge if it has a full 32bit bus for data without overlaying anything else on it.

I may be mistaking its usefullness for full floating math if the ALU takes a lot longer for floating point operations than for integers (I see MUL and MULS are reserved for future use, no DIV/S--but what do I want in a uC?), but I can see arrays of boards with 10x10 Propellors per board crunching frighteningly large arrays of data (outside of the bus speed issue). And many operations do just fine with integer only math.

I know I'm insane, but how wrong am I?

Yours, TDP

[Electronegativity]

Hi Tperkins.

I had similar thoughts about number crunching when I first saw the propeller chip.

I will be interested to see the routing of 100 64 pin chips on a single board!

The propeller is indeed a marvel and I believe it will be the chip of choice for robotics applications, but it simply cannot compete with conventional CPU's or FPGA's in terms of FLOPs per dollar.

at 160 million instructions per second it would take 20 propeller chips at a cost of $500 to equal the speed of a $200 3.2GHz pentium4
You also have to deal with routing a board for 20 chips instead of one.

For massively parallel applications a similar argument could be made in favor of FPGA's

Hey Chip!
Since you've been following this thread I have a completely unreasonable request to make.
I read somewhere on this forum that Altera FPGAs were used to make the propeller.
Does that mean that a "softcore" version of the propeller is availabe as a VHDL or Verilog file?
Maybe it would make a nice addition to the download directory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I wonder if this wire is hot...

[Kaos Kidd]

Just a few bits from the old bit bucket:
Preformance is not equated to IPS alone, capabilities must be established as parts of preformance as well.
The current propeller outpreforms a Pentuim 33 as it sits right now, and it needs less hardware to make it work!
When the Propeller 64 comes out, it will exceed the combined power of the Pentium 66 WITH it's componet hard ware!
.....AND..... You don't need any extra hardware or schooling to make it work!

Oh, there's so much more to preformancing a chip like this, establishing a base line...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

[tperkins]

Along those lines, my main questions are, what (presumably fast) assembly language math instructions are or will be available, and how fast could a propellor be made to go in MHz/GHz?

Yours, TDP

[cgracey]

The current chips are rated at 80MHz (20 MIPS / COG), but·top out at around 112 MHz at 3.3V and ambient room temperature. I think that for an application where the part won't be exposed to high heat, 100MHz operation is quite reliable (25 MIPS / COG).

In the current architecture, there are all kinds of logic, rotation, and add/subtract math instructions. It takes two instructions (8 clocks) for each bit multiply (ie 16x16-bit multiply takes 32 instructions, or 128 clocks). I know that's a little anemic, but in the next architecture, we'll have signed and unsigned multiply instructions. That will make a big, or at least·obvious,·difference in potential DSP apps. I'm anticipating that despite the current Propeller's performance limitations, people will coax yet-unimagined performance out of the chip. There are lots of fun ways to get around things like multiplies, divides, and square roots, sines, and trig functions.

Back in the Commodore 64 days, someone told me a cheap way to compute a hypotenuse: take the long leg and add 3/8 (two shifts and an add) of the short leg. I plotted out the error, and it was within about 5%. Dirty, but okay for simple stuff. There are many more tricks with far greater accuracy that can get you around what seems like insurmountable computing requirements. The current Propeller chip is a real playground for that kind of stuff.

tperkins said...
Along those lines, my main questions are, what (presumably fast) assembly language math instructions are or will be available, and how fast could a propellor be made to go in MHz/GHz?

Yours, TDP

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


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey) : 4/13/2006 8:22:01 PM GMT

[tperkins]

Hello Chip,

Thank you for your informative reply. It is an awesome achievement.

With respect to dirt cheap supercomputers however...

Drat.

Nevertheless, the whiff of dedicated function parallel DSP/integer processing capability seems to remain. Wahoo!

Yoursm TDP, ml, msl, & pfpp