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 29600

Article: 29600
Subject: Re: Virtex ambit support
From: Kelvin =?big5?B?Q0hFVU5HL9XFvNLOsC+xaa5hsLY=?=
Date: Wed, 28 Feb 2001 14:20:35 +0800
Links: << >>  << T >>  << A >>
Hi,

FPGA synthesis can be transparent to Ambit when the library contain sufficent information (loading, drive, timing model and so on).  The netlist can be converted to EDIF and then Alliance should be
able to P&R it.  It can be done thru design compiler since .db file is provided. (Not only FPGA compiler but also dc.)  Yet we cannot do it with Ambit with an Ambit library.

Muzaffer Kal wrote:

> Ambit is strictly an ASIC synthesis tool. I don't believe it supports
> any FPGA devices. You're much better off with Synplicity tools for
> Virtex anyway.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com


Article: 29601
Subject: Re: Virtex ambit support
From: Muzaffer Kal <muzaffer@dspia.com>
Date: 28 Feb 2001 07:12:47 GMT
Links: << >>  << T >>  << A >>
Kelvin CHEUNG/żΰ/ia  <cheungkw@solomon-systech.com> wrote:

>Hi,
>
>FPGA synthesis can be transparent to Ambit when the library contain
> sufficent information (loading, drive, timing model and so on).  
>The netlist can be converted to EDIF and then Alliance should be
>able to P&R it.  It can be done thru design compiler since .db file
> is provided. (Not only FPGA compiler but also dc.)  Yet we cannot
> do it with Ambit with an Ambit library.

Yes it "can" be. What makes Buildgates a strictly ASIC synthesis tool
is that Cadence doesn't support any FPGA devices. There are no FPGA
libraries for Buildgates. In theory, theory and practice are the same
thing. In practice they aren't.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 29602
Subject: Re: UNISIM
From: "Ulises Hernandez" <ulisesh@ecs-telecom.removeplease.co.uk.invalid>
Date: Wed, 28 Feb 2001 13:20:35 -0000
Links: << >>  << T >>  << A >>
Hello,

I would not worry for this.
I would define and instantiate the STARTUP component in your top level
module. If you do that you won't need to include the UNISIN library, it is
an enormous library and your compile time could be increased.

-- component definition for the startup block
  component STARTUP
    port
      (
        GSR    : in  std_logic;
        GTS    : in  std_logic;
        CLK    : in  std_logic;
        Q2     : out std_logic;
        Q3     : out std_logic;
        Q1Q4   : out std_logic;
        DONEIN : out std_logic
        );
  end component;

-- Instantiate the xilinx specific startup component.
  -- This ensures that the reset signal uses the specific
  -- global reset resources.
  SU : STARTUP
    port map
    (
      GSR    => RST,
      GTS    => RST,
      CLK    => dummy,
      Q2     => open,
      Q3     => open,
      Q1Q4   => open,
      DONEIN => open
    );

I hope this help you.

"Qian" <junciu@yahoo.com> wrote in message news:ee6fc84.-1@WebX.sUN8CHnE...
> Hi I try to use GSR then I include
> --LIBRARY ieee;
> library IEEE;
> library UNISIM;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.std_logic_unsigned.all;
> use UNISIM.all;
>
> I use Xilinx Foundation and try to
> check syntax, however it says
>
> "library logic name UNISIM cannot be mapped to a host directory"
>
> How to solve it ?
> Thanks al ot!



Article: 29603
Subject: Re: Virtex ambit support
From: Jerry English <jenglish@remove_this.planetc.com>
Date: Wed, 28 Feb 2001 08:37:40 -0500
Links: << >>  << T >>  << A >>
Not so fast. I did run BuildGates with a library of Lucent ORCA3 fpga. I
manage
to get a verilog netlist then had it converted to edif. I then ran the
edif in Lucent's
P&R. While I did get results they were less than optimal. I didn't get
the library
from Cadence.

regards
Jerry
Muzaffer Kal wrote:

> Kelvin CHEUNG/żΰ/ia  <cheungkw@solomon-systech.com> wrote:
>
> >Hi,
> >
> >FPGA synthesis can be transparent to Ambit when the library contain
> > sufficent information (loading, drive, timing model and so on).
> >The netlist can be converted to EDIF and then Alliance should be
> >able to P&R it.  It can be done thru design compiler since .db file
> > is provided. (Not only FPGA compiler but also dc.)  Yet we cannot
> > do it with Ambit with an Ambit library.
>
> Yes it "can" be. What makes Buildgates a strictly ASIC synthesis tool
> is that Cadence doesn't support any FPGA devices. There are no FPGA
> libraries for Buildgates. In theory, theory and practice are the same
> thing. In practice they aren't.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com


Article: 29604
Subject: Re: Spartan II power
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Feb 2001 07:58:32 -0800
Links: << >>  << T >>  << A >>
Rick,

I think you may have misunderstood my comment.  The original thinking was 'Virtex thinking'
for larger parts -- which breaks down completely for smaller parts!  I agree with you.

1 watt for 4 2S15's split between all of the IO's at 3.3 Vdc, and the cores at 2.5 Vdc is a
real challenge, I admit.  If in the steady state, 1 watt is plenty to operate the four
parts, that leaves us with the startup issue.

I admit that for -40C, worst case is 2 amperes (right now, as we don't have enough 2S15
silicon to characterize the -40C number, so we have to go with what we know from larger
parts -- it could be less).  The thought of having to supply 8 amperes to start them up at
2.5 Vdc is a little (lot) daunting.

Is there any way to use a larger part, rather than four separate smaller parts?  I suppose
that isn't a very smart question, as you probably already optimized your system
architecture, but I have to ask.

Ultimately, one could design an 8 amp peak switcher than would deliver the 8 amps for at
least 1 ms to get them all started.  If you could tolerate a 500 mV dip in the 3.3 volts
running the DC to DC switcher, the input capacitor has to be I*dt/dv, or 8 * .001/.5 = 4,000
uF.  That isn't all that obscene, as 4,700 uF at 6.3 wv is still a pretty small component.
I would go with 10,000uF as at -40 C the capacitor (if it is the proper one engineered for
-55C in the data sheet) will have 40% of its room temperature value.  Do not use a standard
-40C capacitor, as they have 0 capacitance at -40C (really, I measure them all of the time
to prove this to the disbelievers!).

The capacitor specifications refer to damage, not operation, and since they are electrolytes
(i.e. there is water in there), it just makes sense that at really low temperatures they are
not a capacitor any more.

I am not recommending staging, or sequencing, but rather hitting them all at the same time.
Any attempt to mess with the program pin is doomed to failure in Virtex and Spartan II.  As
I have said, the chip doesn't even know its name yet at 0.7 to 1 V where the pop is needed.
Any attempt to slow down the ramp is doomed to fail as well.  The 4K parts had decreasing
current with increasing ramp, and some dependency of current on the pins, but not
Virtex/Spartan II.

Ultimately, there may be a better way to solve the problem, as you state, as there are
always alternatives.

By the way, the board is almost built.

Austin

Rick Collins wrote:

> I don't follow the thinking that a fully utilized FPGA requires a lot of
> power. In an earlier thread I was told that the startup current is the
> largest in the smallest Spartan II parts. An XC2S15 should not require a
> lot of operating current in many applications. This is also a function
> of clock speed.
>
> Not all designs require the highest clock speed and many have large
> parts of the circuit that do not cycle on every clock edge. BTW, not
> every design is systolic or serially calculable. Much of my current
> designs take a serial data stream and perfrom DMA to/from memory. By
> definition there is not much I can do to trade off logic for speed
> either way.
>
> The board I am currently selling has a total power consumption of 3
> watts. Over half of that is in the DSP and memory, about .5 Watts are in
> the IO section. This leaves less than a Watt in the four FPGAs on the
> board for an average of 75 mA at 3.3 volts. The smaller parts are
> utilized at about 80%. So where is the under utilization coming in?
>
> I don't see how requiring a 500 mA X 4 power supply is what I need on my
> board. I really don't see how I need to add booster supplies or staging
> switches to allow the FPGAs to boot in sequence. What I need is an FPGA
> that does not require up to 2 Amps of startup current in the industrial
> temperature range.
>
> Unfortunately every FPGA I have looked at has drawbacks. But then that
> is what makes it engineering, right? Anyone can choose a solution that
> is clearly better. It is harder to pick between two different tradeoffs.
>
> Ray Andraka wrote:
> >
> > IIRC, you can get around the monotonicity requirement by holding the program pin
> > until the power is stable.
> > As to the boot current, this should not be a problem if you are really using the
> > FPGA to its potential, as
> > the operating current for a well utilized FPGA is higher than the boot current
> > (if it is not, then you can
> > usually use serial or time multiplex techniques to get into a smaller part with
> > a smaller boot current).
> >
> > Austin Lesea wrote:
> > >
> > > Rick,
> > >
> > > Call it what you will.
> > >
> > > It is intended to aid those that have less than the 500 mA available.
> > >
> > > Initially, we thought, "anyone using this IC will probably run it at a clock speed,
> > > and with enough IO's that 500 mA will be required for its normal operation."
> > > Obviously, there is a smaller contingent of users that do not use the fast clock
> > > rates, or the large drive strengths, and need to get by with 200 or so mA.
> > >
> > > To help those users, we are working on the kick start circuit.
> > >
> > > As I said before, it is now being built, and we hope to have some results to report
> > > by next week.
> > >
> > > The area we are talking about here is pretty tiny.  Surface mount caps are required
> > > anyway for good bypassing.  The comparator is a tiny three leaded surface mount part
> > > (2 X 2 mm?).  Resistors are pretty tiny as well.  I can't see them anymore (getting
> > > old).
> > >
> > > The LDO will supply the voltage to the Vccint from the big capacitor, and at the
> > > output of the LDO, the power will be rising monotonically.  The 3.3 Vdc may droop
> > > (that is why it is better if available to run the core voltage LDO off 5 Vdc), but
> > > the droop is something one engineers (I=C dV/dt) to be small.
> > >
> > > The monotonicity "rule" is not a hard rule.  We care about the voltage rising
> > > through the POR trip point, and not falling back down after once passing through the
> > > POR trip point.  I believe this is stated in a number of tech notes/tech tips.  It
> > > may also be stated in the configuration section of the data sheet similar to how I
> > > have stated it above.  This is even to be relaxed at some point in the future Virtex
> > > II as we designed it to not care about this point in the power on ramp.  This is
> > > something we will later test and verify as not being a problem.  As well, Virtex II
> > > power on is in the tens of mA range, so we do try to improve in every subsequent
> > > generation.
> > >
> > > Austin
> > >
> > > Rick Collins wrote:
> > >
> > > > Austin,
> > > >
> > > > I don't mean to be rude, but is this circuit intended to be a "fix" to
> > > > the power up issue?
> > > >
> > > > I can just as easily increase the surge capacity of my power converter
> > > > than to add a secondary circuit to handle the few mS of startup current.
> > > > The cost of this added startup circuit may be small, but it uses a lot
> > > > of board space. By the time you account for the power requirement of the
> > > > I grade, the board space of the chip has doubled.
> > > >
> > > > The other issue that I would raise with this circuit is the requirement
> > > > that the voltage at startup be increased monotonically. If you depend on
> > > > capacitors to provide current to the load, then the voltage will sag
> > > > during that time. Perhaps the parts are not affected by a small voltage
> > > > droop, hence the huge capacitor requirement. But doesn't the data sheet
> > > > say that the voltage must increase monotonically? I can't find that now.
> > > > Perhaps I saw it in an app note or the data sheet for the Virtex parts?
> > > > Or am I mistaken about this?
> > > >
> > > > Austin Lesea wrote:
> > > > >
> > > > > Rick & Paul,
> > > > >
> > > > > Been out on vacation, so I missed this question.
> > > > >
> > > > > Spartan II is a Virtex derivative, so it has the same behavior during power up
> > > > > as the Virtex family.  Now this is about 2.5 years old, so it is a pretty well
> > > > > known behavior.
> > > > >
> > > > > The ramp up time has a secondary effect on the amount of current required.
> > > > > The shortest ramps require more current than the longer ramps, but as they get
> > > > > close to 50 ms (the spec), the currents may start going back up again.
> > > > > Current increases as temperature decreases.
> > > > >
> > > > > The current is required at about twice the Vt of the transistors (~0.7  to 1.0
> > > > > Vdc), and lasts perhaps as long as 200 us in the smaller parts of Spartan.
> > > > >
> > > > > We are now building the "kick start" circuit I had previously described.  It
> > > > > uses a 500 mA current limited LDO regulator with an enable pin.
> > > > >
> > > > > The enable pin comes from a micro power comparator /voltage reference ( we
> > > > > abandoned the simple RC -- too unpredictable).
> > > > >
> > > > > When the input voltage (3.3 or 5 Vdc) passes a set threshold (set by two
> > > > > resistors), the LDO is enabled.
> > > > >
> > > > > Ahead of the LDO is a ~1,000 uF 6.3 V cap that stores the necessary current to
> > > > > start up the part.
> > > > >
> > > > > For four devices, this same technique can be extended to a larger cap, and a 2
> > > > > ampere LDO.
> > > > >
> > > > > The idea is quite simple: use the stored charge in the big cap to provide the
> > > > > necessary kick to get all the parts started.  For the I grade, at -40C, you
> > > > > need 2 amps per part, and again, it is bigger capacitor, and larger regulators
> > > > > (better is a low voltage switcher enabled by the comparator).
> > > > >
> > > > > The added cost is the mico power comparator / reference (less than 1$), two
> > > > > resistors, and a big cap (<25 cents for a good aluminium electrolytic of large
> > > > > value).  (This assumes you have to provide a 2.5 V power supply regulator
> > > > > anyway).
> > > > >
> > > > > In the meantime, the Spartan designers continue to optimize process / design /
> > > > > test to improve the startup behavior.
> > > > >
> > > > > As soon as we have tested the kick starter with all process corner silicon, I
> > > > > will publish it as a note.
> > > > >
> > > > > Again, I apologize for the delays,
> > > > >
> > > > > Austin
> > > >
> > > > --
> > > >
> > > > Rick "rickman" Collins
> > > >
> > > > rick.collins@XYarius.com
> > > > Ignore the reply address. To email me use the above address with the XY
> > > > removed.
> > > >
> > > > Arius - A Signal Processing Solutions Company
> > > > Specializing in DSP and FPGA design      URL http://www.arius.com
> > > > 4 King Ave                               301-682-7772 Voice
> > > > Frederick, MD 21701-3110                 301-682-7666 FAX
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com  or http://www.fpga-guru.com
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 29605
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: Bard_64 <Bard_64@ntlworld.com>
Date: Wed, 28 Feb 2001 17:56:11 +0000
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote

>
> Question: What i/f has the PP got ? There are basically 3 ``levels'' of
> IDE:
>
> (1) PIO: Programmed I/O i.e. the disk is just treated as a dumb ISA
> peripheral & you read/write data via some polled/int driven s/w routine.
> [NB the data port is 16 bits wide but all the other registers are 8].
>
> (2) DMA: Old fashioned 80?? DMA. Single transfer at a time.
>
> (2a) MultiDMA: As above but you can do bursts as long as the DMA req's
> active.
>
> (3) UDMA: A  ``source synchronous'' abomination but it can get very high
> data rates, UDMA66 up to 133MBytes/sec. Hard to design & get right since
> the h/w protocol is both async wrt your system clock & tediously
> complicated.
>
> For something like a PP I would not have thought you'd need to go beyond 2a
> if that.

Hello Rick

Thanks for replying. In the specificfation data from the Hard disk is to be
sent to the Palm Pilot via the Palm Pilot's RS-232 link. Therefore to reduce
control overheads I am looking at developing some form of secondary processor
to handle file input and retrieval from the hardrive, then sending the data up
the RS 232,

Daniel



Article: 29606
Subject: Re: cpul vs vhdl
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Wed, 28 Feb 2001 11:32:44 -0700
Links: << >>  << T >>  << A >>
Will wrote:
> 
> > You can download free software from both Xilinx and Altera to design
> > FPGAs in VHDL or Verilog. So why both learning CUPL? You don't need to
> > be limimted by your software.
> 
> CUPL is bad comparad to vhdl?

CUPL was a buggy piece of crap last time I looked at it.

--ap

Article: 29607
Subject: Re: UNISIM
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Wed, 28 Feb 2001 11:35:14 -0700
Links: << >>  << T >>  << A >>
Qian wrote:
> 
> Hi I try to use GSR then I include
> --LIBRARY ieee;
> library IEEE;
> library UNISIM;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.std_logic_unsigned.all;
> use UNISIM.all;
> 
> I use Xilinx Foundation and try to
> check syntax, however it says
> 
> "library logic name UNISIM cannot be mapped to a host directory"
> 
> How to solve it ?
> Thanks al ot!

You solve it by not putting the library unisim stuff in your code.  The
synthesis tool will infer GSR automatically, if you follow the rule. 
The rule is: always make sure your reset net resets EVERY flop in your
design.

-a

Article: 29608
Subject: Re: ERROR on Xilinx fundation
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Wed, 28 Feb 2001 11:36:27 -0700
Links: << >>  << T >>  << A >>
Seb C wrote:
> 
> hi,
> 
> i obtained this error message :
> 
> ERROR:baste:314 - NCD was not produced. All logic was removed from design.
> This
>    is usually due to having no input or output PAD connections in the design
> and
>    no nets or symbols marked as 'SAVE'. You can either add PADs or 'SAVE'
>    attributes to the design, or run 'map -u' to disable logic trimming in
> the
>    mapper.
> 
> what means, NCD, PAD connections, because i used hierarchy connectors for
> inputs and outputs and finally i don't understand this message, it's my
> single error !!
> 
> If somebody can help me, don't hesitate !!

Do your schematics have IPADs and OPADs and such on the top level?

-a

Article: 29609
Subject: Re: Virtex USB solution
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Wed, 28 Feb 2001 11:42:35 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Andy,
> 
> I will probably shock someone somewhere, but I agree with you.  There are
> some things that are so well entrenched, so ubiquitous, and/or so screwey to
> implement (perhaps intentionally), that FPGA's are not even a realistic
> consideration.  The ASIC is just too cheap and easy not to use.

Methinks it's a case of "if the only tool available is a hammer,
everything starts to look like a nail."

-andy

Article: 29610
Subject: VHDL to Verilog RTL translator available under GPL
From: Vincenzo Liguori <enzo@nospam.com>
Date: Thu, 01 Mar 2001 09:03:37 +1100
Links: << >>  << T >>  << A >>
Hi,

We design cores which must be available both in VHDL and Verilog.
So, I wrote a translator that supports a limited but useful subset of
synthesisable
VHDL.

Although limited, this program correctly translated our Triple DES and
JPEG cores.
Since we have no commercial interest in such sw I decided to release it
in
the public domain under GPL.

The program is not particularly well written (my first attempt to use
YACC),
but it does a decent job at translating RTL, better, in some cases, than

some commercial programs I've seen.
This was a warm up exercise for a VHDL and Verilog to C, cycle based
compiler I have in mind. One day, maybe......

It is based on YACC/ C and it has been tested on Linux and Sun.
I believe that porting to Win should be easy.

You can fetch it at our download page:

http://www.ocean-logic.com/downloads.htm

Regards,

Vincenzo Liguori
---------------------------------------------------------------------------

Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 1655
Australia

Ph : +61-2-99054152
Fax : +61-2-99050921
WWW : http://www.ocean-logic.com




Article: 29611
Subject: SRAM vs. FLASH?
From: Jonas Thor <thor.NO@SPAM.sm.luth.se>
Date: Wed, 28 Feb 2001 23:04:41 +0100
Links: << >>  << T >>  << A >>
Hello!

This may be a silly question... Why are CPLDs mostly FLASH based and
FPGAs SRAM based? Is the FLASH technology too complex or expensive to
use in FPGAs?

I'm just curious...

/ Jonas 

Article: 29612
Subject: Re: SRAM vs. FLASH?
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 01 Mar 2001 00:48:37 GMT
Links: << >>  << T >>  << A >>
It's their heritage.
When PALs were born, they were made with fuses, and thus were
non-volatile. Nonvolatility has remained the religion through their
evolution to CPLDs with EPROM, then EEPROM and finally Flash.
Due to their structure, all CPLDs have considerable power consumption (
except CoolRunner ) and they are thus limited in complexity.
So it all goes together: non-volatile, single-chip, high power, limited
logic complexity and versatility. To hell with the complexity and
expense of a unique process.

SRAM-based FPGAs were born with high logic flexibility and complexity in
mind, which dictates a standard CMOS-Logic process. Adding Flash to this
process is considered heresy because it makes the process more complex,
most likely slower, and is unnecessary if one emphasizes
reconfiguration.

Antifuses hang in-between, neither fowl nor fish. Sorry, was not meant
as an insult.

There are plenty of opportunities to shoot holes into individual
arguments, but they are basically logical.

Peter Alfke, Xilinx Applications

Jonas Thor wrote:

> Hello!
>
> This may be a silly question... Why are CPLDs mostly FLASH based and
> FPGAs SRAM based? Is the FLASH technology too complex or expensive to
> use in FPGAs?
>
> I'm just curious...
>
> / Jonas


Article: 29613
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: yuryws@banet.net
Date: Thu, 01 Mar 2001 03:37:57 GMT
Links: << >>  << T >>  << A >>
Side note:
 uDMA66 burst transfer rate is approximately 66 MB/sec (4 bytes every 57 ns)
not 133 MB/sec.

-- Yury

Rick Filipkiewicz wrote:

> Bard_64 wrote:
>
> >                  Hello Everyone.
> >
> >                  I am currently doing backgroud reading on a project
> > involving the
> >                  interfacing of a Hard disk to a Palm Pilot.
> >
> >                  I was wondering could it be possible to access the IDE
> > interface
> >                  using an FPGA (specifically the X4003).
> >
> >                  Thanks
> >
> >                  Daniel
>
> Question: What i/f has the PP got ? There are basically 3 ``levels'' of
> IDE:
>
> (1) PIO: Programmed I/O i.e. the disk is just treated as a dumb ISA
> peripheral & you read/write data via some polled/int driven s/w routine.
> [NB the data port is 16 bits wide but all the other registers are 8].
>
> (2) DMA: Old fashioned 80?? DMA. Single transfer at a time.
>
> (2a) MultiDMA: As above but you can do bursts as long as the DMA req's
> active.
>
> (3) UDMA: A  ``source synchronous'' abomination but it can get very high
> data rates, UDMA66 up to 133MBytes/sec. Hard to design & get right since
> the h/w protocol is both async wrt your system clock & tediously
> complicated.
>
> For something like a PP I would not have thought you'd need to go beyond 2a
> if that.


Article: 29614
Subject: Re: Interfacing Xilinx 4003 to an IDE Hard Disk interface.
From: yuryws@banet.net
Date: Thu, 01 Mar 2001 03:40:12 GMT
Links: << >>  << T >>  << A >>
Recently I completed a design interfacing Spartan XL (which is rather
similar to 4000 family) to IDE interface implementing PIO-4 and uDMA66
protocols.

 Yes it is possible.


-- Yury

Bard_64 wrote:

>                  Hello Everyone.
>
>                  I am currently doing backgroud reading on a project
> involving the
>                  interfacing of a Hard disk to a Palm Pilot.
>
>                  I was wondering could it be possible to access the IDE
> interface
>                  using an FPGA (specifically the X4003).
>
>                  Thanks
>
>                  Daniel


Article: 29615
Subject: Re: Xilinx tools: RLOC hierarchy with HDL design?
From: brimdavis@aol.com (BriMDavis)
Date: 01 Mar 2001 03:51:00 GMT
Links: << >>  << T >>  << A >>
Jan wrote:
>
>I consider it such a privilege to have to build and maintain
> .S0 and .S1 versions of all my RPMs.

 It looks like they've gone to an XY numbering scheme for Virtex2,
which eliminates the "name-that-slice" problem.

 Also, in the event that you need to RLOC to a particular FFX/FFY 
within a slice in plain-old-Virtex, the mystery "BEL" attribute is 
now documented in the new 3.x library guide, updated  ~late Nov.

>module dff16_s1(clk, ce, d, q) /* synthesis syn_hier="hard" */;

"Stupid FPGA Trick" of the day for Verilog users:

  Make sure you put that semicolon AFTER the meta-comment, or
 your attribute will be silently ignored by the synthesizer...


Ray wrote:
>
>As Jan mentioned, VHDL's generate statements permit parameterized 
>construction of elements, something that is harder to do with verilog.
>I stand corrected on the availability of the user attributes in Verilog 
>(it has been a while since I last investigated using Verilog).

  I saw some Verilog-2000 slides a while ago; IIRC, it looks like 
 they've added some nice 'generate' type capabilities, but the
 attributes are still done with the 'meta-comment' syntax, rather
 than being a part of the language. As was pointed out in the other
 replies, this makes it harder to do things like:

  ram_gen: for i in 0 to 3 generate

    attribute RLOC    of RAMn : label is calc_rloc(i);
    attribute INIT_00 of RAMn : label is calc_init(i,0);
    attribute INIT_01 of RAMn : label is calc_init(i,1);
    -- etc.

    begin

     d_we(i) <= ( NOT d_wr_l ) AND ( NOT d_wr_en_l(i));

     RAMn : RAMB4_S4_S8
       port map
         (
              DOA   => i_dat( (4*i)+3 downto 4*i ),
              -- etc.

VHDL RPM's

  BTW, a while back (~Oct '99), I posted a link to some example 
 VHDL RPM code that worked with M1.5 and Synplicity 5.X :
    ftp://members.aol.com/fpgastuff/tc_test1.zip

  This XC4000 carry chain example code (with nested RLOC's) worked 
 fine (shows up as a single RPM) with M1.5, almost fine with M2.1, 
 but gives the M3.x mapper complete indigestion; however, it 
 should still be useful as a reference.

  ( I suspect the RPM 'detection' rules have changed in the 3.x mapper,
 at least for the older XC4000 families )

  That example code was inspired by Evan's webpage at :
    http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm

  ( I'd post a deja archive link to the relevant threads, but the 
 deja archive seems to have vanished for now. )


Brian Davis



Article: 29616
Subject: Re: UNISIM
From: "Rmi SEGLIE" <rseglie@celogic.com>
Date: Thu, 1 Mar 2001 09:26:44 +0100
Links: << >>  << T >>  << A >>
Hi,
I think the good answer is to "hide" this library for synthesis :

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.std_logic_arith.all;
  use ieee.std_logic_unsigned.all;
-- synopsys translate_off
library unisim;
  use unisim.vcomponents.all;
-- synopsys translate_on

And it works fine !

For GSR, you can use the ROC component for simulation...

"Qian" <junciu@yahoo.com> a crit dans le message news:
ee6fc84.-1@WebX.sUN8CHnE...
> Hi I try to use GSR then I include
> --LIBRARY ieee;
> library IEEE;
> library UNISIM;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.std_logic_unsigned.all;
> use UNISIM.all;
>
> I use Xilinx Foundation and try to
> check syntax, however it says
>
> "library logic name UNISIM cannot be mapped to a host directory"
>
> How to solve it ?
> Thanks al ot!



Article: 29617
Subject: Re: UNISIM
From: "Rmi SEGLIE" <rseglie@celogic.com>
Date: Thu, 1 Mar 2001 09:28:41 +0100
Links: << >>  << T >>  << A >>
Hi,
I think the good answer is to "hide" this library for synthesis :

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.std_logic_arith.all;
  use ieee.std_logic_unsigned.all;
-- synopsys translate_off
library unisim;
  use unisim.vcomponents.all;
-- synopsys translate_on

And it works fine !

For GSR, you can use the ROC component for simulation...


"Qian" <junciu@yahoo.com> a crit dans le message news:
ee6fc84.-1@WebX.sUN8CHnE...
> Hi I try to use GSR then I include
> --LIBRARY ieee;
> library IEEE;
> library UNISIM;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.std_logic_unsigned.all;
> use UNISIM.all;
>
> I use Xilinx Foundation and try to
> check syntax, however it says
>
> "library logic name UNISIM cannot be mapped to a host directory"
>
> How to solve it ?
> Thanks al ot!





Article: 29618
Subject: throughput of SDRAM controller - xilinx appnote 134
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Thu, 01 Mar 2001 11:42:13 +0100
Links: << >>  << T >>  << A >>
Hi,

I am planning to use the SDRAM controller from xilinx's application note
XAPP134. This question is very specific to the documentation of that
application note !

Figure 5 and 6 show timing diagrams of read and write cycles to the
SDRAM controller. When can I start the next access cycle with that
controller ? At what time can I write the next addr_wr command ? Do I
have to wait until T16 or T17 ? Or is the design strongly pipelined ?
Same question for the read timing !

I need this information to calculate the maximun constant datarate by a
given sdram clk with this sdram controller. My requirements are: 1 data
every 26ns (better 20ns).


Matthias
-- 
-------------------------------------------------
\ Matthias Fuchs                                 \
 \ esd electronic system design Gmbh              \
  \ Vahrenwalder Strae 205                        \
   \ D-30165 Hannover                               \
    \ email: matthias.fuchs@esd-electronics.com      \
     \ phone: +49-511-37298-0                         \
      \ fax:   +49-511-37298-68                        \
       --------------------------------------------------

Article: 29619
Subject: * HOT JOBS * ASIC / FPGA / VLSI designers needed - Canada
From: "PROCOM" <derekw@procom.ca>
Date: Thu, 1 Mar 2001 10:33:40 -0500
Links: << >>  << T >>  << A >>
Our client is the leading provider of highly integrated silicon solutions
that enable broadband digital transmission of voice, video, and data. Using
proprietary technologies and advanced design methodologies, the company
designs, develops and supplies integrated circuits for a number of the most
significant broadband communications markets, including the markets for
cable set-top boxes, cable modems, high-speed local, metropolitan and wide
area networks, home networking, Voice over Internet Protocol (VoIP),
residential broadband gateways, direct broadcast satellite and terrestrial
digital broadcast, optical networking, digital subscriber lines (xDSL) and
wireless communications.

They are currently seeking ASIC Designers with the following...

Required Skills and Experiences:

BSEE or equivalent; MSEE preferred, plus 5+ years' of VLSI hardware design
experience.
Position requires working knowledge of Verilog and Synopsys.
Experience with back-end CAE, layout tools, 3D, video, and DSP is a plus.


Responsibilities:

Responsibilities include: definitions of the molecules specifications based
on the system specification; RTL development and debugging, test bench
development; design validation as part of an overall system, system
integration; synthesis of the RTL at a certain clock speed; Implementation
of the test strategy, scan insertion, ATPG test vectors generation.


PROCOM: Established in 1978, Professional Computer Consultants Group Ltd.
(Procom) is a national leader in the provision of Computer personnel on a
contract
and full-time basis. Our clients are comprised of the largest national and
international corporations that utilize technical resources extensively
across a wide range of disciplines. In the Financial Post (March 1999)
Procom was ranked as the 6th largest professional Services Company in
Canada. In November of 1999, Procom was named a Regional finalist in Canada'
s 50 Best Managed Private companies. Our track record is proven with more
than 180 consultants servicing Ottawa's high tech community and more than
1600 Procom consultants currently on assignment throughout. North America.
For further information on this and other opportunities please visit our web
site at www.procom.ca.

Interested candidates are invited to forward their resumes or questions in
confidence to:



Derek Weber
PROCOM

300 March Rd Suite 600
Kanata, Ontario
K2K-2E2
613-270-9339 x231
613-270-9449 (FAX)

derekw@procom.ca
www.procom.ca



Article: 29620
Subject: Re: Soldering and Unsoldering PQFP by hand ...
From: Fred.Chu@avnet.com ("Chu, Fred")
Date: 1 Mar 2001 16:54:49 +0100
Links: << >>  << T >>  << A >>
After some practice with PQ208's, you will find that PQ240's can be tackled
just as effectively too.
Fred Chu

-- 
Posted from porter.avnet.com [12.9.139.170] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 29621
Subject: Re: Virtex DLLs
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 01 Mar 2001 18:48:24 +0100
Links: << >>  << T >>  << A >>
David C. Hoffmeister schrieb:
> 
>     I am currently designing a board with a Virtex and a Virtex-E
> device.  I am hoping to use 200 MHz ZBT SRAM.  The Xilinx app note uses
> two DLLs, one to deskew the external clock and one to deskew the
> internal clock.  My question is, does anyone have any experience using
> these DLLs with clocks near this frequency?  Specifically, I am afraid
> that if I use one pair of DLLs to do this and then use the generated
> clocks in multiple portions of the chip, I am not sure how well the
> clock is deskewed across the entire chip.  For instance, all of the

AFAIK the skew on the dedicated clock nets is <1ns. No need for
additional deskew?!
At least there are many DLLs inside the Virtex-E.

-- 
MFG
Falk

Article: 29622
Subject: What about speed-grade?
From: "Juan M. Rivas" <jmrivas@media.mit.edu>
Date: Thu, 01 Mar 2001 13:31:09 -0500
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------380478FF6FD1990AA7B6B7AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi everyone!

What's the difference in the speed-grade between devices?

I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which
speed grade should I use?  -4, -5, -6.

Thanks all

-Juan
--------------380478FF6FD1990AA7B6B7AA
Content-Type: text/x-vcard; charset=us-ascii;
 name="jmrivas.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Juan M. Rivas
Content-Disposition: attachment;
 filename="jmrivas.vcf"

begin:vcard 
n:Rivas;Juan M.
tel;home:(617)255-1268
tel;work:(617) 253-5097
x-mozilla-html:FALSE
org:Media Lab, M.I.T.;Object Based Media
version:2.1
email;internet:jmrivas@media.mit.edu
title:Research Assistant
adr;quoted-printable:;;20 Ames Street=0D=0A;Cambridge;Massachusetts;02139;U.S.A.
fn:Juan M. Rivas
end:vcard

--------------380478FF6FD1990AA7B6B7AA--


Article: 29623
Subject: Re: What about speed-grade?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 01 Mar 2001 10:54:54 -0800
Links: << >>  << T >>  << A >>
You might want to use the slowest (cheapest) speed grade ( lowest number ) that
achieves your performance. But you cannot describe the speed requirements of  a
complete design with just one number.
Pick one speed grade, analyze the performance and look how well it matches your
expectations and demands. Then you can easily analyze it for a different speed
grade. Every parameter in a faster speed grade is faster, but not all by the
same percentage.
BTW, I would guess that the slowest available speed grade meets your
requirements.
And don't forget, if you run into a speed bottleneck, pipelining can often save
the day, and it is (almost) free.

Peter Alfke, Xilinx Applications

"Juan M. Rivas" wrote:

> Hi everyone!
>
> What's the difference in the speed-grade between devices?
>
> I'm thinking about using a Virtex XCV200 or XCV150 at 100Mhz, which
> speed grade should I use?  -4, -5, -6.
>
> Thanks all
>
> -Juan


Article: 29624
Subject: Re: Virtex DLLs
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 01 Mar 2001 13:25:48 -0800
Links: << >>  << T >>  << A >>


> David C. Hoffmeister schrieb:
> >
> >      I am not sure how well the
> > clock is deskewed across the entire chip.
>

Very well, thank you.
You actually get a timing report that takes into account clock routing and
loading, and their deltas.
The worst-case skew is well below one nanosecond. In Virtex-II with its even
more buffered structure, it is below 200 ps. Across the chip ! Almost
unbelievable, but true.

Falk, are you coming to our seminar, next Thursday (8th) in Mnchen, Friday in
Frankfurt ? I'll give the 3-hour Virtex-II presentation. In German...

Peter Alfke, Xilinx Applications




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

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