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 59675

Article: 59675
Subject: Re: Enhancing PAR with FPGA floorplanners
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Aug 2003 21:51:14 -0400
Links: << >>  << T >>  << A >>
Says who? See http://www.andraka.com/gallery.htm for examples of large designs
that use placement constraints extensively.  The key is to use hierarchy.  In
order to do so with the current tools though, you'll have to do the placement in
the bottom levels of your code, not in the floorplanner.

Anil Khanna wrote:

> Using placement constraints is okay if you are trying to meet timing on
> certain small sections of the designs AND you know if these are going to be
> the bottleneck. It is not feasible to do this if you have a big design that
> is using 90+% of the slices/LEs etc.
>

--
--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: 59676
Subject: Re: Thinking out loud about metastability
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Aug 2003 21:53:45 -0400
Links: << >>  << T >>  << A >>
Good luck even getting the structure out of the manufacturer though.  Even if you do,
I think you'll find a good part of the delay is in the clock tree. Unless that is
characterized, you probably won't be able to infer much more than what the data sheet
tells you.

Jon Elson wrote:

> Ray Andraka wrote:
>
> >Rickman et al,
> >
> >This is indeed fairly common.  The manufacturer specifies the interface timing
> >only relative to signals on that interface, not relative to the DSP clock.  This
> >often shows up on memory interfaces intended for static async RAM memory, for
> >example.  In that case, the timing is all relative to the address, write pulse
> >and data and nearly never in relation to a clock.  As Rickman points out, there
> >is no valid assumption you can make about the relationship to the DSP clock
> >other than the fact that these signals are synchronous to the clock unless it is
> >specified in the data sheet.  Where it is not, even the manufacturer can't tell
> >you what the timing is because they don't characterize it.
> >
> Well, just because the manufacturer isn't putting the info in the data
> sheets, and don't
> test for it, I suspect that you could get a rough description that could
> be quite helpful.
> Knowing, for instance, that the strobes will always follow a CPU clock
> by at least
> 1 ns, and never change than 5 nS after the clock, would make designing a
> synchronous
> memory/peripheral controller running from the same clock a lot simpler.
>
> If you can just get the roughest of descriptions of the clock vs.
> strobes circuitry, you
> can improve the system performance greatly, because you don't have to
> have ranked
> FFs on every strobe.
>
> Now, on the high speed stuff, with clock multipliers, etc. it can get
> quite complex, and
> a CPU swap to the next higher speed can throw everything off due to a
> change in clock
> multiplier.  But, I gathered from the initial post that this wasn't a
> clock multiplied CPU.
>
> Jon

--
--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: 59677
Subject: Re: TIG Constraint
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Aug 2003 21:56:25 -0400
Links: << >>  << T >>  << A >>
I have not had any success using the TIG within the HDL to date, although I have
not tried it since 4.2.

Martin Euredjian wrote:

> Sure, I could use multi-cycle in the UCF (or TIF, for that matter). For
> maintainability (and reusability) purposes I wanted to include these and
> other constraints with the HDL file.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
> "Anil Khanna" <anil_khanna@mentor.com> wrote in message
> news:3f4a72c4$1@solnews.wv.mentorg.com...
> > Hi Martin,
> >
> > TIG should work, if not, you could always try a MCP (multicycle path
> > constraint) if you know how many times your data is sampled.
> >
> > Anil
> >
> > "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
> > message news:3f49e539@dnews.tpgi.com.au...
> > > Martin Euredjian wrote:
> > > > The constraint guide indicates that the TIG constraint can be used in
> > HDL
> > > > (Verilog in my current design).  However, an attempt to use it
> produces
> > the
> > > > following error:
> > > >
> > > > ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in
> BEGIN
> > > > MODEL/END section in the XCF file, nor in HDL code.
> > > >
> > > > I have not been able to find further information on this error message
> > or
> > > > issue in the Xilinx site.  Does anyone know if TIG is truly supported
> in
> > > > HDL?  I'd hate to place it in the UCF file, to me it feels much more
> > > > approprite to have this constraint move with the HDL source.
> > > >
> > > > The form I'm using is:
> > > >
> > > > // synthesis attribute TIG of <net_name> is "";
> > > >
> > > > As a point of interest, the nets in question are the output of the
> > registers
> > > > of a microprocessor interface.  The values are only sampled a few
> times
> > per
> > > > second by the receiving module.  There is not need to have any of
> these
> > nets
> > > > meet nanosecond level timing constraints as other parts of the design
> > must.
> > > > Is there a better approach than "TIG"?
> > >
> > > Hi Martin,
> > >
> > > I think this old thread answers your question:
> > >
> >
> http://groups.google.com/groups?threadm=3dbd0daa%241_1%40lon-news.intensive.
> > net
> > >
> > > Regards,
> > > Allan.
> > >
> >
> >

--
--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: 59678
Subject: Re: Is a Virtex-II Pro family a hands-down winner for DSP ?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Aug 2003 22:07:17 -0400
Links: << >>  << T >>  << A >>
The M512 has a much coarser granularity, and is not nearly as localized as the SRL16's in
Xilinx.  This becomes very apparent with reloadable DA filters, as the size of the M512
makes for a less than optimum DA lut.  In any event, to get the most from any given
architecture, you have to design to the architecture, hence my comment about staying in
whatever you are comfortable with.


Peter Sommerfeld wrote:

> I haven't used Xilinx parts so I don't know how an SRL is more
> reconfigurable than the Stratix's TriMatrix memories (ie M512, etc).
> Using a dual-port M512 in a design means I can use it as LUT and
> simultaneously reconfigure in through the other port. Why are you
> saying the SRL is the only reloadable LUT out there?
>
> -- Pete

--
--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: 59679
Subject: Re: two questions
From: Ray Andraka <ray@andraka.com>
Date: Mon, 25 Aug 2003 22:20:24 -0400
Links: << >>  << T >>  << A >>
Or, you can use the fast carry chain for the and.  The luts are (i0 xnor i1) and
(i2 xnor i3).  Lut outputs feed into the muxcy sel inputs, muxcy di<='0' and ci
comes from previous muxcy co.  First muxcy ci<='1', then your equality compare
comes out of the last muxcy.  Works out faster once you go over about 20 bit
inputs.

rickman wrote:

> zhengyu wrote:
> >
> > I've got two quick question. I don't have FPGA yet, but I want someone to
> > offer me some quick comments
> >
> > 1. I have got to do some 64 bit integer comparison, actually I have to do up
> > to 64 comparisons at the same time, the output is whether there is any pair
> > that equals.
>
> This is not a question... :)
>
> Equality compares are easy.  It uses a two input XOR for each bit with
> all the results being OR'd together.  This will take 32 LUTs for the XOR
> and the first OR gate and 11 more LUTs to combine the rest for a total
> of 43 LUTs in four levels.  If the design uses the "special" features
> that most chips have (ORing of LUTs within a CLB), you can use the LUTs
> in pairs or even groups of four and reduce the number of levels for
> speed.
>
> > 2. If I want to create an 16 bit address space, that would translate to 512
> > k bits, does Vertex II give enough
> > block RAM so I don't have to use SRAM to do that? What kind of latency
> > performance should I expect from
> > typical SRAM, is 5ns read access reasonable?? what is the performance of
> > block ram??
>
> Is that 16 bit address (64k words) of 8 bit words?  Because 64k x 8 =
> 512K.
>
> You can get this much RAM in the VirtexII if you use the XC2V500 part.
> Or in the new Spartan3 you could use a XC3S1500.  I am not sure which
> will be cheaper, but I bet it is the Spartan3.
>
> The speed of the block RAM will be much faster than anything external to
> the FPGA.  The block ram will be synchronous and lends itself well to
> pipelined operations.
>
> A lot of how you design will be implemented will depend on your data
> flow which you have said nothing about.  Think about how the storage
> will be orgainized and accessed.  Obviously one large block of memory
> with one interface will not let you do 64 compares at one time.  If you
> rate of performing these compares is not fast, you can use one compare
> logic block and run the different data through it sequentially.  Then
> one memory could easily do the job.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

--
--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: 59680
Subject: Re: Enhancing PAR with FPGA floorplanners
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 26 Aug 2003 13:19:47 +1000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> Says who? See http://www.andraka.com/gallery.htm for examples of large designs
> that use placement constraints extensively.  The key is to use hierarchy.  In
> order to do so with the current tools though, you'll have to do the placement in
> the bottom levels of your code, not in the floorplanner.

Send them to the Guggenheim next time they're having a De Stijl exhibition.

http://www.artlex.com/ArtLex/d/destijl.html

Cheers,
Allan.


> Anil Khanna wrote:
> 
> 
>>Using placement constraints is okay if you are trying to meet timing on
>>certain small sections of the designs AND you know if these are going to be
>>the bottleneck. It is not feasible to do this if you have a big design that
>>is using 90+% of the slices/LEs etc.
>>
> 
> 
> --
> --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: 59681
Subject: Re: Enhancing PAR with FPGA floorplanners
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Tue, 26 Aug 2003 04:28:44 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
 
> Says who? See http://www.andraka.com/gallery.htm for examples of large designs
> that use placement constraints extensively.  The key is to use hierarchy.  In
> order to do so with the current tools though, you'll have to do the placement in
> the bottom levels of your code, not in the floorplanner.

Ray's impressive designs are mostly regular structures, mostly data
path.  Placement in the bottom levels of code works well for such
designs.  When the critical paths are in complex control logic, such
placement isn't a realistic alternative.  Other techniques are more
useful.  FPGA designs are not all the same sorts of things.  Different
requirements lead to different usages of the parts and the tools.


-- 
Phil Hays

Article: 59682
Subject: Re: Enhancing PAR with FPGA floorplanners
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 26 Aug 2003 04:51:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F4AE286.80E9CAE4@attbi.com>,
Phil Hays  <SpamPostmaster@attbi.com> wrote:

>Ray's impressive designs are mostly regular structures, mostly data
>path.  Placement in the bottom levels of code works well for such
>designs.  When the critical paths are in complex control logic, such
>placement isn't a realistic alternative.  Other techniques are more
>useful.  FPGA designs are not all the same sorts of things.  Different
>requirements lead to different usages of the parts and the tools.

However, the complex-control-logic hairballs are what simulated
annealing and related FPGA placement algorithms are designed to do
best.  A common (and effective) technique is to hand-place the regular
datapath, and then let the placement tool arrange the control logic
around the periphery.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 59683
Subject: Re: [ann] Microblaze uClinux Demo released
From: antti@case2000.com (Antti Lukats)
Date: 25 Aug 2003 22:51:54 -0700
Links: << >>  << T >>  << A >>
[mbvanilla on ml300 with linux image.bin?]
> It will indeed work - the demo bit file is just mbvanilla targetting the 
> V2MB1000.  Just make sure you keep the address map the same, eg the 
> location of your main RAM bank, which the kernel expects to find at 
> 0x80000000, for 16 Mb.  Also the bootloader expects there to be 
> AMD-style flash at 0xFF000000.  The source of the bootloader comes with 
> the mbvanilla project so you should have no trouble changing that if 
> necessary.

ml300 has (lots of things) +
DDR RAM (no FLASH)
it is possible to preload the RAM from compact flash, so there is no
need for flash, and if the linux image expects to see the flash its
a problem :( I really would not like to write a ip core that 'emulates'
the non existing flash

I have looked at mb ulinux several times, but while working on w2k
workstation it looks very complicated to get all the things to compile.

antti
PS I also have memec board with S2 600E and comm160 module there it
would possible be easier to get the mbvanilla and image.bin to work.

but,,, the flash on p160comm is not AMD?

Article: 59684
(removed)


Article: 59685
Subject: Re: Which Adder?
From: "sanjay" <sanjay@cg-coreel.com>
Date: Tue, 26 Aug 2003 11:24:02 +0530
Links: << >>  << T >>  << A >>
Hi,
As Ray said, it actually implements 2-bit Carry Look Ahead per slice.
Definitely, you can implement any other adder which is of interest to you
using LUTs.
Pls. go to Xilinx Project Navigator => Help => Online Documentation =>XST
User Guide => HDL Coding Techniques to find various signed and Unsigned
Adder Implementation.

Regards,
Sanjay

"Ray Andraka" <ray@andraka.com> wrote in message
news:3F4A8912.FCFFC489@andraka.com...
> It infers a ripple carry adder using the fast carry chains.  The FPGAs
> have special logic for implementing fast ripple carry (they actually do a
> 2 bit carry look-ahead in hardware, but that is invisible to the user).
> Other carry schemes are forced to use the much slower general purpose
> routing and logic.  In most cases, the adder built using the fast carry
> chains is not only the minimum area, it is also the maximum performance.
>
> Nagaraj wrote:
>
> > Hi all,
> >    I am using XST (ISE 5.1i sp3) for my logic synthesis. If I write a
> > piece of VHDL code as in " c <= a + b ", an N-bit adder will be
> > inferred (assuming a,b,c are N bits).
> >    As there are many types of adder algorithms/implementations
> > available (like Carry Look Ahead, Carry Save etc.), I want to know
> > which one does XST infer? Can I have a control over the type of adder
> > ?
> >
> > Regards,
> > Nagaraj
>
> --
> --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: 59686
Subject: FPGA minimum operating frequencies
From: nitin@tenet.res.in (Nitin Chandrachoodan)
Date: 25 Aug 2003 23:21:45 -0700
Links: << >>  << T >>  << A >>
Hello,

I was wondering if there were any *lower* limits on the clock
frequency that can be used to clock FPGAs (in particular the Xilinx
Virtex II : XC2V3000). I know there are certain kinds of high speed
logic families using precharge-discharge operation, where the leakage
sets a lower limit on operating speed. Is there such a limit for these
FPGAs, and if so, what is it (ballpark figures are fine).

Thanks,

Nitin

Article: 59687
Subject: Re: [ann] Microblaze uClinux Demo released
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 26 Aug 2003 16:27:11 +1000
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> [mbvanilla on ml300 with linux image.bin?]
> 
>>It will indeed work - the demo bit file is just mbvanilla targetting the 
>>V2MB1000.  Just make sure you keep the address map the same, eg the 
>>location of your main RAM bank, which the kernel expects to find at 
>>0x80000000, for 16 Mb.  Also the bootloader expects there to be 
>>AMD-style flash at 0xFF000000.  The source of the bootloader comes with 
>>the mbvanilla project so you should have no trouble changing that if 
>>necessary.
> 
> 
> ml300 has (lots of things) +
> DDR RAM (no FLASH)
> it is possible to preload the RAM from compact flash, so there is no
> need for flash, and if the linux image expects to see the flash its
> a problem :( 

Yes that should be fine.  You should could pre-load the ram from CF, 
then jump immediately to 0x80000000, skipping the bootloader entirely.

> I really would not like to write a ip core that 'emulates'
> the non existing flash

Well it's just a Xilinx ext . mem controller core, nothing fancy there, 
but I get your point :)

> I have looked at mb ulinux several times, but while working on w2k
> workstation it looks very complicated to get all the things to compile.

yeah.. building linux kernels under cygwin is not for the faint hearted!

> 
> antti
> PS I also have memec board with S2 600E and comm160 module there it
> would possible be easier to get the mbvanilla and image.bin to work.

That would be cool, haven't heard of anyone running uclinux on a spartan 
yet.

> but,,, the flash on p160comm is not AMD?

Correct, I think it's from Toshiba, but it implements the AMD command set.

In recent progress (ie 20 minutes ago!), I just succesfully mounted a 
JFFS2 file system on the flash, so now microblaze uclinux supports 
wear-levelling flash-based persistent storage...

next step is getting the xilinx ethernet mac working and integrated into 
mbvanilla, then see what sort of a job montavista did on the linux 
driver for it...

Regards,

John


Article: 59688
Subject: Re: [ann] Microblaze uClinux Demo released
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 26 Aug 2003 16:40:22 +1000
Links: << >>  << T >>  << A >>
John Williams wrote:
> Antti Lukats wrote:
> 
>> [mbvanilla on ml300 with linux image.bin?]
>>
>>> It will indeed work - the demo bit file is just mbvanilla targetting 
>>> the V2MB1000.  Just make sure you keep the address map the same, eg 
>>> the location of your main RAM bank, which the kernel expects to find 
>>> at 0x80000000, for 16 Mb.  Also the bootloader expects there to be 
>>> AMD-style flash at 0xFF000000.  The source of the bootloader comes 
>>> with the mbvanilla project so you should have no trouble changing 
>>> that if necessary.
>>
>>
>>
>> ml300 has (lots of things) +
>> DDR RAM (no FLASH)
>> it is possible to preload the RAM from compact flash, so there is no
>> need for flash, and if the linux image expects to see the flash its
>> a problem :( 
> 
> 
> Yes that should be fine.  You should could pre-load the ram from CF, 
> then jump immediately to 0x80000000, skipping the bootloader entirely.

Oh one problem with this approach, the demo kernel image includes the 
MTD flash drivers, and they will be expecting to see some flash at 
0xff000000.  Shouldn't be fatal, you might just get some complaints when 
it  boots up.

I'm happy to make a custom image for you to play with, just tell me how 
you want it configured.  It only takes a few minutes.

Regards,

John


Article: 59689
Subject: Re: Enhancing PAR with FPGA floorplanners
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 26 Aug 2003 07:01:51 -0000
Links: << >>  << T >>  << A >>
>However, the complex-control-logic hairballs are what simulated
>annealing and related FPGA placement algorithms are designed to do
>best.  A common (and effective) technique is to hand-place the regular
>datapath, and then let the placement tool arrange the control logic
>around the periphery.

How good is the current software?

Many years ago, I could, do a manual placement and automatic routing
if far less time than the P&R tools took to do the whole job.

My "complex-control-logic hairballs" were generally pretty simple,
mostly one-hot state machines.  Maybe some pipelining to help.
(They probably have to be simple if you are going to co-exist with
a well planned data path.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 59690
Subject: Re: Why can't Xilinx DCM's regain lock without a RESET??
From: "Håkon Lislebø" <hakon.lislebo@ericsson.no>
Date: Tue, 26 Aug 2003 09:10:25 +0200
Links: << >>  << T >>  << A >>
Hi Austin,

Yes, you could make an edge detect which generates a reset pulse. I tried
it. But if the clock is lost the reset pulse will go away long before the
clock is back and then the DCM needs another reset. That reset will off
course come when CLK_LOS goes off, but I can not trust the CLK_LOS because
the open clk input picks up signal from another clock (BLVDS) and will often
indicate that a clock is present. An auto reset for my applications take som
FF's (shift register, delay to wait for lock signal after reset) and gates.
Multiply that with four DCM's and suddenly a small Virtex-II is gotten even
smaller. Off course you cannot cover all situations, and my telecom
application is a little bit demanding. It is just that an Auto-Lock would
have fit in so nicely!  Yes, squeese that feature into the next  -
Virtex-III?

Hakon


"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F4A1E0C.47FC0DE4@xilinx.com...
> Hakon,
>
> How about an OR gate of the status bits indicating a failure to a flip
> flop that genreates a one clock long reset pulse?
>
> Lots of logic? three gates and a FF or two?
>
> The 'Auto-Lock' suggestion is a good one.  We will keep that in mind.
>
> Austin



Article: 59691
Subject: Re: Thinking out loud about metastability
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 26 Aug 2003 07:13:55 -0000
Links: << >>  << T >>  << A >>
>As long as the voting circuit output is consistant LOW or HIGH, it
>doesn't really matter, at least in the context given.  If the voting
>circuit output is metastable, then thats problematic.

Everything I know about metastability says that looking for things
like voting circuits is barking up the wrong tree.  If anybody has
a good example of some "fix", "kludge" or "hack" that actually works,
please tell me/us and explain why.

We all agree that waiting longer helps.  Right?  (Helps lots!)

Consider a voting circuit.  It adds a few gates between the first
bank of 3 FFs and the next FF that captures the output of the voting
logic.  Compare that with the clean/simple case of FF-FF with minimal
routing delays.  The delay through the gates is working against an
exponential in increased settling time.

Even if the normal no-logic path used a LUT so the voting logic is free,
there is still the extra delay of routing from nearby FFs over to the
LUT.  (The other two FFs won't be quite so close.)

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 59692
Subject: How to listen to music through an FPGA pin?
From: "Jean Nicolle" <j.nicolle@sbcglobal.net>
Date: Tue, 26 Aug 2003 08:07:57 GMT
Links: << >>  << T >>  << A >>
my manager said it couldn't be done. So just to prove him wrong :-)
http://www.fpga4fun.com/PWM_DAC.html

Well, pretty simple stuff anyway.
Have fun.
Jean



Article: 59693
Subject: Re: FPGA minimum operating frequencies
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Tue, 26 Aug 2003 10:46:30 +0200
Links: << >>  << T >>  << A >>
Nitin Chandrachoodan wrote:

> Hello,
> 
> I was wondering if there were any *lower* limits on the clock
> frequency that can be used to clock FPGAs (in particular the Xilinx
> Virtex II : XC2V3000). I know there are certain kinds of high speed
> logic families using precharge-discharge operation, where the leakage
> sets a lower limit on operating speed. Is there such a limit for these
> FPGAs, and if so, what is it (ballpark figures are fine).

All FPGAs (including Virtex II) and other programmable logic devices 
I know about are static devices. That is, all FlipFlops inside are 
complete static ones suitable for a clock from 0 to Fmax. 
Even more, there is no clock required at all.

However, some FPGAs might contain special units that could require a 
minimum clock. The DCMs of the Virtex II are such an example. 
But when you do not need them, it's no matter at all...

Regards,
Mario 

Article: 59694
Subject: Re: Two near-identicial clocks?
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Tue, 26 Aug 2003 11:00:19 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> If you have to cope with frequency differences ( not just unknown phase
> ), then a FIFO is your only choice. And you have to have a strategy for
> FIFO overflow/underflow, which will inevitably happen.

Exactly. And this requires as well that you (Eric) need some kind 
of a handshaking signal that tells the source when the FiFo is full
(or almost full) and it needs to stop transferring more data therefore.

Alternatively you might remove data at the receiver at a rate always 
(guaranteed) higher than the source rate. There you need a trivial 
FiFo with a depth of 1 (i.e. just a register).

Regards,
Mario


Article: 59695
Subject: Re: FPGA minimum operating frequencies
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Tue, 26 Aug 2003 19:03:59 +1000
Links: << >>  << T >>  << A >>
Nitin Chandrachoodan wrote:
> Hello,
> 
> I was wondering if there were any *lower* limits on the clock
> frequency that can be used to clock FPGAs (in particular the Xilinx
> Virtex II : XC2V3000). I know there are certain kinds of high speed
> logic families using precharge-discharge operation, where the leakage
> sets a lower limit on operating speed. Is there such a limit for these
> FPGAs, and if so, what is it (ballpark figures are fine).

Most of the internal logic is (or gives the appearance of being) static.

The DLLs and PLLs are an obvious exception.  As long as you don't use a 
DLL or PLL, you can quite happily clock your logic all the way down to 0Hz.

I do recall that one of the older families (Xilinx 4000e?) had a maximum 
active time for one of the strobes on a CLB ram, which would limit the 
lowest operating frequency.  I think that might have been a bug, and it 
has been fixed in more modern parts.

Regards,
Allan.


Article: 59696
Subject: Re: Altera ACEX 1K IOE
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Aug 2003 10:06:19 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> I am working with the ACEX 1K30 and I don't understand the structure of
> the IOE.  The diagram clearly shows three FFs; data input, data output
> and output enable.  The three FFs even have different types of
> connections to the routing.  But in the text, they seem to be saying
> that there is only a single FF in the IOE.  
> 
> Is there really only one FF in the IOE so that it can be either input or
> output?  Is the OE FF always in an LE rather than the IOE?  Seems like
> this would make for some trouble getting the timing in tight
> situations.  
> 

Yeah - been there, done that - I had great fun making a 10KE do a 100MHz
SDRAM interface meet timing, due to the single flipflop :-(  Someone once
described the 10KE datasheet to me as "less than totally transparent" or
some such.  

The other gotcha is the implication that there is an asynch
preset on the FF - in the text it then describes that the P&R software
will automatically put an invertor fore and aft of the FF and use the
async reset input (that does exist).  Making a bit of a hash of your
tco as a a result :-(  

I was not a happy bunny that day, and from that day forward have made
a point of not looking at Altera's diagrams only reading the text...

Commiserations :-(

Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 59697
Subject: Multi-clock / clocking counter
From: Jay <se10110@yahoo.com>
Date: Tue, 26 Aug 2003 04:11:51 -0500
Links: << >>  << T >>  << A >>
Hello all,

I have a slightly interesting problem here, and I wanted to know if my 
approach has any hazards which I should be aware of. My design is for a 
CPLD, if that matters.

I have a binary synchronous counter, I call Master_Counter, that I want 
to clock at 312.5kHz (1/128th my system clock of 40MHz). I generate my 
1/128 Prescale_CLK by picking off the MSB of a 7-bit counter which is 
clocked at Sys_CLK frequency(40MHz).

In my design, Master_Counter usage is multiplexed -- it will be used to 
time four separate signals (which are synchronous to the 40MHz Sys_CLK) 
all 26kHz or below. To be able to select which signal is timed, I route 
my 4 signals into a 4:1 MUX.

My current approach is to use Prescale_CLK to gate the ENABLE on the 
counter, with Master_Counter getting clocked from the 40MHz Sys_CLK. 

Since I need to time one of the four signals, I am actually ANDing the 
output of the 4:1 MUX with the Prescale_CLK and that feeds the ENABLE 
pin on Master_Counter.

From reading the c.a.fpga archives, I *think* this is the correct 
approach since I've read the CLK input itself should never be gated, 
only the ENABLE but I would appreciate any commentary.

My other problem is dealing with reset/clear logic which could get 
complicated, since I need to make sure the counter is reset/ENABLED 
properly when the MUX is switched (which occurs asynchronous to the four 
signals). I have seen Mr. Alfke's circuit that allows you to switch 
asynchronous clocks, I'll look at that again for ideas.

As usual, thanks!

-- Jay.











Article: 59698
Subject: Re: Two near-identicial clocks?
From: Erik Spaenig <erik.spaenigREMOVE@seitzinger-popp.de>
Date: Tue, 26 Aug 2003 12:38:04 +0200
Links: << >>  << T >>  << A >>
Hi,

Mario Trams wrote:
> Alternatively you might remove data at the receiver at a rate always
> (guaranteed) higher than the source rate. There you need a trivial
> FiFo with a depth of 1 (i.e. just a register).

the FiFo-depth of 1 is only enough if the read-speed the double (or faster)
when the write speed. If you have only a littel bit more than you need a 
FiFo-depth of 2 or 3 (se the double/tribble-buffering on videoprojektors that 
translate 50Hz input-framrate (europa-PAL) into 60Hz LCD-framerate).

@Eric :
how long is an incomming datapacket an how long the delay (for addressing and
others) between the datapackets ??
how big is the diferenz between the clocks ?? (more than 1%)
if you have both answers you can calculate the needet FiFo-depth (+1 for savety)

in my projekt i use 3 buffers(registers) with its own statemaschine in serias
for this problem, if you are interisted on my code then mailto:vikinger@uni.de

Regards,
Erik

--
sorry for my terible english, my favorit language is assembler

Article: 59699
Subject: Re: Two near-identicial clocks?
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Tue, 26 Aug 2003 13:47:07 +0200
Links: << >>  << T >>  << A >>
Erik Spaenig wrote:

> Hi,
> 
> Mario Trams wrote:
>> Alternatively you might remove data at the receiver at a rate always
>> (guaranteed) higher than the source rate. There you need a trivial
>> FiFo with a depth of 1 (i.e. just a register).
> 
> the FiFo-depth of 1 is only enough if the read-speed the double (or
> faster) when the write speed. If you have only a littel bit more than you
> need a FiFo-depth of 2 or 3 (se the double/tribble-buffering on
> videoprojektors that translate 50Hz input-framrate (europa-PAL) into 60Hz
> LCD-framerate).

Ok, I agree that a depth of 2 is desired due to practical issues.

Thanks,
Mario



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