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 27625

Article: 27625
Subject: Re: high level timing by C generated VHDL?
From: "Eric Pearson" <ecp@focus-systems.nospam.on.ca>
Date: Thu, 30 Nov 2000 09:00:31 -0500
Links: << >>  << T >>  << A >>
Hello Robert....

Been there....

I now always pipeline everything on a single clock basis.
If a signal has 5 clock cycles to propagate, rather than trying
to keep track of that I'll add in 5 flip-flops.
That way static timing analysis tells all.
The "next guy" will thank you.

Eric Pearson



Robert S. wrote in message <3a265180.12798893@news.home.ins.de>...
>Hi Group,
>the high level timing is getting terribly
>complicated in one of my designs (for an XCS20),
>not to speak of the approaching maintenance horror:
>floor covered with manually drawn timing diagrams
>the sort of 'here that input gate is open, now here
>5 clocks before the ADC has to be started, then at
>this particular point in time the CORDIC is finished
>with that task and must take over the ADC data at
>the next clock, there, while..'. And everything
>irregularly intertwined on the next higher timing
>level, but fortunately repeating forever in all.
>(All that plus dependent on inputs, would have
>killed me..)
>
>So, had the idea to try another approach:
>- Write a timing dependency simulation in C++
>  or Delphi, producing timing diagrams output.
>- Modify it until everthing looks fine.
>- Replace the graphics output by functions
>  which produce the VHDL to create my timing
>  generator.
>
>Any advice, suggestions, other ideas (preferable ones
>which dont lead into a budgetary desaster instead)?
>
> Robert
>robertDschoerghuberAhomeDinsDde
>
>P.S. Thorough experience in HW/SW/FPGA can be
>assumed, but just about to learn VHDL.



Article: 27626
Subject: Re: Synplify Benchmarks
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 30 Nov 2000 14:46:11 GMT
Links: << >>  << T >>  << A >>
> Place and route is going to take you significantly longer than Synplify's
> synthesis.

That is true for a very full design...but...  One of the things Xilinx does
is recommend NOT using the dedicated global reset.  I believe this to be a
potentially bad suggestion.

I had a design that was not using the GSR, and it took 45 minutes to P&R. 
I re-did the design to use the dedicated GSR, and it now takes 9 minutes to
P&R.

The recommendation to not use the global GSR is due to poor implementation
(it's quite slow) of the dedicated metal in the Xilinx part.  This timing
issue is EASILY overcome in the design such that it will not cause any
problems.


Article: 27627
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: Klaus Falser <kfalser@durst.it>
Date: Thu, 30 Nov 2000 14:54:46 GMT
Links: << >>  << T >>  << A >>
In article <905e4a$s0l@src-news.pa.dec.com>,
  murray@pa.dec.com (Hal Murray) wrote:
>
> LVDS needs 2.5 V Vcco.  That's another power plane (pair) if you
> don't already need it for something else, and a power supply too.
>
> LVPECL uses 3.3 V Vcco which you probably already have for LVTTL signals.
>
> I'm not a wizard at analog stuff, but they look pretty similar to me.
>
> Anybody know any good reason not to use LVPECL instead of LVDS if
> you get to design both ends?
>
> --
> These are my opinions, not necessarily my employers.  I hate spam.
>

Thera are LVDS driver and receiver IC's for 5V and 3.3V too.
No need for a extra power plane.
LVPECL needs more power, operates at higher currents and should
produce more EMI.

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27628
Subject: Re: hard or soft core for FPGA?
From: "Wolfgang Loewer" <wolfgang.loewer@elca.de>
Date: Thu, 30 Nov 2000 16:43:59 +0100
Links: << >>  << T >>  << A >>
Nial,

NIOS comes with CYGNUS GNUPro Toolkit which is basically free software
(www.cygnus.com). Everything's included, C/C++ compiler, assembler, debugger
(cygnus insight), even source code for the tools and 228 pages of
documentation from Cygnus.
My personal background is hardware and I can't really judge the quality of
these tools or compare them to others. Nevertheless I can tell you, our
software guys liked Altera's approach with Cygnus.
There's also quite some documentation that comes with the kit, which
unfortunately I couldn't find on Altera's website.

- Wolfgang


Nial Stewart <nials@sqf.hp.com> wrote in message
news:3A24DF34.AC4D5D95@sqf.hp.com...
> Wolfgang Loewer wrote:
> >
>
> > When you implement NIOS in an ACEX 1K device, which we successfully did,
the
> > silicon cost for the processor core is only about US-$ 5,- and the
complete
> > development environment is only US-$ 995,-.
> >
> > Best regards
> > Wolfgang Loewer
>
> Wolfgang,
>
> What are the software development/emulation tools like for the NIOS
> core?
>
> Nial.



Article: 27629
Subject: Routing constraints & A2.1i
From: mmeraliuk@yahoo.co.uk
Date: Thu, 30 Nov 2000 16:21:30 GMT
Links: << >>  << T >>  << A >>
Does anyone know of a way to prevent Xilinx A2.1i PAR from routing
through a particular CLB's routing resources?

Cheers,
matthew.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27630
Subject: Re: Orca 3t sram gsr question
From: husby@my-deja.com
Date: Thu, 30 Nov 2000 17:03:29 GMT
Links: << >>  << T >>  << A >>
"jj" <jj@rad.com> wrote:
> I am instantiating DCE32x4 dual port srams in a 3T125, when you
> look at the srams in EPIC there in a GSR Enable/ Disable option,
> neither have been highlighted.
> How do you select this option within the HDL, I have instantiated
> a GSR component but these does not solve the problem.

The GSR cannot be used to reset a RAM.  It only applies to
registers.


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27631
Subject: Re: FPGA Express warning
From: "Olivier REGNAULT" <olivier.regnault@avnet.com>
Date: Thu, 30 Nov 2000 09:13:52 -0800
Links: << >>  << T >>  << A >>
You probably described the same functionality within each registers (same inputs and equations). The synthesis tool is removing registers to save area. However, you will have a high fanout. The issue is to disable the "merge duplicate register" from optimization option of FPGA Express.

Regards

O. Regnault / AVNET

Article: 27632
Subject: Re: Xilinx Coolrunner going on last time buy?
From: olivier.regnaultavnet.com <>
Date: Thu, 30 Nov 2000 09:29:17 -0800
Links: << >>  << T >>  << A >>
There is no way to convert a PZ5032CS to an Altera CPLD unless these components are able to go at a 100uA consumption !

However, Betsy is right because XPLA3 is pinout compatible with XPLA or XPLA Enhanced. You should also know that XPLA 3 is 5V tolerant. So, the issue is just to provide a 3.3V power supply on the XPLA 3. We 've already converted designs with success.
It seems easier to convert 5V to 3.3V than 10mA to 100uA.

Olivier REGNAULT
Xilinx FAE
AVNET France

Article: 27633
Subject: Re: high level timing by C generated VHDL?
From: nospam@notarealaddress.de (Robert S.)
Date: Thu, 30 Nov 2000 18:04:13 GMT
Links: << >>  << T >>  << A >>
Hi Eric,


On Thu, 30 Nov 2000 09:00:31 -0500, "Eric Pearson"
<ecp@focus-systems.nospam.on.ca> wrote:
>Hello Robert....
>
>Been there....

Now thats gonna be a nice report from hell, hi back!

>I now always pipeline everything on a single clock basis.
>If a signal has 5 clock cycles to propagate, rather than trying
>to keep track of that I'll add in 5 flip-flops.

Oh yesss, already pipelining everything as heavily as possible 
(still baffled how natural it suddenly became after decades of
watching the big processor fab boys with deepest respect).

No, it's the requirements of the world outside the chip 
which cause all the troubles; my slowest clock enable 
runs at 32Hz, every time decade or so below another level 
downto 16MHz to controll and peek all the peripherals, in 
a "slightly" chaotic manner. 
Everything too tight to be shifted around or beeing more 
pipelined, might even need some automatism to put in the 
big master make file to get it proveably right.

>That way static timing analysis tells all.

No really helpful tools here for that yet. Any pointers?

>The "next guy" will thank you.

That's what I hope.

>Eric Pearson
>
>
>Robert S. wrote in message <3a265180.12798893@news.home.ins.de>...
>>Hi Group,
>>the high level timing is getting terribly
>>complicated in one of my designs (for an XCS20),
[..]
>>So, had the idea to try another approach:
>>- Write a timing dependency simulation in C++
>>  or Delphi, producing timing diagrams output.
>>- Modify it until everthing looks fine.
>>- Replace the graphics output by functions
>>  which produce the VHDL to create my timing
>>  generator.
>>
>>Any advice, suggestions, other ideas (preferable ones
>>which dont lead into a budgetary desaster instead)?
>>
>> Robert
>>robertDschoerghuberAhomeDinsDde
[..]

Article: 27634
Subject: Re: Synplify Benchmarks
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 30 Nov 2000 19:10:31 +0100
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroo98m.com> writes:

> > Place and route is going to take you significantly longer than Synplify's
> > synthesis.
> 
> That is true for a very full design...but...  One of the things Xilinx does
> is recommend NOT using the dedicated global reset.  I believe this to be a
> potentially bad suggestion.
> 
> I had a design that was not using the GSR, and it took 45 minutes to P&R. 
> I re-did the design to use the dedicated GSR, and it now takes 9 minutes to
> P&R.
> 
> The recommendation to not use the global GSR is due to poor implementation
> (it's quite slow) of the dedicated metal in the Xilinx part.  This timing
> issue is EASILY overcome in the design such that it will not cause any
> problems.

Really? How? I never use it, I stick with sync reset.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 27635
Subject: Re: FC II & Xilinx libraries macros
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 30 Nov 2000 19:34:02 +0000
Links: << >>  << T >>  << A >>


Tim Gordon wrote:

> I'm using Synopsys FCII for Virtex synthesis. When I instantiate macros
> listed in the Xilinx Unified Libraries, synthesis fails with a link error.
> I've found XNFs for 3000 and 5200 macros amongst the files installed, but
> not for Virtex. Can anyone tell me how to resolve this problem?

Somehow you need to mark these as ``to be filled in later'' i.e by the Xilinx
back end tools that implement these instantiations as real bits of silicon.
The traditional way is to include a  VHDL/Verilog black-box ``stubs'' library
in your synthesis. This consists of a bunch of modules that have only the
ports defined and some sort of ``synthesis stops here'' marker - generally
some variant of the phrase ``black box''. You'll need to look at the FCII
documenation to find out how to do this, not the Xilinx docs.



Article: 27636
Subject: R: fpga + live
From: "Fabio" <falcon65@supereva.it>
Date: Thu, 30 Nov 2000 21:46:00 +0100
Links: << >>  << T >>  << A >>

Fabio <falcon65@supereva.it> wrote in message 3a20faa4.0@news.dada.it...
> non riesco a configurare , mi causa un errore irreversibile!
> Help!
>
>



Article: 27637
Subject: Re: Synplify Benchmarks
From: "Austin Franklin" <austin@darkroo98m.com>
Date: 30 Nov 2000 22:34:06 GMT
Links: << >>  << T >>  << A >>
> > The recommendation to not use the global GSR is due to poor
implementation
> > (it's quite slow) of the dedicated metal in the Xilinx part.  This
timing
> > issue is EASILY overcome in the design such that it will not cause any
> > problems.
> 
> Really? How? I never use it, I stick with sync reset.

Be glad to tell you ;-)  First, make sure ALL the registers in the design
have a positive asynch set or reset.  Second, instantiate the STARTUP
block:

//
// Xilinx specific instantiation for GSR
//

module STARTUP_VIRTEX_GSR (GSR) /* synthesis black_box .noprune=1 */;
    input  GSR;
endmodule


I also suggest using FPGA Editor to find where the STARTUP block is, and
selecting a pin near it...  Also, if your reset input is active low, put an
inverter between it and the reset signal you are using.

assign		I_reset = ~I_reset_N ;


reference the STARTUP block with the positive sense reset as the argument:

STARTUP_VIRTEX_GSR startup_virtex_gsr (I_reset) ;


and use an asynch reset on all your registers:

always @ (posedge I_clk or posedge I_reset) begin

	if (I_reset == `ASSERTED) begin

		signal	<= `LOW ;

	end

	else begin

		signal	<= 'HIGH ;

	end

end


Also, in your state machines, I would suggest an extra startup state before
looking at any input signals.

If you do all this, Synplicity will automatically use the global GSR.  I
may have missed something...if I did, please let me know.





Article: 27638
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: murray@pa.dec.com (Hal Murray)
Date: 30 Nov 2000 22:59:39 GMT
Links: << >>  << T >>  << A >>

> > Anybody know any good reason not to use LVPECL instead of LVDS if
> > you get to design both ends?
> 
> Power consumption and possibly emitted interference.

I fed some numbers to the Xilix power estimator.

  I told it 17 inputs, 17 outputs, 50% toggle rate, and 20 pf.
  It said 85 mW for LVDS and 135 mW for LVPECL.
  So the LVPECL mode uses ~60% more power.

  That's 34 mA for LVDS and 41 mA for LVPECL.
  Or roughly 20% more current.  Or only 20% more
  total power if you are using a linear regulator.
  Of course, the 60% savings in the Xilinx might be important in
  your design/application.


I can't find a simple/clean way to estimate the EMI difference.  They
both expect a 100 ohm terminator.  I'm willing to assume the traces
and cables/connectors are the same.  So all we need is the voltage or
current.  That's assuming the edge rates are the same which may be bogus.

The spec sheet says 250-450 mV for LVDS output and 300 mV min input
for LVPECL.  Same ballpark.




-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27639
Subject: Re: Orca 3t sram gsr question
From: "j" <j@j.com>
Date: Thu, 30 Nov 2000 23:12:42 -0000
Links: << >>  << T >>  << A >>
As I understand it the 3T sram module contains registers for the write
address and data out ?
it is these registers that I wish to reset


j


<husby@my-deja.com> wrote in message news:90618q$ac3$1@nnrp1.deja.com...
> "jj" <jj@rad.com> wrote:
> > I am instantiating DCE32x4 dual port srams in a 3T125, when you
> > look at the srams in EPIC there in a GSR Enable/ Disable option,
> > neither have been highlighted.
> > How do you select this option within the HDL, I have instantiated
> > a GSR component but these does not solve the problem.
>
> The GSR cannot be used to reset a RAM.  It only applies to
> registers.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.


Article: 27640
Subject: Re: Xilinx Coolrunner going on last time buy?
From: "Ulf Samuelsson" <ulf@atmel.dot.com>
Date: Fri, 1 Dec 2000 00:36:51 +0100
Links: << >>  << T >>  << A >>

<olivier.regnaultavnet.com> skrev i meddelandet =
news:ee6ed78.3@WebX.sUN8CHnE...
> There is no way to convert a PZ5032CS to an Altera CPLD unless these =
components are able to go at a 100uA consumption !
>=20
> However, Betsy is right because XPLA3 is pinout compatible with XPLA =
or XPLA Enhanced. You should also know that XPLA 3 is 5V tolerant. So, =
the issue is just to provide a 3.3V power supply on the XPLA 3. We 've =
already converted designs with success.
> It seems easier to convert 5V to 3.3V than 10mA to 100uA.


So again you have a better choice with the Atmel ATF15xx
which is 5V and need no conversion...

--=20
Best Regards
Ulf at atmel dot com
These comment are intended to be my own personal view
and may or may not be shared by my Employer Atmel Sweden.

(I'll bet $0,02 they'll share this though :-)


> Olivier REGNAULT
> Xilinx FAE
> AVNET France

Article: 27641
Subject: Off subject-WIRELESS H/W S/W - pre IPO - San Jose
From: howard@recruitexpress.com (Recruit Express)
Date: Fri, 01 Dec 2000 02:25:32 GMT
Links: << >>  << T >>  << A >>
WIRLESS PDA  DEVELOPERS - San Jose
ASIC, FPGA, Windows Device Drivers 

Pre-IPO firm in San Jose area needs several developers for
new modules and components to be developed for use with
wireless PDA devices.  This is a new technology and a 'fresh
paint' - clean canvas' opportunity for you!

Hardware engineers should have 3 years design experience
in FPGA and ASIC.   

Software engineers should have 2 years development experience -  
on Windows device drivers and be proficient in C.   

We want to hire you immediately!  Our salary range is from
$80K to $125K plus other financial opportunities - based upon
the depth of your skills and the breadth of your experience.  

We are interested in persons living in the Bay Area only.  
We prefer to offer permanent employment but will consider
contractors.  U.S. citizenship or work permit required.  
We will sponsor visas of persons living in the Bay Area.


Recruit EXpress, our search firm, will pay you a $3,000.00
bonus if you are hired - or if the persons you refer to them 
are also hired for our openings. We have six openings.


Call or send your resume to Rex or Howard Frankel, at
Recruit EXpress
 (713) 666-1001 ....  or fax (713) 666-9993.  Their email is: 

REX@RecruitEXpress.com

or

HOWARD@RecruitEXpress.com

 


Article: 27642
Subject: jtag for fpga
From: xiao_john@excite.com (frank johson)
Date: 1 Dec 2000 04:49:49 +0100
Links: << >>  << T >>  << A >>
Can the Jtag interface be used to debug the FPGA (Xilinx or Altera) ? 
We developed some code for ASIC that has JTAG interface.First we want to
download to FPGA to verify code function,so I suppose the JTAG function is
same as ASIC that I can debug the hardware detail in FPGA. 
Any suggestion are welcome.

Regards
Frank






_______________________________________________________
Tired of slow Internet? Get @Home Broadband Internet
http://www.home.com/xinbox/signup.html


-- 
Posted from kuku-rwcmta.excite.com [198.3.99.63] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 27643
Subject: Re: Orca 3t sram gsr question
From: "Bryan" <bryan@srccomp.com>
Date: Thu, 30 Nov 2000 21:51:42 -0700
Links: << >>  << T >>  << A >>
just make a hard macro of the sram, forget the tool, handroute your address
to half lines(assuming this ram is of substantial size).  Thats the best way
with ORCA 3T.  You'll get a lot better performance anyway.
Bryan
jj <jj@rad.com> wrote in message
news:975572872.22779.0.nnrp-07.9e98b073@news.demon.co.uk...
> Hi
>      I am instantiating DCE32x4 dual port srams in a 3T125, when you look
at
> the srams in EPIC there in a GSR Enable/ Disable option, neither have been
> highlighted.
> How do you select this option within the HDL, I have instantiated a GSR
> component but these does not solve the problem.
>
>
>
> J
>
>


Article: 27644
Subject: Re: Synplify Benchmarks
From: Ray Andraka <ray@andraka.com>
Date: Fri, 01 Dec 2000 05:25:31 GMT
Links: << >>  << T >>  << A >>
Use GSR to initialize all your FF's, but then have only one point in your design
depend on when the GSR is released.  For example, use a synchronized version of
GSR to hold a master state machine in reset after GSR is released, then after
GSR is safely gone away let the thing start going.

Magnus Homann wrote:
> 

> > The recommendation to not use the global GSR is due to poor implementation
> > (it's quite slow) of the dedicated metal in the Xilinx part.  This timing
> > issue is EASILY overcome in the design such that it will not cause any
> > problems.
> 
> Really? How? I never use it, I stick with sync reset.
> 

-- 
-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: 27645
Subject: Re: jtag for fpga
From: "Marc Roche" <marc.roche@mvd-fpga.com>
Date: Fri, 01 Dec 2000 07:49:03 GMT
Links: << >>  << T >>  << A >>
Yes the JTAG interface be used to configure and readback the FPGA on Xilinx.

Xilinx provide a wide range of FPGA sush as VIRTEX, VIRTEX-E, VIRTEX-EM that
offers you the possibility to carry out the prototype of your ASIC.

My company has some good experiment in prototyping ASICs on Virtex family.

Regards

Marc ROCHE
--
Design Ingeneer
Multi Video Designs
106 av des Guis
31830 Plaisance du Touch
France
Tel.: +33(0) 5 62 13 52 32
Fax.: +33 (0) 5 61 06 72 60
mailto : marc.roche@mvd-fpga.com
http://www.mvd-fpga.com




Article: 27646
Subject: Re: Synplify Benchmarks
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 01 Dec 2000 10:04:06 +0100
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:

> Use GSR to initialize all your FF's, but then have only one point in
> your design depend on when the GSR is released.  For example, use a
> synchronized version of GSR to hold a master state machine in reset
> after GSR is released, then after GSR is safely gone away let the
> thing start going.

Sounds like a resonable way of doing it. I'll remember that until next
time.

Doesn't that mean you have to make a fairly structured design, though?
:-)

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 27647
Subject: Re: Synplify Benchmarks
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 01 Dec 2000 10:06:49 +0100
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroo98m.com> writes:

> > > The recommendation to not use the global GSR is due to poor
> implementation
> > > (it's quite slow) of the dedicated metal in the Xilinx part.  This
> timing
> > > issue is EASILY overcome in the design such that it will not cause any
> > > problems.
> > 
> > Really? How? I never use it, I stick with sync reset.
> 
> Be glad to tell you ;-)  First, make sure ALL the registers in the design
> have a positive asynch set or reset.  Second, instantiate the STARTUP
> block:

Wait, this looks like Verilog! :--)

[Code deleted]

> Also, in your state machines, I would suggest an extra startup state before
> looking at any input signals.
> 
> If you do all this, Synplicity will automatically use the global GSR.  I
> may have missed something...if I did, please let me know.

If I managed to read your Verilog, you use the GSR as a regular async
reset? I prefer to use sync reset, to assure that all FFs sees the
reset go away on the same clock pulse.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 27648
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: "fred" <x@y.z>
Date: Fri, 1 Dec 2000 09:21:54 -0000
Links: << >>  << T >>  << A >>

"Hal Murray" <murray@pa.dec.com> wrote in message
news:906m4r$gvh@src-news.pa.dec.com...
>
>>From your comments about 2.5 & 3.3V Vcco I have assumed
you're talking Xilinx here and my comments relate to that
target only:

> > > Anybody know any good reason not to use LVPECL instead
of LVDS if
> > > you get to design both ends?
I'll be doing the same, but only for clocks and for the
reason of reduced power supply count. Have you noticed that
the Xil driver imp obtains LVDS & PECL levels by a resistive
divider chain frig & that the outputs (I believe) perform a
full rail swing (p67 of the latest Virtex-E data sheet). 17
x 3res at the TX end is a bit of a pain - yes, I know the
sheet says there is a combo bourns part but would expect
26wk lead and long term supply headaches. I'd keep the
traces to those res as short as poss, 'cos they'll be
carrying the biggest swing.
> >
> > Power consumption and possibly emitted interference.
>
> I fed some numbers to the Xilix power estimator.
>
>   I told it 17 inputs, 17 outputs, 50% toggle rate, and 20
pf.
>   It said 85 mW for LVDS and 135 mW for LVPECL.
>   So the LVPECL mode uses ~60% more power.
still peanuts?
>
>   That's 34 mA for LVDS and 41 mA for LVPECL.
>   Or roughly 20% more current.  Or only 20% more
>   total power if you are using a linear regulator.
>   Of course, the 60% savings in the Xilinx might be
important in
>   your design/application.
>
>
> I can't find a simple/clean way to estimate the EMI
difference.  They
> both expect a 100 ohm terminator.  I'm willing to assume
the traces
> and cables/connectors are the same.  So all we need is the
voltage or
> current.  That's assuming the edge rates are the same
which may be bogus.
>
> The spec sheet says 250-450 mV for LVDS output and 300 mV
min input
> for LVPECL.  Same ballpark.
No, I think its 350mV for LVDS and 850mV on PECL, at least
for the way that Xil generate them, but if you are using
matched parallel (paired) traces or a short twisted pair,
screened cable you are talking a *massive* reduction running
single ended (or even full swing diff).


>
>
>
>
> --
> These are my opinions, not necessarily my employers.  I
hate spam.


Article: 27649
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: "fred" <x@y.z>
Date: Fri, 1 Dec 2000 09:48:09 -0000
Links: << >>  << T >>  << A >>
Hal,

I will also look at implementing my design with LVDS
primitives then use a 3.3V Vcco supply and alter the dropper
resistor values so the LVDS rx sees a +/-350mV swing. The
specified Vicm of the Xil LVDS receiver appears to cope with
the slightly higher common mode voltage from the 3.3V supply
(1.65 vs 1.25V)

If you want the res values I calc, just shout.

Dave




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