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 124375

Article: 124375
Subject: Re: Guess: what is the largest number of state machines in a current chip design: 1k, 10k, or...
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Wed, 19 Sep 2007 22:56:36 -0500
Links: << >>  << T >>  << A >>

>Scramble technology still uses randomized serial and XOR now? After 8b/
>10b technology, I think other randomized XOR scramble technology is
>dying out, is it right?

8b/10b has a 20% bandwidth hit.  That may be reasonable on short
links where the cost of the link is small relative to the cost
of the end points.  But change hats from a computer room
to a Telco.  Their costs are mostly the fibers in the ground.
Using scramblers is a no-brainer for 20% cost reduction.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 124376
Subject: Re: Guess: what is the largest number of state machines in a current
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 20 Sep 2007 04:05:39 GMT
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:
> Hi Hal,
> 8b/10b is perfect for scrambling function. PCI-e uses 8b/10b
> technology.
> 
> Scramble technology still uses randomized serial and XOR now? After 8b/
> 10b technology, I think other randomized XOR scramble technology is
> dying out, is it right?
> 
> IBM got one patent for 8b/10b technology in 1981, Xilinx filed for 23
> patents on 8b/10b implementation in FPGA on one day in 2004.
> 
> I think that IBM is really a technology leader in almost all respects
> in computer industry. Xilinx is the leader of FPGA.
> 
> Weng

80B/10B is not a scrambler.  It's a coding mechanism used to balance the 
DC offset of the encoded stream.  It's a straight encode/decode.

Don't be disappointed and frustrated for what you don't know.

Article: 124377
Subject: Re: help! ACTEL PROASIC PLUS clock buffer
From: Thomas Stanka <usenet_10@stanka-web.de>
Date: Wed, 19 Sep 2007 22:26:22 -0700
Links: << >>  << T >>  << A >>
On 19 Sep., 17:56, merche <dora...@gmail.com> wrote:
> Hi!, I have a big problem:
>
> I use Libero to Proasic Plus Family of Actel. My FPGA has got 4 global
> pin (4 GL macro), I need put a clock in a global buffer but I can=B4t
> because I have  others signals with highest fanout. what can I do?

Explain your real problem. Do you need more global inputs or is it a
problem of synthesis? Then instantiate a GL Buffer for the clk in your
code



Article: 124378
Subject: Re: Guess: what is the largest number of state machines in a current chip design: 1k, 10k, or...
From: Uncle Noah <nkavv@skiathos.physics.auth.gr>
Date: Wed, 19 Sep 2007 22:38:58 -0700
Links: << >>  << T >>  << A >>
Another fat-ass discussion invoked by Weng.

Hey Weng, you always turn on the most crapiest and unhealthiest
discussions.

BTW any big-company chief scientists or fat-ass academic professors
want to discuss about YARDstick, my super tool for custom processor
development?

There is a joke about academic bozzos and their capability of
coding...

http://electronics.physics.auth.gr/people/nkavv/yardstick/


Article: 124379
Subject: Re: Looking for fast AES cores with low latency
From: backhus <nix@nirgends.xyz>
Date: Thu, 20 Sep 2007 08:12:03 +0200
Links: << >>  << T >>  << A >>
Hi Allan.
You hit the point.
That is exactly why there are no such designs in real life.

You always can trade comb. delay vs. latency, but you have to look for 
the solution that suits your needs the best.

Now look at your example result with 14MHz. Theoretical data throughput 
is the same as in an iterative design running at 14*14Mhz, which I think 
is a clock frequency that can be achieved by modern FPGAs.
But: With the iterative design you save about 90% area and don't have to 
worry so much about moving the data from one clock domain to another. In 
the best possible case you can run the AES and all other circuits at the 
same (high) clock frequency.

The same thing is also valid for the S-Boxes in an AES design. Often 
made with Blockrams, out of convenience. But there are solutions 
published that use very small combinatorical circuits. These solutions 
have the disadvantage of large delays (20 to 30 ns) thus reducing the 
clock rate of the whole AES design. Now what do you do in such a case? 
Find out how to pipeline that solution. If you can increase the clock 
frequency into a range where it fits into the overall design, you can 
save all the valuable and rare BRAMs. It may cost you some clock cycles 
of additional latency, but it depends on the application if that is a 
problem or not.

So back to your original postings title:
Complex cores with low latency have high combinatorical delays.
The problems that arise from such solutions are in most cases larger 
than the benefits, if there are any at all.

Have a nice synthesis
   Eilert

Allan Herriman schrieb:
...snip...
> I did some tests today...
> 
> I unrolled our (conventional) 14 round implementation into one big
> mess of combinatorial logic with FFs at either end and ran it through
> the tools:
> 
...snip...
> 14MHz results in feedback modes giving about 1.8Gb/s encryption
> throughput.  I guess that's enough for GbEthernet, but we already know
> GbE can be done with a conventional pipelined AES implementation.

Article: 124380
Subject: Re: Clock boundary crossing
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 20 Sep 2007 03:23:01 -0500
Links: << >>  << T >>  << A >>

>Also, "Fourteen Ways to Fool Your Synchronizer" is a reasonable paper
>
>http://www.ee.technion.ac.il/~ran/papers/Sync_Errors_Feb03.pdf

I think I understand metastability.

Several/many years ago, I used to use it as a calibration on books.
Look in the index under metastability or synchronizer.  If you don't
find anything you know either the book doesn't cover it or the index
is poor.  It's hard to imagine a text on digital logic that doesn't
mention metastability.  Who wants a book with a crappy index?

If you do find something, see if it matches your understanding.



The paper is probably better than average,, but that's relative to a
field full of bogus/useless papers.  If you don't already understand
metastability, it doesn't do a very good job of explaining it.  If
you do understand it, it has a few patterns that might be good to
add to your list.

The real estate people joke about the 3 most important things being
location, location, and location.  Well, in metastability, the 3 most
important things are settling time, settling time time, and settling time.

Assuming you believe in settling time, here are my comments on the paper.

0) Section 2, A Correct Two Flop Synchronizer

It gives the classic MTBF formula.  It doesn't mention that the data
is hard to get.  I haven't seen any data other than lab typicals.
Has anybody seen any numbers on VCC or Temp or process?  Has anybody
seen anything in a data sheet?  (as compared to an app-note)

It also doesn't even hint that you might want to be extra conservative
if your design is used in safety critical equipment (as compared to a
lab hack to collect some data from a one-shot experiment) or if your
design will be used in a bazillion systems with good software where
a hardware glitch will generate a core dump that the software guys
get to pour over.


1) Section 3.2, the One Flop Synchronizer...

This can actually be good enough.  Suppose you have a system with the
classical 2 FF synchronizer that works OK at 100 MHz.  The best case
settling time is 10 ns.  (That's ignoring clock-to-out, routing, and
setup times.)  Suppose you run that system at 50 MHz but remove the
first FF.  The big ugly cloud of gates in the FSM picture is good
enough to run at 10 ns but your system clock is 20 ns, so you have
a guaranteed 10 ns of settling time.  That was more than good enough
in the 2 FF case.  Why isn't it good enough in the one FF case?


2) They missed another important case - routing delays.

Just because your 2 FFs are right next to each other on the schematic
or source code doesn't meant the placement tools will put them next
to each other on the chip.  If your FFs are far apart, the routing
delays can eat up a lot of the cycle time leaving not much left for
settling time.


3) Section 3.11, Metastability Blocker

Kludges like this are a good sanity check.  There are two reasons to
run away when you see one.

First, they are (often) hard to analyze.  With the classic 2 FF case
you have a good chance of understanding things.  You can use the
standard formula to estimate MTBF and vendors sometimes publish
data to plug into the formula.  With a kludge, you have to read
all the fine print on the data sheets until you find the catch.
One of the classic examples put a runt pulse on the reset to a FF.
Please let me know if you find any data to back that up.

The second reason is that kludges eat up prop time, thus reducing
settling time.  Settling time is exponential.  That's much better
than the constant factor from a kludge.  (If you find one that
works, please let me know.)

I can't figure out how that example is supposed to work.  The
S/R FF gets reset by RESET.  It gets set if the mux lets a 1
through.  Maybe the S/R FF should get reset by clock low, or
something like that.  In any case, it only leaves a half
cycle of settling time.  (assuming 50-50 clocking.)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 124381
Subject: Multi-cycle paths in VHDL libraries
From: "GKnittel" <knittel@gris.uni-tuebingen.de>
Date: Thu, 20 Sep 2007 11:09:22 +0200
Links: << >>  << T >>  << A >>
Hi everyone,

may I ask you a question. I'm trying to find out how to handle multi-cycle
paths in VHDL libraries. I'm using Xilinx ISE 9.2i and XST.
I have designed a number of modules, all compiled into separate libraries,
which I would now like to use in a bigger design.
Some of them have multi-cycle paths, so I would like to specify appropriate
timing constraints. I know that I can specify from-to (only?) in an
.xcf-file, however, that information appears to end up only in the 
.ngc-netlist,
not in the VHDL-library. As opposed to, for example, a maxdelay-constraint,
which I can specify as an attribute in the VHDL-source, and which is
included in the library and later recognized by P&R.
Any help?
Thanks a lot, best regards
Gunter



Article: 124382
Subject: Re: help! ACTEL PROASIC PLUS clock buffer
From: merche <dorama2@gmail.com>
Date: Thu, 20 Sep 2007 09:36:02 -0000
Links: << >>  << T >>  << A >>
On Sep 20, 7:26 am, Thomas Stanka <usenet...@stanka-web.de> wrote:
> On 19 Sep., 17:56, merche <dora...@gmail.com> wrote:
>
> > Hi!, I have a big problem:
>
> > I use Libero to Proasic Plus Family of Actel. My FPGA has got 4 global
> > pin (4 GL macro), I need put a clock in a global buffer but I can=B4t
> > because I have  others signals with highest fanout. what can I do?
>
> Explain your real problem. Do you need more global inputs or is it a
> problem of synthesis? Then instantiate a GL Buffer for the clk in your
> code

thanks Thomas Stanka! But...

In my code I have instantiated a GL Buffer (is a fast clock). But in
the synthesis: the log say...

Automatic dissolve during optimization of view:work.w_r9(w_r9) of
GL2(GL)

then,  others signals with highest fanout promoted to global buffer.
This synthesis is made with Synplify.

I don=B4t know how change this automatic options.


Article: 124383
Subject: proasic plus. actel
From: merche <dorama2@gmail.com>
Date: Thu, 20 Sep 2007 10:42:20 -0000
Links: << >>  << T >>  << A >>
thanks Thomas Stanka! But...

In my code I have instantiated a GL Buffer (is a fast clock). But in
the synthesis: the log say...


Automatic dissolve during optimization of view:work.w_r9(w_r9) of
GL2(GL)


then,  others signals with highest fanout promoted to global buffer.
This synthesis is made with Synplify.


I don=B4t know how change this automatic options.


Article: 124384
Subject: Re: Virtex-4 SELECT MAP configuration
From: "jerzy.gbur@gmail.com" <jerzy.gbur@gmail.com>
Date: Thu, 20 Sep 2007 10:45:27 -0000
Links: << >>  << T >>  << A >>
On 18 Wrz, 04:12, Pasacco <pasa...@gmail.com> wrote:
> Hi
>
> Let me ask two questions --:
>
> According to Virtex-4 configuaration guide
> (http://www.xilinx.com/bvdocs/userguides/ug071.pdf),
> ICAP interface is either 8-bit or 32-bit, with up to 60MHz CCLK.
> Most of diagrams and explanations are based on 8-bit interface.
>
> I also saw one document, in which latest VIrtex-4 ICAP provides 32-bit
> interface with 100 MHz.
>
> I wonder if 32-bit interface operates, in a same way as 8-bit
> interface.
>
> Is 32-bit interface 4 times faster than 8-bit interface?
>
> In 100 MHz mode, are there any handshaking during the bitstream
> loading?

It could be to fast,

> (There was no handshaking during bitream loading, in Virtex-II Pro, if
> I am correct)

There is "busy" signal.

Look into the Virtex4 Configuration Guide

Regards,
Jerzy Gbur


Article: 124385
Subject: Re: Gated Clock Problems
From: vasile <piclist9@gmail.com>
Date: Thu, 20 Sep 2007 11:09:30 -0000
Links: << >>  << T >>  << A >>
Data on D must be stable before CLK, else you'll got garbage,
scientificaly called "metastability" problems.
http://www.interfacebus.com/Design_MetaStable.html

Vasile


On Sep 19, 7:52 pm, Berk Birand <d...@email.me> wrote:
> Hi everyone,
>
> I am running into a really peculiar problem for a research project that I
> am working on. The circuit is fairly simple one, which needs to measure
> which one of two signals reaches a flip-flop first. Two impulses are sent
> through two different paths, and they are both fed to a D flip-flop. The
> circuit uses a nifty trick for outputting which signal got there first.
>
> One of the signals (signal A) is connected to the D input, and the other
> one (signal B) to the Clock input. Both signals get a 0-to-1 transition.
> If signal A arrives first, D is '1' when there is a transition on Clk,
> so output of flip-flop is 1:
>
>              |-------------
> A (D)        |                    
>          ____|
>
>                    |-------------
> B (Clk)            |
>          __________|
>
> If signal B gets there first, then when Clock occurs, D is still '0', so
> output is '0'
>
>               |-------------
> D             |                    
>      _________|
>
>          |-------------
> Clk      |
>      ____|
>
> (I hope my feeble attempts were sufficient to demonstrate the situation)
>
> It was pretty easy to code this using VHDL; I just needed to connect the
> signals correctly.
>
> The problem is that during the Place & Route phase, I receive a warning
> telling me that I have a clock signal coming from a combinatorial, gated
> circuit. As I have pointed out, this is actually what I want. The peculiar
> problem manifests itself as follows:
> When I synthesize it, the Device Summary correctly finds 64 slices that
> are being used. Yet when I run PAR, that number suddenly becomes 8 slices!
> I think the reduction in the slice count is due to the given warning,
> since the rest of the circuit behaves as expected.
>
> Can anybody tell me how I should deal with this situation? I have tried
> using a CLOCK_SIGNAL attribute, but I doubt that's what I want.
>
> I would appreciate any help,
> Thanks,
> Berk Birand
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com



Article: 124386
Subject: Re: Guess: what is the largest number of state machines in a current chip design: 1k, 10k, or...
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Thu, 20 Sep 2007 14:31:32 +0200
Links: << >>  << T >>  << A >>
> IF OP = "Weng Tianxiang" AND group = comp_arch_fpga THEN
>  be_prepared_for_a_long_thread;
> ORIF crossposted = to_comp_lang_vhdl THEN
>  this_could_go_on_all_week;
> ANDIF both_the_above THEN
>  make_that_a_month;
> BUTIF plonk! THEN
>  blessed_relief;
> ELSIF experiences < imagination THEN
>  OP_question <= not(sense);
> ELSE
>  possibly_on_topic;
> END IF;
>
> HTH., Syms. ;-)
>
> p.s. Sorry, couldn't resist it!
>
> p.p.s. I guess one. You can view the whole FPGA as one big state machine. 
> Do I win £5?

ROFL, how could I have missed this posting for 3 days... LOL

Thomas 



Article: 124387
Subject: Re: Gated Clock Problems
From: "Mike Lewis" <someone@micrsoft.com>
Date: Thu, 20 Sep 2007 08:41:44 -0400
Links: << >>  << T >>  << A >>

"vasile" <piclist9@gmail.com> wrote in message 
news:1190286570.416365.21640@19g2000hsx.googlegroups.com...
> Data on D must be stable before CLK, else you'll got garbage,
> scientificaly called "metastability" problems.
> http://www.interfacebus.com/Design_MetaStable.html
>
> Vasile
>

I feel I need to argue this morning ... you won't get garbage. If you 
violate setup, the output will go metastable for a short period of time and 
then settle on either the previous value or the new value. The metastability 
will be so short in duartion you may as well ignore is effect unless you 
have a clock period above 500Mhz.

Mike 



Article: 124388
Subject: Is it possible for two wires to share the same FPGA pin?
From: Wei Wang <camwwang@gmail.com>
Date: Thu, 20 Sep 2007 07:06:42 -0700
Links: << >>  << T >>  << A >>
For example, I have two wires FA[23:1] (address line for Flash) and
RAM_A_SD[63:0] (data line for SRAM), due to the number of pins
constraint, FA and RAM_A_SD share the same FPGA pins (seen from
outside of FPGA). I tried to assign those two wires to the same pins
in pin assignment file, but got errors from Xilinx ISE mapping
process, saying that it is incorrect to assign two wires to the same
pin and cannot resolve the pin assignments. Just wondering whether it
is possible to use both Flash and SRAM outside of FPGA in this case,
or should I tri-state every single data line which shares the same pin
with other wires, such that there is only one wire goes into a
particular pin (seen from inside fpga)? cheers, -Wei


Article: 124389
Subject: Re: Looking for fast AES cores with low latency
From: Allan Herriman <allanherriman@hotmail.com>
Date: Fri, 21 Sep 2007 00:22:08 +1000
Links: << >>  << T >>  << A >>
On Thu, 20 Sep 2007 08:12:03 +0200, backhus <nix@nirgends.xyz> wrote:

>Hi Allan.
>You hit the point.
>That is exactly why there are no such designs in real life.

Ah yes.  I have come to the same conclusion.

A few years ago, I designed what I believe was the first 10Gb/s AES256
encryptor on the market.  It used CTR mode, because that was the only
mode suitable to run at those rates in the FPGAs that were available
then.
I recall thinking that feedback modes (e.g. CFB) would be possible at
10Gb/s in FPGAs in a few years time.  I'll try this test again when
the next generation of FPGAs come out.


For the crypto naive:  The throughput of a block cypher with feedback
is determined by the delay through the block cypher calculation.
Pipelining is good for getting impressive clock numbers, but it
actually hurts throughput.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation


Thanks to all who responded,
Allan.

Article: 124390
Subject: Re: Gated Clock Problems
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 20 Sep 2007 15:35:22 +0100
Links: << >>  << T >>  << A >>
"Mike Lewis" <someone@micrsoft.com> wrote in message 
news:55a73$46f26a9e$401a86c3$16577@PRIMUS.CA...
>
> "vasile" <piclist9@gmail.com> wrote in message 
> news:1190286570.416365.21640@19g2000hsx.googlegroups.com...
>> Data on D must be stable before CLK, else you'll got garbage,
>> scientificaly called "metastability" problems.
>> http://www.interfacebus.com/Design_MetaStable.html
>>
>> Vasile
>>
>
> I feel I need to argue this morning ... you won't get garbage. If you 
> violate setup, the output will go metastable for a short period of time 
> and then settle on either the previous value or the new value. The 
> metastability will be so short in duartion you may as well ignore is 
> effect unless you have a clock period above 500Mhz.
>
> Mike
>
Hi Mike,
That's not true. (You did say you were up for an argument!) Flipflops can go 
metastable for any (unlimited) amount of time, with rapidly decreasing 
probability as the metastable time increases. Also, it is not necessarily 
the case that the FF's output goes crazy during metastability. The effect 
can manifest itself as an arbtrarily long clock to out.
As to ignoring this effect unless you're going at 500MHz or more, I hope you 
don't work on any safety critical systems! In FPGA-land, the timing closure 
tools only aim to meet the clock timing for non-metastable FFs. The place 
and route could easily leave a circuit vulnerable to a slight increase in 
clock to out delay caused by metastability.
There's no need for us to go over all this yet again. Googling 
comp.arch.fpga will doubtless return hundreds of posts about folks' 
"metastability proof FFs" with thousands of replies shooting these devices 
down!
IIRC, Peter from Xilinx has published the results of his extensive 
experiments on this issue. I urge anyone interested to track this down.
HTH, Syms.

p.s. As for the OP's question, I'm pretty sure the warning isn't the 
problem. I guess the P&R is optimising away logic which can be reduced, 
perhaps because the logic's outputs don't get used. 



Article: 124391
Subject: Re: Is it possible for two wires to share the same FPGA pin?
From: Dave Pollum <vze24h5m@verizon.net>
Date: Thu, 20 Sep 2007 07:36:14 -0700
Links: << >>  << T >>  << A >>
On Sep 20, 9:06 am, Wei Wang <camww...@gmail.com> wrote:
> For example, I have two wires FA[23:1] (address line for Flash) and
> RAM_A_SD[63:0] (data line for SRAM), due to the number of pins
> constraint, FA and RAM_A_SD share the same FPGA pins (seen from
> outside of FPGA). I tried to assign those two wires to the same pins
> in pin assignment file, but got errors from Xilinx ISE mapping
> process, saying that it is incorrect to assign two wires to the same
> pin and cannot resolve the pin assignments. Just wondering whether it
> is possible to use both Flash and SRAM outside of FPGA in this case,
> or should I tri-state every single data line which shares the same pin
> with other wires, such that there is only one wire goes into a
> particular pin (seen from inside fpga)? cheers, -Wei

I'll try this again:

Wei;
<1>
       FA[0] ---|3S>-----+------ FPGA pin
       FA_en----^        |
                         |
      RAM_A_SD---|3S>----+
      RAM_A_en -----^

      --|3S>--   is a tri-state buffer
                 ^ is its enable pin

-Dave Pollum


Article: 124392
Subject: Re: Is it possible for two wires to share the same FPGA pin?
From: mk <kal*@dspia.*comdelete>
Date: Thu, 20 Sep 2007 07:43:53 -0700
Links: << >>  << T >>  << A >>
On Thu, 20 Sep 2007 07:06:42 -0700, Wei Wang <camwwang@gmail.com>
wrote:

>For example, I have two wires FA[23:1] (address line for Flash) and
>RAM_A_SD[63:0] (data line for SRAM), due to the number of pins
>constraint, FA and RAM_A_SD share the same FPGA pins (seen from
>outside of FPGA). I tried to assign those two wires to the same pins
>in pin assignment file, but got errors from Xilinx ISE mapping
>process, saying that it is incorrect to assign two wires to the same
>pin and cannot resolve the pin assignments. Just wondering whether it
>is possible to use both Flash and SRAM outside of FPGA in this case,
>or should I tri-state every single data line which shares the same pin
>with other wires, such that there is only one wire goes into a
>particular pin (seen from inside fpga)? cheers, -Wei

If I understand what you're asking, you need to time multiplex the
pins internally ie as you have to have two sets of wires, one for
flash, one for sram, you need to multiplex them before you drive the
pins. So you have a single set of pins which goes to both flash & sram
and individual chip enable pins to tell which external chip can use
the wires. So internally multiplex the buses, & externally de-mux with
the chip select.

Hope this helps.

Article: 124393
Subject: Re: Gated Clock Problems
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Thu, 20 Sep 2007 17:18:14 +0200
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
Symon <symon_brewer@hotmail.com> wrote:
>>
>> "vasile" <piclist9@gmail.com> wrote in message 
>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com...
>>> Data on D must be stable before CLK, else you'll got garbage,
>>> scientificaly called "metastability" problems.
>>> http://www.interfacebus.com/Design_MetaStable.html
[...]
> That's not true. (You did say you were up for an argument!) Flipflops can go 
> metastable for any (unlimited) amount of time, with rapidly decreasing 
> probability as the metastable time increases. Also, it is not necessarily 
> the case that the FF's output goes crazy during metastability. The effect 
> can manifest itself as an arbtrarily long clock to out.

If the clock to out can be arbitrary long, how would the above proposed
solution with the extra synchronizer DFF solve the problem? If the setup
of the synchronizer DFF is violated (which is inevitable as the D-input
is an external signal), it's output may violate the input setup time
of the synchronous system for the next clock edge.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)


Article: 124394
Subject: Re: Gated Clock Problems
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 20 Sep 2007 16:21:44 +0100
Links: << >>  << T >>  << A >>

"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message 
news:a9f1c$46f28f36$54f63171$8563@publishnet.news-service.com...
> In comp.arch.fpga,
> Symon <symon_brewer@hotmail.com> wrote:
>>>
>>> "vasile" <piclist9@gmail.com> wrote in message
>>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com...
>>>> Data on D must be stable before CLK, else you'll got garbage,
>>>> scientificaly called "metastability" problems.
>>>> http://www.interfacebus.com/Design_MetaStable.html
> [...]
>> That's not true. (You did say you were up for an argument!) Flipflops can 
>> go
>> metastable for any (unlimited) amount of time, with rapidly decreasing
>> probability as the metastable time increases. Also, it is not necessarily
>> the case that the FF's output goes crazy during metastability. The effect
>> can manifest itself as an arbtrarily long clock to out.
>
> If the clock to out can be arbitrary long, how would the above proposed
> solution with the extra synchronizer DFF solve the problem? If the setup
> of the synchronizer DFF is violated (which is inevitable as the D-input
> is an external signal), it's output may violate the input setup time
> of the synchronous system for the next clock edge.
>
> -- 
> Stef
>
Hi Stef,
That's the whole point. You can't cure the problem 100%, but you can get 
arbitrarily close to fixing it by using more synchronising FFs, or waiting 
longer. Someone once suggested that circuits should be designed to only go 
metastable once (on average) for twice the amount of time you plan to be in 
the job you're doing!
HTH, Syms. 



Article: 124395
Subject: Re: Gated Clock Problems
From: mk <kal*@dspia.*comdelete>
Date: Thu, 20 Sep 2007 17:08:19 GMT
Links: << >>  << T >>  << A >>
On Thu, 20 Sep 2007 17:18:14 +0200, Stef
<stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>In comp.arch.fpga,
>Symon <symon_brewer@hotmail.com> wrote:
>>>
>>> "vasile" <piclist9@gmail.com> wrote in message 
>>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com...
>>>> Data on D must be stable before CLK, else you'll got garbage,
>>>> scientificaly called "metastability" problems.
>>>> http://www.interfacebus.com/Design_MetaStable.html
>[...]
>> That's not true. (You did say you were up for an argument!) Flipflops can go 
>> metastable for any (unlimited) amount of time, with rapidly decreasing 
>> probability as the metastable time increases. Also, it is not necessarily 
>> the case that the FF's output goes crazy during metastability. The effect 
>> can manifest itself as an arbtrarily long clock to out.
>
>If the clock to out can be arbitrary long, how would the above proposed
>solution with the extra synchronizer DFF solve the problem? If the setup
>of the synchronizer DFF is violated (which is inevitable as the D-input
>is an external signal), it's output may violate the input setup time
>of the synchronous system for the next clock edge.

You don't solve the problem you ameliorate it. The probability that a
flop going metastable is p, two of them going metastable one after the
other is p^2 (rougly speaking, I'm an engineer not a mathematician).
If p is sufficiently small, p^2 may be small enough that you won't get
it till sun goes super nova (or what ever our star will do when it
reaches its end of life). If that's not acceptable to you add another
flop to make the probability p^3 and stick around till our galaxy
becomes a mush.

Article: 124396
Subject: Re: Clock boundary crossing
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 20 Sep 2007 10:18:21 -0700
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> 1) Section 3.2, the One Flop Synchronizer...
> 
> This can actually be good enough.  Suppose you have a system with the
> classical 2 FF synchronizer that works OK at 100 MHz.  The best case
> settling time is 10 ns.  (That's ignoring clock-to-out, routing, and
> setup times.)  Suppose you run that system at 50 MHz but remove the
> first FF.  The big ugly cloud of gates in the FSM picture is good
> enough to run at 10 ns but your system clock is 20 ns, so you have
> a guaranteed 10 ns of settling time.  That was more than good enough
> in the 2 FF case.  Why isn't it good enough in the one FF case?

I use at least two anyway to rule out duplication
of the synchronizing register by synthesis
(which could eliminate the synchronization effect).

I could do the same thing with constraints,
but these do not always follow the source
code around.

       -- Mike Treseler

Article: 124397
Subject: DMA scatter gather with PLB bus?
From: cesarp <cesar.pedraza@gmail.com>
Date: Thu, 20 Sep 2007 17:27:27 -0000
Links: << >>  << T >>  << A >>
Hi everyone.
I'm trying to transfer data from DDR memory to a custom PLB_IPIF
peripheral in a Virtex II Pro XUP card. I have some questions:
1. In EDK is not possible to configure a scatter-gather DMA access
with PLB in the Peripheral wizard. Why?
2. I'm trying to transfer data using simple DMA under linux 2.4
compiled for PPC405, but the system crash when it is inicialized the
DMA transfer. Totally dead. I'm keeping in mind the differences
between physical and virtual addresses in source and destiny
registers, in fact i have tried with a driver for kernel. In
standalone mode the DMA transfer works fine. I'm working with EDK
8.2 .

I know there are many things can be wrong, but any help or suggestion
is appreciated.

Thank you in advance.


Article: 124398
Subject: Comparing Adder synthesis techniques
From: Joseph <jozamm@gmail.com>
Date: Thu, 20 Sep 2007 17:41:26 -0000
Links: << >>  << T >>  << A >>
Hi,

I am working on a study to copmpre the effiency of synthesied adders.
I have built a ripple adder and a carry look ahead using VHDL for a
Virtex FPGA. I know that the lookahead carry adder is much faster than
the ripple carry adder but when I synthezied both fro a 16 bit adder
i got only an improvement of 2ns using the lookahead carry adder.

For the lookahead adder i built a 1 bit adder which generates the
P,G,Sum and Carry and than built the lookahead logic using standard
techniques. The carry in was computed as :

C(i) <= G(i-1) or ( P(i-1) and C(i-1);

Finally i added the inputs and the Carries.

Can someone telle me if i did wrong implementation or give me some
tips how to code it properly.

Thanks a lot

Joseph


Article: 124399
Subject: Re: Gated Clock Problems
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 20 Sep 2007 13:26:17 -0500
Links: << >>  << T >>  << A >>

>I feel I need to argue this morning ... you won't get garbage. If you 
>violate setup, the output will go metastable for a short period of time and 
>then settle on either the previous value or the new value. The metastability 
>will be so short in duartion you may as well ignore is effect unless you 
>have a clock period above 500Mhz.

What page of the data sheet says that?

How do you know what can be ignored in my application?  (You probably
won't "ignore" things if your system is doing critical things like
pointing missles or keeping track of money.)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.




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