PicoBlaze

[evgenia89]

Hello!

I could successfully import UART macros and PicoBlaze processor to my project. For testing I made my own loop in the file uart_control.psm which sends '1' to computer and I received this '1' in Hyperterminal.

Now I want to send to PC not a constant, but a signal from FPGA in decimal way. Where and how can I load the signal to UART?

Any help and references are appreciated!

Best regards,

Evgenia.

[eteam00]

This request has very little to do with PicoBlaze.

• Where does the data come from?
• What does "in decimal way" mean?
• How do you load the "1" character to UART in your current design?  Will this same "load" work with other characters?

-- Bob Elkind

[eilert · Accepted solution]

Hi Evgenia,

You need to add a Input Port to your Picoblaze design. The Picoblaze documentation describes how to do this.

then you connect the signal of interest to that port. A single port can be 8 bit wide at maximum.(For wider signals you have to use multiple ports and scan them sequentially. )

You can read the port using the INPUT command within your Assembler code (.psm). Maybe you need some function that converts this value into some meaningful char or string that will be sent out via the UART afterwards.

The realtime-clock example that comes with the KCPSM3 ressources has some nice example code about how to create strings and if you search the forum you might even find some binary2bcd conversion code examples. Adapt this to your needs.

Have a nice synthesis

  Eilert

[evgenia89]

I connected my signal dac_data_prebuf (std_logic_vector(7 downto 0)) to input port of kcpsm6 processor instead of signal uart_rx_data_out as it was in an example.

But there is a problem: the router has detected an unroutable situation.

     Unroutable      signal: dac_data_prebuf<7>      pin:  in_port<6>/D2
     Unroutable      signal: dac_data_prebuf<6>      pin:  in_port<6>/D5
     Unroutable      signal: dac_data_prebuf<5>      pin:  in_port<6>/C2
     Unroutable      signal: dac_data_prebuf<4>      pin:  in_port<6>/C5
     Unroutable      signal: dac_data_prebuf<0>      pin:  in_port<6>/A5
     Unroutable      signal: dac_data_prebuf<1>      pin:  in_port<6>/A2
     Unroutable      signal: dac_data_prebuf<2>      pin:  in_port<6>/B5
     Unroutable      signal: dac_data_prebuf<3>      pin:  in_port<6>/B2

My process:

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

	  -- Read UART status at port address 00 hex
	  when '0' =>   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
	  -- (see 'buffer_read' pulse generation below) 
--	  when '1' =>       in_port <= uart_rx_data_out;  -- it was in an example
     when '1' =>       in_port <= dac_data_prebuf;       --my signal

	  when others =>    in_port <= "XXXXXXXX";  

	end case;
--
--	-- Generate 'buffer_read' pulse following read from port address 01
--
	if (read_strobe = '1') and (port_id(0) = '1') then
	  read_from_uart_rx <= '1';
	 else
	  read_from_uart_rx <= '0';
	end if;

 end if;
end process input_ports;

 I declared the constant in PSM file:
CONSTANT DAC_input_port, 01

and I read from the port:
INPUT s5, DAC_input_port
CALL UART_TX

What can be a problem?

Best regards,

Evgenia.

[eilert]

Hi Evgenia,

the messages are coming from the Place&Route tool, aren't they?

Is your (full) design really so area consuming that there are no free routes left, or is there some other problem? (e.g. wrong pad locations)

The signal dac_data_prebuf seems to be a IN port that goes directly to some FPGA pads (via IBUFs or IFFs).

Is that signal connected to some other part of your design too?

Your code looks quite ok, while I'm not sure how the synthesis tool deals with the assignment of 'X' values.

You should check the reports for ressource occupation and location constraint issues. 

There surely is some cause for this situation, but probably not in the way you connected the signal to the picoblaze subsystem.

Hard to say without more information.

Have a nice synthesis

  Eilert

[evgenia89]

Hi Eilert,

yes, the message is comming from Place&Route tool.

I don't think that there are no free routes anymore, the project is not so huge.

The signal dac_data_prebuf is connected to input of OBUFDS component and output of OBUFDS are connected to pins of FPGA:

Am I not allowed to use the signal as an input of KCPSM3?

[joelby]

I don't think there should be a problem with the OBUFDS alone. Are you able to post the sections of HDL where you declare and assign data to dac_data_prebuf, and the OBUFDS instantiation?

[evgenia89]

Declaration of the signal:

signal dac_data_prebuf   : std_logic_vector(7 downto 0);

 I took this part of the code from reference design example without changing:

dac_data: for i in 0 to 7 generate

  --oserdes in data path
  oserdes_data : oserdes
  generic map (
    DATA_RATE_OQ => "DDR",
    DATA_RATE_TQ => "DDR",
    DATA_WIDTH => 4,
    INIT_OQ => '0',
    INIT_TQ => '0',
    SERDES_MODE => "MASTER",
    SRVAL_OQ => '0',
    SRVAL_TQ => '0',
    TRISTATE_WIDTH => 1
  )
  port map (
    oq        => dac_data_prebuf(i),
    shiftout1 => open,
    shiftout2 => open,
    tq        => open,
    clk       => clk_491_52MHz,
    clkdiv    => clk_245_76MHz,
    d1        => dac_din_i(i + 8),
    d2        => dac_din_i(i),
    d3        => dac_din_q(i + 8),
    d4        => dac_din_q(i),
    d5        => '0',
    d6        => '0',
    oce       => '1',
    rev       => '0',
    shiftin1  => '0',
    shiftin2  => '0',
    sr        => io_rst,
    t1        => '0',
    t2        => '0',
    t3        => '0',
    t4        => '0',
    tce       => '0'
  );

  --output buffers
  obufds_data : obufds_lvds_25
  port map (
    i  => dac_data_prebuf(i),
    o  => dac_data_p(i),
    ob => dac_data_n(i)
  );

end generate;

[joelby]

Ah, there's your problem.

From UG381 (Spartan-6, but I'm sure the deal is the same with Virtex et al.), the OSERDES OQ port is "Data path output to pad or IODELAY2." You cannot connect this port to fabric logic - there isn't any physical way to do so. Also, this signal could be operating at a very high speed, much faster than fabric logic can be driven.

The 'correct' way to monitor the signal would be to feed dac_din_i and dac_din_q to your PicoBlaze port. It's the same data, but in parallel format after all. Note that you may have to cross a clock domain to do so, if the PicoBlaze 'clk' and your OSERDES CLKDIV 'clk_245_76MHz' are not the same, and you might need to come up with an inventive way of capturing all 32 bits of the dac_din_*.

Incidentally, for the latter, I would use four PicoBlaze input ports. Reading from the first would freeze the current values all 32 bits into a register and send the first 8 to PicoBlaze. Reading from the next three will read out the next three bytes. I presume you only want to be able to take an occasional snapshot of the dac_din_* readings because PicoBlaze and the UART will be running at orders of magnitude slower than your 245 MHz clock.

If you're just trying to debug the OSERDES output in a creative manner, you'll need to use a high bandwidth oscilloscope or something (or you could dial down the speed and use a lower bandwidth oscilloscope). Output a fixed pattern and you can easily look at each of the traces and deserialise it on paper.

[evgenia89]

I presume you only want to be able to take an occasional snapshot of the dac_din_* readings because PicoBlaze and the UART will be running at orders of magnitude slower than your 245 MHz clock.

No, I want to read all the data from the flow. Thank you for your notice, I will change the clock frequency. I found that for PicoBlaze the maximum frequency for Virtex-6 devices is 165MHz. But I couldn't find the maximum frequency for UART macros.

So, if I make 4 input ports and leave one output port how will the data be caught in HyperTerminal? Will it be consequent 8 bits at every output?