Electronic – Protecting fpga / ram against mistakes

fpga

I'm looking to build a board using a xilinx xc3s50a fpga and using a static ram chip of some kind. Perhaps something such as the GSI Tech GSI71116A.

My worry is about the data lines of the ram chip. If I make a mistake on my verilog I could easily do a read cycle from the chip while outputting data from the fpga. I don't imaging setting a '0' on the fpga and a '1' on the ram chip, or the reverse would end well…

So basically I'm looking for information on what would happen? Is it likely to damage either or both chips or are they protected against this kind of thing by limiting the current? If the answer is no, could I protect myself by adding a small resistor in each data line to limit the current? While that would probably work electrically, I'm not sure what effect that would have once it's working and I need to send data at up to 100Mhz.

So basically, do I need to protect myself here? Can I protect myself? Or do I simply need to be really careful with my verilog code not to enable output on both devices at the same time?

Best Answer

Simply put: Don't make that mistake. Check and double check before trying it. Simulate it too. When analyzing the timing, make sure you look at how long it takes the SRAM to tri-state and un-tri-state the data bus.

You could do something like add resistors, but that has issues as you suspect.

This sort of thing comes up frequently in electronic design, and engineers just deal with it. They try not to make a mistake, but if they do then oh well. If the part got damaged then they fix the bug, replace the part, and move on.

As for what will happen, it all depends. Really, we don't know. The manufacturers don't say what will happen because this is not correct or normal usage. We can guess, but it is only just a guess.

My guess is that it won't work. If the bus contention is only for a clock or two then odds are that it won't be functional, but you won't damage anything either. If you have contention for longer periods of time then you'll run the risk of damaging things. But, as I said, this is just a guess. Reality might be very different.

One thing that your answer brings up, but you didn't specifically ask anything about is your "send data at up to 100 MHz" thing. You do realize that while your SRAM is 10 ns, you will not be able to read or write at a 100 MHz rate? Interfacing to async SRAM at this rate is difficult, and this is why most people use Sync-SRAM for this now.

The exact speed that you will get is going to depend on your application and FPGA clock frequency, but it will certainly be less than 100 MHz. Possibly as slow as 50 MHz. The point is, think this one through before you commit to using this SRAM.

Related Solutions

Electronic – FPGA, first steps

Code Examples

Hop over to OpenCores and you will find dozens of open source projects. There are many written in Verilog and cover the gamut from I/O devices through to processors.

Also, do not forget the many Application Notes available from Xilinx. They are very helpful with their own devices.

Design Flow

Pick up a book or two on design flow so that you get an overview on the steps involved in FPGA design. In summary, they will involve:

Design entry - in your case, Verilog.
Functional simulation - using various tools.
Synthesis - in your case, using the Xilinx ISE tools.
Simulation - to verify your post-synthesis design because some aspects of Verilog are not synthesisable.
Place & Route - using the Xilinx ISE tools.
Implementation - downloading the design onto the FPGA.
Testing.

FPGA Components

As for using the FPGA components, there are different ways to use them. But assuming that you are using a Verilog design entry, you can either infer or instantiate the different components.

Inference generally involves getting the synthesis tool to pick the best components to use based on the functionality that you require. The best example of this would be to design an adder.

By doing q <= a + b or q = a + b you can infer an adder. Both will infer the adder but there is a difference in when you use the blocking/non-blocking syntax.

Instantiation generally involves calling the exact library component in code. Some components just cannot be easily inferred in code - such as the DCM. You can use the ISE tools and examples to learn more about this.

The actual list of components themselves are provided by Xilinx in the Libraries Guide.

Protip

The best way to learn this is actually to experiment with short bits of code and run them through the ISE synthesis to see what it spits out. There are also plenty of examples in the ISE toolset itself.

Electronic – Birectional I/O pin in verilog

Inouts are actually "wire" so you can't use any procedural/sequential assignments (where the left hand side must be a reg). Generally speaking:

input : internally must always be of type net, externally the inputs can be connected to a variable of type reg or net.
output : internally can be of type net or reg, externally the outputs must be connected to a variable of type net.
inout : internally or externally must always be type net, can only be connected to a variable net type.

A common approach is to have an "enable" signal for the output of your inout, and to drive to high impedance if the output is not enabled. In your case direction is playing that role.

So try this instead:

module test(
    input  clk,      // The standard clock
    input  direction,  // Direction of io, 1 = set output, 0 = read input
    input  data_in,    // Data to send out when direction is 1
    output data_out,   // Result of input pin when direction is 0
    inout  io_port     // The i/o port to send data through
    );

    reg a, b;    

    assign io_port  = direction ? a : 1'bz;
    assign data_out = b;

    always @ (posedge clk)
    begin
       b <= io_port;
       a <= data_in;
    end

endmodule

The hardware corresponding to the above code would look something like this:

enter image description here

Best Answer

Related Solutions

Electronic – FPGA, first steps

Electronic – Birectional I/O pin in verilog

Related Topic