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 42550

Article: 42550
Subject: Re: Destroying Xilinx xc4000 etc
From: Rissa Tero <rissa@kaarne.cs.tut.fi>
Date: Sat, 27 Apr 2002 01:25:23 +0000 (UTC)
Links: << >>  << T >>  << A >>
Herbie <petemartin@ntlworld.com> wrote:
> I know there is anecdotal evidence of people frying an FPGA by loading
> illegal configuration patterns - eg when using evolutionary techniques, but
> does anyone know of any published work on this?

Something like that was done in:

Ilija Hadzic, Sanjay K. Udani, and Jonathan M. Smith, "Hardware Viruses," in Field
Programmable Logic 1999, Springer-Verlag, Edinburgh, UK (1999), pp. 291-300.

-- 
T.Rissa

Article: 42551
Subject: ABEL for the Altera MAX 7000
From: DAHZ@aol.com (Benjamin Heart)
Date: 26 Apr 2002 20:23:28 -0700
Links: << >>  << T >>  << A >>
Does anyone know of an ABEL compiler that is available, free or
otherwise, for use with Altera products; the MAX 7000 in particular.
Xilinx and Lattice each have their ABEL tools, but Altera does not
seem to support ABEL. Is there some third party option? If so where
can I get it?

Thanks in advance,
Ben

Article: 42552
Subject: Re: Newbie Advice Please
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 26 Apr 2002 21:01:01 -0700
Links: << >>  << T >>  << A >>
"Stephen Henry" <s@s.com> wrote
>     I'm an Electrical Engineering Student enterring my final year and i
> have to choose a project to do. I want to build and design a small and
> simple computer system, with a fpga as its cpu (designed by me) -hopefully
> getting to the stage where i can get it to output to a VGA device.

With apologies to newsgroup regulars, please visit www.fpgacpu.org for
helpful resources, and links, including a Circuit Cellar magazine series on
just this subject (building a RISC CPU and system on a chip, including
bitmapped video controller, and dev tools, in an XC4005).

I think this can indeed be a managable senior project, but keep it simple!

Jan Gray, Gray Research LLC




Article: 42553
Subject: Re: Using 74HCT245N between Spartan-II and ISA
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Apr 2002 05:50:12 GMT
Links: << >>  << T >>  << A >>
BZZZT!

Wrong answer.  The SpartanII most certainly is 5v tolerant.  I believe the Vih max is 5.5v  Using pull-ups is the way to get
outputs up to 5v, just make sure they are compatible with the rest of the bus.  It has been awhile, but as I recall, the ISA bus
usually has someone pulling up on it anyway.

rickman wrote:

> Actually, you are violating the max Vih spec for these chips.  Spartan
> II devices are not 5 volt tolerant and should not be used in this
> application.  We are doing the same thing with the same chip and we are
> using a CoolRunner part as a large buffer chip to isolate the ISA bus
> from the Spartan II chip.
>
> If you are just designing an IO mapped, 8 bit peripheral, then you only
> need 8 data bits plus 10 address bits and 3 or so control lines.  You
> can interface all this with three 245 chips.  But as another poster
> said, you have to decode the address inside the FPGA to generate the
> enable to the 245 data buffer chip.  If you are enabling it on just
> IORD, then you are responding when any IO device is being read and
> corrupting that data.  This is why your PC won't boot.
>
> So add the decoding to the SpartanII, use a pullup on the enable to the
> data bus 245, enable the address and control line 245s at all times with
> the direction fixed to input from the bus and your design should start
> to work.
>
> Sean wrote:
> >
> > Hi everyone again.
> >
> > I think I solved my problem, but I did it by completely getting rid of
> > the transciever and simply putting 4.7k ohm pullup (to 5V) resistors
> > to the bus outputs.  It seems to work fine, aside from some single
> > glitches on a few occasions.  In any case it's much more reliable now
> > that it was.  I'm not doing something foolish by using pullup
> > resistors on the bus though am I?  It doesn't seem to cause any harm
> > or impede the operation of the PC in any way, at least visibly.
> >
> > Sean A Laughter <s2salaug@mail2.vcu.edu> wrote in message news:<Pine.SGI.4.33.0204241846190.308721-100000@neptune.vcu.edu>...
> > > Hi everyone.
> > >
> > > I'm interfacing a Spartan-II to an ISA/PC-104 bus.  I have had no success
> > > with tying the Spartan directly to the bus, it is just not reliable and
> > > gives me sporadic values when reading from the Spartan.  Since I have no
> > > trouble writing to the Spartan I'm assuming it has something to do with
> > > the 3.3V just basically not making it over the wires to the bus (because
> > > all my errors appear to be 1's that are being interpreted as lows).
> > >
> > > Anyway, to rectify this problem I'm attempting to use a 74HCT245
> > > transciever to pull the Spartan outputs to a full 5V.  I'm tying the
> > > IOread signal to the direction pin of the transciever, but I can't get the
> > > PC to boot when the setup is attached to the ISA data bus.
> > >
> > > I've decided this is probably because the transciever needs to be in
> > > isolation mode at the appropriate time.  However, I can't think of a way
> > > to do this during boot.  It would be easy enough to control this once the
> > > Spartan is programmed because I'd have my ISA port code and I could just
> > > output a few signals to tell the 74HCT to go into isolation.  This
> > > obviously isn't possible before the chip is programmed though, and so I'm
> > > stuck with a PC that won't boot with the spartan (via the transciever)
> > > attached to the data bus.  The "enable" signal is active low.  So when it
> > > is high the chip goes into isolation, which is what I would want at
> > > boot-up.
> > >
> > > Has anyone else used this chip in this fashion and can tell me how they
> > > solved this problem, or does anyone have any ideas on how to solve this
> > > problem?  Thanks.
> > >
> > > Sean
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 42554
Subject: Re: Using 74HCT245N between Spartan-II and ISA
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Apr 2002 05:54:42 GMT
Links: << >>  << T >>  << A >>
Oh yeah, for ISA IIRC, you need to spec a high current driver on several of the signals.  12 MA on data, and there were one or two
that need to drive 24mA.  Since even 3.3v meets the high level spec for the ISA, I don't think pull-ups or lack thereof is the
problem, rather you are probably not providing enough drive on one or more signals.  While I haven't interfaced SpartanII to the ISA
bus (don't have any computers left with those in them), I did do several 4KXLA designs that connected directly to the ISA bus several
years ago.

Ray Andraka wrote:

> BZZZT!
>
> Wrong answer.  The SpartanII most certainly is 5v tolerant.  I believe the Vih max is 5.5v  Using pull-ups is the way to get
> outputs up to 5v, just make sure they are compatible with the rest of the bus.  It has been awhile, but as I recall, the ISA bus
> usually has someone pulling up on it anyway.
>
> rickman wrote:
>
> > Actually, you are violating the max Vih spec for these chips.  Spartan
> > II devices are not 5 volt tolerant and should not be used in this
> > application.  We are doing the same thing with the same chip and we are
> > using a CoolRunner part as a large buffer chip to isolate the ISA bus
> > from the Spartan II chip.
> >
> > If you are just designing an IO mapped, 8 bit peripheral, then you only
> > need 8 data bits plus 10 address bits and 3 or so control lines.  You
> > can interface all this with three 245 chips.  But as another poster
> > said, you have to decode the address inside the FPGA to generate the
> > enable to the 245 data buffer chip.  If you are enabling it on just
> > IORD, then you are responding when any IO device is being read and
> > corrupting that data.  This is why your PC won't boot.
> >
> > So add the decoding to the SpartanII, use a pullup on the enable to the
> > data bus 245, enable the address and control line 245s at all times with
> > the direction fixed to input from the bus and your design should start
> > to work.
> >
> > Sean wrote:
> > >
> > > Hi everyone again.
> > >
> > > I think I solved my problem, but I did it by completely getting rid of
> > > the transciever and simply putting 4.7k ohm pullup (to 5V) resistors
> > > to the bus outputs.  It seems to work fine, aside from some single
> > > glitches on a few occasions.  In any case it's much more reliable now
> > > that it was.  I'm not doing something foolish by using pullup
> > > resistors on the bus though am I?  It doesn't seem to cause any harm
> > > or impede the operation of the PC in any way, at least visibly.
> > >
> > > Sean A Laughter <s2salaug@mail2.vcu.edu> wrote in message news:<Pine.SGI.4.33.0204241846190.308721-100000@neptune.vcu.edu>...
> > > > Hi everyone.
> > > >
> > > > I'm interfacing a Spartan-II to an ISA/PC-104 bus.  I have had no success
> > > > with tying the Spartan directly to the bus, it is just not reliable and
> > > > gives me sporadic values when reading from the Spartan.  Since I have no
> > > > trouble writing to the Spartan I'm assuming it has something to do with
> > > > the 3.3V just basically not making it over the wires to the bus (because
> > > > all my errors appear to be 1's that are being interpreted as lows).
> > > >
> > > > Anyway, to rectify this problem I'm attempting to use a 74HCT245
> > > > transciever to pull the Spartan outputs to a full 5V.  I'm tying the
> > > > IOread signal to the direction pin of the transciever, but I can't get the
> > > > PC to boot when the setup is attached to the ISA data bus.
> > > >
> > > > I've decided this is probably because the transciever needs to be in
> > > > isolation mode at the appropriate time.  However, I can't think of a way
> > > > to do this during boot.  It would be easy enough to control this once the
> > > > Spartan is programmed because I'd have my ISA port code and I could just
> > > > output a few signals to tell the 74HCT to go into isolation.  This
> > > > obviously isn't possible before the chip is programmed though, and so I'm
> > > > stuck with a PC that won't boot with the spartan (via the transciever)
> > > > attached to the data bus.  The "enable" signal is active low.  So when it
> > > > is high the chip goes into isolation, which is what I would want at
> > > > boot-up.
> > > >
> > > > Has anyone else used this chip in this fashion and can tell me how they
> > > > solved this problem, or does anyone have any ideas on how to solve this
> > > > problem?  Thanks.
> > > >
> > > > Sean
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 42555
Subject: Re: ABEL for the Altera MAX 7000
From: Kelly Hall <hall@priest.com>
Date: Sat, 27 Apr 2002 05:59:43 GMT
Links: << >>  << T >>  << A >>
On 26 Apr 2002 20:23:28 -0700, Benjamin Heart <DAHZ@aol.com> wrote:
> Does anyone know of an ABEL compiler that is available, free or
> otherwise, for use with Altera products; the MAX 7000 in particular.
> Xilinx and Lattice each have their ABEL tools, but Altera does not
> seem to support ABEL. Is there some third party option? If so where
> can I get it?

I seem to recall having to use AHDL when using Altera parts.  But if
you use the Atmel ATF15xx family, which are largely compatible with
the MAX7K series, you can use Atmel's ABEL tool.

Kelly

Article: 42556
Subject: Re: Hack an bitstream file for AT40Kxx
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 27 Apr 2002 00:06:42 -0700
Links: << >>  << T >>  << A >>
"Michael Kleinkes" <michael.kleinkes@cryptovision.com> writes:
> Please donīt misunderstand me, I only wonder why I donīt have the right to
> get all the technical information to my product without any limitations.

Same reason Intel doesn't give you a netlist for your Pentium IV.

OK, not *exactly* the same reason, but close enough.  The format of
the bit stream is considered by the vendor to be a valuable trade secret,
just as the netlist of the PIV is considered by Intel to be a valuable
trade secret.

Also, the vendor doesn't want to have to support people messing with
the bit streams.  Aside from the possibility of causing damage to the
part, if they documented it they'd get inundated with tech support
issues resulting from that.

Lots of FPGA customers want the bit stream formats, but they're not likely
to become available.

Article: 42557
Subject: function usage
From: bharathbhushan_g@nrsa.gov.in (bharathbhushan)
Date: 27 Apr 2002 02:54:46 -0700
Links: << >>  << T >>  << A >>
we got a problem in using a function repeatedly calling through a variable.

any one is there to help in providing a sample code or an example.

bhushan

Article: 42558
Subject: Re: Does Vertex II PRO Really work?
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Sat, 27 Apr 2002 12:37:43 +0100
Links: << >>  << T >>  << A >>
On 25 Apr 2002 18:47:09 -0700, hideout@usa.com (SECRET) wrote:

>Hi,
>
>I noticed that Xilinx is claiming on their website that they have a
>Vertex II PRO with a 3.125 Gbps Transceiver and up to 4 IBM PowerPC
>Processors?  Can you actually get silicon for this or is this just
>Marketing BS?
>
>(do not e-mail me.. just post here)
>
>>Hideout<

Priceless...

Turn the headers on. See a line that says
NNTP-Posting-Host: 66.35.226.228

Try a lookup...

IP address: 66.35.226.228
Official name: ip66-35-226-228.altera.com


oops!

- Brian

Article: 42559
Subject: synplicity 6.2.4 can not recongnize "altera_implement_in_esb" directive
From: shengyu_shen@hotmail.com (ssy)
Date: 27 Apr 2002 07:03:22 -0700
Links: << >>  << T >>  << A >>
Hi everyone

I am using synplicity 6.2.4 to synthesis my design, but it tell me
that it can not recognize altera_implement_in_esb:


@W: mul16.v(4): Unrecognized synthesis directive
altera_implement_in_esb
@W:"e:\ssy\nn\nn\nnarm\prim\indep\mul16\mul16.v":4:16:4:39
@W: alushell.v(1185): Unrecognized synthesis directive
altera_implement_in_esb
@W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1185:16:1185:39
@W: alushell.v(1189): Unrecognized synthesis directive
altera_implement_in_esb
@W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1189:16:1189:39
@W: alushell.v(1193): Unrecognized synthesis directive
altera_implement_in_esb
@W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1193:16:1193:39
@W: alushell.v(1197): Unrecognized synthesis directive
altera_implement_in_esb
@W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1197:16:1197:39


why?

Article: 42560
Subject: Re: SpartanII design considerations...
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 27 Apr 2002 11:44:19 -0400
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> 
> "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
> news:3CC8BCEA.89FC0A7@yahoo.com...
> > I am not clear about what the four clock resources are.  Are you saying
> > that there are only four BUFGs in the Spartan II and they go hand in
> > hand with the DLLs?
> 
> They do. Since the DLLS and BUFGs are very close together (with dedicated
> routing between them) you have very good control over timing.
> 
> > Four clocks with clock enables is not the clean approach I would like.
> > I have a memory bus clock at 100 MHz, an MCU bus clock at 30.xxx MHz and
> > four IO clocks at independant rates from 8 kHz to 60 MHz set according
> > to the application which varies.  Even if we use clock enables, that
> > requires the reclocking of the data and the IO clocks would need to be
> > distributed for the data reclocking.  How would that be accommodated?
> > Is there a way to use conventional routing and keep the skew low for a
> > small number of clock inputs?
> 
> How about this. Use a small asynchronous FIFO to synchronize all non-global
> clock datas to your fastest clock. In this case, the clock on non-clock
> lines must drive only a dozen clock inputs, which can be easyly constraint
> to a column. Use
> 
> NET mynet uselowskewlines;
> 
> in the UCF to force the P&R to do so.
> 
> --
> MfG
> Falk

Thanks Falk.  Interesting that I got this advice from another user while
the Xilinx FAE just tells me to read the data sheet.  

Can you tell me how/if this type of clock distribution will characterize
the skew?  I know that with the dedicated clock nets, Xilinx guarantees
that the skew will not interfere with hold times on FF D inputs.  Can
the same guarantee be made with non-clock net routing?  

Somehow I was under the impression that the DLLs and the clock buffers
could be operated independantly and that there were a total of 8 clock
nets on the chip.  Do the Virtex chips also only have four clock nets?  

It would be nice if there was a simple clear document explaining the
differences in the two device families.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42561
Subject: Re: SpartanII design considerations...
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 27 Apr 2002 11:53:16 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> The DLLs work by delaying the clock input so that the delay, including the
> delay through the clock distribution is equal to a period of the input
> clock.  The DLL has a state machine in it that dynamically selects the best
> tap on a tapped delay line to accomplish that goal.
> 
> The length of the tapped delay line determines the lowest frequency that can
> be supported by the DLL.  The 25 MHz minimum frequency spec ensures that the
> delay line is long enough under any legal voltage/temperature/process
> condition with some margin.

Thanks for the post Ray.  But I understand how the DLL works, at least
at the top level of understanding.  What I don't know is how all the
clock resources in the chip play together.  Somehow I had gotten the
impression that the DLLs and the clock buffers could be used separately
to let you route up to 8 clocks around on the chip.  It would appear
that I was wrong.  

I can certainly use the clock resync trick, especially for the slow
clocks.  But I am not clear how to keep the skew small enough on the
peripheral clocks when you have, say 16 bit data to clock into the sync
latch/fifo.  But then I guess that might not be important if the data
flow is done a certain way.  I guess I am still concerned about data
coming into the chip on my peripheral clocks.  If an ADC only outputs
data for say 2nS before and after the rising edge of the clock, will I
be able to route the clock cleanly enough to the IOB FFs to meet the
setup and hold times?  

Likewise one of the clocks may end up being the WRITE strobe from a
processor.  The clock route will need to be faster than the data path to
prevent the loss of the hold time.  Are there constriants to control
this?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42562
Subject: Availability of XC2S150E-6FG456I
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 27 Apr 2002 12:04:42 -0400
Links: << >>  << T >>  << A >>
I have been trying to get my hands on some pieces of XC2S150E-6FG456I
for over a month.  I am told that they will not be shipping until June
and I need to get about four pieces for prototypes in a month.  I can
buy the commercial temp versions, but we need the industrial temp
versions for this version of the board.  

I have tried working with distis and they keep saying that Xilinx won't
give them parts until June no matter how much they beg.  I have
contacted the rep and they keep talking about placing an order so that
it can be expedited.  But what is the point of placing an order if I
can't get delivery when I need it?  

Anyone know how to get your hands on a small number of ES chips prior to
the official release?  

I was able to get some chips from the Coolrunner product manager under
these same conditions awhile back.  But I don't have a way to contact
the SpartanIIE product manager.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42563
Subject: Spartan II OBUF drive strengths
From: Jon Schneider <jschneider@cix.ceeowe.ewekay>
Date: Sat, 27 Apr 2002 18:05:07 +0100
Links: << >>  << T >>  << A >>
I've got a device that "can't be doing that" and suspect the bank of
LEDs.

I drive them with OBUF_S_24s as they take about 15mA. This breaks the
rules in the "Max number of simultaneous switching outputs" table.

If I use OBUF_S_12s say, I would be ok for switching rules but would the
output buffers then drop whatever and reduce the output current or would
they drive the same and just take a ns or so longer to switch ?

That is does the OBUF drive current really affect DC drive capability or
just switching speed ? There are no V/I curves.

	Jon

Article: 42564
Subject: Re: synplicity 6.2.4 can not recongnize "altera_implement_in_esb" directive
From: Ken McElvain <ken@synplicity.com>
Date: Sat, 27 Apr 2002 17:11:27 GMT
Links: << >>  << T >>  << A >>
It is a boolean attribute, not a directive - You have to give
it a value.

/* synthesis altera_implement_in_esb=1 */


ssy wrote:

> Hi everyone
> 
> I am using synplicity 6.2.4 to synthesis my design, but it tell me
> that it can not recognize altera_implement_in_esb:
> 
> 
> @W: mul16.v(4): Unrecognized synthesis directive
> altera_implement_in_esb
> @W:"e:\ssy\nn\nn\nnarm\prim\indep\mul16\mul16.v":4:16:4:39
> @W: alushell.v(1185): Unrecognized synthesis directive
> altera_implement_in_esb
> @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1185:16:1185:39
> @W: alushell.v(1189): Unrecognized synthesis directive
> altera_implement_in_esb
> @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1189:16:1189:39
> @W: alushell.v(1193): Unrecognized synthesis directive
> altera_implement_in_esb
> @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1193:16:1193:39
> @W: alushell.v(1197): Unrecognized synthesis directive
> altera_implement_in_esb
> @W:"e:\ssy\nn\nn\nnarm\src\alushell.v":1197:16:1197:39
> 
> 
> why?
> 


Article: 42565
Subject: Re: SpartanII design considerations...
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 27 Apr 2002 17:13:59 -0000
Links: << >>  << T >>  << A >>
>Thanks for the post Ray.  But I understand how the DLL works, at least
>at the top level of understanding.  What I don't know is how all the
>clock resources in the chip play together.  Somehow I had gotten the
>impression that the DLLs and the clock buffers could be used separately
>to let you route up to 8 clocks around on the chip.  It would appear
>that I was wrong.  

The data sheets usually describe the clock distribution resources.
I'm sure it's in there now that you know what to look for.

Whenever I start working with a chip, I usually spend a lot of time
with the FPGA Editor (XACT?) learning the details of the special
routing resources.  That involves iterations of reading the data
sheets, making test cases, seeing what really results...  There
are occasional "Ahh.  That's what that section was telling me."

Maybe I work/think at too low a level and should just push the big
green button, but I always end up pushing some timing limit.  I'm
not sure how to do that if I don't know what I want the tools to
produce.

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


Article: 42566
Subject: Re: Xilinx Programmable World 2002 - Review
From: Ray Andraka <ray@andraka.com>
Date: Sat, 27 Apr 2002 17:36:59 GMT
Links: << >>  << T >>  << A >>
The best way we have to deal with the glitching (without giving up the fast
carry chains at least) is to deeply pipeline a design.  Pipelining at nearly
every LUT keeps the glitch propagation to a minimum.  It would be interesting
to see a comparison of power for a deeply pipelined over clocked design for
something running at a lower rate but with many levels of combinatorial
logic.

As for the routing contributing to power, we have definitely seen an effect.
Floorplanning seems to consistently decrease power by 20% or more over the
same design automatically placed.

We recently did our first design that needed fans on the FPGAs (we've got a
couple of designs with heatsinks).  I had a picture of the board with pentium
style coolers on the V2000E's with my exhibit at FCCM earlier this week.  In
that case, each FPGA is dissipating 14w (measured).

Austin Lesea wrote:

> Tim,
>
> I wondered why I was writing this note about power... (actually I am).
>
> In Virtex II and Virtex II Pro we see the beginnings of something that we
> need to address with design techniques, tools, and automated software
> awareness.  If you can't do it manually, then there is no way to automate
> it.  Techniques to reduce the 'glitch' power Steve mentions includes
> reducing the amout of interconnect attached to a toggling LUT node (ie
> register in the CLB), or registering ahead of the inputs to reduce the
> skew int he arrival times at the LUT to reduce gratuitous toggling.
>
> I imagine someday a button labled "optimize for power" in the FPGA
> synthesis flow, just as there are area vs speed buttons today.
>
> Right now, there is no "hot spot" as the silicon conducts the heat
> sufficiently well.  The hot spots Steve is referring to are spots which a
> perhaps a few degrees C warmer than the surrounding areas.  Easily imaged
> with IR sensors.
>
> Steve is right, and when he says "could be" he is just teasing.  We are
> designing 'future' FPGAs already.
>
> Austin
>
> Tim wrote:
>
> > Austin
> >
> > To help in the hunt, here is the reference to the eetimes
> > news article:
> >
> > http://www.eetimes.com/semi/news/OEG20020228S0050
> >
> > Quoting from eetimes:
> >
> > Despite this reluctance to tackle the issue head-on, power consumption
> > could soon be at the top of the to-do list in the near future,
> > especially if programmable logic device (PLD) makers are serious
> > about winning sockets in power-sensitive consumer electronics
> > applications, said Xilinx's Trimberger.
> >
> > Xilinx has already taken the first steps to raise the awareness of
> > power issues by disclosing a study on the hot spots in its latest
> > Virtex 2 architecture. In the paper, the company showed that 60
> > percent of the power consumption in the Virtex 2 family is from
> > routing while logic and clocking account for 16 and 14 percent,
> > respectively.
> >
> > Additionally, Xilinx found that the cluster of LUTs, flip-flops and
> > other circuitry that make up its configurable-logic blocks take up
> > 5.9 microwatts per MHz for a typical design. But this is just for
> > "typical" designs; actual power consumption within the configurable
> > logic blocks (CLBs) can change wildly depending on the switching
> > activity. This can occur frequently in synchronous circuits, where
> > the inputs to the LUTs come in at different times during the same
> > clock cycle. This "glitching" effect could contribute up to 70 percent
> > of the power dissipation in a CMOS circuit, whether it's an ASIC or
> > FPGA.
> >
> > <end quote>
> >
> > I guess you feel an application note coming on :-)
> >
> > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
> > news:3CC42242.B251D66F@xilinx.com...
> > > Tim,
> > >
> > > I don't recall the article, I'll go look...
> > >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 42567
Subject: Re: Maximum Usage in a Virtex FPGA
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sat, 27 Apr 2002 17:58:05 -0000
Links: << >>  << T >>  << A >>
>It all depends on what speed you are running. In my experience of customer
>designs that are running fairly slow (<60MHz) they have had no problems
>literally filling the devices to the gills.

>As you increase the usage, you end up with the Mapper merging un-related logic,
>and the side effect of this is of course performance.

I can't figure out what that means, but it seems interesting,
maybe even important.

Is there any basic reason why putting unrelated logic in otherwise
empty slots is going to hurt performance?  Or is that just a handy
rule of thumb to indicate that the routing will have to work a bit
harder?

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


Article: 42568
Subject: Controller Initial State
From: "Hristo Stevic" <hristostev@yahoo.com>
Date: Sat, 27 Apr 2002 19:30:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
Say I have 2 parallel filters. I feed a multiplixer with the two
filters'output. The output should be frist derived from a filter F1 and
then F2. Hence whenever the outputs of the two filters are valid, Sel
input of the multplixer should be at zero level, and then transit
between 1 and zero.

as you see i have to put the Mux sel, at a certain instant T0, in a
certain state.
In order to do so, i compute the latency of the two filters to deduce
the initial state of my Sel signal. if their latency are odd, the state
of the toogle flip flop is 0, otherwise 1

Is it appropriate?
ant comments


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 42569
Subject: Re: SpartanII design considerations...
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 27 Apr 2002 16:48:22 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >Thanks for the post Ray.  But I understand how the DLL works, at least
> >at the top level of understanding.  What I don't know is how all the
> >clock resources in the chip play together.  Somehow I had gotten the
> >impression that the DLLs and the clock buffers could be used separately
> >to let you route up to 8 clocks around on the chip.  It would appear
> >that I was wrong.
> 
> The data sheets usually describe the clock distribution resources.
> I'm sure it's in there now that you know what to look for.
> 
> Whenever I start working with a chip, I usually spend a lot of time
> with the FPGA Editor (XACT?) learning the details of the special
> routing resources.  That involves iterations of reading the data
> sheets, making test cases, seeing what really results...  There
> are occasional "Ahh.  That's what that section was telling me."
> 
> Maybe I work/think at too low a level and should just push the big
> green button, but I always end up pushing some timing limit.  I'm
> not sure how to do that if I don't know what I want the tools to
> produce.

Yes, that is what I always end up doing.  But it takes a lot of time and
if the documentation was more clear, this interaction with the graphic
tools would not be required to learn the architechture.  However you
always have the need to learn what the HDL tools are doing with your
design.  I have never seen a tool that did not need a babysitter.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 42570
Subject: Re: SpartanII design considerations...
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sun, 28 Apr 2002 01:37:08 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote

> We at Xilinx are very interested in any constructive suggestions how we can
> make our documentation, especially in my case the data sheet, clearer and
> easier to use.

One splendid feature of Xilinx data sheets of yore, seemingly now
out of favor, was the "differences from previous generation" page.
Taking a leaf out of consumer electronics user guides, perhaps this
should be "even if you (think) you are an expert, read this" :)

Another great feature which has evaporated is the routing/PIP diagram,
which looked like an extract from XACT.  Much easier to mull over
than FPGA_editor, especially for those of us condemned to the
low-level stuff.





Article: 42571
Subject: Re: SpartanII design considerations...
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sun, 28 Apr 2002 00:48:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1019954357.24255.0.nnrp-01.9e9832fa@news.demon.co.uk>,
Tim <tim@rockylogic.com.nooospam.com> wrote:
>Another great feature which has evaporated is the routing/PIP diagram,
>which looked like an extract from XACT.  Much easier to mull over
>than FPGA_editor, especially for those of us condemned to the
>low-level stuff.

Agreed.  I LOVE that diagram on the XC4K datasheets.  I'd love to see
the equivelent for Virtex/Virtex II family parts.

It would also be a good "WHoah, there is a lot of routing" picture.
:)
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 42572
Subject: Re: SpartanII design considerations...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 01:05:37 GMT
Links: << >>  << T >>  << A >>


Tim wrote

> One splendid feature of Xilinx data sheets of yore, seemingly now
> out of favor, was the "differences from previous generation" page.
> Taking a leaf out of consumer electronics user guides, perhaps this
> should be "even if you (think) you are an expert, read this" :)

Thanks, that was my idea, and my doing.
But for almost ten years, nobody (nobody!) ever expressed any appreciation for
it.
Not Marketing, not Sales, and not even the users.  The classical question "who
cares?"
Lots of good ideas die when there is no feedback...

Peter Alfke


Article: 42573
Subject: Re: SpartanII design considerations...
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sun, 28 Apr 2002 13:11:37 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Tim wrote
> 
> > One splendid feature of Xilinx data sheets of yore, seemingly now
> > out of favor, was the "differences from previous generation" page.
> > Taking a leaf out of consumer electronics user guides, perhaps this
> > should be "even if you (think) you are an expert, read this" :)
> 
> Thanks, that was my idea, and my doing.
> But for almost ten years, nobody (nobody!) ever expressed any appreciation for
> it.
> Not Marketing, not Sales, and not even the users.  The classical question "who
> cares?"
> Lots of good ideas die when there is no feedback...

 You didn't talk to the right users :-)

 And add a vote for 'difference from previous release' - US suppliers
often 
skip this, but European and Asian are better, but not perfect.

 eg Philips used to have a bold arrow, for Delta tag, in their older
data sheets.

-jg

Article: 42574
Subject: Re: SpartanII design considerations...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 28 Apr 2002 01:41:29 GMT
Links: << >>  << T >>  << A >>


Nicholas Weaver wrote:

> I
>
> Agreed.  I LOVE that diagram on the XC4K datasheets.  I'd love to see
> the equivelent for Virtex/Virtex II family parts.
>
> It would also be a good "WHoah, there is a lot of routing" picture.
> :)
>

These drawings (and others) were killed because we did not want to call undue
attention to the internal complexity of the FPGA structure. Especially when
the main competitor brags about his no-brainer automatic "push-button"
design.  :-(
There is a fine line between explaining all the details and exotic
capabilities, and scaring potential customers off. Unfortunately, the
documentation cannot be censored or easily be adapted to the intelligence (
or level of friendliness, patience, and dedication ) of the user.

Peter Alfke, Xilinx Applications





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