I like the larger offset range, but I also liked the immediate addressing of $0000-$00FF, as it meant a single instruction could be used to read/write to a mailbox by any cog.
Without the immediate mode, it will now take two instructions - ie set pointer A or B, or modify a long address in another register.
I am curious, why does the ROM have to overlap RAM? I'd prefer the ROM to start at $FFFFFFFF leaving a lot of room for it to grow down, and RAM to start at $00000000 leaving room for it to grow up
Would anyone have any opposition to putting the ROM at the BOTTOM of memory, so that it builds up from $00000?
This way, there's no ugly caveat at the end of memory which would inhibit one from allocating a huge top-justified block of RAM. I think this would lead to more efficient use of RAM. Also, RAM could begin right away after the bare necessities of ROM code, never minding any 2k rule.
Also, since immediate-address RDxxxx/WRxxxx would be pointless because of ROM, all immediate S values could be pointers, giving us one more bit of scaled offset, so instead of -16..+15 offsets, we could express -32..+31 offsets.
For the debug kernel, at one point I was going to put in auto baud detection, using CTRL-A to auto baud.
Why?
0x01 plus start bit is eight bit periods.. save CNT when RX goes low, save it when it goes high, divide by 8 and you get the bit period in clock cycles!
I think it's special because it has minimal-time transitions and six 0's in a row (starting with the start bit), so it can't be doubled (twelve 0's in a row is NOT serial). For high-speed automated systems, they could send an $FF before the $20 to cause at least nine 1's in a row (ending with the stop bit). For a user sitting at a terminal, he'll have plenty of 1's (idle bit periods) between characters. SPACE it is!
While the monitor is running, you might turn on the crystal and PLL and switch up to 160MHz, or go back down to ~20MHz. It needs to accommodate anything.
Oh, I thought this AutoBaud was just for the ROM loader ?
Is this for ROM, or a loaded user monitor ?
Large jumps are always going to be a challenge, and a risk.
Can a Prop 2 timer optionally always clock from the 20MHz - to keep the numbers reasonable, or perhaps the user could adjust the capture/compare value, as they change gears, as they know where they are going from/to ?
0x01 plus start bit is eight bit periods.. save CNT when RX goes low, save it when it goes high, divide by 8 and you get the bit period in clock cycles!
Phil, you would want Ctrl-A, but not quite for the reason he states. 0x01 would have the first data bit high, then you go low for 7 bits plus the stop bit, then high again. That's 8 clocks low, so you have 8 clocks between low-going transition and high-going transition.
However, I do agree with Bill in having ROM grow down, RAM up. One look ahead to P3 makes me wonder if having ROM start low isn't a kludge of some sorts... P2 ended up significantly more complex than P1, and building off the very clean P1 looks like it's going to pay off very nicely. So there is a purity argument. Not sure what that's worth, but I like that kind of thing just because.
Are the offsets that important? Well, more important than the optimal mailbox cases? I don't know. We've got the inter-cog comms now, (PORT D + MASKS) meaning mailboxes don't have to be used in all the ways they basically must on P1, unless somebody uses real pins.
Edit: Is the goal to have power of two alignment at top of RAM? If so, I think that's worth a lot.
I like the larger offset range, but I also liked the immediate addressing of $0000-$00FF, as it meant a single instruction could be used to read/write to a mailbox by any cog.
Without the immediate mode, it will now take two instructions - ie set pointer A or B, or modify a long address in another register.
I am curious, why does the ROM have to overlap RAM? I'd prefer the ROM to start at $FFFFFFFF leaving a lot of room for it to grow down, and RAM to start at $00000000 leaving room for it to grow up
However, I do agree with Bill in having ROM grow down, RAM up. One look ahead to P3 makes me wonder if having ROM start low isn't a kludge of some sorts... Are the offsets that important? Well, more important than the optimal mailbox cases? I don't know.
Chip, I hope you get time to adequately test the idea of sending commands to SQI chips to put them back in SPI mode with actual hardware.
After boot, it would be very nice to have SQI speed from the memory. With a 160 MHz Prop II, that should equate to an actual 4X speed increase...
I like the larger offset range, but I also liked the immediate addressing of $0000-$00FF, as it meant a single instruction could be used to read/write to a mailbox by any cog.
Without the immediate mode, it will now take two instructions - ie set pointer A or B, or modify a long address in another register.
I am curious, why does the ROM have to overlap RAM? I'd prefer the ROM to start at $FFFFFFFF leaving a lot of room for it to grow down, and RAM to start at $00000000 leaving room for it to grow up
Without immediate addressing, you would need the address of the mailbox in a register which you would use in lieu of an immediate.
Rather than putting four ROM instances onto the die (we didn't have room, it turned out), we just borrowed the last few word lines of the hub RAMs and put ROM bits in, instead of the normal 6T SRAM cells. This made the memory faster, too, since it didn't have to tri-state its outputs to share with the ROMs. So, now we've got a hybrid memory that is RAM and ROM. We would need to add an address bit to the hub memories to get those ROM bits out of the first 128k. In retrospect, we should have done this, but it's too big a change to make, at this point. We only realized we could plug in ROM bits after many other things had cemented up.
I didn't read it that way. What I read was HUB addressing starts at 0, with ROM at 0, and when ROM ends, RAM starts, where ever that ends up being. Am I wrong on that?
The product of it then is an alignment at top of RAM, and the messy bit that isn't all RAM is just one small page that can be ignored for memory allocation type purposes, etc...
There is a lot of P1 code that uses immediate addressing. This change does make up-ports harder, though they are going to be harder in a lot of cases anyway as the optimal uses cases changed and are expanded a lot. Maybe that's just not a worry at this point...
I am curious, why does the ROM have to overlap RAM? I'd prefer the ROM to start at $FFFFFFFF leaving a lot of room for it to grow down, and RAM to start at $00000000 leaving room for it to grow up
A variant on this, could have the long at $FFFFFFFF, indicate where the BOTTOM of ROM is, so you always know where you are,
and ROM changes can be managed ?
Smile, was editing, and decided to delete. Well, my original post was as quoted by Chip. Sorry for the confusion all. Thought I could move quickly enough to avoid that extra conversation. Not!
Rather than putting four ROM instances onto the die (we didn't have room, it turned out), we just borrowed the last few word lines of the hub RAMs and put ROM bits in, instead of the normal 6T SRAM cells. This made the memory faster, too, since it didn't have to tri-state its outputs to share with the ROMs. So, now we've got a hybrid memory that is RAM and ROM. We would need to add an address bit to the hub memories to get those ROM bits out of the first 128k. In retrospect, we should have done this, but it's too big a change to make, at this point. We only realized we could plug in ROM bits after many other things had cemented up.
Ah, if ROM is wire-initialised RAM, and has to be in the same map, I think you need to allow for ROM Size changes.
So placing all ROM at 000 is not going to be nice.
Perhaps you could place one Long of ROM at 000, that says where real ROM starts ?
That way user code would load and run the same, on future Props that may have ROM updates, and on Prop 3.
What does the Prop 2 return, for reads above physical memory ?
I second the idea of address 0 pointing to end of ROM.
Either P2 is static, or not, but if it's not, then we've built in something really nice for a very small cost, which could pay off really nicely.
If P3 ends up a variant of P2, instead of another big build out like P2 is over P1, same advantage.
If P3 is significantly built out, there will be code changes / up-ports and such needed, and that all goes like it is right now, the trade-off being we get a much better chip, which justifies the new code.
No downsides to this, and several potential gains, IMHO.
I second the idea of address 0 pointing to end of ROM.
Start and end are perhaps confusing. I would point the special 1 Long ROM @ 0000, to the lowest Code ROM address, as that would be where any copy started from. ROM Tables etc would be above that ?
Without immediate addressing, you would need the address of the mailbox in a register which you would use in lieu of an immediate.
Rather than putting four ROM instances onto the die (we didn't have room, it turned out), we just borrowed the last few word lines of the hub RAMs and put ROM bits in, instead of the normal 6T SRAM cells. This made the memory faster, too, since it didn't have to tri-state its outputs to share with the ROMs. So, now we've got a hybrid memory that is RAM and ROM. We would need to add an address bit to the hub memories to get those ROM bits out of the first 128k. In retrospect, we should have done this, but it's too big a change to make, at this point. We only realized we could plug in ROM bits after many other things had cemented up.
If you do a cached read (RDxxxxC) and the cache is not valid and in range (cache miss) the instruction's timing becomes exactly like a normal RDxxxx instruction. When a RDxxxxC is a cache-miss, it loads 4 longs (16 bytes) from the address range %x_xxxxxxxx_xxxx0000..%x_xxxxxxxx_xxxx1111. Thereafter, RDxxxxC instructions which access a location in that range take just one clock. If you do RDBYTEC instructions on a long stretch of hub memory, every 16th instruction will time like a RDBYTE, while every one in-between will take just one clock.
Ah, right, of course, first read fills the buffer. Presumably it's just an upper address compare on each access so that buffer locations can be read in any order. Refreshing stale data would require a double-buffer approach then I guess.
Why wouldn't it just be end of ROM? Or start of RAM? The problem with the user code would be not knowing where it can start writing. As I understand it, there are no tables and such this time around as we've got hardware instructions capable of similar things, more room to store those tables in RAM, should they be needed or specialized, etc... Same for the fonts and such too.
For the uninitiated, using the lower $200 longs for ROM could make sense to differentiate between $0 COG and $0 Hub addresses. Some might have a mental block that doesn't allow them to grok the 2 different address spaces. Having ROM at $000-$1FF in Hub memory kinda helps convey that "RAM" is $000-$1FF in COG and $200-$1FFFF in Hub.
The uninitiated know nothing about Cog space at all. It's all Spin space which is Hub space.
Either way, it's a pointer to the RAM / ROM region, whether or not it's top or bottom of the address space, which I second however it ends up being done.
Now we need to see how Top-ROM vs Bottom ROM gets settled.
Putting the ROM at address 0 will break compatibility with P1 Spin that uses address 0 for CLKFREQ and 4 for CLKMODE. It also affects PropGCC that used location 5 and 6. Of course, this is not a big deal since everything will need to adapt to P2 anyway.
Putting the ROM at address 0 will break compatibility with P1 Spin that uses address 0 for CLKFREQ and 4 for CLKMODE. It also affects PropGCC that used location 5 and 6. Of course, this is not a big deal since everything will need to adapt to P2 anyway.
It does not HAVE to be at 000, the important detail is it is a single Long, ROM coded, at a fixed and known location, that does not vary with ROM changes or variant devices, and so allows binary compatible operation, on ROM variants.
Add: Making it @zero is I believe more novice safe, as if you start to move the reserved byte up,
there is more chance someone will treat it as RAM....
Tools patches could partially avoid this, but not all code lets the tools choose.
If @zero is too invasive, then a Long/word @RAMTOP, can still show the size of ROM in that device.
Comments
I like the larger offset range, but I also liked the immediate addressing of $0000-$00FF, as it meant a single instruction could be used to read/write to a mailbox by any cog.
Without the immediate mode, it will now take two instructions - ie set pointer A or B, or modify a long address in another register.
I am curious, why does the ROM have to overlap RAM? I'd prefer the ROM to start at $FFFFFFFF leaving a lot of room for it to grow down, and RAM to start at $00000000 leaving room for it to grow up
Why?
0x01 plus start bit is eight bit periods.. save CNT when RX goes low, save it when it goes high, divide by 8 and you get the bit period in clock cycles!
Oh, I thought this AutoBaud was just for the ROM loader ?
Is this for ROM, or a loaded user monitor ?
Large jumps are always going to be a challenge, and a risk.
Can a Prop 2 timer optionally always clock from the 20MHz - to keep the numbers reasonable, or perhaps the user could adjust the capture/compare value, as they change gears, as they know where they are going from/to ?
Don't you mean 0x80? Serial is LSB-first.
-Phil
$0x08 and divide by 4 (you could even time the second low period of four bits and average)
However, I do agree with Bill in having ROM grow down, RAM up. One look ahead to P3 makes me wonder if having ROM start low isn't a kludge of some sorts... P2 ended up significantly more complex than P1, and building off the very clean P1 looks like it's going to pay off very nicely. So there is a purity argument. Not sure what that's worth, but I like that kind of thing just because.
Are the offsets that important? Well, more important than the optimal mailbox cases? I don't know. We've got the inter-cog comms now, (PORT D + MASKS) meaning mailboxes don't have to be used in all the ways they basically must on P1, unless somebody uses real pins.
Edit: Is the goal to have power of two alignment at top of RAM? If so, I think that's worth a lot.
VERY good point!
It is not as RAM will not start as ---> 0
Both RAM and ROM with start at ---> 0
And ROM will be disabled in RUN mode as it is not necessary after BOOT
After boot, it would be very nice to have SQI speed from the memory. With a 160 MHz Prop II, that should equate to an actual 4X speed increase...
Without immediate addressing, you would need the address of the mailbox in a register which you would use in lieu of an immediate.
Rather than putting four ROM instances onto the die (we didn't have room, it turned out), we just borrowed the last few word lines of the hub RAMs and put ROM bits in, instead of the normal 6T SRAM cells. This made the memory faster, too, since it didn't have to tri-state its outputs to share with the ROMs. So, now we've got a hybrid memory that is RAM and ROM. We would need to add an address bit to the hub memories to get those ROM bits out of the first 128k. In retrospect, we should have done this, but it's too big a change to make, at this point. We only realized we could plug in ROM bits after many other things had cemented up.
No, the ROM area is always ROM, as it actually replaced (in silicon!) the RAM bits with ROM bits inside those memories.
You got it.
A variant on this, could have the long at $FFFFFFFF, indicate where the BOTTOM of ROM is, so you always know where you are,
and ROM changes can be managed ?
Ok now I understand.
BUT i think after I read all on it it was not correct way to go as You need ROM only in BOOT mode to load COG ---- COGs if You had more ROM place.
On my thing I work on --- I have both RAM and ROM starting at ---> 0
and after reset default is ROM --- that is loaded and forgotten.
And RAM switched in.
Ah, if ROM is wire-initialised RAM, and has to be in the same map, I think you need to allow for ROM Size changes.
So placing all ROM at 000 is not going to be nice.
Perhaps you could place one Long of ROM at 000, that says where real ROM starts ?
That way user code would load and run the same, on future Props that may have ROM updates, and on Prop 3.
What does the Prop 2 return, for reads above physical memory ?
I would like to be able to use MCP2210
It's a 20pin USB-to-SPI Protocol Converter with GPIO (Master Mode)
More options than just FDI is always good.
Either P2 is static, or not, but if it's not, then we've built in something really nice for a very small cost, which could pay off really nicely.
If P3 ends up a variant of P2, instead of another big build out like P2 is over P1, same advantage.
If P3 is significantly built out, there will be code changes / up-ports and such needed, and that all goes like it is right now, the trade-off being we get a much better chip, which justifies the new code.
No downsides to this, and several potential gains, IMHO.
Start and end are perhaps confusing. I would point the special 1 Long ROM @ 0000, to the lowest Code ROM address, as that would be where any copy started from. ROM Tables etc would be above that ?
Re/ immediate addressing - if I needed to deal with say 16 longs for mailboxes, I'd chew up 16 cog longs, or have to load PTRx - chewing up longs.
The larger index range is nice though. Tough call.
Ah, right, of course, first read fills the buffer. Presumably it's just an upper address compare on each access so that buffer locations can be read in any order. Refreshing stale data would require a double-buffer approach then I guess.
The uninitiated know nothing about Cog space at all. It's all Spin space which is Hub space.
I was meaning a single ROM byte at 000, so user RAM does NOT need to be re-compiled to run on a ROM-Size variant.
The same binary will work.
So Adr0 is ROM, Adr1..128k-RomSize is RAM and 128k-RomSize+1..128k is ROM.
The ROM byte at 0000H has [128k-RomSize] loaded, so points to the top of RAM+1
User code would allocate RAM from 1 up, and/or stacks/fifos from Value at 0000H down.
Either way, it's a pointer to the RAM / ROM region, whether or not it's top or bottom of the address space, which I second however it ends up being done.
Now we need to see how Top-ROM vs Bottom ROM gets settled.
It does not HAVE to be at 000, the important detail is it is a single Long, ROM coded, at a fixed and known location, that does not vary with ROM changes or variant devices, and so allows binary compatible operation, on ROM variants.
Add: Making it @zero is I believe more novice safe, as if you start to move the reserved byte up,
there is more chance someone will treat it as RAM....
Tools patches could partially avoid this, but not all code lets the tools choose.
If @zero is too invasive, then a Long/word @RAMTOP, can still show the size of ROM in that device.