Avnet V2Pro dev board "Hello world"


I'm trying to get started with logic programming on this board (ADS-XLX-V2PRO-DEVP20-6), ie. VHDL and no processors, and what could be easier than flashing the LEDs. However, I haven't had any luck yet. Does anyone have any such simple code which works the LEDs on this board? Or the serial line for that matter, anything to enable me to get feedback from it. If you want to see my efforts thus far, read on...

The best data to go by seemed to be Avnet's OPB-mem example project, which includes a part to flash the LEDs (but driven by the processor). I ran that LED test successfully, then tried to use it to guide my own code. I used their UCF file almost verbatim, and wrote a simple VHDL entity which sets all the relevant enable bits (I think I got them right, quite possibly not) and puts a constant signal on the data bus, which should then drive the LEDs. However, no such luck

- they don't respond at all when I download the code to the board.

My speculations as to the problem:

- I missed or mis-set some enable bits,

- Something needs to transition for the LED register to be loaded. I tried to transition the LED_CS_L signal, didn't help.

If anyone has time to look at the short VHDL file at the end, and perhaps see what's wrong, that'd be fantastic.

I'm using ISE 8.1, downloading code over JTAG for now.



-- main.vhd

-- Author: Alex Iliev

-- Entity based on Avnet's OPB-mem sample project

library IEEE; use IEEE.STD_LOGIC_1164.ALL;

-- synthesis translate_off library UNISIM; use UNISIM.vcomponents.all;

-- synthesis translate_on

entity main is -- these are the names used by Avnet for their ucf file, so this is just an -- entity to allow mapping my names to their names and using their ucf file -- as closely as possible. port (

-- OPB_Clk : in std_logic := '0';

-- A : out std_logic_vector(0 to 31); -- A, OE, WE, D are shared flash & sram OE_L : out std_logic;

-- RST_L : out std_logic; SDRAM_CE_L : out std_logic;

-- sasho: for the reset button SYS_RESET_N : in std_logic; WE_L : out std_logic;

D : inout std_logic_vector(0 to 31);

FLASH_CS_L : out std_logic_vector(0 to 0); SYS_ACE_CS_N : out std_logic;

GPIO_CS_N : out std_logic; LED_CS_L : out std_logic;

-- sasho: changed this from inout in the example project to 'out' here. SRAM_CS_L : out std_logic_vector(0 to 0) -- set up as vector to match output of platgen

-- SRAM_BS_L : out std_logic_vector(0 to 3) -- SRAM byte select


end main;

architecture Behavioral of main is

-- notice this is LSB on the left, like the D bus declaration taken from the -- system_top entity. signal data_write : std_logic_vector(0 to 31); component IOBUF port ( O : out std_logic; IO : inout std_logic; I : in std_logic; T : in std_logic); end component;

begin -- IOBUF for the D port. We don't need to read anything so the reading port -- is open. g1 : for i in D'range generate iod0 : IOBUF port map (I => data_write(i), IO => D(i), O => OPEN, T => '0' -- enable output/disable tristate ); end generate g1;


Reply to
Alex Iliev
Loading thread data ...

If all you want is to turn on a LED connected to the LED_CS_L then the following should suffice (assuming it needs low level at the pin to turn on):

entity main is port ( LED_CS_L : out std_logic; ); end main;

architecture Behavioral of main is begin LED_CS_L

Reply to

Actually the LEDs (8 of them) are connected to the data bus D, which is shared with SRAM, SDRAM and FLASH at least. LED_CS_L is an enable bit for the LEDs. Also, some of these devices, including the LEDs, sit behind a bridge FPGA, whose current program should just pass the data bus through. But it makes it impossible to tell how the wiring works from the schematic. Also, the LEDs have a register in front of them.

Hence, getting started with the board is taking some effort :)



Reply to
Alex Iliev

In which of the 2 FPGA's? It's not in your code, and you previously said that the second FPGA is configured to pass the data straight through... Or do you mean it is a separate IC? In any case if it is really a register and not a buffer then you certainly need to clock your data in it somehow... So make sure it gets the clock.


Reply to

I got a hold of the second (bridge) FPGA's design, and it turned out that the process (DFF register) driving the LEDs is indeed clocked, and I had not been providing that clock. Now the board said hello, with a counter on the LEDs :)


Reply to
Alex Iliev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.