Traversing hierarchy in UCF works for OBUF, but not IOBUF, please help

Hi all,



I have an SDRAM interface buried deep inside the hierarchy.
I was able to instantiate OBUF for the control & address signals and
traverse the hierarchy from the UCF file to tie the signals to the
FPGA pins.

However, when I try to do something similar for the  IOBUFs, I get an
error of the type



INFO:NgdBuild:889 - Pad net 'eight_chan_gen/u1/external_sdram/U1/
DQ<0>' is not connected to an external port in this design.  A new
port 'DQ<0>' has been added and is connected to this signal.



Example of a successful OBUF:

--VHDL file (inside the submodule)

obuf_sdram_a0:    OBUF port map (O => sdram_a0, I => A(0));

--.UCF file

NET "eight_chan_gen/u1/external_sdram/U1/A<0>" LOC="D14";



Example of a failing IOBUF:

--VHDL file (inside the submodule)

   IOBUF_inst0 : IOBUF
   generic map (
      DRIVE => 12,
      IOSTANDARD => "LVCMOS25",
      SLEW => "SLOW")
   port map (
        O => DQ_OUT(0),
      IO => DQ(0),
      I => DQ_IN(0),
      T => nDQ_OE);

--UCF file

NET "eight_chan_gen/u1/external_sdram/U1/DQ<0>"   LOC = "A4";



Any suggestions?



Thanks in advance!

On Sep 8, 12:13=A0pm, Telenochek <elet.mir...@gmail.com> wrote:
> Hi all,
>
> I have an SDRAM interface buried deep inside the hierarchy.
> I was able to instantiate OBUF for the control & address signals and
> traverse the hierarchy from the UCF file to tie the signals to the
> FPGA pins.
>
> However, when I try to do something similar for the =A0IOBUFs, I get an
> error of the type
>
> INFO:NgdBuild:889 - Pad net 'eight_chan_gen/u1/external_sdram/U1/
> DQ<0>' is not connected to an external port in this design. =A0A new
> port 'DQ<0>' has been added and is connected to this signal.
>
> Example of a successful OBUF:
>
> --VHDL file (inside the submodule)
>
> obuf_sdram_a0: =A0 =A0OBUF port map (O =3D> sdram_a0, I =3D> A(0));
>
> --.UCF file
>
> NET "eight_chan_gen/u1/external_sdram/U1/A<0>" LOC=3D"D14";
>
> Example of a failing IOBUF:
>
> --VHDL file (inside the submodule)
>
> =A0 =A0IOBUF_inst0 : IOBUF
> =A0 =A0generic map (
> =A0 =A0 =A0 DRIVE =3D> 12,
> =A0 =A0 =A0 IOSTANDARD =3D> "LVCMOS25",
> =A0 =A0 =A0 SLEW =3D> "SLOW")
> =A0 =A0port map (
> =A0 =A0 =A0 =A0 O =3D> DQ_OUT(0),
> =A0 =A0 =A0 IO =3D> DQ(0),
> =A0 =A0 =A0 I =3D> DQ_IN(0),
> =A0 =A0 =A0 T =3D> nDQ_OE);
>
> --UCF file
>
> NET "eight_chan_gen/u1/external_sdram/U1/DQ<0>" =A0 LOC =3D "A4";
>
> Any suggestions?
>
> Thanks in advance!

How did you instantiate the modules between this and the top?
Are all connections "inout" through the whole hierarchy including
the top level port?

On Sep 8, 9:13=A0am, Telenochek <elet.mir...@gmail.com> wrote:
> Hi all,
>
> I have an SDRAM interface buried deep inside the hierarchy.
> I was able to instantiate OBUF for the control & address signals and
> traverse the hierarchy from the UCF file to tie the signals to the
> FPGA pins.
>
> However, when I try to do something similar for the =A0IOBUFs, I get an
> error of the type
>
> INFO:NgdBuild:889 - Pad net 'eight_chan_gen/u1/external_sdram/U1/
> DQ<0>' is not connected to an external port in this design. =A0A new
> port 'DQ<0>' has been added and is connected to this signal.
>
> Example of a successful OBUF:
>
> --VHDL file (inside the submodule)
>
> obuf_sdram_a0: =A0 =A0OBUF port map (O =3D> sdram_a0, I =3D> A(0));
>
> --.UCF file
>
> NET "eight_chan_gen/u1/external_sdram/U1/A<0>" LOC=3D"D14";
>
> Example of a failing IOBUF:
>
> --VHDL file (inside the submodule)
>
> =A0 =A0IOBUF_inst0 : IOBUF
> =A0 =A0generic map (
> =A0 =A0 =A0 DRIVE =3D> 12,
> =A0 =A0 =A0 IOSTANDARD =3D> "LVCMOS25",
> =A0 =A0 =A0 SLEW =3D> "SLOW")
> =A0 =A0port map (
> =A0 =A0 =A0 =A0 O =3D> DQ_OUT(0),
> =A0 =A0 =A0 IO =3D> DQ(0),
> =A0 =A0 =A0 I =3D> DQ_IN(0),
> =A0 =A0 =A0 T =3D> nDQ_OE);
>
> --UCF file
>
> NET "eight_chan_gen/u1/external_sdram/U1/DQ<0>" =A0 LOC =3D "A4";
>
> Any suggestions?
>
> Thanks in advance!

If the net had been succesfully brought all the way to a port at the
top level of the design the name should not include hierarchy.

Ed McGettigan
--
Xilinx Inc.

I would prefer to avoid bringing all the ports to top level.

I should be able to LOC constrain any internal signal of choice?

On Sep 9, 10:46=A0am, Telenochek <elet.mir...@gmail.com> wrote:
> I would prefer to avoid bringing all the ports to top level.
>
> I should be able to LOC constrain any internal signal of choice?

You should be able to, theoretically, but in the end it is useful
to have access to the board pins from the top level module as
it makes it much easier to attach them to the SDRAM simulation
model in your testbench.

On Sep 9, 7:46=A0am, Telenochek <elet.mir...@gmail.com> wrote:
> I would prefer to avoid bringing all the ports to top level.
>
> I should be able to LOC constrain any internal signal of choice?

IMHO not bring your IO to the level is a mistake for the following
reasons

- Signals that aren't used or driven are usually removed from the
design during synthesis
- Synthesis won't "know" to insert IO buffers on these nets requiring
the IO buffers to be instantiated in the HDL
- System level simulation won't be possible as the IOs are not
accessible

Ed McGettigan
--
Xilinx Inc.

Not really helpful with the original question, unfortunately.

Xilinx MIG (memory interface generator) hides I/Os deep in the design
hierarchy.
Too bad I don't have access to the code to see what the proper syntax
is.

"System level simulation won't be possible as the IOs are not
accessible"
Sorry to correct you here, but attaching SDRAM simulation models to
dedicated internal controller blocks is even easier than to the top
level.

Finally, making the design internal makes it much more portable, as
you can simply pass the controller interface with instantiated I/O
buffers and I/O to one of your engineers, and they never have to do
anything but work with the interface.

BTW, Xilinx realized recently that this is much more advantageous from
hardware standpoint than the ancient top level driven designs: the
latest ISE 10 allows multiple .ucf files for this reason.

Not really helpful with the original question, unfortunately.

Xilinx MIG (memory interface generator) hides I/Os deep in the design
hierarchy.
Too bad I don't have access to the code to see what the proper syntax
is.

"System level simulation won't be possible as the IOs are not
accessible"
Sorry to correct you here, but attaching SDRAM simulation models to
dedicated internal controller blocks is even easier than to the top
level.

Finally, making the design internal makes it much more portable, as
you can simply pass the controller interface with instantiated I/O
buffers and I/O to one of your engineers, and they never have to do
anything but work with the interface.

BTW, Xilinx realized recently that this is much more advantageous from
hardware standpoint than the ancient top level driven designs: the
latest ISE 10 allows multiple .ucf files for this reason.

On Sep 9, 10:35=A0pm, Telenochek <elet.mir...@gmail.com> wrote:
> Not really helpful with the original question, unfortunately.
>
> Xilinx MIG (memory interface generator) hides I/Os deep in the design
> hierarchy.
> Too bad I don't have access to the code to see what the proper syntax
> is.
>
> "System level simulation won't be possible as the IOs are not
> accessible"
> Sorry to correct you here, but attaching SDRAM simulation models to
> dedicated internal controller blocks is even easier than to the top
> level.
>
> Finally, making the design internal makes it much more portable, as
> you can simply pass the controller interface with instantiated I/O
> buffers and I/O to one of your engineers, and they never have to do
> anything but work with the interface.
>
> BTW, Xilinx realized recently that this is much more advantageous from
> hardware standpoint than the ancient top level driven designs: the
> latest ISE 10 allows multiple .ucf files for this reason.

Actually, I think that the suggestion to bring the IO ports to the top
level is helpful to your orginal question as it appears that the net
name on the IO port of the IOBUF is different than you expected it to
be and this would solve the problem.

One addition suggestion, since you don't want to propogate the signal
then try adding the LOC to the instance name which likely has not
changed.

INST "eight_chan_gen/u1/external_sdram/U1/IOBUF_inst0"   LOC =3D "A4";

With respect to your comments on the MIG output, the physical level
interface is presented on the core interface with the intent that nets
are connected to the top level ports in the design.  This is shown in
all of the design examples.

I have no idea how "attaching SDRAM simulation models to the dedicated
internal memory blocks" is easier.   Please elaborate on why this is
easier to use and maintain between simulation and synthesis.

Ed McGettigan
--
Xilinx Inc.

On Wed, 9 Sep 2009 23:09:58 -0700 (PDT), Ed McGettigan
<ed.mcgettigan@xilinx.com> wrote:

>On Sep 9, 10:35&#4294967295;pm, Telenochek <elet.mir...@gmail.com> wrote:
>> Not really helpful with the original question, unfortunately.
>>
>> Xilinx MIG (memory interface generator) hides I/Os deep in the design
>> hierarchy.
>> Too bad I don't have access to the code to see what the proper syntax
>> is.
>>
>> "System level simulation won't be possible as the IOs are not
>> accessible"
>> Sorry to correct you here, but attaching SDRAM simulation models to
>> dedicated internal controller blocks is even easier than to the top
>> level.

>I have no idea how "attaching SDRAM simulation models to the dedicated
>internal memory blocks" is easier.   Please elaborate on why this is
>easier to use and maintain between simulation and synthesis.

I haven't done this; I confess I hadn't thought of it (being blinded by starting
from the Xilinx examples) but I can see how it would work...

You create a DDR block, e.g. a wrapper covering (MIG, all external ports, the
logic you must add to make MIG usable, AND the sim models) and then test the
hell out of it (a testbench instantiates the whole block).

For synthesis, the IOBs are inserted as instantiated, and the sim models are not
(they are guarded by "translate" pragmas).

This whole block can be dropped into a user design without having to add
superfluous ports on the instantiating block; the top level block; every
hierarchical level in between; AND the testbench. 

That eliminates a huge maintenance task, e.g. when you later change the memory
size, you have to add address and BA bits to every level and the testbench too.
Oh and you used this subsystem in a couple of dozen designs, so you have to
update over a hundred files to let someone plug a bigger SODIMM into the ML505.

Better to keep the I/Os and the sim models in the instantiated block; and simply
drop that, whole, into a user design. Just solve the tool flow issues first...

For an even better example of the maintenance nightmare approach, take a look at
how I/O signals are routed in the insane PCIe endpoint example design, as
created by Coregen.

- Brian