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 108300

Article: 108300
Subject: Re: Performance Appraisals
From: "Homer J Simpson" <nobody@nowhere.com>
Date: Thu, 07 Sep 2006 19:52:58 GMT
Links: << >>  << T >>  << A >>

"Michael A. Terrell" <mike.terrell@earthlink.net> wrote in message 
news:44FF8FE2.C059168A@earthlink.net...

>   Too bad he didn't get hit by a truck when he was leaving. ;-)

One very mean trick is to praise the prick everywhere you go and wait for 
him to make a jump after the head-hunters get to him. Then the new boss 
finds out what a POS he is and fires him




Article: 108301
Subject: Re: Qestion about the ability of synthesis
From: "radarman" <jshamlet@gmail.com>
Date: 7 Sep 2006 12:54:20 -0700
Links: << >>  << T >>  << A >>

David Ashley wrote:
> >>>a 8 bit "=" needs at maximum 7 AND2 and 7 INV not 15 XOR2. And of course
> >
> >
> > This threw me for a bit, then I realized you're comparing
> > 8 bits with a constant value, not two 8 bit registers.
>
> Actually wouldn't you need 7 AND2 and 8 INV if you're comparing to 0?
>
> -Dave
>
>
> --
> David Ashley                http://www.xdr.com/dash
> Embedded linux, device drivers, system architecture

If you are comparing your 8-bit count value to a constant, it can be
handled in two levels of logic. Remember, you don't use up an input
when you are comparing with a constant, the constant becomes part of
the truth table, so you use all four inputs for the counter input. This
is why it is preferable to (pre)load an up/down counter, and compare
against a constant to reload/stop generate a terminal count signal.

There are times when you have to compare the counter with a register,
but they are fairly rare in my experience. Typically, you can avoid the
vast majority of these cases with careful design.


Article: 108302
Subject: Re: Altera CPLD 7128S heating up
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 07 Sep 2006 20:54:51 +0100
Links: << >>  << T >>  << A >>
On Thu, 07 Sep 2006 21:34:54 +0200, jean-francois hasson
<jfhasson@club-internet.fr> wrote:

>I work on a board with an Altera 7128S part (5V quite old but still used 
>...). It seems the part is most of the time working just fine but 
>depending on when it is powered on it overheats a lot and does not seem 
>to be well configured : an input acts as an output, and the component is 
>not working fine at all. Does anyone havea clue as to what could be 
>going wrong ? It does not happen all the time.

This sounds suspiciously like latch-up caused by a power sequencing
problem; typically, +5V or some other power rail applied to a device's
input before the device itself has been powered-up.  This can easily
happen if you have voltage level-shifters on the CPLD's input, taking
an external 12V or 24V signal and dropping it to 5V for the device.
It can also happen if you have multiple interconnected PCBs with
separate power to each.

The problem can often be solved by adding current limiting resistors
in series with each susceptible input.  Keep the worst-case input 
current below about 1mA and you should be safe. These
resistors will restrict the input bandwidth, but otherwise should
cause no trouble.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 108303
Subject: Re: Altera CPLD 7128S heating up
From: "dscolson@rcn.com" <dscolson@rcn.com>
Date: 7 Sep 2006 12:57:47 -0700
Links: << >>  << T >>  << A >>

jean-francois hasson wrote:
> Hi,
>
> I work on a board with an Altera 7128S part (5V quite old but still used
> ...). It seems the part is most of the time working just fine but
> depending on when it is powered on it overheats a lot and does not seem
> to be well configured : an input acts as an output, and the component is
> not working fine at all. Does anyone havea clue as to what could be
> going wrong ? It does not happen all the time.
>
> Thanks,
>
> JF

Does this part have JTAG, and if so does it have the TRST pin? I had a
lot of trouble with an Actel ProAsic device and the JTAG boundry scan.
I finally had to tie the TRST pin low to keep it out of the boundry
scan mode. Also check that your rise time on your VCC is within limits
for the part.


Article: 108304
Subject: Re: Altera CPLD 7128S heating up
From: "dscolson@rcn.com" <dscolson@rcn.com>
Date: 7 Sep 2006 12:57:51 -0700
Links: << >>  << T >>  << A >>

jean-francois hasson wrote:
> Hi,
>
> I work on a board with an Altera 7128S part (5V quite old but still used
> ...). It seems the part is most of the time working just fine but
> depending on when it is powered on it overheats a lot and does not seem
> to be well configured : an input acts as an output, and the component is
> not working fine at all. Does anyone havea clue as to what could be
> going wrong ? It does not happen all the time.
>
> Thanks,
>
> JF

Does this part have JTAG, and if so does it have the TRST pin? I had a
lot of trouble with an Actel ProAsic device and the JTAG boundry scan.
I finally had to tie the TRST pin low to keep it out of the boundry
scan mode. Also check that your rise time on your VCC is within limits
for the part.


Article: 108305
Subject: Re: Synchronous Clocks
From: "Gabor" <gabor@alacron.com>
Date: 7 Sep 2006 13:11:03 -0700
Links: << >>  << T >>  << A >>
zohair wrote:
> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?

Normally you can use FROM :TO style of timing constraints to inform the
tools of the required time from active edge of one clock to another.
If you have signals crossing the clock boundaries in both directions
you would need two FROM : TO timing specs.  If in addition you use more
than one edge of the clocks you may need more specs.

example:
NET "x1_clock" TNM_NET = "x1_clock";
NET "x2_clock" TNM_NET = "x2_clock";
TIMESPEC "TS_1x_2x" = FROM "x1_clock" TO "x2_clock" 1.75 ns;
TIMESPEC "TS_2x_1x" = FROM "x2_clock" TO "x1_clock" 2.75 ns;

That being said, if the clocks are generated on chip, for example using
DCM's, the tools will automatically generate the required timing specs
based on the PERIOD time spec of the source clock.

HTH,
Gabor


Article: 108306
Subject: Re: Synchronous Clocks
From: "radarman" <jshamlet@gmail.com>
Date: 7 Sep 2006 13:25:51 -0700
Links: << >>  << T >>  << A >>
zohair wrote:
> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?

What do you mean by synchronous? Typically, this means you derived one
clock from the other, or both clocks from a master oscillator.

Unfortunately, you still can't consider the resulting clocks
"synchronous" anymore. They may be frequency locked, but you can't
guarantee phase lock without careful design analysis. You can generally
clean up the situation with careful use of DCM's, but even then, use
care when crossing boundaries.

I have seen a lot of designs fail due to improper treatment of clocks.
As a result, I treat every boundary crossing as asynchronous, and tweak
the crossing logic based on the measured phase relationship between the
clocks.


Article: 108307
Subject: Re: ddr with multiple users
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 7 Sep 2006 23:11:20 +0200
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> Seems to me that your second idea would involve each device
> having a complete DDR access controller in it.  That sounds 
> like quite a bad idea to me; if you're going to make good use 
> of SDRAM you need to keep track of the RAM's internal state
> to some extent (which banks are active, current row address,
> that sort of thing) and it would be very difficult for all four
> accessors to keep that kind of internal state in step.
> 
> Of course, passing each client's requests to the RAM 
> controller is sure to cost some latency if you use a common
> controller.  If you have a custom controller (rather than a 
> standard single-port controller on a common bus) then you
> can hide most of that latency in the arbitration delay, at the
> expense of some extra complexity.
> 
> It's an interesting question, though.  I need to deal with
> something quite similar in the immediate future, so any
> other ideas would be gratefully received!  Oh, and does
> anyone have any strong opinions (positive or negative)
> about any of the available open-source DDR controllers?

No matter what happens, 4 separate widgets need to gain
access to memory. If they have to interface to some other
controller anyway, what's the advantage? Why not make the
DDR itself the controller?

For example wishbone, the idea behind replacing DDR's own
interface with a wishbone in-between would be based on
assertions that
1) DDR is overly complex, wishbone's simpler
2) IP core reuse -- wishbone is more standard

I *need* to be able to burst large blocks of memory to the
DDR. If I use a wishbone interface, then there needs to
be some mechanism to translate a burst from one
clock domain (the wishbone's) to the DDR's clock
domain. That might involve some sort of fifo...and sounds
complicated to me.

On the other hand the DDR controller is actually not that
complicated. Using DDR itself would allow known, easy
burst accesses, and memory bandwidth can be maximized.

Regarding the DDR's internal state, I'm planning on all
widgets doing burst accesses, and each access would only
be to a single row. If each widget just precharged the row
upon exit, the overhead would be minimal, yet bandwidth
would still be good.

Finally, if a refresh cycle needs to be imposed, that can be
done with a 5th widget that just does a refresh cycle, or it
could be a function of the arbitrator itself.

-Dave

-- 
David Ashley                http://www.xdr.com/dash
Embedded linux, device drivers, system architecture

Article: 108308
Subject: Managing small IP library
From: "avishay" <avishorp@yahoo.com>
Date: 7 Sep 2006 14:17:02 -0700
Links: << >>  << T >>  << A >>
Hi everyone,
A few months ago, I have started working in a small group which designs
FPGAs for video application. By the nature of this application, there
is a collection of building blocks that are repeatedly being used in
our designs. Currently, the knowledge about cores available and how to
use them is kept by each designer, so if I need a core from someone I
have to ask him to send it to me by e-mail. Certainly, this model is
very problematic causing the same cores to be designed again and again
by different engineers.
I would like to suggest my managers a better way to share this valuable
data between the engineers, and I'm looking for a solution that will
provide:

* Integration with a source control system (sadly, SourceSafe is being
used in my company, so
I'm binded to that awful tool)
* A catalog of available cores
* An easy way to add new cores and to update existing ones
* A structured way to minimally document the core (functionality,
interface)
* Integration with design tools (Quartus, HDL Designer, Synplify...)

I would appreciate if anyone can give me an idea if such tools exist on
the market, or to let me know how such task is being handled in other
companies.

Thanks,
Avishay


Article: 108309
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: "radarman" <jshamlet@gmail.com>
Date: 7 Sep 2006 14:28:58 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
> Peter Alfke schrieb:
>
> > jacko wrote:
> > >>
> > > pin compatability is just customer support, how about a 1 pin high
> > > implies a self program from a small hardwired rom, which gets enough of
> > > the chip off the ground, to work as a programmer for itself and others.
> > >
> > >
> > We have had that since the beginning, 20 years ago.
> > It is called "Master Mode Configuration"
> >
> > Peter Alfke, Xilinx
>
> no - I think this is more like one of my past "idea for xilinx"
>
> FPGA has built in hardware loader for __small__ rom. this rom contains
> the logic to implement the actual loader, be it compact flash or nand
> or
> whatever. easily doable. just make a small part of the FPGA to become
> alive first. allowing the rest of the FPGA to be configured from the
> 'bootstrap ipcore'.
>
> nobody is doing it - but without that, the RAM nased FPGA configuration
> solutions are still kinda PITA.
>
> sure as Xilinx is now bringing back the parallel flash solutions from
> XC2K
> into S3E and Virtex-5 it becomes better, but the bootstrap idea would
> still be the kicker!
>
> Antti


This is way off-topic, but I would like to expand on Antti's comment.

I'm planning on using my S3E sample pack board in this way. The FPGA
will be configured from the end of memory, while the software for the
embedded processor runs from the beginning of memory. The supplied
FLASH memory can easily handle both the configuration and the program.
The nice part of this configuration is that I don't need to waste
resources on a an internal BRAM based ROM in my design, and can use all
the BRAM's for RAM.

It would be nice, however; if the ability to boot from a NOR flash
could be expanded to NAND flash. Since many applications already
include a large NAND flash memory, this would allow you to use higher
density memories, while still dumping the separate configuration
memory. I realize that normal NAND flash is a bit more complex to
access, but there are now several vendors that supply NAND flash
memories that automatically make the first page readable in a
pseudo-microprocessor mode, and for the same reason - to allow a
processor to bootstrap from flash without a separate BIOS ROM.

Even if there was a requirement to use a NAND flash that auto-accessed
the first page, it  would be a nice improvement.


Article: 108310
Subject: Re: ddr with multiple users
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 07 Sep 2006 21:56:03 GMT
Links: << >>  << T >>  << A >>
David Ashley <dash@nowhere.net.dont.email.me> wrote:

>Hi,
>
>I have about 4 different independent things that each need to access
>a ddr.
>
>On one hand it seems I can make them all wishbone
>compliant then just have a wishbone ddr interface.
>
>Would be workable/advisable to instead just have each device
>control the ddr itself, and use the ddr's own interface directly?

I have created something similar. I created a fifo in a block ram
which is used to source or sink data to or from the ddr memory from
and to multiple devices at different speeds. In my application I need
to write or read large bursts of data so I created a fifo which can
work only one direction at a time. I use interleaved fixed burst sizes
of 8 (16 bits per DQ line in one transaction) so the overhead is
minimal.

You might want to look into some sort of caching scheme anyway because
accessing ddr to read or write just one address is dead slow.

>I'd only need one complicated mechanism to initialize the ddr
>after reset, but from then on each of the user processes can just
>request access to the ddr, and when granted just take over
>the lines.

I created a hook into the ddr statemachine which allows me to execute
any type of 'instruction' on the ddr memory from a microcontroller.
This reduces initialisation to a software thing. Don't forget about
refresh.

>One concern is that ddr timing at 100 mhz is pretty tight. Having
>the logic to combine 4 different sources into control signals for
>the ddr might add too much overhead. Of course it can be

You can run the DDR controller at 50MHz (half the ddr memory clock)
which relaxes the timing for the address and control signals a lot
(also good for meeting EMC limits because the drive strength can be
reduced and the signals carry lower frequencies). The only line that
actually needs tight timing is CS. Fortunately, this is the least
loaded line in large multi-chip memory setups. 

The data lines are a different story. Using a clock with a fixed delay
(in my case 90 degrees is just fine) to capture the data gives more
than enough margin.

As you can read, I didn't use the MIG tool (doesn't work for a
Spartan3/200).

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108311
Subject: Re: Synchronous Clocks
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 07 Sep 2006 21:58:20 GMT
Links: << >>  << T >>  << A >>
"radarman" <jshamlet@gmail.com> wrote:

>zohair wrote:
>> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?
>
>What do you mean by synchronous? Typically, this means you derived one
>clock from the other, or both clocks from a master oscillator.
>
>Unfortunately, you still can't consider the resulting clocks
>"synchronous" anymore. They may be frequency locked, but you can't
>guarantee phase lock without careful design analysis. You can generally
>clean up the situation with careful use of DCM's, but even then, use
>care when crossing boundaries.
>
>I have seen a lot of designs fail due to improper treatment of clocks.
>As a result, I treat every boundary crossing as asynchronous, and tweak
>the crossing logic based on the measured phase relationship between the
>clocks.

You can also specify an amount of clock jitter which translates into a
clock uncertaintity which the router will take into account. It does
tighten the timing budget.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 108312
Subject: Re: Synchronous Clocks
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 07 Sep 2006 15:00:32 -0700
Links: << >>  << T >>  << A >>
radarman,

You are quite right.  The term 'synchronous' means "of the same time" or
in the same phase.  'Syntonous' means "of the same tone" or the same
frequency.

So, to be precise, even to say something is 'synchronous' is often
misleading, especially if the two signals being compared go through
different circuits/parts/paths.  You must know the jitter, wander, and
possible maximum offset.  And then you must subtract the worst case
error from the clock period constraint if you expect to be able to use
either clock domain to register data.

There are even more fun clock terms, like isochronous, pleisiochronous,
and so on....

Austin

radarman wrote:
> zohair wrote:
>> How do we apply a constrain to the Xilinx PAR tool to let it know that two clocks in the design are synchronous, and so the clock tree needs to be built with that in mind?
> 
> What do you mean by synchronous? Typically, this means you derived one
> clock from the other, or both clocks from a master oscillator.
> 
> Unfortunately, you still can't consider the resulting clocks
> "synchronous" anymore. They may be frequency locked, but you can't
> guarantee phase lock without careful design analysis. You can generally
> clean up the situation with careful use of DCM's, but even then, use
> care when crossing boundaries.
> 
> I have seen a lot of designs fail due to improper treatment of clocks.
> As a result, I treat every boundary crossing as asynchronous, and tweak
> the crossing logic based on the measured phase relationship between the
> clocks.
> 

Article: 108313
Subject: Re: Managing small IP library
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 07 Sep 2006 15:03:44 -0700
Links: << >>  << T >>  << A >>
avishay wrote:

> I would appreciate if anyone can give me an idea if such tools exist on
> the market, or to let me know how such task is being handled in other
> companies.

Step one is quality source control.

I'd start by finding a pc and setting up
a subversion server. Sounds like you use windows,
so maybe this would work:
http://svn1clicksetup.tigris.org/files/documents/3106/33794/Svn1ClickSetup-1.3.3.exe

Then I'd check in my own stuff and show anyone interested
how to do the same. If it works, and the designers like it,
I doubt that the boss will mind, because it's also free.
...except for a few months of your "spare" time, of course :)


              -- Mike Treseler

Article: 108314
Subject: Re: 2 FF synchronizer
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 08 Sep 2006 00:25:45 GMT
Links: << >>  << T >>  << A >>

The following long article at the www.fpga-faq.org site should help
you better understand these issues:

   http://www.fpga-faq.org/FAQ_Pages/0017_Tell_me_about_metastables.htm


On 7 Sep 2006 08:48:50 -0700, "himassk" <himassk@gmail.com> wrote:
>Hi,
>
>Kindly clarify the following doubts on Two FF synchronizer.
>Most of the material available in net says the two flip-flop
>synchronizer is sufficient to remove all likely metastability.

That is correct, with the qualifier that the path delay between the
two flip flops should be minimized, thus maximizing the slack time,
and the clock frequency should be minimized, thus maximizing the
slack time.

>The first flip-flop samples the asynchronous input signal and waits
>for a full clock cycle to permit any metastability output signal to
>come to stable either 1 or 0.

This is not correct. There is no "waiting". This is a statistical
process.

>How can the ouput of the first FF will becomes stable before the
>next clock cycle? On what factors it will depend?

See the above mentioned article.

>(Theoritically it not guarenteed that Two FF synchronizer avoids
>metastability but proctically it is, how?)

The practical result is that if there is sufficient slack time between
the 2 FFs, the probability of the metastable getting through both is
very small.

>Whats vendors approach for the first FF to go to stable state before
>next sampling edge arrives?

High loop gain/bandwidth.

>Whats information/insructions the vendor can provide designers
>regarding first FF settling time etc....?

Metastable characteristics data, and test results to back it up.
The parameters can be used in the MTBF calculations to decide if
a 2, 3 or more stage synchronizer is needed.

>What are all the options available in the designer hand to make the
>two ff synchronizer work properly?

Maximize slack time, use highest performance FFs available, read the
above article.

>Please make me clear.

Humans are inherently opaque. Making you clear would probably kill you.

>Thanks in advance.

Good luck!

>Regards,
>SruthiTeja.


Philip Freidin
Metastability Understanding crusader


===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG

Article: 108315
Subject: Re: Performance Appraisals
From: Jerry Avins <jya@ieee.org>
Date: Thu, 07 Sep 2006 20:40:24 -0400
Links: << >>  << T >>  << A >>
Homer J Simpson wrote:
> "Charlie Edmondson" <edmondson@ieee.org> wrote in message 
> news:44ff2839$1@news.cadence.com...
> 
>> Had a similiar situation when I worked on the 91 Express lanes toll road. 
>> My boss was a real A-hole, who would do things like, pull out a knife and 
>> shave his arms, commenting on how sharp it was, while asking for the 
>> status of your assignments.  The threat was very thinly veiled...
> 
> That's when you pull out a mini butane torch and comment on how hot it is.

I would have pulled out my pocket knife and trimmed my sideburns, then 
offered to trim his.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 108316
Subject: Re: NON-CLK pins failed to route using a CLK template
From: dhruvakshad@gmail.com
Date: 7 Sep 2006 17:59:28 -0700
Links: << >>  << T >>  << A >>
I have one more question. If I have two state machines with following
signals gating their states

P <= '1' WHEN ( B='1' ) ELSE     '0';

 P1 <='1' WHEN P='1' AND D > "00000000000000000" ELSE '0';

both these two signals are needed
Now when I pass signal P1 to the state machine  then do I have to pass
it via a flip flop ?

the signals B and D are assigned in another state machine and both the
state machines are running at same clock.
Thanks,
-D


dhruvakshad@gmail.com wrote:
> Thank you very much for the tip. I realised my mistake. It works fine
> now.
> -D


Article: 108317
Subject: Re: Why No Process Shrink On Prior FPGA Devices ?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 7 Sep 2006 18:10:26 -0700
Links: << >>  << T >>  << A >>

c d saunter wrote:
> Peter Alfke (alfke@sbcglobal.net) wrote:
>
> <snip>
> : Higher performance requires radical innovation and real cleverness
> : these days.
> : Peter Alfke
>
> Such as this?
>
> http://www.tip.csiro.au/ISEC2003/talks/OWe2.pdf
>
> JPL and Northrop Grumman built a 5k gate 8 bit CPU running at 20GHz by
> using superconducitng logic on a chip, it needs helium cycle cryogenics to
> hit 4.5k, but on the other hand it doesn't generate much heat being
> superconducting...
>
> I'd have thought gate arrays would make an excelent tool for
> investigating the technology...

>
> cds
Hi cds,
JPL and Northrop Grumman project is amasing. But you showed the slide
made in 2002. 4 years have passed, what is the latest advance? Do they
reach their goal? or don't get enough financial support and the project
was aborted?

Weng


Article: 108318
Subject: Re: 2 FF synchronizer
From: "rickman" <gnuarm@gmail.com>
Date: 7 Sep 2006 18:19:30 -0700
Links: << >>  << T >>  << A >>
himassk wrote:
> Hi,
>
> Kindly clarify the following doubts on Two FF synchronizer.
> Most of the material available in net says the two flip-flop
> synchronizer is sufficient to remove all likely metastability.
>
> The first flip-flop samples the asynchronous input signal and waits
> for a full clock cycle to permit any metastability output signal to
> come to stable either 1 or 0.
>
> How can the ouput of the first FF will becomes stable before the
> next clock cycle? On what factors it will depend?
> (Theoritically it not guarenteed that Two FF synchronizer avoids
> metastability but proctically it is, how?)
>
> Whats vendors approach for the first FF to go to stable state before
> next sampling edge arrives?
> Whats information/insructions the vendor can provide designers
> regarding first FF settling time etc....?
>
> What are all the options available in the designer hand to make the
> two ff synchronizer work properly?
>
> Please make me clear.

You have received some good answers to your questions, but partly
because I think you could still benefit from a simple explanation and
partly because I feel like listening to myself talk, I will give you a
third explanation of metastability and how to avoid its consequences.

Metastability is a state of a FF or other similar device (such as a
pencil standing on the pointed end) that has two stable states and if
released at any point in between will eventually assume one of those
two states.  The trick is that depending on how close to the threshold
point the pencil or FF is released, it can take an arbitrarily long
time to end up in one of the stable states.

For a pencil, holding it at a given position and releasing it is like
the active edge of the clock occuring too close to a transition of the
data input.  If the FF samples the data input while it is changing, the
intermediate logic gates may also be in transition and the feedback of
the FF can be in the middle of the voltage range.  If the logic values
were all at stable values the output would change at a time that is a
known delay from the clock edge.  But since the internal logic values
are not valid, the delay will not depend on the path delays, but rather
on how fast the invalid logic values are pushed one way or the other to
a stable state.  Just like the pencil, this depends on how close to the
threshold the invalid value is.

This is when statistics take over.  If you assume the delta from the
logic value to the threshold is not deterministic, but rather random
(as will usually be the case) then the time delay will also be random
reaching out to infinity.  The curve is such that there is a higher
probability at shorter delays and an ever decreasing probability at
longer delays.  Since the area under the curve has to integrate to
unity, you can see that the probability must go down very quickly since
it stretches forever.

So the upshot is that the current logic found in FPGAs is designed to
maximize the probability of short delays.  This means if you allow 2 or
3 ns of excess setup time between FFs (slack time), the probability of
the first FF output still being metastable is so low, that you will
never see it in your lifetime if you watch a billion FPGAs.

I have not supported this with any hard data, but the FPGA vendors have
done that for us.  I believe Peter Alfke has made numerous measurements
of the metastability coefficients for their products and the 2 or 3 ns
is the short version of his data.  Someone please correct me if I am
wrong about the numbers.

But please remember that it is the slack time, not the clock cycle time
that allows metastability to be resolved.  You can put logic in the
path as long as you have sufficient slack time.  Conversely, a clock
cycle may not be long enough if the routing delay is too long reducing
the slack time.  It does not hurt to add a specific timing constraint
to these paths.


Article: 108319
Subject: Re: ddr with multiple users
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 08 Sep 2006 12:39:01 +1000
Links: << >>  << T >>  << A >>
Hi David,

David Ashley wrote:

> I have about 4 different independent things that each need to access
> a ddr.
> 
> On one hand it seems I can make them all wishbone
> compliant then just have a wishbone ddr interface.

Some off-the-shelf options that spring to mind:

Firstly there's the opb_mch_ddr interface core that comes with Xilinx EDK - in
addition to the OPB bus interface (which you can ignore), it has 4 independent
channels that support a fairly simple simple cacheline fetch protocol (Xilinx
CacheLink).  In reality it's just their FSL port, with a specific access protocol.

It's intended for interfacing MicroBlaze CPUs to memory, but no reason you
couldn't use it for something else.  Current versions of the core are fixed
priority on the 4 ports, but I believe that round robin and other priority
schemes are in the roadmap (if you read the VHDL sources anyway).

Xilinx also has a MPMC (multiport memory controller) that was developed for the
gigabit serial reference design (GSRD), also worth a look.  I think you need to
register to download this design.

MPMC uses something called LocalLink, again just a sort of cacheline read/write
protocol, nothing too tricky I don't think, and there should be full source
examples of how to drive it in the reference design.

Ultimately you have to arbitrate somewhere, be that on a bus, in the memory
controller, or at the DDR pin/signal stage.  But as others have suggested, that
may be more trouble than its worth.

Regards,

John

Article: 108320
Subject: ML 310 on board power measurement...
From: "Xesium" <amirhossein.gholamipour@gmail.com>
Date: 7 Sep 2006 19:49:54 -0700
Links: << >>  << T >>  << A >>
Hi guys,

I'm trying to measure power consumption of my system on ML 310 board. I
was wondering if any one of you have done this. I checked the board
data sheet but I couldn't find any pin on the board from which I can
get the current on Vccint which goes to the chip and thus measuring the
power of the chip.

Do you know if there is any pin for measuring the power of the chip or
do you know any other way (other than simulation) for measuring power
consumption of the chip on ML 310?

Thanks in advance,

Amir


Article: 108321
Subject: Hennessy & Patterson new ed Computer Architecture:A Quantitative Approach
From: "Tara" <merrit_malloy@yahoo.com>
Date: 7 Sep 2006 20:34:42 -0700
Links: << >>  << T >>  << A >>
I don't want to spam, but I noticed someone referenced this book as a
"must-have" on the comp.arch group  I work for the publisher that is
printing a new edition
in September and would love to garner exposure for it in this forum.

I don't want to appear as though I am spamming though so let me know if
it is okay to provide more details.  I can also provide an offer code
that will give
members of this board a 20% discount and free shipping.  Amazon does
not sell this book at a discounted price. 

Thanks all, 

Tara


Article: 108322
Subject: Re: ddr with multiple users
From: Christian Kirschenlohr <c.kirschenlohr@bgmbh.de>
Date: Fri, 08 Sep 2006 09:40:18 +0200
Links: << >>  << T >>  << A >>
Hi David,
i had a similar problem where 3 different clocked users,
needed to access a SDRAM Interface wich run by a clock of 166 MHz.
The main problem was that every user needed full page bursts
in/out of the RAM.
So every one of the users got its own dc-Fifo. A single
arbitration unit took care that all users got access at the
right time. As SDRAM Controller I used the OpenCore from Altera.
This Design runs very well in Cyclone and Cyclone II devices.
Hope that helps.

Regards
Christian

Article: 108323
Subject: microblaze startup problem
From: "sjulhes" <t@aol.fr>
Date: Fri, 8 Sep 2006 10:08:26 +0200
Links: << >>  << T >>  << A >>
Hello all,

We are trying to design a small microblaze design in a spartan 3 and the 
problem we have is that the microblaze does not always start when the 
bitsream is downloaded with JTAG.

But when we implement the debug module it always works.

Does anyone has a clue ?
Is it timing problems ? Is there specific timing constraints to add for 
microblaze ?
Software problem ( linker script is automatically generated by edk)?

Any idea is welcome.

Thank you.

Stéphane. 



Article: 108324
Subject: Re: Please help me with (insert task here)
From: jasen <jasen@free.net.nz>
Date: 8 Sep 2006 08:28:23 GMT
Links: << >>  << T >>  << A >>
On 2006-09-06, phaeton <blahbleh666@hotmail.com> wrote:
> Hi can someone please explain to me how to post to usenet?

you've cleared the first hurdle,  read all of this page:

<http://groups.google.com/support/bin/answer.py?answer=12348>


Bye.
   Jasen



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