2010-09-21 20:06:55 Async memory bank access
Ben Burleson (UNITED STATES)
Message: 93713
I've been working with the Bluetechnix CM-BF537E for a while, but we are building new hardware with an FPGA connected to the Address and Data buses coming from the core module. I've seen a few references to this type of functionality in this forum, but I'm having a hard time finding a simple resource that explains the basics of how to do it.
First of all, is the Async Memory Bank the correct way to communicate with the FPGA?
Is this the same as EBIU?
Do I need to change any kernel configs to use this? I currently have all banks enabled and EBIU_AMBCTL set to 0x7BB0 for Banks 0-2 and 0xFFC3 for Bank 3.
From what I've read, it is simple to access the bus from userspace. I just need to be able to read and write 16-bit words to a given address. If you can point me in the right direction, I'd greatly appreciate it!
Thanks,
Ben
QuoteReplyEditDelete
2010-09-21 22:02:58 Re: Async memory bank access
Mike Frysinger (UNITED STATES)
Message: 93714
it depends on what exactly the FPGA is doing. if you're moving a lot of data, it makes more sense to connect to the PPI or SPORT. if you're doing simple register control, then the async bank may work fine.
you can find one example here:
docs.blackfin.uclinux.org/doku.php?id=hw:cards:fpga_kit
QuoteReplyEditDelete
2010-09-22 11:09:11 Re: Async memory bank access
Ben Burleson (UNITED STATES)
Message: 93751
It's more like simple register control. Only reading or writing 16 bits at a time, no mass data transfers.
Thanks for the link,
Ben
QuoteReplyEditDelete
2010-09-22 11:16:24 Re: Async memory bank access
Ben Burleson (UNITED STATES)
Message: 93752
Mike,
Just had a quick read through that link. I'm actually not too concerned with programming the FPGA at this point. We're outsourcing that programming. I am only interested in how I write and read 16-bit words on the memory bus. Is it as simple as specifying an address (that won't clobber the running system or flash) as a pointer and reading/writing to it? I understand there are probably timing issues, but I figure I can sort those out once I understand the basics of how this works.
Is there any example of how I can put an address on the address bus and data on the data bus from userspace?
Thanks,
Ben
QuoteReplyEditDelete
2010-09-22 13:44:05 Re: Async memory bank access
Mike Frysinger (UNITED STATES)
Message: 93765
typically you only get one device per bank, so you wouldnt really be able to collide with other devices
once it is connected to a bank, you just read/write addresses in that bank to access the device in question
QuoteReplyEditDelete
2010-09-22 13:50:28 Re: Async memory bank access
Ben Burleson (UNITED STATES)
Message: 93767
Hi Mike,
Connecting to a bank is what I don't understand. What needs to be configured or set up or initialized to do that?
Is there a reference somewhere that explains this or a good existing example application?
Thanks,
Ben
QuoteReplyEditDelete
2010-09-22 13:59:16 Re: Async memory bank access
Mike Frysinger (UNITED STATES)
Message: 93768
the kernel has a kconfig option for you to specify the EBIU_AMGCTL and EBIU_AMBCTL0/1 registers. otherwise, you simply access the async banks with their hardcoded address ranges.
the HRM documents the MMRs in the EBIU chapter (AMC section) and the memory map in the Memory chapter.
QuoteReplyEditDelete
2010-09-22 15:32:54 Re: Async memory bank access
Wojtek Skulski (UNITED STATES)
Message: 93770
Ben:
I am carefully listening to this discussion because I am now working on the exact same problem. One difference is that my board is already designed and I am working with a prototype. Today I posted a detailed description and the photos. You are invited to have a look: www.skutek.com/VME.htm
Let me say what I know and Mike and Michael can correct my misunderstanding(s).
1. Concerning accessing the FPGA on the asynch memory bus, which I am doing with my design. You need to route the data, address, the controls ARE#, AWE#, AMSx. The AOE# is optional because it is a version of ARE#, but you may want to route it anyway (I did). Byte access ABE is optional, but remember that one of the ABE's may stand for the low address bit in some BF chips (certainly my case). Do not forget the clock SCLK. The memory may be named "asynch" at the BF side, but it is definitely not asynchronous at the FPGA side. Using the clock can hardly be avoided in the FPGA.
The EBIU can be configured in U-Boot, if you want to talk to the FPGA before booting the kernel. There is some example FPGA code in the U-boot tree (I have not explored it yet). After the boot the kernel will setup the banks its own way. There are menu options in the menuconfig. These are pretty self explanatory.
The fun starts after you boot the kernel. One way of talking to the asynch space is using /dev/mem. You need to mmap the /dev/mem and then you can use the memory pointers. There is documentation on this website and even more on the web. I am exploring this topic right now.
Another way may be with User Mode Driver named uio. Again, there is lots of documentation and I am also exploring it.
2. If you have not designed your FPGA board yet, then you may look at light-weight alternatives to asynch memory. If you are accessing just a few registers at low speed, then you can use USART, I2C, or SPI. Concerning SPI, it can be implemented as a simple shift register at the FPGA side. You can shift some address bits and then data. Under SPI the FPGA would be accessed much the same way as most SPI chips (ADCs, DACs, etc). You can then get away by using one of many SPI drivers which Analog Devices have recently developed and released on this website.
Concerning USART or I2C you will need to use Picoblaze at the FPGA side (if your FPGA is Xilinx), or its equivalent in other FPGAs. (There is a Verilog implementation of Picoblaze, named Pacoblaze. In all likelihood runs in all kinds of FPGAs.) Picoblaze is very well supported. You will need to explore the Picoblaze Lounge at the Xilinx website.
The advantage of using SPI, I2C, or USART over asynch memory is fewer data lines, easier PCB routing, and infinitely long distance between the BF and the FPGA. The disadvantage is speed.
3. Concerning the PPI, there is some unfinished code under the "canned applications". I am exploring it now. It is unfinished, but it looks promising.
4. In general, FPGAs are a huge topic of its own which Analog Devices are trying not to get into. A big mistake in my opinion. But I can understand, why. FPGAs are not easy, to say it mildly.
Hope it helps. -- Wojtek