Flash and EEPROM would defeat the reason for fuses, the one-time-programmable thing to secure a chip.
And I do not see any difference between fuses and OTP, isn't that basically the same?
confused again today,
Mike
Sorry, I must beg to disagree with you on this aspect.
If the Flash/EEprom can't be (externally, or internally) accessible, unless you know the actual state of the protection bits, in wich case the routine to report/rewrite their contents is runing, because it was encoded under the rules dictated by their states, them Flash/EEprom are also valid options.
Sure the report/rewrite routine must clear any internal memory contents (including the most part of itself) before proceeding to some type of standardized sign-off procedure or loop, waiting for power off or reset.
An external eeprom reprogramming will be needed, afterwards, since the old keys will not work.
It would be good if we could have those options, because the same chip could be returned to its pristine condition, several times.
Flash and EEPROM would defeat the reason for fuses, the one-time-programmable thing to secure a chip.
And I do not see any difference between fuses and OTP, isn't that basically the same?
confused again today,
Mike
From what I undersstood, fuses and OPT is different.
FLASH or EEPROM or OTP could be used just like fuses. The hardware would decode a small block as fuses and determine if they are protected or not. It's not rocket science here. And the result would be no external SPI chip required (at least if the internal size is sufficient for the user software). Then the internal flash/eeprom/otp could be used to boot from SD, or any SPI or I2C chip (or any new chip such as quad spi, or any of the proposed novram chips being discussed now, or in the future).
FLASH or EEPROM or OTP could be used just like fuses. The hardware would decode a small block as fuses and determine if they are protected or not. It's not rocket science here. And the result would be no external SPI chip required (at least if the internal size is sufficient for the user software). Then the internal flash/eeprom/otp could be used to boot from SD, or any SPI or I2C chip (or any new chip such as quad spi, or any of the proposed novram chips being discussed now, or in the future).
I'm not sure it's practical to have on-die FLASH large enough to displace an off die SPI chip.
( price goes up, and die area available for RAM also reduces, and one concern is RAM of 512k may already be squeezed)
What could happen, is to place the SPI memory inside the same package. (see Nuvoton NUC505 for exactly this approach)
Having RAM based code memory that loads is trending to become less uncommon, than it was back when P2 was conceived.
FLASH or EEPROM or OTP could be used just like fuses. The hardware would decode a small block as fuses and determine if they are protected or not. It's not rocket science here. And the result would be no external SPI chip required (at least if the internal size is sufficient for the user software). Then the internal flash/eeprom/otp could be used to boot from SD, or any SPI or I2C chip (or any new chip such as quad spi, or any of the proposed novram chips being discussed now, or in the future).
I'm not sure it's practical to have on-die FLASH large enough to displace an off die SPI chip.
( price goes up, and die area available for RAM also reduces, and one concern is RAM of 512k may already be squeezed)
What could happen, is to place the SPI memory inside the same package. (see Nuvoton NUC505 for exactly this approach)
Having RAM based code memory that loads is trending to become less uncommon, than it was back when P2 was conceived.
or the recent ESP32, which has 520 KB SRAM, 16 KB SRAM in RTC, and loads from QSPI flash/SRAM, up to 4 x 16 MB
A small flash/eeprom/otp sufficient for booting off SD (currently <10KB without any attempt to simplify) would save an external SPI flash/eeprom/otp boot chip !!!
FWIW Chip is planning 16KB.
A small flash/eeprom/otp sufficient for booting off SD (currently <10KB without any attempt to simplify) would save an external SPI flash/eeprom/otp boot chip !!!
FWIW Chip is planning 16KB.
Ah, ok, you omitted the all important boot word before.
On current prices, there is no price advantage in a smaller-(boot-sized)-flash, 4Mb or16Mb are about the bottom of the price curve already.
Certainly, that raises a good point, that if the Fuses move to OTP in the main process, should Parallax look at also moving the ROM into OTP ?
Any charge pumps and access blocks can likely be shared, and this removes the risk of ROM bugs, allows ROM revisions, and also opens up new markets as some customers will like the idea of their own ROM.
Calibration of Oscillators becomes that little bit easier...
That leaves open the issue of how to initially program that blank Boot OTP. Maybe the IP covers that with a small i2c access block, or similar ?
I do a lot with Raspi computers right now. Newer SD cards don't work.
The Pi foundation is selling ones that do.
If we go here again, we really do need to nail down what will be supported and how.
Latest win 10 updates do strange things with older SD cards. Can't make reliable images on them right now.
All of the above is a good argument for a move to OTP Boot ROM, when the change is made to OTP fuses ?
Seems there is no universal 'ROMable' solution that stands the test of time, so best design a chip that can at least adapt.
I believe there was consensus on not having filesystem support built in. Given the migration to EXFAT as the default format in SD cards, that's probably where the Pi came unstuck. Next hurdle may be GPT support but since that isn't needed until the drive is greater than 2TB I don't think it'll be any time soon for average SD cards.
The one that seemed to blow up into an argument way too easy was over supporting only a single contiguous load or also allowing additional clusters.
eg: single cluster: (fixed 12 bytes size at start of MBR)
SIGNATURE word
FIRST block number of cluster
NUMBER of contiguous blocks
vs multiple clusters: (minimum 16 bytes size at start of MBR)
SIGNATURE word
FIRST block number of cluster
NUMBER of contiguous blocks
NULL termination
Given the migration to EXFAT as the default format in SD cards, that's probably where the Pi came unstuck.
When and or/or how did the Pi come unstuck. I seem to have missed something over the years.
EXFAT, or whatever, being the default format on SD cards is of no consequence as whatever it is is blown away and replaced when the Pi OS image is put on the card.
@potatohead
I do a lot with Raspi computers right now. Newer SD cards don't work.
Which newer SD cards don't work? I recently set up a bunch of Pi with a new batch of SD cards, including 32GB Samsung EVO. No problems. Surely those big EVOs count as "newer SD" cards.
Mind you, having said all that I'm not keen on SD card support built into the P2. Especially if it takes even one second of further development time. The SD scene all seems to woolly to me.
Heater, I'll have to dig a bit deeper. Above 32GB definitely are a problem. I don't have too many problems personally, but I'm either running a live linux, or Win 7, both of which feature very robust filesystem support. (legacy filesystem)
The guy I'm working with is on Win 10, and has a lot of trouble, more since the last round of updates.
Linux in a VM doesn't work well either, so it's something very basic.
I do know it's enough of an issue that the Foundation is selling "works no matter what" SD cards.
Well, maybe I'm a part of that. Don't know. I was opposed to filesystem support, unless we actually do support filesystems, not just a hack, or counting on specifics to be true, sort of, if we do X.
At the block level, I'm totally good with a single load, though doing it in a way that permits partition support would be best.
Don't care on that though. If we are smart about it, an SD card can be made that will boot a P2 and be useful in other ways. Something tells me doing that is wise, but totally not necessary.
In the block case, no real support, then it's just a dedicated SD, no expectation of anything other than blocks.
I dislike the hybrid, works if we do X, sorta... kinds of ideas we had floating around.
All that said, I was never married to the SD card. It's a super spiffy feature, if done well, and a lot of the "spiffy" has to do with interacting with PC's, meaning the partition and filesystem either support or compatibility should be there.
I don't care if we have any of this on chip either. Adding a storage device is fine. And that's my plan at present. However the thing boots, we know serial is in the can, and we know a storage device will be in the can.
Just do the right kind of support on whatever storage device and then provide for SD at that level. Works a treat, easy peasy.
An OTP ROM? If it's no big deal fine. People, myself included, would definitely use it. Gets rid of the storage device, potentially, depending on it's size.
I'll want to use SD card as I currently do with P1 in any of these cases.
Heck, if we had the chip right now, I probably would setup a SD imaging / editing system on it to bullet proof creating custom Pi images. Just insert the cards, go, one master, and a few others as pins allow, and just blast the data to the cards, verify, done.
...
I don't care if we have any of this on chip either. Adding a storage device is fine. And that's my plan at present. However the thing boots, we know serial is in the can, and we know a storage device will be in the can.
Just do the right kind of support on whatever storage device and then provide for SD at that level. Works a treat, easy peasy.
Practical sized SPI flash parts start around 15c/1k+, with SO8 packages looking the cheapest.
Really small SPI EEPROMs can come for less than 15c, but they are not address or clock speed compatible, and quickly go > 15c
In a P2 product, I don't see ~15c ( or SO8 size) as being a deal breaker.
An OTP ROM? If it's no big deal fine. People, myself included, would definitely use it. Gets rid of the storage device, potentially, depending on it's size.
Logical is to simply swap the BOOT ROM -> OTP, no big architecture changes, so the size will not be 'large' in total P2 terms. I think that's "COG Sized" at the moment ?
Possibly "COG sized + LUT" is another increment choice ?
I don't see it. Looking at the list Keith has posted (Thanks Keith): Working / Non-working SD cards: http://elinux.org/RPi_SD_cards, sorting by size, it seems there have been non-working SD cards for the Pi since the 2GB sizes of 2012. Quickly scanning the end of the list I get the impression the newer and bigger, 32GB and up, cards have less models not working than before!
The guy I'm working with is on Win 10, and has a lot of trouble, more since the last round of updates.
Win 10, latest updates, here also. No problems with SD cards and Pi so far.
Linux in a VM doesn't work well either, so it's something very basic.
That may or may not be related. For the record I have Debian running under Virtual Box on this Win 10 Surface Prop with out hitch.
I do know it's enough of an issue that the Foundation is selling "works no matter what" SD cards.
That may well be a totally different issue. Many Pi Vendors supply kits or Pi with pre-imaged cards. I know a lot of people have had trouble with this Why? Because new Pi have a slightly different architecture and little hardware tweaks that require the latest OS build. The vendors were still shipping old images on their SD cards causing much confusion.
Of course its good that the Foundation supplies the latest and greatest images on known working cards. One would only expect them to. Never had to use one.
...Logical is to simply swap the BOOT ROM -> OTP, no big architecture changes, so the size will not be 'large' in total P2 terms. I think that's "COG Sized" at the moment ?
Possibly "COG sized + LUT" is another increment choice ?
Latest I remember is a up to 16K serial boot-ram copied into Hub at startup and not accessible later on.
By now just ~2K? are used in the current boot code, but @Chip seems to still keep the option to put more code into the boot rom.
I personally wished the P1 had a soft-rom in the upper 32K, pre-loaded at boot time, but changeable at runtime.
So if you don't need sin/cos use the space for other things.
On the p2 @Chip seems to go the other way around, providing as less as rom as possible and not having the rom in the address space at all.
I do understand the reasoning behind that, not blocking higher addresses by using them for rom. Thinking about the P2-Family concept with variable number of cogs/pins/ram placing a rom into address space could be a challenge, if it is not placed on the end of the address space requiring more address lines.
But since Hubexec is kind of kinky in the first 2K(4K?) because it needs odd addresses there could be a possibility to put some common library routines there, loaded at boot time and just left there.
If your program do not need them it can use the space for other things, but at startup there would be some useful code there,
Say simple serial with auto baud (already in the boot code), the nice Monitor of the P2-Hot, maybe some other code snippets one could use, like calling the encryption/decryption stuff already in the boot code. Or even a simple debugger, using the now existing debug interrupts without any hassle.
And if you need to secure your P2 for production, just overwrite and use the space for something else.
I personally wished the P1 had a soft-rom in the upper 32K, pre-loaded at boot time, but changeable at runtime.
So if you don't need sin/cos use the space for other things.
On the p2 @Chip seems to go the other way around, providing as less as rom as possible and not having the rom in the address space at all.
I do understand the reasoning behind that, not blocking higher addresses by using them for rom. Thinking about the P2-Family concept with variable number of cogs/pins/ram placing a rom into address space could be a challenge, if it is not placed on the end of the address space requiring more address lines.
There is other reasons too but the simple one is the Prop1 saved a notable amount of physical silicon space by having half of the 64 KB as mask ROM. Keeping the same 50/50 ratio would make for a large amount of ROM in the Prop2, it's no surprise Chip changed tact.
On that note, I'd also guess it played into Chip's decision to restart the design. At 128 KB the Prop2-Hot attempt was struggling. People are still wanting more even at 512 KB. 1 MB would be a pushover space wise if it was built from MRAM instead of SRAM. 2 MB would fit no problem, except code space doesn't extend that far under current instruction set.
YES! Of all the features we missed, a region of RAM, write inhibited, would resolve these use cases. Would make on-chip tools more robust too. Chip was concerned about it being accidentially triggered, then being useless. But a few state changes via COGID would fix that. Random instructions just won't hit those very easily.
Moving on though...
Re: SD = Pi.
Thanks guys! I am going to inquire about the methods our guy is using. Perhaps he's on a crappy path.
What we are doing is writing images to cards, after mastering them on a PC. The Pi is a dedicated device at that point, running enough Linux to provide for a local user, but not much else.
I was looking at the SCLU and SCL instructions, and there appears to be errors in their descriptions in the Propeller 2 Instruction document. The description for SCLU is "Next instruction's S value = unsigned (D[15:0] * S[15:0])." It appears that the product is also shifted to the right by 16 bits.
The description for SCL is "Next instruction's S value = signed (D[15:0] * S[15:0]) / $4000." However, rather than dividing by $4000 it would be more accurate to say that it is shifted right by 14 bits with sign extension. If I multiply 1 * (-1) the result is -1. A division by $4000 would have produced a value of zero instead.
I was looking at the SCLU and SCL instructions, and there appears to be errors in their descriptions in the Propeller 2 Instruction document. The description for SCLU is "Next instruction's S value = unsigned (D[15:0] * S[15:0])." It appears that the product is also shifted to the right by 16 bits.
The description for SCL is "Next instruction's S value = signed (D[15:0] * S[15:0]) / $4000." However, rather than dividing by $4000 it would be more accurate to say that it is shifted right by 14 bits with sign extension. If I multiply 1 * (-1) the result is -1. A division by $4000 would have produced a value of zero instead.
I have just found four bugs in:
ADDS/ADDSX/SUBS/SUBSX
The last-minute change to these instructions has broken them.
"Signed carry" is a misnomer as signed arithmetic doesn't have a carry. As far as I can tell "signed carry" is simply the sign bit of the result.
With C as the overflow flag, a sign test would take one more instruction.
With C as the sign flag, how will users know there has been an overflow? Bugs will slip through undetected.
I have just found four bugs in:
ADDS/ADDSX/SUBS/SUBSX
The last-minute change to these instructions has broken them.
"Signed carry" is a misnomer as signed arithmetic doesn't have a carry. As far as I can tell "signed carry" is simply the sign bit of the result.
With C as the overflow flag, a sign test would take one more instruction.
With C as the sign flag, how will users know there has been an overflow? Bugs will slip through undetected.
Chip, you're disagreeing with yourself from 2006. The P1 has it right.
Maybe I've called it the wrong thing, but it's what I intended, I'm quite sure.
I want to be able to do a 'SUBS D,S' and find out if D was less than S via C (both signed values). CMPS needs to work the same way. And, yes, it's really just the sign bit of the extended result that goes into C.
This way CMP/CMPS both set C if D<S. SUB/SUBS do the same thing. ADD sets C if unsigned overflow. ADDS sets C to the sign bit of the extended result. That's what I wanted.
What is the most simple way to express this behavior?
The only instructions that set C to overflow are SUMC/SUMNC/SUMZ/SUMNZ.
I don't like how Prop1 had different C behavior between CMPS and SUBS. Now, it's all uniform.
Thanks Chip, now that there is some light at the end of the tunnel I will be able to see what I'm doing
I'll be sure to load up my boards and update Tachyon as well.
If everything is stable with the instruction set I will write an inline assembler so it becomes a very easy task to interactively test out the instructions and smart pins etc on the fly.
Brian found some trouble with the spinning Fozzy demo. Our 120MHz overclocking is too aggressive.
I'm recompiling everything now for 80MHz operation. This is below the Fmax of most compiles, but still 8MHz above the 16-cog compiles, which will be fine. Getting 11% above Fmax is no problem, but asking for 67% more is just too much.
This new version will be out tomorrow and it will be v21a. So, back to 80MHz for reliable FPGA testing.
The chip should close timing at 160MHz, and we'll shoot for 200MHz.
Comments
Sorry, I must beg to disagree with you on this aspect.
If the Flash/EEprom can't be (externally, or internally) accessible, unless you know the actual state of the protection bits, in wich case the routine to report/rewrite their contents is runing, because it was encoded under the rules dictated by their states, them Flash/EEprom are also valid options.
Sure the report/rewrite routine must clear any internal memory contents (including the most part of itself) before proceeding to some type of standardized sign-off procedure or loop, waiting for power off or reset.
An external eeprom reprogramming will be needed, afterwards, since the old keys will not work.
It would be good if we could have those options, because the same chip could be returned to its pristine condition, several times.
Henrique
The main issues with Flash and EEPROM are the extra process steps that add to the cost.
OTP can emulate MTP/FTP with some spare/duplicate cells, and that likely also helps chip yields.
FLASH or EEPROM or OTP could be used just like fuses. The hardware would decode a small block as fuses and determine if they are protected or not. It's not rocket science here. And the result would be no external SPI chip required (at least if the internal size is sufficient for the user software). Then the internal flash/eeprom/otp could be used to boot from SD, or any SPI or I2C chip (or any new chip such as quad spi, or any of the proposed novram chips being discussed now, or in the future).
Certainly, the Parallax Fuses and OnSemi OTP cells are not the same thing.
Any end user probably does not care how the OTP memory is derived, just that it is easy to use and reliable.
I'm not sure it's practical to have on-die FLASH large enough to displace an off die SPI chip.
( price goes up, and die area available for RAM also reduces, and one concern is RAM of 512k may already be squeezed)
What could happen, is to place the SPI memory inside the same package. (see Nuvoton NUC505 for exactly this approach)
Having RAM based code memory that loads is trending to become less uncommon, than it was back when P2 was conceived.
Look also at this new device :
https://toshiba.semicon-storage.com/ap-en/product/assp/applite/tz1200.html
Note the 2.2MB of embedded SRAM, loads from Quad SPI for Flash memory interface.
or the recent ESP32, which has 520 KB SRAM, 16 KB SRAM in RTC, and loads from QSPI flash/SRAM, up to 4 x 16 MB
FWIW Chip is planning 16KB.
On current prices, there is no price advantage in a smaller-(boot-sized)-flash, 4Mb or16Mb are about the bottom of the price curve already.
Certainly, that raises a good point, that if the Fuses move to OTP in the main process, should Parallax look at also moving the ROM into OTP ?
Any charge pumps and access blocks can likely be shared, and this removes the risk of ROM bugs, allows ROM revisions, and also opens up new markets as some customers will like the idea of their own ROM.
Calibration of Oscillators becomes that little bit easier...
That leaves open the issue of how to initially program that blank Boot OTP. Maybe the IP covers that with a small i2c access block, or similar ?
I do a lot with Raspi computers right now. Newer SD cards don't work.
The Pi foundation is selling ones that do.
If we go here again, we really do need to nail down what will be supported and how.
Latest win 10 updates do strange things with older SD cards. Can't make reliable images on them right now.
Seems there is no universal 'ROMable' solution that stands the test of time, so best design a chip that can at least adapt.
The one that seemed to blow up into an argument way too easy was over supporting only a single contiguous load or also allowing additional clusters.
eg: single cluster: (fixed 12 bytes size at start of MBR)
SIGNATURE word
FIRST block number of cluster
NUMBER of contiguous blocks
vs multiple clusters: (minimum 16 bytes size at start of MBR)
SIGNATURE word
FIRST block number of cluster
NUMBER of contiguous blocks
NULL termination
EXFAT, or whatever, being the default format on SD cards is of no consequence as whatever it is is blown away and replaced when the Pi OS image is put on the card.
@potatohead Which newer SD cards don't work? I recently set up a bunch of Pi with a new batch of SD cards, including 32GB Samsung EVO. No problems. Surely those big EVOs count as "newer SD" cards.
Mind you, having said all that I'm not keen on SD card support built into the P2. Especially if it takes even one second of further development time. The SD scene all seems to woolly to me.
The guy I'm working with is on Win 10, and has a lot of trouble, more since the last round of updates.
Linux in a VM doesn't work well either, so it's something very basic.
I do know it's enough of an issue that the Foundation is selling "works no matter what" SD cards.
Well, maybe I'm a part of that. Don't know. I was opposed to filesystem support, unless we actually do support filesystems, not just a hack, or counting on specifics to be true, sort of, if we do X.
At the block level, I'm totally good with a single load, though doing it in a way that permits partition support would be best.
Don't care on that though. If we are smart about it, an SD card can be made that will boot a P2 and be useful in other ways. Something tells me doing that is wise, but totally not necessary.
In the block case, no real support, then it's just a dedicated SD, no expectation of anything other than blocks.
I dislike the hybrid, works if we do X, sorta... kinds of ideas we had floating around.
All that said, I was never married to the SD card. It's a super spiffy feature, if done well, and a lot of the "spiffy" has to do with interacting with PC's, meaning the partition and filesystem either support or compatibility should be there.
I don't care if we have any of this on chip either. Adding a storage device is fine. And that's my plan at present. However the thing boots, we know serial is in the can, and we know a storage device will be in the can.
Just do the right kind of support on whatever storage device and then provide for SD at that level. Works a treat, easy peasy.
An OTP ROM? If it's no big deal fine. People, myself included, would definitely use it. Gets rid of the storage device, potentially, depending on it's size.
I'll want to use SD card as I currently do with P1 in any of these cases.
Heck, if we had the chip right now, I probably would setup a SD imaging / editing system on it to bullet proof creating custom Pi images. Just insert the cards, go, one master, and a few others as pins allow, and just blast the data to the cards, verify, done.
Practical sized SPI flash parts start around 15c/1k+, with SO8 packages looking the cheapest.
Really small SPI EEPROMs can come for less than 15c, but they are not address or clock speed compatible, and quickly go > 15c
In a P2 product, I don't see ~15c ( or SO8 size) as being a deal breaker.
Logical is to simply swap the BOOT ROM -> OTP, no big architecture changes, so the size will not be 'large' in total P2 terms. I think that's "COG Sized" at the moment ?
Possibly "COG sized + LUT" is another increment choice ?
This list has some large cards that supposedly work o.k. You can sort the table by size.
http://elinux.org/RPi_SD_cards
Of course its good that the Foundation supplies the latest and greatest images on known working cards. One would only expect them to. Never had to use one.
Latest I remember is a up to 16K serial boot-ram copied into Hub at startup and not accessible later on.
By now just ~2K? are used in the current boot code, but @Chip seems to still keep the option to put more code into the boot rom.
I personally wished the P1 had a soft-rom in the upper 32K, pre-loaded at boot time, but changeable at runtime.
So if you don't need sin/cos use the space for other things.
On the p2 @Chip seems to go the other way around, providing as less as rom as possible and not having the rom in the address space at all.
I do understand the reasoning behind that, not blocking higher addresses by using them for rom. Thinking about the P2-Family concept with variable number of cogs/pins/ram placing a rom into address space could be a challenge, if it is not placed on the end of the address space requiring more address lines.
But since Hubexec is kind of kinky in the first 2K(4K?) because it needs odd addresses there could be a possibility to put some common library routines there, loaded at boot time and just left there.
If your program do not need them it can use the space for other things, but at startup there would be some useful code there,
Say simple serial with auto baud (already in the boot code), the nice Monitor of the P2-Hot, maybe some other code snippets one could use, like calling the encryption/decryption stuff already in the boot code. Or even a simple debugger, using the now existing debug interrupts without any hassle.
And if you need to secure your P2 for production, just overwrite and use the space for something else.
Anyways,
Mike
On that note, I'd also guess it played into Chip's decision to restart the design. At 128 KB the Prop2-Hot attempt was struggling. People are still wanting more even at 512 KB. 1 MB would be a pushover space wise if it was built from MRAM instead of SRAM. 2 MB would fit no problem, except code space doesn't extend that far under current instruction set.
YES! Of all the features we missed, a region of RAM, write inhibited, would resolve these use cases. Would make on-chip tools more robust too. Chip was concerned about it being accidentially triggered, then being useless. But a few state changes via COGID would fix that. Random instructions just won't hit those very easily.
Moving on though...
Re: SD = Pi.
Thanks guys! I am going to inquire about the methods our guy is using. Perhaps he's on a crappy path.
What we are doing is writing images to cards, after mastering them on a PC. The Pi is a dedicated device at that point, running enough Linux to provide for a local user, but not much else.
The description for SCL is "Next instruction's S value = signed (D[15:0] * S[15:0]) / $4000." However, rather than dividing by $4000 it would be more accurate to say that it is shifted right by 14 bits with sign extension. If I multiply 1 * (-1) the result is -1. A division by $4000 would have produced a value of zero instead.
http://forums.parallax.com/discussion/165453/question-on-scl-sclu-instruction-operation
This is the code that is headed for synthesis.
ADDS/ADDSX/SUBS/SUBSX
The last-minute change to these instructions has broken them.
"Signed carry" is a misnomer as signed arithmetic doesn't have a carry. As far as I can tell "signed carry" is simply the sign bit of the result.
With C as the overflow flag, a sign test would take one more instruction.
With C as the sign flag, how will users know there has been an overflow? Bugs will slip through undetected.
This was all discussed here:
http://forums.parallax.com/discussion/167295/c-after-cmps-cmpsx-adds-addsx-subs-subsx/p1
More info here:
http://teaching.idallen.com/dat2343/10f/notes/040_overflow.txt
Chip, you're disagreeing with yourself from 2006. The P1 has it right.
EDIT
ADDS/ADDSX/SUBS/SUBSX in v21 are fine. Please see this later post:
http://forums.parallax.com/discussion/comment/1421463/#Comment_1421463
Maybe I've called it the wrong thing, but it's what I intended, I'm quite sure.
I want to be able to do a 'SUBS D,S' and find out if D was less than S via C (both signed values). CMPS needs to work the same way. And, yes, it's really just the sign bit of the extended result that goes into C.
This way CMP/CMPS both set C if D<S. SUB/SUBS do the same thing. ADD sets C if unsigned overflow. ADDS sets C to the sign bit of the extended result. That's what I wanted.
What is the most simple way to express this behavior?
The only instructions that set C to overflow are SUMC/SUMNC/SUMZ/SUMNZ.
I don't like how Prop1 had different C behavior between CMPS and SUBS. Now, it's all uniform.
I'll be sure to load up my boards and update Tachyon as well.
If everything is stable with the instruction set I will write an inline assembler so it becomes a very easy task to interactively test out the instructions and smart pins etc on the fly.
I'm recompiling everything now for 80MHz operation. This is below the Fmax of most compiles, but still 8MHz above the 16-cog compiles, which will be fine. Getting 11% above Fmax is no problem, but asking for 67% more is just too much.
This new version will be out tomorrow and it will be v21a. So, back to 80MHz for reliable FPGA testing.
The chip should close timing at 160MHz, and we'll shoot for 200MHz.
1. P2 v20 or earlier or P1
2. P2 v21
and report the 1a/1b/1c, 2a/2b/2c results?
Thank you, this is important.