Propeller II (Chat with CHIP) __ Some extra questions will come
Sapieha
Posts: 2,964
zappman: What types of FPGAs do you use? Altera, Xlinx?
Chip Gracey I'm using an Altera Stratix III part now. It's an EP3SL150
Chris, Chip here. This is the place, right?
Hi, Sapieha!
Hey, roy!
Hello, Everyone!
CHIP: Chris, do you want to order this discussion in any way?
CHIP: Ok, Prop II guts...
Let me open Quartus (Altera FPGA software), because there's more than I can remember....
localroger: How about basics like cores, hub and cog RAM, counters, and pins?
CHIP: Basics....
8 cores
128KB hub RAM
92 I/O's
32-bit pipes between all cogs
Each cog has a scientific calculator in hardware, pretty much.
We wanted more hub RAM, but these cogs have 7.4x the amount of logic as the current cogs - takes ~12mm of silicon for cog guts.
There are very nice I/O pins now...
13-bit quality delta-sigma ADC on every pin.
300MHz 9-bit DACs on every pin w/dither for 18-bit settable values.
DACs are 75-ohm.
Each cog has a colorspace converter matrix for ANY video standard.
SDRAM hooks up very easily for ~$3 of 32MB RAM external.
Lots of funny math functions in hardware, like stepping fixed-1's count patterns.
JohnR: does the SDRAM use some of the 92 i/o, or have it
Sapieha: Chip --can SDRAM's can be used as Video buffers?
CHIP: SDRAMs for video - Absolutely! 1080p @ 60Hz, 24 BBP.
Sapieha: Chip ---- On SDRAM's Can't You combine DATA/Adress lines on same pins ---- Like I8085 CPU have that can save pins BUT with speed of Propeller II It still will not be mising of acces timing
CHIP: Sapieha, on SDRAM, data and address must be fed concurrently, so no mux'ing.
Sapieha: YES - But with muxing possibilitys --- Needs only some latches to separate addresses --- BUT that can be even usable with some standard I/O IC's
CHIP: Sapieha, yes, you could use external latches.
CHIP: There's a lot of other stuff, but I can't think of it all. Need more questions.....
Bean: Chip any details about how the hardware registers are accessed ? I assume it is via some kind of index/pointer register ?
ratronic: Chip, 32 bit pipes between all cogs - does that mean cogs can talk to each other directly without using the hub?
Sapieha: Chip --- How about Serializer's
CHIP:Serializers... There are dual-edge-triggered serializers in each cog which can talk to OTHER propeller chips at ~400Mb/s.
Sapieha: But --can them send/receive both as syncron and asyncron?
CHIP: Yes, the serializers are asynchronous. The all feed off a common clock that someone supplies. ???
localroger: Does DACs on-chip mean video without the external resistors?
CHIP: Yes, DACs drive video DIRECTLY
CHIP: About accessing registers...
There are only PIN and DIR registers mapped in register space. All other special registers are written via dedicated instructions.
These dedicated instructions do nice things, though, like read and clear, so you don't have to compute deltas.
.Sapieha: (coment) More space for code
CHIP: Code space is 512 longs (-8, actually), so no big change there.
CHIP: Core runs at 1.8V, while I/O run best at 3.3V, but can be powered at 1.8V for logic compatibility.
realtham: do the cogs still have a CLUT as separate memory?
CHIP: Each cog has a CLUT of 128 longs.
Sapieha: Chip -- If Video use DAC's --- It needs only 5 pins?
CHIP: Video DACs.... 1 pin for composite, 5 for VGA: R/G/B/H/V, 3 for component/HDTV.
JohnR: does the SD Ram access use some of the 92 I/O or have it's own pins?
CHIP: The SDRAM eats 16 or 32 pins for data and another 20 for control+clock.
ratronic: Chip, 32 bit pipes between all cogs - does that mean cogs can talk to each other directly without using the hub?
CHIP: Yes, the 32-bit pipes between cogs are instantaneous and useable with WAITPNE/WAITPEQ + timeout.
bittled: Will it be 5V tolerant?
CHIP: I/Os are not 5V tolerant - 3.6V max.
Bean: Yes, I assume PINA, PINB, PINC, PIND ?
CHIP: Bean, yes. I/O regs start at $1F8: PINA, DIRA, PINB, DIRB, PINC, DIRC, PIND, DIRD.
Bean: I assume DIRA, DIRB, DIRC, DIRD, OUTA, OUTB, OUTC, OUTD are the 8 registers ?
CHIP: Yes, PINA..PIND with each of those REASSIGNABLE to whatever you want, so you can hardcode PINA..PIND, but initialize them on entry to point to whatever ports you want. They initialize to Port 0..3.
CHIP: Localroger, yes, same I/O voltages as current Propeller chip.
CHIP: Power requirements... Don't know yet, but extensive clock gating is used, so should be lower that current Prop.
CHIP: Supply voltages: core = 1.8V, I/O = 1.8V..3.3V
Al Booth: Do the 1.8V and 3.3V supplies need special sequencing on power-up and power-down?
CHIP: No special sequencing is needed on power.
CHIP: Packages... right now just planning on 14x14mm TQFP-128.
CHIP: Yes, the package is very dense, but it has to be to pack 128 pins. It's either that or a ball-grid array.
bittled: Will you have a breakout board for the Prop II for breadboarding?
CHIP: Breakout board... Absolutely!
CHIP: ...Probably a few breakout boards.
CHIP: There is 3D graphics stuff, too... texture lookup/lighting/alpha-blending. 8-bit quality on R/G/B.
reltham: With DIRA-DIRD and such, that is room for 128 ports/pins... with only 92 physical pins, are the other spots some form of internal thing?
CHIP: Roy, three 32-bit ports are implemented, though the last port's 4 highest pins are missing, since those got used on the package for XI/XO/BOEn/RESn.
CHIP: Each 8-bit port has its own set of power/ground pins for voltage selection and noise reduction.
CHIP: Forgot to mention... 3 ports, minus 4 pins, are implemented, the last 'port' is the cog pipe, where each cog can filter what he's seeing from the other cogs' pipe outputs.
Roger Lee: scientific calc. Floatpoint?
CHIP: No floating point, but multiply, divide, square root, and transcendentals via cordic, plus EXP and LOG via cordic.
Yeah, it seems fine to me.
John A. Zoidberg: btw are hardware dividers and multipliers included in Prop II?
CHIP: John, yes. 64/32 divide, 32x32 multiply, 32->16 sqrt, and cordic is all in hardware.
Al Booth: Does the 32x32 bit multiplyhave a 32 bit or 64 bit result?
CHIP: The 32x32 mutiplier has a 64-bit result. The 64/32 divider has a 32-bit quotient and remainder results.
CHIP: There is a separate 16x16 signed/unsigned single-cycle multiplier that executes from these instructions: MUL, MULS, MAC, MACS. The MAC instructions sum into a signed 64-bit accumulator.
CHIP: Some stuff about the CTRs...
CHIP: They can input ADC streams from the pins and run a Goertzel algorith, which is like a live slice of an FFT.
CHIP: Also, CTRs can read ADCs from pins and do PWM output without any hand-holding from the cog, so these will work in Spin, or other high-level languages.
Sapieha: Chip --- Can that CRT's generate 3 phase syncronized waves in one COG? with Sinusoid waves
(Cant find adequate answer)
CHIP: Oh... some more stuff about the new CTRs. Each is a sine/triangle/sawtooth/square function generator w/scale and amplitude for output to the DACs.
eod_punk: Any chance of built in DTMF support like the BS2?
CHIP: Since each cog has two CTRs, and each CTR can generate a sine, and each DAC channel can sum the outputs of its cog's CTRs, you can do this over one pin, hands-free.
CHIP: So, with the Goertzel in CTR hardware, and 50MHz ADC BW, you should be able to demodulate IF's pretty well.
John A. Zoidberg: By the way - will the new Prop II compiler will have easier access to counter modules?
John A. Zoidberg: Because I had a hard time using the counters for the Prop I in Spin and ASM
CHIP: In a way, because of the hands-free modes, the CTRs will be more useful under Spin.
John A. Zoidberg: On top of that - i read that these have a built-in Func.Generators:?
trodoss: Are you still planning on having the embedded ROM font?
CHIP: ROM font is still the same, though we'll probably add a smaller font, too, like an 8x12.
CHIP: Roy, 8x8 what?
CHIP: Okay... 8x8 font. Can do. It's small.
John A. Zoidberg: So there are shared ports in dira/dirb for aDCs and comparators? all needed to set in the respective config registers during startup?
tdlivings: Connecting to the A/D how close, for delta sig P1 had to be on top of chip
CHIP: About connecting ADC stuff - no need for multiple pins - it's all built-in, just connect your signal to the pin.
CHIP: There are special ADC modes within the pins for doing a very high-Z feedback delta-sigma between two adjacent pins for digitizing data from passive weak-signal sensors. Should be useful for lots of new things.
tdlivings: Because the ADC can be done inside the pin, there are no special considerations about trace length or pin numbers.
CHIP: Because the ADC can be done inside the pin, there are no special considerations about trace length or pin numbers.
microcontrolled: Can the built in ADC be used in direct replacement of an external IC?
CHIP: Yeah, there should be no need for external ADC chips. Not only can you do voltage ADC, but you can do current-feedback ADC between two pins to read funny stuff, like a loop of wire, or something.
microcontrolled: I saw something mentioned earlier about sigma-delta. Does this mean that the Prop II will take direct potentiometer input, with no external caps needed?
CHIP: For reading a potentiometer, just connect the outer legs to VSS/VDD and connect the center-tap to an I/O pin for conversion. Nothing else needed.
tdlivings: Sounds like I do not need my DDS chip anymore
tubular: any idea of ADC input impedance yet?
CHIP: ADC input impeadance is ~4M ohms.
CHIP: About DDS... The sine generator uses a 9-bit phase lookup table with 9-bit quality output. The scaling is done with a separate 9-bit coefficient, hence the 18-bit settable DAC outputs.
John A. Zoidberg: So, how many DDS channels does the prop II have?
Chris Savage: So "PINx" handles both INx and OUTx that the Prop 1 has as seperate registers ?
CHIP: Yes, PINx is both OUTA and INA in one, but don't get worried... Whenever you perform a write/r-m-w to a PINx register, it writes to OUT, whereas a read-only operation, cause IN to be read.
Bean: So "PINx" handles both INx and OUTx that the Prop 1 has as seperate registers ?
CHIP: About the PINx registers. These: TEST PINA,mask or TEST mask,PINA both cause the IN to be read, not the OUT.
CHIP: Extra about the 3D stuff - the texture lookup is perspective-correct, which means a hardware divide is being performed for each texel lookup.
Oldbitcollector: talk about multi-propeller2 considerations. Anything special there for us? Timetable to release. What's next?
CHIP: Multi-Prop II possibilities. They're there, facilitated by those fast serializers.
CHIP: To do multi-PropII apps, it's a matter of development tools. The chips can talk amongst themselves pretty easily.
Oldbitcollector: Timetable to release date? What's next?
Release date... We've got a test chip in fab now, but it's just to prove the memories, PLLs, I/O pins, etc. A final chip is a matter now of converting my FPGA code into a schematic, and then Beau laying it all out.
Release date... If we go standard cell place-and-route, it could be 6 months, otherwise, full custom will take another several months. Hard to say. Never good at it.
eod_punk: Have you had to take something out/reduce something that you didn't want to leave out/reduce? Biggest trade off you had to make?
CHIP: Well, we wanted a heck of a lot more ram, like 512KB, ideally. The cogs are such pigs now, that we can only fit 128KB. The good news is the pins are setup for doing
CHIP: SDRAM signalling and there is a hardware facilitator for moving data between SDRAM and hub
CHIP: SDRAM comes in 32MB for about $3. That's enough RAM to build console applications in. I really want to make a nice PCB layout program, but don't want to write it on the PC. I hope to do it on Prop II.
John A. Zoidberg: By the way - u mentioned about SDRAM controllers. How are SDRAMs important in microcontroller applications? Work things better?
CHIP: SDRAM is just BIG, cheap RAM!!! Having lots of memory opens lots of new doors.
CHIP: Chip design tools, too, would be fun to write.
tubular: Chip can you please give us an overview of what you're aiming for regarding security features?
CHIP: For security, we are planning to use poly silicon fuses for giving each chip a 128-bit key that can be used with some block encryption standard. The user can program the key himself.
CHIP: More about the security fuse bits... The ROM program will read the key (which is afterwards hidden) and perform downloading/loading, then start execution.
reltham: How is the CLUT arrange for colors? 16bit 24bit color?
CHIP: The CLUT is 128 longs. There are many modes of output which can use 4, 8, 16, or 24 bits to signify color.
CHIP: The CLUT can stream to the video like a FIFO, or you can hand off one set of pixels and scale at a time per WAITVID.
Sapieha: What types of media to load from?...
CHIP: What types of media to load from?... serial, USB, I2C EEPROM, SPI EEPROM, SD CARD. Any others that it should be sensitive to?
SDCARD, from what I know is just SPI, maybe 4-5 pins to work.
We would use FAT for loading off SDCARD, or, if some signature was present in the first bytes, just stream it in directly.
John A. Zoidberg: Btw any special interfaces for SDCARD?
CHIP: FAT would have to be supported to make things nicely compatible with the PC world.
CHIP: The chip, with SDCARD and SDRAM, could nicely host some O.S.
What are MADDs?
realthm: @JohnR, Multiply ADD
CHIP: MADD will go well with the SEUSSF and SEUSSR instructions, which circulate an invert bits through a Dr. Seuss-like pattern.
blittled: Will the Prop II be able to interface with USB easily since PS2 keyboards and mice are becoming outdated?
CHIP: About USB... Each even/odd pair of pins can form a 30MHz differential input, so you can make USB all over the place. There are also 1.5k resistors you can turn on in the pads to set the USB mode.
CHIP: How many hours designing Prop II... I don't know. It's been 4.5 years since the Propeller was finished, and this is the only project I've been working on. It's got to be several thousand hours, so far.
CHIP: Yes, Beau's been working several years now on the layout stuff. He designed every single polygon that is in the chip. There is nobody else's "IP" in there.
How about a double-barreled bit shifter?
CHIP: Yes, there is a barrel shifter just like in the current Prop. We've just got lots of new instructions.
CHIP: A barrel shifter is something that can shift any number of bits at once, as opposed to just one bit-position at a time.
CHIP: If you can do SHR reg,#20, that's a barrel shifter.
eod_punk: Has any other microcontoller influenced you in making the Proppeller 2?
CHIP: I've never used an Arduino, but have heard that many people like them. I heard it uses a type of C. That's about all I know about its technicality.
localroger: Not a P2 question but something I have always wanted to ask: how did you make the break from what everyone else was doing to the P1? I have been swimming in CPU's since 1974 and I would never have thought of it. So tell me whatr I missed!
CHIP: @localroger - I just new we needed something that could execute mutiple programs at once. I tried lots of different things on the FGPA, but then settled on simple cogs w/each having its own peripherals, and then all cogs sharing a common RAM, for comm.
CHIP: Yes, we plan on making the Prop I for as long as the process is available. It'll be around for at least another 15 years. MOST new IC designs actually use .35um technology, which is what the Prop I uses. Something like 70% of tapeouts target that process.
CHIP: Compatibility... There are many new instructions in the Prop II. The memory map is 32-bits, though we can't realize much of it.
Oldbitcollector: yes. will I be able to run my Prop1 code on the Prop2?
CHIP: You will have to rewrite your code in cases where you are doing new I/O stuff. For the most part, Spin routines should compile as they do now.
Beau Schwabe: @Chip Gracey - on Compatability between PropI and PropII - it sounds as though in some cases a simple text translator might be able to convert the differences.
CHIP: @Beau, the differences will probably go beyond text translation, as they mainly revolve around new possibilities.
CHIP: About 3D graphics... We have, thanks to Andre patient helping me to understand what we needed to do, a texture-mapping system with lighting and blending. It's rudimentary by today's standards, but gets you into the ballpark.
CHIP: I think 3D graphics will be especially neat for showing sensor data in nice ways.
CHIP: Instructions are almost all 1-cycle. Exceptions are the same we have now, like hub accesses. You can read four longs at once into cog ram, then execute them.
Bean: Are instructions 1 cycle ? Also is LMM execution (running code from the hub) supported by hardware / faster ?
CHIP: That is what facilitates LMM programming. Otherwise, there is no special case of LMM execution.
CHIP: @localroger - if a child could visualize a CPU, he could design one. It's like lego's.
CHIP: ADC bandwidth... If the chips is running at 160MHz, Nyquist says you'll get 80MHz bandwidth, but 50MHz would be more like it, as the aliasing would average out better.
CHIP: ADC input impeadance is ~4M ohms.
Sapieha: We are missing You on FORUM!
CHIP: I want to get back on the forum, but haven't been able to log in, so I've just been working.
electromanj: Given the track record of the BS1, I assume the PROP1 will be around for a while?
CHIP: Yes, we plan on making the Prop I for as long as the process is available. It'll be around for at least another 15 years. MOST new IC designs actually use .35um technology, which is what the Prop I uses. Something like 70% of tapeouts target that process.
CHIP: Full instruction set... I'll give to Daniel at Parallax for posting. Or, I'll find out how to get on the forum and do it myself.
Chip Gracey I'm using an Altera Stratix III part now. It's an EP3SL150
Chris, Chip here. This is the place, right?
Hi, Sapieha!
Hey, roy!
Hello, Everyone!
CHIP: Chris, do you want to order this discussion in any way?
CHIP: Ok, Prop II guts...
Let me open Quartus (Altera FPGA software), because there's more than I can remember....
localroger: How about basics like cores, hub and cog RAM, counters, and pins?
CHIP: Basics....
8 cores
128KB hub RAM
92 I/O's
32-bit pipes between all cogs
Each cog has a scientific calculator in hardware, pretty much.
We wanted more hub RAM, but these cogs have 7.4x the amount of logic as the current cogs - takes ~12mm of silicon for cog guts.
There are very nice I/O pins now...
13-bit quality delta-sigma ADC on every pin.
300MHz 9-bit DACs on every pin w/dither for 18-bit settable values.
DACs are 75-ohm.
Each cog has a colorspace converter matrix for ANY video standard.
SDRAM hooks up very easily for ~$3 of 32MB RAM external.
Lots of funny math functions in hardware, like stepping fixed-1's count patterns.
JohnR: does the SDRAM use some of the 92 i/o, or have it
Sapieha: Chip --can SDRAM's can be used as Video buffers?
CHIP: SDRAMs for video - Absolutely! 1080p @ 60Hz, 24 BBP.
Sapieha: Chip ---- On SDRAM's Can't You combine DATA/Adress lines on same pins ---- Like I8085 CPU have that can save pins BUT with speed of Propeller II It still will not be mising of acces timing
CHIP: Sapieha, on SDRAM, data and address must be fed concurrently, so no mux'ing.
Sapieha: YES - But with muxing possibilitys --- Needs only some latches to separate addresses --- BUT that can be even usable with some standard I/O IC's
CHIP: Sapieha, yes, you could use external latches.
CHIP: There's a lot of other stuff, but I can't think of it all. Need more questions.....
Bean: Chip any details about how the hardware registers are accessed ? I assume it is via some kind of index/pointer register ?
ratronic: Chip, 32 bit pipes between all cogs - does that mean cogs can talk to each other directly without using the hub?
Sapieha: Chip --- How about Serializer's
CHIP:Serializers... There are dual-edge-triggered serializers in each cog which can talk to OTHER propeller chips at ~400Mb/s.
Sapieha: But --can them send/receive both as syncron and asyncron?
CHIP: Yes, the serializers are asynchronous. The all feed off a common clock that someone supplies. ???
localroger: Does DACs on-chip mean video without the external resistors?
CHIP: Yes, DACs drive video DIRECTLY
CHIP: About accessing registers...
There are only PIN and DIR registers mapped in register space. All other special registers are written via dedicated instructions.
These dedicated instructions do nice things, though, like read and clear, so you don't have to compute deltas.
.Sapieha: (coment) More space for code
CHIP: Code space is 512 longs (-8, actually), so no big change there.
CHIP: Core runs at 1.8V, while I/O run best at 3.3V, but can be powered at 1.8V for logic compatibility.
realtham: do the cogs still have a CLUT as separate memory?
CHIP: Each cog has a CLUT of 128 longs.
Sapieha: Chip -- If Video use DAC's --- It needs only 5 pins?
CHIP: Video DACs.... 1 pin for composite, 5 for VGA: R/G/B/H/V, 3 for component/HDTV.
JohnR: does the SD Ram access use some of the 92 I/O or have it's own pins?
CHIP: The SDRAM eats 16 or 32 pins for data and another 20 for control+clock.
ratronic: Chip, 32 bit pipes between all cogs - does that mean cogs can talk to each other directly without using the hub?
CHIP: Yes, the 32-bit pipes between cogs are instantaneous and useable with WAITPNE/WAITPEQ + timeout.
bittled: Will it be 5V tolerant?
CHIP: I/Os are not 5V tolerant - 3.6V max.
Bean: Yes, I assume PINA, PINB, PINC, PIND ?
CHIP: Bean, yes. I/O regs start at $1F8: PINA, DIRA, PINB, DIRB, PINC, DIRC, PIND, DIRD.
Bean: I assume DIRA, DIRB, DIRC, DIRD, OUTA, OUTB, OUTC, OUTD are the 8 registers ?
CHIP: Yes, PINA..PIND with each of those REASSIGNABLE to whatever you want, so you can hardcode PINA..PIND, but initialize them on entry to point to whatever ports you want. They initialize to Port 0..3.
CHIP: Localroger, yes, same I/O voltages as current Propeller chip.
CHIP: Power requirements... Don't know yet, but extensive clock gating is used, so should be lower that current Prop.
CHIP: Supply voltages: core = 1.8V, I/O = 1.8V..3.3V
Al Booth: Do the 1.8V and 3.3V supplies need special sequencing on power-up and power-down?
CHIP: No special sequencing is needed on power.
CHIP: Packages... right now just planning on 14x14mm TQFP-128.
CHIP: Yes, the package is very dense, but it has to be to pack 128 pins. It's either that or a ball-grid array.
bittled: Will you have a breakout board for the Prop II for breadboarding?
CHIP: Breakout board... Absolutely!
CHIP: ...Probably a few breakout boards.
CHIP: There is 3D graphics stuff, too... texture lookup/lighting/alpha-blending. 8-bit quality on R/G/B.
reltham: With DIRA-DIRD and such, that is room for 128 ports/pins... with only 92 physical pins, are the other spots some form of internal thing?
CHIP: Roy, three 32-bit ports are implemented, though the last port's 4 highest pins are missing, since those got used on the package for XI/XO/BOEn/RESn.
CHIP: Each 8-bit port has its own set of power/ground pins for voltage selection and noise reduction.
CHIP: Forgot to mention... 3 ports, minus 4 pins, are implemented, the last 'port' is the cog pipe, where each cog can filter what he's seeing from the other cogs' pipe outputs.
Roger Lee: scientific calc. Floatpoint?
CHIP: No floating point, but multiply, divide, square root, and transcendentals via cordic, plus EXP and LOG via cordic.
Yeah, it seems fine to me.
John A. Zoidberg: btw are hardware dividers and multipliers included in Prop II?
CHIP: John, yes. 64/32 divide, 32x32 multiply, 32->16 sqrt, and cordic is all in hardware.
Al Booth: Does the 32x32 bit multiplyhave a 32 bit or 64 bit result?
CHIP: The 32x32 mutiplier has a 64-bit result. The 64/32 divider has a 32-bit quotient and remainder results.
CHIP: There is a separate 16x16 signed/unsigned single-cycle multiplier that executes from these instructions: MUL, MULS, MAC, MACS. The MAC instructions sum into a signed 64-bit accumulator.
CHIP: Some stuff about the CTRs...
CHIP: They can input ADC streams from the pins and run a Goertzel algorith, which is like a live slice of an FFT.
CHIP: Also, CTRs can read ADCs from pins and do PWM output without any hand-holding from the cog, so these will work in Spin, or other high-level languages.
Sapieha: Chip --- Can that CRT's generate 3 phase syncronized waves in one COG? with Sinusoid waves
(Cant find adequate answer)
CHIP: Oh... some more stuff about the new CTRs. Each is a sine/triangle/sawtooth/square function generator w/scale and amplitude for output to the DACs.
eod_punk: Any chance of built in DTMF support like the BS2?
CHIP: Since each cog has two CTRs, and each CTR can generate a sine, and each DAC channel can sum the outputs of its cog's CTRs, you can do this over one pin, hands-free.
CHIP: So, with the Goertzel in CTR hardware, and 50MHz ADC BW, you should be able to demodulate IF's pretty well.
John A. Zoidberg: By the way - will the new Prop II compiler will have easier access to counter modules?
John A. Zoidberg: Because I had a hard time using the counters for the Prop I in Spin and ASM
CHIP: In a way, because of the hands-free modes, the CTRs will be more useful under Spin.
John A. Zoidberg: On top of that - i read that these have a built-in Func.Generators:?
trodoss: Are you still planning on having the embedded ROM font?
CHIP: ROM font is still the same, though we'll probably add a smaller font, too, like an 8x12.
CHIP: Roy, 8x8 what?
CHIP: Okay... 8x8 font. Can do. It's small.
John A. Zoidberg: So there are shared ports in dira/dirb for aDCs and comparators? all needed to set in the respective config registers during startup?
tdlivings: Connecting to the A/D how close, for delta sig P1 had to be on top of chip
CHIP: About connecting ADC stuff - no need for multiple pins - it's all built-in, just connect your signal to the pin.
CHIP: There are special ADC modes within the pins for doing a very high-Z feedback delta-sigma between two adjacent pins for digitizing data from passive weak-signal sensors. Should be useful for lots of new things.
tdlivings: Because the ADC can be done inside the pin, there are no special considerations about trace length or pin numbers.
CHIP: Because the ADC can be done inside the pin, there are no special considerations about trace length or pin numbers.
microcontrolled: Can the built in ADC be used in direct replacement of an external IC?
CHIP: Yeah, there should be no need for external ADC chips. Not only can you do voltage ADC, but you can do current-feedback ADC between two pins to read funny stuff, like a loop of wire, or something.
microcontrolled: I saw something mentioned earlier about sigma-delta. Does this mean that the Prop II will take direct potentiometer input, with no external caps needed?
CHIP: For reading a potentiometer, just connect the outer legs to VSS/VDD and connect the center-tap to an I/O pin for conversion. Nothing else needed.
tdlivings: Sounds like I do not need my DDS chip anymore
tubular: any idea of ADC input impedance yet?
CHIP: ADC input impeadance is ~4M ohms.
CHIP: About DDS... The sine generator uses a 9-bit phase lookup table with 9-bit quality output. The scaling is done with a separate 9-bit coefficient, hence the 18-bit settable DAC outputs.
John A. Zoidberg: So, how many DDS channels does the prop II have?
Chris Savage: So "PINx" handles both INx and OUTx that the Prop 1 has as seperate registers ?
CHIP: Yes, PINx is both OUTA and INA in one, but don't get worried... Whenever you perform a write/r-m-w to a PINx register, it writes to OUT, whereas a read-only operation, cause IN to be read.
Bean: So "PINx" handles both INx and OUTx that the Prop 1 has as seperate registers ?
CHIP: About the PINx registers. These: TEST PINA,mask or TEST mask,PINA both cause the IN to be read, not the OUT.
CHIP: Extra about the 3D stuff - the texture lookup is perspective-correct, which means a hardware divide is being performed for each texel lookup.
Oldbitcollector: talk about multi-propeller2 considerations. Anything special there for us? Timetable to release. What's next?
CHIP: Multi-Prop II possibilities. They're there, facilitated by those fast serializers.
CHIP: To do multi-PropII apps, it's a matter of development tools. The chips can talk amongst themselves pretty easily.
Oldbitcollector: Timetable to release date? What's next?
Release date... We've got a test chip in fab now, but it's just to prove the memories, PLLs, I/O pins, etc. A final chip is a matter now of converting my FPGA code into a schematic, and then Beau laying it all out.
Release date... If we go standard cell place-and-route, it could be 6 months, otherwise, full custom will take another several months. Hard to say. Never good at it.
eod_punk: Have you had to take something out/reduce something that you didn't want to leave out/reduce? Biggest trade off you had to make?
CHIP: Well, we wanted a heck of a lot more ram, like 512KB, ideally. The cogs are such pigs now, that we can only fit 128KB. The good news is the pins are setup for doing
CHIP: SDRAM signalling and there is a hardware facilitator for moving data between SDRAM and hub
CHIP: SDRAM comes in 32MB for about $3. That's enough RAM to build console applications in. I really want to make a nice PCB layout program, but don't want to write it on the PC. I hope to do it on Prop II.
John A. Zoidberg: By the way - u mentioned about SDRAM controllers. How are SDRAMs important in microcontroller applications? Work things better?
CHIP: SDRAM is just BIG, cheap RAM!!! Having lots of memory opens lots of new doors.
CHIP: Chip design tools, too, would be fun to write.
tubular: Chip can you please give us an overview of what you're aiming for regarding security features?
CHIP: For security, we are planning to use poly silicon fuses for giving each chip a 128-bit key that can be used with some block encryption standard. The user can program the key himself.
CHIP: More about the security fuse bits... The ROM program will read the key (which is afterwards hidden) and perform downloading/loading, then start execution.
reltham: How is the CLUT arrange for colors? 16bit 24bit color?
CHIP: The CLUT is 128 longs. There are many modes of output which can use 4, 8, 16, or 24 bits to signify color.
CHIP: The CLUT can stream to the video like a FIFO, or you can hand off one set of pixels and scale at a time per WAITVID.
Sapieha: What types of media to load from?...
CHIP: What types of media to load from?... serial, USB, I2C EEPROM, SPI EEPROM, SD CARD. Any others that it should be sensitive to?
SDCARD, from what I know is just SPI, maybe 4-5 pins to work.
We would use FAT for loading off SDCARD, or, if some signature was present in the first bytes, just stream it in directly.
John A. Zoidberg: Btw any special interfaces for SDCARD?
CHIP: FAT would have to be supported to make things nicely compatible with the PC world.
CHIP: The chip, with SDCARD and SDRAM, could nicely host some O.S.
What are MADDs?
realthm: @JohnR, Multiply ADD
CHIP: MADD will go well with the SEUSSF and SEUSSR instructions, which circulate an invert bits through a Dr. Seuss-like pattern.
blittled: Will the Prop II be able to interface with USB easily since PS2 keyboards and mice are becoming outdated?
CHIP: About USB... Each even/odd pair of pins can form a 30MHz differential input, so you can make USB all over the place. There are also 1.5k resistors you can turn on in the pads to set the USB mode.
CHIP: How many hours designing Prop II... I don't know. It's been 4.5 years since the Propeller was finished, and this is the only project I've been working on. It's got to be several thousand hours, so far.
CHIP: Yes, Beau's been working several years now on the layout stuff. He designed every single polygon that is in the chip. There is nobody else's "IP" in there.
How about a double-barreled bit shifter?
CHIP: Yes, there is a barrel shifter just like in the current Prop. We've just got lots of new instructions.
CHIP: A barrel shifter is something that can shift any number of bits at once, as opposed to just one bit-position at a time.
CHIP: If you can do SHR reg,#20, that's a barrel shifter.
eod_punk: Has any other microcontoller influenced you in making the Proppeller 2?
CHIP: I've never used an Arduino, but have heard that many people like them. I heard it uses a type of C. That's about all I know about its technicality.
localroger: Not a P2 question but something I have always wanted to ask: how did you make the break from what everyone else was doing to the P1? I have been swimming in CPU's since 1974 and I would never have thought of it. So tell me whatr I missed!
CHIP: @localroger - I just new we needed something that could execute mutiple programs at once. I tried lots of different things on the FGPA, but then settled on simple cogs w/each having its own peripherals, and then all cogs sharing a common RAM, for comm.
CHIP: Yes, we plan on making the Prop I for as long as the process is available. It'll be around for at least another 15 years. MOST new IC designs actually use .35um technology, which is what the Prop I uses. Something like 70% of tapeouts target that process.
CHIP: Compatibility... There are many new instructions in the Prop II. The memory map is 32-bits, though we can't realize much of it.
Oldbitcollector: yes. will I be able to run my Prop1 code on the Prop2?
CHIP: You will have to rewrite your code in cases where you are doing new I/O stuff. For the most part, Spin routines should compile as they do now.
Beau Schwabe: @Chip Gracey - on Compatability between PropI and PropII - it sounds as though in some cases a simple text translator might be able to convert the differences.
CHIP: @Beau, the differences will probably go beyond text translation, as they mainly revolve around new possibilities.
CHIP: About 3D graphics... We have, thanks to Andre patient helping me to understand what we needed to do, a texture-mapping system with lighting and blending. It's rudimentary by today's standards, but gets you into the ballpark.
CHIP: I think 3D graphics will be especially neat for showing sensor data in nice ways.
CHIP: Instructions are almost all 1-cycle. Exceptions are the same we have now, like hub accesses. You can read four longs at once into cog ram, then execute them.
Bean: Are instructions 1 cycle ? Also is LMM execution (running code from the hub) supported by hardware / faster ?
CHIP: That is what facilitates LMM programming. Otherwise, there is no special case of LMM execution.
CHIP: @localroger - if a child could visualize a CPU, he could design one. It's like lego's.
CHIP: ADC bandwidth... If the chips is running at 160MHz, Nyquist says you'll get 80MHz bandwidth, but 50MHz would be more like it, as the aliasing would average out better.
CHIP: ADC input impeadance is ~4M ohms.
Sapieha: We are missing You on FORUM!
CHIP: I want to get back on the forum, but haven't been able to log in, so I've just been working.
electromanj: Given the track record of the BS1, I assume the PROP1 will be around for a while?
CHIP: Yes, we plan on making the Prop I for as long as the process is available. It'll be around for at least another 15 years. MOST new IC designs actually use .35um technology, which is what the Prop I uses. Something like 70% of tapeouts target that process.
CHIP: Full instruction set... I'll give to Daniel at Parallax for posting. Or, I'll find out how to get on the forum and do it myself.
Comments
Hi CHIP.
As I said in Thread title " Some extra questions will come" ---> Now them come. Still not all of them.
CHIP - My first question are to clarify some misunderstanding on SERIALIZER?
I asked "Sapieha: But --can them send/receive both as syncron and asyncron? --> Need be - Asynchronous/Synchronous"
That maybe confused YOU!
As You answered ---> "CHIP: Yes, the serializers are asynchronous. The all feed off a common clock that someone supplies."
Now Look on attachment PDF -- That maybe give You more readable picture in You mind what I have mean on that.
Next question I have is: Will it be instructions to possibility of use COG's CLUT memory in user friendly requirement.
WOW! The Prop II just keeps getting better (apart from the loss of hub Ram). I want one, I want one, I want one... LOL
But I agree: Chip's assertion is contrary to what's been said before.
-Phil
"CHIP: Power requirements... Don't know yet, but extensive clock gating is used, so should be lower that current Prop. "
So if the same clock speed was used, the P2 would be more efficient than the P1? This is contrary to what has been said before, and is a very good thing!
I really liked what the SX had. Being able to run assembly code at full speed and then stop at a breakpoint is really useful. It would be nice if the P2 was able to to do that.
Bean
I wasn't able to register for some reason. Your summary might even be better than 'attending', tho some comments might have been missed. Thank you for doing this.
Thanks to Chip Gracey for the update on the Prop 2. Sounds like no one will be able to use everything on this smorgasbord microcontroller. WOW!!! I think it will be a Joy to use it.
Only comments that are missing That Chip said are about Walnuts.
Thanks Saphiea for posting all this.
I noticed a question about serializers that seemed to be unanswered.
Was there any mention at all about deserializers or even DMA?
Did you miss this:
Or this:
All sounds quite amazing.
That Question was partially answered.
Serializers ---> As I proposed to Chip are BOTH Serialize/DeSerialize.
It Was not any discutions on DMA ---> I was not directly interested in first place -- And Not any other raised that Question
So, I think I'll need 3 SDRAMs... One for code and 2 as video buffers...
Let me see... That 16data+20control * 3=108 ... Ugh Oh, I'm out of pins already
Most of us have asked about all kinds of stuff on Propeller2. No one "owns any of the ideas" except Chip and that is only because he is the implementer
There were discussions of other types of DMA before - I wonder if the SDRAM offers any input kick other than providing the clock (which can be done today). Curious that 16 or 32 bit only interfaces were mentioned for SDRAM
@Rayman, shhh! Give Chip a chance to ship this design
Nice; - what silicon cost is there, to have these HW maths operations on all COGs ?
I see NXP have an Asymmetric Dual core part just released.
That seems a very good way to avoid silicon bloat, and so allow the vital MORE RAM.
Could the P2 fit in more RAM, if the COGs were made with a common base, but
less 'fruit' on some ?
As an example Compact ones could call ROM Maths routines, to make the differences between HW and SW extended precision, more user-invisible ?.
Just trying to make sure I have this counter detail right.
triangle/sawtooth/square are possible with a flexible counter+DAC, but Sine needs a look-up table. (RAM or ROM ? )
Does this mean each counter/DAC includes a small table ram, which can also do that
'colorspace converter matrix' ?
Q: What size is what I'll call Pin-Table memory ?
If the ports can dual-edge-triggered serialize at 400mbps, can the counters
count/capture at that 2.5ns speed, or just 200MHz, or is it some lower-still speed ?
My ideal Counter-pin-structure config option, allows One counter to Divide a PinFreq by N (1..2^32), and the TC of that Divider, to capture a highest-speed timebase counter.
(viz a reciprocal frequency counter. just add the 32*32->64 -> 64/32 )
With 2 Counters present per pin, the large building blocks seem to all be there!!.
Q:Will the details support the interconnections I describe ?
It has been said before that the price of the Prop II was aimed to be (IIRC) < $10.
Now, I am presuming from what has been said, that the Prop II die just fits the QFP128 package and that is why we cannot have more Hub Ram.
Could a larger die be used with a bigger package to get say 512KB of Hub Ram??? Everything else the same, so either the extra pins would be no-connect or wider spacing (I am unsure of ramifications here).
I would much prefer a 512KB Hub Ram Prop II in a QFP196 (or QFP128 with bigger pin spacing preferred) for $12-$14. Perhaps BEAU could comment further???
BTW I agree, nothing will kill the current Prop 1. It will continue to be used in various places. The Prop II will only seek to further legitimise the Prop 1 and to make it more visible to professionals.
Right now with the pitch size of the I/O's and the current 128 pin package, we are "CORE" limited as opposed to "PAD" limited. What this means is that we are limited physically as to what we can fit in the core based on the current package and available room remaining in the core. The I/O's could actually grow slightly in size if needed.
Saying that it's not by a huge amount that they 'could' grow. The I/O's themselves are packed with stuff of their own.
It's a balancing act ... reduce the I/O pad size and you gain more core space losing functionality of the PAD ... reduce the core space requirement and gain I/O functionality but at the cost of losing core functionalty.
In a system that requires both to make to make it work the way everyone wants it to, it's a complex juggling act.
Going to a larger package isn't such a huge deal, going to a larger die size becomes cost prohibitive, but it would eliminate being "CORE" limited.
EDIT:
One of the tests that we can determine with the test die is just how much current and I/R drop we get across the power and ground rails which are built within the PADs that makeup part the power ring that goes all the way around the chip.
Right now they are 100 microns wide totaling just over 400 microns 'JUST' for the power/ground rings... remember VIO,GIO,VDD, and GND ... The 'I/O PAD guts' are built underneath these power/ground lines. However if they can be reduced even by 50 microns, that's a difference of about 1.4 Million square microns gained in the core.
Can you comment on the power requirements? It was my impression that the smaller feature size entailed more leakage current and a much higher power consumption than the Prop I. But Chip's recent comments seem to indicate otherwise.
Thanks,
-Phil
"It was my impression that the smaller feature size entailed more leakage current and a much higher power consumption" - Compared to 350nm (<-- Prop I) this is true, but the leakage for the Prop II should be comparable to other 180nm processes. The exact numbers we won't know until we get our hands on the test die. Outside of that we only have what the simulator is telling us.
-Phil
I sort of understand that you have balanced the I/O space with the core space. So, if you increase the core size (i.e. increase hub ram) then there will essentially be unused I/O space which has to be paid for in wasted die space. Die size translates directly to chip cost.
I do not know if anyone else agrees, but I would rather 512KB of Hub Ram with a larger die size. I am prepared to pay $2-$4 for this.
So, my question is, everything else remains the same (except maybe the package to accommodate the larger die) .....
Is it feasible to increase the hub ram to 512Kb and how much would the cost increase (estimate) ???
If it is within say 25% extra, then perhaps a poll to see if it would be viable?
Yeah, I know it's a big deal, but the difference between 350nm and 180nm is really low in comparison to other processes.
- At 350nm the leakage is about 7% of the total consumed power
- At 180nm the leakage is about 16% of the total consumed power
- At 90nm the leakage jumps to almost 40% of the total consumed power
Cluso99,
I'm not sure it would be a simple matter of just going to a bigger die size along with a bigger package size for a couple of dollars extra per chip. I think there is a significant jump in price.
What you are paying for is silicon real-estate. Look at it this way... a die that measures 6mm square is going to have 36 million square microns. Compare that to a die that measures 8mm square with 64 million square microns ... increasing the die just 2mm almost doubles the silicon real-estate.
The 'next' available die size increase looking at it this way would be cost prohibitive.
Another factor... the bigger the die, the lower the yield in two ways... the lower the yield in terms of how many can physically fit on a wafer, and the lower the yield as far as how many IC's are actually good. A typical yield per wafer due to process variations is about 85%-95%... this factor goes down as the size of the die increases.
, or (and this is a wild guess)
volumes need to be 8x to justify that?
Seems to me then, the smaller size, has less variance, but isn't as competitive, but costs less to compete.
The larger sizes must then be reserved for known proven designs in demand? A new design, really needs to be optimal, in order to yield a "burn rate" sufficient to spark demand? Don't know about optimal, but the overall risk / attempt at the market is favorable to the smaller size by a considerable factor, thus a smarter wager.
Close on that?
If so, very interesting dynamics in play here. Thanks for sharing!
That's a good summary, the cost per wafer is also very high, not sure right off hand what it is, but it factors in just as well.
...unless risk is mitigated with some known demand, then it's just a cost / margin equation.
I love it when you talk MBA
This chip will pack some very serious features, good !!!
That would make the size of hub RAM almost irrelevant and let people write SPIN code of unlimited size...