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
2017JanFebMarApr2017

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 35975

Article: 35975
Subject: Re: transferring data between related clocks
From: Patrick Hibbs <phibbs@ti.com>
Date: Thu, 25 Oct 2001 08:39:21 -0500
Links: << >>  << T >>  << A >>
What's wrong with a robust asynchronous fifo???

Pat

hamish@cloud.net.au wrote:

>In a design I'm working on at the moment, I have new data on every
>rising edge of a 175 MHz clock and I need to transfer it to
>be synchronous to a 350 MHz clock. No uncertainty in the
>350 MHz data is acceptable.
>
>To generate the clocks, I have an external 350 MHz source,
>and I'm using the CLK0 and CLKDV (divided by 2) outputs on
>a DCM. I'm using a Xilinx 2V6000-5. 
>
>I have global buffers for each clock, but I expect there
>will be some skew between the clocks, since the 350 MHz
>clock is lightly loaded (200-300 FFs), compared to the
>175 MHz clock (2500 FFs). So I might violate the hold
>time on the 350 MHz FFs if I'm not careful.
>
>Some things I have considered:
>
>1. Sample the 175 MHz data with the 350 MHz clock directly. Could
>   violate the hold time if there is sufficient skew between the
>   clocks and the logic/net delays are particularly small. Also,
>   I have 68 bits of data, so this isn't too good.
>
>2. Sample the 175 MHz data with the next falling edge of the
>   350 MHz clock. A half-period of the 350 MHz clock is only
>   1.429 ns. Allowing for jitter, the FF to FF delay needs
>   to be about 1.3 ns, on all 68 data paths. Plus another
>   68 paths to get it back to the rising edge, possibly.
>
>3. Generate an enable signal at 175 MHz and sample it using
>   the falling edge of the 350 MHz. Same problem as #2,
>   but with only 1-2 bits. I did try this, with hand placement
>   of the FFs, and got the delay down to 1.41 ns, which is
>   impressive (effectively over 700 MHz performance), but
>   probably not enough. Using the enable signal, the data
>   bits have a full 350 MHz period of setup and hold (less skew).
>
>4. Just do it (like #1), but add some deliberate delays in the
>   data path to try to guarantee that the delays are larger
>   than the clock skew. Deliberate delays could include hand
>   placement to create long net delays, or instantiating
>   LUTs to act as buffers. This could be limited to a single
>   enable bit, with the data bits transferred safely on
>   the next 350 MHz edge.
>
>#3 is preferred, but not quite fast enough. #4 seems the
>next best option, but it makes me a bit uncomfortable.
>
>Can anyone add any other suggestions? Or try to convince
>me that #4 is acceptable, or otherwise?
>
>I saw a new Xilinx app note, XAPP265, which described a design
>for doing an 8:1 SERDES. That design would have a similar
>requirement to mine. It uses an 1/4 frequency clock instead
>though, which seems to simplify the problem a bit.
>
>
>thanks,
>Hamish
>


Article: 35976
Subject: Re: Recommend a book
From: "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in>
Date: Thu, 25 Oct 2001 19:09:37 +0530
Links: << >>  << T >>  << A >>
Hi,

"Ray Andraka" <ray@andraka.com> wrote in message
news:3BD814AD.2E81FE2E@andraka.com...
> I think perusing the FPGA vendor's websites, especially the design
for
> synthesis and applications notes pages will get you farther than a
book,
> and is likely to be more current.
>

    Agreed, but if someone wants to learn the very basics (like CLBs,
routability, number of CLBs utilized etc. - I am sure there are more),
I feel this book is good, again I recommend this mainly as a VHDL book
with some Programmable stuff "embedded".

    Let me put it this way, if I were to switch to FPGAs I will go
through this book once before looking at Vendors' stuff.

Regards,
Srinivasan

>

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)




Article: 35977
Subject: Re: How to make an implementable big counter?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 25 Oct 2001 13:40:42 GMT
Links: << >>  << T >>  << A >>
A count to 10^7 needs only 24 bits, which should require only 12 slices or
24 LEs to implement if it uses the fast carry chain.  If you want a modulo
10^7 count, use a downcounter that gets reloaded when it reaches its
terminal count (goes negative).  That way, there are no resources used to
do the compare, and by changing the load value the modulus is easily
changed.  Alternatively, if you need the counter bits out and the count
modulus never changes, you needn't decode all the bits:

1000000 = 989680/h   numbers above this are never reached, so you only
need to decode the '1' bits.  so the decode need only look at bits
23,20,19,15,12,10,9, and 7.  That's only 8 of the 24 bits.

Jerre wrote:

> Hello,
>
> In my design I need to make a synchronous counter that counts, let's
> say, till 1000000. (Actual aim for counter is to built in a delay).  I
> do this by the use of integer type signals and with each clock'event I
> add 1 till I reach the wanted 1000000.  When I try to implement this
> in an FPGA it consumes a very high amount of CLBs and it seems very
> disastrous for the maximum reachable clock freq.
>
> If I would use an unsigned type would it differ a lot?
>
> Other tips?
>
> Greetz from a newbie,
>
> Jerre.

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35978
Subject: Re: transferring data between related clocks
From: Ray Andraka <ray@andraka.com>
Date: Thu, 25 Oct 2001 13:51:12 GMT
Links: << >>  << T >>  << A >>
YOu can buy a little more margin by synthesizing a 175 MHz clock enable
in the 350 MHz clock domain, then using that to effectively sample the
175 MHz data in the middle of the sample.  The synthesized clock enable
has to be synchronized to your 175 MHz clock, obviously.  To do that,
sample your 175 MHz clock with the falling edge of the 350 MHz clock,
then retime that to the rising edge.  These 2 flip-flops should be
floorplanned so that the delay between them does not exceed your allowed
time.  This is a variation on what you are doing in alternative #2,
except here you have only one signal with the really tight timing.

Another consideration is to either not use single ended I/O on the same
IO Bank as the clock.  Single ended I/Os on the same bank seem to add a
considerable amount of jitter to the internal clock because of the I/O
rail fluctuations, especially for outputs.

hamish@cloud.net.au wrote:

> In a design I'm working on at the moment, I have new data on every
> rising edge of a 175 MHz clock and I need to transfer it to
> be synchronous to a 350 MHz clock. No uncertainty in the
> 350 MHz data is acceptable.
>
> To generate the clocks, I have an external 350 MHz source,
> and I'm using the CLK0 and CLKDV (divided by 2) outputs on
> a DCM. I'm using a Xilinx 2V6000-5.
>
> I have global buffers for each clock, but I expect there
> will be some skew between the clocks, since the 350 MHz
> clock is lightly loaded (200-300 FFs), compared to the
> 175 MHz clock (2500 FFs). So I might violate the hold
> time on the 350 MHz FFs if I'm not careful.
>
> Some things I have considered:
>
> 1. Sample the 175 MHz data with the 350 MHz clock directly. Could
>    violate the hold time if there is sufficient skew between the
>    clocks and the logic/net delays are particularly small. Also,
>    I have 68 bits of data, so this isn't too good.
>
> 2. Sample the 175 MHz data with the next falling edge of the
>    350 MHz clock. A half-period of the 350 MHz clock is only
>    1.429 ns. Allowing for jitter, the FF to FF delay needs
>    to be about 1.3 ns, on all 68 data paths. Plus another
>    68 paths to get it back to the rising edge, possibly.
>
> 3. Generate an enable signal at 175 MHz and sample it using
>    the falling edge of the 350 MHz. Same problem as #2,
>    but with only 1-2 bits. I did try this, with hand placement
>    of the FFs, and got the delay down to 1.41 ns, which is
>    impressive (effectively over 700 MHz performance), but
>    probably not enough. Using the enable signal, the data
>    bits have a full 350 MHz period of setup and hold (less skew).
>
> 4. Just do it (like #1), but add some deliberate delays in the
>    data path to try to guarantee that the delays are larger
>    than the clock skew. Deliberate delays could include hand
>    placement to create long net delays, or instantiating
>    LUTs to act as buffers. This could be limited to a single
>    enable bit, with the data bits transferred safely on
>    the next 350 MHz edge.
>
> #3 is preferred, but not quite fast enough. #4 seems the
> next best option, but it makes me a bit uncomfortable.
>
> Can anyone add any other suggestions? Or try to convince
> me that #4 is acceptable, or otherwise?
>
> I saw a new Xilinx app note, XAPP265, which described a design
> for doing an 8:1 SERDES. That design would have a similar
> requirement to mine. It uses an 1/4 frequency clock instead
> though, which seems to simplify the problem a bit.
>
> thanks,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35979
Subject: Re: SpartanXL Device Utilization Summary
From: "Dave Brown" <dbrown@novatel.ca>
Date: Thu, 25 Oct 2001 09:19:32 -0600
Links: << >>  << T >>  << A >>
Thanks for the reply. I guess the deceptively simple sentence "design with
the CLB architecture in mind" is the crux. What exactly that entails
probably requires years of experience and a lot of knowledge. Any advice you
can give a rookie to get me started?
Thanks,
Dave

"Patrick Hibbs" <phibbs@ti.com> wrote in message
news:3BD81348.5060900@ti.com...
> The reason the CLB usage is so high is due to the fact that CLBs are
> partially
> used.  For example, the report states that you've used 68/200 flops --
> what you
> don't know is how the flops are packed into the CLBs.  Each CLB contains
> two flops, 3 look-up-tables (LUTs), & two groups of muxes.  You might have
> 1 flop per CLB.  If you design with the CLB architecture in mind then
> you can
> map to both of the flops in each CLB.  The same goes for the LUTs in
> your report.
>
> Pat
>
>
> Dave Brown wrote:
>
> >Hi all,
> >    Thanks for all the great help so far, this is a great newsgroup! I'm
> >looking at my Device Utilization Summary in Foundation ISE 4.1, for a
> >Spartan 05XL, and I'm not sure why the overall CLB utilization is so high
> >when my other numbers are low, is there some tool setting I'm missing, if
> >not, what is eating up all my CLBs? Here's the exerpt from the summary:
> >
> >Device utilization summary:
> >
> >   Number of External IOBs            52 out of 80     67%
> >      Flops:                           0
> >      Latches:                         0
> >
> >   Number of CLBs                     87 out of 100    87%
> >      Total Latches:                   0 out of 200     0%
> >      Total CLB Flops:                68 out of 200    34%
> >      4 input LUTs:                  137 out of 200    68%
> >      3 input LUTs:                   27 out of 100    27%
> >
> >   Number of BUFGLSs                   5 out of 8      62%
> >
> >Thanks,
> >Dave
> >
> >
>



Article: 35980
Subject: 2/3 trellis code in vhdl
From: srinas@my-deja.com (srinas)
Date: 25 Oct 2001 08:21:56 -0700
Links: << >>  << T >>  << A >>
Dear All,
 I want to implement a 2/3 trellis coder. Could someone refer some
vhdl codes. It must be an easy task. I also wonder how puncturing of a
1/2 convolutional code is implemented in vhdl, to obtain 3/4, 7/8 rate
codes.
Thanks
Srinas

Article: 35981
Subject: Re: What's the JBits ?
From: klonsky@hotmail.com (Noel Klonsky)
Date: 25 Oct 2001 08:53:44 -0700
Links: << >>  << T >>  << A >>
"????? <rokn92@lycos.co.kr> wrote in message news:<9r7tu0$i42$1@green.kreonet.re.kr>...
> Hello everyone!
> I'm graduated student at university.
> I want know about JBits.
> from fundamental to applications
> please, answer to me.
> thank you.

Have a look at http://www.geocities.com/SiliconValley/Pines/6639/fpga/jbits.html
 for JBits resources

JBits is a tool set of Java APIs and classes so you can handle FPGA bit streams.

Article: 35982
Subject: Re: How to make an implementable big counter?
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Thu, 25 Oct 2001 12:15:59 -0400
Links: << >>  << T >>  << A >>
Got one for you that works nicely in an FPGA (virtex2).  It is brute force
but it works OK.  Note that the counter is strictly quasi-asynchrounous.
You could code the last few bits as a synchnous counter for a little
better behavior.  I am using this with a 100MHz counter as an input.  It
gives a reset for the DCM at roughly 0.6 seconds if I recall correctly.

main file is

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

entity rst_generator is
    Port ( clock : in std_logic;
           done : in std_logic;
           rst_out : out std_logic
--     stop : inout std_logic
   );
     end rst_generator;

architecture Behavioral of rst_generator is

component dibitcounter
  port (
      clock  : in std_logic;
        enable   : in std_logic;
        reset    : in std_logic;
    dibit_out: inout std_logic_vector(1 downto 0)
 );
end component;

component dibitcounter2
  port (
      clock  : in std_logic;
        reset    : in std_logic;
    dibit_out: inout std_logic_vector(1 downto 0)
 );
end component;


signal dibit_out: std_logic_vector(1 downto 0);
signal stop, not_stop: std_logic;
signal data_out: std_logic_vector(27 downto 0);
signal not_done: std_logic;
signal temp_clock: std_logic;
function int2vec(int1,NBits: integer)
        return std_logic_vector is
variable N1: integer;
variable retval: std_logic_vector(NBits-1 downto 0);
begin
        N1:=int1;
        for i in retval'Reverse_Range loop
                if (N1 mod 2)=1 then
                        retval(i):='1';
                else
                        retval(i):='0';
                end if;
                N1:=N1/2;
        end loop;
        return retval;
end int2vec;

begin

not_done <= not(done);

u1:dibitcounter
port map
(
clock => clock,
enable => not_stop,
reset => not_done,
dibit_out => data_out(1 downto 0)
);

u2:dibitcounter2
port map
(
clock=>data_out(1),
reset=>not_done,
dibit_out=>data_out(3 downto 2)
);

u3:dibitcounter2
port map
(
clock=>data_out(3),
reset=>not_done,
dibit_out=>data_out(5 downto 4)
);

u4:dibitcounter2
port map
(
clock=>data_out(5),
reset=>not_done,
dibit_out=>data_out(7 downto 6)
);

u5:dibitcounter2
port map
(
clock=>data_out(7),
reset=>not_done,
dibit_out=>data_out(9 downto 8)
);

u6:dibitcounter2
port map
(
clock=>data_out(9),
reset=>not_done,
dibit_out=>data_out(11 downto 10)
);

u7:dibitcounter2
port map
(
clock=>data_out(11),
reset=>not_done,
dibit_out=>data_out(13 downto 12)
);

u8:dibitcounter2
port map
(
clock=>data_out(13),
reset=>not_done,
dibit_out=>data_out(15 downto 14)
);

u9:dibitcounter2
port map
(
clock=>data_out(15),
reset=>not_done,
dibit_out=>data_out(17 downto 16)
);

u10:dibitcounter2
port map
(
clock=>data_out(17),
reset=>not_done,
dibit_out=>data_out(19 downto 18)
);

u11:dibitcounter2
port map
(
clock=>data_out(19),
reset=>not_done,
dibit_out=>data_out(21 downto 20));

u12:dibitcounter2
port map
(
clock=>data_out(21),
reset=>not_done,
dibit_out=>data_out(23 downto 22));

u13:dibitcounter2
port map
(
clock=>data_out(23),
reset=>not_done,
dibit_out=>data_out(25 downto 24));

u14:dibitcounter2
port map
(
clock=>data_out(25),
reset=>not_done,
dibit_out=>data_out(27 downto 26));

process (data_out, done)
begin
 if done = '0' then -- not done
  rst_out<='0';
  stop<='0';
  not_stop<='1';
  elsif done='1' and data_out(27 downto 23)="00000" then--done and running

  rst_out<='0';
  stop<='0';
  not_stop<='1';
 elsif done='1' and data_out(27 downto 23)="01000" then-- pulse high
  rst_out<='1';
  stop<='0';
  not_stop<='1';
 elsif done='1' and data_out(27 downto 23)="01001"  then--pulse low
  rst_out<='0';
  stop<='1';
  not_stop<='0';
 end if;
end process;

end Behavioral;

secondary file 1 is

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

entity dibitcounter is
    Port ( clock : in std_logic;
           enable : in std_logic;
           reset : in std_logic;
           dibit_out : inout std_logic_vector(1 downto 0));
end dibitcounter;

architecture Behavioral of dibitcounter is

begin
process(clock, enable, reset)
begin
if reset='1' then
dibit_out<="00";
elsif enable='1'then
 if clock'event and clock='0' then
    case dibit_out is
     when "00"=>
      dibit_out<="01";
   when "01"=>
    dibit_out<="10";
     when "10"=>
      dibit_out<="11";
   when "11"=>
    dibit_out<="00";
     when others=>
    null;
  end case;
 end if;
end if;
end process;

end Behavioral;

secondary file 2 is

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

entity dibitcounter2 is
    Port ( clock : in std_logic;
--           enable : in std_logic;
           reset : in std_logic;
           dibit_out : inout std_logic_vector(1 downto 0));
end dibitcounter2;

architecture Behavioral of dibitcounter2 is

begin
process(clock, reset)
begin
if reset='1' then
dibit_out<="00";
 elsif clock'event and clock='0' then
    case dibit_out is
     when "00"=>
      dibit_out<="01";
   when "01"=>
    dibit_out<="10";
     when "10"=>
      dibit_out<="11";
   when "11"=>
    dibit_out<="00";
     when others=>
    null;
  end case;
 end if;
end process;

end Behavioral;

Good Luck
Theron Hicks






Jerre wrote:

> Hello,
>
> In my design I need to make a synchronous counter that counts, let's
> say, till 1000000. (Actual aim for counter is to built in a delay).  I
> do this by the use of integer type signals and with each clock'event I
> add 1 till I reach the wanted 1000000.  When I try to implement this
> in an FPGA it consumes a very high amount of CLBs and it seems very
> disastrous for the maximum reachable clock freq.
>
> If I would use an unsigned type would it differ a lot?
>
> Other tips?
>
> Greetz from a newbie,
>
> Jerre.


Article: 35983
Subject: Re: S/PDIF interface for FPGA
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 25 Oct 2001 18:16:54 +0200
Links: << >>  << T >>  << A >>
Robert Staven schrieb:
> 
> This brings me to another question, anybody done a up/oversampler with
> sample rate convertion?(e.g. you don't need to 'lock' on the incoming

No.

> signal, just get rid of the jitter on it)
> (I haven't done the maths for it yet, but I'm shure it ain't going to be
> easy :)

Why that pessimistic? Lets do a rough calculation.

S/PDIF is max. 6Mbit/s (right?). So lets say we would like to work with
an oversampling ratio of 16 (which should be fine, even 4 would probably
work). So we need a 96 MHz clock, not too hard to get (just use 2 DLLs
in Spartan-II/Virtex, to quadruple a 25 Mhz Xtal clock, we should not
use 24 Mhz, because datasheet says minimum input freuquency for the DLL
is 25 MHz)
With a 100 MHz clock inside your FPGA it is possible to build a digital
PLL to

- recover the clock information from the datastream
- create a second (dejitterd) clock to read the data from a FIFO.

Since the oversampling factor is ~16, we will see a jitter of 1/16 on
the outside clock, or with some more advanced design using both clock
edges 1/32. Not too bad I think. And its a nice single chip solution.
And a nice design challenge too. ;-)

-- 
MFG
Falk



Article: 35984
Subject: Re: Verilog vs. VHDL
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 25 Oct 2001 18:19:01 +0200
Links: << >>  << T >>  << A >>
Andy Peters schrieb:
> 
> tgingold@pc204.ipricot.fr wrote:
> 
> > BTW, what's about:
> >   when '1' => a <= '1';
> > bad coding style...
> 
> Well, that's more than bad coding style -- it's pathological!

Right.
Who the hell needs such weired synthax possible with C/C++ ??
A nice, clean style like Pascal or VHDL is all we need.
And makes things easy to read.

-- 
MFG
Falk


Article: 35985
Subject: Re: CPLD with built-in oscillator?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Thu, 25 Oct 2001 18:21:08 +0100
Links: << >>  << T >>  << A >>


"Assaf Sarfati" <assaf_sarfati@yahoo.com> wrote in message
news:44b0ca4e.0110242218.79ed6771@posting.google.com...
> Hello,
>
> I want to design a very small board to control some LEDs, relays etc. It
will
> be controlled by a serial port (Rx-only).
>
> I don't want to use any processor (not even PIC); instead I'd like to
implement
> the control-logic with a CPLD.
>
> I would like to use a watch-crystal (32768 Hz) as the clock source; is
there
> any CPLD with built-in crystal oscillator? I don't want to add another
chip
> to the design just for clock-source.

You could use an inverter in the CPLD (with the input and output brought out
to pins) biased with a resistor in an oscillator circuit. There was a
discussion about this a few weeks ago.

Leon
--
Leon Heller, G1HSM leon_heller@hotmail.con
http://www.geocities.com/leon_heller
Low-cost Altera Flex design kit: http://www.leonheller.com




Article: 35986
Subject: Re: 2/3 trellis code in vhdl
From: Patrick Hibbs <phibbs@ti.com>
Date: Thu, 25 Oct 2001 12:31:59 -0500
Links: << >>  << T >>  << A >>
The easiest (and most widely used) trellis coder is rate 1/2 (the 
"mother" rate).  
You can easily tack a puncturer onto the output of the convolutional encoder
to get the desired coding rate.  Try doing searches for convolutional 
encoder
and viterbi encoder ... it'll be implemented as a simple shift register 
(probably)
with feedback taps & output taps.  

The puncturer can be implemented as such:
  rate    data_in  data_out
---------------------------
   1/2        X1
                Y1        X1Y1
    2/3       X1X2
                Y1Y2   X1Y1Y2
    etc.

In other words, the puncturer takes the convolutional encoder
parallel output (x & y) on the first clock and outputs x followed
by on the next two successive clocks (try a pipelined implementation).
Higher coding rates are trivial once you see the pattern (or just look in
a coding theory textbook).

Hope it helps,
Patrick Hibbs


srinas wrote:

>Dear All,
> I want to implement a 2/3 trellis coder. Could someone refer some
>vhdl codes. It must be an easy task. I also wonder how puncturing of a
>1/2 convolutional code is implemented in vhdl, to obtain 3/4, 7/8 rate
>codes.
>Thanks
>Srinas
>


Article: 35987
Subject: Cheap programming of XC2018?
From: Peter Heitzer <hep09515@rrzs42.uni-regensburg.de>
Date: 25 Oct 2001 17:32:33 GMT
Links: << >>  << T >>  << A >>
Hello folks,
I have a few Xilinx XC2018 chips (5V version) and wonder if there was
a cheap way of programming those chips.
I know that the XC2000 series is now obsolete an no newer software
supports it. But perhaps there is some old software for free download
in the net.

Thanks in advance,
Peter

-- 
Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
mail Peter.Heitzer@rz.uni-regensburg.de

Article: 35988
Subject: GAL compiler
From: "Gunther May" <g.may@tu-bs.de>
Date: Thu, 25 Oct 2001 19:38:09 +0200
Links: << >>  << T >>  << A >>
Hello,

could anybody say me where to find a simple free GAL (especially 16V8)
compiler for MS-DOS?

Thank you in forward,
Gunther May



Article: 35989
Subject: Re: S/PDIF interface for FPGA
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Thu, 25 Oct 2001 17:41:47 GMT
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> 
> Andy Peters <andy@exponentmedia.deletethis.com> writes:
> > Do yourself a favor, and don't directly use the Crystal
> > MCLK/LRCLK/BCLK/data outputs to drive a converter.  Use a FIFO in
> > between, and generate your clocks locally.  You'll cut the jitter down.
> 
> And potentially introduce slips, since your sample rate may not match
> the source.  :-(

No, you clock your incoming data into a FIFO, and you have a
local-generated clock on the read side that runs at the same frequency
as the recovered clock, but it's from an oscillator and not a PLL, so
the hope is that the jitter on the clock feeding your DAC (the only
place you really need to worry about jitter) should be lower.

-a

Article: 35990
Subject: Re: GAL compiler
From: Peter Heitzer <hep09515@rrzs42.uni-regensburg.de>
Date: 25 Oct 2001 17:45:04 GMT
Links: << >>  << T >>  << A >>
Gunther May <g.may@tu-bs.de> wrote:
> Hello,

> could anybody say me where to find a simple free GAL (especially 16V8)
> compiler for MS-DOS?

> Thank you in forward,
> Gunther May

try http://www.ee.bgu.ac.il/~elinst/palasm/ or do a google search for PALASM



-- 
Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
mail Peter.Heitzer@rz.uni-regensburg.de

Article: 35991
Subject: Re: LUT Glitches
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Thu, 25 Oct 2001 17:45:41 GMT
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> 
> Bob Perlman <bob@cambriandesign.com> writes:
> 
> >You can build glitch filters with tapped delay lines and majority
> >detection logic, but with an important caveat.  These filters will
> >eliminate pulses shorter than X ns and pass pulses longer than Y ns,
> >but X and Y aren't the same number.  In between X and Y, the circuit
> >can misbehave; there's a range of pulse durations that can produce
> >glitches at the output of the filter.
> 
> >If there were such a thing as a perfect glitch filter, we could build
> >a metastable-proof flip-flop by filtering out runt pulses.  Were it
> >that it were.
> 
> The original question asked about asynchronous logic, which doesn't
> have a metastability problem.  Asynchronous logic, also called self
> timed logic, runs as fast as gates can change.  Look up self-timed
> logic somewhere.

OK, so you've traded potential metastability in synchronous logic for
potential race conditions in asynchronous logic.

pick yr poison.

-a

Article: 35992
Subject: Re: SpartanXL: DOUT or GCK6?
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 25 Oct 2001 17:47:05 GMT
Links: << >>  << T >>  << A >>
If you want to use GCK6 as a clock input, you must tristate the external
clock driver during configuration. Otherwise you will have contention from
the time of power up, till configuration complete.

Philip

On Thu, 25 Oct 2001 15:25:54 +0300, Utku Ozcan <ozcan@netas.com.tr> wrote:
>
>Our application will be targetted to Xilinx SpartanXL XCS30XL-4-BG256C.
>In Spartan/SpartanXL datasheet v1.6, it says that GCK6 and DOUT is on
>B19 in a BG256 package.
>
>We have too many clocks and we want to use this B19 as clock input.
>
>But during the configuration, does it harm that we connect a clock to B19,
>if the device is master/slave serial? Shall we disable the clock to B19 during
>the configuration of this device?
>
>Utku
>

Philip Freidin
Fliptronics

Article: 35993
Subject: Re: SpartanXL Device Utilization Summary
From: Patrick Hibbs <phibbs@ti.com>
Date: Thu, 25 Oct 2001 12:52:45 -0500
Links: << >>  << T >>  << A >>

--------------060006070307000301040200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

You've got it now ... that simple sentence takes a while to get the hang of.

As far as advice:
    o  open up the xilinx datasheet for the 05xl & look at what makes up
        a clb.  if you have a simple single flop process in vhdl, 
synthesis will
        map that flop to one of the flops in a clb.  if you have two simple
        flops in vhdl, synthesis COULD map that to two clbs or just one clb.

    o  use constraints to guide your synthesis run.  if you optimize for 
speed,
        it's likely that you'll have a larger implementation.  just the 
opposite for
        area.  check out the delay of a flop to flop inside of one CLB & 
compare
        that to the delay of a flop of one clb to a flop of another clb 
+ routing.

    o  use constraints to guide your place & route run.  open up chipviewer
        & see how constraints affect the placement of logic.

    o  use the schematic viewer inside of your synthesis tool to see how 
your
        rtl was implemented.  this will give you clues on how to 
re-architect your
        rtl.

Patrick.

Dave Brown wrote:

>Thanks for the reply. I guess the deceptively simple sentence "design with
>the CLB architecture in mind" is the crux. What exactly that entails
>probably requires years of experience and a lot of knowledge. Any advice you
>can give a rookie to get me started?
>Thanks,
>Dave
>
>"Patrick Hibbs" <phibbs@ti.com> wrote in message
>news:3BD81348.5060900@ti.com...
>
>>The reason the CLB usage is so high is due to the fact that CLBs are
>>partially
>>used.  For example, the report states that you've used 68/200 flops --
>>what you
>>don't know is how the flops are packed into the CLBs.  Each CLB contains
>>two flops, 3 look-up-tables (LUTs), & two groups of muxes.  You might have
>>1 flop per CLB.  If you design with the CLB architecture in mind then
>>you can
>>map to both of the flops in each CLB.  The same goes for the LUTs in
>>your report.
>>
>>Pat
>>
>>
>>Dave Brown wrote:
>>
>>>Hi all,
>>>   Thanks for all the great help so far, this is a great newsgroup! I'm
>>>looking at my Device Utilization Summary in Foundation ISE 4.1, for a
>>>Spartan 05XL, and I'm not sure why the overall CLB utilization is so high
>>>when my other numbers are low, is there some tool setting I'm missing, if
>>>not, what is eating up all my CLBs? Here's the exerpt from the summary:
>>>
>>>Device utilization summary:
>>>
>>>  Number of External IOBs            52 out of 80     67%
>>>     Flops:                           0
>>>     Latches:                         0
>>>
>>>  Number of CLBs                     87 out of 100    87%
>>>     Total Latches:                   0 out of 200     0%
>>>     Total CLB Flops:                68 out of 200    34%
>>>     4 input LUTs:                  137 out of 200    68%
>>>     3 input LUTs:                   27 out of 100    27%
>>>
>>>  Number of BUFGLSs                   5 out of 8      62%
>>>
>>>Thanks,
>>>Dave
>>>
>>>
>
>


--------------060006070307000301040200
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
You've got it now ... that simple sentence takes a while to get the hang
of.<br>
<br>
As far as advice:<br>
&nbsp;&nbsp;&nbsp; o &nbsp;open up the xilinx datasheet for the 05xl &amp; look at what makes
up<br>
&nbsp; &nbsp; &nbsp; &nbsp; a clb. &nbsp;if you have a simple single flop process in vhdl, synthesis
will<br>
&nbsp; &nbsp; &nbsp; &nbsp; map that flop to one of the flops in a clb. &nbsp;if you have two simple<br>
&nbsp; &nbsp; &nbsp; &nbsp; flops in vhdl, synthesis COULD map that to two clbs or just one clb.<br>
<br>
&nbsp; &nbsp; o &nbsp;use constraints to guide your synthesis run. &nbsp;if you optimize for
speed,<br>
&nbsp; &nbsp; &nbsp; &nbsp; it's likely that you'll have a larger implementation. &nbsp;just the opposite
for<br>
&nbsp; &nbsp; &nbsp; &nbsp; area. &nbsp;check out the delay of a flop to flop inside of one CLB &amp;
compare<br>
&nbsp; &nbsp; &nbsp; &nbsp; that to the delay of a flop of one clb to a flop of another clb +
routing.<br>
<br>
&nbsp; &nbsp; o &nbsp;use constraints to guide your place &amp; route run. &nbsp;open up chipviewer<br>
&nbsp; &nbsp; &nbsp; &nbsp; &amp; see how constraints affect the placement of logic.<br>
<br>
&nbsp; &nbsp; o &nbsp;use the schematic viewer inside of your synthesis tool to see how
your<br>
&nbsp; &nbsp; &nbsp; &nbsp; rtl was implemented. &nbsp;this will give you clues on how to re-architect
your<br>
&nbsp; &nbsp; &nbsp; &nbsp; rtl.<br>
<br>
Patrick.<br>
<br>
Dave Brown wrote:<br>
<blockquote type="cite" cite="mid:9r9ah2$js3$1@pallas.novatel.ca">
  <pre wrap="">Thanks for the reply. I guess the deceptively simple sentence "design with<br>the CLB architecture in mind" is the crux. What exactly that entails<br>probably requires years of experience and a lot of knowledge. Any advice you<br>can give a rookie to get me started?<br>Thanks,<br>Dave<br><br>"Patrick Hibbs" <a class="moz-txt-link-rfc2396E" href="mailto:phibbs@ti.com">&lt;phibbs@ti.com&gt;</a> wrote in message<br><a class="moz-txt-link-freetext" href="news:3BD81348.5060900@ti.com">news:3BD81348.5060900@ti.com</a>...<br></pre>
  <blockquote type="cite">
    <pre wrap="">The reason the CLB usage is so high is due to the fact that CLBs are<br>partially<br>used.  For example, the report states that you've used 68/200 flops --<br>what you<br>don't know is how the flops are packed into the CLBs.  Each CLB contains<br>two flops, 3 look-up-tables (LUTs), &amp; two groups of muxes.  You might have<br>1 flop per CLB.  If you design with the CLB architecture in mind then<br>you can<br>map to both of the flops in each CLB.  The same goes for the LUTs in<br>your report.<br><br>Pat<br><br><br>Dave Brown wrote:<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">Hi all,<br>   Thanks for all the great help so far, this is a great newsgroup! I'm<br>looking at my Device Utilization Summary in Foundation ISE 4.1, for a<br>Spartan 05XL, and I'm not sure why the overall CLB utilization is so high<br>when my other numbers are low, is there some tool setting I'm missing, if<br>not, what is eating up all my CLBs? Here's the exerpt from the summary:<br><br>Device utilization summary:<br><br>  Number of External IOBs            52 out of 80     67%<br>     Flops:                           0<br>     Latches:                         0<br><br>  Number of CLBs                     87 out of 100    87%<br>     Total Latches:                   0 out of 200     0%<br>     Total CLB Flops:                68 out of 200    34%<br>     4 input LUTs:                  137 out of 200    68%<br>     3 input LUTs:                   27 out of 100    27%<br><br>  Number of BUFGLSs                   5 out of 8      62%<br><br>Thanks,<br>Dave<br
><br><br></pre>
      </blockquote>
      </blockquote>
      <pre wrap=""><!----><br><br></pre>
      </blockquote>
      <br>
      </body>
      </html>

--------------060006070307000301040200--


Article: 35994
Subject: Re: transferring data between related clocks
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 25 Oct 2001 11:19:17 -0700
Links: << >>  << T >>  << A >>
Here are some thoughts:

hamish@cloud.net.au wrote:

> In a design I'm working on at the moment, I have new data on every
> rising edge of a 175 MHz clock and I need to transfer it to
> be synchronous to a 350 MHz clock. No uncertainty in the
> 350 MHz data is acceptable.
>
> To generate the clocks, I have an external 350 MHz source,
> and I'm using the CLK0 and CLKDV (divided by 2) outputs on
> a DCM. I'm using a Xilinx 2V6000-5.
>
> I have global buffers for each clock, but I expect there
> will be some skew between the clocks, since the 350 MHz
> clock is lightly loaded (200-300 FFs), compared to the
> 175 MHz clock (2500 FFs). So I might violate the hold
> time on the 350 MHz FFs if I'm not careful.

I think the loading ( if it has any effect at all  ) would help you: It would
move the 175 MHz data a little later. When the source clock is late and the
receive clock is early, you avoid all hold time issues, but you lose
performance.  So, no hold-time issues here.

I would run everything off the 350 MHz clock and generate a 175 MHz clock enable
off that clock, and use it for the "175 MHz" portion.
Global clock distribution skew has always been good, but is very good in
Virtex2. Count on less than 200 ps, perhaps even less than 100 ps.

One obvious drawback to this suggestion of using 350 MHz clock for the many
slower places, is increased power consumption.

Peter Alfke

>
>


Article: 35995
Subject: Re: transferring data between related clocks
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 25 Oct 2001 11:41:05 -0700
Links: << >>  << T >>  << A >>
Continuing,

The max skew in a 2V6000 is 200 ps, but as Peter points out, smaller devices have
smaller skew in relation to their size.  A 2V1000 is ~ .4 times less skew (~85 ps)
One can guess at the dimension ratio by examining the X by Y size of the CLB's
(96x88 vs 40x32, or .41 times less skew).

Actual measurements confirms these values, but we tend to use the largest value in
the data sheet, rather than specify eveything per device.  The per device
information is reserved for the speeds files when appropriate.

In Virtex II we actually turn off parts of the clock tree that are unused, so there
is a major power savings if the 350 MHz clock tree is constrained to a local area
(perhaps using RLOC's).  If all CLB's and IOB's can be localized, the power savings
is quite real.  If everything must run at 350 MHz, you better invest in a serious
heatsinking solution!

Use of clock enable saves less power, as everything is switching right up, and
including logic, into the heart of the CLB.

Austin

Peter Alfke wrote:

> Here are some thoughts:
>
> hamish@cloud.net.au wrote:
>
> > In a design I'm working on at the moment, I have new data on every
> > rising edge of a 175 MHz clock and I need to transfer it to
> > be synchronous to a 350 MHz clock. No uncertainty in the
> > 350 MHz data is acceptable.
> >
> > To generate the clocks, I have an external 350 MHz source,
> > and I'm using the CLK0 and CLKDV (divided by 2) outputs on
> > a DCM. I'm using a Xilinx 2V6000-5.
> >
> > I have global buffers for each clock, but I expect there
> > will be some skew between the clocks, since the 350 MHz
> > clock is lightly loaded (200-300 FFs), compared to the
> > 175 MHz clock (2500 FFs). So I might violate the hold
> > time on the 350 MHz FFs if I'm not careful.
>
> I think the loading ( if it has any effect at all  ) would help you: It would
> move the 175 MHz data a little later. When the source clock is late and the
> receive clock is early, you avoid all hold time issues, but you lose
> performance.  So, no hold-time issues here.
>
> I would run everything off the 350 MHz clock and generate a 175 MHz clock enable
> off that clock, and use it for the "175 MHz" portion.
> Global clock distribution skew has always been good, but is very good in
> Virtex2. Count on less than 200 ps, perhaps even less than 100 ps.
>
> One obvious drawback to this suggestion of using 350 MHz clock for the many
> slower places, is increased power consumption.
>
> Peter Alfke
>
> >
> >


Article: 35996
Subject: Re: GAL compiler
From: Bertram Geiger <bgeiger@aon.at>
Date: Thu, 25 Oct 2001 22:01:27 +0200
Links: << >>  << T >>  << A >>

> could anybody say me where to find a simple free GAL (especially 16V8)
> compiler for MS-DOS?
> 
search for "easyAbel", might be its still somewhere around on the web or
ask on the university
Its simple and works fine up to 22v10

Greetings,  Bertram
-- 
Bertram Geiger,  bgeiger@aon.at
HTL Bulme Graz-Goesting - AUSTRIA

Article: 35997
Subject: Re: How to make an implementable big counter?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 25 Oct 2001 20:03:58 GMT
Links: << >>  << T >>  << A >>
At 100 MHz, why not use a synchronous counter and let the synthesizer take
care of the construction?  It should use the carry chain.  A 32 bit straight
synchronous counter should work at well over 100 MHz in virtexII.  For bigger
counts, you can pipeline the carries between counter segments, or connect the
carry outs from segments into a carry look ahead scheme.  If you need several
hundred MHz input, then it may make sense to use a prescaler with a ripple
carry, but not for a 100 MHz count.

Theron Hicks wrote:

> Got one for you that works nicely in an FPGA (virtex2).  It is brute force
> but it works OK.  Note that the counter is strictly quasi-asynchrounous.
> You could code the last few bits as a synchnous counter for a little
> better behavior.  I am using this with a 100MHz counter as an input.  It
> gives a reset for the DCM at roughly 0.6 seconds if I recall correctly.
>
> ma--

--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35998
Subject: Re: Cheap programming of XC2018?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 25 Oct 2001 20:21:04 GMT
Links: << >>  << T >>  << A >>
I know of no source for the old sw.  You might find someone with a used copy,
but you'll have to make sure you get the dongle, and a valid license file.
I'm pretty sure the license files from back then did not expire, but you
might check to make sure.  I'm not sure what use these parts would be now:
They are feature poor compared with new devices, consume considerably more
power, are orphaned from both tools ans support points of view, and will
likely not teach you much as far as using modern FPGAs go.  It may cost you
less to pick up an eval board with a current device on it, when you consider
the time and effort of finding and then getting tools to run for these old
parts.  It is also worth noting that the software for the 2000 series is DOS
based.  IIRC, the 2000 series was dropped from the tools about the same time
the windows (3.1) version of XACT came out.  XACT did not work very well
under win95.  You will probably have to resurrect an old operating system,
and perhaps even an old machine (I suspect the new machines may be too fast
to work the dongle properly, that was a problem with some faster machines
back then) jsut to get the software up an running.  Sounds like an awful lot
of effort for a very questionable return to me.

Peter Heitzer wrote:

> Hello folks,
> I have a few Xilinx XC2018 chips (5V version) and wonder if there was
> a cheap way of programming those chips.
> I know that the XC2000 series is now obsolete an no newer software
> supports it. But perhaps there is some old software for free download
> in the net.
>
> Thanks in advance,
> Peter
>
> --
> Dipl.-Inform. Peter Heitzer, phone +49 941 943 4850, fax +49 941 943 4857
> mail Peter.Heitzer@rz.uni-regensburg.de

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 35999
Subject: Re: JTAG question
From: Mike <none@null.net>
Date: Thu, 25 Oct 2001 14:00:34 -0700
Links: << >>  << T >>  << A >>
Dean,

Yes, if it's controlling the chain like this, then no contention will occur.  All you have to do now is write a JTAG controller <g>.

Mike



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
2017JanFebMarApr2017

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