New P2 Silicon Observations

1235723

Comments

  • Also you are lucky. You can use RISC V formal to check your work.
  • Great, isn't it?

    Not that I have got that far yet...

  • evanh wrote: »
    There is a group of missing timing values in the docs: SETQ/SETQ2 + RD/WRLONG

    [/me goes reads the details of SETQ ...]

    EDIT: Okay, it'll just be RD/WRLONG timings plus however many loadwords are read/written.

    Good point. That should be documented.

    It's going to be the same as RD/WRLONG, plus one clock for each extra long, barring any priority interruptions from the streamer.
  • cgraceycgracey Posts: 11,762
    edited 2018-09-30 - 20:18:55
    evanh wrote: »
    Opps, I see. It was all nulls so wasn't printing until the valid data came through. Fool myself. :)

    Thanks for testing that, Evanh. My first impression on reading your initial post was that D[31] + RDFAST was waiting, afterall. Then I remembered testing it for no-wait and it worked okay.
  • KeithEKeithE Posts: 955
    edited 2018-09-30 - 21:29:04
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.
  • jmgjmg Posts: 14,021
    cgracey wrote: »
    I made a bunch of current measurements of 0..7 cogs running from 20MHz..220MHz:

    https://docs.google.com/spreadsheets/d/1maeX7_tFKshFVPXdt9scWupgoN61MaEniNhF2_901l4/edit?usp=sharing

    If you repeat those measurements for 1.5V Core Voltage, what do they look like ? (including Quiescent power numbers )
    Not everyone wants 180+ MHz, and it may be that a 100+MHz part that runs at lower power at 1.5V than 1.8V is a better fit for some designs ?

    The Cpd formula predicts appx (100MHz)
    Vcc = 1.8 Pd = Cpd * Vcc^2 * Fi Pd = 518mW
    Vcc = 1.5 Pd = Cpd * Vcc^2 * Fi Pd = 360mW
  • KeithE wrote: »
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.
    Interesting. Does it optimize well? GCC and LLVM are pretty good at optimization.

  • Wow!

    I have no idea about the Plan 9 C compiler but if it runs on the PicoRV32, which has no memory management and such heavy weight OS stuff, it sounds promising.

    Back in the day BDSC could compile C code on a 64K Z80 machine running CP/M. (Still the first and only C compiler to actually run on a Propeller chip by the way)

    Given the vastly bigger memory space of the P2 a self-hosting C compiler should be possible.


  • Heater. wrote: »
    Wow!

    I have no idea about the Plan 9 C compiler but if it runs on the PicoRV32, which has no memory management and such heavy weight OS stuff, it sounds promising.

    Back in the day BDSC could compile C code on a 64K Z80 machine running CP/M. (Still the first and only C compiler to actually run on a Propeller chip by the way)

    Given the vastly bigger memory space of the P2 a self-hosting C compiler should be possible.

    This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler. We have people who are happy to have PC-based tools and those who want a self-hosted development environment. We don't even have a very large community here but even that small community is hopelessly splintered. I'm afraid none of these efforts (except maybe p2gcc) are going to succeed because none have enough resources with all of the other projects going on.
  • octettaoctetta Posts: 54
    edited 2018-09-30 - 22:31:48
    KeithE wrote: »
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.

    KeithE/Heater/David, I would support this 100% with love and effort. I know a few wizards in the plan9 community who had an interest in the P1 years ago who I could reach out to for help.

    In case others here are curious, the plan9 compilers favor simplicity of implementation over optimizations. In fact the Go language community leveraged this compiler family early in that language's development (I haven't kept up with the state-of-that-art).

    During my TurboPascal and TurboC days, when those compilers couldn't generate optimal code, we just used the asm keyword to insert x86 code. I'd favor that to be honest.

    Quite honestly, I've avoided the whole GCC thing here because after "porting" it to a couple of architectures back in the late 90's, there's no way I'd subject myself to that complexity again.

    On the other hand, non-GCC might cause others grief here... from my point of view, if we had a nice front end, ala the Arduino multi-platform front-end, 75% of the users wouldn't care as long as there was a smooth path from code-example to code-execution.

    While I'm on this rant, I saw that the TI430 community has their Arduino development environment (https://energia.nu) that leverages on that community's work (has GCC behind the scenes).
  • jmgjmg Posts: 14,021
    David Betz wrote: »
    This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler. We have people who are happy to have PC-based tools and those who want a self-hosted development environment. We don't even have a very large community here but even that small community is hopelessly splintered. I'm afraid none of these efforts (except maybe p2gcc) are going to succeed because none have enough resources with all of the other projects going on.

    That's true, but this is early research stages, and simpler has the appeal it is easier to actually do the port.

    octetta wrote: »
    KeithE/Heater/David, I would support this 100% with love and effort. I know a few wizards in the plan9 community who had an interest in the P1 years ago who I could reach out to for help.

    In case others here are curious, the plan9 compilers favor simplicity of implementation over optimizations. In fact the Go language community leveraged this compiler family early in that language's development (I haven't kept up with the state-of-that-art).

    During my TurboPascal and TurboC days, when those compilers couldn't generate optimal code, we just used the asm keyword to insert x86 code. I'd favor that to be honest.

    Quite honestly, I've avoided the whole GCC thing here because after "porting" it to a couple of architectures back in the late 90's, there's no way I'd subject myself to that complexity again.
    Are there any pages/links of current plan9 activity and active ports ?
    Which C standards does to comply with ?

  • David Betz,
    This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler
    Yes, wouldn't it be great if we could harness all the Propeller heads to do the one true thing? Whatever that is.

    It's in the nature of Propeller heads, and humans in general, that this is no so easy.

    Which I would say is a good thing in some way. It gave us the Catalina and ImageCraft compilers. It gave us BST and HomeSpun. Back in the day it gave us propasm by Clif Biffle.

    At the end of the day everyone has different skill sets and different passions that drive them.

    Me, I'm just an observer of all this. Happy that I got some emulators running on the P1 that enabled using real compilers.

  • jmgjmg Posts: 14,021
    KeithE wrote: »
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.

    Maybe this language diversion, should go into its own thread, so as to not confuse the new-p2-silicon-observations thread ?
  • octettaoctetta Posts: 54
    edited 2018-09-30 - 23:42:14
    Are there any pages/links of current plan9 activity and active ports ?
    Which C standards does to comply with ?

    I'll leave this here:

    https://9p.io/sys/doc/compiler.html

    You might recognize the author. :D
  • Heater. wrote: »
    David Betz,
    This is one problem with doing work on a C compiler for the P2. Lots of people want to go in lots of directions. We have p2gcc already and there is talk of a GCC or an LLVM backend. Now we're talking about a port of the Plan 9 C compiler
    Yes, wouldn't it be great if we could harness all the Propeller heads to do the one true thing? Whatever that is.

    It's in the nature of Propeller heads, and humans in general, that this is no so easy.

    Which I would say is a good thing in some way. It gave us the Catalina and ImageCraft compilers. It gave us BST and HomeSpun. Back in the day it gave us propasm by Clif Biffle.

    At the end of the day everyone has different skill sets and different passions that drive them.

    Me, I'm just an observer of all this. Happy that I got some emulators running on the P1 that enabled using real compilers.
    Let's see, RossH who wrote Catalina is gone and so it is now unsupported, ImageCraft abandoned their Propeller offering. BST has been abandoned as has HomeSpun I believe. Even PropGCC has stagnated. Is this what we want again?
  • That does sound very gloomy David.

    I have no idea what those guys are up to now. Clearly their propeller heads took them off to other realms.

    Sounds like we still have some skillful Propeller enthusiasts on board though.

    I hear that new guys on the block want to get MicroPython running on the P2.

    Hmm...except that will require a C compiler...

  • jmg wrote: »
    KeithE wrote: »
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.

    Maybe this language diversion, should go into its own thread, so as to not confuse the new-p2-silicon-observations thread ?

    Seconded, there are a number of existing threads for C-related discussions. Please use those, not this.
    Formerly known as TonyB
  • TonyB_ wrote: »
    jmg wrote: »
    KeithE wrote: »
    Heater - check out this tweet:

    “Richard Miller tells us we can use the Plan 9 C compiler instead of GCC or LLVM #ORConf“

    To which Clifford replied:

    “It even runs on PicoRV32! <3

    https://orconf.org/#plan9

    I wonder how hard it would be to target P2? And run on P2.

    Maybe this language diversion, should go into its own thread, so as to not confuse the new-p2-silicon-observations thread ?

    Seconded, there are a number of existing threads for C-related discussions. Please use those, not this.

    +1 YES - why can't we self-regulate ourselves when we see we are going OT and cluttering the thread?

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • I don't know if the PropGCC development was contributed back, but the *secret* to keeping stuff relevant is to contribute it upstream to the main project. If there is an LLVM port, then that port needs to be contributed back to LLVM so it's not just a pet project of 1 person.

    I've seen the results of forks in the past, they never survive reliably and just end up being much harder to maintain as the core arch of the forked project changes.

    I've never used/tinkered with LLVM, but I've heard lots of good things about it. I see it as the BSD of compilers as GCC is the Linux of compilers.

    You can be certain that if I get MicroPython working, I'll be issuing pull requests to their Git repo.
  • AleAle Posts: 2,356
    Arithmetic manipulation between mixes of signed
    and unsigned may simulate and synthesize in unintended
    ways

    I dream of having to deal with that... no I don't. It may be because of such things that the VHDL crowd seems so keen of the strong types in VHDL. No sarcasm here. I just wonder... I don't know the matter deep enough to judge.

  • That is the sort of reason I'm getting into SpinalHDL for logic design. Being based on the Scala language Spinal is very fussy about types and all kind of other checks that can catch one out in Verilog. Besides it's generally a much higher level and nicer language than Verilog. Spinal generates Verilog or VHDL code so it's easy to check that you get what you order.
  • I just did a test to determine if my limited use of '$signed' caused the problem in the modulator.

    It did.

    Altera's Quartus II Verilog compiler sign-extends any term within a $signed() construct, whereas the ASIC Verilog compiler only honors $signed() if all other terms on the right-hand part of the equation are also of signed type.

    This caused the modulator to not work right.

    I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:

    1) The colorspace modulator is broken (as observed).
    2) The ALTSN..ALTB instructions don't sign-extend S[17:09] before adding it into D.
    3) The smart pin measurement modes that are supposed to count +1/-1 can only count +1/+3.

    These are all simple to remedy at the Verilog level, but will require a respin to fix.
  • Does the +/- 1 smartpin thing possibly break Goertzel accumulation?
  • I'd vote for going forward with the 1500 chips as is (is there a question about this?).

    Glad to hear the problem is identified.
    Fix this and the P59 thing and we're golden...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 14,021
    Rayman wrote: »
    I'd vote for going forward with the 1500 chips as is (is there a question about this?).

    Glad to hear the problem is identified.
    Fix this and the P59 thing and we're golden...

    That's only one problem identified, on the use of $signed.
    There may be many others still to find.... - ie more may need to be fixed yet.

    The errata is growing, but the chips are still looking useful engineering samples.
  • jmgjmg Posts: 14,021
    edited 2018-10-02 - 00:24:31
    cgracey wrote: »
    I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:

    Should you just remove all uses of '$signed()', even if some uses appear to follow some rules ? Just seems a high risk item, best avoided entirely...
    cgracey wrote: »
    3) The smart pin measurement modes that are supposed to count +1/-1 can only count +1/+3.

    Does that mean Quadrature counting is broken ? What other modes are affected ?
    What about live-clear-on-read ? I think that just loads 0 or +1 ?

  • Chip,
    I would like to buy a board with a P2 mounted on it. So that I can write assembler programs that I can upload to the obex.

    HydraHacker
  • Tubular wrote: »
    Does the +/- 1 smartpin thing possibly break Goertzel accumulation?

    Fortunately, the Goertzel stuff seems to all be okay. I am going to test it tonight to be sure, though.
  • Rayman wrote: »
    I'd vote for going forward with the 1500 chips as is (is there a question about this?).

    Glad to hear the problem is identified.
    Fix this and the P59 thing and we're golden...

    I agree.
  • jmg wrote: »
    cgracey wrote: »
    I checked all my Verilog source files for use of '$signed()' where I involved another term which was not signed, which would cause errant results. I found three things:

    Should you just remove all uses of '$signed()', even if some uses appear to follow some rules ? Just seems a high risk item, best avoided entirely...
    cgracey wrote: »
    3) The smart pin measurement modes that are supposed to count +1/-1 can only count +1/+3.

    Does that mean Quadrature counting is broken ? What other modes are affected ?
    What about live-clear-on-read ? I think that just loads 0 or +1 ?

    "$signed()" worked where I used it amid other signed values. I think it is okay.

    Smart pin quadrature counting is broken! The other affected modes are the INC/DEC modes. Modes that just INC and reload 0 on read are unaffected.
Sign In or Register to comment.