1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx XST Error

Xilinx XST Error

At the bottom of this post is the code.

First, let me say that I have run this "program" through a TBW, and it seems to simulate correctly.

Second, I'll describe what this module does (or at least, should do).

8 bytes (along with 5 address bits that are carried). When 8 bytes come in, it outputs all 8 at once in a 64 bit value (again, along with the carried 5 bit address).

The latch line is mostly simply passed through, except that it is additionally used to reset the buffer pointer.

Am I making this task overly complex? If not, what's going on with it?

When I run the "implement design" task, I get the following warnings / errors:

=========================================================================

  • HDL Analysis
  • ========================================================================= Analyzing Entity (Architecture ). WARNING:Xst:790 - "C:/xilinx/tutorial/queue.vhd" line 46: Index value(s) does not match array range, simulation mismatch. INFO:Xst:1433 - Contents of array may be accessed with an index that exceeds the array size. This could cause simulation mismatch. ERROR:Xst:827 - "C:/xilinx/tutorial/queue.vhd" line 23: Signal DATA_OUT cannot be synthesized, bad synchronous description.

I'm indeed new to VHDL, and I'm just not clear on what the problem is here. Any help would be greatly, greatly appreciated. I can supply a zip of the project to anyone interested in helping enough for that.

Thanks!

Alex McHale

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity queue is Port ( DATA_IN : in STD_LOGIC_VECTOR (7 downto 0); LATCH_IN : in STD_LOGIC; CLOCK_IN : in STD_LOGIC; ADDRESS_IN : in STD_LOGIC_VECTOR (4 downto

0); DATA_OUT : out STD_LOGIC_VECTOR (63 downto 0); LATCH_OUT : out STD_LOGIC; CLOCK_OUT : out STD_LOGIC; ADDRESS_OUT : out STD_LOGIC_VECTOR (4 downto 0)); end queue;

architecture Behavioral of queue is type ram_type is array (0 to 7) of STD_LOGIC_VECTOR (7 downto

0); signal data_buffer : ram_type := ("00000000", "00000000", "00000000", "00000000", "00000000", "00000000", "00000000", "00000000"); signal buffer_write_offset : STD_LOGIC_VECTOR (3 downto 0) := "0000"; signal address_buffer : STD_LOGIC_VECTOR (4 downto 0) := "00000"; begin process (CLOCK_IN, LATCH_IN) begin if rising_edge( LATCH_IN ) then buffer_write_offset
Reply to
Alex McHale
Loading thread data ...

Alex -

I don't usually use VHDL, but it looks to me like you have at least one serious problem in your code.

You are creating a counter called buffer_write_offset which counts on the rising edge of the clock and resets on the rising edge of LATCH_IN.

Do you know of any type of counter hardware that acts like this? Could you show me Xilinx primitives like FD that could be used to make such a counter?

Counters should have only one edge sensitive signal, the clock.

A second issue is that you're using code like: address_buffer

Reply to
johnp

You data_buffer is an array of (0 to 7), but the index buffer_write_index is 4 bits, which means it can range from 0 to 15. Those two messages are trying to warn you of that potential problem.

The DATA_OUT is somewhat misleading. Really the problem is the bad synchronous description. And johnp pointed out the problem there.

Reply to
Duane Clark

Excellent, thank you for the reply. Like I said, I'm new to VDHL and logic programming in general. I've got breadboard experience from college, but that's it. Otherwise I'm a software developer.

johnp wrote:

Reply to
Alex

I would suggest that you not think of VHDL or Verilog like a programming language. You can code it in a similar way, but I find I get poor results that way. Instead, I design in block diagrams with registers and arbitrary blocks of logic which I just specify with the logic equations. Once I am comfortable with my block diagram, I "describe" the hardware elements in a standard form for that element. After all, it is not called Vhsic Hardware DESCRIPTION Language for nothing!

Registers are coded in a standard style that will produce a register with or without an enable or a reset (sync or async or both). Random logic is coded either inside the register description, or better in separate concurrent statements. This will give you signals that you can examine going into as well as out of the register for better visibility. Using the block diagram gives you more clarity of what you will be producing in the hardware. Since you are using standard templates for the logic blocks, you won't get errors about unsynthesizable statements.

One other thing. I don't intend to be mean, but if you don't understand why resetting a register on a signal's rising edge is not good, then you need more training in hardware design before you continue. That may just have been a slip on your part, but if it was a mistake from lack of understanding, then your background is not sufficient to be designing digital hardware. Of course, if this is a learning exercise for you, then please ask questions.

Alex wrote:

Reply to
rickman

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.