Hydra sram card comming soon...

AndreL

The original HYDRA was going to have SRAM built in, but we decided to leave it out since Parallax wanted to show off the propeller as much as possible without any extra hardware. Anyway, I designed the memory expansion about 15 months ago, but only recently had time to start playing with it again a couple months ago, and pricing the whole thing. In any event, its all done now, so I will start the manufacturing phase very soon.

Any last minute requests, I can still probably get in if they are reasonable, so I am all ears. But, more or less its a byte wide system with a 3 pin control and clock, so there are only so many things you can do with that. A number of others have been working with memory expansion designs for the propeller and they all more or less look alike at the end other than the implementation and some of the features.

Thus,·what I am talking about are "easter eggs" on the card, I am planning on the SRAM itself, the controller, and of course the EEPROM, so this will be a "super cart" of sorts.

Also, I am open for suggestions for other add on cards people would like to see, if I get enough suggestions, I might take the top #1 suggestion and do it. I probably can imagine what people will say, but I want to see before I say anything, so I don't sway anyone's ideas --

Andre'
·

kelvin james

A flash from the past, i see no one has looked at these lately, whether it is useful or not, i just thought i would remind people that they do exsist.


SAMSUNG Electronics to Produce Industry's Highest-density Smart Card IC with Embedded NOR Flash

CARTES 2004, Paris, France - November 2, 2004 : Samsung Electronics Co., Ltd., a leader in advanced semiconductor technology, announced today that it is preparing to mass produce a smart card IC with 1-megabyte (MB) of embedded NOR Flash memory (S3FJ9SK) the highest density available today.

The IC's higher data storage will enable the first widespread use of multimedia message service (MMS), as well as improved Internet access, increased phone book storage, more online games and other applications for 3G mobile handsets.

The new 1MB embedded NOR Flash smart card IC will be demonstrated in Booth Hall 3 no.3 C 29 at the CARTES 2004 exhibition held at Paris, France from November 2 through 4.

The embedded1MB NOR Flash memory smart card IC utilizes an ARM-based 32bit SC200 secure core, a 3-DES encryption standard and a crypto processor, enabling enhanced reliability, faster subscriber identification and more security for preventing the leakage of information.

Samsung also has an embedded 16Kilobytes (KB) SRAM to enable code designers to apply diverse programs, while simultaneously attaining significant performance enhancements. A built-in JAVA accelerator facilitates a JAVA-based platform, improving the speed up to 8 times.

The high-density embedded NOR Flash memory smart card IC supports operating voltages from 1.62V to 5.5V. The low power feature fully complies with the power consumption levels of the GSM standard. Moreover, memory management has been optimized because data programming and updating processes operate independently of one another.
With the introduction of this highly efficient smart card IC, Samsung now supports a full line of embedded NOR Flash memory smart card ICs from 192KB to 1MB.
The S3FJ9SK is available for sales in Europe.

Paul Baker

Andre, this post may be a little too late, but I have a suggestion. At one point I was designing something similar using a second Propeller instead of CPLD/FPGA (before other more pressing issues bumped it off the radar screen), and one feature I was going to implement was 8/16bit pointer mode where the contents of the SRAM were used·to update the address into the SRAM. This would make linked lists and other pointer type data structures streamlined on the architecture. The 8 bit pointer mode is easy to implement, the 16 bit pointer would require an 8 bit internal buffer to preserve the pointer's address to get both parts of the new address. I don't know how helpful the mode would be for game design, but generally it can speed up such data structure addressing by more than 100%.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

AndreL

Right, the pointer idea is a good one, but in the end, I decided that as long as you can directly/ranomly address the 1st 64K of memory use can do all your dynamic linked lists, trees etc. there, then from 64 up, it will work in more of a block streaming mode with auto inc/dec.

We will see how people use the SRAM card, if they really like it then I will build more of a memory controller with these nice features like you suggested.

But, once its done, I will send one to you to check out. I am sure parallax will probably want to sell these as well as an accessory with the hydra.

Right now, I am just trying to layout this little monster on that miniature card [noparse]:)[/noparse] For all the buses, etc. I had to use a 100 pin CPLD to do all the interfaces, that doesn't give you a lot of room to work with for routing (at least if you want it to look nice).

Andre'

Dennis Ferron

Anyone ever do that 6502 Hydra card you mentioned wanting to see, Andre? It seems to me that any 6502 card would also work as an SRAM card, if you had shared access to the RAM.

AndreL

No, there are no cards for the hydra yet other than the ones I developed. But, hopefully people will develop cards and put them for sale. However, on the 6502 card. One thing you could do is out a 6502 microcontroller on the card, then use the byte wide interface to act as a conduit to memory mapped space on either machine for comms thru a shared memory as you mentioned.

Andre'

Bill Henning

Hmm...

I strongly suspect that a 6502 emulator could be written to fit in one cog and run at around at 1-1.5 6502 MHZ equivalent. I used to do a LOT of 6502 assembly coding over 20 years ago...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Dennis Ferron

Well then someone's got to make a 6502 card then!

This week I been working on a Hydra 6502 card prototype; it's on my breadboard right now. I just finished debugging the RAM access and control logic, and I'm about to try jamming the 6502 with NOP's to see if the address lines cycle. Instead of latching the address lines for the RAM, I'm using the 6502 to address RAM for me.

It'll be another month before I can afford a Hydra, so I'm running it on a PropStick until I get my Hydra.

Yeah, you could probably emulate a 6502 on the Prop and even run it faster than the real hardware, but -blah- I'm just not a big fan of simulations! They're not real!

lnielsen

Andre'

Sorry for the late response. Sometimes work gets in the way. Is there any chance you could have the card work with Phil Pilgrim' PropCAM http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=131097 When I recently asked him the same question he seemed to thing it would require a custom CPLD configuration. It would be real cool if we could reconfigure your memory board to act as a video image buffer from his camera. His limiting factor seems to be Propeller memory which your board fixes. I would like to see stereo RGB vision for my robot some day in the future.

Len

El Paisa

Is the procam for sale yet?

Paul Baker

Len, since Andr

Lawson

AndreL, will the CPLD on this SRAM card be re-programmable? I wouldn't want anything fancy, but having the CPLD programming pins easy to access would let crazy people tweek the memory card if they needed to.

Marty

AndreL

I am glad you asked [noparse]:)[/noparse] Of course, I always like to slip some extra functionality in there for really creative people, so the CPLD is re-programmable, there is a header port on the board, you can plug right into. Once the board is done, I will release the specs, CPLD, etc. so if you want you basically have a CPLD that has nearly every single I/O pin from the expansion port going into it then the interface to the SRAM, thus you can do whatever you want with it internally and give it other behavior. For example, with the CPLD dealing with 512K sram, that takes up a lot of space, but if you back off to 16-32K, then that leaves some room for some cool image processing or bitblitting you might be able to get the CPLD to do. Also, the board then doubles as a CPLD dev kit, and there are 9 leds you can control, so with the board, you can also experiment with CPLD programming as well, and just blink lights etc., so its a cool like guy [noparse]:)[/noparse]

My local PCB makers are making it right now, should have prototypes back in a week, then maybe 1-2 more iterations and then we will be ready to manufacture and sell it. Thinking $39-49.

Andre'

JT Cook

That is cool that you can reprogram the CPLD, what hardware do you need to do that?

AndreL

You would need a programmer for the CPLD, but like most in circuit programmers you can make one with a parallel cable and some parts, or just buy one for $39-79, whatever they cost from your respective distributor.

Andre'

dr hydra

Andre

When is release the SRAM card be sure to include a kick butt demo program. A little eye candy is always good

AndreL

I will try, but my new philosophy is to get product out then deploy software later. Rather than hold it until all the demos are done. But, when I get the cards back, I will send one to all my demo coders, see what they come up with. However, a good demo takes 2-4 weeks, I don't think we want to delay the deployment by another month on top of all the other delays that are incurred with manufacturing etc. but, if I can overlap the delay with the manufacturing cycle of the full one then of course we will have some demos.

If I get some time I will write a 3D engine that uses the memory, but doubtful that will deploy with the card. So we will see what happens, but first thing is to get the card out there and then we can always add more stuff to the CD that it comes with [noparse]:)[/noparse]

Andre'

Jasper_M

Is the EEPROM the same (size) as on the standard Hydra cards? And is how does the SRAM access speed compare to the speed of Prop's shared RAM?

AndreL

The EEPROM is 128K, and to access the SRAM, basically, you have to control the r/w line, then pulse the latch, so its about 5 operations or 5 instructions, that's about it, thus at the end of the day, its 1.5x as slow as the hub memory, since you can get one hub access every 16 clocks or 4 instructions. Its more or less the amount of time it takes toggle a pin and then pull the data from the data bus. The SRAM can go 100Mhz if you could drive it that fast, so the bottle neck is just the control from the propeller. But, if you want random access then you have to write the low and high byte address, which each also take 4-5 instructions, but once you use the post increment/decrement modes for block moves then the work is just selecting read or write, and pulsing the sram and looking at the data on the bus, or putting the data on the bus to write, so its as fast as it can go.

Of course, if you are doing multiple reads or writes, or this or that, you can cut down on I/O settings, but the bottom line is you will want to access the memory usually in a loop of sorts, thus you will take an address counter and have to write it to the port, then put the data there, then pulse the write latch, things like that. So although you can cut instructions in certain cases, there is a minimum amount of work that has to be done to any sram to get things in and out of it.

Andre'

AndreL

The SRAM cards are back from prototyping, they look pretty cool [noparse]:)[/noparse] Green for now, the final ones will be yellow I think. Anyway, I am reviewing the circuit before soldering the parts down for test, its all 603 SMD, so I need to lower my stress level before doing this. I am pretty excited, this will really improve the HYDRAs abilities for emulation, games, graphics, and languages. Also, anyone can buy this card, so all you need is a 20 pin header and you can plug it into your propeller projects as well


Andre'

Jasper_M

Sounds good enough [noparse]:)[/noparse] . Maybe you could get even more speed with counters (if someone would require higher speed...)

AndreL

The counters aren't the problem, the SRAM controller goes much faster than the propeller does, but its simply the fact that the propeller has no external bus interface, so you have to go thru the steps of accessing memory virtually by puttting down and address, performing a read or write, etc. and have all the steps. When you say:

move x,y

With a processor with an external bus interface, it does all the work at the atomic level with the bus, but when you have to simulate a an external bus with data, address, and control, you have to control those signals state by state, this is why things are limited by the propeller not by the external hardware, it goes 400Mhz, and the memory 100+Mhz, the prop is going 20 mips, but the prop needs to do 3-5 things to "talk" to the memory that's where the bottleneck happens.

Jasper_M

Actually I didn't mean the counters on the CPLD, but the ones on Propeller (CTRA/B). Maybe they could be used to request data automatically from SRAM, so you could skip one or two steps in ASM (if reading in a loop).

AndreL

Yes, that's possible, we could set up a counter to pulse the read line over and over, each time the memory would put the data on the bus, you read it, increment your local pointer, then by the next 4 cycles and you come to read again the counter pulsed the read line again. The trick would be to make sure to set the stuff up perfectly, but "should" be possible. This is why I have a single clock line to the sram for "do it", this way if we can work out to control it with a counter out put, we set teh counter to pulse every 4 cycles then sync it to the read, so that he read happens in the middle of the pulses and we should be able to remove the

pin out = low
pin out = high
pin out = high

Sequence to pulse the clock line on the memory.

Andre

Jasper_M

Okay, thanks for your replies : ). I can't wait to get my hands on the card... even though I have very little free time in my hands now... By the way, are you going to release the card along with a bitmapped video driver? Or will the code be released later or do we have to code all ourselves?

AndreL

Maybe, its just a matter of time, I would rather put the card for sale ASAP, then add more software to the CD as I develop it.

Andre'

AndreL

Status report, the SRAM cards came back and with a couple noise issues resolved seem to work 100%, we are going to continue to test them, running billions of iterations, forward, backward, random access, etc. to see if we can get a single bad bit, but so far, with billions of memory accesses, looks good. So sending out another prototype with a little better layout, and fingers crossed this next iteration should be ready to go. Usually it takes 4-5 iterations to get it perfect, but looks like this one will only take 2 iterations.

End of next week, the next PCBs should be back and we will know more then.

Now, just need to decide on the color [noparse]:)[/noparse] I think yellow PCB with black lettering would look slick.

Andre'

mahjongg

Andre'

Exciting stuff!

Could you say something about the programmer interface and it's capabilities yet?
I am very curious about them.

Also, do you think your memory expander is flexible/fast enough so that a COG can use it directly as a frame-buffer for generating a high resolution and high color mode video signal? That would be fantastic!

For example a completely unencumbered (no color limitations) 256x192 by 96 color PAL/NTSC composite signal driver, and a 1024x768 by 64 color VGA signal driver should both be possible if the COG can get data from the memory expander fast enough. That is, unless there is something in the video shifter logic, or the COG's execution speed, that prevents these modes. I am not aware of all the limitations or the Propeller yet.

One trick you could use is to use two COG's. One that does the even, and another that does the odd pixels. of course the COG's must be extremely well synchronized to pull this off.
But I thought of one way to do this. Lets say we have two COG's, a "master" and a "slave". Both are loaded with a (each slightly modified) copy of the new TV driver, and each routine would have a slightly different "prelude" routine, that is used to synchronise (start at exactly the same time) the TV drivers. The "master" COG routine must read the system counter, and add a reasonable value to it, and then "publish" this "future time" value for the slave cog through the 32k main RAM, along with a "flag" to tell the "future time" value in RAM is valid. The slave COG, in the mean time, could wait for this flag to become 'true', and then read the "future time" value. Then, both master and slave should wait for this "future time", and at that exact time continue execution. The result is that both COG's continue with their copy of the TV driver at exactly the same time!

I understand the video hardware supports 96 colors without too much trouble in composite video mode (and a bit more with some trickery), and can generate a 6-bit color RGB signal in VGA mode.

Also, it's a pity the SPIN interpreter can't be re-written to read it's byte data directly from your external memory, that would truly be a great improvement.

P.S.
My Hydra is working fine, and your book is great... I think I am in the market for your memory expansion soon.

Martin (Mahjongg)

Dennis Ferron

mahjongg, having just completed some (unrelated) hacking on the tv.spin driver, I'd like to propose a different solution to using an SRAM card as video buffer. Instead of having two video cogs and trying to synchronize those, still use 2 cogs, but have one video cog and one memory fetch cog. The video cog would have two line-buffers in hub RAM. One line would contain the pixels currently being scanned onto the TV or VGA monitor. The other line would be filled by the memory-fetch cog. Every time the video cog completes a line, it would change over to the line buffer recently filled by the memory fetch cog, and the memory-fetch cog would take the line buffer discarded by the video cog and fill it as fast as it possibly can from the SRAM card. I don't know the exact speed specs on the Hydra SRAM card, but I am 90% certain it'd be fast enough to do this for VGA, and 100% certain it would be fast enough for TV.

I think having a video cog and a memory fetch cog would be easier to synchronize because the tv.spin driver could remain mostly as it is now, and the memory fetch cog would be very simple to implement and would require only h-sync and v-sync messages.

Actually the Spin interpreter COULD be re-written to get it's data out of external memory. If you can write a Propeller emulator (on the PC) that interprets Spin code, then you could also roll your own Spin interpreter Propeller assembly. But I'm sure it's no simple task.

AndreL

If you look at our demos, we use n cogs to fetch memory and fill a raster line then one cog to render the cog, so make sure to take a look at our drivers that already do this massively parallel rendering. And yes, the whole idea of this is to use it as a frame buffer, it can go much faster than the cog can, so the cog will be the bottleneck, not the memory.

And the programming interface is just a couple control lines and a clock line to "do it", 0-64k random access, 64K-512K linear increment/decrement access.

- Load low 8-bits of 19-bit address
- Load high 8-bits, clear upper address lines of 19-bit address
- read mem (optional post increment/decrement), parallel byte read at current address
- write mem (optional post increment/decrement) parallel byte write at current address

Lastly, the spin interpreter is already so tight , nothing more would fit probably, so a better thing would be to KILL a few functions that no one cares about, use the code space to implement external SRAM memory access functions OR use the code space to augment the normal memory addressing, so anything over 32K maps to the external RAM --

Andre'

Jasper_M

So loading a 19-bit address is impossible, meaning that the upper memory can't be accessed randomly? If that part of the memory is used as a frame buffer, that'd mean that the whole frame would have to be re-painted on a VBLANK or alternatively do some very inefficient read-looping to be used to get the pointer where it should be (here the prop counters would be useful to increment the counter as fast as possible)?