问题
is there a way to synthesize an architecture in verilog such that a deeply nested endpoint can access some top level pins (from a .ucf) without expressly routing the pins through every module of the hierarchy.
In my case i have a PCIe block with a deeply nested endpoint. AT the endpoint there have an address decoder that needs to provide some signal information from pins at the top level.
I'd rather not modify every intervening module to carry the necessary wires.
my web searches are frustrated because the terms 'net' and 'bus' already have alternative meanings in verilog.
I have tried specific hierarchical naming like (for example) top.button and top.LED but have only succeeded in getting access to readable pins, but not writeable pins, leading me to assume i'm missing something fundamental here.
UPDATE I can simulate this http://www.edaplayground.com/x/AAq
and synthesize (a similar construct) without error (Xilinx XST) but there is no output on the LED when it is run in real hardware so i'm wondering if upwards name reference is not supported for synthesis?
回答1:
Have you tried explicitly naming the complete hierarchical path of the pin you want to access?
For example, lets say your top module instance name is top, and then five level down the hierarchy you need to access top's pin x and assign it to the local variable y:
//At level 5:
assign y = top.x
Some synthesis tools support $top. In that case, you can try:
//At level 5:
assign y = $top().x
Here is a working example on edaplayground.com (I have not tried synthesis).
For more info, see "Upwards name referencing" in Section 23.8 of IEEE 1800-2012
回答2:
Yes, this is possible and synthesisable using some tools. The only mechanism I'm aware of is to use a static variable in a function to create the "connection", calling the function once to set the value and once to get the value.
For an example of this, check out my proof-of-concept on Github
SystemVerilog proof-of-concept for using static variables inside functions to communicate between modules.
This allows connections to be made without having to add wiring through the hierarchy. Possible applications include pulling signals out to logic analyser, writing to global resources (event log, statistics, UART etc.)
This synthesises correctly in Quartus 13, I haven't tried it with other tools so YMMV.
UPDATE: Not currently supported by Xilinx Vivado, see this thread for details.
回答3:
If known about at the time of implementation, using SystemVerilog Interfaces Section 3.5 and 25 of IEEE 1800-2012 can solve this issue.
An interface is a named bundle of nets, so if everything in the path connects to the interface, adding an extra net to the interface means all instances of that interface get the extra wire.
Adding signals to the interface allows low level modules to be instantly connected to everything else (top level) using that bus, without any additional port work to connect once the interface is connected through the hierarchy.
Interfaces vs Structs has been discussed previously.
A Doulos Tutorial on interfaces.
For a slightly more complete answer I include the example given in 25.3.3 IEEE 1800 showing to modules connected via an interface:
// memMod and cpuMod can use any interface
module memMod (interface a, input logic clk);
...
endmodule
module cpuMod(interface b, input logic clk);
...
endmodule
interface simple_bus; // Define the interface
logic req, gnt;
logic [7:0] addr, data;
logic [1:0] mode;
logic start, rdy;
endinterface: simple_bus
module top;
logic clk = 0;
simple_bus sb_intf(); // Instantiate the interface
// Reference the sb_intf instance of the simple_bus
// interface from the generic interfaces of the
// memMod and cpuMod modules
memMod mem (.a(sb_intf), .clk(clk));
cpuMod cpu (.b(sb_intf), .clk(clk));
endmodule
Using modports (Section 25.5 of IEEE 1800) you can specify master slave sections of the interface to define port directions.
As Tim has mentioned I avoid using this as it becomes very difficult to debug. I have worked on one project where interfaces were heavily used. The connections were not one to one, but propagated everywhere through the hierarchy. Imagine register writes happening over LBUS, using WiredOR bus or tristate for the readback. The tools we had at the time would not let you see which module was driving the bus. Therefore if it went X from multiple drives it was a guessing game as to what was causing it.
We were not using interfaces only for standard protocols like LBUS but new ones which were being altered on the fly, which meant modules that had not been fixed for protocol changes corrupted the bus. Using interfaces greatly sped up the implementation as extra signal were quick to integrate. The cost was almost impossible to debug as the source of issues on the interface could not be traced.
来源：https://stackoverflow.com/questions/24591396/access-top-level-resources-outside-of-hierarchy