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.
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.
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!
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.
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
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.
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.
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.
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.
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.
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.
...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.
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?
"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.
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.
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?
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".
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?
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.
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.
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.
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.
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!
Comments
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.
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.
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 ...
Ross.
Does it get cancelled by JMP and friends, or not?
-Phil
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 ?
Will the Propeller II need an address / data latch (74LVT573) for the Sdram, or will it do this internally ?
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.
Can You post it as DXF?
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.
Thanks - It is official PINOUT from Parallax - Else have You extracted it from Beau's last post about building Prop II?
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
I got the pin-outs from Beau last year and am not sure if they are current or correct.
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.
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?
"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.
Yes, I agree. Some accurate and reliable information is long overdue.
Ross.
I see 4 sine tables, 2 for each counter. Just wondering what use a pair is for each counter - obviously for something?
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.
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.
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.
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.