Below I do have following two VHDL files. The file x.vhd with a component x which needs to be referenced (included) in the file top.vhd as a package.
-- x.vhd
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
package x_pkg is
component my_x
port(clk_clk : in std_logic := '0';
reset_reset_n : in std_logic := '0';
end component my_x;
end package x_pkg;
-----------------------------------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
entity x is
port (
clk_clk : in std_logic := '0'; -- clk.clk
reset_reset_n : in std_logic := '0'; -- reset.reset_n
);
end entity x;
architecture rtl of x is
This package needs to be referenced in following top-file:
-- top.vhd
library ieee;
use ieee.std_logic_1164.all;
library altera;
use altera.altera_syn_attributes.all;
use work.x_pkg.all;
entity EyeTracker_Top is
port
(
Nios_Clk : in std_logic;
Nios_Reset_n : in std_logic;
);
end EyeTracker_Top;
architecture struct of EyeTracker_Top is
begin
M1 : my_x port map(Nios_Clk, Nios_Reset_n); -- Here I get the error message!
After compiling, it get following error message:
***Error (12006): Node instance "M1" instantiates undefined entity "my_x"
What is the problem here? I guess there is something wrong with the package reference...
Thanks!
You are instantiating a component my_x. A component is just a declaration, a kind of empty shell. Every component instantiation must at some point be bound to an actual entity/architecture pair. This binding must be done with an explicit configuration. There are several ways to do this. One is to add:
for all: my_x use work.x(rtl);
in the declaration area of your architecture (between architecture and begin). Of course, the entity x and its architecture rtl must be compiled in the library you use as work before you can elaborate your top level.
The error message you got is difficult to understand because your tool tries to apply a default configuration strategy based on names: for unbound instances of components it searches an entity with the same name as the component. Because it found none, it complains about a missing entity while it is a component binding problem, that is, a missing configuration. A better tool would tell you that the M1 instance of component my_x is not bound.
A last note: if all this component stuff is too complicated for your needs, just get rid of it and directly instantiate your entity:
M1: entity work.x(rtl) port map(Nios_Clk, Nios_Reset_n);
and you will need no component declaration and no configuration.
There are basically two approaches:
top-down design with components instantiations and configurations,
bottom-up design with entity instantiations, no components and no configurations.
Understanding the differences between the two, their pros and cons is not easy. And there, a good VHDL book is probably better than questions and answers on stackoverflow.
Related
I am reading Autosar document and in one of the document (Autosar_TemplateModelingGuideline.pdf), it says that:
Composite aggregation, forming a whole-part relationship
Regular association, expressing a reference from the associating to
the associated model element
My question is: what is the difference between these two in practice? How do I have to interpret them in a class diagram, e.g. the Com Module in Autosar.:
The AUTOSAR COM module’s Configuration Overview
Consider Specified class ComGwSignalRef surrounded with a red rectangle. This class has a composition relation with ComGwSignalRef class and two regular association with ComGroupSignal and ComSignal.
How would you interpret this as a developer and how do you implement in C?
if regular association is a reference to an object that has independent life from ComGwSignalRef why designer do not use instanceRef here?
if it is not a reference, why did the designer not use composition?
PS. There is a concept in Autosar "InstanceRef" which is used for reference for independent object with independent lifecycle.
Maybe you should also consider the following:
The Com Configuration is an instance of the EcuC configuration meta-model as defined in the AUTOSAR_TPS_EcuConfiguration.
The ComGwSignalRef is of type EcucChoiceContainerDef, and as such, the two destination associations of ComSignal and ComGroupSignal have a meaning. Only one of these "choices" can be selected in the final configuration as a reference. In AUTOSAR metamodel, that is the definition of how EcucChoiceContainerDef works, in UML you might need here an additional constraint element to define the XOR relation of two associations.
An object can only be composed as part of one object.
A <>- C -<>B
In the diagram above C is composed in A and B. This would lead to the following instances:
a: A <>- c: C -<> b:B
Now the specific instance c is now part of both a and b.
What happen would with c if b goes out of scope? By the semantics it should be destroyed and not be destroyed (a still exists).
Or more pointed:
Take Alice,Bob, and Collar Bone as examples. Alice’s collar bone cannot be part of Bob.
UML is a modeling language and has not the same expressiveness as, say a C compiler. This is by design to simplify things.
Remember: All models are wrong, but some are useful. — George E. P. Box
I intend to use the MapWinGis component in Delphi 10.3
There are a number of errors when compiling this component
Has anyone used this component to guide me?
I had the same problem. As fpiette told you, you should change 'result' to 'AResult' in all functions producing this error.
function TShapefile.SelectShapes(const BoundBox: IExtents; Tolerance: Double; SelectMode: SelectMode; var AResult: OleVariant): WordBool;
begin
Result := DefaultInterface.SelectShapes(BoundBox, Tolerance, SelectMode, AResult);
end
You must also change it in the interface section of MapWinGIS_TLB.pas.
Unfortunately that's not all. Compilation and linking is now possible but I got errors to register the classes TImage, TShape, TPoint, TTable, TLabel, TChart, TGrid, TField because Delphi already uses these names for classes.
So, you must rename these classes (TImage to TMWImage, etc.) in MapWinGIS_TLB.pas.
Afterwards registration of these classes is working and the component TMap should be shown in the ActiveX tab or the tab you defined.
Animal
deferred class ANIMAL
inherit
ANY
redefine
default_create
end
feature
creator: like Current
guts: GUTS
default_create
do
create guts
end
make_malformed
do
default_create
end
end --class
PIG
class PIG
inherit
ANIMAL
redefine
make_malformed
end
create
default_create,
make_malformed,
make_from_insemination
feature
guts: GUTS
make_malformed
do
Precursor
set_left_eye (create {MALFORMED_EYE})
end
make_from_insemination (some_humain: HUMAIN)
do
default_create
creator := some_humain
end
end --class
Into my vision of best practices, I'll say that
If there is no particular sense of making a creation procedure (like my make_malformed example) redefine the default_create
All creation procedure should call default_create and add specific behavior (like my make_from_db example)
So what is the purpose of many libraries in Eiffel which are adding a make like create {LINKED_LIST}.make
Correct me if I'm wrong. Thanks in advance!
Many Eiffel libraries were developed before default_create was added to ANY with the corresponding semantics. This explains why many classes of the base library do not use it.
Also, creation procedures can carry some specific sense. For example, make can create a container that compares internal objects using reference equality whereas make_equal can create a container that uses object equality instead (this is the case for HASH_TABLE, though there is an additional argument to indicate an expected number of elements, this argument could be omitted with some other design choice). In such cases, default_create and default_create_equal would be non-symmetric, whereas make and make_equal are symmetric, so that the design is more consistent.
As you point out, default_create should not carry any specific behavior, just some basic things, expected from all descendants.
Whether default_create should be called by all other creation procedures heavily depends on the design. One example, where this is almost a rule, is the library "vision" that encodes in default_create a correct order of initialization, crucial for void safety. It's still possibly to write a class (based on this library) that performs the initialization correctly without calling default_create in its creation procedure, but having a ready-to-follow patters simplifies development.
I am trying to write bindings for a C library, specifically the libnfc. My current code is available on Github.
One of the central structures in the libnfc is the device. It is represented by the Go type Device.
type Device struct {
d *C.nfc_device
}
All functions inside the libnfc that operate on a Device are methods of it. Now, there are other C libraries (e.g. the libfreefare) whose APIs operates on nfc_devicees. For the sake of modularity, I want to place the code for each library I wrap into its own module. This leads to the problem, that I can't access private structure members from within other modules. I thought about the following solutions:
Make d a public member of Device
This would make it easy to access the underlying nfc_device from within other modules, but it makes it also easy to sidestep type safety. Additionally, I don't know whether cgo recognizes pointers to foreign types if they come from different modules. Finally, I lose flexibility if I change the structure of the Device type.
Add an accessor func (Device) GetCPtr() unsafe.Pointer
This solves the issues above but introduces the new issue that you suddently have access to an unsafe.Pointer in a module that might not even import unsafe.
Add an accessor func (Device) GetCPtr() uintptr
This solves the aforementioned issue, as you have to manually cast the result to get a proper pointer.
Are there any ways I missed? Is there a better, more idiomatic way to provide access to the underlying nfc_device?
I'm generally in favour with the third proposal of yours as this is the way the reflect package
handles this issue.
What you could also do is to expose only an interface in your libnfc wrapper, e.g.
type NFCDevice interface {
Read() ([]byte, error)
Write() ([]byte, error)
// ...
}
Now you have a public API that is safe.
Additionally, your device type implements a function
func (d *device) NfcDevice() *C.nfc_device {
return d.nfc_device
}
which you can use in your other wrappers by asserting your NFCDevice to implement the
interface
interface {
NfcDevice() *C.nfc_device
}
which you can create on the fly in the other wrappers. This way a programmer has to deliberately
do something to access the inner workings of your device.
I've been getting errors when trying to do many-to-many relations in Slick. This test shows how to do many-to-many relations in Slick. I followed it but then go this error:
Select(TableNode, "id") found. This is typically caused by an attempt to use a "raw" table object directly in a query without introducing it through a generator
I then found out that this is caused by declaring your tables at a static location (an object) and then trying to import it (it works fine if the object is in the same block). http://slick.typesafe.com/doc/1.0.0/lifted-embedding.html#tables
Ok, so val T = new Table inside of an object is the answer. But now I'm getting this error:
recursive method bs needs result type
It doesn't need a result type if it is an object and not a val. I've heard of using a class but I can't find any examples on how to do this.
How do you declare many-to-many models and import them from somewhere else?
EDIT:
Here's a gist showing what I mean: https://gist.github.com/pjrt/5332311
If you run the first test, it will pass, no issue.
If you run the second test, the following error is thrown:
scala.slick.SlickException: Select(TableNode, "id") found. This is typically caused by an attempt to use a "raw" table object directly in a query without introducing it through a generator.
If you run the third test (using vals inside of objects instead of objects directly), you get this error:
recursive method bs needs result type
[error] val A = new Table[(Int, String)]("a") {
recursive value AToB needs type
[error] def as = AToB.filter(_.bId === id).flatMap(_.aFK)
I know why the errors are happening, but I want to know how people got around them. One way is to put the objects inside of a class and instantiating a class every time you want to use Slick (but this seems...weird). Another is to never use Slick-related stuff outside of the package (or at least many-to-many stuff) but that also seems bad.
My question, still is, how do you guys get around this? Is there a proper way?
The error message you showed makes me think that you defined your tables but tried to access them directly instead of using a for comprehension.
The test file you were referring has an example right at the bottom, after defining the many-to-many tables that goes like
val q1 = for {
a <- A if a.id >= 2
b <- a.bs
} yield (a.s, b.s)
q1.foreach(x => println(" "+x))
assertEquals(Set(("b","y"), ("b","z")), q1.list.toSet)
What you see is that object table A is used as a comprehension generator (i.e. a <- A)
Does your code access the tables in some other way?