"Best practice" for capturing data mid pipeline

[Tricky]

I have a design where I need to capture data in the middle of a
pipeline and dump it to file. I wanted to know people's thoughts on
where you would normally put code to do this.

The pipeline in question is in the top level file, between 2 entity
instantiations. What Im doing is capturing the data and generating the
expected results for the next entity in the pipeline via a process
(surrounded by synthesis translate_off/on directives). My Questions:

1. Is it possible to access the same signals via the top level
instantiation in the testbench, thus removing the debugging code from
the top level file?
2. If the signals change name for some reason in the top level file in
the future, would this missmatch then be picked up by the compiler
when I compile the testbench?
3. Are people happy with debug processes sat in the middle of
synthesisable code, or would you rather see this kind of stuff in the
testbench?

Any input appriciated.

Thanks
Richard

 

[KJ]

I have a design where I need to capture data in the middle of a
pipeline and dump it to file. I wanted to know people's thoughts on
where you would normally put code to do this.

3. Are people happy with debug processes sat in the middle of
synthesisable code, or would you rather see this kind of stuff in the
testbench?

Given a parameter that simply enables/disables the collection I prefer
the collection of non-top level stuff to be in the design itself.
That way, if the module gets used in some other application, I have a
built-in way to collect data.

Along those same lines, I prefer self-checking designs to self-
checking testbenches for the same reason...but many times that is not
always possible.

Kevin Jennings

 

[Bill Mills]

1. Is it possible to access the same signals via the top level

instantiation in the testbench, thus removing the debugging code from
the top level file?

If you don't mind doing some post-processing, then something like this
ModelSim macro can be used to collect the signals of interest.

# Just run this .do file before you vsim and run
#
# Keep going on an error
onerror {resume}

# The first signal added is STROBE 0 !!!
add list -width 7 -label dds_clk /mod_top/dds_clk

# See all of the -notrigger below?
# Without this switch any transition on
# any of the signals will cause the list to update.
# But we only want to update when dds_clk changes.
add list -notrigger -unsigned -label pipe1 /mod_top/pipe1_out
add list -notrigger -unsigned -label pipe2 /mod_top/pipe2_out

# Declare the first signal as the capture STROBE
configure list -usestrobe 0
configure list -strobestart {0 ps} -strobeperiod {0 ps}
configure list -delta none


Good Luck!
Bill

 

[Martin Thompson]

I have a design where I need to capture data in the middle of a
pipeline and dump it to file. I wanted to know people's thoughts on
where you would normally put code to do this.

I'd do it within the module in question.

The pipeline in question is in the top level file, between 2 entity
instantiations. What Im doing is capturing the data and generating the
expected results for the next entity in the pipeline via a process
(surrounded by synthesis translate_off/on directives). My Questions:

1. Is it possible to access the same signals via the top level
instantiation in the testbench, thus removing the debugging code from
the top level file?

With VHDL-2008 I believe so, yes.

2. If the signals change name for some reason in the top level file in
the future, would this missmatch then be picked up by the compiler
when I compile the testbench?

i would assume so.

3. Are people happy with debug processes sat in the middle of
synthesisable code, or would you rather see this kind of stuff in the
testbench?

I'm perfectly happy (in fact, positive) about having debug and
verification code within "synthesisable" code.

To me, it's all just code - some of which is used by a synthesiser. I
see no reason to split it into different files - unless the tools
force me to, and then I need better tools.

"Don't separate stuff that belongs together" - who said that?

Cheers,
Martin