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

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

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

Custom Search

Messages from 85475

Article: 85475
Subject: Re: floorplanning
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Fri, 10 Jun 2005 14:05:52 +1200
Links: << >>  << T >>  << A >>
Paul Boven wrote:
> Having studied the datasheet quite well before getting into this, it is 
> a lot easier for me to map a desired circuit into FFs, LUTs and the 
> like. Learning VHDL or even using the schematic editor, feels like a 
> terribly involved way to convince the software to configure those LUTs 
> the way I want them. So yes, I can imagine some demand for a FPGA layout 
> tool that stays this close to the hardware. But 'realy slick and 
> commercial' probably would put it out of my reach.

HDL's not too bad for laying things out like this, if you have regular 
structures, because you can express the relationships algorithmically, 
and then easily mix and match this structural code with higher level, 
less speed critical HDL code.

My 2c,
Jeremy

Article: 85476
Subject: Re: Question for Alex Gibson
From: "Alex Gibson" <news@alxx.net>
Date: Fri, 10 Jun 2005 12:24:06 +1000
Links: << >>  << T >>  << A >>

"Dimitri Turbiner" <dima_turbiner@yahoo-dot-com.no-spam.invalid> wrote in 
message news:UeqdnS6cqvrGQTXfRVn_vg@giganews.com...
> Hi Alex, I couldn't find your original email so I thought posting on
> CAStalk
> Here's my original message:
>
>>
>> Hi Alex,
>>
>> I'm Dimitri Turbiner.
>> Actually I'm extremely interested in working exactly
>> on the XUPv2p board and since I saw your post on
>> CAStalk that you have already a working instalation of
>> Linux I would like to ask you some questions:

No I'm not the one with the working version of linux yet.
A few people on the uclinux microblaze mailing list have.

I suggest posting on the mailing list and asking them your questions.

John Williams has uclinux working on it.
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

original messages were on the uclinux microblaze mailing list
http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
see below for messages

I'm still waiting on the board to be purchased
(takes a while through the university)

Alex

 From the original messages dated 29.04.2005


Or http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html

I've already used these helpful references to get a Linux kernel running on
the PowerPC405 on the Digilent XUP-V2Pro board.  I'm new to ucLinux but it
doesn't appear to be much more complicated than the ucLinux steps.

Paul Hi Aurash, hi John,
>
> We are working with the PPC on virtex2p. You do not need Monta Vista
> Linux.
> All you need is denx eldk: http://www.denx.de/twiki/bin/view/DULG/ELDK
> And the penguin ppc linux distribution:
> http://www.penguinppc.org/kernel/#developers
> (we are using the 2.4 Kernel)
> To get started: http://www.klingauf.de/v2p/index.phtml might be helpful.
>
> On the other hand we are also using uClinux on spartan3.
> It is really a question of what hardware you have and what you want to do
>  ;-)
>
> Have Fun
> Jan 



Article: 85477
Subject: Re: DDR desing with FPGA
From: "Teo" <themarenas@comcast.net>
Date: 9 Jun 2005 19:26:01 -0700
Links: << >>  << T >>  << A >>
If you want to save some coin, you should look at the Lattice EC fpgas.
 They have built in DQS & clock domain transfer logic to support DDR
memory up to 200Mhz.  Although density is not as large as V4, you can
get up to a 33k or 40k LUT device.

Symon wrote:
> "Antti Lukats" <antti@openchip.org> wrote in message
> news:d88m0o$be1$03$1@news.t-online.com...
> >
> > Q: as the DDR chips are mounted VERY close, all wires less than 0.5 inch?
> > and there is never more than one load on the DDR chips, I am wondering is
> it
> > safe to not have DDR termination resistors by using DCI in the FPGA and
> > switching the DDR into SSTL1 mode by the extended mode register write?
> >
> Antti,
> If the risetime is six times the flight time of the traces, you'll probably
> be safe without terminations. Risetime 1ns => 1 inch trace length in FR4.
> (25.4mm for metric Estonians! Actually, are Estonians metric?) Trace length
> must, of course, include the bond wires, bga traces, lead frames.
> Cheers, Syms.


Article: 85478
Subject: Re: pcb layers on BGAs Spartan-3
From: "dlharmon" <harmon.darrell@gmail.com>
Date: 9 Jun 2005 20:13:01 -0700
Links: << >>  << T >>  << A >>
> Without knowing what PCB technology you're using, it's impossible to say.
> Here are a few questions off the top of my head.
> Can you use microvias? What's your minimum track width? Minimum gap between
> tracks? What's the biggest BGA package on the board? Are you prepared to
> swap pins on the FPGA to aid the routing process? Is your volume enough to
> make it worth spending a lot of time on the layout? How fast are your
> risetimes and how long are your traces? Do you have Hyperlynx? Are you gonna
> insist on a plane for each of your power supplies, or do you know what
> you're doing? ;-)
>
> 256 pin BGA, 4mil tack/gap, uvias, two ground planes, routed powers,
> quick(ish) turnaround, long and fast traces = 6 layers, maybe even 4 with
> one ground plane if you're quite talented and have a lot of time.
> Cheers, Syms.
> p.s. Simetry (sic)? Pah, I spit on symmetry.

I have laid out my first board using the FT256. I have not had it
fabricated yet. It is 4 layers 6/6mil track/space.  The real killer was
the size of the vias.  I used 1 solid groundplane and planelets for
VCCIO VCCAUX and VCCCORE.  All IO voltages are the same which helps.  I
was not able to route out all the IO.  I have posted a PDF file
containing the PCB layers at http://dlharmon.com/dspcard.pdf  Any
comments on whether or not it will have decent signal integrity would
be appreciated.  Maybe it can provide some ideas.

Darrell Harmon
http://dlharmon.com


Article: 85479
Subject: Re: Question for Alex Gibson
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 10 Jun 2005 13:46:58 +1000
Links: << >>  << T >>  << A >>
Alex Gibson wrote:

> John Williams has uclinux working on it.
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux

Credit where credit's due - Paul Hartke did the work, I'm just hosting 
the files! :)

John

Article: 85480
Subject: I2C clock stretching(XILINX reference design)
From: praveen.kantharajapura@gmail.com
Date: 9 Jun 2005 21:31:11 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am implementing a I2C slave. I am refering XAPP333 for my deisgn.
But one of the "limitation" of that reference design from XILINX is
that it does not support "clock stretching".

Suppose we do not need clock stretching "SCL" will be taken as INPUT to
my I2C slave block.But if i want Clock stretching the slave also will
be driving the SCL low when required to keep the master on hold.In this
case SCL will be an INOUT for my module.

My question is how to go about this implementation(tristate buffers on
SCL!!!).
Waht i am planning to do is, i will pull the SCL line low whenever i
want to stop the clock transition on SCL from master else i will drive
a "Z" on SCL.

please comment on this implementation.


Regards,
Praveen


Article: 85481
Subject: Re: FPGA : MAC FIR doubt--HELP ME PLEASE
From: bijoy <pbijoy@rediffmail.com>
Date: Thu, 9 Jun 2005 22:10:23 -0700
Links: << >>  << T >>  << A >>
Hi

I have made a FIR filter using multipler components and BRAMs

But i am facing problems during timing simulation, it works fine during functional simulation.

will explain little bit about other components involved in my design

In my design i have a 35.328 MHz base clock

have multipled it by 2 and used to run another FIR filter (32 tap decimation available from core gen) this is a fixed tap one

Now i multipled 70.656 MHz output of my first DCM again by 2 to get 140.312 MHz which is given to the new 32 tap FIR filter i made as described above (ie using descrite components , multipler,BRAM etc)

I need to run it at 140.312 Mhz as my input data rate is at 4.416 and the number of tap filters are 32. (i can split it into two 16 tap filter but in that case i need 4 BRAMs for this filter itself, in that case i cannot accomodate other filters which is already existing in my design, as i am currently using xc3s50 device which has got 4 BRAMs only)

functionally it simulated well

but during timing simulation i am getting this error in my model sim simulator

===================================

Time: 9898215 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu138 # ** Warning: /X_FF HOLD Low VIOLATION ON I WITH RESPECT TO CLK; # Expected := 0.381 ns; Observed := 0.055 ns; At : 9898.226 ns # Time: 9898226 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu142 # ** Warning: /X_FF HOLD High VIOLATION ON I WITH RESPECT TO CLK; # Expected := 0.381 ns; Observed := 0.328 ns; At : 9898.5 ns # Time: 9898500 ps Iteration: 3 Instance: /tb_gl/uut/glrx_1_tde_filter_comp_tde_filter1_multiply_comp_bu152 # ** Warning: /X_FF HOLD High VIOLATION ON I WITH RESPECT TO CLK;

==================================

what is this error means. i think there is some set-up violation but how do i debugg this problem

how can i see the internal signals during timing simulation ?

please advice me in this regard

thanks

bijoy

Article: 85482
Subject: Re: Question for Alex Gibson
From: "Alex Gibson" <news@alxx.net>
Date: Fri, 10 Jun 2005 15:15:28 +1000
Links: << >>  << T >>  << A >>

"John Williams" <jwilliams@itee.uq.edu.au> wrote in message 
news:newscache$9unuhi$4kd$1@lbox.itee.uq.edu.au...
> Alex Gibson wrote:
>
>> John Williams has uclinux working on it.
>> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>
> Credit where credit's due - Paul Hartke did the work, I'm just hosting the 
> files! :)
>
> John

I thought, Paul had linux running on the v2pro board ?

So he got uclinux running as well. Good :-)

I'm tempted to buy one of the xupv2p boards myself
rather than wait and share the one at uni.

Paul Hartke wrote:
> Or http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
>
> I've already used these helpful references to get a Linux kernel running 
> on
> the PowerPC405 on the Digilent XUP-V2Pro board.  I'm new to ucLinux but it
> doesn't appear to be much more complicated than the ucLinux steps.
>
> Paul

Alex 



Article: 85483
Subject: SPD interface(Serial presence detect)
From: praveen.kantharajapura@gmail.com
Date: 9 Jun 2005 23:25:27 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am implementing a SPD interface in an FPGA. The DDR SDRAM is from
MICRON.
Now to redd the EEPROM content(first 128 bytes) , first i will send the
slave addres of EEPROM over I2C(with r/w='1' , which indicates a
read).Now my question is will the EEPROM send all the bytes serially at
one shot, OR should i address which byte i want to read explicitly ??


Regards, 
Praveen


Article: 85484
Subject: fast universal compression scheme and its implementation in VHDL
From: "Jens Mander" <quinn_the_esquimo@freenet.de>
Date: Fri, 10 Jun 2005 08:28:30 +0200
Links: << >>  << T >>  << A >>


Hi folks,

my name is Jens and I am student of the Technical University Berlin. Through
my course of study in microelectronics VHDL design is becoming my favorite
hobby. My other interests are signal processing and compression in general.
Lately I purchased an FPGA Evalution board second-hand (guess where?) and I
am now starting my first "private" implementations. Just to give you a short
intro... ;-)

I  am interested in implementing compression algorithms using VHDL on an
FPGA. I want to build a data transmission system that compresses portions of
the incoming data (not the whole data but "frames" of like 800 bytes)
on-the-fly. In my search for a fast (i.e. real-time capable at a "desired"
data rate of - let's say - 300 MHZ?) "universal" compression scheme I came
across the following stepping stones:

- is there any free example code for compression algorithms available in
VHDL to get an overview and a first impression of implementation complexity?

- what would you think are the most promising algorithms for my purpose
(i.e. when statistics and semantics of the input data are unknown), first of
all I thought of delta encoding, sorted RLE, LZ, ....?

- as the input data is unknown the álgorithm must be lossless, reducing
redundancy (if possible), not irrelevancy. what are the theoretical limits
of "universal" compression, not emphazizing one particular statistical
property (like similar by values in succession)?

- what is meant by the keyword "systolic implementations" and "pipeling" in
that particular context? I came across that very often lately

- what if my code gains different compression ratios for consecutive data
portions? surely a FIFO can decouple input and output rate but eventually
the FIFO will underflow?

Thanks for you help + support in advance, any comments, hints and help is
appreciated!

Bye Jens


P.S.: I'm looking for the standard works "Sayood, Khalid: Introduction to
data compression, Academic Press, 199x or 200x" and/or ". Salomon: Data
Compression, Springer-Verlag, New York, 200x". Are there any sources of an
electronic copy (ps, pfd, etc.) or transcriptions?






Article: 85485
Subject: Re: faster Spartan III adder
From: =?ISO-8859-1?Q?G=F6ran_Bilski?= <goran.bilski@xilinx.com>
Date: Fri, 10 Jun 2005 09:04:21 +0200
Links: << >>  << T >>  << A >>
Paul Smith wrote:
> Hi,
> 
> I need to add a pair of 8 bit (unsigned) integers to get a 9 bit 
> (unsigned) result at 250 MHz, preferably in an XC3S50-4.
> 
> Using the Coregen adder/subtractor V7 with maximum pipelining (9) and 
> RPM on, the best cycle time I can get is 4.55 ns.  At each pipeline 
> level the critical path is a LUT, a MUXCY, and another LUT.
> 
> Can anyone point me at some hints for a faster implementation (besides 
> going to a faster part?
> 
> TIA
> 
> Paul Smith
> Indiana University Physics

Hi,

Another solution is to fully pipeline the adder but it requires that the result 
can be pipelined and that you are not area limited.

This solution doesn't use the carry chain but instead doing a normal adder with 
one lut for calculate the carry bit and one lut for calculate the result bit.
Each LUT is directly connected to a DFF.

Making it 9 or 10 doesn't change the speed, just the size.
So the critical path is DFF->LUT->DFF which should meet your speed requirement.

The code below is a quick and dirty implementation of this.
It can now do 3 ns now in a Spartan3-4.
It can be improved both in area and speed.
If you want it faster then the LUTS and DFFS needs to be floorplanned using RLOC.

Göran Bilski


library IEEE;
use IEEE.std_logic_1164.all;

entity adder is
   generic (
     Size : natural := 8);
   port (
     Clk : in  std_logic;
     A   : in  std_logic_vector(Size-1 downto 0);
     B   : in  std_logic_vector(Size-1 downto 0);
     Res : out std_logic_vector(Size-1 downto 0)
     );
end entity adder;

architecture IMP of adder is

   type   array_type is array (natural range 0 to Size) of
                         std_logic_vector(Size-1 downto 0);
   signal A_Temp   : array_type;
   signal B_Temp   : array_type;
   signal Res_Temp : array_type;
   signal Carry    : std_logic_vector(Size downto 0);

begin  -- architecture IMP

   Res_Temp(0) <= (others => '0');
   carry(0)    <= '0';

   All_Bits: for I in 0 to Size-1 generate

     Res_Bit : process (Clk) is
     begin  -- process Res_Bit
       if Clk'event and Clk = '1' then   -- rising clock edge
         A_Temp(I+1)      <= A_Temp(I);
         B_Temp(I+1)      <= B_Temp(I);
         Res_Temp(I+1)    <= Res_Temp(I);
         Res_Temp(I+1)(I) <= A_Temp(I)(I) xor B_Temp(I)(I) xor Carry(I);
         Carry(I+1)       <= (A_Temp(I)(I) and B_Temp(I)(I)) or
                             (A_Temp(I)(I) and Carry(I)) or
                             (B_Temp(I)(I) and Carry(I));
       end if;
     end process Res_Bit;
   end generate All_Bits;

   DFFs : process (Clk) is
   begin  -- process DFFs
     if Clk'event and Clk = '1' then     -- rising clock edge
       A_Temp(0) <= A;
       B_Temp(0) <= B;
       Res       <= Res_Temp(Size);
     end if;
   end process DFFs;
end architecture IMP;


Article: 85486
Subject: Re: faster Spartan III adder
From: Sylvain Munaut <com.246tNt@tnt>
Date: Fri, 10 Jun 2005 09:23:01 +0200
Links: << >>  << T >>  << A >>
Paul Smith wrote:
> ISE 7.1 defaults to 85 C and 1.14 volts; I thought the idea was that if 
> a design meets timing under these limits you were safe under "normal" 
> conditions.

No, if the timing meets at these conditions, it is safe to run it at 
85°C and 1.14V ...


	Sylvain

Article: 85487
Subject: programmation with IMPACT with one PROM and two FPGAs
From: "Marie" <mvq@oip.be>
Date: 10 Jun 2005 00:48:26 -0700
Links: << >>  << T >>  << A >>
Hello,

I use IMPACT to program two FPGAs via a PROM.
The PROM is xc18v04 and the FPGAs are xc2S300E-6.
Here is the organization of the connections (as on p. 12 of the DS026
document, datasheet of the PROM):
Vref and GND pins of the parallel IV cable are connected to 3.3V and
ground.
TCK and TMS pins of the cable are connected with the PROM and the
FPGAs.
TDI pin is connected with the PROM.
TD0 pin of the PROM is connected with TDI pin of the first FPGA (M2M1M0
=3D 000).
TDO pin of the first FPGA is connected with TDI pin of the second FPGA
(M2M1M0 =3D 111).
TDO pin of the second FPGA is connected with the TDO pin of the
parallel IV cable.
I build the chain in the PROM formatter (file mode in IMPACT). PROM
file generation is successfull.
Then I go to device mode, serial mode.
The connection to the cable is successfull.
If I do not use the wizard, I can only add the .bit files of the FPGAs.
If I use the wizard, I can add the mcs file created with the PROM
formatter.
In both cases, when I try to "program" I get the following error
message "DONE pin did not go low".
We checked the activity on TCK clock and we only see a down pulse of
about 600=B5s.
Could you tell me what I have to do in IMPACT to generate the necessary
signals to the cable?

Thank you,

Marie


Article: 85488
Subject: Re: ISE/EDK 6.3 vs 7.1...
From: Klaus Falser <kfalser@durst.it>
Date: Fri, 10 Jun 2005 09:52:35 +0200
Links: << >>  << T >>  << A >>
In article <ee8ec82.1@webx.sUN8CHnE>, vadimv@ieee.org says...
> I also noticed that the fitter for ISE 7.1 isn't as efficient. 
> I had a legacy design for an XC9500, and I called Xilinx tech 
> support on an unrelated issue. I was using 6.3, the tech support 
> guy used 7.1, and he couldn't fit my design to the chip. 
> He had to install 6.3 to be able to work on it. It really does 
> seem that the new fitter isn't as efficient.
> 

IMHO, for XC9500 CPLD's it is best to stick with 
Webpack 5.2.
Only yesterday I had a case where I needed to modify an
old design slightly and in this occasion I thought 
to migrate the design to the lastest ISE version.
The design failed to work, but in a way that only 
some signals were wrong. So the failure was not 
noticed immediately, since some parts of the 
design worked, but an important function did not.
Simply compiling the design with 5.2 brought 
the design to work.

Since this was not the first time I got burned with 
7.1 (remember the inverted outputs bug ?), 
I hope I will learn the lession this time.

The story however confirms my opinion that 
the XC9500 family is a unloved child in Xilinx.

Regards
Klaus 

Article: 85489
Subject: S3 not auto-loading from platform flash
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 10 Jun 2005 08:54:13 GMT
Links: << >>  << T >>  << A >>

I'm using the Digilent S3 starter kit, which includes a xcf02 platform flash chip.

With the as-shipped test design in the platform flash, it loads automatically on power-up, however
when I program my design into the flash chip, it only loads when I push the Prog button on the
board. If I reprogram the test design, it auto-loads OK. 

Is there an option I need to set somewhere to make it auto-load my design from the flash? 


Article: 85490
Subject: Gated clock question
From: stoyan.shopov@gmail.com
Date: 10 Jun 2005 02:12:11 -0700
Links: << >>  << T >>  << A >>
Hi, everybody
I have a simple question about gated clocks. I remember reading
somewhere in this group that "gated clocks are anathema to this group".
Can someone explain what is bad about such clocks.
Also, I recently read that XST and Quartus perform different timing
analyses on paths between flip-flops with gated flops in between
(www.altera.com/literature/wp/wp_timingAnalysis.pdf, page 6 -
transparent latches):

"Using the Xilinx ISE tool, the minimum period analysis may start at or
end in latches because the ISE
software treats latches as timing points similar to registers. The
Quartus II software treats latches as logic
and analyzes them as part of a look-up table (LUT) chain. Because of
this difference, the register-to register
logic level in the timing analysis report is shorter as reported by the
ISE software than it is as
reported by Quartus II software when latches are involved."

Does anybody think that this can be a pitfall? If so, can you give an
advice of avoiding it? I am a novice to VHDL and FPGA usage...

Thanks and best regards!
Stoyan Shopov


Article: 85491
Subject: X-Fest devkit order leadtimes & software silliness....
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 10 Jun 2005 09:30:00 GMT
Links: << >>  << T >>  << A >>
Wondering if anyone else has experienced this....
After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA Design Starter kit on the
x-fest special offer, as it was a cheap way to get the BaseX software. 
I'm now told that the kit won't be shipped til mid-August. I have no problem with that as I don't
need the hardware immediately & already have the S3 starter kit.. 

However when I contacted Memec to ask if they could ship the software immediately (which
Incidentally they charged my card for 2 weeks ago), they claimed that this wasn't possible, and when
I pressed them they said they'd ask Xilinx but were fairly sure they wouldn't do it. 
  
I'm sure I'm not the only one who ordered this offer as it was a very good deal compared to the
normal price - has anyone else had any joy getting the software out of them ahead of the hardware ?

Seems like a pretty daft situation.....

Article: 85492
Subject: Re: Gated clock question
From: "Jon Beniston" <jon@beniston.com>
Date: 10 Jun 2005 02:41:35 -0700
Links: << >>  << T >>  << A >>
> Can someone explain what is bad about such clocks

They're almost impossible to implement without getting glitches. Use
clock enables instead. If your prototyping an ASIC, and can afford it,
SynplifyPro will do automatic clock gate to enable conversion.

Cheers,
Jon


Article: 85493
Subject: Re: Gated clock question
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Fri, 10 Jun 2005 10:52:21 +0100
Links: << >>  << T >>  << A >>
> I remember reading
> somewhere in this group that "gated clocks are anathema to this group".
> Can someone explain what is bad about such clocks.

Short version:

Putting a clock through logic leads to skew, jitter, runt pulses, and lots
of other horrible things. These all make life far harder for the
implementation tools, which work on the assumption that you're not a moron.
FPGA logic fabric was designed for synchronous logic design. If you need to
switch a clock on and off "globally" (e.g. for power saving), some devices
have dedicated "clock multiplexor" resources to do this.

Gate your clocks, and your designs will run slower. Your tools will run
slower. Your designs will stop working inexplicably when they warm up or
cool down. Your logic will cease to work when you buy a new batch of chips.
Your wife will leave you for a younger man and your pot plant will die. Just
don't do it!

        -Ben-

P.S. You *really* don't want to hear the long version.



Article: 85494
Subject: Re: Gated clock question
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Fri, 10 Jun 2005 11:59:51 +0100
Links: << >>  << T >>  << A >>
In addition to all the other comments already made there is the basic 
problem that every time you re-run the build process the timing of the 
generated clock, relative to it's source, will be different. The result can 
be a nightmare of the design sometimes working, or not, and if you are very 
unlucky a half way house between working and not.

That said if you are gating (dividing) by using a flip-flop then you can do 
something in this area. Your generated clock will still differ in timing 
relationship to the source clock. Factors such as build, silicon batch, 
voltage, temperature will have a variance on this timing.

The only time I would use this is if I had a large design, that had a 
variable enable function (non regular 1 in N clocks), was also resource 
critical (tight squeeze in chip), to sit on the (gated) clock. By not using 
local clock enables you can save some resource.Otherwise I would use a clock 
enable or something like a DCM to divide, or control, the clock. If you do 
use a flip-flop control then extreme care will need to be taken in passing 
signals, or data, between the generated clock domain and source clock 
domain. All the usual non-related clock domain signal interfacing techniques 
will need to be used.

John Adair
Enterpoint Ltd. - Home of MINI-CAN. FPGA CAN Bus Development Board.
http://www.enterpoint.co.uk



<stoyan.shopov@gmail.com> wrote in message 
news:1118394731.028676.14960@g47g2000cwa.googlegroups.com...
> Hi, everybody
> I have a simple question about gated clocks. I remember reading
> somewhere in this group that "gated clocks are anathema to this group".
> Can someone explain what is bad about such clocks.
> Also, I recently read that XST and Quartus perform different timing
> analyses on paths between flip-flops with gated flops in between
> (www.altera.com/literature/wp/wp_timingAnalysis.pdf, page 6 -
> transparent latches):
>
> "Using the Xilinx ISE tool, the minimum period analysis may start at or
> end in latches because the ISE
> software treats latches as timing points similar to registers. The
> Quartus II software treats latches as logic
> and analyzes them as part of a look-up table (LUT) chain. Because of
> this difference, the register-to register
> logic level in the timing analysis report is shorter as reported by the
> ISE software than it is as
> reported by Quartus II software when latches are involved."
>
> Does anybody think that this can be a pitfall? If so, can you give an
> advice of avoiding it? I am a novice to VHDL and FPGA usage...
>
> Thanks and best regards!
> Stoyan Shopov
> 



Article: 85495
Subject: Re: DDR desing with FPGA
From: ALuPin@web.de
Date: 10 Jun 2005 04:06:50 -0700
Links: << >>  << T >>  << A >>
>If you want to save some coin, you should look at the Lattice EC fpgas.
 >They have built in DQS & clock domain transfer logic to support DDR
>memory up to 200Mhz.  Although density is not as large as V4, you can
>get up to a 33k or 40k LUT device.

Teo,
have you tried the IP core from Lattice ?
Or are you using the datapath template from the IP Manager ?

Rgds
Andr=E9


Article: 85496
Subject: Re: X-Fest devkit order leadtimes & software silliness....
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Fri, 10 Jun 2005 12:07:31 +0100
Links: << >>  << T >>  << A >>
If you just need synthesis, p&r, then ISE Webpack can be used as a stop gap 
for Spartan-3 devices up to XC3S1500.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk


"Mike Harrison" <mike@whitewing.co.uk> wrote in message 
news:cenia1pc7q3ptsc4rrhts8phl8085g2smh@4ax.com...
> Wondering if anyone else has experienced this....
> After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA 
> Design Starter kit on the
> x-fest special offer, as it was a cheap way to get the BaseX software.
> I'm now told that the kit won't be shipped til mid-August. I have no 
> problem with that as I don't
> need the hardware immediately & already have the S3 starter kit..
>
> However when I contacted Memec to ask if they could ship the software 
> immediately (which
> Incidentally they charged my card for 2 weeks ago), they claimed that this 
> wasn't possible, and when
> I pressed them they said they'd ask Xilinx but were fairly sure they 
> wouldn't do it.
>
> I'm sure I'm not the only one who ordered this offer as it was a very good 
> deal compared to the
> normal price - has anyone else had any joy getting the software out of 
> them ahead of the hardware ?
>
> Seems like a pretty daft situation..... 



Article: 85497
Subject: Re: Gated clock question
From: stoyan.shopov@gmail.com
Date: 10 Jun 2005 04:30:28 -0700
Links: << >>  << T >>  << A >>
Thanks to all of you, guys, you have been really very helpful!
Actually, I suspected there might be glitches when gating a clock, now
things are quite more clear.


Article: 85498
Subject: Re: X-Fest devkit order leadtimes & software silliness....
From: "Unbeliever" <alfkatz@remove.the.bleedin.obvious.ieee.org>
Date: Fri, 10 Jun 2005 21:40:48 +1000
Links: << >>  << T >>  << A >>

"Mike Harrison" <mike@whitewing.co.uk> wrote in message
news:cenia1pc7q3ptsc4rrhts8phl8085g2smh@4ax.com...
> Wondering if anyone else has experienced this....
> After the recent X-Fest seminar in Cambridge UK, I ordered the Memex FPGA
Design Starter kit on the
> x-fest special offer, as it was a cheap way to get the BaseX software.
> I'm now told that the kit won't be shipped til mid-August. I have no
problem with that as I don't
> need the hardware immediately & already have the S3 starter kit..
>
> However when I contacted Memec to ask if they could ship the software
immediately (which
> Incidentally they charged my card for 2 weeks ago), they claimed that this
wasn't possible, and when
> I pressed them they said they'd ask Xilinx but were fairly sure they
wouldn't do it.
>
> I'm sure I'm not the only one who ordered this offer as it was a very good
deal compared to the
> normal price - has anyone else had any joy getting the software out of
them ahead of the hardware ?
>
> Seems like a pretty daft situation.....

Same deal downunder, Mike,
    I'm making do with a 60 day version of the software while waiting, which
the local FAE has promised to refresh for me if the kit takes too long.

Cheers
--
Alf
alfkatz@remove.the.obvious.ieee.org.y,



Article: 85499
Subject: Building a MicroBlaze from scratch, unable to run.
From: raybakk@yahoo.no (Raymond Bakken)
Date: 10 Jun 2005 05:15:41 -0700
Links: << >>  << T >>  << A >>
Hi

I am using a spartan3 development board and trying to learn about
MicroBlaze.

My application is simple, I want the bitpattern at the slideswitches
to appear on the leds (The board has 8 slideswitches and 8 leds).

If I use the BSB to create my MicroBlaze it works fine.
the modules (in Add/Edit cores) the BSB create/use is:
microblaze         4.00.a    microblaze_0
opb_mdm            2.00.a    debug_module
lmb_bram_if_cntrl  1.00.b    dlmb_cntlr
lmb_bram_if_cntrl  1.00.b    ilmb_cntlr
bram_block         1.00.a    lmb_bram
opb_gpio           3.01.b    LEDs_8Bit
opb_gpio           3.01.b    DIP_Switches_8Bit
dcm_module         1.00.a    dcm_0

If I make one from scratch it doesn't work.
the module (in Add/Edit cores) I create/use is:
lmb_bram_if_cntrl  1.00.b    i_bram
lmb_bram_if_cntrl  1.00.b    d_bram
bram_block         1.00.a    bram
opb_gpio           3.01.b    Switch
microblaze         4.00.a    MyProsessor
opb_gpio           3.01.b    Leds
dcm_module         1.00.a    dcm_0

and my c-code is simple (used on both):
#include "xparameters.h"
#include "xgpio_l.h"



int main()
{
	unsigned char ucData;	
	while(1)
	{
                // read from slide switches.
		ucData = XGpio_mGetDataReg(SWITCH BASEADDR, 1);
                // put value in LEDs
		XGpio_mSetDataReg(LEDS BASEADDR, 1, ucData);
	}	
	return 0;
}

The BASEADDR are from the headers xparameters.h in the respective
projects.

BSBs ucf file look like this:
Net sys_clk_pin LOC=T9;
Net sys_rst_pin LOC=l14;
## System level constraints
Net sys_clk_pin TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 20000 ps;
Net sys_rst_pin TIG;

## FPGA pin constraints
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<0> LOC=k12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<1> LOC=p14;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<2> LOC=l12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<3> LOC=n14;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<4> LOC=p13;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<5> LOC=n12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<6> LOC=p12;
Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<7> LOC=p11;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<0> LOC=k13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<1> LOC=k14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<2> LOC=j13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<3> LOC=j14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<4> LOC=h13;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<5> LOC=h14;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<6> LOC=g12;
Net fpga_0_DIP_Switches_8Bit_GPIO_in_pin<7> LOC=f12;

My ucf file look like this:
NET "sys_reset"  LOC = "L14"  ; 
NET "sys_clock"  LOC = "T9"  ; 
NET "Leds_GPIO_d_out<0>"  LOC = "K12"  ; 
NET "Leds_GPIO_d_out<1>"  LOC = "P14"  ; 
NET "Leds_GPIO_d_out<2>"  LOC = "L12"  ; 
NET "Leds_GPIO_d_out<3>"  LOC = "N14"  ; 
NET "Leds_GPIO_d_out<4>"  LOC = "P13"  ; 
NET "Leds_GPIO_d_out<5>"  LOC = "N12"  ; 
NET "Leds_GPIO_d_out<6>"  LOC = "P12"  ; 
NET "Leds_GPIO_d_out<7>"  LOC = "P11"  ; 
NET "Switch_GPIO_in<0>"  LOC = "F12"  ; 
NET "Switch_GPIO_in<1>"  LOC = "G12"  ; 
NET "Switch_GPIO_in<2>"  LOC = "H14"  ; 
NET "Switch_GPIO_in<3>"  LOC = "H13"  ; 
NET "Switch_GPIO_in<4>"  LOC = "J14"  ; 
NET "Switch_GPIO_in<5>"  LOC = "J13"  ; 
NET "Switch_GPIO_in<6>"  LOC = "K14"  ; 
NET "Switch_GPIO_in<7>"  LOC = "K13"  ; 

This problem is realy getting annoying, there must be something
essential I have been overlooked.



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

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

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

Custom Search