For example
entity xilinx_TDP_RAM is
generic(
ADDR_WIDTH : integer := 32;
DATA_WIDTH : integer := 129;
ENTRIES : integer := 32 -- number of entries (should be a power of 2)
);
port(
clk : in std_logic; -- clock
addra : in std_logic_vector(ADDR_WIDTH-1 downto 0); -- Port A Address bus, width determined from RAM_DEPTH
addrb : in std_logic_vector(ADDR_WIDTH-1 downto 0); -- Port B Address bus, width determined from RAM_DEPTH
dina : in std_logic_vector(DATA_WIDTH-1 downto 0); -- Port A RAM input data
dinb : in std_logic_vector(DATA_WIDTH-1 downto 0); -- Port B RAM input data
wea : in std_logic; -- Port A Write enable
web : in std_logic; -- Port B Write enable
ena : in std_logic; -- Port A RAM Enable, for additional power savings, disable port when not in use
enb : in std_logic; -- Port B RAM Enable, for additional power savings, disable port when not in use
douta : out std_logic_vector(DATA_WIDTH-1 downto 0); -- Port A RAM output data
doutb : out std_logic_vector(DATA_WIDTH-1 downto 0) -- Port B RAM output data
);
end xilinx_TDP_RAM;
What are the relations about ADDR_WIDTH & DATA_WIDTH & ENTRIES ?
DATA_WIDTH must be 2**N ?
THX!
This is not an xilinx interface.
but I think we can still give an answer to your question:
ADDR_WIDTH is typically be equal to:
ceil(log2(real(ENTRIES)))
without looking at the implementation,
DATA_WIDTH can be equal to anything positive (in the limit of your FPGA resources).
as a side note, the memery I used from Xilinx is xpm_memory_tdpram
Related
I have a lattice MachXO3L starter kit and I'm having some trouble with inputs, I think. I'm tried reducing the code only to read 4 switches (MachXO3 Starter Kit User’s Guide page 26) and light 4 LEDs according to the state of the switch. The problem is the LEDs seem to be half off. I tried adding 'reveal' and it appears that I'm not getting any change from the switches when I expect change. I set the spreadsheet I set it the same as in the example. I'm still learning VHDL, this is the first time I'm actually trying to connect something to it and the example is on Verilog, so I can't really check what I'm doing wrong. I'm probably missing something basic, but I don't know what.
Top File:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity TOP is
GENERIC(
DATAWIDTH : natural := 4
);
PORT(
-- Input Buffer --
ADCInputBuffer : IN STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0);
OUTPUT : OUT STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0);
ADC_SRT : OUT STD_LOGIC
);
end TOP;
architecture ADReader of TOP is
SIGNAL INTERNAL_CLOCK : STD_LOGIC;
SIGNAL CLOCK : STD_LOGIC;
SIGNAL CLOCK_65 : STD_LOGIC;
-- BUFFER --
signal adcInPut : std_logic_vector(DATAWIDTH-1 downto 0);
---------------------------------------------------
-- Internal Clock. Mach0X3 --
---------------------------------------------------
COMPONENT OSCH is
GENERIC(NOM_FREQ: string := "133.00"); --133.00MHz, or can select other supported frequencies
PORT(
STDBY : IN STD_LOGIC; --'0' OSC output is active, '1' OSC output off
OSC : OUT STD_LOGIC; --the oscillator output
SEDSTDBY : OUT STD_LOGIC --required only for simulation when using standby
);
END COMPONENT;
---------------------------------------------------
-- Internal Clock multiplier. Mach0X3 --
---------------------------------------------------
COMPONENT MASTERCLOCK is
PORT(
CLKI : IN STD_LOGIC; --'0' OSC output is active, '1' OSC output off
CLKOP : OUT STD_LOGIC; --the oscillator output 260MHz
CLKOS : OUT STD_LOGIC --the oscillator output for adc 65Mhz
);
END COMPONENT;
---------------------------------------------------
-- Read data In --
---------------------------------------------------
COMPONENT InputBuffer is
GENERIC(n: natural :=DATAWIDTH );
PORT(
clk : in STD_LOGIC;
CLK65 : IN STD_LOGIC;
En : in STD_LOGIC;
STRT : OUT STD_LOGIC;
Ipin : in STD_LOGIC_VECTOR (n-1 downto 0);
Output : out STD_LOGIC_VECTOR (n-1 downto 0)
);
END COMPONENT;
begin
-- System Clock
OSC: OSCH
GENERIC MAP (NOM_FREQ => "133.0")
PORT MAP (STDBY => '0', OSC => INTERNAL_CLOCK, SEDSTDBY => OPEN);
-- System Clock Multiplied
OSCmain: MASTERCLOCK
PORT MAP (CLKI => INTERNAL_CLOCK, CLKOP => CLOCK, CLKOS => CLOCK_65);
-- Gets data from ONE ADC
ADCIn: InputBuffer
GENERIC MAP (n => DATAWIDTH)
PORT MAP( clk => CLOCK, CLK65 =>CLOCK_65, EN =>'0', Ipin => adcInPut, Output => OUTPUT, STRT => ADC_SRT );
adcInPut <= ADCInputBuffer;
end ADReader;
InputBuffer:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity InputBuffer is
generic(n: natural :=4 );
Port (
clk : in STD_LOGIC;
CLK65 : IN STD_LOGIC;
En : in STD_LOGIC;
STRT : OUT STD_LOGIC;
Ipin : in STD_LOGIC_VECTOR (n-1 downto 0);
Output : out STD_LOGIC_VECTOR (n-1 downto 0)
);
end InputBuffer;
architecture Behavioral of InputBuffer is
signal temp : STD_LOGIC_VECTOR(n-1 downto 0);
SIGNAL CLK2 : STD_LOGIC;
begin
-- invert the signal from the push button switch and route it to the LED
process(clk, En)
begin
if( En = '1') then
temp <= B"0000";
elsif rising_edge(clk) then
temp <= Ipin;
end if;
end process;
Output <= temp;
STRT <= CLK65;
end Behavioral;
this is the setting for MASTERCLOCK generated by lattice diamond:
this is how the pins are setup:
and here is the netlist generated by lattice-diamond:
here I'm just trying to have a static output:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity TOP is
GENERIC(
DATAWIDTH : natural := 4
);
PORT(
OUTPUT : OUT STD_LOGIC_VECTOR (DATAWIDTH-1 downto 0)
);
end TOP;
architecture ADReader of TOP is
begin
OUTPUT <= B"1010";
end ADReader;
Page 15 of the user guide (The link you provided) mentions different LED pins: H11,J13,J11,L12 which you have as ADC input. I think you might have swapped some pins around...
I have the following input signal:
addr : IN STD_LOGIC_VECTOR(9 DOWNTO 0);
As far as I know, this means that addr(9) is the most significant bit.
But when run a simulation and assign, say, 128 to it, I get the following:
0(9) 0(8) 0(7) 0(6) 0(5) 0(4) 0(3) 1(2) 0(1) 0(0)
Meaning that the most significant bit is actually addr(0).
The assignment is done through simulation via vector waveform, in Quartus 9.1. I assign an arbitrary value to it.
Here is part of the .vhd file, where I use this:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
ENTITY ram_256x4B IS
PORT(clk, wr_en : IN STD_LOGIC; -- clock, write control signal
addr : IN STD_LOGIC_VECTOR(9 DOWNTO 0); -- read and write addresses
d : IN STD_LOGIC_VECTOR(31 DOWNTO 0); -- data to be written
q : OUT STD_LOGIC_VECTOR(31 DOWNTO 0)); -- memory read output
END ram_256x4B;
ARCHITECTURE comportamental OF ram_256x4B IS
SIGNAL addr_validation_bits : STD_LOGIC;
BEGIN
addr_validation_bits <= addr(9) & addr(8);
END comportamental;
If the valued of addr is 2, I expect addr(9) and addr(8) to be both 0, but instead they are 0 and 1, respectively.
This assigns a STD_LOGIC_VECTOR with 128.
architecture ...
signal addr : STD_LOGIC_VECTOR(9 downto 0);
begin
addr <= std_logic_vector(to_unsigned(128, addr'length));
end;
addr(7) is '1', all other bits are '0'.
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.
I am a fresh student and the assignment is to build 3 components with testbench and then to arrange them into one structure. All 3 components I have built work great but when I put them together one of the the outputs stays undefined. I tried to trace the signal called dat and it is fine, but probably I am not using correct syntax to assign the dat signal to data_out . The id_led_ind is the second output and it works fine but the data_out is undefined.
Here is the code (i think the problem is in lane 21 - "data_out <= dat")
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity peak_detect is
port(
input : in std_logic_vector (7 downto 0);
data_out : out std_logic_vector (7 downto 0);
reset : in std_logic;
clock : in std_logic;
enable : in std_logic;
id_led_ind : out std_logic);
end peak_detect;
architecture dataflow of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
begin
en <= (enable or a_big_b);
data_out <= dat;
end dataflow;
architecture structure of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
component comp_8bit is
port(
A : in std_logic_vector (7 downto 0);
B : in std_logic_vector (7 downto 0);
res : out std_logic);
end component;
component dff is
port (
data : in std_logic_vector (7 downto 0);
q : out std_logic_vector (7 downto 0);
clk : in std_logic;
reset : in std_logic;
en : in std_logic);
end component;
component id_sens is
port(
data_in : in std_logic_vector (7 downto 0);
led : out std_logic);
end component;
begin
reg : dff port map (data => input, q => dat, clk => clock, reset => reset, en => enable);
comp : comp_8bit port map (A => input, B => dat, res => a_big_b);
sens : id_sens port map (data_in => dat, led => id_led_ind);
end structure;
There appears to be confusion over having two architectures (dataflow and structure) for the entity peak_detect. The two architectures are mutually exclusive, and the last one analyzed is the default in absence of other configuration specifying one of the architectures directly.
For purposes of evaluating how the components are interconnected and their port mapped connections relate to the port declarations of peak_detect, the first architecture could be commented out (dataflow).
When you disregard the architecture dataflow we find there is no driver for data_out in architecture structure.
You're missing an assignment to data_out using dat as a source in architecture structure, as found in architecture dataflow. Copy or replicate the concurrent signal assignment statement data_out <= dat; into architecture structure.
You can't simply connect data_out to q in the port map of dff because the output of dff is also used as an input to id_sense.
dat is driven by q of dff. That is not how you connect components. port map should be used to connect ports of different components/entities, not signals of any entity to the port of another entity.
Am working on discrete cosine transform using VHDL. Am trying to convert the VHDL code from integer to standard logic vector. I applied some of the techniques i read online and from textbooks but it didn't work. Below is the code i tried converting.I would like the input length to be 8 bit and the output length to be 12bit.Thank you.
entity dct is
port (
Clk : in BIT;
Start : in BIT;
Din : in INTEGER;
Done : out BIT;
Dout : out INTEGER
);
end dct;
architecture behavioral of dct is
begin
process
type RF is array ( 0 to 7, 0 to 7 ) of INTEGER;
variable i, j, k : INTEGER;
variable InBlock : RF;
variable COSBlock : RF;
variable TempBlock : RF;
variable OutBlock : RF;
variable A, B, P, Sum : INTEGER;
begin
Here is the one i tried after reading some books and i keep getting errors.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity dct is
port (
Clk : in std_logic;
Start : in std_logic;
Din_temp: in INTEGER;
temp := conv_std_logic_vector(Din_temp, 8);
Done : out std_logic;
Dout_temp: out INTEGER;
temp := conv_std_logic_vector(Dout_temp, 9));
end dct;
architecture behavioral of dct is
begin
process
type RF is matrix( 0 to 7, 0 to 7 ) of ;
variable i, j, k : std_logic_vector(7 downto 0);
variable InBlock : RF;
variable COSBlock : RF;
variable TempBlock : RF;
variable OutBlock : RF;
variable A, B, P, Sum : std_logic_vector(7 downto 0);
begin
seems that you combined the entity declaration with the signal assignement; this doesn't work like this! keep the entity as it was and use the type conversion functions inside your architecture. the example below shows this for Din and Dout:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity dct is
port (
Clk : in BIT;
Start : in BIT;
Din : in INTEGER;
Done : out BIT;
Dout : out INTEGER
);
end dct;
architecture behavioral of dct is
signal temp_din: std_logic_vector(7 downto 0);
signal temp_dout: std_logic_vector(11 downto 0);
begin
temp_din<=std_logic_Vector(to_unsigned(Din,8));
Dout<=to_integer(unsigned(temp_dout));
...
of course, you can also use std_logic_vector directly in your entity:
entity dct is
port (
Clk : in BIT;
Start : in BIT;
Din : in std_logic_Vector(7 downto 0);
Done : out BIT;
Dout : out std_logic_vector(11 downto 0)
);
end dct;
Integers are perfectly synthesisable and work just fine as ports, so if the module you have is working satisfactorily, and synthesise correctly, leave it well alone.
It is good practice to use ranged integers : for example, if Din, Dout represent values in the range 0 to 255, create either a new integer type or a subtype for them :
type Int_8 is new Integer range 0 to 255; -- or
subtype Int_8 is Integer range 0 to 255;
(The difference is that subtypes can be freely mixed with other Integers, but accidentally mixing the new type with integer will be flagged by the compiler as an error).
The benefit of this is that synthesis won't try to create 32-bit math units where only 8 (or 3 or 19) bits is needed. Normally it does, then trims the excess bits later so it doesn't cost any more gates, it just floods the report files with "trimming redundant logic" messages...
However I am guessing the problem you have is interfacing this core with other parts of a design, implemented in a less enlightened fashion, which have std_logic_vector ports.
Then you can implement a wrapper to adapt this DCT core to a std_logic_vector environment.
I have used different techniques for different port signals : conversions in the port maps are neater, but some tools have problems (bugs) handling them. So I have used internal signals as adapters for Start and Dout, to show how you can work around such problems.
In reality, pick one or the other!
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
entity std_lv_dct is
port (
Clk : in std_logic;
Start : in std_logic;
Din : in std_logic_vector(7 downto 0);
Done : out std_logic;
Dout : out std_logic_vector(11 downto 0);
);
end std_lv_dct;
architecture wrapper of std_lv_dct is
Dout_int : integer range 0 to 4095;
Start_int : bit;
begin
-- internal signals as type adapters
Dout <= std_logic_vector(to_unsigned(Dout_int),11);
Start_int <= to_bit(Start);
-- direct entity instantiation for the real core
Transform : entity work.dct
port map(
Clk => to_bit(Clk),
Start => Start_int,
Din => to_integer(unsigned(Din)),
std_logic(Done) => Done,
Dout => Dout_int
);
end architecture wrapper;