If you can give me 12.5ns of setup time, I can make 16 props read any 16 data lines in less than 5ns.
This wouldn't work for RAM, unless you had 32 props.
Its a super hardware hack job... But im not too sure of the software limitations.
It can be done by clocking each prop a bit longer than the first.
the first prop runs at 80mhz = 12.5ns
the second 79mhz = 12.658ns
the third 78mhz = 12.8205ns
and so on... till you have enough props to sample each line.
This could be done in the pll 16x mode too.
the first prop clocks at 5mhz = 12.5ns
the second 4.9375mhz = 12.658ns
the third 4.875mhz = 12.8205ns
and so on...
You can see where I am going with this?
Not so good for use with much of anything but a scope perhaps? I dunno.
It would be nice to be able to have all COG's run on different clock cycles.
I am sure there are issues with this.. but.... my spin sense says don't overlook this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License
"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "
The dsp/fpga king is dead, long live the prop.
Post Edited (Clock Loop) : 12/1/2009 9:24:39 PM GMT
Once I found that 10nS access was not possible, and that I do not want, nor can I afford, the overhead in synchronising multiple cogs for access, I decided that a 'nop' had to be introduced between the address output and the read input.
This meant that there was a delay of 50nS between the instructions, which I can use to advantage most times anyway. So now my SRAM can be 55nS - no need for 10nS. That was before overclocking. Now, overclocking 25% (for 100MHz operation) gives 25% overall speed on all instructions, but because I am using 55nS parts (pinouts different for 10nS parts) I can either overclock the SRAM (which is working) or add another 'nop' (or rearrange instructions to use it) when accessing SRAM. This is more than offset by the improvement in all instruction speeds.
I have spent considerable time in trying to get the RamBlade layout correct to try even higher overclocking to 120MHz (50% improvement) and beyond. Only time will tell. And of course there is no guarantee when running chip(s) out of spec.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Parsec said...
All I can say is you all are seriously hardcore. It's not every day you can hear a debate surrounding RAM timing. I knew I should have gone for a stinkin' EE degree instead of taking the shortcut 4-year IS degree...!
This thread is how one really builds a computer. None of that pansy buying of preconfigured stock PC parts.
Nick: I was always taught that nS, uS, mS, S was the correct way (1970) and it is habit. I do however note the wiki says differently.
BTW: Disk was spelt Disc in the 1970's before Apple called it Disk. The plural of mouse (computer kind) was declared to be mouses, but how many refer to the plural as mice, just like the animal kind.
There are far more serious grammatical and spelling errors. You just have to learn to live with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Nick's right -even about the· 1960 date --- we were still using it 'wrong' in 1970 because none of us important people noticed that a bunch of EggHead-Government folks changed everything.
I don't trust the wiki as much as the *cough* US government... so here it is from the horse's patoot:
It's just like cps (which meant something - and yes that was small "s", so no doubt I was taught incorrect, but it stuck) changed to Hz. What a lot of Smile!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
It's just like cps (which meant something - and yes that was small "s", so no doubt I was taught incorrect, but it stuck) changed to Hz. What a lot of Smile!
I'm positive Heinrich Hertz would be just ecstatic to hear you say that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
And while we are at it, lets change the "microprocessor" to be called the "faggin-hoff" to honour the original Intel designers.
And we will honour Chip "Gracey" for the "Parallax 8-cog" microprocessor.
Now we have this amazing gracey faggin-hoff that......
No disrespect, but to rename something later is Smile.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
And while we are at it, lets change the "microprocessor" to be called the "faggin-hoff" to honour the original Intel designers.
And we will honour Chip "Gracey" for the "Parallax 8-cog" microprocessor.
Now we have this amazing gracey faggin-hoff that......
No disrespect, but to rename something later is Smile.
I'm positive someone had a loose description of force prior to the Newton, and a measure of electrical storage prior to the Farad. They are official units. Cycles per second is not a unit, it's a description. It finally grew up and was awarded a unit name. It wasn't renamed after the fact.
I always thought it was invented by someone sticking their finger in a socket and going "gosh, that hurts 50 times a second" (yes, I know it's 100 or 120 in some countries).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BradC: No, cycles per second or cps was officially a unit until it was renamed Hertz (Hz). see http://en.wikipedia.org/wiki/Hertz which confirms that it was changed. I was taught Hz in 1970 and that it had just officially replaced cps.
BTW Where is it 100 or 120Hz? In countries with 110Vac (about) it is 60Hz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I learned it as CPS too .... I laughed when my father said I had to start saying Hertz.
Just curious: wasn't Toilette also someone's name? Sounds a little French to me [noparse]:)[/noparse]
@Cluso99: 60 Hz means it has one maximum plus one minimum ... that means it hurts twice per periode
And renaming is not Smile ... it's a commitment to one naming. In fact that is very helpful if two people from different countries talk together (or read each others publications). Because having names being standardized means that there is less problem with missunderstanding. S and s might be obvious when using it in a special context ... what about m and M? mW and MW is a little difference.
The world changes ... of course you have to leave comfort-zone if you want to stay up to date.
Whether or not you can access a byte every 10ns, the following describes how 10ns SRAM has value.
On my board running at 80MHz with 1MB of 10ns SRAM with data/address on P0..7/P8..27:
I've implemented the algorithm described in the other thread with counters in 5 cogs and it works.
Bytes appear to be sampled every 25ns ... a bit of a surprise, but good for mctrivia's PSRAM [noparse]:)[/noparse]
Fast random byte read/write and byte burst read/write are also implemented.
There is no need to waste an instruction between setting the address and reading the data.
Now to optimize which means basically putting all the byte read/write stuff in another cog.
Possible system XLMM performance is TBD, but based on experiments I expect >= 1.66 MIPS.
There will be one cog left for comm with a second Propeller when fully implemented.
I MUST state again, that the output address from 1 cycle cannot necessarily be followed by a read in the next cycle, no matter how you do it (i.e. by multiple cogs).
While this timing is 12.5nS between clock using 80MHz, the timing is unspecified in the prop and CAN be expected to be CONSIDERABLY less than 12.5nS between the outputs (address bits) going valid and the inputs (read data bits) settled (setup time) before sampling.
Remember, the 10nS srams are most likely the selected faster chips from the wafer and the slower ones are 15nS & 20nS. If they were at the other end, then you may expect to be able run them faster. For example, the 20nS parts may in fact pass 15nS or 10nS specs.
We need a clock to data out valid time and the setup time before sampling plus the time sampling occurs after the clock. These timings will also be affected by the track length/size/layout at these speeds. Only Chip can give us a definitive answer on this.
Just because it works today, does not mean it will work tomorrow, let alone on another pcb or ICs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
I MUST state again, that the output address from 1 cycle cannot necessarily be followed by a read in the next cycle, no matter how you do it (i.e. by multiple cogs).
I've asked for clarity from Chip or Beau. Until then, we can operate on the basis of Fear, Uncertainty, and Doubt (FUD).
Assuming you have pins 0..7 for the data I/O, and pins 8..15 as the least significant bits of the address, you could use the video hardware to automatically increment the address 4 values at a time (using 8 clocks per "pixel" lets me put 2 insctructions per address value). This lets you get 256 bytes of data in a single loop, storing it in a cog buffer. Something like this (untested):
' now initialize the video HW's LSB address values, my long count, and the buffer
mov four_address_bytes,initial_4x_address
mov tmp,#256/4
movd :store_long,#buffer
' sync up with the video generator, and get the 1st address going
waitvid four_address_bytes,#%%3333
mov vscl,vscl_actual
:read_long
' get the LSB address bits set up, then increment all 4
' (the video hardware shifts out a byte every 8 clocks,
' in the order 3 2 1 0 0 0 ... 0 (total of 16 bytes max)
waitvid four_address_bytes,#%%123
mov val,ina 'xxxxxxxxxxxxxxxxxxxxxxxxAAAAAAAA --
ror val,#17 wc 'xxxxxxxxxAAAAAAAAxxxxxxxxxxxxxxx A0
movi val,ina 'bBBBBBBBBAAAAAAAAxxxxxxxxxxxxxxx A0
shr val,#8 '........bBBBBBBBBAAAAAAAAxxxxxxx A0
movi val,ina 'cCCCCCCCCBBBBBBBBAAAAAAAAxxxxxxx A0
shr val,#8 '........cCCCCCCCCBBBBBBBBAAAAAAA A0
movi val,ina 'dDDDDDDDDCCCCCCCCBBBBBBBBAAAAAAA A0
rcl val,#1 'DDDDDDDDCCCCCCCCBBBBBBBBAAAAAAAA A0
' get ready for the next 4 addresses
add four_address_bytes,inc_4x_address_long
:store_long
mov 0-0,val
add :store_long,incDest
' continue if needed
djnz tmp,#:read_long
' done reading, make the waitvid as short
' as possible for a quick re-entry later.
mov vscl,vscl_fastest
burst_read_ret
ret
{===== PASM initialized variables and parameters =====}
inc_4x_address_long long $04_04_04_04
initial_4x_address long $00_01_02_03
incDest long 1 << 9
vscl_fastest long |<12 + 1 ' one clock per "pixel", 1 "pixel"
vscl_actual long |<12 + 7 ' one clock per "pixel", 4 data "pixels" + 3 turnaround
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
I am doing something similar, but with three cogs (one address cog, two readers), to read at 20MB/sec on Morpheus - although I increment the address manually, as I did not want to spend the time to figure out setting up a video generator to do it before UPEW 2009
Using 5 cogs, and faster memory, this should allow for 40MB/sec burst reads (or 50MB/sec with a 100MHz clock)
lonesock said...
Assuming you have pins 0..7 for the data I/O, and pins 8..15 as the least significant bits of the address, you could use the video hardware to automatically increment the address 4 values at a time (using 8 clocks per "pixel" lets me put 2 insctructions per address value). This lets you get 256 bytes of data in a single loop, storing it in a cog buffer. Something like this (untested):
' now initialize the video HW's LSB address values, my long count, and the buffer
mov four_address_bytes,initial_4x_address
mov tmp,#256/4
movd :store_long,#buffer
' sync up with the video generator, and get the 1st address going
waitvid four_address_bytes,#%%3333
mov vscl,vscl_actual
:read_long
' get the LSB address bits set up, then increment all 4
' (the video hardware shifts out a byte every 8 clocks,
' in the order 3 2 1 0 0 0 ... 0 (total of 16 bytes max)
waitvid four_address_bytes,#%%123
mov val,ina 'xxxxxxxxxxxxxxxxxxxxxxxxAAAAAAAA --
ror val,#17 wc 'xxxxxxxxxAAAAAAAAxxxxxxxxxxxxxxx A0
movi val,ina 'bBBBBBBBBAAAAAAAAxxxxxxxxxxxxxxx A0
shr val,#8 '........bBBBBBBBBAAAAAAAAxxxxxxx A0
movi val,ina 'cCCCCCCCCBBBBBBBBAAAAAAAAxxxxxxx A0
shr val,#8 '........cCCCCCCCCBBBBBBBBAAAAAAA A0
movi val,ina 'dDDDDDDDDCCCCCCCCBBBBBBBBAAAAAAA A0
rcl val,#1 'DDDDDDDDCCCCCCCCBBBBBBBBAAAAAAAA A0
' get ready for the next 4 addresses
add four_address_bytes,inc_4x_address_long
:store_long
mov 0-0,val
add :store_long,incDest
' continue if needed
djnz tmp,#:read_long
' done reading, make the waitvid as short
' as possible for a quick re-entry later.
mov vscl,vscl_fastest
burst_read_ret
ret
{===== PASM initialized variables and parameters =====}
inc_4x_address_long long $04_04_04_04
initial_4x_address long $00_01_02_03
incDest long 1 << 9
vscl_fastest long |<12 + 1 ' one clock per "pixel", 1 "pixel"
vscl_actual long |<12 + 7 ' one clock per "pixel", 4 data "pixels" + 3 turnaround
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 12/4/2009 6:43:55 PM GMT
@Jonathan, Nice idea. This allows the other counter to be used for a write strobe [noparse]:)[/noparse] Is two pins the limit?
Bill's block read idea overcomes sync setup time inherent in most multi cog block reads by unrolling the loop.
The block read is good for caching, but I find even a simple low/high bound cache is too slow. Not to high-jack this thread or it's origins, but a fast cache should be discussed at some point. I may start a new thread for that if someone else doesn't do it first. There has to be a way faster than 40 cycles (my lowest to date).
Comments
This wouldn't work for RAM, unless you had 32 props.
Its a super hardware hack job... But im not too sure of the software limitations.
It can be done by clocking each prop a bit longer than the first.
the first prop runs at 80mhz = 12.5ns
the second 79mhz = 12.658ns
the third 78mhz = 12.8205ns
and so on... till you have enough props to sample each line.
This could be done in the pll 16x mode too.
the first prop clocks at 5mhz = 12.5ns
the second 4.9375mhz = 12.658ns
the third 4.875mhz = 12.8205ns
and so on...
You can see where I am going with this?
Not so good for use with much of anything but a scope perhaps? I dunno.
It would be nice to be able to have all COG's run on different clock cycles.
I am sure there are issues with this.. but.... my spin sense says don't overlook this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License
"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "
The dsp/fpga king is dead, long live the prop.
Post Edited (Clock Loop) : 12/1/2009 9:24:39 PM GMT
Once I found that 10nS access was not possible, and that I do not want, nor can I afford, the overhead in synchronising multiple cogs for access, I decided that a 'nop' had to be introduced between the address output and the read input.
This meant that there was a delay of 50nS between the instructions, which I can use to advantage most times anyway. So now my SRAM can be 55nS - no need for 10nS. That was before overclocking. Now, overclocking 25% (for 100MHz operation) gives 25% overall speed on all instructions, but because I am using 55nS parts (pinouts different for 10nS parts) I can either overclock the SRAM (which is working) or add another 'nop' (or rearrange instructions to use it) when accessing SRAM. This is more than offset by the improvement in all instruction speeds.
I have spent considerable time in trying to get the RamBlade layout correct to try even higher overclocking to 120MHz (50% improvement) and beyond. Only time will tell. And of course there is no guarantee when running chip(s) out of spec.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
It drives me *nuts* when I read units that are written the wrong way.
nS is nano-Siemens
ns is nano-seconds
Nitpicking, Nick-picking, ...
Nothing real to contribute,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
BTW: Disk was spelt Disc in the 1970's before Apple called it Disk. The plural of mouse (computer kind) was declared to be mouses, but how many refer to the plural as mice, just like the animal kind.
There are far more serious grammatical and spelling errors. You just have to learn to live with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
No, the SI units have been introduced in 1960
> I do however note the wiki says differently.
And the SI (the standard; "Syst
Nick's right -even about the· 1960 date --- we were still using it 'wrong' in 1970 because none of us important people noticed that a bunch of EggHead-Government folks changed everything.
I don't trust the wiki as much as the *cough* US government... so here it is from the horse's patoot:
All You'd Ever EVER want to know about SI units (and then some)
-courtesy of the National Institute for Standards and Technology·(NIST)
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm positive Heinrich Hertz would be just ecstatic to hear you say that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
And we will honour Chip "Gracey" for the "Parallax 8-cog" microprocessor.
Now we have this amazing gracey faggin-hoff that......
No disrespect, but to rename something later is Smile.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm positive someone had a loose description of force prior to the Newton, and a measure of electrical storage prior to the Farad. They are official units. Cycles per second is not a unit, it's a description. It finally grew up and was awarded a unit name. It wasn't renamed after the fact.
I always thought it was invented by someone sticking their finger in a socket and going "gosh, that hurts 50 times a second" (yes, I know it's 100 or 120 in some countries).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
BTW Where is it 100 or 120Hz? In countries with 110Vac (about) it is 60Hz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Just curious: wasn't Toilette also someone's name? Sounds a little French to me [noparse]:)[/noparse]
And renaming is not Smile ... it's a commitment to one naming. In fact that is very helpful if two people from different countries talk together (or read each others publications). Because having names being standardized means that there is less problem with missunderstanding. S and s might be obvious when using it in a special context ... what about m and M? mW and MW is a little difference.
The world changes ... of course you have to leave comfort-zone if you want to stay up to date.
"My car gets 40 rods to the hogshead and that's the way I likes it."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Is 1billion 10^9 or 10^12?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder.
What? Nobody ever told me we don't! See my sig for clarification.
You can mess with all the units you like except I want my beer to come in Pints.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
at 2.57 guldengroshen's per hogshead, it seems·a·fractionally-distillated,·aliphatic-hydrocarbon Sus Barbatus!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Excellent. I had to look Sus Barbatus up. Gold [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
On my board running at 80MHz with 1MB of 10ns SRAM with data/address on P0..7/P8..27:
- I've implemented the algorithm described in the other thread with counters in 5 cogs and it works.
- Fast random byte read/write and byte burst read/write are also implemented.
- There is no need to waste an instruction between setting the address and reading the data.
- Now to optimize which means basically putting all the byte read/write stuff in another cog.
Possible system XLMM performance is TBD, but based on experiments I expect >= 1.66 MIPS.Bytes appear to be sampled every 25ns ... a bit of a surprise, but good for mctrivia's PSRAM [noparse]:)[/noparse]
There will be one cog left for comm with a second Propeller when fully implemented.
While this timing is 12.5nS between clock using 80MHz, the timing is unspecified in the prop and CAN be expected to be CONSIDERABLY less than 12.5nS between the outputs (address bits) going valid and the inputs (read data bits) settled (setup time) before sampling.
Remember, the 10nS srams are most likely the selected faster chips from the wafer and the slower ones are 15nS & 20nS. If they were at the other end, then you may expect to be able run them faster. For example, the 20nS parts may in fact pass 15nS or 10nS specs.
We need a clock to data out valid time and the setup time before sampling plus the time sampling occurs after the clock. These timings will also be affected by the track length/size/layout at these speeds. Only Chip can give us a definitive answer on this.
Just because it works today, does not mean it will work tomorrow, let alone on another pcb or ICs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
' now initialize the video HW's LSB address values, my long count, and the buffer mov four_address_bytes,initial_4x_address mov tmp,#256/4 movd :store_long,#buffer ' sync up with the video generator, and get the 1st address going waitvid four_address_bytes,#%%3333 mov vscl,vscl_actual :read_long ' get the LSB address bits set up, then increment all 4 ' (the video hardware shifts out a byte every 8 clocks, ' in the order 3 2 1 0 0 0 ... 0 (total of 16 bytes max) waitvid four_address_bytes,#%%123 mov val,ina 'xxxxxxxxxxxxxxxxxxxxxxxxAAAAAAAA -- ror val,#17 wc 'xxxxxxxxxAAAAAAAAxxxxxxxxxxxxxxx A0 movi val,ina 'bBBBBBBBBAAAAAAAAxxxxxxxxxxxxxxx A0 shr val,#8 '........bBBBBBBBBAAAAAAAAxxxxxxx A0 movi val,ina 'cCCCCCCCCBBBBBBBBAAAAAAAAxxxxxxx A0 shr val,#8 '........cCCCCCCCCBBBBBBBBAAAAAAA A0 movi val,ina 'dDDDDDDDDCCCCCCCCBBBBBBBBAAAAAAA A0 rcl val,#1 'DDDDDDDDCCCCCCCCBBBBBBBBAAAAAAAA A0 ' get ready for the next 4 addresses add four_address_bytes,inc_4x_address_long :store_long mov 0-0,val add :store_long,incDest ' continue if needed djnz tmp,#:read_long ' done reading, make the waitvid as short ' as possible for a quick re-entry later. mov vscl,vscl_fastest burst_read_ret ret {===== PASM initialized variables and parameters =====} inc_4x_address_long long $04_04_04_04 initial_4x_address long $00_01_02_03 incDest long 1 << 9 vscl_fastest long |<12 + 1 ' one clock per "pixel", 1 "pixel" vscl_actual long |<12 + 7 ' one clock per "pixel", 4 data "pixels" + 3 turnaroundJonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Using 5 cogs, and faster memory, this should allow for 40MB/sec burst reads (or 50MB/sec with a 100MHz clock)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 12/4/2009 6:43:55 PM GMT
Bill's block read idea overcomes sync setup time inherent in most multi cog block reads by unrolling the loop.
The block read is good for caching, but I find even a simple low/high bound cache is too slow. Not to high-jack this thread or it's origins, but a fast cache should be discussed at some point. I may start a new thread for that if someone else doesn't do it first. There has to be a way faster than 40 cycles (my lowest to date).
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.