Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 76775

Article: 76775
Subject: Re: Trying to get 4 LUTs, MUXF5, MUXF6 in Spartan-3
From: Artenz <usenet+5@ladybug.xs4all.nl>
Date: Fri, 10 Dec 2004 23:37:37 +0100
Links: << >>  << T >>  << A >>
On Fri, 10 Dec 2004 22:52:51 +0100, Artenz wrote:

> However, if you try to write vector 't' above with a case or if-else
> (which I had tried before), then you get 4 more LUT1s. Apparently you
> have to spell things out really carefully for XST to have it find the
> optimal solution, especially if you want the MUXF6 in there. Which is too
> bad, because it tends to make the code much harder to read.

Actually, you can use a case(f) for the 't' vector if you disable
automatic mux extraction, resulting in something fairly readable:

module lut_test( a, b, c, f, s );
    input [3:0] a, b;
    input [1:0] s;
    input [1:0] f;
    output c;

reg [3:0] t;
wire x0, x1;

// synthesis attribute mux_extract of lut_test is false;

always @(a or b or f )
    case(f)
        2'd0: t <= a & b;
        2'd1: t <= a | b;
        2'd2: t <= a ^ b;
        2'd3: t <= a & ~b;
    endcase

MUXF5 m_1a( .I0(t[0]), .I1(t[1]), .S(s[0]), .O(x0) );
MUXF5 m_1b( .I0(t[2]), .I1(t[3]), .S(s[0]), .O(x1) );
MUXF6 m_2 ( .I0(x0),   .I1(x1),   .S(s[1]), .O(c) );
 
endmodule


Article: 76776
Subject: Inferring dual port RAMs with different bus widths.
From: Elder Costa <elder.costa@terra.com.br>
Date: Fri, 10 Dec 2004 20:41:12 -0200
Links: << >>  << T >>  << A >>
Hello folks.

I have implemented the entity bellow by instantciating a dual ported 
block RAM with different bus widths (RAMB16_S18_S36 - I am developing 
for Virtex II or Spartan 3). Whereas it is relatively simple to do it by 
instantiacing the component from Xilinx library, I wonder if there is a 
way to code the module so that Xst infers the block RAM. I tried in one 
or two ways but it used logic in slices instead of BRAM and it required 
a lot of logic for a 1kib RAM. Could somebody give a hint on this? I 
looked at Xilinx documentation and couldn't find an example for this 
particular problem.

entity gaintab is
     Port (
         -- ports de acesso do processador
         i_ProcAddr      : in std_logic_vector(9 downto 0);
         i_ProcDataIn    : in std_logic_vector(15 downto 0);
         i_ProcWr        : in std_logic;
         i_ProcEn        : in std_logic;
         i_ProcClk       : in std_logic;
         o_ProcDataOut   : out std_logic_vector(15 downto 0);
         -- ports de acesso interno (fpga)
         i_FpgaAddr      : in std_logic_vector(6 downto 0);
         i_FpgaClk       : in std_logic;
         o_FpgaDataOut   : out std_logic_vector(31 downto 0)
     );
end gaintab;


TIA.

Elder.


Article: 76777
Subject: Re: Lookup table simulation problems
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 10 Dec 2004 15:01:16 -0800
Links: << >>  << T >>  << A >>


Elder Costa wrote:

(snip regarding sin lookup tables)

>> It would be more usual to make the number of table entries a power
>> of two, such that mod 360 degrees could be done by ignoring high
>> order bits.  You might see if that works better in your case.

> It is not possible in my application, a lock in demodulator at 2.5Msps 
> using a 125KHz carrier.

Well, it could probably be done with a phase accumulator,
but if the frequencies really are fixed, yes, the 20 element
table is best.

-- glen


Article: 76778
Subject: Re: Trying to get 4 LUTs, MUXF5, MUXF6 in Spartan-3
From: Artenz <usenet+5@ladybug.xs4all.nl>
Date: Sat, 11 Dec 2004 00:02:11 +0100
Links: << >>  << T >>  << A >>
On Fri, 10 Dec 2004 14:09:00 -0800, Chris Ebeling wrote:

> Annti,
> 
> Your correct this can be done. But your coding style isn't exactly conducive
> to the synthesis of a mux. Case statements are the preferred coding style if
> you want the MUXF5/MUXF6/MUXF# resources to be used. The dedicated
> muxes also roughly correlate to a particular width MUXF5 == 4:1,
> MUXF6 == 8:1. etc.
> 
> So if you want to get a MUXF6, at three bit case statement is appropriate:
> 
> module lut_test2(a,b,c,f,s);
>     input f;
>     input [1:0] s;
>     input [3:0] a;
>     input [3:0] b;
>     output c;
> 
> //Implicit wires exist
> //wire [3:0] a;
> //wire [3:0] b;
> //wire f;
> //wire [1:0] s;
> 
> reg caseout;
> //wire [2:0] sel = {s,f};
> 
> always @(s or f or a or b)
> case ({s,f})
> //f is 0
> 3'b000 :  caseout = (a[0] & b[0]);
> 3'b010 :  caseout = (a[1] & b[1]);
> 3'b100 :  caseout = (a[2] & b[2]);
> 3'b110 :  caseout = (a[3] & b[3]);
> //f is 1
> 3'b001 :  caseout = (a[0] | b[0]);
> 3'b011 :  caseout = (a[1] | b[1]);
> 3'b101 :  caseout = (a[2] | b[2]);
> 3'b111 :  caseout = (a[3] | b[3]);
> endcase
> 
> assign c = caseout;
> 
> endmodule

Chris,

Thanks for the info. I tried the same method on my slightly more
complicated design:

module lut_test( a, b, c, f, s );
    input [3:0] a, b;
    input [1:0] s;
    input [1:0] f;
    output c;

reg  c;

always @(a or b or f or s)
    case({s, f})
        4'b0000: c = a[0] & b[0];
        4'b0100: c = a[1] & b[1];
        4'b1000: c = a[2] & b[2];
        4'b1100: c = a[3] & b[3];

        4'b0001: c = a[0] | b[0];
        4'b0101: c = a[1] | b[1];
        4'b1001: c = a[2] | b[2];
        4'b1101: c = a[3] | b[3];

        4'b0010: c = a[0] ^ b[0];
        4'b0110: c = a[1] ^ b[1];
        4'b1010: c = a[2] ^ b[2];
        4'b1110: c = a[3] ^ b[3];

        4'b0011: c = a[0] & ~b[0];
        4'b0111: c = a[1] & ~b[1];
        4'b1011: c = a[2] & ~b[2];
        4'b1111: c = a[3] & ~b[3];
    endcase

endmodule

But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7. Is there a way to
write this so it'll fit in 4 LUTs without resorting to instantiating
the MUXF5/MUXF6 manually?


Article: 76779
Subject: Re: Trying to get 4 LUTs, MUXF5, MUXF6 in Spartan-3
From: Chris Ebeling <christopher.ebeling@xilinx.com>
Date: Fri, 10 Dec 2004 17:07:26 -0800
Links: << >>  << T >>  << A >>
Nope,

Quote:
But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7.

This is exactly what you should expect for a 4 bit select vector
MUXF6 = 8:1, MUXF7 = 16:1.

If you run my example through the tools you can review the results and
see that each (of the 4 LUTs) is already fully unitized with 4 inputs
(f, s(0), A#, B#).  So you can't get anything more complex, without
using more logic.

Your example will underutilize the LUT4s, 3 inputs A#,B#,& f.
With the select bits driving MUXF5/MUXF6/MUXF7. So you could
make is still more  complicated (add a mask bit for example) and not
use any additional resources.

Chris

Artenz wrote:

> On Fri, 10 Dec 2004 14:09:00 -0800, Chris Ebeling wrote:
>
> > Annti,
> >
> > Your correct this can be done. But your coding style isn't exactly conducive
> > to the synthesis of a mux. Case statements are the preferred coding style if
> > you want the MUXF5/MUXF6/MUXF# resources to be used. The dedicated
> > muxes also roughly correlate to a particular width MUXF5 == 4:1,
> > MUXF6 == 8:1. etc.
> >
> > So if you want to get a MUXF6, at three bit case statement is appropriate:
> >
> > module lut_test2(a,b,c,f,s);
> >     input f;
> >     input [1:0] s;
> >     input [3:0] a;
> >     input [3:0] b;
> >     output c;
> >
> > //Implicit wires exist
> > //wire [3:0] a;
> > //wire [3:0] b;
> > //wire f;
> > //wire [1:0] s;
> >
> > reg caseout;
> > //wire [2:0] sel = {s,f};
> >
> > always @(s or f or a or b)
> > case ({s,f})
> > //f is 0
> > 3'b000 :  caseout = (a[0] & b[0]);
> > 3'b010 :  caseout = (a[1] & b[1]);
> > 3'b100 :  caseout = (a[2] & b[2]);
> > 3'b110 :  caseout = (a[3] & b[3]);
> > //f is 1
> > 3'b001 :  caseout = (a[0] | b[0]);
> > 3'b011 :  caseout = (a[1] | b[1]);
> > 3'b101 :  caseout = (a[2] | b[2]);
> > 3'b111 :  caseout = (a[3] | b[3]);
> > endcase
> >
> > assign c = caseout;
> >
> > endmodule
>
> Chris,
>
> Thanks for the info. I tried the same method on my slightly more
> complicated design:
>
> module lut_test( a, b, c, f, s );
>     input [3:0] a, b;
>     input [1:0] s;
>     input [1:0] f;
>     output c;
>
> reg  c;
>
> always @(a or b or f or s)
>     case({s, f})
>         4'b0000: c = a[0] & b[0];
>         4'b0100: c = a[1] & b[1];
>         4'b1000: c = a[2] & b[2];
>         4'b1100: c = a[3] & b[3];
>
>         4'b0001: c = a[0] | b[0];
>         4'b0101: c = a[1] | b[1];
>         4'b1001: c = a[2] | b[2];
>         4'b1101: c = a[3] | b[3];
>
>         4'b0010: c = a[0] ^ b[0];
>         4'b0110: c = a[1] ^ b[1];
>         4'b1010: c = a[2] ^ b[2];
>         4'b1110: c = a[3] ^ b[3];
>
>         4'b0011: c = a[0] & ~b[0];
>         4'b0111: c = a[1] & ~b[1];
>         4'b1011: c = a[2] & ~b[2];
>         4'b1111: c = a[3] & ~b[3];
>     endcase
>
> endmodule
>
> But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7. Is there a way to
> write this so it'll fit in 4 LUTs without resorting to instantiating
> the MUXF5/MUXF6 manually?


Article: 76780
Subject: Re: Inferring dual port RAMs with different bus widths.
From: "Simon Peacock" <nowhere@to.be.found>
Date: Sat, 11 Dec 2004 16:41:56 +1300
Links: << >>  << T >>  << A >>
from what I understand.. you cant infer different bus widths sorry..  Not
even Synplify can

Simon


"Elder Costa" <elder.costa@terra.com.br> wrote in message
news:31umvgF3h46qjU1@individual.net...
> Hello folks.
>
> I have implemented the entity bellow by instantciating a dual ported
> block RAM with different bus widths (RAMB16_S18_S36 - I am developing
> for Virtex II or Spartan 3). Whereas it is relatively simple to do it by
> instantiacing the component from Xilinx library, I wonder if there is a
> way to code the module so that Xst infers the block RAM. I tried in one
> or two ways but it used logic in slices instead of BRAM and it required
> a lot of logic for a 1kib RAM. Could somebody give a hint on this? I
> looked at Xilinx documentation and couldn't find an example for this
> particular problem.
>
> entity gaintab is
>      Port (
>          -- ports de acesso do processador
>          i_ProcAddr      : in std_logic_vector(9 downto 0);
>          i_ProcDataIn    : in std_logic_vector(15 downto 0);
>          i_ProcWr        : in std_logic;
>          i_ProcEn        : in std_logic;
>          i_ProcClk       : in std_logic;
>          o_ProcDataOut   : out std_logic_vector(15 downto 0);
>          -- ports de acesso interno (fpga)
>          i_FpgaAddr      : in std_logic_vector(6 downto 0);
>          i_FpgaClk       : in std_logic;
>          o_FpgaDataOut   : out std_logic_vector(31 downto 0)
>      );
> end gaintab;
>
>
> TIA.
>
> Elder.
>



Article: 76781
Subject: Re: default changes with new release
From: "Brian Davis" <brimdavis@aol.com>
Date: 10 Dec 2004 20:07:04 -0800
Links: << >>  << T >>  << A >>
Colin wrote:
>
> On a somewhat related subject I have fiddled with setting the
> iostandard in VHDL. <snip> but what about a simple net out of
> the top level entity with IOB created by synthesis.
>
See example below

Brian

--
-- I/O pin attribute example for Xilinx Spartan3 eval kit
--
entity ram_test is
port
(
--
-- default clock osc.
--
clk50_in  : in  std_logic;

--
-- 4 pushbuttons, 8 slide switches
--
pb  : in  std_logic_vector(3 downto 0);
sw  : in  std_logic_vector(7 downto 0);

--
-- individual leds
--
led : out std_logic_vector(7 downto 0);

--
-- muxed seven segment LEDs
--
digit  : out  std_logic_vector(3 downto 0);

seg_a  : out std_logic;
seg_b  : out std_logic;
seg_c  : out std_logic;
seg_d  : out std_logic;
seg_e  : out std_logic;
seg_f  : out std_logic;
seg_g  : out std_logic;
seg_dp : out std_logic;

--
-- SRAM signals
--

--
-- shared control and address
--
ram_we_l   : out std_logic;
ram_oe_l   : out std_logic;
ram_addr   : out std_logic_vector(17 downto 0);

--
-- per-bank SRAM signals
--
ram_a_dat  : inout  std_logic_vector(15 downto 0);
ram_a_ce_l : out std_logic;
ram_a_ub   : out std_logic;
ram_a_lb   : out std_logic;

ram_b_dat  : inout  std_logic_vector(15 downto 0);
ram_b_ce_l : out std_logic;
ram_b_ub   : out std_logic;
ram_b_lb   : out std_logic

);

attribute loc        : string ;
attribute slew       : string ;
attribute drive      : string ;
attribute iostandard : string ;

attribute loc        of clk50_in   : signal is "t9";
attribute iostandard of clk50_in   : signal is "LVCMOS33";

attribute loc        of pb         : signal is "l14,l13,m14,m13";
attribute iostandard of pb         : signal is "LVCMOS33";

attribute loc        of sw         : signal is
"k13,k14,j13,j14,h13,h14,g12,f12";
attribute iostandard of sw         : signal is "LVCMOS33";

attribute loc        of led        : signal is
"p11,p12,n12,p13,n14,l12,p14,k12";
attribute iostandard of led        : signal is "LVCMOS33";
attribute slew       of led        : signal is "SLOW";

attribute loc        of digit      : signal is "e13,f14,g14,d14";
attribute iostandard of digit      : signal is "LVCMOS33";
attribute slew       of digit      : signal is "SLOW";

attribute loc        of seg_a      : signal is "e14";
attribute iostandard of seg_a      : signal is "LVCMOS33";
attribute slew       of seg_a      : signal is "SLOW";

attribute loc        of seg_b      : signal is "g13";
attribute iostandard of seg_b      : signal is "LVCMOS33";
attribute slew       of seg_b      : signal is "SLOW";

attribute loc        of seg_c      : signal is "n15";
attribute iostandard of seg_c      : signal is "LVCMOS33";
attribute slew       of seg_c      : signal is "SLOW";

attribute loc        of seg_d      : signal is "p15";
attribute iostandard of seg_d      : signal is "LVCMOS33";
attribute slew       of seg_d      : signal is "SLOW";

attribute loc        of seg_e      : signal is "r16";
attribute iostandard of seg_e      : signal is "LVCMOS33";
attribute slew       of seg_e      : signal is "SLOW";

attribute loc        of seg_f      : signal is "f13";
attribute iostandard of seg_f      : signal is "LVCMOS33";
attribute slew       of seg_f      : signal is "SLOW";

attribute loc        of seg_g      : signal is "n16";
attribute iostandard of seg_g      : signal is "LVCMOS33";
attribute slew       of seg_g      : signal is "SLOW";

attribute loc        of seg_dp     : signal is "p16";
attribute iostandard of seg_dp     : signal is "LVCMOS33";
attribute slew       of seg_dp     : signal is "SLOW";

attribute loc        of ram_addr   : signal is
"l3,k5,k3,j3,j4,h4,h3,g5,e4,e3,f4,f3,g4,l4,m3,m4,n3,l5";
attribute iostandard of ram_addr   : signal is "LVCMOS33";
attribute slew       of ram_addr   : signal is "SLOW";
attribute drive      of ram_addr   : signal is "24";

attribute loc        of ram_we_l   : signal is "g3";
attribute iostandard of ram_we_l   : signal is "LVCMOS33";
attribute slew       of ram_we_l   : signal is "FAST";
attribute drive      of ram_we_l   : signal is "24";

attribute loc        of ram_oe_l   : signal is "k4";
attribute iostandard of ram_oe_l   : signal is "LVCMOS33";
attribute slew       of ram_oe_l   : signal is "SLOW";
attribute drive      of ram_oe_l   : signal is "12";

attribute loc        of ram_a_dat  : signal is
"r1,p1,l2,j2,h1,f2,p8,d3,b1,c1,c2,r5,t5,r6,t8,n7";
attribute iostandard of ram_a_dat  : signal is "LVCMOS33";
attribute slew       of ram_a_dat  : signal is "SLOW";
attribute drive      of ram_a_dat  : signal is "6";

attribute loc        of ram_a_ce_l : signal is "p7";
attribute iostandard of ram_a_ce_l : signal is "LVCMOS33";
attribute slew       of ram_a_ce_l : signal is "SLOW";
attribute drive      of ram_a_ce_l : signal is "12";

attribute loc        of ram_a_lb   : signal is "p6";
attribute iostandard of ram_a_lb   : signal is "LVCMOS33";
attribute slew       of ram_a_lb   : signal is "SLOW";
attribute drive      of ram_a_lb   : signal is "12";

attribute loc        of ram_a_ub   : signal is "t4";
attribute iostandard of ram_a_ub   : signal is "LVCMOS33";
attribute slew       of ram_a_ub   : signal is "SLOW";
attribute drive      of ram_a_ub   : signal is "12";

attribute loc        of ram_b_dat  : signal is
"n1,m1,k2,c3,f5,g1,e2,d2,d1,e1,g2,j1,k1,m2,n2,p2";
attribute iostandard of ram_b_dat  : signal is "LVCMOS33";
attribute slew       of ram_b_dat  : signal is "SLOW";
attribute drive      of ram_b_dat  : signal is "6";

attribute loc        of ram_b_ce_l : signal is "n5";
attribute iostandard of ram_b_ce_l : signal is "LVCMOS33";
attribute slew       of ram_b_ce_l : signal is "SLOW";
attribute drive      of ram_b_ce_l : signal is "12";

attribute loc        of ram_b_lb   : signal is "p5";
attribute iostandard of ram_b_lb   : signal is "LVCMOS33";
attribute slew       of ram_b_lb   : signal is "SLOW";
attribute drive      of ram_b_lb   : signal is "12";

attribute loc        of ram_b_ub   : signal is "r4";
attribute iostandard of ram_b_ub   : signal is "LVCMOS33";
attribute slew       of ram_b_ub   : signal is "SLOW";
attribute drive      of ram_b_ub   : signal is "12";

end ram_test;


Article: 76782
Subject: [Altera] lpm_decode works great, but where is lpm_encode ???
From: GieTeGie <tomaszdemborNOSPAM@wp.pl>
Date: Sat, 11 Dec 2004 08:07:32 +0100
Links: << >>  << T >>  << A >>
Hi,
I'm working on project of digital encoder '1 from 16' to natural binary 
code on LPM elements. I'm able to do it in VHDL, AHDL, on gates, 74148 
etc. but I didn't find function like lpm_encode in MAX+plus II 10.1, or 
any other parameterized function from LPM library, that will allow me to 
do my encoder. There is a lpm_decode function only.
Is there any solution?

Thanks for any advice
Best regards

Article: 76783
Subject: Re: Trying to get 4 LUTs, MUXF5, MUXF6 in Spartan-3
From: "Antti Lukats" <antti@case2000.com>
Date: Sat, 11 Dec 2004 08:57:19 +0100
Links: << >>  << T >>  << A >>

"Chris Ebeling" <christopher.ebeling@xilinx.com> wrote in message
news:41BA1E7C.4F6EF452@xilinx.com...
> Annti,
>
> Your correct this can be done. But your coding style isn't exactly
conducive
:)
thanks - well that coding style isnt mine it was from original poster, it
did surprise, I have never used that and possible never will.
surprising is that it yields to correct synthesis but not using muxF while
the other styles will use muxF

I think more in low level terms.
started 1979 (or even before) with 7400 "things" today trying to use only
minimal set ot vhdl/verilog

antti



Article: 76784
Subject: Re: Trying to get 4 LUTs, MUXF5, MUXF6 in Spartan-3
From: Artenz <usenet+5@ladybug.xs4all.nl>
Date: Sat, 11 Dec 2004 09:22:01 +0100
Links: << >>  << T >>  << A >>
On Fri, 10 Dec 2004 17:07:26 -0800, Chris Ebeling wrote:

> Nope,
> 
> Quote:
> But this resulted in 8 LUTs, 4xMUXF5, 2xMUXF6, and 1xMUXF7.
> 
> This is exactly what you should expect for a 4 bit select vector
> MUXF6 = 8:1, MUXF7 = 16:1.
> 
> If you run my example through the tools you can review the results and
> see that each (of the 4 LUTs) is already fully unitized with 4 inputs
> (f, s(0), A#, B#).  So you can't get anything more complex, without
> using more logic.

You can fit it in 4 LUTs, if you reorder things a bit.

Feed each of the 4 LUTs with (f[0], f[1], A#, B#), and then select
the output bit with the MUXF5, MUXF6, feeding them with s[0] and s[1]
respectively.

What I originally started with is the following:

module lut_test( a, b, c, f, s );
    input [3:0] a, b;
    input [1:0] s;
    input [1:0] f;
    output c;

reg [3:0] lut_out;
reg c;

always @(a or b or f)
    case(f)
        2'b00: lut_out <= a & b;
        2'b01: lut_out <= a | b;
        2'b10: lut_out <= a ^ b;
        2'b11: lut_out <= a & ~b;
    endcase

always @(lut_out or s)
    case(s)
        2'b00: c = lut_out[0];
        2'b01: c = lut_out[1];
        2'b10: c = lut_out[2];
        2'b11: c = lut_out[3];
    endcase
endmodule

Now, if I run that through the tools I get 4 LUTs to calculate
each bit of lut_out[3:0], as I would expect.

However, the 4-1 mux is not implemented using the MUXF5/MUXF6, as I
had hoped, but using another 2xLUT3 + MUXF5. By hard instantiations of
a MUXF5/MUXF6 pair, I can force the desired packing, but I would like
to avoid tricks like that because it makes the code less readable and
harder to port to other devices. Is there any way to achieve that ?


Article: 76785
Subject: Re: PCI design with vhdl
From: Ben Popoola <b.popoola@ntlworld.com>
Date: Sat, 11 Dec 2004 12:16:51 GMT
Links: << >>  << T >>  << A >>
kender wrote:
> Hi, I've read that many of you have realized PCI card using FPGAs... 
> I have to do something similar, but I hope simpler, for my thesis (I'm
> an university student): I have to realize a PCI core (but it should
> work as a target only device) that should transfer some data that is
> collected by the FPGA to an embedded processor, via the PCI bus...
> I "just" have to realize the PCI component for the FPGA as all the
> other stuff have already been done (and maybe connect the component to
> data acquisition logic) and the processor already has its own PCI
> controller (that acts as master and arbiter), so my question is: where
> should I start from?
> 
> I've read part of the PCI Local Bus Specification but I have some
> doubts about the addressing differences..

What might help is to write the testbench first!!

Although this sounds odd, what results from this is not only will you 
have to fully understand the PCI target portion of the specification, it 
will also you in the planning of the datapath of your PCI target core.

It works for me!!



Article: 76786
Subject: Re: PCI design with vhdl
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 11 Dec 2004 08:06:43 -0800
Links: << >>  << T >>  << A >>
Ben Popoola wrote:

> What might help is to write the testbench first!!
> Although this sounds odd, what results from this is not only will you 
> have to fully understand the PCI target portion of the specification, it 
> will also you in the planning of the datapath of your PCI target core.
> It works for me!!

I agree. Even commercial cores have free
documentation and an evaluation model and testbench.
For me step one is to make the core model run with
it's own testbench on my simulator.
Step two is to make the trial core play with the rest of
my design in an HDL simulation. What better way to
learn and understand the interface?

However, I realize that some designers prefer a
download and go, trial and error process over
hdl simulation. This doesn't work for me,
but I don't doubt that works for some.

          -- Mike Treseler


Article: 76787
Subject: Re: Software controllable clock generator, Xilinx Virtex-II
From: Kolja Sulimma <news@sulimma.de>
Date: Sun, 12 Dec 2004 01:02:49 +0100
Links: << >>  << T >>  << A >>
Stephen Williams wrote:

> So is there a way that I'm missing for getting a single software-
> selectable output clock with a nearly 50/50 duty cycle ranging
> from 20 to 85MHz? On an XC2V3000-4?

Peter Alfke did a design were he build a phase accumulator running at a 
few hundred MHz to generate a square wave with almost arbitrary 
frequency but a few ns jitter.
If you feed the result threw a DCM apparently the jitter is reduced to 
about 100ps. That should be good enough for your application.

Kolja Sulimma

Article: 76788
Subject: Re: Software controllable clock generator, Xilinx Virtex-II
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sun, 12 Dec 2004 11:26:21 +0100
Links: << >>  << T >>  << A >>

"Kolja Sulimma" <news@sulimma.de> schrieb im Newsbeitrag
news:41bb8bc2$0$16030$9b4e6d93@newsread4.arcor-online.net...

> > So is there a way that I'm missing for getting a single software-
> > selectable output clock with a nearly 50/50 duty cycle ranging
> > from 20 to 85MHz? On an XC2V3000-4?
>
> Peter Alfke did a design were he build a phase accumulator running at a
> few hundred MHz to generate a square wave with almost arbitrary
> frequency but a few ns jitter.
> If you feed the result threw a DCM apparently the jitter is reduced to
> about 100ps. That should be good enough for your application.

Are you sure? I thought that the DCM does NOT reduce jitter and furthermore
has very tight input jitter reqirements (300ps cycle to cycle, 1ns periodic
max.)
Its a DCM, not a PLL.

Regards
Falk




Article: 76789
Subject: Re: Spartan3 Block RAM from WebPACK
From: "nshimizu" <nshimizu@ip-arch.jp>
Date: Sun, 12 Dec 2004 06:46:31 -0500
Links: << >>  << T >>  << A >>
I resolved by myself.

Regards,

Naohiko


Article: 76790
Subject: UART receiver
From: "Konstantin Dols" <Konstantin.Dols@rwth-aachen.de>
Date: Sun, 12 Dec 2004 13:25:31 +0100
Links: << >>  << T >>  << A >>


Greetings !

I'm looking for a simple RS232 UART16550 receiver for my tiny cyclone board
for different baudrates, 8databits, 1stop&startbit and no(!) partity and  
handshake stuff.

I found several free VHDL implementations in the net but compared to what  
I need
they are to complicated and appear like shooting with missiles on birds ;-)



The entity might have a simple structure like this:

entity receiver is
	generic(	frequency	: integer := 10000000; -- e.g. for 10MHz
			baudrate	: integer := 9600	     -- e.g. for 9600bps
		 );

	port(	clk		: in  std_logic;	-- clockspeed is 'frequency'
		reset 	: in  std_logic;	-- resets the receiver
		receiver	: in  std_logic;	-- input from receive pin from RS232 connector

		char_avail	: out std_logic;	-- indicated that a valid char has beed  
received
		char		: out std_logic_vector(7 downto 0) -- received char, only   
available for one clock
	    );
end receiver;

The 'reciever' values are 'active high'...

This structure gives the responsibility for catching received data in time  
to the user
but surely allowes adding a FIFO.


Probably this question has been asked about 47283407239 times in this group
so please just send me a usefull link or code snippet...


Konstantin

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Article: 76791
Subject: Re: UART receiver
From: "Rob Young" <rwyoung@ieee.xspam.org>
Date: Sun, 12 Dec 2004 12:08:59 -0600
Links: << >>  << T >>  << A >>
"Konstantin Dols" <Konstantin.Dols@rwth-aachen.de> wrote in message 
news:opsiv94toznxvpac@pc113...
>
>
> Greetings !
>
> I'm looking for a simple RS232 UART16550 receiver for my tiny cyclone 
> board
> for different baudrates, 8databits, 1stop&startbit and no(!) partity and 
> handshake stuff.
>
> I found several free VHDL implementations in the net but compared to what 
> I need
> they are to complicated and appear like shooting with missiles on birds 
> ;-)
>

www.opencores.org (but probably something you have already investigated).

The UART "problem" seems to be a pretty common example in various VHDL 
books.  I think Ben Cohen's book has an implementation as well as Navabi's. 
I can't comment on how or if they work (synthesis).

Have you prowled around on the Xilinx web site.  A quick search popped up 
lots of internal links, for example

http://www.xilinx.com/bvdocs/appnotes/xapp699.pdf
http://www.xilinx.com/bvdocs/appnotes/xapp223.pdf

but these may be the "missles" you are refering to.  xapp223.pdf does look 
promising however...

If it was me, I'd start with one of the "missles" and start paring it down, 
removing features.

>
>
> The entity might have a simple structure like this:
>
> entity receiver is
> generic( frequency : integer := 10000000; -- e.g. for 10MHz
> baudrate : integer := 9600      -- e.g. for 9600bps
> );
>
> port( clk : in  std_logic; -- clockspeed is 'frequency'
> reset : in  std_logic; -- resets the receiver
> receiver : in  std_logic; -- input from receive pin from RS232 connector
>
> char_avail : out std_logic; -- indicated that a valid char has beed 
> received
> char : out std_logic_vector(7 downto 0) -- received char, only   available 
> for one clock
>     );
> end receiver;
>
> The 'reciever' values are 'active high'...
>
> This structure gives the responsibility for catching received data in time 
> to the user
> but surely allowes adding a FIFO.
>
>
> Probably this question has been asked about 47283407239 times in this 
> group
> so please just send me a usefull link or code snippet...
>
>
> Konstantin
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ 



Article: 76792
Subject: PLLs on biphase mark signals
From: "Adam" <1@1.com>
Date: Sun, 12 Dec 2004 18:35:02 GMT
Links: << >>  << T >>  << A >>
Hello all,

  Will an FPGA PLL lock onto a biphase mark(Manchester ??) encoded signal?
I'm trying to build an SPDIF receiver and am wondering if its possible to
directly connect the input signal(after analog level adjustment) to an FPGA
and read the level at the 90 and 270 degree phases.  If frames are
continuously being transmitted when the PLL attempts to lock on, how does it
know which frequency to use?  It seems if all zeros are being transmitted
the PLL will lock to half the frequency it should.



Article: 76793
Subject: Xilinx Christmas present: EDK 6.3 !
From: "Antti Lukats" <antti@case2000.com>
Date: Sun, 12 Dec 2004 20:07:39 +0100
Links: << >>  << T >>  << A >>
Hi all,

Christmas is closing so everybody is making presents. So is Xilinx. I just
got mine! Read the story below:
***********************************************************************
ISE/EDK/ChipScope update to 6.3

In attempt to get our EDK based SoC systems up and running again in EDK 6.3
I ended up creating simplest possible SoC using BSB (because none of working
EDK 6.2 projects worked after update no matter any attempts to get them
working). Attempted to debug in XMD: fatal disaster BRAM can be loaded from
elf, can also look at the disassembly all is ok. Any attempt to trace or
execute simplest program and all goes pasta, not any more possible to view
(or write) even to LMB RAM ! Then I added ChipScope bus analyzer core to OPB
bus. And simplified the test application. Here is the source code:

-----------------------------------------------------------
// Xilinx Christmas Lights application ver 1.0
while (1) {
   i++;
   WriteToGPOutput(XPAR_LED_7SEGMENT_BASEADDR, i);
 }
-----------------------------------------------------------
This is running in MicroBlaze SoC at system frequency 50MHz. Pretty much all
leds should be lit, right? Or?

It looks like (due to Christmas feeling !?) Xilinx tools have decided for me
that my application should be "Christmas Lights" - because that how it
works! The LEDS are blinking in fancy true random fashion at "human" blink
rate, ie very slowly. The visual effects are pretty cool, really!

When looking in ChipScope (OPB bus analyzer) I see writes to the GPIO port:
0x00800000, 0x01000000,0x02000000,0xFFFFFFE,0xFFFFFFC... Those are 5 example
sequential writes to GPIO port (from the above program!), notice that
between the GPIO writes there is always more than 512 OPB clocks of no OPB
bus activity.

And yes, I did UNINSTALL ALL ISE/EDK/ChipScope before update, then installed
all the new versions plus service packs, etc..

***********************************************************************

Antti



Article: 76794
Subject: Inconsistant compilations with quartus
From: daniel.tasc@xtra.co.nz (Daniel)
Date: 12 Dec 2004 12:28:58 -0800
Links: << >>  << T >>  << A >>
I are having truoble with quartus comiling my designs. I did a design
in schematic and it worked correctly until I inserted a AHDL uart at
witch time the uart was unstable every thing else worked fine. My
supplier advised me that I shouldn't use the schematic as it doesn't
compile properly and things can work one time and then do a small
change and they do not the next. So I wrote it all out with his help
in AHDL. Things eventually started to fall into place excpt that a
have a very unstable design. sure the uart worked well but every time
I compile it with a slight change the something else does not work
properly. Conseqently I have no faith in AHDL file at all. The
schematic still works fine without the uart. Has anybody else come
accross this and do they have any solutions for the problem. Is it a
common consencuse that schematic is not the method that should be used
and AHDL or VHDl is the only reliable way to program these? I are
using quartus 4.2 sp2 WE and flex6000 device.

Daniel

Article: 76795
Subject: Re: Inconsistant compilations with quartus
From: "Vaughn Betz" <vaughn_and_corinne@sympatico.ca>
Date: Sun, 12 Dec 2004 16:58:48 -0500
Links: << >>  << T >>  << A >>
Hi Daniel,

It's quite unlikely that this is a problem with the AHDL synthesis support
in Quartus.  That support is very extensively tested, and used by thousands
of users, so it's much, much more likely that there is a problem with your
UART design than a problem with the AHDL support in Quartus.

Usually "unstable" hardware that works sometimes and not others, or works on
one compile and not others is due to race conditions or missed timing
constraints in your design.  Have you followed proper asynchronous design
practice for all asynchronous transfers in your design?  If you search this
newsgroup, you'll find some pointers to good documents giving tutorials on
asynchronous design.

Have you set timing constraints on all your synchronous transfers, and
checked the Quartus timing report to be sure they were all met?

Are you using a disciplined reset scheme, or performing  a recovery &
removal timing analysis (see Quartus 4.2 help) to check your design will
reset cleanly?

Vaughn
Altera

"Daniel" <daniel.tasc@xtra.co.nz> wrote in message
news:4953ed5f.0412121228.4c95b803@posting.google.com...
> I are having truoble with quartus comiling my designs. I did a design
> in schematic and it worked correctly until I inserted a AHDL uart at
> witch time the uart was unstable every thing else worked fine. My
> supplier advised me that I shouldn't use the schematic as it doesn't
> compile properly and things can work one time and then do a small
> change and they do not the next. So I wrote it all out with his help
> in AHDL. Things eventually started to fall into place excpt that a
> have a very unstable design. sure the uart worked well but every time
> I compile it with a slight change the something else does not work
> properly. Conseqently I have no faith in AHDL file at all. The
> schematic still works fine without the uart. Has anybody else come
> accross this and do they have any solutions for the problem. Is it a
> common consencuse that schematic is not the method that should be used
> and AHDL or VHDl is the only reliable way to program these? I are
> using quartus 4.2 sp2 WE and flex6000 device.
>
> Daniel



Article: 76796
Subject: Re: Virtex-II PRO, DDR2 SDRAM, RocketIO
From: Tullio Grassi <tgrassi@mail.cern.ch>
Date: Sun, 12 Dec 2004 23:03:10 +0100
Links: << >>  << T >>  << A >>
On Tue, 7 Dec 2004, Marc Randolph wrote:

> ...  In short, I think we're doing a pretty good
> job of exploring the limits on that chip, and the MGT keeps running
> error free, even at industrial temperatures (junction of 100C).
> 
> Having used them, here are my suggestions:
> 
> 1. Follow the Xilnix guidelines for power filtering on the MGT and
> vccaux.
> 2. Use a low jitter clock reference for the MGT.  No PLL or DLL
> sources.  A cheap crystal osc will do just fine.
> 3. Use the BREFCLK pin for the MGT if possible.
> 4. Use the flip-chip package if possible.  Not a requirement, but
> it'll just make signals, ground, and power just that much better.
> 


What is your feeling about using RocketIO over 5 meters of copper cable ?
Assuming we follow your suggestions and that we get good cables and
connectors, what is the data rate that we could reach reliably ?

Thanks,

  Tullio Grassi

Article: 76797
Subject: LUT and MUXF5 placement
From: Jim George <"jimgeorge at softhome dot net">
Date: Sun, 12 Dec 2004 16:14:20 -0700
Links: << >>  << T >>  << A >>
Hello,
    I wanted to know how you instruct MAP to place an LUT and a MUXF5 
into the same slice. Looking at the V2 Datasheet, it seems to be an 
allowed combination. However, I get a MAP error stating that the LUT and 
MUXF5 cannot share the same slice. I'm specifiying the constraints 
within the VHDL (again, inspired by Ray Andraka).
    Thanks!
    -Jim

Article: 76798
Subject: Re: Virtex-II PRO, DDR2 SDRAM, RocketIO
From: Al Gosselin <algst@cox.net>
Date: Sun, 12 Dec 2004 18:38:14 -0500
Links: << >>  << T >>  << A >>
Tullio Grassi wrote:
> On Tue, 7 Dec 2004, Marc Randolph wrote:
> 
> 
>>...  In short, I think we're doing a pretty good
>>job of exploring the limits on that chip, and the MGT keeps running
>>error free, even at industrial temperatures (junction of 100C).
>>
>>Having used them, here are my suggestions:
>>
>>1. Follow the Xilnix guidelines for power filtering on the MGT and
>>vccaux.
>>2. Use a low jitter clock reference for the MGT.  No PLL or DLL
>>sources.  A cheap crystal osc will do just fine.
>>3. Use the BREFCLK pin for the MGT if possible.
>>4. Use the flip-chip package if possible.  Not a requirement, but
>>it'll just make signals, ground, and power just that much better.
>>
> 
> 
> 
> What is your feeling about using RocketIO over 5 meters of copper cable ?
> Assuming we follow your suggestions and that we get good cables and
> connectors, what is the data rate that we could reach reliably ?
> 
> Thanks,
> 
>   Tullio Grassi

What kind of copper cable? What sort of drive will you be doing? Any 
preemphasis?

This is a perfect thing to try in simulation. Set up your drivers, 
receivers, and cable, then look at some eyes. Don't forget the 
connectors and the traces on the PC boards.

Article: 76799
Subject: Re: PLLs on biphase mark signals
From: Jim George <"jimgeorge at softhome dot net">
Date: Sun, 12 Dec 2004 16:49:16 -0700
Links: << >>  << T >>  << A >>
Adam wrote:

> Hello all,
> 
>   Will an FPGA PLL lock onto a biphase mark(Manchester ??) encoded signal?
> I'm trying to build an SPDIF receiver and am wondering if its possible to
> directly connect the input signal(after analog level adjustment) to an FPGA
> and read the level at the 90 and 270 degree phases.  If frames are
> continuously being transmitted when the PLL attempts to lock on, how does it
> know which frequency to use?  It seems if all zeros are being transmitted
> the PLL will lock to half the frequency it should.
> 
> 

Probably not for a Xilinx Virtex II, Spartan III or Virtex II Pro, the 
FPGA specs state that the DCM inputs must have < 1ns period jitter, 
outside which they will lose lock. A true-PLL design may be more 
forgiving, though.

-Jim



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search