I use Xilinx system generator blocks in Matlab and i find the block black box wich can generate and simulate vhdl code. I programme a simple program in vhdl for port and,
--import std_logic from the IEEE library
library ieee;
use ieee.std_logic_1164.all;
--ENTITY DECLARATION: name, inputs, outputs
entity andGate is
port( A, B : in std_logic;
F : out std_logic);
end andGate;
--FUNCTIONAL DESCRIPTION: how the AND Gate works
architecture func of andGate is
begin
F <= A and B;
end func;
I simulate in xilinx with blackbox and i make simulation mode ISE Simulator because i use xilinx .
I apreciate any kind of help thanks :)
check your gateway in, you should select its output as Boolean
also, check the sampling time of the system, you should make all equal to 1
Related
I am currently developing an AES encryption core for a Pynq-Z1 FPGA board. I would like to see the routing of the logic in FPGA logic and timing summary of the design.
The project synthesises, but it results in a warning saying that I am using exceeding the number of IOB blocks on the package. This is understandable because the core takes in and outputs a 4 x 4 matrix.
Instead, I would like to have "internal I/O" in order to see the routing on FPGA fabric. How would I go about doing this? Currently, the device view shows an empty topology (shown below) but my synthesised design utilises 4148 LUT and 389 FF. I expect to see some CLBs highlighted.
design device view
I appreciate any feedback and reference to any application notes which might further progress my FPGA understanding.
Cheers
You can use a simple wrapper around your core with a serial interface. Something like:
entity wrapper is
port(clk, rst, dsi, dsi_core, shift_out: in std_ulogic;
di: in std_ulogic_vector(7 downto 0);
dso_core: out std_ulogic;
do: out std_ulogic_vector(7 downto 0)
);
end entity wrapper;
architecture rtl of wrapper is
signal di_core, do_core, do_buffer: std_ulogic_vector(127 downto 0);
begin
u0: entity work.core(rtl)
port map(clk, rst, dsi_core, di_core, dso_core, do_core);
input_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
di_core <= (others => '0');
elsif dsi = '1' then
di_core <= di & di_core(127 downto 8);
end if;
end if;
end process input_process;
output_process: process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
do_buffer <= (others => '0');
elsif dso_core = '1' then
do_buffer <= do_core;
elsif shift_out = '1' then
do_buffer <= do_buffer(119 downto 0) & X"00";
end if;
end if;
end process output_process;
do <= do_buffer(127 downto 120);
end architecture rtl;
The wrapper just receives inputs, one byte at a time (when dsi = '1') and shifts them in a 128-bits register that is connected to the 128-bits input of your core. When 16 bytes have been entered the environment asserts dsi_core to instruct the core that the 128-bits input can be sampled and processed. The environment waits until the core asserts dso_core, signalling that the processing is over and the 128-bits output is available on the do_core output port of core. When dso_core is asserted the wrapper samples do_core in a 128-bits register (do_buffer). The environment can now read the leftmost byte of do_buffer which drives the do output port of the wrapper. The environment asserts shift_out to shift do_buffer one byte to the left and read the next byte...
This kind of wrapper is a very common practice when you want to test in the real hardware a sub-component of a larger system. As it frequently happens that the number of IOs of sub-components exceeds the number of available IOs, serial input-output solves this. Of course there is a significant latency overhead due to the IO operations but it is just for testing, isn't it?
Your demands are contradictory.
If the design can not place all the I/Os it can not show all the routing as it has not all the begin and/or endpoints. You should reduce your I/O.
The simplest way is to have a real or imaginary interface which much less pins.
An imaginary interface is one which is syntactically correct, reduces your I/Os but will never be used in real life so does not have to be functionally correct.
As it happens you are the third person to ask about reducing I/O in the last weeks and I posted an (untested) SPI interface which has a parameter to generate an arbitrary number of internal inputs and outputs. You can find it here: How can I assign a 256-bit std_logic_vector input
I have the following input: logic SWI[7: 0], which I would like to control from another executable, in C ++ for example.
And I have the following outputs: logic LED[7:0], SEG[7: 0], which I would like to get in real time.
Is there any way to simulate systemverilog in such a way that I can simulate inputs and get outputs (in this model)?
Example code that I would like to run:
logic T1, T2;
always_comb begin
T1 <= SWI[0];
T2 <= SWI[1];
LED[0] <= T1 && T2;
end
I'm sorry for bad english.
You can use DPI (C/C++ code linked to the simulation) to get/set values of Verilog signals. Then you can implement some IPC from this DPI code to another executable (e.g. using sockets, pipes etc.).
My model is currently roughly 2000 equations, and the simulation period is a couple of weeks. I'm using the OpenModelica Connection Editor.
The problem I'm facing is the huge amount of output variables, and I've had the plot window crash a couple of times.
The question is, therefore, how can I reduce the number of output variables?
I'm only really interested in 20-50 of them. I'm aware that I can remove parameter output by making them protected, but I haven't been able to locate any similar tricks for variables.
If you are simulating the model via command line then take a look at variableFilter argument of simulate command https://build.openmodelica.org/Documentation/OpenModelica.Scripting.simulate.html.
If you are using OMEdit then Simulation->Simulation Setup->Output->Variable Filter (Optional)
Actually, protected isn't limited to parameters. Here's an example duplicating Modelica.Mechanics.Translational.Examples.SignConvention and protecting everything but mass1
Tested in Dymola 2017FD01 with pedantic mode (so it should work in OpenModelica as well); it works fine, and gives only mass1 parameters and variables in the simulation results
model SignConvention "Examples for the used sign conventions."
extends Modelica.Icons.Example;
Modelica.Mechanics.Translational.Components.Mass mass1(
L=1,
s(fixed=true),
v(fixed=true),
m=1) a;
protected
Modelica.Mechanics.Translational.Sources.Force force1
a;
Modelica.Blocks.Sources.Constant constant1(k=1) a;
Modelica.Mechanics.Translational.Components.Mass mass2(
L=1,
s(fixed=true),
v(fixed=true),
m=1) a;
Modelica.Mechanics.Translational.Sources.Force force2
a;
Modelica.Blocks.Sources.Constant constant2(k=1) a;
Modelica.Mechanics.Translational.Components.Mass mass3(
L=1,
s(fixed=true),
v(fixed=true),
m=1) a;
Modelica.Mechanics.Translational.Sources.Force force3(useSupport=true)
a;
Modelica.Blocks.Sources.Constant constant3(k=1) a;
Modelica.Mechanics.Translational.Components.Fixed fixed
a;
equation
...
I want to run MATLAB 2015b algorithm on Android device through NDK. So I need a standalone c code from algorithm. I used Matlab Coder for this, But I get this error:
The function 'bwboundaries' is not supported for standalone code generation. See the documentation for coder.extrinsic to learn how you can use this function in simulation.`
I used this function in this way:
[B,L]=bwboundaries(h1);
the h1 is an 280*500 logical array which comes from a Black & White image.
I searched and found this list: Functions and Objects Supported for C and C++ Code Generation
As we see there the bwboundaries declared in the list:
bwboundaries :
The conn and options arguments must be compile-time constants and the return value A can only be a full matrix, not a sparse matrix.
If you choose the generic MATLAB Host Computer target platform, generated code uses a precompiled, platform-specific shared library.
MATLAB Function Block support: No.
I don't understand it!! How should I use this function to have its c code?
OR Is there any function to use instead?
I see this SO questions which didn't help me:
q1 q2 q3
In Modelica it is possible to define external functions.
Chapter 12.9 of the spec says C and Fortran77 are supported,
C++ and Fortran90 might be supported in the future.
Now I wonder which versions of C are supported?
In particular I need the logarithmic gamma function which is available in C99, so I tried the following:
function lgamma "logarithmic gamma function"
input Real u;
output Real y;
external "C" y = lgamma(u);
end lgamma;
but it does not work, while powf works:
function powf "power function a^b"
input Real a;
input Real b;
output Real y;
external "C" y = powf(a,b);
end powf;
This probably happens because powf is available in C while lgamma was introduced in C99. But is this a limitation of Modelica, Dymola or of my compiler?
Is there a way to get C99 external functions to work?
On the Wikipedia list of C mathematical operations there are some more interesting function like error function erf and erfc, these would also be nice to have.
You can only assume that C89/90 code compiles in a Modelica compiler. This is mainly concerning syntax though (if you use Include annotations or Library="file.c").
The functions that are available mainly depend on the C library that your compiler links against. I guess Microsoft's C library does not contain lgamma, so it cannot be linked against.
On Linux/OpenModelica, the lgamma example does work as libm contains the function (it's compiling using c90 mode, but implicitly adding a double lgamma(double) declaration).
The powf example also compiles, but does not work correctly since your external "C" declaration states that it uses double precision floating point (and you cannot change this as of Modelica 3.2). powf will read half of a and use it as its first argument, then read the second half of a and use it as its second argument. b would be discarded. If you set the compiler flags to std=c99, the error is detected:
powf.h:23:15: error: conflicting types for ‘powf’
Note that if you use Dymola on Windows, you are most likely using Visual Studio. In that case, there is no C99 support except the parts that were copied from C++.