I think there is a typo with those instructions in that pdf.
Here's my understanding of how they work. For DECOD5 if the register passed in contained a value A between 0 and 31, then it would write back into that register a value with the A bit set and the other bits 0. For DECOD4 if the register passed in contained a value A between 0 and 15, then it would write back into that register a value with the lower 16bits having bit A set and the upper 16bits having bit A set (all other bits 0). And so on for the rest with more repeats as the size of the "field" shrinks.
Parallax is looking at having a test chip in hand within 4 months. Chip also said that if (and that is a big if, as there are an incredible number of details that have to be accounted for) everything goes smoothly, chips can be in your hands in 6 - 9 months from now.
Fingers crossed, we may get a nice Christmas present?
:-)
This PDF don't say anything - Mostly only what instructions we will have in assembly (Some very bad described to) .
As jmg pointed in other threads it leaks much of important info on some Hardware solutions and even some instructions functions.
As I pointed many times and even jmg point in theirs threads --- Some things are simply waste of silicon.
And degrade possibility's what will be possible on PropII.
Even if I see some nice solutions -- Total words on it --- Are not so good.
Sorry Parallax --- It was possible to be better -- But if any look only on single peoples NEED's not at How much people need find it usable -- It will always be bad directions taken.
Well I have read the docs. I basically concur with Sapieha's comments. I was expecting a lot more info. Really, it is nothing more than a brief instruction set summary, and for that you have to know the Prop 1 instructions. I guess it is really an end of year availability at best - yeah 6 mths is October but it will be Xmas at least.
So, having that off my chest, there is plenty of time for the info to be detailed better.
I found the external ram access interesting... 5ns cycle time, 16bit.
I could not work out how the quadlong cache works - actually how does it fill ?
I am extremely disappointed that there appears to be no silicon to permit those fantastic registers to be used to clock anyting into them. What a waste for a tiny piece of silicon. Please tell me I am wrong???
I note that we cannot set the carry on a hub read. I don't think that matters because we can still set the zero flag.
Does TJZ/TJNZ(D) set the Z flag (WZ)? Same for IJZ/IJNZ(D) & DJZ/DJNZ(D) ?
Table 16 OFFP mneumonic? Does this toggle the DIR for the Pin? OFF seems wrong for TOGGLE ?
Table 18 SETSER How are the pins set with only 0-63 ?
Table 19 SETMAP How does register mapping work ?
errata:
Table 5 COGINIT, etc missing the word "access" in operation
Table 14 INDA & INDB word "my" should be "by" in operation
I am extremely disappointed that there appears to be no silicon to permit those fantastic registers to be used to clock anyting into them. What a waste for a tiny piece of silicon. Please tell me I am wrong???
That's how I read it too, A highly custom Prop-prop serial support, even with special opcodes, but no Standard SPI, and no QuadSPI.
There are a LOT more QuadSPI devices out there, than Prop II's !!
QuadSPI would allow execute in place at much higher speeds. Cost is a handful of gates/ff. Opcodes & SFR are there already.\
I'm frankly stunned they missed this.
There's been some nice enhancements to the single-cycle multiplier since the last version of the spec. It's been increased from 16 bits to 24 bits, and there're instructions to normalize the product. This should make floating point operations execute much faster.
Is there a way to diff two PDF files? It would be helpful to know exectly what has changed since the last version was posted.
I think the Prop 2 sounds fantastic! I'm not sure what the quibbling over SPI is about - SRAM transfer will be enormously faster than any QuadSPI. Same folks who think the design has been compromised by catering to just a few users are those who want Chip to cater to them, seems to me.
Boot device information appears to be missing from the spec. As I recall it will be a SPI device interface.
I asked Chip if he could arrange it so that we could use a QuadSPI device without having to disassemble/reassemble nibbles - see below.
Assuming CS is highest pin number under the serial port pins and CLK is next highest, you get a configuration something like this which leaves 80 P2 pins available for generic usage.
P(n) = CS
P(n-1) = CLK
P(n-2) = SI or IO0
P(n-3) = SO or IO1
P(n-4) = WP or IO2
P(n-5) = HOLD or IO3
P(n-6) = SI or IO0*
P(n-7) = SO or IO1*
P(n-8) = WP or IO2*
P(n-9) = HOLD or IO3*
Note*: use with 2nd QuadSPI chip for a byte-wide interface. CS/CLK shared with 1st and 2nd QuadSPI chip.
SRAM transfer will be enormously faster than any QuadSPI.
This is only correct for a small number of bytes at a time on typical asynchronous SRAM. For more than say 8 bytes at a time synchronous device like QuadSPI or SDRAM (more than 8 bytes at a time) will perform better with the P2 design. On P1, synchronous devices perform better than stock SRAM reads when using QuadSPI pins (other conveniences like more pins available and maintaining normal serial port usage are not sacrificed). The same advantages could be enjoyed by connecting 74*161s with an asynchronous SRAM, but then you start having even bigger real-estate issues.
I did a side-by-side comparison of the V1.3 document with the V2.0 document, and I compiled a list of chnages. The clock rate was increased from 160 MHz to 200 MHz while maintaining the same number of instruction pipeline delays. The size of the color lookup table was increased from 128 longs to 256 longs. The hub RAM was decreased slightly from 128K to 126K. The single-cycle multiplier was increased from 16 bits to 24 bits, and normalization instructions were added. There are now 2 64-bit accumulators used with the multiply-accumulate instructions.
A cached read-quad instruction was added. An instruction that gives the number of clock ticks since the last time it was used was also added. A summary of the changes in the instructions is given below.
V1.3 V2.0
Instruction Change Instruction
----------- ------ -----------
added RDQUADC
POPUPA renamed to POPAR
POPUPB renamed to POPBR
PUSHDNA renamed to PUSHAR
PUSHDNB renamed to PUSHBR
GETCORX renamed to GETQX
GETCORY renamed to GETQY
GETCORZ renamed to GETQZ
SETCORX replaced by SETQM
SETCORY replaced by SETQI
SETCORZ renamed to SETQZ
CORDROT renamed to QROTATE
CORDATN renamed to QARCTAN
CORDEXP renamed to QEXP
CORDLOG renamed to QLOG
added QSINCOS
added SUBCNT
MAC replaced by MACA, MACB
MULS removed
CLRAACC replaced by CLRACCA, CLRACCB, CLRACCS
GETACC replaced by GETACCA, GETACCB
added FITACCA, FITACCB, FITACCS
DECODE2 swapped opcodes with DECODE5
DECODE3 swapped opcodes with DECODE4
DECODE4 swapped opcodes with DECODE3
DECODE5 swapped opcodes with DECODE2
SWAPZC removed
REP replaced by REPD
added SETSKIP
SETVIDM removed
A little off. It's actually 2922 years,.266 days, 9 hours, 52 minutes, and 49 seconds
This is not accounting for leap seconds but does include skipped leap years.
That could be off by as much as 32 days using a 30ppm crystal.
I am extremely disappointed that there appears to be no silicon to permit those fantastic registers to be used to clock anyting into them. What a waste for a tiny piece of silicon. Please tell me I am wrong???
That's how I read it too, ... [yada yada yada] ... I'm frankly stunned they missed this.
I think it's highly premature to critique the Prop II's design based solely on the brief summary info we've been given. And, if even you're right, it's probably too late to make any substantive changes anyway. Based on our experience with the Prop I, the Prop II is certain to have some hidden jewels that we will all have fun discovering, exploiting, and repurposing (i.e. abusing) to great benefit. The design is in good hands. We just need to wait for more to be revealed. I, for one, am anxious to find out more about the Prop II's new counter modes.
I think it's highly premature to critique the Prop II's design based solely on the brief summary info we've been given. And, if even you're right, it's probably too late to make any substantive changes anyway.
These are not what I'd call "substantive changes" - I could have done this in HDL, in less time than we have spent discussing it.
If someone from the design team wants to clarify just what the Silicon WILL do, around hardware support for Serial Input, and industry Standard SPI and QuadSPI support, that would, of course, be great.
It doesn't have SPI in the silicon, just like the Prop 1 doesn't have I2C in silicon. The whole notion of the prop is to give you the tools in a robust instruction set to be able to do what you want. The P2P serial is described in the instruction set for what is known now. All that you can say is that it transfers 1 long per instruction call, the clock rate is unknown, etc.
What's with the 20 questions trying to pin it down on preliminary info? How many companies post this kind of data before the silicon is done? Chip is pretty firm on the design, but is known to change things last minute.
I just had a quick look at the new spec. Automatic PWM generation by the counters is mentioned, will that include deadband?
You might want to explain that request a little more. I doubt automatic PWM generation means anything like profile following. I think that's just the proportional toggling hardware. Deadband generation is no biggie to throw into your own code when you are already performing the servo code or whatever.
For motor control, software generated PWM is doable even on the Prop 1, you don't need counters to make it happen. This is how I will probably do my stepper driver, so I can drive more than 1 motor per COG.
In Half-Bridge mode, a digitally programmable deadband
delay is available to avoid shoot-through current
from destroying the bridge power switches. The delay
occurs at the signal transition from the non-active state
to the active state.
Phil & all:
I am certain there will be many jewels in the P2's counters. Heck, we have not even touched the surface of what the P1's counters are capable, partly due to the lack of detailed information.
Yes, there is info on the P1 counters, but not enough. I would like to see a much more detailed block diagram. I believe the video counters have many untouched uses as well as the counters. I have noted the uses in the sd (SPI) drivers such as fsrw2.6 and kye's. I know we can use the vga for outputting serial data but have not had sufficient time to test this theory.
I am just disappointed that the lack of a simple controllable gate and line to input to the counters/video seems to be missing. This is such a simple thing and would permit these complex counters/video to be used in all kinds of ways in reverse (as in clocking the data in rather than out). Perhaps I am oversimplifying, but IMHO this would have far more use in any P2 design (for use as serial in modes) than any of the complex functions of these counters/video provide. Enough said.
As I have said many times before, Parallax really needs to push the P1 & P2 as chips with all kinds of soft configurable I/O blocks. Almost every time we get a new experienced user here, they complain about no basic standard peripherals like UARTS, I2C and SPI. We have to go to great lengths to explain how this is done simply using already written objects. I just keep wondering how many engineers have seen the specs, noted no peripherals, and moved on. As all of us experienced P1 users know, this is the biggest benefit of the prop. I never have to go searching for a AVR/PIC/etc chip with a specific set of peripherals, and then wait for it to arrive. I just pull one of my trusty 1" prebuilt modules and I am away with a new design. I know that it can almost have any peripheral set (within reason) that I may desire. We really have to sell this feature prominently, not hidden, in the datasheet.
Anyway, P2 is still some time off, so I will watch and wait, while I continue on my P1 designs. There is way too much to do with the P1 anyway
A little off. It's actually 2922 years,.266 days, 9 hours, 52 minutes, and 49 seconds
This is not accounting for leap seconds but does include skipped leap years.
That could be off by as much as 32 days using a 30ppm crystal.
Comments
See the LPC1111 data sheet. It'll be a month or two before they are available, I have a couple of them in QFN.
Fingers crossed, we may get a nice Christmas present?
:-)
This PDF don't say anything - Mostly only what instructions we will have in assembly (Some very bad described to) .
As jmg pointed in other threads it leaks much of important info on some Hardware solutions and even some instructions functions.
As I pointed many times and even jmg point in theirs threads --- Some things are simply waste of silicon.
And degrade possibility's what will be possible on PropII.
Even if I see some nice solutions -- Total words on it --- Are not so good.
Sorry Parallax --- It was possible to be better -- But if any look only on single peoples NEED's not at How much people need find it usable -- It will always be bad directions taken.
So, having that off my chest, there is plenty of time for the info to be detailed better.
I found the external ram access interesting... 5ns cycle time, 16bit.
I could not work out how the quadlong cache works - actually how does it fill ?
I am extremely disappointed that there appears to be no silicon to permit those fantastic registers to be used to clock anyting into them. What a waste for a tiny piece of silicon. Please tell me I am wrong???
I note that we cannot set the carry on a hub read. I don't think that matters because we can still set the zero flag.
Does TJZ/TJNZ(D) set the Z flag (WZ)? Same for IJZ/IJNZ(D) & DJZ/DJNZ(D) ?
Table 16 OFFP mneumonic? Does this toggle the DIR for the Pin? OFF seems wrong for TOGGLE ?
Table 18 SETSER How are the pins set with only 0-63 ?
Table 19 SETMAP How does register mapping work ?
errata:
Table 5 COGINIT, etc missing the word "access" in operation
Table 14 INDA & INDB word "my" should be "by" in operation
That's how I read it too, A highly custom Prop-prop serial support, even with special opcodes, but no Standard SPI, and no QuadSPI.
There are a LOT more QuadSPI devices out there, than Prop II's !!
QuadSPI would allow execute in place at much higher speeds. Cost is a handful of gates/ff. Opcodes & SFR are there already.\
I'm frankly stunned they missed this.
My take here, is they are in groups of 3 or 4, and so that number will be a Pin-Group, likely x4 to select actual base-pin.
The pin-map is highly flexible; why not take the same care with the shifter engine itself ?
Is there a way to diff two PDF files? It would be helpful to know exectly what has changed since the last version was posted.
I couldn't resist posting this again, it is the new Parallax 128 pin dip package and special socket.128pDip.bmp
Can't wait to have a Prop2 proto board!!!
http://forums.parallax.com/showthread.php?138458-Prop-II-question-Serial-Chip-To-Chip-Communication&p=1080219
System clock roll over is once every ~2900 years?
I asked Chip if he could arrange it so that we could use a QuadSPI device without having to disassemble/reassemble nibbles - see below.
Assuming CS is highest pin number under the serial port pins and CLK is next highest, you get a configuration something like this which leaves 80 P2 pins available for generic usage.
This is only correct for a small number of bytes at a time on typical asynchronous SRAM. For more than say 8 bytes at a time synchronous device like QuadSPI or SDRAM (more than 8 bytes at a time) will perform better with the P2 design. On P1, synchronous devices perform better than stock SRAM reads when using QuadSPI pins (other conveniences like more pins available and maintaining normal serial port usage are not sacrificed). The same advantages could be enjoyed by connecting 74*161s with an asynchronous SRAM, but then you start having even bigger real-estate issues.
P2 development is going to be a blast!
Figures....I need 81 pins! Here we go again!!
See posts beginning at #1026 where the question was asked and answered.
-Phil
A cached read-quad instruction was added. An instruction that gives the number of clock ticks since the last time it was used was also added. A summary of the changes in the instructions is given below.
V1.3 V2.0 Instruction Change Instruction ----------- ------ ----------- added RDQUADC POPUPA renamed to POPAR POPUPB renamed to POPBR PUSHDNA renamed to PUSHAR PUSHDNB renamed to PUSHBR GETCORX renamed to GETQX GETCORY renamed to GETQY GETCORZ renamed to GETQZ SETCORX replaced by SETQM SETCORY replaced by SETQI SETCORZ renamed to SETQZ CORDROT renamed to QROTATE CORDATN renamed to QARCTAN CORDEXP renamed to QEXP CORDLOG renamed to QLOG added QSINCOS added SUBCNT MAC replaced by MACA, MACB MULS removed CLRAACC replaced by CLRACCA, CLRACCB, CLRACCS GETACC replaced by GETACCA, GETACCB added FITACCA, FITACCB, FITACCS DECODE2 swapped opcodes with DECODE5 DECODE3 swapped opcodes with DECODE4 DECODE4 swapped opcodes with DECODE3 DECODE5 swapped opcodes with DECODE2 SWAPZC removed REP replaced by REPD added SETSKIP SETVIDM removedThis is not accounting for leap seconds but does include skipped leap years.
That could be off by as much as 32 days using a 30ppm crystal.
-Phil
One hopes
These are not what I'd call "substantive changes" - I could have done this in HDL, in less time than we have spent discussing it.
If someone from the design team wants to clarify just what the Silicon WILL do, around hardware support for Serial Input, and industry Standard SPI and QuadSPI support, that would, of course, be great.
What's with the 20 questions trying to pin it down on preliminary info? How many companies post this kind of data before the silicon is done? Chip is pretty firm on the design, but is known to change things last minute.
You might want to explain that request a little more. I doubt automatic PWM generation means anything like profile following. I think that's just the proportional toggling hardware. Deadband generation is no biggie to throw into your own code when you are already performing the servo code or whatever.
That depends very much on the underlyng hardware.
You need deadband on BOTH edges, and vanilla/generic (sawtooth) PWM only allows code-fix on the moving edge, all flyback edges are the same.
So, some companies build triangle counters, and allow True/False and with that HW, you can control symmetric dead band in SW.
Smarter HW still, allows asymmetric deadband, and fast current sense inputs, to quickly remove PWM drive on a fault.
Also common on 'better' controller chips (say > $5) is fractional time control on PWM - 1ns, or even 150ps.
which is available on little low-cost PICs.
I am certain there will be many jewels in the P2's counters. Heck, we have not even touched the surface of what the P1's counters are capable, partly due to the lack of detailed information.
Yes, there is info on the P1 counters, but not enough. I would like to see a much more detailed block diagram. I believe the video counters have many untouched uses as well as the counters. I have noted the uses in the sd (SPI) drivers such as fsrw2.6 and kye's. I know we can use the vga for outputting serial data but have not had sufficient time to test this theory.
I am just disappointed that the lack of a simple controllable gate and line to input to the counters/video seems to be missing. This is such a simple thing and would permit these complex counters/video to be used in all kinds of ways in reverse (as in clocking the data in rather than out). Perhaps I am oversimplifying, but IMHO this would have far more use in any P2 design (for use as serial in modes) than any of the complex functions of these counters/video provide. Enough said.
As I have said many times before, Parallax really needs to push the P1 & P2 as chips with all kinds of soft configurable I/O blocks. Almost every time we get a new experienced user here, they complain about no basic standard peripherals like UARTS, I2C and SPI. We have to go to great lengths to explain how this is done simply using already written objects. I just keep wondering how many engineers have seen the specs, noted no peripherals, and moved on. As all of us experienced P1 users know, this is the biggest benefit of the prop. I never have to go searching for a AVR/PIC/etc chip with a specific set of peripherals, and then wait for it to arrive. I just pull one of my trusty 1" prebuilt modules and I am away with a new design. I know that it can almost have any peripheral set (within reason) that I may desire. We really have to sell this feature prominently, not hidden, in the datasheet.
Anyway, P2 is still some time off, so I will watch and wait, while I continue on my P1 designs. There is way too much to do with the P1 anyway
And also on low cost TI msp430's
But most of the time you have a few motors to control, so dedicate a cog to handle it in software is no big deal.
If only the prop1 could have a 64 bit counter!