All is relative -->
How much noise You will accept from motors and how bid moving tolerance You will have,
BUT consider I will build 3D real vision to mo Robot with 2 Cameras controlled by small steper motors and from that moving calculate distance to any object in Picture from that 2 Cameras.
Even very small difference in movement of Cameras give me big difference in calculated distance.
ONE thing I not mentioned only ---> That synchronizing/control/Driving need be possible from one COG only to one else more that group's of DAC signals
Good question. But neither of those examples requires such simultaneous firings since both examples are a broadly modulated analogue that are far from noise free and far from needing precision on a per sample basis. The response of the motor windings is likely at least a couple of orders of magnitude slower than your carrier frequency. The currents are in phase even if the switching isn't.
The one exception would be if you were to independently drive the high-side and low-side stages with separate outputs on the Prop. And there is an argument for doing that.
A better example is for multichannel direct A/D where noise and phase alignment are critical for each and every sample. Where you want to compare the signal between channels.
The answer is no problem really. That's the power of the Prop, it's deterministic even down to instruction to output response time. About the only unknown is clock jitter/skew.
All is relative -->
How much noise You will accept from motors and how bid moving tolerance You will have,
Oops, I meant electrically noisy. The point was the motor currents are not out of phase. You have just as tight control no matter what is happening with the phasing of the carrier.
In fact it's considered good practice to fluctuate the carrier to spread the primary out creating a hiss instead of a whistle.
I haven't used external RAM before, so maybe I am missing something, but people are saying reading SRAM will be faster than accessing COG RAM? Currently, does it really take less than 22 cycles to access 4 bytes of SRAM (22 cycles is worst case scenario for accessing a long in COG)? Seems unlikely.
On Prop II it will only take 8 cycles (right?) to read 16 bytes (quad-long-read). So COG RAM, I would still imagine, is faster than external RAM. Maybe I am thinking about it wrong, external RAM uses some type of serial communication, not magic telepathy or osmosis or something, right?
==============
Where was the post that descibed the number of pins being used now? Is it 120 pins, 128?
Is there any chance that Prop II will be available as a PDIP with reduced I/O pins? It's nice to have the option of a PDIP. I hate to see that go away with Prop II.
Is there any chance that Prop II will be available as a PDIP with reduced I/O pins? It's nice to have the option of a PDIP. I hate to see that go away with Prop II.
They have heard this many times. I think the answer has been, maybe, but unlikely. There will be plenty of breakout boards available for DIP people (not meant as an insult).
@Beau: If 256K memory isn't going to fit, or it is too much work rearrange things to make it work, is there some constraint on multiples of 128K? Why not try to fit 192K in? That as least is a compromise.
Sorry for all the questions today but I have another.
Has anyone thought of replacing the on-chip ROM with flash and eliminate the need for the external EEPROM? The chip could ship with the SPIN interpreter in flash but it could be overwritten with some other code like ZOG if the application required it. Same with all of the tables that might not be needed for some applications.
There is an old very long thread that discusses a lot of what is continually asked. Please read it, but do not continue it please.
DIP is most unlikely. A carrier to DIP will be available by a few of us if Parallax does not do it and I expect they will.
Flash will not happen.
External RAM (SRAM or SDRAM) will never be as fast as hub. Hub has inbuilt contention and as has been stated, each cog will get round-robbin access once every 8 clocks and can be as wide as 128 bits (4 x 32 bits). Even if we used 32 bit wide external memory, 512KB x 32 = 18 address pins, 32 data pins and 2+ control pins = 52+ pins, so we have 40 I/Os left.
At 160MHz the clock will be 6.25ns so lets say we can access external ram at that rate. We still need to increment the address so that halves the access rate so we can expect to read in 2 clocks. Therefore we can read into cog at exactly the same rate as reading from hub (effectively 2 clocks. But, we may need to increment the cog pointer (it may not have an auto increment instruction) so we lose another clock. I believe that we can issue a block instruction that increments automatically (maybe repeat instruction - not quite sure how) for hub transfers, so this will be real 2 cycle access (effective) per long (32bit). Don't forget, hub can be accessed by any cog, whereas external ram requires software contention.
However, I am presuming that bitmap video can be stored and accessed in external ram for those requiring it.
One can conceive of times and ways in which an external RAM would be faster. Your Prop II example relies on 128-bit HUB accesses for the math to work out. It also relies on successive accesses.
For a one-off random access (write the address, read the data) external RAM is pretty fast. You don't have to wait some variable length for HUB.The use of FIFOs in certain instances is also a quick thing - one cycle presents the data, the next cycle clocks the FIFO. Finally, for scanning display memory, an external synchronous counter might be the ticket. But whether the counter was external or internal, that's just a one-cycle affair so long as the video DACs are external.
Guess it depends on your application and also on the particular magic that goes into the I/O pads. Besides, Humanoido will have it all figured out for us, anyway.
That's a great Prop II update. I can't wait to see the final product of course!
Btw, any additions to the multiply and divide engine? That will make Prop II another killer microcontroller in no time with the hardware mult. and div. stuff inside.
It looks good. Beau, keep up the great works on Propeller II!
BTW, I am not surprised as of why you couldn't fit the 256KB SRAM, it suggests to me that you are now sticking with either 180nm or 130nm SOI process, even that, with larger lithography process, we can't be excepted to stuff way too much things without sacrificing some features or go to 90nm and smaller (which both are indeed expensive options).
And, lastly, I am curious - I am guessing that Propeller II will be packaged in TQFP-144 and MAPBGA-144. Correct me if I am wrong.
@Beau: If 256K memory isn't going to fit, or it is too much work rearrange things to make it work, is there some constraint on multiples of 128K? Why not try to fit 192K in? That as least is a compromise.
Why not fit in a trickle cog? Something not big enough to do a lot but something big enough to trickle information in and out? Well, you probably have enough cogs for that.
How about a Print Using kind of command for printing text to the screen or ordering bytes around?
"Any chance these I/O pin blocks will have something as simple as a pull-up resistor?" - Yes, I believe this is one of the options or modes within the DAC section
--> Early November is still on the calendar for the Test-Die tapeout date.
--> The Layout tool has an issue with auto-routing by label names, so I have
to do all of the routing manually. (see before and after attached images about
a day and a half apart) The tool was routing wires right into Power and Ground
causing a short, without lifting to the next metal layer above or below.
--> As a side note, if anyone knows of a good video editing tool (Windows or Linux)
(... and FREE) that can handle *.ogv files it would be much appreciated.
I have been using VideoPad Video Editor only to narrate the videos, and
realized that there is a trial period about to run out.
I'm sure we'd rather all see extra RAM, etc squeezed in to any unused area but if there is an empty spot where you can't add any circuits an image of the propeller hat may be fun....
Regarding *.ogv*, yu may want to try LiVES. I think it should be fine with OGV video extension, I haven't tried it out so much yet, but it should work. (I don't have my Athlon 64 X2 workstation with me right now - but I may give it shot, seeing how well it turns out.)
As far as I am aware, it's getting harder to draw out the symbols, logo and any pictures on Silicon die, due to lithography size. Since the fab Parallax depends on are still using 193nm Extreme-UV (Argon Chloride) Excimer laser, it is pretty hard to set up the laser optics up so that way the pictures' details don't get "warped". Unfortunately, as the companies are going to switch out to pulsed 7 - 3nm X-ray laser (after the usage of 153nm Argon Fluoride laser), it get complicated so quickly (as the future Propeller generations get so small, the more difficult it gets involving the development of sub 40nm transistors.)
If you got enough free Silicon area, Beau, go for the robot wearing Propeller hat!
(Although I doubt you would have enough left for the logo after completing and buttoning up the Propeller II chip. Let's hope what everyone are hoping for: Having enough room for the Propeller hat-wearing robot!)
The attached view is what I call a frame view (there is no official name)... basically the sub-blocks have a frame, with a name and outline. Everything else is the wiring I have been working on over the last two days... should be done later tonight. 96 wires to go out of 512 total.
Then, I will be at the top level Test Die LVSing (the fun part)
LiVES worked for me cleaning up youtube stuff to eliminate audio/video dropouts. I installed my copy from the Ubuntu binary repository.
I've not tried actually creating my own recordings but it certainly looks up to the job.
Couple of caveats: LiVES stores each editing frame as a separate image file so can be very slow at managing a lot of frames. It also lacks a lot of cancel buttons and as such you find yourself, when having made a wrong choice, having to toss up between slaying the process or waiting it out.
Comments
All is relative -->
How much noise You will accept from motors and how bid moving tolerance You will have,
BUT consider I will build 3D real vision to mo Robot with 2 Cameras controlled by small steper motors and from that moving calculate distance to any object in Picture from that 2 Cameras.
Even very small difference in movement of Cameras give me big difference in calculated distance.
ONE thing I not mentioned only ---> That synchronizing/control/Driving need be possible from one COG only to one else more that group's of DAC signals
Oops, I meant electrically noisy. The point was the motor currents are not out of phase. You have just as tight control no matter what is happening with the phasing of the carrier.
In fact it's considered good practice to fluctuate the carrier to spread the primary out creating a hiss instead of a whistle.
It's possible with this one too, just not enough pins to do much else...
Interesting idea. I'm going to search old posts to see what's been done so far in this regard.
On Prop II it will only take 8 cycles (right?) to read 16 bytes (quad-long-read). So COG RAM, I would still imagine, is faster than external RAM. Maybe I am thinking about it wrong, external RAM uses some type of serial communication, not magic telepathy or osmosis or something, right?
==============
Where was the post that descibed the number of pins being used now? Is it 120 pins, 128?
Has anyone thought of replacing the on-chip ROM with flash and eliminate the need for the external EEPROM? The chip could ship with the SPIN interpreter in flash but it could be overwritten with some other code like ZOG if the application required it. Same with all of the tables that might not be needed for some applications.
DIP is most unlikely. A carrier to DIP will be available by a few of us if Parallax does not do it and I expect they will.
Flash will not happen.
External RAM (SRAM or SDRAM) will never be as fast as hub. Hub has inbuilt contention and as has been stated, each cog will get round-robbin access once every 8 clocks and can be as wide as 128 bits (4 x 32 bits). Even if we used 32 bit wide external memory, 512KB x 32 = 18 address pins, 32 data pins and 2+ control pins = 52+ pins, so we have 40 I/Os left.
At 160MHz the clock will be 6.25ns so lets say we can access external ram at that rate. We still need to increment the address so that halves the access rate so we can expect to read in 2 clocks. Therefore we can read into cog at exactly the same rate as reading from hub (effectively 2 clocks. But, we may need to increment the cog pointer (it may not have an auto increment instruction) so we lose another clock. I believe that we can issue a block instruction that increments automatically (maybe repeat instruction - not quite sure how) for hub transfers, so this will be real 2 cycle access (effective) per long (32bit). Don't forget, hub can be accessed by any cog, whereas external ram requires software contention.
However, I am presuming that bitmap video can be stored and accessed in external ram for those requiring it.
For a one-off random access (write the address, read the data) external RAM is pretty fast. You don't have to wait some variable length for HUB.The use of FIFOs in certain instances is also a quick thing - one cycle presents the data, the next cycle clocks the FIFO. Finally, for scanning display memory, an external synchronous counter might be the ticket. But whether the counter was external or internal, that's just a one-cycle affair so long as the video DACs are external.
Guess it depends on your application and also on the particular magic that goes into the I/O pads. Besides, Humanoido will have it all figured out for us, anyway.
Btw, any additions to the multiply and divide engine? That will make Prop II another killer microcontroller in no time with the hardware mult. and div. stuff inside.
BTW, I am not surprised as of why you couldn't fit the 256KB SRAM, it suggests to me that you are now sticking with either 180nm or 130nm SOI process, even that, with larger lithography process, we can't be excepted to stuff way too much things without sacrificing some features or go to 90nm and smaller (which both are indeed expensive options).
And, lastly, I am curious - I am guessing that Propeller II will be packaged in TQFP-144 and MAPBGA-144. Correct me if I am wrong.
Why not fit in a trickle cog? Something not big enough to do a lot but something big enough to trickle information in and out? Well, you probably have enough cogs for that.
How about a Print Using kind of command for printing text to the screen or ordering bytes around?
What needs aren't answered here?
"Any chance these I/O pin blocks will have something as simple as a pull-up resistor?" - Yes, I believe this is one of the options or modes within the DAC section
Here are a few screenshots of the Test Die...
--> Early November is still on the calendar for the Test-Die tapeout date.
--> The Layout tool has an issue with auto-routing by label names, so I have
to do all of the routing manually. (see before and after attached images about
a day and a half apart) The tool was routing wires right into Power and Ground
causing a short, without lifting to the next metal layer above or below.
--> As a side note, if anyone knows of a good video editing tool (Windows or Linux)
(... and FREE) that can handle *.ogv files it would be much appreciated.
I have been using VideoPad Video Editor only to narrate the videos, and
realized that there is a trial period about to run out.
I've enjoyed reading about all the developments on the Propeller II and I'm looking forward to the chip when it comes out (as many others are too).
It took me a while to find this link but I was curious if you are going to add any special logo's on the silicon like these:
http://micro.magnet.fsu.edu/creatures/logoindex.html
Perhaps an image of a Propeller hat??
I'm sure we'd rather all see extra RAM, etc squeezed in to any unused area but if there is an empty spot where you can't add any circuits an image of the propeller hat may be fun....
Some images from other chips that stand out:
http://micro.magnet.fsu.edu/creatures/pages/train.html
http://micro.magnet.fsu.edu/creatures/pages/wdtrain.html
http://micro.magnet.fsu.edu/creatures/pages/adgodzilla.html
http://micro.magnet.fsu.edu/creatures/pages/bat.html
http://micro.magnet.fsu.edu/creatures/pages/toshibatriangle.html
http://micro.magnet.fsu.edu/creatures/pages/germanelephant.html
http://micro.magnet.fsu.edu/creatures/pages/tihappyface.html
Browse some of the other images on the site too....
Robert
No silicon images slated for Prop II yet, but it's easy enough to do with a simple script.
The DsPHYTER I worked on does have an image of a Georgia peach since much of the layout and design was done there
LiVES link:
http://lives.sourceforge.net/
Ok, If there is room I vote for robots wearing Propeller hats. Haven't seen that one done before!
Robert
As far as I am aware, it's getting harder to draw out the symbols, logo and any pictures on Silicon die, due to lithography size. Since the fab Parallax depends on are still using 193nm Extreme-UV (Argon Chloride) Excimer laser, it is pretty hard to set up the laser optics up so that way the pictures' details don't get "warped". Unfortunately, as the companies are going to switch out to pulsed 7 - 3nm X-ray laser (after the usage of 153nm Argon Fluoride laser), it get complicated so quickly (as the future Propeller generations get so small, the more difficult it gets involving the development of sub 40nm transistors.)
If you got enough free Silicon area, Beau, go for the robot wearing Propeller hat!
(Although I doubt you would have enough left for the logo after completing and buttoning up the Propeller II chip. Let's hope what everyone are hoping for: Having enough room for the Propeller hat-wearing robot!)
Then, I will be at the top level Test Die LVSing (the fun part)
I've not tried actually creating my own recordings but it certainly looks up to the job.
Couple of caveats: LiVES stores each editing frame as a separate image file so can be very slow at managing a lot of frames. It also lacks a lot of cancel buttons and as such you find yourself, when having made a wrong choice, having to toss up between slaying the process or waiting it out.