Using REPORT statement during synthesis

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;
-------------------------------------------------------------------------------

After that I can use
CONSTANT N_CNT_ADDR : NATURAL := log2ceil(N_COE_PER_SECTION);

xipn

xipn wrote:

> 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

Mike Treseler

"xipn" <> wrote in message
news:ehonpf$2c0a$...
> 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

KJ

Hi,

"xipn" <> wrote in message
news:ehonpf$2c0a$...
> 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-

Ben Jones

Ben Jones wrote:

> 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

Mike Treseler

Hi Mike,

"Mike Treseler" <> wrote in message
news:...
> Ben Jones wrote:
>
>> 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.

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-

Ben Jones