1. Home
  2. Field-Programmable Gate Arrays
  3. Help with bidirectional interface of a FPGA with a uC

Help with bidirectional interface of a FPGA with a uC

Hi need to implement a bidirectional 8 bit interface of a FPGA with a microcontroller. For now i am developing with a Ciclone II but i will have to make it for a Spartan-3A too.

Inside the FPGA i have 2 fifos one that will hold the data that i will wire to the uC and on the other i have to put the data that the uC sends to FPGA. The communication is controlled by the uC, so there will be a we pin to set the pins direction.. a 8 bit birectional data bus, a data_rdy pin to tell uC that there is data availabe on the FIFO, and a "clk" pin. I mean clock becouse it wont be a continuously clock. Just something like on every posedge the data will be sampled on FPGA (if we is asserted) or the FPGA will change the the output (if we is not asserted). On the FPGA there will be a 50Mhz clock. I am implementing both fifos using altera megafuntion (and probably the same will be done with Xilinx FPGA). I have a few questions. First will this code works to control the port direction? Or it should be clocked?

module bidir_port ( out_en, data_in, data_out, port );

input out_en; input [7:0] data_in; output [7:0] data_out; inout [7:0] port;

assign port = out_en ? data_out : 8'bz; assign data_in = port;

endmodule;

Second, i have two options to create this communication. First, to use the communication control pin to clock the FIFOs, but i dont know if need to use a constiguously clock on FIFOs ... The other option would be to synchronize all the signals to FPGA 50Mhz, and create a pulse on the wt_en and rd_en port of fifos on every edge of the uC ctrol pin.

Will both work? Anything i should pay attention?

Thank you!!

Reply to
Sink0
Loading thread data ...

The code snippet you posted, it has some errors. Have you tried synthesizing it? You already have a bidirectional port for communication between uC and FPGA so you don't need to declare data_in and data_out as in/out . Declare them as simple wires and use them wherever you want to use them.

Secondly, if i were you, i'd prefer to sync all the signals to FPGA's 50Mhz clock and create a pule on wr_en / rd_en signals.

Btw, you will write data to uC when rd_en will be asserted, right ? In that case, your tri-state condition will be

assign port = rd_en ? data_port : 8'hzz;

--------------------------------------- Posted through

formatting link

Reply to
salimbaba

o

hz

at

Hahaha, about the in and out signals.. thats just the signals inside the FPGA becouse i was creating a generic module for a bidirectional port, it is a waste of lines, but would be easier to change .... anyway, just to know, why do you say that to sync the signal is better? Will i have any problem to clock a DPRAM with a non-contiguous signal?

Thank you!

Reply to
Sink0

If you do that, then you'll (most likely) write out multiple bytes on a read from your device, and read in multiple identical bytes from a write to your device.

You want to detect the rising edge of the write enable and pop _one_ byte from your FPGA's outward-bound FIFO. Similarly, you want to detect the rising edge of your read enable and push _one_ byte into your inward-bound FIFO.

If you can meet the microprocessor's setup and hold time while clocking the port from your FPGA clock, then that's the way to go. Synchronous is nearly always better than asynchronous -- to the point where, if you have to ask, you should assume that it should be synchronous.

If you are using a memory port on the microprocessor, then there will be a timing diagram in the microprocessor data sheet that details its operation. Take that timing diagram and copy it out, then finish it with the pertinent internal signals of the FPGA. Calculate where all the edges may land (remember that if you're clocking the port from a

50MHz clock that's asynchronous to the micro that you have to treat the FPGA clock edges as being uncertain to +/- 10us).

If you are bit-banging the exchange, and you have the pins available, then the timing diagram is your responsibility -- but you should still draw it out; in particular you should make sure that the read and write pulses out of the micro are long enough that the FPGA reliably catches the edges.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

If i would be restricted to a memory interface the problem would have a direct solution.. but as the uC is not fixed i cannot ensure the existence of a memory interface. I did try to create a bit-banged the communtication (i did run a test on a PIC32 that i had here on my hand, but i am expecting to use some Texas DSC on the final version to run the tests) but i could not get a real good communication speed, nothing close to the 40Mbps of the SPI, so created a simple SPI interface on the FPGA and it is working quite well. Thank you for the help.

--------------------------------------- Posted through

formatting link

Reply to
Sink0

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.