1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar 2019

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 24425

Article: 24425
Subject: Re: Circuit Drawing
From: Sigurd Urdahl <sigurdur@naglfar.ifi.uio.no>
Date: 08 Aug 2000 01:45:27 +0200
Links: << >>  << T >>  << A >>
"Goulas George" <george_goulas@hotmail.com> writes:

>
> It's a bit irrelevant to this newsgroup...
>
> I need a drawing program that produces good looking digital circuit designs.
> I've tried Visio, but I could n't find muxes or ffs.
> I don't need all the graphic detail of the good digital
> simulation programs, I just need to present some
> circuits....

Good(?), old digilog from the Chipmunk tools package (www.google.com
*nix box.

-sig

--
sigurd urdahl

Article: 24426
Subject: Re: Xilinx Foundation 3.1i
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 07 Aug 2000 20:26:21 -0400
Links: << >>  << T >>  << A >>
I had not given this issue a lot of thought, but then I took a look at
the Xilinx web site to see just what was going on and I found out a lot.

The Foundation tools have been broken into two sets, the standard
schematic based tools and the new ISE tools. The base schematic tools
have gone up in price from $500 to$1000 with no useful additional
features or products that I can see.

The new ISE tools come with crippled simulation tools (Allstar tools).
The description says, "If your design needs exceed the capabilities of
the ALLSTAR tools, upgrades are available for purchase directly from
each of the partners.  These upgrades utilize the same user interface of
the ALLSTAR tool, while providing increased performance and/or
capacity." But I can't find a description of the limitations of these
tools.

Not only is Xilinx now renting the tools vs. selling you the tools, they
are promoting support with "you get what you pay for" marketing.

- PLATINUM Hotline Service with premium access
- 8 Xilinx education credits (an $800 value) So it appears that Xilinx is doing what Microsoft has done and created a mechanism to get support and another mechanism to get "good" support for a higher price. Is it me, or is this something to get bugged about? Rick Filipkiewicz wrote: > > Is it worth upgrading from 2.1iSP6 to the new s/w ? Any experiences good > or bad ? > > Considering that I now have to pay the time based license'' fee aka > the shareholders are complaining and chip prices are competitive so > lets make more money out of the s/w' I want to know what the benefits > are, if any. > > I don't actually mind paying a fair bit for Xilinx s/w - our original > total outlay up to XCV1000 was about UKP3500 - since in general its > pretty good. But I do strongly object to it timing out after a year. I > want to buy the s/w, not rent it. > > Note for the lawyers: Normally if you are renting something and it goes > wrong its the responsibility of the owner to get it fixed or replaced. > Does this mean I can demand an instant fix for any serious bug I trip > over ? -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com  Article: 24427 Subject: Re: Xilinx Foundation 3.1i From: Rick Filipkiewicz <rick@algor.co.uk> Date: Tue, 08 Aug 2000 02:08:02 +0100 Links: << >> << T >> << A >>  rickman wrote: > I had not given this issue a lot of thought, but then I took a look at > the Xilinx web site to see just what was going on and I found out a lot. > > The Foundation tools have been broken into two sets, the standard > schematic based tools and the new ISE tools. The base schematic tools > have gone up in price from$500 to $1000 with no useful additional > features or products that I can see. > That's the conclusion I sort of came to. As far as I can see all that ISE has done is to emulate the shining example of Visual C/C++. The only addition I can detect is that there is now, finally, some sort of source code revision control mechanism > > The new ISE tools come with crippled simulation tools (Allstar tools). > The description says, "If your design needs exceed the capabilities of > the ALLSTAR tools, upgrades are available for purchase directly from > each of the partners. These upgrades utilize the same user interface of > the ALLSTAR tool, while providing increased performance and/or > capacity." But I can't find a description of the limitations of these > tools. > Oh good. > > Not only is Xilinx now renting the tools vs. selling you the tools, they > are promoting support with "you get what you pay for" marketing. > > The PLATINUM DPP adds: > > - PLATINUM Hotline Service with premium access > This sort of thing is an indication that its time to design out the parts and sell your shares since the marketing people have staged a coup d'etat. > - Access to engineers with increased expertise > - 8 Xilinx education credits (an$800 value)
>
> So it appears that Xilinx is doing what Microsoft has done and created a
> mechanism to get support and another mechanism to get "good" support for
> a higher price.

Maybe they've decided to really work at getting the tools as good as MS s/w.

>
> Is it me, or is this something to get bugged about?

No its not just you so I suggest we Xilinx users all get seriously bugged
together or we
will most assuredly be bugged individually.


Article: 24428
Subject: Re: Place&Route report of spartan2
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 08 Aug 2000 02:12:10 +0100
Links: << >>  << T >>  << A >>


Michael Randelzhofer wrote:

> Hi Xilinx Freaks,
>
> I'm doing my first Spartan2(XC2S50) design with Foundation 2.1i_sp6.
> In my incremental design-process in vhdl, i want to check up the left
> resources in the fpga after each design-step.
>
> The Place&route report only informs me about the used I/O's, 'slices' and
> tbufs.
>
> In my design are lots of shiftregisters which do not need any lut, but if
> only 1
> FF is used in a slice, the report seems to mark it as used.
> So the slice-count could not help me to estimate the free resources.
>
> In former Xilinx fpga families, the report gave me the exact information
> used flipflops, 4input-luts, 3input-luts and so on.
>
> Is there any other simple way to check the resources ?
> I don't want to count the used luts in the fpga-editor, or in a netlist.
> Is Foundation 3.1 a solution ?
>
> MIKE

A much better source from the Xilinx tools is the MAP report file usually
called <design>.mrp. Although PAR might add a few things here and there its
insignificant. If you are using HDL synthesis then you can get the info from
the post synth reports.

If you want the whole MAP process report you will have to set the -detail
flag.


Article: 24429
Subject: Re: XST?
From: "rodger" <rodger@bit.bucket>
Date: Mon, 7 Aug 2000 20:49:34 -0600
Links: << >>  << T >>  << A >>
XST is Xilinx Synthesis Technology and is included, I believe, with
the new Foundation ISE 3.1i. Foundation ISE 3.1i is based, I believe,
on the Synario Project Navigator and includes a schematic capture tool.

<eml@riverside-machines.com.NOSPAM> wrote in message
news:398a87b7.6740492@news.dial.pipex.com...
> On Fri, 04 Aug 2000 00:51:56 -0400, Dave Vanden Bout <devb@xess.com>
> wrote:
>
> >Xilinx Synthesis Technology?  I know they use this to synthesize netlists
from
>
> I hadn't realised it was used on Webpack, but it comes with 3.1. I
> don't know if it's priced separately or if it's a freebie. It's the
> old Minc synthesiser, acquired (I think) along with the Synario stuff
> a year or two ago, which is all re-appearing in 3.1, after some
> development. I've only seen a demo, so I've got no real details, but
> the project manager front-end will look very familiar to anyone who's
> used Synario or the later Abels. I think the Synario schematic capture
> tool is also included in the Project Manager, but I didn't see it.
>
> Evan


Article: 24430
Subject: Re: XST?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 07 Aug 2000 23:28:44 -0400
Links: << >>  << T >>  << A >>
rodger wrote:
>
> XST is Xilinx Synthesis Technology and is included, I believe, with
> the new Foundation ISE 3.1i. Foundation ISE 3.1i is based, I believe,
> on the Synario Project Navigator and includes a schematic capture tool.

What is going on with the revamp of the tools in ISE 3.1? Does anyone
have an idea of why Xilinx wants to change the toolset and start from
scratch every year or two?

Now instead of supporting two Foundation tools (Basic and Express), they
are supporting seven different versions of the tools. And then they tell
us that it is too much support work to give out the bitstream
information... ???

The one I really don't get is the Elite packages. The Express package
supports every part other than the Virtex E > 1 million gates. For those
largest two or three parts, they make you use a different package. Is
there some special reason for that???

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 24431
Subject: Re: Crossing Clock Domains.
From: "Chris Fritz" <chris.fritz@att.net>
Date: Tue, 08 Aug 2000 05:50:45 GMT
Links: << >>  << T >>  << A >>
You might check out an article in the March 2000 isd magazine (page 22-30)
by Peter Alfke.

"Moving Data across Asynchronous Clock Boundaries"

It has some good information highlighting the problems with moving data
between clock domains.

Regards,
Chris Fritz
Freestone Systems Inc.

K. Orthner <korthner@hotmail.nospam.com> wrote in message
news:8F897D1AAkorthnerhotmailcom@158.202.232.7...
> I'm working on a design where I have two clock domains.
>
> I've decided to implement everything crossing the two domains using FIFOs,
> both BlockRAM-based, and distributed RAM based.
>
> I've looked at two application notes that deal with this, One aimed at the
> Spatan-II, and one for the 4000 series.
>
> In the appnote for the 4000 series (XAPP051, 1996, Peter Afke), Grey
> counters are used to improve speed and to simplify the generation of the
> FULL and EMPTY signals to prevent "weird" states.  The new appnote for
> Spartan-II (XAPP175, 11/99) discusses pretty much the same thing, using
> grey counters and what-not, as well as keeping copies of "next_pointer"s
> make full and empty synchronous signals.
>
> The new appnote doesn't seem to consider how to prevent problems arising
> from using the two clock domains, however.  I've copied what it said
below,
> for anyone who wants to read it.
>
> In the old appnote, it suggested using latches, to latch the empty/fuill
> signal that was generated in the other clock domain, and then re-clocking
> the output of the latch with the desired clock.
>
> So, my question is, is it really suggested to use a latch at the output of
> simple combinatorial logic to "stretch" the full/empty signal and then re-
> clock it?
>
> I'm somewhat new to working in two clock domains, and I would rather
figure
> it all out now, as I'm doing my design, then later when I'm dabugging it.
>
> Thanks a million.
>
> -Kent
>
>
> From XAPP175:
>
> "To solve this problem, and to maximize the speed of the control logic,
> additional logic complexity is accepted for increased performance. There
> are primary 9-bit Read and Write binary address counters, which drive the
> address inputs to the Block RAM. The binary addresses are converted to
> Gray-code, and pipelined for a few stages to create several address
> write_nextgray) which are used to generate the Full and Empty flags as
> quickly as possible. Gray-code addresses are used so that the registered
> Full and Empty flags are always clean, and never in an unknown state due
to
> the asynchronous relationship of the Read and Write clocks. In the worst
> case scenario, Full and Empty would simply stay active one cycle longer,
> but this would not generate an error."
>


Article: 24432
Subject: Re: tbuf
From: "Andrew Ince" <andrew.ince@gecm.com>
Date: Tue, 8 Aug 2000 10:43:50 -0000
Links: << >>  << T >>  << A >>

"Domagoj" <domagoj@engineer.com> wrote in message
news:8majcd$523$1@bagan.srce.hr...
>     one of disadvantages : if you are planning to port your design to ASIC
> some day, or maybe to another FPGA family without tbufs, you'll probably
> need to rewrite your code again. so, using plain old muxes implemented in
> luts enhance  portability.

What about the Automatic replacement of internal Tristates available in
Synthesis tools.?

Andrew Ince


Article: 24433
Subject: Re: Memory specification
From: Rodolfo Jardim de Azevedo <rjazevedo@ic.unicamp.br>
Date: Tue, 08 Aug 2000 10:32:15 -0300
Links: << >>  << T >>  << A >>
rickman wrote:
>
> SRAM modules are not terribly common although they do exist. Much more
> common are DRAM modules although standard DRAM and EDO DRAM are being
> phased out. SDRAM and DDSDRAM (or whatever the acronym is for double
> data rate SDRAM) are the newer standards with more years left in them.
>
> SRAMs are easy to get as chips (other than for allocation problems >:).
> But you mention that you want density. EEPROMs are much more dense than
> SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16
> times more dense than SRAM. I can get 64 Mbit Flash chips but I don't
> think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the
> stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC.
>
> Of course Flash is much slower than SRAM, but you didn't say what speeds
> you need. If you don't need speed, SDRAM can be faster than Flash, but
> you need a more complex controller. Of course that all depends on what
> you are connecting it to.
>
> Sound complicated? It is! Until you learn about the different memory
> flavors.

Do you sugest me any book?

Thanks again,

Rodolfo

Article: 24434
Subject: Re: Memory specification
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 08 Aug 2000 09:41:39 -0400
Links: << >>  << T >>  << A >>
Rodolfo Jardim de Azevedo wrote:
>
> rickman wrote:
> >
> > SRAM modules are not terribly common although they do exist. Much more
> > common are DRAM modules although standard DRAM and EDO DRAM are being
> > phased out. SDRAM and DDSDRAM (or whatever the acronym is for double
> > data rate SDRAM) are the newer standards with more years left in them.
> >
> > SRAMs are easy to get as chips (other than for allocation problems >:).
> > But you mention that you want density. EEPROMs are much more dense than
> > SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16
> > times more dense than SRAM. I can get 64 Mbit Flash chips but I don't
> > think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the
> > stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC.
> >
> > Of course Flash is much slower than SRAM, but you didn't say what speeds
> > you need. If you don't need speed, SDRAM can be faster than Flash, but
> > you need a more complex controller. Of course that all depends on what
> > you are connecting it to.
> >
> > Sound complicated? It is! Until you learn about the different memory
> > flavors.
>
>         Do you sugest me any book?
>
>         Thanks again,
>
>                 Rodolfo

No one book, but go to the web sites for several of the memory
manufacturers and read the datasheets, the app notes and the selection
guides for all of their parts. Some good sites to visit are Micron,
Samsung and Intel. Micron data sheets are very clear and they have good
app notes. Samsung has a nice variety of parts. Intel has a poor web
site that is hard to navigate, but they sell a lot of Flash and have
some rather unique parts.

I don't think you will find much of this stuff in a text book of any
kind.

Summary:

Async SRAM - Fast to slow, no clock, no overhead for first access.

Sync SRAM - Fast, clock up to 200 MHz(?), one or two clock overhead for
first access.

EEPROM - Moderately slow, no clock, no overhead for first read, erase
and write bytes.

Async Flash - Moderately slow, no clock, no overhead for first read,
must erase in blocks.

Sync Flash - I have not used this (or even looked at it yet) but Micron
(or is it Samsung?) claims it is compatible with SDRAM.

Sync DRAM - Fast, up to 133 MHz clock, multiple cycle delay for first

DD DRAM - Like Sync, but transfers data on each clock edge.

RAMBUS - Sync DRAM with a special very high speed interface up to 400
MHz(?), used in high end PCs.

There are others, but they are for special applications and cost more or
a lot more money.

--

Rick Collins

rick.collins@XYarius.com

removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 24435
Subject: Re: Memory specification
From: Mark W Brehob <brehob@cse.msu.edu>
Date: 8 Aug 2000 15:03:06 GMT
Links: << >>  << T >>  << A >>
Some books that might be of interest.

Look at things written by Betty Prince.  She has two books out I think, both
of which may be in the second edition.  They are fairly detailed.

Micron's free book about what they sell is an interesting read if you take
your time.  I learned a lot from it.

Both of these can be fairly detailed and neither are really what you are
really looking for, but the info you want is likely inside of both.  Careful
web searching might help too.  If your company is willing to hire someone to
get you all up to speed, you might try Ms. Prince.  She comes across as
quite knowledgeable and is available for such things.  (I've only met her
once.)

Best of luck,
Mark

In comp.arch rickman <spamgoeshere4@yahoo.com> wrote:
> Rodolfo Jardim de Azevedo wrote:
>>
>> rickman wrote:
>> >
>> > SRAM modules are not terribly common although they do exist. Much more
>> > common are DRAM modules although standard DRAM and EDO DRAM are being
>> > phased out. SDRAM and DDSDRAM (or whatever the acronym is for double
>> > data rate SDRAM) are the newer standards with more years left in them.
>> >
>> > SRAMs are easy to get as chips (other than for allocation problems >:).
>> > But you mention that you want density. EEPROMs are much more dense than
>> > SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16
>> > times more dense than SRAM. I can get 64 Mbit Flash chips but I don't
>> > think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the
>> > stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC.
>> >
>> > Of course Flash is much slower than SRAM, but you didn't say what speeds
>> > you need. If you don't need speed, SDRAM can be faster than Flash, but
>> > you need a more complex controller. Of course that all depends on what
>> > you are connecting it to.
>> >
>> > Sound complicated? It is! Until you learn about the different memory
>> > flavors.
>>
>>         Do you sugest me any book?
>>
>>         Thanks again,
>>
>>                 Rodolfo

> No one book, but go to the web sites for several of the memory
> manufacturers and read the datasheets, the app notes and the selection
> guides for all of their parts. Some good sites to visit are Micron,
> Samsung and Intel. Micron data sheets are very clear and they have good
> app notes. Samsung has a nice variety of parts. Intel has a poor web
> site that is hard to navigate, but they sell a lot of Flash and have
> some rather unique parts.

> I don't think you will find much of this stuff in a text book of any
> kind.

> Summary:

> Async SRAM - Fast to slow, no clock, no overhead for first access.

> Sync SRAM - Fast, clock up to 200 MHz(?), one or two clock overhead for
> first access.

> EEPROM - Moderately slow, no clock, no overhead for first read, erase
> and write bytes.

> Async Flash - Moderately slow, no clock, no overhead for first read,
> must erase in blocks.

> Sync Flash - I have not used this (or even looked at it yet) but Micron
> (or is it Samsung?) claims it is compatible with SDRAM.

> Sync DRAM - Fast, up to 133 MHz clock, multiple cycle delay for first

> DD DRAM - Like Sync, but transfers data on each clock edge.

> RAMBUS - Sync DRAM with a special very high speed interface up to 400
> MHz(?), used in high end PCs.

> There are others, but they are for special applications and cost more or
> a lot more money.

> --

> Rick Collins

> rick.collins@XYarius.com

> removed.

> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design

> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX

> Internet URL http://www.arius.com

--
~~~~~~~~~~~~~~~~ http://www.cps.msu.edu/~brehob ~~~~~~~~~~~~~~~~~~
| | The reports of SIMD's death have been greatly exaggerated  | |
| -=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
~~~~~~Mark Brehob: Ultimate Player, Gamer, Computer Geek~~~~~~~~~~

Article: 24436
Subject: Re: Circuit Drawing
From: Hazelton@exo.com (Full Name)
Date: Tue, 08 Aug 2000 15:18:21 GMT
Links: << >>  << T >>  << A >>
In article <8mk8ue$en6$1@foo.grnet.gr>, "Goulas George" <george_goulas@hotmail.com> wrote:

1. Start news .
2. goto     alt.binaries.warez.ibm-pc.0-day
3. extract   rbs-ct01.zip through rbs-ct-04.zip   .
4. The  ".diz" file reads :

CircuitMaker 6.2 & TraxMaker 3.03 Pro
______________________________[xx/04]
\_ _  \_ ____/_ _  \_ ____/ |_\  ___/
/    _/  ___)/    _/  ___)  | \___  \
/   |  \_ |  \   |  \  |  \  :  \  :  \
\___|   /___  \____  \___  \___  \___  \
====|__/===\__/===\__/==\__/==\__/==\__/
REBELS: WE MAKE ALL DAYS PARTY DAYS
>> RELEASING WITHOUT PERMISSION <<

Hope it helps.

>It's a bit irrelevant to this newsgroup...
>
>I need a drawing program that produces good looking digital circuit designs.
>I've tried Visio, but I could n't find muxes or ffs.
>I don't need all the graphic detail of the good digital
>simulation programs, I just need to present some
>circuits....
>
>
>
>

Article: 24437
Subject: FPGA intro
From: Dan Yang <dyang@drs.ca>
Date: Tue, 08 Aug 2000 16:04:27 GMT
Links: << >>  << T >>  << A >>
I am a FPGA newbie. Can anyone tell me some good FPGA introduction
papers? Thanks.

Dan


Article: 24438
Subject: HELP! Strange Xilinx Software Error
From: Nicholas Pappas <npappas@vt.edu>
Date: Tue, 08 Aug 2000 12:49:24 -0400
Links: << >>  << T >>  << A >>
We are getting a very strange error when using the Xilinx, Foundation
Series, Design Manager software, to create a bit file implementation for
our 4010XLPC84 Xilinx chip, durring the mapping stage.

ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not valid
following site types: CLKIOB

What we are doing here, is we have a std_logic_vector named DS that we
are trying to map to some pins in a UCF file.  For some reason, it
generates this error, and I have been unable to find any documentation
on this error.  If anyone out there has encountered this error, how did
you solve it?  Thanks.

Nick Pappas


Article: 24439
Subject: Re: HELP! Strange Xilinx Software Error
From: com@mail.cmautner (Christian Mautner)
Date: Tue, 8 Aug 2000 20:04:11 +0200
Links: << >>  << T >>  << A >>
On Tue, 08 Aug 2000 12:49:24 -0400, Nicholas Pappas <npappas@vt.edu> wrote:
>We are getting a very strange error when using the Xilinx, Foundation
>Series, Design Manager software, to create a bit file implementation for
>our 4010XLPC84 Xilinx chip, durring the mapping stage.
>
>ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not valid
>following site types: CLKIOB
>
>What we are doing here, is we have a std_logic_vector named DS that we
>are trying to map to some pins in a UCF file.  For some reason, it
>generates this error, and I have been unable to find any documentation
>on this error.  If anyone out there has encountered this error, how did
>you solve it?  Thanks.
>

Are you using DS<0> as a clock input to any flip flop in your design?
Maybe inadvertedly?. It looks to me as your synthesis tool connects DS<0>
directly to a BUFG, but P69 is no BUFG'able input

just a theory,
chm.

--
cmautner@  -  Christian Mautner
mail.com   -  Vienna/Austria/Europe

Article: 24440
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other curiosities
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 08 Aug 2000 11:27:24 -0700
Links: << >>  << T >>  << A >>

I could spend an hour or two and give a more detailed answer,
but I am fairly sure you have a bug to report. The problem is
at least that PAR should be telling you that it can't create the
thing you want for some of these cases.

To help guide you to an answer, it may help to know that the
FF is really two latches, the first is transparent when clock is
low, the second is transparent when clock is high (assuming
no CLB level clock inversion). To implement a latch, I suspect
that an additional config bit permanently holds the second
latch transparent. This avoids the alternative, which is a
bypass around either of the latches, which would screw up
timing, such as Tcko.

Since the first latch is the remaining one that is used, it is a
transparent low latch (again assuming no CLB level clock
inversion). You will also see this in the Xilinx libraries guide
for the XC4000X/XL, LDCE_1 is the primitive, the rest are
macros. The libraries guide lies that all the different versions
of latches are primitives in the Virtex chips. (although that
may be a netlist issue. If for 4KX/XL, the only valid prim
is LDCE_1, and others are transformed at netlisting time,
and for virtex, all forms are allowed in the netlist, and PAR
sorts it out, I guess the guide could be argued to be ok)

My guess is that the bug you are facing, is the PAR code
that handles latches for Virtex, is quietly changing the clock
sense, oblivious to the fact that other things in the CLB
use the clock too.

Good luck trying to get Xilinx to understand, acknowledge,
and fix it.

Philip Freidin

On Sun, 06 Aug 2000 06:10:27 GMT, "Jan Gray" <jsgray@acm.org> wrote:
>
>Then I thought, hey, in my application a latch might do.
>Not pretty, but the latch output is then reregistered in half
>a clock anyhow.
>
>But when I implemented a simple latch and looked
>at its configuration in the FPGA Editor, I was surprised to
>see that PAR had set the slice clock inverter.  I checked the
>edif that came out of Foundation Express for my latch, and
>it looked right, a simple instance of LD with no CLK inversion.
>Should pass data on CLK high and hold it on CLK low.
>
>Then I tried some more experiments, and I found that
>
>1. when I constrain a rising edge triggered single-port RAM
>   and a G=clk latch into the same slice, it passes PAR, but curiously,
>   FPGA Editor again shows the slice clk mux selects inverted CLK
>   for both!
>
>2. when I constrain the same RAM and latch to be in different slices,
>   the RAM slice shows up as rising edge triggered, but the latch
>   slice again shows up with CLK inverted!
>
>3. when I constrain a rising edge triggered single-port RAM and
>   a G=~clk latch in the same slice, it fails PAR with the error
>
> ERROR:xvkpu - Unable to obey design constraints (LOC = CLB_R3C1.S1) which
>   require the combination of the following symbols into a single slice:
>    RAM symbol "r2" (Output Signal = o2)
>    LATCH symbol "q2_reg" (Output Signal = q2)
>   The clock signals don't agree.
>
>I expected 3.  But I really don't understand why inverted CLK
>is selected for the RAM and the latch in cases 1 and 2, and at
>any rate why cases 1 and 2 don't receive identical CLK polarities.
>This feels like a bug, either in PAR, or in FPGA Editor.
>
>Any ideas?
>Thanks.
>Jan Gray
>Gray Research LLC

Philip Freidin

Mindspring that acquired Earthlink that acquired Netcom has
decided to kill off all Shell accounts, including mine.

My new primary email address is    philip@fliptronics.com

I'm sure the inconvenience to you will be less than it is for me.

Article: 24441
Subject: Re: Can i see Gate-delay and Interconnection-delay of circuit on FPGA and where??
From: yuryws@my-deja.com
Date: Tue, 08 Aug 2000 19:04:24 GMT
Links: << >>  << T >>  << A >>
In article <8mlhal$ps3$1@atom.nectec.or.th>,
"Phunjapa Ruangsinsup" <mpr@siampage.com> wrote:
> I must design asynchronous circuit on FPGA and I must know Gate-delay
and
> interconnection delay for create Complete signal check (the signal
which
> have delay longest than another in circuit). I design by RTL-VHDL
code and
> synthesis by Xilinx Foundation 2.1i, my synthesis output is VHDL and
SDF
> code. So can i use delay report from SDF code to be a Gate-delay??
and Where
> i can see interconection-delay of each signal??
>
>

What you are looking for is the output of PAR tools, not synthesis
tools, since the synthesis tools can only estimate the delays.

Use the timing analyzer GUI or trce to obtain the timing report.
Gate to gate ptopagation is not going to be easy to find out, since
synthesis tools and then PAR tools will try to optimize your logic.
You can only rely on registers still being there (with some exceptions).
If the synthesis tool did not optimize away the nets of interest then
you can ask PAR tools to KEEP them, so that when you run the timing
analyzer you can examine the paths pertinent to those nets.

FPGAs are much more suitable for synchronous design. What you are
trying to do is not easy and very much part-batch dependent.

Good luck

-- Yury Wolf

Sent via Deja.com http://www.deja.com/

Article: 24442
Subject: Re: HELP! Strange Xilinx Software Error
From: yuryws@my-deja.com
Date: Tue, 08 Aug 2000 19:51:13 GMT
Links: << >>  << T >>  << A >>
In article <39903A14.526BD890@vt.edu>,
Nicholas Pappas <npappas@vt.edu> wrote:
> We are getting a very strange error when using the Xilinx, Foundation
> Series, Design Manager software, to create a bit file implementation
for
> our 4010XLPC84 Xilinx chip, durring the mapping stage.
>
> ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not
valid
the
> following site types: CLKIOB
>
> What we are doing here, is we have a std_logic_vector named DS that we
> are trying to map to some pins in a UCF file.  For some reason, it
> generates this error, and I have been unable to find any documentation
> on this error.  If anyone out there has encountered this error, how
did
> you solve it?  Thanks.
>
> Nick Pappas
>

Did by any chance that pin get prohibited in UCF file from being used?
Check .pcf file as well.
P69 is special in that it is used for configuration in Master parrallel
and peripheral modes.

Make sure that the pin name listed in ucf/pcf file has the same name as
the I/O bus pin in HDL code.

If you are using UCF it should be called DS<0>. In VHDL code it would
be DS(0).

Yury Wolf

>

Sent via Deja.com http://www.deja.com/

Article: 24443
Subject: Re: Fast (> 100Mb) serial link to PC
From: "Fred SKalka" <fskalka@juno.com>
Date: Tue, 8 Aug 2000 12:56:40 -0700
Links: << >>  << T >>  << A >>
You could send it out byte-wise to a hot link interface.  it will operate at up to 400Mbit/sec.  Cards for PCI bus interface exist.

Article: 24444
Subject: Re: Memory specification
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 08 Aug 2000 19:12:54 -0400
Links: << >>  << T >>  << A >>
Goto the www.micron.com site. They provide Verilog and VHDL models for
all of their RAMs. YOu probably want to use either Sync DRAM or ZBT sync
SRAMs.

Rodolfo Jardim de Azevedo wrote:
>
> Hi,
>
>         I'm trying to make an experimental board which will use 2 modules of
> memory. I will write some VHDL code and use a FPGA to implement it. But
> I could not find some information yet. I need SRAM modules (I think some
> PCs use them as cache memory, that would be the best choice). Where can
> I get some specification of such modules? How to make an interface?
> (pinouts, time diagrams, ...)
>         In fact, I could even use EEPROMs, because I don't need to change the
> system memory too much. But I would prefer SRAM modules due to space
> constraints in my board.
>
>
>                         Rodolfo

Article: 24445
Subject: Re: Who needs all those printed ac parameters?
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 09 Aug 2000 00:10:11 +0000
Links: << >>  << T >>  << A >>
Hal Murray wrote:
>
> > This was triggered by the recent debate over the delay differences
> > between the 4 different LUT inputs. I feel strongly that the
> > designers should not be bothered with such details. The software
> > should analyze and synthesize this for you.

Yes but I like to know what my software is doing. There is times
you add logic to help with timing delays and logic hazards. Not that
often but you do. Here we have 2x clock generating a enable for a
latch. If the software does somthing stupid with my NOR gate I could
end up with wrong data.

><~~><~~
--__--__ clock
__--____ enable

---+[T Q]--o[&]    -[D Q]
+-------o[ ]-----[E  ]

> Software has a long history of not being smart enough to do the
> right thing.
>
> So independent of whether the numbers are in the data sheet or
> we have to get them from a tool, I think it's important for the
> designer to understand the low level issues AND for there to
> be some path to make the software do what the designer wants
> when he is smarter than the software.

playing around with the TTL macros to get a feel for the
software. Using some 74181's I can get a carry out in about
50 ns or 100 ns whether the logic is  optimized for
speed or size. Reading the data sheet for the for using fast
This gives me now a good idea depending on the rest of my
circuit timing to stick with the 181 ALU or design my own.
Since this my first design I will stick with the TTL macros
but know that the ALU could use improvment down the road.

Ben.
PS, The printed page or data book is handy at 3am
when happen to think of a better way to do something
and the office with your computer is Locked up for the
night.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
http://www.jetnet.ab.ca/users/bfranchuk/index.html

Article: 24446
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 09 Aug 2000 00:19:50 +0000
Links: << >>  << T >>  << A >>
robby75@my-deja.com wrote:
>
> Hi FPGA freaks,
>
> microprocessor with an on-chip reconfigurable logic. A year ago,
> Triscend have anounced the first Micro-controller with reconfigurable
> logic (configurable system on a chip CSoC). Apart from Xess who have
> developed a board based on CSoC, I did not hear much about it.
> The idea seems great and dates from some time now. Are there any
> practical limitations?
>

Are not the computers on Star Trek all reconfigurable logic !?
and you know the problems they have had. With a bad bug or virus
in regular logic your program or HD dies. With a bad bug or virus
for reconfigurable logic everything could die, or be hard to kill.
Hmm a HAL 9000 toaster -- Dave is that you! my vision circuits are
not working here.

Ben.
--
"We do not inherit our time on this planet from our parents...
We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
http://www.jetnet.ab.ca/users/bfranchuk/index.html

Article: 24447
Subject: Re: Xilinx Alliance Base
From: "Andy Krumel" <andy@krumel.com>
Date: Tue, 8 Aug 2000 17:45:03 -0700
Links: << >>  << T >>  << A >>
FYI, I received my copy via UPS about a month or two ago.

Andy

Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in message
news:8mmp4c$1rql$1@noao.edu...
> peter dudley wrote in message <8mk3gg$9gg$1@abq-news-01.ihighway.net>...
> >Last December I bought the Xilinx Alliance Base software for some home
> >projects that I had to do. Since then 3.1i has come out.
> >
> >Does anyone know if I should receive a free update on this software?
>
> If you've paid the maintenance ransom, you should receive the 3.1i
software.
>
> At least, that's what I'm told.  I'm still waiting for the software.
>
>
> -- a
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "A sufficiently advanced technology is indistinguishable from magic"
>      --Arthur C. Clarke
>
>
>


Article: 24448
Subject: Re: Help!! Virtex system gate count.
Date: Wed, 09 Aug 2000 03:07:55 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
<The gate counting that they do is a little complicated since they have
< to make some assumptions for how much of the block ram to count as well
> as what modes you will use the other features in. So I don't think you
> will be able to figure it out without contacting them directly.

Here is what I explained more than a year ago. The numbers refer to an
XC4000-XL part, but the concept is similar for Virtex. Gate count is a
borderline meningless number when applied to LUT-based FPGAs, with large
amounts of RAM on-chip, plus dedicated ( hidden and un-counted ) carry logic,

sophisticated clock manipulation, and multi-standard I/Os.
But as amanufacturer we have to come up with a number, and market the devices

in a competitive environment.
Anyhow, here is the old explanation from early 1999:

Let me explain the 10,982 Logic Cells, 147 k bits of RAM and 265000
max logic gates claimed for the XC40125XV.

This is a mixture of engineering specifications and marketing.

Engineering specifications:

The XC40125XV has a 68 x 68 array of CLBs = 4624 CLBs
Each of these CLBs has 32 RAM bits = 147 968 RAM bits total.
No ifs and no buts.

Now we get into marketing:

Since this is a competitive world, our users want to compare different
manufacturers, but the structures are not the same.  Altera puts eight
LUTs in a block, Lucent puts four, and we put two LUTs into a CLB, but
everybody's LUTs are more or less identical.

So Xilinx decided to standardize the nomenclature and emphasize not
CLBs but rather Logic Cells, as a lingua franca for FPGAs.  Good idea!

Then marketing saw the third LUT in our CLB and gave it a value of 3/8
of a Logic Cell, so the whole CLB is worth 2.375 LCs.  Obviously, we can
for some really nice and efficient solutions. :-)

Multiply the 4624 CLBs by 2.375 and you get 10 982 Logic Cells.

What is that in ASIC gates?

There is no scientific answer, because it depends on the design.  What
is the LUT being used for, is the flip-flop being used at all, and what if
you use the LUT as RAM ?

Assume that every LUT is worth 6 gates and every flip-flop is worth 6
gates, then every Logic Cell is worth 12 gates (sometimes more,
sometimes less).  12 gates times 10 982 LCs makes a bare-bone
gate-count of 131 784, and that is reflected in the name of the device.
We are conservative and round it down a little. :-)

But there is the RAM in the LUT, and if only 25% of them are really
used as RAM, these LUTs are not worth 6 gates, but rather 64 gates (16
bits with 4 bits per RAM cell, again, very conservative, ignoring the
another 58 gates times 25% of 9248 LUTs, which means another 134 096
gates, for a total of 265 880 logic gates. And we say explicitly that this
assumes 20 to 30 % of the CLBs being used as RAM.

That's how the XC40125XV got its name and its gate-count range of
125,000 to 265,000 gates.  It is an attempt to bring some sanity to the
gate-count confusion.

Users will never agree about these assumption, and if you don't want to
compare different manufacturers, then you can forget the whole thing
and just stick with CLBs and RAM bits, for they are physical and thus
non-controversial.

Peter Alfke
February 27, 1999


Article: 24449
Subject: opencores doing first silicon
From: dlampret@my-deja.com
Date: Wed, 09 Aug 2000 04:06:26 GMT
Links: << >>  << T >>  << A >>
Hello everybody,

I am happy to announce OpenCores will be doing its first silicon (TSMC
0.25u, 5LM) using its current open source cores. Current idea is to put
together three 32-bit RISC cores (OR1320 + 2x OR1601), SDRAM & master
PCI controller, 2x Ethernet MAC, 2x serial UART, RTC & WDT. Something
similar like Intel's IXP1200 network processors. First operating system
for the chip will probably be Linux (also eCos and RTEMS will be
ported).

Since all cores are more or less still under development we would like
to invite more people to help us. Help is especially needed on Ethernet
MAC and PCI master cores. Also all other teams welcome any additional
help. Prefered HDL to be used for _current_ chip is Verilog (unless you
can supply netlists for Artisan 0.25u TSMC).

project please visit us at http://www.opencores.org/. Currently details
about silicon project are not yet published.

regards, Damjan
--
mailto:lampret@opencores.org
http://www.OpenCores.org

Sent via Deja.com http://www.deja.com/
`