long counters in simulation and synthesis

Hi all,

I have a question regarding long counters in VHDL code that's meant
for synthesis.

The problem is as follows: the FPGA needs to count long time periods
- tens of ms, sometimes even seconds. There are communications that
happen once in many ms, etc.
When I'm designing the code and simulating it, these long counters
are impossible. Running even 10 ms in Modelsim on a large design
takes a lot of time, not mentioning seconds. So, my approach so far has
been to cut these counters, for simulation. The design is fully
synchronous, w/o race conditions, so these simulations represent
reality well. But this is good for one block. When many blocks, each
having some counters , are stitched together, the approach is
problematic. I fear to forget certain counters, there are just too
many.

I seek some methodology that will help me with this. No doubt, it's a
problem people run into all the time. Should I define
a package with all the counters in it, and modify all-at-once ? What
are the approaches to handling this ?

TIA
Eli

Eli Bendersky

Eli Bendersky wrote:

> When I'm designing the code and simulating it, these long counters
> are impossible. Running even 10 ms in Modelsim on a large design
> takes a lot of time, not mentioning seconds. So, my approach so far has
> been to cut these counters, for simulation.

Consider inferring the counters from code.
Simulate the code before synthesis.
Modelsim runs more quickly in this case.

Since your design
is synchronous, you can verify timing statically
after place and route without using modelsim.

-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
> Eli Bendersky wrote:
>
> > When I'm designing the code and simulating it, these long
counters
> > are impossible. Running even 10 ms in Modelsim on a large design
> > takes a lot of time, not mentioning seconds. So, my approach so far
has
> > been to cut these counters, for simulation.
>
> Consider inferring the counters from code.
> Simulate the code before synthesis.
> Modelsim runs more quickly in this case.
>

What do you mean by "inferring the counters from the code" ??

Eli Bendersky

Eli Bendersky a écrit:
> Hi all,
[...]
> I seek some methodology that will help me with this. No doubt, it's a
> problem people run into all the time. Should I define
> a package with all the counters in it, and modify all-at-once ? What
> are the approaches to handling this ?

Hello
I use a generic parameter, usually called "fast_sim", and shorten the
count-periods whan its value is true. At the top level, this parameter
is false by default but the testbench overrides this so that the
parameter is true for simulation

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

Nicolas Matringe

Nicolas Matringe wrote:
> Eli Bendersky a écrit:
> > Hi all,
> [...]
> > I seek some methodology that will help me with this. No doubt,
it's a
> > problem people run into all the time. Should I define
> > a package with all the counters in it, and modify all-at-once ?
What
> > are the approaches to handling this ?
>
> Hello
> I use a generic parameter, usually called "fast_sim", and shorten the

> count-periods whan its value is true. At the top level, this
parameter
> is false by default but the testbench overrides this so that the
> parameter is true for simulation
>

This is a good idea... However, one problem: my counters are usually
set with constants, like:

constant CLOCKS_PER_BIT: integer := 1056;
signal trans_counter: integer range 0 to CLOCKS_PER_BIT;

And then, in the process, the counter is reset if it's
equal CLOCKS_PER_BIT, or something like it.

Can I somehow condition the constant declaration on a generic ?
I.e. if (fast_sim) CLOCKS_PER_BIT = XXX else YYY
??

TIA
Eli

Eli Bendersky

Eli Bendersky a écrit:

> Can I somehow condition the constant declaration on a generic ?
> I.e. if (fast_sim) CLOCKS_PER_BIT = XXX else YYY
> ??

You can't do it as simply as that but you can use a function and use its
return value to set your constant.
If you have several constants to set according to a single parameter,
you can define a record type to group all your constants and make your
function return this type, and then use each record field to set your
constants.

function count_value (sim : boolean) return natural is
begin
if sim then
return <simulation value>;
else
return <synthesis value>;
end if;
end count_value;

constant CLOCKS_PER_BIT : natural := count_value(fast_sim);

Or with a record:

type const_record : record
const_1 : natural;
const_2 : std_logic_vector(3 downto 0);
const_3 : natural;
end record const_record;

function const_calc (sim : boolean) return const_record is
begin
if sim then
return (<sim value 1>, <sim value 2>, <sim value 3>);
else
return (<synth value 1>, <synth value 2>, <synth value 3>);
end if;
end const_calc;

constant consts : const_record := const_calc(fast_sim);
constant count_1 : natural := consts.const_1;
constant hex_val : std_logic_vector(3 downto 0) := consts.const_2;
constant count_2 : natural := consts.const_3;

--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

Nicolas Matringe

Eli Bendersky wrote:

> What do you mean by "inferring the counters from the code" ??

I mean n_v := n_v + 1; in a synchronous process
rather than instancing a vendor core/netlist.
Synth code sims faster than a primitive netlist.
Variables sim faster than signals.
If it's still too slow, use Mr Mantinge's advice
of a generic switch that defaults to the synth value.

-- Mike Treseler

Mike Treseler

Mike Treseler a écrit:
> use Mr Mantinge's advice

It's 'Matringe', actually )


--
____ _ __ ___
| _ \_)/ _|/ _ \ Adresse de retour invalide: retirez le -
| | | | | (_| |_| | Invalid return address: remove the -
|_| |_|_|\__|\___/

Nicolas Matringe