Well, point 'em to the thread here, and they can go read history. Seriously. That way, the major points and a picture or two to keep 'em awake will get the whole thing done nice and easy.
If needed, I can assemble collages and other bits of art tomorrow. When is the submission deadline? If you want a Power Point spiffed up, I do that in my sleep. Just let me know.
It's really something to review all that has gone on. Without this forum and your ongoing interest, the Prop2 wouldn't have blossomed like it has. Of course, we still have that pesky issue of actually getting a working chip.
Ariba sent me a pm with a bunch of links to important discussions, which I hope he posts here. He's a little reticent because they are all things that he was involved in. I know each of you are most inclined to remember discussions you were part of. Alas, my stack runneth over, and I can't recall all the details, myself. So, your help was needed.
I've probably got enough here to fill twelve minutes a few times over, but if you think of anything noteworthy, please post it.
Thanks for all your help. If you were here, I'd treat you to some fantastic honeydew melons.
It has been very enlightening to read over the contributions. I've no ego on any of it. Seeing all the references is valuable and entertaining. Man, some of the stuff we said!
12 minutes? Yeah, you are so covered. To be honest, do this one. Then, we probably all should contribute to a somewhat longer one and get the process bits out and really clear. It's valuable as both just sharing what happened, and as educational material / promotion for Parallax overall.
Chip, you are so humble. So therefore I suggest you mention the help this thread has given so you can quote the statements given by others about you.
Perhaps someone can put them together in a single post. I am going to think about my own quote too.
I will try to think of some of the things we had input to. I wont recall who and that doesn't matter for the talk anyway.
But you must warn of the design by committee. You (and Ken) have been a fantastic judge of when things we asked for were too complicated or of little use, you were able to filter those out.
Here are a few things that I recall being discussed and implemented...
Intercog communication via a 32bit I/O - you added more functionality to the base suggestion
P2 to P2 communication
Various pullup & pulldowns on I/O pins
Fuse bits for both user and security
Softloading the encryption engine / downloader (wasn't that written by ???)
Wasn't the monitor suggested by ???
What instructions were suggested - I know there were a number of them
Don't forget Bill Henning and the LMM methodology and how it has been advanced with support instructions.
It's really something to review all that has gone on. Without this forum and your ongoing interest, the Prop2 wouldn't have blossomed like it has. Of course, we still have that pesky issue of actually getting a working chip.
Ariba sent me a pm with a bunch of links to important discussions, which I hope he posts here. He's a little reticent because they are all things that he was involved in. I know each of you are most inclined to remember discussions you were part of. Alas, my stack runneth over, and I can't recall all the details, myself. So, your help was needed.
I've probably got enough here to fill twelve minutes a few times over, but if you think of anything noteworthy, please post it.
Thanks for all your help. If you were here, I'd treat you to some fantastic honeydew melons.
Chip, we are all so proud to be a part of the P2 Development Process.
You made this possible by sharing the details of your design with us. You followed this up with encouragement when we asked questions or made suggestions. Some of those suggestions were refined by many on this forum and yourself. In those instances, the ultimate output was far in excess of the sum of the input.
And then to release FPGA code so we could run emulations on our cheaper FPGA boards to test code and begin developing tools etc is unprecedented in history.
This is not an evolution in Chip Design, but in fact a revolution.
Chip,
I remember you changing the DACs to support better VGA signal output based on a discussion way back when on the forums. Also, we added the texture mirroring and some change to the alpha blending stuff when I visited a while back.
I agree with the others here that a key part of why it worked so well with the P2, was you keeping hold of the reigns and steering things toward the end result.
Not that I find them the most important, but they caused some design changes or brought some solutions that even Chip did not think about.
The P2-LMM thread where we found a real bug regarding cogram mapping of the Quads. This had the consequence that the whole chip needed to be synthesized again:
It's a long conversation over a few pages. It started at post #32 up to this post: Link
where the error was recognized up to post #80 where Chip could locate the error in the Verilog file.
The PAL-Video thread, on which I found an unintented solution for PAL switching (I know NTSC people find it not that important): Link
The whole thread is a good example how a community can help with knowhow and testing and pictures. This was also the base for the PAL part of Baggers NTSC-PAL-Interlaced driver that Chip presented at the Parallax Expo in May.
The link to the "Spin2 XOR atomic PINx/DIRx operations" that Chip mentioned in this thread before: Link
Finally an example of something that got not fixed so far, because it does not justify a whole new revision of the chip design. Link
But beside the post I linked, the whole documentation thread is also a good example for the usefulness of an open hardware design.
That discution was started by me - I think --- Asking why use that many pins for VGA instead of using DAC's directly from P2 and reduce pins usage to 5 only
Chip,
I remember you changing the DACs to support better VGA signal output based on a discussion way back when on the forums. Also, we added the texture mirroring and some change to the alpha blending stuff when I visited a while back.
I agree with the others here that a key part of why it worked so well with the P2, was you keeping hold of the reigns and steering things toward the end result.
I'm most amused by the fact that even when Chip asks for some ideas about things to mention in a presentation about how allowing input from users has influenced the design of the P2 (and the P1), everyone immediately chimes in! "Yo dawg, I opened my inputs to hear some input about your input, so you can input what you input". :-)
I didn't discover the Propeller 1 until 2009 or so and I've had almost no impact on P2 design (only a little bit on how the GCC tools work), but the things that stand out for me as important changes that were made because of input from users, are:
- Opening the source of the P1 Spin bootloader, and removing it from the P2 to leave more space (and presumably improve flexibility and reduce risk).
- The invention of LMM and other memory models, and how Parallax and the developers made it even more important in the GCC compiler than "native" mode.
- Making the FPGA binaries for the P2 available so eager developers could already play with the chip even before it existed, and contribute to the documentation and sample code.
I remember walking through the orchard one night wearing a headlight, eating mandarins, and discussing a few things like having only the boot-loader in ROM ... I think it was Chip's idea really.
More than one of us suggested that CLUT could be used as a stack or queue in addition to color look-up. SERDES was also requested by more than one of us.
In looking around my old files, I found this, from ~22 years ago:
Dear Tom, November 1, 1991
I took a break from the PIC stuff tonight. After finishing that last project,
I got little burned out. I started thinking about that quad-processor we were
talking about.
Here is a rough idea for one:
It is an 8-bit system with up to 256 registers and 64K ROM. Indirect register
addressing is done via special registers, like the PIC. The PC is a set of
registers for each 'cpu'. There are 3 flags for each 'cpu': Z, FF, C. EVERY
instruction executes in 1 cycle, the system executing each cpu in sequence.
Every instruction can be conditionally executed when encountered. Also, you
can specify whether the result is to be stored or whether the flags are to be
affected. Now, rather than having to sometimes branch around exception code,
messing up otherwise consistent timing, small exceptions can be handled in line
without interruption. Look at the last two examples.
The coding for the instructions could be optimized somewhat, hopefully getting
rid of two bits to produce a 24-bit word:
mnem operand op-code flags affected
------------------------------------------------------------------------------
JMP Regs/# 010 e ccc 0 0 s llllllll llllllll none
CALL Regs/# 001 e ccc 0 0 s llllllll llllllll none
RET Reg,Reg/# 000 e ccc 0 0 s rrrrrrrr llllllll none
MOV Reg,Reg/# 000 e ccc a d s rrrrrrrr llllllll Z, FF
AND Reg,Reg/# 001 e ccc a d s rrrrrrrr llllllll Z, FF
OR Reg,Reg/# 010 e ccc a d s rrrrrrrr llllllll Z, FF
XOR Reg,Reg/# 011 e ccc a d s rrrrrrrr llllllll Z, FF
ADD Reg,Reg/# 100 e ccc a d s rrrrrrrr llllllll Z, FF, C
SUB Reg,Reg/# 101 e ccc a d s rrrrrrrr llllllll Z, FF, C
RL Reg,Reg/# 110 e ccc a d s rrrrrrrr llllllll Z, FF, C
RR Reg,Reg/# 111 e ccc a d s rrrrrrrr llllllll Z, FF, C
bit description meaning/value
------------------------------------------------------------------------------
e conditional execution 0=no, 1=yes
c condition 000=Z, 001=/Z, 010=C, 011=/C
100=FF, 101=/FF, 110=c or z, 111=/c and /z
a affect flags 0=no, 1=yes
d destination 0=don't store, 1=store
s source 0=register, 1=literal
r register 0h-0ffh
l register or literal 0h-0ffh
Here are some example routines, first in expanded, bottom form, and secondly in
easier customer-use macros.
;
;
; Load 74HC164 shift register - 57 cycles
;
mov bits,#8 ;load bits with #8
loop rr byte ;rotate right byte
if_c or port,#00000001b no_flags ;set data if c
if_nc and port,#11111110b no_flags ;clr data if /c
and port,#11111101b no_flags ;clr clk
or port,#00000010b no_flags ;set clk
sub bit,#01h ;dec bits
if_nz jmp loop ;loop if /z
;
;
; Load 74HC164 shift register (same as above, but with macros)
;
mov bits,#8
loop rr byte
mov d,c
clr clk
set clk
djnz bits,loop
;
;
; Load dram w/64k samples - 8 cycles/loop
;
loop mov address_port,address+0
and control_port,#11111110b no_flags ;clr ras
mov address_port,address+1
and control_port,#11111101b no_flags ;clr cas
or control_port,#00000011b no_flags ;set ras,cas
add address+0,#01h ;inc address+0
if_z add address+1,#01h ;if z, inc address=1
if_nz jmp loop ;if /z, loop
;
;
; Load dram w/64k samples (same as above, but with macros)
;
loop mov address_port,address+0
clr ras
mov address_port,address+1
clr cas
set ras,cas
ijnz16 address,loop
;
;
; 8-Channel pwm - 26 cycles/loop
;
pwm sub counter,pwm1 no_store ;get bit in c
if_c or port,#00000001b no_flags ;set ch1
if_nc and port,#11111110b no_flags ;clr ch1
sub counter,pwm1 no_store ;get bit in c
if_c or port,#00000010b no_flags ;set ch2
if_nc and port,#11111101b no_flags ;clr ch2
sub counter,pwm1 no_store ;get bit in c
if_c or port,#00000100b no_flags ;set ch3
if_nc and port,#11111011b no_flags ;clr ch3
sub counter,pwm1 no_store ;get bit in c
if_c or port,#00001000b no_flags ;set ch4
if_nc and port,#11110111b no_flags ;clr ch4
sub counter,pwm1 no_store ;get bit in c
if_c or port,#00010000b no_flags ;set ch5
if_nc and port,#11101111b no_flags ;clr ch5
sub counter,pwm1 no_store ;get bit in c
if_c or port,#00100000b no_flags ;set ch6
if_nc and port,#11011111b no_flags ;clr ch6
sub counter,pwm1 no_store ;get bit in c
if_c or port,#01000000b no_flags ;set ch7
if_nc and port,#10111111b no_flags ;clr ch7
sub counter,pwm1 no_store ;get bit in c
if_c or port,#10000000b no_flags ;set ch8
if_nc and port,#01111111b no_flags ;clr ch8
add counter,#01h ;inc counter
jmp pwm
;
;
; 8-Channel pwm (same as above, but with macros)
;
pwm cmp counter,pwm1
mov ch1,c
cmp counter,pwm2
mov ch2,c
cmp counter,pwm3
mov ch3,c
cmp counter,pwm4
mov ch4,c
cmp counter,pwm5
mov ch5,c
cmp counter,pwm6
mov ch6,c
cmp counter,pwm7
mov ch7,c
cmp counter,pwm8
mov ch8,c
inc counter
jmp pwm
;
;
; Octant 8 line draw - 7 cycles/loop
;
octant8 mov slope,dx
:loop dec count
if_z ret
inc x
add slope,dy
if_c dec y no_flags
if_c sub slope,dx
jmp :loop
;
;
; 16-bit decrement - 2 cycles
;
dec count_low
if_ff dec count_high
;
;
; 16-bit increment - 2 cycles
;
inc count_low
if_z inc count_high
P.S. It looks like a some 'move carry bit' instructions could be added to shape
things up.
That was when I was busy making PIC tools, before BASIC Stamps.
Here's a little comparison I made between 8051, PIC, and the architecture I was dreaming about:
From here, it seemed that chip security was the main thing the forum helped with...
Maybe we pushed for other things, like multi-tasking too.
Getting PropGCC working for P2 (and P1) also seems like a big point.
I'm sure this has been mentioned already but didn't a conversation between Chip and Bill Henning result in the RDLONGC, RDWORDC, and RDBYTEC instructions that promise to make LMM and bytecode interpreters a lot faster?
I'm sure this has been mentioned already but didn't a conversation between Chip and Bill Henning result in the RDLONGC, RDWORDC, and RDBYTEC instructions that promise to make LMM and bytecode interpreters a lot faster?
Here's a collage of avatars from many who contributed to the P2 Blog thread. I acknowledge it has errors and my apologies for the discrepencies that might have got culled incorrectly. There were many other contributors who don't have avatars. Jeff Martin has surely contributed much but doesn't appear, for instance
If anyone has a collage tool that can handle 104 images, feel free to run the attached pics through it as I think it will make a much better result. I tried Picasa but it didn't like the small pixel dimension files for whatever reason (only would import 8 of the 104).
You probably have enough for an all day presentation. Put it ALL into a pdf with hot links to more/expanded info. As you read through it, highlight what you think will fit into 12 minutes. Those wanting more can download it.
I need to show how you guys contributed, demonstrating that openness leads to a better product.
Chip, openness doesn't really give you squat. What matters is open-mindedness. There have been lots of open hardware designs by engineers with closed minds.
Perhaps the distinction might be embarrassing to tout, but I think most here would agree it's been your willingness to *truly* entertain the thoughts and ideas of others that has made the difference.
I'm sure there are many, many contributions by forum members that led to a better Prop2, and they're worthy of a mention, if not just as a group. But what really mattered is that you cared to listen. As an audience member, I think I'd be keenly interested in the method and discipline you used to ask for, filter, and process the good ideas given here. How were you able to weigh the pros and cons of the ideas? Maybe this can be part of your talk.
Phil makes the same comments, but I wanted to say something more than just "ditto."
I seconded them, and this too. Speaking to that would be a very high value presentation. Open is good because it makes things like this possible as much as it helps everybody make best use of tools and knowledge out there.
The community design input process has another less productive side for a designer to consider, too. It was mentioned above, too. We all in good company, so...
Sometimes the input can delay the development and eventual release of a product. Engineers can innovate for a really long time without finishing a project, especially when working with their own types. I've seen a couple of occasions when feature requests are considered and incorporated that would serve a small number of customers. When this happens it is often more productive to simply finish the design and make a future revision. We support Chip (our boss) with the freedom to do whatever he wants, but once in a while we have to beg him to move onward and save some features for the next release because the continued delay has an opportunity cost greater than the addition of more features. The industry wants smaller steps and frequent releases from Parallax. Planning around our infrequent chip releases challenges us strategically to make the right short and medium-term decisions.
There. You get the idea.
This is a minor consideration and not meant to diminish the value of the contributions Chip has received from the forums. I talk with Chip regularly and I understand his currency - it's people like you guys who use the hardware and have something to contribute. We have an ecosystem that money can't buy, one that's grown over time with the right people. But with this input we must encourage Chip to make decisions that favor completion vs. addition of more features.
Okay. I think it's done. Thank you all very much for helping out with this. This took all day.
I tried to post the .pptx file, but it's 9.45MB and the forum software only allows 7.15MB. We'll try to get this increased tomorrow and David Carrier will post it here.
Comments
Well, point 'em to the thread here, and they can go read history. Seriously. That way, the major points and a picture or two to keep 'em awake will get the whole thing done nice and easy.
If needed, I can assemble collages and other bits of art tomorrow. When is the submission deadline? If you want a Power Point spiffed up, I do that in my sleep. Just let me know.
Ariba sent me a pm with a bunch of links to important discussions, which I hope he posts here. He's a little reticent because they are all things that he was involved in. I know each of you are most inclined to remember discussions you were part of. Alas, my stack runneth over, and I can't recall all the details, myself. So, your help was needed.
I've probably got enough here to fill twelve minutes a few times over, but if you think of anything noteworthy, please post it.
Thanks for all your help. If you were here, I'd treat you to some fantastic honeydew melons.
It has been very enlightening to read over the contributions. I've no ego on any of it. Seeing all the references is valuable and entertaining. Man, some of the stuff we said!
12 minutes? Yeah, you are so covered. To be honest, do this one. Then, we probably all should contribute to a somewhat longer one and get the process bits out and really clear. It's valuable as both just sharing what happened, and as educational material / promotion for Parallax overall.
Chip could write a whole book of Prop and Prop II development and Parallax history. It would be fascinating. "Soul of a New Machine" and all that.
Perhaps someone can put them together in a single post. I am going to think about my own quote too.
I will try to think of some of the things we had input to. I wont recall who and that doesn't matter for the talk anyway.
But you must warn of the design by committee. You (and Ken) have been a fantastic judge of when things we asked for were too complicated or of little use, you were able to filter those out.
Here are a few things that I recall being discussed and implemented...
- Intercog communication via a 32bit I/O - you added more functionality to the base suggestion
- P2 to P2 communication
- Various pullup & pulldowns on I/O pins
- Fuse bits for both user and security
- Softloading the encryption engine / downloader (wasn't that written by ???)
- Wasn't the monitor suggested by ???
- What instructions were suggested - I know there were a number of them
Don't forget Bill Henning and the LMM methodology and how it has been advanced with support instructions.Chip, we are all so proud to be a part of the P2 Development Process.
You made this possible by sharing the details of your design with us. You followed this up with encouragement when we asked questions or made suggestions. Some of those suggestions were refined by many on this forum and yourself. In those instances, the ultimate output was far in excess of the sum of the input.
And then to release FPGA code so we could run emulations on our cheaper FPGA boards to test code and begin developing tools etc is unprecedented in history.
This is not an evolution in Chip Design, but in fact a revolution.
Thankyou for allowing me to be a part of it.
I remember you changing the DACs to support better VGA signal output based on a discussion way back when on the forums. Also, we added the texture mirroring and some change to the alpha blending stuff when I visited a while back.
I agree with the others here that a key part of why it worked so well with the P2, was you keeping hold of the reigns and steering things toward the end result.
Roy
Not that I find them the most important, but they caused some design changes or brought some solutions that even Chip did not think about.
The P2-LMM thread where we found a real bug regarding cogram mapping of the Quads. This had the consequence that the whole chip needed to be synthesized again:
It's a long conversation over a few pages. It started at post #32 up to this post:
Link
where the error was recognized up to post #80 where Chip could locate the error in the Verilog file.
The PAL-Video thread, on which I found an unintented solution for PAL switching (I know NTSC people find it not that important):
Link
The whole thread is a good example how a community can help with knowhow and testing and pictures. This was also the base for the PAL part of Baggers NTSC-PAL-Interlaced driver that Chip presented at the Parallax Expo in May.
The link to the "Spin2 XOR atomic PINx/DIRx operations" that Chip mentioned in this thread before:
Link
Finally an example of something that got not fixed so far, because it does not justify a whole new revision of the chip design.
Link
But beside the post I linked, the whole documentation thread is also a good example for the usefulness of an open hardware design.
Andy
That discution was started by me - I think --- Asking why use that many pins for VGA instead of using DAC's directly from P2 and reduce pins usage to 5 only
I didn't discover the Propeller 1 until 2009 or so and I've had almost no impact on P2 design (only a little bit on how the GCC tools work), but the things that stand out for me as important changes that were made because of input from users, are:
- Opening the source of the P1 Spin bootloader, and removing it from the P2 to leave more space (and presumably improve flexibility and reduce risk).
- The invention of LMM and other memory models, and how Parallax and the developers made it even more important in the GCC compiler than "native" mode.
- Making the FPGA binaries for the P2 available so eager developers could already play with the chip even before it existed, and contribute to the documentation and sample code.
===Jac
More than one of us suggested that CLUT could be used as a stack or queue in addition to color look-up. SERDES was also requested by more than one of us.
That was when I was busy making PIC tools, before BASIC Stamps.
Here's a little comparison I made between 8051, PIC, and the architecture I was dreaming about:
I've been working on Propeller chips for half my life, it seems. It wasn't until 1998 that I was free to start making a chip, full time.
Maybe we pushed for other things, like multi-tasking too.
Getting PropGCC working for P2 (and P1) also seems like a big point.
Likely so. I'll throw that in.
Yes, and it was QUARP before TWERP.
If anyone has a collage tool that can handle 104 images, feel free to run the attached pics through it as I think it will make a much better result. I tried Picasa but it didn't like the small pixel dimension files for whatever reason (only would import 8 of the 104).
Rick
Chip, openness doesn't really give you squat. What matters is open-mindedness. There have been lots of open hardware designs by engineers with closed minds.
Perhaps the distinction might be embarrassing to tout, but I think most here would agree it's been your willingness to *truly* entertain the thoughts and ideas of others that has made the difference.
I'm sure there are many, many contributions by forum members that led to a better Prop2, and they're worthy of a mention, if not just as a group. But what really mattered is that you cared to listen. As an audience member, I think I'd be keenly interested in the method and discipline you used to ask for, filter, and process the good ideas given here. How were you able to weigh the pros and cons of the ideas? Maybe this can be part of your talk.
Phil makes the same comments, but I wanted to say something more than just "ditto."
But it's not primary. Just enabling, necessary.
Sometimes the input can delay the development and eventual release of a product. Engineers can innovate for a really long time without finishing a project, especially when working with their own types. I've seen a couple of occasions when feature requests are considered and incorporated that would serve a small number of customers. When this happens it is often more productive to simply finish the design and make a future revision. We support Chip (our boss) with the freedom to do whatever he wants, but once in a while we have to beg him to move onward and save some features for the next release because the continued delay has an opportunity cost greater than the addition of more features. The industry wants smaller steps and frequent releases from Parallax. Planning around our infrequent chip releases challenges us strategically to make the right short and medium-term decisions.
There. You get the idea.
This is a minor consideration and not meant to diminish the value of the contributions Chip has received from the forums. I talk with Chip regularly and I understand his currency - it's people like you guys who use the hardware and have something to contribute. We have an ecosystem that money can't buy, one that's grown over time with the right people. But with this input we must encourage Chip to make decisions that favor completion vs. addition of more features.
It's a necessary component of any design, and there should be no worries at all expressing it's part in things.
I tried to post the .pptx file, but it's 9.45MB and the forum software only allows 7.15MB. We'll try to get this increased tomorrow and David Carrier will post it here.
Thanks, again, Everyone!
Chip
Designing Multicore Microcontrollers.zip
Thanks again for all you help, Everyone!
We will have 16 seconds to show each slide, in order to fit in 12 minutes.