I am a beginner in vhdl, I am trying to generate a sinus and square singal with a frequency of 50 Mhz, but first i'm trying to generate the sinus wave. I saw a lot of tutorials but it was quite complicated to understand. Here is the code I made. Thank you in advance for your help :)
Indications
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
entity sinus is
port(clk : in std_logic;
clear : in std_logic;
sel : in std_logic_vector(1 downto 0);
Dataout : out std_logic_vector(7 downto 0));
end sinus;
architecture Behavioral of sinus is
signal in_data : std_logic_vector(Dataout'range);
signal i : integer range 0 to 77:=0;
TYPE mem_data IS ARRAY (0 TO 255) OF integer range -128 to 127;
constant sin : mem_data := (
( 0),( 3),( 6),( 9),( 12),( 15),( 18),( 21),( 24),( 28),( 31),( 34),( 37),( 40),( 43),( 46), ( 48),( 51),( 54),( 57),( 60),( 63),( 65),( 68),( 71),( 73),( 76),( 78),( 81),( 83),( 85),( 88), ( 90),( 92),( 94),( 96),( 98),( 100),( 102),( 104),( 106),( 108),( 109),( 111),( 112),( 114),( 115),( 117), ( 118),( 119),( 120),( 121),( 122),( 123),( 124),( 124),( 125),( 126),( 126),( 127),( 127),( 127),( 127),( 127), ( 127),( 127),( 127),( 127),( 127),( 127),( 126),( 126),( 125),( 124),( 124),( 123),( 122),( 121),( 120),( 119), ( 118),( 117),( 115),( 114),( 112),( 111),( 109),( 108),( 106),( 104),( 102),( 100),( 98),( 96),( 94),( 92), ( 90),( 88),( 85),( 83),( 81),( 78),( 76),( 73),( 71),( 68),( 65),( 63),( 60),( 57),( 54),( 51), ( 48),( 46),( 43),( 40),( 37),( 34),( 31),( 28),( 24),( 21),( 18),( 15),( 12),( 9),( 6),( 3), ( 0),( -3),( -6),( -9),( -12),( -15),( -18),( -21),( -24),( -28),( -31),( -34),( -37),( -40),( -43),( -46), ( -48),( -51),( -54),( -57),( -60),( -63),( -65),( -68),( -71),( -73),( -76),( -78),( -81),( -83),( -85),( -88), ( -90),( -92),( -94),( -96),( -98),(-100),(-102),(-104),(-106),(-108),(-109),(-111),(-112),(-114),(-115),(-117), (-118),(-119),(-120),(-121),(-122),(-123),(-124),(-124),(-125),(-126),(-126),(-127),(-127),(-127),(-127),(-127), (-127),(-127),(-127),(-127),(-127),(-127),(-126),(-126),(-125),(-124),(-124),(-123),(-122),(-121),(-120),(-119), (-118),(-117),(-115),(-114),(-112),(-111),(-109),(-108),(-106),(-104),(-102),(-100),( -98),( -96),( -94),( -92), ( -90),( -88),( -85),( -83),( -81),( -78),( -76),( -73),( -71),( -68),( -65),( -63),( -60),( -57),( -54),( -51), ( -48),( -46),( -43),( -40),( -37),( -34),( -31),( -28),( -24),( -21),( -18),( -15),( -12),( -9),( -6),( -3));
begin
process(clk, clear) begin
if (clear='1') then
in_data <= (others => '0');
elsif (clk'event and clk='1') then
in_data <= in_data +1;
end if;
end process;
process (in_data(3))
begin
if (in_data(3)'event and in_data(3)='1') then
in_data <=conv_std_logic_vector(sin(i).8);
i<=i+1;
if (i=77) then
i<=0;
end if;
end if;
end process;
process(in_data, sel) begin
case sel is
when "00" =>Dataout<=in_data;
when others =>Dataout<= "00000000";
end case;
end process;
end Behavioral;
Thanks for the diagram. Because VHDL is hardware description language, the question you should ask yourself is : what do I want to implement ? where are the entity ports, the internal signals on this block diagram ?
The main issue you face is that you've no real correspondence between your design and your illustration. Moreover your VHDL coding style needs improvement both regarding the VHDL language itself and how you implement things.
Start by replacing
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
by
use IEEE.NUMERIC_STD.ALL;
This is the official vendor-agnostic VHDL package for signed and unsigned types. IEEE.STD_LOGIC_UNSIGNED and STD_LOGIC_ARITH.ALL are outdated vendor-dependent VHDL packages provided at a time where vendors couldn't agree on a common definition. This led to a lot of portability issues when having a design flow with tools from different vendors (Cadence, Mentor, Synopsys). The IEEE specification body solved once and for all this issue.
If you're designing real hardware, the following code can lead to implementation problems
process(clk, clear) begin
if (clear='1') then
in_data <= (others => '0');
elsif (clk'event and clk='1') then
in_data <= in_data +1;
end if;
end process;
Your in_data signal is asynchronously cleared but synchronously set. As you don't control when the clear signal will be asserted relative to the clk rising edge, there is a risk of in_data metastability or even that some bits of the in_data remains in reset while the others capture a new value.
For a description of the various ways to implement the reset Xilinx has a well documented white paper (WP272) which provides some guidelines useful for any synchronous design be it ASIC or FPGA, Xilinx or Altera. By the way if you have a look, for example, to the widely popular AMBA specifications (AHB, AXI, AXI-Stream, ...), their reset is asserted asynchronously but deasserted synchronously.
Personnally, following Xilinx guidelines, I distribute an asynchronous reset through the entire design and generate locally a synchronous reset with the following piece of code (being locally avoid the fanout issue of a system-wide synchronous reset)
if (p_reset_n = '0') then
s_reset_on_clock <= (others => '1');
else if rising_edge(p_clock) then
s_reset_on_clock <= '0' & s_reset_on_clock(3 downto 1);
end if;
end if;
s_reset_on_clock(0) is now your local synchronous reset signal that you can use like any other signal within the synchronous code block.
Please replace the old fashioned
elsif (clk'event and clk='1') then
with
elsif rising_edge(clk) then
it will be more obvious what's going on here.
You say that you want to generate a 50MHz signal but you don't say what the system frequency (or maybe I should understand it the other way around). The ratio system clock frequency / 50MHz will give you the sequence length.
Anyway, you will need to declare a free running counter as signal, let's call it counter (in your original code you have two signals, i and in_data, for this same purpose), and reset/increment it using your locally synchronous reset and your clock signal.
In case of a square signal (let's say sel = '0'), your output will be solely determined by the value of your counter. Below a given counter value, you'll have a predetermined dataout value (your 'low' state), while above this value, you'll have another predetermined dataout value (your 'high' state).
In case of a sine signal (let's say sel = '1'), the counter will represent the phase and will be used as input to your sine lookup table (that you, by the way, could initialize with a VHDL function calculating the lookup table content instead of providing precalculated literals). The output of the sine lookup table is your dataout output.
Let me know if you need more help.
I have written the code in three parts. The first part contains functions such as add, subtract and negate. The second part is the butterfly structure. The third part is fft4.
I find some errors in butterfly part, please help to solve these.
The program is given below. In fft_pkg instead of multiplication by -j, I used negation function.
I avoided multiplication by 1 and -j and used addition and negate function.
-- Design Name:
-- Module Name: butterfly - Behavioral
-- Project Name:
-- Target Devices:
-- Tool versions:
-- Description:
--
-- Dependencies:
--
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
-------------------------------------------------------------
library ieee;
use IEEE.STD_LOGIC_1164.ALL;
library work;
use work.fft_pkg.all;
entity butterfly is
port (
s1,s2 : in complex;
stage : in std_logic; -- inputs
-- w : in complex -- phase factor
g1,g2 : out complex -- outputs
);
end butterfly;
architecture Behavioral of butterfly is
begin
--butterfly equations.
if ( stage ='0') then
g1 <= add(s1,s2);
g2 <= sub(s1,s2);
elsif (stage ='1') then
g1 <= add(s1,negate(s2));
g2 <= sub(s1,negate(s2));
end if;
end Behavioral;
--butterfly structure(in it instead of multiplication negate func is used)
library ieee;
use IEEE.STD_LOGIC_1164.ALL;
library work;
use work.fft_pkg.all;
entity butterfly is
port (
s1,s2 : in complex;
stage : in std_logic; -- inputs
-- w : in complex; -- phase factor
g1,g2 :out complex -- outputs
);
end butterfly;
architecture Behavioral of butterfly is
begin
--butterfly equations.
if ( stage ='0') then
g1 <= add(s1,s2);
g2 <= sub(s1,s2);
elsif (stage ='1') then
g1 <= add(s1,negate(s2));
g2 <= sub(s1,negate(s2));
end if;
end Behavioral;
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.fft_pkg.all;
entity fft4 is
port (
s: in comp_array;
y : out comp_array
);
end fft4;
architecture rtl of fft4 is
component butterfly is
port (
s1,s2 : in complex; -- inputs
-- w : in complex; -- phase factor
g1,g2 : out complex -- outputs
);
end component;
signal g1,g2: comp_array; -- :=(others=>(0000,0000));
-- signal w:comp_array2 :=(("0000","0001"),("0000","1111"));
begin
--first stage of butterfly
bf11 : butterfly port map(s(0),s(2),'0',g1(0),g1(1));
bf12 : butterfly port map(s(1),s(3),'0',g1(2),g1(3));
--second stage of butterfly's.
bf21 : butterfly port map(g1(0),g1(2),'0',g2(0),g2(2));
bf22 : butterfly port map(g1(1),g1(3),'1',g2(1),g2(3));
end rtl;
Errors are
ERROR:HDLCompiler:806 - "C:\Users\RObin\fftfinal\butterfly.vhd" Line 36: Syntax error near "if".
ERROR:HDLCompiler:806 - "C:\Users\RObin\fftfinal\butterfly.vhd" Line 39: Syntax error near "elsif".
ERROR:HDLCompiler:806 - "C:\Users\RObin\fftfinal\butterfly.vhd" Line 42: Syntax error near "if".
ERROR:HDLCompiler:854 - "C:\Users\RObin\fftfinal\butterfly.vhd" Line 31: Unit ignored due to previous errors.
Try placing the if statements into a process:
architecture behavioral of butterfly is
begin
--butterfly equations.
process (s1, s2)
begin
if ( stage ='0') then
g1 <= add(s1,s2);
g2 <= sub(s1,s2);
elsif (stage ='1') then
g1 <= add(s1,negate(s2));
g2 <= sub(s1,negate(s2));
end if;
end process;
end behavioral;
It's not possible to verify your code without either package fft_pkg, or writing one, which would seem to require deciding what the type complex is.
Note that while Nicolas also commented that you could use concurrent conditional assignment statements, all concurrent statements have equivalent process statements or processes and block statements, which is how VHDL is both simulated and synthesized after elaboration.
You can also comment out or remove one of the two copies of entity butterfly and it's architecture Behavioral. If you need two different representations with the same interface you can change the architecture name of successive different architectures.
By default the last one analyzed will be used. Analyzing the same named entity and architecture over again has the effect of replacing the first occurrence while still requiring both are valid VHDL.
I want to describe an entity that can either function normally or be put in a test mode. The general design I have is a top level entity that wraps the "real" entity and a test entity.
I am trying to figure out the best way to express this in VHDL, but I get the feeling I'm overcomplicating things.
Consider a small top-level entity (realistically, there are many more I/Os):
entity toplevelobject is
port (
in1 : inout std_logic;
in2 : inout std_logic;
out1 : out std_logic;
out2 : out std_logic;
testline : in std_logic;
testclk : in std_logic;
);
end toplevelobject;
This is supposed to switch between the real functionality and the test mode depending on the state of "testline" (high means test). Note that the test module actually uses everything but clk as an output, even in_*.
architecture test_passthrough of toplevelobject is
-- This is the actual module
component real_module
port (
in1 : in std_logic;
in2 : in std_logic;
out1 : out std_logic;
out2 : out std_logic;
clk : in std_logic;
-- Note absence of "testline"
);
end component;
-- This is the test module, which will just put the clk
-- signal out on all pins, or play a tune, or something
component test_module
port (
in1 : out std_logic;
in2 : out std_logic;
out1 : out std_logic;
out2 : out std_logic;
testclk : in std_logic;
-- Note absence of "testline"
);
end component;
signal real_in1, real_in2 : std_logic;
signal real_out1, real_out2 : std_logic;
signal test_in1, test_in2 : std_logic;
signal test_out1, test_out2 : std_logic;
begin
real_0 : real_module port map (
in1 => real_in1,
in2 => real_in2,
out1 => real_out1,
out2 => real_out2,
clk => clk,
);
test_0 : test_module port map (
in1 => test_in1,
in2 => test_in2,
out1 => test_out1,
out2 => test_out2,
testclk => clk,
);
-- Ports that are outputs on both don't need
-- much special attention
out1 <= real_out1 when testline = '0' else test_out1;
out2 <= real_out2 when testline = '0' else test_out2;
end test_passthrough;
So I have a few questions:
For the inout ports, should I have one big process with a case ... when statement that switches on testline? Or a process for each I/O with an if statement? Theoretically I figure that many smaller processes are executed concurrently instead of sequentially, but will it actually make a difference to simulation or synthesis? For example:
passthrough_in1 : process(testline, in1, test_in1) is
begin
if testline = '0' then
real_in1 <= in1;
else
in1 <= test_in1;
end if;
end process passthrough_in1;
...vs...
passthrough_all : process(in1, test_in1, in2, test_in2, testline) is
case testline is
when '0' =>
real_in1 <= in1;
real_in2 <= in2;
when '1' =>
in1 <= test_in1;
in2 <= test_in2;
end case;
end process passthrough_all;
Is this a sane approach or is there something simpler?
I'm confused about sensitivity — do I need passthrough_in1 (or even passthrough_all to be sensitive to anything other than testline?
Do I need the real_in1/test_in1 to select between the two wrapped entities? Or is there another way to say "if testline is high, connect test_module output in_1 to the toplevelobject I/O in_1?
If I understand you correctly your testmodule drives the (badly named - I assume in the real code they make more sense :) in1,2 ports?
If so, you need to do something like this:
real_in1 <= in1;
in1 <= test_in1 when testline = '1' else 'Z';
That way in non-test-mode the in1 signal will be driven by a 'Z', so the external proper in1 signal can override it.
You can represent this in various other ways (like the processes that you described), all of which should come out being equal in the simulator. The downside of the "all in one process" option is that you'll need to keep what might end up as an enormous sensitivity list up to date. Doing it one process per signal is just a long winded way of what I did above.
To save some code and copy/paste effort, you could potentially push those two lines of code into an entity of their own and then instance it many times - in that case, I'd put the instance and port map all on one line, but that would offend some coding standards...
This all assumes I've understood the problem correctly!
Maybe I don't fully understand what you're trying to do, but in a typical VHDL testbench:
Your "real_module" code is left as it is. No changes are made to it when it is tested.
A second module, akin to your "toplevelobject" is made. This is typically called a testbench module.
The toplevelobject testbench instantiates real_module.
The testbench usually has no inputs, and doesn't really need outputs (depending on the situation and the testing software used).
The testbench has sequential logic that drives the inputs of real_module.
If you're using testing software such as ModelSim, the inputs and outputs of real_module can be plotted over time to watch the behaviour of real_module as it is driven by your testbench.
What software are you using? I can dig up an old testbench example from a university project a couple of years ago if it would be of any help to you.