MP dual port nenory idea

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Everyone. I've been a long time absent due to illness and even now have to use 2 monitors to be able to use my Personal Confusor.

Anyway... With assistanve I have contined to design electronic products and am currently working on a dual ATMEGA2560 MP design. I had an udea about optimizing performance: using dual port RAN in eternal memory space of both processors to allow highet speed inter-procssor communications.

Of course the big lmitartion is tht these processors do not have an external bus cycle wait state mechanism. Hence I may have to resott to co-operative resource-sharing of thid mrmory, which is a shame becwuse ots less than ideal performance.

Another idea is to use clock-strtching to add wait states into rcternal bus acssses. Hoever that probablu only would work if the procssor is fully-static in operation.

I have yet to find any information on bus cycle manipulation using the external clock, so this idea remains theoretical.

Can anyone shad some light?

Thanks,
DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really my bag, but you might noodle with using FIFO chips (one each way) and a few control lines--you burn a lot of pins with the external memory interface, anyway.

I'm always curious as to the justification of MP with AVRs, especially when right next to each other. There is another current thread relating to video generation and syncing the clocks--that thread touted the low cost of using a couple AVRs.

More pins needed? Extend the I/O with serial chips instead to avoid the complexity of MP design. More "horsepower"? e.g., "co-processor"? Maybe a different chip like AVR32 or SAM7. Or the Xmega. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danafraymond wrote:
Of course the big limitation is that these processors do not have an external bus cycle wait state mechanism. Hence I may have to resort to co-operative resource-sharing of this memory, which is a shame because its less than ideal performance.
I'm a little confused -- do you mean that there is not a mechanism to apply wait states between address and the read/write strobe, or or you saying there is not a mechanism for the external buss to tell the processor to wait? The first is not true, while the second *is* true. I assume you want the external buss to apply a forced wait to hold off the reading processor while the writing processor finishes.

How about using the SPI mechanism to talk between the two processors? The clock rate can get pretty high (upwards of 1/2 of the CPU clock), with the advantage that you can use the SPI interrupt as a "mail arrived" flag. Granted, data would come one byte at a time and the interrupt would need to queue data in and out.

danafraymond wrote:
Another idea is to use clock-stretching to add wait states into external bus accesses. However that probably only would work if the processor is fully-static in operation.
I would avoid this like the plague. Although I expect you would be able to get it to work, I suspect there's all sorts of things inside the processor that would get upset if you played this game.

Even worse, I bet the beta units work fine, but you'll constantly have problems with 1 out of 17 units in the field doing mysterious things that can never be replicated in the lab. And they always do it at 3:17 AM, on Saturday morning. GMT. Why it doesn't happen at 3:16 AM or on Fridays will keep you up nights for weeks on end.

At the very minimum, work out a signal between the two processors; some kind of two (four?) signal handshake that allows only one or the other processor access to the memory.

Or buy a dual port memory and be done with it.

---

One other possibility comes to mind. If you don't really need the external memory for any other purpose, why not repurpose the external memory address lines and the Read/write signals to a parallel port between the two processors? PORTA could drive data out, PORTC could read data in, you could continue to use PORTG0 as the "I'm writing" signal, but use one of the external interrupt pins to clock read data in. Down side to this is that I think your throughput would actually be higher with SPI once the interrupt latency is taken into account.

---

Good problem! I would probably go with either the SPI or the handshake-with-external-memory approach, but would probably spend a little while looking at the PORTA/PORTC approach, just to cover the bases.

As I said above, I'd stay away from clock stretching. Along that way lies madness.

Best of luck, and welcome back!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies Guys!

Unfortunately, there isn't enough slack in the schedukle to expeiment. :(

I've settled for using dual-port ram in a Spartan-II and a co-operative time-sharing scheme.

I am intrigued with the idea of AVR MP... Can you imagine wht kind of computing power oukd be available for so little money?

OK, back to work for me! :)

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Unfortunately, there isn't enough slack in the schedukle to expeiment. :(

Well-defined prototyping should be part of a project like this. I would suggest that you don't have time not to i.e. if you get it wrong you will pay by having a much longer schedule for test and debugging. Worse you may reach the conclusion that a redesign is needed. Much better to resolve these design issues now.

Another way to say the same thing: if you get your design right, the code just falls out. You may well spend 75% spend of your time on design but coding and debugging will be trivial.

BTW Please check your spelling. Carelessness in posting appends like the ones above doesn't help your case in looking for a job. This kind of thing puts people off very quickly.

--Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your thoughts Mike... I appologize for the spelling errors. The fact is I am now legally blind and am doig my best withe the computer equipment given.

again, thanks.
DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mike wrote

Quote:
BTW Please check your spelling. Carelessness in posting appends like the ones above doesn't help your case in looking for a job. This kind of thing puts people off very quickly.

BTW.. if this bugs you...you are in for a rough ride...there is a bunch of people who can not spell worth a damn on here, some who post the most!....hope you enjoy the forum in spite of the spelling!

and DFR..glad to see you are continuing to do what you enjoy doing in spite of the difficulties... :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In DFR's defense, I believe the issues with spelling are not spelling in fact but simple typing issues. Still totally understandable. And with the occasional non-native english speakers/writers that post in the forums, you have to get used to the interpretation, to get the real text..now if we could get rid of the people who abbreviate everything to save space...U instead of You, L8 instead of late...you get the picture.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danafraymond wrote:
Thanks for your thoughts Mike... I appologize for the spelling errors. The fact is I am now legally blind and am doig my best withe the computer equipment given.
I wasn't aware of your difficulties. There are some good screen readers out there that may help and there are other tools like word processors that automatically complete words or at least spell check. You could cut and paste from there into your append. A simple proof read can trap simple errors too.

To the other people who commented on this. I have seen a lot of poor spelling in posts from both native and non-native speakers and that doesn't bother me. However most of these people do not say they are looking for a job. First impressions count and that was the helpful advice I was trying to impart to DFR.

--Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

while I kmew of my typing ettots, as evdenced by net name errors in orcad, Mike's commemnts spotlighted them clearly. Iwill mae sure to use spell-checking for official communications to outside parties.

I expect to improve accyracy over time.

Thanks to evryone for the time nd attentio given to this thread.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Best of luck in your recovery Dan. Most of your errors are one-off errors in your typing, where you're hitting the key just to the left, or the right (looks to be predominantly to the left), of the desired one. It's a little harder to read, sometimes, than bad English, but we will do our best to follow along. I suggest getting into the practice of going back and reading what you have typed, before hitting submit or send (we all should do that... I often forget, leaving hideous typing errors) I'm in the process of trying to get my father to do the same, who is having difficulties as a result of a stroke.

For a web-browser I suggest grabbing Firefox (2.x), as it will highlight your typing errors as you go.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think this thread clearly shows that AVR FREAKS is a fine community of good people. I am glad to be nack here (and back in the land of the living as well :) )

This message previewd before submitted.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the possible problems with clock stretching is the internal pipeline. While it appears to be static, I have seen warnings from Atmel about large variations in the clock cycle length (maybe above 20% between successive cycles ?????); what ever it is, it does not give much room to wiggle.

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the possible problems with clock stretching is the internal pipeline. While it appears to be static, I have seen warnings from Atmel about large variations in the clock cycle length (maybe above 20% between successive cycles ?????); what ever it is, it does not give much room to wiggle.

GOOD pOINT JIM.
DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've settled on using FIFOs for inter-processor communications. A Spartan-II XC2S50 FPGA will provide up to 4 bi-directional FIFO channels. XILINX APP175 assists with constructing the FIFOs in Verilog and VHDL.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danafraymond wrote:
I've settled on using FIFOs for inter-processor communications. A Spartan-II XC2S50 FPGA will provide up to 4 bi-directional FIFO channels. XILINX APP175 assists with constructing the FIFOs in Verilog and VHDL
Very cool! How deep do your FIFOs need to be? I'm just curious. I keep think about learning about FPGAs but just never seem to find the time.

I'm also interested in whether you are a Verilog or VHDL guy. I don't want to start a religious war; I used Verilog in a previous life and was curious about what you were comfortable with.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The FIFO depth will be 511 bytes per direction for each channel. Actual message size is much smaller. Essentially the 2nd proessor handles communications, along with some high level functionality. pio semaphores will be used to allow for polled or interrupt driven operation at each end.

Yes, using an FPGA is fun, its been quite a while since I've done a synchronous design.

I am using Xilinx's ISE, and would reccomend it.

Verilog is what I use but I am a little rusty.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oF COURSE, i'VE NOW STUMBLED OVER THE note above Figue 16 in the aymega2560 datasheet that states that the xmem interface is asynchronous and is not suitable for synchronous design. Now I know this is due to internal skew between thr oscillator and intenal CLK signals and that the xmem bus waveforms are actually synchronous to the CLK.

Unfortunately my FIFOs are synchronous and I am working on a product-term clock approach to make this work.

Doe anyone have any experience with this? I am using XTAL2 as the FPGA clock source(yes, CLKO would have been better. hindsight is always 20/20).

well... It wouldn't be impressive if just anyone could do it with ease.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can tell the AVR to put wait states after changing addresses and/or before a read or write. I suppose you could use that to make the FIFO "look" like an asynchronous part even though it is synchronous.

That's the only idea I have off the top of my head, but I admit it's probably not a good one. Anyone else?

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes... I thought of tat as well, but decided it maybe unreliable. checking a semaphore and deciding to use an address with different timing, etc.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a note to anyone following his thread...

This project is complete. The AX9000 board is a dual ATMega2560 platform with 1MB NVSRAM each, 4 RS232 ports, 10base-T Ethernet option, SD card, 2-32MB Dataflash, and 4 channel interprocessor communications with 128B message boxes. 8 DI and 4 DO are also provided.
Its an embedded syetems platform not a development kit.

Interprocessor communication and 3V3 sram interfacing is aomplished with an Xilinx XC2S50 Spartan-II FPGA.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am posting this for those who may be following this thread...

This design was completed. The AX9000 board is a dual ATMEGA2560 platform that inludes 1MB of NVSRAM per MPU, 2-32MB of Dataflash, a SD card slot, FTDI USB serial port, 4 RS232 serial ports, 8DIs and 4DOs, and an optional 10base-T ethernet module. Another optional module provides USB Host capability as well as FAT file system for SD/USB Keyfob.

DFR

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the du[licate. it seems that if I delete one of them they both disappear.

DFR