On Tue, Feb 10, 2009 at 4:23 PM, Stephen Williams <[email protected]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
