Partial Reconfiguration - Pin access from within the module

  • Follow


Hello group,

I am trying to acces some IOB from within a partial reconfigurable 
module (prm).

The arch would look like this:

                       /- IOB
                       |
|---------------------|----|
||--------------| |---|---||
||              | |       ||
|| static part  | |  PRM  ||
||              |-|       ||
||              |-|       ||
||              |-|       ||
||              |-|       ||
||              | |       ||
||              | |       ||
||              | |       ||
||--------------| |-------||
|--------------------------|

Between both modules, there are the busmacros.
Those are working great. Anyway, the IOB located above the prm must be 
connected to the prm. No busmacros. I tried so by connecting the IOB 
(named debug_io(21)) within the toplevel design.
++++++++++++++++++++++++
mod_can_wrapper: mod_can
port map (
....
	id => debug_io(21),
....
	);
++++++++++++++++++++++++

The problem appears while running 'par':
++++++++++++++++++++++++
ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part of 
a slice macro.
        Nets crossing region boundaries must be part of a slice macro
++++++++++++++++++++++++
I remeber setting the -iobuf option of 'xst' to no, so the module itself 
does not add ibufs to the interface signals.


My question is: How can I access IOBs from within the module?

Thanks for your help

Sincerely
	-- Fabian Schuh
0
Reply Fabian 8/12/2009 9:43:32 AM

Fabian Schuh schrieb:
> Hello group,
> 
> I am trying to acces some IOB from within a partial reconfigurable 
> module (prm).
> 
> The arch would look like this:
> 
>                       /- IOB
>                       |
> |---------------------|----|
> ||--------------| |---|---||
> ||              | |       ||
> || static part  | |  PRM  ||
> ||              |-|       ||
> ||              |-|       ||
> ||              |-|       ||
> ||              |-|       ||
> ||              | |       ||
> ||              | |       ||
> ||              | |       ||
> ||--------------| |-------||
> |--------------------------|
> 
> Between both modules, there are the busmacros.
> Those are working great. Anyway, the IOB located above the prm must be 
> connected to the prm. No busmacros. I tried so by connecting the IOB 
> (named debug_io(21)) within the toplevel design.
> ++++++++++++++++++++++++
> mod_can_wrapper: mod_can
> port map (
> ...
>     id => debug_io(21),
> ...
>     );
> ++++++++++++++++++++++++
> 
> The problem appears while running 'par':
> ++++++++++++++++++++++++
> ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part of 
> a slice macro.
>        Nets crossing region boundaries must be part of a slice macro
> ++++++++++++++++++++++++
> I remeber setting the -iobuf option of 'xst' to no, so the module itself 
> does not add ibufs to the interface signals.
> 
> 
> My question is: How can I access IOBs from within the module?
> 
> Thanks for your help
> 
> Sincerely
>     -- Fabian Schuh

Hi there,

found the relevant part in "Xilinx Development System Reference Guide" 
<www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf>

It says on page 110:
+++++++++++++++++++++++++++++
External I/Os in a Module
It is recommended that you declare external I/Os in the top-level 
design. However, you
can include external I/Os in a module without modifying the top-level 
code. This may be
useful if you want to add a temporary external I/O in the module for 
simulation. To do
this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. 
Following are
examples of code.
Note: Do not directly connect these I/Os to module ports.
+++++++++++++++++++++++++++++

Greetz
	-- Fabian
0
Reply Fabian 8/13/2009 8:23:48 AM


Fabian Schuh schrieb:
> Fabian Schuh schrieb:
>> Hello group,
>>
>> I am trying to acces some IOB from within a partial reconfigurable 
>> module (prm).
>>
>> The arch would look like this:
>>
>>                       /- IOB
>>                       |
>> |---------------------|----|
>> ||--------------| |---|---||
>> ||              | |       ||
>> || static part  | |  PRM  ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              | |       ||
>> ||              | |       ||
>> ||              | |       ||
>> ||--------------| |-------||
>> |--------------------------|
>>
>> Between both modules, there are the busmacros.
>> Those are working great. Anyway, the IOB located above the prm must be 
>> connected to the prm. No busmacros. I tried so by connecting the IOB 
>> (named debug_io(21)) within the toplevel design.
>> ++++++++++++++++++++++++
>> mod_can_wrapper: mod_can
>> port map (
>> ...
>>     id => debug_io(21),
>> ...
>>     );
>> ++++++++++++++++++++++++
>>
>> The problem appears while running 'par':
>> ++++++++++++++++++++++++
>> ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part 
>> of a slice macro.
>>        Nets crossing region boundaries must be part of a slice macro
>> ++++++++++++++++++++++++
>> I remeber setting the -iobuf option of 'xst' to no, so the module 
>> itself does not add ibufs to the interface signals.
>>
>>
>> My question is: How can I access IOBs from within the module?
>>
>> Thanks for your help
>>
>> Sincerely
>>     -- Fabian Schuh
> 
> Hi there,
> 
> found the relevant part in "Xilinx Development System Reference Guide" 
> <www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf>
> 
> It says on page 110:
> +++++++++++++++++++++++++++++
> External I/Os in a Module
> It is recommended that you declare external I/Os in the top-level 
> design. However, you
> can include external I/Os in a module without modifying the top-level 
> code. This may be
> useful if you want to add a temporary external I/O in the module for 
> simulation. To do
> this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. 
> Following are
> examples of code.
> Note: Do not directly connect these I/Os to module ports.
> +++++++++++++++++++++++++++++
> 
> Greetz
>     -- Fabian

Hi again,

The verilog example description is more precise:
++++++++++++++++++++
In the following example, the module has two external inputs 
(IPAD_MODA_CLK and
IPAD_MODA_DATA) and one external output (OPAD_MODA_OUT). These external
I/Os, IBUF, OBUF, and BUFGP are instantiated.
The lower-level port declaration is different from the top-level 
declaration of module_a.
Lower-level module_a has three additional ports. With Modular Design, 
NGDBuild
ignores this port mismatch and uses module_a.edf to describe module_a. These
I/Os will be present in the design and available for simulation.
++++++++++++++++++++

Greetz
	-- Fabian
0
Reply Fabian 8/13/2009 8:27:31 AM

2 Replies
129 Views

(page loaded in 0.216 seconds)

Similiar Articles:





7/22/2012 6:35:55 PM


Reply: