updating a bit file

[Guest pedro_trying_papilio]

Hello everyone,

I was trying to learn a few things using Jack's UART example.

The idea was to use Picoblaze UART tx only and stream some data from the fpga to be logged in the computer.

-- I commented out rx from UCF file

-- only used FIFO / uart TX/  kcuart TX from picoblaze

-- objective: Basic idea was that fpga should broadcast message with asci character 'A' on every UART

--transmission.

----------------------------------------------------------------------------------

-- Company: Gadget Factory

-- Engineer: Jack Gassett

--

-- Create Date:    22:31:30 11/27/2010

-- Design Name:

-- Module Name:    UARTExample - Behavioral

-- Project Name:

-- Target Devices:

-- Tool versions:

-- Description: Example code for implementing the Xilinx UART example on the Papilio One.

--              http://www.xilinx.com/support/documentation/application_notes/xapp223.pdf

-- Dependencies:

-- Requires the latest Picoblaze source code. Xilinx EULA does not allow the redistribution of Source code so the source modules must be downloaded seperately.

-- 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;

-- Uncomment the following library declaration if instantiating

-- any Xilinx primitives in this code.

--library UNISIM;

--use UNISIM.VComponents.all;

entity UARTExample is

    Port ( --rx : in  STD_LOGIC;

          tx : out  STD_LOGIC;

  extclk : in STD_LOGIC

  );

end UARTExample;

architecture Behavioral of UARTExample is

component uart_tx is

  port (            data_in : in std_logic_vector(7 downto 0);

                write_buffer : in std_logic;

                reset_buffer : in std_logic;

                en_16_x_baud : in std_logic;

                  serial_out : out std_logic;

                  buffer_full : out std_logic;

            buffer_half_full : out std_logic;

                          clk : in std_logic);

  end component;

 

COMPONENT dcm32to96

PORT(

CLKIN_IN : IN std_logic;         

CLKFX_OUT : OUT std_logic;

CLKIN_IBUFG_OUT : OUT std_logic;

CLK0_OUT : OUT std_logic

);

END COMPONENT;

signal dout : STD_LOGIC_VECTOR (7 downto 0);

signal data_present, en_16_x_baud, clk, clk32 : STD_LOGIC;

signal baud_count : integer range 0 to 5 :=0;

constant message: std_logic_vector (7 downto 0):= X"41"; --asci 'A'

begin

dout<=message;

baud_timer: process(clk)

begin

if clk'event and clk='1' then

if baud_count=1 then

baud_count <= 0;

en_16_x_baud <= '1';

data_present <= '1';

else

baud_count <= baud_count + 1;

en_16_x_baud <= '0';

data_present <= '0';

end if;

end if;

end process baud_timer;

Inst_dcm32to96: dcm32to96 PORT MAP(

CLKIN_IN => extclk,

CLKFX_OUT => clk,

CLKIN_IBUFG_OUT => open,

CLK0_OUT => open

);

INST_UART_TX : uart_tx

port map (

  data_in => dout,

  write_buffer => data_present,

  reset_buffer => '0',

  en_16_x_baud => en_16_x_baud,

  clk => clk,

  serial_out => tx,

buffer_half_full => open,

  buffer_full => open

);

end Behavioral;

-----------------------------------------------

Now the problem is when I load what i think is the correct bit file the board still behaves as in the original uart example (any character written to board is transmitted back), even though I obviously no longer have an UART _RX core (RTL confirms it on TX core in design).

The odd thing is every time I ask to re-run  'generate programming file' the date of last modified on the bit file does change so assumed it has been updated. Am I missing something in the procedures within Xilinx or the loader?

Regards

Pedro

[Jack Gassett]

Whenever I get behavior that doesn't make sense I always do a, "Project/Cleanup Project Files" from the menu. Run that option and then look in your project folder and make sure the bit file was deleted. I also make it a standard practice to do a right click on "Generate Programming File" and select "ReRun All" whenever I make big  changes like removing a module. This forces the entire process to be run over, the Xilinx ISE is written as a collection of modules tied together by ISE and occasionally they get confused.

Let me know if that makes a difference.

Jack.

[Guest pedro_trying_papilio]

Hi Jack thank a lot for your reply. As always the learning continues. It's good to know what is good practice in this sort of things. You were right on the taggled sort of effect on xilinx projects with a lot files dependencies.

I got it running but a little brute forcish: I am basically saying in UART_TX  port map that

write_buffer=>'1'

now I am not sure how this would operate but I get the impression you would need some sort of settle period. instead of attempting to write to buffer all the time.

When i streamed I was getting not very consistent results with pyserial so figured i would give putty a try just to see if it was the comms or the vhdl implementation.

for example if I implement message is

0100 0001 'A'

I get:

0101 0000 'P'

if i implement message is:

0110 0001 a

i get:

0101 1000 X

You get the idea. Now the only pattern i see is if the word is being read from bit 1 instead of from bit 7 like so: bit [1 0 7 6 5 4 3 2 ]  instead of [7 6 5 4 3 2 1 0 ].

But Nevertheless hardware wise it is operating normally so nothing to worry.

whatever the problem is its just somethin I need to improve on my 'VHDL grasp of things'.

I will go through the xilinx uart manual and make sense of it rather than have you guys tell me how to fix it. Its more fun!

Thanks for all your help

Regards

Pedro

[alvieboy]

Are you simulating your design, or are you relying on implementation trial-and-error ?

Alvie

[Guest pedro_trying_papilio]

Hi Álvaro,

thanks for your reply. Well because I was just having a play around I was going with trial and error(!)

Naively enough I thought I could just eliminate the RX side of things mantain the TX core and just feed a message into it. But It obviously isn't that simple. At 3Mega transmission I will probably have some timing issues if there isn't a form of flow control. I was being lazy because I am not very savvy with ISim and I have only used ModelSim before but thought it would be a bit of an overkill for something this simple.

I guess I will have to look into the black box instead of hoping it works out.

By the way the weekend project idea here (what I really want to do at the end of this) is to be able to have UART core to transmitt back to a PC and an SPI core (or a few SPI cores) mimicking a master SPI to receive data from other IC's . Sort of try to do my homebrewed DAQ system and bundle data from all the sensors I can grab a hold of.

I have seen some pretty cool things with real time data done using matplotlib (its a library extension for python) and I figured it would be cool to get all the hardware side of things centralised around an fpga.

I thought it wouldn't be too complicated If I could reuse/adapt stuff from the Picoblaze IP. Maybe it is a bit ambition for a first FPGA project but there you go.  If you guys have any ideas views suggestions advice on this project and how to best go around it let me know.

Regards

Pedro

[Jack Gassett]

Pedro,

I don't think this is too ambitious for a first FPGA project, it seems just right, so don't get discouraged.

My first advice if you want to go the VHDL route is to think of the UART core as a chip that you are using and the documentation that comes with the core as the datasheet for it. The included documentation is actually very good, so study it like you would any datasheet. Then use VHDL to tie things together like you would chips on a motherboard.

Having said that, I would recommend a different approach here. If I'm understanding what you want to do here, and correct me if I'm wrong, but you want to connect a bunch of different SPI devices to the 48 I/O pins that are available? Depending on the speed at which you need to get data from the sensors you might be able to use the ability to move the SPI pins on the fly that is built into the AVR8 and ZPUino to communicate with multiple SPI devices. With both soft processors you can move the SPI pins to different locations on the fly, communicate with the device, move the pins to the next device, and communicate with it. You are limited by the soft processor to how much data you can collect. Maybe this approach will be fast enough? I guess you could also connect all SPI pins as a bus and then have each SPI device attached with its own /cs pin and use the /cs pin to select which device to communicate with.

Look at the source code for the uSD card in the Papilio-Arduino example code to see how to move SPI pins on the fly.

If that is not fast enough then there are other approaches to take.

Jack.