Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > long counters in simulation and synthesis

Reply
Thread Tools

long counters in simulation and synthesis

 
 
Eli Bendersky
Guest
Posts: n/a
 
      10-24-2004
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

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      10-24-2004
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
 
Reply With Quote
 
 
 
 
Eli Bendersky
Guest
Posts: n/a
 
      10-25-2004

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" ??

 
Reply With Quote
 
Nicolas Matringe
Guest
Posts: n/a
 
      10-25-2004
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 -
|_| |_|_|\__|\___/

 
Reply With Quote
 
Eli Bendersky
Guest
Posts: n/a
 
      10-25-2004

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

 
Reply With Quote
 
Nicolas Matringe
Guest
Posts: n/a
 
      10-25-2004
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 -
|_| |_|_|\__|\___/

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      10-26-2004
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
 
Reply With Quote
 
Nicolas Matringe
Guest
Posts: n/a
 
      10-27-2004
Mike Treseler a écrit:
> use Mr Mantinge's advice


It's 'Matringe', actually )


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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using integers for counters in synthesis Benjamin Couillard VHDL 12 12-14-2010 03:04 PM
Having compilation error: no match for call to ‘(const __gnu_cxx::hash<long long int>) (const long long int&)’ veryhotsausage C++ 1 07-04-2008 05:41 PM
Event counters for simulation only _spot_thegthorpe_extra@ee.ryerson.ca VHDL 9 06-28-2005 06:15 PM
SOS! newbie question about synthesizable VHDL : synthesis run successfully but post-synthesis failed... walala VHDL 4 09-09-2003 08:41 AM
what are the possible reasons that successful pre-synthesis simulation + successful synthesis = failed post-synthes walala VHDL 4 09-08-2003 01:51 PM



Advertisments