Using REPORT statement during synthesis

[xipn]

Hi all,
I am working on design which is parametrized by GENERIC. In dependence
on values of GENERIC there is inherited e. g. number of counter bits
(just for simplicity). Is there any way how to write on the stdout
(console) actual value of bits during the synthesis?

I have tied textio package (write etc.) without avail.
Partial success has been achieved by means of REPORT statement:
REPORT "Value: " & INTEGER'image(v_line);
On the console (XST) at least static text "Value:" appears but
without the actual value.

Is there any idea how to write to the console actual values?

I attached the code. Of course the output of the function is not
difficult calculate by hand I have chosen it only because of its simplicity.

Thanks for comments.


-------------------------------------------------------------------------------
FUNCTION log2ceil (
CONSTANT x : NATURAL)
RETURN POSITIVE IS

VARIABLE v_tmp : NATURAL := x;
VARIABLE v_ret : NATURAL := 0;
VARIABLE v_line : INTEGER;

BEGIN -- FUNCTION log2

WHILE (v_tmp > 0) LOOP

v_tmp := v_tmp / 2;
v_ret := v_ret + 1;

END LOOP;

v_line := v_ret;
REPORT "Value: " & INTEGER'image(v_line);

RETURN v_ret;

END FUNCTION log2ceil;

 

[Mike Treseler]

Is there any way how to write on the stdout
(console) actual value of bits during the synthesis?

No.
Run a simulation to see text output.
textio and "report" are ignored for synthesis.

-- Mike Treseler

 

[KJ]

Hi all,
I am working on design which is parametrized by GENERIC. In dependence
on values of GENERIC there is inherited e. g. number of counter bits
(just for simplicity). Is there any way how to write on the stdout
(console) actual value of bits during the synthesis?

Is there any idea how to write to the console actual values?

Depends on the synthesis tool, but most will not (or at least didn't when I
last checked). If you're using Altera, then Quartus will output one line
from either an assert or a report. As Mike stated though, better to get
what you want from a simulator since all of them handle 'report'.

KJ

 

[Ben Jones]

Hi,

Hi all,
I am working on design which is parametrized by GENERIC. In dependence
on values of GENERIC there is inherited e. g. number of counter bits
(just for simplicity). Is there any way how to write on the stdout
(console) actual value of bits during the synthesis?

As you have discovered, XST will process REPORT statements and print the
value to the console & log file... but only if the string to be reported is
a constant value. If your generic has a very limited range of values, and
you're really desperate to print it out, you can do something like:

assert COUNTER_BITS = 4 report "4 counter bits" severity note;
assert COUNTER_BITS = 5 report "5 counter bits" severity note;
assert COUNTER_BITS = 6 report "6 counter bits" severity note;

This gets tedious very quickly.

I know that requests have been made (internally) here at Xilinx to lift this
restriction. There doesn't seem to me to be a good reason not to allow
REPORT statements to print out information about your design while it is
being processed. It is very useful as a sanity check during debugging.

For similar reasons, I think that the ability to write files during
synthesis, by means of the standard VHDL mechanisms, has also been
requested, although that is probably a lower priority. I cannot think of any
other solution to your problem right now...

Cheers,

-Ben-

 

[Mike Treseler]

I know that requests have been made (internally) here at Xilinx to lift this
restriction. There doesn't seem to me to be a good reason not to allow
REPORT statements to print out information about your design while it is
being processed. It is very useful as a sanity check during debugging.

The problem is that synthesis processing
unwinds all loops and flattens hierarchy
to construct a netlist. It doesn't
"run the code" like a simulator does.
Doing more than reporting some static values
during elaboration does not make sense to me.

The more valuable debugging aid provided
by synthesis is the RTL viewer.

For similar reasons, I think that the ability to write files during
synthesis, by means of the standard VHDL mechanisms, has also been
requested, although that is probably a lower priority.

For good reason.
Synthesis data ought to be in a vhdl package
anyway or it will miss the free consistency
checks during syntax parsing and elaboration.

-- Mike Treseler

 

[Ben Jones]

Hi Mike,

The problem is that synthesis processing
unwinds all loops and flattens hierarchy
to construct a netlist. It doesn't
"run the code" like a simulator does.

Well, that's true to some extent, but it does rather depend what you mean by
"run the code". If I write some VHDL that implies a ROM, and the values
inside that ROM are being calculated by a function, then that function is by
necessity being "run" by the synthesis tool.

Doing more than reporting some static values
during elaboration does not make sense to me.

The OP's complaint was that he has a static value (well, a generic
parameter, which seems static enough to me whatever the LRM says on the
subject!) and he can't print it out. I think he should be able to do that.
Currently I think XST will only process a report statement if its argument
is a single, constant string literal.

If your design is, or contains, a highly parameterized piece of re-usable
IP, then there is a good chance that you cannot run enough simulations to
cover the entire generic space. If your design has a deep hierarchy in which
the parameters passed to each level are calculated by the level above, and
so on all the way down, then it can be hard to know exactly which
sub-modules are being instantiated with what parameters.

In situations like these, having a log file that tells you "what the
synthesis tool did" is just as valid a requirement as having one telling you
"what the simulator did" when elaborating a design. At the very least, it's
useful to be able to cross-check one against the other to make sure they are
both doing what you expect.

Synthesis data ought to be in a vhdl package
anyway or it will miss the free consistency
checks during syntax parsing and elaboration.

I'd absolutely agree with that (although I think that's a different issue).

Cheers,

-Ben-