05-10-2021 10:02 AM
I get (a lot) of messages :
" conflicting RAM Tu[pes(3D/Records) detected"
without further reference or description.
Any ideas what this could mean or how to get more verbosity?
05-10-2021 10:48 AM - edited 05-10-2021 10:51 AM
>>Does it give any context- like the file?
the message that I copied (but I can see what submodule/file is causing it, but there are multiple inferred memories)
05-10-2021 02:23 PM
(Up front - I'm a verilog user, but I think this applies for VHDL too).
Synthesis tools (and even tutorials for Simulation), since the early days, always thought of using 2-D arrays as solely for the purpose of modeling memories. So the first time the FPGA synthesis vendors started inferring RAMS, it started with just looking for 2-D arrays.
However, this is a rather limited use case for multi-dimensional variables. For me at least, I use multi-dimensional arrays for purposes other than modeling memories for the majority of my RTL code. But the current heuristics for the tools use to "look" for inferred memories start with the simple "is it a 2-d (or higher) array." Then attaches more qualifications. So I see all sorts of warnings from the tools about multi-dimensional arrays not matching a memory template. Which is true - I'm not modeling a memory! So, more warnings from the tool for me to ignore...
Not sure if the OP case matches mine, but it's a possible use case.
05-10-2021 09:59 PM
Could you please share the runme.log ( project mode ) / vivado.log ( non-project mode ) file which captures these messages?
Also, could you provide a simple test case for reproducing the messages at our end.
05-11-2021 01:23 AM
I agree with you, and thought not as good as you , I'm you opposite, VHDL, and a bit of verilog when i "have to go that route "
This is likely to be history,,,,
The tools are VERY slow to evolve,
not least this I think is because they came out of Millitary work, who never want to change if an out of date / old / technique is around, no matter how much "better" the new is .
yes @markcurry, System Verilog
the languages were designed to allow defining modules accurately , and simulate them.
it was only much later that people made tools that converted the language into real silicon..
In the real digital world, everything is a pin, and inherently a vector,
It was only much later still that the tools could "infer" a two dimensional array , if "you were very explicit" in how you coded it.
Multi dimensional arrays, just don't map into silicon, they are more abstract,
and at its heart RTL is describing silicon ( well hardware anyway )
so after all this ramble,
what I'm getting at, is the tools are lagging,
They are millions of times better than they were in 1980 when I started,
but humans can still make code that the tools will hick up on
so don't be surprised that your more clever than the tools,
Suggest that you try a few simple examples of multidimensional to see what is and is not possible
05-11-2021 05:24 AM - edited 05-11-2021 05:24 AM
I think we're mostly agreeing, however I disagree with this statement:
> Multi dimensional arrays, just don't map into silicon, they are more abstract, and at its heart RTL is describing silicon
Multi-dimensional arrays map to silicon just as easily as single dimensional vectors. Arrays (of any number of dimensions) are just a convenience for the human reader to map algorithms. I have 48 wires - these could be any of (SystemVerilog style):
All this maps quite fine to hardware. The indexing of the various arrays is a convenience for the human reader. To the machine it's just 48 wires. It's the same thing in any computer language really. Create a computer language. Before long someone's asking for arrays. Very quickly after, one's asking for multi-dimensional arrays. I'd bet a good portion of software language questions on stackoverflow are "how does one create multi-dimensional arrays in language XXX".
05-11-2021 07:46 AM
I think I did not explain myself @markcurry
by saying silicon is not multi dimensional,
I was referring to the silicon being laid out X / Y
So for instance a two by two byte "array" is conceptualy , "just" laid out on the silicon,
and that show the tools were designed,
As you say, now days , things are much more software like , dimensions are "infinate"
records are standard, with multipe size objects in them,
My point was the tools initial were not,
and humans have infinite ways of creating code,
and the poor tools have to decode that to a two dimensional silicon slice,
( OK there is stacked silicon, but thats another story )
I just keep in mind the job the tools do, and sometimes check just what they are chucking out when I get "creative" cause its easier for me.
05-16-2021 11:43 PM
The UG901 has a few example codes for RAMs using 3D Array:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug901-vivado-synthesis.pdf (page 158)
Please check the sample codes or share your RTL file for us to understand the issue.
05-17-2021 01:00 PM - edited 05-17-2021 01:00 PM
the problem occurs with a quite complex design that I needed to trim down before sharing.
Having done that, it seems the arrays that I intended to be mapped on RAMs are still mapped to RAMs;
The warning "conflicting RAM Types(3D/Records) detected" is apparently triggered by something else in the code that I had no intention to be a memory in the first place (actually I don't know how it could be"
Too bad that the tool doesn't give any more information (like what signal it is referring too).
So the warning is useless, but trying to find what is causing it would take too much effort.
This issue can be closed.
05-17-2021 10:55 PM
05-18-2021 03:09 AM
I feel the pain tryign to locate a feature in a large lump of code,
more than once I have ended up commenting out lumps of code to see when the feature disappears.
There must be abetter way ,
I Know, Xilinx will suggest writing in HLS ,,,,