NetBurner Community Forum

I have just done the "Getting started guide to NB Eclipse" and got my dev kit running demos (Trying NB for the first time having used Rabbit & PIC's on previous projects). I need to prototype hooking the MOD5270 upto a CY7C009V dual port ram (128k x 8bit).

From my cursory review of various doc's it all seems a bit more complicated than just hooking up say a Z80 to an SRAM. ie there are few unfamiliar signals such as /BS /TA /TIP /TS Since my SRAM does not have any transfer start, acknowledge type pins is there a way to ignore these ? Does any one have a schematic showing how to interface a simple SRAM to the external bus ? A code snippet on how to initialise and access the SRAM would be very useful also

Since the SRAM will be the only device on the external bus I think I can avoid needing to use buffers on the address/data lines.

Also if I am using the D16-23 for an external 8bit bus can I still use D0-15 as GPIO ?

FYI : The other port of the DP SRAM is connect to a Xilinx CPLD which drives about 4k of RGB Leds in a display matrix. ie I am trying to add a low res colour display to the 5270.

Why do you need the dual ported RAM? Just connect the CPLD directly to the ColdFire's external bus.

The LED drivers I am using require a clocked data stream at about 30Mhz and since I have 4,160 RGB leds which need which each need 36 bits of intesity data at 50 frames per second the CPLD is pretty busy nocking out 7.488 Mbps .

So that this data rate demand does not fall on the shoulders of the uP I am using the DP SRAM to decouple the display driving aspect from my application . This pretty much is how CRT display interfaces used to be (and probably still are). ie All the application has to do is draw its frame image into memory (DP SRAM) and the CPLD on the otherside of the DP SRAM will just get on and display the image.

All I want is bit of help to figure out the correct way to get the MOD5270 to interface to 128k of 8bit static ram. I am sure this must be a fairly basic use of the external bus.

Interesting first NB project....

1. you can use D0-15 as GPIO when you are using either byte or word external access.
2. remember that D24-31 are byte access and D16-31 are used for WORD
3. all you need to rattle with your stuff are A1-Ax, R/W, Data lines, CS1, and or CS2.
4. I would add a 16245 for your external stuff no matter what if I was you. Always buffer it...

Chris

What happens with these TA, TIP and TS signals ? Will my read/write external bus acceses hang if I leave them unconnected ? Is there some 'C' lib function that will setup the external bus config ?

I note that the address/data bus is only specified with enough umph to drive one load, so does it realy matter if the one load is an SRAM or a buffer ?

Neil

Neil

I would lightly ignore TA, TIP and TS.
I have in a number of my 5270 hardware projects.
If the only data bus load is a CPLD and all of the other stuff you are talking about is all driven from the CPLD then you can certainly ignore putting in a buffer. I personally always put in a buffer if for no other reason than to be able to stop my peripherals from driving the data bus (by lifting an IC leg or cutting a trace) if I can't figure out why the processor won't start, is bus faulting, etc.

**fear and paranoia are the hallmarks of a good hardware designer.

NB has an excellent example of how to setup 5270 external access.

By not using TA, TIP, etc. you are accepting the wait states control function for your external accesses. If you want absolute maximum throughput between your peripherals and the 5270 you need to use those signals...

Chris

I did a similar project several years ago. I used a MOD5270 with a Xilinx FPGA. The FPGA provided double buffering for 768 LEDs organized as a 16 x 16 pixel matrix (a Red, Green and Blue LED per pixel). The "module" was 16" x 16" and was combined with hundreds of additional modules to form a large electronic LED billboard. The modules received data via UDP from a PC that provided the video data. The system was capable of be driven at about 70 fps. Each LED was driven directly by a 12 bit PWM by the FPGA. LED drivers were used, but they only provided on/off capability hence the FPGA did the PWM (this was LONG before LED drivers supported driving LEDs at a specified intensity). The FPGA was connected directly to the external bus and looked like memory. The ColdFire simply wrote the 12 bit intensity values to the inactive buffer in the FPGA and then switched buffers when all the values had been updated. I used the dual ported block RAM on the FPGA for storing the LED values. One port of the block RAM was written to by the ColdFire, the second port was read by the FPGA logic which drove the 12 bit PWM for each LED.

Couple of questions and comments:

1) 4,160 RGB LEDs seems like an awful lot of LEDs to be driving with a CPLD. Is that actually the correct number?

2) Is the CPLD merely an interface between the stored data that you would be putting in RAM and your LED drivers?

3) Whose LED drivers are you using?

4) 4,160 36 bit values at 50 fps is an awful lot of data. Assuming 3 16 bit writes to get your 36 bits to the CPLD, that would equate to 624,000 16 bit writes per second.

bb

Yes the design uses 130 circuit boards each with 32 RGB Leds each. The LED circuit boards all "tile" together to create a panel the size of a wide door. Each circuit board uses the two MAX6974 driver chips for multiplex control of 32 RGB leds. The 130 LED boards cacade the LVDS data single down the chain from board 1 to board 130. The boards are all power by 5 120w 5v PSU distributed around the edge of the panel.

The idea is to have the Mod5270 write the display images into one port of the DP SRAM and the CPLD will read out the data through the other port and essential act like a UART and put the serialised data out at 30Mhz to the string of 260 LED drivers chips. It does this over and over so as to get the frame rate required. While the CPLD is running the Mod5270 can write the next display frame into another display frame in the DP SRAM. Once written it just changes a pointer at the base of memory that the CPLD is checking every frame to the new display frame.

I have a PIC 18F and CPLD based prototype running just 256 LED's on 8 circuit boards. Although the CPLD is running at the full required clock data rate it is only accessing conventional single port SRAM on the same bus as the PIC. ie the the PIC has to stop the CPLD running too tri-state its bus, then it writes its data into the SRAM, and then it gets off the bus and starts the CPLD to run again until the PIC needs to update the next display frame. This kind of works but the frame rate is to slow.

Are there any functions in NB to setup the use of the external bus ?

The following sets up the Chip Select Interface...

#define FPGA_BASE_ADDRESS (0x20010000)
#define CSCR_INIT 0x4981 // 16 bit transfers, AA, 2 IW, 1 SW, 1 SR

// setup CS1 for FPGA access
sim.cs[1].csar = (FPGA_BASE_ADDRESS >> 16);
sim.cs[1].cscr = CSCR_INIT;
sim.cs[1].csmr = 0x00000001;

This setus up the chip select interface for 16 bit transfers with the interface beginning at 0x2001000. The wait states were appropriate for the FPGA being used. Now you just read/write to an address within your chip select range.

bb

Sorry... couple of typos....


Address is 0x20010000.

bb