Shop OBEX P1 Docs P2 Docs Learn Events
CNT extension to 64-bit - Page 6 — Parallax Forums

CNT extension to 64-bit

12346»

Comments

  • K2K2 Posts: 693
    @ Brian Fairchild:

    You want a giant ecosystem with dirt-cheap hardware and abundant, complete, and free tools. Then you point out that such ecosystems already exist. But instead of joining them, you remain here to carp. You're not the first to do this, of course. But it remains as mystifying a phenomenon as ever.

    Clearly you've got a burr in your saddle blanket, but what can Chip or any 10 people do about it?
  • jmgjmg Posts: 15,173
    In the decade since work on the P2 started a lot has changed and I'm not sure the P2 has kept up.
    Kept up with what exactly ?

    Your laundry list merely shows how far and wide the tentacles have spread, and that no single chip has any hope of covering all those bases.
    Yes, 8 bit MCU's have continued on a trend line, and prices are lower, for more. 25c is now a useful price point.
    32b MCUs have spread up, into Pi-level and a new MCU from NXP has 4.5MB of RAM.
    32b MCUs also continue the spread into low power parts, check recent press releases from OnSemi and Renesas

    - but in some areas, like FPGAs, the action is where the money is, on the top end - which leaves more room in the middle for niche players.

    However, it is not so easy to find a useful package FPGA, if we take a look at 100 pin TQFP, for example, as that is the P2 package.
    Digikey lists just 73 normally stocked, from, $2.20 for basic 256LE MachXO2 thru to $23 for XC3S250E
    That Spartan 3 was released circa 2007

    RISC V is still a novelty. The next Prop may well include a RISC V.

    Another litmus test:
    180MHz+ is a decent MCU speed, of the 20k+ MCUs Digikey lists as normally stocked, if we filter for 180MHz just 1200 remain.
    Filter to 200MHz and 512kB, and ~800 remain (just 4% of where we started), with prices starting at $5.33/3k and going thru to a whole page above $30/5k
    That smaller space, is where P2 competes.
  • potatoheadpotatohead Posts: 10,261
    edited 2018-11-16 20:22
    Fact is, we all believe in this thing. I know I do.

    P2 will shine in distinctive ways. And getting at the good stuff will mean working differently too. It is that working differently that keeps me interested.

    I will be frank and say had the goal been to make a better Arduino, I would have found much better things to do. We can already get those. Same for Raspi.

    P2 can be worked with in more standard ways, but that just will not be optimal. Going against the grain, so to speak.

    A lot of this discussion boils down to wanting the cool stuff without the differences that make the cool stuff cool. Great example is, "I wish someone would make a machine rhat is as cool and easy to work with as an Apple Mac is, but without the price, and running Windows 10."

    That never happens, because it is the differences, the ways things work and the why that add value.

    Ever put Windows 10 on a Mac? I have, and suddenly it is just not the same. Still cool hardware, but otherwise normal. Might as well get a nice Lenovo. No joke.

    That is what treating a P2 like an Arduino will look like. People will wonder why not just get a more powerful Arduino. (And will be largely right about it)

    For better or worse, this chip is designed to work in very different ways. It can work in fairly ordinary ways, but anyone who really wants the sizzle, will need to also work in the different ways. If they do, they will get all the high value in the P2. And there is a whole lot there too.

    Either that all proves compelling, or it does not. We shall all see. I think it will.

    Asking for it to be true, by following the others out there, is like asking Apple to be more like Samsung, or Google. Not gonna really happen. Nor should it.

    Secondly, anyone wanting for that to happen probably needs to begin building that toolchain. And having done that work, the differences and tradeoffs will be more obvious.

    Ersmith has made one. I really like it.

    Chip will make one. I know I will like that too.

    Parallax will make one with Blockly and for education. I may not touch that one. Not my thing. But, it is attractive to many, so no worries.

    Anyone else?



  • cgraceycgracey Posts: 14,152
    KeithE wrote: »
    I understand Phil's point. At first I thought this was going to be an ECO sort of spin to produce an A1. Minimal edits to save costs and reduce risk and pull in the schedule. For example if wafers with base layers were already available, and waiting for metal only. But it sounds like it's an all layer B0 spin at this point.

    It has to be. The sign-extension bug is not fixable with anything less than an all-layer change.

    As long as we've got time, and we are pushing OnSemi to begin ASAP, we can make a few last-minute improvements to the design. This window is going to close shortly.
  • KeithEKeithE Posts: 957
    edited 2018-11-17 00:40
    >It has to be. The sign-extension bug is not fixable with anything less than an all-layer change.

    Didn't they sprinkle in some spare gates for this kind of thing? I've seen many things fixed with metal only changes.

    Maybe it's just to complex for anyone to want to try?
  • cgraceycgracey Posts: 14,152
    KeithE wrote: »
    >It has to be. The sign-extension bug is not fixable with anything less than an all-layer change.

    Didn't they sprinkle in some spare gates for this kind of thing? I've seen many things fixed with metal only changes.

    Maybe it's just to complex for anyone to want to try?

    They did, but there were over 2,000 carry chains that needed to be built. Even if the resources were available in unused cell, it's unlikely that it would have met timing, with all the crazy routing involved.
  • GETCT questions:

    1. Are interrupts deferred just for the first GETCT when 64-bit count is read? One hopes so.

    2. Is it idiot-proof? What happens if there are lots of GETCTs in a row?

    3. Could we please write the flags with something? C=D[31] and Z=D[30] the same as GETRND would be better than wasting the opcode bits. This could save a bit test with CT[31:0] for short inexact delays and it would be good way to clear the flags free of charge with CT[63:32]. GETCT and GETRND opcodes differ only in bit 0, so there would no extra logic involved.
  • Another option for GETCT flags is Z=D[0] so that a cog would know whether its code is aligned to even or odd clock counts.
  • edited 2018-11-17 01:31
    You're will still need to program for rollover even if count gets extended to 64 bits. Correct?

    I'm assuming the the counter doesn't get initialized to zero at power up.
  • >They did, but there were over 2,000 carry chains that needed to be built

    Yeah - that's a bit much!

    With your new counter scheme - is it required to always read all 64-bits? (Sorry if this was already covered.) It there any scenario where things could get out of sync, and the values returned out of order?e.g. if you reload a COG while it's in the middle of a read? I assume not, but I'm somewhat ignorant so have to ask.
  • It does get initialized to zero.
    So you can effectively ignore roll over, unless you plan on having your P2 run without any interruption for over 2000 years.
  • jmgjmg Posts: 15,173
    You're will still need to program for rollover even if count gets extended to 64 bits. Correct?

    I'm assuming the the counter doesn't get initialized to zero at power up.

    It does get set to zero. Only your distant descendants need to worry about rollover :)
  • jmgjmg Posts: 15,173
    KeithE wrote: »
    It there any scenario where things could get out of sync, and the values returned out of order?e.g. if you reload a COG while it's in the middle of a read? I assume not, but I'm somewhat ignorant so have to ask.
    TonyB_ wrote: »
    GETCT questions:

    1. Are interrupts deferred just for the first GETCT when 64-bit count is read? One hopes so.

    2. Is it idiot-proof? What happens if there are lots of GETCTs in a row?

    I think counter is read only, so cannot write-disturb, and the fetch-upper window should be a monostable type design that opens only for 1 following opcode, if not already open (the same signal can be used to defer INTERRUPTS).
    That means COG resets and any number of GETCTs will auto-restore to reading LOW first.



  • Cluso99Cluso99 Posts: 18,069
    Some of those top bits may as well be hardcoded to 0's.
    As Chip said, the metal layers will have migrated in ~100 years. (8nm only guarantees 10 years IIRC)
  • cgracey wrote: »
    To me, loading up a multi-GB IDE so that I can play with modern stuff...

    I've just looked. The current Arduino IDE, including C compiler, is a 103Mbyte download.

    I just downloaded MicroChip's MPLAB X v5.1... 829MB... ;-)
  • Cluso99Cluso99 Posts: 18,069
    I just heard that some xbox video games download 60GB updates and regularly too!
  • Yup.

    This rolling development model is making less and less sense every day.
  • william chanwilliam chan Posts: 1,326
    edited 2018-11-21 03:58
    Chip is on the right path.
    There is much less risk on changes now as he is getting more adept with the design process.
    The benefits in the changes now far outweighs the risks.
    The production P2 chip will outsell the Pi.
  • jmgjmg Posts: 15,173
    ...
    The production P2 chip will outsell the Pi.


    Now there is a brave forecast ! :)
    Raspberry Pi passed thru 15 Million sales in 2017.
  • cgraceycgracey Posts: 14,152
    edited 2018-11-21 04:29
    jmg wrote: »
    ...
    The production P2 chip will outsell the Pi.


    Now there is a brave forecast ! :)
    Raspberry Pi passed thru 15 Million sales in 2017.

    Microchip was selling a million PICs a day, 20 years ago.

    Did William accidentally type "i" instead of "1", maybe?
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Did William accidentally type "i" instead of "1", maybe?
    It's not totally nuts, as a prediction. Outselling PIC's would be..

    The first threshold/milestone would be to morph 'outsell' to mean exceed RaspPi sales rate - which is currently roughly running 450,000 a month
    Speaking of Pi, I notice they have a model A 3+, (November 2018) which keeps the 'A' line going, with a Pi-Zero PCB width, and is cheaper than the Ethernet-added Model B3+

    Makes that Pi-Zero connector/holes footprint more compelling
  • jmg wrote: »
    The first threshold/milestone would be to morph 'outsell' to mean exceed RaspPi sales rate - which is currently roughly running 450,000 a month

    No misstypes.

    Who needs a 1.2GHz ARM processor to do HDMI when P2 can do HDMI at 150Mhz?
    P2 can do USB, MicroSD, Ethernet, Wifi everything a Pi3 can do and use less power.
    P2 will have it's own P2Linux soon.
    I am one of those waiting to buy the Rev B chips.
Sign In or Register to comment.