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 40825

Article: 40825
Subject: Re: High speed clock routing
From: Jonathan Kirwan <jkirwan@easystreet.com>
Date: Sat, 16 Mar 2002 06:50:28 GMT
Links: << >>  << T >>  << A >>
On Sat, 16 Mar 2002 06:20:46 -0000, hmurray-nospam@megapathdsl.net
(Hal Murray) wrote:

>A more modern version is:
>
>  High-Speed Digital System Design
>       A Handbook of Interconnect Theory and Design Practices
>  by Hall, Hall, and McCall

I'll take a look at it, too.  Thanks.  I agree about your comments on
Johnson and Graham's book.

Jon

Article: 40826
Subject: Re: Spartan II IOB tristate control FF use
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 16 Mar 2002 09:47:22 +0000
Links: << >>  << T >>  << A >>


Dan wrote:

> Hi Eric,
>
> Good point about all the FFs in an IOB needing the same clk.
>
> Well, my IOB=TRUE constraint did not get implemented. Do you know what else
> might have caused this problem ?
>
> Sincerely
> Daniel DeConinck
> www.PixelSmart.com
> TEL: 416-248-4473

The IOB packing problem comes up on this NG many times so you could try an
archive search but a brief summary, for Virtex/Spartan2  is:

o No logic before an input FF.

o No logic after an output FF - not even an inverter.

o No feedback from an output FF. (*)

For BiDirs (almost all PCI signals are such).

o A common clock.

o A common initialisation signal. The function - async/sync set/reset - of this
signal can differ between the input and output FFs. The easiest way in which
this can be broken is to have one FF with an init condition and the other
without (+).

I've never really had to force the use of the tri-state FF so I'm not sure what
the exact rules for it are.

Note that even if you think you are keeping to the rules synthesis tools can
break them behind your back  esp. (*) & (+).

Having kept to all these rules its then best to use the `-pr b' flag to MAP
which tells it to IOB pack FFs if at all possible.  You can then use the
`IOB=FALSE' attribute to exclude ones you don't want packed. Its rare that
you'll need to do this but I can give you my example: The incoming IO data bus
feeds 3 registers, one "ordinary" one going into the main data path (in the
IOB) and 2 async clocked ones for IDE UDMA (not in the IOB).

Now the hard part: Finding the ones that should have been packed but weren't
...



Article: 40827
Subject: Why do I want to do this ??
From: meng.engineering@bluewin.ch (Markus Meng)
Date: 16 Mar 2002 02:06:04 -0800
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<a6qsl0$gikto$3@ID-84877.news.dfncis.de>...
> "Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag
> news:aaaee51b.0203132355.60183b6b@posting.google.com...
> > Hi all,
> >
> > on the Xilinx documentation I do find, that the bitstream
> > format has a minimum of 8 '1' at the very beginning of
> > the serial bitstream. Is it possible to extend the minimum
> > 8 of '1' to any higher number before the start-pattern
> > is being applied?
> 
> I dont know at all. Why do you want to do this? The SpartanXL are known to
> be a little bit more sensitive on configuration data clocking, since the use
> a length counter encoded into the first bits of the datastream.
> Spartan-II(E) are much easier to use, since the configuration is much
> simplified.

Hi Falk,

Using the XC2S300E for example ...

I'am shure you know that the ISP configuration PROM from Xilinx does cost
~ 20 US$ in small quantities. Now I'am working on a solution for 2$! in
small quantities. That's why I want to know ...

I got a feedback from a Xilinx support engineer, that explained me that I need
to adjust the total length count when I add '1' at the beginning. Is that your
experience as well?

For me it sounds somewhat strange, since clocking in '1' before the start-
preamble looks like not being important. Maybe I'am wrong ...

markus

Article: 40828
Subject: FPGA tools and Win2000 - problems
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 16 Mar 2002 10:09:55 +0000
Links: << >>  << T >>  << A >>
I've just had my main box in the office upgraded to 1.6GHz DDR Athlon XP
(Yippee, I've had an ordinary DDR Athlon at home for a long time) but,
according to the people who make up our PCs WinNT doesn't run reliably
on the Athlon XP. As a result I've been forced, against my will, to
abandon my tried & trusted WinNT-SP6A, which as been bomb & bullet-proof
reliable for a long time and downgrade to Win2K. I've found some strange
problems & I'm wondering if anyone can help:

o The first question has to be - have I been given a load of BS about
WinNT not running on the XP ?

o I ran a PAR with no other things happening on the box. Looking at the
post PAR report I can see that it took 31 minutes of CPU time for a
quick 4 iteration route (non XP home Athlon =~ 36) **but** the `real'
time as reported by PAR was 51 min.

Under NT the `CPU' and `real' times are never more than a minute or so
apart on a quiet machine, even with PAR set to low priority. The
difference being accounted for, I'd guess, by file IO.

Any ideas what the %^$£& Win2K was doing with those 20 min ?

o When I run ModelSim I keep most of the project stuff, scripts, etc on
a Unix box and export them to the PC via Samba. Under WinNT it made very
little difference when I did `Open Project' where the .mrp project file
was. Trying this last night under Win2K and it took ~10min just to load
the project. I hate to think what's going to happen when it tries
loading an SDF.

BTW Does anyone other than my find the Windows `My Computer' and `My
Network Places' stuff insufferably twee ?



Article: 40829
Subject: Re: Spartan-XL, SpartanII and Spartan-IIE bitstream format question ...
From: meng.engineering@bluewin.ch (Markus Meng)
Date: 16 Mar 2002 02:26:37 -0800
Links: << >>  << T >>  << A >>
Hi all,

I forgot the mention that I'am interested only in master serial
mode configuration. The CCLK's come from the FPGA ...

markus

Article: 40830
Subject: Re: Proto boards for labs
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 16 Mar 2002 10:28:25 -0000
Links: << >>  << T >>  << A >>
In article <1103_1016120744@news.glue.umd.edu>,
 Nitin Chandrachoodan <nitin@eng.umd.edu> writes:

>3. Can be used to implement reasonably large designs, 
>especially DSP filters, FFTs etc. Here  we would like to 
>implement the designs without having to go to too much low-
>level optimization (bit-serial implementations etc.) unless 
>absolutely necessary, as this would change the focus from 
>learning about FPGA implementation to low-level design.

I'm curious.  What does "learning about FPGA implementation"
mean to you?  Are you top-down type designer?  Are you trying
to teach how to use HDLs with FPGAs as compared to how to
get the best performance out of an FPGA?

I'm a bottom-up person.  I want to know the grubby details,
and the tricks for taking advantage of them - pipelining,
duplicating logic, floorplanning... 

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 40831
Subject: Re: Difference between Virtex-II(E) und Virtex-E
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 16 Mar 2002 02:32:47 -0800
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3C90C799.E64C72C2@xilinx.com...
> Virtex E was a shrink to 0.18u of the classic Virtex architecture and
> circuitry.  Virtex E added LVDS input buffers to the original Virtex
> design, but little else was changed.

I understand this was not the focus of the posting, but let us not overlook
one of Virtex-E's most notable enhancements -- the -E's doubling, tripling,
or quadrupling of the number of block RAMs per LUT, compared to Virtex.

In base Virtex devices, there are two columns of block RAMs, one at the left
edge and one at the right.  In Virtex-E there are four (V50E-V400E), six
(V600E-V1000E), or eight (V1600E-V3200E) columns of block RAMs.  In block
RAM constrained designs, this makes all the difference.

Jan Gray, Gray Research LLC




Article: 40832
Subject: Re: Why do I want to do this ??
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 16 Mar 2002 10:41:30 -0000
Links: << >>  << T >>  << A >>
>I got a feedback from a Xilinx support engineer, that explained me that I need
>to adjust the total length count when I add '1' at the beginning. Is that your
>experience as well?

>For me it sounds somewhat strange, since clocking in '1' before the start-
>preamble looks like not being important. Maybe I'am wrong ...

You should look in the data sheet or maybe an app note.  There should
be a reasonable description of the bit stream format so people can
do things like this.

On the older chips, there used to be a total-bit-count field in the
header of the bit stream.  After that many cclks, the configuration
stage ended so (as support said) if you wanted to insert 1s, you
should adjust the total count so it ends at the right time.  Otherwise
it will try to start running before you have sent it all the bits.

I'm not sure if Vertex works this way - it complicates partial
reconfiguration.  But find the documentation...

If the chip doesn't have a total-bit-count mechanism then your extra 1s
(before the preamble) should not be a problem.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 40833
Subject: Re: Difference between Virtex-II(E) und Virtex-E, correction
From: "Jan Gray" <jsgray@acm.org>
Date: Sat, 16 Mar 2002 02:46:16 -0800
Links: << >>  << T >>  << A >>
Oops.  I wrote:

> the -E's doubling, tripling, or quadrupling of the number of block RAMs
> per LUT, compared to Virtex.

Scratch "quadrupling".  There was of course no V1600-V3200 to compare
V1600E-V3200E against.  Sorry about that.

Jan Gray, Gray Research LLC




Article: 40834
Subject: Re: High speed clock routing
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 16 Mar 2002 12:35:08 +0100
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> writes:

> "Magnus Homann" <d0asta@mis.dtek.chalmers.se> schrieb im Newsbeitrag
> news:ltsn71cyyw.fsf@mis.dtek.chalmers.se...
> > > > Is this differential? In that case I would go for daisychaining and
> > > > termination at the end. SHORT stubs at intermediate devices.
> > > >
> > > > Homann
> > >
> > > No this is not differential.  This is LVTTL.
> >
> > Ah, in that case I would ask my boss to be put on another project...
> 
> You are a big Sissy.
> 
> SCNR.  ;-))

Nah, just lazy.

> A little bit more serious, is a 100 MHz LVTTL clock propagating some inches
> on a FR4 board that difficult to handle?? I mean, sure, lots of things can
> go wrong if you dont know what you are doing, BUT

Was it LVTTL? The headache start when you don't have point-to-point
clocks. With P2P, it is much easier. Slap in a series termination
resistor, and adjust as apropriate.

Daisy-chaining works quite well, but it is a bit harder to route, and
you get clock skew between devices.

Star-topology? Well, in some cases.

> Two guys in our company designed a board with a big communication processor,
> with 3 fast SDRAM/SSRAM/ZBTRAM busses (100-133 MHz). They did NO simulation,
> "just" had an eye at the layout and followed the basic guidelines that apply
> on this kind of stuff. And you wont believe it, it worked on the first run,
> almost perfect, just some minor modification of termination resistors and
> some clock line (length) modification.

As long as you know what you're doing.

> Your comment, Austin?? ;-)
> 
> > Or use a zero-delay clock buffer (PLL/DLL), if possible.
> 
> No problem, there are at least 4 inside the FPGA, Virtex-E/-II has even
> more.

Unless they have to be independent of the FPGA, of course.

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

Article: 40835
Subject: Re: High speed clock routing
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 16 Mar 2002 12:35:51 +0100
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> writes:

> "Magnus Homann" <d0asta@mis.dtek.chalmers.se> schrieb im Newsbeitrag
> news:ltg03190da.fsf@mis.dtek.chalmers.se...
> > rickman <spamgoeshere4@yahoo.com> writes:
> >
> > > I need to plan a high speed bus that will connect 5 devices.  They will
> > > all be very closely spaced so that the lengths of the routes can be kept
> > > pretty short.  The clock line is the one I am most concerned about.  It
> > > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an SBSRAM,
> > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
> >
> >
> > Is this differential? In that case I would go for daisychaining and
> > termination at the end. SHORT stubs at intermediate devices.
> 
> Isnt end termination the ONLY clean way when daisy-chaining??? (According to
> the "bible" from  Howard Johnson)

Of course. Was I unclear?

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

Article: 40836
Subject: Re: XST duplicates unnecessary IOB OE FFs
From: hamish@cloud.net.au
Date: 16 Mar 2002 12:19:38 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> Yes, if I wanted the OE FFs to be merged into IOBs, I will manually
> duplicate the OE FFs myself in my design (I used to do that.), but the
> design decision I made needs only one OE FF for AD[31:0], and one OE FF
> for C/BE#[3:0].
[...]
> I don't appreciate XST overriding the design trade off I made in the
> design, and do I have a way to prevent XST from duplicating the OE FF?
> I am using ISE WebPACK 4.1WP3.0's XST (XST E.33), and Spartan-II XC2S150
> is the target device.
> I feel like this OE FF duplication thing should not happen, and hope
> that the future version of XST will give its users an option to disable
> OE FF duplication if the user doesn't want it.

That's life with the synthesis tools - they make life easy when you
want to do the obvious thing, and difficult when you want to do something
different. Current versions of Synplify do the same thing - duplicate
the output enable FFs. Earlier versions (6.0.x, 6.1.x) didn't, and
in that case it wasn't easy to manually duplicate them. It would
combine your manually duplicated signals on you.

So, XST thinks it is being helpful by duplicating the OE FFs. Generally
speaking I think that is pretty helpful. I can't think why you wouldn't
want it. 

The only thing you get by not using the OE FFs is longer delays from 
tristate to driven or the reverse. If that's what you're trying to do,
you're depending on the minimum delays in the chip - generally not
a good idea, and in a lot of cases those delays aren't even published.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 40837
Subject: Re: High speed clock routing
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 16 Mar 2002 14:09:26 +0100
Links: << >>  << T >>  << A >>
"Magnus Homann" <d0asta@mis.dtek.chalmers.se> schrieb im Newsbeitrag
news:ltelik3fu0.fsf@mis.dtek.chalmers.se...
> > > Is this differential? In that case I would go for daisychaining and
> > > termination at the end. SHORT stubs at intermediate devices.
> >
> > Isnt end termination the ONLY clean way when daisy-chaining???
(According to
> > the "bible" from  Howard Johnson)
>
> Of course. Was I unclear?

Hmm, not at all. It sounded a little bit like, "there is also another
solution, but I prefer this one"
Anyway, understood.

--
MfG
Falk





Article: 40838
Subject: Extracting schematics to a vector file
From: Christopher.Saunter@durham.ac.uk (Christopher Saunter)
Date: Sat, 16 Mar 2002 13:19:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi All,
	I am using the Aldec schematic editor from Xilinx Foundation 4.1i
as my main design environment.  I have recently started doccumenting what
I am designing (oh joy ;-) and I am embeding parts of the schematics in
the doccument.  Currently this is being done with screenshots, which eats
up rather a lot of space and is not conductive to very good print quality.

What I would like to do is export the schematic to a standard (eg WMF)
vector format, so I can easilly embed it in documents, and edit it as a
vector file.  I would have thaught this would be a simple option to add to
SC programs, but...

The nearest I have found to a solution so far is using a demo version of
SVGMaker (sort of like Acrobat Distiller, except it produces SVG vector
files) to produce .svg files.  I figure I could then read this file in
with some language and convert it into a metafile.  This should be quite
simple, as I have libraries that abstract away the metafile format to a
graphics device context, but it all seems like a -=big=- cludge.

Does anybody know of a simpler way to do this?

Regards,
	Chris Saunter



Article: 40839
Subject: Re: Why do I want to do this ??
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 16 Mar 2002 14:23:03 +0100
Links: << >>  << T >>  << A >>
"Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag
news:aaaee51b.0203160206.2c7a77c7@posting.google.com...

> > Spartan-II(E) are much easier to use, since the configuration is much
> > simplified.
>
> Hi Falk,
>
> Using the XC2S300E for example ...
>
> I'am shure you know that the ISP configuration PROM from Xilinx does cost
> ~ 20 US$ in small quantities. Now I'am working on a solution for 2$! in
> small quantities. That's why I want to know ...

Hmm, ok.

> I got a feedback from a Xilinx support engineer, that explained me that I
need
> to adjust the total length count when I add '1' at the beginning. Is that
your
> experience as well?

??? AFAIK the Spartan-II/Virtex dont have a length count anymore. Just a s I
said in my other posting, a configured Spartan-II/Virtex ignores CCLK and
DIN (which is even a user IO after configuration), so its easy to share some
signals, you only need a seperate PROGAM pin.

--
MfG
Falk





Article: 40840
Subject: Spartan II IOB tristate control FF use
From: dmac <no@email.supplied>
Date: Sat, 16 Mar 2002 14:03:11 GMT
Links: << >>  << T >>  << A >>
Hi Dan,

My suggestion is to do this on a v small test design - can save loads of
heartache when migrating to the full design.

Try it on a single signal first and then grow it to a bus (if that's what you
want). Often the tool can do it for a single bit but gets confused on
multiples.

Open up the chip editor, look at the IOB structure & draw exactly that on
your schem - then cut out the bits you don't need - it'll make sure you're
not trying to use bits that don't exist.

Also, does your ts stimulus come from internal logic or external - if
external then the tool may get confused where to put that flip-flop.

Like Rick said, there will be loads on this in Google groups - prob targetted
at VHDL but I think you'll find parallels.

Dave

-- 
dmac

Article: 40841
Subject: Re: High speed clock routing
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Sat, 16 Mar 2002 14:23:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3C9237E8.8D818B3A@yahoo.com...
> Magnus Homann wrote:
> >
> > rickman <spamgoeshere4@yahoo.com> writes:
> >
> > > I need to plan a high speed bus that will connect 5 devices.  They
will
> > > all be very closely spaced so that the lengths of the routes can be
kept
> > > pretty short.  The clock line is the one I am most concerned about.
It
> > > is 100 MHz ECLKOUT from a TI C6711 DSP.  The five devices are an
SBSRAM,
> > > two SDRAMs (16 bits each for 32 bit memory) and an XC2S200E.
> >
> > Is this differential? In that case I would go for daisychaining and
> > termination at the end. SHORT stubs at intermediate devices.
> >
> > Homann
>
> No this is not differential.  This is LVTTL.  BTW, what do you mean by
> SHORT?  Is that anything like telling someone to pay CAREFULL attention
> to signal routing?  :)

Presumably 'short relative to 1/4 the wavelength', where the wavelength is
that of the highest harmonic you need to maintain the integrity of the
signal. You don't want the stub acting as a circuit component, as with
transmission lines and microwave circuitry.

Leon



Article: 40842
Subject: Re: FPGA tools and Win2000 - problems
From: emanuel stiebler <emu@ecubics.com>
Date: Sat, 16 Mar 2002 09:22:14 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> o The first question has to be - have I been given a load of BS about
> WinNT not running on the XP ?

Probably ;-)
 
> Under NT the `CPU' and `real' times are never more than a minute or so
> apart on a quiet machine, even with PAR set to low priority. The
> difference being accounted for, I'd guess, by file IO.

You're using palain w2000 or already sp2 ?
 
> Any ideas what the %^$£& Win2K was doing with those 20 min ?

Calling billy for help ?
;-)
 
> o When I run ModelSim I keep most of the project stuff, scripts, etc on
> a Unix box and export them to the PC via Samba. Under WinNT it made very
> little difference when I did `Open Project' where the .mrp project file
> was. Trying this last night under Win2K and it took ~10min just to load
> the project. I hate to think what's going to happen when it tries
> loading an SDF.

Check the version of samba you're using. The versions before 2.1 (IIRC)
had big problems with w2000. (mostly performance)

Actual version of samba is 2.2.3a (from february ?)

cheers,

P.S. Sitting in the same boat. Downgraded my system from nt4sp6a to
w2000sp2,
     but on a P4. As at your place, all my design files are on a box I
trust.

Article: 40843
Subject: Re: FPGA tools and Win2000 - problems
From: spam_hater_7@email.com (Spam Hater)
Date: Sat, 16 Mar 2002 16:34:19 GMT
Links: << >>  << T >>  << A >>

FWIW:

WinNT had a meager TCP/IP stack, and terrible memory management.

Attempts were made to fix those in Win2K.

Unfortunately, that just made matters worse.  The few good features of
the IP stack were removed, and the memory management was made worse.

(Sort of on-topic for the group, as a lot of people run their tools
under 'doze.)

I can't imagine that WinNT-SP6a has any problems with an XP.  The SMP
features might not work, but a single processor should.

I, personally, would kick and scream to get my stable OS back.  I've
spent a fair amount of time doing CAD tools administration, and
swapping out an OS in the middle of a project is a hanging offense.

SpamHater7


On Sat, 16 Mar 2002 10:09:55 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>I've just had my main box in the office upgraded to 1.6GHz DDR Athlon XP
>(Yippee, I've had an ordinary DDR Athlon at home for a long time) but,
>according to the people who make up our PCs WinNT doesn't run reliably
>on the Athlon XP. As a result I've been forced, against my will, to
>abandon my tried & trusted WinNT-SP6A, which as been bomb & bullet-proof
>reliable for a long time and downgrade to Win2K. I've found some strange
>problems & I'm wondering if anyone can help:
>
>o The first question has to be - have I been given a load of BS about
>WinNT not running on the XP ?
>
>o I ran a PAR with no other things happening on the box. Looking at the
>post PAR report I can see that it took 31 minutes of CPU time for a
>quick 4 iteration route (non XP home Athlon =~ 36) **but** the `real'
>time as reported by PAR was 51 min.
>
>Under NT the `CPU' and `real' times are never more than a minute or so
>apart on a quiet machine, even with PAR set to low priority. The
>difference being accounted for, I'd guess, by file IO.
>
>Any ideas what the %^$£& Win2K was doing with those 20 min ?
>
>o When I run ModelSim I keep most of the project stuff, scripts, etc on
>a Unix box and export them to the PC via Samba. Under WinNT it made very
>little difference when I did `Open Project' where the .mrp project file
>was. Trying this last night under Win2K and it took ~10min just to load
>the project. I hate to think what's going to happen when it tries
>loading an SDF.
>
>BTW Does anyone other than my find the Windows `My Computer' and `My
>Network Places' stuff insufferably twee ?
>
>


Article: 40844
Subject: Re: Spartan II IOB tristate control FF use
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Sat, 16 Mar 2002 10:19:28 -0800
Links: << >>  << T >>  << A >>

I think you can find a summary of what was packed and what was not
by looking towards the tail end of the mapper report (whatever.mrp).

For each IOB/Pin, it lists the use of the INFF, OUTFF, or ENBFF.

Eric

Rick Filipkiewicz wrote:

> Now the hard part: Finding the ones that should have been packed but weren't
> ...

Article: 40845
Subject: Virtex & CLKDLL
From: "niv" <niv@ntlworld.com>
Date: Sat, 16 Mar 2002 18:51:01 -0000
Links: << >>  << T >>  << A >>
Hi,

I have a design with 6 clocks, all below 20MHz, so can't use the DLL.

However, redesigning to use only 5 clocks, 4 very slow and one at 40 MHz.

The 40MHz goes to a DLL and the other 4 to various inputs.
2 of these go to global clock pins, and 2 not.
The 40M should go to a global clock pin.

However, upon synth (leonardo) only  the 4 slow clocks show up in the clock
constraints tab, the 40MHz is only listed under the input tab!

I tried to force the 40M to global pin by firstly putting it in the VHDL
code (BUFGP) and then, when that failed, by telling leonardo to use BUFGP
pad.  Still failed.

These failures are occurring in PAR (Xilinx 3.1), it does seem to synth OK,
but not as req..

Anyone got an insight how to sort this out?

The old design with six clocks worked just fine, 4 to global clk pins and 2
(very slow) to normal IO pins.

TIA, Niv



Article: 40846
Subject: Re: Block Ram
From: "Edwin Bland" <edwinb@in-inc.com>
Date: Sat, 16 Mar 2002 12:36:01 -0800
Links: << >>  << T >>  << A >>
I have a Spartan 2 that I wish to use for an 8051 core.  I need to know how to instantiate the RAM & ROM elements for this device.  Any help will be appreciated.  I believe I should be able to utilize the internal resources of this device without having to use external memories...  I guess I'm not looking in the right area of the Xilinx site.

Article: 40847
Subject: just bought Cohen's book...Real Chip Design and Verification using Verilog and VHDL
From: strut911@hotmail.com (strut911)
Date: 16 Mar 2002 12:47:39 -0800
Links: << >>  << T >>  << A >>
its a little rough around the edges in appearance (sorry mr. cohen)
but its worth its weight in gold in terms of the lessons that can be
learned from it. i had it for one day and i already learned about five
new things, and i thought i had been in the industry long enough to
consider myself a semi-professional. there are all sorts of tips and
tricks that can be used to combat well-known design issues (i never
thought of using a flancter before) and it goes through the real way
to write verification suites (instead of paying lip-service to some
simple testbenches). overall, i am very happy with it. some issues i
have with it are: leans a bit more towards vhdl than verilog, although
he obviously tries to balance the two languages, synplify pro
schematics are sometimes a bit tough to follow, and in some cases it
might be slightly better to abbreviate the code listings instead of
allowing it to take up multiple pages.
but like i said, in the true spirit of independent publishing, its
rough around the edges, but definitely written by an expert. i will
definitely recommended the people at work to pick up a copy. the only
thing mr. cohen needs to worry about is that he might not get as much
consulting work since he already present many solutions to common
problems in his book.
i just wanted to give everyone a heads up on my experience with this
book. if you want to learn more about chip/fpga design and
verification, at least the way it is done by professionals, i
recommend this book. or if you want to support good independent
publishing and encourage more experts to publish books where they can
actually make money and provide quality instruction (are you listening
mr. andraka?), then i would also recommend this book. this is just my
two cents. i hope other people can present their reviews of this or
other industry books also.
strut911

Article: 40848
Subject: Re: just bought
From: Mike Treseler <tres@tc.fluke.com>
Date: Sat, 16 Mar 2002 13:52:28 -0800
Links: << >>  << T >>  << A >>
strut911 wrote:

> i just wanted to give everyone a heads up on my experience with this
> book. if you want to learn more about chip/fpga design and
> verification, at least the way it is done by professionals, i
> recommend this book. 

I would find this review much more credible 
if Mr. Strut911 from hotmail.com
would identify himself. 

         -- Mike Treseler

Article: 40849
Subject: Re: XST duplicates unnecessary IOB OE FFs
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 16 Mar 2002 16:11:29 -0600
Links: << >>  << T >>  << A >>
hamish@cloud.net.au wrote:
> 
> 
> That's life with the synthesis tools - they make life easy when you
> want to do the obvious thing, and difficult when you want to do something
> different. 

        Yes, synthesis tool makes the design process easier for a state
machine design compared to using schematics I think, but when I start to
do something different than most people will do like using only one OE
FF for 32 pins, I guess that's when things go wrong.


> Current versions of Synplify do the same thing - duplicate
> the output enable FFs. Earlier versions (6.0.x, 6.1.x) didn't, and
> in that case it wasn't easy to manually duplicate them. It would
> combine your manually duplicated signals on you.
> 
> So, XST thinks it is being helpful by duplicating the OE FFs. Generally
> speaking I think that is pretty helpful. I can't think why you wouldn't
> want it.
> 


        I guess the XST is not the only synthesis tool that has this
problem.
Yes, I also think XST thinks that it is being helpful by noticing that I
use only one OE FF, and automatically duplicating it for me so that all
output and OE FFs will be merged into IOBs, and thus making Tco, Ton,
and Toff faster, but I only want Tco to be fast, and I don't care about
Ton or Toff.
For Ton and Toff, reducing Tsu for the OE FF is more important.
        To tell you the truth, for 33MHz PCI, since Tsu is < 7ns,
getting an OE FF automatically duplicated is not a big problem for
meeting Tsu, but I realized that this OE FF duplication is a big problem
if I wanted my PCI IP core to have even a small chance to meet 66MHz
PCI's Tsu < 3ns.
Mine doesn't have to meet 66MHz PCI's Tsu < 3ns, but it will be nicer if
it had some chance.



> The only thing you get by not using the OE FFs is longer delays from
> tristate to driven or the reverse. If that's what you're trying to do,
> you're depending on the minimum delays in the chip - generally not
> a good idea, and in a lot of cases those delays aren't even published.
> 
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>


        The reason why I am using only one OE FF which most people will
prefer duplicating OE FF in the code, or getting it automatically
duplicated is because I use a thing called Address/Data Stepping in my
design.
Address/Data Stepping is a technique in PCI for slower devices to turn
on their AD[31:0], C/BE#[3:0], and PAR tri-state buffer slowly to reduce
switching noise (I know virtually nothing about signal integrity issues,
but this is what I read somewhere.), but can also be used to turn on
those tri-state buffers one cycle later if the device cannot turn it on
within Tval < 11ns.
Xilinx and Altera both use this technique in their PCI IP cores, so I
figured, why shouldn't I?
In my current design, a path from control signals (FRAME#, IRDY#,
DEVSEL#, TRDY#, STOP#) to AD or C/BE# OE FF has about 4 levels of
4-input LUT which is not nice at all (I wish it was lower like 2 or 3
levels, but I have got a lot of inputs.), plus the routing distance is
pretty long.
Things can only get worst in 64-bit PCI, and I think will be near
impossible to meet Tsu < 3ns in 66MHz PCI even if more Tsu is
artificially created by putting delay on the global clock buffer.
So, I think Xilinx decided to make a trade-off, and put an OE FF near
the control signals to meet Tsu < 3ns, and have the thing turned on by
the next cycle.
Fortunately in PCI, Ton is infinite (I will turn it on within 30ns (15ns
in 66MHz PCI) though.), and Toff is 28ns (14ns for 66MHz PCI), so after
the control signals are latched into the OE FF, I have plenty of time to
turn the tri-state buffers on or off.
The only downside to doing this is GNT# has to be asserted for at least
two cycles to do a busmaster transfer, so that can reduce performance
somewhat in theory.



Kevin Brace (Typically, don't respond to me directly, and respond within
the newsgroup.)



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