It shuttles bytes/word/longs of I/O pin data to/from hub RAM at up to 32 bits per clock.
and this ?
and smart pins
If the streaming R/W HW is already there, for 8/16/32-wide transfers, at Sys-clock speeds, then that is the hard data-path stuff done. Sounds quite impressive to me, and a desirable feature - LCD & Camera IO were other requested IO support areas, and looks like Chip has nailed that, plus CLUT and DDS/Goertzel too !
This parallel HW will need some strobe signals for most common I/O (LCD out, Camera In etc), so I'd expect QuadSPI and HyperBUS (etc) to come via a few config bits, now the Data-Path is there.
Even SDRAM support is largely covered, with the mentioned choices of 8/16/32b wide to/from streaming data paths.
Leaves CLK and RAS/CAS phasing to manage.
LOL, I just realised JDat wasn't being facetious ... it's so common for english speaking pep's to use the opposite meaning that I'd not thought to look back and check context. Damn, it must get a tad frustrating for non-native english speaking how fast our slang changes at times.
Back to P2.
1) Is there any detailed information how smart pins will work?
2) Will smart pins work in differential mode? Useful for direct LVDS bitbang (ethernet, DSI/CSI). Alternative: use LVDS driver IC.
3) Is it possible to use smart pins as binary counter and/or register output? Useful for SRAM addressing. Yes, it take lot of I/O pins but anyway...
4) What about current source and/or current sink mode? Useful for I2C, 1- wire. Alternative: OUTA(i2cDATA):=LOW and switch from hi to low with DIRA[i2cDATA]~ or DIRA[i2cDATA]~~ plus pullup (or rare situations pulldown).
5) Will on P2 be oly one global video generator? This will consume less space than 8 generators on P1.
6) What about other onchip peripherals? CORDIC module (great idea)? What else?
7) What about ISA on P2? Any information?
8) Sounds, that access from COG (yes, COG, not Core) to HUBRAM will be much, much better.
9) HUBEXEC? Interesting...
10) Code protection: A musthave feature!
3) Is it possible to use smart pins as binary counter and/or register output? Useful for SRAM addressing. Yes, it take lot of I/O pins but anyway...
Smart pins will have counters, but who would use parallel SRAM (in volume)?
There is cheaper, smaller and less-pin-cost Serial memory & SDRAM available now.
Parallel Address counting will always have some limit, and the 'how many pins as address?' question is open
5) Will on P2 be oly one global video generator? This will consume less space than 8 generators on P1.
See Chips recent post.
The DAC's are not per-COG, but per-pin, so the Video Generation is split between .COG for data-path (which can stream from Hub, via CLUT), and Pins
Chip now also has added the 8/16/32b parallel paths per-COG (R/W & DDS clocked (!), see earlier discussions on this), for LCD type video (and a whole other raft of uses..).
Multiple data-paths could be needed, as they are useful for not just video, so that is why Chip has placed that per-COG.
That last point is what I was about to say regarding multi video capability.
The old generator in the hot chip did too much. By splitting it like this, we still get the benefit of multiple streams and COGS, but now we also get a more generally useful thing. And input as well as output.
The video details, color, etc... all go back to software like in the P1. If the COGS so hit 200Mhz, there is plenty of time for them to do what most of the dedicated hardware was doing.
And we get 2x the cogs, which significantly decreases the cost of simple displays and streams.
The video details, color, etc... all go back to software like in the P1. If the COGS so hit 200Mhz, there is plenty of time for them to do what most of the dedicated hardware was doing.
200MHz COG clocks is unlikely, but there is also this
["It uses a 256x32 look-up RAM for outputting pixel-type and DDS/Goertzel data."]
(plus some implied small FIFOs in the COG-HUB link, to allow SysClk/N & DDS rates )
All up, a great example of the HW doing the data flow, and the SW being used for what SW does best.
Wow! At least I found specs for P2. Evanh! Thank you for pdf link in dark silicon thread. Sorry, I too young in propeller stuff (1 year). It's hard to read 130 pages about P2. Need more input (read: links) about P2.
Wow! At least I found specs for P2. Evanh! Thank you for pdf link in dark silicon thread. Sorry, I too young in propeller stuff (1 year). It's hard to read 130 pages about P2. Need more input (read: links) about P2.
Ah, you've found that. I'm starting to feel the need to collate the time line ... my own memory has failed me badly ...
I saw a similar idea using two 8 bit dac's on a 16 bit address bus with the outputs going to the X and Y inputs of an oscilloscope. Very helpful for debugging.
There was a 1970s BYTE article that featured this on an Altair. It was cool to watch a basic program run. It was a decent looking tool. The article included a schematic.
There was a 1970s BYTE article that featured this on an Altair. It was cool to watch a basic program run. It was a decent looking tool. The article included a schematic.
Probably where I saw it as well. Unfortunately with the higher bus speeds and larger memories of today it may not be as practical or useful today as it was back then.
There have been almost a thousand views of this thread in the past 3 days. This indicates to me that there are many people out there waiting for the P2 to appear. Things should get really exciting on the forum when Chip posts the P2 FPGA image in the next few weeks. 46 days and counting.
... meanwhile, I see the 800lb gorilla that is intel, is rediscovering 'Microcontrollers' with parts listing in distributors for under $10 in moderate volumes, and images of a new button module with 384KF and 80KB RAM - for intel, those numbers are miniscule. I've not found data on that coming device, or even if the Flash is on-chip, stacked die, or separate. I doubt intel would do on-chip flash, but XIP QuadSPI could.be done.
Where's those hours, minutes and seconds? PS: Did you ever doubt how cool the Prop2 is? Posting the FPGA image willl crash the website!
That depends on which FPGA boards will be able to run it. If it's restricted to the Parallax board and the DE2-115 then there might not be as many takers. I'm hoping at least a minimal configuration will run on a DE0-Nano.
That depends on which FPGA boards will be able to run it. If it's restricted to the Parallax board and the DE2-115 then there might not be as many takers. I'm hoping at least a minimal configuration will run on a DE0-Nano.
..and something that can run on a MAX10, like maybe SmartPin testing on a P1V host.
... meanwhile, I see the 800lb gorilla that is intel, is rediscovering 'Microcontrollers' with parts listing in distributors for under $10 in moderate volumes, and images of a new button module with 384KF and 80KB RAM - for intel, those numbers are miniscule. I've not found data on that coming device, or even if the Flash is on-chip, stacked die, or separate. I doubt intel would do on-chip flash, but XIP QuadSPI could.be done.
The Curie is indeed kind of neat, although very sparse information is available.
Not even sure if it is X86.
I read somewhere it is a Quark family member, but they could have pruned some super-set opcodes.
Certainly be interesting to see more complete data, as those Flash + RAM numbers are quite small for intel.
I read somewhere it is a Quark family member, but they could have pruned some super-set opcodes.
Certainly be interesting to see more complete data, as those Flash + RAM numbers are quite small for intel.
Comments
Fancy I/O can be addressed when Chip gets to doing SmartPins. He's already indicated forum input will be requested at that time.
It shuttles bytes/word/longs of I/O pin data to/from hub RAM at up to 32 bits per clock.
and this ?
and smart pins
If the streaming R/W HW is already there, for 8/16/32-wide transfers, at Sys-clock speeds, then that is the hard data-path stuff done. Sounds quite impressive to me, and a desirable feature - LCD & Camera IO were other requested IO support areas, and looks like Chip has nailed that, plus CLUT and DDS/Goertzel too !
This parallel HW will need some strobe signals for most common I/O (LCD out, Camera In etc), so I'd expect QuadSPI and HyperBUS (etc) to come via a few config bits, now the Data-Path is there.
Even SDRAM support is largely covered, with the mentioned choices of 8/16/32b wide to/from streaming data paths.
Leaves CLK and RAS/CAS phasing to manage.
Back to P2.
1) Is there any detailed information how smart pins will work?
2) Will smart pins work in differential mode? Useful for direct LVDS bitbang (ethernet, DSI/CSI). Alternative: use LVDS driver IC.
3) Is it possible to use smart pins as binary counter and/or register output? Useful for SRAM addressing. Yes, it take lot of I/O pins but anyway...
4) What about current source and/or current sink mode? Useful for I2C, 1- wire. Alternative: OUTA(i2cDATA):=LOW and switch from hi to low with DIRA[i2cDATA]~ or DIRA[i2cDATA]~~ plus pullup (or rare situations pulldown).
5) Will on P2 be oly one global video generator? This will consume less space than 8 generators on P1.
6) What about other onchip peripherals? CORDIC module (great idea)? What else?
7) What about ISA on P2? Any information?
8) Sounds, that access from COG (yes, COG, not Core) to HUBRAM will be much, much better.
9) HUBEXEC? Interesting...
10) Code protection: A musthave feature!
Many of your questions are already answered in the P2 threads,
Smart pins will have counters, but who would use parallel SRAM (in volume)?
There is cheaper, smaller and less-pin-cost Serial memory & SDRAM available now.
Parallel Address counting will always have some limit, and the 'how many pins as address?' question is open
See Chips recent post.
The DAC's are not per-COG, but per-pin, so the Video Generation is split between .COG for data-path (which can stream from Hub, via CLUT), and Pins
Chip now also has added the 8/16/32b parallel paths per-COG (R/W & DDS clocked (!), see earlier discussions on this), for LCD type video (and a whole other raft of uses..).
Multiple data-paths could be needed, as they are useful for not just video, so that is why Chip has placed that per-COG.
The old generator in the hot chip did too much. By splitting it like this, we still get the benefit of multiple streams and COGS, but now we also get a more generally useful thing. And input as well as output.
The video details, color, etc... all go back to software like in the P1. If the COGS so hit 200Mhz, there is plenty of time for them to do what most of the dedicated hardware was doing.
And we get 2x the cogs, which significantly decreases the cost of simple displays and streams.
200MHz COG clocks is unlikely, but there is also this
["It uses a 256x32 look-up RAM for outputting pixel-type and DDS/Goertzel data."]
(plus some implied small FIFOs in the COG-HUB link, to allow SysClk/N & DDS rates )
All up, a great example of the HW doing the data flow, and the SW being used for what SW does best.
It shuttles bytes/word/longs of I/O pin data to/from hub RAM at up to 32 bits per clock.
some interesting numbers are found here, for PHY connections
http://en.wikipedia.org/wiki/Media-independent_interface
Even the GMII might be just reachable ? - that needs Bytes streamed at 125MHz
Back to P2....[/QUOTE]
Latest update - http://forums.parallax.com/showthread.php/160694-Dark-Silicon?p=1325000&viewfull=1#post1325000
Ah, you've found that.
There was a 1970s BYTE article that featured this on an Altair. It was cool to watch a basic program run. It was a decent looking tool. The article included a schematic.
Probably where I saw it as well. Unfortunately with the higher bus speeds and larger memories of today it may not be as practical or useful today as it was back then.
April May June Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa -- -- -- -- 1 2 1 2 3 4 5 6 -- -- -- -- -- -- -- 3 4 5 6 7 8 9 7 8 9 10 11 12 13 -- -- -- -- -- -- -- 10 11 12 13 14 15 16 14 15 16 17 18 19 20 19 20 21 22 23 24 25 17 18 19 20 21 22 23 -- -- -- -- -- -- -- 26 27 28 29 30 24 25 26 27 28 29 30 -- -- -- 31May June Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa -- -- 1 2 3 4 5 6 3 4 5 6 7 8 9 7 8 9 10 11 12 13 10 11 12 13 14 15 16 14 15 16 17 18 19 20 17 18 19 20 21 22 23 -- -- -- -- -- -- -- 24 25 26 27 28 29 30 -- -- -- 31Where's those hours, minutes and seconds?
..and something that can run on a MAX10, like maybe SmartPin testing on a P1V host.
Pffft! Who wants that mess?
ARM first.
Not even sure if it is X86.
I read somewhere it is a Quark family member, but they could have pruned some super-set opcodes.
Certainly be interesting to see more complete data, as those Flash + RAM numbers are quite small for intel.
I saw Quark mentioned several times as well.