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 111050

Article: 111050
Subject: Re: A spectre is haunting this newsgroup, the spectre of metastability
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Sat, 28 Oct 2006 00:04:30 +0200
Links: << >>  << T >>  << A >>
Applause!!!

Article: 111051
Subject: A pre-emptive strike against blaming the chip
From: PeteS <peter.smith8380@ntlworld.com>
Date: Fri, 27 Oct 2006 22:09:00 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> To paraphrase Karl Marx:
> A spectre is haunting this newsgroup, the spectre of metastability.
> Whenever something works unreliably, metastability gets the blame. But
> the problem is usually elsewhere.
> 
> Metastability causes a non-deterministic extra output delay, when a
> flip-flop's D input changes asynchronously, and happens to change
> within an extremely narrow capture window (a tiny fraction of a
> femtosecond !). This capture window is located at an unknown (and
> unstable) point somewhere within the set-up time window specified in
> the data sheet. The capture window is billions of times smaller than
> the specified set-up time window. The likelihood of a flip-flop going
> metastable is thus extremely small. The likelihood of a metastable
> delay longer than 3 ns is even less.
> As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
> clock, causes an extra 3 ns delay statistically once every billion
> years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
> ten times more often, once every 100 million years.
> But a 2.5 ns delay happens a million times more often !
> See the Xilinx application note XAPP094
> You should worry about metastability only when the clock frequency is
> so high that a few ns of extra delay out of the synchronizer flip-flop
> might causes failure. The recommended standard procedure,
> double-synchronizing in two close-by flip-flops, solves those cases.
> Try to avoid clocking synchronizers at 500 MHz or more...
> So much about metastability.
> 
> The real cause of problems is often the typical mistake, when a
> designer feeds an asynchronous input signal to more than one
> synchronizer flip-flop in parallel, (or an asynchronous byte to a
> register, without additional handshake) in the mistaken believe that
> all these flip-flops will synchronize the input on the same identical
> clock edge.
> This might work occasionally, but sooner or later subtle difference in
> routing delay or set-up times will make one flip-flop use one clock
> edge, and another flip-flop use the next clock edge. Depending on the
> specific design, this might cause a severe malfunction.
> Rule #1: Never feed an asynchronous input into more than one
> synchronizer flip-flop. Never ever.
> 
> Peter Alfke
> 

First, I fully agree that metastability is a very rare issue, and if it 
_does_ occur, it is because the designer has not guarded against it. Yes 
- the designer has a responsibility to meet the setup and hold times 
(which will help prevent such issues).

Second, metastability, as a potential problem, _does_ exist in any FF 
based system, by definition. See point number 1.

So I agree with Peter Afke on this. I understand why the thread was 
named that way too :)

I've noticed the large number of recent threads 'blaming' purported 
metastability issues for problems, but at (for instance) 10MHz, a 
metastability issue would only show up in the occasional few million or 
so transactions (at an absolute maximum, and then only a few times at 
that rate).

So if there's a problem with your design throwing bad data at a rate of 
1 in a million or so, check your timing. It's highly unlikely to be 
metastability.

I have had *true* metastable problems (where an output would float, 
hover, oscillate and eventually settle after some 10s of 
*milliseconds*), but those I have seen recently don't qualify :)

Cheers

PeteS



Article: 111052
Subject: Re: A spectre is haunting this newsgroup, the spectre of metastability
From: John Kortink <kortink@inter.nl.net>
Date: Sat, 28 Oct 2006 00:24:48 +0200
Links: << >>  << T >>  << A >>

On 27 Oct 2006 14:25:09 -0700, "Peter Alfke" <peter@xilinx.com> wrote:

>To paraphrase Karl Marx:
>A spectre is haunting this newsgroup, the spectre of metastability.
>Whenever something works unreliably, metastability gets the blame. But
>the problem is usually elsewhere.

In my experience, ground bounce is a bigger problem.
Especially in a device that is nearly 'full' it is
wise to invest in a few fabricated grounds (dedicate
a pin at a strategic location, i.e. as far away as
possible from other ground pins, drive it to ground,
and tie it to ground externally).

When you find that moving cells around alleviates or
intensifies observed instabilities, you may want to
look into ground bounce problems.

>Metastability causes a non-deterministic extra output delay, when a
>flip-flop's D input changes asynchronously, and happens to change
>within an extremely narrow capture window (a tiny fraction of a
>femtosecond !). This capture window is located at an unknown (and
>unstable) point somewhere within the set-up time window specified in
>the data sheet. The capture window is billions of times smaller than
>the specified set-up time window. The likelihood of a flip-flop going
>metastable is thus extremely small. The likelihood of a metastable
>delay longer than 3 ns is even less.
>As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz
>clock, causes an extra 3 ns delay statistically once every billion
>years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs
>ten times more often, once every 100 million years.
>But a 2.5 ns delay happens a million times more often !
>See the Xilinx application note XAPP094
>You should worry about metastability only when the clock frequency is
>so high that a few ns of extra delay out of the synchronizer flip-flop
>might causes failure. The recommended standard procedure,
>double-synchronizing in two close-by flip-flops, solves those cases.

I've found that one synchronizing flip-flop was not enough
in one particular case (from a 4-ish to 50-ish MHz domain).
Two was. Does one ever work reliably ? Or has the 'window'
become smaller in the past few years ?


John Kortink
Windfall Engineering

-- 

Email    : kortink@inter.nl.net
Homepage : http://www.windfall.nl

Your hardware/software designs realised !


Article: 111053
Subject: A spectre is haunting this newsgroup, the spectre of metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Oct 2006 15:30:01 -0700
Links: << >>  << T >>  << A >>

To paraphrase Karl Marx:
A spectre is haunting this newsgroup, the spectre of metastability.
Whenever something works unreliably, metastability gets the blame. But
the problem is usually elsewhere.

Metastability causes a non-deterministic extra output delay, when a
flip-flop's D input changes asynchronously, and happens to change
within an extremely narrow capture window (a tiny fraction of a
femtosecond !). This capture window is located at an unknown (and
unstable) point somewhere within the set-up time window specified in
the data sheet. The capture window is millions of times smaller than
the specified set-up time window. The likelihood of a flip-flop going
metastable is thus extremely small. The likelihood of a metastable
delay longer than 3 ns is even smaller.
As an example, a close-to 1 MHz asynchronous signal, synchronized by a
100 MHz clock, causes an extra 3 ns metastable delay statistically once
every billion years. If the asynchronous event is at ~10 MHz, the 3 ns
delay occurs ten times more often, once every 100 million years.
But a 2.5 ns delay happens a million times more often !
See the Xilinx application note XAPP094
You should worry about metastability only when the clock frequency is
so high that a few ns of extra delay out of the synchronizer flip-flop
might causes failure. The recommended standard procedure,
double-synchronizing in two close-by flip-flops, solves those cases.
Try not to use a 500 MHz clock to capture asynchronous inputs...
So much about metastability.

Much more common is the typical oversight, when a designer feeds an
asynchronous input signal to more than one synchronizer flip-flop in
parallel, in the mistaken believe that all these flip-flops will
synchronize the input on the same identical clock edge. Or feed an
asynchronous byte into an eight-bit register, without any additional
handshake.
This might work occasionally, but sooner or later subtle difference in
routing delay or set-up times will make one flip-flop use one clock
edge, and another flip-flop use the following clock edge. Depending on
the specific design, this might cause a severe malfunction.
Rule #1: Never feed asynchronous inputs into more than one synchronizer
flip-flop. Never ever.

Peter Alfke


Article: 111054
Subject: Usage of RAMB16 prmitives
From: "Bhanu Chandra" <vbhanu@gmail.com>
Date: 27 Oct 2006 15:47:27 -0700
Links: << >>  << T >>  << A >>
Hi,

I am trying to make a multi core processor design on  board of virtex 4
family. I have 2 processors so i believe that I would need 2 local
memory units, that is two BRAM blocks. One for each of the processor.

What is happening is when i am synthesizing the design I find that I am
using more number of RAMB16 primitives than what are there on the
board. I am using 52 while there are just 36 on the board.

I am using Xilinx Platform Studio for this purpose. It computes the
BRAM block size, Address Width and Data Width on it's own. I am not
sure if there is some way I can configure this.

Please tell me how I can reduce the number of RAMB16 primitives that I
am using.


Thanks in Advance,

Bhanu

P.S: Board I am using is ML403 board.


Article: 111055
Subject: Re: A pre-emptive strike against blaming the chip
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 28 Oct 2006 11:48:40 +1300
Links: << >>  << T >>  << A >>
PeteS wrote:

> 
> I have had *true* metastable problems (where an output would float, 
> hover, oscillate and eventually settle after some 10s of 
> *milliseconds*), but those I have seen recently don't qualify :)

Can you clarify the device/process/circumstances ?

-jg


Article: 111056
Subject: Re: A pre-emptive strike against blaming the chip
From: PeteS <peter.smith8380@ntlworld.com>
Date: Fri, 27 Oct 2006 22:52:58 GMT
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> PeteS wrote:
> 
>>
>> I have had *true* metastable problems (where an output would float, 
>> hover, oscillate and eventually settle after some 10s of 
>> *milliseconds*), but those I have seen recently don't qualify :)
> 
> 
> Can you clarify the device/process/circumstances ?
> 
> -jg
> 

This was a discrete design with FETs that I was asked to test (at a 
customer site). The feedback loop was not particularly well done, so 
when metastability did occur, it was spectacular.

Cheers

PeteS

Article: 111057
Subject: Re: Survey: simulator usage
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 27 Oct 2006 15:53:42 -0700
Links: << >>  << T >>  << A >>
Evan Lavelle wrote:
> Those of you with long memories may recall coding devices in ABEL. One
> nice thing about ABEL was that you could write very simple vector
> files to simulate your device, where a vector was something like
>
> [C,1,0,1,etc] -> [1,1,0,1,HHHH,01AB,etc]
>
> ie. setup some inputs, apply a clock pulse, and check some outputs.
> I've written some software over the years that lets me do the same
> thing in VHDL, with various extensions, and I use it to test most of
> my RTL code. It's simple, you don't need to write or know *any* VHDL
> to use it, and it gives you a pass/fail very quickly, for a module or
> a whole device.

This sort of test-vector entry is basically unmaintainable, and to be
honest, I haven't written this type of go/no-go test in ages (maybe
since the last time I used ABEL).

I prefer to write test benches at a higher level.  I like to have
models of the things to which the DUT connects drive the DUT.  For
example, if my FPGA is a NAND flash controller that sits between a
microprocessor bus and the NAND flash devices, I'll use a
bus-functional model of the micro and the flash, and my test bench will
mostly consist of MicroWriteBus() and MicroReadBus() "commands."

I can't go back to the simple drive-a-vector test.

-a


Article: 111058
Subject: Re: FPGA-based music synthesizer (with MyHDL)
From: "Jawbreaker" <george@gammaburst.net>
Date: 27 Oct 2006 16:09:50 -0700
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:
> Jan Decaluwe wrote:
> (snip)
> > description language. This project demonstrates that this technology
> > is real and practical.
>

> Not really, I know a guy that built a SID clone using mostly 74xxx
> parts. I also know another guy that wrote his own schematic capture in
> order to design, thats right, a SID clone. Does this demonstrates that
> their technology was real and practical?
>

Jan is talking about MyHDL itself, not PhoenixSID per se. Perhaps he
could have been clearer.

That said, rest assured my project is real; I even took it on the road
and did a live demonstration of it at UMass Lowell (and got paid for it
to boot). I'm still working on the practical part ;-) And I know I'll
get there!

> That page has been there for a long while.

Even a basic glance at the project page would show that I've been
putting in steady
effort over many months of my spare time, following through on my idea,
which also
has consistently been demo-ready even while under development.

>And I am still waiting for the source code so I can form my own opinion.

1) I have no idea who you are. Someone did ask me for it, but
it surely was a different person. They were quite polite and
respectful.

2) Who said you had to wait for the PhoenixSID source code to get a
feel for MyHDL?

It's not that hard to try it yourself.
Hell, all the tools are free: Python, MyHDL, even Xilinx WebPACK ISE
The Digilent Spartan3 board can be had for as little as $99.

The MyHDL cookbook (easily accessible from the front page of the Wiki)
contains examples that range from simple D-flip flops all the way to a
Cordic Sine Computer and a recursive Bitonic Sorter.

The tutorials are rich in detail and insight. The knowledge they
contain can readily be used to make your own, more complex designs.
Often, the full design flow from MyHDL->Verilog->FPGA (including unit
tests) is shown.

Try starting off with a blinking LED demo. That's what worked for me.

3)
I spent months of my free time working hard and continually learning to
create PhoenixSID, and I had tons of fun in the process.

I learned far, far more than how to build a "SID clone".
Among the things I've learned are serious Python skills, digital
hardware design, analog hardware design, synthesizer design, widely
applicable engineering skills, problem solving, stress management, how
to stay motivated and follow through on a long-term, difficult goal,
people and presentation skills, how to combine my love of music with my
love of electronics and engineering in a productive way and I even had
some valuable insights about life in general along the way.

Why do you feel entitled to my source code? What have you contributed?

Even though I'm still considering my license options I still want to
share my knowledge somehow. So, in the meantime, I'd like to write some
tutorials for the website. Also, I'm working on the MyHDL Booster
package (see below), which will be open and free. I'm a busy person so
that may be a little while still.

Also, I'm planning a huge improvement to PhoenixSID that requires
significantly more complexity in the hardware invloved. Rather than
blindly jump into that, I've been  experimenting with techniques to
simplify and streamline the process and make it much more fun.

To make sure MyHDL Booster will be applicable to a real project and not
just an academic exercise, I'm working on it in tandem with real,
synthesizable, working examples, (including the next upgrade to
PhoenixSID) and using the feedback to improve MyHDL Booster. This takes
time, effort, imagination, insight, patience and persistence.


George, are you
> listening?
>

Besides all the work mentioned above, I've been holding down a
full-time engineering job with a major company, practicing guitar,
taking voice lessons, playing in a band and keeping up an active social
life.

I don't have time for people who troll newsgroups instead of offering
constructive feedback.

Be clear, respectful and specific with your questions and feedback, do
your homework and have something to offer.

Then we'll talk.

Rock on,
George Pantazopoulos
http://www.gammaburst.net


Article: 111059
Subject: Re: A spectre is haunting this newsgroup, the spectre of metastability
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Oct 2006 16:22:18 -0700
Links: << >>  << T >>  << A >>
Our server did strange things, like filing my (long) posting twice...

The numbers I quoted are from experiments with VirtexIIPro, a few years
ago. (XAPP094)
So it's modern, but not very modern.
Old horror stories of millisecond oscillations must have been based on
TTL circuits, where there are multiple slow stages in the master-latch
feedback loop (the only participant in metastability delays).Modern
CMOS flip-flops are much simpler, and I have never heard about them
oscillating due to metastability.
There is a human tendency to blame every evil on the mystery du jour.
Metastability is not mysterious, but it is rare and non-deterministic,
which bothers some people...
I agree that ground bounce a.k.a. simultaneously switching outputs
(SSOs) is a far nastier problem.
Peter Alfke

Peter Alfke wrote:
> To paraphrase Karl Marx:
> A spectre is haunting this newsgroup, the spectre of metastability.
> Whenever something works unreliably, metastability gets the blame. But
> the problem is usually elsewhere.
>
> Metastability causes a non-deterministic extra output delay, when a
> flip-flop's D input changes asynchronously, and happens to change
> within an extremely narrow capture window (a tiny fraction of a
> femtosecond !). This capture window is located at an unknown (and
> unstable) point somewhere within the set-up time window specified in
> the data sheet. The capture window is millions of times smaller than
> the specified set-up time window. The likelihood of a flip-flop going
> metastable is thus extremely small. The likelihood of a metastable
> delay longer than 3 ns is even smaller.
> As an example, a close-to 1 MHz asynchronous signal, synchronized by a
> 100 MHz clock, causes an extra 3 ns metastable delay statistically once
> every billion years. If the asynchronous event is at ~10 MHz, the 3 ns
> delay occurs ten times more often, once every 100 million years.
> But a 2.5 ns delay happens a million times more often !
> See the Xilinx application note XAPP094
> You should worry about metastability only when the clock frequency is
> so high that a few ns of extra delay out of the synchronizer flip-flop
> might causes failure. The recommended standard procedure,
> double-synchronizing in two close-by flip-flops, solves those cases.
> Try not to use a 500 MHz clock to capture asynchronous inputs...
> So much about metastability.
>
> Much more common is the typical oversight, when a designer feeds an
> asynchronous input signal to more than one synchronizer flip-flop in
> parallel, in the mistaken believe that all these flip-flops will
> synchronize the input on the same identical clock edge. Or feed an
> asynchronous byte into an eight-bit register, without any additional
> handshake.
> This might work occasionally, but sooner or later subtle difference in
> routing delay or set-up times will make one flip-flop use one clock
> edge, and another flip-flop use the following clock edge. Depending on
> the specific design, this might cause a severe malfunction.
> Rule #1: Never feed asynchronous inputs into more than one synchronizer
> flip-flop. Never ever.
> 
> Peter Alfke


Article: 111060
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 27 Oct 2006 16:40:54 -0700
Links: << >>  << T >>  << A >>

> The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR
> type) cable.

Yes I thought it was a no brainer.

>I currently have a design using a V2PRO30 that drives 5m of cable.  The 
>differential pins are driven by the below module.

I think my VHDL is similar. What is your FPGA editor showing
when you go to those pins? Mine shows two pads, a master and
a slave. When I push into these pads I don't see any options
checked. Do you have additional stuff in your UCF file?

Thanks,
Brad Smallridge

>
> Take care,
> Rob
>
>
> module diff_outbuf_single(in, p_out, n_out);
>    input in;
>    output p_out;
>    output n_out;
>
>  OBUFDS inst1 (
>      .O(p_out),   // Diff_p output(connect directly to top-level port)
>      .OB(n_out), // Diff_n output (connect directly to top-level port)
>      .I(in)    // Buffer input
>    );
>
> endmodule
>
>
> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
> news:12k1op3ddh0iea@corp.supernews.com...
>> Can anyone tell me what I need to drive a Camera Link
>> output directly from a V4? I have tried LVCMOS25 and I
>> can see differential signals at the outputs but at the
>> end of a 2 meter cable I see only DC differential levels
>> as if the signals are dampened somehow.
>>
>> Brad Smallridge
>> aivision
>>
>>
>
> 



Article: 111061
Subject: Re: A pre-emptive strike against blaming the chip
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 28 Oct 2006 12:53:25 +1300
Links: << >>  << T >>  << A >>
PeteS wrote:
> Jim Granville wrote:
> 
>> PeteS wrote:
>>
>>>
>>> I have had *true* metastable problems (where an output would float, 
>>> hover, oscillate and eventually settle after some 10s of 
>>> *milliseconds*), but those I have seen recently don't qualify :)
>>
>> Can you clarify the device/process/circumstances ?
>>
>> -jg
>>
> 
> This was a discrete design with FETs that I was asked to test (at a 
> customer site). The feedback loop was not particularly well done, so 
> when metastability did occur, it was spectacular.

Do you mean they built a D-FF, using discrete FETS ?!

I have seen transistion oscillations (slow edges) cause very strange 
effects in Digital Devices, but I'd not call that effect metastability.

-jg


Article: 111062
Subject: Question about generic usage?
From: "fl" <rxjwg98@gmail.com>
Date: 27 Oct 2006 17:18:50 -0700
Links: << >>  << T >>  << A >>
Hi,
I am learning VHDL from Mike's example Uart.vhd in ISE 8.2. For
behavioral simulation, I can run Modelsim smoothly. But for other
simulation, such as post-translate or post-route simulation, there are
the following warnings:

# Reading C:/Modeltech_xe_starter/tcl/vsim/pref.tcl
# do {test_uart.ndo}
# ** Warning: (vlib-34) Library already exists at "work".
# Model Technology ModelSim XE III vcom 6.1e Compiler 2006.03 Mar  8
2006
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading package vital_primitives
# -- Loading package textio
# -- Loading package vpackage
# -- Compiling entity uart
# -- Compiling architecture structure of uart
# Model Technology ModelSim XE III vcom 6.1e Compiler 2006.03 Mar  8
2006
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package numeric_std
# -- Loading package uart_pkg
# -- Compiling entity test_uart
# -- Compiling architecture sim of test_uart
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading package vital_primitives
# -- Loading package textio
# -- Loading package vpackage
# -- Loading entity uart
# ** Error: test_uart.vhd(110): (vcom-1136) Unknown identifier
"char_len_g".
# ** Error: test_uart.vhd(111): (vcom-1136) Unknown identifier
"tic_per_bit_g".
# ** Error: test_uart.vhd(407): VHDL Compiler exiting
# ** Error: C:/Modeltech_xe_starter/win32xoem/vcom failed.
# Error in macro ./test_uart.ndo line 7
# C:/Modeltech_xe_starter/win32xoem/vcom failed.
#     while executing
# "vcom -explicit  -93 "test_uart.vhd""

After I check the library work, I find the work.uart (for other than
behavioral simulation) does not have char_len_g anymore (only the
source, i.e. behavioral file has that generic definition). How to deal
with this?


Thank you in advance.





>From test_uart.vhd:

begin  -- architecture sim
   dut : entity work.uart
     generic map (char_len_g    => tb_char_g, -- for vsim command line
overload
                  tic_per_bit_g => tb_tics_g)


Article: 111063
Subject: Re: A pre-emptive strike against blaming the chip
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Oct 2006 17:32:55 -0700
Links: << >>  << T >>  << A >>
Well, in the beginning of my professional life, I built flip-flops out
of two Ge transistors, 8 resistors, two diodes and two capacitors.
Remember, the term J-K flip-flop comes from a standardized sinle-FF
pc-board where the connector oins were labeled A-Z, and the set and
reset inputs were on the adjacent central pins J and K.
Not a joke...
Peter Alfke

On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> PeteS wrote:
> > Jim Granville wrote:
>
> >> PeteS wrote:
>
> >>> I have had *true* metastable problems (where an output would float,
> >>> hover, oscillate and eventually settle after some 10s of
> >>> *milliseconds*), but those I have seen recently don't qualify :)
>
> >> Can you clarify the device/process/circumstances ?
>
> >> -jg
>
> > This was a discrete design with FETs that I was asked to test (at a
> > customer site). The feedback loop was not particularly well done, so
> > when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?!
>
> I have seen transistion oscillations (slow edges) cause very strange
> effects in Digital Devices, but I'd not call that effect metastability.
> 
> -jg


Article: 111064
Subject: On the Futility of Documentation Webcases ( Was: Xilinx documentation typos )
From: "Brian Davis" <brimdavis@aol.com>
Date: 27 Oct 2006 17:42:39 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
>
>This is the official answer from our support organization:
<snip>
> "use our great WebCase tool"
>
 Describing WebCase as "great" for documentation errors
is (cough, hack) a bit of a stretch; have you ever filed one ?

  ( If not, the next time you find and report, say, a particularly
sneaky FIFO flag bug, wait a few months for your internal
paperwork mill to grind- then pseudonymously file a WebCase
describing exactly that same problem, and see what happens... )

 Filing documentation error reports through a WebCase
is particularly time consuming and pointless;
my experience has been that Xilinx essentially refuses
to fix the documentation problems no matter how
painstakingly detailed the report.

 The WebCase will be closed as rapidly as possible by Xilinx,
possibly without the first responder even understanding the
documentation problem.

 If you are persistent, you can get some CR's filed, at which
point the WebCase will then be closed; none of that persistence
will result in any good, as the CR's then vanish into the mists.

 Post-WebCase, nothing happens:
  - datasheet errors and omissions persist
  - Answer Records remain incorrect
  - software bugs remain
    ( or perhaps worse, reappear in a version or two )

 At best, years later there may appear a cryptic Answer Record
or an indecipherable footnote that bears almost no resemblance
to the original problem report.

  AFAIK, there's no way to track a CR's status without
opening a new WebCase and asking again; if you're lucky,
the link on your WebCase history page may actually display
the old WebCase text without locking up your browser.

 And to top it all off, if you then post a summary of said
problems here on comp.arch.fpga, you run the risk of being
flamed by Xilinx's own Troll of Implausible Deniability.

Brian


Article: 111065
Subject: Re: Xilinx Virtex4 Outputs for Camera Link
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 28 Oct 2006 01:54:03 GMT
Links: << >>  << T >>  << A >>
I see the same thing you do within the editor, master and slave pads.  Both 
pads have an IO standard of LVDS_25.  I have nothing else in my UCF file 
pertaining to these pins.

Is you sure your bank voltage being powered by 2.5V?

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
news:12k56ahdpboge63@corp.supernews.com...
>
>> The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR
>> type) cable.
>
> Yes I thought it was a no brainer.
>
>>I currently have a design using a V2PRO30 that drives 5m of cable.  The 
>>differential pins are driven by the below module.
>
> I think my VHDL is similar. What is your FPGA editor showing
> when you go to those pins? Mine shows two pads, a master and
> a slave. When I push into these pads I don't see any options
> checked. Do you have additional stuff in your UCF file?
>
> Thanks,
> Brad Smallridge
>
>>
>> Take care,
>> Rob
>>
>>
>> module diff_outbuf_single(in, p_out, n_out);
>>    input in;
>>    output p_out;
>>    output n_out;
>>
>>  OBUFDS inst1 (
>>      .O(p_out),   // Diff_p output(connect directly to top-level port)
>>      .OB(n_out), // Diff_n output (connect directly to top-level port)
>>      .I(in)    // Buffer input
>>    );
>>
>> endmodule
>>
>>
>> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
>> news:12k1op3ddh0iea@corp.supernews.com...
>>> Can anyone tell me what I need to drive a Camera Link
>>> output directly from a V4? I have tried LVCMOS25 and I
>>> can see differential signals at the outputs but at the
>>> end of a 2 meter cable I see only DC differential levels
>>> as if the signals are dampened somehow.
>>>
>>> Brad Smallridge
>>> aivision
>>>
>>>
>>
>>
>
> 



Article: 111066
Subject: Re: Survey on Quartus SOPC/Nios-II
From: "Chris" <nospam@nospam.com>
Date: Fri, 27 Oct 2006 19:21:17 -0700
Links: << >>  << T >>  << A >>
> require less than 1,000 writes, you could use the flash.

It's not a matter of the number of writes.  It is a matter of where to
write.  I don't need to change the flash bits that control the FPGA, I need
other flash area that is unused by the FPGA.  They tell me that in the XO
and XP all of the flash bits are used to config the FPGA.  There is no extra
space.  If I write in that, then the FPGA logic will be messed up.

>  since you want to turn off the part and reconfigure?

No, I don't want to recofigure the FPGA.  I need to store serial numbers and
calibration data on the product somewhere.  The FPGA code itself is not
going to change.

The point is this:  Lattice thinks that it's a big advantage having built-in
flash that you don't need an external memory part like the Altera or Xlinix.
Well that's only true if you don't need to store some other stuff in NV
memory also.  If you do, then the advantage is lost because you have to add
an external memory anyway.  Whether the external mem chip is $0.40 (8K
EEPROM) or $0.75 (1M-SPI) is no big deal.  It doesn't save much, and no
board space at all.  Lattice would have been miles ahead if they would have
left some extra space besides what the FPGA uses in their onboard flash.

They now know that all too well, and in the XP-II parts coming out next
quarter there will be extra flash space.

The big advantage Lattice has right now is single supply.  That may make the
difference between a 4 layer board and double sided board in my case, and
that difference pays for the entire FPGA.  That is a real big deal.  Single
supply is probably the most cost saving feature in these cases where a
multilayer board is not needed for much else than the FPGA.

Thanks,  Chris.



Article: 111067
Subject: Re: On the Futility of Documentation Webcases ( Was: Xilinx documentation typos )
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 27 Oct 2006 19:55:06 -0700
Links: << >>  << T >>  << A >>
Brian, in spite of (or because of) your nasty tone, I will on Monday
submit this to the responsible group in Xilinx support.
Just a few comments:
Not everything is just a documentation fault.

The unfortunate and very subtle Virtex-4 FIFO flag problem haunted us
for many weeks, until we had found the cause and a barely acceptable
work-around. (I was in the middle of it, and still have the mental
scars). The System Monitor design had a subtle problem that caused us
to delete it from Virtex-4 documentation. Now that it is fixed, we
re-introduced it in Virtex-5LXT. And Virtex-4FXMGTs had more than their
share of difficulties...
As FPGAs have changed from being a "homogeneous sandbox" to a diverse
mixture of highly complex and specific system blocks, the testing,
guaranteeing and documenting of operation under a wide variety of user
circumstances has become increasingly challenging.
You can be sure that we try our best, even when that sometimes is not
good enough.

Peter Alfke, definitely not a "Troll of Implausible Deniability".
====================================
On Oct 27, 5:42 pm, "Brian Davis" <brimda...@aol.com> wrote:
> Peter Alfke wrote:
>
> >This is the official answer from our support organization:
> <snip>
> > "use our great WebCase tool" Describing WebCase as "great" for documentation errors
> is (cough, hack) a bit of a stretch; have you ever filed one ?
>
>   ( If not, the next time you find and report, say, a particularly
> sneaky FIFO flag bug, wait a few months for your internal
> paperwork mill to grind- then pseudonymously file a WebCase
> describing exactly that same problem, and see what happens... )
>
>  Filing documentation error reports through a WebCase
> is particularly time consuming and pointless;
> my experience has been that Xilinx essentially refuses
> to fix the documentation problems no matter how
> painstakingly detailed the report.
>
>  The WebCase will be closed as rapidly as possible by Xilinx,
> possibly without the first responder even understanding the
> documentation problem.
>
>  If you are persistent, you can get some CR's filed, at which
> point the WebCase will then be closed; none of that persistence
> will result in any good, as the CR's then vanish into the mists.
>
>  Post-WebCase, nothing happens:
>   - datasheet errors and omissions persist
>   - Answer Records remain incorrect
>   - software bugs remain
>     ( or perhaps worse, reappear in a version or two )
>
>  At best, years later there may appear a cryptic Answer Record
> or an indecipherable footnote that bears almost no resemblance
> to the original problem report.
>
>   AFAIK, there's no way to track a CR's status without
> opening a new WebCase and asking again; if you're lucky,
> the link on your WebCase history page may actually display
> the old WebCase text without locking up your browser.
>
>  And to top it all off, if you then post a summary of said
> problems here on comp.arch.fpga, you run the risk of being
> flamed by Xilinx's own Troll of Implausible Deniability.
> 
> Brian


Article: 111068
Subject: Re: Survey on Quartus SOPC/Nios-II
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 28 Oct 2006 16:19:39 +1300
Links: << >>  << T >>  << A >>
Chris wrote:
>>require less than 1,000 writes, you could use the flash.
> 
> 
> It's not a matter of the number of writes.  It is a matter of where to
> write.  I don't need to change the flash bits that control the FPGA, I need
> other flash area that is unused by the FPGA.  They tell me that in the XO
> and XP all of the flash bits are used to config the FPGA.  There is no extra
> space.  If I write in that, then the FPGA logic will be messed up.
> 
> 
>> since you want to turn off the part and reconfigure?
> 
> 
> No, I don't want to recofigure the FPGA.  I need to store serial numbers and
> calibration data on the product somewhere.  The FPGA code itself is not
> going to change.

  Lattice offer Soft CPUs like the Mico8 and they need to store the 
Opcodes in ROM. That means there must be an Opcode-> ROM pathway, for
their parts ( ie using BRAM as ROM ).
  Why not look at the Mico8 flows for that, and put your 
Serial#/Calibration infos into the psuedo ROM space ?

-jg



Article: 111069
Subject: Re: FPGA-based music synthesizer (with MyHDL)
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 27 Oct 2006 21:30:34 -0700
Links: << >>  << T >>  << A >>

Jawbreaker wrote:
> burn.sir@gmail.com wrote:
> > Jan Decaluwe wrote:
> > (snip)
> > > description language. This project demonstrates that this technology
> > > is real and practical.
> >
>
> > Not really, I know a guy that built a SID clone using mostly 74xxx
> > parts. I also know another guy that wrote his own schematic capture in
> > order to design, thats right, a SID clone. Does this demonstrates that
> > their technology was real and practical?
> >
>
> Jan is talking about MyHDL itself, not PhoenixSID per se. Perhaps he
> could have been clearer.
>
> That said, rest assured my project is real; I even took it on the road
> and did a live demonstration of it at UMass Lowell (and got paid for it
> to boot). I'm still working on the practical part ;-) And I know I'll
> get there!
>
> > That page has been there for a long while.
>
> Even a basic glance at the project page would show that I've been
> putting in steady
> effort over many months of my spare time, following through on my idea,
> which also
> has consistently been demo-ready even while under development.
>
> >And I am still waiting for the source code so I can form my own opinion.
>
> 1) I have no idea who you are. Someone did ask me for it, but
> it surely was a different person. They were quite polite and
> respectful.
>
> 2) Who said you had to wait for the PhoenixSID source code to get a
> feel for MyHDL?
>
> It's not that hard to try it yourself.
> Hell, all the tools are free: Python, MyHDL, even Xilinx WebPACK ISE
> The Digilent Spartan3 board can be had for as little as $99.
>
> The MyHDL cookbook (easily accessible from the front page of the Wiki)
> contains examples that range from simple D-flip flops all the way to a
> Cordic Sine Computer and a recursive Bitonic Sorter.
>
> The tutorials are rich in detail and insight. The knowledge they
> contain can readily be used to make your own, more complex designs.
> Often, the full design flow from MyHDL->Verilog->FPGA (including unit
> tests) is shown.
>
> Try starting off with a blinking LED demo. That's what worked for me.
>
> 3)
> I spent months of my free time working hard and continually learning to
> create PhoenixSID, and I had tons of fun in the process.
>
> I learned far, far more than how to build a "SID clone".
> Among the things I've learned are serious Python skills, digital
> hardware design, analog hardware design, synthesizer design, widely
> applicable engineering skills, problem solving, stress management, how
> to stay motivated and follow through on a long-term, difficult goal,
> people and presentation skills, how to combine my love of music with my
> love of electronics and engineering in a productive way and I even had
> some valuable insights about life in general along the way.
>
> Why do you feel entitled to my source code? What have you contributed?
>
> Even though I'm still considering my license options I still want to
> share my knowledge somehow. So, in the meantime, I'd like to write some
> tutorials for the website. Also, I'm working on the MyHDL Booster
> package (see below), which will be open and free. I'm a busy person so
> that may be a little while still.
>
> Also, I'm planning a huge improvement to PhoenixSID that requires
> significantly more complexity in the hardware invloved. Rather than
> blindly jump into that, I've been  experimenting with techniques to
> simplify and streamline the process and make it much more fun.
>
> To make sure MyHDL Booster will be applicable to a real project and not
> just an academic exercise, I'm working on it in tandem with real,
> synthesizable, working examples, (including the next upgrade to
> PhoenixSID) and using the feedback to improve MyHDL Booster. This takes
> time, effort, imagination, insight, patience and persistence.
>
>
> George, are you
> > listening?
> >
>
> Besides all the work mentioned above, I've been holding down a
> full-time engineering job with a major company, practicing guitar,
> taking voice lessons, playing in a band and keeping up an active social
> life.
>
> I don't have time for people who troll newsgroups instead of offering
> constructive feedback.
>
> Be clear, respectful and specific with your questions and feedback, do
> your homework and have something to offer.
>
> Then we'll talk.
>
> Rock on,
> George Pantazopoulos
> http://www.gammaburst.net

Hey I must congratulate you. The SID was one of the best sounding
synthesizer chips during the early 80s. Though I must say that it is no
match for the FM synthesizers though. The fidelity on FM synthesizers
was unmatched by the sampled crap in the SNES and other systems.

I seem to remember the original SID chip had somewhat of a bug in which
many composers exploited to produce the drum sound. Something to do
with changing an amplitude register?

>From what I know about the chip it had a pretty complex feature set:

Envelope Control (unheard of in other PSG's) and Pulse Width Modultion
(Makes some interesting sounds).

May I ask, have you tried some tunes in your simulator? All you need is
a 6502 CPU emulator to run the C64 code for the synth control. You can
find many free emulators or you can make your own in Python. The 6502
core is quite simplistic.

Also how did you make the DAC? I still dont understand how to do that
with an FPGA, gotta read up on it. Or did you just generate the
waveforms for each channel seperately and summed them up w/ analog
circuity?

I look forward to developments on your project. 
-Isaac


Article: 111070
Subject: Re: Survey: simulator usage
From: "bronzefury" <r.oteyza@sbcglobal.net>
Date: Sat, 28 Oct 2006 06:37:10 GMT
Links: << >>  << T >>  << A >>


>
> What I'd really like to find out, if you can spare the time and this
> might be of interest to you, is:
>
> * What simulator do you use?

NC-Verilog

>
> * Is your RTL code in Verilog/VHDL/both?

Verilog

>
> * Does your simulator have a C-language interface? From Verilog, or
> VHDL, or both?

I'm sure it does

>
> * If your simulator doesn't support C, would you be willing to upgrade
> it to use a product of this sort? Or would you prefer to get pure VHDL
> or Verilog out of this software, even if it means reduced vector file
> functionality?

Frankly, as an ASIC designer.  I probably wouldn't use this language.  In 
the future, we plan to use System Verilog.

>
> As a bonus, if you add the line "this is a great idea and I claim my
> 50% discount", then you can have 50% off the (initial) purchase price,
> if I ever get around to doing this.
>
> You can reply here or directly to me at 'unet+50' 'at'
> 'riverside-machines' 'dot' 'com'.
>
> Thanks -
>
> Evan 



Article: 111071
Subject: Re: Jumps in FPGA implemented integrator
From: "krishna.janumanchi@gmail.com" <krishna.janumanchi@gmail.com>
Date: 27 Oct 2006 23:48:19 -0700
Links: << >>  << T >>  << A >>
This is clearly Metastabilty issue. Thomas is correct.
I was also having such kind of problem.
There is an interesting article in cadence on Metastability & Cross
Clock domain.
If you have time, go through it
http://www.cadence.com/whitepapers/cdc_wp.pdf

Regards,
Krishna Janumanchi


Helen wrote:
> Thanks Thomas - I will try this!


Article: 111072
Subject: Stratix II basic questions
From: "vasile" <piclist9@gmail.com>
Date: 28 Oct 2006 00:06:11 -0700
Links: << >>  << T >>  << A >>
Hi,there is any Stratix II user here?

I'm involved in a hardware design for an EP2S90 device. I didn't ever
used such a beast
but I have some serious background in analogic/logic/RF design. I've
downloaded everything I found from the Altera site but the information
is huge and not very well organised in those books. The questions would
be:

- which is the most common configuration methode you'll choose for a
Stratix II
(would be the AS a good choice or better the PS, assuming there is a
PCB space constrain and starting time is not an issue)
- for an active serial configuration:
a. you'll use the download cable port for the serial FLASH config
device every time you'll change the configuration ? or
b. you may change the configuration with the JTAG for software test
purposes and burning the flash will be the last operation and it will
be quite rarely ?
- how you'll choose the input and output ports (regarding to banks and
quadrants) if you'll need to implement a complex math including DSP
operations (FIR, matrix, etc) ?
c. there are restrictions for such operations in using the banks of one
quadrant for input and banks from other quadrant for the outputs (or
banks for the same quadrand, but using huge number of  LABs from
different quadrant
d. there are restrictions in sending data from one quadrant to other
quadrant ( like from Q1 to Q3 for example?
- how you'll use the FPGA (and clocks) if a part of it must act as a
FIFO between two different speed systems

any help appreciated 
thx, 
Vasile


Article: 111073
Subject: Re: FPGA-based music synthesizer (with MyHDL)
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 28 Oct 2006 10:58:35 +0200
Links: << >>  << T >>  << A >>
Isaac Bosompem wrote:

> Also how did you make the DAC? I still dont understand how to do that
> with an FPGA, gotta read up on it. 

A very simlpe concept is this: http://www.fpga4fun.com/PWM_DAC.html

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 111074
Subject: Re: Stratix II basic questions
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sat, 28 Oct 2006 05:24:24 -0700
Links: << >>  << T >>  << A >>
vasile wrote:

> - which is the most common configuration methode you'll choose for a
> Stratix II

It depends what else is on the board.
If there is a cpu and flash file system,
loading the fpga image is just one of
many initialization tasks, and I can
ftp an fpga image file directly to
the embedded kernel whenever I like.

> - how you'll choose the input and output ports (regarding to banks and
> quadrants) 

I like to write and sim the hdl code first
and then let place and route take the first
cut at picking pins.

     -- Mike Treseler



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