FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 11-13-2007, 10:12 AM
Nial Stewart
Guest
 
Posts: n/a
Default Structured way of changing eg time constants for real world build / simulation?

Frequently when doing simulation of a design I'll change time
constants so I can run the simulation in a reasonable timescale.

I like to keep things simple so to date this has mostly involved
commenting out the 'proper' value with a -- XXXX comment at the end
of the line. When I want to do a real workd build a search for
-- XXXX throughout the design should allow me to quickly find the
values that need changed and comment them back to their correct
values.

Except I keep forgetting. Over the years this has caused hours of
lost work until I have realised what I've done.

I've thought of including a generic in all my modules by default to
indicate whether simulation or real world build is being done, this
could be propogated down from the top of a design to select which
values are being used. Another solution would be a script to search the
source directory commenting out --XXXX lines and uncommenting -- YYYY
lines (for example).

But why re-invent the wheel....

Does anyone have a clever (simple) structured way of ensuring that
temporary simulation values aren't included when doing real world builds?


Thanks for any pointers,


Nial.


Reply With Quote
  #2 (permalink)  
Old 11-13-2007, 10:26 AM
Hal Murray
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?


>Does anyone have a clever (simple) structured way of ensuring that
>temporary simulation values aren't included when doing real world builds?


This isn't a real solution, but sometimes hacks are good enough.

grep -r XXXX .

That will find them all. As long as there aren't many you can check
them by eye.

--
These are my opinions, not necessarily my employer's. I hate spam.

Reply With Quote
  #3 (permalink)  
Old 11-13-2007, 10:35 AM
Nial Stewart
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

>>Does anyone have a clever (simple) structured way of ensuring that
>>temporary simulation values aren't included when doing real world builds?

>
> This isn't a real solution, but sometimes hacks are good enough.
>
> grep -r XXXX .
>
> That will find them all. As long as there aren't many you can check
> them by eye.



Aye Hal, I have windows Grep on my PC so can create a tool in Textpad to
do this and capture the results fairly easily.

The problem is that I keep forgetting to check.

:-(




Nial.


Reply With Quote
  #4 (permalink)  
Old 11-13-2007, 01:46 PM
Brian Drummond
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

On Tue, 13 Nov 2007 10:12:02 -0000, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk > wrote:

>Frequently when doing simulation of a design I'll change time
>constants so I can run the simulation in a reasonable timescale.


>But why re-invent the wheel....
>
>Does anyone have a clever (simple) structured way of ensuring that
>temporary simulation values aren't included when doing real world builds?


constant ddr_reset_time : integer := 200 us / clk_period; -- cycles
constant sim_reset_time : integer := 2 us / clk_period; -- cycles

function reset_time return integer is
variable temp:integer := ddr_reset_time;
begin
-- pragma synthesis off
temp := sim_reset_time;
-- pragma synthesis on
return temp
end;

....

reset_counter <= reset_time;


- Brian

Reply With Quote
  #5 (permalink)  
Old 11-13-2007, 03:34 PM
Andy
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

On Nov 13, 7:46 am, Brian Drummond <[email protected]>
wrote:
> On Tue, 13 Nov 2007 10:12:02 -0000, "Nial Stewart"
>
> <nial*[email protected] > wrote:
> >Frequently when doing simulation of a design I'll change time
> >constants so I can run the simulation in a reasonable timescale.
> >But why re-invent the wheel....

>
> >Does anyone have a clever (simple) structured way of ensuring that
> >temporary simulation values aren't included when doing real world builds?

>
> constant ddr_reset_time : integer := 200 us / clk_period; -- cycles
> constant sim_reset_time : integer := 2 us / clk_period; -- cycles
>
> function reset_time return integer is
> variable temp:integer := ddr_reset_time;
> begin
> -- pragma synthesis off
> temp := sim_reset_time;
> -- pragma synthesis on
> return temp
> end;
>
> ...
>
> reset_counter <= reset_time;
>
> - Brian


Nice trick Brian; I'll have to remember that...

I would use a generic, passed up to the top level, with a default
value defined for synthesis. Then when you instantiate the top level
module in your testbench for simulation, override the default value
with a generic map. This can be done for one or a whole group of
generics. If you use a group of generics, you can define them as
elements of a record type in a package, and every entity takes that
generic record. That way when you want to add a generic for some lower
level entity, you just have to add it's element to the record
definition, then set it at the top (default and testbench), and use it
at the leaf level where needed. The record definition acts like a
conduit through which you can pass anything you want.

Andy

Reply With Quote
  #6 (permalink)  
Old 11-13-2007, 04:26 PM
Nial Stewart
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

> I would use a generic, passed up to the top level, with a default
> value defined for synthesis. Then when you instantiate the top level
> module in your testbench for simulation, override the default value
> with a generic map. This can be done for one or a whole group of
> generics. If you use a group of generics, you can define them as
> elements of a record type in a package, and every entity takes that
> generic record. That way when you want to add a generic for some lower
> level entity, you just have to add it's element to the record
> definition, then set it at the top (default and testbench), and use it
> at the leaf level where needed. The record definition acts like a
> conduit through which you can pass anything you want.
>
> Andy



Another nice trick, although after spending ages trying to get my head
round a design I had to pick that used records on port maps everywhere
I tend to try to avoid them.

Sometimes they can be a great tool for obfuscation :-)



Nial.


Reply With Quote
  #7 (permalink)  
Old 11-13-2007, 05:24 PM
John Adair
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

Personally I use two copies of a VHDL package with constants etc in
there. Named clearly as SIM or SYNTHESIS. You just need to carefully
keep the two copies in track with any extra values added.

John Adair
Enterpoint Ltd. - Home of Darnaw1 the PGA FPGA Module.


On 13 Nov, 10:12, "Nial Stewart"
<nial*[email protected] > wrote:
> Frequently when doing simulation of a design I'll change time
> constants so I can run the simulation in a reasonable timescale.
>
> I like to keep things simple so to date this has mostly involved
> commenting out the 'proper' value with a -- XXXX comment at the end
> of the line. When I want to do a real workd build a search for
> -- XXXX throughout the design should allow me to quickly find the
> values that need changed and comment them back to their correct
> values.
>
> Except I keep forgetting. Over the years this has caused hours of
> lost work until I have realised what I've done.
>
> I've thought of including a generic in all my modules by default to
> indicate whether simulation or real world build is being done, this



> could be propogated down from the top of a design to select which
> values are being used. Another solution would be a script to search the
> source directory commenting out --XXXX lines and uncommenting -- YYYY
> lines (for example).
>
> But why re-invent the wheel....
>
> Does anyone have a clever (simple) structured way of ensuring that
> temporary simulation values aren't included when doing real world builds?
>
> Thanks for any pointers,
>
> Nial.



Reply With Quote
  #8 (permalink)  
Old 11-13-2007, 06:46 PM
Andy
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

On Nov 13, 10:26 am, "Nial Stewart"
<nial*[email protected] > wrote:
> > I would use a generic, passed up to the top level, with a default
> > value defined for synthesis. Then when you instantiate the top level
> > module in your testbench for simulation, override the default value
> > with a generic map. This can be done for one or a whole group of
> > generics. If you use a group of generics, you can define them as
> > elements of a record type in a package, and every entity takes that
> > generic record. That way when you want to add a generic for some lower
> > level entity, you just have to add it's element to the record
> > definition, then set it at the top (default and testbench), and use it
> > at the leaf level where needed. The record definition acts like a
> > conduit through which you can pass anything you want.

>
> > Andy

>
> Another nice trick, although after spending ages trying to get my head
> round a design I had to pick that used records on port maps everywhere
> I tend to try to avoid them.
>
> Sometimes they can be a great tool for obfuscation :-)
>
> Nial.


Yeah, records on ports can get really ugly, especially since
everything ends up being of mode inout, with default 'Z' drivers,
etc.

Fortunately for generics, which are "in" only, it is not as bad.

I've been wishing for user defined modes for record type ports (or
procedure arguments), used in lieu of in, out or inout, that would
allow you to specify the mode of each individual element. If only we
could do something like:

type bus_type is record
data : std_logic_vector(31 downto 0);
ack : std_logic;
...
end record;
mode slave of bus_type is (data => inout; ack => out; others => in);
mode master of bus_type is (data => inout; ack | clk | rst => in;
others => out);

Andy

Reply With Quote
  #9 (permalink)  
Old 11-16-2007, 09:12 AM
Andreas Ehliar
Guest
 
Posts: n/a
Default Re: Structured way of changing eg time constants for real world build / simulation?

On 2007-11-13, Andy <[email protected]> wrote:
> I've been wishing for user defined modes for record type ports (or
> procedure arguments), used in lieu of in, out or inout, that would
> allow you to specify the mode of each individual element. If only we
> could do something like:
>
> type bus_type is record
> data : std_logic_vector(31 downto 0);
> ack : std_logic;
> ...
> end record;
> mode slave of bus_type is (data => inout; ack => out; others => in);
> mode master of bus_type is (data => inout; ack | clk | rst => in;
> others => out);


If you aren't too attached to VHDL you could look at SystemVerilog
which has exactly this functionality. Keywords to look for are
"interface" and "modport".

/Andreas
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

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 On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Real-world soft-cpu performance Simon Gornall FPGA 7 08-15-2006 03:28 AM
Standards in the real world: UWB Austin Lesea FPGA 0 01-17-2006 07:06 PM
real constants in XST gallen FPGA 2 08-22-2005 01:49 PM
simulation and real world [email protected] FPGA 1 03-05-2005 03:25 PM
Quartus II tutorial vs the real world pjjones FPGA 7 10-07-2003 10:52 PM


All times are GMT +1. The time now is 05:17 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved