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 40450

Article: 40450
Subject: Re: exceeding 2GB limits in xilinx
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Thu, 7 Mar 2002 15:27:24 -0000
Links: << >>  << T >>  << A >>
Allan Herriman wrote

> BTW, I see a significant speedup for large designs in Synplify if I
> use the syn_hier attribute, which stops optimisations across module
> boundaries.

How big a speedup?  I have wondered about this but never had an
opportunity to measure it on truly large designs.

Presumably the gain increases as the design size goes up.  When
syn_hier is asserted I would expect compilation time to be linear
with design size.  Without this attribute, is compilation time
quadratic with size, or worse?

If the company coding style include flops at the exit of all logic
blocks I would not expect syn_hier to have much effect, though this
style can be pretty hard to enforce for the control logic part of an
application.

Maybe Ken McElvain, or another Synplicity expert, can comment?







Article: 40451
Subject: Xilinx ISE 4.1
From: Salman Sheikh <sheikh@pop500.gsfc.nasa.gov>
Date: Thu, 7 Mar 2002 10:28:55 -0500
Links: << >>  << T >>  << A >>
Hello,

I have a question for anyone out there familiar with Xilinx FPGA design.  I am using Xilinx ISE and during the design rule check of the place & route (after writing out the verilog netlists and sdf files for post-route simulation), I get messages like the following:

WARNING: DesignRules: 372 - Netcheck: Gated clock: Clock net fsync1/CPUINTERFACE_0/N_115_inferred_clock is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.

I have code like the following to generate my write strobes.
--------------
-- cut out library for brevity

entity CPUWRTGEN is
  port
    (RST	:in	std_logic;
     CPU_ADDR   :in     std_logic_vector (10 downto 0);
     WRT        :out    std_logic_vector (30 downto 0);
end CPUWRTGEN;

architecture BEHAVIOR of CPUWRTGEN is
signal CPU_ADDR_INT :  integer range 0 to 63;

begin

CPU_ADDR_INT <= conv_integer(CPU_ADDR(5 downto 0));

  process(CPU_ADDR, CPU_ADDR_INT)
    begin
     for I in 39 downto 9 loop
      if  CPU_ADDR (10 downto 6) = "01000" and CPU_ADDR_INT = I then
       WRT(I-9) <= '0';
      else
       WRT(I-9) <= '1';
      end if;
     end loop;
   end if;
  end process;

end BEHAVIOR;
-----------------

I suspect this is the reason for the inferred clock since there is not clk controlling the write strobes.
How do I remedy the controlling the loading of the date into the flip-flop via the CE pin?
-- 
 Salman Sheikh					
 NASA/GSFC Code 564					
 Greenbelt, MD 20771				
 301-286-3763 301-286-0220 (fax)				

Article: 40452
Subject: Re: FPGA or DSP in a power supply?
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 07 Mar 2002 15:34:52 GMT
Links: << >>  << T >>  << A >>
Ray gave an excellent detailed description.
Here is the more simplistic one:
Using a phase acumulator and a 50 MHz clock, you will achieve an average frequency or
average on-time with extremely fine resolution, as fine as you want, determined only by
the length of the accumulator. But not every on-time will be the same. You have excellent
control over the average on-time, but since each on-time will be an integer multiple of
20 ns ( 50 MHz! ), the individual on-times will "dance around" to make your desired
high-precision average.
The output analog filter will average this all out.

Hope this helps.
Peter Alfke

"F. Modderkolk" wrote:

> Maybe I don't quit understand the working of the fpga, so explain me
> whem I'm wrong.
> I want to give you give you an example why my resolution needs to be
> so high.
> When I'm switching the fets with 300 kHz and I can switch my output
> with 300MHz, the following is  possible. Let's say the duty cycle of
> my pulse is 40% ( it's always less than 50%). When I switch with 300
> kHz, one period is 3,33333 us. the next frequncy I can create at my
> output = 1/300k + 1/300M = 3,33666 us. That is a frequency of
> 299,700kHz. That is a difference of 300Hz. Such a difference means at
> the output of the power supply a change of current of 0.2A. This is
> because the working frequency is very small. I hope I made clear why I
> need the high frequency.
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3C862BFA.6BD14523@andraka.com>...
> > See my post to your previous post.  Knowing now what you are doing, I am
> > sure you can get away with a much slower clock.  Jitter is not likely to
> > be much of a problem in this application.  If, for example, you use a 10
> > MHz clock and a 32 bit accumulator you get a frequency resolution of 0.002
> > Hz with jitter no greater than 100ns (1 cycle of the master clock).  Your
> > master clock determines the amount of jitter and the maximum output
> > frequency (Fclk/2).  Resolution is determined just by the number of bits.
> >


Article: 40453
Subject: Re: Announcement: Freely available AES/Rijndael Core in Virtex FPGAs
From: Michael Amling <spambad@nospam.com>
Date: Thu, 07 Mar 2002 09:41:33 -0600
Links: << >>  << T >>  << A >>
Nicholas Weaver wrote:
> 
> (Note followup)
> 
> I'm proud to announce the availability of a free, high performance
> (1.3 Gbps in a Spartan II-100), and compact (<800 CLB slices),
> Rijndael/AES encryption core optimized for Virtex family FPGAs from
> Xilinx.  It is fully key agile, uses 128b keys, and has a 5 stage
> pipeline.  It is currently only available as a Foundation 4.1
> schematic.
> 
> It is available from http://www.cs.berkeley.edu/~nweaver/rijndael/

  Are there other implementations of Rijndael in hardware? (If so, I'll
add them to www.rijndael.com/implementations.html.)

--Mike Amling


Article: 40454
Subject: Re: Announcement: Freely available AES/Rijndael Core in Virtex FPGAs
From: "Flip Flippy" <flip@safebunch.com>
Date: Thu, 7 Mar 2002 15:57:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
"Michael Amling" <spambad@nospam.com> wrote in message
news:3C878A3B.5E5C8DC1@nospam.com...

>   Are there other implementations of Rijndael in hardware? (If so, I'll
> add them to www.rijndael.com/implementations.html.)
> 
> --Mike Amling

Hi Mike,

there are many in both FPGA and in ASICS.

http://www.heliontech.com/downloads/aes_asic_helioncore.pdf

http://www.realtime-info.be/vpr/layout/display/pr.asp?PRID=2298
 
I am amazed at some of the speeds, the support for three key sizes
and support for all modes of operation.

If I get time, I'll post more links.

HTH, Flip


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 40455
Subject: Re: max frequency of obuf_lvdci_dv2_18
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 07 Mar 2002 08:00:25 -0800
Links: << >>  << T >>  << A >>
Run an IBIS simulation.

Austin

Nahum Barnea wrote:

> Hi.
> I would like to use virtex 2 OBUF_LVDCI_DV2_18 output pad
> in order to drive a clock signal of 250 MHz.
>
> Is it possible ?
> Will I get good clock shape on the board ?
> How can I verify that I will get good clock shape on the board ?
>
> ThankX ,
> Nahum.


Article: 40456
Subject: Re: Virtex-II : Temperature Sensing Diodes
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 07 Mar 2002 08:02:25 -0800
Links: << >>  << T >>  << A >>
Cindy,

The same as any other pin in the Abs Max section of the data sheet.

Austin

Cindy wrote:

> Is there is absolute maximum voltage specified for the DXP and DXN pins?
>
> Thanks!


Article: 40457
Subject: Re: Rising and falling edge of a clk
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Mar 2002 16:09:34 GMT
Links: << >>  << T >>  << A >>
*Sigh*

I've really got to put together the FAQ on this one...

In your architecture declarations:

 component RAMB4_S1_S1
 --synthesis translate_off
 generic(
  TimingChecksOn : BOOLEAN := FALSE);
 --synthesis translate_on
 port(
  DIA : in std_logic_vector(0 downto 0);
  DIB : in std_logic_vector(0 downto 0);
  ENA : in std_ulogic;
  ENB : in std_ulogic;
  WEA : in std_ulogic;
  WEB : in std_ulogic;
  RSTA : in std_ulogic;
  RSTB : in std_ulogic;
  CLKA : in std_ulogic;
  CLKB : in std_ulogic;
  ADDRA : in std_logic_vector(11 downto 0);
  ADDRB : in std_logic_vector(11 downto 0);
  DOA : out std_logic_vector(0 downto 0);
  DOB : out std_logic_vector(0 downto 0));
 end component;
 attribute syn_black_box of RAMB4_S1_S1:component is TRUE;

Then in the architecture body:

 MEM:  RAMB4_S1_S1 port map(
    DIA => wdata(0 to 0),
    DIB => "0",
    ENA => '1',
  ENB => '1',
  WEA => '1',
  WEB => '0',
  RSTA => '0',
  RSTB => '0',
  CLKA => clk,
  CLKB => clk,
  ADDRA =>waddr,
  ADDRB => raddr,
  DOA   => open,
  DOB => rdata(0 to 0));

Your signals may vary.


Theron Hicks wrote:

> Ray,
>     How does one instantiate the BRAM directly?  I am using VHDL if that has any
> impact on the question.  Can you give me a code snippet as an example?
>
> Thanks,
> Theron Hicks
>
> Ray Andraka wrote:
>
> > Personally, I prefer to instantiate the BRAM primitives directly rather than
> > using the coregen.  That way you lose the extra layer of abstraction, that in
> > this case does little more than make it harder to simulate.  If you do use the
> > BRAM generator and select register inputs under the design options, then putting
> > a small combinatorial mux in front of it should put the mux with the registers
> > (at least the last layer of the mux if it is more than 2 inputs).  If you are
> > instantiating the BRAMs, then your muxes should be registered.  One note of
> > caution: if you are trying to get the most speed, keep in mind that you want the
> > registers as close as possible to the BRAM.  Putting muxes with those registers
> > is going to tend to congest the routing there, which may slow your critical BRAM
> > connections.  For that matter, it also helps to keep the width of the BRAM
> > relatively small so you don't have a ton of data lines going in and out
> > (especially for dual ports with both ports used in both directions).
> >
> > "H.L" wrote:
> >
> > > Hello Ray,
> > > thanks a lot your post clarified things.
> > > Xilinx Core Generator cant put additional register on the EN signal, so the
> > > only thing is to instantiate a D flip-flop and put it in the right place?
> > >
> > > Regarding my project I have to arbitrate the access in 3 BRAMs (registered
> > > for the reason described above) so I think I must use a MUX_BUS from the
> > > CORE GENERATOR (one MUX_BUS for each BRAM).  I will use 3 MUX_BUS with 3
> > > input 41-bit buses (32 for the data, 7 for the address, 2 bits for EN,WE).
> > > If I use non-registered MUXs I think is not good for the following reasons:
> > > 1) The timing analysis will not include them in the period calculation so I
> > > will not be able to see if my FPGA meets the timing constraints
> > > 2) Combinatorial logic in the BRAM paths. Here is my second question, as I
> > > said before I am going to use registered BRAMs do you think that these
> > > registers are capable to cope with the inserted MUXs' combinatorial logic? I
> > > don't know if these MUXs I'll use can be described as "large" or "small"
> > > combinatorial logic.
> > >
> > > So the right thing to do is to use registered MUXs (LUT based only as Xilinx
> > > says)?
> > >
> > > Best Regards,
> > > Harris
> > >
> > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > news:3C824FD0.71540235@andraka.com...
> > > >
> > > >
> > > > "H.L" wrote:
> > > >
> > > > > Hi Ray,
> > > > > I have seen these tips written by you many times in this group. I have
> > > them
> > > > > always as a guide but I want to see if I understand them right. Please
> > > > > correct me where I am wrong:
> > > > >
> > > > > 1) The need for additional registers in DATA_IN and ADDR signals.
> > > > > In BRAMs the EN and WE signals  have long set-up times thats why we need
> > > to
> > > > > register the data_in and addr of the BRAM, in this way the addr and
> > > data_in
> > > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock period
> > > > > earlier (at 155MHz  clock speed that means about 6 ns) the setup-time
> > > for
> > > > > these signals is not violated resulting BRAM to be in the operation mode
> > > we
> > > > > wish (read or write) the moment addr and data_in arrive.
> > > >
> > > > If you look at the data sheet, there are fairly long set-up times on all
> > > the
> > > > BRAM inputs.  Routing to the BRAMs also adds to the delay, as does any
> > > > combinatorial logic on these inputs.  The idea of putting registers on the
> > > > inputs (which includes the EN and WE inputs) is to minimize the amount of
> > > delay
> > > > added externally to these signals.  Your understanding is a bit incorrect,
> > > as
> > > > what you are suggesting is delaying signals to allow a long combinatorial
> > > > delay.  That is dangerous, because there is no guarantee on the minimum
> > > delay.
> > > > Instead, what I am suggesting is to remove as much of the delay as
> > > possible
> > > > between the registers driving the BRAM inputs and the BRAM inputs, which
> > > meahs
> > > > avoiding combinatorial logic on these paths, minimizing the fanout of
> > > these
> > > > signals, and physically locating the registers close to the BRAMs.
> > > >
> > > > >
> > > > > 2) The need for floorplanning
> > > > > Xilinx software tool maybe has put the additional registers far from the
> > > > > BRAMs, if this is the case we must manual place them near the BRAM to
> > > > > decrease the propagation delay of the signals.
> > > >
> > > > That is correct.  Routing in FPGAs is not just wire, it also consists of
> > > > switches which add to the propagation delay of signals on the connections
> > > > between logic.  Manually placing the registers near the BRAM helps to
> > > minimize
> > > > the added delay.
> > > >
> > > > >
> > > > > 3) Tying the WE,EN inputs and contol access through the address when
> > > working
> > > > > at high speeds.
> > > > > Do you mean to keep WE,EN high all the time and when we wish not to use
> > > the
> > > > > BRAMs to write dummy data in some (or just one) specified addresses (or
> > > > > address) reserved for this reason?
> > > >
> > > > That is correct.  The set up times for EN and WE are nearly twice the
> > > set-up
> > > > times for address and data, so if we can eliminate these from the equation
> > > we
> > > > can run at a higher clock rate.  They can be eliminated by always writing,
> > > but
> > > > directing the writes of invalid data to locations where it does not affect
> > > the
> > > > operation of the design.  In the case of FIFOs, you can just park the
> > > write
> > > > address until you have a valid write, since you are presumably not reading
> > > that
> > > > data until it is valid.
> > > >
> > > > >
> > > > >
> > > > > Also I have another one question about BRAMs, Xilinx says that BRAMs'
> > > DATA
> > > > > OUT are already registered. In Xilinx Floorplanner I believe this
> > > register
> > > > > is "inside" the BLKRAM box so no manual floorplanning for the output is
> > > > > needed. You need to manual floorplan (in the same way you do for the
> > > inputs)
> > > > > only if you choose to add an additional output register, correct?
> > > >
> > > > That is correct, the BRAM acts as though it is registered, although I
> > > believe
> > > > the actual implementation has the register on the address, not on the
> > > memroy
> > > > outputs.  In any event, the clock to out time is long compared to that of
> > > the
> > > > CLB flip-flops.  The system clock rate can be increased by putting an
> > > additional
> > > > register on the BRAM data outputs and placing that register physically
> > > close to
> > > > the BRAM (that register should have no combinatorial logic in front of
> > > it).
> > > >
> > > > >
> > > > >
> > > > > I really appreciate your help.
> > > > >
> > > > > Best Regards,
> > > > > Harris
> > > > >
> > > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > > news:3C7FD73D.F6A3109A@andraka.com...
> > > > > > VirtexE BRAMs can be written at 155MHz in any speed grade.  To do so,
> > > you
> > > > > will
> > > > > > likely have to put registers near to and with no logic between them
> > > and
> > > > > the
> > > > > > BRAMs.  Watch the loading too, routing to more than 1 BRAM for each
> > > > > register may
> > > > > > cause you some heartburn.  At higher speeds, you probably should also
> > > > > consider
> > > > > > tying the WE, and ENA inputs active and controlling your access
> > > through
> > > > > the
> > > > > > address registers instead.  You'll also need to floorplan the
> > > registers to
> > > > > make
> > > > > > sure they are located physically close to the BRAMs.
> > > > > >
> > > > > > "H.L" wrote:
> > > > > >
> > > > > > > Hi Peter, thanks for your reply
> > > > > > > I was confident of this method's effectiveness but now I am worried
> > > :))
> > > > > . I
> > > > > > > have already done a timing analysis in the paper and also the
> > > simulation
> > > > > > > waveforms seem promising.
> > > > > > > I didnt understand what do you mean when telling me that one of my
> > > words
> > > > > > > arrives early and the other one late. The transmitter sends to my
> > > FPGA
> > > > > an
> > > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit
> > > > > indicating
> > > > > > > the transmission time period) and of course the 16-bit words that I
> > > have
> > > > > to
> > > > > > > store. Every clock period (~6 ns) I have available in my ports one
> > > > > 16-bit
> > > > > > > word, I register two sequential words from the in port to a 32-bit
> > > > > register
> > > > > > > (31->16 the first incoming word, 15->0 the second one). Then , in
> > > > > another
> > > > > > > 32-bit register I register (2 nd time) the 32-bit word I just "made"
> > > > > which
> > > > > > > are the BRAM data_in. All the above operations are in a process that
> > > has
> > > > > in
> > > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz
> > > using
> > > > > the
> > > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are
> > > assigned
> > > > > in
> > > > > > > the falling edge of the 77MHz clock so as to be before the rising
> > > edge
> > > > > (of
> > > > > > > the same clock) where the BRAM samples them. The write operations
> > > are in
> > > > > > > another process with the slow clock in its sensitivity list.
> > > > > > > The timing waveforms of the simulation are the same with the timing
> > > > > analysis
> > > > > > > in paper but does this is a valid hardware design technique?
> > > > > > > Thanks for your time and help!
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Harris
> > > > > > >
> > > > > > > p.s: thats a small part of my design. I use DLL because other parts
> > > need
> > > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155
> > > MHz
> > > > > and I
> > > > > > > got many timing errors (floorplanning managed to reduce them but
> > > still
> > > > > lot
> > > > > > > of work to be done)
> > > > > > >
> > > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > > > > > news:3C7E621F.1E77A244@xilinx.com...
> > > > > > > > I suggest you grab pencil and paper and do a clock-by-clock timing
> > > > > > > analysis. You
> > > > > > > > will find that your clock-speed reduction buys you nothing, unless
> > > you
> > > > > > > also
> > > > > > > > double-buffer the data.
> > > > > > > > One of your words arrives nice and early, the other one late.
> > > However
> > > > > you
> > > > > > > clock
> > > > > > > > the BRAM, one of the two words has the same old short set-up
> > > time...
> > > > > > > > Double-buffering would help. But Ray has mentioned some neat
> > > tricks to
> > > > > > > avoid the
> > > > > > > > long set-up time of the control inputs.
> > > > > > > >
> > > > > > > > I will get back with more constructive notes. "Gotta run"
> > > > > > > >
> > > > > > > > Peter Alfke
> > > > > > > > ===================
> > > > > > > > "H.L" wrote:
> > > > > > > >
> > > > > > > > > Hello all,
> > > > > > > > >
> > > > > > > > > I have a module that accepts 16 bit words at 155MHz and I want
> > > to
> > > > > store
> > > > > > > then
> > > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA)
> > > to
> > > > > > > divide by
> > > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high to
> > > > > write in
> > > > > > > the
> > > > > > > > > BRAM. So far I think 2 processes are enough to do my job, one
> > > > > operating
> > > > > > > @
> > > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit
> > > register
> > > > > and
> > > > > > > the
> > > > > > > > > another one @ 75MHz to write the content of the 32-bit register
> > > in
> > > > > the
> > > > > > > BRAM.
> > > > > > > > > I am thinking to assign the BRAM's signals
> > > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > > > > > the falling edge of the 75MHz clock, the main reason for this is
> > > the
> > > > > > > setup
> > > > > > > > > time of the BRAMs signals (in this way the address,data are 6 ns
> > > > > before
> > > > > > > next
> > > > > > > > > rising edge of the clock where BRAM samples its inputs). My
> > > question
> > > > > now
> > > > > > > :)
> > > > > > > > > , if one process uses the falling edge of one clock does this
> > > causes
> > > > > > > > > problems to other processes in the design , e.g to processes
> > > that
> > > > > use a
> > > > > > > > > different clock or to  processes using the rising edge of the
> > > same
> > > > > > > clock?
> > > > > > > > >
> > > > > > > > > Best Regards,
> > > > > > > > > Harris.
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > --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
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > --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: 40458
Subject: Ports disappear after generating post place and route simulation model
From: kenny@trangosys.com (Kenny)
Date: 7 Mar 2002 08:30:12 -0800
Links: << >>  << T >>  << A >>
Hi All,

I am using ISE 4.1i and ModelSim PE for Verilog.
I try to simulate one sub-module of my design. I use "Generating Post
Place and Route Simulation Model" to generate Verilog file for
ModelSim PE.
I always lost some ports in that file. How do I keep those ports even
I did not use them in that sub-module ?

Any idea ?

Kenny

Article: 40459
Subject: Re: Is there a ver 7.1 of Sunplify?
From: Bob Efram <efram@divide.net>
Date: Thu, 07 Mar 2002 09:51:12 -0700
Links: << >>  << T >>  << A >>
Call your local Synplicity FAE. Synplify 7.1 is available in late Beta.

Leon Qin wrote:
> 
> Altera says that QuartusII 2.0 working with Synplify 7.1 ,but I can
> only found ver 7.03 on SYNPLICITY website for download.

Article: 40460
Subject: Re: DDR-Interface
From: "Manfred Kraus" <newsreply@cesys.com>
Date: Thu, 7 Mar 2002 17:52:57 +0100
Links: << >>  << T >>  << A >>
>
> Look at the app notes:
>
>  http://www.support.xilinx.com/xapp/xapp253.pdf
>

This appnote is not available any more.
Maybe somebody has it and is willing to send it to me ?

I also have trouble using VIRTEX-2 with DDR-SDRAM.

Thanks
Manfred Kraus

newsreply@cesys.com





Article: 40461
Subject: Need XC2V4000/6000-4FF1152CES
From: jhallen@world.std.com (Joseph H Allen)
Date: Thu, 7 Mar 2002 17:07:03 GMT
Links: << >>  << T >>  << A >>
I have 60 XC2V3000-4FF1152CES (still in original vacuum-pack), but I need
XC2V4000-FF1152CESs and XC2V6000-4FF1152CESs.  If you have excess inventory
of the larger parts and want to sell them or trade them for the the smaller
ones, please contact me.  We are in need of the larger parts ASAP and can't
deal with the long lead times.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 40462
Subject: Re: Rising and falling edge of a clk
From: "H.L" <alphaboran@yahoo.com>
Date: Thu, 7 Mar 2002 19:07:54 +0200
Links: << >>  << T >>  << A >>
Thanks a lot Ray!!!
I will try to instantiate the BRAM primitives according to your following
post.

Best Regards
Harris

"Ray Andraka" <ray@andraka.com> wrote in message
news:3C86D04D.991FE2B8@andraka.com...
> Personally, I prefer to instantiate the BRAM primitives directly rather
than
> using the coregen.  That way you lose the extra layer of abstraction, that
in
> this case does little more than make it harder to simulate.  If you do use
the
> BRAM generator and select register inputs under the design options, then
putting
> a small combinatorial mux in front of it should put the mux with the
registers
> (at least the last layer of the mux if it is more than 2 inputs).  If you
are
> instantiating the BRAMs, then your muxes should be registered.  One note
of
> caution: if you are trying to get the most speed, keep in mind that you
want the
> registers as close as possible to the BRAM.  Putting muxes with those
registers
> is going to tend to congest the routing there, which may slow your
critical BRAM
> connections.  For that matter, it also helps to keep the width of the BRAM
> relatively small so you don't have a ton of data lines going in and out
> (especially for dual ports with both ports used in both directions).
>
> "H.L" wrote:
>
> > Hello Ray,
> > thanks a lot your post clarified things.
> > Xilinx Core Generator cant put additional register on the EN signal, so
the
> > only thing is to instantiate a D flip-flop and put it in the right
place?
> >
> > Regarding my project I have to arbitrate the access in 3 BRAMs
(registered
> > for the reason described above) so I think I must use a MUX_BUS from the
> > CORE GENERATOR (one MUX_BUS for each BRAM).  I will use 3 MUX_BUS with 3
> > input 41-bit buses (32 for the data, 7 for the address, 2 bits for
EN,WE).
> > If I use non-registered MUXs I think is not good for the following
reasons:
> > 1) The timing analysis will not include them in the period calculation
so I
> > will not be able to see if my FPGA meets the timing constraints
> > 2) Combinatorial logic in the BRAM paths. Here is my second question, as
I
> > said before I am going to use registered BRAMs do you think that these
> > registers are capable to cope with the inserted MUXs' combinatorial
logic? I
> > don't know if these MUXs I'll use can be described as "large" or "small"
> > combinatorial logic.
> >
> > So the right thing to do is to use registered MUXs (LUT based only as
Xilinx
> > says)?
> >
> > Best Regards,
> > Harris
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3C824FD0.71540235@andraka.com...
> > >
> > >
> > > "H.L" wrote:
> > >
> > > > Hi Ray,
> > > > I have seen these tips written by you many times in this group. I
have
> > them
> > > > always as a guide but I want to see if I understand them right.
Please
> > > > correct me where I am wrong:
> > > >
> > > > 1) The need for additional registers in DATA_IN and ADDR signals.
> > > > In BRAMs the EN and WE signals  have long set-up times thats why we
need
> > to
> > > > register the data_in and addr of the BRAM, in this way the addr and
> > data_in
> > > > signals have a clock period delay.As EN,WE reach the BRAM 1 clock
period
> > > > earlier (at 155MHz  clock speed that means about 6 ns) the
setup-time
> > for
> > > > these signals is not violated resulting BRAM to be in the operation
mode
> > we
> > > > wish (read or write) the moment addr and data_in arrive.
> > >
> > > If you look at the data sheet, there are fairly long set-up times on
all
> > the
> > > BRAM inputs.  Routing to the BRAMs also adds to the delay, as does any
> > > combinatorial logic on these inputs.  The idea of putting registers on
the
> > > inputs (which includes the EN and WE inputs) is to minimize the amount
of
> > delay
> > > added externally to these signals.  Your understanding is a bit
incorrect,
> > as
> > > what you are suggesting is delaying signals to allow a long
combinatorial
> > > delay.  That is dangerous, because there is no guarantee on the
minimum
> > delay.
> > > Instead, what I am suggesting is to remove as much of the delay as
> > possible
> > > between the registers driving the BRAM inputs and the BRAM inputs,
which
> > meahs
> > > avoiding combinatorial logic on these paths, minimizing the fanout of
> > these
> > > signals, and physically locating the registers close to the BRAMs.
> > >
> > > >
> > > > 2) The need for floorplanning
> > > > Xilinx software tool maybe has put the additional registers far from
the
> > > > BRAMs, if this is the case we must manual place them near the BRAM
to
> > > > decrease the propagation delay of the signals.
> > >
> > > That is correct.  Routing in FPGAs is not just wire, it also consists
of
> > > switches which add to the propagation delay of signals on the
connections
> > > between logic.  Manually placing the registers near the BRAM helps to
> > minimize
> > > the added delay.
> > >
> > > >
> > > > 3) Tying the WE,EN inputs and contol access through the address when
> > working
> > > > at high speeds.
> > > > Do you mean to keep WE,EN high all the time and when we wish not to
use
> > the
> > > > BRAMs to write dummy data in some (or just one) specified addresses
(or
> > > > address) reserved for this reason?
> > >
> > > That is correct.  The set up times for EN and WE are nearly twice the
> > set-up
> > > times for address and data, so if we can eliminate these from the
equation
> > we
> > > can run at a higher clock rate.  They can be eliminated by always
writing,
> > but
> > > directing the writes of invalid data to locations where it does not
affect
> > the
> > > operation of the design.  In the case of FIFOs, you can just park the
> > write
> > > address until you have a valid write, since you are presumably not
reading
> > that
> > > data until it is valid.
> > >
> > > >
> > > >
> > > > Also I have another one question about BRAMs, Xilinx says that
BRAMs'
> > DATA
> > > > OUT are already registered. In Xilinx Floorplanner I believe this
> > register
> > > > is "inside" the BLKRAM box so no manual floorplanning for the output
is
> > > > needed. You need to manual floorplan (in the same way you do for the
> > inputs)
> > > > only if you choose to add an additional output register, correct?
> > >
> > > That is correct, the BRAM acts as though it is registered, although I
> > believe
> > > the actual implementation has the register on the address, not on the
> > memroy
> > > outputs.  In any event, the clock to out time is long compared to that
of
> > the
> > > CLB flip-flops.  The system clock rate can be increased by putting an
> > additional
> > > register on the BRAM data outputs and placing that register physically
> > close to
> > > the BRAM (that register should have no combinatorial logic in front of
> > it).
> > >
> > > >
> > > >
> > > > I really appreciate your help.
> > > >
> > > > Best Regards,
> > > > Harris
> > > >
> > > > "Ray Andraka" <ray@andraka.com> wrote in message
> > > > news:3C7FD73D.F6A3109A@andraka.com...
> > > > > VirtexE BRAMs can be written at 155MHz in any speed grade.  To do
so,
> > you
> > > > will
> > > > > likely have to put registers near to and with no logic between
them
> > and
> > > > the
> > > > > BRAMs.  Watch the loading too, routing to more than 1 BRAM for
each
> > > > register may
> > > > > cause you some heartburn.  At higher speeds, you probably should
also
> > > > consider
> > > > > tying the WE, and ENA inputs active and controlling your access
> > through
> > > > the
> > > > > address registers instead.  You'll also need to floorplan the
> > registers to
> > > > make
> > > > > sure they are located physically close to the BRAMs.
> > > > >
> > > > > "H.L" wrote:
> > > > >
> > > > > > Hi Peter, thanks for your reply
> > > > > > I was confident of this method's effectiveness but now I am
worried
> > :))
> > > > . I
> > > > > > have already done a timing analysis in the paper and also the
> > simulation
> > > > > > waveforms seem promising.
> > > > > > I didnt understand what do you mean when telling me that one of
my
> > words
> > > > > > arrives early and the other one late. The transmitter sends to
my
> > FPGA
> > > > an
> > > > > > external clock (thats the 155MHz clock), a valid signal (1 bit
> > > > indicating
> > > > > > the transmission time period) and of course the 16-bit words
that I
> > have
> > > > to
> > > > > > store. Every clock period (~6 ns) I have available in my ports
one
> > > > 16-bit
> > > > > > word, I register two sequential words from the in port to a
32-bit
> > > > register
> > > > > > (31->16 the first incoming word, 15->0 the second one). Then ,
in
> > > > another
> > > > > > 32-bit register I register (2 nd time) the 32-bit word I just
"made"
> > > > which
> > > > > > are the BRAM data_in. All the above operations are in a process
that
> > has
> > > > in
> > > > > > its sensitivity list the 155 clock. I write to the BRAM at 77MHz
> > using
> > > > the
> > > > > > incoming clock divide by 2 using a DLL. BRAM input signals are
> > assigned
> > > > in
> > > > > > the falling edge of the 77MHz clock so as to be before the
rising
> > edge
> > > > (of
> > > > > > the same clock) where the BRAM samples them. The write
operations
> > are in
> > > > > > another process with the slow clock in its sensitivity list.
> > > > > > The timing waveforms of the simulation are the same with the
timing
> > > > analysis
> > > > > > in paper but does this is a valid hardware design technique?
> > > > > > Thanks for your time and help!
> > > > > >
> > > > > > Best Regards,
> > > > > > Harris
> > > > > >
> > > > > > p.s: thats a small part of my design. I use DLL because other
parts
> > need
> > > > > > them (BUS_MUX e.t.c) , I tried to implement my whole design @
155
> > MHz
> > > > and I
> > > > > > got many timing errors (floorplanning managed to reduce them but
> > still
> > > > lot
> > > > > > of work to be done)
> > > > > >
> > > > > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> > > > > > news:3C7E621F.1E77A244@xilinx.com...
> > > > > > > I suggest you grab pencil and paper and do a clock-by-clock
timing
> > > > > > analysis. You
> > > > > > > will find that your clock-speed reduction buys you nothing,
unless
> > you
> > > > > > also
> > > > > > > double-buffer the data.
> > > > > > > One of your words arrives nice and early, the other one late.
> > However
> > > > you
> > > > > > clock
> > > > > > > the BRAM, one of the two words has the same old short set-up
> > time...
> > > > > > > Double-buffering would help. But Ray has mentioned some neat
> > tricks to
> > > > > > avoid the
> > > > > > > long set-up time of the control inputs.
> > > > > > >
> > > > > > > I will get back with more constructive notes. "Gotta run"
> > > > > > >
> > > > > > > Peter Alfke
> > > > > > > ===================
> > > > > > > "H.L" wrote:
> > > > > > >
> > > > > > > > Hello all,
> > > > > > > >
> > > > > > > > I have a module that accepts 16 bit words at 155MHz and I
want
> > to
> > > > store
> > > > > > then
> > > > > > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E
FPGA)
> > to
> > > > > > divide by
> > > > > > > > 2 the 155MHz clock as this frequency seems to be pretty high
to
> > > > write in
> > > > > > the
> > > > > > > > BRAM. So far I think 2 processes are enough to do my job,
one
> > > > operating
> > > > > > @
> > > > > > > > 155MHz to accept the 16-bit data and store them in a 32-bit
> > register
> > > > and
> > > > > > the
> > > > > > > > another one @ 75MHz to write the content of the 32-bit
register
> > in
> > > > the
> > > > > > BRAM.
> > > > > > > > I am thinking to assign the BRAM's signals
> > > > > > (ENABLE,WRITE,ADDRESS,DATA_IN) in
> > > > > > > > the falling edge of the 75MHz clock, the main reason for
this is
> > the
> > > > > > setup
> > > > > > > > time of the BRAMs signals (in this way the address,data are
6 ns
> > > > before
> > > > > > next
> > > > > > > > rising edge of the clock where BRAM samples its inputs). My
> > question
> > > > now
> > > > > > :)
> > > > > > > > , if one process uses the falling edge of one clock does
this
> > causes
> > > > > > > > problems to other processes in the design , e.g to processes
> > that
> > > > use a
> > > > > > > > different clock or to  processes using the rising edge of
the
> > same
> > > > > > clock?
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Harris.
> > > > > > >
> > > > >
> > > > > --
> > > > > --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
> > > > >
> > > > >
> > >
> > > --
> > > --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: 40463
Subject: Re: Xilinx ISE 4.1
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 7 Mar 2002 18:09:44 +0100
Links: << >>  << T >>  << A >>
"Salman Sheikh" <sheikh@pop500.gsfc.nasa.gov> schrieb im Newsbeitrag
news:20020307102855.29f702fc.sheikh@pop500.gsfc.nasa.gov...

> WARNING: DesignRules: 372 - Netcheck: Gated clock: Clock net
fsync1/CPUINTERFACE_0/N_115_inferred_clock is sourced by a combinatorial
pin. This is not good design practice. Use the CE pin to control the loading
of data into the flip-flop.
>
> I suspect this is the reason for the inferred clock since there is not clk
controlling the write strobes.
> How do I remedy the controlling the loading of the date into the flip-flop
via the CE pin?

process (clk)
begin
  if clk='1' and clk'event then
    if load='1' then
       flipflip<=data;
    end if;
  end if;
end process;

This gives you a nice clock enable without gated clocks.

--
MfG
Falk




Article: 40464
Subject: Re: Ports disappear after generating post place and route simulation
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Thu, 07 Mar 2002 10:31:22 -0700
Links: << >>  << T >>  << A >>


Try enabling the "Correlate Simulation Data to Input Design" switch form
the simulation netlist options in ISE.  That works sometimes but not all
the time.  If that does not work, you will need to modify your testbench
(comment out those port connnections).  If you were using VHDL, there is
one other trick of compiling the architecture only, but that is not an
option for Verilog.

--  Brian


Kenny wrote:

> Hi All,
>
> I am using ISE 4.1i and ModelSim PE for Verilog.
> I try to simulate one sub-module of my design. I use "Generating Post
> Place and Route Simulation Model" to generate Verilog file for
> ModelSim PE.
> I always lost some ports in that file. How do I keep those ports even
> I did not use them in that sub-module ?
>
> Any idea ?
>
> Kenny


Article: 40465
Subject: Re: Mutual Clock Synchronization
From: Greg Neff <gregeneff@yahoo.com>
Date: Thu, 07 Mar 2002 12:52:28 -0500
Links: << >>  << T >>  << A >>
On Wed, 06 Mar 2002 23:50:32 GMT, John_H <johnhandwork@mail.com>
wrote:

Yes, I can see why one would wonder why I would want to do such a
thing.  Imagine a series-connected string of nodes (up to 24), with a
pair of back-to-back E1 transceivers in each node.  Most of the data
on the E1 link is repeated, but there is some add-drop activity in
each node.  

The tough part is that nodes are added to each end, and removed or
inserted in the middle, on a dynamic (in the order of once a day)
basis.  These nodes have no knowledge of where they are physically in
the chain, and cannot be configured by an operator.  Coming up with a
mechanism to reliably maintain one master clock in this dynamic system
is non-trivial.  The thinking is that a democratic clock may be an
easier thing to do then dealing with master management.

>The telecom timing management tends to be a central timing standard with
>the E1 signals deriving their timing from the reference.  This distributed
>scheme leaves clock management in one central node.  When you cross
>jurisdictions (e.g. France/England interface) you live with slips defined
>at a maximum rate.
>
>What I don't understand (since you are deviating from this standard) is
>what you gain by trying to "democratize" the independent timing elements.
>This is such a non-standard approach to my telecom background and to my
>timing system development in general that I can't make suggestions.
>
>What you're looking for, in effect, is to have three independent systems
>(for instance) come to a compromise on a common frequency so you end up
>with a very "symmetric" timing scheme?  It would be soooo much easier if
>you chose one element to be the timing master.
(snip)

===================================
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Article: 40466
Subject: Re: Mutual Clock Synchronization
From: John_H <johnhandwork@mail.com>
Date: Thu, 07 Mar 2002 18:12:40 GMT
Links: << >>  << T >>  << A >>
A series-connected string of nodes could pass tthe timing from node to node to
node down the chain.  If you use good E1 parts, clock recovery is part of the
silicon and conforms to ITU-T jitter transfer specifications which maintains
clean phase jitter at higher frequencies by design.  These things are made to
be daisy-chained about once a kilometer on some very long runs.

If you're dealing with bidirectional traffic, you just need to know if the node
is an end node or not and loop back the timing that came down from the front of
the nodes.  A ring is a slightly different issue, but selecting one node as
"master" is straightforward.

Alternatively, one timing reference could be delivered to all 24 nodes as with
the central timing scheme.

Pretty standard telecom stuff applies nicely to non telecom applications.

Otherwise, would you be using 23 different phase comparators on each of the 24
nodes for the democratic approach?



Greg Neff wrote:

> On Wed, 06 Mar 2002 23:50:32 GMT, John_H <johnhandwork@mail.com>
> wrote:
>
> Yes, I can see why one would wonder why I would want to do such a
> thing.  Imagine a series-connected string of nodes (up to 24), with a
> pair of back-to-back E1 transceivers in each node.  Most of the data
> on the E1 link is repeated, but there is some add-drop activity in
> each node.
>
> The tough part is that nodes are added to each end, and removed or
> inserted in the middle, on a dynamic (in the order of once a day)
> basis.  These nodes have no knowledge of where they are physically in
> the chain, and cannot be configured by an operator.  Coming up with a
> mechanism to reliably maintain one master clock in this dynamic system
> is non-trivial.  The thinking is that a democratic clock may be an
> easier thing to do then dealing with master management.
>
> >The telecom timing management tends to be a central timing standard with
> >the E1 signals deriving their timing from the reference.  This distributed
> >scheme leaves clock management in one central node.  When you cross
> >jurisdictions (e.g. France/England interface) you live with slips defined
> >at a maximum rate.
> >
> >What I don't understand (since you are deviating from this standard) is
> >what you gain by trying to "democratize" the independent timing elements.
> >This is such a non-standard approach to my telecom background and to my
> >timing system development in general that I can't make suggestions.
> >
> >What you're looking for, in effect, is to have three independent systems
> >(for instance) come to a compromise on a common frequency so you end up
> >with a very "symmetric" timing scheme?  It would be soooo much easier if
> >you chose one element to be the timing master.
> (snip)
>
> ===================================
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com


Article: 40467
Subject: Re: MXE 5.5e speed
From: Kamal <>
Date: Thu, 7 Mar 2002 10:14:15 -0800
Links: << >>  << T >>  << A >>
Hello Kenny,

I believe that you are referring to MXE-II (5.5e) rather than MXE (5.5b) which is the question Cindy answered.

To clarify, MXE-II has the following limitations on speed:

< 40k lines is 40% the speed of PE
40k - 50k lines is 10% the speed of PE
> 50k lines is 1% the speed of PE

The numbers in Cindy's answer are for MXE.  I hope this helps.

Regards,
Kamal

Article: 40468
Subject: Re: Mutual Clock Synchronization
From: Greg Neff <gregeneff@yahoo.com>
Date: Thu, 07 Mar 2002 13:27:38 -0500
Links: << >>  << T >>  << A >>
On Thu, 07 Mar 2002 06:10:09 GMT,
allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote:

See my reply to John_H as to why we want to implement a democratic
clock.

I took a quick look at the parts you were kind enough to provide links
to.  One part has two clock inputs.  The other has many clock inputs.
The problem is that the PLL selects one of the inputs to be the
reference.   We would want a PLL that would accept three reference
clocks simultaneously.  The PLL output would be a function of all
three clocks.  One reference clock would be the local XO.  The other
two clocks would be recovered from the two E1 receivers.  The output
of the PLL would then provide the clock for both E1 transmitters.
This is the general idea.  We are trying to figure out if this idea
will work reliably in practice, and would like to find any information
that exists on this type of scheme.

(snip)
>
>As the other posters have mentioned, a "democratic" approach to timing
>is unusual, and (to me) doesn't make sense.
>
>Regarding the ITU-T specifications, I think you should look at the
>SONET/SDH specs instead of the E1 ones.
>Try: ITU-T G.707 (SDH) and the G.810 series (SDH timing).
>Also GR-253 (SONET).
>
>Even the Network Time Protocol (RFC1305) that is used to synchronise
>time of day clocks on computers has a hierarchy of timing sources.
>But it might give you some ideas that will help you with your problem.
>http://www.ietf.org/rfc/rfc1305.txt
>
>Oh, you should probably look at the datasheets for chips that are
>designed for phone network timing, e.g. Zarlink (nee Mitel) MT90401
>http://products.zarlink.com/partfinder/prodprofile.cgi?device=1127
>or maybe this one from Semtech:
>http://www.semtech.com/products/sets.html
>
>Regards,
>Allan.


===================================
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Article: 40469
Subject: Re: Using a battery instead of Config device
From: kayrock66@yahoo.com (Jay)
Date: 7 Mar 2002 10:40:13 -0800
Links: << >>  << T >>  << A >>
The leakage current will vary dramatically (AKA exponentially) with
temperature.  The 300uA numbers in the datasheet are for room temp
only.  Also, all your inputs must be driven to one of the supply
rails, anything between VDD and VSS on an input will leak juice and
drain your battery.  The outputs cannot be left driving anything
except a FET gate.  If you haven't been through this game before, it
can really be an task trying to patch all the leaks.  Did something
similar for a USB device trying to make the 500uA standby requirement.

Regards


Peter Alfke <palfke@earthlink.net> wrote in message news:<3C86D98F.1305708A@earthlink.net>...
> I can obviously not speak for Altera, but here are some general
> observations:
> 
> If the manufacturer made sure that all dc-consuming utilities are turned
> off as soon as the normal Vcc disappears, and if the process is somewhat
> old-fashioned ( >0.5 micron), then there is a chance. XC3000L used to
> consume <50 microamps, which is an acceptable (barely!) value.
> 
> If the manufacturer did not pay special attention, and does not indicate
> so in the data sheet, your hopes are slim.
> For all really up-to-date devices with geometries below 0.2 microns, (or
> 200 nanometers as it is more fashionably called), there is no hope. The
> inherent so-called leakage current is milliamps ( and more).
> 
> But you can always try it out by measuring, both at room and at slightly
> elevated temperature...
> 
> 
> Peter Alfke, Xilinx Applications
> ====================================
> Chris Cowdery wrote:
> 
> > I am considering using a lithium battery on a board instead of a
> > config device to enable my Altera FLEX10KA to retain its
> > configuration.
> >
> > Has anyone any idea of the absolute min quiescent current I can expect
> > a 10KA to draw?
> >
> > Thanks,
> >
> > Chris.

Article: 40470
Subject: Re: Fast transmission
From: kayrock66@yahoo.com (Jay)
Date: 7 Mar 2002 10:53:37 -0800
Links: << >>  << T >>  << A >>
In that case use NRZ, look at what is done in USB 1.0.  Its NRZ at
12Mb/s.  The SEI (serial interface engine) is public domain.  The
input signal is sampled with the 4x clock in the traditional way.  A
DPLL resynchronizes on every data transition and is in turn used to
pick the correct phase to sample data.  You need bit stuffing or
something like that at the transmitter to generate transitions to
maintain synchronization of the receiver with your transmitter because
during long periods of mark or space, the 2 clocks will drift.

Regards

"Roberto Capobianco" <capobianco@igi.pd.cnr.it> wrote in message news:<3c8780ec$1@news.mhogaming.com>...
> Thank you Peter for reply,
> yes i have a 100MHz free running receiver clock (4x oversampling).
> Just few questions. In the case of NRZ transmission is correct to
> synchronize the incoming signal with
> my 100MHz clock (with a classic two stage flip-flops, no problem for me two
> clock cycles delay) and after
> to do sampling on synchronized signal or is better to do sampling directly
> on incoming signal ?
> In the case of Manchester transmission (50MHz transmission clock in this
> case) receiver clock should be 200MHz (4x oversampling).
> Maybe this frequency is too high for me. Can i do a manchester decoder with
> different technique, maybe PLL with 50MHz
> reference clock ?
> 
> Thanks.
> 
> 
> Roberto Capobianco
> Consorzio RFX - CNR di Padova
> C.so Stati Uniti, 4
> 35127 - Camin (PD)
> email: capobianco@igi.pd.cnr.it
> web: www.igi.pd.cnr.it
> tel.: +39-049-8295048
> fax: +39-049-8700718
> 
> 
> 
> 
> 
> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3C86944B.F4D25F0@xilinx.com...
> > NRZ is fine if you have exactly the same clock at the transmitting and the
> > receiving end.
> > If there is any question about clock accuracy, then Manchester is much
>  better,
> > since it is kind of self-clocking. But it has far more transitions ( max
>  two per
> > bit, vs max 1 for NRZ). That limits the max bandwidt, but may not be a
>  problem
> > with fibre.
> > 8 or even 4 times oversampling with a free-running receiver clock is ok,
> > provided you have solid signals, and almost no clock frequency
>  uncertainty.
> >
> > Peter Alfke, Xilinx Applications
> > ==============================
> > Roberto Capobianco wrote:
> >
> > > Hi all,
> > > i want to send on fiber a digital pattern of approximately 50 bits with
>  Tbit
> > > = 40ns (25MHz transmission clock).
> > > First question : NRZ or Manchester code ?
> > > Second question: UART and Manchester decoders in FPGA often use 16x
> > > oversampling to sample at mid-bit of data cell.
> > > This is impossible for me.
> > > In the design at http://www.xilinx.com/xcell/xl17/xl17-30.pdf  we have a
>  8x
> > > oversampling manchester decoder
> > > but with my flex (Altera ACEX 1K) is very difficult to have a single
>  global
> > > clock at 200MHz for all.
> > > Exist different ways to realize a good sampling with a low frequency ?
> > >
> > > Thanks.
> > >
> > > --
> > > Roberto Capobianco
> > > Consorzio RFX - CNR di Padova
> > > C.so Stati Uniti, 4
> > > 35127 - Camin (PD)
> > > email: capobianco@igi.pd.cnr.it
> > > web: www.igi.pd.cnr.it
> > > tel.: +39-049-8295048
> > > fax: +39-049-8700718
> >

Article: 40471
Subject: Re: Virtex-II : Temperature Sensing Diodes
From: kayrock66@yahoo.com (Jay)
Date: 7 Mar 2002 11:05:23 -0800
Links: << >>  << T >>  << A >>
I haven't seen the spec but I'd imagine that its more of a maximum
current spec before your burn it up.  Its fabed with the same process
technology as all the junctions on the die, so maybe the max operating
conditions for the part would be a hint of the diodes range?  This is
a good Peter question.

Regards

Cindy <cindicater@hotmail.com> wrote in message news:<ee7548a.-1@WebX.sUN8CHnE>...
> Is there is absolute maximum voltage specified for the DXP and DXN pins?
> 
> Thanks!

Article: 40472
Subject: Re: V-II DCM options
From: kayrock66@yahoo.com (Jay)
Date: 7 Mar 2002 11:08:08 -0800
Links: << >>  << T >>  << A >>
What about one of those Roboclock chips and the likes that you see
from Cypress and others.  I vaguely remember them being digitally
programmable PLLs.

Regards

Martin Thompson <martin.j.thompson@trw.com> wrote in message news:<uelixtz18.fsf@trw.com>...
> Austin Lesea <austin.lesea@xilinx.com> writes:
> 
> > Martin,
> > 
> > Nope.
> > 
> > How about the 2V40?  Pretty tiny, cs144 package (smallest)?
> > 
> 
> I wonder... could I solder onto the balls for prototyping.....
> 
> Anyone have any ballpark idea how much these devices cost?
> 
> Cheers,
> Martin

Article: 40473
Subject: Re: Quartus II 2.0 fast fit option
From: "bob elkind" <eteam@aracnetfoofoo.com>
Date: Thu, 07 Mar 2002 19:34:18 GMT
Links: << >>  << T >>  << A >>
Free (for download version) or not, anyone interested in making serious use
of Altera or Xilinx toolsets (and the synth/sim products that go along with
them)
would be well advised to use Win2K rather than W9x or WME.

What do I mean by the term "serious use" ?
You need to get your job DONE, as in MAKE A LIVING.

If X and A don't say as much explicitly, there are occasional clues (e.g.
WinNT,
W2K or higher RECOMMENDED).  Just because you can get some of your work
done on W9x doesn't mean it's a good idea.  We could go on and on about the
"my rights" vs. "corporate slime" vs. "lazy programmers" issues forever, but
I
don't think we could add any new insights to the discussion.  Do you want to
be
"right", or do you want to design stuff?  So....

That's life.  Now move on and get work done.

-- Bob Elkind

"Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in
message news:a648lj$1fb$1@newsreader.mailgate.org...
> Peter Ormsby wrote:
> >
> >
> > Kevin,
> >
> > You have been exceedingly critical of Altera long before QII v2.0 WE was
> > ever released.
>

... snipped stuff

> Yes, I use a Windows 98 PC which is known for its legendary instability,
> but still XST doesn't crash like that.
> You might say that Altera didn't write LS (Mentor Graphics/Exempler
> Logic did), but if it is so buggy that it crashes when stop button is
> pressed why is Altera distributing such software, even if it is free?
>         One of my major complaint of QII 1.1/2.0 (only tried Web Edition
> though) is that for some reason, QII drains Windows 9x's system
> resources much more heavily than ISE WebPACK.
> Because Windows 98 is so bad, I always have to put Resource Meter on the
> side of my screen, and whenever QII is running, I see it draining large
> amounts of system resources, which comes back if I exit QII, but each
> time this happens, I have to interrupt what I was doing, and I don't
> like that.
> Altera seemed to have made no improvements there compared to QII 1.1.
> I read somewhere that Altera doesn't recommend using QII under Windows
> 98, and instead recommend using Windows NT 4.0 or 2000, but I sort of
> suspect that is because the system resource issue.




Article: 40474
Subject: Re: Virtex-II : Temperature Sensing Diodes
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 07 Mar 2002 11:36:43 -0800
Links: << >>  << T >>  << A >>
Jay,

It is intended to be exactly equivalent to a 1N914 diode.

Austin

Jay wrote:

> I haven't seen the spec but I'd imagine that its more of a maximum
> current spec before your burn it up.  Its fabed with the same process
> technology as all the junctions on the die, so maybe the max operating
> conditions for the part would be a hint of the diodes range?  This is
> a good Peter question.
>
> Regards
>
> Cindy <cindicater@hotmail.com> wrote in message news:<ee7548a.-1@WebX.sUN8CHnE>...
> > Is there is absolute maximum voltage specified for the DXP and DXN pins?
> >
> > Thanks!




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