Smart Pins Docs and features

15678911»

Comments

  • Let's just hope it works when it comes back from the foundry.
  • cgracey wrote: »
    Let's just hope it works when it comes back from the foundry.
    If for some reason it doesn't does that imply another $250k for a second try or is it cheaper to fix bugs than do the initial synthesis?

  • cgracey wrote: »
    If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.

    Seems like an 80MHz compile could be useful. Looks like Garryj has the Prop123-A9 board based on this exchange from Page 10 of the USB thread:

    garryj wrote: »
    cgracey wrote: »
    Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.

    The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.

    Yep, a Prop123-A9, and the status bit changes look good.

    Thanks, Chip, and remember to take it easy!
    Affirmative on the Prop123-A9.
    garryj
  • Dave Hein wrote: »
    cluso99, your comments are not conducive to getting the P2 as soon as possible. Could you please refrain from proposals that are counter to the P2? Parallax has made a commitment to producing the P2. We should all work together to support the P2 development.
    Just because you disagree with my comments doesn't in any way mean they are wrong, or against Parallax's interest. In fact, my comments are entirely, in my perceived way, made for the benefit of Parallax, and probably against my own desires too.

    But reality must be examined. Parallax revenue is at stake here. The current P2 cannot possibly generate revenue for Parallax as quickly as a P1 variant, due to the additional requirements of P2, including silicon, software and documentation issues.

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    It is all about mitigating risk, together with a saleable product, for the least amount of expenditure.

    Very easy to claim anything, but that's not what your path actually delivers.
    The devil is in the details.
    Cluso99 wrote: »
    However, this does not change my view that a Bigger P1 is now, more than ever, the immediate requirement! Now I see you can use the P2 ring soup with the P1 extras.
    ....
    At least a "Big P1" would bring us backward compatibility, such that all the P1 software, objects, demos and tools could be used from day one of silicon. P2 has now moved too far away from P1 compatibility that it must be considered a new beast, not an upgraded P1.

    - but your P1x totally fails to deliver "bring us backward compatibility" !!

    It lacks the same Crystal/RC Oscs & config, lacks the same PLL design, and lacks any Video PLL - all that claim of "software used from day one" is a mirage.

    It also is now in a much larger package, with two Vcc's, so it seems the earlier 32io did not last very long at all !

    All of this means 'your P1x' also "must be considered a new beast, not an upgraded P1"

    The Verilog is testable, and needs to be tested, in FPGA, exactly the same for P1x and P2, and then synthesized.

    Reality: P2 is more tested than P1x, so actually represents the lower risk, not to mention a far larger TAM.

  • Chip,
    Glad to see you are still moving forward with things. I for one am looking forward to the P2 as my go to chip for my various robotic projects, as well as experimenting with it in the areas of sound generation.

    I really think that it's going to be a fun beast to work with and program, and I am sure that I am not alone in this.

    Let's not not diverge into alternate paths or what could have been's, and just get what we have finalized into a chip we can all start using soon.
  • Cluso99Cluso99 Posts: 12,847
    edited September 27 Vote Up0Vote Down
    Chip,
    Could the P1 instruction set be easily inserted into the P2?
    While there probably would be some extras required, this surely may mitigate bugs, and would permit the use of existing software with minimal changes, if any.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Could the P1 instruction set be easily inserted into the P2?
    What does that even mean ? They are different CPUs.
    Did you meant to ask can a synthesised P1 be 'dropped inside' the P2 ring ?
    Why not ask if a RISV-V can be 'dropped inside' a P2 ring ?

    What happens to all the analog features, currently designed into the P2 ring, but NOT in any P1 design ?

    Cluso99 wrote: »
    While there probably would be some extras required, this surely may mitigate bugs, and would permit the use of existing software with minimal changes, if any.

    Why the claim "surely may mitigate bugs" ? - ALL Verilog code needs to be fully tested. Reality: There is no proven P1 Verilog Silicon.
    P1x and P2 really have exactly the same Verilog-> FPGA testing issues, but P2 has a significant head start...


    Unless you clone ALL the P1 Analog sections precisely, which is NOT done in the P2 Ring, you cannot simply reuse existing binaries.

    Even classic P1 ADC circuits, rely on buffer thresholds, and are unlikely to operate the same in 180nm.
    I guess that can be checked on the new P2 PAD Ring test silicon

    Once you add 'minimal changes', you now need two code bases...
  • Chip, do you have someone (several someones, preferably) you trust to review your verilog? You really should have a peer review of your code.
  • garryj wrote: »
    cgracey wrote: »
    If Garryj can tell me which board he has, I can do a special compile for him at 80MHz to replicate how things used to be.

    Seems like an 80MHz compile could be useful. Looks like Garryj has the Prop123-A9 board based on this exchange from Page 10 of the USB thread:

    garryj wrote: »
    cgracey wrote: »
    Garryj, I think I asked before, but do you have a Prop123-A9 board? I can do an updated A9 compile today and post it. It uses bit 3 of the readback status in the USB mode to tell whether SE0/K/J have been valid for 7+ USB bit periods, while bits 2/1/0 express immediate SE0/K/J states, without any delays.

    The new compile would also cover the bug where CALLPA/CALLPB and the event jumps couldn't branch backwards using 9-bit relative addresses.

    Yep, a Prop123-A9, and the status bit changes look good.

    Thanks, Chip, and remember to take it easy!
    Affirmative on the Prop123-A9.

    Garryj,

    Here is an 80MHz setup for the Prop123-A9 board. It has 8 cogs and all 64 smart pins:

    https://drive.google.com/file/d/0B9NbgkdrupkHYy1yYW15WXktS28/view?usp=sharing
  • These days you simulate the RTL of the chip, and simulate a gate level extraction with loading before tapeout. I assume tree house will do this, though Parallax would be responsible for the stimulus, and free house would give a coverage figure. Most main line chip vendors include scan chains for production test.
  • Seairth wrote: »
    Chip, do you have someone (several someones, preferably) you trust to review your verilog? You really should have a peer review of your code.

    When we go to synthesis, it gets linted really well. That's it.

    I don't think there are any obvious bugs someone would find looking at the Verilog. It's more modal stuff in peripherals where hard-to-discover things lurk, and they only come out when running the FPGA. That's what I'm mainly worried about.
  • brucee wrote: »
    These days you simulate the RTL of the chip, and simulate a gate level extraction with loading before tapeout. I assume tree house will do this, though Parallax would be responsible for the stimulus, and free house would give a coverage figure. Most main line chip vendors include scan chains for production test.

    This chip has a TESn pin to put it into scan mode. I wanted all the logic verifiable, this time around. The analog pads will still need to be tested, outside of the scan chain.
  • Sound is on my list too. Cool beans Roy
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • potatohead,
    It's like 16 DSPs with 64 DACs or ADCs or some combo of each adding up to 64. All kinds of nifty and weird things can be done with audio in this thing.
    I need to work up a board that will take a pile of pins being used as DACs and mix them into a stereo output.
  • In my understanding a P1+ is already doable with various FPGA variations. And the price is coming down quite fast. Even if Parallax could sell a P1+ for say $10 it will be less then 2 years and a P1+ FPGA is cheaper then a P1+ Chip from Parallax.

    The whole "We need a P1+" train left the station around 5 years ago, together with a lot of people, I certainly miss @pullmoll, for example, or @mpark, or...

    Now it is definitive to late for a P1+. Sorry @clusso99, but this is not just a financial risk like the P2 but a preprogrammed financial disaster. Even $250-$350 as a ballpark, and then a production run. How can they ever get that money back, since FPGA prices are falling and the IP/Verilog is out in the public?

    The P2 is - as usual - almost there, but this time I have the strong feeling that @Ken AND @Chip agree on the same timeline.

    Overall Parallax has spend some maybe 2-3 million over the last 10 years, investing into the next generation of the propeller. Now they have to, and will, bite the apple and get it in production.

    Everything else would be simply stupid, if not insane.

    And for sure has @Chip a hard time to let it got, and needs reassurance from us that it is OK now and he can say DONE!

    It is completely wrong now to say, look - you have a new product, but better not produce it because you need to write DOCUMENTATION, and everybody hates that.

    PropGCC is not ready yet, but there is already a working C compiler. It even can compile old SPIN for the P2. As far as I was able to follow the PropGCC posts, getting it basically running is not that far away.

    SPIN2 will be ready before we really get silicon, and I am quite sure the changes for the PropTool to adjust to P2 Syntax are not so hard.

    And then there is SPIN-WRAP a somehow unnoticed gem, allowing to use P1-SPIN unchanged in C by running a SPIN-Interpreter. That could work for the P2 too, and I even think some one could write a PASM1-emulator for the P2. Even if I need to state clearly to @heater, that this is impossible and remind him that he does not want to write any emulator ever again.

    Someone will.

    And @Ken made a really good decision with the whole Blockly endeavor. It took me a while to understand that move. Just brilliant, business-wise. And now it will pay out double, because as soon as PropGCC works for the P2 its just the simple library.

    And all 10 things you listed as to be needed to be done for a P2, would also be needed for a P1+, or do I miss something here?

    Enjoy!

    Mike
    I am just another Code Monkey.

    A determined coder can write COBOL programs in any language. -- Author unknown.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • TorTor Posts: 1,789
    edited September 28 Vote Up0Vote Down
    Must agree with Mike here. It's way too late for any P1+ ideas now. Focus on P2. It looks like we're finally getting there. If it works, or mainly works, it will be good. No distractions, please.
  • cgraceycgracey Posts: 8,030
    edited September 28 Vote Up0Vote Down
    Garryj,

    Any word on how that 80MHz FPGA image worked with your USB code?
  • garryjgarryj Posts: 140
    edited September 29 Vote Up0Vote Down
    I just tried. The FPGA image loads fine, and PNut_v21_80MHz compiles and loads the code fine, but the cogs don't get started.

    Is default startup sysclock set to 80MHz? I tried with no CLKSET and a CLKSET #$ff.

    Edit: Loaded the all_cogs_blink program and no joy there, either.
    Edit2: It does run the all_cogs_blink program, but you need to repeat F11'ing, and after a random number of attempts, the program runs. No success so far with my much larger program. The 120MHz v21 works, but my USB demo still doesn't.

    I can wait for the upcoming 80MHz drop.
    garryj
  • garryj wrote: »
    I just tried. The FPGA image loads fine, and PNut_v21_80MHz compiles and loads the code fine, but the cogs don't get started.

    Is default startup sysclock set to 80MHz? I tried with no CLKSET and a CLKSET #$ff.

    Edit: Loaded the all_cogs_blink program and no joy there, either.
    Edit2: It does run the all_cogs_blink program, but you need to repeat F11'ing, and after a random number of attempts, the program runs. No success so far with my much larger program. The 120MHz v21 works, but my USB demo still doesn't.

    I can wait for the upcoming 80MHz drop.

    Garry, sorry about this. I think the problem is that I didn't adjust the NCO constant for the 20MHz "RC" mode.

    New stuff is compiling now.

    Thanks.
Sign In or Register to comment.