Shop Learn
Propeller II update - BLOG - Page 221 — Parallax Forums

Propeller II update - BLOG

1217218219221223

Comments

  • cgraceycgracey Posts: 13,580
    edited 2014-03-25 14:51
    Yes, we need to get SERDES defined and then we'll be able to figure the countdown to real chips. It would be good to get some testing time in, as well.
  • RaymanRayman Posts: 11,970
    edited 2014-03-25 16:46
    Is SERDES going to operate on a single pin only? Or, maybe a differential pair?
    Might be interesting if it could do nibble on 4 pins or byte on 8 pins...
  • jmgjmg Posts: 14,663
    edited 2014-03-25 17:58
    Rayman wrote: »
    Is SERDES going to operate on a single pin only? Or, maybe a differential pair?
    Might be interesting if it could do nibble on 4 pins or byte on 8 pins...

    I'm pretty sure QuadSPI is quite high up the list, IIRC Chip said the main issue was mapping the pins.

    Pushing the QuadSPI as a higher-priority, are new parts like the just announced FTDI FT900, which is from $3.90/10k, and has 480MBd USB, Ethernet(+PHY), 10ns CPU, 256K code, 64K data, USB DFU Bootloader, and says SPI master supports single/dual/quad modes
  • RamonRamon Posts: 476
    edited 2014-03-25 20:00
    jmg wrote: »
    Pushing the QuadSPI as a higher-priority, are new parts like the just announced FTDI FT900, which is from $3.90/10k, and has 480MBd USB, Ethernet(+PHY), 10ns CPU, 256K code, 64K data, USB DFU Bootloader, and says SPI master supports single/dual/quad modes

    I didn't wanted to be the first to mention that new IC, but because it have arised I want to comment two ideas:

    1) It has been only an announcement. The IC is not available yet. I hope the finally make what they announced, but we don't know. I remember that also lattice made on sep 2013 the announcement of a gigabit hard IP machXO3 FPGA with 22K LUTs and a lot of features but 5 months later they forgot every improvement over machXO2 and released a crippled MachXO2 with only 2 times reprogramable memory. (There is a thread in this forum explaining this)

    2) It would be a competitor to P2. It doesn't have a multicore as P2 or XMOS, but they follow the "easy of use" idea. Don't know if this changes any plan or schedule with P2, or if it has even been considered by Parallax.
  • jmgjmg Posts: 14,663
    edited 2014-03-25 20:53
    Ramon wrote: »

    2) It would be a competitor to P2. It doesn't have a multicore as P2 or XMOS, but they follow the "easy of use" idea. Don't know if this changes any plan or schedule with P2, or if it has even been considered by Parallax.

    I'm not sure it is too directly a competitor - but it certainly does set buyers expectations, which is why I mentioned it.

    I should have added, as well as QuadSPI, it also has I²S master/slave interface (24.57/22.57 MHz)

    With Dual HighSpeed USB, the FT900 goes into spaces the P2 cannot, and I could imagine designs using both devices.

    The FT900 looks a pretty impressive universal serial bridge, at a price not much above FT2232H.
    ie anyone who was going to bolt-on a HighSpeed USB chip anyway, can now also look at the FT900.

    Their FT51 is also a P2 companion candidate, as it looks to land in the USB-UART space at $1.46/10k, but much more flexible.
    That's slightly above the price of the overlapping SiLabs C8051F38C
  • RaymanRayman Posts: 11,970
    edited 2014-03-26 09:42
    What's the status of C/C++ for Prop2? Anything working yet?
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-03-26 09:46
    Rayman wrote: »
    What's the status of C/C++ for Prop2? Anything working yet?
    Ray,

    There was a working version shortly after the first emulation release. Then the instruction set started going through so much churn and feature addition that it was hard to keep up. Now, from what David said, since it has settled, work can begin again. I don't think anyone has mentioned time frames, though.
  • RaymanRayman Posts: 11,970
    edited 2014-03-26 15:13
    I think I remember that it could compile for cog mode only... But, now with hubexec, you'd think that cog mode could be pretty big...
    It would be really, really nice to have PropGCC working with hubexec mode...
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-26 16:37
    Actually, I think David had more than COG mode working.

    In any case, HUBEX and the specific instructions needed should make C really sing on this chip, no LMM needed. :)
  • David BetzDavid Betz Posts: 14,366
    edited 2014-03-26 17:21
    Rayman wrote: »
    I think I remember that it could compile for cog mode only... But, now with hubexec, you'd think that cog mode could be pretty big...
    It would be really, really nice to have PropGCC working with hubexec mode...
    PropGCC for P2 worked in COG, LMM, and CMM modes. I never implemented XMM model. I'd like to dive into this again immediately but unfortunately I'm now in a mode with my day job where I have to spend Tuesday-Friday in Philadelphia. I don't really want to lug the DE2-115 board back and forth so I have to work on P2 GCC on the weekends. In any case, my first task is to get binutils ported which mostly means GAS.
  • RamonRamon Posts: 476
    edited 2014-03-26 19:13
    David Betz wrote: »
    In any case, my first task is to get binutils ported which mostly means GAS.

    I have zero experience doing assembler porting and also don't have free time. Anyway, how can we help you? What version (from ftp://sourceware.org/pub/binutils/snapshots) will you port?
  • David BetzDavid Betz Posts: 14,366
    edited 2014-03-26 19:59
    Ramon wrote: »
    I have zero experience doing assembler porting and also don't have free time. Anyway, how can we help you? What version (from ftp://sourceware.org/pub/binutils/snapshots) will you port?
    No, I'll just use the same code we have in the current P1 PropGCC Google Code repository. Most of the parsing of P2 instructions is already there from the first time I did the port. I just have to enter all of the new instruction encodings. The harder part (but also more fun) will be modifying the code generator to use the new hub execution mode.
  • Cluso99Cluso99 Posts: 17,711
    edited 2014-03-26 20:49
    Chip,
    In the latest code, IIRC we have a 4 deep (18bit) LIFO for each of the 4 possible tasks. Is this correct?

    Might it be possible to chain these to give a 16 deep LIFO when multitasking is not used? Perhaps it could be the default mode until a SETTASK is executed?

    I have just found how useful and simple it is to use the CALL/RET instructions without any setup being required. But 4 deep is not very big and currently I am not multitasking.
  • ozpropdevozpropdev Posts: 2,763
    edited 2014-03-26 21:08
    Cluso99 wrote: »
    Chip,
    In the latest code, IIRC we have a 4 deep (18bit) LIFO for each of the 4 possible tasks. Is this correct?

    Might it be possible to chain these to give a 16 deep LIFO when multitasking is not used? Perhaps it could be the default mode until a SETTASK is executed?

    I have just found how useful and simple it is to use the CALL/RET instructions without any setup being required. But 4 deep is not very big and currently I am not multitasking.

    Chip
    I'm currently chasing a intermittent bug in Nano Invaders which I now believe is a LIFO stack overflow.
    Is it possible to include a new instruction to check the LIFO status for this scenario.

    e.g CHKLIFO WC,WZ returns C=1 if stack overflow, Z=1 if stack underflow. (resets both flags after execution)

    A four deep stack has caught me out a couple of times. A configurable LIFO is an interesting idea Ray :)

    Cheers
    Brian
  • Cluso99Cluso99 Posts: 17,711
    edited 2014-03-26 21:23
    ozpropdev wrote: »
    Chip
    I'm currently chasing a intermittent bug in Nano Invaders which I now believe is a LIFO stack overflow.
    Is it possible to include a new instruction to check the LIFO status for this scenario.

    e.g CHKLIFO WC,WZ returns C=1 if stack overflow, Z=1 if stack underflow. (resets both flags after execution)

    A four deep stack has caught me out a couple of times. A configurable LIFO is an interesting idea Ray :)

    Cheers
    Brian
    Brian,
    Because it is just a 4 deep LIFO, and it wraps, probably you just want to know its current depth which could be returned as 2 bits (in C & Z or written to a destination register).

    What I thought is that by chaining the 4 x 4 LIFOs would give a 16 deep LIFO. I would think this just requires the counter to be able to be 2 or 4 bits for task#0, and gates/multiplexors to chain the 4 sets of LIFOs together. I guess a lot depends on how the LIFOs have been constructed.
  • potatoheadpotatohead Posts: 10,179
    edited 2014-03-26 21:24
    Agreed. If it's not tough, having the extra depth in single task mode would be worth it, as would the overflow flag.
  • cgraceycgracey Posts: 13,580
    edited 2014-03-26 22:22
    potatohead wrote: »
    Agreed. If it's not tough, having the extra depth in single task mode would be worth it, as would the overflow flag.


    These LIFO stacks don't have pointers. They are built from flops that load from the lower level on a push or from the higher level on a pop.

    I'll think about how to divide them among tasks. Four levels is adequate for cog execution, but not enough for hub execution. Maybe they should be given 8 levels per task.
  • Cluso99Cluso99 Posts: 17,711
    edited 2014-03-26 22:29
    A lot depends on the space the LIFOs take up. If they could be chained together if tasks don't require them (ie not multitasking) then we get extra usage from them. Is this possible and does it take much silicon?

    Maybe I shouldn't be so lazy, and just use PTRX/Y.
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-03-26 23:04
    Cluso99 wrote: »
    Maybe I shouldn't be so lazy, and just use PTRX/Y.

    This made me laugh out loud!

    <Patton voice>
    All these new features and instructions are making us soft! We're assemmbler programmers, men! Don't sit around feeling sorry for yourself, point to your AUXRAM and feel sorry for the P1 programmer that doesn't have any stack! Now, get out there and write some code before I have to slap you!!
    </Patton voice>
  • Cluso99Cluso99 Posts: 17,711
    edited 2014-03-27 00:10
    ozpropdev:
    Where is your latest Debug code? I thought I would give it a whirl.
  • ozpropdevozpropdev Posts: 2,763
    edited 2014-03-27 00:19
    Cluso99 wrote: »
    ozpropdev:
    Where is your latest Debug code? I thought I would give it a whirl.
    Ray
    Here is the current release
    P2 Test Toolbox

    I'm just testing another update right now. Hopefully I can post it tomorrow.
    Cheers
    Brian
  • RaymanRayman Posts: 11,970
    edited 2014-03-27 03:06
    Does LMM still work for P2? Or, does it need updating due to instruction set changes?
    David Betz wrote: »
    PropGCC for P2 worked in COG, LMM, and CMM modes. I never implemented XMM model. I'd like to dive into this again immediately but unfortunately I'm now in a mode with my day job where I have to spend Tuesday-Friday in Philadelphia. I don't really want to lug the DE2-115 board back and forth so I have to work on P2 GCC on the weekends. In any case, my first task is to get binutils ported which mostly means GAS.
  • evanhevanh Posts: 10,918
    edited 2014-03-27 04:05
    What was LMM will be absorbed into the Hubexec extentions.
  • RossHRossH Posts: 4,696
    edited 2014-03-27 04:19
    evanh wrote: »
    What was LMM will be absorbed into the Hubexec extentions.

    Hub execution will become the norm for the P2. Cog execution will be used only by a few crusty old forumistas who fondly remember the P1 :
    "What? 256kb? Luxury! In our day, we had to support Linux in only 496 instructions!" :lol:

    Ross.
  • David BetzDavid Betz Posts: 14,366
    edited 2014-03-27 04:22
    Rayman wrote: »
    Does LMM still work for P2? Or, does it need updating due to instruction set changes?
    Nothing works anymore. All of the instruction encodings changed multiple times. I'm just hoping they don't change again.
  • ozpropdevozpropdev Posts: 2,763
    edited 2014-03-27 04:40
    RossH wrote: »
    Hub execution will become the norm for the P2. Cog execution will be used only by a few crusty old forumistas who fondly remember the P1 :
    Are you suggesting to remove COG execution mode???
  • RossHRossH Posts: 4,696
    edited 2014-03-27 04:42
    ozpropdev wrote: »
    Are you suggesting to remove COG execution mode???

    No, of course not. Just that fewer people will use it.

    Ross.
  • RaymanRayman Posts: 11,970
    edited 2014-03-27 05:48
    Why would one want to use cog execution mode when hub execution mode is available?
    Only thing obvious to me is that cog mode code can't be corrupted by other cogs...
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-03-27 06:22
    Rayman wrote: »
    Why would one want to use cog execution mode when hub execution mode is available?
    Only thing obvious to me is that cog mode code can't be corrupted by other cogs...

    Because the P1 isn't going away and PropGCC needs to be able to handle both architectures.

    So many people seem to be seeing a P1 or P2 world instead of a P1 AND P2 world. The tools need to be able to handle both chips equally and seamlessly as much as possible. While Spin and Spin2 will have different features, I sure don't want to have a Spin development tool and a Spin2 development tool. PropGCC isn't going to have a flavor for each, P1GCC and P2GCC (at least I hope not). Anything done to include the features needed to support P2 can't be done by excluding the P1 it's not going away.

    The Spin debate is headed the same way - "You can't do that for Spin2 because then Spin won't work!" - well if somebody is foolish enough to let that happen, then they shouldn't be here. Spin is Spin - there just need to be features and enhancements for Spin2 and P2 added capabilities....nobody says you have to use them and if the tools make you use them or exclude the P1, then somebody made a BIG mistake.

    I play with software a lot and that will probably move more and more toward the P2 but when I do hardware stuff, I'll probably use the P1 more unless I really need a P2 feature. I'd rather smoke an $8 dip than a $15-$20 little surface mount bugger on a minimum development board that cost me $50, thank you very much! If the application doesn't need the P2, why use it? Sometimes it's better to dance with the horse that brung ya!
  • Cluso99Cluso99 Posts: 17,711
    edited 2014-03-27 06:22
    Cog mode is still faster and more/easier deterministic. It depends on what is being done. Hubexec requires a bitmore thought and care.
    Remember we have a small cache for hub instructions, and hub data access will stall cache loads.
Sign In or Register to comment.