Electrical – FPGA Simple RAM Model – Why is the address delayed

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.

It has to do with what can be easily evaluated at elaboration time, formally, what is called a "locally static expression". This is an obscure looking rule, but it deserves some thought - eventually it does make some sense, and your simulator is quite correct in alerting you by generating non-obvious results.

Now, temp(1) can be evaluated at compile time (even earlier than elaboration time) and it can generate a driver on bit 1 of "temp".

However, temp(i) involves a bit more work for the tools. Given the trivial nature of the loop bounds here ( 1 to 4 ) it is obvious to us humans that temp(0) cannot be driven and what you are doing is safe. But imagine the bounds were functions lower(foo) to upper(bar) in a package declared somewhere else... now the most you can say with certainty is that temp is driven - so the "locally static" expression is temp.

And that means that the process is constrained by these rules to drive all of temp, at which point you have multiple drivers on temp(0) - the process driving (no initial value, i.e. 'u') and the external temp(0) <= '0';. So naturally the two drivers resolve to 'U'.

The alternative would be a "hacky little rule" (opinion) that if the loop bounds were constants, do one thing, but if they were declared as something else, do something else, and so on ... the more such oddball little rules there are, the more complex the language becomes... in my opinion, not a better solution.