2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ About 10 years ago I did an educational FPGA board, which had resistors in the lines. It worked at 20MHz. You might be able to get 100MHz ... \$\endgroup\$ – pjc50 Mar 6 '12 at 14:04
  • \$\begingroup\$ Thanks for the feedback. I think I'll just "be careful". \$\endgroup\$ – John Burton Mar 6 '12 at 15:41
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thank you for this, that's answered a lot of my questions and is very helpful. And yes I do understand the difficulties in getting the ram to work at that speed. It was more that I need to hold the data for at least 10ns for the ram to recognise it, not that I expect to be able to do this every 10ns. I simplified that down to saying 100Mhz as it wasn't really the point of my question. \$\endgroup\$ – John Burton Mar 2 '12 at 22:08
  • \$\begingroup\$ I suppose this is actually reasonably easy to simulate fully anyway. I think being a software programmer first, makes it difficult to think in the right way for this kind of thing, as it's _just_close enough to writing code that you bring along all kinds of wrong assumptions about what are reasonable development processes without it even occuring to you they might be wrong. Simulation and "being careful" is so much more important here :) \$\endgroup\$ – John Burton Mar 2 '12 at 22:13
  • 2
    \$\begingroup\$ @JohnBurton On the plus side, being a SW guy you have skills in managing and organizing large chunks of code that the typical HW guy just doesn't have. So don't sell yourself short just yet. :) \$\endgroup\$ – user3624 Mar 2 '12 at 22:18
  • \$\begingroup\$ Yeah no reason why you can't do both - it just takes a bit of a shift switching from c++ to verilog, and a black box computer to pins and wires and voltages :) \$\endgroup\$ – John Burton Mar 2 '12 at 22:26
  • \$\begingroup\$ @DavidKessner: I've never used synchronous SRAM, but when you say a 10ns SRAM cannot supply data at 100MHz, are you simply saying that the timing budget needs to include timing differences between then the address out from the processor (or device communicating with the memory) becomes available to the RAM, and when the processor samples the previous byte data returned? Can a synchronous SRAM perform a single random access faster than an async one, or are they only useful in pipelined situations? \$\endgroup\$ – supercat Mar 5 '12 at 16:39
1
\$\begingroup\$

As David says, be careful.

But in my experience, the IO drivers in RAM and FPGA devices are tough enough to fight with each other for plenty of lab time while the debugging is going on. Just don't think it'll work long term in a product (you'll never pass an EMC emissions test with that sort of fight going on anyway!)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.