Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 129 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1126127129131132160

Comments

  • cgraceycgracey Posts: 14,131
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »

    There are 7 differential inverters in the loop.

    That gives another solution point of 9 inverters.
    If we say 7 is 450MHz, 9 is appx 350MHz typ-max, which sounds about right ?
  • TonyB_TonyB_ Posts: 2,099
    edited 2018-03-24 10:02
    cgracey wrote: »
    TonyB_ wrote: »

    Bug alert:
    Is the 4-bit skip call counter only decremented on RET/_RET if it is non-zero?

    Yes. It works that way.
  • TonyB_TonyB_ Posts: 2,099
    edited 2018-03-24 00:47
    cgracey wrote: »
    About the hub RAM map...

    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?



  • TonyB_ wrote: »
    Bug alert:
    Is the 4-bit skip call counter only decremented on RET/_RET if it is non-zero?
    Correct.

  • ozpropdev wrote: »
    TonyB_ wrote: »
    Bug alert:
    Is the 4-bit skip call counter only decremented on RET/_RET if it is non-zero?
    Correct.

    That's good to know. Thanks, ozpropdev!

  • TonyB_ wrote: »
    cgracey wrote: »
    About the hub RAM map...

    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.


  • Cluso99Cluso99 Posts: 18,066
    edited 2018-03-24 08:00
    Contiguous memory is ALWAYS SUPERIOR.

    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.
  • cgraceycgracey Posts: 14,131
    edited 2018-03-24 10:06
    TonyB_ wrote: »
    cgracey wrote: »
    About the hub RAM map...

    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.
  • evanhevanh Posts: 15,091
    edited 2018-03-24 10:12
    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.
  • cgraceycgracey Posts: 14,131
    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.
  • Cluso99Cluso99 Posts: 18,066
    Is there a cost for faster RAMs?

    Still think you are wrong in forcing the debug space on everyone.
  • cgraceycgracey Posts: 14,131
    edited 2018-03-24 11:00
    Cluso99 wrote: »
    Is there a cost for faster RAMs?

    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.
  • evanhevanh Posts: 15,091
    edited 2018-03-24 11:06
    cgracey wrote: »
    Unless we reserve some memory, though, debug won't always be viable.
    How come? Surely those that want it will use it appropriately.

  • cgraceycgracey Posts: 14,131
    evanh wrote: »
    cgracey wrote: »
    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.
  • evanhevanh Posts: 15,091
    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.
  • cgraceycgracey Posts: 14,131
    evanh wrote: »
    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.
  • cgracey wrote: »
    evanh wrote: »
    cgracey wrote: »
    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.

  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    Is there a cost for faster RAMs?

    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.

  • I missed the last change.

    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.



  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?

  • rjo__rjo__ Posts: 2,114
    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.

    Security... really?

  • Heater.Heater. Posts: 21,230
    evanh,
    Oh, that's not really debugging at all. That's more about reverse engineering.
    Hmm...isn't "debugging" and "reverse engineering" the same thing?

    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.

  • Cluso99 wrote: »
    Contiguous memory is ALWAYS SUPERIOR.

    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.

    A little while ago somebody mentioned 1920 x 1080 x 2bpp which needs 506.25KB.
  • TonyB_TonyB_ Posts: 2,099
    edited 2018-03-24 22:42
    cgracey wrote: »
    TonyB_ wrote: »
    cgracey wrote: »
    About the hub RAM map...

    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?
  • jmgjmg Posts: 15,140
    edited 2018-03-24 22:54
    TonyB_ wrote: »
    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.
  • jmg wrote: »
    TonyB_ wrote: »
    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.
  • A while back, the discussion was robust debug or not.

    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.

  • potatoheadpotatohead Posts: 10,253
    edited 2018-03-24 23:51
    When the end user runs the application there won't be any Debug code. Unfortunately there won't be 512KB of hub RAM, either.

    Precisely. It's just there. Standard feature, same as any other feature a user may or may not use.


Sign In or Register to comment.