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 54750

Article: 54750
Subject: Distributing clock to external devices
From: damn_spam2001@yahoo.co.uk (Sam Duncan)
Date: 17 Apr 2003 07:09:36 -0700
Links: << >>  << T >>  << A >>
Hi

I'm designing a board which will have an XC2V2000 connected to two external
SRAM chips and an Analog Devices TigerSHARC DSP.  The Virtex is clocked by
the 80MHz TigerSHARC bus clock.  The internal logic of the Virtex operates
in two clock domains - 80MHz (synchronous to the TigerSHARC clock) and
120MHz (not necessarily synchronous to the TigerSHARC clock).  I would like
to interface to the SRAM chips using the 120MHz clock.  Xilinx App Note 132
suggests the configuration shown below for distributing a clock to multiple
non-Virtex devices.  The bus lengths are very short (approx 40mm) so I'm
planning on connecting the buses directly with no termination and using DCI
if necessary.

Xilinx App Note 132
===================
Please view in a fixed-width font such as Courier.


                    XC2V2000
        +-----------------------------+
        |           DCM               |
        |        +-------+            |
   -----+-IBUFG+-+clkin  |            |
        |      | |       |            |
        |      | |   clk0+----OBUF----+------+
        |      | |       |            |      |
        |      | |       |            |      |
        |      | |       |            |      |
        |      | |       |            |      |
    +---+-IBUFG+-+clkfb  |            |      |
    |   |      | |       |            |      |
    |   |      | +-------+            |      |
    |   |      |                      |      |
    |   |      |                      |      |
    |   |      |    DCM               |      |
    |   |      | +-------+            |      |
    |   |      +-+clkin  |            |      |
    |   |        |       |            |      |
    |   |        |   clk0+----BUFG-+  |      |
    |   |        |       |         |  |      |
    |   |        |       |         |  |      |
    |   |        |       |         |  |      |
    |   |    +---+clkfb  |         |  |      |
    |   |    |   |       |         |  |      |
    |   |    |   +-------+         |  |      |
    |   |    +---------------------+  |      |
    |   |                             |      |
    |   +-----------------------------+      |
    |                                        |
    |                                        |
    +----------------------------------------+
    |
    |
    |
    +------- Non-Virtex Device
    |
    +------- Non-Virtex Device
    |


However, I have the following two worries:

1) This seems to suggest a branching clock line.  The two SRAMs are on
opposite sides of the Virtex and each branch will be approximately 40mm.  At
120MHz, I'm concerned about the reflections/glitches this may cause.
2) Since my input clock is 80MHz and the output 120MHz, I'll have to use the
DCM to multiply the frequency up.  This means that I won't be able to feed
the board clock (the clock driving the SRAMs) back into the DCM for
deskewing.  I suppose I could cascade two DCM's and use the first one to
multiply up and the second for deskewing....

To be safe, I'm planning on using an zero delay SDRAM clock buffer from
Cypress as shown in the diagram below:

Clock distribution using SDRAM clock buffer
===========================================
Please view in a fixed-width font such as Courier.

                  XC2V2000
      +-----------------------------+              SDRAM clk buffer
      |           DCM               |             +------+
      |        +-------+            |             |      |
 -----+-IBUFG+-+clkin  |            |             |    o1|-------+
      |        |       |            |             |      |       |
      |        |  clkfx|----OBUF----+-------------+in  o2|----+  |
      |        |       |            |             |      |    |  |
      |     +--+clk0   |            |             |    o3+-+  |  |
      |     |  |       |            |             +------+ |  |  |
      |     +--+clkfb  |            |                      |  |  |
      |        |       |    IBUFG --+----------------------+  |  |
      |        +-------+      |     |                         |  |
      |     +-----------------+     |              SRAM1      |  |
      |     |                       |             +------+    |  |
      |     |     DCM               |             |      |    |  |
      |     |  +-------+            |             |      +----+  |
      |     +--+clkin  |            |             |      |       |
      |        |       |            |             |      |       |
      |        |   clk0+----BUFG+   |             |      |       |
      |        |       |        |   |             |      |       |
      |        |       |        |   |             +------+       |
      |        |       |        |   |                            |
      |    +---+clkfb  |        |   |              SRAM1         |
      |    |   |       |        |   |             +------+       |
      |    |   +-------+        |   |             |      |       |
      |    +--------------------+   |             |      |       |
      |                             |             |      |       |
      +-----------------------------+             |      +-------+
                                                  |      |
                                                  |      |
                                                  +------+

The crucial requirement is for the internal logic running in the 120MHz
domain to be synchronous to the SRAM (not necessarily the 80 MHz input
clock).  This means that the situation is slightly different to the app note
which is concerned with ensuring that there is negligible skew between the
board clock and the input clock to the Virtex.

However, from reading a number of posts in the newsgroups about using the
Virtex itself to distribute a board clock I feel that I'm missing something.
Does anyone have any suggestions as to how this could be done better?  Am I
justified in my concern over a branching clock line?

Many thanks

Sam Duncan
--

Article: 54751
Subject: Avalon Bus Master
From: jim006@att.net (Jim M.)
Date: 17 Apr 2003 07:31:48 -0700
Links: << >>  << T >>  << A >>
As mentioned in an earlier post I've been developing a SOC using NIOS
3.0 and my own custom logic on a Stratix 1S10 Development Board.

I've been trying to interface my custom logic to on-chip memory
through the NIOS CPU by creating an Avalon Bus Master.

I've set up the entire 1S10 MRAM block as a dual port RAM in the NIOS
CPU using SOPC Builder.  The NIOS CPU is a bus master for one port of
the RAM (through the CPU Data Master Bus) and I've added 2 Avalon
Masters to the second port of the RAM.

I've had issues where data written to the RAM through the 2 Avalon
Masters sometimes doesn't make it.  Initially this was due to the
address/data/handshake being calculated in a separate, asynchronous,
clock domain.  I've added the appropriate synchronization blocks
between the domains and moved the address calculation into the Avalon
Master clock domain.  This cleared up about 99% of the dropped writes
(as it turns out these dropped writes were really writes to incorrect
addresses... I determined this through some extensive software
debugging of the memory).  Thanks Paul Leventis for the Multiple Clock
Domain paper!!!! ( http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf
)

However, I'm still stuck with an occasional failed memory write. 
Through the same software debugging, it appears that the data was
never written to the RAM (at the desired address or otherwise).  This
makes sense since the address calculation is performed in it the same
clock domain one cycle before the initiation of the actual write
sequence.  In addition, I check that the 'waitrequest' line is low
(inactive) before releasing the write_n line.

By design, if the write sequence does not execute within 30-35 clock
cycles from the receipt of the handshake, it will be aborted.  I'm
assuming that a Avalon Bus Master write sequence to memory, even with
the occasional 'waitrequest', should execute within a few clock
cycles.

I do not receive any timing warnings through Quartus and the design is
completely synchronous (within each clock domain).  I've implemented
DFF synchronization blocks between the two clock domains but, as I
mentioned above, the address calculation is now performed in the
Avalon Master code itself so there should be no fear of address
corruption.

QUESTION:
Has anyone else experienced similar problems either using a custom
Avalon Bus
Master or using the Stratix MRAM as Dual Port RAM?

Looking for feedback, thanks!

Jim

Article: 54752
Subject: Re: Clock Doubled domain
From: "Eric Pearson" <epearson@lsil.com>
Date: Thu, 17 Apr 2003 10:36:16 -0400
Links: << >>  << T >>  << A >>
Hi John....

Static timing analysis must take into acount both setup and hold.
You comments about minimum time (hold time) are true, however don't
be too conservative. The delays of concern do track at a macroscopic level
as they have common voltage, process, and temperature. Don't forget
that even for a single clock case you still have hold time issues in
the face of clock skew within the distribution tree.

The key question is how will you verify that the design will work
over all situations.

Are you sure those 'others' who have not been able to get their systems
operating with two clocks did any sort of hold time analysis? There are
yet 'others' who sucessfully use 1x/2x domain crossing again and again
using full setup and hold time analysis.


Good luck with your design. You are approaching it with the right
frame of mind.

Eric


"John_H" <johnhandwork@mail.com> wrote in message
news:3E9EB04A.3090705@mail.com...
> I don't belive this will produce 100% results.  Using the same DLL is a
> requirement to having a chance of working at the high speeds.
>
> The "same" edge is not necessarily guaranteed to be sourced from the
> same input edge through the delay taps to the output.  I'd like it if
> they were such that input jitter won't produce skew between like edges.
>   Without details on the DLL innerds, I can't make that call so I err on
> the side of caution.
>
> The clock skews are accounted for in the static timing analysis for
> worst case delays.  If the longest Tcko, the longest net delays, the
> worst case Tsu and clock skew don't exceed your budget, the static
> timing analysis declares that you're "golden."  Unfortunately, the
> "minimum" timing isn't specified.  The skew between clocks can result in
> the earlier clock producing a result before the destination register
> (and associated clock) is clear of its setup/hold window.  We have a
> guarantee for the same-clock situation where the clock skews are in the
> range of 10s of ps but not for the different-clock situation where that
> spread is easily in the 100s of ps.
>
> Other users have been bitten by crossing the 1x and 2x domains on the
> "common" rising edge so I'm trying to avoid that assumption that the
> edges are safely coincident.
>
> . . .
>
> I need to revisit my thoughts to see if I considered using latches
> instead of registers for the negedge x2 sampling of the x1 domain.  I
> might sneak out 100s of ps with latches rather than registers.
>
>
>
> Eric Pearson wrote:
> > Hi John...
> >
> > Can't you generate both clocks from the same PLL so the edges stay
> > together, and use static timing analysis to handle any clock tree
loading
> > skews?
> > I usually do anything to avoid "clock-the-clock" situations.
> >
> > Eric
> >
> > "John_H" <johnhandwork@mail.com> wrote in message
> > news:3E9C1B1F.8020305@mail.com...
> >
> >>Thanks, Ray.
> >>
> >>I used the RLOCs and double-checked the routing to make sure the numbers
> >>were "smallest" and still found myself with almost no margin left over
> >>for input jitter tolerance.  The Tcko and any of the Tceck or Tdick or
> >>Tsrck values along with the shortest net I could muster left the 1.8 ns
> >>for 1/4 clock at the hairy edge.  I was hoping there was an innovative
> >>approach to avoiding the 1.8ns requirement for a 7.2 ns x1clk.
> >>
> >>- John_H
> >>
> >>Ray Andraka wrote:
> >>
> >>>John, You are right ot be concerned about skew between the 1x and 2x
> >>
> > clocks.  If
> >
> >>>you control placement and are clever about getting direct flip-flop to
> >>
> > flip-flop
> >
> >>>connections you can manage to do what you are describing using a
falling
> >>
> > edge
> >
> >>>sensitive FF in the 2x domain to capture the 1x clock, then take the
> >>
> > output of
> >
> >>>the falling edge FF and feed it to a rising edge FF in the 2x domain to
> >>
> > time
> >
> >>>align the resulting CE with the 2x clock rising edges.  The CE is
> >>
> > probably
> >
> >>>inverted WRT to what you wanted at that point, in which case an
> >>
> > additional
> >
> >>>rising edge FF will put it right without adding any logic delays in the
> >>
> > critical
> >
> >>>timing around the neg edge FF.  You'll need to use primitives with
RLOCs
> >>
> > on them
> >
> >>>to keep the timing tight, and with v4.2 and later tools you need to
make
> >>
> > sure
> >
> >>>you put the time constraints in for each connection in order to keep
the
> >>
> > router
> >
> >>>honest (3.3 did a good job of finding the direct connect without having
> >>
> > an
> >
> >>>explicit time constraint).
> >>>
> >>>John_H wrote:
> >>>
> >>>
> >>>
> >>>>Thanks for the message last week, Eric - my newsreader at work isn't
> >>>>100% and I had to read/respond at home.
> >>>>
> >>>>Your comment about only needing two flops is accurate as long as the
> >>>>designer can trust that the x1clk and x2clk domains will always work
> >>>>together as we'd expect where the rising edges are coincident.  The
> >>>>reality is that those two edges may be separated by some 100s of ps
> >>>>since the clock net loading can be different between the two domains
and
> >>>>input clock jitter to the DLL may translate to the two domains at
> >>>>different cycles.  THe former problem is known, I'm only speculating
on
> >>>>the latter.  Bottom line: I can't depend on the two domains to play
nice
> >>>>at the common rising edge, hense the nead to offset things by 1/4 the
> >>>>x1clk (or 1/2 th x2clk).
> >>>>
> >>>>Any further thoughts are appreciated.
> >>>>
> >>>>- John_H
> >>>>
> >>>>Eric Pearson wrote:
> >>>>
> >>>>
> >>>>>"John_H" <johnhandwork@mail.com> wrote in message
> >>>>>news:T9Hka.9$716.2363@news-west.eli.net...
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Has anyone figured out a nice, clean method to track which phase of
a
> >>>>>
> >>>>>Xilinx
> >>>>>
> >>>>>
> >>>>>
> >>>>>>DLL's 1x clock corresponds to a 2x clock cycle?  One 2x rising edge
> >>>>>>corresponds to the 1x rising edge, the other 2x rising edge
> >>>>>
> > corresponds to
> >
> >>>>>>the 1x falling edge.
> >>>>>>
> >>>>>>When I start getting up in frequencies, the ability to use the 1x
> >>>>>
> > clock
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>inverted 1x clock to generate two signals that I can XOR for a phase
> >>>>>
> > is
> >
> >>>>>>compromised.  It's not inherently safe to use the 1x edges and 2x
> >>>>>
> > rising
> >
> >>>>>>edges as "effectively" the same edge due to clock skews and input
> >>>>>
> > jitter
> >
> >>>>>>issues.  Using the falling edge of the 2x clock to sample the 1x
> >>>>>
> > generated
> >
> >>>>>>signals works, but at the 1/4 period timing budget is too tight at
the
> >>>>>>frequencies I'm working.
> >>>>>>
> >>>>>>For those who are Verilog friendly, the code here shows how I would
> >>>>>>"normally" extract the phase without running a clock through a LUT.
> >>>>>
> > The
> >
> >>>>>>"negedge x2clk" is where the timing gets tough since the
> >>>>>
> > Tcko+Tnet+Tick is
> >
> >>>>>a
> >>>>>
> >>>>>
> >>>>>
> >>>>>>little over the 1/4 period of my x1clk.
> >>>>>>
> >>>>>>always @(posedge x1clk)  posTog <= ~posTog;
> >>>>>>always @(negedge x1clk)  negTog <= posTog;
> >>>>>>always @(negedge x2clk)  rawPhase <= posTog ^ negTog;
> >>>>>>always @(posedge x2clk)  phase <= rawPhase;
> >>>>>>
> >>>>>>Is there a cleaner way to figure out the which half of the x1clk I'm
> >>>>>
> > in?
> >
> >>>>>>Thanks,
> >>>>>>- John_H
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>It really only takes 2 flops working on rising edge.
> >>>>>
> >>>>>always @(posedge x1clk)  Toggle <= ~Toggle;
> >>>>>always @(posedge x2clk)  Delayed <= Toggle;
> >>>>>assign Phase = DelTog ^ Tog;
> >>>>>
> >>>>>Eric
> >>>>>
> >>>>>
> >>>>
> >>>--
> >>>--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: 54753
Subject: Re: spartan2e vs cyclone
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Apr 2003 10:42:38 -0400
Links: << >>  << T >>  << A >>
Paul Leventis wrote:
> 
> > Looks like the EP1C4 is still not out yet.  At least it did not show up
> > when I did a web search at Arrow.  The approach of providing a smaller
> > part with higher IO count is interesting.  It fits my needs very well.
> > But looks like it is yet to come out.  Any idea when?
> 
> Hi Rick,
> 
> EP1C4 is scheduled for release in September 2003.  Given the early or
> on-time delivery of the other members of the family, this date is pretty
> solid.

After reading Fredrik's post, I found the release dates by searching the
press releases which contained a link.  

I am curious.  Since all the other devices are shipping now, why is the
EP1C4 shipping so much later?  I saw on the EBV web site that they still
don't even list the EP1C4 in the Cyclone Family Overview.  Was the EP1C4
added as an afterthought after the other devices had been planned?  It
seems like 5 months is a long time after all the other family members
are out.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 54754
Subject: SpartanIII Partial Reconfiguration
From: "Silvano Bettinzana" <bettinzana@diadix.it>
Date: Thu, 17 Apr 2003 15:25:09 GMT
Links: << >>  << T >>  << A >>
Hi there,

is possible to partial reconfigure SpartanIII devices (something similar to
partial reconfiguration of VirtexII) ?

Thanks

Silvano





Article: 54755
(removed)


Article: 54756
(removed)


Article: 54757
(removed)


Article: 54758
(removed)


Article: 54759
Subject: Re: Advice on FPGA IIR Filter
From: "gallenm" <gallenm@ic24.net>
Date: Thu, 17 Apr 2003 17:52:23 +0100
Links: << >>  << T >>  << A >>
Hi,
Just adding a plug for ONEoverT digital filter designer. It will
automatically produce
synthesizable VHDL for IIRs and FIRs. Very cheap, the demo can be downloaded
from
the website
www.tyder.com

If you download the case study, it will show you the implemention of an IIR
onto a Spartan
FPGA.

Yours
Alan Mc Kitterick
www.tyder.com

"Pramod" <pramod@procsys.com> wrote in message
news:a7c0720d.0304152101.581c85be@posting.google.com...
> Hi All,
> I am new to this group and also to the field of FPGA based design.
> I have some doubts and issues which I feel will be easy for you guys
> to answer.
> 1. For a 4 pole IIR Filter in FPGA (targeted device EP1C6), I have a
> spec of 24 bit wide data input and
> 32 bit wide coeff (dynamic) inputs. So, the multiplied results should
> ideally have
> 56 bits width. Are these widths practically relevant for a 4 pole
> filter
> or can we get an affordable precision with rounding to lower sizes?
> If so, can anyone suggest a standard procedure for
> rounding the  results with lowest error and without causing the output
> to become unstable?
> 2. Another thing I would like to get some advice is, if I go with the
> 24 X 36 busses,
> since I have to implement a number of such filters in a single device,
> the bit-parallel implementation will take up huge resources.
> The digit serial approach using (either small multiplier or LUT
> method)
> also will end up in huge resources due to big number of partial
> products and sums involved.
> If anyone can suggest any alternate method it will be of great help to
> me.
> 3. On another front, in a timing simulation scenario I am using
> Quartus II .vo output and ModelSIM PE. My code has
> a ROM (ALTSYNCRAM megafunction used to generate this). I found some
> differences in the
> readout data during timing simulation between using .MIF format file
> and .HEX format file for initializing ROM
> eventhough the QII displayed same contents in the memory editor.
> Has anyone ever faced any such issues?
> Hoping to get some valuable leads on these..
> Thanks in advance,
> Pramod



Article: 54760
Subject: fpga_edline.exe
From: "Steve Harlow" <sharlow1@san.rr.com>
Date: Thu, 17 Apr 2003 17:27:28 GMT
Links: << >>  << T >>  << A >>
Anybody know what fpga_edline.exe is?
What it is useful for?
How to use it?




Article: 54761
Subject: Boycott All Xilinx products untill they correct all ISE software errors
From: billh40@aol.com (Bill Hanna)
Date: 17 Apr 2003 11:01:24 -0700
Links: << >>  << T >>  << A >>
I have been designing a Digital Signal Processor using the XC2V4000
chip.
Software errors in ISE 4.2 and 5.1 have caused long hours of delay in
developing the design:

    Software bugs in SystemAce causes erase problems in the MPM. 
    Deleting signal wires in ECS causes Fatal errors that crash the
system.
    A large design exceeds the 2GB memory limit and generates a fatal
memory error.

    I have designed Altera chips for over 6 years and never had a
problem.

    All digital designers should stop designing new projects with
Xilinx ICs until Xilinx corrects all software problems with ISE.

Bill Hanna

Article: 54762
Subject: Help with this component: ADD_BITSLICE
From: "Kang Liat Chuan" <kanglc@starhub.net.sg>
Date: Fri, 18 Apr 2003 02:14:45 +0800
Links: << >>  << T >>  << A >>
Hi comp.arch.fpga,

I came across a component in Orcad named ADD_BITSLICE, and am thinking what
it does.

It seems it is not a lower level schematic, neither is it a
logiblox/coregen. The ports are:

BIT_PREV : in std_logic;
BIT_NEW  : in std_logic;
BYTE0    : in std_logic;
BIT0     : in std_logic;
CE       : in std_logic;
CLK      : in std_logic;
ACC_NEW  : out std_logic;

I know this may sound silly, but it seems pretty simple to construct this
component using AND, XOR and a FF. So why is it a primitive/macro component?

I've search many places, but don't seem to find this component. Anyone who
can help, thanks!

Regards,
LC



Article: 54763
Subject: Re: Boycott All Xilinx products untill they correct all ISE software
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Apr 2003 14:38:09 -0400
Links: << >>  << T >>  << A >>
Bill Hanna wrote:
> 
> I have been designing a Digital Signal Processor using the XC2V4000
> chip.
> Software errors in ISE 4.2 and 5.1 have caused long hours of delay in
> developing the design:
> 
>     Software bugs in SystemAce causes erase problems in the MPM.
>     Deleting signal wires in ECS causes Fatal errors that crash the
> system.
>     A large design exceeds the 2GB memory limit and generates a fatal
> memory error.
> 
>     I have designed Altera chips for over 6 years and never had a
> problem.
> 
>     All digital designers should stop designing new projects with
> Xilinx ICs until Xilinx corrects all software problems with ISE.
> 
> Bill Hanna

Perhaps we should be a bit more demanding in the quality of our tools. 
But if we stopped using them, how would the vendors know what the bugs
were, and how would we keep jobs and get paid?  With no paycheck, I
would not be an engineer anymore and would not care about the tools.  

Seems rather extreem to me.  As good or bad as they are, they are the
tools we have.  Is this a leadin for a demand for open source tools?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 54764
Subject: Re: Boycott All Xilinx products untill they correct all ISE software errors
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Thu, 17 Apr 2003 19:41:12 +0100
Links: << >>  << T >>  << A >>
"Bill Hanna" <billh40@aol.com> wrote in message
news:97d137ce.0304171001.5ec5461d@posting.google.com...
>     I have designed Altera chips for over 6 years and never had a
> problem.

I was listening until you said that.

Sorry but Altera and Xilinx both have a fair share of problems. If you are
going to berate Xilinx at least don't ruin the case by unfounded Altera
comments.

My 0.02cents

Paul




Article: 54765
Subject: Re: Boycott All Xilinx products untill they correct all ISE software errors
From: "John Milbanks" <phony@nowhere.cc>
Date: Thu, 17 Apr 2003 12:05:18 -0700
Links: << >>  << T >>  << A >>

"Bill Hanna" <billh40@aol.com> wrote in message
news:97d137ce.0304171001.5ec5461d@posting.google.com...
> I have been designing a Digital Signal Processor using the XC2V4000
> chip.
> Software errors in ISE 4.2 and 5.1 have caused long hours of delay in
> developing the design:
>
>     Software bugs in SystemAce causes erase problems in the MPM.
>     Deleting signal wires in ECS causes Fatal errors that crash the
> system.
>     A large design exceeds the 2GB memory limit and generates a fatal
> memory error.
>
>     I have designed Altera chips for over 6 years and never had a
> problem.
>
>     All digital designers should stop designing new projects with
> Xilinx ICs until Xilinx corrects all software problems with ISE.
>
> Bill Hanna

Frustration speaking, no doubt, and I sympathize. However, you do have the
ability as a customer to take your business elsewhere if you're unhappy with
a vendor's products, and that's exactly what you should do. I'd give your
Xilinx rep and tech support a chance to get this rectified first (assuming
you haven't), and let Xilinx know why you're departing. Otherwise they'll
never know that you're unhappy and that there's a problem. If you find a
vendor/tool you like better, post about it to the group. Don't expect to
find a tool devoid of problems, though. Having written mucho software over
the years, I know that a defectless software product isn't going to exist.



Article: 54766
Subject: Re: NIOS 3.0 Fmax and other Issues
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Thu, 17 Apr 2003 21:18:34 +0200
Links: << >>  << T >>  << A >>
Hi Jim,

> I found that eliminating my LogicLock regions sped up the compilation
> and improved the results.  I guess it's true when Altera says you
> should only use LogicLock if you know what you're doing.  Some recent
> feedback from Altera suggested that LogicLock is more of a benefit on
> the APEX parts than on the Stratix/Cyclone FPGAs.

I have had incredible performance boosts with LogicLock with certain
designs, but most of the time performance varies only 10-15%. And, I have
seen performance go down as well, so LogicLock is definitely not a magic
sword.

My personal rule of thumb roughly works as follows: a good indicator with
APEX to start thinking about using LogicLock is when the routing delay gets
to be more than twice your cell delay in your critical path. If you then
examine the entire path, and there are more than two or three interconnects
going over 4ns you have a strong contender. If you then look at the
offenders and find out in the floorplanner that the source cell drives only
one or two destination cells, then you should definitely give it a try. Of
course, your mileage may vary ;-)

Stratix routing is faster and its behaviour is more linear - with an APEX,
as soon as you leave the MegaLAB you get a farly heavy performance hit, with
Stratix the delay is more or less linearly dependant on the New York
distance (how many LABs horizontal plus how many LABS vertical) between
source and destination, all this with a maximum resolution of 4 LABs. Thus,
if for some reason there is a bit more distance between two cells, it will
not give such a terrible performance hit, and thus the need for LogicLock is
less.

With Stratix I start looking to LogicLock stuff when the routing gets to be
over three times the cell delay, and then roughly follow the APEX procedure.
It does still help, but as you have found out, excessive use of LogicLock
strongly restricts the placement algorithm and may cause long fitting times.

> I'm using a 1.2 GHz Athlon K7 as well... I'm tempted to upgrade to a
> P4 but I'm not sure what sort of performance boost I'll see when using
> Quartus... tough call on wether to spend the money.

Quartus is quite CPU hungry, but it's an unmatched memory bandwidth eater,
and your CPU might as well not have a cache. So, if you do spring for a
faster CPU, make sure that it has a matching memory subsystem. Use CL2
DDR333 or DDR400 SDRAM, or 800MHz RDRAM, and pick a motherboard with a good
memory controller.

Personally I'm aiming for an Athlon XP 3000+ - I still think they're more
bang for the buck at about $400. But then I would also have to swap my 1GB
CL2 DDR266 SDRAM out again... Oh, those luxury problems ;-)

Good luck,



Ben



Article: 54767
Subject: Re: spartan2e vs cyclone
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Thu, 17 Apr 2003 21:32:12 +0200
Links: << >>  << T >>  << A >>
Hi Rick,

> Was the EP1C4
> added as an afterthought after the other devices had been planned?  It
> seems like 5 months is a long time after all the other family members
> are out.

Since the Cyclone family spec was based on a lot of customer feedback, I
guess that it took five months of customers complaining about too little I/O
per LE in the Cyclone family to get this one started ;-)

By the way, if you install Quartus II 2.2 service pack 2 you can already
start designing for it.

Best regards,



Ben



Article: 54768
Subject: Re: spartan2e vs cyclone
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Thu, 17 Apr 2003 19:52:31 GMT
Links: << >>  << T >>  << A >>
> After reading Fredrik's post, I found the release dates by searching the
> press releases which contained a link.

If you go to the 'Overview' page on the Cyclone web site, it also lists the
Production availability dates -- Sept 2003 is for production devices.

http://www.altera.com/products/devices/cyclone/overview/cyc-overview.html

> I am curious.  Since all the other devices are shipping now, why is the
> EP1C4 shipping so much later?  I saw on the EBV web site that they still
> don't even list the EP1C4 in the Cyclone Family Overview.  Was the EP1C4
> added as an afterthought after the other devices had been planned?  It
> seems like 5 months is a long time after all the other family members
> are out.

Really the anomally is rolling out (to full production status, no less) four
devices in three months -- when you look at the roll-out of other FPGA
families, 9 months from first to last member is not abnormal.

The technical reason: In order to achieve the higher IO density on the 1C4,
we use a staggered (vs. linear) pad ring, which required a small amount of
additional design, verification and software modeling effort.  All the other
Cyclone members use a linear pad ring and share the same IO building
blocks -- that's why we could stamp them out so quickly.

Regards,

Paul Leventis
Altera Corp.



Article: 54769
Subject: rloc in verilog / tutorial for creating macros
From: "kris" <twofold@gmx.net>
Date: Thu, 17 Apr 2003 19:52:38 GMT
Links: << >>  << T >>  << A >>
I'm would like to use rloc directly in verilog. Yet it does not work.
I use the ISE design flow with the XST synthesis on  a Virtex2. Below you
can find the code.

It consists of 2 gates in parallel followed by 2 registers in parallel
followed by 2 gates in parallel.
After place and route the 2 registers are in the same slice. But this is not
according to the rloc statement.
Can anybody tell me what I'm doing wrong?

Also where can I find a good tutorial regarding how to create macros
(with/without the fpga editor)?

Kris


////////////////////////////////////////////////////////////////////////////
/////////////////////////



module REGS(clk, ina, inb, outa, outb);

input clk, ina, inb;

output outa, outb;

wire in1, in2, out1, out2;

//-- logic

assign in1= ina|inb;

assign in2 = ina&inb;

assign outa = out1|out2;

assign outb = out1&out2;


//-- registers

REG1 REG1a(clk, in1, out1);

REG2 REG2a(clk, in2, out2);

endmodule

module REG1(clk, in, out);

input clk, in;

output out;

reg out;

always @(posedge clk)

begin

out <= in;

end

endmodule

module REG2(clk, in, out);

input clk, in;

output out;

reg out;

always @(posedge clk)

begin

out <= in;

end

endmodule



// synthesis attribute u_set of REG1a is set1;

// synthesis attribute rloc of REG1a is X0Y0;

// synthesis attribute u_set of REG2a is set1;

// synthesis attribute rloc of REG2a is X3Y3;








Article: 54770
Subject: Re: spartan2e vs cyclone
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 17 Apr 2003 19:53:46 GMT
Links: << >>  << T >>  << A >>
Wow - the Cyclone may now be a contender!

As much I/O available as in the largest EP1C20 but just slightly more logic
than the smallest EP1C3.


"Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl> wrote in message
news:ViDna.2090$KF1.84443@amstwist00...
> Hi Rick,
>
> > Was the EP1C4
> > added as an afterthought after the other devices had been planned?  It
> > seems like 5 months is a long time after all the other family members
> > are out.
>
> Since the Cyclone family spec was based on a lot of customer feedback, I
> guess that it took five months of customers complaining about too little
I/O
> per LE in the Cyclone family to get this one started ;-)
>
> By the way, if you install Quartus II 2.2 service pack 2 you can already
> start designing for it.
>
> Best regards,
>
>
>
> Ben



Article: 54771
Subject: Re: Hardware acceleration for raytracing purposes
From: <wickedchicken@trioptimum.com>
Date: Thu, 17 Apr 2003 15:55:42 -0400
Links: << >>  << T >>  << A >>

"Matt Giwer" <jull43@tampabay.rr.com> wrote in message
news:Ri_ma.155738$j8.3403659@twister.tampabay.rr.com...

>
> Even then, each processor would create an output file in the chosen
> format with all the right headers. So they would have to be processed to
> reassemble instead of simply concatenating them. Ideally instead of each
> processor writing to its own file it would send the results to one
> computer which would then create a single output file. That would be
> another interesting rewrite.
>
> That is why so far I have only addressed the trivial issue of
> animations where the number of frames is assigned by clock speed.
>

I'm writing my own raytracer that does this (although by no means POV-Ray
quality, I don't have much up right now). My idea is to dole out bunches of
rays to each proc (or maybe specify a light and have each proc produce
rays), and after that all the reflected rays are split up and redistributed
according to how fast each proc is (by a simple benchmark, maybe rays/sec or
something).



Article: 54772
Subject: Re: NIOS 3.0 Fmax and other Issues
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: Thu, 17 Apr 2003 20:07:19 GMT
Links: << >>  << T >>  << A >>
> > I'm using a 1.2 GHz Athlon K7 as well... I'm tempted to upgrade to a
> > P4 but I'm not sure what sort of performance boost I'll see when using
> > Quartus... tough call on wether to spend the money.

Assuming you are limited by the place & route time (as most non-toy designs
are), then take a look at the SPEC 2000 benchmark, in particular the SPEC
Int test "175.vpr".  This test is based on the academic VPR tool, which is a
simulated annealing-based placer and negotiated congestion router for an
FPGA.  The results of this test should correlate reasonably well with
Quartus run times, or pretty much any place & route CAD tool.  In some
informal testing, we've found the results hold up pretty well (in
particular, that a P4 has to have a high clock rate to beat out a P3).

Web site:  www.spec.org/cpu2000

Some results I grabbed randomly:

AMD XP 3000+:        215
3.06 Ghz P4                231
1.4 Ghz P3                  283
1.5 Ghz P4                  460
Athlon 1.2 Ghz            549

Of course, this ignores the impact of the memory sub-system...

Regards,

Paul Leventis
Altear Corp.



Article: 54773
Subject: Re: Boycott All Xilinx products untill they correct all ISE software
From: Mike Treseler <tres@fluke.com>
Date: Thu, 17 Apr 2003 13:09:47 -0700
Links: << >>  << T >>  << A >>
Bill Hanna wrote:

> 
>     Software bugs in SystemAce causes erase problems in the MPM. 

For development, consider downloading from the host
or flash file system.

>     Deleting signal wires in ECS causes Fatal errors that crash the
> system
>     A large design exceeds the 2GB memory limit and generates a fatal
> memory error.

Consider using an HDL for large designs.
> 
>     I have designed Altera chips for over 6 years and never had a
> problem
>     All digital designers should stop designing new projects with
> Xilinx ICs until Xilinx corrects all software problems with ISE.


Consider synthesis to isolate yourself somewhat from the brand differences.
The devices and the vendor-supplied front end tools don't
have to be used together.

   -- Mike Treseler


Article: 54774
Subject: Re: NIOS 3.0 Fmax and other Issues
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Thu, 17 Apr 2003 23:13:33 +0200
Links: << >>  << T >>  << A >>
Little addition:

> Quartus is quite CPU hungry, but it's an unmatched memory bandwidth eater,
> and your CPU might as well not have a cache. So, if you do spring for a
> faster CPU, make sure that it has a matching memory subsystem. Use CL2
> DDR333 or DDR400 SDRAM, or 800MHz RDRAM, and pick a motherboard with a
good
> memory controller.

See for a nice comparison chart:

http://www.tomshardware.com/mainboard/20030303/amd_athlon-03.html

If I were to switch from my current AMD760-based motherboard to one using
the nForce chipset I could easily gain 20% performance, while keeping the
rest of my system the same...






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