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 112800

Article: 112800
Subject: Re: DVI clock generation
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Nov 2006 15:41:57 -0000
Links: << >>  << T >>  << A >>
"Sean Durkin" <news_nov06@durkin.de> wrote in message 
news:456d9828$1@news.fhg.de...
>
> Nope, Virtex5 does indeed have analogue PLLs, half as many as DCMs. The
> FAE told us this was because of the increasing popularity of spread
> spectrum clocks (like in PCs), and the only way to handle those is a
> PLL, so Xilinx saw a demand there.
>
Hi Sean,
That must be why Xilinx don't support the spread spectrum feature the DCMs 
have/used to have? Sounds like your FAE is bluffing!
http://toolbox.xilinx.com/docsan/xilinx6/de/libs/dcm.pdf

Cheers, Syms. 



Article: 112801
Subject: Re: XC3020-50 board documentation
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Wed, 29 Nov 2006 15:54:18 -0000
Links: << >>  << T >>  << A >>
XC3020 is a tiny chip by today's standards. By the fairly inaccurate guide 
of gate count our starter student product is about x20 in notional gate 
count. You may be lucky and someone on this group has the data for your 
board but I guess that most people will have thrown a board of this type 
away by now.

There a number of products from ourselves and our competitors that will do 
you good service and possible more importantly the current Xilinx tools will 
support the chips on board.

John Adair
Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development 
Board.
http://www.enterpoint.co.uk


"sjb" <sjb@mindspring.com> wrote in message 
news:9Lgbh.4783$tM1.1156@newsread1.news.pas.earthlink.net...
> Hi all,
>
> Would anyone be able to direct me to (or provide me with) any materials 
> related to this board that I've got.
>
> http://trifs.dyndns.org/xilinx%20board.jpg
>
> It's an Xilinx XC3020-50 chip on a board of which I cannot locate anything 
> describing the layout or functions (dip switches/leds/connections/etc...). 
> The only markings on the board are:
>
> Xilinx (1994 (C))(on front side)
> 0430456 rev 04 (on front side)
> 1280037 Rev 02 (on back side)
>
> I got this board thinking it would be good to continue my education with 
> FPGA's, of which I'm just starting (so please go easy on me :>)). I've 
> tried Xilinx's site and can only get documentation on the chip itself. 
> Xilinx won't provide me with any support on this whatsoever! Internet 
> searches turn up nothing. Is this really that old of a board/chip that I 
> should just scrap this thing and try something else?
>
> Thanks for any input...
>
> Scott
> 



Article: 112802
Subject: Re: So who has used Lattice FPGAs recently?
From: "Andy" <jonesandy@comcast.net>
Date: 29 Nov 2006 07:58:55 -0800
Links: << >>  << T >>  << A >>
I agree with Martin: Synplify is better than XST in runtime and QOR,
and if you have synplify-pro, the HDL analyst (RTL or gate level
schematic viewing) is much better than what XST has.

I don't have any experience with Quartus synthesis.

Andy


Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.conekt.net/electronics.html


Article: 112803
Subject: Re: Bus structures question (Spartan 3)
From: "Andy" <jonesandy@comcast.net>
Date: 29 Nov 2006 08:05:09 -0800
Links: << >>  << T >>  << A >>
I wrote and use is0() and is1() vhdl functions that assert warnings if
meta-values are encountered in the argument. They also interpret L and
H as 0 and 1.

Andy


Andreas Ehliar wrote:
> On 2006-11-28, John_H <newsgroup@johnhandwork.com> wrote:
> > If you synthesize with tristate values, the synthesizer may implement your
> > bus_star or the roughly equivalent "1 if idle, 0 if there's bus contention"
> > like what the Spartan 2E's internal BUFTs implemented electrically.
>
> A big problem here is that you might have different behavior in simulation
> than in reality unless you take care.
>
> For example, if you assign z to some signals that are used as control
> signals you might have some problems as seen in the following example:
>
> if(controlsignal) begin
> 	Dosomething;
> end
>
> Dosomething will not happen in simulation because z is not true. However, it
> will do something in reality because the signal will in reality be 1 in this
> situation due to the pullup you described. (I guess you could add pullups or
> pulldowns to the signals in the source code to avoid this in Verilog.)
>
> But this still shows that you must be careful about this situation. My
> advice is to totally avoid tristates internally if you can avoid it.
> 
> /Andreas


Article: 112804
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: "JJ" <johnjakson@gmail.com>
Date: 29 Nov 2006 08:05:52 -0800
Links: << >>  << T >>  << A >>

Joseph wrote:
> Hi all,
>
> I wonder if anyone here are in the same situation as me.
> I am think of buying a new PC, but wondering if I should
> wait for Windows Vista become available first.
> Have anyone try running FPGA tools (Xilinx Webpack,
> Modelsim XE, Quartus, Cygwin) on Windows Vista beta?
> Does it work okay?
> Or should I get a "Vista capable" PC now and upgrade later?
> (sound too much hassle to me, but it might be better?)
> Thanks.
>
> regards,
>
> Joe

Have to agree with pbdel, Vista is a giant piece of whatever.

If W2k or XP or Linux works well already what possible reason could
there be to add the extra burden that Vista imposes. From what I hear,
Vista takes more things away like your right to rebuild your hardware
the way you like, it locks things up with more DRM and more
restrictions on changing your base.configuration. It also uses far more
resources to do the same job even without the Aero candy.

Still we will have to deal with Vista eventually, shame that MS wants
to make W2K go away and then XP when they are working just fine.

just my 2c
John Jakson


Article: 112805
Subject: Re: So who has used Lattice FPGAs recently?
From: burn.sir@gmail.com
Date: 29 Nov 2006 08:13:40 -0800
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> burn.sir@gmail.com writes:
>
> {about Lattice}
> > They use Synplify (and Precision) for synthesis. Not as good as Quartus
> > or XST, but it does the job. Might need some tweaking however when
> > inferring memories.
> >
>
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
>
> Cheers,
> Martin


Short answer: synplify _is_ better than XST, but its ECP2 technology
mapper is still a little immature.

burns


Article: 112806
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: mk <kal*@dspia.*comdelete>
Date: Wed, 29 Nov 2006 16:20:27 GMT
Links: << >>  << T >>  << A >>
On Wed, 29 Nov 2006 14:19:56 +0000, Joseph
<joseph.yiu@obviously-not-a-valid-domain.com> wrote:

>Hi all,
>
>I wonder if anyone here are in the same situation as me.
>I am think of buying a new PC, but wondering if I should
>wait for Windows Vista become available first.
>Have anyone try running FPGA tools (Xilinx Webpack,
>Modelsim XE, Quartus, Cygwin) on Windows Vista beta?
>Does it work okay?
>Or should I get a "Vista capable" PC now and upgrade later?
>(sound too much hassle to me, but it might be better?)

You can turn off much of Vista's eye candy which takes quite a bit of
cpu cycles. In addition the main saving grace of Vista is that it has
a 64 bit version where ISE and other tools (I've tried ISE 8.2 under
64 bit Vista) get a full 4G adress space so if your design doesn't fit
to 2G but fits 4G you're still in luck.

Article: 112807
Subject: Re: Bus structures question (Spartan 3)
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 29 Nov 2006 16:46:16 GMT
Links: << >>  << T >>  << A >>
=?ISO-8859-1?Q?J=FCrgen_B=F6hm?= <jboehm@gmx.net> wrote:

>
>hi,
>
>currently I am working on a small hobby project with the Spartan 3
>Starter Kit board from Xilinx. I use ISE WebPack 8.1i and Verilog as a
>language.
>
> Now some questions have come up during this:
>
>1) There is a need to implement bus structures, say a 16 bit
>bidirectional data bus which should connect several modules on the
>highest level of the project.
>

This is one of the down sides of the Spartan 3. The way to solve this
is to have a multiplexer at each device's input. This seems a bit
cumbersome, but it actually works quite well and fast.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 112808
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: Joseph <joseph.yiu@obviously-not-a-valid-domain.com>
Date: Wed, 29 Nov 2006 16:53:24 +0000
Links: << >>  << T >>  << A >>
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote:
> Joseph <joseph.yiu@obviously-not-a-valid-domain.com> wrote:
> 
>>I wonder if anyone here are in the same situation as me.
>>I am think of buying a new PC, but wondering if I should
>>wait for Windows Vista become available first.
>>Have anyone try running FPGA tools (Xilinx Webpack,
>>Modelsim XE, Quartus, Cygwin) on Windows Vista beta?
>>Does it work okay?
>>Or should I get a "Vista capable" PC now and upgrade later?
>>(sound too much hassle to me, but it might be better?)
> 
> 
> What is two months waiting time worth to you ..?
> 

If I buy it now I can get everything setup during my Christmas holiday.
If I wait two months I could be too busy to sort things out afterward.


> What hinders you to use MS-XP after Vista is released..?

MS will possibly eventually stop supporting XP.
(e.g. no more service pack and security updates)
Some existing software will eventually move over to Vista.

Also, it is often necessary to learn new stuffs.
When you work in IT fields people, e.g. family and friends,
expect you to know everything, from changing toner of their
printers (brands you've never used before) to fixing
virus/spyware infected computer. *sign* :(

> 
> You most likely will pay for hardware that will be consumed by Vista Bells &
> Whistles that won't benefit your vhdl/verilog processing.
> 

Processing power is not really my biggest concern. I am using
the Xilinx Spartan-3 starter kit anyway (only a 200k FPGA).
It is purely for learning, not for real work stuffs.
But I want to make sure it can run existing tools that I am using now.

Glad to know that someone has actually used ISE 8.2 in 64-bit Vista :)
I don't think I will spend that much money to get a home PC with
4G RAM (2GB RAM more likely).

Joe



Article: 112809
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: "Subroto Datta" <sdatta@altera.com>
Date: 29 Nov 2006 08:56:41 -0800
Links: << >>  << T >>  << A >>
You do not have to wait for Vista to get 64 bits. WinXP64 is available
today and works just fine. One advantage of WinXP64 is that 32 bit
Windows Apps have access to 4GB of address space. On the WinXP32 32 bit
Windows applications have access to at most 3GB of memory, if the
application is linked with a special flag.

- Subroto Datta
Altera Corp.

On Nov 29, 8:20 am, mk <kal*@dspia.*comdelete> wrote:
> On Wed, 29 Nov 2006 14:19:56 +0000, Joseph
>
> <joseph....@obviously-not-a-valid-domain.com> wrote:
> >Hi all,
>
> >I wonder if anyone here are in the same situation as me.
> >I am think of buying a new PC, but wondering if I should
> >wait for Windows Vista become available first.
> >Have anyone try running FPGA tools (Xilinx Webpack,
> >Modelsim XE, Quartus, Cygwin) on Windows Vista beta?
> >Does it work okay?
> >Or should I get a "Vista capable" PC now and upgrade later?
> >(sound too much hassle to me, but it might be better?)You can turn off much of Vista's eye candy which takes quite a bit of
> cpu cycles. In addition the main saving grace of Vista is that it has
> a 64 bit version where ISE and other tools (I've tried ISE 8.2 under
> 64 bit Vista) get a full 4G adress space so if your design doesn't fit
> to 2G but fits 4G you're still in luck.


Article: 112810
Subject: FPGA application field
From: "tenteric" <tenteric@gmail.com>
Date: 29 Nov 2006 08:58:55 -0800
Links: << >>  << T >>  << A >>
Hello everybody.

It seems, I wish to build my career as engineer who use FPGA to
construct ad hoc designs, in the field of fast computation.
I've heard about cryptoanalysts' FPGA experiments.. and I'm
interesting, where else I'll able to apply my professional profile, now
or in the near future?


Article: 112811
Subject: Re: FPGA application field
From: jez-smith@hotmail.co.uk
Date: 29 Nov 2006 09:11:19 -0800
Links: << >>  << T >>  << A >>

tenteric schrieb:

> Hello everybody.
>
> It seems, I wish to build my career as engineer who use FPGA to
> construct ad hoc designs, in the field of fast computation.
> I've heard about cryptoanalysts' FPGA experiments.. and I'm
> interesting, where else I'll able to apply my professional profile, now
> or in the near future?

You can apply FPGAs to just about any field that you care to mention,
there are plenty of companies who are activly seeking engineers with
skills in designing with FPGAs.Personaly ive worked on and developed
designs for telecoms systems,cryptographic systems,soft processor
cores.AS you mention cryptograhic applications I wrote a pipelined AES
core a couple of years ago and got my present job of the basis of the
knowledge gained during the development of that core.


Article: 112812
Subject: Re: DVI clock generation
From: Sean Durkin <news_nov06@durkin.de>
Date: Wed, 29 Nov 2006 18:15:32 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
> Hi Sean,
> That must be why Xilinx don't support the spread spectrum feature the DCMs 
> have/used to have? Sounds like your FAE is bluffing!
> http://toolbox.xilinx.com/docsan/xilinx6/de/libs/dcm.pdf
Well, he was talking about spread spectrum clocks as INPUT clocks to the
FPGA, not as outputs of a DCM. Supposedly (I've never had the pleasure
of dealing with spread spectrum clocks) DCMs can't handle that and won't
lock, at least in some cases. But now with PCI-E and SATA and everything
going serial and spread-spectrummy this is something people want.

But he was still bluffing in a lot of ways when he presented the new
architecture. Like availability and prices. :)

cu,
Sean

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 112813
Subject: Re: FPGA application field
From: "tenteric" <tenteric@gmail.com>
Date: 29 Nov 2006 09:18:52 -0800
Links: << >>  << T >>  << A >>
jez-sm...@hotmail.co.uk wrote:
> tenteric schrieb:
>
> > Hello everybody.
> >
> > It seems, I wish to build my career as engineer who use FPGA to
> > construct ad hoc designs, in the field of fast computation.
> > I've heard about cryptoanalysts' FPGA experiments.. and I'm
> > interesting, where else I'll able to apply my professional profile, now
> > or in the near future?
>
> You can apply FPGAs to just about any field that you care to mention,
> there are plenty of companies who are activly seeking engineers with
> skills in designing with FPGAs.Personaly ive worked on and developed
> designs for telecoms systems,cryptographic systems,soft processor
> cores.AS you mention cryptograhic applications I wrote a pipelined AES
> core a couple of years ago and got my present job of the basis of the
> knowledge gained during the development of that core.

I need to be more precise - my passion is just very fast computation -
I'm very interesting in implementing any math algorithm thus it will
work as fast as it can.


Article: 112814
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: Sean Durkin <news_nov06@durkin.de>
Date: Wed, 29 Nov 2006 18:21:32 +0100
Links: << >>  << T >>  << A >>
Subroto Datta wrote:
> You do not have to wait for Vista to get 64 bits. WinXP64 is available
> today and works just fine.
... and don't forget about Linux. ISE8.2 (I can't comment on Altera's
tools) now (I thin SP2 did the trick) runs fine on just about any
64bit-Linux I've tried (OpenSuSE, Ubuntu, Fedora...). Available today
AND free ;)

cu,
Sean

-- 
My email address is only valid until the end of the month.
Go figure what the address is going to be after that...

Article: 112815
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: curtis_m_watson@yahoo.com
Date: 29 Nov 2006 09:30:11 -0800
Links: << >>  << T >>  << A >>
I would just go with XP. I will admit that I'm skeptical of anything
new from Microsoft and I wait 3-6 months before making the switch, if
not longer.

> MS will possibly eventually stop supporting XP.
> (e.g. no more service pack and security updates)
> Some existing software will eventually move over to Vista.
>

I don't think this should be a concern. I read that Microsoft just
stopped (within the past year) supporting Windows 98. So I think you
have a few years before they stop supporting XP.

-cmw


Article: 112816
Subject: Re: Spartan3 Configuration Puzzler
From: "Daveb" <dave.bryan@gmail.com>
Date: 29 Nov 2006 09:45:06 -0800
Links: << >>  << T >>  << A >>
davide wrote:
> "Daveb" <dave.bryan@gmail.com> wrote in message
> news:1164754755.908635.123850@16g2000cwy.googlegroups.com...
> > Gabor wrote:
> >> Daveb wrote:
> >> > Hi,
> >> >
> >> > I'm using a microcontroller to configure a Spartan-3 device. The device
> >> > seems to configure ok (the design works as expected) but INIT_B goes
> >> > low & stays low after the last frame has been clocked in. According to
> >> > the datasheet this indicates a CRC error.
> >> >
> >> > Does anyone have any idea why I'd get a CRC error but my design still
> >> > works ?
> >> >
> >> > Thanks
> >> > Dave
> >>
> >> INIT_B is a "dual-purpose" pin.  After config it is an I/O.  Make sure
> >> you
> >> haven't inadvertently assigned this pin as an output (this can happen
> >> if
> >> your .ucf file doesn't specify LOC for all top level module outputs).
> >> When
> >> in doubt, use FPGA editor to check the pin.
> >>
> >> HTH,
> >> Gabor
> >
> > Gabor
> >
> > I've checked my .ucf file & loaded it into FPGA pin editor & INIT_B
> > isn't inadvertently being used by the design. I'm really quite baffled
> > as to what is going on because the datasheet says that if the CRC is
> > incorrect then the startup sequence is aborted. In this situation I'm
> > assuming the design isn't used to configure the device. Maybe this is
> > an incorrect assumption ?
> >
> > Dave
> >
>
> Dave,
>
> During configuration, there are several CRC checks.  The first makes sure
> that the bitstream device ID matches that of the device being programmed.
> The other CRC checks are performed after the final frame of each FRDI read
> sequence.  After the final CRC is completed, the startup sequence begins and
> DONE goes high (assuming default startup).  The IO's are released as well as
> internal FF's and RAM.
>
> As you are not using INIT as an IO in your design, the default is to attach
> a weak pulldown on the (all unused) IO.  Thus, it is now low.  Without
> knowing what type of file you are using with your u-proc configuration, it
> is hard to say what is contained in the last frame of the configuration
> file, but everything you are describing appears to be normal.
>
> You can always specify to leave unused IO as floating or pulled up if you
> wanted to test this for a sanity check.
>
> -David

Thanks for the suggestions.

I decided to set the INIT_B to an output forced high in my design and
hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
purpose I/O pins are weak pull down. Turns out that there's weak and
there's weak! the pull down can be less than 2K so my (fairly weak)
pull up lost. So no CRC error after all but I should have read the
datasheet in more detail before panicking.

DaveB


Article: 112817
Subject: Re: FPGA workstation - should I wait for Window Vista?
From: mk <kal*@dspia.*comdelete>
Date: Wed, 29 Nov 2006 17:48:03 GMT
Links: << >>  << T >>  << A >>
On 29 Nov 2006 08:56:41 -0800, "Subroto Datta" <sdatta@altera.com>
wrote:

>You do not have to wait for Vista to get 64 bits. WinXP64 is available
>today and works just fine. One advantage of WinXP64 is that 32 bit
>Windows Apps have access to 4GB of address space. On the WinXP32 32 bit
>Windows applications have access to at most 3GB of memory, if the
>application is linked with a special flag.

The device driver support for and application compatibility of Vista
64 is much better than XP 64 (I have both installed). As a 64 bit
windows, I don't think XP 64 is an option anymore.

Article: 112818
Subject: Re: Spartan3 Configuration Puzzler
From: "rickman" <gnuarm@gmail.com>
Date: 29 Nov 2006 09:54:43 -0800
Links: << >>  << T >>  << A >>
Daveb wrote:
> I decided to set the INIT_B to an output forced high in my design and
> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
> purpose I/O pins are weak pull down. Turns out that there's weak and
> there's weak! the pull down can be less than 2K so my (fairly weak)
> pull up lost. So no CRC error after all but I should have read the
> datasheet in more detail before panicking.

You are not the first engineer to have been caught napping by the
Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
tendancy to not act, or even react, but to *over*react to issues.
Someone discovered this on a project a couple of years ago and decided
to use 0 ohm jumpers to set the config pins.  Then when I was drawing
up my schematics, like you, I initially used resistors that were
inappropriate.  When another engineer corrected me and I investigated,
I found what the issue was and decided to only add jumpers to ground
since the pullups were plenty strong enough to pull up and could not be
turned off.  That led to a tirade about how 0 ohm jumpers were required
in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
is not correct, but that day it was no fun being right.

The long and the short of it is that Xilinx does not always get this
stuff right and they don't consider this broken enough to fix it.  You
would think they would note this clearly in the documentation that this
part is very different from their other devices.


Article: 112819
Subject: Re: Bus structures question (Spartan 3)
From: =?ISO-8859-1?Q?J=FCrgen_B=F6hm?= <jboehm@gmx.net>
Date: Wed, 29 Nov 2006 19:00:56 +0100
Links: << >>  << T >>  << A >>
Nico Coesel wrote:
>>
>> 1) There is a need to implement bus structures, say a 16 bit
>> bidirectional data bus which should connect several modules on the
>> highest level of the project.
>>
> 
> This is one of the down sides of the Spartan 3. The way to solve this
> is to have a multiplexer at each device's input. This seems a bit
> cumbersome, but it actually works quite well and fast.
> 

   Is it not on the contrary necessary to feed *different outputs* from
the different devices into a multiplexer, which then drives a *single*
input line for all devices ? Would not otherwise the notorious error
message, saying that a single "wire" is driven by several different
"out"s appear?

   At least it was for this reason I conceived this "bus_star" topology
(essentially a multiplexer of course) the way I outlined it in my
original posting.

Greetings

Jürgen

-- 
Jürgen Böhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
desirable that some, who can, dream ?"  R. Thom

Article: 112820
Subject: modular design / PlanAhead
From: wojtek_himself <wojtek2u@wp.pl>
Date: Wed, 29 Nov 2006 19:23:09 +0100
Links: << >>  << T >>  << A >>
Hi,

Does anyone have experience with modular design flow or PlanAhead?
Could you answer my questions related to it:

1) I know that all IO ports in modular design flow have to be placed on 
the top level. But does it mean that all FFs/tri-state buffers I want to 
have in IOBs have to be inferred on the top level as well or these logic 
can stay locally in modules?

2) Do I understand it correctly that PlanAhead is just graphical 
interface to modular design and partial reconfiguration functionality 
(plus some other features)?

3) Do you know if evaluation version of PlanAhead is fully functional?

4) Is this modular design or PlanAhead really useful and not one of toy 
tools?

I would appreciate sharing your experience,

Regards
Wojtek

Article: 112821
Subject: Re: So who has used Lattice FPGAs recently?
From: PeteS <peter.smith8380@ntlworld.com>
Date: Wed, 29 Nov 2006 18:24:26 GMT
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> burn.sir@gmail.com writes:
> 
> {about Lattice}
>> They use Synplify (and Precision) for synthesis. Not as good as Quartus
>> or XST, but it does the job. Might need some tweaking however when
>> inferring memories.
>>
> 
> Can you provide more details?  My experience to date has been that
> Synplify is better than XST, especially on runtime, and almost all the
> time on size & speed.
> 
> Cheers,
> Martin
> 

Thanks for the answers, chaps.

I can now be a little more confident of using the devices. I have the 
time to do a migration (well, a clean new design as it happens) if I 
start now, and most of that extra time should (hopefully) be merely tool 
related.

I'll talk to my friendly vendor about pricing etc., tomorrow.

That doesn't mean I won't use the other brands; in this particular case 
it may make more sense to use brand L.

Cheers

PeteS

Article: 112822
Subject: Re: Bus structures question (Spartan 3)
From: PeteS <peter.smith8380@ntlworld.com>
Date: Wed, 29 Nov 2006 18:26:55 GMT
Links: << >>  << T >>  << A >>
Jürgen Böhm wrote:
> Nico Coesel wrote:
>>> 1) There is a need to implement bus structures, say a 16 bit
>>> bidirectional data bus which should connect several modules on the
>>> highest level of the project.
>>>
>> This is one of the down sides of the Spartan 3. The way to solve this
>> is to have a multiplexer at each device's input. This seems a bit
>> cumbersome, but it actually works quite well and fast.
>>
> 
>    Is it not on the contrary necessary to feed *different outputs* from
> the different devices into a multiplexer, which then drives a *single*
> input line for all devices ? Would not otherwise the notorious error
> message, saying that a single "wire" is driven by several different
> "out"s appear?
> 
>    At least it was for this reason I conceived this "bus_star" topology
> (essentially a multiplexer of course) the way I outlined it in my
> original posting.
> 
> Greetings
> 
> Jürgen
> 

If you define each module with inout (as if you had tristates 
internally), then the tools will infer the appropriate multiplexers for 
you (at least they will in XST).

Cheers

PeteS

Article: 112823
Subject: Re: Spartan3 Configuration Puzzler
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 29 Nov 2006 18:52:22 GMT
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message 
news:1164822883.158338.136150@j72g2000cwa.googlegroups.com...
> Daveb wrote:
>> I decided to set the INIT_B to an output forced high in my design and
>> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
>> purpose I/O pins are weak pull down. Turns out that there's weak and
>> there's weak! the pull down can be less than 2K so my (fairly weak)
>> pull up lost. So no CRC error after all but I should have read the
>> datasheet in more detail before panicking.
>
> You are not the first engineer to have been caught napping by the
> Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
> tendancy to not act, or even react, but to *over*react to issues.
> Someone discovered this on a project a couple of years ago and decided
> to use 0 ohm jumpers to set the config pins.  Then when I was drawing
> up my schematics, like you, I initially used resistors that were
> inappropriate.  When another engineer corrected me and I investigated,
> I found what the issue was and decided to only add jumpers to ground
> since the pullups were plenty strong enough to pull up and could not be
> turned off.  That led to a tirade about how 0 ohm jumpers were required
> in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
> is not correct, but that day it was no fun being right.
>
> The long and the short of it is that Xilinx does not always get this
> stuff right and they don't consider this broken enough to fix it.  You
> would think they would note this clearly in the documentation that this
> part is very different from their other devices.

Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August 
19 2005) diction similar to the first instance is found:

  The Spartan-3 I/O pull-up and pull-down resistors are stronger
  than the "weak" pull-up/pull-down resistors used in previous
  Xilinx FPGA families. See Table 6, Module 3 for
  equivalent resistor strengths.

Your design was probably before the data sheet revision but the 
documentation DOES reflect this change.  If you've looked at the S3E data 
sheet, your comment that "You
> would think they would note this clearly in the documentation" is made 
> MORE clear by adding the great big warning signs and outlined text to 
> emphasize the issues that are issues.

They didn't do a good job with the resistor strength in S3, absolutely. 
They _have_ taken care of the documentation side of things. 



Article: 112824
Subject: Re: Spartan3 Configuration Puzzler
From: "rickman" <gnuarm@gmail.com>
Date: 29 Nov 2006 11:04:53 -0800
Links: << >>  << T >>  << A >>
John_H wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:1164822883.158338.136150@j72g2000cwa.googlegroups.com...
> > Daveb wrote:
> >> I decided to set the INIT_B to an output forced high in my design and
> >> hey presto INIT_B goes high. As 'Davide' pointed out, unassigned dual
> >> purpose I/O pins are weak pull down. Turns out that there's weak and
> >> there's weak! the pull down can be less than 2K so my (fairly weak)
> >> pull up lost. So no CRC error after all but I should have read the
> >> datasheet in more detail before panicking.
> >
> > You are not the first engineer to have been caught napping by the
> > Spartan 3 "weak" pullups (downs).  Where I work, there is a strong
> > tendancy to not act, or even react, but to *over*react to issues.
> > Someone discovered this on a project a couple of years ago and decided
> > to use 0 ohm jumpers to set the config pins.  Then when I was drawing
> > up my schematics, like you, I initially used resistors that were
> > inappropriate.  When another engineer corrected me and I investigated,
> > I found what the issue was and decided to only add jumpers to ground
> > since the pullups were plenty strong enough to pull up and could not be
> > turned off.  That led to a tirade about how 0 ohm jumpers were required
> > in *all* cases on the Spartan 3s, pullup or pulldown.  Of course this
> > is not correct, but that day it was no fun being right.
> >
> > The long and the short of it is that Xilinx does not always get this
> > stuff right and they don't consider this broken enough to fix it.  You
> > would think they would note this clearly in the documentation that this
> > part is very different from their other devices.
>
> Starting in the Spartan-3 FPGA Family: Functional Description v1.4 (August
> 19 2005) diction similar to the first instance is found:
>
>   The Spartan-3 I/O pull-up and pull-down resistors are stronger
>   than the "weak" pull-up/pull-down resistors used in previous
>   Xilinx FPGA families. See Table 6, Module 3 for
>   equivalent resistor strengths.
>
> Your design was probably before the data sheet revision but the
> documentation DOES reflect this change.  If you've looked at the S3E data
> sheet, your comment that "You
> > would think they would note this clearly in the documentation" is made
> > MORE clear by adding the great big warning signs and outlined text to
> > emphasize the issues that are issues.
>
> They didn't do a good job with the resistor strength in S3, absolutely.
> They _have_ taken care of the documentation side of things.

I don't agree with this.  I had this discussion with Xilinx (mostly in
this group) when I was investigating the behavior of all the pullups on
all the pins of the Spartan 3.  I found that the required information
was scattered over multiple sections of the document and stated in
different ways that even appear to contradict each other in some ways.
Xilinx did make some adjustments to the data sheet, but I think the
issue of using the pullup resistors in Spartan 3 devices is complicated
enough that the information should be pulled together in one section
where it can be found easily and completely.  No one has time to read
every sentance in a 200 page document.  Instead we rely on the tools
available for searching the document and typically don't expect to have
to find info in multiple places to tell us the *whole* story.

Putting one sentance at the end of one section is not what I would call
"taking care" of documentation.  Obviously people are still missing
this sentance and not realizing that the Spartan 3 pullups are
different from the pullups on nearly every FPGA made by any vendor.




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