Related
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 am stupid new with VHDL, in fact I thoroughly hate this language and am only using it because I am forced to due to a project, and am having trouble with my case when statements. Basically, I'm making a 256x8 word RAM for a project. It takes in an address, based off that address it assigns a value to the memory location, then another process where it looks for the address that was inserted, and assigns the value to my output. It is very dumb, but my teacher wants it this way. I looked at my testbench and my code and have no idea why it's messing up.
I am currently testing it out with an address of "00000001" and it should get me the same thing, but with 32 bits instead of the 8 you saw in the address, just 24 0s in front basically. My output, The case I am trying to test, the case I am testing. I almost forgot, in these images, I changed it from x"00000001" to 31 0s and a 1, so these images are a little old. I shortened my code so its easier to read. In my second case it's basically the same except that I am also looking for if memRead = '1', if so then it assigns a value. Any help would be greatly appreciated.
----------------------------------------------------------------------------------
-- Company:
-- Engineer:
--
-- Create Date: 09:45:26 03/30/2020
-- Design Name:
-- Module Name: module - 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;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;
entity RAM is
Port( Address : in std_logic_vector(7 downto 0) := "00000000";
inputData : in std_logic_vector(31 downto 0) := "00000000000000000000000000000000";
Memwrite, Memread, rst, clk : in std_logic;
read_out_data : out std_logic_vector(31 downto 0));
end RAM;
architecture behave of RAM is
signal mem0, mem1, mem2, mem3, mem4, mem5, mem6, mem7, mem8, mem9, mem10, mem11, mem12, mem13, mem14, mem15, mem16, mem17, mem18, mem19, mem20, mem21, mem22, mem23, mem24, mem25,
mem26, mem27, mem28, mem29, mem30, mem31, mem32, mem33, mem34, mem35, mem36, mem37, mem38, mem39, mem40, mem41, mem42, mem43, mem44, mem45, mem46, mem47, mem48, mem49, mem50, mem51,
mem52, mem53, mem54, mem55, mem56, mem57, mem58, mem59, mem60, mem61, mem62, mem63, mem64, mem65, mem66, mem67, mem68, mem69, mem70, mem71, mem72, mem73, mem74, mem75, mem76, mem77,
mem78, mem79, mem80, mem81, mem82, mem83, mem84, mem85, mem86, mem87, mem88, mem89, mem90, mem91, mem92, mem93, mem94, mem95, mem96, mem97, mem98, mem99, mem100, mem101, mem102, mem103,
mem104, mem105, mem106, mem107, mem108, mem109, mem110, mem111, mem112, mem113, mem114, mem115, mem116, mem117, mem118, mem119, mem120, mem121, mem122, mem123, mem124, mem125, mem126, mem127, mem128, mem129,
mem130, mem131, mem132, mem133, mem134, mem135, mem136, mem137, mem138, mem139, mem140, mem141, mem142, mem143, mem144, mem145, mem146, mem147, mem148, mem149, mem150, mem151, mem152, mem153, mem154, mem155,
mem156, mem157, mem158, mem159, mem160, mem161, mem162, mem163, mem164, mem165, mem166, mem167, mem168, mem169, mem170, mem171, mem172, mem173, mem174, mem175, mem176, mem177, mem178, mem179, mem180, mem181,
mem182, mem183, mem184, mem185, mem186, mem187, mem188, mem189, mem190, mem191, mem192, mem193, mem194, mem195, mem196, mem197, mem198, mem199, mem200, mem201, mem202, mem203, mem204, mem205, mem206, mem207,
mem208, mem209, mem210, mem211, mem212, mem213, mem214, mem215, mem216, mem217, mem218, mem219, mem220, mem221, mem222, mem223, mem224, mem225, mem226, mem227, mem228, mem229, mem230, mem231, mem232, mem233,
mem234, mem235, mem236, mem237, mem238, mem239, mem240, mem241, mem242, mem243, mem244, mem245, mem246, mem247, mem248, mem249, mem250, mem251, mem252, mem253, mem254, mem255 : std_logic_vector(31 downto 0);
signal read_data_s : std_logic_vector(31 downto 0);
begin
--Work on the RAM!
process(clk, rst, MemWrite)
begin
if(rising_edge(clk)) then
case Address is
when "00000000" => mem0 <= "00000000000000000000000000000000";
when "00000001" => mem1 <= "00000000000000000000000000000001";
when "00000010" => mem2 <= "00000000000000000000000000000010";
when "00000011" => mem3 <= "00000000000000000000000000000011";
when "00000100" => mem4 <= "00000000000000000000000000000100";
when others => read_out_data <= "00000000000000000000000000000001";
end case;
end if;
end process;
process(clk)
begin
if(Memread = '1') then
if(rising_edge(clk)) then
case Address is
when "00000000" => read_out_data <= mem0;
when "00000001" => read_out_data <= mem1;
when "00000010" => read_out_data <= mem2;
when "00000011" => read_out_data <= mem3;
when "00000100" => read_out_data <= mem4;
when others => read_out_data <= "00000000000000000000000000000000";
end case;
end if;
end if;
end process;
end behave;
My teacher kinda sux at teaching this stuff and this language isn't really my strong suit, because I'm used to high level languages and don't know mess with this in my day to day. But the issue is solved, because the TA got back to me. Tank you to everyone who commented.
Basically, I needed to create a separate signal for my others condition to handle the output, instead of just setting the output in my others condition.
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 got these warnings from Lattice Diamond for each instance of any uart (currently 11)
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_14' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_0_COUT1_9_14' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_12' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_10' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_8' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_6' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_4' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_2' has no load
WARNING - ngdbuild: logical net 'UartGenerator_0_Uart_i/Uart/rxCounter_cry_0' has no load
The VHDL-code is
entity UART is
generic (
dividerCounterBits: integer := 16
);
port (
Clk : in std_logic; -- Clock signal
Reset : in std_logic; -- Reset input
ClockDivider: in std_logic_vector(15 downto 0);
ParityMode : in std_logic_vector(1 downto 0); -- b00=No, b01=Even, b10=Odd, b11=UserBit
[...]
architecture Behaviour of UART is
constant oversampleExponent : integer := 4;
subtype TxCounterType is integer range 0 to (2**(dividerCounterBits+oversampleExponent))-1;
subtype RxCounterType is integer range 0 to (2**dividerCounterBits)-1;
signal rxCounter: RxCounterType;
signal txCounter: TxCounterType;
signal rxClockEn: std_logic; -- clock enable signal for receiver
signal txClockEn: std_logic; -- clock enable signal for transmitter
begin
rxClockdivider:process (Clk, Reset)
begin
if Reset='1' then
rxCounter <= 0;
rxClockEn <= '0';
elsif Rising_Edge(Clk) then
-- RX counter (oversampled)
if rxCounter = 0 then
rxClockEn <= '1';
rxCounter <= to_integer(unsigned(ClockDivider));
else
rxClockEn <= '0';
rxCounter <= rxCounter - 1;
end if;
end if;
end process;
txClockDivider: process (Clk, Reset)
[...]
rx: entity work.RxUnit
generic map (oversampleFactor=>2**oversampleExponent)
port map (Clk=>Clk, Reset=>Reset, ClockEnable=>rxClockEn, ParityMode=>ParityMode,
ReadA=>ReadA, DataO=>DataO, RxD=>RxD, RxAv=>RxAv, ParityBit=>ParityBit,
debugout=>debugout
);
end Behaviour;
This is a single Uart, to create them all (currently 11 uarts) I use this
-- UARTs
UartGenerator: For i IN 0 to uarts-1 generate
begin
Uart_i : entity work.UartBusInterface
port map (Clk=>r_qclk, Reset=>r_reset,
cs=>uartChipSelect(i), nWriteStrobe=>wr_strobe, nReadStrobe=>rd_strobe,
address=>AdrBus(1 downto 0), Databus=>DataBus,
TxD=>TxD_PAD_O(i), RxD=>RxD_PAD_I(i),
txInterrupt=>TxIRQ(i), rxInterrupt=>RxIRQ(i), debugout=>rxdebug(i));
uartChipSelect(i) <= '1' when to_integer(unsigned(adrbus(5 downto 2)))=i+4 and r_cs0='0' else '0';
end generate;
I can syntesis it and the uarts work, but why I got the warning?
IMHO the rxCounter should use each single possible value, but why each second bit creates the warning "has no load"?
I read somewhere that this mean that these net's aren't used and will be removed.
But to count from 0 to 2^n-1, I need no less than n-bits.
This warning means that nobody is "listening" to those nets.
It is OK to have signals that will be removed in synthesis. Warnings are not Errors! You just need to be aware of them.
We cannot assess what is happening from your partial code.
Is there a signal named rxCounter_cry?
What is the datatype of ClockDivider?
What is the value of dividerCounterBits?
What happens in the other process? If it is irrelevant, please try to run your synthesis without that process. If it is relevant, we need to see it.
Lattice ngdbuild is particularly spammy for the job it is doing, I pipe ngdbuild output through grep in my makefile to remove exactly these messages:
ngdbuild ... | grep -v "ngdbuild: logical net '.*' has no load"
There's more than 2500 of these otherwise, eliminating them helps concentrate on real issues.
Second worst toolchain spammer is edif2ngd complaining about Verilog parameters it does not have explicit handling for. This one is a two line message (over 300 of these) so I remove it with:
edif2ngd ... | sed '/Unsupported property/{N;d;}'
Just be aware that sometimes it implements things with adders. The highest order bit will not use the carry output of that adder, and the lowest order bit will not use the sign input. So you get a warning like:
WARNING - synthesis: logical net 'clock_chain/dcmachine/count_171_add_4_1/S0' has no load
WARNING - synthesis: logical net 'clock_chain/dcmachine/count_171_add_4_19/CO' has no load
No problem, bit 19 is the highest, so it will not carry anywhere, and bit 1 is the lowest, so it does not get a sign bit from anywhere. If, however, you get this warning on any of the bits in between highest and lowest, it normally means something is wrong, but not an error, so it will build something that "works" when you test it, but not in an error case. If you simulate it with error cases it will normally show undesirable results.
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.