Re: gEDA-user: order of defparam vs. #(.) parameters in icarus

[Matt Ettus <boyscout@xxxxxxxxx>]

On Tue, Feb 10, 2009 at 4:23 PM, Stephen Williams <steve@xxxxxxxxxx> wrote:
> Matt Ettus wrote:
>> In some Xilinx models, they make instantiations like this:
>>
>> block instance(ports);
>> defparam instance.param=VALUE
>>
>>
>> This normally works ok.  The problem is that inside the block,
>> generate statements are being used which are dependent on the value of
>> the parameter.  What appears to be happening is that the block is
>> instantiated, and before the defparam line is "executed", the
>> decisions are made with the default value of the parameter.
>
> The elaboration order of defparams and generate schemes is tricky
> business and there is a very specific order of events. I put a
> lot of painful effort into it, but I'm willing to check my work
> if there is a specific example that generates controversy.

I see the problem when using the Xilinx primitive "BRAM_TDP_MACRO",
which further instantiates "RAMB36" which then instantiates
ARAMB36_INTERNAL".  If you give it inital contents through the use of
the INIT_xx or INIT_FILE parameters, they don't get in.  I can give
you example code if you want, but it is pretty big.

Thanks,
Matt


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user