Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 23775

Article: 23775
Subject: Re: Problem with XC95288 using JTAG with HW-JTAG-PC
From: "Alun" <alun101@DELETEtesco.net>
Date: Fri, 7 Jul 2000 21:16:29 +0100
Links: << >>  << T >>  << A >>
Simon Bilodeau <sbilodo@videotron.ca> wrote in message
news:Ta_85.317$VQ6.1085@wagner.videotron.net...
> Is it normal to have 200 ohms resistance between TCLK and TMS and between
> TCLK and TDI pins directly on the chip?
>
> I saw that those pins influence each other because the programmer's pins
> can't get enough current on IC's pins (the programmer works well alone)
and
> I didn't see anything special that could make a short on the board.

No it's not right.

Alun
Camdigital


Article: 23776
Subject: Re: FPGA Express/Foundation Error 470
From: Anna Acevedo <acevedo@xilinx.com>
Date: Fri, 07 Jul 2000 13:21:52 -0700
Links: << >>  << T >>  << A >>
See  http://support.xilinx.com/techdocs/5638.htm

Jens Popp wrote:

> Hi,
>
> does anybody know what this is? It happens when I try to invoke a Syntax
> Check/ Synthesis of Verilog Code in Foundation.
>
> Initialize DPM...
>
> Checking license...
>
> License check OK.
>
> Source: G:\FNDTN\ACTIVE\PROJECTS\CPU\mux16.v.
> Create project...
> DPM Error: Project creation/opening failed.Ausnahmefehler des Servers.
>
> Thanks
> --
>
> Jens Popp
> Institut fuer Rechnerstrukturen
> Universitaet Siegen
> Hoelderlinstr.3
> D-57068 Siegen
> Germany
>
> TEL  +49 271 740 2376
> FAX  +49 271 740 2473
> mailto:popp@rs.uni-siegen.de

--
*****************************
Anna M. Acevedo
Xilinx University Program
2100 Logic Drive
San Jose, CA 95124
PH: (408) 879-5338
FAX: (408) 879-4780

Email: anna.acevedo@xilinx.com
http://www.xilinx.com/programs/univ.htm
*****************************


Article: 23777
Subject: Re: BIST in FPGAs?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 07 Jul 2000 17:00:46 -0400
Links: << >>  << T >>  << A >>
Robert Posey wrote:
> 
> rickman wrote:
> >
> > Robert Posey wrote:
> > >
> > > Rickman wrote:
> > > >
> >
> >
> > >You could get 100% coverage of I/O and Macro cells fairly
> > > easily with special load modes, and even get 100% coverage of logic in each
> > > cell at considerably more expense.  Getting 100% coverage of the RAM in the
> > > part would be a little harder, if not impossible.
> >
> > I don't understand why this is hard. RAM is easy to test by loading and
> > testing patterns. Each bit can be independently tested with simple
> > patterns. The bits can be tested against the neighbors with more complex
> > patterns. The largest array of RAM in a Xilinx part is 4K bits.
> > Certainly this is not time exhaustive to test?
> 
> The question is how can you access it,  to test a memory to 98% using a
> venerable March II takes about 4 patterns, at 8 memory accesses per-cell,
> per-pattern.  According to their website, XILINX XC4000XV has over
> 270,000 RAM bits.  If you are using Serial Access mode, that means you have
> to perform 270Kx4x8 ~= 8 Megabit Reads and Writes which I admit is not
> impossible, takes awhile.  That only gives you 98% coverage of all hard and
> soft faults.  I over-estimated how many RAM cells there where, so it is doable
> even through the serial port.  I not well versed in the the RAM cell accessing
> methods, but if its not random this number would go way, way up.  Of course for
> to detect stuck at faults the number of patterns should be far less.  You can't
> test individual RAM Bits, it must always be against its neighbors, to catch all
> even hard faults.  The classic alternating A's and 5's only detects 1/2 the
> data bit faults, and tests only 1 address line.  I am by no means saying that
> you can't get upper 90's coverage, but you can't get 100% detection on anything.
> 
> >
> > > How could you test all
> > > the possible BIT leakage combinations in a reasonable time.  You can test the
> > > configuration RAM for a given operational load fairly well by reading back the
> > > down load, but this is by no means a 100% coverage.  If you have a RAM Cell
> > > that floats, it may return the correct value part of the time.  Then you have
> > > the issue that all the RAM and Logic Cells have the potential to leak to
> > > any cell that is close to in some manner.  RAMs have faults that cause certain
> > > memory cells to change for a correct 0 to a 1, only when all surrounding
> > > cells are also 1's.
> >
> > This is true for standard memory such as SRAMs. But the configuration
> > memory is made of D FFs and are not co-located with memory from the
> > other CLBs. So you don't have the same test problems that you have with
> > SRAM.
> To really know, you have to look at how isolated each piece is on the actual
> die.  If the RAM cells are embedded in the logic, then the logic states may
> cause unwanted changes or the reverse.  It is likely you are somewhat less
> likely to have this problem in FPGA, than other Memories.
> 
> >
> > But that is not normally what we mean when we talk about coverage of
> > test sets. We assume a much simplified failure model and test against
> > that. Other failure modes need to be tested separately. So we would need
> > a different set of test vectors to test against quantum fluctuations in
> > the sub-space field.  ;)
> 
> Hey for Reagen's Star Wars program to have worked, they would have had to
> detect and correct for those on the fly to get the 100's million part system to
> work. :)  Most of the difference is the location of the testing.  My tests run
> over a large temperature range, and on systems exposed to radiation (hopefully
> just in space).  If you read NASA pages on FPGA's you will find that they
> feel the need to recheck the program load in the FPGA's periodically during
> operation to correct Single Event Upsets of RAM Cells.  In Space Applications,
> this is a real problem, and you can be fairly sure your system won't work
> for long if you don't handle this issue.  There is also a severe shortage of
> IC Test Machines on the battle field, thus all test support is in system.
> I am well aware of what test coverage means in most of the commercial world,
> but the original 100% poster was quoting someone from the defense industry that
> has a well defined concept of failure detection that is based on failure rate,
> and includes soft and hard failures.
> 
> Robert Posey

Yes, I agree that no system can be tested 100% for all possible
failures. But what is your point?

I did not see anywhere in the original post that this was a "defence
industry" test issue. The thread started out asking about tools to
insert scan chain registers. I was tying to make the point that by
making use of the reconfiguration capabilities the parts could be tested
just as well (to 100% by normal "stuck at" fault measures) without
adding extra test logic in the FPGA. 

But I will always agree when someone tells me that a system can not be
shown to work by testing. 


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23778
Subject: Re: Clock Buffer
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 07 Jul 2000 17:08:02 -0400
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> Jens Hildebrandt wrote in message
> <39658097.32F7DDE9@e-technik.uni-rostock.de>...
> >
> >
> >Andy Peters wrote:
> >>
> >> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>...
> >> >Hi,
> >> >
> >> >I'm working with a XILINX XC40250XV and I have following problem:
> >> >
> >> >There is an signal input port and a internal clock should be generated
> >> >from this signal.
> >> >How can I push synopsis to create the internal clock buffer for this
> >> >internal clock automatically.
> >> >Is there at all a way to say "synopsis do this".
> >>
> >> If that signal is connected to only flip-flop clocks, the tool should
> infer
> >> the proper global buffer.
> >>
> >As far as I know Synopsys, this is done only for external clock inputs
> >(i.e. inputs that drive only flip-flops or that are explicitly set to
> >pad-type "clock")
> >For internally generated clocks like the divided-by-X or multiplied-by-Y
> >or gated-by-Z input clock etc. you have to instantiate a BUFG clock
> >buffer (for XC4k) and set a dont_touch attribute to it.
> >BTW,in that case, if you use the timing constraint "clock" for that
> >signal you have to define it for the buffer output signal as the Xilinx
> >tools don't propagate such a constraint through a clock buffer.
> 
> Actually, with FPGA Express v3.3, if you create a divided clock, a la:
> 
>     clkdiv : process (fastclk, reset) is
>     begin
>         if reset = 0 then
>             slowclk <= '0';
>         elsif rising_edge(fastclk) then
>             slowclk <= not slowclk;
>         end if;
>     end process clkdiv;
> 
> and you then use slowclk for flops only, it WILL instantiate a clock buffer
> and that buffer's output will drive your slow-clocked flops clock inputs.
> Unfortunately, the tool gives the output of that buffer a stupid name (such
> as N3012) so every time you synthesize, you have to figure out hat the new
> name of the slow clock net is and edit your P+R constraints accordingly.
> 
> If anyone knows a way to apply a period constraint to flops clocked by the
> derived clock without having to figure out what the clock net is called, I'd
> love to hear it.
> -- a
> -----------------------------------------
> Andy Peters

Wouldn't instantiating a clock buffer be a good way to apply a period
contraint?


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23779
Subject: Re: BIST in FPGAs?
From: Robert Posey <muddy_take_out_this@raytheon.com>
Date: Fri, 07 Jul 2000 16:18:32 -0500
Links: << >>  << T >>  << A >>


rickman wrote:
> 
> Robert Posey wrote:
> >
> > rickman wrote:
> > >
> > > Robert Posey wrote:
> > > >
> > > > Rickman wrote:
> > > > >
> > >
> > >
> > > >You could get 100% coverage of I/O and Macro cells fairly
> > > > easily with special load modes, and even get 100% coverage of logic in each
> > > > cell at considerably more expense.  Getting 100% coverage of the RAM in the
> > > > part would be a little harder, if not impossible.
> > >
> > > I don't understand why this is hard. RAM is easy to test by loading and
> > > testing patterns. Each bit can be independently tested with simple
> > > patterns. The bits can be tested against the neighbors with more complex
> > > patterns. The largest array of RAM in a Xilinx part is 4K bits.
> > > Certainly this is not time exhaustive to test?
> >
> > The question is how can you access it,  to test a memory to 98% using a
> > venerable March II takes about 4 patterns, at 8 memory accesses per-cell,
> > per-pattern.  According to their website, XILINX XC4000XV has over
> > 270,000 RAM bits.  If you are using Serial Access mode, that means you have
> > to perform 270Kx4x8 ~= 8 Megabit Reads and Writes which I admit is not
> > impossible, takes awhile.  That only gives you 98% coverage of all hard and
> > soft faults.  I over-estimated how many RAM cells there where, so it is doable
> > even through the serial port.  I not well versed in the the RAM cell accessing
> > methods, but if its not random this number would go way, way up.  Of course for
> > to detect stuck at faults the number of patterns should be far less.  You can't
> > test individual RAM Bits, it must always be against its neighbors, to catch all
> > even hard faults.  The classic alternating A's and 5's only detects 1/2 the
> > data bit faults, and tests only 1 address line.  I am by no means saying that
> > you can't get upper 90's coverage, but you can't get 100% detection on anything.
> >
> > >
> > > > How could you test all
> > > > the possible BIT leakage combinations in a reasonable time.  You can test the
> > > > configuration RAM for a given operational load fairly well by reading back the
> > > > down load, but this is by no means a 100% coverage.  If you have a RAM Cell
> > > > that floats, it may return the correct value part of the time.  Then you have
> > > > the issue that all the RAM and Logic Cells have the potential to leak to
> > > > any cell that is close to in some manner.  RAMs have faults that cause certain
> > > > memory cells to change for a correct 0 to a 1, only when all surrounding
> > > > cells are also 1's.
> > >
> > > This is true for standard memory such as SRAMs. But the configuration
> > > memory is made of D FFs and are not co-located with memory from the
> > > other CLBs. So you don't have the same test problems that you have with
> > > SRAM.
> > To really know, you have to look at how isolated each piece is on the actual
> > die.  If the RAM cells are embedded in the logic, then the logic states may
> > cause unwanted changes or the reverse.  It is likely you are somewhat less
> > likely to have this problem in FPGA, than other Memories.
> >
> > >
> > > But that is not normally what we mean when we talk about coverage of
> > > test sets. We assume a much simplified failure model and test against
> > > that. Other failure modes need to be tested separately. So we would need
> > > a different set of test vectors to test against quantum fluctuations in
> > > the sub-space field.  ;)
> >
> > Hey for Reagen's Star Wars program to have worked, they would have had to
> > detect and correct for those on the fly to get the 100's million part system to
> > work. :)  Most of the difference is the location of the testing.  My tests run
> > over a large temperature range, and on systems exposed to radiation (hopefully
> > just in space).  If you read NASA pages on FPGA's you will find that they
> > feel the need to recheck the program load in the FPGA's periodically during
> > operation to correct Single Event Upsets of RAM Cells.  In Space Applications,
> > this is a real problem, and you can be fairly sure your system won't work
> > for long if you don't handle this issue.  There is also a severe shortage of
> > IC Test Machines on the battle field, thus all test support is in system.
> > I am well aware of what test coverage means in most of the commercial world,
> > but the original 100% poster was quoting someone from the defense industry that
> > has a well defined concept of failure detection that is based on failure rate,
> > and includes soft and hard failures.
> >
> > Robert Posey
> 
> Yes, I agree that no system can be tested 100% for all possible
> failures. But what is your point?
> 
> I did not see anywhere in the original post that this was a "defence
> industry" test issue. The thread started out asking about tools to
> insert scan chain registers. I was tying to make the point that by
> making use of the reconfiguration capabilities the parts could be tested
> just as well (to 100% by normal "stuck at" fault measures) without
> adding extra test logic in the FPGA.

It was in the second post on my list, but its not important.
> 
> But I will always agree when someone tells me that a system can not be
> shown to work by testing.
> 
> --
> 
> Rick 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
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
Article: 23780
Subject: Re: Clock Buffer
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 7 Jul 2000 17:05:19 -0700
Links: << >>  << T >>  << A >>
rickman wrote in message <396646B2.838BBDFA@yahoo.com>...
>Andy Peters wrote:
>> Actually, with FPGA Express v3.3, if you create a divided clock, a la:
>>
>>     clkdiv : process (fastclk, reset) is
>>     begin
>>         if reset = 0 then
>>             slowclk <= '0';
>>         elsif rising_edge(fastclk) then
>>             slowclk <= not slowclk;
>>         end if;
>>     end process clkdiv;
>>
>> and you then use slowclk for flops only, it WILL instantiate a clock
buffer
>> and that buffer's output will drive your slow-clocked flops clock inputs.
>> Unfortunately, the tool gives the output of that buffer a stupid name
(such
>> as N3012) so every time you synthesize, you have to figure out hat the
new
>> name of the slow clock net is and edit your P+R constraints accordingly.
>>
>> If anyone knows a way to apply a period constraint to flops clocked by
the
>> derived clock without having to figure out what the clock net is called,
I'd
>> love to hear it.


>Wouldn't instantiating a clock buffer be a good way to apply a period
>contraint?

Oh, absolutely it would.  But "it would be nice if I didn't have to do
that."  I mean, I'm not sure why the tool feels the need to give the
post-BUFGLSed net a bizarre name, esp. since, for input clock pins, it names
the buffered version something obvious such as sysclk_BUFG.

Actually, since the period constraint is applied to the pin before the
global buffer, whyizzit different for derived clocks?


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"A sufficiently advanced technology is indistinguishable from magic"
     --Arthur C. Clarke



Article: 23781
Subject: Xilinx 6200 series data sheets
From: Steve Oldridge <steveo@ece.ubc.ca>
Date: Fri, 07 Jul 2000 17:45:42 -0700
Links: << >>  << T >>  << A >>
Can anyone point me towards (or e-mail me) a copy of the Xilinx 6200
data sheets.  Xilinx no longer makes them available (as far as I could
find anyway) but they'd be invaluable for the research that I'm involved
with.
  Many thanks in advance
     Steve

Steve Oldridge
steveo@ece.ubc.ca
University of British Columbia M.A.Sc. Student

Article: 23782
Subject: Re: Canadian University
From: Steve Oldridge <steveo@ece.ubc.ca>
Date: Fri, 07 Jul 2000 18:13:44 -0700
Links: << >>  << T >>  << A >>
Alan Hu wrote:

> In article <395714B0.F9A192B6@opencores.org>,
> Jamil Khatib  <khatib@opencores.org> wrote:
> >Hi,
> >Could you please mention some good universites in Canada "English
> >speekers area" to continue my graduate studies in the Reconfigurable
> >Computing  and its EDA feilds.
> >
> >Please email me at khatib@opencores.org
> >
> >Thanks in advance
> >Jamil Khatib
> >
>
> University of Toronto is the default high-profile Canadian university,
> and they do have cool stuff going on in EDA and reconfigurable computing.
>
> UBC has great EDA research (including reconfigurable computing), too,
> plus we have better weather, better skiing, better hiking, ... :-)
>
>                                         --Alan Hu

I'd have to agree with Alan...  UBC has a great FPGA group, and we're
looking into reconfigurable computing, although the research is just
preliminary right now.  We've got students looking into both
FPGA/Microprocessor combinations as well as FPGA/ASIC groupings.  As far as
U of T, I looked into it when I was deciding where to do my Masters, but I'm
a West Coast boy through and through.  The style of life and the weather out
here can't be beat.  That and Steve is one of the best profs I've ever met.
Best thing to do is talk to the group heads.  Over here that'd be Steve
Wilton (http://www.ece.ubc.ca/~stevew/) and I'm not sure who now runs U of T
but their site is (http://www.eecg.toronto.edu/EECG/RESEARCH/FPGA.html).  If
you've got any other questions about UBC from a student's perspective you
can e-mail me at the address below.  Best of luck and let me know how it
goes because I'll probably be looking for a place to do a PhD in a year or
two...
  Cheers
     Steve

Steve Oldridge
steveo@ece.ubc.ca
M.A.Sc. Student ~ University of British Columbia
http://www.ece.ubc.ca/~steveo/


Article: 23783
Subject: Re: BIST in FPGAs?
From: rk <stellare@nospamplease.erols.com>
Date: Fri, 07 Jul 2000 21:31:11 -0400
Links: << >>  << T >>  << A >>
rickman wrote:

> Robert Posey wrote:
> >
> > Rickman wrote:
> > >
> > > I disagree that you can't get 100% coverage for test. I am sure that Xilinx
> tests every chip they make 100%. Since the chip is fully
> programmable, I doubt that they needed to design in special test circuitry or
> modes. Certainly this may take more than a single bit file.  But I am sure that you
> can test every transistor, every wire and every connection in a Xilinx FPGA if you
> need to do that.
>
> > Its an absolute fact you can't get 100% coverage of all the possible failure
> modes of an FPGA.
>
> Perhaps we need to qualify this statement. Certainly you can never get
> 100% coverage for ALL modes of failure. There are time variant failures the can
> never be detected by test unless you get lucky. I was referring to "stuck at"
> faults. These are the ones that can be systematically analyzed and accounted for
> and are most common. Less common are the "shorted" faults where two nodes are
> shorted together. Shorted faults do not result in a defined behavior. When shorted
> and driving different states, two nodes may drive a high, a low or an indeterminate
> value which has very poorly defined behavior (failing sometimes and not others). So
> "shorted" faults can not be systematically analyzed.

You can see these faults by looking at the Icc levels.  This generally falls under
the heading of IDDQ testing.  IDDQ testing definitely adds to the fault coverage and
while there is some overlap with stuck-at testing, is complementary.

----------------------------------------------------------------------
rk                               History will remember the twentieth
stellar engineering, ltd.        century for two technological
stellare@erols.com.NOSPAM        developments: atomic energy and
Hi-Rel Digital Systems Design    space flight. -- Neil Armstrong, 1994

Article: 23784
Subject: Re: BIST in FPGAs?
From: rk <stellare@nospamplease.erols.com>
Date: Fri, 07 Jul 2000 21:53:09 -0400
Links: << >>  << T >>  << A >>
rickman wrote:

       < major snippage >

> I did not see anywhere in the original post that this was a "defence
> industry" test issue. The thread started out asking about tools to
> insert scan chain registers. I was tying to make the point that by
> making use of the reconfiguration capabilities the parts could be tested just as well
> (to 100% by normal "stuck at" fault measures) without adding extra test logic in the
> FPGA.

I believe that the original poster was using Actel FPGAs with antifuse technology. For a
reprogrammable device, the situation can in fact get more complicated for 100% stuck-at
testing.  For example, you must show that each individual configuration logic bit can be
set.  You must also show that each individual pass transistor is capable of controlling
it's connection - being both open and closed.

Complicating things further is demonstrating that other architectural features do not
have any stuck-at faults.  For example, programmable delays (found in the I/O modules of
some FPGAs) and DLLs quickly come to mind.

- - - - - - - - - - - - - - -

> But I will always agree when someone tells me that a system can not be
> shown to work by testing.

Very much agreed.  One can not test in reliability.  I have seen many people declare
their systems bug free only to fail later, when environmental conditions change, a new
batch of parts come in, or Mr. Murphy comes home from vacation.

Have a nice evening,

----------------------------------------------------------------------
rk                               History will remember the twentieth
stellar engineering, ltd.        century for two technological
stellare@erols.com.NOSPAM        developments: atomic energy and
Hi-Rel Digital Systems Design    space flight. -- Neil Armstrong, 1994


Article: 23785
Subject: FPGA Internet Resources - Updated
From: <jmcdonald@eg3.com>
Date: Sat, 08 Jul 2000 02:27:38 GMT
Links: << >>  << T >>  << A >>
Hi,

We've updated our FPGA Internet resources at:

http://www.eg3.com/WebID/soc/fpga/net-rsrc/blank/hot-list/a-z.htm

Our goal for the summer is to look for free demo's, code, free seminars,
etc. - non-commercial stuff, either from vendors (yet not that
sales-oriented) or elsewhere on the Net.  If you know of something that we
do not index, please email pr@eg3.com.

Thanks.

--
Best regards,


Jason McDonald
Senior Editor
jmcdonald@eg3.com

------------------------------
http://www.eg3.com
eg3.com: window on the electronic design world

2.1 million hits per month - 150,000+ users:
tel: 408-938-9150 fax: 408-938-9155 email: inquiry@eg3.com

    audience:
       * software and hardware design engineers
       * programmers * oem decision-makers
       * management and chief executive officers

    categories:
       * applied computing * dsp * embedded chips
       * embedded software * embedded systems
       * industrial computing * internet
       * mcu/mpu * realtime * news * hi-tech marketing



Article: 23786
Subject: Where can I get Altera MAX+Plus2 9.x software?
From: "webber" <cslim@dreamwiz.com>
Date: Sun, 9 Jul 2000 00:13:38 +0900
Links: << >>  << T >>  << A >>
I want to study VHDL with MaxPlus2 9.x.
But I don't know to download.
Please known me the FTP address or so.


Article: 23787
Subject: Re: division in FPGA - help !
From: "Allan Redenbaugh" <aredenbaugh@whiterocknetworks.com>
Date: Sat, 08 Jul 2000 16:54:47 GMT
Links: << >>  << T >>  << A >>
Or use Xilinx's Coregen.  They have a pipelined divider with various
options.

Regards,
Allan Redenbaugh

"Kate Atkins" <kate.atkins@siraeo.noldckspam.co.uk> wrote in message
news:962637629.2771.0.nnrp-08.9e98b847@news.demon.co.uk...
> Hi Dan
>
> Take two binary numbers.
> Divide one by the other using pencil and paper.
> Turn what you just did into logic.
>
> Last time I did it there was a compare, a subtract and a shift. How long
you
> keep going round the loop depends on how much accuracy you need.
>
> Of course there may be better ways!
>
> Kate
>
> Dan <daniel.deconinck@sympatico.ca> wrote in message
> news:2xI75.21849$W35.537179@news20.bellglobal.com...
> > Hello,
> >
> > I am looking for 16 bit integer division. (I need to calculate averages)
> >
> > I just hope for a tip on technique. I do not need high speed.
> >
> > I use Xilinx.
> >
> > Sincerely
> > Dan DeConinck
> >
> >
> >
>
>
>


Article: 23788
Subject: Re: Xilinx 6200 series data sheets
From: "Dmitry Senjakin" <dmitrysn@farlep.net>
Date: Sat, 8 Jul 2000 20:08:05 +0300
Links: << >>  << T >>  << A >>
Steve Oldridge wrote ...
>Can anyone point me towards (or e-mail me) a copy of the Xilinx 6200
>data sheets.  Xilinx no longer makes them available (as far as I could
>find anyway) but they'd be invaluable for the research that I'm involved
>with.
>  Many thanks in advance
>     Steve

Hi !!!

        You can find PDF-file at :
http://dec.bournemouth.ac.uk/drhw_lib/archive/xc6200.pdf
A nice site about Reconfigurable Computing theme.

Dmitry



Article: 23789
Subject: Re: Where can I get Altera MAX+Plus2 9.x software?
From: "Carlhermann Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Sat, 8 Jul 2000 23:10:50 +0200
Links: << >>  << T >>  << A >>
Hi,

"webber" <cslim@dreamwiz.com> schrieb im Newsbeitrag
news:AAH95.7$ZV4.1180@news.hananet.net...
> I want to study VHDL with MaxPlus2 9.x.
> But I don't know to download.
> Please known me the FTP address or so.

Their baseline software is available @ http://www.altera.com

Greetings, Carlhermann


Article: 23790
Subject: PhD studentship: UK
From: alastairallen99 <alastairallen99@netscapeonline.co.uk>
Date: Sat, 08 Jul 2000 22:22:23 +0100
Links: << >>  << T >>  << A >>
UNIVERSITY OF ABERDEEN

CENTRE FOR ENVIRONMENTAL & INDUSTRIAL IMAGING

This multi-disciplinary research centre represents expertise in such
areas as computational image analysis, pattern recognition, holography
and instrumentation.  There is experience in a wide range of imaging
modalities and application areas, and an extensive network of links with
industry.  The work is supported by state of the art computational and
imaging equipment.

RESEARCH STUDENTSHIP

Applications are invited from UK/EU nationals for a three year PhD
Studentship.  The student will work on aspects of the representation of
image information, with an emphasis on multiscale techniques and
compression.  The immediate application area will be in the imaging of
deepsea marine life.  Project supervision will be joint between the
Departments of Engineering and Zoology.  The techniques developed will
have relevance to other environmental and industrial applications of
interest to the Centre.  The work will provide experience in
computational imaging, compression techniques, and embedded systems
engineering.

The funding of the studentship covers UK/EU tuition fees and a
maintenance grant equivalent to standard Research Council rates (UKP
6800 for 2000-01).  Applicants should have a good first degree
(equivalent of UK 1st class or upper second) in computational, physical,
engineering or mathematical science.  Informal enquiries may be directed
to Dr Alastair Allen, telephone: +44 1224 272501, fax: +44 1224 272497,
e-mail: a.allen@abdn.ac.uk

Application forms: Postgraduate Office, Department of Engineering,
Fraser Noble Building,  University of Aberdeen, Aberdeen, AB24 3UE, UK.
Tel: +44 1224 272513.  Fax: +44 1224 273895.  Email:
pgoffice@eng.abdn.ac.uk


Article: 23791
Subject: Re: Remedies after the Fathers' Day Massacre
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 09 Jul 2000 01:15:10 +0100
Links: << >>  << T >>  << A >>


Robert Binkley wrote:

> Simon,
>
> We answered that one too.
>
> MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped
> together) can now be found on Xilinx's web site at the following URL:
>
> http://www.xilinx.com/products/spartan2/s2_pin.zip
>
> There will be no page links for another week yet. After downloading, you
> can save the excel files as text files with different delimiters (see
> included readme file). Please let me know if you have any questions.
>

... and when will the same files appear for Virtex, VirtexE, ViretxII., XC4K,
SpartanI, XC95K etc.

 If you manage to get all of these on the Web in almost electronically readable
[still have manually dump the .csv files from Excel] Perl parseable form Xilinx
will have achieved an industry first far more pratically important than the
first GigaGate FPGA.



Article: 23792
Subject: Re: Remedies after the Fathers' Day Massacre
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 08 Jul 2000 23:29:11 -0400
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Robert Binkley wrote:
> 
> > Simon,
> >
> > We answered that one too.
> >
> > MS Excel spreadsheets for the Spartan-II pin-out tables (seven files zipped
> > together) can now be found on Xilinx's web site at the following URL:
> >
> > http://www.xilinx.com/products/spartan2/s2_pin.zip
> >
> > There will be no page links for another week yet. After downloading, you
> > can save the excel files as text files with different delimiters (see
> > included readme file). Please let me know if you have any questions.
> >
> 
> ... and when will the same files appear for Virtex, VirtexE, ViretxII., XC4K,
> SpartanI, XC95K etc.
> 
>  If you manage to get all of these on the Web in almost electronically readable
> [still have manually dump the .csv files from Excel] Perl parseable form Xilinx
> will have achieved an industry first far more pratically important than the
> first GigaGate FPGA.

Isn't it amazing how simple it can be to please customers? 

You just give them what they want!  :)


-- 

Rick 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

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23793
Subject: Nuke the Competition!
From: wqjchn@sdjxtrwhsh.gov
Date: 9 Jul 2000 17:17:52 GMT
Links: << >>  << T >>  << A >>

begin 666 ommom.jpg
M_]C_X``02D9)1@`!`0$`8`!@``#_VP!#`!`+#`X,"A`.#0X2$1`3&"@:&!86
M&#$C)1TH.C,]/#DS.#=`2%Q.0$1713<X4&U15U]B9VAG/DUQ>7!D>%QE9V/_
MVP!#`1$2$A@5&"\:&B]C0CA"8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V-C
M8V-C8V-C8V-C8V-C8V-C8V-C8V-C8V/_P``1"`#<`=D#`2(``A$!`Q$!_\0`
M'P```04!`0$!`0$```````````$"`P0%!@<("0H+_\0`M1```@$#`P($`P4%
M!`0```%]`0(#``01!1(A,4$&$U%A!R)Q%#*!D:$((T*QP152T?`D,V)R@@D*
M%A<8&1HE)B<H*2HT-38W.#DZ0T1%1D=(24I35%565UA96F-D969G:&EJ<W1U
M=G=X>7J#A(6&AXB)BI*3E)66EYB9FJ*CI*6FIZBIJK*SM+6VM[BYNL+#Q,7&
MQ\C)RM+3U-76U]C9VN'BX^3EYN?HZ>KQ\O/T]?;W^/GZ_\0`'P$``P$!`0$!
M`0$!`0````````$"`P0%!@<("0H+_\0`M1$``@$"!`0#!`<%!`0``0)W``$"
M`Q$$!2$Q!A)!40=A<1,B,H$(%$*1H;'!"2,S4O`58G+1"A8D-.$E\1<8&1HF
M)R@I*C4V-S@Y.D-$149'2$E*4U155E=865IC9&5F9VAI:G-T=79W>'EZ@H.$
MA8:'B(F*DI.4E9:7F)F:HJ.DI::GJ*FJLK.TM;:WN+FZPL/$Q<;'R,G*TM/4
MU=;7V-G:XN/DY>;GZ.GJ\O/T]?;W^/GZ_]H`#`,!``(1`Q$`/P#J****\,]`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHJGJ]_\`V9ILUWY?F^7CY<XSD@=<
M>]-)MV0-V+E%)D>O?N??%9TFM6T5C=W3)+LM)?*D7`W$@@9'/3D52A)]">9&
ME12<@9/0'!(Z?XT<X'')Z>]39CYD+13)ID@A>61@(XU+L?0#G^E9L6L.T.FE
M[;;-?-\L6_[J=2^<<X7!QUYJHTY2V$Y)&K12<XR>./UH)QGV_P#U5/*[[#NA
M:*3G'^?SZT=CUXZT6870M%)R/K_/_/UJI<WWV?4K*T\K<+GS/GW8"[5W?C34
M6W9!=%RBDS@\D<?AZ?X_RI>G7UQUQ2LPN@HI.>.V?7USC_/X4#D#!Z\46?8+
MH6BD_#&?7C'YU7L[V.],_E*X\B9H6##^(>GYC&<4U%O8+HLT5#<R31B(PP";
M=(%?YPNQ>[<]<>E2Y_\`K=.>_K[T<K"Z%HI.<=#CV&:.?\\TM]@NA:*ANYS;
M6<UQLW>4C.5!ZX!./TI+.<W5E;W&W;YL:OMSG&1G&<57([7871/12<]*/QY]
M_P#/%39A="T4G/\`B.X_SZ4=!D\#J21@#_/]:$KA="T4G(ZC%&<`FBS"XM%)
MSGIW_P`\T=3Q].F?ZYI\K"Z%HJG>7PM[JTMU3S);I\``XVJ.6;/MZ=ZMY(Z_
MKV^M'*[7%S(6BDSTR0,GO_GFCG(_S^OXTK,=T+12>GO5;3[Z/4;..ZA#*DF<
M!@,C!(Z?AUI\K"Z+5%(3@\_SHYS@CGT'^?\`(Q2LPNA:*3_/_P!>JVHWT>G6
M,EW,KM&F,A1SR<=^.XIJ+>E@NBU12?R[<4M*S3L.X4444@"BBB@`HHHH`***
M*`"BBB@`HHHH`****`"L?Q;_`,BW=_\``/P^=>:V*K:A8QZC9R6LK.J28R4(
M!X(/?Z5=-\LDQ25T8QTZ#3?$6E"V,@:=9EF=I"3)A<C.3Z\UB7&E62Z+J]P(
M?WMO>-'$VYCM4,HQC.#UZUV<]E%<7UM=.S;[??L`(P=RX.?R[54ET"TE:\#2
MSB.[SYD0D^0,2#N`]<@'_P"M75&LENS)Q90U/3;9=2T2QC#16_[\;4D()!&2
MNX\\\C\<58TZWBTSQ!-86@(MY;83["Q(5@VWCZCD_0=JBU#23+>Z3`7NY8HQ
M-ON"Q+H2`5)8=.<8^E:>G:9%IS3.LD\\LY!>2=]S-@8`SCMS1*2Y=P293U>)
M;'0TT^P_=?:)!;1<DA=YR<Y]1N^F126\4<WB'RXP%@TRW6.-6/(=QUSW&T8.
M3VJZFEQC[)YMQ<3_`&1BZ^<X;>3T+?3MZ5+:64=J\\BL[R7$F]W<C=TP%!]`
M.GI4^T2B[;CY3CX+*&#P@FK)O-[$P:.0N?W>)0.!TQ]1WK7_`+.ATSQ'I?V4
MR!YA,)Y-[%I2%!YY]>:T/[$MCHO]D^9*8>S;AN/S;O3%6)[**XO+:Y=G\RWW
M[`I&#N&#FCVVOWBY3CK:TO-4M6OTTJ22ZF<NEVEV$"-G@!.P&,8/OSTQL:I`
M;W4M!AO`\;R)(9E1L'[@)7/IP1UZ5<E\/VSW$SK<W<23,6D@2;;&Q/4$=><5
M<DT^![JTN!E#:!A$B8"@,NTC'MQTJI54]@Y3#L='LYM4U*P='-E;&-HX!(=N
M]D&6/.2?EX^IJC90B^A\.13R2;6^T`E7VDJ/X<]1G&/I760644%[<W:L_F7&
MS>#@A=HP,50/AJS-M:0&6X`M-_ELK;6RQSG('8X(^E"K*^K_`*L#BR/3H(M,
MU^;3[0%;:2V$^PL6"L&V\>G')SZ#M6!;VE[J=J]\NER27,\A9+M;L)L;=P`O
M8`C'/Y],=;IVF0Z>9I%DFFEF(,DD[[V(`X!X],_G59_#ULUQ(XN;N..5BTL*
M381\_>R.N#1&M!-ARLH2V7]H^(((]25E_P"):CS1JVT%MV""0>@/\AUJM<:<
MMC)<2:CIUW-!&Q%O=03%S#&.57:6X"C/)XS^O2)801Z@MXF5D6#[.%4@*JYS
MQ^'%5KG1+:XG>03W,*R',D44VV.4]RP]2.M"K*XG!]"]:NLMK$Z2-(K1@B0C
MEN.">`._2N,FT^VM]"UR>*+;+'=M;J=Q.$#H=O7]3Z5V)M%,]O(DCQK""%BC
M.$8$8P1W`[50G\/VDK78,]PD=T<R1+(-H.X,2`0>25_6IISA&XY1;*>IZ;:Z
M>-.-NK[Y+^'?([$LY&[DY[G/^<4U--MM1\2:NMVKR(GDXCWE5)*=3@\GT[<G
MU%;=Y8QWI@\TL/(F690IZLN<`\=.:R/[)-WK^IS2/=6P/E>7-`Q0NNS#`'H1
MD+^55&::O>P-%/S9/[)_LWS#Y8U+[%YFX^9Y>?7IG'?I[=*NQV5OHVNV45@I
MCBO(Y$EC+DJ=HW!N3][G'/KTK1_LBU_LC^R_F-OMVG#<YSG/Y\TW3](AL;EK
MG[1<W,Q0)YEQ)OPN<X'I2]K%WM_PX<K,)-/M]1\/76L7'F?;)4ED+AR-N,C:
M.<;<#H>?Z=#H_.CV/'_+O'G!_P!D>U5)_#EI/+.3/=K%.S.\*S?(6/?'KGG\
M*NQ6*1&S"33;;5=BH'&UQ@#YAW/&?QJ:DXR5@46C#33X-9DU.]NIC%-!<-'%
M*K_+"J`8;!/3U_3%37$$>IZO:6%Y+]HMXK/S]RM@2L2%W'!Y&.>/SQ5N]T"T
MO;IYI)IU\T+YL:RX6;;T+#_/2I[[28+U8,/-;-!GRC;ML*@C&T'IV'Y57M8Z
M!RLYW45^QZ7KFGQ9\BV>%XLL24WD$@9Z#]?<U9N='MK76=.MX#*JW8E2Y<.=
MTH4*V"<\`D=L5J#0K4Z3+I_F3LD[^8\A<%W8D'))X[#\JM3V44][:W3,WF6V
M[8`1@[A@Y_\`K4W6C=68<O<S-"@CL]6U:T@W+;Q&$HNXD+N0DGGN3BDUZV2Z
MUW1X)2ZH_G;MK;"1M&5SZ'&/Q-:L%E'!?7-TC-YEQLW`D8&T8&/U_*L?4-(,
ME[I-MYEU+#&)M]P6.Y"1E6+#ISC'TJ5)2G?^M@:=K#%":)J-];6"_N?L)N5C
M=B0KKD8&3G!`Y'7\*R[73]0-M;7EII;F[RLPNFO`?,[G<,]#SQU_7/5:=ID>
MG-,Z2SS23$&229]S-@<#.![_`)U4A\.6D15?M%T]LK;OLSRYBZY`(],\U:K1
MNQ<C8Y?],\4,W)CL80J`\$/(,Y&.OR\'WZ#BL/3M(MI/"7]H,9?M42.\4@D(
M\O:Q(`[`<$_C[UU5K9QVKSRJSO)/(9'9CECZ`8'0#I7/Z/X=CGTF$73WD+-G
MSK?S"BN0QP2I]@OY4HS7+N#B[DK*NMZC8V]\,P?81=,B.RAG)QR>O';O_*HT
MM[E8-9TG37=/(:-X#YAS\PW%0?3C@>_)-;>I:9%J+0NTD\,L))CD@?:P!&",
M^_\`GK3;?2+2&PEM'5YXIF+RF4[F<G^(GUX'Y9I>UA8?*S'TV&QAO5LY+&ZT
M^2X1T>(REX9AW&_G)`YR,8/%5--@L+?PK;W$RW.;F0(Z6['=<$.P"=?3TQT]
M:Z&STB*UN!</<7-U*H(5KB3?LSU"^F>/RJ!?#MHMLT"W%T(_,62,";_4,"3\
MGIU/7/;TJO;1;#E9G:#']F\1R1164MC"]KO$+R$[_GP&(R<'!(QVP?6H8M.@
MU#PY<ZO/YGVR5)9"ZN0%QD;<9QC"]#SBMVST6VL[I;F.:=IRI1Y)'W&13C&[
M/88&,8Z"N>O+5I?M"#3-52YN&)-NKAK<2-T8L/3AO8\=!51DI.Z)=T36UC#J
M&IV$-QN,7]DQLR*Y4.0>`<>^#^%5[J"(>%]6CP2MI?LL`+D[!N48'J/F/'X]
M:Z2QTM+9K>>1_P!_%:K;,%/R8&"2,C.<T-H]LUG>6LC2&.ZE,KY8`JQQR#[8
MS4NM'F*Y6RU:VL-E;I;VR;(DSM&2>I)[\U/4-G;_`&6V2'S99=N</*VYCDYZ
M_C4U<<G>5S2*L%%%%24%%%%`!1110`4444`%%%%`!1110`4444`%%%%`!111
M0`G;':@<=.*6B@`_3Z4444`)_+TI?Q-%%`!^-%%%`!1]***0"8]A2_G113`*
M***`"CD=***`$Q2T44`%%%%`!1UHHH`/QHQ110`?UH^M%%`!VQVH[8[>E%%"
MT`3%+^)HHH`*.V***`$P#VI:**`"BBB@`H]J**`#%'2BB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
MB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****
M`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`
M****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`H
MHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BBB@`HHHH`****`"BB
,B@`HHHH`****`/_9
`
end

Article: 23794
Subject: I/O Help
From: "Andrew Buckin" <ipm_grp@iptelecom.net.ua>
Date: Sun, 9 Jul 2000 20:49:21 +0300
Links: << >>  << T >>  << A >>
Whether it is possible to reprogram MAX7000S on ByteBlaster if JTAG pin will
be used for I/O



Article: 23795
Subject: Xilinx Data memory
From: lamb_baa@hotmail.com (Eric L)
Date: 9 Jul 2000 19:42:15 GMT
Links: << >>  << T >>  << A >>
In Xilinkx Appnote XAPP058 it says it requires a "Xilinx Data Memory". Is that 
just static RAM?

Thanks
Eric

Article: 23796
Subject: Re: Clock Buffer
From: Utku Ozcan <ozcan@nortelnetworks.com>
Date: Mon, 10 Jul 2000 01:55:10 +0300
Links: << >>  << T >>  << A >>
> Oh, absolutely it would.  But "it would be nice if I didn't have to do
> that."  I mean, I'm not sure why the tool feels the need to give the
> post-BUFGLSed net a bizarre name, esp. since, for input clock pins, it names
> the buffered version something obvious such as sysclk_BUFG.
>
> Actually, since the period constraint is applied to the pin before the
> global buffer, whyizzit different for derived clocks?

I wonder how you could apply some UCF constraints to the output
of Synopsys FPGA Express. I think you don't have a schematic
view option of the synthesis output, then you have to search
the XNF or EDIF file, for example, to apply clock-domain constraint
or special constraints. You have to know the signal name and if
the tool generates a different name for each pass, it is overkill
to deal with. Synplify has a graphical technology view, which
enables us to generate UCF constraints very fast.

Utku

--
I feel better than James Brown.



Article: 23797
Subject: JTAG headers
From: Bill Lenihan <lenihan3we@earthlink.net>
Date: Mon, 10 Jul 2000 06:45:34 GMT
Links: << >>  << T >>  << A >>
Does anyone know a good source (& part number) for a 6-pin (power &
ground + 4 JTAG signals) 'header' that can handle the flying leads of
the Xilinx JTAG pod(s)?

--
==============================
William Lenihan
lenihan3weNO@SPAMearthlink.net
==============================


Article: 23798
Subject: Re: Xilinx Design Flow
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Date: Mon, 10 Jul 2000 09:13:59 +0200
Links: << >>  << T >>  << A >>
Jens Popp wrote:
> till now we run our lab (3rd & 4th semester) with the xilinx design flow
> from cadence. Unfortunately Europractice does not longer support this
> design flow.
> 
> So I'm searching for a new design environment. I've tested Xilinx
> Foundation and found it quite good, but only aviable for Windows. The
> Solaris version (Alliance) hasn't the required features.

Hi Jens,

you could try FPGA Advantage from Mentor. We also dropped Cadence half
a year ago, and so far, the tools run fine. It's a package of
Renoir (Design Entry: block, FSM, flowchart, truth table editors),
Modelsim (Verilog/VHDL simulator), and
Leonardo Spectrum (FPGA/ASIC synthesis).
We are running them on Solaris.

There are some nice demo videos on the Mentor site, just have a look
at them.
A very good feature is the crossprobing between all tools. We will
use them together with the Alliance software.
There is a University package of 5 license for each tool for 10kDM.
If you're interested, i could give you the email/phone of a good
distributor.

Lars
-- 
Address:  University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel:      +(49) 621 181-2716, Fax: -2713
email:    larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Article: 23799
Subject: Re: Clock Buffer
From: Jens Hildebrandt <hil@e-technik.uni-rostock.de>
Date: Mon, 10 Jul 2000 09:17:24 +0200
Links: << >>  << T >>  << A >>


Andy Peters wrote:
> 
> Jens Hildebrandt wrote in message
> <39658097.32F7DDE9@e-technik.uni-rostock.de>...
> >
> >
> >Andy Peters wrote:
> >>
> >> Kai Schulze wrote in message <3964734C.D088118F@ee.nec.de>...
> >> >Hi,
> >> >
> >> >I'm working with a XILINX XC40250XV and I have following problem:
> >> >
> >> >There is an signal input port and a internal clock should be generated
> >> >from this signal.
> >> >How can I push synopsis to create the internal clock buffer for this
> >> >internal clock automatically.
> >> >Is there at all a way to say "synopsis do this".
> >>
> >> If that signal is connected to only flip-flop clocks, the tool should
> infer
> >> the proper global buffer.
> >>
> >As far as I know Synopsys, this is done only for external clock inputs
> >(i.e. inputs that drive only flip-flops or that are explicitly set to
> >pad-type "clock")
> >For internally generated clocks like the divided-by-X or multiplied-by-Y
> >or gated-by-Z input clock etc. you have to instantiate a BUFG clock
> >buffer (for XC4k) and set a dont_touch attribute to it.
> >BTW,in that case, if you use the timing constraint "clock" for that
> >signal you have to define it for the buffer output signal as the Xilinx
> >tools don't propagate such a constraint through a clock buffer.
> 
> Actually, with FPGA Express v3.3, if you create a divided clock, a la:
> 
>     clkdiv : process (fastclk, reset) is
>     begin
>         if reset = 0 then
>             slowclk <= '0';
>         elsif rising_edge(fastclk) then
>             slowclk <= not slowclk;
>         end if;
>     end process clkdiv;
> 
> and you then use slowclk for flops only, it WILL instantiate a clock buffer
> and that buffer's output will drive your slow-clocked flops clock inputs.
> Unfortunately, the tool gives the output of that buffer a stupid name (such
> as N3012) so every time you synthesize, you have to figure out hat the new
> name of the slow clock net is and edit your P+R constraints accordingly.
<snip>

Well, seems to be one more reason to convince my Synopsys admin to
install a newer version, since with our current synopsys_1998_08 tools
no clock buffers are inferred for derived clocks. I just checked it out
with the following design:

entity clkbuftest is
	port(clk: in std_logic;
	     reset: in std_logic;
	     data: in std_logic_vector(7 downto 0);
	     sl_dat: out std_logic_vector(7 downto 0);
	     fst_dat: out std_logic_vector(7 downto 0)
	    );
end clkbuftest;

architecture behav of clkbuftest is
 SIGNAL sl_clk: std_logic;
begin

 divider: process(clk, reset)
 begin
   if (reset = '1') then
     sl_clk <= '0';
   elsif (clk'event and clk = '1') then
     sl_clk <= not sl_clk;
   end if;
 end process;

 sl_ff: process(sl_clk, reset)
 begin
   if (reset = '1') then
     sl_dat <= (others => '0');
   elsif (sl_clk'event and sl_clk = '1') then
     sl_dat <= data;
   end if;
 end process;

 fst_ff: process(clk, reset)
 begin
   if (reset = '1') then
     fst_dat <= (others => '0');
   elsif (clk'event and clk = '1') then
     fst_dat <= data;
   end if;
 end process;
end behav;

The only BUFG component inferred is that for the clk-input.
May be this is due to the older version of my Synopsys tools or are
there some extra configurations needed in the .synopsys_dc.setup file?

Jens


Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search