Cocotb using generics/parameters in gate level simulation

Question

I have successfully setup a Cocotb verification environment for my design, and I am happy the way it works for RTL (VHDL in my case).

My design is using generics, and I am retrieving the value of these generics in several places of the python code (mostly in the run_test and in the model), following the template:
my_generic = dut.GEN_NAME.value

Unfortunately, this is not working in the case of gate level simulation, since my synthesized design does not have generics anymore, and therefore dut.GEN_NAME.value does not exist.

Should I move all in the direction of getting the parameters/generics values from the simulation flow (makefile of Cocotb) ?

If so, what is the cleanest way to do so? Using env variable?

(Btw, I use Questa, even if I don't expect this aspect to be simulator dependent...)

Thanks for your help and your advices...

It is often the case that the output of the synthesiser doesn't quite look like the RTL. The classic way round is to use a wrapper: instantiate your gate-level model in a dummy layer of hierarchy, whose interface (entity in your VHDL case) looks like the original RTL. — Matthew Taylor, Dec 07 '16 at 10:53

score 2 · Accepted Answer · answered Dec 07 '16 at 14:59

2

Passing the configuration to the Python Cocotb code might be possible, but it is error prone because you have to ensure that the same values are passed which have been used for synthesis.

Another solution is to have a configuration package for the top-level entity stored in a separate file, e.g., top_config.vhdl with content:

library ieee;
use ieee.std_logic_1164.all;

package top_config is

  constant AA : positive := 5;
  constant BB : integer := 10;

end package top_config;

The constants defined here, are then used as the default values for the generics of the top-level entity or directly within the top-level entity.

The package can be parsed now via some Python code within the Cocotb testbench:

from re import compile as re_compile

constantRegExpStr  = r"^\s*constant\s*"   # keyword and spaces
constantRegExpStr += r"(?P<name>\w+)"     # name fo constant
constantRegExpStr += r"\s*:\s*"           # divider and spaces
constantRegExpStr += r"(?P<type>\w+)"     # type name
constantRegExpStr += r"\s*:=\s*"          # assignment and spaces
constantRegExpStr += r"(?P<value>[0-9]+)" # value
constantRegExpStr += r"\s*;"              # end of statement

constantRegExp = re_compile(constantRegExpStr)


with open("top_config.vhdl") as f:
    for line in f.readlines():
        m = constantRegExp.match(line)
        if m is not None:
            print("constant '{0}' with value '{1}'".format(m.group('name'), m.group('value')))

Instead of printing the matches, you can add it to a dictionary or do something else.

answered Dec 07 '16 at 14:59

Martin Zabel

3,589
3
19
34

The solution you offer makes sense. Nevertheless, I have a question about it. It implies to use the config package in my top level to have the visibility of the package. I foresee this as a potential problem if the top I am working with is not the design top level. In this case, wouldn't it conflict between the generics value driven by the "higher level" to my block, and the content of the package about the value to drive the generics? – user1654361 Dec 07 '16 at 16:58
This config package must be included in the RTL top-level you are using for synthesis. The gate-level top-level will not require the package, it has no generics anyway. Or did you mean something else? – Martin Zabel Dec 07 '16 at 17:47
Sorry, my explanation was not clear. My question/fear is in the case I am working below the design top level (hierarchical synthesis for instance). In this case, I am afraid of the potential conflict at elab of the real top-level, that will instantiate my block, between the generics values given by the package and at the instantiation. Do you get my point? – user1654361 Dec 08 '16 at 15:29
@user1654361 Now I understand. How are the parameters of the synthesized entity (intermediate top level) set? Via default values? If yes, then these default values can come from a package without any interference with the overall design top-level. – Martin Zabel Dec 08 '16 at 20:17
I use to define them with a default value directly in the file. I went for a solution as you offered, but based on parsing the file containing the generics. Thanks for your help! – user1654361 Dec 19 '16 at 10:44

Cocotb using generics/parameters in gate level simulation

1 Answers1