default baud rate and clock frequency for P2?

Just wondering what folks' opinions are on the default clock rate and frequency for P2 programs. On P1 a lot of programs ended up using 115_200 baud and 80 MHz. Early P2 development tools either defaulted to this (p2gcc) or used 230_400 and 160 MHz (fastspin). That was fine for development, but now that we've got (approximately) final hardware and we've seen that things are stable at a higher clock frequency, I wonder if we should establish a kind of informal convention for baud rate and clock. It would just be a convention, of course -- particular applications may have particular requirements on clock frequency or baud, and naturally they'll use whatever is appropriate. But it would be convenient if the tools and terminal emulators defaulted to some widely used values.

Here are some thoughts on baud rates:
  115_200: matches common P1 baud rate, but is slow
  230_400: double P1 rate, so convenient, and good for bit-banging. But slow for file transfers and such.
  921_600: I think some terminal programs max out at this. Decent speed
2_000_000: max that the ROM bootloader supports?
921_600 seems like a good compromise between speed and widespread support. OTOH for tools like loadp2 that we have control of perhaps 2_000_000 is better, especially if we're doing things like serving files or doing TCP/IP over serial. The only drawback of these higher speeds would be that bit-banged serial becomes tricky, but honestly for P2 people should be using the smart pins for serial I/O so I think that's a very minor consideration.

For clock rates, I honestly don't know what the current thinking is. 160 MHz was definitely a conservative choice (probably too conservative!) motivated by the convenient fact that it was twice the common P1 clock frequency. But I think a higher frequency might be better for many applications. Do we have a sense now of a "safe" upper bound? At one point the chip was spec'd to 180 MHz, but I think we're up to 252 MHz now?

Again, all this is just thinking about conventions or defaults. I'm definitely not trying to suggest that all applications must all use the same clock speed or baud rate! For programs where neither of these really matter, though, what should we pick?

Comments

  • For what its worth, I’m routinely running the P2-ES Rev B board at 320 mhz. I’ve had no stability issues there. The chip does get quite warm when you work more than a couple of cogs hard, but it handles it just fine.

    I tend to run the serial link rather slow: 230k. That setting just seems to work best for me across multiple platforms, operating systems, and generations of computers.
  • I’m doing 115200 baud and 250 MHz
  • It's a tough one. In theory you'd probably want to choose a clock speed default that is within the spec of the P2, so is that 180MHz these days or higher? It might still be 180MHz.

    If you want to enable video, 252MHz is only really good for official digital HDMI/DVI output at VGA resolution. It may be just a subset of people who want/need to use that.

    Another reasonable clock speed choice that still supports analog video might be 200MHz - with that rate you could get both analog VGA at 25MHz and SVGA at 40MHz and potentially close to XGA 65MHz dot clocks (using 66.66MHz) using simple integer dividers of the base P2 frequency. It would also let you run the existing HyperRAM board at its rated speed for 200MB/s which is handy.

    If there is going to be a default we'd probably want to pick some rate that also is known to work fine with USB in case there are any dead zones there (from memory I think there were a few frequencies that garryj encountered some timing issues).

    Ideally people can write objects that work over a range of clocks by patching their code appropriately, though in some cases that makes things rather difficult, and for some synchronous applications that may not be possible.
  • I don't think there's going to be the same tendency to use a common frequency. It's so much easier to get a wide range and it doesn't even crash when over-ranged. Almost foolproof.

    What will limit many is thermal or power restrictions. If they don't want to use any heat-sinking for example, then the die will get warmer and they may be limited in clock frequency.

    As for a spec, the OnSemi rating is now at 175 MHz. 250 MHz would be a convenient spec for Parallax to support given the desire to list DVI/HDMI output as supported.

  • I'm happily still using 115200 baud for user as this lets me do testing down below 1 MHz sys-clock.

  • evanh wrote: »
    I'm happily still using 115200 baud for user as this lets me do testing down below 1 MHz sys-clock.
    Yeah and 115200 is probably safer and more universal, despite potentially being "slowish" these days. Also once you choose high serial rates like 2MBd etc, you might start to be at the mercy of various USB-serial adapter performance limitations with internal buffer sizes etc, not all may work nicely at the high rates whereas it would be unusual to find something not supporting 115200 bps.
  • I've been finding 230400 rather slow when using loadp2's built in file server -- it works out to a bit over 20KB per second, so it takes 25 seconds or so to fill the P2's memory with it :(. 2Mbaud would be nearly 10x faster.

    loadp2 has defaulted to 2Mbaud for downloads for a while now, and I haven't heard of any issues. After the download it switches to whatever the user specifies for the terminal speed, which is usually 115200 or 230400. But if the download is working well then there's probably no reason not to run the terminal at the same speed.
  • I see the point with the loader being faster, and people can tune their image downloads to whatever speed they can get. The runtime speed for serial I/O is possibly a slightly different case. Setting it too high may mean that every program written for the P2 will default to a speed that not all systems can support, meaning shared binaries are problematic for some people and if they have a slower system they'd have to get the source and customize every program they want to use. It's a hard one and I'd obviously prefer as fast as possible too.
  • I suggest that the maximum clock rate should be set so that the chip doesn't exceed a temperature that is painful to the touch. This article suggests that the threshold for pain is at 44C (111F). Some tests could be run on the P2 eval board that is running a worse-case program on all 8 cogs. I think Chip has posted a program that toggles lots of transistors. A graph showing case temperature versus clock rate could then be generated. Maybe Chip has already done this.

    I think 115200 is a good default baud rate. It is supported on virtually every system, and the rate is sufficient for most purposes. When a higher rate is needed, such as for transferring large files, it can be set by the program.
  • The analog RCFAST clock source was designed to always run at over 20MHz, which enables the auto-baud-detection in the boot ROM to work at up to 2Mbaud, which is the baud rate that PNut uses to talk to the P2.
  • Cluso99Cluso99 Posts: 15,686
    edited 2020-01-13 - 04:39:06
    I've used 115,200 baud just because that's what I use with P1 so my terminal programs have been set to default to that.

    If it were to change then I'd suggest we shift to say 921,600 (8*115200), or 2M baud. Haven't looked to see if PCs/Macs will work at 2MB or if they need to be some binary multiple of 300 or 1200??? @jmg - you there?

    As for xtal, IIRC P2D2s are 12MHz, P2-EVALs are 20MHz, so 0.5/1/2/4MHz could be a common divide by base.

    148.5MHz was a sweet spot for VGA IIRC, so 297MHz might be a nice overclocked speed ???
  • Only the very first P2D2 boards were 12MHz while the current version being produced are set to output a standard 20MHz. As for baud rate while I favor 2M, I find that I dumb it down to 115200 for compatibility as almost any serial coms can handle this. While 921600 is better, I would be more inclined to just up it to 2M and be done with it.
  • Cluso99Cluso99 Posts: 15,686
    edited 2020-01-13 - 06:10:38
    Only the very first P2D2 boards were 12MHz while the current version being produced are set to output a standard 20MHz. As for baud rate while I favor 2M, I find that I dumb it down to 115200 for compatibility as almost any serial coms can handle this. While 921600 is better, I would be more inclined to just up it to 2M and be done with it.
    Agreed. Yes 2MB :smiley:

Sign In or Register to comment.