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 39300

Article: 39300
Subject: Re: Virtex-II and SDRAM Controller at 133MHz
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 06 Feb 2002 01:14:29 +0000
Links: << >>  << T >>  << A >>


Jay wrote:

> Why don't you give it a rough cut, then synth, and P&R and see what
> you get.  If you're a designer of similar caliber to some of the
> regular posters on here then you should have a good shot at it.  We
> run our ECC SDRAM interface at 25MHz, but then again, its a standard
> cell design being proto'd in a Vertex 2 6000, not a purpose build FPGA
> design.
>

So far I've manged to push ours to 100MHz or so in an XCV600E-6, no floorplanning or hard
macro'ing,  just the auto P&R tools. The target/goal, after some floorplanning & much
sweat+cursing etc, is 125/133Mhz in a -7.

Then, sometime in April, we'll move to the V2 and I'll start similing again.



Article: 39301
Subject: Re: FPGA vs GAL : Lattice Its a TROLL
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 06 Feb 2002 01:25:44 +0000
Links: << >>  << T >>  << A >>


Philip Freidin wrote:

> It's a TROLL, don't encourage it.

Is that some sort of Hipcrime variant ?


Article: 39302
Subject: Re: FPGA --> SDRAM & Groundbounce: Latchup Possible?
From: rk <stellare@nospamplease.erols.com.invalid>
Date: Tue, 05 Feb 2002 21:47:26 -0500
Links: << >>  << T >>  << A >>
Hi,

Thanks for the quick response; comments embedded below.

Austin Lesea wrote:
> 
> RK,

It's rk, not RK.  It looks funny in big letters.  ;-)

 
> The concern is that if you inject enough current below ground, and
> forward bias the parasitic SCR structure, you may cause latchup.  A few
> years ago we were really worried about this for 4K (a customer had done
> no signal integrity engineering, and created an SI nightmare for his
> company), so we wired 128 outputs through 1 foot of transmssion lines (50
> ohm coax) to 128 inputs in order to provide the horrendous overshoot and
> undershoot required.  We were slamming > 20 mA on each and every pin,
> both above 3.3 Vdc and below 0.0 V by as much as .71 volts (after all,
> the diode is clamping as hard as it can, so voltage doesn't tell you
> anything at all--you need to know the current).

Yup; I was just relaying what I had.  Another engineer went to a meeting
and brought back a set of viewgraphs.  They simply had recorded one
parameter of the ground bounce, max voltage.  Also, I don't have a physical
model of the board so I don't know how long the lines were, how many loads
on it, nada.

From the cartoon that they showed, it didn't look like it was clamping; it
was just a tiny little peak, no flat top.  It was not an oscilloscope
picture.

Based on the XQR400XL data sheet, it didn't seem like there should be a
problem in the FPGA, although some people were saying it might have latched
up.  

   During transitions, the device pins may undershoot to -2.0 V or
   overshoot to + 7.0 V, provided this over- or undershoot lasts
   less than 10 ns and with the forcing current being limited to
   200 mA.

They didn't have a time scale on the picture or currents.  200 mA on a
whole pile of pins is a whole mess of current.  Doubt they did that for 10
ns.

 
> No problem.
> 
> It seems that to trigger the SCR latchup, it requires a steady currents
> for many tens of nanoseconds, at currents greater than 300 mA for the
> entire edge, at a voltage above or below ground by a diode drop.
> 
> These tests were done on 4Kxl and 4Kxla, which had almost identical 0.35u
> IO transistor structures.

This was, as far as I know, an XQR device, although I'm not sure.  Info is
sketchy.  :-(

 
> Bottom line, don't do that!

Yikes!  I didn't do anything!


>                          Even if the design doesn't latch up, it will
> have incredible jitter, and probably have other problems caused by all of
> that ground bounce.  Any voltage that causes the diodes to be forward
> biased is going to lead to problems, one way or another.  As "just an old
> engineer" you should be familiar with signal integrity from the days when
> being an engineer meant you knew what Ldi/dt meant, and knew how to
> calculate the voltage at the end of a transmission line.

Yup.  I don't like designs that turn on the diodes at all.  But that's just
me.


> Now latching up the SDRAM might well be possible (maybe they didn't have
> time to characterize the parasitic SCR structure, or to control the
> alphas of the npnp stucture), but don't blame the FPGA!  If you hit it
> with a hammer, it would break, too.  Is it the hammer's fault?

I blame no one.

Yet.  ;-)

I just hadn't messed with DRAMs in a while, been using SRAMs, and don't
know how susceptible the devices were to latch up.  The last few times I
did DRAM designs, I was very, Very, VERY careful to have nicely terminated
lines, controlled impedance boards, and did not allow the signals to go
below ground or above Vcc and didn't have any problems.  From what I can
tell from the little bit of information that I have, they didn't have
terminated signals and were using high-slew outputs from the FPGA.  They
apparently didn't test the SDRAMs for latchup from driving inputs below
ground as part of the failure report.  Me, being a bit lazy, don't want to
have to set that up and do that.  So I was hoping someone here might have
some experience with more modern SDRAMs.

Thanks!

-- rk
Just an OldEngineer

> 
> Austin
> 
> 
> 
> 
> rk wrote:
> 
> > Hi,
> >
> > A friend asked me a question and perhaps someone out there can help.
> > There
> > was a Xilinx 4036XL hooked up to an SDRAM (no, he didn't know what
> > manufacturer and model) and the claim was that groundbounce in the FPGA
> >
> > from SSO's caused the SDRAM to latchup; this was supposed to explain a
> > functional failure that would be cleared by cycling the power.
> >
> > That sounds a bit odd to me, although I haven't used SDRAM and am not
> > familiar with their details.  For a low, quiet output, they measured a
> > 710
> > mV peak below ground; that doesn't sound too bad, about a diode drop.
> > Again, I don't know what's going on inside SDRAM technology so I
> > thought
> > I'd ask and see if anyone has any experience with this.
> >
> > Thanks in advance,
> >
> > --
> > Just an OldEngineer

Article: 39303
Subject: Re: FPGA vs GAL : Lattice
From: Keith R. Williams <krw@attglobal.net>
Date: Tue, 5 Feb 2002 23:24:06 -0500
Links: << >>  << T >>  << A >>
In article <ee74ad1.6@WebX.sUN8CHnE>, ls@swissonline.ch says...
> I really do not know what is wrong with you guys. Why donīt you just admit that 80% of your applications could be implemented by using 16V8s? I believe a very intelligent guy like Ray Andraka could fill up a ispLSI1032 (have you seen all that complicated stuff on his web page??). But: most of you guys?? Be serios with me, 
please!! I mean, you guys use a Spartan or even Virtex part and leave 99% of the resources free, donīt you? Then you sell the application and claim that you have spend weeks or month to fill it up. Honest engineers like me do only charge the real work they have done. And this usually fits into a 16V8 and sometimes into a 20V8 and 
for real big stuff into a 22V10. Why donīt you just admit that I am right?
> 
> And: What do you want to tell me about MP3 players and so. I mean, I can buy a MP3 player at Freys or so and nobody really develops that complicated stuff himself. This usually is the hard work of multiple engineers at Sony or so.
> 
Yeah, you're right.  I didn't use more than 10-15% of a Virtex 
600E.  However, I did use 514 out of 512 I/O (neat eh?) and 
LVCMOS, LV_PECL, HSTL, and LVTTL I/O levels though.  Then there 
was the that DLL, thingy.

Now, go back under your bridge like a good little troll.

----
  Keith

Article: 39304
Subject: Re: Programming Altera PGAs.
From: Duane Hague <dhague@neo.rr.com>
Date: Wed, 06 Feb 2002 05:14:16 GMT
Links: << >>  << T >>  << A >>
In article <1012949075.213793@busy.neca.nec.com.au>, 
jamesf@xxxnec.com.au says...
> Hi,
> 
> just scored some used, but reusable EPM7064 gate arrays that I would like to
> use in some home projects. Unfortunately they are NOT "in circuit
> programmable" and require a seperate programmer.
> 
> The Altera web site has no details on programming these devices, but do have
> free software for circuit entry etc.
> 
> Can a programmer be built by me for these parts (I don't need high speed or
> flexibility)? Obviously my budget doesn't allow for a bought one - unless
> extremely cheap (few 10s of $), else I'd just buy one.
> 
> Does anyone know where programming details can be found? Surely such details
> are freely available!
> 
> My return address has been corrupted.
> To reply either remove the 'xxx', or reply to the group, or email
> 
> james.fenech (at) nec.com.au
> 
> Thanks,
> James.
> 
> 
> 
> 
James,
	While someone will eagerly correct me if I'm wrong, I believe that  
you are out of luck on doing your own cheap programmer.  I was using 
EPM5xxx/7xxx parts back in the 1990-1995 timeframe.  IIRC, the 
programming of these chips required a shaped-timed pulse (current, 
voltage, and dV/dT controlled) on multiple pins.  The published 
programming details were quite limited at that time (viewed as semi-
proprietary IIRC, and at a later date even the limited programming data 
was dropped from the Altera documentation [probably because it was not 
useful to an end-user anyway]).  There was no cheap way to programm the 
chips other than Altera's programmer hardware ($700~ for programmer and 
chip adapter) or one of the Data-I/O generic Programmers (with adapter 
and software, $3K~).  This was one of the reasons Altera (and everyone 
else went to ISP in the first place).  Maybe your "source" also has an 
old Altera programmer box stuck in a cabinet gathering dust?

	Suggest that you consider your salvaged parts as "wall-art" and 
plan on using ACEX-1K which are ISP and fairly cheap and also have "App 
Notes" available on how to build your own "cable/programming-adapter" 
for a PC.  Don't be surprised if someone else jumps in to say that you 
would be better off with Xilinx and their "Free Webpack".

Either way, Good Luck!!


Article: 39305
Subject: Re: FPGA vs GAL : Lattice
From: Bob Perlman <no-spam@sonic.net>
Date: Wed, 06 Feb 2002 05:49:34 GMT
Links: << >>  << T >>  << A >>
On Tue, 5 Feb 2002 12:59:44 -0800, ls_user <ls@swissonline.ch> wrote:

>next time i will tell you something about 74LS00īs. Will get some of you with that as well. 
>
>have a nice evening

What a sophisticated jokester you are!  Here you had us thinking that
you were some kind of bozo, when in fact you're a...oh, wait a minute.

Bob Perlman



Article: 39306
Subject: Re: Programming Altera PGAs.
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 06 Feb 2002 19:01:57 +1300
Links: << >>  << T >>  << A >>
James wrote:
> 
> Hi,
> 
> just scored some used, but reusable EPM7064 gate arrays that I would like to
> use in some home projects. Unfortunately they are NOT "in circuit
> programmable" and require a seperate programmer.
> 
> The Altera web site has no details on programming these devices, but do have
> free software for circuit entry etc.
> 
> Can a programmer be built by me for these parts (I don't need high speed or
> flexibility)? Obviously my budget doesn't allow for a bought one - unless
> extremely cheap (few 10s of $), else I'd just buy one.
> 
> Does anyone know where programming details can be found? Surely such details
> are freely available!

No, because the support is too costly. It wont work first time, and then
what happens...

You might find an old programmer that supports the non-isp models, but
better
is to move to ISP CPLDs

In this class of CPLD are

Altera 7064S - newer ISP versions of those you have 
Xilinx CoolRunner XCR3064
Atmel ATF1504AS

Atmel have the best 5V support.

-jg

Article: 39307
Subject: Re: Making Altera development quicker
From: "z.karim" <z.karim@attbi.com>
Date: Wed, 06 Feb 2002 06:16:56 GMT
Links: << >>  << T >>  << A >>
Altera guys can correct me if I'm wrong, but I believe the version of
Modelsim
that is packaged with Quartus II is a stripped down version that has
limitations
for the size designs it simulates quickly.  If designs are above a certain
size, I
believe that the simulator slows considerably.

Good luck


"Paul" <nospam@nospamplease.com> wrote in message
news:o1Z78.4838$il3.839543@news6-win.server.ntlworld.com...
> I'm investigating ways of improving my development throughput.
>
> At the moment I'm using Leonardo Altera Edition for synthesis, Altera
> Quartus 2 for P&R and Quartus 2's simulator.
> Targeting Apex 20KE600-1X devices
>
> I'm using an Athlon 1GHz with 512MB RAM.
>
> I'm in the middle of a project and am finding that as the design comes
> together, compilation and more especially simulation is becoming a real
> problem.
>
> I realise that the most positive step may be to either use the Modelsim
> Altera edition or invest in a full Modelsim license.
>
> The problem is that Modelsim does appear somewhat more cryptic than using
> Alteras offering. Plus I'm mid-project so changing from my *.vwf approach
to
> modelsim may take time I haven't got. :)
>
> What I'd like is
>
> a) How much better is Modelsim than Altera's own simulator especially for
> post layout analysis. Since that's like asking about string length, I'd
> accept anecdotal evidence based on your own designs :Ž)
>
> b) Are full versions of Modelsim that much faster than the Altera edition.
>
> c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual
> processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound
> or memory bandwidth bound) and does an MP setup provide any noticeable
> improvement or are all tools resolutely single threaded.
>
> d) Any other suggestions.
>
> I am already trying as best I can to restructure testing to minimise the
> issues, but these 10 hour simulation times (when it doesn't crash) are
> really non-productive.
>
> Paul
>
> Background on the design, though probably of limited additional help:
>
> Typically my designs use a lot of EABs as FIFOs, a lot of 32bit register
> moving about and various high speed memory interfaces 120MHz SDRAM x 2 on
> each chip. Logic is relatively simple and I believe I've taken enough
> pipelining precautions to limit routing problems.
>
> I'm trying to simulate passing message packets in, processing them,
storing
> them, acting upon them etc. To capture a large part of this as the system
> comes together I'm finding I need simulations of up to 10ms (though 1ms is
> more typical).
>
> I've simulated at individual block level, so its really only the last
level
> of testing that
>
>
>



Article: 39308
Subject: Re: ClkEnable vs gated clock
From: nurit.eliram@mailandnews.com (Nurit Eliram)
Date: 5 Feb 2002 23:18:08 -0800
Links: << >>  << T >>  << A >>
Antonio,
The reason is very simple,
using clock enable you actually adding a multiplexer in front of every 
clock enabled flip-flop.
There is more logic in every path that ends with a flop.

The good news is that you probably have multi cycle paths.
You have to tell to the P&R about these paths and then the
max clock frequency will rise up again.

Nurit

dottavio@ised.it (Antonio) wrote in message news:<fb35ea96.0202032328.296fe30@posting.google.com>...
> I coudn't understand why for a gated clock project I was fighting to
> obtain 150MHz and now with
> the clkEnable version of the same I'm fighting to obtain only 70MHz,
> to what this is due ??
> All suggest me to use clkEnable if there are situation where clock
> enable is not a must, is it
> really necessary in my project where I've a master clock from which I
> obtain 3 derived clock in
> the gated clock version and 3 enable signal (...via a programmable
> counter) in the clock enable
> version. And to put in my thesis and based on your experience please
> add some lines to the following:
> 
> ***********************************************************************************************
> Clock Enable Clock Enable Clock Enable Clock Enable Clock Enable Clock
> Enable Clock Enable
> ***********************************************************************************************
>   					 PRO						
> P1) Immunity to temperature change			
> P2) Only CLK recognized by synthesizer
> 
> 					VERSUS
> V1) slow (.. I don't know why)
> v2) More power dissipated because all the circuit run at f_clk
> 
> 
> ***********************************************************************************************
> Gated Clock Gated Clock Gated Clock Gated Clock Gated Clock Gated
> Clock Gated Clock Gated Clock
> ***********************************************************************************************
> 
>   					 PRO						
> P1) Less power dissipated because not all the circuit run at f_clk
> P2) 
> 
> 					VERSUS
> V1) Derived clock not recognized by synthesizer
> v2)

Article: 39309
Subject: Re: Adding internal JTAG chains on FPGA
From: taita72@hotmail.com (Marco Serafini)
Date: 6 Feb 2002 04:04:40 -0800
Links: << >>  << T >>  << A >>
Ciao Luigi,

have you already looked at AN39? You can download this PDF document
through the Altera's web site. I think you can find what you need.

Marco

guiducci@cern.ch (Luigi) wrote in message news:<235ed672.0202050639.17879a70@posting.google.com>...
> I'm a student and I'm developing a design on an APEX20k. This device
> is not really a choice now, I just started to try Quartus. I'll have
> the need to add a jtag chain, not attached to the boundary scan one,
> but parallel, to be used for some configuration registers I'll have in
> the chip. It seems that the apex has a built in port, the tap
> controller, a boundary scan registers chain (in silicon?). No way to
> add what I need using basically the same jtag port? I could rewrite by
> hand all the jtag circuitry, but would this mean I could not use
> anymore the pin-dedicated fast input/output registers?
> Sorry if i wasn't clear or if it's a stupid question
> 
> Luigi

Article: 39310
Subject: Virtex 2 rect->pol conversion
From: ykernin@cmseddyscan.com (Yann)
Date: 6 Feb 2002 04:48:15 -0800
Links: << >>  << T >>  << A >>
Hello,

I'm looking for a Virtex 2 method to convert (or approximate) the
angle from the rectangular coordinates (x, y) of a point. The x,y
coordinates are coded on 16 bits.

Thanks for your help
Yann

Article: 39311
Subject: Re: FPGA vs GAL : Lattice
From: hamish@cloud.net.au
Date: 06 Feb 2002 12:52:18 GMT
Links: << >>  << T >>  << A >>
ls_user <ls@swissonline.ch> wrote:
> Thank you, John. But: What is a FFT. Why should I wnat to implement something what I do not know? I can do everything I could imagine by using 16V8s and 20V8s and I believe most of you guys could do the same. However, it seems to be the trend to use larger devices. My believe is that most people use large FPGAs and leave all the not used area free. All of them could use 16V8s and save a lot of money. I just want my applications to be functional and have the lowest device cost. Poor stupid FPGA users!

I guarantee you that for the application I'm doing, I couldn't fit enough
16V8s on the board (ignoring the power budget). Possibly not a few cubic
metres. And do those run at 160+ MHz?

Fortunately, the 2V6000 in an 1152 pin BGA package is a little bit
more power and density friendly.

I'd like to see a board full of PALs running 10 gigabits per sec throughput.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 39312
Subject: Re: Programming Altera PGAs.
From: "Victor Schutte" <victors@mweb.co.za>
Date: Wed, 6 Feb 2002 15:00:33 +0200
Links: << >>  << T >>  << A >>
I agree. The cost of a couple of 7064Ss and a homemade ByteBlaster cable is
a lot less than an Altera programmer.

Victor

"Jim Granville" <jim.granville@designtools.co.nz> wrote in message
news:3C60C6D5.48CB@designtools.co.nz...
> James wrote:
> >
> > Hi,
> >
> > just scored some used, but reusable EPM7064 gate arrays that I would
like to
> > use in some home projects. Unfortunately they are NOT "in circuit
> > programmable" and require a seperate programmer.
> >
> > The Altera web site has no details on programming these devices, but do
have
> > free software for circuit entry etc.
> >
> > Can a programmer be built by me for these parts (I don't need high speed
or
> > flexibility)? Obviously my budget doesn't allow for a bought one -
unless
> > extremely cheap (few 10s of $), else I'd just buy one.
> >
> > Does anyone know where programming details can be found? Surely such
details
> > are freely available!
>
> No, because the support is too costly. It wont work first time, and then
> what happens...
>
> You might find an old programmer that supports the non-isp models, but
> better
> is to move to ISP CPLDs
>
> In this class of CPLD are
>
> Altera 7064S - newer ISP versions of those you have
> Xilinx CoolRunner XCR3064
> Atmel ATF1504AS
>
> Atmel have the best 5V support.
>
> -jg



Article: 39313
Subject: Re: ClkEnable vs gated clock
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Feb 2002 13:39:50 GMT
Links: << >>  << T >>  << A >>
Clock enabled circuits can get slow because of the high fanout on the clock enable net.  You may
need to distribute the clock enables with a tree of flip-flops.

Antonio wrote:

> I coudn't understand why for a gated clock project I was fighting to
> obtain 150MHz and now with
> the clkEnable version of the same I'm fighting to obtain only 70MHz,
> to what this is due ??
> All suggest me to use clkEnable if there are situation where clock
> enable is not a must, is it
> really necessary in my project where I've a master clock from which I
> obtain 3 derived clock in
> the gated clock version and 3 enable signal (...via a programmable
> counter) in the clock enable
> version. And to put in my thesis and based on your experience please
> add some lines to the following:
>
> ***********************************************************************************************
> Clock Enable Clock Enable Clock Enable Clock Enable Clock Enable Clock
> Enable Clock Enable
> ***********************************************************************************************
>                                          PRO
> P1) Immunity to temperature change
> P2) Only CLK recognized by synthesizer
>
>                                         VERSUS
> V1) slow (.. I don't know why)
> v2) More power dissipated because all the circuit run at f_clk
>
> ***********************************************************************************************
> Gated Clock Gated Clock Gated Clock Gated Clock Gated Clock Gated
> Clock Gated Clock Gated Clock
> ***********************************************************************************************
>
>                                          PRO
> P1) Less power dissipated because not all the circuit run at f_clk
> P2)
>
>                                         VERSUS
> V1) Derived clock not recognized by synthesizer
> v2)

--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39314
Subject: RE Xilinx 3.3SP8, Beware!
From: "niv" <niv@ntlworld.com>
Date: Wed, 6 Feb 2002 13:43:47 -0000
Links: << >>  << T >>  << A >>
Well, sussed out my problem with my DPRAM built with BlockRAMs.

It's all Xilinx fault.  They've owned up to "accidentally" removing the pin
polarity option for signals on Coregen BlockRAMs that goes with 3.3.

I had built a DPRAM with clka using a -ve clock edge in coregen with 3.1i
However, this isn't supported in 3.3, so the PAR tool just didn't connect my
clock to the BlockRAM.  Wonderful! (NOT).

Apparently, pin polarity is back in 4.1, I'll have to wait for our IT
support group to install it, but god knows when that'll be; they're useless
most of the time when it comes to putting on new s/w.  We're usually a t
least one release behind what's available in both Xilinx and Mentor tools.

Enough whinging, time for some more VHDL; at least the text editor doesn't
need upgrading!

Regards, Niv



Article: 39315
Subject: Re: Virtex 2 rect->pol conversion
From: Ray Andraka <ray@andraka.com>
Date: Wed, 06 Feb 2002 13:44:05 GMT
Links: << >>  << T >>  << A >>
Even with v2, the best method for rectangular to polar conversion is
a CORDIC rotator unless you have very limited resolution
requirements.  You can read my paper "a survey of CORDIC algorithms
for FPGA based computers" for (what I am told is) a good explanation
of the CORDIC algorithm.  The paper is available at no cost from my
website.

Yann wrote:

> Hello,
>
> I'm looking for a Virtex 2 method to convert (or approximate) the
> angle from the rectangular coordinates (x, y) of a point. The x,y
> coordinates are coded on 16 bits.
>
> Thanks for your help
> Yann

--
--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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 39316
Subject: Re: Xilinx synthesis tools
From: "John McCluskey" <john_mccluskey@hotmail.com>
Date: Wed, 6 Feb 2002 09:19:19 -0500
Links: << >>  << T >>  << A >>
This is an interesting question, since ISE 4.2 is now working it's way
through the manufacturing channel.  The following excerpt is from the
"What's New in ISE 4.2" file on the release CD.

XST Enhancements
XST includes the following enhancements:

  a.. Preservation of internal buses by using bus<#> naming convention
  b.. Preservation of upper and lower case in the final netlist
  c.. Support for property lists for buses in the attribute syntax
  d.. VHDL Enhancements
    a.. Support for concatenation of slices when target is an array of
vectors
    b.. Support for constant definitions in processes
    c.. Support for signals declaration in a package file
    d.. Support for "loop" and "while...loop" statements
    e.. Improved run time and memory use for "next," "exit," and "return"
processing in "loop" statements
    f.. Support for records in constant declarations
    g.. Support for record type in function return
    h.. Support for "string" type in functions
    i.. Support for unconstrained vectors in component declaration component
    j.. Improved attribute calculation through functions
    k.. Enhanced multi-dimensional array support
XST supports the Virtex-II PRO device family. XST now also supports the new
CoolRunner-II device family as follows:

  a.. Support for inference of a dual edge triggered flip-flop
  b.. Support for the following constraints:
    a.. DIVIDE_BY
    b.. DIVIDER_DELAY
    c.. COOL_CLK
    d.. DATA_GATE
For syntax examples, see Xilinx Answer Record #13166.

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

This is all pretty cool, but it still doesn't support the IEEE
real_math.vhd package (IEEE 1076.2).   That will probably be next year.









"Arvin Patel" <apatel@chello.no> wrote in message
news:wkvgddxc2x.fsf@chello.no...
> Does anyone have any experience with the latest version of
> Xilinx XST? I would be interested in any comments on stability
> of the tool and of the quality of results.
>
> Does anyone have any comparisons of XST and Synopsys FPGA Express?
> I have made some tests and it seems that XST gives slightly
> better timing results than FPGA Express.
>
> It seems from earlier postings that many people use Synplify.
>
> Thanks in advance.
> Arvin Patel
>
>
>
>



Article: 39317
Subject: Re: solutions manuals, and no they are not for school
From: ricklyon@remove.onemain.com (Rick Lyons)
Date: Wed, 06 Feb 2002 14:23:20 GMT
Links: << >>  << T >>  << A >>
On Tue, 05 Feb 2002 14:31:49 -0500, Jerry Avins <jya@ieee.org> wrote:

  snipped)
>
>Be fair! As I read the original question, my impression was that he
>wanted to know of any algorithm texts for which an answer manual is
>available. If there is one, he wants it for self study. I don't leave my
>car keys in the ignition when I park, but I don't assume that every
>passerby is a thief. I should have thought to tell him that many texts
>have answers to, say, odd-numbered problems. 
>
>Jerry
>-- 

Jerry, you are kind-hearted.
Of course I don't know what's in strut911's 
heart, but his comment that he wanted solutions manuals 
for:

  "almost anything related or of practical use to 
   engineering."

seems so odd.  To state that he'll evaluate the quality 
of a textbook by looking at the solutions manuals defies 
common sense.  What if he said: "Send me the keys to your 
homes, so I can decide what kind of house to buy"?

[-Rick-]
P.S. Just to be safe Jer, assume that every passerby is a 
thief, until proven otherwise.

Article: 39318
Subject: Re: FPGA --> SDRAM & Groundbounce: Latchup Possible?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 06 Feb 2002 16:31:20 +0000
Links: << >>  << T >>  << A >>
rk <stellare@nospamplease.erols.com.invalid> writes:
<snippage>
> 
> I just hadn't messed with DRAMs in a while, been using SRAMs, and don't
> know how susceptible the devices were to latch up.  The last few times I
> did DRAM designs, I was very, Very, VERY careful to have nicely terminated
> lines, controlled impedance boards, and did not allow the signals to go
> below ground or above Vcc and didn't have any problems.  From what I can
> tell from the little bit of information that I have, they didn't have
> terminated signals and were using high-slew outputs from the FPGA.  They
> apparently didn't test the SDRAMs for latchup from driving inputs below
> ground as part of the failure report.  Me, being a bit lazy, don't want to
> have to set that up and do that.  So I was hoping someone here might have
> some experience with more modern SDRAMs.
> 

According to my Micron datasheet (MT48LC64M4A2):


PARAMETER/CONDITION                       SYMBO L MIN    MAX    UNITS
INPUT HIGH VOLTAGE: Logic 1; All inputs     VIH    2  VDD + 0.3   V
INPUT LOW VOLTAGE : Logic 0; All inputs     VIL  -0.3    0.8      V

And the associated footnote:

VIH overshoot: VIH (MAX) = VDDQ + 2V for a pulse width = 3ns, and the
pulse width cannot be greater than one third of the cycle rate.

VIL undershoot: VIL (MIN) = -2V for a pulse width = 3ns.

<more snippage>

HTH!

Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 39319
Subject: Re: Making Altera development quicker
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 06 Feb 2002 16:56:53 +0000
Links: << >>  << T >>  << A >>
"Paul" <nospam@nospamplease.com> writes:

<snip>
> 
> What I'd like is
> 
> a) How much better is Modelsim than Altera's own simulator especially for
> post layout analysis. Since that's like asking about string length, I'd
> accept anecdotal evidence based on your own designs :Ž)
> 

I imagine lots, but I've never used Altera's sim in anger

> b) Are full versions of Modelsim that much faster than the Altera edition.
> 

Lots on big things.  I believe an exponential slowdown can be expected
with design size in the AE version.

> c) I've been toying with getting a 2GHz P4 or an AMD 1900+ or even a dual
> processor rig. (With 1Gb RAM). Does performance scale well (i.e. CPU bound
> or memory bandwidth bound) and does an MP setup provide any noticeable
> improvement or are all tools resolutely single threaded.
> 

I reckon you'd be memory bandwidth bound, esp. on large post-layout
stuff.  All the benchmarks I;ve seen show AMD being much faster than P4.

> d) Any other suggestions.
> 

Hardware emulator :-)  Bit expensive though.  Alternatively, you
sometimes can't beat just configuring a device and hanging scope
probes off it.

> I am already trying as best I can to restructure testing to minimise the
> issues, but these 10 hour simulation times (when it doesn't crash) are
> really non-productive.
> 

I bet :-)

<snip>

HTH!
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 39320
Subject: Re: FPGA vs GAL : Lattice Its a TROLL
From: Davis Moore <dmoore@ieee.org>
Date: Wed, 06 Feb 2002 10:00:23 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:

> Philip Freidin wrote:
>
> > It's a TROLL, don't encourage it.
>
> Is that some sort of Hipcrime variant ?

>From http://www.altairiv.demon.co.uk/troll/trollfaq.html#one

troll v.,n. To utter a posting on Usenet designed to attract predictable
responses or flames. Derives  from the phrase "trolling for
      newbies"; which in turn comes from mainstream "trolling";, a style
of fishing in which one trails bait through a likely spot hoping for a
      bite. The well-constructed troll is a post that induces lots of
newbies and flamers to make themselves look even more clueless than
      they already do, while subtly conveying to the more savvy and
experienced that it is in fact a deliberate troll. If you don't fall for
the
      joke, you get to be in on it.

The following extract is from a broader expansion of the defining
comments given above:

      In Usenet usage, a "troll" is not a grumpy monster that lives
beneath a bridge accosting passers-by, but rather a provocative
      posting to a newsgroup intended to produce a large volume of
frivolous responses. The content of a "troll" posting generally falls
      into several areas. It may consist of an apparently foolish
contradiction of common knowledge, a deliberately offensive insult to
the
      readers of a newsgroup, or a broad request for trivial follow-up
postings.


Article: 39321
Subject: Re: FPGA --> SDRAM & Groundbounce: Latchup Possible?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 06 Feb 2002 10:32:55 -0800
Links: << >>  << T >>  << A >>
rk wrote:
> the claim was that groundbounce in the FPGA
> from SSO's caused the SDRAM to latchup; this was supposed to explain a
> functional failure that would be cleared by cycling the power.

Any CMOS device can latch up if device pins
are forced below ground with enough energy.

CMOS wells and substrates combine to form 
unintended n-p-n-p (SCR) structures. 

If these get triggered you get a 
a pretty good short from power to
ground through the device.

This may destroy the chip, or if you are lucky, 
requires a power cycle to turn off the SCR.

To fix this, you need a better ground plane
and/or better supply bypassing.

> For a low, quiet output, they measured a 710
> mV peak below ground; that doesn't sound too bad, 

That is above the maximum low value for most devices,
another indication an inadequate ground plane.

 -- Mike Treseler

Article: 39322
Subject: designing a protocol analyzer for proprietary serial bus
From: strut911@hotmail.com (strut911)
Date: 6 Feb 2002 10:33:04 -0800
Links: << >>  << T >>  << A >>
hello.
i have been given the task of designing a protocol analyzer for my
company's proprietary serial bus to help speed up the software design.
i guess that means it needs to be finished quickly because software is
really struggling right now. i have never designed a protocol analyzer
before, but my first instincts are that i will need an fpga, a bunch
or RAM (or Block RAM) if the quantity is sufficient, and a
microcontroller. the serial bus runs at a max speed of 25 mhz although
it can be slower if needed. i think it would be no problem to hit that
target in today's FPGAs. my main question would be how to partition
the hardware and software to be optimal to the design. my first
thoughts were to take the incoming serial data, dump it all to memory
when some trigger condition is asserted, and then have software
post-process it into the various protocol control or data fields. if
it is this easy (i doubt it is), then my fpga requirements would be
minimal. however, when i look at the ethernet protocol analyzer my
company has, it looks quite a bit more sophisticated than my
minimalist design.
another idea i had was to forget the microcontroller, and dump the
memory contents to a PC when the data acquisition is finished. that
way, i can let the PC post-process all the data and put it in a nice,
colorful gui. are my ideas too simplistic?
strut911

Article: 39323
Subject: Pseudorandom Bitstream
From: Stromeko@nexgo.de (Achim Gratz)
Date: 6 Feb 2002 10:37:41 -0800
Links: << >>  << T >>  << A >>
[I posted a similar message earlier, but it seems it didn't get
through. My apologies if you see this twice.]

Hello,

I would like to know if there are efficient methods, easily
implementable with high speed in an FPGA, to produce a pseudorandom
bitstream with a known and finely, at runtime adjustable density of 1s
or 0s. The density would be below 1/8 or 1/32, this excludes densities
around 0.5 that are easily obtained with LSFR. If several such
bitstreams could be produced that have no correlation amongst each
other that would be great. The randomness really is only a requirement
as far as the correlation/autocorrelation properties go and that the
bandlimited spectrum of the integral of the signal must be white.

I have found a few leads on LFSR implementations that yield pink
instead of white noise, but AFAIK noone figured out how to obtain
arbitrary let alone continuously adjustable frequency responses. Plus
the pink noise, to the best of my knowledge, is not obtained from the
bitstream, but some code the LFSR outputs.

Any hints in which directions I might search?


Achim.

Article: 39324
Subject: Re: Pseudorandom Bitstream
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 06 Feb 2002 10:45:37 -0800
Links: << >>  << T >>  << A >>
Achim Gratz wrote:

> I would like to know if there are efficient methods, easily
> implementable with high speed in an FPGA, to produce a pseudorandom
> bitstream with a known and finely, at runtime adjustable density of 1s
> or 0s. 

How about one LFSR for the basic bitstream and another
to pick the bit positions to zero out for the required
density setting.

  -- Mike Treseler



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