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 77900

Article: 77900
Subject: Re: Comparison of LEON2, Microblaze and Openrisc processors
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 19 Jan 2005 22:11:52 -0600
Links: << >>  << T >>  << A >>
>Reasonably, such a chip will need to have an external flash memory
>and the pins between the FPGA and the Flash.

Good point, but... It depends upon the problem.

Lots of interesting problems will fit into on-chip RAM.
They might fit better into a special purpose CPU.  That
costs more design time.

External serial flash will be horribly slow, but might be good
enough for some problems.  Only takes a few pins.  You could
use on chip RAM for a cache or load it explicitly (bank switching).

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


Article: 77901
Subject: Asynchronous memory in Stratix devices
From: "vlsi_learner" <bajajk@gmail.com>
Date: 19 Jan 2005 20:53:27 -0800
Links: << >>  << T >>  << A >>
What if i design an asynchronous memory in Stratix devices??
Will it create any design problems??


Article: 77902
Subject: Re: Comparison of LEON2, Microblaze and Openrisc processors
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 20 Jan 2005 18:10:34 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:
>>Reasonably, such a chip will need to have an external flash memory
>>and the pins between the FPGA and the Flash.
> 
> 
> Good point, but... It depends upon the problem.
> 
> Lots of interesting problems will fit into on-chip RAM.
> They might fit better into a special purpose CPU.  That
> costs more design time.

The PicoBlaze, and tiniest variant of NIOS are interesting forthis

> 
> External serial flash will be horribly slow, but might be good
> enough for some problems.  Only takes a few pins.  You could
> use on chip RAM for a cache or load it explicitly (bank switching).

Yes, a core that used 50MHz SPI memory, and was optimised for
serial-code fetch could be quite interesting....

-jg


Article: 77903
Subject: Re: Comparison of LEON2, Microblaze and Openrisc processors
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 19 Jan 2005 23:09:30 -0800
Links: << >>  << T >>  << A >>
I have an unpublished success-story about using MicroBlaze in Commercial Product using XC2S100 with no external memory. Thats I think the smallest FPGA where Microblaze (at least Xilinx version!) can be used. The open- source MicroBlaze used in simple controller fashion could possible be useable in S50 too. Or small smallest Cyclone :)

And some comments to previous posters it is possible: 1) to run NIOS-II in Xilinx FPGA 2) to run Microblaze in Altera FPGA well at least I have tried both :)

Antti

Article: 77904
Subject: Re: video decoder for altera dev. board
From: "descoubes" <odescoubes@tietronix-optics.com>
Date: Thu, 20 Jan 2005 03:15:50 -0500
Links: << >>  << T >>  << A >>
Hi Rick,

If you have such a board, would you sell me one ?
I need just one!

Thanks

Olivier



Article: 77905
Subject: Re: LVDS through connectors
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 20 Jan 2005 00:38:10 -0800
Links: << >>  << T >>  << A >>
James Morrison wrote:

(snip)

> Not true.  Its not the frequency that matters but the edge rate.  Given
> the 4 bits and clock it sounds an awful lot like the TigerSHARC link
> port and it has a very fast edge rate.  The data sheet indicates a MAX
> of 200ps (that's pico-seconds).

If you believe in Fourier you know that edge rate is frequency.

> Anyways, at that edge rate any change in impedance in the trace will
> cause reflections.  If the path of the differential pair through the
> connector has a different impedance than the rest of the trace you will
> get a reflection.  In fact you'll get two--one at each side of the
> connector.  That is the difference in high-speed connectors--they pay
> attention to this.

Well, the two reflections will partially cancel in many cases.
That is why you don't notice them at lower frequencies.
Even at 200ps the wavelength is still significantly longer
than most connectors.

> Now it is true that the trace length through the connector needs to be
> matched as well.  Otherwise you'll get the + and - signals getting out
> of phase.

Out of phase relative to what?  There are coaxial cables where
the center conductor is helical to increase its inductance.
Signal velocity depends on the inductance per unit length
of the shield and center conductor, but one doesn't arrive
at the other end ahead of the other.

-- glen


Article: 77906
Subject: C programmer, what does this syntax mean?
From: "Fat Cat" <fatcat2005@h0tmail.org>
Date: Thu, 20 Jan 2005 17:07:46 +0800
Links: << >>  << T >>  << A >>
I am a bit confused. I have never seen such syntax even though I read a lot
of
C++ codes.

Thanks for your suggestion...







BluetoothReceiver::BluetoothReceiver()
: bandpassFilter(BPLENGTH),
  differentiatorFilter(DIFFLENGTH)
{
    m_bitrate = 1;
    m_bitDelay = BITDELAYBT;

    // Compute Bandpass filter coefficients and
    const double h0 = sqrt(2.0) * Br;
    const double kexp = -twopi * Br * Br;
    for (int i=0; i<bandpassFilter.size(); ++i) {
        double temp = i - (BPLENGTH *1.)/2.+.5;
        temp /= Ns;
        double hreal = h0 * exp(kexp * temp * temp);
        bandpassFilter[i] = Sample(hreal,0.0);
    }

    // Set Differentiator filter coefficients
    differentiatorFilter[0] = Sample(-0.0062, 0.0);
    differentiatorFilter[1] = Sample(0.0372, 0.0);
    differentiatorFilter[2] = Sample(-0.4566, 0.0);
    differentiatorFilter[3] = Sample(0.4566, 0.0);
    differentiatorFilter[4] = Sample(-0.0372, 0.0);
    differentiatorFilter[5] = Sample(0.0062, 0.0);
}








Article: 77907
Subject: Altera HardCopy and SEUs
From: "Roger" <rogerwilson@hotmail.com>
Date: Thu, 20 Jan 2005 10:56:56 GMT
Links: << >>  << T >>  << A >>
Compared with a normal Stratix, is a HardCopy version immune to SEUs?

I'd have thought the possibility of a configuration error is reduced to zero 
as the configuration SRAM cells have gone but an event in the logic is still 
possible. Does anyone have any ideas (or figures maybe)?

TIA

Rog. 



Article: 77908
Subject: Re: LVDS through connectors
From: "Mark Smith" <mark.smith@latticesemi.com>
Date: 20 Jan 2005 04:01:51 -0800
Links: << >>  << T >>  << A >>
Hi Georgi,

For Higher speeds, I would recommend the AMP Mictor connectors.

This document is a useful design guide:

http://www.latticesemi.com/lit/docs/technotes/tn1033.pdf
Regards

Mark Smith
Strategic Marketing
Lattice Semiconductor


Article: 77909
Subject: Re: LVDS through connectors
From: "Marc Randolph" <mrand@my-deja.com>
Date: 20 Jan 2005 05:00:45 -0800
Links: << >>  << T >>  << A >>

James Morrison wrote:
> On Wed, 2005-01-19 at 17:29 -0800, Marc Randolph wrote:
> > I hate to say that it doesn't matter, but in the grand scheme of
> > things, the type or style of the connector is not of huge
importance at
> > that speed, as long as one pin isn't massively longer than another
> > (which occurs with some types of right angle connectors).  We run
many
> > times that speed using the worst connector you can imagine.
> >
> > Much more important is the stuff that Brad mentioned: keep _p/_n
pair
> > trace length the same and routed as a diff pair into and out of the
> > connector - and routed against a ground plane if possible.  Give
> > yourself a ground pin next to each pair within the connector.
>
> Not true.  Its not the frequency that matters but the edge rate.

Howdy James,

I was figuring that someone would disagree with what I said - I just
didn't figure it would be within a half hour!

I was actually referring to the whole solution when I was referring to
the speed: signalling type (LVDS, which has slower edges than PECL and
CML), termination location (hopefully on-chip), voltage swing, etc.

> Given
> the 4 bits and clock it sounds an awful lot like the TigerSHARC link
> port and it has a very fast edge rate.  The data sheet indicates a
MAX
> of 200ps (that's pico-seconds).

No arguing that 200ps is fast.  But it is fast enough to cause problems
on a properly terminated and routed differential pair?  Our extensive
experience on our telecom boards have shown it isn't even close to
causing problems.  In fact, I was referring to both CML *and* LVDS when
I was mentioning our past experience.  CML has edge rates closer to
100ps.

> Anyways, at that edge rate any change in impedance in the trace will
> cause reflections.  If the path of the differential pair through the
> connector has a different impedance than the rest of the trace you
will
> get a reflection.  In fact you'll get two--one at each side of the
> connector.  That is the difference in high-speed connectors--they pay
> attention to this.

And the the termination that differential signals have do an excellent
job of minimizing those reflections.  Go check out the people running
LVDS buses with 20 drops!

> Now it is true that the trace length through the connector needs to
be
> matched as well.  Otherwise you'll get the + and - signals getting
out
> of phase.
>
> You'll always have slight mismatches in impedance and trace length.
But
> with a 200ps edge rate you have a lot less margin for error than at
more
> reasonable rates.

The beauty of terminated differential signalling is that you have such
an improved signal infrastructure, I think you actually have more
margin than you had with signal ended, unterminated signals that swing
all the way from 3.3v, even if their edge rates were "only" 1.5ns.  I
think that's where people go wrong... while the concepts between
unterminated single-ended and terminated differential are close to the
same, the rules of thumb for one don't translate well to the other.
I stand by my original post.  Let the flames begin.

   Marc


Article: 77910
Subject: Problem with Signal Tap II Logic Analyzer in Altera Quartus II 4.1 and Microtronix Stratix development board
From: "Sebastian Schmidt" <fpga@gmx.de>
Date: Thu, 20 Jan 2005 14:13:39 +0100
Links: << >>  << T >>  << A >>
Hi.

A colleague and me are having problems getting the SignalTap II Logic  
Analyzer from Quartus II running on our Stratix device.
We compiled a NIOS example-design and programmed it to the device. We know  
the example is working because we loaded a little C-program to the NIOS  
which resulted in correct output. We also tried to use Signaltap with a  
self-created simple design but this also didn't work.
We tried to use the SignalTap II Logic Analyzer in two ways:
1) We opened the Signaltap II Logic Analyzer from the Tools menu in  
Quartus. There we added the nodes we tried to analyze. We enabled  
SignalTap II Logic Analyzer in the project's settings and chose the  
created stp-file there. We followed the instructions we got from the  
program which told us to compile the design and then to program the  
device. After programming the device, SignalTap still told us to program  
the device. In the documention it says that "Ready to acquire" should be  
the next message but we still get "Program the device to continue". When  
we try to ignore the message and acquire data anyway we get a JTAG  
communication error.
2) The second way was to create an instance of a SignalTap II Logic  
Analyzer using the MegaWizard Plug-In Manager and added it to the design.  
We connected the inputs (clock, data, trigger), then we created a stp-file  
using the menu item as described in the documentation. This way we  
encountered the same problems as before.

We don't know what we are doing wrong, can anybody help us getting the  
SignalTap II Logic Analyzer running?

Thanks.

Article: 77911
Subject: Re: C programmer, what does this syntax mean?
From: "Peter" <pdstroud@gmail.com>
Date: 20 Jan 2005 05:37:43 -0800
Links: << >>  << T >>  << A >>
Which part, in particular, is confusing?

"BluetoothReceiver::BluetoothReceiver() : bandpassFilter(BPLENGTH),
differentiatorFilter(DIFFLENGTH) {...}" is the default constructor. The
stuff after the ":" is the initialization list and may be used to
initialize member objects or base class portions of a derived object.

My guess is that bandpassFilter and differentiatorFilter are both
contained by BluetoothReceiver and are initialized with BPLENGTH and
DIFFLENGTH upon construction.


Article: 77912
Subject: Re: Asynchronous memory in Stratix devices
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Thu, 20 Jan 2005 15:41:00 GMT
Links: << >>  << T >>  << A >>
Hi vlsi_learner,

> What if i design an asynchronous memory in Stratix devices??
> Will it create any design problems??

If you model fully asynchronous memory in whatever modern FPGA it will be
implemented as latches (= 1 logic cell) behind a big address multiplexer.
If it's 32 bits in total that's not a big problem but if you go for several
Kbytes then, yes you're in trouble.

Best regards,


Ben


Article: 77913
Subject: X-checker Pod : Problem w/ X-checker and Win2000
From: "Vadim Vaynerman" <vaynerma@aaicorp.com>
Date: Thu, 20 Jan 2005 08:03:28 -0800
Links: << >>  << T >>  << A >>
Hi all,

I have a legacy design for an XC4000 that I'm trying to program through the X-checker pod, and this has not worked under Windows 2000 or XP. Windows 98 works fine. What can I do to get this to work under the new OS?

Thanks,

Vadim

Article: 77914
Subject: Re: LVDS through connectors
From: James Morrison <spam1@emorrison.ca>
Date: Thu, 20 Jan 2005 11:33:31 -0500
Links: << >>  << T >>  << A >>
On Thu, 2005-01-20 at 05:00 -0800, Marc Randolph wrote:

> I was figuring that someone would disagree with what I said - I just
> didn't figure it would be within a half hour!

Life is all about timing!

> I was actually referring to the whole solution when I was referring to
> the speed: signalling type (LVDS, which has slower edges than PECL and
> CML), termination location (hopefully on-chip), voltage swing, etc.

I don't disagree with what you've said and appreciate the insight from
your past experience.  I guess what I was reacting to is the concept
that the connector doesn't matter.  It does matter, but as I said, it
all depends on how much margin you have in your design.  In a particular
design it may or may not matter based on a hundred other factors.

As you mentioned, in a lot of ways differential signalling is a whole
lot easier to deal with.  Of course there is no such thing as a
single-ended signal.  Ground is typically the other end that happens to
be common among all signals.

James.


Article: 77915
Subject: Xilinx constraint question- DC input
From: "wpiman@aol.com" <wpiman@aol.com>
Date: 20 Jan 2005 08:41:44 -0800
Links: << >>  << T >>  << A >>
Hi-
I need to add something to my UCF file and I am not entirely sure how
to do it.

We have a chip that is going to operate in one of two modes.  We will
have a pin which will be tied high on one side- and low on the other.

The problem is is that this signal fans out throughout the whole
device- but that timing analyzer thinks that this is an input it has to
run timing analysis on.

What we would like to do is tell the timing analyzer that the pin
"mode" will not change- and that it should not consider this in its
timing calculations.

Thanks,
WP


Article: 77916
Subject: Re: San Jose job offer - advice needed
From: Brendan Cullen <bcullen@xilinx.com>
Date: Thu, 20 Jan 2005 16:49:07 +0000
Links: << >>  << T >>  << A >>
Hi Vadim,

vadim wrote:

> Thanks for your responses to my posting.
>
> I would like to ask you if you would know why are they interested in
> bringing me down from Canada ?
> The reason I am asking is, I am a recent graduate and have been
> working in Toronto only for couple of months. So I am not some expert
> they can't find in Silicon Valley..
> This raises my suspicion abit and am afraid of being "lured" by the
> glorious image of Silicon Valley to exchange my current job for
> something that doesn't worth it.
>
> I know this is my decision and at the end of the day you have to take
> some chances to get anywhere, but I am just trying to gather some
> opinions from either edges of the spectrum to understand whats
> "cooking" down there and what
> people have experienced.
>
> Everyone of my US relatives and friends are saying:
> "Jump on it!"
> "Once there you will have lots of opportunities"
>
> and I realize that there are dozens of others in SV who would gladly
> take
> this position....so is it a genuine opportunity ?
>
> PS
> Toronto is not a cheap place. Yet is safe and very multi-cultural.

Whether SJ is the right place for you or not largely depends on what it
is you're looking for.  Are you looking to move ?  And, if so, why ?

Brendan


Article: 77917
Subject: Hardened Logic and SEUs
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 20 Jan 2005 08:50:03 -0800
Links: << >>  << T >>  << A >>
Roger,

The simple answer is that it is "they claim to be better".

That used to be the one big advantage an ASIC used to have over a FPGA: 
(note the past tense -- the fact that there are "so many fewer memory 
cells" means that "the upset rate is much less" - all else being equal).

The facts are less clear, at the latest technology nodes.

Since we, and the SRAM vendors do SEU testing (eg Cypress has a similar 
project to our Rosetta where they to simulation, beam testing, and 
atmospheric testing), we are the only two vendors that "know" what is 
happening (see our MAPLD presentation for the last few years).

But, look carefully at what Cypress is saying:  SRAM at 90 nm is ~ 3000 
FIT/Mb for atmospheric SEU's at sea level (which Cypress has improved to 
better than 1500 by design, doing things similar to what we are doing).

Our configuration latches in comparison are ~180 FIT/Mb at 90nm (latest 
extrapolation of all testing, with a margin of error of 1/2 to 2X -- 
just need more time (or more errors).  Good position to be in.  Our 
promise is to get better with each technology, not worse.  And we are 
proving that to be true.

Well, a D FF in an ASIC (or hardened solution) is a pretty small animal 
at 90nm.  Our studies show its upset rate to be significantly higher 
than one would first suppose.  In fact, the 90nm standard cell D FF is 
the most sensitive element!  They are by, our calculations, 10X our CMOS 
configuration latch in terms of FIT/Mb.

If the FIT/Mb for 90 nm CMOS configuration latch is ~180, and it takes 
on average 10 tries to hit something 'critical' (a LUT, a piece of 
interconnect that matters - open/shorting something), then the mean time 
to fail is 18 FIT/Mb of config memory in our FPGAs.  Gee, 10X better. 
If the ASIC has even 1/10 the D FF and memory that the FPGA has, then 
they are equal in time to fail by atmospheric upsets....

By the way, the D FF in the CLB is 1 FIT/Mb, so it is so unlikely to be 
flipped, it is not even on the radar screen (can be ignored).

Now let us say that I use a XC4VLX60, and once I am done, I use a 2M 
gate ASIC (an actual customer story, one million gates + 1 million D 
FF's).  If we make a few reasonable calculations, I get ~500 years 
between functional failures in the FPGA (assuming you do not use our 
correction features, which would make this much much better (longer)), 
and ~500 years between functional failures for the 90nm ASIC.  So, given 
we are no better, no worse (on paper), and we can be better by using the 
FRAME_ECC, and other easy built in error correction techniques, we win 
in the SEU MTBF with the longest time to a failure category.


Now, we know what we do, and we tell you.

For fun, go ask your vendors what their atmospheric MTBF is for soft 
errors (SEU, SEE, SER, SEL) for their hardened solution.

Many large companies are doing this (have done this).

They don't know.  Ask more closely, and do they know how to do Qcrit 
studies?  Can they follow JESD89?

Ask for the results.  We will talk about ours, just contact your FAE.

Are they hiding just how bad they really are?

Or, are they just afraid that they are really bad, and have no way to 
know (predict)?

Do they do beam testing? (we do)

Do they test for latch-up (which may destroy the chip)? (we do, and have 
to latch-up)

Do they do atmospheric experiments? (we do)

Do they promise to only get better from one generation to the next?  (we 
and Cypress both do)

So, we can not say they are "worse" but we can certainly say that they 
are not "better."

The truth is somewhere in between.

But I would choose the technology that knows what is going on, and has a 
means to predict the MTBF, and extend the MTBF hours by using simple 
built in features, if it is something that is needed.

Make a reliability spreadsheet for your system.  Set goals (hard and 
soft).  Then work with our FAEs to meet those goals.  It is called 
reliability engineering, and it may surprise you that the FPGA will win.

After all, being in satellites, autonomous aircraft, jet fighters, 
automobiles, and on Mars has taught us a lot about reliability 
engineering, and SEUs.

Go Mars Rovers!   One year and counting!

Austin


Roger wrote:
> Compared with a normal Stratix, is a HardCopy version immune to SEUs?
> 
> I'd have thought the possibility of a configuration error is reduced to zero 
> as the configuration SRAM cells have gone but an event in the logic is still 
> possible. Does anyone have any ideas (or figures maybe)?
> 
> TIA
> 
> Rog. 
> 
> 

Article: 77918
Subject: Re: Xilinx constraint question- DC input
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 21 Jan 2005 03:57:51 +1100
Links: << >>  << T >>  << A >>
On 20 Jan 2005 08:41:44 -0800, "wpiman@aol.com" <wpiman@aol.com>
wrote:

>Hi-
>I need to add something to my UCF file and I am not entirely sure how
>to do it.
>
>We have a chip that is going to operate in one of two modes.  We will
>have a pin which will be tied high on one side- and low on the other.
>
>The problem is is that this signal fans out throughout the whole
>device- but that timing analyzer thinks that this is an input it has to
>run timing analysis on.
>
>What we would like to do is tell the timing analyzer that the pin
>"mode" will not change- and that it should not consider this in its
>timing calculations.
>
>Thanks,
>WP


>From the Constraints Guide:

TIG (Timing IGnore) is a basic timing constraint and a synthesis
constraint. It causes paths that fan forward from the point of
application (of TIG) to be treated as if they do not exist (for the
purposes of the timing model) during implementation.


The basic UCF syntax is:
NET “net_name” TIG;
PIN “ff_inst.RST” TIG=TS_1;
INST “instance_name” TIG=TS_2;
TIG=TSidentifier1,..., TSidentifiern


Regards,
Allan

Article: 77919
Subject: Asic prototyping in Fpga - prototyping the gates.
From: "gretzteam" <david.lamb@gmail.com>
Date: 20 Jan 2005 09:11:59 -0800
Links: << >>  << T >>  << A >>
Hi,
We are currently using virtexIIpro and virtex4 fpga to prototype a dsp
processor. All the code is synthesizable verilog and we are using
Xilinx ISE to do synthesis and place and route. Everything works fine
and the processor runs at full speed (50Mhz). However, this is only
good for functionnal verification on the bench. The ASIC flow and the
FPGA flow are very different so the actual gates in the FPGA are
different than what will be on the ASIC. For example, we can't use the
FPGA to verify the test vectors and scan chains that the test engineer
is working on.

Is it possible to prototype the EXACT same gates that will be in the
ASIC? We use Synopsys Design Compiler to generate the ASIC gates.
Basically is there a way to take the gates generated by Design
Compiler, and map them in the FPGA? We don't really care if this runs
slower, but it would allow the test engineer to start working on all
the test vectors before we receive silicon.

Thank you very much,
David


Article: 77920
Subject: Re: C programmer, what does this syntax mean?
From: jon@beniston.com (Jon Beniston)
Date: 20 Jan 2005 09:13:00 -0800
Links: << >>  << T >>  << A >>
Which part?

Probably you are refering to the part that passes arguments to the
object's super-classes constructor.

Maybe.

Cheers,
Jon

Article: 77921
Subject: Re: Asic prototyping in Fpga - prototyping the gates.
From: mk<kal*@dspia.*comdelete>
Date: Thu, 20 Jan 2005 17:23:10 GMT
Links: << >>  << T >>  << A >>
On 20 Jan 2005 09:11:59 -0800, "gretzteam" <david.lamb@gmail.com>
wrote:

>Hi,
>We are currently using virtexIIpro and virtex4 fpga to prototype a dsp
>processor. All the code is synthesizable verilog and we are using
>Xilinx ISE to do synthesis and place and route. Everything works fine
>and the processor runs at full speed (50Mhz). However, this is only
>good for functionnal verification on the bench. The ASIC flow and the
>FPGA flow are very different so the actual gates in the FPGA are
>different than what will be on the ASIC. For example, we can't use the
>FPGA to verify the test vectors and scan chains that the test engineer
>is working on.
>
>Is it possible to prototype the EXACT same gates that will be in the
>ASIC? We use Synopsys Design Compiler to generate the ASIC gates.
>Basically is there a way to take the gates generated by Design
>Compiler, and map them in the FPGA? We don't really care if this runs
>slower, but it would allow the test engineer to start working on all
>the test vectors before we receive silicon.
>
>Thank you very much,
>David

Yes of course. What you need to do is to take the standard cell
library file(s) which define the behavior of individual gates and add
it your gate level netlist during synthesis. All combinational gates
will have their behaviour described in a synthesizable way in the
library. The only case where this will not work are the latches and
flip-flops as they are most probably defined as udps which are not
synthesizable but they are relatively easy to code in behavioral rtl.
the same situation may exists for muxes but that's doable too. but of
course you have to understand that even these gates will be mapped to
the luts on the fpga.


Article: 77922
Subject: SystemACE and Jtag
From: Scarex <scarex_s@yahoo.com>
Date: Thu, 20 Jan 2005 18:45:22 +0100
Links: << >>  << T >>  << A >>
I'm working on a Xilinx demonstration board equipped with a jtag chain 
including a SystemACE CF and a Virtex-II FPGA.
My goal is to configure the FPGA via Jtag bypassing the SystemACE.
Unfortunaly, after the hardware reset, the SystemACE is configured by 
default to look for a bitstream on the Compact Flash: in this way, it 
doesn't allow me to
reach the FPGA through the Jtag. I have to use Impact software to 
configure for the first time, and then I can access to FPGA. So, I think 
that Impact configures
the SystemACE in order to transfer data to FPGA.
It's possible to program the SystemACE via Jtag?On Xilinx 080 Datasheet 
(SystemACE CF solution) I can find only 4 instructions (idcode, sample, 
extest, bypass);
in adding to this, it seems that Jtag Configuration Register is not present.
Are there any others not documented commands which allow me to configure 
SystemAce (for example cgfin and cfgout)? Otherwise, have anybody a 
solution for my problem?
Thank you very much.
Salvatore

Article: 77923
Subject: Re: LVDS through connectors
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 20 Jan 2005 09:51:12 -0800
Links: << >>  << T >>  << A >>
"James Morrison" <spam1@emorrison.ca> wrote in message
news:1106192534.5033.8.camel@oxygen.emorrison.ca...
>
> Not true.  Its not the frequency that matters but the edge rate.  Given
> the 4 bits and clock it sounds an awful lot like the TigerSHARC link
> port and it has a very fast edge rate.  The data sheet indicates a MAX
> of 200ps (that's pico-seconds).
>
Hi James,
Not true either! You've brought out the pedant in me! It's not edge rate,
but rise time. For example, what's the edge rate in a 400kV power line?
Still only 50 or 60 Hz though!
Also, In the context of this thread, I assume you mean bit-rate when you say
frequency. Marc didn't mention frequency anywhere. (And as Glen meant, rise
time and frequency are equivalent anyway.) If that's the case, here's a
counter-example where bit rate does matter. The bus is required to get data
from one end to the other. If the bit-rate was 1Mbps instead of 400Mbps, a
200ps edge rate would give you overshoot/undershoot problems through a
shoddy connector plus lots of EMI, but you'd still have a big enough eye to
recover the data. So, bit-rate is a part of the design exercise.
That said, I understand what you're saying. I'm just being pedantic....
Cheers, Syms.



Article: 77924
Subject: Re: decrease slew rate - Actel Libero
From: David Colson <dscolson@rcn.com>
Date: Thu, 20 Jan 2005 13:19:43 -0500
Links: << >>  << T >>  << A >>
Marie wrote:

> Hello,
> 
> I am using Actel Libero 6.0.
> I would like to decrease the slew rate of some of the outputs of my
> FPGA.
> I found an option in Designer PinEdit where the slew rate can be set
> low or high.  Does someone have an idea of what means low or high? 
> Are there any numbers (in ns) available somewhere?  Is it programmable
> in ns?
> Is it possible to see the rise time on the simulation (I use
> ModelSim)?
> Will the fall time also be influenced?  Is it possible to influence it
> separately?
> 
> Thank you very much.
> 
> Marie Van Quickelberghe
Hi,

It turns out the only place to get the actual numbers is from the ibis 
file for that device. We have done it in the past, real painful to 
figure out. Good luck!

Dave Colson



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