unsupported types

[ashu]

while compiling the program i am getting the error: "Time" is an
unsupported type

the code is underementioned


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ram is
generic (mem_size : natural := 256; -- Size of the memory in words
latency : Time := 0 ns);


what cud be the reson ?

 

[Duane Clark]

while compiling the program i am getting the error: "Time" is an
unsupported type

the code is underementioned


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity ram is
generic (mem_size : natural := 256; -- Size of the memory in words
latency : Time := 0 ns);


what cud be the reson ?

Compiling with what program? If a synthesis tool, Time cannot be
synthesized.

 

[ashu]

yes i am compiling with synopsys
what shoudl i do if it cant be synthesiszed ?

 

[Duane Clark]

yes i am compiling with synopsys
what shoudl i do if it cant be synthesiszed ?

Time cannot be synthesized, so don't use it.

 

[Hans]

Use pragma's around the non-synthesisable constructs.

-- synopsys translate_off
-- synopsys translate_on

Hans
www.ht-lab.com

 

[KJ]

Time cannot be synthesized, so don't use it.

While it's true that time can not be synthesized, it does not imply
that a *good* synthesis tools shouldn't support time at all. As an
example, suppose to control some device you need to generate a 2 us
pulse and the PLD/FPGA/ASIC/whatever has a 25 ns clock. Immediately,
you recognize that you need a counter to count from 0 to some upper
limit and can probably quickly figure out that there are 80 clock
cycles and define your counter signal as...

signal Counter: natural range 0 to 79;

Now years later, somebody picks this wonderful design and wants to use
it someplace else...or maybe you're just wanting to soup it up and run
your whole design at a faster clock frequency so now you need to go
through all the code you want to reuse and unearth the places where the
implicit knowledge of the original 25 ns clock was used.

Now suppose instead you had brought in a generic time input into the
entity (say 'T: time). Now you might go about defining the counter
as...

signal Counter: natural range 0 to (2 us / T);

It's a whole heck of a lot clearer that the Counter is now being used
to generate a 2 us something...and hey, in order to run the new design
at the new clock frequency you simply need to change the generic input
from the 'old' clock period to the 'new' one.

So even though you don't synthesize time, it is certainly useful to be
able to use time types in the manner I've described to write code that
is clearer as to the intent and more maintainable.

Having said all that, it doesn't surprise me at all that Synopsys
doesn't support time in any fashion. Synplicity had some troubles with
it at least a year or so ago when I tried it (submitted a service
request to them on it). Quartus does support time types, at least in
the manner that I'm using them.

Time, it's not just for simulation anymore....

KJ

 

[KJ]

yes i am compiling with synopsys

what shoudl i do if it cant be synthesiszed ?

1. Use something other than Synopsys (if that's even possible).
2. Bow to Synposis and don't use time types....and then submit a gripe
to Synopsys about their lack of support of time types since it can be
useful for synthesis

KJ

 

[ashu]

clark thanks
KJ: wonderfull insight !!
Hans: will this turning on and off of translator affect the synthesis
in any way ?

 

[Duane Clark]

1. Use something other than Synopsys (if that's even possible).

Careful. Read KJ's post carefully. He used Time in an arithmetic
calculation, where the result is a plain integer without units. The only
thing synthesized in his example was a plain, unitless integer. A plain
integer can be synthesized, Time cannot.

You need to think about what actual hardware you are expecting to be
synthesized. Perhaps you should show the code where you are using it.

2. Bow to Synposis and don't use time types....and then submit a gripe
to Synopsys about their lack of support of time types since it can be
useful for synthesis

Be sure you truly understand what you are asking for before submitting a
gripe.

 

[Duane Clark]

KJ wrote:
...

Oops, sorry. I meant to point this out to ashu.

 

[ashu]

thakns duane
i used the pragma thing and it worked ..no problems in analyzing

the code is simple its a basic RAM memory

-----------------------------------------------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

library work;
use work.pack_mips.all;

entity ram is
generic (mem_size : natural := 256; -- Size of the memory in words
-- synopsys translate_off
latency : Time := 0 ns);
-- synopsys translate_on
port(
req : in std_logic;
adr : in bus32;
data_inout : inout bus32;
r_w : in std_logic;
ready : out std_logic
);
end;


architecture bench of ram is
type storage_array is array(natural range 1024 to 1024+4*mem_size -
1) of bus8;
signal storage : storage_array; -- The memory
begin


process(adr, data_inout, r_w)
variable inadr : integer;
variable i : natural;
begin
inadr := to_integer(unsigned(adr));

if (inadr>=storage'low) and (inadr<=storage'high) then
-- synopsys translate_off

ready <= '0', '1' after latency;
-- synopsys translate_on
if req = '1' then
if r_w /= '1' then -- Reading in memory
for i in 0 to 3 loop
data_inout(8*(i+1)-1 downto 8*i) <=
storage(inadr+(3-i)) after latency;
end loop;
else
for i in 0 to 3 loop
storage(inadr+(3-i)) <= data_inout(8*(i+1)-1
downto 8*i) after latency;
end loop;
data_inout <= (others => 'Z');
end if;
else
data_inout <= (others => 'Z');
end if;
else
data_inout <= (others => 'Z');
ready <= 'L';
end if;
end process;

end bench;

 

[Duane Clark]

thakns duane
i used the pragma thing and it worked ..no problems in analyzing

the code is simple its a basic RAM memory

Well, yes. That will synthesize. Just as long as you realize that in
hardware, "ready" will go to L and never change. The simulation will not
match the hardware.

 

[Andy]

For reusable modules that have some time-based behavior/requirements, I
include an integer ns_per_clk generic (with an appropriate range
constraint) to help calculate timer values, etc. to meet requirements.
If the requirement is somewhat flexible, it will be in generic form
also, but always an integer (and I include units in the generic name,
as in the ns_per_clk example). The former allows application to
different clock speeds; the latter allows different performance
requirements to be implemented. All the calculations are static, so
divide and multiply are not limited to powers of two, etc.

Andy

 

[KJ]

For reusable modules that have some time-based behavior/requirements, I

include an integer ns_per_clk generic (with an appropriate range
constraint) to help calculate timer values

I've done the same thing in the past as well, (and will again when
using tools that don't support 'time') the only 'but' comes along with

(and I include units in the generic name, as in the ns_per_clk example).

....if you use a time type the unit of measure is a part of 'live code'
and will be correctly handled (well, if it's handled at all) instead of
relying on a naming convention....a decent convention but still just a
convention.

Kicking the tool guys every now and then to support valid code is a
time honored way of getting them to improve their tools....geez after
all these years we're still living with clock'event and clock = '1'
instead of rising_edge(clock) because so many people got trained that
way because the synthesis tools didn't support such a simple thing.

KJ