Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 19 — Parallax Forums

Propeller II update - BLOG

11617192122223

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2011-06-03 07:14
    Hi All.

    As I work for now on one PCB that use same Footprint Package as Propeller II.
    I can show You that it is mostly impossible to made at home.

    Look on pic attached.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-03 08:46
    Why not just have a set of instructions that allows the use of the alternate address space, that of the functional registers, thus allowing up to 512 functional registers, this would mean having fewer instructions for cog mem, though one could also add a series of ops that use the bits normally reserved for effects, thus not allowing effects for the particular op group(s). If thus done what would we lose? I see nothing lost, and if there are less than 512 functional registers we could gain effective Cog mem.
    This is sort of the approach that Parallax has taken, where the SETxxx, GETxxx, ADDxxx and SUBxxx instructions only apply to the registers and not the cog RAM. Of course, these new instructions are dedicated to certain registers, and they don't address the registers in a linear address space. By doing this, they were able to fit the new instructions into the unused intruction space of the Prop 1, and they didn't have to remove any Prop 1 instructions from the Prop 2.

    However, I still think a linear register address space that shadows some of the cog RAM is a much cleaner approach. To be honest, the current approach of adding lots of new instructions to SET and GET registers is making the Prop 2 look very CISC-like. It is a workable solution, but the Prop 2 manual will probably have to grow to at least 600 pages to accomodate all the new instructions.
  • RossHRossH Posts: 5,463
    edited 2011-06-05 19:14
    Roy Eltham wrote: »
    Just wanted to post a quick note to let you know why I haven't posted more prop 2 instruction details. I've been sick for the last few days, and not doing much of anything. Yay, for the long weekend to be sick on. :P
    I will post more info in soon.

    Hi Roy,

    Hope you're feeling better! We're all depending on you to document the new Propeller II instructions.

    But ... you know ... no pressure or anything ... :lol:

    Ross.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-06-05 19:19
    I have another post in the works, but I have run it by Chip first (via email). I should be able to post it soon.
  • potatoheadpotatohead Posts: 10,261
    edited 2011-06-06 07:33
    Was just wondering something. We've got the REP instruction coming, which looks something like REP [number of instructions][iterations]

    Does it get cancelled by JMP and friends, or not?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-06 07:53
    I have a feeling it will be the programmer's responsibility to avoid pathological cases like that -- or Kuroneko's responsibility to find useful ways to abuse them! :)

    -Phil
  • potatoheadpotatohead Posts: 10,261
    edited 2011-06-06 07:57
    That is exactly where I was thinking this morning. On one hand, it's clean, if cancelled by JMP. On the other, some very interesting constructs can be made, if it's not.
  • jmgjmg Posts: 15,173
    edited 2011-06-06 17:00
    potatohead wrote: »
    Was just wondering something. We've got the REP instruction coming, which looks something like REP [number of instructions][iterations]

    Does it get cancelled by JMP and friends, or not?
    This sounds like the Zero (?) overhead Loop, seen in DSPs, usually applied to the tightest inner loops, which would otherwise be unrolled.
    Such loops may contain short jumps inside the block, or even larger jumps or calls outside.

    It would be complex to cancel such a REP, which is really a hidden DJNZ (anyone know if REP has real Zero loop cost ?)

    In HW, this would be a (PC=LoopEnd) & (RepCtr<>Z) to force a PC reload, rather than usual INC

    So in that context, it does not 'know/care' about Jump/Calls, it merely checks every pass of LoopEnd.
    (or, if pipelined, likely for highest speed? @ LoopEnd-1, so jumps to LoopEnd may need care ? )

    Could make for a nice BreakPoint debug, but would need to be on code that does not already use REP, tho perhaps a REP_Save, REP_Restore macro would allow a minor impact workaround.

    If REP allows user control of LoopTo, LoopEnd, the common usage would be LoopTo before LoopEnd, but if you made LoopTo LoopEnd+1, around a call to Break routine, then a HW Breakpoint with Counter could be built. : ReLoads the PC to skip until Count is hit, then falls into the CALL

    Is there a separate HW Breakpoint support ?
  • BigFootBigFoot Posts: 259
    edited 2011-06-07 10:31
    Beau,

    Will the Propeller II need an address / data latch (74LVT573) for the Sdram, or will it do this internally ?
  • BigFootBigFoot Posts: 259
    edited 2011-06-07 19:38
    Here is another way you could lay out a breadboard. There are 4x .1uF caps on the
    I/O (3.3V) supplies, two on the 1.8V supplies and a 47uF low esr tantalum on each.
    The layout is an AutoCad 3d model.
  • SapiehaSapieha Posts: 2,964
    edited 2011-06-08 06:49
    Hi BigFoot.

    Can You post it as DXF?


    BigFoot wrote: »
    Here is another way you could lay out a breadboard. There are 4x .1uF caps on the
    I/O (3.3V) supplies, two on the 1.8V supplies and a 47uF low esr tantalum on each.
    The layout is an AutoCad 3d model.
  • BigFootBigFoot Posts: 259
    edited 2011-06-08 08:05
    Sapieha,

    Sure thing, here is the DXF in AutoCad 2004 format. I corrected one mistake and turned on the silk screen layer. I am also working on a power supply and SDram interface.
  • SapiehaSapieha Posts: 2,964
    edited 2011-06-08 08:23
    Hi BigFoot.

    Thanks - It is official PINOUT from Parallax - Else have You extracted it from Beau's last post about building Prop II?

    BigFoot wrote: »
    Here is another way you could lay out a breadboard. There are 4x .1uF caps on the
    I/O (3.3V) supplies, two on the 1.8V supplies and a 47uF low esr tantalum on each.
    The layout is an AutoCad 3d model.
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-08 08:42
    Roy Eltham wrote: »
    I have another post in the works, but I have run it by Chip first (via email). I should be able to post it soon.
    Roy,

    Any word from Chip on whether you can post more information? It's been a looong time since Beau posted the Prop 2 instruction set. There are been a few bits and pieces since then, but it would be nice to get something more substantial.

    Dave
  • BigFootBigFoot Posts: 259
    edited 2011-06-08 09:08
    Sapieha,

    I got the pin-outs from Beau last year and am not sure if they are current or correct.
  • SapiehaSapieha Posts: 2,964
    edited 2011-06-08 09:12
    Thanks

    BigFoot wrote: »
    Sapieha,

    I got the pin-outs from Beau last year and am not sure if they are current or correct.
  • Beau SchwabeBeau Schwabe Posts: 6,566
    edited 2011-06-08 13:40
    All,

    Here's another layout video showing how to go from 450 some odd labels and pins to 3650 labels and pins within 20 min. The hard part was the initial 450 labels and pins. Years ago I wrote a Visual Basic GDS2 parser that allowed for human readability of the GDS file, however it was lacking the ability to go the other direction. Since I only needed to go the other direction for the label renaming, that’s exactly what I focused on. All of the other GDS2 codes just fall through unchanged, but if GDS code [1906] is detected, then only that section is altered to reflect the enumerated COG … So a new GDS2 file is generated with the changes reflecting the next COG in line. I run the script 7 more times to generate the remaining COG labels. From there I can just read in the GDS2 file into the Layout tool and place it in the correct position as you can see in the video.

    http://www.youtube.com/watch?v=1lpYTUE3OX0 - Q: How do you assign labels and pins to 3650 wires in layout?

    ...Since the EXPO I have placed labels on 3650 pins. Each pin has a label plus the associated metal layer for that pin. I have also included a boundary layer that only should represent the East West extensions which happens to be 5400.4 microns. The pins are center aligned within this East/West extension. There should be a total of 3,650 labels, and 3,650 pins plus 1 boundary layer. From the layout perspective with the COG’s at the bottom, ALL pins should escape in the North direction only to connect to the synthesized logic.

    ...The next step is to LVS the 8 COGs with all of those labels ( an overnight LVS process )

    ... Following that Chip will finalize the ROM/RAM combination block that was discussed at the EXPO where the same pin renaming script can be applied.

    Note: The purpose for providing all of those labels and pins is to provide the synthesis guys something to work with in terms of real connection locations as well as a way to anchor the LVS tool during it's evaluation.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-06-08 14:19
    Thanks for the info Beau. The nice thing about the prop is that much of it is replicated 8 times, and the pins 92/96 times, so it does make the chip simpler to layout.

    Can you explain (when time permits) a little more about what is contained in the cog versus what is contained in the synthesis section for each cog please?
  • Beau SchwabeBeau Schwabe Posts: 6,566
    edited 2011-06-08 21:33
    Cluso99,

    "what is contained in the cog versus what is contained in the synthesis" - basically the COGs contain the COG_RAM (main COG memory), the DUALPORT_RAM (used for the Color Lookup Table), Two PLL's for the Counters, Four Sine ROM's (two per counter), and one CORDIC_ROM ... So really aside from the PLL's it's mostly specialized memory that lives in the reserved COG sections. The synthesis portion is where the CPU(s) live as well as all of the other logic for each COG that make it function like a processor based on what lives in the memories.
  • RossHRossH Posts: 5,463
    edited 2011-06-08 22:24
    Dave Hein wrote: »
    Roy,

    Any word from Chip on whether you can post more information? It's been a looong time since Beau posted the Prop 2 instruction set. There are been a few bits and pieces since then, but it would be nice to get something more substantial.

    Dave

    Yes, I agree. Some accurate and reliable information is long overdue.

    Ross.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-06-08 22:45
    Thanks Beau. I was not sure as I had surmised conflicting info. With all that rom code and dual port clut plus the 4port (3xread + 1xwrite cog memory) that is quite a lot of real estate. Should make for some pretty powerful code.

    I see 4 sine tables, 2 for each counter. Just wondering what use a pair is for each counter - obviously for something?
  • DaveJensonDaveJenson Posts: 375
    edited 2011-06-10 13:52
    Here is my first draft for a PropII breadboard layout. Done using ExpressPCB. Still needs all the bypass caps, voltage regulation, crystal, and programing interface. (Still need final pinouts from Beau or Chip.) And I feel 100% comfortable making this at "home".
  • HShankoHShanko Posts: 402
    edited 2011-06-10 13:59
    Dave,

    I suppose you do plan to reposition some traces better; there are some that nearly are touching. Does ExpressPCB provide any 'checking' for traces too close to pads?
  • DaveJensonDaveJenson Posts: 375
    edited 2011-06-10 14:28
    HShanko wrote: »
    Dave,

    I suppose you do plan to reposition some traces better; there are some that nearly are touching. Does ExpressPCB provide any 'checking' for traces too close to pads?

    ExpressPCB is really simple minded in that respect. It doesn't have any of that sort of checking. (But is is FREE...) And again, this is a first try. Don't want to invest too much into it until the final pin-out is published.
  • thefatmoopthefatmoop Posts: 1
    edited 2011-06-10 23:05
    Not to ask a question that should be obvious, but is the prop2 going to have: internal ADC (for those of us who live in the real word), C++ syntax, and a datasheet? Will it be able to handle floats or doubles without using the extremely awkward string methods?

    I can't believe I have to ask if a micro will have a datasheet lol... I guess that shows my expectations.
  • jazzedjazzed Posts: 11,803
    edited 2011-06-10 23:45
    thefatmoop wrote: »
    Not to ask a question that should be obvious, but is the prop2 going to have: internal ADC (for those of us who live in the real word), C++ syntax, and a datasheet? Will it be able to handle floats or doubles without using the extremely awkward string methods?

    I can't believe I have to ask if a micro will have a datasheet lol... I guess that shows my expectations.

    There will be a datasheet :)

    GCC C/C++ is being seriously considered.

    Internal ADC and other features will be available on each I/O pin.
  • RossHRossH Posts: 5,463
    edited 2011-06-11 01:37
    jazzed wrote: »

    GCC C/C++ is being seriously considered.

    Well, I wouldn't hold my breath on that one - the GCC thread in the Parallax Semiconductor forums seems to have died from lack of interest!

    Ross.
  • Heater.Heater. Posts: 21,230
    edited 2011-06-11 01:49
    We do C++ on the current Prop with zpu-gcc and the Zog ZPU virtual machine. It's as slow as a Java VM without JIT but it works. It will be much nicer on the Prop II.
  • RossHRossH Posts: 5,463
    edited 2011-06-11 01:58
    Heater. wrote: »
    We do C++ on the current Prop with zpu-gcc and the Zog ZPU virtual machine. It's as slow as a Java VM without JIT but it works. It will be much nicer on the Prop II.

    True! I had forgotten that. So I suppose that it is fair to say there will be GCC/C++ on the Prop II one way or another!

    Ross.
  • Heater.Heater. Posts: 21,230
    edited 2011-06-11 02:09
    Oh yes. Can't wait.
Sign In or Register to comment.