What is fakebox for? I don't see how it's referenced.
Can I use it instead of hacking up vmdebug.spin for interfacing to a second COG?
Why is mailbox defined in vmdebug.spin anyway?
It is not used at all there except for passing the address to vmcog.start.
Can't you just move mailbox to vmcog.spin ?
Bill Henning said...
Happy to!
Only reference as much memory as is allocated to the working set - so if you have 12 pages, you can only write to virtual addresses $0000-0BFF
Bill Henning said...
If you need to interface to a second cog, I suggest declaring two instances of the vm object - say vm1 and vm2.
Bill,
The point of the second cog is to run the memory interface code from that cog without adding all of that to vmcog itself. I do not want to add that code to vmcog. Having a memory driver run in a separate cog lets me redefine the driver without having to commit 10000000 different #defines in your code. I don't mind losing a cog, and I don't mind the small performance hit in my application.
Why is mailbox defined in vmdebug.spin? It is not used at all there except for passing the address to vmcog.start. Can you move mailbox to vmcog.spin and make it 6 longs?
Congrats finding that bug. That may have been what I was seeing in my early testing.
Ok - I thought you were trying to run 2 vmcog's [noparse]:)[/noparse]
The mailbox is defined in the client applications so that more than one VMCOG can run on the same propeller. All VMCOG cares about is getting the address of a four-long mailbox in PAR on startup.
Once BradC adds #include (if he has the time), the #ifdef forest will get thin... I plan on three files:
vmcog-h.spin
vmcog-init.spin
vmcog-hardware.spin
vmcog-h would include constants needed for the second.
vmcog-init would have the BINIT code (that gets overwritten)
vmcog-hardware would have BREAD and BWRITE (and a BSTART if there was one)
That way, just rename a platforms files, no changes to VMCOG [noparse]:)[/noparse]
Thanks re/bug... that was a nasty one.
jazzed said...
Bill,
The point of the second cog is to run the memory interface code from that cog without adding all of that to vmcog itself. I do not want to add that code to vmcog. Having a memory driver run in a separate cog lets me redefine the driver without having to commit 10000000 different #defines in your code. I don't mind losing a cog, and I don't mind the small performance hit in my application.
Why is mailbox defined in vmdebug.spin? It is not used at all there except for passing the address to vmcog.start. Can you move mailbox to vmcog.spin and make it 6 longs?
Congrats finding that bug. That may have been what I was seeing in my early testing.
Ok, most of that makes sense. But if you have more than one vmcog, wouldn't you need more than one mailbox?
It seems that's an even better argument for encapsulating it all in vmcog and providing a method to get the interface pointer.
In any event though (for more than one vmcog per propeller) it seems like there would be more than one copy of vmcog lying around with different defines per file.
Cheers.
--Steve
Bill Henning said...
Hi Steve,
Ok - I thought you were trying to run 2 vmcog's [noparse]:)[/noparse]
The mailbox is defined in the client applications so that more than one VMCOG can run on the same propeller. All VMCOG cares about is getting the address of a four-long mailbox in PAR on startup.
OBJ
vm1: "VMCOG-PROPCADE"
vm2: "VMCOG-TRIBLADE2"
VAR
long mbox1, mbox2
PUB main
vm1.start(@mbox1,$7E00,8)
vm2.start(@mbox2,$6E00,8)
In this case, yes, mbox could be defined in the vmcog.spin file
But consider this case:
OBJ
vm1: "VMCOG-SPISHARED"
vm2: "VMCOG-SPISHARED"
cpm1: "zicog"
cpm2: "zicog"
VAR
long mbox1, mbox2
PUB main
vm1.start(@mbox1,$7E00,16)
vm2.start(@mbox2,$5E00,16)
cpm1.start(@mbox1,$00000)
cpm2.start(@mbox2,$10000)
- assume there is a semaphore around BREAD/BWRITE so only one VMCOG can do it at once
- assume zicog.start(@vmcog_mailbox,virtual_addr_base_for_64KB)
then two CP/M images can happily share the same extended memory hardware, without conflict, rarely waiting for the other cpm's swapping!
Four SPI ram's, two CP/M's, both running at close to the same speed one would run at!
Or two ZOG's... or one ZOG / one CP/M... or...
jazzed said...
Fascinating ....
Ok, most of that makes sense. But if you have more than one vmcog, wouldn't you need more than one mailbox?
It seems that's an even better argument for encapsulating it all in vmcog and providing a method to get the interface pointer.
In any event though (for more than one vmcog per propeller) it seems like there would be more than one copy of vmcog lying around with different defines per file.
Thanks Bill, but I think I would rather merge the diffs myself later ... I posted those mainly for your review. I'm not happy with the the diffs as they are and I can just as easily patch the diffs as necessary until I have something that works. I still can't figure out how the pages ended up in ROM space ... any hints on that would be greatly appreciated [noparse]:)[/noparse]
That way, when there is a new revision of a specific platform (until we have includes) a simple posting here of a file with four sections can integrate easily:
BINIT
BREAD
BWRITE
BDATA
I can also support the optional BSTART, or it can be part of BREAD or BWRITE.
Thoughts?
Re/ ROM space
I can see two ways of that happening:
1) You referred to a VM address above $FFFF, which would use an invalid TLB descriptor
2) The TLB was corrupted
jazzed said...
Thanks Bill, but I think I would rather merge the diffs myself later ... I posted those mainly for your review. I'm not happy with the the diffs as they are and I can just as easily patch the diffs as necessary until I have something that works. I still can't figure out how the pages ended up in ROM space ... any hints on that would be greatly appreciated [noparse]:)[/noparse]
1) You referred to a VM address above $FFFF, which would use an invalid TLB descriptor
2) The TLB was corrupted
My working assumption is 2 and is somehow related to trying to use part of mailbox for my purpose.
---
BTW: as you know DRAM is a little complicated with RAS/CAS, etc....
One other thing that is necessary for DRAM in a one cog solution is a way to do a refresh timer.
Today, I call the refresh in the cog interface "spinner" and use a count down timer in the refresh
when the count down expires.
Regardless, I'm not a big fan of this because of the spinner performance hit when enabled.
Of course all these details are hidden away in another file and can be replaced whole-sale if necessary [noparse]:)[/noparse]
{{
COG Interface Spinner ...
}}
' so the waitcmd loop would be something like this which of course makes a 2:1 slow down on the spinner
'
waitcmd wrlong zero,pvmcmd
wl rdlong vminst, pvmcmd wz ' top 23 bits = address, bottom 9 = command
mov vmaddr, vminst
#ifdef XEDODRAM
call #mmuRefresh
#endif
if_z jmp #wl
#ifdef XEDODRAM
{{
______________
PRI mmuRefresh
Refresh must happen typically in less than 15 milliseconds for old DRAM.
}}
mmuRefresh djnz mmuRefCnt,#mmuRefresh_ret ' skip refresh if not time
' to save some time the djnz could just as easily be djnz mmuRefCnt, #wl
mov mmuRefCnt,mmuRefPer
' ...
mmuRefresh_ret ret
#endif
jazzed, I was thinking about the refresh placement...
It's OK to refresh dram in bursts, as long as you hit every row.
I think it is fairly safe to assume that there will be many rdvxxxx each second, and there will be some time available right before the "jmp #waitcmd" due to the client cog having to see that cmd is now clear... so I think a good approach would be replacing "jmp #waitcmd" with "jmp #refresh"
I'd code refresh something like:
refresh
mov tnow,cnt
mov diff,tnow
sub diff,then wc
mov then,tnow
cmp diff,five_ms wc
if_nc jmp #waitcmd
<insert code to refresh all rows>
jmp #waitcmd ' or fall into waitcmd
You could also refersh say 128 rows at a time, and change the five_ms to one_ms or similar
**OR**
bet that reads will be done often enough, and just do a CAS-before-RAS autorefresh cycle after every read!
Actually, assuming 1024 rows, and 15ms, you would have to do a cas-before-ras every 14.6us
a read takes approx. 1.2us, so you would be pretty safe doing a refresh cycle every 4th read or so.
I really like what you're thinking there Bill. Unfortunately there is a small problem with the approach.
The problem with replacing jmp #waitcmd with jmp #refresh is one example from the JVM code.
All "hardware" things are done using the JNI (Java Native Interface). This means that some code
like the JNI delay call is all done in Spin. No Java code is required for the delay and thus, the
vmcog spinner won't get posted.
Yes, I'm using CAS before RAS [noparse]:)[/noparse]
Now if we could only find a really nice way to connect that Micron 32MB SDRAM [noparse]:)[/noparse]
Bill Henning said...
I think it is fairly safe to assume that there will be many rdvxxxx each second, and there will be some time available right before the "jmp #waitcmd" due to the client cog having to see that cmd is now clear... so I think a good approach would be replacing "jmp #waitcmd" with "jmp #refresh"
Page replacement logic is working.
I'm just puzzled with the readback after fill (the memory dump is ok, see screenshot below).
Also reading a single byte to force loading a new page works, but the byte is wrong.
I went up to promising memory tests and benchmarks, but no further (thanks to VMCog maybe that code could be recovered now...)
For the refresh, I simply added a CBR at each command wait cycle, thus enforcing that at least one refresh cycle was made in the event of continuos page read requests.
It only adds a slight latency to the page transfer, and in this case we're only talking of cache misses, not regular memory accesses, so I'd go with the simple and easy one. ·
I would be perfectly willing to add a "VMREFRESH" command, that Spin could send to the mailbox to force a refresh...
also, at the cost of a 200ns performance hit, it would be possible to change the spinner to incorporate a "is it time to refresh yet? / call refresh" two instruction sequence.
I am sure a viable solution exists
Funny, I have five of those 32Mx8 TSOP-II parts in my "in box"... strange coincidence, don't you think? They arrived from Digikey a few months ago...
jazzed said...
I really like what you're thinking there Bill. Unfortunately there is a small problem with the approach.
The problem with replacing jmp #waitcmd with jmp #refresh is one example from the JVM code.
All "hardware" things are done using the JNI (Java Native Interface). This means that some code
like the JNI delay call is all done in Spin. No Java code is required for the delay and thus, the
vmcog spinner won't get posted.
Yes, I'm using CAS before RAS [noparse]:)[/noparse]
Now if we could only find a really nice way to connect that Micron 32MB SDRAM [noparse]:)[/noparse]
Try the new version, I fixed a bug where the first value written to a non-present page would be corrupted. I was re-using a temp variable in one place too many [noparse]:)[/noparse]
With a four page working set, you could just fill to 2048 and it would force a flush of all four pages.
Looks like I need to add a "'#define HX512" to BINIT/BREAD/BWRITE/BEND in the next version...
AntoineDoinel said...
Hydra+HX512 here, still something wrong it seems.
Page replacement logic is working.
I'm just puzzled with the readback after fill (the memory dump is ok, see screenshot below).
Also reading a single byte to force loading a new page works, but the byte is wrong.
I need a better look, meanwhile if anyone want to try on the real hardware, as I can't test on my Proto+HX512 franken-thing (I broke the messy cable )
I used a 4 page working set, and only 4096 fill instead of 65536 as Gear is excruciating slow...
P.S.: I see that you just put out a new version, this one is based on previous but the parts are easily identifiable.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Only reference as much memory as is allocated to the working set - so if you have 12 pages, you can only write to virtual addresses $0000-0BFF
This could have been the cause of the corruption where you saw hub page addresses > $7C00
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Can I use it instead of hacking up vmdebug.spin for interfacing to a second COG?
Why is mailbox defined in vmdebug.spin anyway?
It is not used at all there except for passing the address to vmcog.start.
Can't you just move mailbox to vmcog.spin ?
Nothing is ever easy [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
It is used by vm.readfbyte / vm.writefbyte, which execute a similar amount of code to readvbyte/writevbyte without talking to vmcog
If you need to interface to a second cog, I suggest declaring two instances of the vm object - say vm1 and vm2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I shaved one long too much in April, and re-used a temporary variable I should not have.
First writes work now. I'll upload a new version shortly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
The point of the second cog is to run the memory interface code from that cog without adding all of that to vmcog itself. I do not want to add that code to vmcog. Having a memory driver run in a separate cog lets me redefine the driver without having to commit 10000000 different #defines in your code. I don't mind losing a cog, and I don't mind the small performance hit in my application.
Why is mailbox defined in vmdebug.spin? It is not used at all there except for passing the address to vmcog.start. Can you move mailbox to vmcog.spin and make it 6 longs?
Congrats finding that bug. That may have been what I was seeing in my early testing.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Ok - I thought you were trying to run 2 vmcog's [noparse]:)[/noparse]
The mailbox is defined in the client applications so that more than one VMCOG can run on the same propeller. All VMCOG cares about is getting the address of a four-long mailbox in PAR on startup.
Once BradC adds #include (if he has the time), the #ifdef forest will get thin... I plan on three files:
vmcog-h.spin
vmcog-init.spin
vmcog-hardware.spin
vmcog-h would include constants needed for the second.
vmcog-init would have the BINIT code (that gets overwritten)
vmcog-hardware would have BREAD and BWRITE (and a BSTART if there was one)
That way, just rename a platforms files, no changes to VMCOG [noparse]:)[/noparse]
Thanks re/bug... that was a nasty one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Ok, most of that makes sense. But if you have more than one vmcog, wouldn't you need more than one mailbox?
It seems that's an even better argument for encapsulating it all in vmcog and providing a method to get the interface pointer.
In any event though (for more than one vmcog per propeller) it seems like there would be more than one copy of vmcog lying around with different defines per file.
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
A puzzle..
How come this:
mov data, ina 'Read SRAM wrbyte data,ptr 'Save the byteIs not equivalent to this:
wrbyte ina,ptr 'Read and save the byteAssuming that "data" is not further used and the timing difference does not matter?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In this case, yes, mbox could be defined in the vmcog.spin file
But consider this case:
- assume there is a semaphore around BREAD/BWRITE so only one VMCOG can do it at once
- assume zicog.start(@vmcog_mailbox,virtual_addr_base_for_64KB)
then two CP/M images can happily share the same extended memory hardware, without conflict, rarely waiting for the other cpm's swapping!
Four SPI ram's, two CP/M's, both running at close to the same speed one would run at!
Or two ZOG's... or one ZOG / one CP/M... or...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
It really annoyed me in the past!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Ha! (Slaps head).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yea, it really tweaked me when I found out about it. You could say I'm still annoyed by it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Largos has pre-defined mailboxes [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I uploaded v0.961 to the first post, it supports PropCade, TriBlade_2 and XEDORAM!
After we test this for a couple of days with real software, I will make a version that uses a hub-based table, allowing 512KB+ of VM space.
I've already written the new table code, I just have to test it
I am also going to be adding support for FlexMem, both CPU's on Morpheus and Morpheus+, and PLC-G.
It would be nice to also support the Hydra memory card, as well as DracBlade and RamBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/7/2010 8:09:48 PM GMT
Cheers.
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I am adding another "section"
BDATA
for interface specific data.
That way, when there is a new revision of a specific platform (until we have includes) a simple posting here of a file with four sections can integrate easily:
BINIT
BREAD
BWRITE
BDATA
I can also support the optional BSTART, or it can be part of BREAD or BWRITE.
Thoughts?
Re/ ROM space
I can see two ways of that happening:
1) You referred to a VM address above $FFFF, which would use an invalid TLB descriptor
2) The TLB was corrupted
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I think the vmcog.spin XEDODRAM code is mostly safe. BDATA sounds like what I need ... I look forward to details on that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I could quite happily move my BSTART code to the front of BREAD and BWRITE if we can spare the space (6 LONGS).
Actually those two mods would save 2 CALLs a RET and a JMP.
So attached is a version with a BSTARTBDATA and some more optimizations to BREAD/WRITE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/7/2010 9:04:48 PM GMT
That BDATA I added at the end has those pesky LONG constants you have to define for big immediates in PASM and actual variable data.
The latter should be in VAR if you want multiple VMCogs running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My working assumption is 2 and is somehow related to trying to use part of mailbox for my purpose.
---
BTW: as you know DRAM is a little complicated with RAS/CAS, etc....
One other thing that is necessary for DRAM in a one cog solution is a way to do a refresh timer.
Today, I call the refresh in the cog interface "spinner" and use a count down timer in the refresh
when the count down expires.
Regardless, I'm not a big fan of this because of the spinner performance hit when enabled.
Of course all these details are hidden away in another file and can be replaced whole-sale if necessary [noparse]:)[/noparse]
{{ COG Interface Spinner ... }} ' so the waitcmd loop would be something like this which of course makes a 2:1 slow down on the spinner ' waitcmd wrlong zero,pvmcmd wl rdlong vminst, pvmcmd wz ' top 23 bits = address, bottom 9 = command mov vmaddr, vminst #ifdef XEDODRAM call #mmuRefresh #endif if_z jmp #wl #ifdef XEDODRAM {{ ______________ PRI mmuRefresh Refresh must happen typically in less than 15 milliseconds for old DRAM. }} mmuRefresh djnz mmuRefCnt,#mmuRefresh_ret ' skip refresh if not time ' to save some time the djnz could just as easily be djnz mmuRefCnt, #wl mov mmuRefCnt,mmuRefPer ' ... mmuRefresh_ret ret #endif▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Great! I will add BDATA at the end of the code, where some ifdef's currently reside...
heater:
I will merge in your changes in a couple of hours; re/ variables - each cog has its own local set [noparse]:)[/noparse]
jazzed:
That could easily be the case. Feel free to tack on extra longs to the mailbox.
Yep, I am familiar with DRAM's - I have a bunch of different types around my lab that I intend to play with - when I have some time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
datax long 0
outx long 0
Presumably for multiple VMCOGs they should be in a VAR section.
Scratch that. I'm getting tired here. I was in the mode of DAT that ends up in HUB but this all gets loaded to COG anyway, duhhh...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 6/7/2010 9:18:18 PM GMT
It's OK to refresh dram in bursts, as long as you hit every row.
I think it is fairly safe to assume that there will be many rdvxxxx each second, and there will be some time available right before the "jmp #waitcmd" due to the client cog having to see that cmd is now clear... so I think a good approach would be replacing "jmp #waitcmd" with "jmp #refresh"
I'd code refresh something like:
You could also refersh say 128 rows at a time, and change the five_ms to one_ms or similar
**OR**
bet that reads will be done often enough, and just do a CAS-before-RAS autorefresh cycle after every read!
Actually, assuming 1024 rows, and 15ms, you would have to do a cas-before-ras every 14.6us
a read takes approx. 1.2us, so you would be pretty safe doing a refresh cycle every 4th read or so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 6/7/2010 9:29:34 PM GMT
The problem with replacing jmp #waitcmd with jmp #refresh is one example from the JVM code.
All "hardware" things are done using the JNI (Java Native Interface). This means that some code
like the JNI delay call is all done in Spin. No Java code is required for the delay and thus, the
vmcog spinner won't get posted.
Yes, I'm using CAS before RAS [noparse]:)[/noparse]
Now if we could only find a really nice way to connect that Micron 32MB SDRAM [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Page replacement logic is working.
I'm just puzzled with the readback after fill (the memory dump is ok, see screenshot below).
Also reading a single byte to force loading a new page works, but the byte is wrong.
VMDebug Main Menu 1) View Page Table 2) Flush Page Table 3) VMREADB 4) VMREADW 5) VMREADL 6) VMWRITEB 7) VMWRITEW 8) VMWRITEL 9) Show VM Page 0) Fill test pattern h) Heater's test b) Benchmark (slow, in spin) f) Fill memory with Word pattern READY> 1 TLB Contents: Acesses L D Hub (Raw Data) VM_ADDR ------- - - ----- ---------- ------- 00: $000000 - - $7600 (0000003B) $000000 01: $000000 - - $7800 (0000003C) $000200 02: $000000 - - $7A00 (0000003D) $000400 03: $000000 - - $7C00 (0000003E) $000600 VMDebug Main Menu 1) View Page Table 2) Flush Page Table [color=gray][noparse][[/noparse]...][/color] f) Fill memory with Word pattern READY> f Filling memory... Reading memory... [color=red]0000: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0020: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0040: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0060: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0080: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]00A0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]00C0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]00E0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0100: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0120: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0140: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0160: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0180: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]01A0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]01C0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]01E0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 [/color] [color=red]0200: B400 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202 0202[/color] VMDebug Main Menu 1) View Page Table 2) Flush Page Table [color=#808080][noparse][[/noparse]...][/color] f) Fill memory with Word pattern READY> 1 TLB Contents: Acesses L D Hub (Raw Data) VM_ADDR ------- - - ----- ---------- ------- 01: $000010 - - $7600 (0000803B) $000200 05: $000100 - D $7800 (0008023C) $000A00 06: $000100 - D $7A00 (0008023D) $000C00 07: $000100 - D $7C00 (0008023E) $000E00 VMDebug Main Menu 1) View Page Table 2) Flush Page Table 3) VMREADB [color=gray][noparse][[/noparse]...][/color] f) Fill memory with Word pattern READY> 3 Enter HEX Address: 1234 Read Byte [color=red]$99[/color] VMDebug Main Menu 1) View Page Table 2) Flush Page Table [color=gray][noparse][[/noparse]...][/color] f) Fill memory with Word pattern READY> 1 TLB Contents: Acesses L D Hub (Raw Data) VM_ADDR ------- - - ----- ---------- ------- 05: $000100 - D $7800 (0008023C) $000A00 06: $000100 - D $7A00 (0008023D) $000C00 07: $000100 - D $7C00 (0008023E) $000E00 09: $000001 - - $7600 (0000083B) $001200 VMDebug Main Menu 1) View Page Table [color=gray][noparse][[/noparse]...][/color] b) Benchmark (slow, in spin) f) Fill memory with Word pattern READY> b Approx. Spin overhead for Filling memory...37 ms. Approx. Spin overhead for Reading memory...33 ms. Filling memory...Spin Fill took 52 ms. Reading memory...Spin Read took 47 ms. VMDebug Main Menu [color=#808080][noparse][[/noparse]...][/color] READY>I need a better look, meanwhile if anyone want to try on the real hardware, as I can't test on my Proto+HX512 franken-thing (I broke the messy cable·
I used·a 4 page working set, and only 4096 fill instead of 65536 as Gear is excruciating slow...
P.S.: I see that you just put out a new version, this one is based on previous but the parts are easily identifiable.
Post Edited (AntoineDoinel) : 6/7/2010 9:59:37 PM GMT
I've done a similar experiment with a Fast Page Mode SIMM: http://forums.parallax.com/showthread.php?p=869842
I went up to promising memory tests and benchmarks, but no further (thanks to VMCog maybe that code could be recovered now...)
For the refresh, I simply added a CBR at each command wait cycle, thus enforcing that at least one refresh cycle was made in the event of continuos page read requests.
It only adds a slight latency to the page transfer, and in this case we're only talking of cache misses, not regular memory accesses, so I'd go with the simple and easy one.
·
Further optimization of the BREAD/BWRITE loops. Now about as tight as they will ever be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I would be perfectly willing to add a "VMREFRESH" command, that Spin could send to the mailbox to force a refresh...
also, at the cost of a 200ns performance hit, it would be possible to change the spinner to incorporate a "is it time to refresh yet? / call refresh" two instruction sequence.
I am sure a viable solution exists
Funny, I have five of those 32Mx8 TSOP-II parts in my "in box"... strange coincidence, don't you think? They arrived from Digikey a few months ago...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Try the new version, I fixed a bug where the first value written to a non-present page would be corrupted. I was re-using a temp variable in one place too many [noparse]:)[/noparse]
With a four page working set, you could just fill to 2048 and it would force a flush of all four pages.
Looks like I need to add a "'#define HX512" to BINIT/BREAD/BWRITE/BEND in the next version...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system