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 28075

Article: 28075
Subject: Re: dual port ram for altera
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 08:53:05 -0800
Links: << >>  << T >>  << A >>


Hal Murray wrote:

>
>
> Just checking to make sure I understand...
>
> "corrupted data" means some of the bits were written
> by one side and some of the bits were written by the other.  Right?
>
> So this only matters if the RAM is more than 1 bit wide.

Yes. One-bit wide is the special case where it doesn't matter if the data is
corrupted. If both sides write the same, 1 or 0, it will be fine. If the  two
sides differ, then the outcome will be either 1 or 0, which is acceptable. So
in this particular case, you can ignore all precautions.

Peter Alfke



Article: 28076
Subject: Re: really fast counter in SpartanXL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 08:57:49 -0800
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> [Context is making a fast counter to measure the width of a pulse.]
>
> Could you get an extra half bit of resolution by clocking things
> on the other edge of the clock too?
>
> I think that requires that both the clock-enable (pulse being measured)
> and the clock be be routed to 2 CLBs with matching routing delays.
>

And I suppose you would then build two complete counters and add their values.
That gives you the number of rising + the number of falling edges.  Should work.

Peter Alfke


Article: 28077
Subject: Re: Spartan2 and industrial temperatures
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 09:02:16 -0800
Links: << >>  << T >>  << A >>


Karl Olsen wrote

>
> Hi again,
>
> ds001_3.pdf mentions 500mA startup current for commercial parts, and nothing
> for industrial.  Is the startup current expected to be larger for industrial
> parts in the whole -40C to 100C range?

No, only when cold. It is a function of die temperature, not of the designated
speed grade.

>
>
> Another thing -- I haven't found much info about Spartan2 dynamic power.
> The closest is the Virtex power estimator at
> http://support.xilinx.com/cgi-bin/powerweb.pl
> Can this be used with any accuracy for XC2S15 and XC2S30 designs, if I
> select XCV50 in the power estimator?

I cannot answer this. Just don't know.

Peter Alfke


Article: 28078
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: "Andrew Ince" <andrew.ince@gecm.com>
Date: Wed, 20 Dec 2000 17:03:29 -0000
Links: << >>  << T >>  << A >>

"Martin Heimlicher" <heimlicher@scs.ch> wrote in message
news:3a37e67f@news.datacomm.ch...

> How do I assure that an externally supplied reset signal connected to some
> sort of GSR (global set/reset) net releases all registers simultaneously
(in
> the same clock cycle) and reliably (no metastability) ?
>   Martin Heimlicher, Supercomputing Systems AG, Switzerland

On a related point, Why should the 'uncritical' resets be coded?

The  Synthesis/PAR tools know the VHDL code targets FPGA's, and adds the
GSR.
Post layout simulation of code resulting from un-Reset VHDL works
 e.g. "alt_en <= NOT alt_en WHEN Rising_Edge(clk);"

However most vendors produce 'VHDL Simulators' that in Pre Layout simulation
cannot
cope with the FPGA's initialisation of registers and the simulation fails.
As most designs target FPGA's, the simulators should have a 'PreSimulation
Reset' command
that can be overturned by code defaults on individual signals if required.
The Tools will then simulate the above 'FPGA code' correctly with out having
to code the
asynchronous GSR reset or the "risky" signal initial values.

Andrew Ince




Article: 28079
Subject: Re: Question about Xilinx pins at high-frequency
From: David Hawke <dhawke@xilinx.com>
Date: Wed, 20 Dec 2000 17:05:32 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------5220559A49A0A01D0E1A448A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andrew,

If you are using tools like Leonardo Specrum, then yes, this tool will
duplicate the register for you. (It has certain rules though, such as the FF
has to be at the top level) so probably not much use unless you remove the
levels of hierarchy using:

ungroup <inst> -hierarchy

Dave

Andrew Ince wrote:

> "fred" <x@y.z> wrote in message news:91ptuj$3t5$1@news7.svr.pol.co.uk...
> > "David Hawke" <dhawke@xilinx.com> wrote...
> > > If you use Map -pr b then the mapper will place the
> > registers for the Output Enable in the IOB, this is only the
> > case however if there is one source register per pin (eg 32
> > bit bus with single OE register will not be placed in the
> > IO). This will give you faster switch-over and make doing
> > ZBT interfaces much easier...
> > >
> > Thank you Dave, the one OE reg per IOB thing is obvious when
> > you look at it but I would have missed it - just saved me an
> > age in debug time.
>
> But It is only obvious if you look for ways the tool may fail to work.
>
> As users we should expect tools to do simple tasks like automatic
> duplication.
>
> Andrew Ince

--------------5220559A49A0A01D0E1A448A
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:Hawke;David Hawke
tel;cell:(+44) 778 875 5002
tel;work:(+44) 870 7350 517
x-mozilla-html:TRUE
org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx">
version:2.1
email;internet:dhawke@xilinx.com
title:XILINX   Field Applications Engineer
adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;;
x-mozilla-cpt:;2672
fn:David Hawke
end:vcard

--------------5220559A49A0A01D0E1A448A--


Article: 28080
Subject: Re: Virtex and metastability
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 09:12:07 -0800
Links: << >>  << T >>  << A >>


Jonas Thor wrote:

> Why is the "standard" estimation of MTBF a function of only td, f1 and
> f2? (td = acceptable extra delay, f1 = clock and f2 = data frequency).
> The rise time of the clocks and data signals must matter... or? At
> least for external interfaces.
>
>

I don't think so.
1. There is sufficient gain in the input buffer and even some hysteresis to
make any input rise time look fast once it reaches the internal flip-flop.

2. What matters is how often the master latch is caught in the process of
changing and being "in the middle", exactly at the moment when the clock pulse
stops it from being transparent. Then the issue is, how long it takes to fall
to one side. The input rise time should be irrelevant. IMHO

Peter Alfke



Article: 28081
Subject: Re: Question about Xilinx pins at high-frequency
From: David Hawke <dhawke@xilinx.com>
Date: Wed, 20 Dec 2000 17:17:13 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------0F4C2A6B857631C38411B6CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Pascal C." wrote:

> A few things:
>
> 1.  for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch.  What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3.  Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)?
>

I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high!
Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work...

The tools I use is all of them! Spectrum, XST, Synplicity and FPGA Express...

>
> In case 2, the chips the FPGA is connected to are about an inch away.  I believe that the measurement was made with a 1" ground, but I'll have to check up on that (I didn't take the measurement myself).
>
> I am already setting the DRIVE through the UCF.  The problem is that PAR won't do its thing when the drive is below 12 mA...
>

I don't understand this...Which IO standard are you using? I have always reduced the drive strength on most IO to the point where I have enough speed left to meet constraints... Beware, even with default PAR options you do not necessarily need the full drive. It often makes better of a poor PCB design to do this. Don't forget these are the largest transistors on the die (0.35u) and have plenty of ooommph (you can also make a nice
extra GND out of the transistors connected to GND internally and then increase the drive to 24) - basically you just grounded the substrate again....

>
> One trick that was recommended to me was to synthesize with a drive of 12 mA (if that's what it takes), then using FPGA Editor to manually modify each of the pins.  However there are 91 pins to change, and the prospect isn't too thrilling (it wouldn't matter, except we're not yet in production, and the idea of repeating these steps each time I synthesize isn't too exciting)...
>
> Thanks for all your help!
>
> Pascal

--------------0F4C2A6B857631C38411B6CA
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:Hawke;David Hawke
tel;cell:(+44) 778 875 5002
tel;work:(+44) 870 7350 517
x-mozilla-html:TRUE
org:<br><img src="http://www.xilinx.com/images/smvirtex.gif" alt="Xilinx">
version:2.1
email;internet:dhawke@xilinx.com
title:XILINX   Field Applications Engineer
adr;quoted-printable:;;Xilinx Northern Europe=0D=0ABenchmark House;203 Brooklands road;Weybridge;;
x-mozilla-cpt:;2672
fn:David Hawke
end:vcard

--------------0F4C2A6B857631C38411B6CA--


Article: 28082
Subject: Re: Reverse-engineering FPGA's
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 09:18:07 -0800
Links: << >>  << T >>  << A >>
Virtex-II, to be available very soon, will change the landscape:
It has, as a configuration option, an internal triple-DES
configuration-bitstream decryptor.
That should be a big relief for any designers worrying about the security
of their design.

Please forgive this commercial message...

Peter Alfke, Xilinx Applications
============================================




Article: 28083
Subject: Re: dual port ram for altera
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 20 Dec 2000 10:17:43 -0800
Links: << >>  << T >>  << A >>
On Wed, 20 Dec 2000 08:53:05 -0800, Peter Alfke <peter.alfke@xilinx.com> wrote:

>Hal Murray wrote:
>
>>
>>
>> Just checking to make sure I understand...
>>
>> "corrupted data" means some of the bits were written
>> by one side and some of the bits were written by the other.  Right?
>>
>> So this only matters if the RAM is more than 1 bit wide.
>
>Yes. One-bit wide is the special case where it doesn't matter if the data is
>corrupted. If both sides write the same, 1 or 0, it will be fine. If the  two
>sides differ, then the outcome will be either 1 or 0, which is acceptable. So
>in this particular case, you can ignore all precautions.
>
>Peter Alfke
>

Ummmmm, I'm not as sure. I believe that if both sides write a bit
at the "same" time, and one writes a '0', and one writes a '1'
there is a possibility of a metastable. If the two write clocks are
the same clock signal, the delta time between the two will be
constant, and the circuit will behave the same way probably
all the time: either metastable each time, or one of them always
wins, or a zero always wins or a one always wins. If the clocks
are asynchronous, then as for all metastable situations, there
will be some delta delay (clock vs clock) at which the charge
injected into the RAM cell will make it metastable. It may resolve
befor the next read, or the read may disturb the cell and resolve
the metastable.

Philip Freidin
Philip Freidin
Fliptronics

Article: 28084
Subject: Re: dual port ram for altera
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 10:46:25 -0800
Links: << >>  << T >>  << A >>


Philip Freidin wrote:

>
> >Yes. One-bit wide is the special case where it doesn't matter if the data is
> >corrupted. If both sides write the same, 1 or 0, it will be fine. If the  two
> >sides differ, then the outcome will be either 1 or 0, which is acceptable. So
> >in this particular case, you can ignore all precautions.
> >
> >Peter Alfke
> >
>
> Ummmmm, I'm not as sure. I believe that if both sides write a bit
> at the "same" time, and one writes a '0', and one writes a '1'
> there is a possibility of a metastable. If the two write clocks are
> the same clock signal, the delta time between the two will be
> constant, and the circuit will behave the same way probably
> all the time: either metastable each time, or one of them always
> wins, or a zero always wins or a one always wins. If the clocks
> are asynchronous, then as for all metastable situations, there
> will be some delta delay (clock vs clock) at which the charge
> injected into the RAM cell will make it metastable. It may resolve
> befor the next read, or the read may disturb the cell and resolve
> the metastable.

This seems to be the season of metastability.
Ok, so in the absolute worst case scenario the two conflicting simultaneous writes
leave the cell in the metastable condition. Everybody agrees that it cannot stay
there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our
lifetime. So, unless you read that same location that you just wrote conflicting
information into ( so you really shouldn't care whether it's a 1 or a 0) within a
few ns again, everything will be calm and peaceful.

Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We
just have this running battle over the practical ( not the philosophical !)
aspects of metastability.  Let me establish the probabilities by testing Virtex-II
in January.

Peter Alfke, Xilinx Applicationss



Article: 28085
Subject: Re: really fast counter in SpartanXL?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 10:53:14 -0800
Links: << >>  << T >>  << A >>


Hal Murray wrote:

>
> Could you get an extra half bit of resolution by clocking things
> on the other edge of the clock too?
>
> I think that requires that both the clock-enable (pulse being measured)
> and the clock be be routed to 2 CLBs with matching routing delays.
>

Come to think of it:
Why limit yourself to just two edegs? You can create a bunch of increasingly
longer clock delays with perhaps 100 ps granularity, and use all of them.

Peter Alfke


Article: 28086
Subject: Re: 3V -> 5V clock signal level conversion
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 11:06:58 -0800
Links: << >>  << T >>  << A >>
This is the way I normally describe it:
Drive the internal OE signal with an internal 2-input NAND gate.
One of its inputs is the same signal driving the output buffer, the
other one comes from the input buffer that looks at the output pin
we want to drive.
If you drive a 0, the NAND output is High, output is active.
When you change to driving a 1, the output will first still be below
the threshold, so the output driver stays active for a while, giving
us a fast rise time.
When the output passes through the threshold, the NAND gate output
will go Low, 3-stating the output, and leaving it up to the external
pull-up resistor to finish the job.
Clearly, it is in your interest to make the feedback signal into the
NAND gate reasonably slow, not fast!

Peter Alfke

Kent Orthner wrote:

> Nial,
>
> Something else you *might* consider (I don't know
> how fast your clock is, or how fast a rising edge
>  you need) is using the FPGA to pull up to a 3.3v
> level, and then tristating, letting the resistor
> pull it up the ret of the way.
>
> I think this solution comes from Peter Afke, but
> I'm not sure.
>
> The VHDL process to drive your pins would be as
> follows, assuming that PIN is of type inout, and
> that OUTPUT is the output level that you want.
>
> process (PIN, OUTPUT) is
> begin
>   if OUTPUT = '0' then
>
>     PIN <= '0';
>
>   elsif PIN = '0' then -- This is when OUTPUT is '1,
>                        -- but PIN isn't there yet, so
>     PIN <= '1';        -- you keep driving with the
>                        -- FPGA.
>   else                 -- This is when PIN is above the
>                        -- the FPGA's Vih threshold, and
>     PIN <= 'Z';        -- you let the resistor do the rest
>                        -- of the work.
>   end if;
> end process;
>
> Disclaimer:  I have not done this myself, and I
> don't know if it's a particularly good idea to do it
> with a clock signal.
>
> HTH,
> Kent.
>


Article: 28087
Subject: Re: Samsung SDRAM behavioural models
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 20 Dec 2000 13:28:12 -0700
Links: << >>  << T >>  << A >>
Paul Bateson wrote:

> Q. Why can't manufactures provide the code for their models........

Micron does.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 28088
Subject: Re: FPGA and Board for Microprocessor Design?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 20 Dec 2000 21:34:48 +0100
Links: << >>  << T >>  << A >>
sulimma@my-deja.com writes:

> In article <3A3FA329.C726271@jetnet.ab.ca>,
>   Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote:
> > Simon Gornall wrote:
> > > I'll need to figure out how easy/stable it is when you get rid of
> the
> > > 24MHz clock. Presumably there's a good reason why they've crippled
> it
> > > like this

Cheaper clock chip? This is after all only the default "good for most
users" chip, which can be replaced by "we want max power" users.

Also don't forget that the XC2S chips like the XCV have 4 on-chip DLLs
which can do f*2 and of which pairs can be cascaded (App note says
so). So you can go up to 96MHz with that default Osc.


> > This could be for VGA output. One clock does all.
> As would a 48 MHz or 96 Mhz or 144 MHz Clock. So they really might
> have a problem with the power supply or similar.

The post from Burch also mentioned expansion boards. One of these has
an VGA connector and 3*4bit DACs on it. That board also has an second
24MHz Osc (and an 3.xxxMHz for the RS 232 on it). So the 24MHz on the
main board is not for VGA.

Hmmm. Having 24MHz for the VGA board would make reducing inventory
positions an further reason for an 24MHz default. Given that Burch
seems to be aiming for absolute minimal cost that could be it.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic

Article: 28089
Subject: Re: Question about Xilinx pins at high-frequency
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 20 Dec 2000 13:42:05 -0700
Links: << >>  << T >>  << A >>
David Hawke wrote:
> 
> "Pascal C." wrote:
> 
> > A few things:
> >
> > 1.  for case 1, we did create a 32-bit registered OE and did PAR with the "-pr b" switch.  What tools do you use David? Personnally, I am using Foundation 3.2i.5 (note: I installed SP6 yesterday and MAP crashed pathethically even when started by the GUI!) with FPGA Express 3.4.3.  Is it possible that FPGA Express made it impossible for the PAR to recognize the OEs and place them properly (I did prevent it from merging the logic)?
> >
> 
> I forgot to mention, the other reason that it may not do this, is if you have the logic sense the wrong way round in the code....(therefore requiring a LUT before the Tri) - Can't remember if it is active high or low to HighZ...Think it is high!

David,

According to the Virtex 23 May 2000 datasheet, "The output buffer and
all of the IOB control signals have independent polarity controls." In
fact, a quick peek via FPGA editor shows a four-input mux for the
tristate enable.  This means that you should be able to write the output
enable as either active high or active low, and the synthesis tool
should do the right thing.

> Best thing to do it check the schematic viewer in Synopsys and checking whether there is a LUT in the way....If there is correct the code, and this should work...

Ah, there's the rub.  At least for FPGA Express v3.4 and the XC4KXLA
family, there's a bug: FPGA Express doesn't know about the
polarity-select mux, and if you write your output enable code active
high, an inverter in a CLB is put before the IOB's output enable
control.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 28090
Subject: Re: 3V -> 5V clock signal level conversion
From: "markp" <map@nospam_dial.pipex.com>
Date: Wed, 20 Dec 2000 21:34:17 -0000
Links: << >>  << T >>  << A >>

"Nial Stewart" <nials@sqf.hp.com> wrote in message
news:3A3F3339.AC12CB9E@sqf.hp.com...
> I'm looking at a problem where we need to drive a
> couple of 5V CMOS clock inputs from a SpartanII
> 3v output.
>
> There are data lines being driven from the 3V output,
> we can get away with the 'tristate and pull high
> for logic high' trick, but I don't want to do this with
> the clock signals. The active (rising) edges are
> _very_ slow and the risk of double clocking etc
> would be too high.
>

I guess you mean open collector signals have slow rise times (which they
usually do).  I would suggest using totem pole clock output, series
terminate with 50R or so into the input of a 74ACT device (e.g. 74ACT244),
then series terminating from that gate to your CMOS clock input. I would
also recommend stuffing your data through one of these too. Some of these
devices are available in different speed grades, and some even define skew
between signals.

In my experience series terminating clocks is superior to other forms of
clock termination, but I'll leave that can of worms to another thread!

>
> Space is fairly tight so my immediate thought was
> to use an 8 pin soic dual comparator with the -ve
> input tied to 1.8V (power plane).
>

The above devices are available in QSOP and TSSOP, so shouldn't be that much
larger once all the discretes are taken into account

> My only concern with this is that I think I read a
> while ago that comparators shouldn't be used for this
> sort of application, I can't remember where I read this
> so I can't check if I'm right. It might have been
> because of the lask of hysteresis on the input,
> but if the -ve input is set to a 'clean' part
> of the waveform I don't think we should see
> any problems.
>
> Can anyone think of any drawbacks of using a fast
> comparator for this conversion?

I wouldn't use comparators for this - even fast ones are much slower than
the logic equivalent and it is difficult if not impossible to control skew.
I don't know what the impedance on the line would be as it crosses the
threshold, but if it does change as Robert suggests then there could be
unwanted reflections. I wouldn't take the risk with a clock!

Mark.



Article: 28091
Subject: Re: dual port ram for altera
From: Ray Andraka <ray@andraka.com>
Date: Wed, 20 Dec 2000 21:57:14 GMT
Links: << >>  << T >>  << A >>
Probability of metastability depends on your clock rates too.  If you are the
average Virtex user doing a design between say 20 to 60 MHz, it is not likely to
be a real problem in your system considering the probable time to resolve the
metastable state, which Peter indicates is very unlikely to be 5-10ns (Peter
what parts are we talking about here too, it'll make a difference.  I suspect
the 2.5v virtex-4 parts will have a higher probability.  Anyway, push the clock
rate up to where you are pushing the envelope, and  think metastability is
likely to become a real issue in your system.

That said, even if it is not an issue, you still have to be careful when sending
more than one signal or to more than one destination when crossing an async
clock domain boundary.  Metastability is only half the issue. Ya'll be careful
out there :-)

Peter Alfke wrote:
> 
> Philip Freidin wrote:
> 
> >
> > >Yes. One-bit wide is the special case where it doesn't matter if the data is
> > >corrupted. If both sides write the same, 1 or 0, it will be fine. If the  two
> > >sides differ, then the outcome will be either 1 or 0, which is acceptable. So
> > >in this particular case, you can ignore all precautions.
> > >
> > >Peter Alfke
> > >
> >
> > Ummmmm, I'm not as sure. I believe that if both sides write a bit
> > at the "same" time, and one writes a '0', and one writes a '1'
> > there is a possibility of a metastable. If the two write clocks are
> > the same clock signal, the delta time between the two will be
> > constant, and the circuit will behave the same way probably
> > all the time: either metastable each time, or one of them always
> > wins, or a zero always wins or a one always wins. If the clocks
> > are asynchronous, then as for all metastable situations, there
> > will be some delta delay (clock vs clock) at which the charge
> > injected into the RAM cell will make it metastable. It may resolve
> > befor the next read, or the read may disturb the cell and resolve
> > the metastable.
> 
> This seems to be the season of metastability.
> Ok, so in the absolute worst case scenario the two conflicting simultaneous writes
> leave the cell in the metastable condition. Everybody agrees that it cannot stay
> there very long. I claim that 5 ns is extremely unlikely, 10 ns only once in our
> lifetime. So, unless you read that same location that you just wrote conflicting
> information into ( so you really shouldn't care whether it's a 1 or a 0) within a
> few ns again, everything will be calm and peaceful.
> 
> Phil and I have been friends ( and colleagues at AMD ) for the past 20 years. We
> just have this running battle over the practical ( not the philosophical !)
> aspects of metastability.  Let me establish the probabilities by testing Virtex-II
> in January.
> 
> Peter Alfke, Xilinx Applicationss

-- 
-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  or http://www.fpga-guru.com

Article: 28092
Subject: Re: 3V -> 5V clock signal level conversion
From: Ray Andraka <ray@andraka.com>
Date: Wed, 20 Dec 2000 22:01:52 GMT
Links: << >>  << T >>  << A >>
WOrks as long as 1) you can tolerate the ringing that inevitably occurs when the
driver shuts off, and 2) it is not a wired or bus like you might have with a
processor bus control signal (transfer start in a motorola processor with
multiple masters comes to mind).

Peter Alfke wrote:
> 
> This is the way I normally describe it:
> Drive the internal OE signal with an internal 2-input NAND gate.
> One of its inputs is the same signal driving the output buffer, the
> other one comes from the input buffer that looks at the output pin
> we want to drive.
> If you drive a 0, the NAND output is High, output is active.
> When you change to driving a 1, the output will first still be below
> the threshold, so the output driver stays active for a while, giving
> us a fast rise time.
> When the output passes through the threshold, the NAND gate output
> will go Low, 3-stating the output, and leaving it up to the external
> pull-up resistor to finish the job.
> Clearly, it is in your interest to make the feedback signal into the
> NAND gate reasonably slow, not fast!
> 
> Peter Alfke
> 
> Kent Orthner wrote:
> 
> > Nial,
> >
> > Something else you *might* consider (I don't know
> > how fast your clock is, or how fast a rising edge
> >  you need) is using the FPGA to pull up to a 3.3v
> > level, and then tristating, letting the resistor
> > pull it up the ret of the way.
> >
> > I think this solution comes from Peter Afke, but
> > I'm not sure.
> >
> > The VHDL process to drive your pins would be as
> > follows, assuming that PIN is of type inout, and
> > that OUTPUT is the output level that you want.
> >
> > process (PIN, OUTPUT) is
> > begin
> >   if OUTPUT = '0' then
> >
> >     PIN <= '0';
> >
> >   elsif PIN = '0' then -- This is when OUTPUT is '1,
> >                        -- but PIN isn't there yet, so
> >     PIN <= '1';        -- you keep driving with the
> >                        -- FPGA.
> >   else                 -- This is when PIN is above the
> >                        -- the FPGA's Vih threshold, and
> >     PIN <= 'Z';        -- you let the resistor do the rest
> >                        -- of the work.
> >   end if;
> > end process;
> >
> > Disclaimer:  I have not done this myself, and I
> > don't know if it's a particularly good idea to do it
> > with a clock signal.
> >
> > HTH,
> > Kent.
> >

-- 
-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  or http://www.fpga-guru.com

Article: 28093
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 20 Dec 2000 22:08:07 GMT
Links: << >>  << T >>  << A >>
On 19 Dec 2000 08:39:20 GMT, murray@pa.dec.com (Hal Murray) wrote:

>Speaking of global-reset, how does GSR work on a Virtex?  If I look
>with the FPGA Editor, I don't see any place where GSR connects up
>to a CLB or IOB.
>
>  If I specify an explicit set/reset term, does that replace what GSR
>  does or does it get ORed in with GSR?

OR'ed in

>  Is there an extra input on some SR mux that isn't shown?  Or does GSR
>  get wired up outside the CLB on some path that isn't shown?  Or am I
>  just not looking in the right place?

My guess is that it's an ASIC test structure, ie. it's under the hood
and we don't get to see it. The only concession is that we're allowed
to OR in our own FPGA-level signal, at our own risk.

BTW, the last time I checked both the Virtex and the 4K data sheets
there were no relevant skew timings on GSR. None of the important
numbers are documented. This is, IMO, either (1) unnecessary
embarassment at how slow it is (it has to be slow, I think, or there
would be a large current spike at start-up), or (2) part of a
conspiracy to remove user-level GSR connectivity on future software or
hardware.

>  The SR input to a CLB is also used as a write-enable when the LUT
>  memory is used as a RAM or shift-register.  Do the FFs still get
>  reset by GSR?

They always get set/reset by GSR - the SR input is just an optional
additional term.

Evan

Article: 28094
Subject: Re: Verilog or VHDL
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 20 Dec 2000 22:08:46 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Dec 2000 13:13:58 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>While I distinctly didn't want to start a big argument, I guess it's
>inevitable. The "reg" declaration in Verilog has always been a thorn in my
>side. To the novice, it implies that it will be a register, typically with a
>clock input. Actually, all it means is that the assignment must occur within
>an "always" block. Therefore, some regs are "registers", while others are
>combinational.

Verilog 2000, as you may know, is replacing the term 'register' with
'variable' for exactly this reason. It's before my time, but I suspect
that Verilog's original intention was that the register types should
be used only for coding real registers, and that the net types were
intended for all the combinatorial stuff. It would be interesting to
hear from someone who can remember this far back.

Evan

Article: 28095
Subject: Re: 3V -> 5V clock signal level conversion
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 20 Dec 2000 14:15:07 -0800
Links: << >>  << T >>  << A >>


markp wrote:

> In my experience series terminating clocks is superior to other forms of
> clock termination, but I'll leave that can of worms to another thread!
>

Series termination is great for signals that go from one source to one
destination.
Since the drive impdance is adjusted to match the transmission line Z0, a
half-amplitude signal travels down the line, is reflected at the unterminated
far end to become a full signal "instantaneously", then travels back to the
source, where it is swallowed up in the output impedance = Z0.

Neat trick. It USES the reflection instead of FIGHTING it.

But beware: Never ever (NEVER EVER!) use series termination for a signal that
has to travel to multiple destinations. All but the farthest of these
destinations will see the half-amplitude signal for some time, which is the
worst level possible. Poor noise immunity, double-triggering etc. Ugly stuff.

The best way to terminate a clock that drives multiple loads is to have a
strong ( low-impedance ) driver, then terminate the farthest end of the clock
"snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in
SERIES, and this combination used as a parallel termination)
Make the RC larger than the transition time, but smaller than the clock High or
Low time.
50 Ohm and 100 pF is a proven combination for all but the very fastest clocks.

Peter Alfke, Xilinx Applications


Article: 28096
Subject: Re: Help with encoder/decoder
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 20 Dec 2000 22:27:31 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Dec 2000 13:41:03 +0100, Javier SERRANO
<Javier.Serrano@cern.ch> wrote:

>Hi,
>
>I am looking for an encoder/decoder pair to transmit serial data through
>long distances. There will be one emitter and many receivers, and the
>system cannot accept more than one nanosecond of jitter among receivers,
>that is there can be absolute delay differences from one receiver's
>decoder output to another's, but those differences have to be stable to
>within one ns. On the other hand, I would not like to buy a commercial
>pair of encoder/decoder but rather design my own with an FPGA (I might 
>have to give support for many years). I assume that to get that kind of
>accuracy, I will have to use either an on-chip or an on-board PLL/DLL.
>Does someone know where I can get schematics or text-based designs for
>simple encoders like Manchester or biphase mark? Any good books or URLs
>on the subject?
>
>Thank you very much.
>
>Javier

An excellent place to start is NatSemi's AN808, 'Long transmission
lines and data signal quality':

http://www.national.com/an/AN/AN-808.pdf

This covers various PCM schemes. If you want to spend money, try
Bernard Sklar, Digital Communications, 0-13-211939-0, for starters. He
covers PCM in a couple of pages. Xilinx have an app note on Manchester
coding, but I don't think it covers the digital PLL, which is the only
part of the design which requires any thought.

Evan

Article: 28097
Subject: Re: Samsung SDRAM behavioural models
From: Duane <junkmail@junkmail.com>
Date: Wed, 20 Dec 2000 16:25:02 -0800
Links: << >>  << T >>  << A >>
Paul Bateson wrote:
> 
> Hi,
> 
> Does anyone have  experience with any Samsung SDRAM behavioural models?
> I have been simulating the K4s281632b 128Mbit SDRAM model and I get :
> 
> ** Warning: tRASmax: Maximum Row Active Violation at.....
> 
> The strange thing is that the warning occurs during the power up period where
> there are no commands sent to the SDRAM.
> The warning would make sense if I had activated a row and left it Active for more
> than tRASmax (100us).
> 
> The problem is that Samsung only provide ModelSim compiled libraries, so I can
> not look at the code to see what is happening.
> 
> Q. Has anyone used this model before?
> Q. Is this a bug in the model?
> Q. Are any other bugs in this model I should watch out for.
> 
> Q. Why can't manufactures provide the code for their models........
> 
> Thanks for your time,
> Paul

The Free Model Foundation provides a VHDL model for the Samsung
KM416S4030, which appears to be almost identical, except that it is only
1Mx16x4.

http://vhdl.org/fmf/fmf_public_models/ram/

I have found the FMF stuff to be pretty easy to setup and use.

> 
> --
> Paul Bateson
> Hardware Systems Division
> Silicon & Software Systems
> South County Business Park
> Leopardstown, Dublin 18, IRELAND
> tel: +353-1-207-8913
> fax: +353-1-207-8801
> mailto:paul.bateson@s3group.com
> http://www.s3group.com

--
My real email is akamail.com@dclark (or something like that).

Article: 28098
Subject: Re: 3V -> 5V clock signal level conversion
From: "markp" <map@nospam_dial.pipex.com>
Date: Thu, 21 Dec 2000 00:58:45 -0000
Links: << >>  << T >>  << A >>
Yes, I should have said 'series terminating clocks is superior to other
forms of clock termination for point to point connections'. This is a
subject in its own right, but off topic for this thread so I'll leave it at
that!

Mark.


> Series termination is great for signals that go from one source to one
> destination.
> Since the drive impdance is adjusted to match the transmission line Z0, a
> half-amplitude signal travels down the line, is reflected at the
unterminated
> far end to become a full signal "instantaneously", then travels back to
the
> source, where it is swallowed up in the output impedance = Z0.
>
> Neat trick. It USES the reflection instead of FIGHTING it.
>
> But beware: Never ever (NEVER EVER!) use series termination for a signal
that
> has to travel to multiple destinations. All but the farthest of these
> destinations will see the half-amplitude signal for some time, which is
the
> worst level possible. Poor noise immunity, double-triggering etc. Ugly
stuff.
>
> The best way to terminate a clock that drives multiple loads is to have a
> strong ( low-impedance ) driver, then terminate the farthest end of the
clock
> "snake" with a resistor (=Z0) in series with a capacitor to ground. (RC in
> SERIES, and this combination used as a parallel termination)
> Make the RC larger than the transition time, but smaller than the clock
High or
> Low time.
> 50 Ohm and 100 pF is a proven combination for all but the very fastest
clocks.
>
> Peter Alfke, Xilinx Applications
>



Article: 28099
Subject: Re: Is it necessary to synchronize the reset signal in an FPGA ?
From: murray@pa.dec.com (Hal Murray)
Date: 21 Dec 2000 02:40:38 GMT
Links: << >>  << T >>  << A >>

> They always get set/reset by GSR - the SR input is just an optional
> additional term.

Thanks.  Is that in the documentation someplace?  I don't remember
seeing it and it's the sort of detail I think I would remember.


> BTW, the last time I checked both the Virtex and the 4K data sheets
> there were no relevant skew timings on GSR. None of the important
> numbers are documented.

Why are you interested in skew?  Suppose the skew is 1 ns but the
prop time is somewhere between 0 and 20.  How do I use GSR if my clock
time is 10 ns?


My copy of the VirtexE data sheet has some GSR data: GSR to Pad,
is on the bottom of the IOB Output Switching, Table 21.  There is
a similar number a few pages earlier for GSR to IQ on the input
side.

Yes, similar data for CLBs and RAMs would be helpful.

  (DS022 v1.6, Aug 2000)
-- 
These are my opinions, not necessarily my employers.  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
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