In something as simple as the code in the article, yes. It's likely that the tool will infer a block RAM as long as there are BRAM resources with the required n

In something as simple as the code in the article, yes. It's likely that the tool will infer a block RAM as long as there are BRAM resources with the required number of ports, etc. It gets a little more unreliable when you start accessing it in more complex ways though. From my understanding (I'm no FPGA expert), the code in the article will infer a BRAM with two read ports and one write port. That may be fine. I actually battled with this recently on a project. I found that the tool was not inferring a block RAM when I expected it to, so I had to modify the Verilog to gate the reads and writes so that only one could happen at a time. That wasn't an issue in my case though. My takeaway from the exercise was that it's sort of the equivalent of relying on the optimizer of a compiler to recognize the programming pattern and do the right thing. After talking to one of the FPGA guys I work with, he seemed to feel that it's better to just instantiate a vendor IP BRAM directly. The downside is portability though.