Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Xilnx ISE RTL schematic Viewer and FPGA Design Flow

Status
Not open for further replies.

GhostInABox

Junior Member level 2
Joined
Sep 3, 2009
Messages
22
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,543
Hi all ,

I am modelling the following code in ISE(12.4) and VIVADO , VIVADO(2014) elaborated schematic seems to give quite accurate results while i am struggling to see how ISE RTL schematic viewer is useful to the RTL designer at all ?

Here is the code for a FIR filter with 4 taps

Code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
package temp is
type tapType is array (integer range <>) of signed(7 downto 0);
end package temp;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.temp.all;

entity FIR_SLOW is
port( clk : in std_logic;
reset : in std_logic;
input : in signed(7 downto 0);
output : out signed(7 downto 0));
end FIR_SLOW;

architecture Behavioral of FIR_SLOW is


signal tap : tapType(3 downto 0);
signal coefficent : tapType(3 downto 0);
type tapType_internal is array (integer range <>) of signed(15 downto 0);
signal tap_internal : tapType_internal(3 downto 0);

signal add3 : signed(17 downto 0);
begin

coefficent(0)  <= to_signed(8,8);
coefficent(1)  <= to_signed(10,8);
coefficent(2)  <= to_signed(4,8);
coefficent(3)  <= to_signed(6,8);

tap_proc:process(reset,clk)
begin
if(reset = '1') then
    for i in 0 to 3 loop
        tap(i)  <= to_signed(0,8);
    end loop;
    output <= to_signed(0,8);
elsif(rising_edge(clk)) then
    for i in 3 downto 1 loop
        tap(i) <= tap(i-1);
    end loop;
    tap(0) <= input;
    output <= add3(17 downto 10);
end if;
end process;

process(tap,coefficent)
begin
    for i in 0 to 3 loop
     tap_internal(i)  <= tap(i) * coefficent(i);
    end loop;
end process;

process(tap,tap_internal)

variable add1 : signed(16 downto 0);
variable add2 : signed(16 downto 0);

begin

add1 := resize(tap_internal(0),17) + resize(tap_internal(1),17);
add2 := resize(tap_internal(2),17) + resize(tap_internal(3),17);
add3 <= resize(add1,18) + resize(add2,18);
end process;

end Behavioral;

Here is the VIVADO schematic
vivado.png

Here is the ISE RTL schematic for the same design
ISE.png


1. I would like to know from users of these tools if they ever found the ISE RTL schematic tool useful for complex designs ?

2. I just started to write VHDL code for FPGA's and find myself constantly going back and forth between the Schematic Design and Synthesis report to figure out if my VHDL was synthesized as expected. Is this typical of the normal design flow for FPGA's , I have seen guys who just write RTL and simulate on modelsim but don't seem to be looking at the synthesized constructs ( that often)

Just want to get an idea about the best flow to follow , if anyone would like to know what they do I can get some idea as i am not working in a commercial FPGA dev environment.

3. ISE XST does not seem to identify even output ports in the above design correctly , I am just wondering how people designed complexed design before VIVADO was released



Please let me know your thoughts

Thank you
 

Hi all ,

I am modelling the following code in ISE(12.4) and VIVADO , VIVADO(2014) elaborated schematic seems to give quite accurate results while i am struggling to see how ISE RTL schematic viewer is useful to the RTL designer at all ?
Why are you using such old versions of the tools? ISE's current version is 14.7 and Vivado is at 2016.2

1. I would like to know from users of these tools if they ever found the ISE RTL schematic tool useful for complex designs ?
Yes, when I wanted to make sure the synthesis tool understood my code and did what I wanted.

2. I just started to write VHDL code for FPGA's and find myself constantly going back and forth between the Schematic Design and Synthesis report to figure out if my VHDL was synthesized as expected. Is this typical of the normal design flow for FPGA's , I have seen guys who just write RTL and simulate on modelsim but don't seem to be looking at the synthesized constructs ( that often)
Only when I'm using some structure that I'm not sure the tool will understand perfectly. Things like adding parenthesis around something could change how the synthesis tool partitions the logic and implements something parallel instead of daisy chained. I would imagine in the case you mention either the coders understand what synthesis will implement (because they've perhaps already done this before so they know what they will get) or they don't know any better and think the synthesis tool is perfect and can figure out their junk code and make it perfect. ;-)

Just want to get an idea about the best flow to follow , if anyone would like to know what they do I can get some idea as i am not working in a commercial FPGA dev environment.
Knowing what your synthesis tool will produce is something you should know. Now hopefully you will learn from looking at the results and can stop checking everything you write.

3. ISE XST does not seem to identify even output ports in the above design correctly , I am just wondering how people designed complexed design before VIVADO was released
In what way is it not showing the ports correctly? I've never noticed that in all the years I've used the schematic output.
 

@ads-ee thanks for your comments


In what way is it not showing the ports correctly? I've never noticed that in all the years I've used the schematic output.

if you look at my VHDL , I have a coefficient port but in the RTL schematic viewer(ISE) , i dont see that port. Also if you look into the structure of the synthesized HW, the ISE image shows that internal signals are grounded when they are not , it should show what the VIVADO schematic viewer shows.

Also I was wondering how to infer the coefficients

By writing

Code:
coefficent(0)  <= to_signed(8,8);
coefficent(1)  <= to_signed(10,8);
coefficent(2)  <= to_signed(4,8);
coefficent(3)  <= to_signed(6,8);

The code seems to connect signals to 1's and 0's . I am not sure that this is the best way to store the coefficients
 

It's quite easy to say that the readability of the ISE RTL schematic is poor, but it has still most of the design information. The connection between last adder and output register seems to be missing at first sight, but I presume it's present in the synthesized design and the logic is functionally correct.

The RTL shown in ISE schematic seems to have undergone some optimization, the single bit coefficients that can be implemented by a simple shift are omitted. Not sure if the shift operation shows clearly in the signal indices.

Five significant result bits are truncated in your design due to unsuitable scaling, only three significant bits kept in the output.
 

Thanks FvM... Well it was VERY confusing for me to see what i saw in ISE because I am still not that confident with my VHDL and I was not sure if i had coded up my solution correctly. After synthesis schematic is mainly LUT's and FF's so its hard to see how my code has interpreted. I also try to check the synthesis log to see what blocks were inferred but there is nothing like diagrams :)
 

@op
1.) It is rare for me to look at RTL schematics for complex designs. More commonly, I'll look at the number of key resources used and if there are timing issues. But these are after implementation. I tend to get the design into a state where the tools can finish implementation, even if the logic isn't all in yet. For purpose of discussion, your design would not be considered complex.
2.) I find it very good to do small "sandbox" designs to see how coding constructs are handled by the tools, and to see if there are issues with smaller designs. Likewise, it can help to test random code when moving to a new device -- one where it isn't clear what makes the most impact on area/performance. Some developers get into a "overpipeline and only use simple language features" design mode. This mostly works, but in some cases the long pipelines can create nasty corner cases.
3.) The optimizer can do weird things. This gets worse as you get into implementation schematics. Especially if you enabled global optimizations and retiming.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top