Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 34425

Article: 34425
Subject: Re: Slowing PCI for FPGA
From: Phil Hays <spampostmaster@home.com>
Date: Fri, 24 Aug 2001 05:56:09 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

> You know, all this fancy (and expensive) "stuff" that you have to do to get
> synthesized code to work "fast" is absolutely no effort to do with the
> design correctly done using schematics as the entry methodology.  Sigh.

Absolutely no effort?  Ho Ho.

I've done schematics with floorplanning.  I know better than absolutely no
effort.  Sure, if there are significant regularities in the design you can save
some effort, yet you still need to plop down a lot of little shapes and connect
little wires to each of them and label or connect each little wire.  No effort? 
Ho Ho.  And doing this for say 4,000 FFs, 5,000 LUTs, 1,200 luts used as memory
and 72 block RAMs?  That's a lot of little wires to attach.  Then there is the
floorplanning.  It takes effort to attach each little RLOC or LOC to each little
gate.  Doing this for a 5000 LUTs might be easier if they are in some sort of
regular array.  What if they mostly not regular?

And not just design entry.  It takes effort to plan out a design, from the top
level specification to the implementation.  It takes effort to work out the
details.  It takes effort to verify the design by simulation.  It takes effort
to work through the timing issues.  It takes effort to properly pass information
between different clock domains.  It takes effort to take the design into a
reliable product.  It takes effort to document the whole process so that others
might be able to extend it in the future.

I agree that some designs can be done with less effort with schematics.  And if
there was a good package that allowed mixed schematics and HDL, that might be a
good choice for some designs.  Yet the majority of designs are done in HDL for
good reasons:  less effort, better results.


-- 
Phil Hays

Article: 34426
Subject: Spartan-II & clock
From: "Jan Pech" <j.pech@sh.cvut.cz>
Date: Fri, 24 Aug 2001 09:31:46 +0200
Links: << >>  << T >>  << A >>
Hi all,
I have some problem with my design in Xilinx WebPACK. I need to count events
on an I/O pin. When I specify the pin number for counter clock signal in UCF
file, the map process generates error 93 .......IPAD-IBUFG should only be
LOCed to GCLKIOB site.
I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and
internal clock signal but they may be used with GCLK pins only.
Is there any way to drive clock signal for counter by an general I/O pin?

Thanks for your help!

Regards,
Jan

___________________________
     j.pech@sh.cvut.cz
     +420 (723) 760802
     ICQ: 56431283




Article: 34427
Subject: Re: Actel Pad locations
From: Thomas Stanka <Thomas.Stanka@de.bosch.com>
Date: Fri, 24 Aug 2001 09:43:44 +0200
Links: << >>  << T >>  << A >>
Hi,

Patrick Dano wrote:

> Does anyone know how to associate pin location with pad location in Actel
> FPGA's (ie, what pins are associated to what pads), specifically the
> A500K130-456?  The documents I have are missing some figures, and I cant
> find anything on their web page.

Try using the pineditor in the designer.

bye Thomas

-- 
Thomas Stanka	    
Bosch SatCom GmbH                         BC/EMD4
D-71522 Backnang      	   Tel. +49 7191 930-1690
Gerberstr. 49             Fax. +49 7191 930-21690      
Zi. 10/528             Thomas.Stanka@de.bosch.com

Article: 34428
Subject: Re: SmartMedia
From: mar@tcelectronic.com (Martin Roenne)
Date: 24 Aug 2001 00:46:53 -0700
Links: << >>  << T >>  << A >>
From VHDL you can only read files that you can specify as a path in
your filesystem. So - to read a file from a Smartmedia card, requires
a Smartmedia cardreader with a driver that supports your operating
systems file system. If you can read the Smartmedia files from your
file browser, you should also be able to read it from a VHDL file by
specifying the same path as shown in your browser. Hope this helps.

regards Martin

"Andrew Gray" <andrew@tuks.co.za> wrote in message news:<998576679.227273@nntp.up.ac.za>...
> Hi
> 
> Does anyone know how to read a file from a SmartMedia card in VHDL?
> 
> Andrew

Article: 34429
Subject: Re: Spartan-II & clock
From: Stephan Neuhold <stephan.neuhold@xilinx.com>
Date: Fri, 24 Aug 2001 10:56:57 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------2A7DBD766E28375B77F738DC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jan,

Try this:

IPAD--BUFG

The IBUFG symbol suggests a dedicated clock pad.

Jan Pech wrote:

> Hi all,
> I have some problem with my design in Xilinx WebPACK. I need to count events
> on an I/O pin. When I specify the pin number for counter clock signal in UCF
> file, the map process generates error 93 .......IPAD-IBUFG should only be
> LOCed to GCLKIOB site.
> I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and
> internal clock signal but they may be used with GCLK pins only.
> Is there any way to drive clock signal for counter by an general I/O pin?
>
> Thanks for your help!
>
> Regards,
> Jan
>
> ___________________________
>      j.pech@sh.cvut.cz
>      +420 (723) 760802
>      ICQ: 56431283

--------------2A7DBD766E28375B77F738DC
Content-Type: text/x-vcard; charset=us-ascii;
 name="stephan.neuhold.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Stephan Neuhold
Content-Disposition: attachment;
 filename="stephan.neuhold.vcf"

begin:vcard 
n:Neuhold;Stephan
tel;fax:+44 (0)870 7350 620
tel;work:+44 (0)870 7350 576
x-mozilla-html:FALSE
url:http://www.xilinx.com
org:Xilinx;Xilinx Technical Support
version:2.1
email;internet:stephan.neuhold@xilinx.com
title:Customer Applications Engineer
adr;quoted-printable:;;203 Brooklands Road=0D=0A;Weybridge;;KT13 0RH;United Kingdom
fn:Stephan Neuhold
end:vcard

--------------2A7DBD766E28375B77F738DC--


Article: 34430
Subject: Re: Spartan-II & clock
From: Falk <>
Date: Fri, 24 Aug 2001 04:04:41 -0700
Links: << >>  << T >>  << A >>
Usually, you should connect clocks to the dedicated clock inputs (there are 4).
If you really want to connect a clock to a non-clock pad (which is only recommended if you have sufficient expirience) then you have to add some synthesis constraints that tells the compiler NOT to generate a IBUFG for your clock signal. I dont know how do do it in Webpack, because I use Foundation.

Regards
Falk

Article: 34431
Subject: Re: Spartan-II & clock
From: "Jan Pech" <j.pech@sh.cvut.cz>
Date: Fri, 24 Aug 2001 13:58:00 +0200
Links: << >>  << T >>  << A >>

<Falk> wrote in message news:ee7216f.1@WebX.sUN8CHnE...
> Usually, you should connect clocks to the dedicated clock inputs (there
are 4).
> If you really want to connect a clock to a non-clock pad (which is only
recommended if you have sufficient expirience) then you have to add some
synthesis constraints that tells the compiler NOT to generate a IBUFG for
your clock signal. I dont know how do do it in Webpack, because I use
Foundation.
>
> Regards
> Falk

I instantiated the BUFG primitive into the top-level design file between the
input pad (and of course the IBUF) and the internal clock signal.

Jan



Article: 34432
Subject: Re: Carry chain warnings from Xilinx MAP
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 24 Aug 2001 13:32:24 +0100
Links: << >>  << T >>  << A >>

I wrote:


>   ------------------------------------------------------------------------
> I'm getting some warnings from MAP that I think are being caused by a
> bum synthesis [Synplify] but I'm not sure, it might be a MAP
> problem.
>

Yada, Yada, Yada ...

I looks like I was wrong & its MAP shooting itself in the foot. Now off for
several weeks to persuade Xilinx of this fact. Apologies to any Synplicity
engineers herein present.





Article: 34433
Subject: Re: SmartMedia
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Fri, 24 Aug 2001 15:13:20 +0200
Links: << >>  << T >>  << A >>


Martin Roenne wrote:

> From VHDL you can only read files that you can specify as a path in
> your filesystem. So - to read a file from a Smartmedia card, requires
> a Smartmedia cardreader with a driver that supports your operating
> systems file system. If you can read the Smartmedia files from your
> file browser, you should also be able to read it from a VHDL file by
> specifying the same path as shown in your browser. Hope this helps.
>
> regards Martin
>
> "Andrew Gray" <andrew@tuks.co.za> wrote in message news:<998576679.227273@nntp.up.ac.za>...
> > Hi
> >
> > Does anyone know how to read a file from a SmartMedia card in VHDL?
> >
> > Andrew

I suspect that the original poster wanted to know how to read data from a smart media card that
is connected to an FPGA with some wires.

The information on how to perform low level accesses to SmartMedia chips can be found in the
data sheets of NAND-Flash manufactures. For example at www.amd.com. SmartMedia is not mentioned
in the data sheet, but the protocol is the same. (An it is very simple, too)

But to exchange data with other devices (PC, camera, ...) via smart media cards you need to
implement the file system that is used by these devices. I know nothing about this, but I
suspect that you can find it in the Linux kernel sources. It is probably a good idea to use a
processor for the file system implementation. See www.fpgacpu.org.

Kolja Sulimma


Article: 34434
Subject: Re: SmartMedia
From: "Bram van de Kerkhof" <bvdk@oce.nl>
Date: Fri, 24 Aug 2001 15:15:49 +0200
Links: << >>  << T >>  << A >>
Cant you read the file byte by byte ??

Yours B

"Martin Roenne" <mar@tcelectronic.com> wrote in message
news:c62dc1e0.0108232346.7aa0ff9@posting.google.com...
> From VHDL you can only read files that you can specify as a path in
> your filesystem. So - to read a file from a Smartmedia card, requires
> a Smartmedia cardreader with a driver that supports your operating
> systems file system. If you can read the Smartmedia files from your
> file browser, you should also be able to read it from a VHDL file by
> specifying the same path as shown in your browser. Hope this helps.
>
> regards Martin
>
> "Andrew Gray" <andrew@tuks.co.za> wrote in message
news:<998576679.227273@nntp.up.ac.za>...
> > Hi
> >
> > Does anyone know how to read a file from a SmartMedia card in VHDL?
> >
> > Andrew



Article: 34435
(removed)


Article: 34436
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@dark55room.com>
Date: Fri, 24 Aug 2001 10:17:52 -0400
Links: << >>  << T >>  << A >>
> > You know, all this fancy (and expensive) "stuff" that you have to do to
get
> > synthesized code to work "fast" is absolutely no effort to do with the
> > design correctly done using schematics as the entry methodology.  Sigh.
>
> Absolutely no effort?  Ho Ho.

I see you have a second job around XMass time and are getting some practice
in.  It's three "Ho"'s by the way.

> I've done schematics with floorplanning.  I know better than absolutely no
> effort.

Yes, but I said "correctly done" ;-)  One can do a bad job at anything.  Do
you have a library of preplaced and mapped symbols that give you most any
permutation of data path elements you would need (counters, timers,
registers, I/O, muxes etc.)?  If not, then you really aren't setup
correctly, now are you?

> Then there is the
> floorplanning.  It takes effort to attach each little RLOC or LOC to each
little
> gate.

No effort at all, that is already done for the elements in your
library...oops, I forgot...you don't have a library?

> And not just design entry.  It takes effort to plan out a design, from the
top
> level specification to the implementation.  It takes effort to work out
the
> details.  It takes effort to verify the design by simulation.  It takes
effort
> to work through the timing issues.  It takes effort to properly pass
information
> between different clock domains.  It takes effort to take the design into
a
> reliable product.  It takes effort to document the whole process so that
others
> might be able to extend it in the future.

And this has nothing at all to do with your design methodology at all.

> I agree that some designs can be done with less effort with schematics.
And if
> there was a good package that allowed mixed schematics and HDL, that might
be a
> good choice for some designs.

Ah, there is, and has been for a long time.  It's called ViewDraw.

> Yet the majority of designs are done in HDL for
> good reasons:  less effort, better results.

You have no proof of this.  That is absolutely pure myth.  Have you actually
done the same design in schematic and HDL and compared the effort and
results?  I have no doubt that there are SOME designs that MAY be
implemented quicker in HDL, but I believe that is many many less than people
believe.

There are MAJOR political/business/ego reasons that there is a LOT of
press/push for use of HDLs...and none for schematics.  There is a lot of
money to be had if you can convince people that HDLs are "the way to
go"...whether it's true or not isn't important.




Article: 34437
Subject: Re: Principles of Verifiable RTL Design (2nd ed)
From: "Mike" <mike@nospam.com>
Date: Fri, 24 Aug 2001 14:27:12 GMT
Links: << >>  << T >>  << A >>

"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message
news:3B83BFE7.944667A6@jetnet.ab.ca...
> James Lee wrote:
> >
> > I reviewed the book.  It was quite interesting, I did not fully
> > understand it untill I spoke with the authors.  The focus is on
> > picking a set of tools and libraries that work consistently with a
> > style of verilog.
> >
> That sounds bad for the state of hardware development. Bugs in my
> code/schematics I can correct, yet with the fact that the final output of
logic
> synthesizers is totally hidden from the public how do I know if there are
no
> bugs in the system.
> Ben.

It's not hidden, Ben, it's just in a different form. The way you know it's
the same is twofold: first, you have a testbench you can run on the
synthesized result, which should produce the same results as your original
code. Second, you have formal verification tools, that can compare the
synthesizer output (gate level verilog, in the case I'm familiar with) with
your original VHDL or verilog code.

-- Mike --




Article: 34438
Subject: Set associative mapping in VHDL
From: "Artur" <kacorsz@wp.pl>
Date: Fri, 24 Aug 2001 17:11:07 +0200
Links: << >>  << T >>  << A >>
Hi,

I'm looking for VHDL example of a set-associative mapping. Is anyone who can
help me?

Thanks in advance,

Artur.
kacorsz@wp.pl

P.S. I'm also looking for some papers about software/hardware
partitioning, especially using simulated annealing algorithm. If someone can
send me them, I'll be grateful.





Article: 34439
Subject: Re: Reading Text in Verilog
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Fri, 24 Aug 2001 09:25:20 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F37237A7D0AA334821D5B917
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hello Kevin,

   If you are using one of the newer versions of ModelSim, 5.5 or better, then
there are some new Verilog-2001 constructs that do make reading and writing to
files much easier than in the past.  I have just started to play with it myself
so I am no expert but try looking into the $fscanf function.  It has much more
flexibility than the more traditional $readmem functions.  Here are some
relevant lines from my latest testbench to help you get started:

data_file = $fopen("../input_data.dat", "r"); // Open file for reading
$fseek (data_file, 102, 0); // Skip over some documentation at top of file
$fscanf(data_file, "%b", a_data); // Grab some data and store to reg called
a_data (binary in this case)
$fclose(data_file); // Close file


This is working quite well for me so far but again, just getting started with
this.  If you are using another simulator, ask if there is Verilog-2001 support
or else the above constructs are invalid.

Good luck,

--  Brian




Kevin Neilson wrote:

> For testbenches, is there a method to read in a text file in Verilog?  The
> $fdisplay function is great for writing to files, but the functions for
> reading in files are limited; the only method I know of to read in a file is
> to dump it into a register using the $readmemh command.  However, that only
> works with files formatted in ascii-hex, e.g. "41 42 43", not files
> formatted in text, e.g. "ABC".  I wrote a Perl script to convert text files
> to ascii-hex but that seems a lame workaround.
>
> -Kevin

--------------F37237A7D0AA334821D5B917
Content-Type: text/x-vcard; charset=us-ascii;
 name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
 filename="brian.philofsky.vcf"

begin:vcard 
n:Philofksy;Brian
x-mozilla-html:TRUE
org:Xilinx, Inc.;System Level & Alliance Marketing
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
title:Technical Marketing Engineer
fn:Brian Philofksy
end:vcard

--------------F37237A7D0AA334821D5B917--


Article: 34440
Subject: Re: hardware damage to a Virtex or Spartan-II?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 24 Aug 2001 08:43:13 -0700
Links: << >>  << T >>  << A >>
Dave,

Thanks!

Austin

Dave Vanden Bout wrote:

> Austin Lesea wrote:
>
> > John,
> >
> > Make, model number, and where to buy the IR temp sensor?
> >
> > I get sooo many questions, and it would be worth its weight in gold to publicize this
> > info!
>
> You can buy an Extech infrared thermometer from Techni-tool for $99.00.  Measures 0 - 600
> degrees F with a 6:1 field view.
>
> >
> >
> > Austin
> >
> > John Larkin wrote:
> >
> > > On Mon, 20 Aug 2001 19:10:26 +0100, Rick Filipkiewicz
> > > <rick@algor.co.uk> wrote:
> > >
> > > >Peter,
> > > >
> > > >On top of all the other useful stuff you contribute to CAF you have just answered a
> > > >long-standing (or burning ?) question of mine regarding the calibration of heat
> > > >sensing fingertips.
> > >
> > > Peter,
> > >
> > > my right forefinger is calibrated as follows:
> > >
> > > 50C - ok for infinite duration contact
> > >
> > > 52C - 10 seconds to pullaway
> > >
> > > 60C - 1 second to pullaway
> > >
> > > Interpolate linearly between points. Your digits may vary.
> > >
> > > We just got a cheap ($79) infrared temp sensor, which is cool (no pun,
> > > really) for scanning FPGAs on a board.
> > >
> > > John
> > >
> > > >
> > > >To go further and get another data point: Last summer I was wondering why our new
> > > >board wasn't doing anything from power-on. I, very briefly, put my finger on it &
> > > >came away with a large &  painful blister that was still very sore 2 days later.
> > > >
> > > >Cause = BGA chip pinout mirrored (not by me I hasten to add).
> > > >
> > > >What temp do you think the package would have reached ?
>
> --
> || Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
> || devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
> || http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


Article: 34441
Subject: Re: Principles of Verifiable RTL Design (2nd ed)
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Fri, 24 Aug 2001 15:53:24 GMT
Links: << >>  << T >>  << A >>
Ben Franchuk wrote:
> 
> > It's not hidden, Ben, it's just in a different form. The way you know it's
> > the same is twofold: first, you have a testbench you can run on the
> > synthesized result, which should produce the same results as your original
> > code. Second, you have formal verification tools, that can compare the
> > synthesizer output (gate level verilog, in the case I'm familiar with) with
> > your original VHDL or verilog code.
> 
> Since I use free tools I don't have access to the fancy tools. 

Further proof of the old adage, "you get what you pay for."

-a

Article: 34442
Subject: Re: Optical Bay Area Start-up! SW/HW Engs needed
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Fri, 24 Aug 2001 16:14:19 GMT
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> 
> 
> By the way Andy, did we really need for you to include his whole post ? :-)

I was so angry and annoyed and upset and pioughed that I neglected to
use the magic "delete" function.

Must be this Macintosh I'm workin' on...

---a

Article: 34443
Subject: Re: Reading Text in Verilog
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Fri, 24 Aug 2001 16:18:52 GMT
Links: << >>  << T >>  << A >>
Kevin Neilson wrote:
> 
> For testbenches, is there a method to read in a text file in Verilog?  The
> $fdisplay function is great for writing to files, but the functions for
> reading in files are limited; the only method I know of to read in a file is
> to dump it into a register using the $readmemh command.  However, that only
> works with files formatted in ascii-hex, e.g. "41 42 43", not files
> formatted in text, e.g. "ABC".  I wrote a Perl script to convert text files
> to ascii-hex but that seems a lame workaround.

Do a Google search for "Verilog fileio."  I don't remember off-hand what
the exact url is, but this PLI is pretty much what you're looking for. 
Most, if not all, of its functionality is in Verilog-2001 but tool
support is not clear.

It works on a Solaris box.  No idea if it works on Windows.  

BTW: you may want to post this in comp.lang.verilog...

-a

Article: 34444
Subject: Spartan II JTAG configuration
From: atali@cygrp.com (Aare Tali)
Date: 24 Aug 2001 09:57:54 -0700
Links: << >>  << T >>  << A >>
Hi all,

I'm playing with XC2S200-PQ208, WebPack 3.3W8 and homemade parallel
cable (74HC125 x 2). I ground PROGRAM pin, DONE goes low. I program
the chip without verification, DONE goes high. Verify fails always in
same place (frame 2000+). Docs (ds001_2.pdf, page 13) say that if DONE
goes high device should be configured OK. Does all that mean that even
if bitstream was received OK, the chip is fried and cannot be
programmed?

How important is to have 12 sets of 0.1/0.01uF caps, one on each
power/ground pair? What else could go wrong? I have nothing else
connected to the chip, just JTAG, M0-M2 jumpers, PROGRAM pullup and
DONE LED, and all power/ground pins. I/O is floating.

Article: 34445
Subject: Re: DRAM burst mode
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Fri, 24 Aug 2001 18:37:20 +0100
Links: << >>  << T >>  << A >>
Thanks Jan & Rick,

I found a verilog model at micron that should help.

Dave


"Jan Pech" <j.pech@sh.cvut.cz> wrote in message
news:9m3ivb$mub$1@ns.felk.cvut.cz...
> Very good description of DRAM modes, access etc. can be found in Micron's
> datasheets (http://www.micron.com).
>
> Jan
>
> > Hi All,
> >
> > I can read and write data using a fpga and dram but have no information
on
> > how to use the burst mode.
> > Has anyone got any information that could help me?
> >
> > I know that I need to change the mode and then assert the burst command
> but
> > do not have any of the mode information.
> >
> > Intel used to have a good page but it has since been removed and I never
> > downloaded the pdf (DOH)
> >
> >
> > Cheers in advance
> > Dave
> >
> >
> >
> >
>
>



Article: 34446
Subject: Re: SmartMedia
From: "darrell mcginnis" <darrell.s.mcginnis@intel.com>
Date: Fri, 24 Aug 2001 16:55:09 -0700
Links: << >>  << T >>  << A >>
Doh! I imagine that the request is for finite autonoma that
implements a SmartMedia interface protocol...

SmartMedia format has been released to the public.
There is/was a SSFDC forum that you can join to access the latest
specifications.

try www.ssfdc.or.jp
btw, SmartMedia is a trademark of  Toshiba Corporation.

"Andrew Gray" <andrew@tuks.co.za> wrote in message
news:998576679.227273@nntp.up.ac.za...
> Hi
>
> Does anyone know how to read a file from a SmartMedia card in VHDL?
>
> Andrew
>
>



Article: 34447
Subject: Re: DRAM burst mode
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 25 Aug 2001 01:09:55 +0100
Links: << >>  << T >>  << A >>


Speedy Zero Two wrote:

> Thanks Jan & Rick,
>
> I found a verilog model at micron that should help.
>
> Dave
>

Sorry, I should have mentioned the sim models as well. They're pretty good too,
the only thing they really lack is a refresh period check - or at least the ones
I downloaded a long while back.




Article: 34448
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Sat, 25 Aug 2001 00:09:58 GMT
Links: << >>  << T >>  << A >>
On Tue, 21 Aug 2001 17:14:00 GMT, 101551.3434@compuserve.com (Mark Taylor)
wrote:

>On Tue, 21 Aug 2001 10:41:04 +0100, "Tim" <tim@rockylogic.com.nospam.com>
>wrote:
>
>>"Mark Taylor" <101551.3434@compuserve.com> wrote in message
>>news:3b816b86.32685097@news.compuserve.com...
>>
>>> 1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set
>>>    for a wide data configuration?
>>>   (ie presumably the output signals can skip 4 levels of multiplexers)
>>
>>Most likely you get the muxes (pretty fast pass-transistors?) anyway.
>>
>Yes but they will be mainly switched off ( and so not contributing much to
>delays)
>or switched on and contributing  say 80 ps for 4 layers or less for fewer.
>Since the BRAMS are synchronous, they might go through a final layer of FFs.
>(in which case I am surprised that the Tbcko is so high, ~3ns on -6 grade)
>(if they do , then obviously the MUXES won't contribute at all to Tbcko)
>
>The probable difference is that for a NARROW Data width configuration,
>the setup time for some address lines (which only control the muxes) might be
>vey much less than that for other address lines (which have to go through the
>physical RAM as well).
>
>What I wanted to do was to have deliberately skewed clocks such that much of
>the fixed delays are effectively eliminated, but  I wanted to be sure that the
>delays would not have appreciable skew between the data bits. 
>There is also the issue of the net delays for routing, and whether these can be
>modelled as primarily TRANSPORT or INERTIAL. 
>I want to aggressively maximise throughput,  but not at the expense of 
>unreliability.  
>
>Look at the timing specs for the BRAMs. 
>If you are just reading from them, then they can probably coast along at
>250MHz+.
>The Tbcko + net delay +? +setup time  might add 7nS for one path.
>If this were all transport delay, it would be possible to read imposing no 
>limit on operating frequency. 
>BUT if another path only took 1nS, then there would be a slight problem.
>There's a skew of 6nS, which at a clock rate of 166Mhz would mean that the
>pipeline would be completely screwed up.
>Fmax would probably be reduced to 80MHz or so....
>This is a somewhat extreme case, but  the difference between 80MHz &
>250 MHz is enormous.
>So I need to know how severe these skews are.
>( and no, I'm not asking for 250Mhz!)
>
>
>
>
>
>>> 11)The P&R tools seem to consider (single port) RAM address lines to be
>>>    unswappable.
>>>    Is there any way around this, because almost invariably I find that
>>>    swapping  (ie deleting net pins  then adding net pins)
>>>    the two highest net delay address inputs improves the timing on BOTH lines.
>>
>>Be grateful that these lines aren't swapped when used as SRL delay values...
>>
>>
>>
>>
>Actually that wouldn't matter, as long as I knew about it!
>I would use the SRL's as a convenient way of reprogramming the contents of a
>LUT.
>This would only be sensible where most of the bits change and where the 
>update rate is less than a MHz, because 16 ~ is 16~.
>I would be mainly using RAM16s to update those LUTs where only 1 or 2 bits
>change, and where the update rate is higher.
>
>I can see that for complex cells integrating RAM with the multiplier AND's the
>scope for pin swapping is less, but would still be there.
>(just upper 2 bits and/or lower 2 bits)
>
>Even dual port is ok, as long as the F & G lines have equal swaps.
>So, the question is how do I automate the procedure of reducing the maximum net
>delays? (manually using FPGA_EDITOR is just not on ..)
>
>
>
>
Dear Sir,
 My local telephone exchange has had a problem recently so
I have had no internet access over the last few days.
Even now the connection is at 16Kbaud!
I had intended to send the text below somewhat earlier,
but at least the delay allowed me to notice a program
distributed with ISE 3: speedprint.
I wasn't able to find any references to it, but it does seem to allow
reports for best/worse case timing specifications for many
devices.
So consider questions 6 & 7 to be already well  answered by Xilinx!


>Message text written by INTERNET:peter.alfke@xilinx.com
>> 
>Mark, the reason I did not answer has to do with the large number of different
>questions, packaged together. I cannot answer them all, so I answered none.
>
>Here is the incomplete set of answers I got from a colleague:
>Some answers
>
>> 1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set
>>    for a wide data configuration?
>>   (ie presumably the output signals can skip 4 levels of multiplexers)
>
>no clue, but the speeds files would tell you (ie timing report)
>
Yes but only one Tbcko is reported by the software.
I was interested in the timing of the hardware.
I don't believe that there aren't any differences between
either the clock to data for all data lines for all configurations,
or the address to clock setup for all address lines for all configurations. 
I could be wrong, should the BRAMS contain a large number of FFs
to synchronise all lines.
The matter might be irrelevant, such as only a few pS difference, which
would get swamped by the net delays.
The net delays might be INERTIAL, in which case the swamping would be more.

>>
>> 2) is the carry out pin of a CLB in a LOW/HIGH/TRI STATE if not selected to
>>    be used in a 1 CLB hard macro?
>
>all logic is on, or off.  even the tbufs are not tristate
>
Makes sense, obviously bad for CMOS lines to be floating within high speed
logic.
So I can initialise a carry chain even when the BX input is being used for
something else?

>>
>> 3) whats the point of the CIN pins in the lowest row of slices?
>>    (ie with highest row index)
>
>No idea.  I do know that signals that don't go anywhere are tied off by the
>special term cells that go all around the clb array
>
I never understood about the tie-points for the 4000 series.
Neither did the software.

>>
>> 4) if the answer to the 3rd question is NONE then you might be amused
>>     to try smart-placing (within FPGA_EDITOR) a hard macro which uses a
>> CIN     (seems to like the lowest row for some reason!)
>
>so what happens?
>
I stopped using "smart-placing". 
>
>> 5) The Spartan2 databook is very unclear about IO banks & PQ packages.
>>     Presumably the Vref & Vccio arrangements are as with the Virtex?
>>     (which was at least clearly documented)
>
Sorry , unclear question.  What I should have written would be:
I understand that within the Virtex devices there are 8 I/O Banks,
each potentially with their own Vccio & Vref lines.
Within some packages the Vccio lines for different banks are bonded together .
The exteme case is with the HQ/PQ packages, with just 1 Vccio line,
but still with independent Vrefs.
I guess that the same applies for the Spartan2, but if I hadn't seen the
Virtex documentation I might not even have made that guess.
Am I correct in assuming independent Vrefs for the Spartan2 PQ
packages?

>spartan is always more io bonded out, with fewer vcc's and gnds.  if you want
>performance, then you buy Virtex.  If you want low cost, you buy Spartan II.
>

I want high processing performance and (generally) low I/O data rates.
Hardly any of the OBUFS will be set to FAST, so I won't be ground bouncing.
Spartan2-6 is the most cost effective solution.
(better performance than Vertex-5 )

>>
>> 6) Any chance of filling in some of the blank fields for Spartan2 -6
>> timing?
>
>don't know.  ask Robert Wells.
>
Who is Robert Wells? is he accessible via robert.wells@xilinx.com ?

>>
>> 7) How about guaranteed best case timings as well ?
>>    ( specifically for BRAM access)
>
>some day
>
Sorry It's just that I could have sworn that Xilinx indicated the availability
of this
data several months ago.The indication was in tabular form.

>>
>> 8) Would it be possible to sacrifice a BRAM   & use a DLL to lock onto the
>> Tbcko , or would the delay of other BRAMS not track? (even though being
>> guaranteed to have the same Vccint & presumably approximately the same
>> temperature?) (bearing in mind question 1, I would only be applying this to
>> identical
>> data width BRAMS)  If this approach is possible which data bit should I route
>> through?
>
>BRAM and DLL are completely different animals, and I doubt they would track
>with process/voltage/temperature
>
I meant having a clock from the output of a 2xDLL fed by the output of a BRAM
whose sole duty is to toggle 1 output bit per input clock cycle.
I.e. sanitising a dirty source in a highly controlled manner.
The delay between the two clocks would depend on Tbcko.

>
>> 9) Do the industrial versions draw more startup current than the commercial
>> devices at any given temperature,  or is it only at extremely low
>> temperatures (below the commercial range)   that the current increases?
>
>just below 0C

OK, so this should never be a reason to NOT select an Industrial part..

>
>>
>> 10) Using XST VHDL (SP8, on both WebPACK & ISE3.3i) RLOCS are lost on
>>all but
>> the first instance of a component containing RLOCS.  This is BAD , especially
>> when Carry logic and / or  MUXF5 is involved, because what creeps into the
>> wrong CLB makes no sense at all (as regards timing/space) .  I originally
>> thought this was a problem with MAP, but then examined the EDN file &
>>found
>> that MAP hadn't been told to cluster components within a CLB. (for any except
>> the first instance)
>>    "Preserve Heirarchy" had been SET (as a synthesis option).  Presumably the
>>only way around this is to use "Incremental Synthesis"?  (Apart from hacking
>> the edn file to ensure all instances refer to the first cell definition,which
>> does indeed work, but surely can't be considered a standard flow!) but
>> incremental synthesis doesn't work for any OTHER component!  I haven't tried
>> using the XILFILE attribute which could be a way to enforce the correct
>> hierarchy.
>
>This is a software question, right?  I don't do software.
>
Sorry. I thought it was a bug report !

>>
>> 11)The P&R tools seem to consider (single port) RAM address lines to be
>>    unswappable.    Is there any way around this, because almost invariably I
>> find that
>>  swapping  (ie deleting net pins  then adding net pins)   the two highest
>> net delay address inputs improves the timing on BOTHlines.
>
>There may be a dedicated route reason why this isn't allowed.  I just don't
>know.
>
It is allowed, but the tools don't do it themselves.
I'll try pretending  to MAP that the RAMs are LUTs, then patch the
file after it has been routed. 
The P&R is very good about swapping LUT inputs to improve timing.
The difficulty will be in ensuring all placement info gets through the tool
chain.
I'd pity someone targeting the xc2v10000 & using XDL.

>>
>> 12) Any chance of a job at Xilinx? (I can write tools. I can design hardware.
>> I like Xilinx hardware.)  I'm afraid that jobs locally to me are of the sort
>> "You've got to use ACTEL" (probably something to do with the name of their
>> main product line.)  or "You've got to use Virtex" ( note not Virtex-E,
>> Spartan2 or Virtex2 but  Virtex).  or "You've got to use ALTERA" or "You've
>> got to have marketing experience". I can supply the names of the guilty
>> parties, but I don't think that would help.
>
>There is always a chance.  Got a resume?  I can't say that it is a good chance,
>or if it is a bad chance, but there is a chance, yes.
>
Ok, I'll just delete the section in which I indicate my bitterness as regards
some versions of Xilinx software!



>----------------------- Internet Header --------------------------------
>Sender: peter.alfke@xilinx.com
>Received: from newsgate.xilinx.com (unknown-60-204.xilinx.com [149.199.60.204])
>	by siaag2ae.compuserve.com (8.9.3/8.9.3/SUN-1.12) with ESMTP id QAA07396
>	for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 16:39:06 -0400 (EDT)
>Received: from cliff.xsj.xilinx.com (cliff [149.199.38.103])
>	by newsgate.xilinx.com (8.11.3/8.11.3) with ESMTP id f7LKctT08896
>	for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:56 -0700 (PDT)
>Received: from newman.xilinx.com (newman [149.199.37.215])
>	by cliff.xsj.xilinx.com (8.11.3/8.11.3) with ESMTP id f7LKcbf07993
>	for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:37 -0700 (PDT)
>Received: from xilinx.com ([149.199.5.189]) by newman.xilinx.com
>          (Netscape Messaging Server 4.15) with ESMTP id GIFQOT00.TFE for
>          <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:53 -0700 
>Message-ID: <3B82C6F9.B425883E@xilinx.com>
>Date: Tue, 21 Aug 2001 13:39:21 -0700
>From: "Peter Alfke" <Peter.Alfke@xilinx.com>
>Reply-To: peter.alfke@xilinx.com
>Organization: Xilinx
>X-Mailer: Mozilla 4.7 (Macintosh; U; PPC)
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Mark Taylor <101551.3434@compuserve.com>
>Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
>References: <3b810b5a.8061400@news.compuserve.com>
>Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
>Content-Transfer-Encoding: 7bit


enc: monstercved3b.doc

Article: 34449
Subject: Re: Xilinx FPGA Editor - how to route to an internal macro net?
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Sat, 25 Aug 2001 00:20:37 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Aug 2001 00:19:48 GMT, arast@inficom.com (Alex Rast) wrote:

>This is one I think I've done before, so I probably just need my memory 
>jogged. I'm sure it's something that happens, and that you need, all the time.
>
>I've defined a hard macro, call it custommacro.nmc. This macro will have 
>internal routes and external macro pins (not the pins/I/O pads of the device, 
>the logical pins of the macro). Now, at least one of the nets connects to an 
>external pin and an internal route. One common example, for instance, is CLK. 
>You want the signal to be common to the internal CLB's of the macro and to 
>connect to external routes (in the case of CLK, to the global clock net). 
>
>Now, within the macro I define a proper external pin for the clock net, 
>attaching it to one of the CLK pins for a slice. Then I instantiate the macro 
>in the design within FPGA editor. So now I go to route a net, for instance the 
>global clock net, to the appropriate external pin on the macro, thus 
>connecting the external signal to the internal macro net. What I do is 
>highlight the macro pin I want, and all segments of the external net I want to 
>route. Then I click the route button.
>
>No success. FPGA Editor complains "WARNING:FPGAEditor: 145 - Cannot add to net 
>"Macro1CLK" -- it is an internal macro net."
>
>What am I doing wrong? Is it an error in how I've defined the external pins in 
>the macro? Using the wrong procedure to route the external nets? Or something 
>else? This situation must surely be pretty common (clock signals, in 
>particular, are almost always going to have to be common to internal routes in 
>a macro and external routes) so I think I'm missing something. As I say, I 
>think I've solved this problem before. But in any event, can someone give me 
>the basic idea of what to do?
>
>Thanks.
>
>Alex Rast
>arast@inficom.com
>arast@qwest.net

As far as I know, nets could never be included in hard macros.
(despite documentation suggesting otherwise, right back to before EPIC)
Just use the hard macro to configure slices/CLBs or whatever,
then embed the macro within a soft macro
 (ie a schematic macro with  RLOCS).
The soft macro can contain all the routing.
You will need to use FILE= thingy.nmc,
( or XILFILE=thingy.nmc if you have to go through VHDL)
as an attribute for the symbol associated with the hard macro.

Mark Taylor
Mark_Taylor_Chess@compuserve.com






Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search