I am new in quartus. one of my home work was to implement a full adder with two half adder in quartus. now I created half adder but I don't know how to use it in other schematic file to implement full adder.
thanks.
You have to export your half adder to a .bdf file (File > Create/Update > Create Symbol Files for Current File) and then use it as a symbol (i.e. just like other gates) in another schematic files.
Related
I have my own function which I want to use via scifunc_block_m block. The function is defined in an .sci file, as suggested in this answer. Running the script from the scilab console before starting the simulation works fine. However, if I call exec() of this very .sci under xcos Simulation -> Set Context instead, the function seem to remain unknown in xcos. Am I missing something about the context setting?
It began with a function typed into scifunc_block_m or expression block. However,
I didn't want to make the block big and was unable to use .. to split the function definition over multiple lines to prevent the text spilling over the block boundaries.
The function will be used several times, I wanted a single definition vs copy&paste.
For the Set Context part:
I guess that you must specify the absolute path of fader_func.sci, either directly in the set Context box, or through a variable defined in the console:
--> fader_PATH = "C:\the\path\fader_func.sci"
// Then in the Context box;
exec(fader_PATH,-1);
Or directly in the Context box (far less portable solution):
exec("C:\the\path\fader_func.sci", -1);
about scifunc_block_m input
Continuation dots are unlikely supported. Instead, have you tried to explicitly split any long instruction in several shorter ones?
tmp = tanh((u3-u1+u2/2)/0.25/abs(u2))
y1 = 0.5 + sign(u2)*tmp/2
I define an outer syntax command, imake to write some code to a file and do some other things. The intended usage is as follows:
theory Scratch
imports Complex_Main "~/Is0/IsS"
begin
imake ‹myfile›
end
The above example will write some contents to the file myfile. myfile should be a path relative to the location of the Scratch theory.
ML ‹val this_path = File.platform_path(Resources.master_directory #{theory})
I would like to be able to use the value this_path in specifying myfile. The imake command is defined in the import ~/Is0/IsS and currently looks as follows:
ML‹(*imake*)
val _ = Outer_Syntax.improper_command #{command_spec "imake"} ""
(Parse.text >>
(fn path => Toplevel.keep
(fn _ => Gc.imake path)))›
The argument is pased using Parse.text, but I need feed it the path based on the ML value this_path, which is defined later (in the Scratch theory). I searched around a lot, trying to figure out how to use something like Parse.const, but I won't be able to figure anything out any time soon.
So: It's important that I use, in some way, Resources.master_directory #{theory} in Scratch.thy, so that imake gets the folder Scratch is in, which will come from the use of #{theory} in Scratch.
If I'm belaboring the last point, it's because in the past, I wasted a lot of time getting the wrong folder, because I didn't understand how to use the command above correctly.
How can I achieve this?
Your minimal examples uses Resource.master_directory with the parameter #{theory} to define your path. #{theory} refers (statically) to the theory at the point where you write down the antiquotation. This is mostly for interactive use, when you explore stuff. For code which is used in other places, you must use the dynamically passed context and extract the theory from it.
The function Toplevel.keep you use takes a function Toplevel.state -> unit as an argument. The Toplevel.state contains a context (see chapter 1 of the Isabelle Implementation Manual), which again contains the current theory; with Toplevel.theory_of you can extract the theory from the state. For example, you could use
Toplevel.keep (fn state => writeln
(File.platform_path (Resources.master_directory (Toplevel.theory_of state))))
to define a command that prints the master_directory for your current theory.
Except in simple cases, it is very likely that you do not only need the theory, but the whole context (which you can get with Toplevel.context_of).
Use setup from preceding (parts of the) theory
In the previous section, I assumed that you always want to use the master directory. For the case where the path should be configurable, Isabelle knows the concept of configuration options.
In your case, you would need to define an configuration option before you declare your imake command
ML ‹
val imake_path = Attrib.setup_config_string #{binding imake_path}
(K path)
› (* declares an option imake_path with the value `path` as default value *)
Then, the imake command can refer to this attribute to retrieve the path via Config.get:
Toplevel.keep (fn state =>
let val path = Config.get (Toplevel.context_of state) imake_path
in ... end)
The value of imake_path can then be set in Isar (only as a string):
declare [[imake_path="/tmp"]]
or in ML, via Config.map (for updating proof contexts) or Config.map_global (for updating theories). Note that you need to feed the updated context back to the system. Isar has the command setup (takes an ML expression of type theory -> theory) for that:
setup ‹Config.map_global imake_path (K "/tmp")›
Configuration options are described in detail in the Isar Implementation Manual, section 1.1.5.
Note: This mechanism does not allow you to automatically set imake_path to the master directory for each new theory. You need to set it manually, e.g. by adding
setup ‹
Config.map imake_path
(K (File.platform_path (Resources.master_directory #{theory})))
›
at the beginning of each theory.
The more general mechanism behind configuration options is context data. For details, see section 1.1 and in particular section 1.1.4 of the Isabelle Implementation Manual). This mechanism is used in a lot of places in Isabelle; the simpset, the configuration of the simplifier, is one example for this.
I have tried
let _ = Unix.create_process "ls" [||] Unix.stdin Unix.stdout Unix.stderr
in utop, it will crash the whole thing.
If I write that into a .ml and compile and run, it will crash the terminal and my ubuntu will throw a system error.
But why?
The right way to call it is:
let pid = Unix.create_process "ls" [|"ls"|] Unix.stdin Unix.stdout Unix.stderr
The first element of the array must be the "command" name.
On some systems /bin/ls is a link to some bigger executable that will look at argv.(0) to know how to behave (c.f. Busybox); so you really need to provide that info.
(You see more often that with /usr/bin/vi which is now on many systems a sym-link to vim).
Unix.create_process actually calls fork and the does an execvpe, which itself calls the execv primitive (in the OCaml C implementation of the Unix module).
That function then calls cstringvect (a helper function in the C side of the module implementation), which translates the arg parameters into an array of C string, with last entry set to NULL. However, execve and the like expect by convention (see the execve(2) linux man page) the first entry of that array to be the name of the program:
argv is an array of argument strings passed to the new program. By
convention, the first of these strings should contain the filename
associated with the file being executed.
That first entry (or rather, the copy it receives) can actually be changed by the program receiving these args, and is displayed by ls, top, etc.
I am new to Julia Lang. I am coming from the background of Matlab.
In Matlab, when pressing whos command I will get all variables in the current scope; and also, I can store them in another variable like x=whos; Is there such commands exists in Julia?
Example code in Matlab:
>> a=3;
>> b=4;
>> whos
Variables in the current scope:
Attr Name Size Bytes Class
==== ==== ==== ===== =====
a 1x1 8 double
b 1x1 8 double
prefix 1x16 16 char
Total is 18 elements using 32 bytes.
An Update:
whos()
... is not working either in iJulia or at the command prompt in Julia-1.0.0.
It is working in Julia-0.6.4, though.
On the other hand,
varinfo()
....prints information about the exported global variables in a module. For Example,
julia-1.0> varinfo()
name size summary
–––––––––––––––– ––––––––––– –––––––––––––––––––––––––––––––
Base Module
Core Module
InteractiveUtils 154.271 KiB Module
Main Module
PyPlot 781.872 KiB Module
ans 50.323 KiB Plots.Plot{Plots.PyPlotBackend}
myrepl 0 bytes typeof(myrepl)
x 88 bytes 1×6 Array{Int64,2}
y 0 bytes typeof(y)
Hope, this is found useful.
You can use Julia's whos functions just like that Matlab command.
julia> whos()
Base Module
Core Module
Main Module
ans Nothing
julia> x = 5
5
julia> whos()
Base Module
Core Module
Main Module
ans Int64
x Int64
Any modules (packages/libraries) you import into your local scope (using using) will also show up in the list (as Modules, like Base, Core, and Main above).
Additionally, you can ask about names exported by Modules. Base is the module containing the standard library.
julia> whos(Base)
! Function
!= Function
!== Function
$ Function
% Function
& Function
* Function
+ Function
.... (lots and lots more)
Considering that that result scrolls way off my screen, you can understand why you'd want to filter the results. For that you can use Regexes. (For more info on Julia's regexes, see this manual section)
julia> whos(r"M")
Main Module
julia> whos(Base, r"Match"i)
DimensionMismatch DataType
RegexMatch DataType
each_match Function
eachmatch Function
ismatch Function
match Function
matchall Function
I wasn't aware of the whos function before you asked, so thanks for helping me learn something new too. :)
Julia issue #3393 on github is about adding memory sizes to the whos output. It also references making whos return a value rather than just printing the information out.
Not sure if there is something better, but
names(Main)[4:end]
seems to work. The [4:end] part is because it includes :Main, :Core and :Base which I think you would not want. I hope they will always be at the beginning.
whos() is not available in newer versions of Julia (1.0 onward). Use varinfo() instead. For example, varinfo(Core,r".*field.*")
As of version 1.1 there is also the #locals macro
The experimental macro Base.#locals returns a dictionary of current local variable names and values
Release notes
My Taglist in a C code:
macro
|| MIN_LEN
|| MAX_ITERATIONS
||- typedef
|| cell
|| source_cell
||- variable
|| len_given
Taglist elements (domain):
A = {MIN_LEN, MAX_ITERATIONS, cell, source_cell, len_given}
Code snippets (codomain):
B = {"code_MIN_LEN", "code_MAX_ITERATIONS", ..., "code_len_given"}
Goal: to have bijection between the sets A and B.
Example: I want to remove any element in A, such as the MIN_LEN, from A and B by removing either its element in A or B.
Question: Is there a way to quarantee a bijection between A and B so that a change either in A or in B results in a change in the other set?
I strongly doubt you can do that. The taglist plugin uses ctags to collect the symbols in your code and display them in a lateral split. The lateral split contains readonly information (if you try to work on that window, vim tells you that modifiable is off for that buffer).
What you want to achieve would imply quite complex parsing of the source code you are modifying. Even a simple task like automatic renaming (assuming you modify a function name entry in the taglist buffer and all the instances in your source are updated) requires pretty complex parsing, which is beyond the ctags features or taglist itself. Deleting and keeping everything in sync with a bijective relationship is even more complex. Suppose you have a printf line where you use a macro you want to remove. What should happen to that line? should the whole line disappear, or just the macro (in that case, the line will probably be syntactically incorrect.
taglist is a nice plugin for browsing your code, but it's unsuited for automatic refactoring (which is what you want to achieve).
Edit: as for the computational complexity, well, the worst case scenario is that you have to scout the whole document at every keystroke, looking for new occurrence of labels that could be integrated, so in this sense you could say it's O(n) at each keystroke. This is of course overkill and the worst method to implement it. I am not aware of the computational complexity of the syntax highlight in vim, (which would be useful to extract tags as well, via proper tokenization), but I would estimate it very low, and very limited in the amount of parsed data (you are unlikely to have large constructs to parse to extract the token and understand its context). In any case, this is not how taglist works. Taglist runs ctags at every vim invocation, it does not parse the document live while you type. This is however done by Eclipse, XCode and KDevelop for example, which also provide tools for automatic or semiautomatic refactoring, and can eventually integrate vim as an editor. If you need these features, you are definitely using the wrong tool.