|
|
Partial Reconfiguration - Pin access from within the module
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)
|
|
|
|
|
|
|
|
|