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 40850

Article: 40850
Subject: Re: just bought
From: "Paul" <nospam@nospamplease.com>
Date: Sat, 16 Mar 2002 22:59:00 -0000
Links: << >>  << T >>  << A >>
Whilst I agree with the principle, Mike. It was perhaps a tad harsh
sounding.

Ben (aka VHDL) Cohen hasn't struck me as a shameless self promotor on here.

Anyway I look forward to the book when it arrives here in England.
Its a bit of a shame its not featured at any of the major booksellers online
and only at www.vhdlcohen.com AFAIK

Paul Baxter (also with a munged email address registered, but its
pauljnospambaxter@hotnospammail.com without the nospams)


"Mike Treseler" <tres@tc.fluke.com> wrote in message
news:3C93BE9C.87F44C40@tc.fluke.com...
> 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: 40851
Subject: Re: just bought...
From: "Austin Franklin" <austin@dar55kroom.com>
Date: Sat, 16 Mar 2002 18:03:59 -0500
Links: << >>  << T >>  << A >>
> > 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

Same thought came to my mind....though he's posted in comp.arch.fpga
before...

Out of curiosity, and not meaning to sound crass (me, no) but don't they
teach the use of capital letters, two spaces after a period, and a line
break between paragraphs in school these days?

Austin




Article: 40852
Subject: Re: just bought...
From: "Pete Fraser" <pfraser@covad.net>
Date: Sat, 16 Mar 2002 15:51:15 -0800
Links: << >>  << T >>  << A >>

"Austin Franklin" <austin@dar55kroom.com> wrote in message
news:u97jr0cosbpc33@corp.supernews.com...

> Out of curiosity, and not meaning to sound crass (me, no) but don't they
> teach the use of capital letters, two spaces after a period, and a line
> break between paragraphs in school these days?
>
> Austin
>
I certainly hope they don't teach two spaces after a period.
That's a typographical no-no that went out with the typewriter.

ObFPGA. Anybody got sensible speed numbers from Leonardo/Stratix yet?



Article: 40853
Subject: Re: To Falk Brunner
From: Ray Andraka <ray@andraka.com>
Date: Sat, 16 Mar 2002 23:59:25 GMT
Links: << >>  << T >>  << A >>
You can use it too, it just isn't documented.  The block can be wired from
within the FPGA editor.  It is a strictly combinatorial block, intended to get
the OE turned around from trdy/irdy quickly.  I'm not sure if the current
software will recognize the block if you put it in the edif netlist (direct
instantiation of a black box in your source), there was mention that perhaps
it did a while back here...I haven't tried it.  If it does, you are nearly
home free, if not, then you can always add it as a hard macro generated in
FPGA editor.

Dan wrote:

> Thanks for the input.
>
> Which signals can not be registered ?
>
> Do you mean TRDY and IRDY ?
>
> Xilinx told me that the dedicated IRDY & TRDY pins do have different logic
> than the other IO pins. But they said that they do not publish the
> difference and that only Xilinx can use it.
>
> Sincerely
> Daniel DeConinck


Article: 40854
Subject: Re: just bought...
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sun, 17 Mar 2002 00:03:21 -0000
Links: << >>  << T >>  << A >>
Pete Fraser wrote
>
> "Austin Franklin" <austin@dar55kroom.com> wrote in message
> news:u97jr0cosbpc33@corp.supernews.com...
>
> > Out of curiosity, and not meaning to sound crass (me, no) but don't they
> > teach the use of capital letters, two spaces after a period, and a line
> > break between paragraphs in school these days?
> >
> > Austin
> >
> I certainly hope they don't teach two spaces after a period.
> That's a typographical no-no that went out with the typewriter.

You try getting your fingers to forget it...




Article: 40855
Subject: Re: Reply to Kevin
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 16 Mar 2002 18:04:46 -0600
Links: << >>  << T >>  << A >>



Dan wrote:
> 
> Hi Kevin,
> 
> First off, thanks for lots of great input.
> 
> So which ones can not be registered ?
> 


        When transitioning from an idle state to an address decode state
(PCI specification Appendix B target state machine doesn't have such a
state, but I added such a state in my design), the PCI IP core has to
monitor FRAME# and IRDY#, and when FRAME# = 'L' and IRDY# = 'H', it
should transition to an address decode state.
In Appendix B, the example transitions to a bus busy state, but I didn't
like that, so I did it differently.
However, it is pretty much a requirement to implement a bus busy state,
and I will explain that later.
Regardless, using a registered version of whatever signal means
incurring one cycle of delay, and when determining when the target state
machine should get out of an idle state, and transition to an address
decode state, that one cycle of delay will mess things up.
Unfortunately, a lot of things in PCI in my opinion cannot be
registered, and especially so regarding control signals (FRAME#, IRDY#,
DEVSEL#, TRDY#, STOP#, and PAR).



> >I finally figured out a way to activate that mysterious PCILOGIC thing
> >I can E-mail the sample code to anyone interested.
> I accept your offer support@pixelsmart.com
> 
> Tsu < 7ns. I assumed that this applied to PCI input signals. I use a
> dedicated clock input and the high speed clock routing. All input FFs are in
> the IOB and get latched at the same time. I thought that was all that could
> be done and all that should be done to input PCI signals.


        Some unregistered control signals have to go through multiple
levels of LUT, and reach another IOB output FF or OE FF (tri-state
control FF).
For example, in target mode, unregistered FRAME# and IRDY# will
influence the outcome of DEVSEL#, TRDY#, and STOP#'s output FF and OE
FF, and for timing reasons, those FFs have to be within IOBs.
So, latching unregistered FRAME# and IRDY# within an IOB input FF or
regular CLB FF, and influencing the outputs of DEVSEL#, TRDY#, and STOP#
will be too late in some cases like when the PCI IP core detected an end
to a burst transfer, or when waiting for FRAME# to get deasserted in a
backoff state (STOP# and DEVSEL# have to be immediately deasserted when
FRAME# is deasserted.).



> I get the feeling
> that I am missing the point on Tsu. What am I missing ?
> Tsu: where is this measured from and to ?
> 


        For 33MHz PCI, Tsu has to be < 7ns, and it is defined as 7ns
before a positive edge of a clock strikes.
However, in practice, you have about 2.5ns more global clock delay
within a Spartan-II XC2S150-5CPQ208 (the chip Insight Electronics PCI
card uses), but that global clock delay can be significantly less in
some other FPGAs (device dependent).
Using Floorplanner is the most effective way of reducing Tsu in addition
to reducing levels of LUT through simplifying the design.



> >I heard some chipsets don't let PCI devices that don't implement
> configuration registers function at all by cutting off clock supply to it.
> 
> I heard the same thing about the PCI clock being disabled.
> 
> >What are the chipsets do the motherboards you got have?
> I have not even looked at my mother board chipset.
> 


        In theory, ANY PCI card should work with ANY motherboard that
has PCI slots, but in practice, some designers seem test it only on
Intel chipsets, and not on other chipsets (VIA, SiS, ALi, AMD, etc.).
VIA or SiS has a lot more market share than 4 or 5 years ago (Intel
seemed to had 90% market share in motherboard chipsets at one point.),
so assuming that people will only have an Intel chipset in their
computers is probably not a safe idea.
Otherwise, you will get buggy cards that work on certain computer, but
not on others, and certainly customers who know almost nothing about PCI
will pay for that.



> >You should never assume that burst read cycle won't occur.
> I have always heard people complaining that wintel platforms do not busrt
> read. Is this just a myth ? Do some of them acctually burst read ?
> 


        Yes, I think it is true that x86 processors don't do read
bursts, and my theory is that most memory read instructions cannot be
posted unlike memory write instructions.
I don't own a logic analyzer, and don't have access to it, so I haven't
actually seen it.
However, Intel and AMD recently added prefetch instructions in their
latest processors, so who knows, someone may write some code trying to
prefetch data from your PCI card's memory map.
Besides that, as far as I know, NO where in the PCI specification says
"In x86 platforms, a host bridge doesn't initiate burst read cycles," so
you have to design your PCI IP core knowing that it might happen.
At least, that's how I did mine.
Plus, in PCI, any bus master device can initiate burst read cycles, and
you cannot tell if that device is a microcessor (CPU) or a bus master
PCI device.



> I use viewdraw. I will eventually learn VHDL. I get more embarrassed each
> day about using schematics.
> 


        I guess I shouldn't start those Verilog vs. VHDL debate here,
but I personally think Verilog is somewhat a simpler language, and has
less learning curve compared to VHDL.
So, I will recommend learning Verilog, 
But even for a PCI IP core design, I think you should use Verilog or
VHDL rather than schematics because HDL makes state machine design easy
compared to schematics.
Learning either HDL should save you a lot of time in the long run
compared to doing a PCI IP core in schematics.
At least, I cannot imagine myself doing a PCI IP core in schematics
because it will take much much more time.
However, Austin Franklin said some time ago that Xilinx's LogiCORE PCI
was done in schematics, and was pretty buggy when it was first released.
Austin's PCI IP core which Xilinx once considered buying it (or
licensing it) was also done in schematics according to him.



> I would love to get my PCI logic design working rather than using another.
> Having your own is very very flexible.
> 


        My PCI IP core has a flexible interface that can handle burst
transfers, and at least I know that the target part of it is fairly
stable, but the initiator (bus master) part still needs more work.
If still interested, let me know that (What happened to the plane ticket
thing?).
I am sure using a PCI IP core will save you many months of struggle to
get yours to work (Mine is also taking long long time to develop it.).
However, you will also learn a lot about PCI by doing your own PCI IP
core.



> I do not have a bus busy state. But I only start a transaction if the
> command is a memory read/write AND my address space is decoded. Shouldn't
> this be enough to prevent me from starting a transaction that is not for me.
> 


        I am starting to suspect that not having a bus busy state is the
reason why the card works most of the time, but fails sometimes.
My theory is that occasionally, the AD[31:0] and C/BE#[3:0]'s bit
pattern happens to be same as the address and command you are thinking
is not being utilized, and when that happens, your PCI IP core
mistakenly starts the transaction, leading to a crash because some other
device is still using the bus.
I came up with this theory when you said something like when a third
party PCI card is with your Spartan-II PCI card, the computer crashes.
It is possible that third party PCI card (Who made it?) is a bus master
device, and during the bus master transfer, it may output certain bit
patterns on AD[31:0] and C/BE#[3:0] that exactly matches your PCI card's
address and command.
PCI bus is a time multiplexed bus, so you need to have a bus busy state
to ignore the traffic on the bus when you know that the transaction is
not for you.
If you have a logic analyzer, you should be able to see when the thing
crashes.
In my case, I used Post P&R simulation extensively before burning a
Configuration PROM.




> >In PCI, FRAME# = 'L' and IRDY# = 'H' signals the start of a transaction,
> I think of the start of a transaction in another way. It is the first clock
> that FRAME# goes low. This is when I latch the command nibble and the
> address. I ignore IRDY# when making this determination. Shouldn't this be
> sufficient to prevent me from claiming a transaction in error ?
> 
> Thanks again Kevin.
> 
> Dan DeConinck


        Again, PCI bus is a time multiplexed bus, so you cannot assume
that when FRAME# = 'L' is the only condition that signals an address
phase.
FRAME# and IRDY#'s meaning change depending on where you are in the
transaction.
Therefore, a bus busy state is important.



Kevin Brace

Article: 40856
Subject: Re: Difference between Virtex-II(E) und Virtex-E
From: Ray Andraka <ray@andraka.com>
Date: Sun, 17 Mar 2002 00:05:51 GMT
Links: << >>  << T >>  << A >>
And those extra columns can make using the floorplanner a PITA with RPMs because
of a bug in the floorplanner software.  Basically, an RPM can't be placed so
that it straddles a BRAM column in the floorplanner even though it is legal to
do and accepted by the rest of the tools  It can make the floorplanning a real
fun time!

Jan Gray wrote:

> 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: 40857
Subject: Re: just bought
From: Tim Hubberstey <sendme@no.spam>
Date: Sun, 17 Mar 2002 00:15:18 GMT
Links: << >>  << T >>  << A >>
Paul wrote:
[snip]
> Anyway I look forward to the book when it arrives here in England.
> Its a bit of a shame its not featured at any of the major booksellers online
> and only at www.vhdlcohen.com AFAIK

Fatbrain:
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0970539428&vm=

Barnes & Noble:
http://shop.barnesandnoble.com/bookSearch/isbnInquiry.asp?isbn=0970539428
-- 
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . .  VHDL, ASICs, FPGAs, embedded systems

Article: 40858
Subject: Re: To Falk Brunner
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Sat, 16 Mar 2002 18:51:06 -0600
Links: << >>  << T >>  << A >>
Should I post the Verilog code I wrote that instantiates it from XST as
a public service to this newsgroup?
I figured it out how to use it from ISE WebPACK + XST (I don't have
access to FPGA Editor.), and it seems to work well in ModelSim
XE-Starter with my own PCI IP core.
However, I didn't feel like burning a Configuration PROM just for it, so
I haven't tested it in a real computer though.
Do people of this newsgroup have a problem me posting fairly long code
with a constraint file?
I honestly don't really like the idea that Xilinx has an upper hand over
ordinary users, and they are the only ones who know how to use it.



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

Article: 40859
Subject: Re: just bought...
From: William Meyer <wmhmeyer@earthlink.net>
Date: Sun, 17 Mar 2002 01:08:12 GMT
Links: << >>  << T >>  << A >>
In article <u97jr0cosbpc33@corp.supernews.com>, austin@dar55kroom.com 
says...
> 
> Out of curiosity, and not meaning to sound crass (me, no) but don't they
> teach the use of capital letters, two spaces after a period, and a line
> break between paragraphs in school these days?

No, they teach creative spelling, and other feel-good notions. Spelling, 
phonics, and grammar are all deprecated, as is any sense of conventional 
layout, of course.

Bill

Article: 40860
Subject: Looking for EBook?
From: lyqin@cti.com.cn (Leon Qin)
Date: 16 Mar 2002 18:51:31 -0800
Links: << >>  << T >>  << A >>
HDL Chip Design,
Writting TestBench,
Real Chip Design


Who can help me ?
My email box is big enough for receieve this boos .

Article: 40861
Subject: pipeline
From: poirjh <svcb@urti.oirut>
Date: Sat, 16 Mar 2002 18:54:23 -0800
Links: << >>  << T >>  << A >>
who can introduce some examples and concept (books/link)about pipeline?

Article: 40862
Subject: Re: just bought...
From: "Austin Franklin" <austin@dar55kroom.com>
Date: Sat, 16 Mar 2002 22:36:11 -0500
Links: << >>  << T >>  << A >>
> I certainly hope they don't teach two spaces after a period.
> That's a typographical no-no that went out with the typewriter.

Hi Pete,

Says who (I mean in an authoritative position WRT type written
"correctness"...like the MLA Style Sheet....remember that?)?  And I ask that
seriously.

At least to me, it's a heck of a lot more readable with two spaces...which
is why I believe "they" did it in the first place.

Austin




Article: 40863
Subject: Re: Spartan II IOB tristate control FF use
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Sun, 17 Mar 2002 03:43:28 GMT
Links: << >>  << T >>  << A >>
On Sat, 16 Mar 2002 09:47:22 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>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. (*)

You can get feedback from an output FF quite easily - the feedback
comes back through the ibuf.

It's a bit tricky to specify in HDL though, as you need to convince
the tool that this pin is bidirectional.
1.  The port mode should be inout  (VHDL)
2.  The output driver needs a tristate control, but not a trivial one
that the tool can optimise out, yet something that will always be on
during operation.  Gsr works well for this (if you can handle the
output pins going hiZ during reset).

It's not something you need often.  I've used it for connections to a
logic analyser, when I wanted the signals on the pins (input and
output) to be sampled at the same time.

Regards,
Allan.

>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: 40864
Subject: Re: just bought Cohen's book...Real Chip Design and Verification using Verilog and VHDL
From: strut911@hotmail.com (strut911)
Date: 16 Mar 2002 21:16:14 -0800
Links: << >>  << T >>  << A >>
man...tough crowd. first my credibility is challenged, and then my
typographical style. next post will be in all capitals with 5 spaces
after the period.
strut911

Article: 40865
Subject: Re: just bought
From: strut911@hotmail.com (strut911)
Date: 16 Mar 2002 21:22:52 -0800
Links: << >>  << T >>  << A >>
Mike Treseler <tres@tc.fluke.com> wrote in message news:<3C93BE9C.87F44C40@tc.fluke.com>...
> 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

ouch...just trying to help. disregard it if you feel uncomfortable.
strut911

Article: 40866
Subject: Re: minimum value for clock to output
From: nahum_barnea@yahoo.com (Nahum Barnea)
Date: 17 Mar 2002 00:30:29 -0800
Links: << >>  << T >>  << A >>
Hi Rick.
ThankX for your answer.
Can you please elaborate on the 'SPEEDPRINT' utility ?
Is it a part of the xilinx package ?

ThenkX again.
Nahum.

Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3C91A1E7.C179FA9A@algor.co.uk>...
> Nahum Barnea wrote:
> 
> > Hi.
> > Xilinx tradionally publish only max values for the clock to out
> > delays.
> >
> 
> This isn't quite correct. Although quite often the early datasheets don't
> publish min delays when a part family matures a little they do tend to
> appear. Its even possible to do a min timing simulation.
> 
> >
> > I remember that there is an application note that say that the min clock
> > to out value can be taken as 1/3 'rd of the max value (or 1/4 'th if
> > you are a conservative person).
> >
> 
> Check out the `SPEEDPRINT' utility. There's a min timing flag and it will
> tell you either the min timings or a message saying they are not available.
> 
> Its some time since I dumped the min & max timings and did a comparison but
> IIRC the ratio for the 1000001 timing values for original Virtex  was,
> overall, about  ~ 1/3.

Article: 40867
Subject: Re: Extracting schematics to a vector file
From: hamish@cloud.net.au
Date: 17 Mar 2002 09:02:04 GMT
Links: << >>  << T >>  << A >>
Christopher Saunter <Christopher.Saunter@durham.ac.uk> wrote:
> 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...

Print to PostScript, convert to EPS?


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

Article: 40868
Subject: Re: minimum value for clock to output
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 17 Mar 2002 09:07:02 +0000
Links: << >>  << T >>  << A >>


Nahum Barnea wrote:

> Hi Rick.
> ThankX for your answer.
> Can you please elaborate on the 'SPEEDPRINT' utility ?
> Is it a part of the xilinx package ?
>
> ThenkX again.
> Nahum.
>
>

Its certainly part of the full, paid for, ISE package. I don't know about WebPACK.

Its documented in the Development System Reference Guide.


Article: 40869
Subject: Re: Spartan II IOB tristate control FF use
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 17 Mar 2002 09:12:17 +0000
Links: << >>  << T >>  << A >>


Eric Crabill wrote:

> 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
>
>

I should have elaborated: By "hard part" I mean detecting automatically that an FF
that should be packed wasn't, generating an error message, and stopping the build
process. I had a script that had worked fine since I first came across the IOB
packing problem ... and then the $£*&$%'s changed the MAP report format for 4.1i
!?




Article: 40870
Subject: Re: XST duplicates unnecessary IOB OE FFs
From: hamish@cloud.net.au
Date: 17 Mar 2002 09:13:16 GMT
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
>        I guess the XST is not the only synthesis tool that has this
> problem.

I wouldn't say it's a problem. Generally speaking it is a helpful
thing for it to do. It makes the code look better if you only have
a single output enable signal, rather than manually creating N of them.

It's a fact of life that if you want something different from the
obvious behaviour, you have to fight the tools for it. The tool thinks
it is optimising the design for you. But the tools just aren't very
good at optimising really high speed stuff.

A while back I was having trouble getting a design routed, so I started
fiddling with the manual fan-out control. I changed the value and looked
at the tool's speed estimate. I found an optimal value according to
the tool -- but the optimal value at route time was different again.
So I don't pay too much attention to the estimated clock speeds.

The automatically duplicated signals are only half as effective as
they could be due to register ordering performed by Xilinx MAP.
The synth tool companies need to do something to work around this
ASAP. In the longer term, Xilinx urgently needs to provide an
attribute that can be applied to signals to disable this behaviour.


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

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


Allan Herriman wrote:

> On Sat, 16 Mar 2002 09:47:22 +0000, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>
> >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. (*)
>
> You can get feedback from an output FF quite easily - the feedback
> comes back through the ibuf.
>
> It's a bit tricky to specify in HDL though, as you need to convince
> the tool that this pin is bidirectional.
> 1.  The port mode should be inout  (VHDL)
> 2.  The output driver needs a tristate control, but not a trivial one
> that the tool can optimise out, yet something that will always be on
> during operation.  Gsr works well for this (if you can handle the
> output pins going hiZ during reset).
>
> It's not something you need often.  I've used it for connections to a
> logic analyser, when I wanted the signals on the pins (input and
> output) to be sampled at the same time.
>
> Regards,
> Allan.
>

I use that trick as well. The `Rule' really relates to those times when your
wonderful synth tool has fed back an output FF behind your back. Typically it goes
like this. In some state machine:

in state A: my_out_ff is optionally turned on

in states B,C: my_out_ff holds its value.

in state D: my_out_ff gets turned off

What I've seen Synplify do is to not use the clock enable at B,C but wire the
`my_out_ff' value through LUTs into the D input.



Article: 40872
Subject: Re: just bought...
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 17 Mar 2002 10:29:40 +0100
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@dar55kroom.com> writes:

> > > 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
> 
> Same thought came to my mind....though he's posted in comp.arch.fpga
> before...
> 
> Out of curiosity, and not meaning to sound crass (me, no) but don't they
> teach the use of capital letters, two spaces after a period, and a line
> break between paragraphs in school these days?

Only in US schools, I believe. Here, it is one space and no line
break.

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

Article: 40873
Subject: Re: To Falk Brunner
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 17 Mar 2002 10:32:17 +0100
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> writes:

> I honestly don't really like the idea that Xilinx has an upper hand over
> ordinary users, and they are the only ones who know how to use it.

Well, they make the chip, so I guess it's hard to imagine theyh NOT
having an upper hand.

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

Article: 40874
Subject: Re: FPGA tools and Win2000 - problems
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 17 Mar 2002 09:45:24 +0000
Links: << >>  << T >>  << A >>


emanuel stiebler wrote:

> 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 ;-)
>

The problem is that the guy who installs the O/S on our boxes is a firm
believer in the wonders of Windoze and accepts potential nonsense like the
above. I really should have bitten the bullet and installed NTSP6A myself just
to see what happened.

>
> > 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 ?
>

Certainly SP2 and probably SP3. What's the Win2K equivalent of `winvers' ?

>
>
> > 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 ?)
>

Thanks I'll check that out.

>
> 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.

In my case, at home, the rock solid box is a 1995 PI running BSDI 4.2 Unix at
the astounding clock speed of 150MHz with the huge memory size of 64MB. In
terms of the ability to interact i.e. type things in emacs, with some heavy
processes running in the background, it completely blows away the super Wintel
boxes. This also applies when it starts swapping. NT's (and no doubt Win2K's)
performance nosedives dramatically at the slightest hint whereas BSD Unix
degrades fairly gracefully.
I've been told that Linux is pretty poor in this area as well.

Ironically in some ways its a real shame that memory prices got so low -
otherwise the pressure to run memory hungry EDA tools on Unix would have
become irresistable.




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