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 46475

Article: 46475
Subject: Re: The Prodigal Son
From: Tom Liehe <moox@flatland.dimensional.com>
Date: 30 Aug 2002 20:36:36 -0600
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:
> Xilinx welcomes Steve Knapp, back from 5 years trying his luck
> elsewhere.
> We are glad he found the way back home, where he belongs !

ALl right!  Good to hear.

Steve was my FAE back in late 1985 when I started using
the XC2064.  I had a design which wouldn't quite fit.
He was convinced he could squeeze in the one last net I 
needed to route.  He beat on it for hours but finally
had to admit I'd filled it all the way up.  Had to put
1 discrete 3-in NOR on the PCB :-)

Anyway he was definitely a great FAE. What will he be
doing now?

Tom (at StorageTek in Colorado)

Article: 46476
Subject: Re: Spartan-II inrush and other power suppy isues (was Re: need cheap and dirty time delay for spartan2e)
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 31 Aug 2002 00:40:00 -0700
Links: << >>  << T >>  << A >>
I asked:
> XAPP450 says that Vccint and Vcco should be applied simultaneously to the
> Spartan-IIE devices, but does not mention the Spartan-II.  Will bad things
> happen with the Spartan II if Vcco is available earlier than Vccint?

Austin Lesea <austin.lesea@xilinx.com> writes:
> Nope.  Spartan II does not care if Vcco is applied before, or after (or with)
> Vccint.

So a half hour earlier or three weeks later is OK?

Thanks for answering my questions, it looks like everything should work
out the way I'd hoped.  Those Spartan II parts seem to be a great value.


Article: 46477
Subject: Re: The Prodigal Son
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Sat, 31 Aug 2002 09:05:37 +0100
Links: << >>  << T >>  << A >>
Peter,

I think you have re-acquired a fine asset there!

Good luck Steve with the return. Hope they give you time to continue your
excellent web pages in an FPGA neutral way.

I expect you'll be yet another Xilinx newsgroup poster. Hopefully that'll
encourage Altera to half-heartedly attempt to do the same.

I've been an Altera user all my working life (386-20 with original Maxplus
:) ) but due to the levels of support for Xilinx here and elsewhere I think
I know who my next large FPGA job will be with.

PS You need to sign up Ray to write that holy grail book describing how to
get the most out of your Xilinix chip.


Paul

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3D6FE22D.959F4F3B@xilinx.com...
> Xilinx welcomes Steve Knapp, back from 5 years trying his luck
> elsewhere.
> Some of you may remember his Optimagic Jumpstation.
> Here we remember him as a hell of an Applications engineer,
> a good writer, and a genuinely nice guy.
> We are glad he found the way back home, where he belongs !
>
> Peter Alfke, Xilinx Applications
>



Article: 46478
Subject: A little question
From: goodpanda35@sohu.com (Jianrong Wang)
Date: 31 Aug 2002 02:54:12 -0700
Links: << >>  << T >>  << A >>
Dear Sir:
     I like the fpga design. This is the first time i login in the
news gruop by google.com. But i think it is very complex to use google
to login.Can you tell me a simple way to use MS-outlook express to
login.
     Thank you!!

Greetings
                                    Jianrong Wang

Article: 46479
Subject: Re: A little question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 31 Aug 2002 12:17:43 +0200
Links: << >>  << T >>  << A >>
"Jianrong Wang" <goodpanda35@sohu.com> schrieb im Newsbeitrag
news:9b325b3d.0208310154.6f673fd8@posting.google.com...
> Dear Sir:
>      I like the fpga design. This is the first time i login in the
> news gruop by google.com. But i think it is very complex to use google
> to login.Can you tell me a simple way to use MS-outlook express to
> login.

Just find a news server, create a account in Outlook for news, you are done.
I use a free news server from germany

http://news.cis.dfn.de/

You need to register, but its all free.

--
MfG
Falk




Article: 46480
Subject: Re: gate the main FPGA clk
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 31 Aug 2002 12:31:28 +0200
Links: << >>  << T >>  << A >>
"Denis Gleeson" <dgleeson@utvinternet.com> schrieb im Newsbeitrag
news:6f080894.0208301342.1e68894d@posting.google.com...
> Hi Peter
>
> Thanks for your response.
> One of the things that concerns me is the number of pins on a device.
> If it comes to it I am hoping to mount these devices on the PCB myself.
> Certainly for prototypes anyway.
>
> So in keeping to a PLCC84 package I see that I could get a XCS05XL
> or XCS10XL at low cost in small quantities.  I see that I can even get
> a PLCC84 XCS05 spartan device at a good price.

Why using a SPARTAN?? Peter suggested a SPARTAN-II or SPARTAN-IIE. Sounds
similar, but is very different. Yes, these families are not available in
PLCC, but you can solder a QFP by hand without major problems. Even a BGA
has been soldered by hobbyists.

http://wwwbode.cs.tum.edu/~acher/bga/index.html

;-)))

> Can you comment on possible problems I might come across when gating the
> 100MHz
> clk with say the XCS05XL.

1st. better use Spartan-II.
2nd, if you are going to gate the 100MHz, you do this usually be using a AND
gate, with one input beeing the clock, the other the enable signal. To make
the gated clock glitch free, you must generate the enable signal by a
FlipFlop, which is clocked on the falling edge of the 100 MHz.

--
MfG
Falk

P.S: Is there a difference/definition of glitch and runt pulse?





Article: 46481
Subject: Re: SDRAM - is concurrent auto precharge common?
From: spam_hater_7@email.com (Spam Hater)
Date: Sat, 31 Aug 2002 16:29:49 GMT
Links: << >>  << T >>  << A >>
On Fri, 30 Aug 2002 15:09:17 GMT, spam_hater_7@email.com (Spam Hater)
wrote:

>Paul,
>
>The place to check to see if it's "very common" is Intel's PC100
>specification.
>
>IME, all SDRAMs will do auto-precharge, but...
>
>1) It's only useful if you always do the same size burst.
>
>2) It doesn't really save you any cycles.  You activate C while
>transferring from B, you can precharge A while transferring from B
>also.

Unless you're using precharge to terminate the burst...  But you can't
use auto-precharge in that mode anyway.

>
>$.02,
>SH7
>


Article: 46482
Subject: Re: Webpack 4.2 Schematic
From: alw@al-williams.com (Al Williams)
Date: 31 Aug 2002 11:16:00 -0700
Links: << >>  << T >>  << A >>
> I would like to know, if it is possible to have a top level schematic spread
> over more than one sheet, I tried this but couldn't get it to work.

If I understand your question, the answer is yes. Right click on an
otherwise empty part of your schematic and click Object Properties.
You'll see a property dialog for sheets. Click new. Then you can add
sheets. The sheets will show tabs to the left. Nets named the same
thing connect even if they don't look connected.

You might be interested in our WebPack tutorial (we have one for
Altera too) at http://tutor.al-williams.com

Good luck!

Al Williams
AWC
CPLD Prototyping boards: http://www.al-williams.com/pldhome.htm

Article: 46483
Subject: Re: Webpack 4.2 Schematic
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Sat, 31 Aug 2002 23:22:07 GMT
Links: << >>  << T >>  << A >>
Excellent!

Are there any more WebPack tutorials you can recommend for a total newbie
like me?

Frank


"Al Williams" <alw@al-williams.com> wrote in message >
> You might be interested in our WebPack tutorial (we have one for
> Altera too) at http://tutor.al-williams.com




Article: 46484
Subject: Virtex/E/2/2P area efficient addmux, reiterating PAR timing modeler enhancement request
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 31 Aug 2002 22:59:36 -0700
Links: << >>  << T >>  << A >>
In my latest project to shoehorn an impossible amount of functionality into
a tiny pile of LUTs, I am once again banging my head against the tools.

You already know how I feel about the demise of TBUF-based muxes.  And how I
found a way, using carry-logic and MULT_AND tricks, to implement
  o = sel ? a + b : c;
in one LUT per bit.  Call this an "addmux".

Unfortunately the tools model the timing through this construction too
pessimally. In my latest design, I would like to have a series of addmuxes
in series, and the estimated timing is about 100% higher than reality
(including several bogus charges of Topcyf and Tcinx) (in effect blowing out
the cycle time).

Please see
http://groups.google.com/groups?selm=995523%24paj%241%40slb6.atl.mindspring.
net for a recap and explanation of what I am talking about.

In a nutshell, in implementing "o = sel ? a + b : c;" in one LUT per bit as
described, the timing tools propagate delays along false paths from all
inputs c[i] to all outputs o[j], j>i and unnecessarily incurring Topcyf and
Tcinx on these false paths from c[i] to o[j].

A finer grained timing modeler could determine (by considering the slice's
LUT and mux switch settings) that there is no carry out when sel is 0, and
thus while there are timing paths from a[i] to o[j], j>i, and from b[i] to
o[j], j>i, there are none from c[i] to its carry out, and thence to o[j],
j>i, and no Topcyf and Tcinx on paths from c[i], either.

In my design, to make timing, it appears necessary to unfactor both addmuxes
into separate adds and muxes, two LUTs per bit:
   sum = a + b
   o = sel ? sum : c
for which, even though twice as large and a Tilo slower, the timing tools do
the right thing with.

Proposal 1: It would be nice if this topolgy were automatically recognized
by the path timer.  Or...

Proposal 2: I would also be happy to ANNOTATE the LUT asserting that input
c[i] is insensitive to the carry chain and to asserting that c[i] delays do
not propagate up the carry chain.  Or...

Proposal 3: I would also be happy to instantiate a special ADDMUX PRIMITIVE
which rings the appropriate bells in the path timer, and sets the LUT and
associated muxes up the same way I am trying to do manually.  Or...

Proposal 4: I would also be happy to use some convenient TIG like mechanism
to deny these false paths. Currently it looks like I have to ignore the path
from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on
for several dozens of such addmuxes in a big design.

What do you think, Xilinx?  Do you understand what I am asking for?  Is it
too far off the mainstream?  If you fixed this, then the synthesis vendors
could take advantage of this trick and halve areas of certain circuits.

Ken McElvain, would Synplicity use this addmux technology mapping trick if
the Xilinx path timer did a better job?

Thank everyone,
Jan Gray, Gray Research LLC




Article: 46485
Subject: Thermoelectric Controller by FPGAs
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 31 Aug 2002 23:28:00 -0700
Links: << >>  << T >>  << A >>
Hi,
Did anyone build a controller for thermoelectric coolers by PWM method
and FPGAs?
I want to do this, but i didn't know pwm frequency for 0.01C
resolution. I guess there are other potential problems. please let
know them
best regards
masoud naderi

Article: 46486
Subject: Re: Question on Fast CPLDs
From: Kenneth <kenneth.lee@terapower.com.hk>
Date: Sun, 01 Sep 2002 14:38:00 +0800
Links: << >>  << T >>  << A >>
Hi Falk,

Thanks for your reply.
I have further checked the datasheet of Coolrunner-II.  Actually
they don't have clock doubler.  However, it contains DualEDGE 
register which allows something like DDR operation inside.  As 
a result, it allows a clock input which is half of your targeted
operating frequency.

Regards,
Kenneth


Falk Brunner wrote:
> 
> "Kenneth" <kenneth.lee@terapower.com.hk> schrieb im Newsbeitrag
> news:3D6F189F.972F1C46@terapower.com.hk...
> > Dear All,
> >
> > Currently I have a design which is quite simple and am planning to
> > implement it in a CPLD.  However, the target operating speed is
> > around 300MHz.
> >
> > After searching, I found that some CPLDs from Xilinx and Lattice
> > are claimed to be able to operate at more than 300MHz.  However,
> > it seems that there is no PLL/DLL inside their CPLDs.  So how can
> > they operate at this high frequency?  Does it mean that I need to
> 
> AFAIR the new Coolrunner-II have a clock doubler inside.
> 
> --
> MfG
> Falk

Article: 46487
Subject: Re: Webpack 4.2 Schematic
From: "Stephan Flock" <sflock@t-online.de>
Date: Sun, 1 Sep 2002 10:43:09 +0200
Links: << >>  << T >>  << A >>
Thank you Al, this was of great help!

Regards,
Stephan Flock



Article: 46488
Subject: Re: Thermoelectric Controller by FPGAs
From: Janusz Raniszewski <rniski@man.koszalin.pl>
Date: Sun, 01 Sep 2002 12:46:24 +0200
Links: << >>  << T >>  << A >>
> Did anyone build a controller for thermoelectric coolers by PWM method
> and FPGAs?
> I want to do this, but i didn't know pwm frequency for 0.01C
> resolution.

Hi,
I don't know what is relation between frequency of the PWM and temperature
resolution. You may consider only PWM resolution. Is enough 8 bit
resolution of the PWM only for setup temperature and 10 bit for adjust.
Frequency of the PWM is important for thermal inertion of the adjusted
object. Another matter is more easier solution by microcontroller with
PWM.
JanuszR


Article: 46489
Subject: Re: Virtex/E/2/2P area efficient addmux, reiterating PAR timing modeler enhancement request
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sun, 1 Sep 2002 14:33:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
Just a guess, but...

IS this Virtex 2?  


In article <aksal0$oee$1@slb2.atl.mindspring.net>,
Jan Gray <jsgray@acm.org> wrote:
>Proposal 4: I would also be happy to use some convenient TIG like mechanism
>to deny these false paths. Currently it looks like I have to ignore the path
>from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on
>for several dozens of such addmuxes in a big design.

Write a perl script to generate these?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46490
Subject: Re: Webpack 4.2 Schematic
From: alw@al-williams.com (Al Williams)
Date: 1 Sep 2002 08:19:21 -0700
Links: << >>  << T >>  << A >>
> Are there any more WebPack tutorials you can recommend for a total newbie
> like me?

Glad you enjoyed the tutorial. I wrote it because I was very
frustrated that there were few practical examples that actually talked
about simulation. There are many good Verilog and VHDL tutorials, and
a few that work with schematic entry. Most use Foundation or some
other tool, too.

http://www.ee.byu.edu/ee/class/ee224/tutorials/tools_tutorial/xilinx/xilinx.html
has a terse tutorial. You can find many with a google search on
WebPack and tutorial, but like I say, many ignore simulation.

Al Williams
AWC
http://www.al-williams.com

Article: 46491
Subject: Re: Webpack 4.2 Schematic
From: alw@al-williams.com (Al Williams)
Date: 1 Sep 2002 08:23:33 -0700
Links: << >>  << T >>  << A >>
Wow, after posting, I did a quick google search and dug for some I had
not seen before. This site has an excellent looking tutorial in PDF:
http://www.trenz-electronic.de/down/tc-XC2S-SoC-2.pdf

Geared at Spartan II, but the WebPack stuff is pretty much the same
(pretty much, not exactly) no matter which part you are using.

Al Williams
AWC
http://www.al-williams.com/pldhome.htm

Article: 46492
Subject: Multiplexing a tristate bus?
From: "Niv" <niv@ntlworld.com>
Date: Sun, 1 Sep 2002 17:47:44 +0100
Links: << >>  << T >>  << A >>
Hi, any thoughts on muxing a tristate bus?

I have the following scenario in a Virtex design:

About 10 blocks that all communicate to a CPU via a single tristate bus, one
at a time of course.
However, two of these blocks are deemed "safety critical".  So, to enhance
the design safety, it has been decided that these two blocks should be
isolated from the rest.

To this end, their outputs will be permanently enabled, and fed to a mux.,
but what to do with the other 8 or so blocks?

It is a major redesign to make them all permanent outputs and mux all 10
buses. (Not difficult, but very time consuming).

So, is it a "safe" design to put the 8 block tristate bus into the mux; the
mux thus having 3 bus inputs and a single bus output to the CPU?  I should
add that I've built a noddy design that does just this, and no complaints
from synth. or PAR.  However, the RTL sim. gives different response to gate
level sim.  The RTL passes the 'Z's state thru' the mux (as expected), but
the gate level sim. passes "FF" (all '1's) thru' the mux. when the tristate
bus is selected (and undriven).  This all seems OK, but not sure of the
validity of it all.

What exactly is pulling the tristate bus up within the chip, there is
nothing obvious when looking at the chip editor.

Any help much appreciated, NIV.



Article: 46493
Subject: Re: Thermoelectric Controller by FPGAs
From: "Eric Braeden" <braeden@erinet.com>
Date: Sun, 1 Sep 2002 13:28:55 -0400
Links: << >>  << T >>  << A >>

"Masoud Naderi" <naderimisc@yahoo.com> wrote in message
news:2ba3bbea.0208312227.646e1ad3@posting.google.com...
> Hi,
> Did anyone build a controller for thermoelectric coolers by PWM method
> and FPGAs?
> I want to do this, but i didn't know pwm frequency for 0.01C
> resolution. I guess there are other potential problems. please let
> know them
> best regards
> masoud naderi

I believe that TEC's are very sensitive to AC ripple on the DC power.
I also believe that most TEC manufacturers do not recommend PWM
for this reason.




Article: 46494
Subject: Re: Thermoelectric Controller by FPGAs
From: "Spehro Pefhany" <speff@interlog.com>
Date: Sun, 01 Sep 2002 17:49:16 GMT
Links: << >>  << T >>  << A >>
The renowned Masoud Naderi <naderimisc@yahoo.com> wrote:
> Hi,
> Did anyone build a controller for thermoelectric coolers by PWM method
> and FPGAs?
> I want to do this, but i didn't know pwm frequency for 0.01C
> resolution. I guess there are other potential problems. please let
> know them

The hardware on many microcontrollers will let you do this without an
FPGA. I suggest you consider L-C filtering of the
output, because, as another poster mentioned, the RMS-to-average ratio
should be kept as close to 1 as possible, as these things are VERY
inefficient, and you want to minimize I^2R heating. A frequency in the
20-40kHz range should be okay, and can be done by off-the-shelf micros
with their onboard hardware. OTOH, if you used an FPGA you could go very
high in frequency and use a smaller filter inductor, with a more
sophisticated output stage.  

Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
9-11   United we Stand 

Article: 46495
Subject: Re: gate the main FPGA clk
From: dgleeson@utvinternet.com (Denis Gleeson)
Date: 1 Sep 2002 10:52:37 -0700
Links: << >>  << T >>  << A >>
Hi Nicholas

Thanks for your response. This goes to everybody else as well.

There are a few terms here that I am not familiar with, can you point
me at a device so that I might understand "DLL" and "opad"

Denis

nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<akob6o$1gpd$1@agate.berkeley.edu>...
> In article <6f080894.0208291343.4746da5a@posting.google.com>,
> Denis Gleeson <dgleeson@utvinternet.com> wrote:
> >Hello all
> >
> >Im new to this FPGA design stuff so any help or redirection
> >will be appreciated.
> >
> >My problem is this. I am feeding an FPGA with a 100MHz clock.
> >Under certain conditions I want to feed this clock to a pin 
> >on my FPGA as an output.
> >To allow for the condition I need to gate the Main clock 
> >with what I have below. 
> 
> One possibility, on a more modern part: You could take the 100 MHz
> clock, feed it through the DLL to get a 200 MHz clock as well, have
> THAT be the clock on the Opad flip flop, and have the 100 MHz clock,
> gated, be the input to that flip flop.  Voila, no clock glitching,
> runt pulses, or anything.
> 
> >PS. I am targeting a xilinx XC3020
> 
> You're making a 3020 run at 100 MHz?  You sure you have the part
> number right?

Article: 46496
Subject: Re: gate the main FPGA clk
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sun, 1 Sep 2002 18:13:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <6f080894.0209010952.24239dee@posting.google.com>,
Denis Gleeson <dgleeson@utvinternet.com> wrote:
>Hi Nicholas
>
>Thanks for your response. This goes to everybody else as well.
>
>There are a few terms here that I am not familiar with, can you point
>me at a device so that I might understand "DLL" and "opad"

OPAD is just the output pad.  The current Xilinx parts include flip
flops on the output pads.

The DLL or Delay Lock Loop is present in Virtex/Spartan II and beyond,
its the device for generating a clean clock.  It can take an input
clock and double it, and take both the clock and the doubled clock and
distribute it across the chip.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46497
Subject: Re: Thermoelectric Controller by FPGAs
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 01 Sep 2002 18:40:18 GMT
Links: << >>  << T >>  << A >>
Masoud, can you please explain to me and other non-experts:
What is a thermo-electric cooler?
Do you mean an electronic Peltier-effect device?
Or do you mean a fan?

Where do you get the sub-one-degree accuracy from, and why does it
matter? I would think that the purpose is to cool the IC, and the
difficulty is measuring the junction temperture. And at significant
localized power dissipation, where and how do you measure the
temperature?

Lots of questins before we start arguing PWW frequency...
Maybe I just do not understand the basics.
Peter Alfke, Xilinx Applications

Masoud Naderi wrote:

> Hi,
> Did anyone build a controller for thermoelectric coolers by PWM method
> and FPGAs?
> I want to do this, but i didn't know pwm frequency for 0.01C
> resolution. I guess there are other potential problems. please let
> know them
> best regards
> masoud naderi


Article: 46498
Subject: Re: Virtex/E/2/2P area efficient addmux, reiterating PAR timing modeler enhancement request
From: John_H <johnhandwork@mail.com>
Date: Sun, 01 Sep 2002 11:56:08 -0700
Links: << >>  << T >>  << A >>
For the add-mux you're implementing, I used the following syntax in 
Verilog to get the desired results:
   o <= (sel ? a : c)
      + (sel ? b : 0);
which results in the carry chain / mult-and combo from the tool, no 
tricks with primitives or with manually constructing carry chains.  The 
only conceptual trick is that the synthesis sees the adder at a level 
above the logical manipulation - it's tough to look into a mux of two 
adders for optimization but easier to add two muxes.

For the timing problems, I've used a "TPTHRU" constraint on a few items 
that - with the appropriate wildcards - may give you what you need.  In 
the constraints guide for TPTHRU you'll find UCF syntax that might get 
you going.

http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/t9.html

There may be a need to stick to "one" through-point per spec, but syntax 
would get you there even if the timing report is ugly (as long as you 
have reliable naming).  If multiple TPTHRU elements can be lumped 
together, I'd expect something on the order of:

NET o_cry* TPTHRU = addmuxcry;
TIMESPEC TSloadTiming = FROM c[*] THRU addmuxcry TO o[*] 20 ns;

where 20ns is a value that's way beyond your timing needs (roughly 
equivalent to a timing ignore) and the o_cry* would be the MUXCY output 
net names.  This allows the points from a or b through the carries to 
still use the timespec defined elsewhere and from c[*] to o[*] directly 
to also be specified.  The FROM and TO points should both be flops which 
might make the specification interesting in your cascaded addmux 
elements but doable.

- John_hasntusedtbufinyears_H


Jan Gray wrote:

> In my latest project to shoehorn an impossible amount of functionality into
> a tiny pile of LUTs, I am once again banging my head against the tools.
> 
> You already know how I feel about the demise of TBUF-based muxes.  And how I
> found a way, using carry-logic and MULT_AND tricks, to implement
>   o = sel ? a + b : c;
> in one LUT per bit.  Call this an "addmux".
> 
> Unfortunately the tools model the timing through this construction too
> pessimally. In my latest design, I would like to have a series of addmuxes
> in series, and the estimated timing is about 100% higher than reality
> (including several bogus charges of Topcyf and Tcinx) (in effect blowing out
> the cycle time).
> 
> Please see
> http://groups.google.com/groups?selm=995523%24paj%241%40slb6.atl.mindspring.
> net for a recap and explanation of what I am talking about.
> 
> In a nutshell, in implementing "o = sel ? a + b : c;" in one LUT per bit as
> described, the timing tools propagate delays along false paths from all
> inputs c[i] to all outputs o[j], j>i and unnecessarily incurring Topcyf and
> Tcinx on these false paths from c[i] to o[j].
> 
> A finer grained timing modeler could determine (by considering the slice's
> LUT and mux switch settings) that there is no carry out when sel is 0, and
> thus while there are timing paths from a[i] to o[j], j>i, and from b[i] to
> o[j], j>i, there are none from c[i] to its carry out, and thence to o[j],
> j>i, and no Topcyf and Tcinx on paths from c[i], either.
> 
> In my design, to make timing, it appears necessary to unfactor both addmuxes
> into separate adds and muxes, two LUTs per bit:
>    sum = a + b
>    o = sel ? sum : c
> for which, even though twice as large and a Tilo slower, the timing tools do
> the right thing with.
> 
> Proposal 1: It would be nice if this topolgy were automatically recognized
> by the path timer.  Or...
> 
> Proposal 2: I would also be happy to ANNOTATE the LUT asserting that input
> c[i] is insensitive to the carry chain and to asserting that c[i] delays do
> not propagate up the carry chain.  Or...
> 
> Proposal 3: I would also be happy to instantiate a special ADDMUX PRIMITIVE
> which rings the appropriate bells in the path timer, and sets the LUT and
> associated muxes up the same way I am trying to do manually.  Or...
> 
> Proposal 4: I would also be happy to use some convenient TIG like mechanism
> to deny these false paths. Currently it looks like I have to ignore the path
> from c[0] to o[1..31], from c[1] to o[2..31], ... c[30] to o[31], and so on
> for several dozens of such addmuxes in a big design.
> 
> What do you think, Xilinx?  Do you understand what I am asking for?  Is it
> too far off the mainstream?  If you fixed this, then the synthesis vendors
> could take advantage of this trick and halve areas of certain circuits.
> 
> Ken McElvain, would Synplicity use this addmux technology mapping trick if
> the Xilinx path timer did a better job?
> 
> Thank everyone,
> Jan Gray, Gray Research LLC
> 
> 
> 
> 


Article: 46499
Subject: Re: Multiplexing a tristate bus?
From: John_H <johnhandwork@mail.com>
Date: Sun, 01 Sep 2002 12:05:04 -0700
Links: << >>  << T >>  << A >>
Virtex chips use a tristate emulation for the internal tristates busses; 
there is no "undriven" state with undefined outputs (defaults to 
logic-high when undriven) and there is no bus contention (multiple 
drivers result in a zero winning out over ones).

For some simulation problems with tristates in the past (old gate level 
models or possibly RTL), I defined the drivers as weak high, strong low 
and added pullups to the nets.  The result is behavior like the tristate 
emulation logic - no drivers result in logic high and a single logic low 
for multiple drivers has a logic low result for the net.  Perhaps you 
can work the strength and pullup into your RTL simulation.


Niv wrote:

> Hi, any thoughts on muxing a tristate bus?
> 
> I have the following scenario in a Virtex design:
> 
> About 10 blocks that all communicate to a CPU via a single tristate bus, one
> at a time of course.
> However, two of these blocks are deemed "safety critical".  So, to enhance
> the design safety, it has been decided that these two blocks should be
> isolated from the rest.
> 
> To this end, their outputs will be permanently enabled, and fed to a mux.,
> but what to do with the other 8 or so blocks?
> 
> It is a major redesign to make them all permanent outputs and mux all 10
> buses. (Not difficult, but very time consuming).
> 
> So, is it a "safe" design to put the 8 block tristate bus into the mux; the
> mux thus having 3 bus inputs and a single bus output to the CPU?  I should
> add that I've built a noddy design that does just this, and no complaints
> from synth. or PAR.  However, the RTL sim. gives different response to gate
> level sim.  The RTL passes the 'Z's state thru' the mux (as expected), but
> the gate level sim. passes "FF" (all '1's) thru' the mux. when the tristate
> bus is selected (and undriven).  This all seems OK, but not sure of the
> validity of it all.
> 
> What exactly is pulling the tristate bus up within the chip, there is
> nothing obvious when looking at the chip editor.
> 
> Any help much appreciated, NIV.
> 
> 
> 




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