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

1126127129131132160

Comments

  • 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: 14,030
    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: 1,328
    edited 2018-03-24 - 10:02:38
    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.
    Formerly known as TonyB
  • TonyB_TonyB_ Posts: 1,328
    edited 2018-03-24 - 00:47:31
    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?



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

    Melbourne, Australia
  • 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!

    Formerly known as TonyB
  • 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.


    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Cluso99Cluso99 Posts: 15,484
    edited 2018-03-24 - 08:00:42
    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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • cgraceycgracey Posts: 11,790
    edited 2018-03-24 - 10:06:38
    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: 8,116
    edited 2018-03-24 - 10:12:56
    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.
    I love the whooshing sound of deadlines as they fly by.
  • 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.
  • Is there a cost for faster RAMs?

    Still think you are wrong in forcing the debug space on everyone.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • cgraceycgracey Posts: 11,790
    edited 2018-03-24 - 11:00:59
    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: 8,116
    edited 2018-03-24 - 11:06:25
    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 love the whooshing sound of deadlines as they fly by.
  • 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.
  • 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.
    I love the whooshing sound of deadlines as they fly by.
  • 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.

  • 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.
    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • 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.

    My Prop boards: P8XBlade2 , RamBlade , CpuBlade , TriBlade
    P1 Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    P1: Tools (Index) , Emulators (Index) , ZiCog (Z80)
    P2: Tools & Code , Tricks & Traps
  • 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.



    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • jmgjmg Posts: 14,030
    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 ?

  • 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?

  • 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.
    Formerly known as TonyB
  • TonyB_TonyB_ Posts: 1,328
    edited 2018-03-24 - 22:42:40
    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?
    Formerly known as TonyB
  • jmgjmg Posts: 14,030
    edited 2018-03-24 - 22:54:01
    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.
    Formerly known as TonyB
  • 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.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • potatoheadpotatohead Posts: 9,833
    edited 2018-03-24 - 23:51:48
    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.


    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
Sign In or Register to comment.