I have an existing FPGA design that has a read/write type interface (chip select, R/W, data I/O) and am interested in running it on the XEM3001. Looking at the doc for the FrontPanel, it is not immediately obvious what the best way to do this would be.
I have an address/control register and a data register. The key functionality required is that I write the address/control register to select which register will be read/written the next time that the data space is read/written.
Any thoughts?
As you might expect, there are several ways to implement this depending on the speeds you need to achieve.
The most direct (easiest and lowest speed) would be something like this:
From the PC, a transaction sequence would be something like this (pseudocode):
–Perform a WRITE:
WriteWireIn(ADDRESS)
WriteWireIn(DATAOUT)
UpdateWireIns()
ActivateTriggerIn(PERFORM_WRITE_TRIGGER)
–Perform a READ:
WriteWireIn(ADDRESS)
UpdateWireIns()
ActivateTriggerIn(PERFORM_READ_TRIGGER)
UpdateWireOuts()
datain = GetWireInValue(DATAIN)
This provides a really easy way to do what (I think) you want without using much internal logic. But it is slow due to the many transactions required.
An alternative would be to setup a block RAM with a bunch of data to be read/written with some sort of structure to control a state machine. You could use a PipeIn to load that block RAM with transactions, then use a TriggerIn to start processing those transactions. Then, use a PipeOut to read the results (if any). I’ve used this technique to perform I2C transactions.
I think speed might be a problem with the wire/trigger method. The PIPE method would probably be prefereable, but it doesn’t quite fit what I need to do.
What I’m really looking to do is to use the XEM3001 as an interim prototyping solution while waiting for the physical version of my full blown design to be available.
My design has very similar connections between the Cypress CPU and the FPGA. However, there are two main differences. It doesn’t appear that you have any connections between the RDY1 and CTL2 pins and the FPGA, and my design does have connections for these signals. I know that it will void any warranty, but is there any problem with just jumpering the RDY1/CTL2 pins to some unused FPGA I/O pin?
As nice as the FrontPanel software appears to be, what I will probably end up doing is reprogram the EEPROM with my own code to run the interface the same way that it will be run in my final design. The whole idea here is to have the majority of the firmware for my design tested and working without actually building the initial prototype. Your board is a lot cheaper than an extra PCB spin.
I realize that once I jumper the connections and overwrite the EEPROM I am on my own, but do you forsee any problem with connecting the RDY1 and CTL2 pins to the FPGA? Are these pins really unused?
Hello-
While you are correct that the previous PCB (v1) did not have connections for RDY1 and CTL2, the new revision does. (anything purchased in the store now is the new revision)
There is no problem replacing the EEPROM firmware with your own, but yes, you are on your own at that point.
How does your firmware handle the type of communication protocol that you’re looking for? We certainly don’t intend our software/firmware to be the end-all-be-all of FPGA interfaces, but it does provide a good start for many folks. I’m always interested in hearing of any features that could enhance the design.
Jake
The interface that we have uses the extra CTL line to select between a control register space that is like an I/O space and a high speed data register space that is burst oriented. The high speed interface runs like your pipes, but has the ability to run at a single tranfer per clock. It does not have to deal with multiplexing several things over the same bus like your software does, so it is able to dedicate all of the bandwidth to a single stream. Not as versatile as your interface, but when all you need is a single pipe in and out, it can be faster.
Are there particular FPGA pins that RDY1 and CTL2 should be jumpered in order to be compatible with the current rev board, or are there more significant changes in addition to RDY/CTL (like 16 bit data perhaps?).