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 137425

Article: 137425
Subject: Re: Creating a core from my VHDL code
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 15 Jan 2009 21:09:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
axr0284 <axr0284@yahoo.com> wrote:

> I wrote some code in VHDL and I would like to create a core targeting
> Xilinx Spartan-3E devices. I am clueless of how to proceed with that.
> 1) I can synthesize the code using XST with an XCF timing constraint
> file which will create an NGC file. Is that considered a CORE?

What I consider a core is a module (that is the verilog term, I
forget what VHDL calls it) that can be instantiated in a larger
design.  Similar to a library subroutine in software.

In most cases, additional logic will go between that and 
the actual pins.

> 2) Will the NGC file contain the timing information from the XCF
> timing constraint file?

It seems that they now use UCF.  As far as I know, any timing
related constraints will occur when the core is used.

> 3) Is there a way to actually area constrain it during synthesis?

That gets farther into floorplanning than I usually go.

-- glen

Article: 137426
Subject: Re: Webpack 10.1 on Windows XP
From: "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com>
Date: Thu, 15 Jan 2009 13:11:56 -0800
Links: << >>  << T >>  << A >>




"james" <george@washington.edu> wrote in message 
news:f81vm49djff50gd2s2mvfa07jdejkklg0h@4ax.com...
>I have Windows XP with SP3. Can I install Webpack on this OS? The
> Webpage states that i would need XP Pro. I care not to upgrade at this
> point but this is getting rediculus with Xilinx. They offer products
> but very limited scope of OS's. Right now I have 9.2 SP4.
>
>
> james

I submitted a case to Xilinx support asking the same question. Here's their 
response:
---

To answer you question about ISE WebPack running on XP home, is it should 
work, but it's unsupported on XP Home. The Requirement is Microsoft Windows 
XP Professional (32-bit only).

---

Bob

-- 
== All google group posts are automatically deleted due to spam ==



Article: 137427
Subject: Re: Counter: natural VS std_logic_vector
From: aleksa <aleksaZR@gmail.com>
Date: Thu, 15 Jan 2009 14:31:04 -0800 (PST)
Links: << >>  << T >>  << A >>
And here is my last attempt:

First, I was wrong thinking that
8259 requires a "minimum LOW period"
even in level sensitive mode (as it
does in edge mode) so I've removed
IRQCOUNTER and lfIRQANY.

Also, I am using plenty of async
resets in my project, and it works
w/o any problems, so thats what I
used here, also.


Result? The SAME as in my previous post..


I'm starting to think that the problem
is somewhere else, but don't know where..
(of course, the 8259 is broken! ;)

(only channel A shown)

TIMER : process (CLKMAIN)
begin
    if falling_edge(CLKMAIN) then
        if counterA=0 then
            cIRQA <= '0';
            counterA <= reloadA;
        else
            cIRQA <= '1';
            counterA <= counterA -1;
        end if;
    end if;
end process TIMER;


IRQFLAGS : process (CLKMAIN, RD, ADDR)
begin
    if RD='0' and ADDR=ADRA then
        fIRQA <= '0';
    elsif rising_edge(CLKMAIN) and cIRQA='0' then
        fIRQA <= '1';
    end if;
end process IRQFLAGS;


IRQPROC : process (CLKMAIN) begin
    if falling_edge(CLKMAIN) then
        fIRQANY <= fIRQA or fIRQB or fIRQC;
    end if;

    if rising_edge(CLKMAIN) then
        if fIRQANY='1' then
            irqA <= '1';
        else
            irqA <= '0';
        end if;
    end if;
end process IRQPROC;

Anyone see a reason why this should not work?

Article: 137428
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx Coolrunner-II CPLD?
From: "robj" <robj@abc.net>
Date: Thu, 15 Jan 2009 21:15:09 -0800
Links: << >>  << T >>  << A >>
<ikogan@alumni.technion.ac.il> wrote in message 
news:1188838781.893882.166580@r29g2000hsg.googlegroups.com...
>I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA
> from Actel with IGLOO power calculator (posted on Actel website). I
> received very astonishing results. With full logic utilization at 50
> MHz, 25% toggle rate and around 100 I/Os (LVCMOS 1.8V, LVCMOS 3.3V) it
> consumes around 100 mW. It's about half of Xilinx Coolrunner-II
> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex)
> for same functionality. I was very surprised by this so maybe I'm
> missing something here. Is anybody familiar with this chip and its
> power consumption?
>

I'm using IGLOO now for exactly the reasons you state. The main difference 
vs. SRAM-based FPGAs is the insanely low static current (measured in uW even 
in the largest device in the family). The dynamic current is on the order of 
30-40% vs. those guys from what I've seen. As a test I compiled a real 
design into a Xilinx XC2V250 and an AGL600V2. These devices are roughly 
comparable in size. I then and used the vendor tools to estimate power on 
the placed and routed designs. Here's what I got:

XC2V250-4CS144:

Max clock frequency: 119MHz
Flip flops: 757/3072 (24%)
4-input LUTs: 817/3072 (26%)
Block RAMs: 5/24
Estimated power: 253mW* (using Xilinx's XPower tool)
  Static: 32mW
  Dynamic: 221mW

* Calculated at 80MHz with 12.5% data toggle rate.


AGL600V2-FG144:

Max clock frequency: 33.3MHz
Flip flops: 870
Total VersaTiles: 4974/13824 (36%)
Block RAMs: 5/24
Estimated power: 66mW** (using Actel's SmartPower tool)
  Static: 0.067mW (67uW)
  Dynamic: 66mW

** Calculated at 80MHz with 12.5% data toggle rate (even though design won't 
run that fast).

The IGLOO power is ~25% of the Xilinx power at the same frequency, and the 
IGLOO static power is only 67 uW (~1/500th of the Xilinx). Truly amazing. 
You pay the price for that low power, though, as the design runs 3.5x as 
fast in the Xilinx. But for some designs, like the one I'm working on now, 
low power is paramount.

As for the Coolrunner-II, the Coolrunner is a 1.8V part vs. 1.2V for the 
IGLOO V2. That's a 50% power difference right off the bat. The rest must 
just be differences in the design and process.

Rob 



Article: 137429
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx Coolrunner-II CPLD?
From: "robj" <robj@abc.net>
Date: Thu, 15 Jan 2009 21:21:42 -0800
Links: << >>  << T >>  << A >>
"Douglas" <j.d.morrison@gmail.com> wrote in message 
news:1189491208.142555.102930@50g2000hsm.googlegroups.com...
> On Sep 3, 7:59 pm, iko...@alumni.technion.ac.il wrote:
>> It's about half of Xilinx Coolrunner-II
>> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex)
>> for same functionality.
>
> Which Xilinx parts you used as a comparison point? I don't have
> expertise on Actel parts, but they seem to have 'quite' optimistic
> marketing gates readings, so comparing 250k part to 250k part might
> not be fair.
>
> On a related topic - does anyone have expertise about the trade-offs
> of Actel's "Versa-Tiles" vs. 4/6-LUTs. It seems like obviously
> wastefull configuration - how many thansistors they can really share
> between 3-LUT and D-FF? Is there some benefit in this configuration,
> or is this 'design choice' made just to avoid Altera and Xilinx
> patents?
>
> - Doug
>

I don't see it as wasteful. It's just a more granular and generic 
architecture, which has some advantages. I would guess that lowering power 
was also a big part of the equation. No idea about patent concerns.

Rob 



Article: 137430
Subject: Re: Duty Cycle change effects on Internal reg's
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 15 Jan 2009 22:03:59 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote:
> On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > In a conventional design (single clock, distributed over global clock
> > nets, all flip-flops triggered on the same, usually rising, clock
> > edge, clock frequency not at the max data-sheet limit)dutycycleis irrel=
evant, as long as you do not violate any clock-High
> > or clock-Low timing.
> > More exotic designs that use both clock edges or use latches instead
> > of flip-flops, are (or might be) sensitive to clockdutycycle.
> > Distributing clocks on non-global lines can seriously affectdutycycle, =
and also cause uncontrolled clock skew and other bad problems.
> > Don't do that!
> > Peter Alfke
>
> Hi peter,
> thanks for your response, i am still not configuring my doubt on this
> (duty Cycle).
> Here is my clear query: I have requirement saying that "The test case
> is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40%
> and 60% duty cycles", and before that i had a test case for same
> signals on 50% duty cycle. so when i did test on 50% duty cycle i got
> normal results without any problems, and i am not able to figure out
> if i change to 40% and 60% duty cycles than what to expect on output
> line.
>
> As of my knowledge within duty cycle boundary limit the output doesn't
> affect, but out of boundary change in duty cycle is the only
> expectancy.
> If possible could you please give me any example in explaining this
> concept.
>
> Thanks

50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low.
If you use global clock distribution, there will be no difference
whatsoever in the register outputs if you vary the 10 ns to 8 or 12
ns.
Try to understand the operation of clocked D-flip-flops, and you will
agree.
Peter Alfke

Article: 137431
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx Coolrunner-II
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Fri, 16 Jan 2009 08:40:56 +0100
Links: << >>  << T >>  << A >>
robj schrieb:
> <ikogan@alumni.technion.ac.il> wrote in message 
> news:1188838781.893882.166580@r29g2000hsg.googlegroups.com...
>> I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA
>> from Actel with IGLOO power calculator (posted on Actel website). I
>> received very astonishing results. With full logic utilization at 50
>> MHz, 25% toggle rate and around 100 I/Os (LVCMOS 1.8V, LVCMOS 3.3V) it
>> consumes around 100 mW. It's about half of Xilinx Coolrunner-II
>> consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex)
>> for same functionality. I was very surprised by this so maybe I'm
>> missing something here. Is anybody familiar with this chip and its
>> power consumption?

> As for the Coolrunner-II, the Coolrunner is a 1.8V part vs. 1.2V for the 
> IGLOO V2. That's a 50% power difference right off the bat. The rest must 
> just be differences in the design and process.

The voltage counts quadratic for the power consumption. So a difference
from 1.8V to 1.2V results in a power reduction by a factor of 2.25 and
not 1.5!

Matthias

Article: 137432
Subject: Re: Digilent Nexys 2 Issue
From: dave@axoninstruments.biz
Date: Fri, 16 Jan 2009 01:00:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 15, 9:45=A0am, reganirel...@gmail.com wrote:
> Same with me.
>
> A staff member from Digilent emailed me with that same link, good as
> gold now.
>
> Regan

I guess they had shipped the boards before the software was ready to
go on the website.

Have fun. No I can start to have a real go at learning VHDL!

Dave...

Article: 137433
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx Coolrunner-II CPLD?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 16 Jan 2009 10:50:36 -0000
Links: << >>  << T >>  << A >>
> I'm using IGLOO now for exactly the reasons you state. The main difference vs. SRAM-based FPGAs is 
> the insanely low static current.....

...and performance.


> XC2V250-4CS144:
> Max clock frequency: 119MHz

> AGL600V2-FG144:
> Max clock frequency: 33.3MHz


I got bitten recently trying to convert a design from a Cyclone I to
an Actel ProAsic3.

It was runing at 66MHz in the Cyclone I with reasonably tight IO
requirements, this took a wee bit of tweaking in Quartus but I
got it to build cleanly fairly quickly. I've no doubt I could have
translated the design to a Spartan-3 fairly quickly/easily.

After a great deal of work and some assistance from an Actel rep
I still wasn't able to get the design working in the ProAsic3,
I had naievly presumed the performance would be roughly similar
to the Altera/Xilinx parts. My get out was that my client had
chosen the part.

They're great for what they do well but just be wary if you need
to push the performance (at all).


Nial.



Article: 137434
Subject: Re: Counter: natural VS std_logic_vector
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Fri, 16 Jan 2009 10:59:56 -0000
Links: << >>  << T >>  << A >>
> IRQFLAGS : process (CLKMAIN, RD, ADDR)
> begin
>    if RD='0' and ADDR=ADRA then
>        fIRQA <= '0';
>    elsif rising_edge(CLKMAIN) and cIRQA='0' then
>        fIRQA <= '1';
>    end if;
> end process IRQFLAGS;
>

As I said before...

You probably don't want to do this, use your master 20MHz
clock to synchronise all your external signals and use
the re-timed signals to drive the internal logic.

Do a bit of googling on synchronous FPGA design and how to handle
asynchronous inputs.

_DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_


Nial. 



Article: 137435
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 16 Jan 2009 03:07:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 12:50=A0pm, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I'm using IGLOO now for exactly the reasons you state. The main differe=
nce vs. SRAM-based FPGAs is
> > the insanely low static current.....
>
> ...and performance.
>
> > XC2V250-4CS144:
> > Max clock frequency: 119MHz
> > AGL600V2-FG144:
> > Max clock frequency: 33.3MHz
>
> I got bitten recently trying to convert a design from a Cyclone I to
> an Actel ProAsic3.
>
> It was runing at 66MHz in the Cyclone I with reasonably tight IO
> requirements, this took a wee bit of tweaking in Quartus but I
> got it to build cleanly fairly quickly. I've no doubt I could have
> translated the design to a Spartan-3 fairly quickly/easily.
>
> After a great deal of work and some assistance from an Actel rep
> I still wasn't able to get the design working in the ProAsic3,
> I had naievly presumed the performance would be roughly similar
> to the Altera/Xilinx parts. My get out was that my client had
> chosen the part.
>
> They're great for what they do well but just be wary if you need
> to push the performance (at all).
>
> Nial.

Hi Nial,

i could have saved you the trouble, i guess.
after having an almost year long struggle while converting from Xilinx
to A3P060
with a project with NO timing issues at all, well if you had timing
tweaking
requirements with Cyclone, my thumb advice would have been, DO NOT
DARE
to try the same with A3P

well, but they are OK, for what they work, nothing agains them, just
you need to know where to use them, and where not.

world first FPGA-Stamps are made of A3P060-CN132 :)

Antti





Article: 137436
Subject: Re: Counter: natural VS std_logic_vector
From: aleksa <aleksaZR@gmail.com>
Date: Fri, 16 Jan 2009 03:53:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 11:59=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > IRQFLAGS : process (CLKMAIN, RD, ADDR)
> > begin
> > =A0 =A0if RD=3D'0' and ADDR=3DADRA then
> > =A0 =A0 =A0 =A0fIRQA <=3D '0';
> > =A0 =A0elsif rising_edge(CLKMAIN) and cIRQA=3D'0' then
> > =A0 =A0 =A0 =A0fIRQA <=3D '1';
> > =A0 =A0end if;
> > end process IRQFLAGS;
>
> As I said before...
>
> You probably don't want to do this, use your master 20MHz
> clock to synchronise all your external signals and use
> the re-timed signals to drive the internal logic.
>
> Do a bit of googling on synchronous FPGA design and how to handle
> asynchronous inputs.

Ok, will do. But, read below.

>
> _DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_
>
> Nial.

Problem solved.

Nial Stewart pointed out some 2 days ago:

"if you need a count of X then load the
counter with X-1 if you're counting to 0"

Since my "clock to sink-in" time is about 48 hrs,
I did as I was told and it now works..

Thanks, everyone


Article: 137437
Subject: Re: Counter: natural VS std_logic_vector
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 16 Jan 2009 07:34:37 -0500
Links: << >>  << T >>  << A >>

"aleksa" <aleksaZR@gmail.com> wrote in message 
news:68552330-6502-40da-9d6a-31e17040bb0c@v4g2000yqa.googlegroups.com...
> And here is my last attempt:
>
Giving up already?

>
> TIMER : process (CLKMAIN)
> begin
>    if falling_edge(CLKMAIN) then

There is no reason to be using falling edge here.  Synchronous design 
practice uses rising edge.  Other than that there are no obvious problems 
with the timer process.
>
>
> IRQFLAGS : process (CLKMAIN, RD, ADDR)
> begin
>    if RD='0' and ADDR=ADRA then
>        fIRQA <= '0';
>    elsif rising_edge(CLKMAIN) and cIRQA='0' then

And here is your problem.  You're using RD and ADDR asynchronously.  Now ask 
yourself what happens if the condition "RD='0' and ADDR=ADRA " goes *away* 
just prior to the rising edge of CLKMAIN?  The result will be a timing 
problem on signal fIRQA which means that this process can end up setting 
fIRQA to 1.  The other problem is that the async reset of fIRQA can screw up 
the timing to anything that *uses* fIRQA.  The solution as has been pointed 
out already is to:
1. synchronize RD and ADDR before using.
2. Don't use "RD='0' and ADDR=ADRA " to asynchronously reset fIRQA.  In 
fact, don't use asynchronous resets at all...ever (almost ever).
3. Perform static timing analysis

>
> IRQPROC : process (CLKMAIN) begin
>    if falling_edge(CLKMAIN) then
>        fIRQANY <= fIRQA or fIRQB or fIRQC;

Again, synchronous design practice has no use for falling edge triggered 
logic, use the rising edge instead.  Other than that, there doesn't seem to 
be any problems with the irqproc process...however the inputs to the process 
have not been synchronized to the clock because fIRQA is not synchronous due 
to your use of the async reset in the previous process.

> Anyone see a reason why this should not work?

Yes

Kevin Jennings 



Article: 137438
Subject: Re: Webpack 10.1 on Windows XP
From: SUMAN <sumansrb@gmail.com>
Date: Fri, 16 Jan 2009 05:37:43 -0800 (PST)
Links: << >>  << T >>  << A >>
Yes. I'm using webpak 10.1 and edk 10.1 on winxp sp3. They are working
well without any problems.

Article: 137439
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx
From: Petrov_101@hotmail.com
Date: Fri, 16 Jan 2009 06:36:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 5:50=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > I'm using IGLOO now for exactly the reasons you state. The main differe=
nce vs. SRAM-based FPGAs is
> > the insanely low static current.....
>
> ...and performance.
>
> > XC2V250-4CS144:
> > Max clock frequency: 119MHz
> > AGL600V2-FG144:
> > Max clock frequency: 33.3MHz
>
> I got bitten recently trying to convert a design from a Cyclone I to
> an Actel ProAsic3.
>
> It was runing at 66MHz in the Cyclone I with reasonably tight IO
> requirements, this took a wee bit of tweaking in Quartus but I
> got it to build cleanly fairly quickly. I've no doubt I could have
> translated the design to a Spartan-3 fairly quickly/easily.
>
> After a great deal of work and some assistance from an Actel rep
> I still wasn't able to get the design working in the ProAsic3,
> I had naievly presumed the performance would be roughly similar
> to the Altera/Xilinx parts. My get out was that my client had
> chosen the part.
>
> They're great for what they do well but just be wary if you need
> to push the performance (at all).
>
> Nial.

Igloo is slow, that's true, but ProAsic3 should be able to handle 66
Mhz.  My current ProAsic3 is running at 160 Mhz, using vanilla vhdl.
No special constraints or manually placed logic blocks were needed
other than specifying clock speed.


Article: 137440
Subject: Re: Actel IGLOO FPGA has lower power consumption then Xilinx Coolrunner-II CPLD?
From: "robj" <robj@abc.net>
Date: Fri, 16 Jan 2009 07:18:34 -0800
Links: << >>  << T >>  << A >>
"Matthias Alles" <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de> wrote in message 
news:gkpdq5$f02$1@news.uni-kl.de...
>
> The voltage counts quadratic for the power consumption. So a difference
> from 1.8V to 1.2V results in a power reduction by a factor of 2.25 and
> not 1.5!
>
> Matthias

Good point! 



Article: 137441
Subject: Re: Death of the RLOC?
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Fri, 16 Jan 2009 17:35:17 +0100
Links: << >>  << T >>  << A >>

"Andreas Ehliar":
> Is anyone aware of a newer comparison than this one?

Not me.

But what I know is, that manual floorplanning can also affect
the type of logic inferred, not only the routing. So you'll
need to be more specific about if your question relates to 
eaxcat, similar or diffrent types of inferred logic.

Since your post is mainly focussing on routing, I'd expect
you're interested in exact or similar logic types. As a
lesser experienced FPGA user, I'd expect a manually 
floorplanned version to perform at most noticaeble better
than an automatically generated version (please someone 
correct me).

On the other hand, the type of logic resources used makes up 
a heavy difference, no matter if you're mainly focussed on area
or speed. So maybe better don't even mind the theoretical
option to manually take care about where exactly any of the
individual signals might go (in addition to care about some 
few important signals), and just remember that each device 
family always comes with a huge set of undocumented details
about routing options (and even if you just focus on documented 
details, you'll notice that absoulte placement heavily affects
local routing within real devices; just try to get an impression
of how long shortest paths between to given points look like...).
That's not what people normally mean when saying "RLOC".

Gruss

Jan Bruns


Article: 137442
Subject: Re: Death of the RLOC?
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 16 Jan 2009 18:07:58 GMT
Links: << >>  << T >>  << A >>
"Jan Bruns" <testzugang_janbruns@arcor.de> wrote:

>
>"Andreas Ehliar":
>> Is anyone aware of a newer comparison than this one?
>
>Not me.
>
>But what I know is, that manual floorplanning can also affect
>the type of logic inferred, not only the routing. So you'll
>need to be more specific about if your question relates to 
>eaxcat, similar or diffrent types of inferred logic.
>
>Since your post is mainly focussing on routing, I'd expect
>you're interested in exact or similar logic types. As a
>lesser experienced FPGA user, I'd expect a manually 
>floorplanned version to perform at most noticaeble better
>than an automatically generated version (please someone 
>correct me).

I think this is true if you hand-route an entire design that has to be
fast. That would take an enormous amount of time...

I like to think at it like mixing C and assembly. C compilers are very
good these days and generally will produce code you can't get to run
faster using assembly. Assembly however may give you access to special
DSP style instructions which are not supported by the C compilers.
Even though you may have expert assembly skill, the resulting program
may be slower because the C compiler can't fully optimize because of
your code.

I've experienced this with FPGA designs as well. I've used Xilinx's
Picoblaze several times. This is a piece of logic which has quite a
bit of RLOCs however, disabling the RLOCs usually results in designs
that meet there timing specifications. Why? The placer can break the
picoblaze into pieces and optimize it together with the rest of the
logic.

Moral: Optimizers are very powerful tools and have a large window to
look at your design. Its better to try and figure out how to get the
optimizer to work better than to try to outsmart the optimizer.


-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 137443
Subject: Re: Duty Cycle change effects on Internal reg's
From: Gabor <gabor@alacron.com>
Date: Fri, 16 Jan 2009 11:47:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 1:03=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
> On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote:
>
>
>
> > On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > In a conventional design (single clock, distributed over global clock
> > > nets, all flip-flops triggered on the same, usually rising, clock
> > > edge, clock frequency not at the max data-sheet limit)dutycycleis irr=
elevant, as long as you do not violate any clock-High
> > > or clock-Low timing.
> > > More exotic designs that use both clock edges or use latches instead
> > > of flip-flops, are (or might be) sensitive to clockdutycycle.
> > > Distributing clocks on non-global lines can seriously affectdutycycle=
, and also cause uncontrolled clock skew and other bad problems.
> > > Don't do that!
> > > Peter Alfke
>
> > Hi peter,
> > thanks for your response, i am still not configuring my doubt on this
> > (duty Cycle).
> > Here is my clear query: I have requirement saying that "The test case
> > is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40%
> > and 60% duty cycles", and before that i had a test case for same
> > signals on 50% duty cycle. so when i did test on 50% duty cycle i got
> > normal results without any problems, and i am not able to figure out
> > if i change to 40% and 60% duty cycles than what to expect on output
> > line.
>
> > As of my knowledge within duty cycle boundary limit the output doesn't
> > affect, but out of boundary change in duty cycle is the only
> > expectancy.
> > If possible could you please give me any example in explaining this
> > concept.
>
> > Thanks
>
> 50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low.
> If you use global clock distribution, there will be no difference
> whatsoever in the register outputs if you vary the 10 ns to 8 or 12
> ns.
> Try to understand the operation of clocked D-flip-flops, and you will
> agree.
> Peter Alfke

O.K., but it was you and not the OP who inferred that
all flip-flops are using the same clock edge.  Clearly there
would be effect on the period where signals are used on opposite
edges of the clock.

Article: 137444
Subject: Re: Death of the RLOC?
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Fri, 16 Jan 2009 20:59:14 +0100
Links: << >>  << T >>  << A >>

"Nico Coesel":

> Moral: Optimizers are very powerful tools and have a large window to
> look at your design. Its better to try and figure out how to get the
> optimizer to work better than to try to outsmart the optimizer.

On the other hand, tools have no intelligence. They're normally
even to stupid to let the user decide about design gloals that
otherwise need to be "guessed".

For example, "area vs. speed" is still a global switch in ise-xst,
wheres you'd naturally assign diffrent goals to parts of a module.
If there's viable way to tell a tool about what you want, don't
expect it to do what you want.

This leads me to the point I disagree: It's not always wise to 
minimize only "software" development effort, since this often means
much more of work on a other areas. For example, if you decide to 
not do some "free" 50% area-saving manual optimization for a specific
FPGA-product, you might save some weeks of development by
"just buying a better device", but the marketing people might
then have to shout much louder, making it difficult for you to 
focus on the next thing to do.

Gruss

Jan Bruns







Article: 137445
Subject: Re: Counter: natural VS std_logic_vector
From: aleksa <aleksaZR@gmail.com>
Date: Fri, 16 Jan 2009 16:37:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 1:34=A0pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "aleksa" <aleks...@gmail.com> wrote in message
>
> news:68552330-6502-40da-9d6a-31e17040bb0c@v4g2000yqa.googlegroups.com...>=
 And here is my last attempt:
>
> Giving up already?
>
>
>
> > TIMER : process (CLKMAIN)
> > begin
> > =A0 =A0if falling_edge(CLKMAIN) then
>
> There is no reason to be using falling edge here. =A0Synchronous design
> practice uses rising edge. =A0Other than that there are no obvious proble=
ms
> with the timer process.
>
>
>
> > IRQFLAGS : process (CLKMAIN, RD, ADDR)
> > begin
> > =A0 =A0if RD=3D'0' and ADDR=3DADRA then
> > =A0 =A0 =A0 =A0fIRQA <=3D '0';
> > =A0 =A0elsif rising_edge(CLKMAIN) and cIRQA=3D'0' then
>
> And here is your problem. =A0You're using RD and ADDR asynchronously. =A0=
Now ask
> yourself what happens if the condition "RD=3D'0' and ADDR=3DADRA " goes *=
away*
> just prior to the rising edge of CLKMAIN? =A0The result will be a timing
> problem on signal fIRQA which means that this process can end up setting
> fIRQA to 1. =A0The other problem is that the async reset of fIRQA can scr=
ew up
> the timing to anything that *uses* fIRQA. =A0The solution as has been poi=
nted
> out already is to:
> 1. synchronize RD and ADDR before using.
> 2. Don't use "RD=3D'0' and ADDR=3DADRA " to asynchronously reset fIRQA. =
=A0In
> fact, don't use asynchronous resets at all...ever (almost ever).
> 3. Perform static timing analysis
>
>
>
> > IRQPROC : process (CLKMAIN) begin
> > =A0 =A0if falling_edge(CLKMAIN) then
> > =A0 =A0 =A0 =A0fIRQANY <=3D fIRQA or fIRQB or fIRQC;
>
> Again, synchronous design practice has no use for falling edge triggered
> logic, use the rising edge instead. =A0Other than that, there doesn't see=
m to
> be any problems with the irqproc process...however the inputs to the proc=
ess
> have not been synchronized to the clock because fIRQA is not synchronous =
due
> to your use of the async reset in the previous process.
>
> > Anyone see a reason why this should not work?
>
> Yes
>
> Kevin Jennings

Ok, I did a bit of reading,
and this is what I came up with.

(this is similar to one of my prev posts,
but the IRQPROC is simpler and there
are two FF for synchronizing ACK flag)

Is now everything ok?

TIMER : process (cCLKMAIN) begin
    if rising_edge(cCLKMAIN) then
        if counterA=3D0 then
            cIRQA <=3D not cIRQA;
            counterA <=3D reloadA;
        else
            counterA <=3D counterA -1;
        end if;
    end if;
end process TIMER;


IRQFLAGS : process (cCLKMAIN, RD) begin
    if rising_edge(RD) and ADDR=3DADRA then
        aIRQA0 <=3D not aIRQA0;
    end if;

    if rising_edge(cCLKMAIN) then
        aIRQA1 <=3D aIRQA0;
        aIRQA  <=3D aIRQA1;

        if cIRQA /=3D aIRQA then fIRQA <=3D '1'; else fIRQA <=3D '0'; end
if;
    end if;
end process IRQFLAGS;


IRQPROC : process (cCLKMAIN) begin
    if rising_edge(cCLKMAIN) then
        fIRQANY <=3D fIRQA or fIRQB or fIRQC;

        if fIRQANY=3D'1' then
            IRQ <=3D '1';
        else
            IRQ <=3D '0';
        end if;
    end if;
end process IRQPROC;

Article: 137446
Subject: Re: Duty Cycle change effects on Internal reg's
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 16 Jan 2009 17:03:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 11:47=A0am, Gabor <ga...@alacron.com> wrote:
> On Jan 16, 1:03=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
>
>
>
> > On Jan 14, 9:47=A0pm, sreenivas.jyo...@gmail.com wrote:
>
> > > On Dec 15 2008, 11:39=A0am, Peter Alfke <al...@sbcglobal.net> wrote:
>
> > > > In a conventional design (single clock, distributed over global clo=
ck
> > > > nets, all flip-flops triggered on the same, usually rising, clock
> > > > edge, clock frequency not at the max data-sheet limit)dutycycleis i=
rrelevant, as long as you do not violate any clock-High
> > > > or clock-Low timing.
> > > > More exotic designs that use both clock edges or use latches instea=
d
> > > > of flip-flops, are (or might be) sensitive to clockdutycycle.
> > > > Distributing clocks on non-global lines can seriously affectdutycyc=
le, and also cause uncontrolled clock skew and other bad problems.
> > > > Don't do that!
> > > > Peter Alfke
>
> > > Hi peter,
> > > thanks for your response, i am still not configuring my doubt on this
> > > (duty Cycle).
> > > Here is my clear query: I have requirement saying that "The test case
> > > is to test the output signal rcom_tx when fpga_clk is 50 MHz with 40%
> > > and 60% duty cycles", and before that i had a test case for same
> > > signals on 50% duty cycle. so when i did test on 50% duty cycle i got
> > > normal results without any problems, and i am not able to figure out
> > > if i change to 40% and 60% duty cycles than what to expect on output
> > > line.
>
> > > As of my knowledge within duty cycle boundary limit the output doesn'=
t
> > > affect, but out of boundary change in duty cycle is the only
> > > expectancy.
> > > If possible could you please give me any example in explaining this
> > > concept.
>
> > > Thanks
>
> > 50% duty cycle at 50 MHz means 10 ns High followed by 10 ns Low.
> > If you use global clock distribution, there will be no difference
> > whatsoever in the register outputs if you vary the 10 ns to 8 or 12
> > ns.
> > Try to understand the operation of clocked D-flip-flops, and you will
> > agree.
> > Peter Alfke
>
> O.K., but it was you and not the OP who inferred that
> all flip-flops are using the same clock edge. =A0Clearly there
> would be effect on the period where signals are used on opposite
> edges of the clock.

This is a basic discussion, and a basic design would hardly ever use
both clock edges, unless there were an exotic reason. (Excessive clock
delays might be one).
Peter Alfke

Article: 137447
Subject: Re: Counter: natural VS std_logic_vector
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 16 Jan 2009 17:09:50 -0800
Links: << >>  << T >>  << A >>
aleksa wrote:

> Is now everything ok?
NO.
Reread the previous posts
"And here is your problem.  You're using RD and ADDR asynchronously."

"_DON'T_USE_THE_RD_SIGNAL_AS_AN_ASYNCHRONOUS_SIGNAL_"


> IRQFLAGS : process (cCLKMAIN, RD) begin

RD is not a clock.
RD is a plain input.
cCLKMAIN is the only clock.
to detect a 0, 1 sequence on RD, use a shift register on cCLKMAIN

Good night and good luck.

      -- Mike Treseler

Article: 137448
Subject: Re: Duty Cycle change effects on Internal reg's
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 17 Jan 2009 01:28:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote:
(snip)
 
> This is a basic discussion, and a basic design would hardly ever use
> both clock edges, unless there were an exotic reason. (Excessive clock
> delays might be one).

Well, how about DDR RAM?  

I now have a Spartan 3E starter kit with DDR RAM on board, 
though for the designs I have in mind more ordinary RAM would
have been my first choice.   Most likely I don't actually
need the high rate and will only use one edge, if that is possible.

It would be nice to have a simple design that would drive
the DDR, though.  

-- glen

Article: 137449
Subject: CycIII Intefacing these new serial ADC's
From: LC <cupidoREMOVE@mail.ua.pt>
Date: Sat, 17 Jan 2009 02:10:03 +0000
Links: << >>  << T >>  << A >>
Hi,

I'm on a design that requires 2 fast ADC (14bit 100Ms/s)
and an FPGA.

So far all all plans were based on parallel data to the FPGA, but
I must confess these new serial ADC's are tempting
specially the ADS6244 that fits perfectly with my intentions.
(2ch 14bit 125Ms/s in a single package and a few lvds lines only 
interfacing the FPGA)

But I fear the interfacing to an ALtera CycloneIII.
The required will be; serial data at 700Mb/s
and serial clock at 350MHz (DDR)

I would certainly be confident with one of the
high end FPGA's but I can't use anything except
the low cost ones ;-)

I have no problem in doing a proper layout
with all cares about line length and impedances
but...
Is that what it takes and the rest is easy enough ?

I do fear input and inside the FPGA...
too marginal for a CycloneIII to do ?....

is it too hard/difficult ?
does a shift register and word transfer
register design described in VHDL, suffice for the input
deserializer or something fancier is needed ?


Or in the end...
Will I be better off with parallel bus ADC's ?


I'm having trouble to decide myself...

I'll be very happy to hear some comments please.
Thanks.


Luis C.



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