PicoBlaze

[joelby]

The maximum frequency for the UART is probably quite similar to that of PicoBlaze. A PC serial port (or a USB emulation of one) may have a maximum speed of around a megabit per second, though. If your 32-bit dac_din_* signals really are running at 245 MHz, then you'll be trying to shovel 7840 Mbit/sec through that 1 Mbit/s UART. A fair proportion of your data will be lost due to buffer overrun.

Not that it makes much difference in this scenario, but using PicoBlaze to shift data from the data signals to the UART will also reduce your maximum throughput because it'll take a few clock cycles to retrieve the data, check the UART status, and send the byte to the UART. For high speed applications you would tend to bypass the processor and come up with some HDL that, say, interfaces the UART directly with the data stream. PicoBlaze and the UART are a nice combination for low speed serial interfaces, such as a serial console and debug interface.

The only way you can sensibly extract that much data from the FPGA is using OSERDES, and then connecting some sort of LVDS receiver device to the FPGA pins. I'm not really sure why you'd want to involve a UART at all when you've already set up an appropriate high speed output device.

Maybe you need to take a step back and describe exactly what you're trying to do, from a system level?

[evgenia89]

In short, I am trying to implement this:

1. input data to ADC of FMC150 daughter card;

2. applying mathematical operations to this digitized data;

3. writing the data into file on PC.

LVDS is an interface in FMC150. I used this for data output to oscillocsope - for checking if my maths module is working properly.

[joelby]

Fair enough. There's still a massive disparity between your ADC sample rate and the UART that you will need to consider. Depending on your needs you could consider buffering samples into block or external memory and transmitting them to your computer at low speed when the buffer is full, performing rate conversion to reduce the number of samples,, or using a faster interface such as PCI Express.

[eteam00]

...consider buffering samples into block or external memory and transmitting them to your computer at low speed when the buffer is full, performing rate conversion to reduce the number of samples, or using a faster interface such as PCI Express.

A UART is a simple interface to design and debug.  I would strongly recommend using the slower and simpler UART interface until the rest of your design is working, before you consider adding the complexity of a PCIe or ethernet interface to your design.

Debugging one problem at a time will speed up your design completion.

-- Bob Elkind

[evgenia89]

Hello again!

Now I am trying to complete my design with UART and I met more difficulties.

I connected the needed signal to a PicoBlaze input port. This signal is devided to two part and every part is 16-bit width. I am reading 8 bits from every part sequentially. But now I have no idea how to present this data with PC. When HyperTerminal catches 8 bits after 8 bits, it doesn't get the full 32-bit signal which is needed. How can I combine these 4 x 8 bits together?

What I try to do:

input_ports: process(clk)
begin
 if clk'event and clk = '1' then
	case port_id(2 downto 0) is

	  -- Read UART status at port address 00 hex
	  when "000" =>   in_port(0) <= uart_tx_data_present;
			  in_port(1) <= uart_tx_half_full;
			  in_port(2) <= uart_tx_full; 
			  in_port(3) <= uart_rx_data_present;
			  in_port(4) <= uart_rx_half_full;
			  in_port(5) <= uart_rx_full;

	  -- Read UART_RX6 data at port address 01 hex
	  when "001" =>     in_port <= adc_dout_i_new(7 downto 0);
	  when "010" =>	    in_port <= adc_dout_i_new(15 downto 8);
	  when "011" =>	    in_port <= adc_dout_q_new(7 downto 0);
	  when "100" =>     in_port <= adc_dout_q_new(15 downto 8);
	  
	  when others =>    in_port <= "XXXXXXXX";  

	end case;
...

 in *.psm file:

CONSTANT DAC_input_port, 01						  
CONSTANT DAC_input_port_1, 02	
CONSTANT DAC_input_port_2, 03
CONSTANT DAC_input_port_3, 04

main: INPUT s5, DAC_input_port
      CALL UART_TX
      INPUT s5, DAC_input_port_1
      CALL UART_TX
      INPUT s5, DAC_input_port_2
      CALL UART_TX
      INPUT s5, DAC_input_port_3
      CALL UART_TX
      JUMP main

 I get some data in Terminal but it is obviously not correct.

Best regards,

Evgenia.

[joelby]

RS232 only sends 8 (or 7) bits at a time, and HyperTerminal doesn't have any way to represent 32-bit values. You'll generally need to write a program that reads from the serial port and reconstructs 32-bit values from four 8-bit values by shifting and adding them. Don't forget to define some sort of framing or else you won't know where a 32-bit word starts or ends. The other alternative might be to convert the 32-bit value to ASCII and transmit the values as a string, if doing so is appropriate for your needs (this adds a lot of overhead, so it's not much good if you want it to be high speed)

[eteam00]

RS232 only sends 8 (or 7) bits at a time

OK, time for me to play standards police.

• RS-232 defines electrical and mechanical interface -- the physical transport layer -- not the character encoding or framing.
• HyperTerminal is an ASCII console terminal emulator.  ASCII character set and encoding determines what HT displays and sends.

An alternative to writing a custom Windows application for decoding binary data sent from the FPGA in an asynchronous serial bitstream, the FPGA (and, specifically, the PicoBlaze controller) can format the 32-bit binary data into neatly formed ASCII characters for transmission to (and display by) HyperTerminal.

For example,

• the following 32bit data value:  10010111001110100011001101010001
• can be encoded into the following sequence of ASCII data values: 8'h39, 8'h37, 8'h33, 8'h41, 8'h20, 8'h33, 8'h33, 8'h35, 8'h31, 8'h68
• which will be displayed on HyperTerm as "973A 3351h"

The encoding algorithm is simple:

for 4-bit nybble values 0-9, add 8'h30

for 4-bit nybble values A-F, add 8'h31

<space> = 8'h20

<CR> = 8'h0D

<LF> = 8'h0A

"h" = 8'h68

-- Bob Elkind

[eilert]

Hi Evgenia,

not any 8 bit code is a printable character some even just make some sound (0x07 = Bell).

So you need some conversion into a meaning ful display:

How about first splitting them into four bits and then creating the ASCII coding for their hexadecimal valuses (0..9,A..F).

Make sure that the values are in the correct order and that you append some Linefeed/Carriage Return character after each 32 bit value. (This can be done conveniently with the picoblaze, look for code examles in ref designs and the forum)

If you do everything right, hyperterminal should print something like this:

12345678

A4F6B3C7

AAFF5620

etc...  

Of course this means that for every 32 bit value you need to send 10 bytes over the UART.

This will further tighten the bottleneck from the high data rate bus to the PC.

Have a nice synthesis

  Eilert