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 34450

Article: 34450
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 24 Aug 2001 17:58:09 -0700
Links: << >>  << T >>  << A >>

--------------B555A475B383CCA24BB5E365
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark,

(snip)

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

There is no difference.  You may believe what you wish.

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

Don't know.

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

These are special term cells which complete the routing whenever there is a discontinuity in the
fabric.  Has nothing to do with programming, or 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?

Need to check the datasheet.  Packages in Spartan usually have more IO's, and hence fewer
options, and less robust ground bounce, and tighter SSO rules.

> >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 Virtex-5 ) Note correct spelling of Virtex (tm)
>
> >>
> >> 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 ?

I answered this to an internal person, who should never have sent it outside.  They should have
asked Robert and gotten back to you.  I apologize to Robert.  I will ask someone in the Spartan
II program, and get back to you.

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

Maybe for Virtex, Virtex E, but I doubt it for Spartan II.  I'll ask.

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

The BRAM is synchronous, so where does its clock come from?

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

That is handled by opening a webcase over the web.

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

Don't do that!  Why would we want to hire someone who does not honestly represent their views.

Austin

--------------B555A475B383CCA24BB5E365
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Mark,
<p>(snip)
<blockquote TYPE=CITE>&nbsp;
<br>>> 1) Is the access time / CLOCK to DOUT time for the BRAMS faster
when set
<br>>>&nbsp;&nbsp;&nbsp; for a wide data configuration?
<br>>>&nbsp;&nbsp; (ie presumably the output signals can skip 4 levels
of multiplexers)
<br>>
<br>>no clue, but the speeds files would tell you (ie timing report)
<br>>
<br>Yes but only one Tbcko is reported by the software.
<br>I was interested in the timing of the hardware.
<br>I don't believe that there aren't any differences between
<br>either the clock to data for all data lines for all configurations,
<br>or the address to clock setup for all address lines for all configurations.
<br>I could be wrong, should the BRAMS contain a large number of FFs
<br>to synchronise all lines.
<br>The matter might be irrelevant, such as only a few pS difference, which
<br>would get swamped by the net delays.
<br>The net delays might be INERTIAL, in which case the swamping would
be more.</blockquote>

<p><br>There is no difference.&nbsp; You may believe what you wish.
<blockquote TYPE=CITE>>>
<br>>> 2) is the carry out pin of a CLB in a LOW/HIGH/TRI STATE if not
selected to
<br>>>&nbsp;&nbsp;&nbsp; be used in a 1 CLB hard macro?
<br>>
<br>>all logic is on, or off.&nbsp; even the tbufs are not tristate
<br>>
<br>Makes sense, obviously bad for CMOS lines to be floating within high
speed
<br>logic.
<br>So I can initialise a carry chain even when the BX input is being used
for
<br>something else?</blockquote>
Don't know.
<blockquote TYPE=CITE>>>
<br>>> 3) whats the point of the CIN pins in the lowest row of slices?
<br>>>&nbsp;&nbsp;&nbsp; (ie with highest row index)
<br>>
<br>>No idea.&nbsp; I do know that signals that don't go anywhere are tied
off by the
<br>>special term cells that go all around the clb array
<br>>
<br>I never understood about the tie-points for the 4000 series.
<br>Neither did the software.</blockquote>
These are special term cells which complete the routing whenever there
is a discontinuity in the fabric.&nbsp; Has nothing to do with programming,
or the software.
<blockquote TYPE=CITE>>>
<br>>> 4) if the answer to the 3rd question is NONE then you might be amused
<br>>>&nbsp;&nbsp;&nbsp;&nbsp; to try smart-placing (within FPGA_EDITOR)
a hard macro which uses a
<br>>> CIN&nbsp;&nbsp;&nbsp;&nbsp; (seems to like the lowest row for some
reason!)
<br>>
<br>>so what happens?
<br>>
<br>I stopped using "smart-placing".
<br>>
<br>>> 5) The Spartan2 databook is very unclear about IO banks &amp; PQ
packages.
<br>>>&nbsp;&nbsp;&nbsp;&nbsp; Presumably the Vref &amp; Vccio arrangements
are as with the Virtex?
<br>>>&nbsp;&nbsp;&nbsp;&nbsp; (which was at least clearly documented)
<br>>
<br>Sorry , unclear question.&nbsp; What I should have written would be:
<br>I understand that within the Virtex devices there are 8 I/O Banks,
<br>each potentially with their own Vccio &amp; Vref lines.
<br>Within some packages the Vccio lines for different banks are bonded
together .
<br>The exteme case is with the HQ/PQ packages, with just 1 Vccio line,
<br>but still with independent Vrefs.
<br>I guess that the same applies for the Spartan2, but if I hadn't seen
the
<br>Virtex documentation I might not even have made that guess.
<br>Am I correct in assuming independent Vrefs for the Spartan2 PQ
<br>packages?</blockquote>
Need to check the datasheet.&nbsp; Packages in Spartan usually have more
IO's, and hence fewer options, and less robust ground bounce, and tighter
SSO rules.
<blockquote TYPE=CITE>>spartan is always more io bonded out, with fewer
vcc's and gnds.&nbsp; if you want
<br>>performance, then you buy Virtex.&nbsp; If you want low cost, you
buy Spartan II.
<br>>
<p>I want high processing performance and (generally) low I/O data rates.
<br>Hardly any of the OBUFS will be set to FAST, so I won't be ground bouncing.
<br>Spartan2-6 is the most cost effective solution.
<br>(better performance than <font color="#FF0000">Virtex</font>-5 ) <font color="#FF0000">Note
correct spelling of Virtex (tm)</font>
<p>>>
<br>>> 6) Any chance of filling in some of the blank fields for Spartan2
-6
<br>>> timing?
<br>>
<br>>don't know.&nbsp; ask Robert Wells.
<br>>
<br>Who is Robert Wells? is he accessible via robert.wells@xilinx.com ?</blockquote>
I answered this to an internal person, who should never have sent it outside.&nbsp;
They should have asked Robert and gotten back to you.&nbsp; I apologize
to Robert.&nbsp; I will ask someone in the Spartan II program, and get
back to you.
<blockquote TYPE=CITE>>>
<br>>> 7) How about guaranteed best case timings as well ?
<br>>>&nbsp;&nbsp;&nbsp; ( specifically for BRAM access)
<br>>
<br>>some day
<br>>
<br>Sorry It's just that I could have sworn that Xilinx indicated the availability
<br>of this data several months ago.The indication was in tabular form.</blockquote>
Maybe for Virtex, Virtex E, but I doubt it for Spartan II.&nbsp; I'll ask.
<blockquote TYPE=CITE>>>
<br>>> 8) Would it be possible to sacrifice a BRAM&nbsp;&nbsp; &amp; use
a DLL to lock onto the
<br>>> Tbcko , or would the delay of other BRAMS not track? (even though
being
<br>>> guaranteed to have the same Vccint &amp; presumably approximately
the same
<br>>> temperature?) (bearing in mind question 1, I would only be applying
this to
<br>>> identical
<br>>> data width BRAMS)&nbsp; If this approach is possible which data
bit should I route
<br>>> through?
<br>>
<br>>BRAM and DLL are completely different animals, and I doubt they would
track
<br>>with process/voltage/temperature
<br>>
<br>I meant having a clock from the output of a 2xDLL fed by the output
of a BRAM
<br>whose sole duty is to toggle 1 output bit per input clock cycle.
<br>I.e. sanitising a dirty source in a highly controlled manner.
<br>The delay between the two clocks would depend on Tbcko.</blockquote>
The BRAM is synchronous, so where does its clock come from?
<blockquote TYPE=CITE>>
<br>>> 9) Do the industrial versions draw more startup current than the
commercial
<br>>> devices at any given temperature,&nbsp; or is it only at extremely
low
<br>>> temperatures (below the commercial range)&nbsp;&nbsp; that the current
increases?
<br>>
<br>>just below 0C
<p>OK, so this should never be a reason to NOT select an Industrial part..
<p>>
<br>>>
<br>>> 10) Using XST VHDL (SP8, on both WebPACK &amp; ISE3.3i) RLOCS are
lost on
<br>>>all but
<br>>> the first instance of a component containing RLOCS.&nbsp; This is
BAD , especially
<br>>> when Carry logic and / or&nbsp; MUXF5 is involved, because what
creeps into the
<br>>> wrong CLB makes no sense at all (as regards timing/space) .&nbsp;
I originally
<br>>> thought this was a problem with MAP, but then examined the EDN file
&amp;
<br>>>found
<br>>> that MAP hadn't been told to cluster components within a CLB. (for
any except
<br>>> the first instance)
<br>>>&nbsp;&nbsp;&nbsp; "Preserve Heirarchy" had been SET (as a synthesis
option).&nbsp; Presumably the
<br>>>only way around this is to use "Incremental Synthesis"?&nbsp; (Apart
from hacking
<br>>> the edn file to ensure all instances refer to the first cell definition,which
<br>>> does indeed work, but surely can't be considered a standard flow!)
but
<br>>> incremental synthesis doesn't work for any OTHER component!&nbsp;
I haven't tried
<br>>> using the XILFILE attribute which could be a way to enforce the
correct
<br>>> hierarchy.
<br>>
<br>>This is a software question, right?&nbsp; I don't do software.
<br>>
<br>Sorry. I thought it was a bug report !</blockquote>
That is handled by opening a webcase over the web.
<blockquote TYPE=CITE>>>
<br>>> 11)The P&amp;R tools seem to consider (single port) RAM address
lines to be
<br>>>&nbsp;&nbsp;&nbsp; unswappable.&nbsp;&nbsp;&nbsp; Is there any way
around this, because almost invariably I
<br>>> find that
<br>>>&nbsp; swapping&nbsp; (ie deleting net pins&nbsp; then adding net
pins)&nbsp;&nbsp; the two highest
<br>>> net delay address inputs improves the timing on BOTHlines.
<br>>
<br>>There may be a dedicated route reason why this isn't allowed.&nbsp;
I just don't
<br>>know.
<br>>
<br>It is allowed, but the tools don't do it themselves.
<br>I'll try pretending&nbsp; to MAP that the RAMs are LUTs, then patch
the
<br>file after it has been routed.
<br>The P&amp;R is very good about swapping LUT inputs to improve timing.
<br>The difficulty will be in ensuring all placement info gets through
the tool
<br>chain.
<br>I'd pity someone targeting the xc2v10000 &amp; using XDL.
<p>>>
<br>>> 12) Any chance of a job at Xilinx? (I can write tools. I can design
hardware.
<br>>> I like Xilinx hardware.)&nbsp; I'm afraid that jobs locally to me
are of the sort
<br>>> "You've got to use ACTEL" (probably something to do with the name
of their
<br>>> main product line.)&nbsp; or "You've got to use Virtex" ( note not
Virtex-E,
<br>>> Spartan2 or Virtex2 but&nbsp; Virtex).&nbsp; or "You've got to use
ALTERA" or "You've
<br>>> got to have marketing experience". I can supply the names of the
guilty
<br>>> parties, but I don't think that would help.
<br>>
<br>>There is always a chance.&nbsp; Got a resume?&nbsp; I can't say that
it is a good chance,
<br>>or if it is a bad chance, but there is a chance, yes.
<br>>
<br>Ok, I'll just delete the section in which I indicate my bitterness
as regards
<br>some versions of Xilinx software!
<br>&nbsp;</blockquote>
Don't do that!&nbsp; Why would we want to hire someone who does not honestly
represent their views.
<p>Austin</html>

--------------B555A475B383CCA24BB5E365--


Article: 34451
Subject: Re: Slowing PCI for FPGA
From: Phil Hays <spampostmaster@home.com>
Date: Sat, 25 Aug 2001 03:31:21 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

PH> I've done schematics with floorplanning.  I know better than absolutely no
PH> 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.)?

Unless "etc." includes some fairly unusual items, like a writeback cache, some
interesting coders and decoders and such, I don't see how I could, even if I was
still using schematics.  I have not designed with schematics for years, for the
basic reason that schematics take too much effort for more than a small design. 
Most of the designs I've done have had substantial sections that were unique, in
the sense they were very different than anything I've done before or since.


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

That's correct, for I don't think such things can be proven.  Do you?


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

People tend to assume that their experience is typical.  Perhaps we are both
falling for that trap, eh?


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

The ASIC world mostly changed over to HDL's quite a while ago.  If there was
advantage to switching back, couldn't a schematic vendor make a lot of money by
promoting the reverse switch?  Why would they fail to try for that money?


-- 
Phil Hays

Article: 34452
Subject: Re: PCI Postcode Display
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 24 Aug 2001 21:12:07 -0700
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@darkroo87m.com> wrote in message news:<9lplfe$fu2$1@slb4.atl.mindspring.net>...
> > So, if you have an ISA card (legacy or PnP), and want to convert it to
> > a PCI card, and assuming that the card doesn't use the I/O or memory
> > address IBM defined, then it seems to me that you should implement
> > Configuration Address Space (and implement Base Address Register
> > inside the Configuration Address Space), so that BIOS or Windows can
> > assign I/O or memory address automatically.
> 
> My understanding was he was using dedicated addresses, and as such, can't
> let the BIOS or Windows assign them.  I do believe there are PCI boards that
> hardcode the addresses...
> 

        Sure, there are some PCI boards that hardwire the decode
addresses, but again, according to Appendix G of PCI Local Bus
Specification Revision 2.2 states that only legacy devices (i.e., VGA,
IDE) can do that.
Actually, the legacy devices like VGA or IDE, and has a class code
that indicates such a device.
So, if you are not VGA, IDE, or other legacy devices that indicates a
legacy class code, you should not hardcode addresses, and if you do
so, you are violating the specification.



> > Since you are using interrupt, that makes it a requirement to
> > implement Configuration Address Space because interrupt handlers of
> > PCI devices use Configuration Register 3CH (Interrupt Line) and 3DH
> > (Interrupt Pin).
> 
> Not really in PC based PCI implementations.  They only use INTA.  I believe
> there used to be a caveat about that in the spec.


        I will assume that you have never read the PCI specification.
From my understanding of the PCI specification reading the PCI Local
Bus Specification Revision 2.2 is that a PCI device that uses
interrupt uses Configuration Register 3CH (Interrupt Line) and 3DH
(Interrupt Pin).
Although I have never dealt with PCI's interrupt, Configuration
Register 3CH (Interrupt Line) sounds important since that tells the
device driver which IRQ the interrupt is connected to.
In PCI based IBM-PC/AT clones, the device driver has to know the IRQ
number, so that the device driver can send the EOI (End Of Interrupt)
command to the correct 8259A compatible programmable interrupt
controller (to the master only, or to the slave and master depending
on which INTx# gets assigned to which IRQx).
The PCI specification doesn't mention explicitly how to deal with the
8259A programmable interrupt controller, but since the interrupt
controller is 8259A compatible (with some extensions), I think even
the device driver for PCI devices have to send the EOI command.



> 
> > You will likely have to rewrite your device driver to accommodate the
> > I/O or memory address that can get assigned to any location, and also
> > IRQ can get assigned to any IRQ (Configuration Register 3CH will hold
> > the IRQ number assign by BIOS or Windows).
> 
> If the BIOS allows you to set the interrupt from each PCI slot to a
> particular INT, then that is not true.
> 
> I believe he can do exactly what he wants, if he can find a BIOS that allows
> setting the INT.


        Sure, in some BIOSes, the BIOS may let you do that.
But the motherboards I use automatically assigns the IRQ to the PCI
devices.
So, the person who asked this question must accommodate that if he
plans to sell the card he is talking about, so that it will work with
any PCI based IBM-PC/AT clones.
I suppose that if he is building such a card for personal use, I guess
it won't matter that much assuming that he can find such BIOS, but it
is definitely not desirable.
I do realize that the person who asked this question doesn't have
access to the source code of the device driver, but if that is the
case, I suppose he will have to write his own (I realize that that's
not easy).




Regards,



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

Article: 34453
Subject: Re: PCI Postcode Display
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 24 Aug 2001 22:06:52 -0700
Links: << >>  << T >>  << A >>
kevinbraceusenet@hotmail.com (Kevin Brace) writes:
>         Sure, there are some PCI boards that hardwire the decode
> addresses, but again, according to Appendix G of PCI Local Bus
> Specification Revision 2.2 states that only legacy devices (i.e., VGA,
> IDE) can do that.
> Actually, the legacy devices like VGA or IDE, and has a class code
> that indicates such a device.
> So, if you are not VGA, IDE, or other legacy devices that indicates a
> legacy class code, you should not hardcode addresses, and if you do
> so, you are violating the specification.

What's wrong with making the PCI POST code display a legacy device, and
using the appropriate legacy device class code?  The use of port 80
for a POST code has a longer legacy than either VGA or IDE.  VGA wasn't
introduced until 1987; I don't recall when IDE was introduced.



Article: 34454
(removed)


Article: 34455
Subject: Re: DRAM burst mode
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Sat, 25 Aug 2001 16:25:17 +0100
Links: << >>  << T >>  << A >>
Hi Rick,

I already have control of the dram so know the refresh is ok but will
probably modify the code for future design checking.
What I found in the verilog code confirmed what I thought, I am already
using the burst mode but for a single "word".
Now all I have to do is change the mode register to give the required burst
length (which is all I really need).

Thanks again
Dave


"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3B86ECD3.CD797820@algor.co.uk...
>
>
> 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: 34456
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@dark55room.com>
Date: Sat, 25 Aug 2001 13:43:49 -0400
Links: << >>  << T >>  << A >>
"Phil Hays" <spampostmaster@home.com> wrote in message
news:3B871C38.9295BFA2@home.com...
> Austin Franklin wrote:
>
> PH> I've done schematics with floorplanning.  I know better than
absolutely no
> PH> 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.)?
>
> Unless "etc." includes some fairly unusual items, like a writeback cache,
some
> interesting coders and decoders and such, I don't see how I could, even if
I was
> still using schematics.  I have not designed with schematics for years,
for the
> basic reason that schematics take too much effort for more than a small
design.

I believe you were not using schematics correctly if you were not able to do
anything but a small design.  Some of the largest/fastest/densist chips in
the world, that I know of, are done with schematics.  Even our beloved FPGAs
are designed with schematics (oh the horror!)!  The Xilinx PCI core is done
in Viewdraw schematics.

Personally, I find reading through a bunch of text quite tedious and time
consuming.  Most everyone I know, when they first get a block of HDL code in
front of them, that they have not seen, draw a block diagram.  Why bother if
the function of the HDL is so obvious and clear to understand?

I believe people just don't know how to use schematics correctly.  It's that
simple.  There never were any substantial libraries available from any major
vendor, and I certainly wasn't going to just give away my years and years of
libraries to anyone.  They couldn't be protected, so anyone could just copy
them.  I worked with Viewlogic and other vendors for years trying to get
this concept into their heads, but they, from a business standpoint,
couldn't figure out how to make any money with it to pay for the
development.

> Most of the designs I've done have had substantial sections that were
unique, in
> the sense they were very different than anything I've done before or
since.
>
>
> > > Yet the majority of designs are done in HDL for
> > > good reasons:  less effort, better results.
> >
> > You have no proof of this.
>
> That's correct, for I don't think such things can be proven.  Do you?

Then why did you make a claim that you know isn't true?  I've done a number
of designs in both, and schematics win hands down to finished product every
time, except for the simplest/slowest designs.  There can be way too much
fussing with timing and tools etc. with synthesis.  When synthesis works, it
works, and that's nice...but there is no guarantee that it will, and if it
doesn't, the amount of time it takes to get it to work can be exponential,
or even complete failure.

> > 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.
>
> People tend to assume that their experience is typical.  Perhaps we are
both
> falling for that trap, eh?

I know my experience isn't typical...but having dozens of clients, I would
like to believe I have a very good cross section of their experience.

> > 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.
>
> The ASIC world mostly changed over to HDL's quite a while ago.

Hum.  Well, as I said above, most of the fastest/densist/largest designs I
am aware of, are done in schematics.  Synthesis is like C is for the X86
architecture...(though C compilers have become very very good these days),
simply because the X86 has SO much memory, and runs SO fast these days, a
programmer can code the worst most inefficient code they can, and it will
probably "work".  We are moving away from real engineering to the million
monkey theory...  Now, this doesn't mean that there aren't some exceptional
C programmers, or HDL coders out there, on the contrary.  A tool is only as
good as its operator.

>  If there was
> advantage to switching back, couldn't a schematic vendor make a lot of
money by
> promoting the reverse switch?  Why would they fail to try for that money?

Not really.  Schematic packages don't sell for near what synthesis packages
"sell" for.  Most people who have synthesis also have board schematic
packages anyway.

Unfortunately, perception is perceived as everything...whether the
perception is based on reality or truth...or not.





Article: 34457
Subject: Re: Latest Maxim bit serializer-deserializer chip announcements
From: John Larkin <jjlarkin@highlandSNIPTHIStechnology.com>
Date: Sat, 25 Aug 2001 11:33:04 -0700
Links: << >>  << T >>  << A >>
On Fri, 24 Aug 2001 04:50:01 GMT, "Dave Feustel" <dfeustel1@home.com>
wrote:

>Why is this spam?
>

Because it's not about FPGAs and because it's nothing but a commercial
product announcement. If everybody trying to sell chips posted in all
the technology ng's, the groups would be nothing but spam and would
serve nobody.


>What's the story with the Max9690?

Well, Maxim used to make a great ECL comparator... when they felt like
it. They would occasionally lose the recipe and stop production
without warning. Once they made my company sign a waiver of liability
against device bugs before they would allow us to buy more chips - we
were nearly out of business at that point, since promised parts had
not been shipped for six months - but refused to tell us what the bugs
*were*.

They did say that the part was being produced in the millions and was
likely to be available in the long term. 

Then they discontinued the part without warning or provisions for eol
buys. The end-of-life notice was simply that back-ordered parts didn't
arrive. They told my purchasing people that it was replaced with the
'drop-in equivalent' MAX9691, which it certainly isn't; the 9691 won't
work in most of our locations.

I like Maxim and their stuff in general, but they were irresponsible
stonewallers on this one. 

The lawyers should diversify from kids' toys and tires, and go after
the semi people next.

John



Article: 34458
Subject: Re: Slowing PCI for FPGA
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Sat, 25 Aug 2001 19:41:22 -0600
Links: << >>  << T >>  << A >>
Phil Hays wrote:
> 
> This is a reasonable analogy, thanks for bringing it up.  "C", FORTRAN  and
> other "higher level languages" allow people with no detailed understanding of a
> computer to write very complex programs.  The compilers are very good, and while
> an experienced assembly code programmer can probably do slightly better than a
> good higher level programmer, unless the program is not complex and/or needs to
> fit into a tiny space and/or is very speed critical, the program will probably
> be best written in a higher level language for maintainability, for portability
> and for minimum cost.  A monkey will produce a result that may work, but there
> is no guarantee that it will, and if it doesn't, the amount of time it takes to
> get it to work can be exponential, or even complete failure.  Regardless of the
> method chosen.

Generally a program is developed to work with say 95% of the features the
clients
want. Portability and documentation are less important. I see schematics more
like
assembler programs. They work faster but only if you know the hardware. HDL's
tend
to be too abstract from real hardware as to be efficient from my very limited
study.
I don't see HDL's as portable as they claim as FPGA's are all different. Unless
you
stick to Flip/Flops and simple gates with 4 inputs or less things will not be
portable.
Ben.
PS.TTL had one advantage ,you changed suppliers your design still worked.

-- 
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.

Article: 34459
Subject: Re: Slowing PCI for FPGA
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sun, 26 Aug 2001 11:52:06 +1000
Links: << >>  << T >>  << A >>
How do you do compicated state machines with schematics? The circuit
would look quite messy and non-intuitive wouldn't it?

Austin Franklin wrote:
> 
> I believe you were not using schematics correctly if you were not able to do
> anything but a small design.  Some of the largest/fastest/densist chips in
> the world, that I know of, are done with schematics.  Even our beloved FPGAs
> are designed with schematics (oh the horror!)!  The Xilinx PCI core is done
> in Viewdraw schematics.
> 
> Personally, I find reading through a bunch of text quite tedious and time
> consuming.  Most everyone I know, when they first get a block of HDL code in
> front of them, that they have not seen, draw a block diagram.  Why bother if
> the function of the HDL is so obvious and clear to understand?
> 
> I believe people just don't know how to use schematics correctly.  It's that
> simple.  There never were any substantial libraries available from any major
> vendor, and I certainly wasn't going to just give away my years and years of
> libraries to anyone.  They couldn't be protected, so anyone could just copy
> them.  I worked with Viewlogic and other vendors for years trying to get
> this concept into their heads, but they, from a business standpoint,
> couldn't figure out how to make any money with it to pay for the
> development.
> 

--
   ___                                           ___
  /  /\                                         /  /\
 /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
/__/   / Victoria, Australia, Down-Under      /__/\/\/
\  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
 \__\/                                         \__\/

Article: 34460
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@dark55room.com>
Date: Sat, 25 Aug 2001 23:41:53 -0400
Links: << >>  << T >>  << A >>

"Russell Shaw" <rjshaw@iprimus.com.au> wrote in message
news:3B885646.18829572@iprimus.com.au...
> How do you do compicated state machines with schematics? The circuit
> would look quite messy and non-intuitive wouldn't it?

Sometimes I have to do the state machines in schematics, because they don't
make timing in synthesis.  Sometimes, the state machines make timing in
synthesis, so I leave them in synthesis.  It really isn't that hard to do
state machines in schematics if you draw then well, and document them well
right on the schematic.

There was a little company, called "Fliptonics", I believe, that had a very
nice schematic based state machine library...  Perhaps Philip knows
something about that company, and this purported state machine library ;-)




Article: 34461
Subject: Re: Slowing PCI for FPGA
From: Phil Hays <spampostmaster@home.com>
Date: Sun, 26 Aug 2001 04:31:27 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

PH> I have not designed with schematics for years, for the basic reason 
PH> that schematics take too much effort for more than a small design.

> I believe you were not using schematics correctly if you were not able to do
> anything but a small design.

Small in complexity would have been more accurate.  A RAM or a FPGA has lots of
transistors and connections, but not much complexity.  A design with lots of
gates and little complexity is one design where schematics can do well.  Another
good place for schematics is a design on which lots of effort can be expended
for marginal improvements, such as a large volume CPU, which has both lots of
gates and lots of complexity.  Major CPU design teams are hundreds of designers,
some of which may work for a year to slightly optimize a few hundred
transistors.


> > > > Yet the majority of designs are done in HDL for
> > > > good reasons:  less effort, better results.
> > >
> > > You have no proof of this.
> >
> > That's correct, for I don't think such things can be proven.  Do you?
> 
> Then why did you make a claim that you know isn't true?

As Godel showed, propositions can be both true and unprovable.

http://www.earlham.edu/~peters/courses/logsys/g-proof.htm


To prove that "schematics (or HDL) are usually better" would require that all
(or all useful) designs be formally identified, and a majority defined that is
better in schematics (or HDL).  Sorry, but I doubt if the class of designs or of
useful designs can be established in any reasonable fashion.  I don't care to
attempt to prove this statement: but do be my guest.  Yet it is true, at least
for designs that are both complex and need to run reasonably fast.  Write and
simulate the HDL first, then spend the effort on speeding up the critical paths
to the needed speed.  If you have done a reasonable job of the first, the second
isn't that hard, and may not be needed.


> I've done a number of designs in both, and schematics win hands down to 
> finished product every time, except for the simplest/slowest designs.

Back when synthesis got started, designers were drawing transistors on
schematics and wanted a faster way to an acceptable answer.  Sure, by
calculations and experience the human designer can produce a nearly optimal
design for a bit of logic (say for the carry bit of an ALU, perhaps some 20 or
30 transistors, using many hours of human designer time: but a simple synthesis
tool can do nearly as well in seconds.  By freeing the designer from the tiny
details of transistors and gates, much more complex designs could be completed.


> There can be way too much
> fussing with timing and tools etc. with synthesis.  When synthesis works, it
> works, and that's nice...but there is no guarantee that it will, and if it
> doesn't, the amount of time it takes to get it to work can be exponential,
> or even complete failure.

When I write code I know fairly closely what the synthesis tool is going to
produce, and how fast it will run.  This takes experience, but so does "proper
use of schematics", correct?  And yes, I'm sure that an inexperienced HDL
designer can waste a lot of time fussing with timing and tools and such.  I
don't.  I know that an inexperienced schematic designer can waste a lot of time
fussing with timing and tools and such.  I did that a decade ago.

 
> Synthesis is like C is for the X86
> architecture...(though C compilers have become very very good these days),
> simply because the X86 has SO much memory, and runs SO fast these days, a
> programmer can code the worst most inefficient code they can, and it will
> probably "work".  We are moving away from real engineering to the million
> monkey theory...  Now, this doesn't mean that there aren't some exceptional
> C programmers, or HDL coders out there, on the contrary.  A tool is only as
> good as its operator.

This is a reasonable analogy, thanks for bringing it up.  "C", FORTRAN  and
other "higher level languages" allow people with no detailed understanding of a
computer to write very complex programs.  The compilers are very good, and while
an experienced assembly code programmer can probably do slightly better than a
good higher level programmer, unless the program is not complex and/or needs to
fit into a tiny space and/or is very speed critical, the program will probably
be best written in a higher level language for maintainability, for portability
and for minimum cost.  A monkey will produce a result that may work, but there
is no guarantee that it will, and if it doesn't, the amount of time it takes to
get it to work can be exponential, or even complete failure.  Regardless of the
method chosen.


-- 
Phil Hays

Article: 34462
Subject: Re: Can't Install Modelsim - Alternatives for Verilog Simulation???
From: hamish@cloud.net.au
Date: Sun, 26 Aug 2001 05:22:37 GMT
Links: << >>  << T >>  << A >>
In comp.arch.fpga Dave Feustel <dfeustel1@home.com> wrote:
> I also am getting interested in working with Icarus although that is
> possibly complicated by my running Windows. I'd rather have a version
> I can compile with Visual Studio 6 (either as a project or with a make
> file) and run Icarus natively on Windows  than use Cygwin (which I
> have tried) although running Icarus in a  Linux box under VMWare is possible.

You shouldn't have to run Icarus from within the Cygwin shell;
it's just compiled and linked with Cygwin.

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

Article: 34463
Subject: Re: Can't Install Modelsim - Alternatives for Verilog Simulation???
From: Stephen Williams <steve@icarus.com>
Date: 26 Aug 2001 05:45:18 GMT
Links: << >>  << T >>  << A >>
> You shouldn't have to run Icarus from within the Cygwin shell;
> it's just compiled and linked with Cygwin.

It's not even compiled/linked with Cygwin. Cygwin is not needed at all
to run Icarus Verilog: you need Cygwin at compile time but only for all
the tools around the compiler, and not the C++ compiler itself.

The magic here is the mingw compiler, a gcc port for native Windows,
that is used to compile Icarus Verilog binaries. The sanctioned build
process uses the Cygwin shell to gain access to things like bison, flex,
bash, gperf, et al, but the resulting binary is native Windows and does
not require any special tricks or packages/dlls to run. It is as
native as a VC6 compiled binary.

(I went through some pains to make sure that Icarus Verilog can be
compiled *native* on most any platform with only free tools. It's a
matter of pride, by now.)

The mingw.txt file included in the iverilog-0.5.tar.gz tarball has
step-by-step instructions for compiling Icarus Verilog in this fashion.
The only obvious problem with that is that you need tar and gzip to
extract said bundle:-P Perhaps I should write some starter tips into
the FAQ.

Hamish, as the Debian porter, can be forgiven for not knowing this
little detail:-)
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Article: 34464
(removed)


Article: 34465
Subject: Help needed: simulation OK, synthesis OK, but doesnt work :-<
From: "Fred" <doesnt@like.spam>
Date: 26 Aug 2001 18:20:36 GMT
Links: << >>  << T >>  << A >>
Hello,

Just to get familiar with the basics of verilog and all that I tried to make
a 16 bit shift register, and show the contents on a led display.

In simulation it does all it's supposed to do. I do my simulations with
Icarus Verilog 0.5 (g++-3.0). Now when I compile it to the target hardware,
still everything is tip-top.  As hardware I'm using a Post-It board, which
has an Altera EPM3128ATC100-7 on it. [http://www.cmosexod.com/board.htm]
For synthesis I use Max+plusII version 10.0 9/14/2000 (2000.09) from Altera.
It even programs OK. So what's the problem I hear you say?

As inputs I have async_ser_clk and async_ser_clk, which change out of sync
with the system clock of the CPLD. So on the posedge of the system clock I
latch those to two registers to synchronize them. For debugging purposes I
also latch them into two of the four led displays. On the negedge of the
system clock I then check if the synchronized ser_clock has gone from low to
high, and if so, shift the register.

Now the problem is this:
It does seem to synchronize the ser_clock, and does _something_ on the low to
high transition. Only that something should be shift the register, like this:
(See also the appended source-code)
                led_1[7] <= led_1[6];
                led_1[6] <= led_1[5];
...
                led_0[1] <= led_0[0];
                led_0[0] <= ser_dat;

What it seems to do instead is:
                led_1[7] <= ser_dat;
                led_1[6] <= ser_dat;
...
                led_0[1] <= ser_dat;
                led_0[0] <= ser_dat;

It doesn't shift, it changes _ALL_ 16 bits of the 'shift'-register to either
1 or 0, the value of ser_dat. Oh, and before I forget, I don't think it's a
timing problem, since for debugging I use a system clock of 200 Hz, and
change the async_ser_clk and async_ser_dat on the touch of a button (== as
slow as I want). So did I make a stoopid mistake somewhere, and should it
compile to this, or is something else going on?

any help appreciated,
Fred

---

/*
 * shift_leds.v - shift register with led display
 * 
 */
`timescale 1ns / 100ps

module shift_leds(sys_clk, sys_rst_l, async_ser_clk, async_ser_dat, led_3, led_2, led_1, led_0);
    input sys_clk;
    input sys_rst_l;
    input async_ser_clk; // serial clock (has to be resynced)
    input async_ser_dat; // serial data (has to be resynced)
    output [7:0] led_3;
    output [7:0] led_2;
    output [7:0] led_1;
    output [7:0] led_0;

    wire sys_clk;
    wire sys_rst_l;
    wire async_ser_clk;
    wire async_ser_dat;
    reg [7:0] led_3; // Left led
    reg [7:0] led_2;
    reg [7:0] led_1;
    reg [7:0] led_0; // Right led

    reg ser_clk, ser_dat, last_ser_clk;

    always @(sys_clk) begin
        if (sys_clk) begin
            // @(posedge sys_clk) --> synchronize ser_clk and ser_dat
	    last_ser_clk <= ser_clk;
	    ser_clk <= async_ser_clk;
	    ser_dat <= async_ser_dat;
	end else begin
	    // @(negedge sys_clk) --> use synchronized ser_clk and ser_dat
            led_3[7] <= ser_clk;
            led_3[6] <= ser_clk;
            led_3[5] <= ser_clk;
            led_3[4] <= ser_clk;
            led_3[3] <= ser_clk;
            led_3[2] <= ser_clk;
            led_3[1] <= ser_clk;
            led_3[0] <= ser_clk;

            led_2[7] <= ser_dat;
            led_2[6] <= ser_dat;
            led_2[5] <= ser_dat;
            led_2[4] <= ser_dat;
            led_2[3] <= ser_dat;
            led_2[2] <= ser_dat;
            led_2[1] <= ser_dat;
            led_2[0] <= ser_dat;
	   
	    if ((~last_ser_clk) && (ser_clk)) begin
                // @(posedge synchronized ser_clk)
	        // shift ser_dat through
                // led_1 <-- led_0 <-- ser_dat
                led_1[7] <= led_1[6];
                led_1[6] <= led_1[5];
                led_1[5] <= led_1[4];
                led_1[4] <= led_1[3];
                led_1[3] <= led_1[2];
                led_1[2] <= led_1[1];
                led_1[1] <= led_1[0];
                led_1[0] <= led_0[7];

                led_0[7] <= led_0[6];
                led_0[6] <= led_0[5];
                led_0[5] <= led_0[4];
                led_0[4] <= led_0[3];
                led_0[3] <= led_0[2];
                led_0[2] <= led_0[1];
                led_0[1] <= led_0[0];
                led_0[0] <= ser_dat;
	    end // @(posedge synchronized ser_clk)
	end
    end // always @ (sys_clk)
endmodule // shift_leds


/*
 * main.v - testbench for shift_leds.v
 *
 */
`timescale 1ns / 100ps

module main;
    parameter ALTERA_HALF_T=5; // T=2*5ns=10ns --> 100 MHz
    parameter AVR_HALF_T=53; // T=2*53ns=106ns -->  9.43MHz
   
    // simulate 2 ports on the AVR acting as serial bus
    reg ser_clk;
    reg ser_dat;

    // use leds on post-it as outputs
    wire [7:0] led_3;
    wire [7:0] led_2;
    wire [7:0] led_1;
    wire [7:0] led_0;

    // system clock and reset button
    reg sys_clk;
    reg sys_rst_l=1;  // Button not pressed

    // simulation helper variables
    reg [31:0] value;
    integer i, j;

    // instantiate modules
    shift_leds my_shift_leds(sys_clk, sys_rst_l, ser_clk, ser_dat,
			     led_3, led_2, led_1, led_0);

    initial begin
        $dumpfile("shift_leds.vcd");
        $dumpvars(0, main);

        // AVR sending 32 bits over serial bus
        value=32'h76543210; // value to write to shift register

        for (i=0; i<32; i=i+1) begin
            ser_clk = 0;
	    ser_dat = value[31-i]; // shift MSB first
	    #AVR_HALF_T;
            ser_clk = 1;
	    #AVR_HALF_T;
        end
    end

    // generate system clock for Altera
    initial begin
        for (j=0; j<((32*AVR_HALF_T)/ALTERA_HALF_T)+2; j=j+1) begin
            sys_clk = 0;
	    #ALTERA_HALF_T;
            sys_clk = 1;
	    #ALTERA_HALF_T;
        end
    end
endmodule // main

Article: 34466
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Sun, 26 Aug 2001 21:08:35 GMT
Links: << >>  << T >>  << A >>
On Fri, 24 Aug 2001 17:58:09 -0700, Austin Lesea <austin.lesea@xilinx.com>
wrote:

>
>--------------B555A475B383CCA24BB5E365
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Mark,
>
>(snip)
>
>>
>> >> 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.
>
>There is no difference.  You may believe what you wish.

So is there zero skew on the Data out lines ?
Or is the skew the difference between Tbcko max & min  (1.25ns approx) ?
Or do we use a margin such as 10% of Tbcko max          (0.33ns) ?

>
>> >>
>> >> 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?
>
>Don't know.

>
>> >>
>> >> 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.
>
>These are special term cells which complete the routing whenever there is a discontinuity in the
>fabric.  Has nothing to do with programming, or the software.

Yes, but I didn't understand why these couldn't be combinational functions
embedded into the routing (or the pin lines), rather than strange fixed points
that were supposed to be routed to.

The problem with the M1 software for the 4000 series was that the Tying module
would refuse to run with a design that had an irrelevant DRC error.
(such DRC errors would pop up when I absorbed an invertor into the H-LUT of
a CLB containing a RAM. The H-LUT would normally contain just a MUX,
and the DRC would consider anything else but this to be very bad.
This wouldn't have been any problem, but some of the RAMS I was using
only needed 3 address lines. The spare line was connected to GND or VCC
(doesn't matter which.) 
The routing was incomplete (just for these spare lines)... so they needed to be
tied. So I requested Xilinx uk tech support to reduce the DRC to a mild
warning, but they weren't interested. (This was several years ago..)

There weren't any such problems with the Xact6 software,
but the Xact6 didn't support the 4000EX & 4000XL devices.
 


>
>> >>
>> >> 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?
>
>Need to check the datasheet.  Packages in Spartan usually have more IO's, and hence fewer
>options, and less robust ground bounce, and tighter SSO rules.
>
>> >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 Virtex-5 ) Note correct spelling of Virtex (tm)
Sorry! 
(Even worse .. I've made a grammatical error elsewhere. Too much Startrek!)
>
>> >>
>> >> 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 ?
>
>I answered this to an internal person, who should never have sent it outside.  They should have
>asked Robert and gotten back to you.  I apologize to Robert.  I will ask someone in the Spartan
>II program, and get back to you.
Don't worry, the speedprint software DOES provide min & max timings.
>
>> >>
>> >> 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.
>
>Maybe for Virtex, Virtex E, but I doubt it for Spartan II.  I'll ask.
>
Don't worry, the speedprint software DOES provide min & max timings.
I was obviously not the only one who didn't immediately notice it lurking in
bin\nt.

>> >>
>> >> 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.
>
>The BRAM is synchronous, so where does its clock come from?
Any clean source, most probably from another DLL, but perhaps from
a small Virtex II device ( 1 per 4 Spartan II devices for economic reasons).
The Virtex II DCMs look very useful, as do their multipliers, as do their I/O
standards. (shame they cost more than the Spartan II )

>
>> >
>> >> 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 !
>
>That is handled by opening a webcase over the web.
Ok.
>
>> >>
>> >> 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.
>> >
>> >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!
>>
>
>Don't do that!  Why would we want to hire someone who does not honestly represent their views.
>
>Austin
>


Article: 34467
Subject: Some questions about Spartan2 (& a bug report for XST sp8)
From: 101551.3434@compuserve.com (Mark Taylor)
Date: Sun, 26 Aug 2001 21:10:13 GMT
Links: << >>  << T >>  << A >>
This was an email sent to Peter.Alfke@Xilinx.com....

Dear Sir,
	I am sending you (as the sane technical voice of Xilinx) a few
questions
 and one bug report.
 I approve in advance should you wish to post any part of this or subsequent
emails
onto the comp.arch.fpga newsgroup to assist others.

Questions mainly about Spartan2...

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)
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?
3) whats the point of the CIN pins in the lowest row of slices?
   (ie with highest row index)
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!)

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)

6) Any chance of filling in some of the blank fields for Spartan2 -6
timing?

7) How about guaranteed best case timings as well ?
   ( specifically for BRAM access)

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? 

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?

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.

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.

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.
   
Respectfully yours,
	Mark Taylor
Mark_Taylor_Chess@compuserve.com
101551.3434@compuserve.com


  
       

Article: 34468
Subject: Re: Help needed: simulation OK, synthesis OK, but doesnt work :-<
From: skitz_000@hotmail.com (skitz)
Date: 26 Aug 2001 16:28:40 -0700
Links: << >>  << T >>  << A >>
it looks like what you wrote was an asynchronous shift register, and i
am still not sure if it is shifting. anyways, since you are practicing
your verilog and/or learning the language, then i suggest it is
probably easier to start of with a synchronous shift register. in
verilog, it would usually look something like this:

module SerIn_ParallelOut_ShiftReg( 
	CLK,
  	DIN,
   	DOUT,
  	);
 		 	  
	input CLK;
  	input DIN;  
	
  	output [3:0] DOUT; 
	
  	reg [3:0] DOUT;
 	reg [3:0] REG;

always @(posedge CLK) 
    begin
  	REG  <= {REG[2:0], DIN};
	DOUT <= REG;
    end
endmodule

in the module, the bottom 3 bits of REG get moved up one bit place and
the last spot (bit 0) gets filled with DIN.
anyways, this is just an example and i recommend that whatever you do,
try and stay synchronous as much as possible. it looks like you are
playing asynchronous games, and also, you are playing games with the
clock which is always pretty scary to do.
skitz

Article: 34469
Subject: PCI-X based hosts, availability?
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 27 Aug 2001 08:07:27 +0200
Links: << >>  << T >>  << A >>

I'm looking for available PCI-X systems to be used for testing a
prototype adapter card. I know about the Compaq Proliant servers, but
they are quite expensive. ServerWorks makes a chipset called "Grand
Champion" (if memory serves me correctly). Are there any motherboards
based on the Grand Challenge available yet?

TIA

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 34470
Subject: System Requirements
From: "H.L" <alphaboran@yahoo.com>
Date: Mon, 27 Aug 2001 11:15:44 +0300
Links: << >>  << T >>  << A >>
Hello all,
I am going to program a Xilinx FPGA for the first time. I wanna setup the
synthesis tools on a pc, what must be the system's requirements for proper
(and relatively fast) function?
Thanks



Article: 34471
Subject: Polyphase adjustment to keep it working
From: dottavio@ised.it (Antonio)
Date: 27 Aug 2001 01:50:57 -0700
Links: << >>  << T >>  << A >>
Good Morning,
I've used Matlab and it's function RCOSINE to design a SRRC filter
interpolating 6 and having a roll-off of 0.35, it automatically choose
to implement it in a 37 tap filter, so in the implementation I've
arranged 6 fir, the first with 7 taps and the other five with 6 taps,
with the coefficient distribuited in the classical way of the
polyphase filter, the first on the first filter, the second on the
second filter and so on, the problem is that in this way it doesn't
work cause to maintain the vhdl synchronism between the values
produced by the FIRs they had to have the same length so I rearrange
to have all filter with 7 taps and the last 5 FIR have the last
coefficient value = 0, in this way it works perfectly, so my question,
is why matlab produce a 37 value rcosine filter and how I can
rearrange to impose a 42 tap filter

thanks ...


                                   Antonio

Article: 34472
Subject: Re: Slowing PCI for FPGA
From: "Austin Franklin" <austin@dark55room.com>
Date: Mon, 27 Aug 2001 08:17:48 -0400
Links: << >>  << T >>  << A >>
> > > > > Yet the majority of designs are done in HDL for
> > > > > good reasons:  less effort, better results.
> > > >
> > > > You have no proof of this.
> > >
> > > That's correct, for I don't think such things can be proven.  Do you?
> >
> > Then why did you make a claim that you know isn't true?
>
> As Godel showed, propositions can be both true and unprovable.

Well, then I clam that schematics are less effort and give better results.

> > I've done a number of designs in both, and schematics win hands down to
> > finished product every time, except for the simplest/slowest designs.
>
> Back when synthesis got started, designers were drawing transistors on
> schematics and wanted a faster way to an acceptable answer.  Sure, by
> calculations and experience the human designer can produce a nearly
optimal
> design for a bit of logic (say for the carry bit of an ALU, perhaps some
20 or
> 30 transistors, using many hours of human designer time: but a simple
synthesis
> tool can do nearly as well in seconds.  By freeing the designer from the
tiny
> details of transistors and gates, much more complex designs could be
completed.

I don't get your point.  There is no need to draw gates with schematics, any
more so that you do with HDLs.

> > There can be way too much
> > fussing with timing and tools etc. with synthesis.  When synthesis
works, it
> > works, and that's nice...but there is no guarantee that it will, and if
it
> > doesn't, the amount of time it takes to get it to work can be
exponential,
> > or even complete failure.
>
> When I write code I know fairly closely what the synthesis tool is going
to
> produce,

You DO?  How do you know that?  Do you look at the gates that the synthesis
tool generates?  I'm skeptical...

> and how fast it will run.  This takes experience,

More than experience.  It takes only using one revision of one tool!  The
synthesized code will give different results based on a LOT of variables,
even point revisions of the tools.  You can't guarantee that.  Unless there
is a document that synthesis tool vendors provide that shows EXACTLY what
code is generated for each construct, what you suggest just isn't going to
work.

> but so does "proper
> use of schematics", correct?

Er, no it doesn't.  Same schematic, same results.

>  And yes, I'm sure that an inexperienced HDL
> designer can waste a lot of time fussing with timing and tools and such.

Sorry, but one does not have to be inexperienced in HDL to waste a lot of
time.

> I know that an inexperienced schematic designer can waste a lot of time
> fussing with timing and tools and such.  I did that a decade ago.

Then perhaps learining the right way to use those tools would have been to
your benefit!.





Article: 34473
(removed)


Article: 34474
Subject: new to fpga
From: "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se>
Date: Mon, 27 Aug 2001 15:22:33 +0200
Links: << >>  << T >>  << A >>
Hi.
I am not entirely new to pld's, but I have never worked with any kind of
fpga, and I wonder:

I want to use something in the range XC2S200 in my design, I have seen
experiment boards equipped with this chip, that are programmed by xilinx
programmer cable, but these fpga:s don't store the bitfile internally AFAIK,
so some EEPROM has to be added? how is this done? how does programming then
work (and erase)?






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