The VCO frequency cannot overshoot the target by maybe more than 5%. It changes bias quite slowly, as it's designed for steady clock generation, not for something aggressive like bitstream locking.
Debugging needs to be invokable in all cases, not just accommodated when needed. For this reason, we need to have a constant memory map that always allows for the possibility of debug. This means sacrificing some RAM. We are talking about 16KB here. That's just 3% of the 512KB total.
3% sounds like not much at all, but 16KB sounds like a substantial amount!
I'm not sure where we stand with hub RAM now, so a couple of questions:
1. Is 496KB always mapped at the bottom of the address space and 16KB always at the top?
2. Is is possible to use all 512KB of hub memory as general-purpose RAM when debugging is not required?
Debugging needs to be invokable in all cases, not just accommodated when needed. For this reason, we need to have a constant memory map that always allows for the possibility of debug. This means sacrificing some RAM. We are talking about 16KB here. That's just 3% of the 512KB total.
3% sounds like not much at all, but 16KB sounds like a substantial amount!
I'm not sure where we stand with hub RAM now, so a couple of questions:
1. Is 496KB always mapped at the bottom of the address space and 16KB always at the top?
2. Is is possible to use all 512KB of hub memory as general-purpose RAM when debugging is not required?
Yes it can be used that way, but is not contiguous.
Debugging needs to be invokable in all cases, not just accommodated when needed. For this reason, we need to have a constant memory map that always allows for the possibility of debug. This means sacrificing some RAM. We are talking about 16KB here. That's just 3% of the 512KB total.
3% sounds like not much at all, but 16KB sounds like a substantial amount!
I'm not sure where we stand with hub RAM now, so a couple of questions:
1. Is 496KB always mapped at the bottom of the address space and 16KB always at the top?
2. Is is possible to use all 512KB of hub memory as general-purpose RAM when debugging is not required?
1) Yes.
2) No. That would mean that debugging could be made inoperative. Debugging is going to be like Facebook on your Android device. You can't get rid of it. And it's for your own good.
Chip, you might want to expand on the importance of point #2 answer. As it stands, anyone that is not interested in using the debug system, and would like to have HubRAM as contiguous, is loosing out.
So, the earlier argument, by some, that it can be ignored by those that don't want it, seems a tad deceptive.
Been working like mad to cover everything with OnSemi.
It looks like the floorplan is done and we are on the way to final synthesis. 160MHz is no problem. If we put in faster hub RAMs, we could even get to 200MHz. We'll know in a day, or two, about this. With no faster RAMs, we should be able to close timing at 180MHz. Maybe that's good enough, though 200 is a nice, round number.
To solve the PLL problem, where the VCO goes too fast for the PLL's VCO divider, I lengthened the gates on the VCO's differential inverters to slow them down, and then I added a mux to be able to select the VCO directly, when the VCO post-divider is set to %1111, which would normally divide the VCO by 32. This means that for 100..200MHz, we will use the VCO directly, without a post-divider. The VCO can now go 285MHz, worst case. It was going 630MHz at typical case on the test chip. That's too fast.
Still think you are wrong in forcing the debug space on everyone.
It would take a little more space and current. I'm thinking it may be too crazy to embark on, at this point. We are right at the cusp of being on final trajectory if we don't change anything.
I know you hate the debug RAM thing. Unless we reserve some memory, though, debug won't always be viable.
Unless we reserve some memory, though, debug won't always be viable.
How come? Surely those that want it will use it appropriately.
I'd like it to be usable with a full application, requiring no code modification. Imagine being able to take any complete app and debug it without worrying about memory caveats. Whatever you've got, or someone hands you, you can deal with on a debugging basis.
Oh, that's not really debugging at all. That's more about reverse engineering.
While I don't have a major issue with reverse engineering as such, I'm certainly not in favour of making such an exception to accommodate it.
Hmmm.... I don't think about it like that. You'd have to have sources to use it, so that the debugger has some awareness of where things are. The point is that a different type of download can be done which enables debugging. That is, if you want the full debugger experience. You can write your own debug routines for cogs, if you'd like, but there needs to be a system-level approach, too, for teaching people what goes on.
Unless we reserve some memory, though, debug won't always be viable.
How come? Surely those that want it will use it appropriately.
I'd like it to be usable with a full application, requiring no code modification. Imagine being able to take any complete app and debug it without worrying about memory caveats. Whatever you've got, or someone hands you, you can deal with on a debugging basis.
One possible problem with not begin able to turn debugging off to use the full 512K of RAM is that you then can't really advertise that the chip *has* 512K of RAM since the 16K is really dedicated to debugging and can't be used by applications.
We have an FPGA that can be used for debugging. Apart from the few things that cannot be properly emulated in the FPGA, the FPGA could be extended to provide way better debugging than is otherwise possible.
Remember there is no security in the P2 anymore. You don't want to give users easy ways to trace proprietary code. That would be way worse than no security, or no debugging.
Still think you are wrong in forcing the debug space on everyone.
It would take a little more space and current. I'm thinking it may be too crazy to embark on, at this point. We are right at the cusp of being on final trajectory if we don't change anything.
I know you hate the debug RAM thing. Unless we reserve some memory, though, debug won't always be viable.
Take the least risk and time approach. 180MHz will be great and while 200MHz would be nice it's not worth any time or risk.
Honestly, this path is very similar to other in tandem design choices. The software can just work, and do so in a standard way. Big education win here, IMHO.
I'd like it to be usable with a full application, requiring no code modification. Imagine being able to take any complete app and debug it without worrying about memory caveats. Whatever you've got, or someone hands you, you can deal with on a debugging basis.
That makes sense, but I'm not quite seeing that as being mutually exclusive ? Default Debug location is TOP, (1M-) and that includes the usually enabled protection.
That memory can also alias-decode to what is currently a hole, just under 512k, but that copy behaves just like the TOP cell in R/W rules.
Disable Debug, and that memory is normal, and continuous ?
Every time you boost the clock, more applications come into play.
Faster is always better... it is in the Laws of Physics... chapter 23, section a8.
On the debugger issue... sometimes Chip has a lot more going on upstairs than he has time to share. If he has gone to the trouble to do it... it probably makes ultimate sense and we can probably trust it:)
We are going to need external RAM anyway. 16K is nothing... it used to be a lot... today, it is nothing.
Debugging needs to be invokable in all cases, not just accommodated when needed. For this reason, we need to have a constant memory map that always allows for the possibility of debug. This means sacrificing some RAM. We are talking about 16KB here. That's just 3% of the 512KB total.
3% sounds like not much at all, but 16KB sounds like a substantial amount!
I'm not sure where we stand with hub RAM now, so a couple of questions:
1. Is 496KB always mapped at the bottom of the address space and 16KB always at the top?
2. Is is possible to use all 512KB of hub memory as general-purpose RAM when debugging is not required?
1) Yes.
2) No. That would mean that debugging could be made inoperative. Debugging is going to be like Facebook on your Android device. You can't get rid of it. And it's for your own good.
From the replies in the last few hours it's clear there is unhappiness about losing 16KB and I agree with that sentiment as 512KB is not a huge amount to start with.
I have no problem with losing RAM permanently for the debug buffers necessary for the number of actual cogs. I think 32 longs are switched in and out, which requires 32 x 2 x 4 = 256 bytes per cog or 2KB in total for 8 cogs. So the question is why are we losing an extra 14KB?
The P2 stealth debugging is very clever and it's obvious that Chip has put a tremendous amount of thought into it. If only 2KB were lost permanently and the other 510KB available in one contiguous block as user RAM, then nobody would have a valid cause for complaint. Quite the reverse, I predict much rejoicing.
Losing 2KB really is nothing at all, losing 16KB is too much. So why are we losing an extra 14KB?
I have no problem with losing RAM permanently for the debug buffers necessary for the number of actual cogs. I think 32 longs are switched in and out, which requires 32 x 2 x 4 = 256 bytes per cog or 2KB in total for 8 cogs.
That's only the swap memory.
Where is your Debug code itself going to go ?
The Debug area is also shared with the bootloader, and that size is determined by the ROM that this loads from.
There is a lot of useful stuff looking like it is going into that ROM.
I have no problem with losing RAM permanently for the debug buffers necessary for the number of actual cogs. I think 32 longs are switched in and out, which requires 32 x 2 x 4 = 256 bytes per cog or 2KB in total for 8 cogs.
That's only the swap memory.
Where is your Debug code itself going to go ?
The Debug area is also shared with the bootloader, and that size is determined by the ROM that this loads from.
There is a lot of useful stuff looking like it is going into that ROM.
What Debug code? When the end user runs the application there won't be any Debug code. Unfortunately there won't be 512KB of hub RAM, either.
Comments
That gives another solution point of 9 inverters.
If we say 7 is 450MHz, 9 is appx 350MHz typ-max, which sounds about right ?
3% sounds like not much at all, but 16KB sounds like a substantial amount!
I'm not sure where we stand with hub RAM now, so a couple of questions:
1. Is 496KB always mapped at the bottom of the address space and 16KB always at the top?
2. Is is possible to use all 512KB of hub memory as general-purpose RAM when debugging is not required?
That's good to know. Thanks, ozpropdev!
Yes it can be used that way, but is not contiguous.
IMHO splitting it up is a mistake that cannot be corrected. It's possible that some video mode will work with the whole 512KB but not in 496KB.
But for smaller P2's, if they come, 128KB = 112KB + 16KB. That's 12.5%.
Dual mapping solves the problem.
1) Yes.
2) No. That would mean that debugging could be made inoperative. Debugging is going to be like Facebook on your Android device. You can't get rid of it. And it's for your own good.
So, the earlier argument, by some, that it can be ignored by those that don't want it, seems a tad deceptive.
It looks like the floorplan is done and we are on the way to final synthesis. 160MHz is no problem. If we put in faster hub RAMs, we could even get to 200MHz. We'll know in a day, or two, about this. With no faster RAMs, we should be able to close timing at 180MHz. Maybe that's good enough, though 200 is a nice, round number.
To solve the PLL problem, where the VCO goes too fast for the PLL's VCO divider, I lengthened the gates on the VCO's differential inverters to slow them down, and then I added a mux to be able to select the VCO directly, when the VCO post-divider is set to %1111, which would normally divide the VCO by 32. This means that for 100..200MHz, we will use the VCO directly, without a post-divider. The VCO can now go 285MHz, worst case. It was going 630MHz at typical case on the test chip. That's too fast.
Still think you are wrong in forcing the debug space on everyone.
It would take a little more space and current. I'm thinking it may be too crazy to embark on, at this point. We are right at the cusp of being on final trajectory if we don't change anything.
I know you hate the debug RAM thing. Unless we reserve some memory, though, debug won't always be viable.
I'd like it to be usable with a full application, requiring no code modification. Imagine being able to take any complete app and debug it without worrying about memory caveats. Whatever you've got, or someone hands you, you can deal with on a debugging basis.
While I don't have a major issue with reverse engineering as such, I'm certainly not in favour of making such an exception to accommodate it.
Hmmm.... I don't think about it like that. You'd have to have sources to use it, so that the debugger has some awareness of where things are. The point is that a different type of download can be done which enables debugging. That is, if you want the full debugger experience. You can write your own debug routines for cogs, if you'd like, but there needs to be a system-level approach, too, for teaching people what goes on.
One possible problem with not begin able to turn debugging off to use the full 512K of RAM is that you then can't really advertise that the chip *has* 512K of RAM since the 16K is really dedicated to debugging and can't be used by applications.
Remember there is no security in the P2 anymore. You don't want to give users easy ways to trace proprietary code. That would be way worse than no security, or no debugging.
Honestly, this path is very similar to other in tandem design choices. The software can just work, and do so in a standard way. Big education win here, IMHO.
That makes sense, but I'm not quite seeing that as being mutually exclusive ?
Default Debug location is TOP, (1M-) and that includes the usually enabled protection.
That memory can also alias-decode to what is currently a hole, just under 512k, but that copy behaves just like the TOP cell in R/W rules.
Disable Debug, and that memory is normal, and continuous ?
Faster is always better... it is in the Laws of Physics... chapter 23, section a8.
On the debugger issue... sometimes Chip has a lot more going on upstairs than he has time to share. If he has gone to the trouble to do it... it probably makes ultimate sense and we can probably trust it:)
We are going to need external RAM anyway. 16K is nothing... it used to be a lot... today, it is nothing.
Security... really?
In both cases one is studying some complex thing that one does not understand in order to find out how it works.
Only the intent is different.
A little while ago somebody mentioned 1920 x 1080 x 2bpp which needs 506.25KB.
From the replies in the last few hours it's clear there is unhappiness about losing 16KB and I agree with that sentiment as 512KB is not a huge amount to start with.
I have no problem with losing RAM permanently for the debug buffers necessary for the number of actual cogs. I think 32 longs are switched in and out, which requires 32 x 2 x 4 = 256 bytes per cog or 2KB in total for 8 cogs. So the question is why are we losing an extra 14KB?
The P2 stealth debugging is very clever and it's obvious that Chip has put a tremendous amount of thought into it. If only 2KB were lost permanently and the other 510KB available in one contiguous block as user RAM, then nobody would have a valid cause for complaint. Quite the reverse, I predict much rejoicing.
Losing 2KB really is nothing at all, losing 16KB is too much. So why are we losing an extra 14KB?
Where is your Debug code itself going to go ?
The Debug area is also shared with the bootloader, and that size is determined by the ROM that this loads from.
There is a lot of useful stuff looking like it is going into that ROM.
What Debug code? When the end user runs the application there won't be any Debug code. Unfortunately there won't be 512KB of hub RAM, either.
Not won out, largely due to lack of robustness.
I'm of the opinion this feature is either awesome, or omitted as other software means can suffice.
3 percent of RAM is a reasonable tradeoff for what looks to be shaping up to be an excellent debug facility.
Given the playground this thing is, I'll bet it gets used far more than maybe anticipated.
Precisely. It's just there. Standard feature, same as any other feature a user may or may not use.