HyperBus (AKA xSPI) example for P2-ES Eval Board HyperRAM & HyperFlash Add-on, Part number 64004-ES
David Carrier
Posts: 294
in Propeller 2
I've attached Ozpropdev's example program, that we used to test the HyperRAM/HyperFlash add-on. He wrote it as a quick example, so it isn't heavily commented, but it is clearly laid out, with sections that read and write data to the RAM, as well as a separate flash test.
Comments
Requires a VGA module on pin 48+ and hyperram on pin 32+.
RGB24.DAT file is written to hyperram and repeatedly burst read back to hub.
Code also includes compensation for all system clock speeds.
Has tested Ok up to 380MHz (190Mb/S) :cool:
I'm getting some video that almost (but not quite) looks right with VGA on Pin 0+, but nothing on Pin 48+.
I'm looking at the code and don't see how this is possible though...
Think it might be working...
Yes, that's the correct output.
But I'm still waiting for delivery of HyperRAM accessory board. It's been stuck in Auckland since 5:50 AM (18 hours and counting). Sadly tomorrow is Canterbury anniversary day so there won't be any deliveries until Monday now.
The other possible strong application is for deep memory "scope mode" capturing. It won't be the GHz sampling of common scopes on the market today but still shouldn't be too shabby. At the very least Brian's logic analyser can be deep memory extended with HyperRAM.
I'll say. I'd take a 200MHz logic analyser with 16MB sample memory or more. Right now at home I'm using a 12MHz 8 channel one and it's good for what it can do when I under clock things but there are times when higher speed and/or more channels is warranted. The best thing is you can basically use it on the same platform you are developing on which is ideal for doing IO state analysis/debug work. It was great for me to capture the HDMI pin output at full speed when I was looking at that.
Even at sysclk/2 I found I had to "tune" the clock edge to gaurantee valid data.
Here's what my testing revealed by sweeping sysclk across 20-390 MHz
'$' represents valid data (On the money!) Looking forward to see what you come up with Evan.
Encouraging early results...
I had pondered keeping quiet to get first shot at it.
PS: I don't know if you've tried it but I speculate that enabling clocked (registered) pins will be beneficial for a wider working range of each compensating value.
BTW: Chip asked once about using "registered" I/O... Have you tried that?
Those 1v8 hyperrams are rated to 333 MB/sec from memory
The WAITX bands nicely plotted above by ozpropdev, show that delays are already needing to be tuned.
Less clear is how much temperature spread comes into play, but usually that is significant.
That may mean users need care in selecting a MHz justified left in one of those bands, to allow for temperature spreads.
There is another approach and that is to start with the 3v3 (100 MHz) hyperram and gradually lower the supply voltage, to see if the 133 MHz/266MBps and 166 MHz/333MBps spec points can be achieved at some intermediate (non 1v8) operating point
It makes sense to do some temperature sweeps of the hyperram at some point too
The prop2 will perform worse if the voltage is lowered. It won't be a viable option.
You're using the fast settling time of the P2 dacs to do the physical i/o driving at 1v8 or 1v1 or 300mV or whatever level you need. You still use the normal digital signal as if its a 3v3 logic pin. Its a mode I suggested to Chip so we can interface with non 3v3 logic just like this
The hyperrams have spec points at 100 and 166 MHz but also at 133 MHz in between. Of course this operation may venture off the straight and narrow spec, just like standard overclocking
Whether the input comparator (in pin A>D mode) can keen up is one question I have, but even if the input can't keep up, being able to burst write fast is still useful for capture (just not so useful for video).
Effective use of assembler with pinx and bytx constants you've got there. I don't know what I would have done beyond going straight to streamer ops. Maybe used ALTxx prefix instructions.
EDIT: Ah, not so effective for the VGA example though because of the WFBYTE.
It shows up how important the streamer pin groupings are.
Data specs 3.0V, or almost 10%, so improving Vcc to 2% or 1% would give more MHz. - might get to 250MHz P2 sysclk.
They seem to also have automotive temp specs, so ordering those may give more Temp margin, and so also higher MHz.
How about the ability to push the RevB silicon to higher speeds... Would that be relevant in this case?
I'm using the streamer to achieve sysclk/1 transfers instead of fast hub mode.
Some speeds require "clocked IO" and other don't.
'm still trying to map it all out and nail down a reliable universal code snippet.
I'll keep digging....
Hopefully that will work at all speeds...
Yeah keep at it if you can Brian. This is going to be really useful and max out the HyperRAM's performance with the P2 if it is possible to find a stable/reliable setup.
Interesting, yes, it's expected to be 'fussy'.
Hopefully, a solution can be found that does not need re-tune with temperature changes...
Now I've replaced the bit-bashed block write with a streamer+smartpin fed one. At this point I can reintroduce the compensation value and find a band of useful starting alignments between smartpin and streamer.
At sysclock/2, and larger dividers, everything went as planned and got reliable 100% scoring on a single compensation value all the way to 380 MHz sysclock. Same method as I was able to do for the dual SPI testing. With high temperatures, > 80 °C, that was reduced to about 320 MHz. Err, haven't got that far yet, that's a rx issue.
At sysclock/1 not so much. Best I've got so far is about 99% data integrity.
I thought maybe there was a page boundary issue but even first look using the scope shows me a bit0 error at 18th byte, address 17. It should be a 1 but always reads back as a 0. And it's consistent.