Rusty with Configurations

[M. Norton]

Hello,

After a long period of looking for work, I'm back in the saddle
writing VHDL and quite happy about it. On the downside, there are a
few regions where I am a bit rusty. Addtionally I have some
colleagues who are more novice, some of them writing their first VHDL
for FPGA devices on their boards and I've become sort of a mentor,
alarming though that may be ;-)

Anyhow to the point, I'm looking for some help with simulation and
managing multiple configurations along with any best practices and
recommendations for structure. For example, a colleague has his RTL
code and has performed synthesis and I was trying to demonstrate how
he can run his testbench against the back-annotated VHDL the place and
route tool provided. So in the testbench we had something like:

entity design_tb is

end entity design_tb;

architecture beh of design_tb is

component foo_design

end component foo_design;

begin

DUT : foo_design port map ();

end architecture beh;

We have an RTL description of the design, and then the VHDL that was
generated from the place & route tool, labeled def_arch. I added a
couple of configurations at the end of the testbench file thinking he
could comment and uncomment them as needed for whatever he was trying
to simulate.

configuration back_annotated of design_tb is
for beh
for all : foo_design
use entity work.foo_design(def_arch);
end for;
end for;
end configuration back_annotated;

configuration functional of design_tb is
for beh
for all : foo_design
use entity work.foo_design(rtl);
end for;
end for;
end configuration functional;

However, commenting and uncommenting the desired configuration with a
recompile afterwards did not seem to do the trick, it was always using
the most recently compiled architecture for the design, regardless of
what configuration was active. So it seems to me like I've got
something wrong. And additionally, this was what I came up with on
the spur of the moment. As noted above, I'm all ears for best
practices for creating multiple simulation configurations. It's ALSO
entirely possible there's something special in Modelsim's invocation
of vsim that I'm not specifying correctly. I admit we're using the
GUI heavily due to me still feeling rusty. I felt fortunate that I
still remembered how to invoke an SDF file to use with the
backannotated design, but likewise felt bad I couldn't figure out how
to get it to invoke the correct architecture that makes the SDF file
meaningful.

Any ideas? How do you collective designers manage this issue?

Thanks!
Mark Norton

 

[Jonathan Bromley]

However, commenting and uncommenting the desired configuration with a
recompile afterwards did not seem to do the trick, it was always using
the most recently compiled architecture for the design, regardless of
what configuration was active.

I'd put money on the guess that you asked the simulator to load
the testbench. If you use a top-level configuration, it's the
CONFIGURATION that you load into the simulator (vsim config_name
instead of vsim entity_name).

However, there's another thing that you are not doing
optimally. The whole point of configs is that it allows
you to compile your architectures just once, and then edit
and compile only a tiny little config file to decide what
you want to load. Now, if you put the configs into the
same file as your testbench, you must of necessity compile
the testbench whenever you change the config. That kinda
defeats the point. So, move the configs out into a separate
file (maybe even one file per config, though I don't personally
agree with that). Compile the design. Then compile the
testbench. Then compile the configs. Then choose which
config to load into the simulator - no more compiles.
And if you decide you need a couple of extra configs,
maybe because you want to tweak a generic or two on your
top-level entity, then just go add those configs to the
configs file and recompile that, on its own.

In ModelSim's GUI, take a look at the "Library" tab of the
design browser. You should be able to see all the entities
AND THE COMPILED CONFIGS as separate "things" in the work
library, or wherever it was you put them.

Others will no doubt suggest other approaches that don't
involve using configurations. I agree with you that it's
a fairly obscure part of the language; the syntax is
indigestible, and it's something that you generally do
rather infrequently so it's easily forgotten. It's the
only part of VHDL that routinely sends me scurrying for
a reference guide or cheat sheet.

Oh, and do yourself a big favour: learn how to write
simple compile scripts. ModelSim writes out a file
(Called "transcript" by default, although you can
change that with the -l option to vsim). This file
contains all the commands that got executed, even the
commands that you launched through the GUI. It's a
great starting point for creating your own compile/run
scripts. Managing multiple libraries and configs
with the GUI is a sure road to Bedlam.

Good luck

 

[Andy]

I'm pretty rusty with configurations myself; I rarely use them.

If you are willing to edit the source code (commenting/uncommenting)
just use direct entity instanitation instead.

Or you could have two if-generate statements in your TB that
conditionally instantiate the appropriate entity/architecture for the
DUT, based on a generic value that is passed in from the gui or a
command line argument.

generic gate_sim : boolean := false; -- override via cmd line
....

if gate_sim generate

DUT : entity work.foo_design(def_arch) port map ();

end generate;

if not gate_sim generate

DUT : entity work.foo_design(rtl) port map ();

end generate;


With configurations, the simulator should allow you to elaborate a
configuration declaration itself. Just defining and compiling a
configuration declaration (what you appear to have added to the end of
your TB file) specifies nothing about actually using it.

Andy

 

[M. Norton]

I'd put money on the guess that you asked the simulator to load
the testbench.   If you use a top-level configuration, it's the
CONFIGURATION that you load into the simulator (vsim config_name
instead of vsim entity_name).

You'd win the bet. We were sitting at my colleague's machine and I'm
just poking around on modelsim and I think i was just trying to find
the right object in the hierachy to select. I don't recall seeing a
separate item with the configuration names in it, HOWEVER, as you
noted, I did not have things set up optimally for exploiting the
benefit of configurations (via either the separate file method, or
Andy's direct entity instantiation plus generic generate statements.

Oh, and do yourself a big favour: learn how to write
simple compile scripts.  ModelSim writes out a file
(Called "transcript" by default, although you can
change that with the -l option to vsim).  This file
contains all the commands that got executed, even the
commands that you launched through the GUI.  It's a
great starting point for creating your own compile/run
scripts.  Managing multiple libraries and configs
with the GUI is a sure road to Bedlam.

Yep, I'm already getting the swing of that back. I've had to remind
myself how to do some of this already just in getting emacs vhdl-mode
setup so that I can compile in the editor without switching between
utilities, etc. Ultimately I can make this roll into a tcl or
Modelsim *.do file and automate the whole process. I've been trying
to explain to whomever will listen the benefits of making this all
more turnkey, both for future modifications with regression testing,
to "hit-by-bus syndrome" and other pitfalls of design management in an
engineering department.

However as I noted, this was at a colleague's machine and he's writing
his own stuff, and I've got engineers at another nearby facility who
have been generating their designs using the schematic entry tool in
HDL Designer (which is driving me up the wall -- whomever came up with
the concept for that Renoir tool that Mentor bought and ultimately
incorporated into HDL Designer ought to have been taken outside and
shot before it could be birthed), and so it's been a bit of an uphill
battle on this new job. Fortunately, I am of the firm opinion that
they need me, and they haven't seemed to disagree, so I might be able
to do some good here with getting some more rigorous design practices
in place. I just have to remember what they are!

Thanks for the information and suggestions (Andy too, sort of replying
to everyone here.)

Mark Norton

 

[Martin Thompson]

However, there's another thing that you are not doing
optimally. The whole point of configs is that it allows
you to compile your architectures just once, and then edit
and compile only a tiny little config file to decide what
you want to load. Now, if you put the configs into the
same file as your testbench, you must of necessity compile
the testbench whenever you change the config.

Jonathon doubtless knows this already, but (with Modelsim anyway) -
you can use:

vcom -just c blah.vhd

to just compile the configurations.

Slightly tangentially - I have my Emacs compile command mapped to
"vcom -just bac" to just compile bodies, archs and configs, which
suits me almost all the time as it's usually only those bits that
change, so I don;t have to worry about having recompiled an unchanged
"entity" part which then neccesitates compiling everything else that
instantiates it. I do "vcom file.vhd" by hand on the rare occasions
I've changed a package or entity.

That kinda
defeats the point. So, move the configs out into a separate
file (maybe even one file per config, though I don't personally
agree with that). Compile the design. Then compile the
testbench. Then compile the configs. Then choose which
config to load into the simulator - no more compiles.

But I agree, putting the configs in a separate file makes a lot of sense!

Others will no doubt suggest other approaches that don't
involve using configurations. I agree with you that it's
a fairly obscure part of the language; the syntax is
indigestible, and it's something that you generally do
rather infrequently so it's easily forgotten. It's the
only part of VHDL that routinely sends me scurrying for
a reference guide or cheat sheet.

I'm glad it's not just me then - even when Emacs steps me through the
syntax I usually get one of the various fields wrong first time

Cheers,
Martin

 

[Martin Thompson]

Jonathon

Or even "Jonathan" - sorry! That seems to be one of my natural typos - I'll
spell it right one day, honest

Martin

 

[Jonathan Bromley]

Or even "Jonathan" - sorry! That seems to be one of my natural typos - I'll
spell it right one day, honest

Serves me right for having an obscure name. Next time
I'll arrange to be born "Sid" or "Bill" to keep it simple.

Seriously - I've long ago got used to more-or-less random
permutations of o, a and h in my name. The one mis-spelling
I squirm at is "John". Thanks for even taking the trouble
to notice!

 

[Andy]

Or in rural southern US, you could be "Joe Nathan" Bromley, and fit
right in with "Jim Bob" (aka James Robert when his mother wanted his
direct and undivided attention!)

Andy

 

[Andy Peters]

But I agree, putting the configs in a separate file makes a lot of sense!

I agree with this, except that certain synthesis tools, like XST,
barfs on this.

I realize that configuration support for synthesis is still out in the
weeds, but it would be nice if it actually worked. And there's no
reason for it not to, considering that configurations have been in the
language forever.

For example, I wrote a memory controller that supports Virtex4 and
Spartan3A (why? Because the Xilinx cores suck, that's why, and we see
no evidence that the core in Spartan6 is non-sucky, but I digress).
The instances of the device-specific bits are all contained in an
entity called phy which has two architectures (one for each FPGA
family). But XST seems to have a difficult time with the configuration
on the upper levels of the code hierarchy (usually, but not always! it
just uses the wrong architecture, regardless of what I specify).

So the workaround is to use generics and other hackery.

Maybe one day this will work. But today is not that day. And tomorrow
doesn't look good, either.

-a

-a

 

[Martin Thompson]

I agree with this, except that certain synthesis tools, like XST,
barfs on this.

I realize that configuration support for synthesis is still out in the
weeds, but it would be nice if it actually worked. And there's no
reason for it not to, considering that configurations have been in the
language forever.

Indeed! Do you know if it's the same for S6 - new VHDL front-end and
all that...?

For example, I wrote a memory controller that supports Virtex4 and
Spartan3A (why? Because the Xilinx cores suck, that's why, and we see
no evidence that the core in Spartan6 is non-sucky, but I digress).

For what values of "suck"? Performance or predicatability (or
something else)? I'm using a bunch of MPMCs at the moment, which seem
to be working OK (although I'm not asking for outright max
performance... yet)

The instances of the device-specific bits are all contained in an
entity called phy which has two architectures (one for each FPGA
family). But XST seems to have a difficult time with the configuration
on the upper levels of the code hierarchy (usually, but not always! it
just uses the wrong architecture, regardless of what I specify).

So the workaround is to use generics and other hackery.

Yeah, I'd probably end up with the archs in separate files and just
tell XST about the one I want it to know about. But you're right it
really ought to just work!

Maybe one day this will work. But today is not that day. And tomorrow
doesn't look good, either.

Cheers,
Martin