Archived ISE issues

[aitortxo]

Hi all:

I have MOD1 module that acts as TopModule

I have MOD2 module that contains the coreIP

MOD1 has BoardCLK and BoardRST input signals, and the code to interact with MOD2

MOD2 has it's necessary input and output signals.

I wouldn't like MOD1 to have all input-outputs MOD2 needs and interacts with.

Is it possible to assign pins to MOD2's IOs without defining them on MOD1?

(like NET "MOD2/data_in1" LOC "F5")

IThanks in advance,

Aitortxo.

[davidch]

Although I haven't done it myself I believe this should be possible.  Have you tried using one of the floorplanning tools to accomplish this automatically so that you don't have to figure out the exact pin names?  Or you could use wildcard characters such as the asterisk * in order to not have to put in the hierarchy (as long as the IO names are unique).

David

[aitortxo]

Thanks for the reply, David:

I tried "Assign Package Pins" on ISE, but only appear MOD1's IOs, is there any other floorplanning tool on ISE?

I found this on the Internet:

http://www.fpgamac.com/08_ISE_Integration_Lab.pdf

where appears:

NET "Inst_ppc_system/ppc_reset_bus_Chip_Reset_Req" TPTHRU = "RST_GRP";

So I've started trying MOD2/...iopoint, instMOD2/...iopoint

but no luck.

Then I tried ISE's "Assign Package Pins", but in pin IO list only appears MOD1 (top module) IOs. No way to select submodule, as it doesn't appear in list.

So the third step was this forum.

It appears as if submodule's IOs are treated as internal variables.

The schema of code would be like:

module MOD1( CLK, RST);
 input CLK;
 input RST;
 
 wire MOD2_CLK;
 wire MOD2_RST;
 wire [7:0] DATA2MOD;
 wire [3:0] CTRLMOD;
 wire [7:0] RESULT;
 
MOD2 InstMod2(
 .CLK(MOD2_CLK)
, .RST(MOD2_RST)
, .DATA_I(DATA2MOD)
, .CTRL_I(CTRLMOD)
, .DATA_O(RESULT)
);

//MOD1 CODE

endmodule

module MOD2(CLK, RST, DATA_I, CTRL_I, DATA_O);

// MOD2 CODE

endmodule

When selecting MOD1 as TopModule, only CLK and RST appear as selectable IO pins.

Any clues?

Thanks in advance,

Aitortxo

[gszakacs · Accepted solution]

XST will only add I/O buffers to the top level module I/O.  You can have I/O pins

in the lower level modules, but then you will need to instantiate the I/O buffers

yourself.  Otherwise XST cannot know the nets need to go off the chip.  You

can instantiate IBUF or OBUF components within the lower module.  As you

guessed, the name for the LOC in the .ucf file will contain the hierarchical

path to the module.  You can also use wildcards in the .ucf file, but then

you need to make sure that the port name is unique over the whole

design.  In any case you wouldn't use the lower level module ports as

the pins.  These pins would be nets (regs or wires) internal to the module

and connected to the IBUF or OBUF.

While this practice is not common, it can be useful for re-usable code

that deals with external interfaces.  Also starting in ISE 10.1 you can

have more than one .ucf file associated with the design, which can make

adding this re-usable module to another design simpler.  For example you

can place all of the LOC and IOSTANDARD constraints for the lower

level module I/O in a separate .ucf file that you can port together

with the module code when re-using that part of the design.

Regards,

Gabor

[aitortxo]

Uau! Gabor, what a reply. Thanks a lot.

Ok, let's see if I understood correctly.

1) Only I/O buffered signals appear in placement tools, and also these are the only ones that can be used in an UCF.

2) When a TopModule has IOs, XST on its own generates I/O buffers for those IOs - so they are automatically listed in placement tools.

3) If I would like to use SubModule's IOs, I would have to create IO buffers in SubModule, so XST knows those signals will be connected to pins

4) As those IO buffers are in a SubModule, the naming contains [SubModule's implementation name] + "/" + [IO buffered signal] (for example MOD2/DataOut)

5) This can be done, although it's not very common.

If I understood correctly, the easiest and traditional way is to add SubModule's signals to TopModule, with no problems.

But i have the choice to learn a little about IO Buffers and try a re-usable coding style.

I'll go first with the first one just to prove the design is correct, and when urgency is not so big, I'll give a try to second.

Thanks a lot for the reply,

Aitortxo.

[gszakacs]

1) Only I/O buffered signals appear in placement tools, and also these are the only ones that can be used in an UCF.

Actually only I/O buffered signals can be located to a pin.  Other constraints may be applied to internal nets and

instances including LOC constraints, for example setting the location of a slice to a grid position.  You can place

pretty much everything in the design using the floorplanner, you just need to place it on the appropriate

resource type.

2) When a TopModule has IOs, XST on its own generates I/O buffers for those IOs - so they are automatically listed in placement tools.

This is usually true.  It is possible to turn this off in the Synthesis settings under "Add I/O Buffers", but the default

behavior is as you say.

3) If I would like to use SubModule's IOs, I would have to create IO buffers in SubModule, so XST knows those signals will be connected to pins

Right.

4) As those IO buffers are in a SubModule, the naming contains [SubModule's implementation name] + "/" + [IO buffered signal] (for example MOD2/DataOut)

Again this is the default, but the hierarchy separator can be changed in the synthesis options.  You can for example

use the underscore character instead of the slash character as a hierarchy separator.

5) This can be done, although it's not very common.