For example, is the following code legal (with regard to the way that the modules signals are mapped), or do I have to define explicit wires to connect the modules?
module A(
output logic x;
);
module B(
input logic y;
);
A instanceOfA();
B(
.y(instanceOfA.x)
);
You can for simulation, but most synthesis tools do not accept hierarchical references.
Yes you can do that. But it's better to take a common net, which which will be driven by multiple modules.
module top ();
wire common;
A instance_a (common);
B instance_b (common);
endmodule
Related
I'm trying to have two different objects that refer to each other and also use type checking on the attributes. When I do this I get Circular module loading detected trying to precompile. Googling gets me https://docs.raku.org/language/faq#Can_I_have_circular_dependencies_between_modules? which states:
Note that Raku has no “1 file = 1 class” limitation, and circular dependencies within a single compilation unit (e.g., file) are possible through stubbing. Therefore another possible solution is to move classes into the same compilation unit.
I'd rather not put both classes into the same unit if I can avoid it. I'm not sure how to accomplish this with stubbing since there is no example. The following is a small example of what I'm trying to do:
Yak.rakumod
unit class Yak;
use YakStore;
has YakStore $.yak-store is rw;
YakStore.rakumod
unit class YakStore;
use Yak;
has Yak $.yak is rw;
yak.rakutest
use lib '.';
use Test;
use Yak;
use YakStore;
plan 2;
my $yak-store = YakStore.new;
my $yak = Yak.new(:$yak-store);
$yak-store.yak = $yak;
isa-ok $yak-store.yak, Yak;
isa-ok $yak.yak-store, YakStore;
Yeah, I know, the test is lame, but I just wanted to illustrate the problem. Thanks!
The best way to deal with circular dependencies is to turn your circle into a triangle – that is, to make both classes that would depend on each other instead depend (at least in part) on some third Role.
Here's how that might look with the example you provided and a Shaveable role (Yaks should be Shaveable, right?):
Shaveable.rakumod
unit role Shaveable;
Yak.rakumod
use YakStore;
use Shaveable;
unit class Yak does Shaveable;
has YakStore $.yak-store is rw;
YakStore.rakumod
use Shaveable;
unit class YakStore;
has Shaveable $.yak is rw;
With that change, the tests in your example now pass.
I want to write a testbench for a module that instantiates several components but has no significant outputs. To test the correctness I'd have to access variables of components of the uut. At least being able to access variables of the uut would be helpful.
I would imagine that to work a little like this:
uut: top_module port map(
i_clk => clk,
i_reset => reset
);
testbench: process
begin
wait for CLK_PERIOD;
report STD_LOGIC'image(top_module.flag) severity note;
end process;
Of course I can write the testbench in a way that it replaces the top module but then I wouldn't be able to test that model. Expanding the output of the top module/uut is also not really an option.
With VHDL 2008 you can use the new external names syntax:
alias int1 << signal .tb_top.u_ioc.int1 : std_logic >>;
With an earlier VHDL standard you have to use vendor-specific tools, e.g. signal_spy for Questa/ModelSim.
Another method would be to write your testbench at a lower level, e.g. connect your sub-components inside the testbench instead of testing the highest-level entity.
I am in the process of writing some Verilog modules for an FPGA design. I looked around the internet to find out how I best parametrize my modules. I see two different methods occurring often. I included an example hereunder of the two different methodologies.
Which of these methods is the best way to parametrize modules?
What is the difference?
Is it vendor-dependent (Altera vs Xilinx)?
The first method:
Module definition:
module busSlave #(parameter DATA_WIDTH = 1) (
input [DATA_WIDTH-1:0] bus_data,
input bus_wr,
...
);
endmodule
Module instantiation:
module top;
//DATA_WIDTH is 32 in this instance
busSlave #(.DATA_WIDTH(32)) slave32(
.bus_data(data_0),
.bus_wr(wr_0),
...
);
//DATA_WIDTH is 64 in this instance
busSlave #(.DATA_WIDTH(64)) slave64(
.bus_data(data_1),
.bus_wr(wr_1),
...
);
endmodule
The second method:
Module definition:
module busSlave(
parameter DATA_WIDTH = 1;
input [DATA_WIDTH-1:0] bus_data,
input bus_wr,
...
);
endmodule
Module instantiation:
module top;
//DATA_WIDTH is 32 in this instance
busSlave slave32(
.bus_data(data_0),
.bus_wr(wr_0),
...
);
defparam slave32.DATA_WIDTH = 32;
//DATA_WIDTH is 64 in this instance
busSlave slave64(
.bus_data(data_1),
.bus_wr(wr_1),
...
);
defparam slave32.DATA_WIDTH = 64;
endmodule
Thanks in advance
EDIT: a few corrections in the examples
The defparam statement is scheduled for deprecation. The IEEE Std 1800-2012, Annex C (Deprecation), section "C.4.1 Defparam statements" states:
users are strongly encouraged to migrate their code to use one of the
alternate methods of parameter redefinition.
Many features of Verilog are vendor-dependent.
I would like to declare some "user-defined compiler-constants" to keep my specification files as "constant" as possible. This is something common in C++, e.g. :
// misc/config.hh
namespace misc
{
typedef std::shared_ptr<A> A_ptr;
namespace arch = ibmpc;
}
// misc/code.hh
#include "misc/config.hh"
namespace misc
{
void function p(A_ptr a);
}
Which would be in Ada :
-- misc.ads
package Misc is
use Types; ----> forbidden !
procedure P(A : A_Access);
end Misc;
-- misc-types.ads
package Misc.Types is
type A_Access is A'Access;
end Misc.Types;
Of course this does not work since use is a context keyword...hence my question : how is it possible to do something with the same results in Ada ?
I think this is a reasonable mapping from your C++ original to Ada:
To start with, corresponding more-or-less, I think, to your namespace misc, in file misc.ads,
package Misc is
end Misc;
Then, corresponding to config.hh, in file misc-config.ads,
package Misc.Config is
type A is (For_Example, An_Enumeration);
type A_Access is access A;
end Misc.Config;
(which could, of course, also reference types in Misc). Then, corresponding to code.hh, in file misc-code.ads,
with Misc.Config;
package Misc.Code is
use Config;
procedure P (A : A_Access);
end Misc.Code;
Personally I wouldn’t use Config;, at any rate in specs - it can make it difficult to work out where something is defined. Note, you can say use Config; or use Misc.Config; where shown, because you’re in a child of Misc; in the context clause, which is also OK, you would have to use Misc.Config;.
Ok, while I see what you're trying to do you're going about it wrong.
The problem you have with the given sniplets is this: circular dependency.
Now Ada has a great way of managing circular dependency by making it non-circular (in a sense) through it's use of specs and bodies. As the two are discrete, we can have two sets of spec/body files where the body references the other's spec precisely because the specs are publicly visible.
As an example, admittedly ridiculous; let's use fountain-pens and ink-cartridges.
With Cartridge;
Package Pen is
Subtype Model_Number is Positive Range 1000..3304;
Type Fountain_pen is private;
-- Pen procedures
private
Type Fountain_pen is Record
Model : Model_Number;
Ink : Cartridge.Ink_Cartridge;
end record;
end Pen;
and
With Pen;
Package Cartridge is
Type Ink_Cartridge is private;
-- Ink procedures
private
Type Ink_Cartridge is record
Color : Integer; -- I'm being lazy.
This_Pen : Pen.Fountain_pen;
end record;
end Cartridge;
and
Package Body Pen is
--- Pen Stuff
end Pen;
Package Body Cartridge is
-- Ink stuff
end Cartridge;
(Not compiled.)
I forget how to create a component of a circularly-nested type though... Anyway, you should get the general idea there. But what you're wanting is fundamentally different than mutually dependent types; what you want is some sort of container for your constants.
I would recommend using child packages. Something like Misc and Misc.Constants; where you place your base-types into Misc, and the constants into Misc.Constants. If your types are dependent on your constants you might make a separate child package for them Misc.Types and use the mutual withing as shown above.
You could put the child package spec inside the parent package spec, like this:
package Misc is
package Types is
type A is private;
type A_Access is access A;
-- other stuff
end Types;
procedure P (A : Types.A_Access);
end Misc;
you can even use Types; after the declaration of Misc.Types.
I would like to design 2 modules A and B which both have their own functions, for instance: A.compare: A.t -> A.t -> bool, B.compare: B.t -> B.t -> bool. The elements of A and B are convertible. So I would also need functions a_of_b : B.t -> A.t and b_of_a : A.t -> B.t. My question is where I should define these functions? inside the structure of A or the one of B or somewhere else?
Could anyone help?
Edit1: just amended some errors based on the first comment
This is a classic design problem. In OOP languages, it is hard to resolve this elegantly because a class encapsulates both a type definition and methods related to that type. Thus, as soon as you have a function such as a_of_b, which regards two types to an equal extent, there is no clear place for it.
OCaml correctly provides distinct language mechanisms for these distinct needs: type definitions are introduced with the keyword type, and related methods are collected together in a module. This gives you greater flexibility in designing your API, but does not solve the problem automatically.
One possibility is to define modules A and B, both with their respective types and compare functions. Then, the question remaining is where to put a_of_b and b_of_a. You could arbitrarily give preference to module A, and define the functions A.to_b and A.of_b. This is what the Standard Library did when it put to_list and of_list in Array. This lacks symmetry; there is no reason not to have put these functions in B instead.
Instead you could standardize on using of_ functions vs to_ functions. Let's say you prefer to_. Then you would define the functions A.to_b and B.to_a. The problem now is modules A and B are mutually dependent, which is only possible if you define them in the same file.
If you will have lots of functions that deal with values of type A.t and B.t, then it may be worth defining a module AB, and putting all these functions in there. If you will only need two, then an extra module is perhaps overkill.
On the other hand, if the total number of functions regarding A's and B's is small, you could create only the module AB, with type a, type b, and all related methods. However, this does not follow the OCaml community's convention of naming a type t within its own module, and it will be harder to apply the Set and Map functors to these types.
You probably mean A.compare: A.t -> A.t -> bool because types are in lower cases.
You can have a single module AB which contains both the type for A and the type for B.
You can have a single module AB containing both A & B as sub-modules.
You might also use recursive modules & functors.