I am currently working with VGA in Vivado on a Basys3 FPGA and I am having some issues. I want to generate different images (test mires). I have a separate .vhd file for each of these images, and a top level file where I would like to use a multiplexer for these images in order to assign each of them to a separate switch. My question is: How do I assign an image to a switch, if the outputs from every .vhd file are the three colour signals RGB?
What I tried is that I named these 3 output signals differently for every image, and assigned them to the final output signal when a switch is on using a case structure. I will paste part of it so you guys can get the idea:
This is the top entity
entity VGAdraw is
Port ( CLK : in STD_LOGIC;
cntHor : in integer range 0 to cstHorTotSize - 1;
cntVer : in integer range 0 to cstVerTotSize - 1;
SW : in STD_LOGIC_VECTOR (15 downto 0);
LED : out STD_LOGIC_VECTOR (15 downto 0);
RED : out STD_LOGIC_VECTOR (3 downto 0);
GREEN : out STD_LOGIC_VECTOR (3 downto 0);
BLUE : out STD_LOGIC_VECTOR (3 downto 0)
);
end VGAdraw;
This is one of the images:
signal red5, green5, blue5, red7, green7, blue7: STD_LOGIC_VECTOR (3 downto 0);
component Checkers is
Port ( CLK : in STD_LOGIC;
cntHor : in integer range 0 to cstHorTotSize - 1;
cntVer : in integer range 0 to cstVerTotSize - 1;
red7 : out STD_LOGIC_VECTOR (3 downto 0);
green7 : out STD_LOGIC_VECTOR (3 downto 0);
blue7 : out STD_LOGIC_VECTOR (3 downto 0)
);
end component;
component Checkers
port map (CLK => CLK,
cntHor => cntHor,
cntVer => cntVer,
red7 => RED,
green7 => GREEN,
blue7 => BLUE
);
The case structure
process
begin
case SW is
when "0000000000100000" => RED <= red7;
GREEN <= green7;
BLUE <= blue7;
when others => RED <= red5;
GREEN <= green5;
BLUE <= blue5;
end case;
end process;
The VGADraw is the top entity, in which I have declared each image as a different component. Like the one above. How do I assign each of them to a switch on my FPGA board, so i can change to the image I want by turning on a Switch? I have also tried some 'if generate' statements, with no results. Like in this case, having 16 switches on the Basys3, by turning on sw5, I would like to get the image drawn by the Checkers component.
Thanks for any help.
Just above the process starts your code should be something like this:
signal red1, blue1, green1, red7, green7, blue7 red5, green5, blue5 : STD_LOCIC_VECTOR(3 downto 0);
In general, when making a Structural design, after finishing with components you should declare the signals you need as given above.
Related
I am trying to learn the syntax of VHDL. I wrote a simple algorithm using a counter and an LED.
in the port section, I have...
LED : OUT STD_LOGIC_VECTOR(7 downto 0);
Below port, I have...
signal cntr : natural range 0 to (2**30);
I have a process that increments cntr.
After the process, I have...
LED(7 downto 0) <= std_logic_vector (to_signed(cntr(29 downto 22)));
I am trying to blink the LEDs to show the count. I need help in the line above where I am trying to convert a signal to a std_logic_vector and match 8 bits with the LED.
I have such signal:
sw : std_logic_vector(7 downto 0);
and now I want to make another one, which will have it as upper bits, 1 the rest:
std_logic_vector(31 downto 0) := (7 downto 0 => sw, others => '1');
but it won't compile. any help please? I don't want to do it bit by bit.
I'm not entirely sure where should go this smaller signal, but you probably want to do this:
signal sw: std_logic_vector(7 downto 0);
signal big: std_logic_vector(31 downto 0);
big <= sw & x"FFFFFF";
This will assign sw vector to 8 most significant bits of big vector, and '1' to rest of bits. Write in comments, if you want to do something else.
What you are trying to do is assign a signal -which is variable- to another signal during initialization. What do you expect to happen?
I.e. at the moment you define a signal, you can only initialize it. If you want to assign something to the signal, you have to write a declaration.
definition -> initialization
declaration -> assignment
So in this case you can define big a larger range, and fix the constant bits in initialization
signal big : std_logic_vector(31 downto 0) => (others => '1');
And when you want to assign sw to any part of big, do that after the begin.
big(31 downto 24) <= sw;
or
big(7 downto 0) <= sw;
etc. The bits you initialized as '1' will be overwritten by the assignment.
How do I split 16-bit data into 2 8-bit data?
signal part : std_logic_vector (16 downto 0);
signal part_1 : std_logic_vector (8 downto 0);
signal part_2 : std_logic_vector (8 downto 0);
The part is actually 17 bit, since 16 downto 0 is a 17 bit range, and the part_* are likewise 9 bit.
If the ranges are 15 downto 0 and 7 downto 0, then you can do the split with:
part_1 <= part( 7 downto 0);
part_2 <= part(15 downto 8);
Btw, quote by Martin Fowler / Phil Karlton:
There are two hard things in computer science:
cache invalidation, naming things, and off-by-one errors.
Why are your signals 17 bits and 9 bits long? I think they should be 16 and 8...
signal part : std_logic_vector (15 downto 0);
signal part_1 : std_logic_vector (7 downto 0);
signal part_2 : std_logic_vector (7 downto 0);
begin -- architecture begin
part_1 <= part(15 downto 8);
part_2 <= part(7 downto 0);
Pretty simple stuff... I'm surprised you didn't run across this in looking at a VHDL example.
There's also aggregate target assignment:
library ieee;
use ieee.std_logic_1164.all;
entity foo is
end entity;
architecture fum of foo is
type fie is array (natural range 0 to 1) of std_logic_vector (7 downto 0);
signal part: std_logic_vector (15 downto 0);
signal part_1: std_logic_vector (7 downto 0);
signal part_2: std_logic_vector (7 downto 0);
begin
(part_1, part_2) <= fie'(part(15 downto 8), part(7 downto 0));
end architecture;
Which is admittedly more useful for extracting elements of records in one fell swoop. What's slick here is that there's no place there's any named signal of type fie.
The reason for the aggregate on the right hand side is because the element size has to match on both sides of the assignment operator, both aggregates are treated as if they are type fie.
Doing this with records allows you to extract elements of varying sizes. Extracting fields from CPU machine instruction formats comes to mind. It allows you to use simple names without requiring aliases for element selected names. (There would be no named record).
When the element size is the same on both sides you can simply use a target aggregate:
library ieee;
use ieee.std_logic_1164.all;
entity fie is
end entity;
architecture fum of fie is
signal part: std_logic_vector (2 downto 0);
signal part_1: std_logic;
signal part_2: std_logic;
signal part_3: std_logic;
begin
(part_1, part_2, part_3) <= part;
end architecture;
These aggregates all use positional association. You can also use named association. Record aggregates require an others choice represent at least one element and all the elements have to have the same type (e.g. std_logic_vector).
Just for completeness: you can also use aliases which makes the signal assignment obsolete:
signal part : std_logic_vector (15 downto 0);
alias part_1 : std_logic_vector(7 downto 0) is part(15 downto 8);
alias part_2 : std_logic_vector(7 downto 0) is part(7 downto 0);
This has me bugging for quite some time, but is it possible to describe entities in VHDL similar to how templates work in C++ (or to lesser extend generics?). Simply leaving the actual port types to be only decided during synthesize/compilation?
An example would be a multiplexer, say I have a 4 input multiplexer, now I have several bus sizes I use this multiplexer for, -4,6,7,8-. Currently I wrote a different multiplexer for each different bus size; however the output is simply one of the chosen inputs forwarded, and is thus of the same type as the bus.
This seems overly redundant and error prone (choose correct multiplexer at correct times, keep them all in line, update them as I change the bus size). Is there no way to parameterize this?
non generic version below to show the idea.
entity mux_6bit_4input is
port ( input_0 : in std_logic_vector (5 downto 0);
input_1 : in std_logic_vector (5 downto 0);
input_2 : in std_logic_vector (5 downto 0);
input_3 : in std_logic_vector (5 downto 0);
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector (5 downto 0)
);
end entity mux_6bit_4input;
Maybe I misunderstood the question, but doesn't the common solution using generics solve your problem?
library ieee;
use ieee.std_logic_1164.all;
entity mux_4x1 is
generic (
DATA_WIDTH: integer := 8
);
port (
input_0: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_1: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_2: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_3: in std_logic_vector(DATA_WIDTH-1 downto 0);
sel: in std_logic_vector (1 downto 0);
output: out std_logic_vector(DATA_WIDTH-1 downto 0)
);
end;
architecture behavior of mux_4x1 is
begin
output <=
input_0 when sel = "00" else
input_1 when sel = "01" else
input_2 when sel = "10" else
input_3;
end;
Another solution, if you want to keep things really generic, is to use the cool generic types in VHDL-2008. My simulator doesn't yet support this feature, so here's an example from the excellent book VHDL 2008: Just the New Stuff:
entity generic_mux2 is
generic (type data_type);
port (
sel: in bit;
a, b: in data_type;
z: out data_type
);
end;
architecture rtl of mux2 is
begin
z <= a when sel = '0' else b;
end;
Another option is to use unconstrained arrays:
entity mux_4input is
port (
input_0 : in std_logic_vector ;
input_1 : in std_logic_vector ;
input_2 : in std_logic_vector ;
input_3 : in std_logic_vector ;
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector
);
end entity mux_4input;
They will inherit their width (and direction) from the signals they are conencted to in the instantiating entity.
It's probably not the right thing to do in this particular case of a mux, rick's answer is what I'd go for, but unconstrained arrays don't get mentioned much, so I thought I'd offer them! In this case, you'd probably also want some asserts to ensure that everything you've wired up is the same width.
I've bought a Spartan 3A development board from Micronova (http://micro-nova.com/mercury) and I've got some problems interfacing with its SRAM.
This board has 30 GPIO pins that are shared with Cypress SRAM and two pins to switch between them.
Obviously, connecting two VHDL modules (one for controlling SRAM and the other to drive GPIO) to the same pin leads to "Multiple driver error" when synthetizing.
So, to solve the problem I've created a third module as a middle controller that connects both modules with another variable for choosing which one to operate.
This works well for output, but when it comes to read input I always get 1, independently of the real value.
I don't know which pins will be used as input and which ones are for output because I would like an independent module that I can use for other projects.
This is what I got so far:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity DMA2 is
Port (
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
end DMA2;
architecture Behavioral of DMA2 is
begin
IOin2 <= IOphys;
IOin1 <= IOphys;
IOphys <= IOout2 when SwitchEn2 = '1' else IOout1;
end Behavioral;
IOphys are the physical pins on the board, SwitchEn2 is for choosing the driving module and the others are the inputs and outputs of the modules.
You don't seem to be driving your outputs. As a starter, how about defining a tristate driver like so
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity tristate is
port (
signal data_in : out std_logic;
signal data_out : in std_logic;
signal data_tristate : inout std_logic;
signal tristate_select : in std_logic
);
architecture rtl of tristate is
begin
data_in <= data_tristate;
data_tristate <= 'z' when tristate_select = '1' else data_out;
end architecture;
Then selecting between its use like so
entity arbitrate_bus
port(
-- the pins
IOphys : inout STD_LOGIC_VECTOR (29 downto 0);
IOin1 : out STD_LOGIC_VECTOR (29 downto 0);
IOout1 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction1 : in STD_LOGIC_VECTOR (29 downto 0);
IOin2 : out STD_LOGIC_VECTOR (29 downto 0);
IOout2 : in STD_LOGIC_VECTOR (29 downto 0);
IO_direction2 : in STD_LOGIC_VECTOR (29 downto 0);
SwitchEn2 : in STD_LOGIC
);
architecture like_this of arbitrate_bus is
signal input : STD_LOGIC_VECTOR (29 downto 0);
signal output_selected : STD_LOGIC_VECTOR (29 downto 0);
signal direction_selected : STD_LOGIC_VECTOR (29 downto 0);
begin
output_selected <= IOout1 when SwitchEn2 = '0' else IOout2;
direction_selected <= IO_direction1 when SwitchEn2 = '0' else IO_direction2;
g_ts: for g in output_selected'range generate
begin
u_ts: entity tristate
port map(
data_in => input(g),
data_out => output_selected(g),
data_tristate => IOphys(g),
tristate_select => direction_selected(g)
);
end generate;
IOin1 <= input;
IOin2 <= input;
end architecture;
What value are you assigning to the pins that are supposed to be inputs?
You may be able to infer proper operation if you assign 'Z' to the IOout1 and IOout2 signals when that pin is supposed to be an input, but I recommend you actually instantiate tri-state I/O pins. In addition to multiplexing the output state, you should also multiplex the output enable between the two modules, then your input code should work properly.
So each module generates output signals and a set of output enables. These signals get multiplexed and tied to the one set of physical pins, with the output enables determining which pins are inputs and which are outputs. This way, everything in the FPGA is binary logic and you are not relying on the synthesizer to infer a tri-state bus.