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 130900

Article: 130900
Subject: Re: EDK 10.1 first impressions
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 04 Apr 2008 11:03:24 -0700
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> On Apr 3, 3:10 am, Antti <Antti.Luk...@googlemail.com> wrote:
> 
>> PS, I was thinking that 10.1 is not suggested for ML505, but when i
>> just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1
>>
>> Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix
>> the revup or make the 10.1 version of EDK ref design available!
>>
>> I dont want spend weeks to troubleshoot why xilinx ML505 ref design
>> doesnt work with EDK 10.1
> 
> FWIW, our Avnet FAE told us that the 10.1 EDK was exactly the same as
> the 9.2 EDK. It was given a rev bump so that Xilinx wouldn't get the
> usual howls about the EDK shipping months after the ISE tools.
>

This is absolutely not true.  EDK 10.1 is not equal to EDK 9.2.

Ed

Article: 130901
Subject: Re: synplify pro generates negative slack
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Fri, 04 Apr 2008 12:11:04 -0600
Links: << >>  << T >>  << A >>
ni wrote:
> On Apr 4, 7:28 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
>> "ni" <nbg2...@gmail.com> wrote in message
>>
>> news:5f6e1999-3ce9-43c2-bb4a-f9336b3b3edd@s50g2000hsb.googlegroups.com...
>>
>>> What I dont understand is SRL16 is a simple shift reister and the
>>> output of SRL16 is just like any other flipflop output with no
>>> combinational logic at the output.
>> Wrong.
>>
>> An SRL16 *functions* just like a simple shift register, but physically it is
>> a special configuration of a LUT primitive. The setup time and clock-to-out
>> time is very different from a FF primitive in the fabric. When you are doing
>> a high-speed design, you should always try to make the last stage of your
>> shift register pipeline use a dedicated FF. Most synthesis tools will do
>> this for your automatically if you just write a straightforward shift
>> register in RTL. No need to go instantiating things.
>>
>>         -Ben-
> 
> So what your are implying is that its advisable to write the code in
> the following way
> ---------------------------------------------------------------------------------------------------------------------------------------------
> PROCESS(clock,reset)
> begin
> if reset = '1' then
> en4 <= '0';
> elsif clock'event and clock ='1' then
> en4 <= en3;
>  end if;
> end process;
> 
> SR : SRL16 generic map
>  (INIT => x"0000")
> port map (Q => en3,
>              A0 => '0',
>              A1 => '1',
>              A2 => '0',
>              A3 => '0',
>              CLK => clock,
>              D => input);
> 
> ---------------------------------------------------------------------------------------------
> instead of
> 
> 
> 
> SR : SRL16 generic map
>  (INIT => x"0000")
> port map (Q => en4,
>              A0 => '1',
>              A1 => '1',
>              A2 => '0',
>              A3 => '0',
>              CLK => clock,
>              D => input);
> Is that right?
No, no--he's suggesting you write behavioral code, which infers the SRL 
you would don't have to instantiate it.  If you use Synplify, for 
example, it will make the last stage of the delay line a packed flipflop 
depending upon the timing requirements.  So then you needn't worry about 
what primitives are being used.  You shouldn't instantiate primitives 
unless completely necessary.  It destroys clarity, maintainability, and 
portability.  This is an example from the Synplify help files that shows 
how to make a byte-wide 4-cycle delay line:

entity srltest is
    port ( inData: std_logic_vector(7 downto 0);
       clk, en : in std_logic;
       outStage : in integer range 3 downto 0;
       outData: out std_logic_vector(7 downto 0)
);
end srltest;

architecture rtl of srltest is
    type dataAryType is array(3 downto 0) of std_logic_vector(7 downto 0);
    signal regBank : dataAryType;

begin
    outData <= regBank(outStage);
    process(clk, inData)
       begin
          if (clk'event and clk = '1') then
             if (en='1') then
             regBank <= (regBank(2 downto 0) & inData);
             end if;
          end if;
    end process;
end rtl;

It's cleaner in Verilog, of course.
-Kevin

Article: 130902
Subject: Re: Xilinx FPGA + SMPS
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 4 Apr 2008 13:16:36 -0500
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:ft5neg$a38$1@aioe.org...
> sky465nm@trline4.org wrote:
>
> Yes, not reading the "Troubleshooting hints" section of AN19 first. 
> Particularly hint 12.
> Google :-
> AN19 site:linear.com

LOL! 



Article: 130903
Subject: Re: Xilinx PLEASE FIX YOUR servers (ISE 10.1)
From: dalai lamah <antonio12358@hotmail.com>
Date: Fri, 04 Apr 2008 19:14:10 GMT
Links: << >>  << T >>  << A >>
Un bel giorno David Brown digiṭ:

> The reason (I presume) they don't use bittorrent is basically because it 
> would not work for this sort of software.  Only a small proportion of 
> users would be interested in using bittorrent downloads in a 
> professional setting, and only a few of these would be allowed by their 
> IT department, and even fewer would leave the torrents running with fast 
> enough upload capacity for other downloaders to see decent download 
> speeds.  Add to that the common misunderstandings of bittorrent ("How do 
> we know we are getting the proper software - maybe the file is corrupt, 
> or it's picked up a virus from some sharer's PC?" and "Isn't bittorrent 
> only for (sic) pirated files?") and some ISP's brain-dead 
> anti-bittorrent schemes to cheat users out of their bandwidth, and you 
> get a very poor choice of distribution method for this kind of software.

BitTorrent would be an alternative way, not the only way for the download.
Then everyone would choose their preferred way, and I bet that at least a
half of the users would choose the torrent. Many companies distribute their
professional software with either http/ftp and BitTorrent (OpenOffice and
most Linux distributions are the first that come to mind).

-- 
emboliaschizoide.splinder.com

Article: 130904
Subject: Re: synplify pro generates negative slack
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 04 Apr 2008 12:38:13 -0700
Links: << >>  << T >>  << A >>
ni wrote:

> So what your are implying is that its advisable to write the code in
> the following way

If I were having trouble making timing,
I would use a generic shifter.
It is faster in nS and in work hours.
Registers are free on many fpga designs.

           -- Mike Treseler

Article: 130905
Subject: Re: counterfeit Xilinx ?
From: Jon Elson <elson@wustl.edu>
Date: Fri, 04 Apr 2008 14:27:03 -0600
Links: << >>  << T >>  << A >>


John McCaskill wrote:
> On Mar 23, 6:40 pm, Jon Elson <el...@pico-systems.com> wrote:
> 
>>I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese
>>seller, and am having problems with random failures at first
>>power up.  Sometimes it is a stuck I/O pin, sometimes a failure
>>to configure.  I first thought maybe we had an ESD problem, but
>>I'm now thinking these may be counterfeit.  They have white ink
>>printed labels on the front, whereas other Xilinx chips have
>>laser-etched labels.  Also, these Spartan chips don't have the
>>Spartan logo just below the Xilinx logo, like my other Xilinx
>>chips.  Anyone have any comments on this?
>>
>>Jon
> 
> 
> 
> While I have never had to use them for counterfeit detection, I have
> use Process Sciences for process control, inspection and rework for
> several years now. I have always been very happy with their work. They
> have some information about their counterfeit detection services here:
> 
> http://www.process-sciences.com/services/counterfeit_detection.asp
> 
> One of the trade journals I get has been running a series of articles
> about counterfeit parts. I think it was either EE Times, or EDN.  Some
> of the things that they mentioned include remarking to a better speed
> grade, a lower power version, or a larger memory size.


This was a very small batch of parts, so it doesn't make much sense to
spend a lot of money on it.  I still have no idea whether there was any
funny business, or these parts were just mishandled in some way to cause 
them to deteriorate.  A number of them would not do the master mode 
configuration, so that can't be a speed grade problem.  But, half of 
them work!  I still don't know if I have some kind of process problem 
here in my shop, but I am coming around to think it is not something I
caused here.

Jon


Article: 130906
Subject: Xilinx inferred FIFOs
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 4 Apr 2008 14:06:15 -0700
Links: << >>  << T >>  << A >>
What is the current status now about
inferring FIFOs in Virtex 4 or 5
with VHDL ?

Brad Smallridge
Ai Vision



Article: 130907
Subject: Re: counterfeit Xilinx ?
From: John_H <newsgroup@johnhandwork.com>
Date: Fri, 4 Apr 2008 14:39:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jon Elson wrote:
>
> This was a very small batch of parts, so it doesn't make much sense to
> spend a lot of money on it.  I still have no idea whether there was any
> funny business, or these parts were just mishandled in some way to cause
> them to deteriorate.  A number of them would not do the master mode
> configuration, so that can't be a speed grade problem.  But, half of
> them work!  I still don't know if I have some kind of process problem
> here in my shop, but I am coming around to think it is not something I
> caused here.
>
> Jon

Some ideas:
Did you bake the parts before assembly?
Are you hand-soldering the deviecs?

Article: 130908
Subject: Re: Xilinx FPGA + SMPS
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 04 Apr 2008 22:09:04 GMT
Links: << >>  << T >>  << A >>
austin <austin@xilinx.com> wrote:

>
>Go here:
>
>http://www.xilinx.com/products/design_resources/power_central/
>
>Then scroll down to the manufacturers.
>
>Pick the one you like, and go to their Xilinx FPGA power supply pages.
>
>All choices are "approved" for use with ALL Xilinx product.
>
>We (I personally) spend a lot of time with these folks, to ensure a 
>smooth (pun intended) powering experience.
>
>Not sure why the other negative posts...perhaps these are the folks who 

Perhaps a lot of designers are not happy with the fact they are
treated as complete idiots when it comes to SMPS design :-)

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 130909
Subject: Re: Conterfeit parts guidance
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 04 Apr 2008 22:21:40 GMT
Links: << >>  << T >>  << A >>
craig.taylor@xilinx.com wrote:

>Hello all,
>
>I am a Quality manager at Xilinx, and I have asked to provide
>specific
>guidance on the question of counterfieting.  I would like to start by
>saying that the ONLY way to protect yourself is to purchase your
>devices from an authorized Xilinx distributor.  A list can be found
>at
>this link. http://www.xilinx.com/company/sales/ww_disti.htm
>
>
>If you a buying outside of this channel you are taking on a fair
>amount of risk.  Over the past 1.5 years Xilinx along with the Dept
>of
>Homeland Security have become aware of an escalatng issue out of SE
>Asia, where Xilinx component are being marked up for sale into grey
>market channels.  We currently are looking into how to limit this
>activity.

Simple, burn the batch code (fabrication date) and speedgrade into the
die and make them readable through JTAG.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 130910
Subject: Re: Xilinx FPGA + SMPS
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 05 Apr 2008 11:48:43 +1200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> austin <austin@xilinx.com> wrote:
> 
> 
>>Go here:
>>
>>http://www.xilinx.com/products/design_resources/power_central/
>>
>>Then scroll down to the manufacturers.
>>
>>Pick the one you like, and go to their Xilinx FPGA power supply pages.
>>
>>All choices are "approved" for use with ALL Xilinx product.
>>
>>We (I personally) spend a lot of time with these folks, to ensure a 
>>smooth (pun intended) powering experience.
>>
>>Not sure why the other negative posts...perhaps these are the folks who 
> 
> 
> Perhaps a lot of designers are not happy with the fact they are
> treated as complete idiots when it comes to SMPS design :-)

  I'd be less worried about SMPS design, and more worried about the
undocumented interaction of things like fold-back and StartUp
current peaks.
  It's what they DONT say that matters, and there is a lot to be said for
a design that has been tested (and one hopes, fully margined by Austin!)

-jg



Article: 130911
Subject: Re: Xilinx FPGA + SMPS
From: Allan Herriman <allanherriman@hotmail.com>
Date: Sat, 05 Apr 2008 10:49:31 +1100
Links: << >>  << T >>  << A >>
On Sat, 05 Apr 2008 11:48:43 +1200, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>Nico Coesel wrote:
>
>> austin <austin@xilinx.com> wrote:
>> 
>> 
>>>Go here:
>>>
>>>http://www.xilinx.com/products/design_resources/power_central/
>>>
>>>Then scroll down to the manufacturers.
>>>
>>>Pick the one you like, and go to their Xilinx FPGA power supply pages.
>>>
>>>All choices are "approved" for use with ALL Xilinx product.
>>>
>>>We (I personally) spend a lot of time with these folks, to ensure a 
>>>smooth (pun intended) powering experience.
>>>
>>>Not sure why the other negative posts...perhaps these are the folks who 
>> 
>> 
>> Perhaps a lot of designers are not happy with the fact they are
>> treated as complete idiots when it comes to SMPS design :-)
>
>  I'd be less worried about SMPS design, and more worried about the
>undocumented interaction of things like fold-back and StartUp
>current peaks.
>  It's what they DONT say that matters, and there is a lot to be said for
>a design that has been tested (and one hopes, fully margined by Austin!)

Sometimes the app notes and datasheets are wrong as well.  For
example, I've seen plenty of DC/DC converter module datasheets that
indicate that adding more low-ESR capacitance on the output of a DC/DC
converter module will improve transient response.

A closer look reveals that the app note or datasheet was written
around the turn of the century, before modern large ceramic or organic
polymer electrolytic caps became commonly available.  These have much
lower ESR than the app note authors anticipated, and are capable of
making older DC/DC converter modules oscillate, or at least exhibit
poor transient response.

This isn't a problem if you design your own DC/DC converter (in which
case you can tune the compensation network to suit the load) or a more
modern module with a compensation network designed for a large
capacitive load.

This pdf gives more information:
http://www-03.ibm.com/procurement/proweb.nsf/objectdocswebview/file15+-+ibm+06+capacitance+and+transient/$file/15+-+ibm+06+capacitance+and+transient+06_08_18.pdf

Regards,
Allan

Article: 130912
Subject: Re: Conterfeit parts guidance
From: sky465nm@trline4.org
Date: Sat, 5 Apr 2008 02:28:28 +0200 (CEST)
Links: << >>  << T >>  << A >>
craig.taylor@xilinx.com wrote:
>I am a Quality manager at Xilinx, and I have asked to provide
>specific
>guidance on the question of counterfieting.  I would like to start by
>saying that the ONLY way to protect yourself is to purchase your
>devices from an authorized Xilinx distributor.  A list can be found
>at
>this link. http://www.xilinx.com/company/sales/ww_disti.htm

The official distributors all have their own loops & hoops. So it's not
always practical to buy from them.

What we want to know is how to evaluate the authenticity of the product not
how to procure it.


Article: 130913
Subject: Re: synplify pro generates negative slack
From: ni <nbg2006@gmail.com>
Date: Fri, 4 Apr 2008 18:13:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 4, 3:38 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> ni wrote:
> > So what your are implying is that its advisable to write the code in
> > the following way
>
> If I were having trouble making timing,
> I would use a generic shifter.
> It is faster in nS and in work hours.
> Registers are free on many fpga designs.
>
>            -- Mike Treseler

I have recently started(1 week) using Synplify pro. For two years in
my fpga designs I never used synplify pro. For most of the generic
component I used to use core generator and then instantiate those
component in my vhdl code. I was using xilinx XST extensivley and
hence never go these problems. Unfortunately before using synplify pro
for mycurrent design I have used core genrator  in most of the
components. So now I am thingkin of cleaning up the code by changing
the cores for example adders , subtractors, SRL16s,
BRAMs, ROMS etc  to vhdl statements.
Are ther any good documents for vhdl coding styles to infer the
various components in synplify pro?

Thanks for all the suggestions above.

Article: 130914
Subject: Re: EDK 10.1 first impressions
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 4 Apr 2008 19:01:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 4 Apr., 20:03, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

> This is absolutely not true.  EDK 10.1 is not equal to EDK 9.2.

Some software is more equal than other software ....

George O.

Article: 130915
Subject: Re: Conterfeit parts guidance
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 05 Apr 2008 16:19:05 +1200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> craig.taylor@xilinx.com wrote:
> 
> 
>>Hello all,
>>
>>I am a Quality manager at Xilinx, and I have asked to provide
>>specific
>>guidance on the question of counterfieting.  I would like to start by
>>saying that the ONLY way to protect yourself is to purchase your
>>devices from an authorized Xilinx distributor.  A list can be found
>>at
>>this link. http://www.xilinx.com/company/sales/ww_disti.htm
>>
>>
>>If you a buying outside of this channel you are taking on a fair
>>amount of risk.  Over the past 1.5 years Xilinx along with the Dept
>>of
>>Homeland Security have become aware of an escalatng issue out of SE
>>Asia, where Xilinx component are being marked up for sale into grey
>>market channels.  We currently are looking into how to limit this
>>activity.
> 
> 
> Simple, burn the batch code (fabrication date) and speedgrade into the
> die and make them readable through JTAG.

Speed is not known until final test, so that would require OTP fuse 
capability, but that may already be there, at least at the factory level ?.
Now, a really clever counterfeit will clone this too, but it would
catch slippage, easypath, and really dumb (wrong die) attempts.

Unique ID is another natural spin off, for expensive IP.

-jg




Article: 130916
Subject: Re: counterfeit Xilinx ?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Sat, 05 Apr 2008 17:45:17 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:

> This was a very small batch of parts, so it doesn't make much sense to
> spend a lot of money on it.  I still have no idea whether there was any
> funny business, or these parts were just mishandled in some way to cause 
> them to deteriorate.  A number of them would not do the master mode 
> configuration, so that can't be a speed grade problem.  But, half of 
> them work!  I still don't know if I have some kind of process problem 
> here in my shop, but I am coming around to think it is not something I
> caused here.

That reminds me of another scam :  Quantity padding.

Someone in the supply line decides to 'pad the numbers', and
the report I remember had lower failures on the end of tubes, and
higher failures (non blank OTP devices) in the centres.
They hope the user will shrug it off.

Can you pop the top on some failures and look at the die ?

-jg



Article: 130917
Subject: Re: Xilinx FPGA + SMPS
From: austin <austin@xilinx.com>
Date: Fri, 04 Apr 2008 23:32:16 -0700
Links: << >>  << T >>  << A >>
Nico,

My hat is off to you if know how to calculate Ldi/dt, and determine the 
gap in the ferrite inductor, but yes, if we are talking in VHDL/verilog, 
which we do 99.999% of the time, then the people require a power supply 
solution, canned, and ready to go.

Austin

Article: 130918
Subject: Re: Xilinx FPGA + SMPS
From: austin <austin@xilinx.com>
Date: Fri, 04 Apr 2008 23:34:07 -0700
Links: << >>  << T >>  << A >>
Allan,

That is why our power partners read my app notes, and wee read their 
appnotes, and every Xilinx circuit app note must be built and tested (if 
it is hardware, it has to have a pcb...).

Austin

Article: 130919
Subject: Re: Xilinx inferred FIFOs
From: austin <austin@xilinx.com>
Date: Fri, 04 Apr 2008 23:36:08 -0700
Links: << >>  << T >>  << A >>
Brad,

No issue whatsoever.

In V4, the solftware places the extra circuits to bypass the flags that 
didn't work under some conditions, and in V5 all that hardware works 
perfectly.

You do need to use the appropriate version for V4 with the fixes (which 
I believe is any 9.X or later).

Austin

Article: 130920
Subject: Project Ideas
From: Ankit <ankitanand1986@gmail.com>
Date: Fri, 4 Apr 2008 23:50:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello everyone i have been working on FPGA and CPLD's for the past 6
months and i have gained sufficent expertise to do something
innovative or atleast challenging in my final year project.I have
designed ALU units,also implemented the Dice game and also made a
processor on a FPGA so my mentor has asked me to come up with an idea
using the Dragon FPGA board.Here is the link

http://www.fpga4fun.com/PCI.html

The idea should revolve around using the PCI bus for example PCI bus
master or PCI bus analyzer doing something useful,he suggested me that
i should think in terms of what is missing or incomplete on the
board.Waiting for your replies.


Regards
Ankit Anand

Article: 130921
Subject: Re: Antii, can you give us an update?
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 4 Apr 2008 23:56:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 2 Apr., 18:22, Antti <Antti.Luk...@googlemail.com> wrote:
> On 1 Apr., 14:31, "Nial Stewart"
>
> <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I've read all the posts here but have lost track of how you're
> > getting on.
>
> > Can you post an update and describe what the problem turned out
> > to be?
>
> > Nial.
>
> Quote from Actel website: "In March 2008, it was discovered that a
> potential advanced optimization could cause a logic gating of a global
> signal. This optimization is part of a set of other routing
> optimizations that could be invoked if a user sets the Routing High
> Effort Mode in the Advanced Option of the Layout."
>
> This is fixed in Libero 8.3 released march 31 2008
>
> I use the exact target device and setting as described at actel
> website, so I assume at least some of the mess i have had may as well
> be caused by this global signal gating in high effort mode.
>
> Folks, dont think I am not trying hard enough, I am, but the tools
> sometimes choke as well. The code that I currently have, and that is
> randomly failing, whatever constraints, in any normal FPGA fabric with
> no tool injected mess, it SHOULD WORK, but it isnt.
>
> Of course, the tools should be the last thing to blaim on, but
> sometimes they are the root of evil
>
> I try the 8.3 tools and hope it is fixing the issues i have
>
> Antti

updating to 8.3 did not fix the problems, but I am getting closer
status:

in desing exist async strobes A1, A2 (A1 byte rd/wr strobe, A2 spi
slave from ext mcu)

loadable LFSR in A1 domain
2:1 MUX for the selecting the load value
1 input of mux = const, loaded at powerup
2 input of mux connected to 24 bit shift register in A2 domain

LFSR is loaded with constant at powerup, and loaded
with current value in spi shift register ONCE, after
that load the load enable signal is FULLY DISABLED

now, the actual loads to the LFSR work 100%

but when the there is data shifted in into the spi shift
register connected to the input mux of the LFSR load input
then some sequences of data make the LFSR content corrupt

these sequences are REPEATABLE, that is not random!

for different FPGA implementiation runs the sequences are
different, but still for given PCB/FPGA bitstream they are
constant. That is the LFSR gets corrupted at certaing
values being visible on the load input via mux

I already have forced the LFSR enable and mux select
to global clocks
of course the SPI clock and LFSR clocks are global
clocks as well

Antti

Article: 130922
Subject: Re: Project Ideas
From: Frank Buss <fb@frank-buss.de>
Date: Sat, 5 Apr 2008 09:17:01 +0200
Links: << >>  << T >>  << A >>
Ankit wrote:

> http://www.fpga4fun.com/PCI.html
> 
> The idea should revolve around using the PCI bus for example PCI bus
> master or PCI bus analyzer doing something useful,he suggested me that
> i should think in terms of what is missing or incomplete on the
> board.Waiting for your replies.

PCI is fast and FPGAs have many IOs. Maybe buy some RGB LEDs, think how to
build some drivers, which are controlled with PWM signals from the FPGA and
build the next Cubatron:

http://www.nw.com/nw/projects/cubatron/

The FPGA works as a FIFO for precise timing for controlling the LEDs. The
PCI bus would be idle most of the time, but you'll need more speed for a
high resolution version of a spinning globe:

http://www.youtube.com/watch?v=oLygWkHo9nw

In this video you can see how it works:

http://www.youtube.com/watch?v=gBZywmIYw4o

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 130923
Subject: PLA datasheet - PLS161
From: Joseph <jozamm@gmail.com>
Date: Sat, 5 Apr 2008 00:51:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I am looking for the datasheet of the PLS161 which was a PLA. My
interest in it is purely academic. I am teaching a high level digital
electronics course and would like my students to see a datasheet of a
PLA before progressing to CPLD and FPGA's

I would be very grateful if someone could give me the datasheet of
this device or a similar PLA.

Many thanks

Regards

Joseph A. Zammit
Malta

Article: 130924
Subject: Re: A Challenge for serialized processor design and implementation
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 05 Apr 2008 01:28:54 -0800
Links: << >>  << T >>  << A >>
rickman wrote:
(snip)

> Actually, it is not that you *can* produce all logic from NAND gates,
> in effect that is how it *is* done.  The basic logic element consists
> of transistors configured to be a NAND gate, an inverter (a degenerate
> form of a NAND gate), a NOR gate (a NAND gate with inverted logic) and
> transmission gates.  So inside of a chip designed at the gate level,
> there really is no distinction between NAND and NOR gates and there
> are no OR and AND gates.

I believe that is pretty much true for TTL, and I believe
also for ECL, PMOS and NMOS, but not for CMOS.
CMOS can directly implement either NAND or NOR gates.
For non-inverted gates CMOS might require inverters at the
input or output.

-- glen




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