Xst optimizes almost everything away

Hi,

this is my first real VHDL project, so it's perhaps more a beginner's question than a problem with Xst.

I have some components for my module two_pc, but when I translate it in ISE, both "translate" and "Place&Route" have warnings (system report says 308 warnings).

The problem: xst claims that some signals are connected but never used. For one component it even says there isn't any connection:

Xst:524 - All outputs of the instance of the block are unconnected in block .

I don't think that's true:

bild : bildspeicher port map (reset => reset, clk => clk_i, addra => bildaddr1, addrb => bildaddr2, DOA => bilddaten1, DOB => bilddaten2 );

(DOA and DOB are outputs) and there is a process using them:

chooser : process (clk_i, reset) --, update_input) variable links,rechts : std_logic_vector (31 downto 0); begin if (reset='1') then input '0'); elsif (clk_i'event and clk_i='1') then if (update_input'event and update_input='1') then rechts := bilddaten1; case spalte is when "00" => input (31)

Reply to
Adrian Knoth
Loading thread data ...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This statement completely confuses the synthesizer.

I assume you wish to look for the edge of update_input? You can't do it this way. You'll need to use a delay flip-flop (clocked by clk) and then test the state of both update_input and update_input_delayed. If update_input is true and update_input_delayed is false, then you've got the edge of update_input.

-a

Reply to
Andy Peters

Yo Adrian,

(I assume that it's not something simple, like the signals not making it to an output pin on the device)

Take a close look at the beginning of your 'chooser' process:

chooser : process (clk_i, reset) --, update_input) variable links,rechts : std_logic_vector (31 downto 0); begin if (reset='1') then input '0'); elsif (clk_i'event and clk_i='1') then if (update_input'event and update_input='1') then rechts := bilddaten1;

The elsif predicate is a normal enough rising edge clock condition on "clk_i". But then it is followed by an if predicate that indicates a rising edge clock condition on "update_input". What you've coded is a detector that looks for simultaneous rising edges, and this is not realistic for synthesis (not realistic period, the two signals come in on separate pins, and as Einstein observed, there is no simultaneity for separated points. I suspect you had to use the "--, update_input)" in the sensitivity list in order to get the simulation to work, but the synthesis tool complained so you commented it out. Well, keep it out, but change your if statement to read: if update_input='1' then which is the standard construction for a clock enable.

HTH, John

Reply to
JustJohn

Yes.

Wouldn't rising_edge (update_input) do the job? Or falling_edge (), if I need to know whether a signal was once set and is now off (write_A indicates that my processor core has written its result and I now can use the value of the output-FFs to write it to vga.)

How do I synchronize these processes in VHDL? I have the output-FFs containing the current value and need to bitwise store the content in the VGA-RAM every time my write_A indicates that there are new data. I currently use a process for this but I don't know if it really stops after executing the for-loops, how many clock cycles are used for each loop iteration, if every statement in the loop-body is executed in one clock cycle and so on:

to_video : process (clk_i, reset) variable tmp_vga : std_logic_vector (31 downto 0); begin if (reset='1') then addr_vga '0'); web_i

Reply to
Adrian Knoth

I think so, too.

Thanks, this sounds reasonable to me. Unfortunately it doesn't change a thing ;) I also removed some other statements of this kind.

Perhaps the problem is in the generation of update_input? I have to wait with new input until the core has read it, so I have a read_A going from 0 to 1 for two cycles if the data was captured:

addrgen : process (clk_i, reset) -- , read_A) begin if (reset='1') then zeile

Reply to
Adrian Knoth

Not for synthesis. Here is a similar example with just one clock.

formatting link
Note the synthesis template at the end of the file.

-- Mike Treseler

Reply to
Mike Treseler

THINK HARDWARE.

How would you implement the rising_edge() function? How does the hardware "know" when an edge occurs?

Here's a point you must understand: the process statement

myflop : process (clk, rst) is begin if (rst = '1') then q really stops after executing the for-loops, how many clock cycles

This is another problem. Your sensitivity list includes a clock and a reset (which is correct), but your code tells us that you want write_A to be the clock used by the flip-flops. Your synthesis tool should barf on this.

Assuming write_A is synchronous to your clock, you have a couple of options. If your data remain valid during the time write_A is asserted, you can use write_A directly as a clock enable:

myenabledflop : process (clk, rst) is begin if (rst = '1') then q

Reply to
Andy Peters

There is a lot wrong here, and I can't teach you all about H/W design vs. S/W coding, but will try to touch on some key points. I had a look at your website, and see that you have experience with Ada. Do not be fooled by any outward similarities between Ada and VHDL. There are many differences, some obvious and some very subtle. There is a lot more going on 'behind the curtain' in VHDL. Code written in Ada is has a single primary destination; it is compiled into an object file containg bits that control a processor's execution. Code written in VHDL has two primary destinations; it is compiled by a simulator to produce bits (dependency tables, signal lists, and a whole lot more) to control a simulator's exection, and it is compiled by a synthesizer to produce a netlist that is eventually transformed into bits to control the FPGA configuration.

Code written for a processor vs. VHDL code: On a processor, statements execute sequentially, and some kind of timing is almost always imposed on their execution by the processor's clock. In VHDL, all statements outside of a process execute concurrently, with _no_ timing. Statements inside a process execute sequentially, but there is still _no_ timing, everything 'happens in an instant', with the exception of 'wait' statements, which cause suspension of process statement execution until the wait condition is satisfied. BUT 'wait' statements are absolutely verboten in synthesizable VHDL. (Wait statements are used in testbench code, and others can tell you all about the importance of testbenches, and the differences between them and synthesizable code)

In a program running on a processor, you can write as part of a function or procedure: reset_trig

Reply to
JustJohn

I said that wrong, it IS VALID CODE, but silly. It is equivalent to writing:

spalte

Reply to
JustJohn

Thanks, this was more or less the main reason.

Thanks for this explanation, I ever wondered how to do this, your code has enlightened me.

I was misled by a statement in mind "With VHDL you can design your hardware if it was software." Unfortunately the quote originally said "With SystemC ..." and I bet is as wrong as my version ;)

Yes. I have everything in my bitstream now. Thanks for your help (and to all others, too).

--
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

For more information see readme-file WASN.DAT
Reply to
Adrian Knoth

Hi!

Thank you so much, these were exactly the points I needed. They've guided me on the (more or less complete) rewrite.

This was necessary to understand and it works now. I'll ask my professor to slightly change the basic vhdl course[0]; we do not do a lot, just combine some flip flops, but never realize that there are statements which compile but won't work (and yes, I thought the VHDL compiler is as strict as an Ada compiler)

Thank you (and the others) for your patience.

[0] You cannot call this a course, it is only a laboratory with let's say five hours for VHDL in total
--
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

Alt-F4 ist die Grundlage jeden vern├╝nftigen Arbeitens mit Windows.
Reply to
Adrian Knoth

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.