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 11925

Article: 11925
Subject: Re: Confused teacher's THANKS
From: ems@nospam.riverside-machines.com
Date: Sat, 19 Sep 1998 10:52:31 GMT
Links: << >>  << T >>  << A >>
On Fri, 18 Sep 1998 17:56:49 +0100, Jonathan Bromley
<jsebromley@brookes.ac.uk> wrote:

>As a follow-up, I would be extremely intrigued to hear views
>from experienced designers and employers about how successfully
>the universities provide (or not!) the right skill-set in
>fresh-from-college EE graduates.

Very good point. In the last 15 years, I don't think that I have
*ever* met an EE (or any other) graduate who would be remotely useful
as a paid engineer in any company that I've worked for (however, I
have met a few recent science or maths graduates who were very good
softies).

I don't think the problem has been education, but simply intelligence
and experience (or lack of them). You need much more experience to be
a good engineer than to be a good programmer. And education isn't that
important - one of the best engineers I know doesn't even have a
degree.

But, while we're on the subject of what you should actually teach an
undergraduate, I've noticed that a lot of courses now involve
something along the lines of learning some VHDL, learning some tools,
and doing a design in an FPGA. This is a complete waste of time, and
is rather like teaching an author to use a typewriter - the skill
isn't in how you type, but what you type. I don't need a graduate who
knows how to drive Foundation/Max Plus/whatever - the tools will be
completely different in a couple of years. You might as well just
teach them Word for Windoze. What *would* be useful, however, is a
graduate who knows how to get a clock from one end of a PCB to
another, who knows how to build a state machine (clocked or otherwise)
using only a pencil and paper, and who can do some basic design with
7400-series logic. But, of course, you don't need to spend three years
learning this - I did most of the basics in a few weeks while doing a
Physics degree.

Evan

Article: 11926
Subject: Re: sync or async SRAM?
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Sat, 19 Sep 1998 12:23:56 +0100
Links: << >>  << T >>  << A >>
In article <6tumal$62u@src-news.pa.dec.com>, Stefan Ludwig
<ludwig@pa.dec.com> writes

>You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
>and are just wonderful. Micron, Motorola and IDT make them.
>

Interfacing to ZBT rams using Xilinx 4000 series FPGA's is complicated
by possible data bus contention when changing from a write to a read
cycle. The Xilinx tristates the data bus much later (clock to hi-Z)
about 10 ns) than the ram drives the bus (clock to lo-Z about 2 ns). The
Micron web-site has articles about this, and the implications on
increased power-dissipation.

In the new 4000XLA devices, the IOB's have a registered tri-state, which
helps a lot. 

NB, Cypress make almost pin-compatible versions called NOBL (NO Bus
Latency), and i think also ISSI.
-- 
Edward Moore
Article: 11927
Subject: Re: Xilinx Configuration Info
From: APS <resp@associatedpro.com>
Date: Sat, 19 Sep 1998 08:47:05 -0400
Links: << >>  << T >>  << A >>
Rickman,

The APS-X84 manual which is available on line at our website, has
information, and C code examples for doing this. Our website is
http://www.associatedpro.com. The code is loading the FPGA from the ISA BUS
but it should be the same process. Hope this helps.

Rickman wrote:

> I remember there being some posts on info from the Xilinx web site on
> the configuration process. Can someone repost where I can find that
> data. I have searched using their search tool and can't find what I am
> looking for. All I can find is the section out of the data book on
> configuration. I thought there was an app note on downloading from a uC.
>
> I need to put together a clear enough description that the software
> developer can code it. That can be quite a job sometimes.  ;)
>
> --
>
> Rick Collins
>
> redsp@XYusa.net
>
> remove the XY to email me.
>





--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11928
Subject: Re: VHDL Tools
From: APS <resp@associatedpro.com>
Date: Sat, 19 Sep 1998 09:06:08 -0400
Links: << >>  << T >>  << A >>
All of the one's you mentioned are good tools. You might also look at Accolade's
PeakVHDL suite. It can handle all the vendors you mentioned and is a very good
buy. I have used all the vendors you have mentioned. We sell Accolade and the
XILINX Foundation Series (FPGA Express). We also sell FPGA Test Boards which are
very helpful for algorithm development and overall testing. Simulation is great,
but you can't beat actuals. As far as ASICs, if that is going to be a major
emphasis, you may want to look at the Exemplar stuff again. One of their main
strong points is  ASIC retargeting. The Accolade suite is nice, in that it
includes a VHDL simulator. MINC, also uses Accolades VHDL simulator. Accolade is
the small guy on the block, but they have some really nice features. The
simulator and synthesis tool are integrated, and the price their entire suite is
usually about the price of a one VENDOR synthesis (with no simulator) from the
other guys. Exemplar, Synplicity, and Synopsys FPGA Express are all priced very
close to each other. They are a bit pricier but you will happy with them.
Synopsys didn't have VHDL 93 support, but they do now. Anyway our website is at
http://www.associatedpro.com   You can get a free Accolade software download
there. Also if you are just starting in FPGAs and are sticking with just one
vendor, you can't beat the XILINX Foundation kits, The VHDL and VERILOG
synthesis and ROUTER tools, VHDL editor and VHDL tutorial  are all packaged
together. And through APS you also get an FPGA test board with priceless app
notes. Our prices on the Foundation kits are usually lower than you can get
elsewhere, and you can only get the FPGA board from us. Anyway, hope all this
helps. Contact me if I can be of further help.

Ronald Hakola wrote:

> Our company is just starting to think in terms of VHDL.  My task is to
> decide which tools we will be using.  Have looked at Exemplar Leonardo
> Spectrum and Synplicity's Synplify for synthesizing.  Aldec's VHDL simulator
> and Model Sim. for simulators.  Also planning on looking at Minc and FPGA
> Express.  Any other suggestions??  Any comments on the quality of these
> programs from the users.  Design goal is FPGAs: Xilinx, Orca, and Actel for
> a start, possibly ASICs in the future.
>
> Thanks for all comments.
>





--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 11929
Subject: Re: sync or async SRAM?
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Sat, 19 Sep 1998 10:56:40 -0400
Links: << >>  << T >>  << A >>
When I last looked at the ZBT's for an application where I had interleaved read
writes there was an issue on the timing.  I don't recall for sure, but I think
there was a dead cycle caused by the way I needed to access it.  I'll look into
my notes and let you know what the issue was.  Whatever it was, in that
particular case it was an expensive solution that didn't quite fix the
problem.  (I was looking at the IDT parts, and that was right after they were
introduced).

Stefan Ludwig wrote:

> You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles
> and are just wonderful. Micron, Motorola and IDT make them.
>
> Stefan


--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 11930
Subject: Re: ASIC -> FPGA async issues
From: jhallen@world.std.com (Joseph H Allen)
Date: Sat, 19 Sep 1998 17:08:25 GMT
Links: << >>  << T >>  << A >>
In article <3602DEA7.1C47@dial.pipex.com>,
Mark Purcell  <map@dial.pipex.com> wrote:

>What about SRAM based FPGAs causing glitches? For example, a classic
>combinatorial feedback loop like the following:

>OUT = START | HOLD & OUT;

>may not work due to the gates themselves being implemented using SRAM
>lookup tables. The output may glitch or even fail to latch at all (to
>see this think what happens when the logic latches - once latched it
>should be invariant to transitions on START, but since it's an SRAM
>there is a settling time when OUT will be invalid as the new 'address'
>is looked up. This invalid state is fed back causing more invalid
>states). Also using gray coded signals and ORing them to form glitch
>free outputs can also cause problems. SRAM based FPGAs such as Xilinx
>4000 type devices should be avoided if the design contains any
>combinatorial logic that is to remain glitch free (this goes for clock
>domain resynchronizing too if gray coded FIFO flags are decoded and used
>for resynchronization).

This is not true.  The SRAM in all SRAM-based FPGAs is not used in the way
that you think.  I.E., logic block inputs are not the same as conventional
glitchy SRAM address line decoders.  Instead they are the select lines for
something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a
4-input logic block.  The 16:1-MUX inputs are connected to the configuration
SRAM bits. The result is that a single input transition on a select line is
guarenteed to generate either a single glitch-free output transistion or a
glitch-free non-transition.  The actual circuit used is balanced (probably
with different buffer sizes driving each level of 2:1 MUX or something) and
tries to give roughly equal propogation delay for each select line.

Combinatorial latches like your example work just fine.  They are generally
not used because the built-in flip-flops are faster and not subject to
routing delays.  However, they are sometimes useful because the global reset
line does not effect them.  You can use this trick to distinguish between
warm or cold boot, for example.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 11931
Subject: Re: ASIC -> FPGA async issues
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Sep 1998 01:20:55 -0400
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
> In article <3602DEA7.1C47@dial.pipex.com>,
> Mark Purcell  <map@dial.pipex.com> wrote:
> 
> >What about SRAM based FPGAs causing glitches? For example, a classic
> >combinatorial feedback loop like the following:
> 
> >OUT = START | HOLD & OUT;
> 
> >may not work due to the gates themselves being implemented using SRAM
> >lookup tables. The output may glitch or even fail to latch at all (to
> >see this think what happens when the logic latches - once latched it
...snip... 
> This is not true.  The SRAM in all SRAM-based FPGAs is not used in the way
> that you think.  I.E., logic block inputs are not the same as conventional
> glitchy SRAM address line decoders.  Instead they are the select lines for
> something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a
> 4-input logic block.  The 16:1-MUX inputs are connected to the configuration
> SRAM bits. The result is that a single input transition on a select line is
> guarenteed to generate either a single glitch-free output transistion or a
> glitch-free non-transition.  The actual circuit used is balanced (probably
> with different buffer sizes driving each level of 2:1 MUX or something) and
> tries to give roughly equal propogation delay for each select line.
> 
> Combinatorial latches like your example work just fine.  They are generally
> not used because the built-in flip-flops are faster and not subject to
> routing delays.  However, they are sometimes useful because the global reset
> line does not effect them.  You can use this trick to distinguish between
> warm or cold boot, for example.

I have heard this from somewhere else, I believe, but are you sure that
there are no glitches? In general, a mux is not guaranteed to be glitch
free when a single select line changes. A mux is just a collection of
AND gates followed by an OR gate. Only one of the AND gates will have
all of its inputs true at any given time. As one select line changes,
the currently selected AND gate is deselected and the next AND gate is
selected. If there is any difference in prop delay for the two paths,
there can be a glitch on the output. 

You (Xilinx) might be able to prevent a glitch by making one edge faster
than the other. Your (Xilinx's) mux could be constructed with a buffer
and an inverter from each select input feeding all of the AND gates. The
prop delay of the buffer and the inverter should match closely. The
delay for the rising edge to the AND gate should be less than the delay
for the falling edge by more than the tolerance of the delays. Then you
could always guarantee that one AND gate is enabled before the other was
disabled. This would provide glitch free operation. 

Or it could be possible to make the prop delays match closely enough
that a slow output on the OR gate would act as a glitch filter. But this
may not be desirable. 

Someone (I don't remember his name) who works for (used to work for)
Xilinx has posted about some internal design issues before. That was on
the reasons behind the limitations on the dual ported ram. Perhaps he
could answer this one??? Or maybe Peter A.???


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 11932
Subject: Re: Confused teacher's THANKS
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Sep 1998 01:39:03 -0400
Links: << >>  << T >>  << A >>
ems@nospam.riverside-machines.com wrote:
...snip... 
> But, while we're on the subject of what you should actually teach an
> undergraduate, I've noticed that a lot of courses now involve
> something along the lines of learning some VHDL, learning some tools,
> and doing a design in an FPGA. This is a complete waste of time, and
> is rather like teaching an author to use a typewriter - the skill
> isn't in how you type, but what you type. I don't need a graduate who
> knows how to drive Foundation/Max Plus/whatever - the tools will be
> completely different in a couple of years. You might as well just
> teach them Word for Windoze. What *would* be useful, however, is a
> graduate who knows how to get a clock from one end of a PCB to
> another, who knows how to build a state machine (clocked or otherwise)
> using only a pencil and paper, and who can do some basic design with
> 7400-series logic. But, of course, you don't need to spend three years
> learning this - I did most of the basics in a few weeks while doing a
> Physics degree.
> 
> Evan

I agree with much of what you say. I think that a lot of "pratical"
skills were left out of my education that I then had to learn OJT. All
of the things that you mention would have been useful. But some of them
typically are taught. I learned state machine design. Of course it was
by means of present state/next state (PS/NS) tables and hand
calculations. But state machine design nontheless. 

I was also taught a lot about general logic design. That was the focus
of both my undergraduate as well as my graduate classwork. The graduate
work was in multivalued logic design which was really a thinly disguised
Math course in Post Algebra. Not much use for that even now. 

But I feel strongly that students should be taught not just the basics
of signal propagation, but should be taught fully what happens when you
move signals across a board, across a backplane and even between
chassis. I assume that the schools feel that the core classes give you
the tools to solve these problems. But the real world is full of unusual
problems, practical solutions and just plain suprizes. 

I do disagree on the usefulness of learning an FPGA development tool.
Even if the student did not learn the tool you are using, he is better
off to have learned A tool and to have learned the FPGA design process.
It is especially useful to have learned the limitations of FPGA design,
both in the tools and in the chips. 

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 11933
Subject: Re: ASIC -> FPGA async issues
From: fliptron@netcom.com (Philip Freidin)
Date: Sun, 20 Sep 1998 10:27:26 GMT
Links: << >>  << T >>  << A >>
In article <360490B7.B04231A5@yahoo.com> Rickman <spamgoeshere4@yahoo.com> writes:
>Joseph H Allen wrote:
>> 
>> This is not true.  The SRAM in all SRAM-based FPGAs is not used in the way
>> that you think.  I.E., logic block inputs are not the same as conventional
>> glitchy SRAM address line decoders.  Instead they are the select lines for
>> something like a tree of 2:1 glitch-free MUXs which build a 16:1 MUX for a
>> 4-input logic block.  The 16:1-MUX inputs are connected to the configuration
>> SRAM bits. The result is that a single input transition on a select line is
>> guarenteed to generate either a single glitch-free output transistion or a
>> glitch-free non-transition.  The actual circuit used is balanced (probably
>> with different buffer sizes driving each level of 2:1 MUX or something) and
>> tries to give roughly equal propogation delay for each select line.
>> 
>> Combinatorial latches like your example work just fine.  They are generally
>> not used because the built-in flip-flops are faster and not subject to
>> routing delays.  However, they are sometimes useful because the global reset
>> line does not effect them.  You can use this trick to distinguish between
>> warm or cold boot, for example.
>
>I have heard this from somewhere else, I believe, but are you sure that
>there are no glitches? In general, a mux is not guaranteed to be glitch
>free when a single select line changes.

Joseph is absolutely right about the glitch free nature of the LUTs when a
single input changes, and the condition of other inputs makes the change
not have any effect on the output. The muxes that follow the LUT are
glitch free for single input transitions where the before and after values
are the same. More details on how this works in next para.

>A mux is just a collection of AND gates followed by an OR gate.

Not in a Xilinx FPGA following the LUT memory cells. It is a tree of pass
transistors, and the outputs of the LUT bits are static, and have
pre-charged the tree up to the FETs that will change when you change a
single input signal to the LUT. Since the eqn for before and after the
change have the same value ( for the cases where you are worried about the
glitch), when the change occurs, you are switching from one copy of the
value to another. There is nothing in the area that could swing it to the
other value. The change is very fast (probably sub nanosecond in current 
products).

Here are the two scenarios:
1) Turn off is faster than turn on: The parasitic capacitance on the
   the output node will hold the level till the second fet turns on.
   There is no static current drawn on this node so there is no motivation
   for it to change to the other level. The load is either another 
   similar mux, or the high impedance of an inverter.
2) Turn off is slower than turn on: Since both paths have the same value,
   for a short while (sub nanosecond) both sides of the mux drive the
   output with the same value.

>Only one of the AND gates will have
>all of its inputs true at any given time. As one select line changes,
>the currently selected AND gate is deselected and the next AND gate is
>selected. If there is any difference in prop delay for the two paths,
>there can be a glitch on the output. 

True description of a gate based mux, but not relevant for this case.

>You (Xilinx) might be able to prevent a glitch by making one edge faster
>than the other. Your (Xilinx's) mux could be constructed with a buffer
>and an inverter from each select input feeding all of the AND gates. The
>prop delay of the buffer and the inverter should match closely. The
>delay for the rising edge to the AND gate should be less than the delay
>for the falling edge by more than the tolerance of the delays. Then you
>could always guarantee that one AND gate is enabled before the other was
>disabled. This would provide glitch free operation. 

As you can see above, there is a far simpler way to get it to be glitch
free. No need for fancy delay matching either.

>Or it could be possible to make the prop delays match closely enough
>that a slow output on the OR gate would act as a glitch filter. But this
>may not be desirable. 
>Someone (I don't remember his name) who works for (used to work for)
>Xilinx has posted about some internal design issues before. That was on
>the reasons behind the limitations on the dual ported ram. Perhaps he
>could answer this one??? Or maybe Peter A.???

Who could it be ????

All the above information is pubicly available. With some effort, you can
actually find out a lot about the detailed internals of these devices,
because of the very large number of patents that have been filed by all
the FPGA companies. To see the gory details of the above, there are many
patents that show the detailed schematics.  An example would be 5,566,123,
but there are many others. My favorite site for this is

	http://patent.womplex.ibm.com

Philip Freidin

Article: 11934
Subject: Re: Xilinx Spartan and 4K speed grades
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Sun, 20 Sep 1998 11:45:26 -0000
Links: << >>  << T >>  << A >>
Matthew Robinson wrote in message <6tpdfh$388$1@supernews.com>...
>So am I going crazy or is a -3 Spartan part slower than a -4, whereas in
the
>4K series, the -3 was the faster part?
>
>Curiuosly,
>Matthew
>

Matthew,
   The response that Ed McCauley gave you tells it all.
   I just wish that Xilinx had stuck with the XL family way of describing
speed.  I do not care if 09 or 08 means 900 or 800 picoseconds, I can handle
that.  I think that the time through a 4 variable LUT (or some well
established circuit) is a good measure of how fast a design will be, if you
know how to use that parameter.  Giving an FPGA a meaningless number like
the Spartan family has makes it more difficult to determine how fast a
design will be.  In fact, I always used to tell the Orca guy that they
should change their way of gauging a part's speed to the way Xilinx did it!
-Simon Ramirez


Article: 11935
Subject: Re: Xilinx ncd files
From: Nick Hartl <"nhartl[no_spam]"@earthlink.net>
Date: Sun, 20 Sep 1998 06:51:38 -0500
Links: << >>  << T >>  << A >>


Philip Freidin wrote:

> A major advantage of using this batchfile to process your designs, is that
> unlike Xilinx's design manager, it doesn't litter your disk with 10's
> (or 100's ) of megabytes of unwanted files in \rev and \ver directories.
> I continue to be amazed that Xilinx's design manager goes to so much
> effort to maintain all these directories of files for different revisions
> and versions of your design, all of which could be recreated from the
> original design, but the one thing that it won't manage is the revisions
> of the design it-self, which is the only thing that actually needs
> revision control.
>

*****Check the M1.5 Design Manager there is now a a feature to allow copying of extra files i.e. the design files with each new
version/revision. Menu Design=>Properties =>Version List.

You are right a rev with out a source is useless.  But now one can save the source as well.

Have FUN!!!
Nick

> Hope your project goes well.
>
> Philip Freidin.



Article: 11936
Subject: Re: sync or async SRAM?
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Sun, 20 Sep 1998 15:00:08 -0000
Links: << >>  << T >>  << A >>
Stefan Rave wrote in message <35FFDBFD.41C67EA6@LS12.cs.uni-dortmund.de>...
>What is the best choice for use with an XC4000XL FPGA: synchronous or
>asynchronous SRAM? What's the advantage of synchronous SRAM, anyway?

Stefan,
   The best choice of SRAM can only be answered by you, because only you
know what the application is.  You have constraints and parameters that we
do not know about; therefore, only you are capable of answering that
question.
   The advantage of synchronous SRAM is that it breaks up the total path of
delays into two paths of delay.  These two paths have less time associated
with them than the longer path used by asynchronous SRAM, which makes the
design faster.
   For example, assume that in your design the FPGA is generating the
address and using the data provided by the SRAM during a read cycle.  If you
are using asynchronous SRAM, you have the clock to address out time (FGPA),
then the access time of the SRAM (data valid after address valid), then the
setup time of the FPGA to capture the data.
   If you use a synchronous SRAM, you have the clock to address out time
(FPGA) and setup time (SRAM) for the first clock cycle.  This path is less
than the path described in the above paragraph for the asynchronous SRAM.
The second path is clock to data valid out (SRAM) and setup time (FPGA) for
the second clock cycle.  This path also is less than the path described
above.
   While you can run the clock cycles faster, it takes two clock cycles to
get one piece of data out, right?  What if you want burst data out of the
SRAM?  Then it takes three clock cycles to get two pieces of data, four
cycles to get three pieces of data, etc.  So if you burst 256 pieces of
data, you need 257 clock cycles.  The advantage of synchronous SRAM is that
these clock cycles are much faster than clock cycles of the asynchronous
clock cycles.
   Also, the reason that Bob Perlman thought that you were talking about
synchronous SRAMs in FPGAs is because this is an FPGA newsgroup!
Fortunately for all of us, Xilinx and others gave us the ability to use
internal SRAM, synchronous and asynchronous.  So naturally I can see where
he assumed that you were talking about internal SRAM.
   I hope this helps.
-Simon Ramirez


Article: 11937
Subject: Revision 1.27 of David Black's LOGSCAN utility in Qualis Library
From: mikeh@qualis.qualis.com (Michael T. Horne)
Date: 20 Sep 1998 15:56:38 GMT
Links: << >>  << T >>  << A >>

The latest revision of David Black's LOGSCAN utility is now available
in the Qualis Library.  David's LOGSCAN was a big hit at the
1998 Synopsys User Group (SNUG) meeting. You can download it at:

    http://www.qualis.com/cgi-bin/qualis/libObject.pl?object=tr012

For those of you unfamiliary with LOGSCAN, here's an excerpt from
the README file:

-----
A common problem facing most EDA tools users is how to filter through 
hundreds of lines of EDA tool output and quickly focus on the important 
information. Tools such as Synopsys Design Compiler or Quad Design Motive 
Static Timing analyzer produce messages classified as "errors", "warnings", 
or "information" in great volumes. Typically, there are simple methods to 
suppress one or more of these messages. Unfortunately, suppression often 
leads to ignoring important information. On the other hand, reading every 
line of a long report is very error prone. Some engineers choose to use 
various forms of the UNIX 'grep' utility to solve their problems; however, 
it tends to be limited to single line errors. Frequently, multi-lines of 
information are necessary to realize there is a problem and understand what 
needs fixing. Finally, some errors or lines are expected/required (e.g. 
the Thankyou message at the end of a synopsys session).

With the above framework in mind, I developed tools over the years that 
address this very issue. The remainder of the paper demonstrates a 
successful solution implemented with PERL. The script itself, 
independently developed, is made available as charity-ware via the
Internet the EDA community via the Qualis Web site <http://www.qualis.com/>.
-----

Check it out in the Qualis Library for more information about LOGSCAN.

Michael

Qualis Design
http://www.qualis.com/

Article: 11938
Subject: Re: Xilinx Spartan vs. 4K series
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Sun, 20 Sep 1998 17:30:00 +0100
Links: << >>  << T >>  << A >>
In part of article <35f8827c.4654371@newshost>, Allan Herriman
<allan.herriman.hates.spam@fujitsu.com.au> writes

>2.     Not pin compatible.  (more VCC pins, which is a good thing)

>I recently translated a design from a 4020E-3 to an XCS40-3.  There
>were no (VHDL) source code changes needed except for the pin
>numbering. 

Allan, I've got the XCS30 and XC4013 pin-out tables in front of me and
for the PQ240 package at least, the VCC and GND pinouts look identical.
ie apart from configuration pins, they look pin-compatible. Have I
missed something ?.

Also, how do you percieve the marketing of the Spartan parts ?. We have
almost been discouraged to use them. Less profit margins for Xilinx
perhaps ?

-- 
Edward Moore
Article: 11939
Subject: Re: Xilinx Spartan and 4K speed grades
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Sep 1998 12:46:08 -0400
Links: << >>  << T >>  << A >>
Simon Ramirez wrote:
> Matthew,
>    The response that Ed McCauley gave you tells it all.
>    I just wish that Xilinx had stuck with the XL family way of describing
> speed.  I do not care if 09 or 08 means 900 or 800 picoseconds, I can handle
> that.  I think that the time through a 4 variable LUT (or some well
> established circuit) is a good measure of how fast a design will be, if you
> know how to use that parameter.  Giving an FPGA a meaningless number like
> the Spartan family has makes it more difficult to determine how fast a
> design will be.  In fact, I always used to tell the Orca guy that they
> should change their way of gauging a part's speed to the way Xilinx did it!
> -Simon Ramirez

I agree, except that Xilinx wasn't very forward looking with the -09
style. They should have gone to a -900 notation which would have carried
them all the way down to 1 ps delays (-001)! i Think that would have
held them for a couple of years before they had to change again.   ;)

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 11940
Subject: Re: ASIC -> FPGA async issues
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 20 Sep 1998 12:50:57 -0400
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
...snip...
> Here are the two scenarios:
> 1) Turn off is faster than turn on: The parasitic capacitance on the
>    the output node will hold the level till the second fet turns on.
>    There is no static current drawn on this node so there is no motivation
>    for it to change to the other level. The load is either another
>    similar mux, or the high impedance of an inverter.
> 2) Turn off is slower than turn on: Since both paths have the same value,
>    for a short while (sub nanosecond) both sides of the mux drive the
>    output with the same value.

For case 1, you will have both glitch free and contention free
operation. But in case 2, how do you prevent contention when the two
paths have different values? 

...snip...
> All the above information is pubicly available. With some effort, you can
> actually find out a lot about the detailed internals of these devices,
> because of the very large number of patents that have been filed by all
> the FPGA companies. To see the gory details of the above, there are many
> patents that show the detailed schematics.  An example would be 5,566,123,
> but there are many others. My favorite site for this is

Public perhaps. But rather than dig through patents (which may or may
not be implemented in a given device), it would be very nice if Xilinx
(and others) made answers to questions like this easily available on
their web sites. I couldn't find anything after doing a search at
Xilinx. 


Thanks Philip, I knew you would pull through for us!

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 11941
Subject: Re: Xilinx Configuration Info
From: ems@nospam.riverside-machines.com
Date: Sun, 20 Sep 1998 19:34:36 GMT
Links: << >>  << T >>  << A >>
On Fri, 18 Sep 1998 15:37:47 -0400, Rickman <spamgoeshere4@yahoo.com>
wrote:

>I remember there being some posts on info from the Xilinx web site on
>the configuration process. Can someone repost where I can find that
>data. I have searched using their search tool and can't find what I am
>looking for. All I can find is the section out of the data book on
>configuration. I thought there was an app note on downloading from a uC. 
>
>I need to put together a clear enough description that the software
>developer can code it. That can be quite a job sometimes.  ;)

I think the doc you're looking for is 'bus_conf.pdf' - you can find it
by doing a search on 'processor'. I had the same problem a few months
ago, but I found this doc to be too specific to be of any use to a
programmer. I ended up just copying out the relevant bits of the
databook - :<

Evan

Article: 11942
Subject: WANTED: FPGA/ASIC Eng's telecom
From: mdelaney@servtech.com (Mike DeLaney )
Date: Sun, 20 Sep 1998 17:25:15 -0500
Links: << >>  << T >>  << A >>
TITLE: Hardware Eng : ASIC/FPGA
   
REF #: HW-datacom-309-98                   **  MUST reside in the US  **

LOCATION: MA/TX/VA/MD/IL/AL/WI, other areas available too...call me to find
out more

REQUIREMENTS:  2+ yrs; MULTIPLE POSITIONS (Jr & Sr)  
Prior exp with some or all of the following:  ATM, SONET, high-performance
microprocessors, distributed control architectures, or large switching
systems.
Various positions in chip level & circuit design. 2+ yrs designing FPGA &
ASICs for high-speed application (60 MHz+).  VHDL, synopsis, ViewLogic,
Xilinx, SONET/SDH telecom equipment. Architecture to detailed circuit
design positions for DS1, DS3, E1-E4. Designs from 1.5 to 140 Mb/s,
HDSL,/ADSL modem, hardware, DSP, high-speed network technologies.
___________________________________________________________

Call:      Mike DeLaney - Specializing in the communications industry   
        800-248-7020  x260      
         Fax 716-248-3077
     National Engineering Search   
        http://www.nesnet.com    

    "Engineers placing Engineers"

Email (text resume) to: mdelaney@servtech.com
____________________________________________________________
See what your skills are worth...CALL for a FREE salary survey.
____________________________________________________________

National Engineering Search (http://www.nesnet.com) is a technical
recruiting firm, staffed with degreed engineers, dedicated exclusively to
placing Engineers nationwide.  If this position doesn't fit your
requirements, call me with your specific search criteria.
 
€ NES can identify  SELECT  engineering opportunities based on your
background, interests, and geographic requirements.  

€ What makes us better...We are Engineers placing Engineers, We are not a
generalist, We are very focused in a technical arena ONLY.   And we know it
better than anyone else.
 
Article: 11943
Subject: Dynamic pattern matching in Xilinx FPGAs
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Sun, 20 Sep 1998 17:09:24 -0700
Links: << >>  << T >>  << A >>
Another engineer at work wants to build a state machine that watches for a
particular sequence of words and then trigger an output.  E.g., set an
output active after receiving 0x5555,0xaaaa,0x0000,0xffff in that particular
order.  The compare sequence needs to be configurable by a microcontroller
(but only as an "offline" operation on a very occasional basis).  He was
thinking of using the wide address decoders around the perimeter of the
XC4000 series FPGAs to do this decoding, but they have the obvious drawback
that reprogramming the compare sequence would require completely
reprogramming the FPGA.  That would be acceptable, but our understanding is
that this isn't feasible since Xilinx doesn't publish the configuration
bitstream specification due to security concerns about copied designs.

Instead of using the wide edge decoders, one could use CLBs.  Since each CLB
has two four input LUTs, each CLB one could do 4 bits worth of a comparison
(...against some register's compare value that a microcontroller could write
to).  Multiple CLBs outputs could then be ANDed together in another CLB to
generate the match output.  So by my calculations, a 32 bit configurable
compare would require 9 CLBs.

My questions are:
-- Am I correct about Xilinx's policy on the bitstream?  I've read that some
parts of it actually are published -- would that include the wide edge
decoder configuration bits?
-- Assuming no, is there a better way to do this than what I've proposed in
the second paragraph?
-- How much slower will the CLB approach be than the wide edge decoder
approach?

Thank you for your help.

---Joel Kolstad
Joel.Kolstad@USA.Net



Article: 11944
Subject: ICCD 98 Program
From: Chin-Long Wey <wey@egr.msu.edu>
Date: Sun, 20 Sep 1998 21:07:03 -0400
Links: << >>  << T >>  << A >>
Please find enclosed the call for participants for ICCD '98:
International Conference on Computer Design 1998.

Kindly forward this Announcement to your colleagues.

Best regards.
Chin-Long Wey,
Publication Chair, ICCD '98

****************************************************************************

       C A L L      F O R     P A T I C I P A N T S
****************************************************************************

INTERNATIONAL CONFERENCE ON COMPUTER DESIGN, ICCD '98
October 5 - 7, 1998
Marriott Hotel at the Capitol, Austin, Texas
Sponsored by: IEEE Circuits and Systems Society and The IEEE Computer
Society; In Cooperation with: IEEE Electron Devices Society

The International Conference on Computer Design encompasses a wide range

of topics in the design and implementation of computer systems and their

components. ICCD's multi-disciplinary emphasis provides an ideal
environment for developers and researchers to discuss practical and
theoretical work covering system and computer architecture, verification

and test, design and technology, and tools and methodologies. This
year's program includes three invited sessions on the latest processor
developments, two embedded tutorials, two panel discussions, two advance

technology forums, and 21 technical sessions with 69 scheduled paper
presentations. During the poster session on Monday night wine and cheese

will be served. IBM and Motorola will sponsor the lunches on Monday and
Tuesday, respectively. Murray Campbell, IBM Thomas J. Watson Research
Center will give the Keynote Speech. Three plenary sessions provide
leaders in the field the opportunity to present the latest developments
and visions of future progress in key ICCD subject areas.

Up-to-date information on ICCD '98 is available on the World Wide Web---

http://domino.watson.ibm.com/iccd98/iccd98.nsf/Program.html

**************************************************************************

ICCD '98
General Chair: Bing Sheu, University of Southern California, USA
Technical Program Chair: Andreas Kuehlmann, IBM T.J. Watson Research
Center, USA
Publications Chair: Chin-Long Wey, Michigan State University, USA
Treasurer: Tim Brodnax, IBM Corporation, USA
Industry Liaison: Nasr Ullah, Motorola Inc., USA
Local Arrangements: Dan Elgin, University of Texas at Austin, USA
Architecture and Algorithms Track
   Co-Chair: Craig Chase, University of Texas at Austin, USA
   Co-Chair: David Witt, Advanced Micro Devices, USA
Integrated Systems Track
   Co-Chair: Rajesh K. Gupta, University of California, USA
   Co-Chair: John Trotter, Lucent Bell Laboratories, USA
Verification and Test Track
   Co-Chair: Warren A. Hunt, Jr, IBM Corporation, USA
   Co-Chair: Wolfgang Kunz, University of Frankfurt, Germany
Design and Technology Track
   Co-Chair: Sandip Kundu, Austin Research Lab, USA
   Co-Chair: Sarma Vrudhula, University of Arizona, USA
Tools and Methodology Track
   Co-Chair: Joel Grodstein, Digital Equipment Corporation, USA
   Co-Chair: Kenneth L. Shepard, Columbia University, USA

===========****============****===========****==================
Dr. Chin-long Wey, Professor
Department of Electrical Engineering
Michigan State University, East Lansing, MI 48824-1226
Phone: 517-353-0665; Fax: 517-353-1980; E-mail: wey@egr.msu.edu
URL: http://www.egr.msu.edu/~wey
Article: 11945
Subject: ICCD 98 Program
From: Chin-Long Wey <wey@egr.msu.edu>
Date: Sun, 20 Sep 1998 21:08:21 -0400
Links: << >>  << T >>  << A >>
Please find enclosed the call for participants for ICCD '98:
International Conference on Computer Design 1998.

Kindly forward this Announcement to your colleagues.

Best regards.
Chin-Long Wey,
Publication Chair, ICCD '98

****************************************************************************

       C A L L      F O R     P A T I C I P A N T S
****************************************************************************

INTERNATIONAL CONFERENCE ON COMPUTER DESIGN, ICCD '98
October 5 - 7, 1998
Marriott Hotel at the Capitol, Austin, Texas
Sponsored by: IEEE Circuits and Systems Society and The IEEE Computer
Society; In Cooperation with: IEEE Electron Devices Society

The International Conference on Computer Design encompasses a wide range

of topics in the design and implementation of computer systems and their

components. ICCD's multi-disciplinary emphasis provides an ideal
environment for developers and researchers to discuss practical and
theoretical work covering system and computer architecture, verification

and test, design and technology, and tools and methodologies. This
year's program includes three invited sessions on the latest processor
developments, two embedded tutorials, two panel discussions, two advance

technology forums, and 21 technical sessions with 69 scheduled paper
presentations. During the poster session on Monday night wine and cheese

will be served. IBM and Motorola will sponsor the lunches on Monday and
Tuesday, respectively. Murray Campbell, IBM Thomas J. Watson Research
Center will give the Keynote Speech. Three plenary sessions provide
leaders in the field the opportunity to present the latest developments
and visions of future progress in key ICCD subject areas.

Up-to-date information on ICCD '98 is available on the World Wide Web---

http://domino.watson.ibm.com/iccd98/iccd98.nsf/Program.html

**************************************************************************

ICCD '98
General Chair: Bing Sheu, University of Southern California, USA
Technical Program Chair: Andreas Kuehlmann, IBM T.J. Watson Research
Center, USA
Publications Chair: Chin-Long Wey, Michigan State University, USA
Treasurer: Tim Brodnax, IBM Corporation, USA
Industry Liaison: Nasr Ullah, Motorola Inc., USA
Local Arrangements: Dan Elgin, University of Texas at Austin, USA
Architecture and Algorithms Track
   Co-Chair: Craig Chase, University of Texas at Austin, USA
   Co-Chair: David Witt, Advanced Micro Devices, USA
Integrated Systems Track
   Co-Chair: Rajesh K. Gupta, University of California, USA
   Co-Chair: John Trotter, Lucent Bell Laboratories, USA
Verification and Test Track
   Co-Chair: Warren A. Hunt, Jr, IBM Corporation, USA
   Co-Chair: Wolfgang Kunz, University of Frankfurt, Germany
Design and Technology Track
   Co-Chair: Sandip Kundu, Austin Research Lab, USA
   Co-Chair: Sarma Vrudhula, University of Arizona, USA
Tools and Methodology Track
   Co-Chair: Joel Grodstein, Digital Equipment Corporation, USA
   Co-Chair: Kenneth L. Shepard, Columbia University, USA

===========****============****===========****==================
Dr. Chin-long Wey, Professor
Department of Electrical Engineering
Michigan State University, East Lansing, MI 48824-1226
Phone: 517-353-0665; Fax: 517-353-1980; E-mail: wey@egr.msu.edu
URL: http://www.egr.msu.edu/~wey
Article: 11946
Subject: WOW!!! WHAT A STORY ONLINE!!!
From: ryjkotqg@somethingfunny.net
Date: 21 Sep 1998 02:48:13 GMT
Links: << >>  << T >>  << A >>

I happen to have dropped by http://www.despotovic.net and I couldn't believe what I saw. A complete case online with over 48 pictures, 3 police reports and more!!!

Regards.

P.S.- The website address is http://www.despotovic.net

Article: 11947
Subject: Re: Xilinx Spartan vs. 4K series
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Mon, 21 Sep 1998 04:25:20 GMT
Links: << >>  << T >>  << A >>
On Sun, 20 Sep 1998 17:30:00 +0100, Edward Moore
<edmoore@edmoore.demon.co.uk> wrote:
>>2.     Not pin compatible.  (more VCC pins, which is a good thing)
>>I recently translated a design from a 4020E-3 to an XCS40-3.  There
>>were no (VHDL) source code changes needed except for the pin
>>numbering. 
>
>Allan, I've got the XCS30 and XC4013 pin-out tables in front of me and
>for the PQ240 package at least, the VCC and GND pinouts look identical.
>ie apart from configuration pins, they look pin-compatible. Have I
>missed something ?.

No, I did.  As another poster pointed out, the compatibility problem
was only for the PQ208 package.  This just happened to be the only one
I've used so far...

>Also, how do you percieve the marketing of the Spartan parts ?. We have
>almost been discouraged to use them. Less profit margins for Xilinx
>perhaps ?

Our local distributor is recommending them for all new designs.  I
believe that may have something to do with competition with Altera in
this particular market.  They are aware of our application and what we
are willing to pay, so they know that they either sell at a particular
price, or lose market share.

One advantage of working for a big company is that you get to watch
the component suppliers squirm, not the other way around.
[ This rather appeals to my sadistic side.]

I could go on, but company policy prevents me from saying more, sorry.

>Edward Moore

Regards,
Allan.
Article: 11948
Subject: Re: Problems with the Floorplanner in Xilinx Alliance 1.5
From: "Sten Søgaard" <soeg@kom.auc.dk>
Date: Mon, 21 Sep 1998 08:31:46 +0200
Links: << >>  << T >>  << A >>


ems@nospam.riverside-machines.com wrote:

> On Fri, 18 Sep 1998 11:37:01 +0200, "Sten Søgaard" <soeg@kom.auc.dk>
> wrote:
>
> >I know that Xilinx
> >has had a guided layout option for some time now, but whenever I have
> >tried to use it, it results in a "Dr. Watson"-fault of some kind, I
> >don't remember.
>
> I thought this had been fixed recently (a few months ago?), but I
> haven't tried the patches on the website.
>
> >Has anyone else tried to use the Floorplaner with succes, is the
> >Floorplanner still a beta version, or is it my who are using it wrong ?
>
> I asked Xilinx for a beta a few months ago, but they said I should
> wait for the 'proper' release in 1.5, so I guess (hope) it's not beta
> any more. I can't help, since I haven't got 1.5 yet, but I would be
> interested to hear some more about what you're doing:

I don't doubt that Xilinx believe that it is an official release they have
made, it is just me who are referring to the floorplanner as a beta version.

> 1) What synthesiser are you using?

Leonardo

> 2) After you've changed your entity, how much of the design do you
> re-synthesise? Just that one entity/all dependent entities/all 20
> entities?

Well, I have to admit that I do a complete re-synthesis (I have build a nice
script file that handles all the synthesis from bash).
But I keep the hierarchy during synthesis. The modifications I have tried to
make are very minor, e.g. change the terminal count if an incrementer in the
FSM, I haven't inserted new signals in my design, so I hope that should keep
Leonardo from changing other entities.

> 3) You say you remove the modified entity from the floorplan. How do
> you do this? Have you already floorplanned so that the entity is in
> one section of the device, or do you have to remove parts of the
> entity from all over the device?

I copy the placement of an previous version of the design, and then remove
the entity that I have changed since then. It is quite easy with the
Floorplanner, as it shows an hierarchical design tree. When you mark a
entity in the design tree, it automatically selects all cells in that entity
in the placement file.

From this layout the floorplanner generates an .fnf and .mfp file (I only
use the .mfp file - the guide file)

First couple of lines in the mfp file.
CARRY R48C1 COUT0 th/bc/ix2354_cout0 COUT th/bc/ix2354_l1_l0_c_int(0) A1
th/bc/q(1) A0 th/bc/q(0) CIN BEL_th/bc/q(1).POWER.1 ;
CARRY R47C1 COUT0 th/bc/ix2354_cout0_dup_359 COUT
th/bc/ix2354_l1_l0_c_int(1) A1 th/bc/q(3) A0 th/bc/q(2) CIN
th/bc/ix2354_l1_l0_c_int(0) ;
.
.
.

> 4) If you had to re-synthesise any other entities, do you know if the
> XNF/EDIF signal names in those entities changed?

As I mentioned, I keep the hierarchy and I don't include new signals.

> I guess that the success of a guided or floorplan mapping will depend
> very much on how many signal names have changed (this is presumably
> why guided mapping is not recommended for synthesis designs). Mapping
> will be a problem if a small change in an entity results in name
> changes throughout the entity (which will happen with some
> synthesisers) - is this happening in your case?

I don't know, but this is also why I use "Guided FloorPlanning", with
emphasis on guided. Shouldn't it be possible to use a floorplan as the
starting point of the placement iterations in the placement&route step. It
does not lock the cells to specific locations.
Even if the should be some deviations between the signal names in the
floorplan, and the signal names in the design, why can't it just ignore
these deviations, and only use the valid guides.

\Sten

Article: 11949
Subject: Re: Dynamic pattern matching in Xilinx FPGAs
From: Goran.Bilski@enator.se
Date: Mon, 21 Sep 1998 08:21:14 GMT
Links: << >>  << T >>  << A >>
In article <6u45du$grs$1@supernews.com>,
  "Joel Kolstad" <Joel.Kolstad@USA.Net> wrote:
> Another engineer at work wants to build a state machine that watches for a
> particular sequence of words and then trigger an output.  E.g., set an
> output active after receiving 0x5555,0xaaaa,0x0000,0xffff in that particular
> order.  The compare sequence needs to be configurable by a microcontroller

If you are using compare with a large/dynamic pattern, my suggestion is to
use a RAM/ROM lookup table, each CLB of the XC4K family can take an 5 input
address with one bit output or 4 input with two bit output. in your example
2,5 CLB's can be used to match every possible combination. (2 CLB's for
matching and one lut for AND) The best feature is that the RAM match pattern
can be write via uC I/F.

/Goran Bilski

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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