Electronic – How to view, debug, or analyze data being input to the FPGA

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:

1. Design entry - in your case, Verilog.
2. Functional simulation - using various tools.
3. Synthesis - in your case, using the Xilinx ISE tools.
4. Simulation - to verify your post-synthesis design because some aspects of Verilog are not synthesisable.
5. Place & Route - using the Xilinx ISE tools.
6. Implementation - downloading the design onto the FPGA.
7. 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.

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.