I'm trying to remember... Would 2 cogs have faster hub memory access than 8 cogs?
Yes, every second clock cycle would be a rotation/slot time. But that doesn't mean a RDLONG is instant, at least not without redesign, it still has a 9-clock minimum access time.
As long as developing the P2 subset isn't just avoidance activity in lieu of finishing the paperwork (i.e. documentation, dev tools, marketing strategy, etc.) for the P2 ...
<diversion>
I started working on a P2 emulator (I didn't say that out loud did I?) as there isn't one yet .
Trying to find the information isn't hard. Trying to find information that I'm confident enough to think is up-to-date is the real issue.
</diversion>
As long as developing the P2 subset isn't just avoidance activity in lieu of finishing the paperwork (i.e. documentation, dev tools, marketing strategy, etc.) for the P2 ...
<diversion>
I started working on a P2 emulator (I didn't say that out loud did I?) as there isn't one yet .
Trying to find the information isn't hard. Trying to find information that I'm confident enough to think is up-to-date is the real issue.
</diversion>
Another P2 emulator would be cool, but there is one already -- Dave Hein's spinsim can emulate a P2 pretty well, I think. ("spinsim" is a bit of a misnomer -- it may have started out as a Spin simulator, but now it does full instruction set emulation.)
And I'll echo the concerns about P2 subset development -- while it sounds like a neat project, we don't actually have the original P2 in hand yet (well, most of us don't ).
It sounds like the educational customers are asking for software support more than new hardware. Maybe the money should be spent on software development for educational customers first, rather than developing new P2 platforms?
Another P2 emulator would be cool, but there is one already -- Dave Hein's spinsim can emulate a P2 pretty well, I think. ("spinsim" is a bit of a misnomer -- it may have started out as a Spin simulator, but now it does full instruction set emulation.)
Yup, I was... umm, misnomed? ;-) I thought it was spin only.
I had a slightly different vision as to how I wanted my emulator to work but if Dave's done 95% of the work I should be offering to help with that. Awesome!
It sounds like the educational customers are asking for software support more than new hardware. Maybe the money should be spent on software development for educational customers first, rather than developing new P2 platforms?
I'm looking for a way to contribute. C is not my primary language so working on the C compiler probably isn't the best match for me.
I would like to make two smaller variants: a 2-cog, then a 4-cog. And then, if we are successful, we could use the ONC110 process (110nm) to make a 300MHz 16-cog 1MB-hub version.
Gee, Parallax Semiconductor could be back with a vengeance (though a rose by any other name...). And the talk of that potential 110nm, 16-cog variant has me drooling. I soooo wanted 16 cogs but am happy with the 8 powerful ones that we're getting. If such a "double eight" or "sweet 16" every came to fruition, perhaps its total power draw would be about the same or maybe even somewhat less than the current P2 due to the finer process tech used, even with twice the RAM and 120 more MHz. However, that's just a ball-park guess from reading these forums. At any rate, gotta love those smaller process numbers. Now, if we could just piggyback a HyperRAM die or similar on top for extended memory, but I guess I'm confusing the P2 with an applications processor.
All this talk about 2 and 4 cog versions is sooooooo painful to watch. We were so close to the finish line with the 8-cog version, and now we've gone off the track to go look at shiny objects. There are lots of other things to do before other versions should even be thought about. Every time I see the project diverted I just wonder why we even bother with spending time with the P2. I realize this is Chip's project, but many of us have been hoping to get our hands on the P2 for years.
PLEASE FINISH THE 8-COG VERSION!!!!!!! (YES, I AM YELLING!)
Dave, please don't be alarmed. The P2 looks to be done with this pending respin. There are only two problems with the current silicon:
1) Sign-extension issue in Verilog. Fixed and tested.
2) Glitch on some I/O's when DIR goes low when OUT is high. Will be investigated and fixed when respin underway.
When ON Semi does this job, it's a good opportunity to get some more work done by them. It doesn't slow down the main chip effort, just closely follows it. My definition work is already done for either a 2-cog or 4-cog variant. Getting this through ON Semi's pipe takes maybe 14 weeks. Might as well get it rolling now. That's how I see it.
If you make a 4 or 2 COG P2 how would that compare in price with a P1? It seems like the P1 would have to be a lot cheaper if you're going to add either of these to your product line.
3. Check power usage to ensure hub and cogs are not using power when not being used. The current power curves seem to be indicating they are active when they shouldn't be.
And maybe don't jinx us by saying "There are only two problems with the current silicon" without adding the word "known" before "problems," though we all know that that's what you meant and would have normally said.
Wow! Been at work this afternoon/evening and all this breaks! Just had dinner and get to the forum.
Chip,
I have a question. Could the 2 Cog version fit 4 Cogs if two were severely Instruction reduced?
Need to be careful not to put much effort, and minimal risk, into the carve up.
If there's merit, here are a couple of ideas for the other 2 cogs.
Could they be P1 (basic instruction set) cogs?
Could they be "blind" cogs? ie the paired cogs to the main 2 cogs, sharing LUT but no Hub access?
There is no time to break the design down at that granularity. I've only got bandwidth for coarse changes that won't introduce small caveats. These are our only variables:
1) Number of cogs: 1/2/4/8/16
2) Size of hub RAM: Up to 1024KB
3) Number of I/O pins: Up to 64
The P2 part number reflects these quantities.
These are the only knobs we can quickly and confidently turn.
Wow! Been at work this afternoon/evening and all this breaks! Just had dinner and get to the forum.
Chip,
I have a question. Could the 2 Cog version fit 4 Cogs if two were severely Instruction reduced?
Need to be careful not to put much effort, and minimal risk, into the carve up.
If there's merit, here are a couple of ideas for the other 2 cogs.
Could they be P1 (basic instruction set) cogs?
Could they be "blind" cogs? ie the paired cogs to the main 2 cogs, sharing LUT but no Hub access?
There is no time to break the design down at that granularity. I've only got bandwidth for coarse changes that won't introduce small caveats. These are our only variables:
1) Number of cogs: 1/2/4/8/16
2) Size of hub RAM: Up to 1024KB
3) Number of I/O pins: Up to 64
The P2 part number reflects these quantities.
These are the only knobs we can quickly and confidently turn.
Yes, and don't tempt fate jinx us by saying "There are only two problems with the current silicon" without adding the word "known" before "problems," though we all know that that's what you meant and would have normally said.
Yes, you are right. Two problems that we know of. I think it would be best to get the current P2 out on a bunch of boards to customers after we receive the Amkor-packaged chips on November 8th. The current respin needs feedback from that, before it should proceed, anyway.
Sounds prudent. I also liked your earlier words that said "We don't know what we don't know." I actually wrote some song lyrics along those lines once. Anyway, the weather is looking pretty good, with just a couple small clouds in the sky, and none currently on the horizon.
In a 2 cog design, there shouldn't be any requirement for the egg-beater as each cog would have access to the hub on alternate clocks. This should mean that the cogs would self-align their instruction execution to opposing clock pairs, given most instructions are 2 clocks.
Is this correct???
A 2 cog design would have 1 cog accessing the even hub addresses on one clock and odd addresses on the next clock. The second cog would access the opposite.
In a 2 cog design, there shouldn't be any requirement for the egg-beater as each cog would have access to the hub on alternate clocks. This should mean that the cogs would self-align their instruction execution to opposing clock pairs, given most instructions are 2 clocks.
Is this correct???
Yes. That is so.
The eggbeater would compile down to near nothing in a 2-cog chip.
Interesting; so this P2 4COG 32Smart-IO chip can then also become the 'glue'-chip then
between an 8-COG and an 16-COG chip and the outside world.
Bitbanging USB 1.1 level (for programming and/or outside world comm. and debug)
and talk to the main chip, generate differential clock-speeds for the main chip in XI
or even stop the clock for full 'dead' and current reducement,
read in external temperature (analogue temp.sensor close up the main chip), act as
a brown-out-detection by measuring 1,8V and 3,3V and compare it to internal setpoints,
Smaller chip takes far less current, so can be powered by seperate low current
1,8V and 3,3V regulators, primary therefore buffered by a larger capacitor (supercap 10F?)
to let the glue chip operate on his own and do its guarding or even waiting for specific
reasons to wake up the main chip.
Can also act as an RESn controller for the main chip (Including temp and brown-out),
inclusion of a RTC, which can be triggered on (to wake up main chip).
If an I2C or SPI 'receiver' prg is written for it in one of its COGS, it can (by internal R/W 'softregisters')
accept commands from the main chip to set wake-up time, throttle the external XI
speed input, read in temp, measurement of clock-frequency, voltage's of inputvoltage
or main chip voltage's, read in a keyboard or status-info with leds or a (?serial, 4bit)
display (2x16 ...2x40) or simular.
If there could be an inclusion of additional (512KB / 1024KB ?) memory in this P2-4COG chip
with MOSI/MISO or I2C-CL/I2C-D that can by implenting CSn select signal(s) even be used
as the main EERAM for the main processor where it can load its program from,
or store additional (measurement) data, apart from the SD-possibility's.
The I/O pins can be used to switch even the main chip on or off, or adjust the voltage
of it higher or lower for the main chip or wait for a other specific event.
Might solve quite some 'problems' as I've read in the forums where all kind and sorts
of (exotic) IC's are proposed.
With this I.M.H.O. Parallax can have a total in-house solution for having the main
(8C & 16C)-chips operating.
Just an idea to toss up,
Regards,
Erwin
====
[Following the threads for more than 2 yrs seeing a chip in the making.
Ever wanted to buy a P1 'to play with' for some MIDI purposes, but not wanted to
learn 2 new languages short after each other. Did come from the Basic-side (PC, Amiga)
a small bit 68k assembler and Z80 assembler and a bit Pascal but all was so long ago
that a consider myself a newbie.
Make my money as a field-engineer in power electric section (esp. seagoing ships)]
[Following the threads for more than 2 yrs seeing a chip in the making.
Ever wanted to buy a P1 'to play with' for some MIDI purposes, but not wanted to
learn 2 new languages short after each other. Did come from the Basic-side (PC, Amiga)
a small bit 68k assembler and Z80 assembler and a bit Pascal but all was so long ago
that a consider myself a newbie.
Make my money as a field-engineer in power electric section (esp. seagoing ships)]
Welcome to the forums. Looks like you are schooled in both P1 and P2.
[Following the threads for more than 2 yrs seeing a chip in the making.
Ever wanted to buy a P1 'to play with' for some MIDI purposes, but not wanted to
learn 2 new languages short after each other. Did come from the Basic-side (PC, Amiga)
a small bit 68k assembler and Z80 assembler and a bit Pascal but all was so long ago
that a consider myself a newbie.
Make my money as a field-engineer in power electric section (esp. seagoing ships)]
Welcome to the forums. Looks like you are schooled in both P1 and P2.
The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
That's great news!
Arguably, a spin compiler may make a more compelling target than a spin 'terp.
The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
That's great news!
Arguably, a spin compiler may make a more compelling target than a spin 'terp.
There is already a Spin compiler called fastspin by ersmith and Chip is working on a Spin interpreter for P2 so there will be both. They may even be able to call each other.
<stupid question>
In a 2 core P1 you'd always have cog0 running the spin 'terp and you could run PASM in the second cog.
Can I just verify that in the P2 you could run PASM2 in both cogs?
</stupid question>
FWIW, P1 can run PASM in all cogs. It's only necessary for spin to start in cog 0 at boot but it can be replaced by a new PASM program.
BTW, the spin Interpreter that is loaded into the cog is PASM.
I've been a proponent of smaller propeller variants that could be (cost effectively) designed into products all along.
The P2 development has been wonderful to watch but I knew that I would never be able to design it into any of the embedded projects I tend to get into. I would of course buy a few prototype boards to use with my own projects like I have with the PROP, but AVR PIC and TI always win out for embedded designs because of cost/size/power/analog.
I'm currently doing a project for the trucking industry that may eventually scale into hundreds of thousands of units. The prototype is designed around an Arduino because I needed a fast development, analog, small footprint and cheap.
A 2 cog Prop would be perfect for projects like this. I also think a 2 cog version will make a killer 3D printer controller.
I agree with everyone who doesn't want "side issues" to slow down the introduction of the original chip. However, the idea of the P2 quickly turning into a "Family" of "Small and powerful" chips that easily scale up to "BIG and powerful" chips is exciting.
Bring on the "family" and the wait may actually prove to have been worth it.
[Following the threads for more than 2 yrs seeing a chip in the making.
Ever wanted to buy a P1 'to play with' for some MIDI purposes, but not wanted to
learn 2 new languages short after each other. Did come from the Basic-side (PC, Amiga)
a small bit 68k assembler and Z80 assembler and a bit Pascal but all was so long ago
that a consider myself a newbie.
Make my money as a field-engineer in power electric section (esp. seagoing ships)]
Welcome to the forums. Looks like you are schooled in both P1 and P2.
Thanks Publison.
I read a lot. I think a lot (sometimes to much). I fail any practic experience with both the P1
(and the P2 - but will for sure order a nice P2-board (when available) to experiment in
the programming but do not expect any result soon, as i've to learn a new language...)
I've some training in electronics, but are not as seasoned as a lot of other members
here on the side who are (self-)employed and making a living out of it.
A 2-cog version would target low part count designs so you would have to have brown-out reset surely. Sure, you could get by without crystal or Flash but reliable reset is essential. Perhaps a watchdog is in order?
I agree reliable reset is vital, but that can be done with PGood regulators.
Crystal/Osc i’d call essential, as rcfast is not calibrated at all.
More important on smaller family parts will be to solve the power issues.
Welcome to the forums. Looks like you are schooled in both P1 and P2.
The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
Hmmmm,....David,
Take a 10 floor ladder, put it upright and that is the steep learning curve i've to follow.
Starting out in Spin2 would like me a good starter. With inline assembler now for the inclusion
would be a save (slow) transfer before attempting pure PASM2-code.
Or might even be starting with Propbasic2 or simular.
Allthough Spin2 to PASM2 compiler (wich-ever maker) may also sound quit safe for me.
Strangely enough, never understood C, C+, C++ or C#.
But at that time my live started to steer in an other direction,
so other things became more important.
Comments
Yes, every second clock cycle would be a rotation/slot time. But that doesn't mean a RDLONG is instant, at least not without redesign, it still has a 9-clock minimum access time.
<diversion>
I started working on a P2 emulator (I didn't say that out loud did I?) as there isn't one yet .
Trying to find the information isn't hard. Trying to find information that I'm confident enough to think is up-to-date is the real issue.
</diversion>
sure... grab it immediately after the 8 core P2 to sent to production..
Another P2 emulator would be cool, but there is one already -- Dave Hein's spinsim can emulate a P2 pretty well, I think. ("spinsim" is a bit of a misnomer -- it may have started out as a Spin simulator, but now it does full instruction set emulation.)
And I'll echo the concerns about P2 subset development -- while it sounds like a neat project, we don't actually have the original P2 in hand yet (well, most of us don't
It sounds like the educational customers are asking for software support more than new hardware. Maybe the money should be spent on software development for educational customers first, rather than developing new P2 platforms?
Yup, I was... umm, misnomed? ;-) I thought it was spin only.
I had a slightly different vision as to how I wanted my emulator to work but if Dave's done 95% of the work I should be offering to help with that. Awesome!
I'm looking for a way to contribute. C is not my primary language so working on the C compiler probably isn't the best match for me.
I'll give it some thought.
Dave, please don't be alarmed. The P2 looks to be done with this pending respin. There are only two problems with the current silicon:
1) Sign-extension issue in Verilog. Fixed and tested.
2) Glitch on some I/O's when DIR goes low when OUT is high. Will be investigated and fixed when respin underway.
When ON Semi does this job, it's a good opportunity to get some more work done by them. It doesn't slow down the main chip effort, just closely follows it. My definition work is already done for either a 2-cog or 4-cog variant. Getting this through ON Semi's pipe takes maybe 14 weeks. Might as well get it rolling now. That's how I see it.
Yes, less latency then.
Please add to your respin list
3. Check power usage to ensure hub and cogs are not using power when not being used. The current power curves seem to be indicating they are active when they shouldn't be.
There is no time to break the design down at that granularity. I've only got bandwidth for coarse changes that won't introduce small caveats. These are our only variables:
1) Number of cogs: 1/2/4/8/16
2) Size of hub RAM: Up to 1024KB
3) Number of I/O pins: Up to 64
The P2 part number reflects these quantities.
These are the only knobs we can quickly and confidently turn.
Yes, you are right. Two problems that we know of. I think it would be best to get the current P2 out on a bunch of boards to customers after we receive the Amkor-packaged chips on November 8th. The current respin needs feedback from that, before it should proceed, anyway.
Is this correct???
A 2 cog design would have 1 cog accessing the even hub addresses on one clock and odd addresses on the next clock. The second cog would access the opposite.
Yes. That is so.
The eggbeater would compile down to near nothing in a 2-cog chip.
Interesting; so this P2 4COG 32Smart-IO chip can then also become the 'glue'-chip then
between an 8-COG and an 16-COG chip and the outside world.
Bitbanging USB 1.1 level (for programming and/or outside world comm. and debug)
and talk to the main chip, generate differential clock-speeds for the main chip in XI
or even stop the clock for full 'dead' and current reducement,
read in external temperature (analogue temp.sensor close up the main chip), act as
a brown-out-detection by measuring 1,8V and 3,3V and compare it to internal setpoints,
Smaller chip takes far less current, so can be powered by seperate low current
1,8V and 3,3V regulators, primary therefore buffered by a larger capacitor (supercap 10F?)
to let the glue chip operate on his own and do its guarding or even waiting for specific
reasons to wake up the main chip.
Can also act as an RESn controller for the main chip (Including temp and brown-out),
inclusion of a RTC, which can be triggered on (to wake up main chip).
If an I2C or SPI 'receiver' prg is written for it in one of its COGS, it can (by internal R/W 'softregisters')
accept commands from the main chip to set wake-up time, throttle the external XI
speed input, read in temp, measurement of clock-frequency, voltage's of inputvoltage
or main chip voltage's, read in a keyboard or status-info with leds or a (?serial, 4bit)
display (2x16 ...2x40) or simular.
If there could be an inclusion of additional (512KB / 1024KB ?) memory in this P2-4COG chip
with MOSI/MISO or I2C-CL/I2C-D that can by implenting CSn select signal(s) even be used
as the main EERAM for the main processor where it can load its program from,
or store additional (measurement) data, apart from the SD-possibility's.
The I/O pins can be used to switch even the main chip on or off, or adjust the voltage
of it higher or lower for the main chip or wait for a other specific event.
Might solve quite some 'problems' as I've read in the forums where all kind and sorts
of (exotic) IC's are proposed.
With this I.M.H.O. Parallax can have a total in-house solution for having the main
(8C & 16C)-chips operating.
Just an idea to toss up,
Regards,
Erwin
====
[Following the threads for more than 2 yrs seeing a chip in the making.
Ever wanted to buy a P1 'to play with' for some MIDI purposes, but not wanted to
learn 2 new languages short after each other. Did come from the Basic-side (PC, Amiga)
a small bit 68k assembler and Z80 assembler and a bit Pascal but all was so long ago
that a consider myself a newbie.
Make my money as a field-engineer in power electric section (esp. seagoing ships)]
In a 2 core P1 you'd always have cog0 running the spin 'terp and you could run PASM in the second cog.
Can I just verify that in the P2 you could run PASM2 in both cogs?
</stupid question>
Welcome to the forums. Looks like you are schooled in both P1 and P2.
The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
That's great news!
Arguably, a spin compiler may make a more compelling target than a spin 'terp.
BTW, the spin Interpreter that is loaded into the cog is PASM.
The P2 development has been wonderful to watch but I knew that I would never be able to design it into any of the embedded projects I tend to get into. I would of course buy a few prototype boards to use with my own projects like I have with the PROP, but AVR PIC and TI always win out for embedded designs because of cost/size/power/analog.
I'm currently doing a project for the trucking industry that may eventually scale into hundreds of thousands of units. The prototype is designed around an Arduino because I needed a fast development, analog, small footprint and cheap.
A 2 cog Prop would be perfect for projects like this. I also think a 2 cog version will make a killer 3D printer controller.
I agree with everyone who doesn't want "side issues" to slow down the introduction of the original chip. However, the idea of the P2 quickly turning into a "Family" of "Small and powerful" chips that easily scale up to "BIG and powerful" chips is exciting.
Bring on the "family" and the wait may actually prove to have been worth it.
Thanks Publison.
I read a lot. I think a lot (sometimes to much). I fail any practic experience with both the P1
(and the P2 - but will for sure order a nice P2-board (when available) to experiment in
the programming but do not expect any result soon, as i've to learn a new language...)
I've some training in electronics, but are not as seasoned as a lot of other members
here on the side who are (self-)employed and making a living out of it.
Regards,
Erwin
====
Crystal/Osc i’d call essential, as rcfast is not calibrated at all.
More important on smaller family parts will be to solve the power issues.
Hmmmm,....David,
Take a 10 floor ladder, put it upright and that is the steep learning curve i've to follow.
Starting out in Spin2 would like me a good starter. With inline assembler now for the inclusion
would be a save (slow) transfer before attempting pure PASM2-code.
Or might even be starting with Propbasic2 or simular.
Allthough Spin2 to PASM2 compiler (wich-ever maker) may also sound quit safe for me.
Strangely enough, never understood C, C+, C++ or C#.
But at that time my live started to steer in an other direction,
so other things became more important.
Regards,
Erwin
====