Xilinx Schematic design vs VHDL code design

I am currently using Xilinx Project Navigator to do some VHDL programming.
I have created a cicuit using both my own VHDL code and using a schematic
on the Xilinx ECS program. My VHDL code seems to be faster than the
schematic code (when I use the synthesis report), but uses more devices.
For example, one of my programs written as VHDL code produces
8 slices
10 flip flops
11 LUTs
9 IOBs
2 GCLKs
The minumum period is 3.991 ns (250 MHz)

When the same device was written with the schematic program it produced
8 slices
8 flip flops
0 LUTs
10 IOBs
1 GCLK

but the minumum period is 5.979 ns (167 MHz)

Has anyone done any research into why hand written VHDL is faster but uses
more devices? I am really interested in why my VHDL code is faster than
the schematic code. Any information that anyone can give me would be
great

Advertisements

Hi!
> I am currently using Xilinx Project Navigator to do some VHDL
> programming. I have created a cicuit using both my own VHDL code and
> using a schematic on the Xilinx ECS program. My VHDL code seems to be
> faster than the schematic code (when I use the synthesis report), but
> uses more devices. For example, one of my programs written as VHDL
> code produces
> 8 slices
> 10 flip flops
> 11 LUTs
> 9 IOBs
> 2 GCLKs
> The minumum period is 3.991 ns (250 MHz)
>
> When the same device was written with the schematic program it
> produced
> 8 slices
> 8 flip flops
> 0 LUTs
> 10 IOBs
> 1 GCLK
>
> but the minumum period is 5.979 ns (167 MHz)

In this example, notice that the VHDL design ended up with two clocks,
while the schematic design has only one. This makes me doubt that the
two designs are entirely equivalent. What's more, since the former
design has several clocks, one clock's minimum period alone doesn't
provide a metric for how fast it is, and it isn't comparable with the
latter design's clock period.

In other words, rewrite your VHDL code so that it is completely
synchronous and make sure it's behaviourally equivalent to the
schematics design. My guess is that the VHDL code will be slower then.
> Has anyone done any research into why hand written VHDL is faster but
> uses more devices? I am really interested in why my VHDL code is
> faster than the schematic code. Any information that anyone can give
> me would be great

I don't think one can make a general statement. It all depends on at
what level you're coding, on the application, and on how well you master
the language. Theoretically, you can acheive the optimal performance and
device utilization using both VHDL and schematics at structural level,
where you basically just connect the primitive elements of the circuit.
In practice, however, no sane human would do that for a large real-world
design. When it comes to comparing VHDL and schematics at higher levels,
both have their advantages and drawbacks. For example, using VHDL at
register-transfer level (RTL), it's easy to be lazy and create a design
that doesn't very naturally fit the chip you're designing for, and this
would result in a less efficient implementation. On the other hand, VHDL
synthesis tools of today have impressive optimization algorithms that
will remove unnecessary elements and utilize the chip cleverly in ways
that you wouldn't think of when designing with schematics. You can find
more pro's and con's in most introductory books on VHDL.

Advertisements

Thanks for the response, very helpful. One more question. My knowledge of
VHDL programming is limited and I would like to know why the compiler
thinks that my asynchronous reset is a clock signal. Here is my code.
***********************************************************

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

> Thanks for the response, very helpful. One more question. My knowledge
of
> VHDL programming is limited and I would like to know why the compiler
> thinks that my asynchronous reset is a clock signal. Here is my code.

I think it has to do with that the switching of end_col and ce aren't
explicitly synchronized with clk, so the synthesis tool infers latches for
them instead of clocked flip-flops. Since the reset signal can trigger the
latches, the tool decides to use one of the clock nets for it.

That way, the code adheres to the general template for synchronous processes
with asynchronous reset. Notice that I changed "11101111" in your code to
"11101110" here, because now that the compare is placed among the clocked
statements, it will be delayed one cycle. To put it another way, pix_ctr
will be increased from "11101110" to "11101111" at the same instant as when
end_col and ce are updated.

Another suspicious spot in your code is that pix_ctr is declared "inout".
Since this process drives pix_ctr all the time, noone else should drive it,
so I think it should be safe to declare it "out".

Notice that I'm not exactly an expert either, but I hope the real experts
will correct me if I'm wrong!

----/\--------------/\----------------
By this code you no more require variable ce, and you don't need have a
ff for end_col.

JaI

Jerker Hammarberg (DST) wrote:
>>Thanks for the response, very helpful. One more question. My knowledge
>>
>>
>of
>
>
>>VHDL programming is limited and I would like to know why the compiler
>>thinks that my asynchronous reset is a clock signal. Here is my code.
>>
>>
>
>I think it has to do with that the switching of end_col and ce aren't
>explicitly synchronized with clk, so the synthesis tool infers latches for
>them instead of clocked flip-flops. Since the reset signal can trigger the
>latches, the tool decides to use one of the clock nets for it.
>
>I would recommend you to rewrite the process as follows:
>
>COUNT: process(clk,reset)
> variable ce : std_logic := '1';
>begin
> if reset = '1' then
> pix_ctr <= "00000000";
> end_col <= '0';
> ce := '1';
> elsif clk'event and clk = '1' then
> if ce = '1' then
> pix_ctr <= pix_ctr + 1;
> end if;
> if pix_ctr = "11101110" then
> end_col <= '1';
> ce := '0';
> end if;
> end if;
>end process COUNT;
>
>That way, the code adheres to the general template for synchronous processes
>with asynchronous reset. Notice that I changed "11101111" in your code to
>"11101110" here, because now that the compare is placed among the clocked
>statements, it will be delayed one cycle. To put it another way, pix_ctr
>will be increased from "11101110" to "11101111" at the same instant as when
>end_col and ce are updated.
>
>Another suspicious spot in your code is that pix_ctr is declared "inout".
>Since this process drives pix_ctr all the time, noone else should drive it,
>so I think it should be safe to declare it "out".
>
>Notice that I'm not exactly an expert either, but I hope the real experts
>will correct me if I'm wrong!
>
>/Jerker
>
>
>
>

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!