P2D2 with P2-revB - taking orders!

12345679»

Comments

  • Very nice job Peter !!
  • Peter, thank you !

    I am amazed reading all those 'TAQOZ (reloaded) console' options you posted. That board is FULL of everything we have ever dreamed during all these years (easy ethernet and display interfaces, high speed I/O, huge and cheap storage, high-level file manipulation tools, RTC/I2C/SPI ... ). The Fastest and Funniest Development Board Ever.

    All that is included on the small P2D2 or is that for the big evaluation board?. In any case, it's great.
  • Peter,

    Any updates on progress with the P2D2 and associated boards?
  • Since the delivery of these boards has been delayed, would it be possible to delay them a bit further and allow us to order the companion boards at the same time? I'm in no rush for the P2D2 and would appreciate the opportunity to be able to order the other boards at the same time.
  • David Betz wrote: »
    Since the delivery of these boards has been delayed, would it be possible to delay them a bit further and allow us to order the companion boards at the same time? I'm in no rush for the P2D2 and would appreciate the opportunity to be able to order the other boards at the same time.

    always being careful what we wish: there is no definition of "a bit further". So Peter, don't fell motivated to wait until Pxhot is outdated ;-)

  • Peter,
    It has been very quiet for a while. I hope that is a good sign! Any updates on progress with the P2D2 and associated boards? An ETA?
  • TrapperBob wrote: »
    Peter, It has been very quiet for a while.
    I've just been assumming Peter is perhaps on a well deserved New Year's break. :smile:

  • Peter JakackiPeter Jakacki Posts: 8,854
    edited 2020-01-18 - 00:10:23
    TrapperBob wrote: »
    Peter,
    It has been very quiet for a while. I hope that is a good sign! Any updates on progress with the P2D2 and associated boards? An ETA?

    Everything is getting back to normal here, or as normal as it can be :)

    I'm happy with the initial units that were produced and with the UB3 chip acting as the USB serial and clkgen loader and reset control which also only resets the P2 on an actual power-up or DTR event, not just a disconnect/reconnect. Yes, I've had a lazy break from it all and feel I need to get some parts of my anatomy into gear. I just remembered that I was going to allow for a 5P35021 clkgen that can directly output up to 500MHz so that the P2 can be tested beyond the limits of its PLL. This chip will be in very close proximity to the P2 clock input. I will take a look at putting this onto the P2PAL itself since it has access to the clock pins because it is surface mounted onto the P2D2. I'm planning on making up the reset of the P2D2s this coming week, and testing and shipping (woohoo).


    I note that Rayman has HyperRAM working with 16bpp VGA so this option on the P2PAL means we could have TAQOZ sitting in less than 64K, and 16bpp in HyperRAM VGA, and still have 458k hub RAM free. Even with a simple text editor I can have relatively large files sitting in RAM, and a nice GUI, and still have plenty of memory and cogs left over for application code.
    cog 0 TAQOZ
    cog 1 Audio (when needed)
    cog 6 HyperRAM
    cog 7 VGA

  • I'm planning on making up the reset of the P2D2s this coming week, and testing and shipping (woohoo).
    Great!
    I note that Rayman has HyperRAM working with 16bpp VGA so this option on the P2PAL means we could have TAQOZ sitting in less than 64K, and 16bpp in HyperRAM VGA, and still have 458k hub RAM free. Even with a simple text editor I can have relatively large files sitting in RAM, and a nice GUI, and still have plenty of memory and cogs left over for application code.
    Yes the external RAM opens up a lot of new possibilities. If you can get your editor/GUI to work with file buffers obtained indirectly through a HyperRAM transfer API instead of directly reading all data purely from the hub then in theory you could have access to very large files stored in the HyperRAM, even with video running out of this HyperRAM at the same time, once you use my HyperRAM arbiter driver. I need to get back to working on that so it can be bundled with the driver.
  • Hi Peter

    What kind of circuit/device do you intend to use in translating 5P35021's available differential output levels ( LP-HSCL, LVDS, LVPECL) to P2-compatible LVCMOS levels, in order to be able to drive the P2 clock input towards its limits (~400 MHZ)?
  • Peter JakackiPeter Jakacki Posts: 8,854
    edited 2020-01-18 - 02:56:01
    Yanomani wrote: »
    Hi Peter

    What kind of circuit/device do you intend to use in translating 5P35021's available differential output levels ( LP-HSCL, LVDS, LVPECL) to P2-compatible LVCMOS levels, in order to be able to drive the P2 clock input towards its limits (~400 MHZ)?

    If I use a single-ended output from the LVPECL with VDDDIFF set to around 2.7V and appropriate termination, then this can be fed to the clock input of the P2 directly which will switch around the 1.6V mark normally.
    If though the P2 is set to crystal mode it will be biased about halfway and then I do not have to worry about VDDDIFF and simply use a cap to couple the "AC" clock signal. All good unless of course I am missing something and if I did miss something I will just do a new pcb :)

    I am also looking at other clkgen parts since they list that particular one as "obsolete" :)



  • rogloh wrote: »
    I'm planning on making up the reset of the P2D2s this coming week, and testing and shipping (woohoo).
    Great!
    I note that Rayman has HyperRAM working with 16bpp VGA so this option on the P2PAL means we could have TAQOZ sitting in less than 64K, and 16bpp in HyperRAM VGA, and still have 458k hub RAM free. Even with a simple text editor I can have relatively large files sitting in RAM, and a nice GUI, and still have plenty of memory and cogs left over for application code.
    Yes the external RAM opens up a lot of new possibilities. If you can get your editor/GUI to work with file buffers obtained indirectly through a HyperRAM transfer API instead of directly reading all data purely from the hub then in theory you could have access to very large files stored in the HyperRAM, even with video running out of this HyperRAM at the same time, once you use my HyperRAM arbiter driver. I need to get back to working on that so it can be bundled with the driver.

    Thinking about the inactive windows I would like to keep a copy of them in HR to simplify the redraw. Yes, I wouldn't need any tricks with editing large text files if I handled it in HR although most code files are relatively small anyway. My first editor will keep it simple and flat in hub RAM but I have various methods for larger files in hub RAM, and then the option of a flat file in HR. An editor ain't much of an editor either if it doesn't handle undo/redo well either.
  • Hi Peter

    I believe you are aware of the existence of Renesas AN=953 and/or other similar documents:

    https://idt.com/br/en/document/apn/953-quick-guide-output-terminations

    AN-953 shows some interesting options you can try, even if you need to resort to another brand/model of differential clock generator, in order to populate your boards.

    Perhaps an interesting option you can made available at your design is enabling the existence of two 50 Ohm-ready sub-micro smt connections, for differential clock inputs, so you can use one board as the master clock generator to another one (more if you choose a master clock generator that can produce, says, four fully-differential clock outputs, capable of reaching up to 400 MHz (and a bit more, if posible).

    That way you can have at least two P2D2 controlled by a single clock generator mounted on a "master" pcb, while the "slave" accepts its clock source from a external source, and sure, don't needs the clk-gen chip at all.

    If you use a clk-gen device that can control the phase and early/late timing of each clock output independently (in near to +- ~1nS steps), you can reach, says, four interconnected P2, whose clock inputs could be put within any timing relationship with other one(s), easing things like streamer-driven data transfers between them, as well as almost-perfect matches between P2 and HyperBus-enabled or similar devices, even if, says, the HyperBus-enabled device resides in another pcb.

    Very defying scenarios, where a P2 (or HyperBus-enabled device) is acting as the data-provider (or receiver) while another P2 (in another pcb) acts as a peer for such kind of transfers can be devised/tested in a snap, turning the P2D2 a natural choice whenever teaming-up many P2 can be a solution for some intrincate P2-cluster project.

    Hope my poor english didn't messed with the contents of the idea I'm trying to convey.
Sign In or Register to comment.