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 15050

Article: 15050
Subject: Re: Selt-Timed circuit
From: Mike Lewis <lewism@cs.man.ac.uk>
Date: Thu, 04 Mar 1999 09:19:09 +0000
Links: << >>  << T >>  << A >>
David T. Wang wrote:
> 
(snip)... I still think that async
> design is too hard for a large project, and keeping locally sync
> blocks, and just deal with async interface would be a lot easier.
> 

Too hard for a large project?  Have a look at
http://www.cs.man.ac.uk/amulet/ ... our group have developed the AMULET
series of chips; commercially viable asynchronous implementations of ARM
cores... a particularly nice feature is the improved EMC because the
chip doesn't switch in time to a global clock. As ARM cores are
extensively used in GSM cellphone chipsets, this is a pretty desirable
feature. It's also good from a low power point of view... for example,
roughly 1/3 of the total power dissipated in a DEC Alpha is due to the
clock distribution network.

I'm currently working on a low power asynchronous DSP core to complement
the AMULET processors... there is a lot to be said for keeping locally
synchronous blocks with asynchronous interfaces; but there's no need to
feed an external clock to them. With locally generated clocks, you can
run separate modules at the speed most appropriate for them.

IMHO, as we move towards the prediction of a billion transistors on a
chip then the idea of a global clock is going to have to go out of the
window... partly from a synchronisation viewpoint, and partly because of
the power spiking caused by that number of transistors all dancing to
the same tune.

Mike

-- 
Mike Lewis, mailto:lewism@cs.man.ac.uk
--------------------------------------
AMULET Group, University of Manchester
http://www.cs.man.ac.uk/~lewism/
Article: 15051
Subject: Re: Clock divider: 100MHz->40MHz
From: Emil Blaschek <emil.blaschek@siemens.at>
Date: Thu, 04 Mar 1999 11:54:27 +0100
Links: << >>  << T >>  << A >>
Joel Kolstad schrieb:
> 
> Does anyone have a clever circuit that can divide an input clock by two and
> a half?  We're looking to go from 100MHz down to 40MHz.  I've thought of a
> couple of ways to do this, but they all had some asynchronous parts to them
> that required that I could guarantee minimum propagation delays.  In a
> 100MHz part I didn't really want to have to guess at the minimum propagation
> delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs we're
> thinking of implementing this in -- mention their minimum propagation delays
> in the data sheets that I looked at).
>Zipp

> ---Joel Kolstad

Try this : 
div_krumm :process (clk_sys ) 

   variable v_zaehler : integer range 0 to 9; --   
 
begin 
  if (clk_sys'event and clk_sys  = '1') then		
    if reset = '1' then		-- Reset synchron
      v_zaehler := 0;		-- Zaehler auf 0 stellen 
      clk_xl     <=  '0' ;
    else	

      v_zaehler := v_zaehler + 1 ;
      if v_zaehler > 9 then  
         v_zaehler := 0 ;                   
      end if ; 
      if v_zaehler = 2  or v_zaehler = 5  or
         v_zaehler = 7  or v_zaehler = 9 
      then  
        clk_xl     <=  '1' ;
      else  
        clk_xl     <=  '0' ;
      end if ; 
   end if;	 
  end if;	 
end process div_krux;


No warranty ... try
Article: 15052
Subject: Re: Getting started in programmable logic
From: peter.trott@vantis.com
Date: Thu, 04 Mar 1999 11:39:02 GMT
Links: << >>  << T >>  << A >>
Rob

Why dont you have a look at the Vantis web site, www.vantis.com. There you can
download DesignDirect-CPLD which is free of charge. This allows you to do
schematic or ABEL entry and then target any CPLD from Vantis from the humble
16V8 PAL upto the 512 macrocell M5 devices. The tool will let you capture the
complete design and then estimate what the best device is to use for pin
counts, density etc. It is a good way of starting into programmable logic!

Peter Trott
Vantis

In article <19990302151902.13531.00003629@ng-ch1.aol.com>,
  robert4422@aol.com (Robert4422) wrote:
> Hello folks,
>
> I am trying to get started in programmable logic, but so far having somewhat
of
> a hard time.  I have a simple project sitting in my digital circuit emulator
> program, and I would like to realize it using some kind of programmable logic
> device.  Actually, I had been planning to realize the design in discrete 74xx
> TTL's (it's that simple--just a 10-bit counter, some AND gates, some flip
> flops, and some NAND gates), but I thought this might be a good time to get
> into the world of programmable logic devices.  So far, however, I'm having a
> lot of trouble sorting through all the different kinds of devices that are
> available, and was wondering if anyone here could help me out.
>
> Specifically, perhaps someone could help me with the following questions:
>
> 1.  What kind of programmable devices should I be looking into to implement
the
> design mentioned above?  I assume the presence of flip-flops and an n-bit
> counter is a little beyond the level of PALs and GALs, but perhaps I'm wrong?
> Is FPGA what I need/want, or something else entirely?
>
> 2.  Moreover, can someone give a brief description of the differences between
> the major families of programmable devices?  e.g., PAL vs. GAL vs FPGA etc.
> (if there's a FAQ or other reference that does this, please just point me to
> it.)
>
> 3.  Which families of devices have TTL-level inputs/outputs?
>
> 4.  What are some good introductory reference materials?  Books, websites,
etc.
>
> Thank you for your time and help in getting a beginner started!
>
> Rob
>
> VHDL
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 15053
Subject: Re: Selt-Timed circuit
From: alex_schreiber@my-dejanews.com
Date: Thu, 04 Mar 1999 12:16:51 GMT
Links: << >>  << T >>  << A >>
In article <36DE3D89.B3B630EC@kom.auc.dk>,
  Lasse Langwadt Christensen <fuz@kom.auc.dk> wrote:
> alex_schreiber@my-dejanews.com wrote:
> >
> > Hi,
> >
> snip
> >
> > In traditional (synchronous) design techniques you always have
> > the problems of wiring delays. This becomes even more problematic
> > when you are moving towards smaller gate length (Very Deep SubMicron).
> > The transistor switching time becomes less important in comparison
> > to the wire delay. Additionally the amount of gates per area becomes
> > higher as well, which leads to longer clock nets as well.
>
> smaller chips leading to longer nets, that doesn't make sense ?

The die area keeps the same, just the transistor and interconnect
geometries (not in the same rate) are becoming smaller. This means,
a larger amount of transistors can be implemented on the same area.

Moving towards smaller technologies does not mean 'smaller' chips.
If the attributes 'small' and 'large' are based on the functionality,
even the contrary is correct: more transistors - more functionality -
'larger' chips.

>
> >
> > In a synchronous system you need to guarantee that there is not too
> > much skew between the each clock input of the same clock net. The
> > effort to achieve this becomes higher and higher.
> >
> > Exactly here is the advantage of self-timed logic. Because a
> > proceeding action is triggered by the completion of the previous
> > one, you do not have such distribution problems.
>
> won't you have more or less the same problems, just on the signals
> timing instead of the clock?

IMO no, because these protocol signals are connecting to a lower
number of inputs as the clock of a synchronous system (strict
definition: each flip-flop of the system is clocked by the same
clock). So the capacitive and resistive load is smaller and the
signal can be distributed faster.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 15054
Subject: Re: wanted: info about Fast Ethernet cores
From: "lior" <liorp@mysticom.com>
Date: Thu, 4 Mar 1999 14:34:04 +0200
Links: << >>  << T >>  << A >>
Hi ,
  We at Mysticom have developed a 10/100 Ethrnet Core .
  For more information look at our website  : http://www.mysticom.com
    Regards ,

      Lior

Charles F. Shelor wrote in message ...
>Howdy,
>
>I am involved in a make/buy decision to develop or purchase a VHDL
>based Fast Ethernet core for use in an FPGA and then migrate to
>an ASIC.  I am interested in any opinions, recommendations, etc
>from anyone who has purchased/used a Fast Ethernet core in an
>FPGA/ASIC.  Core vendors are welcomed to respond as well.
>
>Thanks,
>
>Charles
>
>charles@efficient.com
>
>Charles F. Shelor
>Efficient Networks
>"DSL for the Masses"
>972 991 3884
>
>--
>Charles Shelor                      (formerly  SHELOR ENGINEERING
>Sr ASIC Designer                     VHDL Training and models)
>Efficient Networks, Inc              http://www.efficient.com
>972 991 3884                         mailto:charles@efficient.com


Article: 15055
Subject: Re: Asynchronous resets: How tricky?
From: z80@ds2.com (Peter)
Date: Thu, 04 Mar 1999 12:54:40 GMT
Links: << >>  << T >>  << A >>

What you appear to be describing is equivalent to decoding the
output(s) of a counter for a particular value, and using that decode
to reset the counter.

This will work if

 a) the decode is glitchless, and
 b) the propagation delay from any counter Q to the counter RST input
    is longer than the counter's RST(min) pulse width

a) is achieved by syncing the decode with the counter clock. In an
FPGA, where routing delays could be just about anything, b) needs to
be done the same way. 

BTW, the old 4000 CMOS logic was designed to work in this way, by
careful internal design. In most cases, you could safely connect a
counter output back to RST, to create a mod-x counter.

>Assume you have a state machine that has some "interesting" state
>encoding... say the reset state encodes to 1010, and then the state machine
>always steps to a state encoded by 0101.  This state machine has an
>asynchronous reset input, which comes from a pin on a CPLD or FPGA.  The
>clock to this synchronous state machine also comes from a pin.
>
>Isn't a completely asynchronous reset input just asking for trouble?  While
>reset is active, the state machine is sitting at 1010.  If I now assume that
>reset goes inactive just a split (nano)-second before the active clock edge,
>I don't have any guarantees at all that some of the state encoding bits are
>going to transition to their expected new values, whereas some won't
>transition at all, correct?
>
>If this is really an issue, it would appear that the correct way to apply an
>asynchronous reset is to first run it through a synchronizer before applying
>it to the asynchronous reset input of the state machine.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 15056
Subject: Re: Clock divider: 100MHz->40MHz
From: Catalin <no@spam.com>
Date: Thu, 04 Mar 1999 09:01:19 -0500
Links: << >>  << T >>  << A >>
Lasse Langwadt Christensen wrote:

> how about using the divided clock to enable/disable the edges?
>
> count three rising edges, invert clk_out, count three
> falling edges invert clk_out.....
>
> increment counter here:(on rising when clk_out = 1, on falling when
> clk_out = 0)
>         |   |   | |   |   | |   |   | |
>         v   v   v v   v   v v   v   v v
>          _   _   _   _   _   _   _   _   _
> clk    _| |_| |_| |_| |_| |_| |_| |_| |_| |
>         ________           _________
> clk_out         \_________/         \____
>
> is it possible ?
>
> --L2C
> --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
> Lasse Langwadt Christensen, MSEE (to be in 1999)
> Aalborg University, Department of communication tech.
> Applied Signal Processing and Implementation (ASPI)
> http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org

Yes, but the design you describe divides by 5 - Joel wants to divide by 2.5!

Catalin Baetoniu


Article: 15057
Subject: Re: combining multiple xilinx designs into one
From: Ray Andraka <randraka@ids.net>
Date: Thu, 04 Mar 1999 10:00:49 -0500
Links: << >>  << T >>  << A >>
Another reason foundation is broken.  In viewlogic, you just create a symbol
for each design then put them The symbols) in a top level schematic.  Where
there are connections between the macros, you would want to remove the IO
macros.  You might want to move the IOs to the top level, but in viewlogic it
isn't mandatory.

Now for foundation...I've had similar problems in the past.  AFAIK, foundation
still requires macros to be one page only.  The easiest approach might be to
save each page as a separate schematic and then make each into a macro.
Instantantiate those macros on a single page to create a hierarchical macro,
then call that macro in your new top level design.

Dan Kuechle wrote:

> I want to combine 3 xilinx designs (4005xl's) into a single 4013xl part.
> The 3 designs are all done in foundation schematic entry, and are "flat".
> Each design is about 5 pages of schematics.
> Can I do a hierarchial schematic for this large design by creating a macro
> for each of the 3 small designs and then connecting them all togeather on
> a top level schematic?  This would require creating a macro for each
> of the small designs from its multi-page schematic.  I have been able to
> create a macro from "the current schematic page", but have not been able
> to create a macro from a multi-page schematic (or add a schematic page
> to a macro).  Can someone help?
>
> Thanks
>    Dan



--
-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: 15058
Subject: virtex chips
From: Daryl Bradley <dwb105@ohm.york.ac.uk>
Date: Thu, 04 Mar 1999 15:56:03 +0000
Links: << >>  << T >>  << A >>
Am I correct in saying that the Virtex chips are now run-time
reconfigurable, in a simialr manner to the 6000 series?

Cheers for any info

Daryl


Article: 15059
Subject: Re: virtex chips
From: Daryl Bradley <dwb105@ohm.york.ac.uk>
Date: Thu, 04 Mar 1999 16:10:01 +0000
Links: << >>  << T >>  << A >>
Sorry, have found all the info out I need on the xilinx site.

I'll wake up sometime today

DAryl

Daryl Bradley wrote:

> Am I correct in saying that the Virtex chips are now run-time
> reconfigurable, in a simialr manner to the 6000 series?
>
> Cheers for any info
>
> Daryl

--

Bio-Inspired Architectures
Department of Electronics
University of York, UK
01904 432379 (office)
http://www-users.york.ac.uk/~dwb105


Article: 15060
Subject: Re: Clock divider: 100MHz->40MHz
From: Catalin <no@spam.com>
Date: Thu, 04 Mar 1999 11:35:33 -0500
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> Catalin wrote in message <36DDB822.DD4263E3@spam.com>...
> >The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges
> (and
> >with two clock enables, one for each edge). If you use a divide by 5 binary
> >counter that counts on both 100MHz clock edges you will get a 40MHz output
> (with
> >40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is
> completely
> >synchronous you do not have minimum delay problems.
>
> This requires you to buy a device with a "counting" frequency of 200MHz
> though, doesn't it?
>
> BTW, for other people who have offered suggestions -- thanks.  Since there's
> been some confusion as to what the requirements of the output are, I'll
> explain further.  The 40MHz output is a pixel clock to a frame grabber.  The
> frame grabber has a PLL on-board, so it wants a 40MHz input that has
> relatively low jitter from one cycle to the next (the PLL happens to be a
> Cypress CY7C992 RoboClock).  The output doesn't have to be precisely 40MHz;
> something within +5%/-10% would be OK as well.
>
> ---Joel Kolstad

Before exploring further any digital solution to your problem you must be aware
of the following limitation. If your 100MHz clock does not have 50% symmetry
(and no clock has absolute symmetry) your 40MHz output will always have jitter.
For example, if your input clock is 4ns high and 6 ns low, the output clock will
have alternating periods of 24ns and 26ns, no matter how clever your design is.
If your frame grabber PLL cannot tolerate this kind of input then I think your
best bet is an external PLL clock (like the 2$ Cypress CY2071A). If the
alternating period jitter is OK and you do not need 50% symmetry for the 40MHz
(you cannot get anything better than 40%-60% anyway) the simplest solution I
think is the following:

entity div25 is
  port(CLK100: in STD_LOGIC;
       RESET: in STD_LOGIC;
       CLK40: out STD_LOGIC;  -- 100MHz div 2.5 (40MHz 40-60%)
       CLK20: out STD_LOGIC); -- 100MHz div 5   (20MHz 50-50%)
end div25;

architecture div25_arch of div25 is
signal CLK:STD_LOGIC;
signal Q:STD_LOGIC_VECTOR(2 downto 0);
begin
  CLK<=CLK100 xor Q(2) when Q(1 downto 0)="11" else
       not CLK100 xor Q(2);

  process(CLK,RESET)
  begin
    if RESET='1' then
      Q<=(others=>'0');
    elsif rising_edge(CLK) then
      if Q(1 downto 0)="00" then
        Q(2)<=not Q(2);
      end if;
      Q(1)<=Q(0);
      Q(0)<=not Q(1);
    end if;
  end process;

  CLK40<=Q(1);
  CLK20<=Q(2);
end div25_arch;

This takes just 1.5 XC4000XL CLBs (you cannot make it smaller than that!) and it
runs at 256MHz in an XC4013XLA-07 so speed should not be a problem even with
slower and cheaper parts.

Since the combinatorial clock CLK goes to two CLBs you must ensure that the net
delay is equal for both CLBs or use a global clock buffer. This way you will not
have any problems with minimum delays.

Catalin Baetoniu


Article: 15061
Subject: Re: Fast-turn ASIC vendors
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Thu, 04 Mar 1999 18:09:36 GMT
Links: << >>  << T >>  << A >>
On Tue, 02 Mar 1999 17:38:52 -0500, Todd Kline <todd@wgate.com> wrote:

>I apologize for being slightly off subject, but have any of the members
>of this group worked with any "fast-turn" ASIC vendors?  We are looking
>for fab times under a month.  We have worked with Chipexpress in the
>past, but Chipexpress doesn't have any processor core licenses and the
>ASIC we are doing needs an embedded processor.

I presume from your statement that you have not yet selected your
processor, as it would seem your requirement centres around the
existence of any core, rather than specifics?

So....Why not license your own core, and then put your ASIC out to
tender, rather than up for ransom?

Try www.arccores.com

Cheers
Stuart

Paint me biased as the company I work for represents ARC in the UK
For Email remove "NOSPAM" from the address
Article: 15062
Subject: Re: Clock divider: 100MHz->40MHz
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 04 Mar 1999 10:13:57 -0800
Links: << >>  << T >>  << A >>
Thanks to Barbara Walters' long commercials, here is the
"ultimate" purely digital solution in two XC4000XL CLBs:

Build a rising edge-triggered divide-by 5 counter out of
three flip-flops and LUTs.
There are 224 different ways to do this.
Pick one where one of the flip-flops is High only for two
consecutive clock periods.
Use the fourth LUT as a latch with three inputs: its own
output, the flip-flop, and the clock.
Program the output of this LUT-latch such that it is
High when (ff) OR ( lut AND clock ).
In other words: the output goes High when the ff goes High,
but then stays High, even after ff has gone Low, until the
next falling clock edge. That output is your 40 MHz
low-jitter signal.
It is guaranteed to be glitch-free.

Two remaining problems:
Your simulator may balk at this combinatorial feedback, and
you will of course see the effect of a non-symmetrical input
clock also at the output.

Peter Alfke, Xilinx Applications

Article: 15063
Subject: Virtex & Xchecker
From: "Stefan Lund" <stefan.lund@kungsbacka.mail.telia.com>
Date: 4 Mar 99 18:20:03 GMT
Links: << >>  << T >>  << A >>
Does anyone know if it is possible to use a Xchecker probe together
with a Virtex ? 

If yes, can I use a  5-Voltage probe with VCC=+5V at the probe and 
the VCCo=+3.3V  at the  I/O banks?

If yes, Is the Xchecker probe interface to a Virtex the same as to a
XC4000?


Thanks.

Stefan



Article: 15064
Subject: Re: Fast-turn ASIC vendors
From: Todd Kline <todd@wgate.com>
Date: Thu, 04 Mar 1999 19:26:51 GMT
Links: << >>  << T >>  << A >>
Actually, I'd love to use the ARC core.  It is hands down my first choice
for a soft core.  Unfortunately, my boss balks at the up-front license fee
of soft cores, even the "relatively" low fee for the ARC.  We are a
start-up, so cash flow management is extremely important.

Thanks,
Todd

>
> I presume from your statement that you have not yet selected your
> processor, as it would seem your requirement centres around the
> existence of any core, rather than specifics?
>
> So....Why not license your own core, and then put your ASIC out to
> tender, rather than up for ransom?
>
> Try www.arccores.com
>
> Cheers
> Stuart

Article: 15065
Subject: A few questions - beginner
From: "Mr Tisdale" <Tisdale@tisdale.prestel.co.uk>
Date: Thu, 4 Mar 1999 20:03:28 -0000
Links: << >>  << T >>  << A >>
Hi,

I've got a project consisting of mostly 74xxx series ICs which I want to
build, to make it easier an nice I wonder if I could use programmable logic
and eliminate the number of ICs required.  Could you please tell me how to
Programme these devices - PALs,PEELs,GALs etc how easy it is (Do they accept
JEDECs file formats) and also a very cheap programmer (or how to make one)
as I am only a student and can't afford these nice expensive programmers.

Many thanks
Neil


Article: 15066
Subject: 1999 Int'l HDL Conference & Exhibition
From: "HDL Conference" <info@vhdl.org>
Date: Thu, 4 Mar 1999 13:27:55 -0700
Links: << >>  << T >>  << A >>
The 8th International HDL Conference & Exhibition
April 6th - 9th
Santa Clara Convention Center
Santa Clara, CA.

Advanced and introductory topics on  Verilog and VHDL.design, and
Innovative
HDL Techniques for System-on-Chip (SoC) design.   This conference and
exhibition will feature papers, tutorials, panel sessions, keynote
speakers,
and 50 EDA exhibitors.  Some of the topics covered include Intellectual
Property, Timing Issues, Synthesis, Verification, and Language
Specifics.

NEW AT HDL CON' 99

* Single session pass registration.
* Register in advance and be automatically entered into a drawing to win
a Canon ELPH Camera!
* Register 2 people and receive the third registrant for FREE!
* Register for only one tutorial session and see the exhibits as part of
the package.
* Location, Santa Clara Convention Center... It's  close to work or
home! Swing by for a 1/2 day of sessions, networking, exhibits, and
speak to vendors in one location!

Stop by the web site for more information and on-line registration.

http://www.hdlcon.org

Mark your calendars and sign-up now (Limited seating capacity).

Sign up in advance for the full conference $300 (or $400 at the door).

For more information contact the HDL Conference office at
5305 Spine Road, Suite A
Boulder, CO 80301
Tel: 303-530-4562
Fax: 303-530-4334
e-mail: info@hdlcon.org



Article: 15067
Subject: Wath's "XOR adjacent path"?
From: "Luis de Funes" <fuzzy8888@hotmail.com>
Date: Thu, 4 Mar 1999 22:00:51 +0100
Links: << >>  << T >>  << A >>
Hi!
In the 1k and 2k Lattice ispLSI data sheets, I read the term
"XOR adjacent path". Wath is it exactly?
Thanks...

Luigi


Article: 15068
Subject: Re: A few questions - beginner
From: Brian Pedersen <brian@kom.auc.dk>
Date: Thu, 04 Mar 1999 22:52:24 GMT
Links: << >>  << T >>  << A >>
Mr Tisdale wrote:
> 
> Hi,
> 
> I've got a project consisting of mostly 74xxx series ICs which I want to
> build, to make it easier an nice I wonder if I could use programmable logic
> and eliminate the number of ICs required.  Could you please tell me how to
> Programme these devices - PALs,PEELs,GALs etc how easy it is (Do they accept
> JEDECs file formats) and also a very cheap programmer (or how to make one)
> as I am only a student and can't afford these nice expensive programmers.

Take a look at www.altera.com. Their Max+plus II software comes in a student
edition (a 6 month trial with a reduced number of synthesis targets). It has
function generators for the 74xxx series and is relatively easy to use. Maybe
you could convince your school/university to buy an evaluation board for you,
altera makes one that costs about $150 as far as I remember, but AFAIK they
don't sell them to private persons.

--                                               
Brian Pedersen, DSP Student                    _/     _/_/_/  _/_/_/  _/
Applied Signal Processing and Implementation  _/_/   _/       _/   _/ _/
Department of Communication Technology       _/  _/   _/_/_/  _/_/_/  _/
Aalborg University, Denmark                 _/_/_/_/       _/ _/      _/
URL: http://www.danbbs.dk/~kibria/brian/   _/      _/ _/_/_/  _/      _/
Article: 15069
Subject: Re: Virtex & Xchecker
From: "mark" <feydo@lcworkshop.com>
Date: Thu, 04 Mar 1999 23:39:07 GMT
Links: << >>  << T >>  << A >>
I was able to use the xchecker with a virtex part  ...  the only trick was
to connect the Vcc pin on the xchecker cable to a +5V source on our board 
...  if you don't have 5V on your board Xilinx sells a small adapter which
steps up the 3.3V on your board to the 5V required by the cable (or you
could easily built your own)

mark


Article: 15070
Subject: Re: Selt-Timed circuit
From: davewang@cslab.kecl.ntt.co.jp.DELETE.delete.DELETE@Glue.umd.edu (David T. Wang)
Date: 5 Mar 1999 01:01:52 GMT
Links: << >>  << T >>  << A >>
Mike Lewis (lewism@cs.man.ac.uk) wrote:
: David T. Wang wrote:
: > 
: (snip)... I still think that async
: > design is too hard for a large project, and keeping locally sync
: > blocks, and just deal with async interface would be a lot easier.

: Too hard for a large project?  Have a look at
: http://www.cs.man.ac.uk/amulet/ ... our group have developed the AMULET
: series of chips; commercially viable asynchronous implementations of ARM
: cores... a particularly nice feature is the improved EMC because the
: chip doesn't switch in time to a global clock. As ARM cores are
: extensively used in GSM cellphone chipsets, this is a pretty desirable
: feature. It's also good from a low power point of view... for example,
: roughly 1/3 of the total power dissipated in a DEC Alpha is due to the
: clock distribution network.

: I'm currently working on a low power asynchronous DSP core to complement
: the AMULET processors... there is a lot to be said for keeping locally
: synchronous blocks with asynchronous interfaces; but there's no need to
: feed an external clock to them. With locally generated clocks, you can
: run separate modules at the speed most appropriate for them.

Nothing wrong with that. Still locally sychronous, and globally async.
Once you get to that stage, where the clock comes from, and what speed
it runs is entirely irrelevant. 

: IMHO, as we move towards the prediction of a billion transistors on a
: chip then the idea of a global clock is going to have to go out of the
: window... partly from a synchronisation viewpoint, and partly because of
: the power spiking caused by that number of transistors all dancing to
: the same tune.

I think we're agreeing, but not claiming to be so. 
As distributing a global synchronizing signal becomes harder and harder,
async's difficulties stays constant. :)

: Mike

: -- 
: Mike Lewis, mailto:lewism@cs.man.ac.uk
: --------------------------------------
: AMULET Group, University of Manchester
: http://www.cs.man.ac.uk/~lewism/

--
No SPAM or email wholly without substance please
davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam
All statements are personal opinions
Not speaking for NTT or University of Maryland
Kyoto, Japan.
Article: 15071
Subject: Dynachip
From: Alain Arnaud <ecla@world.std.com>
Date: Fri, 5 Mar 1999 02:13:42 GMT
Links: << >>  << T >>  << A >>
W've been looking at using FPGAs form Dynachip.

I have a few questions:

1. Are their timing info correct or just marketing hype?
2. Is is true what they say that the routing delays are predictable?
3. How are their back end tools?
4. How's their tech support?
5. And finally will they be there in the long run?



Article: 15072
Subject: Re: High Fanout Signals
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Fri, 05 Mar 1999 03:51:19 +0000
Links: << >>  << T >>  << A >>
Hi!

Thanks for the reply. Actually I am describing the circuit from a high level
environment that I developed.
 It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs
extra development of the my tools to generate the proper layout ( I am
generating placement information myself from a high level programming
environment which generates EDIF netlist). That's why I wanted to use high
fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.



Article: 15073
Subject: Re: High Fanout Signals
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Fri, 05 Mar 1999 03:53:08 +0000
Links: << >>  << T >>  << A >>
Hi!

Thanks for the reply. Actually I am describing the circuit from a high level
environment that I developed.
 It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs
extra development of the my tools to generate the proper layout ( I am
generating placement information myself from a high level programming
environment which generates EDIF netlist). That's why I wanted to use high
fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.



Article: 15074
Subject: Re: High Fanout Signals
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Fri, 05 Mar 1999 03:53:44 +0000
Links: << >>  << T >>  << A >>
Hi!

Thanks for the reply. Actually I am describing the circuit from a high level
environment that I developed.
 It is a lot easier for me to use a single LFSR. Using multiple LFSRs needs
extra development of the my tools to generate the proper layout ( I am
generating placement information myself from a high level programming
environment which generates EDIF netlist). That's why I wanted to use high
fanout signals. May be I'll do an extra effort! - use multiple LFSRs-.





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