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 94025

Article: 94025
Subject: Re: Using posedge and negedge causing me grief
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 04 Jan 2006 12:43:00 -0800
Links: << >>  << T >>  << A >>
Mike Oxlarge wrote:
> On Wed, 04 Jan 2006 11:36:30 -0800, Andy Peters wrote:
>>The simple rule to remember is that you can't assign to a signal in
>>more than one always block.  Put the synchronous reset curval <= 5; in
>>the negedge-clocked block.
>>
>>-a
> 
> 
> I get what you're saying, and have tried your (and the other's) suggestion
> of putting the reset in the negedge-clocked block, and it synthesizes just
> fine. However, I'm now trying to implement what mk suggested:
> 
> <quote mk>
> ...
> You don't need a two phase implementation which necessiates mixed clock
> edges. You can do everything you need with a single edge. Imagine a cloud
> of logic which takes your enable and the cnt value and calculates the next
> value of cnt to be presented. When the clock edge happens this value gets
> to the flop output and the cycle starts again.
> ...
> </quote mk>
> 
> Any ideas on how I can implement what he suggested? I'm working on it, but
> not making much progress. I'm sure there's probably a simple and elegant
> solution to this that I'm missing.
>  

My suggestion would be eliminate using both the posedge and negedge
conditions in your design and just use posedge for the clock edge.

You have created a half-cycle path in your design when it appears
that you have no need to do so.  This will likely lead to a race
condition (aka hold violation) where some of the data gets through
the other edge when it shouldn't have or a setup violation where
the data doesn't get to the register on the other edge in time.

Unless you really need to use opposite edges for a very specific
timing reason you should avoid doing so it minimize lengthy debug
sessions where the design works when it's cold and then starts to
fail when it warms up or the reverse.

Ed

Article: 94026
Subject: Re: Xilinx Spartan3E Sample Pack: Real fun for all Ages!
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 4 Jan 2006 21:51:12 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag 
news:1136404826.510529.30510@z14g2000cwz.googlegroups.com...
> Xilinx does not discriminate against Europe.
> It was the other way around:
> I used a friend who flew home to Germany for Xmas, to hand-carry a kit,
> and mail it locally to Antti.
> So Antti got the first kit outside the US.
> We cannot do that for everybody in Europe. Maybe it was "the squeaky
> wheel gets the grease..."
> In the meantime, we are mailing Antti another board, since we don't
> want him to be a complaining repairman...
> Peter Alfke
>
Ouch - I did not want to complain so much actually, I was just eager to get 
some things tested, and when the power supply surge did burn everything, so 
I tried to repair as much as could - and I am now actually able to use the 
board again to some degree. Spartan3e was pretty much the only silicon 
device on my burnt board that retained some useability, everything else was 
totally dead - this should be taken as very good destructive test of the 
Spartan3e silicon. So I am not complaining about the need of repair, things 
happen - actually similar power supply has damaged here several other 
boards - so it was defenetly not the fault of the board or useage.

Anyway I had and still have fun with Spartan3e and even havent checked all 
the new features yet. And I hope that my bad-luck at the beginning of my 
Sample Pack testing actually brings something useful out of it at least I 
was forced todo lots of more testing then I would otherwise done.

As of US vs Europe, well at first the Distributors provided the "Free" 
special but later on it turned out that those are only valid in the north 
america and asia/pacific, this was kind of surprising, but OTOH maybe those 
specials at those disti sites were ahead of time, as well Xilinx website has 
still no Sample Pack info (or almost none). I just collected the public info 
and provided that, somewhat assuming there will be (some)EU supply also.

More to the Europa - it looks like nahitafu in Japan got his S3e sample pack 
a day or two before I did (or maybe even earlier)

Peter, I just (1 minute ago) received confirmation that first beta test 
person testing the Sample Pack standalone programming utility was actually 
able to use the tool and to reprogram the flash on his board - I keep 
working on and hope to get the tool soon available for public release.

Antti






Article: 94027
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 04 Jan 2006 13:14:47 -0800
Links: << >>  << T >>  << A >>
Parkov,

I would invest my time in learning a HDL:  VHDL or Verilog.

Schematic entry for logic design is (almost) completely dead.  It has 
become rare to find anyone doing anything in schematic form, except for 
the highest level where the pins are connected.

All of the levels of logic are described in hardware design language 
(HDL) modules.

To pick a vendor based on their 'schematic tool' is probably the least 
interesting criteria.

Picking the vendor based on:

-available technology
-speed
-power
-features
-cost
-size
-package
-ease of use of software tools
-available synthesis tools
-available simulators
-FAE support
-web support
-part availability

all makes sense.

Austin

Article: 94028
Subject: Re: Timing problem in ModelSim, Post-Route Simulation.
From: "Andy" <jonesandy@comcast.net>
Date: 4 Jan 2006 13:31:21 -0800
Links: << >>  << T >>  << A >>
Mike,

I'm pretty sure you understand this, but others may not:

The problem is not in having multicycle or false paths in a design; it
is in having constraints that relax timing requirements on those paths
that is the problem.  If the entire design p&r's and meets STA without
any of the above constraints, great, problem solved. But if it does
not, and you include the constraints, then there is a problem in that
the constraints may relax timing on paths that really are not
multicycle (or false), and then only a full timing sim will reveal it
(and then only if that particular path is exercised by the sim!).  In
fact even if you don't include constraints to pass static timing, but
just review the violations and rationalize them as false/multicycle
paths, you really have the same problem in verifying the
rationalizations.

There are some cases where including multicycle and false path
constraints prior to synthesis can resolve timing issues elsewhere in
the design, by not consuming critical resources where they are not
needed, thus reserving them for truely critical paths.  Whatever the
reason/result of including these constraints, they must be verfied just
like the RTL code, but the only way to do it (without a custom formal
analysis tool) is with full timing sim, excersizing the paths so
constrained.

Your point about detailed design loop vs release check-off is a good
one. I assumed we were talking about check-off, since I never run full
timing until then anyway.

Andy


Article: 94029
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 04 Jan 2006 13:49:25 -0800
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> I would invest my time in learning a HDL:  VHDL or Verilog.

Good advice, but allow several months.

> Schematic entry for logic design is (almost) completely dead.  It has 
> become rare to find anyone doing anything in schematic form, except for 
> the highest level where the pins are connected.

The one place it isn't dead is for
circuit-board oriented, first-time
cpld users copying some glue logic
off of an application note.

      -- Mike Treseler

Article: 94030
Subject: Re: Schematic Entry, Xilinx or Altera?
From: "Parkov" <skierpaul@yahoo.com>
Date: 4 Jan 2006 14:06:46 -0800
Links: << >>  << T >>  << A >>
>The one place it isn't dead is for
>circuit-board oriented, first-time
>cpld users copying some glue logic
>off of an application note.

Thats about where I'm at.  No worries, I'm checking out the two HDL
variants, just wanted to get a couple things rolling fast in the
meantime.  I'm coming from a 74xxx chip to chip background so I already
have some designs on paper.  Thanks for the heads up everyone on the
Quartus recomendation.


Article: 94031
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 4 Jan 2006 22:08:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Treseler <mike_treseler@comcast.net> wrote:
> Austin Lesea wrote:

> > I would invest my time in learning a HDL:  VHDL or Verilog.

> Good advice, but allow several months.

But schematic entry oftem leads to non-registered designs, where you should
allow several month of debugging too... 
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 94032
Subject: Re: Timing problem in ModelSim, Post-Route Simulation.
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 04 Jan 2006 14:12:52 -0800
Links: << >>  << T >>  << A >>
Andy wrote:

> The problem is not in having multicycle or false paths in a design; it
> is in having constraints that relax timing requirements on those paths
> that is the problem.

I agree with your posting.
My preference is to constrain only
Fmax and to meet STA by design only.
You are correct that this can consume some
resources, but it also saves time
and reduces stress.

     -- Mike Treseler


Article: 94033
Subject: CORDIC for digital downconversion
From: "bgaughan" <bgaughan@airnetcom.com>
Date: 4 Jan 2006 14:15:13 -0800
Links: << >>  << T >>  << A >>
I started with Ray Andraka's papers, "A Survey of CORDIC
algorithms...", and "High Performance DDC for FPGAs".  From the second
paper it seems that DDS approaches with phase resolution larger than 10
bits or so should be done with other methods, such as CORDIC.

Using the CORDIC should also give you the complex mix for free.  I'm
thinking that you would put your real input into x, set y to zero, and
then put in a phase accumulated value for your desired channel LO
value.  Then you can get out a "de-rotated" I and Q from the X and Y
outputs.  There's some quadrant mapping in there too.

I'm going to start hacking on one of the Xilinx System Generator CORDIC
blocks (SINCOS?) to get what I need.  In practice, how many iterations
or PEs do you need to get a significant SFDR such as 96dB?  With DDS
functions there's a formula ceil(SFDR/6) for the phase width. Is there
something similar for a CORDIC implementation?

For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required,
which is expensive.  I'm assuming the cores (Sysgen blocks) are using
quarter-wave tables?  The Taylor-series DDS drops down the RAM but
requires multipliers.

Thanks for any suggestions,
Brady


Article: 94034
Subject: Re: CORDIC for digital downconversion
From: "John_H" <johnhandwork@mail.com>
Date: Wed, 04 Jan 2006 23:01:00 GMT
Links: << >>  << T >>  << A >>
I was playing with a CORDIC implementation approach but with lower (12-bit) 
phase resolution with a very tiny footprint (no memory).  Is your 
demodulation from 50MS/s+ or 10MS/s- data?  I'd be interested to see if I 
could extend the performance to your needs.  Basically I'm pursuing 
bit-serial manipulation of I/Q data *and* phase to give lower error in the 
LSbits of the CORDIC stages.  I was considering a 16X clock relative to the 
I/Q data but saw that I might double the performance without doubling the 
footprint.

The errors from the multiple add/subtract stages need to be included in the 
SFDR to figure the number of bits of precision needed and should be your 
overriding "tweak."  Adding another 5 stages of fine phase resolution don't 
do you any good if the arithmetic errors are large.  I don't know of - but 
haven't looked for - a general fomula for the SFDR but one of Ray's papers 
discusses the arithmetic errors.

Care to share your requirements?

If you use 1 BlockRAM for 9 bits of phase in a 1/8th wave sine/cos lookup 
(for a total of 12 phase bits) you can have a second 9 bits of lookup 
(because you have 9 bits available at the BlockRAM address) for the sine/cos 
of the phase remainder in a second BlockRAM.  Standard sin(x+d) transform. 
The total number of multiples should be 6 and the total memory: 2 BlockRAMs. 
If you can spare *those* resources, the approach is a smaller footprint than 
a 1-stage DDS demodulator and provides exceptional dynamic range.


"bgaughan" <bgaughan@airnetcom.com> wrote in message 
news:1136412913.561951.194570@z14g2000cwz.googlegroups.com...
>I started with Ray Andraka's papers, "A Survey of CORDIC
> algorithms...", and "High Performance DDC for FPGAs".  From the second
> paper it seems that DDS approaches with phase resolution larger than 10
> bits or so should be done with other methods, such as CORDIC.
>
> Using the CORDIC should also give you the complex mix for free.  I'm
> thinking that you would put your real input into x, set y to zero, and
> then put in a phase accumulated value for your desired channel LO
> value.  Then you can get out a "de-rotated" I and Q from the X and Y
> outputs.  There's some quadrant mapping in there too.
>
> I'm going to start hacking on one of the Xilinx System Generator CORDIC
> blocks (SINCOS?) to get what I need.  In practice, how many iterations
> or PEs do you need to get a significant SFDR such as 96dB?  With DDS
> functions there's a formula ceil(SFDR/6) for the phase width. Is there
> something similar for a CORDIC implementation?
>
> For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required,
> which is expensive.  I'm assuming the cores (Sysgen blocks) are using
> quarter-wave tables?  The Taylor-series DDS drops down the RAM but
> requires multipliers.
>
> Thanks for any suggestions,
> Brady 



Article: 94035
Subject: Re: Schematic Entry, Xilinx or Altera?
From: "Subroto Datta" <sdatta@altera.com>
Date: 4 Jan 2006 15:30:41 -0800
Links: << >>  << T >>  << A >>
Parkov wrote:
> >The one place it isn't dead is for
> >circuit-board oriented, first-time
> >cpld users copying some glue logic
> >off of an application note.
>
> Thats about where I'm at.  No worries, I'm checking out the two HDL
> variants, just wanted to get a couple things rolling fast in the
> meantime.  I'm coming from a 74xxx chip to chip background so I already
> have some designs on paper.  Thanks for the heads up everyone on the
> Quartus recomendation.

And be sure to try out the 7400 series library that is provided with
Quartus too, to make your transition easier. Once you have your design
working use the Quartus builtin Verilog or VHDL synthesizer to expand
your knowledge of FPGA design.

Quartus allows mixed mode designs so that you can create design blocks
as a schematic or HDL.

Hope this helps,
Subroto Datta
Altera Corp.


Article: 94036
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 04 Jan 2006 15:33:22 -0800
Links: << >>  << T >>  << A >>
Uwe Bonnes wrote:

> But schematic entry oftem leads to non-registered designs, where you should
> allow several month of debugging too... 

I was playing the OP's advocate here,
because I started out where he is now.

Certainly HDL is the clean way to go.
But I also know that many hardware guys
will try it the "quick" way first.

      -- Mike Treseler

Article: 94037
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 05 Jan 2006 12:39:32 +1300
Links: << >>  << T >>  << A >>
Parkov wrote:
>>The one place it isn't dead is for
>>circuit-board oriented, first-time
>>cpld users copying some glue logic
>>off of an application note.
> 
> 
> Thats about where I'm at.  No worries, I'm checking out the two HDL
> variants, just wanted to get a couple things rolling fast in the
> meantime.  I'm coming from a 74xxx chip to chip background so I already
> have some designs on paper.  Thanks for the heads up everyone on the
> Quartus recomendation.

There is also a 'middle ground', between VHDL and Schematics :

Use a Boolean Eqn language, such as

Xilinx have ABEL  ( but for CPLD only, which here is OK ),
Altera have  AHDL ( I think still alive for CPLD ? )
Atmel have WinCUPL for CPLD, includes functional simulation, so can 
create test vectors, to allow 100% chip functional test at PGM time.
This flow works best on smaller PLDs that are pgmd off-board.

Lattice also have ABEL, not sure on their plans for ABEL-MachXO support 
? There is a large installed base of ABEL/Boolean EQN code for CPLDs,
so if they want to migrate those designs to MachXO, that would be
an important flow.

ICT have WinPLACE


If you start to need timing simulation, then you need to align to the 
simulation tools.

What complexity/package of CPLD do you expect to use ?

-jg


Article: 94038
Subject: Re: Schematic Entry, Xilinx or Altera?
From: "Parkov" <skierpaul@yahoo.com>
Date: 4 Jan 2006 16:01:11 -0800
Links: << >>  << T >>  << A >>
Hi Jim.

As far as I can forsee, all that I would need are either Altera
EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages.

If I went into a Boolean Equation Language, is ABEL or AHDL easier to
learn/use?  I can't seem to find any head to head comparisons.  Is
Xilinx going to continue support for ABEL for their CPLD's and is
Altera going to continue support for AHDL for theirs?  I know that
these are not practical languages for complex FPGA design, but that
doesn't need to be the issue.  Tks.


Article: 94039
Subject: Re: FPGA-pci communication
From: "Nitesh" <nitesh.guinde@gmail.com>
Date: 4 Jan 2006 16:08:02 -0800
Links: << >>  << T >>  << A >>
I have a psb core written in verilog which interfaces the dual pci
bridge( POWERSPAN II)  friom tundra with virtexII pro. This bridge is
an interface between the PSB bus on the fpga side and the pci bs on the
host side.
I want to configure the bridge to do dma transfer from the fpga to the
32 bit pci on the host. I went through the powerspan II data sheets and
have a rough idea of  the architecture .
Before that I have to configure the bridge . I needed some help on
configuring the bridge  using vhdl. Has anyone written a code to
configure the pci bridge  before?
Thanks,
Nitesh


Article: 94040
Subject: Re: [ANNOUNCE] MyHDL 0.5 released
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 05 Jan 2006 13:13:38 +1300
Links: << >>  << T >>  << A >>
Jan Decaluwe wrote:

> Hi all:
> 
> I'm pleased to announce the release of MyHDL 0.5.
> 
> MyHDL is an open-source package for using Python as a hardware
> description and verification language. Moreover, it can convert
> a design to Verilog. Thus, MyHDL provides a complete path
> from Python to an FPGA implementation.
> 
> MyHDL 0.5 has many new features, in particular with regard to
> conversion to Verilog. The converter automates certain tasks
> that are hard in Verilog directly. The Verilog output code
> works well with popular FPGA synthesis tools.
> 
> For a complete overview, go here:
>   http://myhdl.jandecaluwe.com/doku.php/overview
> 
> The manual is here:
>   http://www.jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html
> 
> To find out the details of what's new, go here:
>   http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5
> 
> You can download the release from SourceForge:
>   http://sourceforge.net/project/showfiles.php?group_id=91207
> 
> Best regards,
> 
> Jan Decaluwe

Looks impressive, and interesting.

  Do you have any Simulation benchmark indications, and any
simple, example 'complete' side-by-side projects ?
  By simple, I mean things like  16/24/32 bit Up/Dn/ReLoad counter,
perhaps a DDS as well, and since it seems to have good ROM/RAM support, 
a 7 segment display counter ?

-jg






Article: 94041
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 05 Jan 2006 13:52:24 +1300
Links: << >>  << T >>  << A >>
Parkov wrote:

> Hi Jim.
> 
> As far as I can forsee, all that I would need are either Altera
> EPM3032A/3064A's or Xilinx's XC9536/XC9576 both in 44pin packages.

Atmel's ATF1502 / 1504 would also be in that category.
( as would Lattice MACH4000 series )
Why not also the Coolrunner  ?

> 
> If I went into a Boolean Equation Language, is ABEL or AHDL easier to
> learn/use?  I can't seem to find any head to head comparisons.  Is
> Xilinx going to continue support for ABEL for their CPLD's and is
> Altera going to continue support for AHDL for theirs?  

Good questions, someone in Xilinx / Altera / Lattice could answer that ?

I do know from a 'tough' Xilinx.ABEL user, that Xilinx improved their 
ABEL flows, for CPLDs in recent releases - In their ABEL flow they now 
use (IIRC) VHDL as the 'back end' and ABEL as the front end.

This allows them to hook-into timing simulation tools, but does
loose ABEL's test vector generation ? (useful only on smaller packages)

One they have that, of course, then 'continued support' is inherent,
as the ABEL is only a front end.

That can't have been trivial to do, so I was impressed - but it does 
indicate how much CPLD code is out there, in ABEL/Boolean EQN.

In a similar vein, of using HDL's as 'back ends languages', see Jan 
Decaluwe's posting today of MyHDL : Python -> Verilog.

-jg



Article: 94042
Subject: Re: CORDIC for digital downconversion
From: Ray Andraka <ray@andraka.com>
Date: Wed, 04 Jan 2006 20:07:34 -0500
Links: << >>  << T >>  << A >>
bgaughan wrote:
> I started with Ray Andraka's papers, "A Survey of CORDIC
> algorithms...", and "High Performance DDC for FPGAs".  From the second
> paper it seems that DDS approaches with phase resolution larger than 10
> bits or so should be done with other methods, such as CORDIC.
> 
> Using the CORDIC should also give you the complex mix for free.  I'm
> thinking that you would put your real input into x, set y to zero, and
> then put in a phase accumulated value for your desired channel LO
> value.  Then you can get out a "de-rotated" I and Q from the X and Y
> outputs.  There's some quadrant mapping in there too.
> 
> I'm going to start hacking on one of the Xilinx System Generator CORDIC
> blocks (SINCOS?) to get what I need.  In practice, how many iterations
> or PEs do you need to get a significant SFDR such as 96dB?  With DDS
> functions there's a formula ceil(SFDR/6) for the phase width. Is there
> something similar for a CORDIC implementation?
> 
> For the 96dB phase-dithered DDS, I'm seeing 15 Block RAMs required,
> which is expensive.  I'm assuming the cores (Sysgen blocks) are using
> quarter-wave tables?  The Taylor-series DDS drops down the RAM but
> requires multipliers.
> 
> Thanks for any suggestions,
> Brady
> 

Brady,

The larger BRAMs in recent devices have pushed the phase resolution 
achievable using BRAMs up a little.  12-14 bits is possible.

The CORDIC rotator phase resolution improves by one bit per iteration. 
For 96 dB, you'll need iterations 0-16 (working from the top of my head 
here).  It is basically the same formula ciel(sfdr/g) but using the 
combination of the phase error of CORDIC and the phase resolution of 
your phase input.

The quadrant mapping can be done with either of the reduction rotations 
I mentioned in the CORDIC survey paper.  I'm not sure the Xilinx CORDIC 
core does that or not (I have my own).

Article: 94043
Subject: Re: CORDIC for digital downconversion
From: Ray Andraka <ray@andraka.com>
Date: Wed, 04 Jan 2006 20:21:50 -0500
Links: << >>  << T >>  << A >>
John_H wrote:

> I was playing with a CORDIC implementation approach but with lower (12-bit) 
> phase resolution with a very tiny footprint (no memory).  Is your 
> demodulation from 50MS/s+ or 10MS/s- data?  I'd be interested to see if I 
> could extend the performance to your needs.  Basically I'm pursuing 
> bit-serial manipulation of I/Q data *and* phase to give lower error in the 
> LSbits of the CORDIC stages.  I was considering a 16X clock relative to the 
> I/Q data but saw that I might double the performance without doubling the 
> footprint.
> 
> The errors from the multiple add/subtract stages need to be included in the 
> SFDR to figure the number of bits of precision needed and should be your 
> overriding "tweak."  Adding another 5 stages of fine phase resolution don't 
> do you any good if the arithmetic errors are large.  I don't know of - but 
> haven't looked for - a general fomula for the SFDR but one of Ray's papers 
> discusses the arithmetic errors.
> 
> Care to share your requirements?
> 
> If you use 1 BlockRAM for 9 bits of phase in a 1/8th wave sine/cos lookup 
> (for a total of 12 phase bits) you can have a second 9 bits of lookup 
> (because you have 9 bits available at the BlockRAM address) for the sine/cos 
> of the phase remainder in a second BlockRAM.  Standard sin(x+d) transform. 
> The total number of multiples should be 6 and the total memory: 2 BlockRAMs. 
> If you can spare *those* resources, the approach is a smaller footprint than 
> a 1-stage DDS demodulator and provides exceptional dynamic range.
> 

You do have to make sure you carry enough extra LSBs in the CORDIC 
rotator to keep the rounding or truncation errors from accumulating into 
your output lsb.  It turns out it is fairly easy to round at each stage 
in the CORDIC only adding one extra bit to the bottom of each adder. 
This works because one input to each adder is shifted, while the other 
is not.  You are only rounding off the lsbs of the shifted input, so 
adding a '1' below the lsb of the unshifted input reduces the bias.  As 
long as you keep the accumulated I and Q path rounding errors below the 
lsb error at the output, those won't contribute significantly to the 
sfdr.  The accumulated error is bounded by roughly log2(iterations) bits 
(I've got it in a spreadsheet somewhere)... that means adding 
log2(iterations) extra lsbs under the output lsb.

For the look-up table approach, you can use a dual port block RAM with a 
sine table in it.  You access one port with the sine address, and the 
other port with the cosine address, which is modified from the sine 
address.  For a full cycle table, the address modification is just 
adding 1 to the top two bits. For a quarter cycle table it is a little 
more complicated.  By using both ports to access different points in the 
same table you cut the real estate needed for your sine/cos tables in half.

In virtex4, the CORDIC is at a significant performance disadvantage 
because the fabric carry chains are quite slow compared to the speed of 
the DSP48 slices and memory.  The DSP48's are really not set up for 
attempting to do CORDIC using them, and if you did, you'd give up all 
those multipliers.



Article: 94044
Subject: How can i get the hex file
From: "bjzhangwn" <bjzhangwn@126.com>
Date: 4 Jan 2006 17:30:50 -0800
Links: << >>  << T >>  << A >>
Now I read a risc8 and  a minimips cpu core ,and I want to know how can
I get the hex file for simulation.I don't have the associate c compiler
and assembly tools.


Article: 94045
Subject: Re: Using posedge and negedge causing me grief
From: mk <kal*@dspia.*comdelete>
Date: Thu, 05 Jan 2006 01:40:11 GMT
Links: << >>  << T >>  << A >>
On Wed, 04 Jan 2006 12:18:48 -0800, Mike Oxlarge
<oxlargeMike@yahoo.com> wrote:

> However, I'm now trying to implement what mk suggested:

To be frank I am not sure what your code is trying to do but let me
start it here and you can fix it the way you want:

   always @ (posedge clk) begin
          if (reset) begin
                 curval <= 5;
	   acnt <= 2'h0;	// nice clean value
          end
          else begin
                 case (acnt)
                   0: cnt <= curval;
                   1: cnt <= ov1;
                   2: cnt <= 2;
                   3: cnt <= 3;
                 endcase

                 if (!enable)
                   acnt <= acnt + 1;

	   if (enable) begin
             	        ov1 <= curval;
                     curval <= curval + 1;
                end
          end
   end

As there is no specific reason I can see for you to have the negedge,
put all your code into the posedge. If the behavior is not what you
want, change it till you get it right. One thing you can do is to put
all the code between the first else to the end of code in a
combinational always block so that not all variables are registered or
you don't have to wait for unnecessary cycles to get curval+1 etc.

HTH.

Article: 94046
Subject: ISE Timing
From: "Rob" <robnstef@frontiernet.net>
Date: Thu, 05 Jan 2006 02:15:39 GMT
Links: << >>  << T >>  << A >>
Hello.

How can I see what the the clock skew is between a set of register?  The 
clock is an output of a DCM.  Also, how can I force the PAR to maintain a 
certain timing spec?

Thanks,
Rob 



Article: 94047
Subject: Virtex 2 configuration problem
From: "gja" <gja@hotmail.com>
Date: Wed, 4 Jan 2006 21:23:14 -0500
Links: << >>  << T >>  << A >>
I'm looking for some suggestions as to what else to look at to fix this 
problem:

Using a Virtex II xc2v40 and xcf02s prom connected in master serial mode. 
JTAG is also implemented.  We've built around 50 of these boards without 
this problem so I believe it's just this particular board.  It 
intermittently doesn't configure on power up.

A power chip holds INIT_B low until 3.3v is 3v to delay configuration, not 
really needed since power ramps up in around 5ms.  When it fails, I see on a 
scope that INIT_B never goes high after power is up and PROG is high. PROG 
is pulled up to 3.3v thru 4.75k. When it works, INIT_B goes high within 5ms 
of PROG going high.

As a test, I connected PROG to GND with a wire and then powered up the 
board. After say 5 secs, I disconnected GND, and sometimes  INIT_B would go 
high as expected, But sometimes it would remain low. If it went high, I 
could pulse PROG low and INIT_B would work as expected everytime.

When the fpga is in its nonworking state, it doesn't respond on the JTAG 
port either.

I lifted the prom pin and the power chip connected to INIT_B to verify that 
when it fails, it's the fpga that is holding INIT_B low and not the other 
chips.

Any ideas on what else to look at? 



Article: 94048
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 05 Jan 2006 15:55:13 +1300
Links: << >>  << T >>  << A >>
Jim Granville wrote:
>> If I went into a Boolean Equation Language, is ABEL or AHDL easier to
>> learn/use?  I can't seem to find any head to head comparisons.  Is
>> Xilinx going to continue support for ABEL for their CPLD's and is
>> Altera going to continue support for AHDL for theirs?  
> 
> 
> Good questions, someone in Xilinx / Altera / Lattice could answer that ?

Further to this, I went to the Lattice web site
http://www.latticesemi.com/products/designsoftware/isplever/ispleverstarter.cfm

It says
"ispLEVER-Starter Primary Module (212 MB)
This module is required to run the ispLEVER Starter software, and should 
be installed first. It includes the ispLEVER Project Navigator, and all 
the tools and device libraries you need to implement a design in 
Lattice's newest and most popular CPLD products. Note: This module 
supports ABEL, EDIF and Schematic design projects only. For Verilog or 
VHDL design project support, you must download one of the Synthesis 
modules listed below."
...

Device Support

FPGA:
LatticeECP: ECP6
LatticeEC: All
LatticeXP: XP3, XP6

CPLD:
MachXO: All
ispMACH 4000
ispXPLD 5000MX

  So, since MachXO is clearly in the "newest and most popular CPLD 
products" category, this web page is saying ABEL support
for MachXO is there.

  Call me cynical, but I'd believe that more if a Lattice FAE was able 
to verify that ?

-jg


Article: 94049
Subject: Re: Schematic Entry, Xilinx or Altera?
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Jan 2006 00:08:07 -0500
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> Austin Lesea wrote:
> 
>> I would invest my time in learning a HDL:  VHDL or Verilog.
> 
> 
> Good advice, but allow several months.
> 
  And frequent use.  It isn't worth learning either one for a one-time 
deal.  If he only does a CPLD once in a blue moon and doesn't use the 
HDL for anything else, he'll forget more than he remembers and will have 
to learn it all over again next time.



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