Shop OBEX P1 Docs P2 Docs Learn Events
Need a little help with Open Hardware Conference material - Page 2 — Parallax Forums

Need a little help with Open Hardware Conference material

2456

Comments

  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-02 23:39
    I just saw the time limit. 12 minutes???

    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.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-02 23:56
    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-03 00:08
    Yes, Ariba should post.

    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.
  • Heater.Heater. Posts: 21,230
    edited 2013-09-03 00:37
    Perhaps it's soon time for a "Why the Propeller II Works (the way it does)" document.

    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-09-03 00:46
    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.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-09-03 00:58
    cgracey wrote: »
    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.

    Thankyou for allowing me to be a part of it.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2013-09-03 01:42
    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.

    Roy
  • AribaAriba Posts: 2,690
    edited 2013-09-03 02:16
    Okay here are the links I sent to Chip.

    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
  • SapiehaSapieha Posts: 2,964
    edited 2013-09-03 02:18
    Hi Roy.

    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
    Roy Eltham wrote: »
    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.

    Roy
  • jac_goudsmitjac_goudsmit Posts: 418
    edited 2013-09-03 06:09
    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.

    ===Jac
  • jazzedjazzed Posts: 11,803
    edited 2013-09-03 09:29
    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.
  • KyeKye Posts: 2,200
    edited 2013-09-03 10:29
    Hey, don't forget that I helped with some of the booting setup layout for FLASH and evaluated the possibility of using SD cards. :)
  • cgraceycgracey Posts: 14,134
    edited 2013-09-03 10:30
    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:
    						cycles	words	cycles/bits/@12MHz
    
    8051:  (8-bit)
    update_latch	mov	a,byte			12	2
    		mov	r0,#8			12	2
    loop		rlc	a			12	1
    		mov	ser,c			24	2
    		setb	srck			12	2
    		clr	srck			12	2
    		djnz	r0,loop			24	2
    		setb	rck			12	2
    		clr	rck			12	2
    		ret				24	1	744/144/62us
    
    PIC:  (12-bit)
    update_latch	movf	byte,0			4	1
    		movwf	temp			4	1
    		movlw	8			4	1
    		movwf	bits			4	1
    loop		rlf	temp			4	1
    		bcf	ser			4	1
    		btfsc	c			4 (no8)	1	
    		bsf	ser			4	1
    		bsf	srck			4	1
    		bcf	srck			4	1
    		decfsz	bits,1			4	1
    		goto	loop			8	1
    		bsf	rck			4	1
    		bcf	rck			4	1
    		retlw				8	1	319/180/27us
    
    TWERP:	(16-bit)
    update_latch	mov	temp,byte		1	1
    		mov	bits,#8			1	1
    loop		rl	temp		c	1	1
    		movc	ser,#80h		1	1
    		or	port,#00010000b		1	1
    		and	port,#11101111b		1	1
    		sub	bits,#1			1	1
    	if nz	jmp	loop			1	1
    		set	rck			1	1
    		clr	rck			1	1
    		ret				1	1	53/176/4.4us
    

    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-03 10:57
    So it was TWERP before PNUT?
  • RaymanRayman Posts: 14,557
    edited 2013-09-03 11:01
    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.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-09-03 11:09
    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?
  • cgraceycgracey Posts: 14,134
    edited 2013-09-03 11:25
    David Betz wrote: »
    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?

    Likely so. I'll throw that in.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-03 11:30
    potatohead wrote: »
    So it was TWERP before PNUT?

    Yes, and it was QUARP before TWERP.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-03 11:31
    Too funny! Thanks for that.
  • jazzedjazzed Posts: 11,803
    edited 2013-09-03 11:35
    Chip, I saw it happen - Bill had your ear for at least two hours :)
  • TubularTubular Posts: 4,693
    edited 2013-09-03 12:55
    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).
    1024 x 695 - 131K
  • RickBRickB Posts: 395
    edited 2013-09-03 13:42
    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.

    Rick
  • David BetzDavid Betz Posts: 14,516
    edited 2013-09-03 13:56
    David Betz wrote: »
    I'm fairly close to Boston. I'll see if I can get the day off to attend. Sounds like fun!
    Darn! I guess I waited too long and now the conference is sold out. :-(
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2013-09-03 18:12
    cgracey wrote: »
    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."
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-03 19:44
    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.

    But it's not primary. Just enabling, necessary.
  • Ken GraceyKen Gracey Posts: 7,390
    edited 2013-09-03 20:30
    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2013-09-03 20:32
    Thus, product management.

    It's a necessary component of any design, and there should be no worries at all expressing it's part in things.
  • cgraceycgracey Posts: 14,134
    edited 2013-09-03 23:31
    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.

    Thanks, again, Everyone!

    Chip
  • MacTuxLinMacTuxLin Posts: 821
    edited 2013-09-03 23:40
    :lol: well, if you want Matanya to stand-up & say "I am Propeller-powered", I'll programme it & loan it to you ....
  • cgraceycgracey Posts: 14,134
    edited 2013-09-03 23:48
    Here's the final PowerPoint presentation for the conference. I got that "to" changed to "too" and added a new slide after the first.

    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.
Sign In or Register to comment.