Parameter override when a Verilog module is instantiated inside a VHDL module - vhdl

Our simulator allows VHDL / Verilog mixed and our design uses an IP that written in VHDL (otherwise, our design is mostly in Systemverilog).
We are having problems as parameter overriding is not correctly working and we found the following statements from Simulator's documentation:
"By default, when a Verilog module is instantiated inside a VHDL design unit and default binding is done, VHDL generics are mapped to Verilog parameters using positional mapping."
It is saying that mappings of VHDL generics to Verilog parameters are done using positional mapping, not named mapping. The simulator offers a special option to change the binding rule to "named mapping" and that solved our problem.
My question is which standard specifies the binding rule when it comes to Verilog inside VHDL (or VHDL inside Verilog)?
Or, is this an arbitrary choice the simulator vendor made?

The unfortunate truth is there is no standard for interoperability between standards. Why this is the case may be highly opinionated. But I can say that if more people bring this issue up to their vendors, the more likely it may get addressed.

Related

Conditional use of libraries when simulating VHDL design with ModelSim in Pre-Synthesis / Post-Synthesis

In my VHDL design there is a 16-bits std_logic_vector. The bit in position 15 is currently not used and the synthesizer (SynplifyPro) throws a warning saying that bit is not used and will be pruned:
#W:CL190 : DATAGEN.vhd(93) | Optimizing register bit MYREG(15) to a constant 0. To keep the instance, apply constraint syn_preserve=1 on the instance.
#W:CL260 : DATAGEN.vhd(93) | Pruning register bit 15 of MYREG(15 downto 0). If this is not the intended behavior, drive the input with valid values, or an input from the top level.
As suggested by the synthesizer, I have added the required attribute and I was able to get rid of these warnings. To add these attributes, I had to include the Synplify library:
library synplify;
at the top of the file, and then define the attribute as follows:
ATTRIBUTE SYN_PRESERVE : BOOLEAN;
ATTRIBUTE SYN_PRESERVE OF MYREG : SIGNAL IS TRUE;
If I try to run ModelSim on Post-Synthesis everything is fine. However, when I try to run ModelSim on Pre-synthesis, it gives me the error:
** Error: .../DATAGEN.vhd(20): (vcom-1598) Library "synplify" not found.
I believe that the problem is because Pre-Synthesis simulation is not supposed to use this library. In fact, if I remove this everything works. The reason for which I would like to keep using the Pre-Synthesis simulation is because it is much faster than Post-Synthesis. However, this issue forces me to keep commenting out this lib for Pre-synthesis and putting it back for Post-synthesis?
Is it possible to use something like conditional include?
Note: I prefer to keep the unused bits, therefore adding the attribute for avoid pruning works fine for me.
Is it possible to use something like conditional include?
The upcoming VHDL-2019 standard supports conditional compilation and some simulators, for example RivieraPro, have started to support that. With such support you can do things like
`if INCLUDE_SYNPLIFY = "true" then
library synplify;
`end if
I don't think ModelSim has that yet but what you can do is to just define a synplify library with vlib and include that when calling vsim. If you are using VUnit you can simply add the following to your run script
prj.add_library("synplify")

Show user-defined VHDL attribute during synthesis

I am working on a design (VHDL-2002) where user-defined attributes are attached to different design units. The attribute values may be passed through the design hierarchy.
Is there a (common) way to list the values of these attributes at synthesis time? Something like VHDL's report statement, but to be evaluated during synthesis...
My problem is with regard to design analysis, changes to the code, e.g. switching to generics instead of attributes, are undesired.
At the moment Xilinx XST 14.4 is used for synthesis, but I'm open to alternatives.
I'm asking since XST does report the attribute "Detected unknown constraint/property custom_attr", but unfortunately not its value.

Ruby and SystemVerilog DPI

The DPI functionality in System Verilog always mentions that you can interface it with any language, the most common one being C/C++. I want to interface my system Verilog code with Ruby. Is there any documentation or support for this functionality? Any known way to do this?
I should add that my main goal is to call a ruby script from my system Verilog uvm test.
Thanks
While the standard mentions that the DPI can interface SystemVerilog with any other foreign language, it then chickens out and says:
For now, however, SystemVerilog defines a foreign language layer only
for the C programming language.
This means that you should get DPI-C support in all IEEE 1800 compliant simulators, but any other foreign languages you get depend on your simulator vendor. Mine for example also offers SystemC, but requires that the SystemC code be patched (i.e. it won't work out of the box).
Some guys in my company managed to interface Python with SystemVerilog through the DPI, but they did it via a 2-step approach: Python -> C and C -> SystemVerilog. You would probably need to do something similar.
This is as close as you get to Ruby, but using VPI:
https://github.com/sunaku/ruby-vpi
If you like Python, you can try coco_tb:
http://potentialventures.github.io/cocotb/

Generating Single Port ROM on Spartan 6 using Xilinx ISE Design Suite

I'm having some trouble designing a single port rom onto a spartan 6 board. I use the provided core generator to create block memory and choose single port rom with 32 bit width and 256 depth with a coe file that just counts from 0 to 255. I drop the rom into my vhdl as a component and add the XilinxCoreLib as a library. When I try to generate the programming file I get the translate error:
logical block 'rom1' with type 'rom' could not be
resolved. A pin name misspelling can cause this, a missing edif or ngc file,
case mismatch between the block name and the edif or ngc file name, or the
misspelling of a type name. Symbol 'rom' is not supported in target
'spartan6'.
I'm currently using Xilinx ISE 13.1 if that helps. I feel like this should be really easy to do but I haven't been able to find how to do it.
Edit: Thanks everyone, was a combination of things. Wrong speed grade, and didn't add a copy of the ngc file to my working directory. I'll use arrays in the future.
Easiest way is to forget the vendor tools altogether and simply declare a constant array!
If this is in a package separate from the rest of the design, a few lines of printf's or a simple script can generate the VHDL boilerplate around the contents, which come from your assembler or whatever tool creates the actual data
Since you're adding a Xilinx generated core to your design in ISE, you need to add both the VHD file and the NGC file via "Add Source" via the Project menu.
Even easier, depending on how large your ROM needs to be and what data goes into it, would be to not even bother with a Xilinx core, but to use pure VHDL to declare a constant array and initialization values right in your VHDL file. Here is an example:
type array_ROM is array (0 to NUMBER_OF_ROWS-1) of std_logic_vector (ROM_BITWIDTH-1 downto 0);
signal my_ROM : array_ROM
:=
(
x"12345678",
x"ABCDEF01",
...
x"01010101"
);
Now, you don't put the elipsis (...) in that initialization list, just put rows of constants with bit widths matching ROM_BITWIDTH. The NUMBER_OF_ROWS is the number of address locations you need in the ROM. In this example, ROM_BITWIDTH would have to be set to 32 as I've used 32-bit hexadecimal constants in the initialization list. Being a signal, it's actually modifiable, so if you need it to be constant, just use "constant" instead of signal.
I guess the problem is, as the message says, a misspelling. to get the correct component declaration/instantiation, select your rom.xco in the design-window of ISE. then select "view vhdl instantiation template" from process window. use the component declaration and instantiation described therein.
There are a number of things that can cause this problem, one is that you are using a blocck that was generated for another FPGA family and using it inside the Spartan6. the other is that you may have generated the ROM using an older version of the tool and the wrapper for the ROM has changed since then.
You can either generate a anrray like Brian suggested and forgetting about the tool specific ROM type, or re-generate the IP under your curernt project settings and see how it goes.

Why do I need to redeclare VHDL components before instantiating them in other architectures?

I've been scratching my head since my first VHDL class and decided to post my question here.
Given that I have a declared entity (and also an architecture of it) and want to instantiate it inside another architecture, why is it that I seemingly have to redeclare the "entity" (component) inside this containing architecture before instantiating it?
Isn't the compiler smart enough to match an instantiation to its architecture just by its name? Where is the need for the component declaration?
You can directly instantiate the component, if desired:
MyInstantiatedEntity : entity work.MyEntity_E
generic map (
config => whatever)
port map (
clk => signal1,
clk_vid => signal2,
...
Creating a component declaration gives you the extra ability to change what gets bound to the instantiation via a configuration specification or similar.
Back when I did my VHDL assignments back when I was in school, I was required to have all our code all in one file so I don't remember whether or not you could write one file for each module and how it was done.
That being said, you would have to declare the entity you would use when defining the behavior, if you were using it much in the same way that you would define prototypes, structures, classes and whatnot in C or C++. The difference here is that you don't have the luxury of defining header files for this "redeclaration" in VHDL (at least I don't think there is an equivalent). So it seems perfectly reasonable to me to have to do this. Note that VHDL came out when C was very common and the compilers weren't "smart enough" as they are today.
A VHDL guru might have a definitive answer for this but this is how I understand it.

Resources