I have a really large lookup table (members of a
finite field) encoded
as a function. This function is only ever invoked with a constant
argument, so it shouldn't actually be synthesized. Altera's synthesis
tool seems to handle this with no problem.

When I try to use Synplify to synthesize my design (particularly this
constant function), the verilog compiler (c_ver) runs out of memory
(hits the 4GB limit).

Seems like Synplify isn't figuring out that the function doesn't
actually need to be synthesized.

So I guess the question is two-fold:

1. is there a better way to encode a large lookup table like that that
should really only be used at elaboration time?
2. is it possible to enable c_ver to run in 64-bit mode, so that it
can go past the 4G boundary?

Thanks,
Ben

On Feb 11, 2:52=A0pm, Ben Gelb
<ben.g...@gmail.com> wrote:
> I have a really large lookup table (members of a finite field) encoded
> as a function. This function is only ever invoked with a constant
> argument, so it shouldn't actually be synthesized. Altera's synthesis
> tool seems to handle this with no problem.
>
> When I try to use Synplify to synthesize my design (particularly this
> constant function), the verilog compiler (c_ver) runs out of memory
> (hits the 4GB limit).
>
> Seems like Synplify isn't figuring out that the function doesn't
> actually need to be synthesized.
>
> So I guess the question is two-fold:
>
> 1. is there a better way to encode a large lookup table like that that
> should really only be used at elaboration time?
> 2. is it possible to enable c_ver to run in 64-bit mode, so that it
> can go past the 4G boundary?


When you say the function is only called with a constant argument, is
it truly a constant in terms of the language?  Maybe if you are using
a variable which is initialized to a value and not changed, this is
not so well understood.  Otherwise, I can't think why the entire
function would need to be "implemented" rather than just evaluated.
Which language are you using?

Rick

Ben Gelb <b...@gmail.com> wrote:

> I have a really large lookup table (members of a finite field) encoded
> as a function. This function is only ever invoked with a constant
> argument, so it shouldn't actually be synthesized. Altera's synthesis
> tool seems to handle this with no problem.
 
> When I try to use Synplify to synthesize my design (particularly this
> constant function), the verilog compiler (c_ver) runs out of memory
> (hits the 4GB limit).
 
> Seems like Synplify isn't figuring out that the function doesn't
> actually need to be synthesized.

That doesn't necessarily follow.  It may be doing a lot of work
while figuring out the value to be synthesized.

I have seen similar effects in Fortran compilers for compile
time constant tables, including running out of memory.
(Even for very small tables.)

-- glen
 

Ben Gelb wrote:
> I have a really large lookup table (members of a finite field) encoded
> as a function. This function is only ever invoked with a constant
> argument, so it shouldn't actually be synthesized. Altera's synthesis
> tool seems to handle this with no problem.
> 
> When I try to use Synplify to synthesize my design (particularly this
> constant function), the verilog compiler (c_ver) runs out of memory
> (hits the 4GB limit).
...
> is there a better way to encode a large lookup table like that that
> should really only be used at elaboration time?

I would use Quartus or code the table as a block ROM.


         -- Mike Treseler

On Feb 11, 4:24=A0pm, rickman
<gnu...@gmail.com> wrote:
> On Feb 11, 2:52=A0pm, Ben Gelb <ben.g...@gmail.com> wrote:
>
>
>
>
>
> > I have a really large lookup table (members of a finite field) encoded
> > as a function. This function is only ever invoked with a constant
> > argument, so it shouldn't actually be synthesized. Altera's synthesis
> > tool seems to handle this with no problem.
>
> > When I try to use Synplify to synthesize my design (particularly this
> > constant function), the verilog compiler (c_ver) runs out of memory
> > (hits the 4GB limit).
>
> > Seems like Synplify isn't figuring out that the function doesn't
> > actually need to be synthesized.
>
> > So I guess the question is two-fold:
>
> > 1. is there a better way to encode a large lookup table like that that
> > should really only be used at elaboration time?
> > 2. is it possible to enable c_ver to run in 64-bit mode, so that it
> > can go past the 4G boundary?
>
> When you say the function is only called with a constant argument, is
> it truly a constant in terms of the language? =A0Maybe if you are using
> a variable which is initialized to a value and not changed, this is
> not so well understood. =A0Otherwise, I can't think why the entire
> function would need to be "implemented" rather than just evaluated.
> Which language are you using?
>
> Rick

Hi Rick and all -

Thanks for the replies.

The function is being called with the index from a generate loop. It
does not need to be synthesized. As a comparison, if I build it in
Quartus, the memory usage never peaks higher than ~250MB.

Is there a better way to be doing this? I could probably remove the
generate loops, table and all and just script some Verilog
generation... but would prefer not having to go that route...

I am using Verilog 2001.

Ben