Reputation: 222
I'm working with Xilinx ISE on a Spartan-6, which is driving a complex board with multiple functions. As you can imagine the VHDL project is becoming pretty complex and as a C++ programmer I feel the need of using arrays to compact the code.
I've already tried using those in the past but I had many problems. At the time I wasn't very experienced and a lot of other errors where present, which I solved after ditching the array structures. Another problem I encountered was the impossibility to simulate the post-translate (again with arrays), but as I discovered that simulation is bugged because it doesn't initialize the LUTs created.
So here are the questions: what precautions do I have to keep in mind when using arrays? What are the most important design practices with arrays? Will I have problems in simulating sub-modules with the post-map or the post-PAR simulation?
Upvotes: 0
Views: 1934
Reputation: 3388
I use arrays for two things.
First, to make code concise and simple. For example:
signal cnt1 : unsigned(10 downto 0);
signal cnt2 : unsigned(10 downto 0);
...
signal cnt9 : unsigned(10 downto 0);
Can be replaced by:
type cnt_arr_t is array(1 to 9) of unsigned(10 downto 0);
signal cnt : cnt_arr_t;
I never had any "problem" in Xilinx using arrays like this, they behave the same as defining multiples signals, they can be multi-dimensionnal, you can pass them to function, have them on entity ports, etc. The XST user guide specifies that multi-dimensional arrays can't be used as an entity port, but Molten Zilmer uses them without having issues.
The second, more common use of arrays is to define memories (RAM, ROM, dual-port RAM, etc). In that case, you have to be careful how you use the array or the design won't map to memory resources. A 512x32 memory use 1 blockRAM or lots of LUTs/register. Memories are smaller, faster and less power intensive for large depth values.
Look at the XST synthesis guide for how to use array to define memories. As a general rule, your array indices should start at 0 (1 to 2048 is not equivalent to 0 to 2047). Also, multi-dimensionnal arrays do not map to memory resources, at least when I tried it with an older version of XST. Otherwise, arrays of std_logic_vector/unsigned and arrays of records are fine.
You should always look at the synthesis report to make sure XST understand your code as you intend. Every memory mapping is reported with it's mode, depth, width and more. It's the best way to spot misinterpretation errors.
I must admit I never have to do post-map/PAR simulations, so I can't tell you if you will have problems.
Upvotes: 1
Reputation: 15934
Arrays and records, and combinations of these, are one of the great strengths of VHDL, and makes it possible to create functional, readable, scalable and maintainable code. These types have always been in VHDL, and I have not encountered any problems in tools due to these types. VHDL tools are generally so mature that it is in more subtle features that you may encounter bugs.
If you encounter interface changes in post-map/PAR netlist, then I think it should be addresses by a wrapper round the design in order to fit into an existing test bench.
Since the majority of the simulation verification is (should be) made at VHDL level (any post-map/PAR simulation is only for sanity check of STA) it is much more important to have a high level and abstract view of the design during such simulation and debugging, instead of designing at bit level just to make the design match at post-map/PAR simulation.
Upvotes: 1
Reputation: 3655
The only complication that I can see with using an array vs using a "flat" signal by name is related to optimization that happens during the build process and how the names of things can be modified so that they are not easily recognizable. As you may have noticed, this is particularly true for multi-dimensional arrays and it is also true with records. Other than that, if you use a flat structure, or an array, they should implement the same, assuming you are describing the same structure in two different ways.
It may be difficult to determine the "new name" for your array due to the optimizations/renaming that took place, but this should not be confused with different design implementation on the hardware level.
When using arrays the syntax can be particularly troublesome when dealing with initialization. Be sure to consult your synthesis tool reference manual or user guide for support syntax and constructs.
In my opinion, the "cost" of using an array (or record) in terms of additional complication in post-synthesis activities is greatly outweighed by the simplification and clarity that can be gained in the code.
Upvotes: 1