I am getting a warning on 18 and 36 bit wide block rams inferred in my Verilog code in ISE 9.1. The following code is an example of what causes the warning. I do not get warnings on 16 or 32 bit wide blockrams inferred this way. The resulting block rams do not work properly when loaded into an FPGA.
I've seen this harmless warning for way too long though I often get it for instantiated BlockRAMs where I don't actually read the parity bits but I write them with zero values so the port isn't undefined.
It's possible the complaint is because the write port is written with parity bits but the write port output parity bits are unused. Who cares?
I'd suggest you take a look at the FPGA Editor (or some other technology view) to see if all your pins are hooked up properly. If your design truly does not work - as opposed to being a coding/debug problem which it often is for my development - then there is something wrong with the synthesis which has to be addressed by the vendor. I often infer memories with SynplifyPro but haven't used XST for any development.
I'd love to see the warning actually mean something but I've lost any confidence that it's communicating anything real because of my past experience with it.
Because it's an extremely poor warning. It takes one programmer a few minutes to produce something nonsensical that doesn't get changed through peer review processes but it takes months and a lot of pain for something to come out of software. The right thing is to be consistent. It takes one person too little effort to produce inconsistent messages.
I tend to skip the post-translate simulation in favor of live testing except for special cases. The FPGA tools have done a superb job historically of producing a target FPGA design that matches the original RTL. While the ASIC industry needs a significant investment in equivalence checking to make sure the output from a tool matches the input, I've only come across one or two instances over the years where the final result isn't a 100% match to the input code.
It's possible a tool problem is in the way of a good simulation. I'd do a quick check to see if the "post-translate" results are producing misconnected hardware or if it looks like the right 18 bits are connected to the right 18 lines in and out of the BlockRAM. If the physical connections aren't there, it's probably a synthesis problem. If the physical connections are there and the warning is its usual bogus self, a mismatch between RTL and "post-translate" simulation would tend to point to the simulation models.
If the problem doesn't appear with 16 and 32-bit memories, the troubles probably aren't with simultaneous read/write operation coming up different in different simulations but this failure mode would be something else I'd look for in bad memory simulations if I didn't have the additional good-inference information.
Thanks to everyone for the help. I did take a look with FPGA Editor and everything is getting connected correctly. It appears that it is just yet another spurious warning as some of you suggested. I had the input signal connected to a scrambled version in another clock domain of the intended signal connected to the DDC input, causing output to be seemingly random.
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.