Processing Speed versus Data through put
TJHJ
Posts: 243
Does anyone know how to figure out how much data processing you need per MIP( maybe). Specifically how fast data would need to be fed from an e-prom to the prop in order for it to directly process from the eprom, versus loading to the ram 1st. Maybe a data transfer rate per cog?
Here is what I am thinking, With a boat loader, It would be possible to process directly from the e-prom, bypassing the 32k limit. The ram could be used as just that, ram, for variables, ect. Similar to how a PIC tends to work. I can never do very much with video because the video buffer takes up 24k right off the bat. So if I was reading the commands from the e-prom then I could have a full 32k of program or more, and not be limited by the video buffer. Even go to higher resolutions. The interesting idea is that because cog's have direct access to IO lines, they could be running their own programs from their own e-prom, and using their 2k ( Minus the loader) for independent ram, and still have access to the common ram.
This is all dependent on being able to read the eprom fast enough, which off the top of my head I have no idea if that is possible as things are laid out now.
TJ
Here is what I am thinking, With a boat loader, It would be possible to process directly from the e-prom, bypassing the 32k limit. The ram could be used as just that, ram, for variables, ect. Similar to how a PIC tends to work. I can never do very much with video because the video buffer takes up 24k right off the bat. So if I was reading the commands from the e-prom then I could have a full 32k of program or more, and not be limited by the video buffer. Even go to higher resolutions. The interesting idea is that because cog's have direct access to IO lines, they could be running their own programs from their own e-prom, and using their 2k ( Minus the loader) for independent ram, and still have access to the common ram.
This is all dependent on being able to read the eprom fast enough, which off the top of my head I have no idea if that is possible as things are laid out now.
TJ
Comments
I2C EEPROMs like those used for the boot loader work up to about 1MHz clock. They are serial, so they require an address at the beginning of a transfer, typically a total of 4 bytes including device select codes which comes out to about 36 bits. Each byte read after that takes about 9 bits. That's 100000 bytes per second maximum. Writing of course takes much longer since it's flash EEPROM.
There are serial memories that use the SPI protocol and require 3 I/O pins, two of which can be shared with other SPI devices. These can use a clock up to 20MHz, require a 3 byte opcode/address initiation to a read, then require only 8 bits per byte to do the read transfer. Writes take a 4th byte and, for flash, take longer to complete.
You'll have to decide whether this is fast enough for your needs. The SPI memories are about 20 times slower than hub RAM and the I2C memories are 25 times slower than the SPI memories.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
Since most programs execute several instructions before a jump the next address and byte of data can be accessed very quickly most of the time. If the Flash/Eeprom contained bytecode instructions for the prop to interpret and execute the time required to do so would probably be as long or longer than the time required for the data to be shifted in.
I think the Prop would be an excellent choice for this application. With multiple cogs you could use one cog for fetching the bytecodes and one or more cogs for executing them.