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 39550

Article: 39550
Subject: Re: Pseudorandom Bitstream
From: Stromeko@nexgo.de (Achim Gratz)
Date: 13 Feb 2002 02:18:15 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3C69B198.C52EA024@andraka.com>...
> Like I said, that is the speed of the routing.  [...]

Sure, I took notice (as I said, I will probably interleave two LFSR as
the FF only implementation takes too many CLB). I just did a quick
hack to ascertain that the extra delay was really coming from routing.
Of course I'll need to do this optimization again when I've settled on
an LFSR polynomial (downloaded XAPP052 a few days ago, still waiting
for time to read it).

> Xilinx: Perhaps a good thing to do would be to add a note in the timing reports when the
> period constraint on a clock that clocks an SRL16 is less than the minimum period dictated
> by the min pulse widths.  Same for the minimum and maximum clocks for the clkdlls.
> Several people I am aware of have missed these limitations in recent designs.

I second that. I would have fallen into that trap and been burned
quite badly. Especially worrysome is that with default settings the
synthesis will automatically infer SRL16 for shift registers that the
user might think should have been instantiated as FF chains. I wonder
if it would be possible to "fix" that by a timing constraint. Is it
possible to put constraints on all instances of some particular
primitive (that is invisible to the original HDL nonetheless) instead
of on specific nets?

> Std_logic_unsigned and std_logic_signed were synopsis libraries.  They generally cannot
> coexist in the same entity because they have conflicting declarations.  Despite the name,
> they are also not standard among different vendors.  For the assignments, you can use
> casts for related types.  Std_logic_vector, unsigned, and signed are related types so;
> Numeric_std is an IEEE standard library.  Us it instead of wrestling with all the problems
> of std_logic_unsigned, std_logic_arith and std_logic_signed.
> 
>     slv_signal<= std_logic_vector(unsigned_signal);
>     unsigned_signal<= unsigned(slv_signal);
> 
> Does that answer your question?

Not fully. I get errors for constructs like:

unsigned_signal <= 0;           -- compiler wants bitstring for
literal
unsigned_signal <= unsigned(0); -- compiler: can not be converted to
unsigned

These must have a simple solution, as for instance

unsigned_signal <= unsigned_signal*0; -- works like a charm

doesn't pose any problems.


Achim Gratz.

Article: 39551
Subject: Re: par and carry chains not allowing manual floorplanning
From: hamish@cloud.net.au
Date: 13 Feb 2002 11:24:30 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> I just tried using the 4.1 sp3 floorplanner for a Virtex (QPRO) design which has
> a bunch of RPMs with RLOCs in the code.  What a disaster.  The new floorplanner
> is badly screwing up the RLOC'd placement...it looks like maybe it thinks it is
> trying to place a virtexII.  I tried reading an FNF from a 3.3 design, that gets

I haven't seen this, but I did notice another problem; I placed some RPMs
(RLOCs in VHDL) with the Floorplanner, for a Virtex-II, and in the UCF
file created, the X and Y co-ordinates were swapped!


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

Article: 39552
Subject: Re: par and carry chains not allowing manual floorplanning
From: hamish@cloud.net.au
Date: 13 Feb 2002 11:31:21 GMT
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote:
> My thoughts are that Xilinx ought to make the updated timing files available for 3.3
> immediately so that people using floorplanner with RPMs aren't in a pickle (do people
> really use floorplanner without RPMs?  How tedious can that be?)

I use it mostly to:
1. inspect the work of the auto-placer, and
2. generate area groups to assist the auto-placer.

Having said that, my last week or two of attempting to route a couple
of ambitious Virtex-E designs have made me place more and more logic
with fixed LOCs rather than area groups. Area groups are a big help
but there's still enough rope for PAR to hang itself.

4.1i in a Virtex-II is a dream to work with, though (at the same clock
speed). 3.1i in Virtex-E is hell for me lately.


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

Article: 39553
Subject: CLKDLL doesn't work without BUFG ?
From: jeremy <>
Date: Wed, 13 Feb 2002 03:39:10 -0800
Links: << >>  << T >>  << A >>
I want to use a CLKDLL without BUFG with a 33% duty-cycle clock. I have the good Duty Cycle Correction Property in the DLL, but I have the same duty-cycle after and before the DLL.

Article: 39554
Subject: Re: spi4-02.0
From: hamish@cloud.net.au
Date: 13 Feb 2002 11:41:00 GMT
Links: << >>  << T >>  << A >>
Dinesh <dineshb@ctd.hcltech.com> wrote:
> 1. What is the significance of CALENDAR_M. How does this value is
> determined?
> 2. Why do we have to iterate the calendar sequence for CALENDAR_M
> times?
> 3. If the calendar_M is set to a large value, how does it impact?

From memory, the receiver sends the sequence of length CALENDAR_LEN,
CALENDAR_M times between control words. That is, there will be
CALENDAR_LEN * CALENDAR_M status bytes transferred, followed by
the DIP2 parity word, followed by the framing word, then the
sequence  repeats.

The transmitter and receiver have to agree on the value of
CALENDAR_LEN and CALENDAR_M for the status bus to frame up.
CALENDAR_LEN may be fixed by the number of ports supported
by your devices but CALENDAR_M is usually configurable.

Increasing CALENDAR_M just decreases the amount of overhead
on the status bus. It also changes the probability of detecting
a parity error on the bus. Probably you would set CALENDAR_M to
the largest value supported by your transmitter or receiver.

> 4. The data transmitter will transmit data based on the FIFO status.
> Based on which FIFO status it will transmit whether based on the first
> iteration or last iteration(calendar_m)?

I would think that you would use the most recent value you have received.

I'm curious as to your application?

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

Article: 39555
Subject: Re: student F2.1i printing problem
From: Stephen <magician1977@hotmail.com>
Date: Wed, 13 Feb 2002 03:51:28 -0800
Links: << >>  << T >>  << A >>
Had the same problem,zero feedback and did this : Installed Paintshop pro and captured the schematics :-) I know it is the solution of the dumb but at least it worked :-)

Article: 39556
Subject: Re: Making Altera development quicker
From: newman5382@aol.com (newman)
Date: 13 Feb 2002 05:21:24 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3C69C149.CDEC9B51@andraka.com>...
> Without a second processor doing other tasks is extremely sluggish, and running a short
> sim or synthesis run while a place and route is in progress (for example) is out of the
> question.  The second processor doesn't speed up any of the EDA tools that I am aware of.
> The difference is that I can do reasonable work (not just text edits) while I've got
> something else running.  To make it at all useful, you've got to load the machine up with
> memory so that it isn't paging a lot, and you should have some good fast storage.  I have
> a dual PIII-800e and a single PIII833 here.  I'll take the dual any day over the single
> because I'm not left sitting on my hands while a sim runs.
> 

A fast dual processor is great to have.  I used a 800 MHz dual PIII,
and while one processor was pegged doing a Place and Route,  I was
able to listen to MP3 tunes and surf the net using the other
processor, without a single glitch heard from the MP3 player! :)

But speaking on the single threaded aspect of a lot of EDA software,
last I looked, dual processor clock speeds tend to lag behind single
processor clock speeds, and I think I am better off buying a
reasonably priced single processor computer every year, and use one of
those keyboard/mouse/video switch boxes to do other things on the old
computer while doing a place and route on my greatest and newest
computer.  This strategy also allowed me to justify the purchase of an
AMD XP system, which made me happy because I own AMD stock.

Newman

Article: 39557
Subject: Re: Newbie SpartanII Block Ram question
From: "Jens Niemann" <jensniemann@gmx.de>
Date: Wed, 13 Feb 2002 14:45:28 +0100
Links: << >>  << T >>  << A >>
Thanks John.
Everything is working fine now.



Article: 39558
(removed)


Article: 39559
Subject: Re: Suggestions on distributing a module...
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 13:50:07 GMT
Links: << >>  << T >>  << A >>
You can put it out as an edif netlist.  That can be blackboxed into any design
flow.  It would be helpful if you could put a simulation model with it.

Nicholas Weaver wrote:

> I have a nice Rijndael encoder implementation for the Spartan
> II/Virtex FPGAs (over 1 Gbps, 115 MHz, <800 clb slices, fully key
> agile, Spartan II-100-5 (according to static timing analysis)).  Once
> I get the last minor interfacing bug squished, I'll release it under
> the LGPL.
>
> The question is, is there a more convenient way than it's current form
> (a Foundation/aldec schematic design, consisting of about 5-6
> schematic specified RLOCed blocks which are placed with RLOC_ORIGINs)
> to release it instead of just the schematics?  EG, a nice way to turn
> the schematic pieces into a more portable modules?  Some RLOCing is
> needed to specify the design to a specific chip (to balance delays
> between blockrams and to place the subkey generation in the
> appropriate place, and to tile to larger bandwidth).
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

--
--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: 39560
Subject: Re: RAM CORE settings for maximum speed
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 13:57:20 GMT
Links: << >>  << T >>  << A >>
for 4K deep, it should be using 12 BRAMs arranged as 4Kx1 bit slices.
Just verify that it is doing that and not something silly with muxes.  The
XCV***-4 parts' BRAM maxes out at about 125 MHz, but to get there you need
to put pipeline registers immediately before and after all the signals in
and out of the RAM.  The worst timing is on the ENA and WE inputs.  These
two really need a duplicated flip-flop driving them and located
immediately adjacent to the BRAM (1 FF per BRAM). Check your timing reprot
for the worst case paths.  dollars to donuts the WE and/or ENA paths are
among the worst.  Also, you should probably duplicate the address
generators, especially if you have not located all the RAMs close
together.  One last thing, the automatic place and route does a lousy job
at placing the BRAMs,  use the floorplanner to place the RAMs close
together and to place the pipeline registers adjacent to the BRAMs.

Antonio wrote:

> Good Morning, the speed of my project is all depending on the speed of
> the RAM I use in it, I need a RAM 3072x12, to obtain it I used CORE
> GENERATOR , choose single port RAM version 3.0 arranged for VIRTEX (in
> my case I use XCV1000BG560-4) but the speed is really low, a maximum
> of 50MHz and I repeat the speed of my circuit is only depending on the
> RAM that can be read only (Essentially it is a ROM) and must be read
> on every negative front of the clock. Can you tell me the setting I've
> to do for this core to obtain the maximum speed ??
> I've choose a dimension of 4096x12 , thinks this help for the speed.
>
> Thanks Antonio

--
--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: 39561
Subject: Re: Pseudorandom Bitstream
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 14:04:29 GMT
Links: << >>  << T >>  << A >>


Achim Gratz wrote:

> Ray Andraka <ray@andraka.com> wrote in message news:<3C69B198.C52EA024@andraka.com>...
> > Like I said, that is the speed of the routing.  [...]
>
> Sure, I took notice (as I said, I will probably interleave two LFSR as
> the FF only implementation takes too many CLB). I just did a quick
> hack to ascertain that the extra delay was really coming from routing.
> Of course I'll need to do this optimization again when I've settled on
> an LFSR polynomial (downloaded XAPP052 a few days ago, still waiting
> for time to read it).
>
> > Xilinx: Perhaps a good thing to do would be to add a note in the timing reports when the
> > period constraint on a clock that clocks an SRL16 is less than the minimum period dictated
> > by the min pulse widths.  Same for the minimum and maximum clocks for the clkdlls.
> > Several people I am aware of have missed these limitations in recent designs.
>
> I second that. I would have fallen into that trap and been burned
> quite badly. Especially worrysome is that with default settings the
> synthesis will automatically infer SRL16 for shift registers that the
> user might think should have been instantiated as FF chains. I wonder
> if it would be possible to "fix" that by a timing constraint. Is it
> possible to put constraints on all instances of some particular
> primitive (that is invisible to the original HDL nonetheless) instead
> of on specific nets?

Problem is the xilinx tools will not change a netlist consisting of only primitives.  The fix
has to be in the synthesis tool so that it instantiates FF's instead of SRL16s.  You can force
the issue by putting a reset on your shift register, since the SRL16 has no reset.  I think
there may be a syn_register_style attribute in some tools that can be used to prevent inference
of an SRL16.

>
>
> > Std_logic_unsigned and std_logic_signed were synopsis libraries.  They generally cannot
> > coexist in the same entity because they have conflicting declarations.  Despite the name,
> > they are also not standard among different vendors.  For the assignments, you can use
> > casts for related types.  Std_logic_vector, unsigned, and signed are related types so;
> > Numeric_std is an IEEE standard library.  Us it instead of wrestling with all the problems
> > of std_logic_unsigned, std_logic_arith and std_logic_signed.
> >
> >     slv_signal<= std_logic_vector(unsigned_signal);
> >     unsigned_signal<= unsigned(slv_signal);
> >
> > Does that answer your question?
>
> Not fully. I get errors for constructs like:
>
> unsigned_signal <= 0;           -- compiler wants bitstring for
> literal
> unsigned_signal <= unsigned(0); -- compiler: can not be converted to
> unsigned
>

That is because it is  expecting a bit vector.  Casting only works for closely relted types.
Use  the to_unsigned function:

unsigned_signal <= (others=>'0');
unsigned_signal<= to_unsigned(10,bits);


>
> These must have a simple solution, as for instance
>
> unsigned_signal <= unsigned_signal*0; -- works like a charm
>
> doesn't pose any problems.
>
> Achim Gratz.

--
--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: 39562
Subject: Re: par and carry chains not allowing manual floorplanning
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 14:07:00 GMT
Links: << >>  << T >>  << A >>
I've found 4.1 to be just about useless for anything other than VirtexII designs.  The
floorplanner is so broken that I can't imagine anyone seriously using it.  Xilinx has
acknowledged the carry chain problem with the floorplanner, but there is also a
problem with it changing the placement on other RPMs too.  The 'workaround' is to let
PAR run on the unfloorplanned design, constrain from placement, unbind then bind each
RPM.  Then you can move it without it getting changed.  Unfortunately, the bulk of my
designs are dense enough that PAR can't find a placement, or in cases where it does
there is not enough room to left to move the RPMs where I need them.  I also found
that even for a placed design the router in 3.3sp8 does a considerably better job than
the 4.1 router.

Thinking back, I think the tools have lost something on every major release.  The 3.x
floorplanner never got to the level the xact floorplanner had reached.  It seems that
if it is not necessary for the big green push button flow, it is not a priority.



hamish@cloud.net.au wrote:

> Ray Andraka <ray@andraka.com> wrote:
> > I just tried using the 4.1 sp3 floorplanner for a Virtex (QPRO) design which has
> > a bunch of RPMs with RLOCs in the code.  What a disaster.  The new floorplanner
> > is badly screwing up the RLOC'd placement...it looks like maybe it thinks it is
> > trying to place a virtexII.  I tried reading an FNF from a 3.3 design, that gets
>
> I haven't seen this, but I did notice another problem; I placed some RPMs
> (RLOCs in VHDL) with the Floorplanner, for a Virtex-II, and in the UCF
> file created, the X and Y co-ordinates were swapped!
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

--
--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: 39563
Subject: Re: Altera's new family Stratix
From: "jakab tanko" <jtanko@ics-ltd.com>
Date: Wed, 13 Feb 2002 09:08:42 -0500
Links: << >>  << T >>  << A >>
Just to add to the international flavor of this thread:
Some Hungarian:
Altera nyomaba se lephet Xilinxnek, legalab ket evvel vannak lemaradva!
Some Romanian:
Viata e frumoasa...Altera are DSP!
:-)
Have fun translating it,
jakab

Austin Lesea <austin.lesea@xilinx.com> wrote in message
news:3C6990D5.28C06D67@xilinx.com...
> "Kunde passen auf."
>
> Oder wie sie sagen in Rom:
>
> Caveat Emptor.
>
> Austin
>
> (Ich kann Deutschen lesen, Danke)
>
> (But excuse my written German, as I am not up to the colloquialisms or
> the venarcular)
>
>
> ls_user wrote:
>
> > Austin: Konkurrenz belebt das Geschaeft.
> >
> > Please ask Peter for translation.
> >
> > regards
> >
> > The Amateur
>



Article: 39564
Subject: Re: Making Altera development quicker
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 14:13:26 GMT
Links: << >>  << T >>  << A >>
I do that occasionally.  I have a single processor PIII 833 here that is also loaded up with
RAM.  I use it if I have more than one PAR going at a time, or if I expect to be running some
serious sims at the same time as a PAR.  It is a little awkward for applications that have
license keys because there is that dongle swapping bit, and there is also the issue of copying
projects back and forth.  It is painful enough that I consider it a last resort (plus it means
getting off my fat duff to move back and forth between machines, the other one is in a
different room so others can use it when I am not without disturbing me).

newman wrote:

> A fast dual processor is great to have.  I used a 800 MHz dual PIII,
> and while one processor was pegged doing a Place and Route,  I was
> able to listen to MP3 tunes and surf the net using the other
> processor, without a single glitch heard from the MP3 player! :)
>
> But speaking on the single threaded aspect of a lot of EDA software,
> last I looked, dual processor clock speeds tend to lag behind single
> processor clock speeds, and I think I am better off buying a
> reasonably priced single processor computer every year, and use one of
> those keyboard/mouse/video switch boxes to do other things on the old
> computer while doing a place and route on my greatest and newest
> computer.  This strategy also allowed me to justify the purchase of an
> AMD XP system, which made me happy because I own AMD stock.
>
> Newman

--
--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: 39565
Subject: Re: Foundation 4.1 vs. ISE 4.1?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 13 Feb 2002 14:14:59 GMT
Links: << >>  << T >>  << A >>
Based on experience (see the par and carry chains not... thread), I'd stick with
3.3 unless you are doing a virtexII design.

Noddy wrote:

> Hi,
>
> Am busy working on a project using Foundation 3.3i, so am hesitant to do any
> software upgrades until the project is complete. I am thus sitting with the
> Xilinx upgrade pack, which Xilinx kindly posted to me, that contains
> software for Foundation 4.1 and ISE 4.1.
> Could someone please give a quick comparison? Which should I be using? Does
> Xilinx see a need for its customers to upgrade to Foundation 4.1 while it is
> trying to market ISE 4.1?
>
> Sorry if this question seems a bit trivial/newbie-ish, but I learn
> everything about FPGA's from this newsgroup.
>
> cheers
>
> adrian

--
--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: 39566
Subject: Is Leonardo spectrum OEM version for Altera limited?
From: "Leon de Boer" <ldeboer@iprimus.com.au>
Date: Wed, 13 Feb 2002 14:27:06 GMT
Links: << >>  << T >>  << A >>
I have found while using Leonardo spectrum and Baseline for an Altera design
that when I get to 10-15K gates the design leaves bits out of the synthesis.
I have had this sort of behaviour with Actel licenses where they have a gate
limit. I can't seem to get anyone at Altera or exemplar to be able to tell
me absolutely if the free baseline, Leonardo version is gate limited. Does
anyone know?

Regards Leon




Article: 39567
Subject: Re: Altera's new family Stratix
From: jpbaudens@wavesat.com (gyp)
Date: 13 Feb 2002 06:38:32 -0800
Links: << >>  << T >>  << A >>
The availability is for June in Europe (I don't know for North America
but I think it is going to be at the same period).
So be patient and keep on using Xilinx'stuff!

Article: 39568
Subject: Re: Altera's new family Stratix
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 13 Feb 2002 08:10:34 -0800
Links: << >>  << T >>  << A >>
'life is good', and 'something about how Altera is now behind schedule'?

Austin

(my father was from Sibu, Romania, and spoke 7 languages.  I did not inherit
much of his talents, I am afraid)



jakab tanko wrote:

> Just to add to the international flavor of this thread:
> Some Hungarian:
> Altera nyomaba se lephet Xilinxnek, legalab ket evvel vannak lemaradva!
> Some Romanian:
> Viata e frumoasa...Altera are DSP!
> :-)
> Have fun translating it,
> jakab
>
> Austin Lesea <austin.lesea@xilinx.com> wrote in message
> news:3C6990D5.28C06D67@xilinx.com...
> > "Kunde passen auf."
> >
> > Oder wie sie sagen in Rom:
> >
> > Caveat Emptor.
> >
> > Austin
> >
> > (Ich kann Deutschen lesen, Danke)
> >
> > (But excuse my written German, as I am not up to the colloquialisms or
> > the venarcular)
> >
> >
> > ls_user wrote:
> >
> > > Austin: Konkurrenz belebt das Geschaeft.
> > >
> > > Please ask Peter for translation.
> > >
> > > regards
> > >
> > > The Amateur
> >


Article: 39569
Subject: Re: CLKDLL doesn't work without BUFG ?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 13 Feb 2002 08:17:42 -0800
Links: << >>  << T >>  << A >>
Jeremy,

The DLL requires a BUFG for the best performance.  If you use local interconect for the CLKFB and CLK0 routing, the duty cycle won't be nearly as good as using BUFG.

BUT, it won't we quite as bad as you are describing.  It may be that your IO is not strong enough to faithfully reproduce what is happening inside the FPGA.

A good experiment to perform, is to come in on a pin, and then go out on the adjacent pin.  The duty cycle distortion you measure there will be pretty small.  Then route through a  lot
of local interconnect to see the difference.  Then put in a DLL.  etc. etc.

If you don't want to use the recommended resources, then you have to become familiar with the performance of less perfect ways of doing the job.

The other issue may be that the DLL isn't LOCKED.  Always check the LOCKED pin, and try resetting the DLL to see if it suddenly becomes 50/50 duty cycle.  WHen clock sources start up,
they sometimes exceed the drift or jitter specs of the DLL, and you need to reset again to be sure everything is locked and running.

Austin



jeremy wrote:

> I want to use a CLKDLL without BUFG with a 33% duty-cycle clock. I have the good Duty Cycle Correction Property in the DLL, but I have the same duty-cycle after and before the DLL.


Article: 39570
Subject: Re: Pseudorandom Bitstream
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 13 Feb 2002 09:07:25 -0800
Links: << >>  << T >>  << A >>
Achim Gratz wrote:
 
> Not fully. I get errors for constructs like:
> 
> unsigned_signal <= 0;      
> -- compiler wants bitstring for literal

numeric_std only covers numeric operations +,-,abs,< etc.
between ints and unsigned vectors.
Assignments are not overloaded, so
the left and right sides must be the same type.

> unsigned_signal <= unsigned(0);
> -- compiler: can not be converted to unsigned

unsigned cast only works on vectors.
numeric_std provides a to_unsigned(length,vec) function
for this case.

> These must have a simple solution, as for instance
> 
> unsigned_signal <= unsigned_signal*0; 
> -- works like a charm

This works because numeric_std overloads 
the function "*" to return an unsigned vector.

It's not much more work to say:
 unsigned_signal <= (unsigned_signal'range => '0');
 -- works like a charm and intent is clear.

 -- Mike Treseler

Article: 39571
Subject: Re: Is Leonardo spectrum OEM version for Altera limited?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 13 Feb 2002 09:28:10 -0800
Links: << >>  << T >>  << A >>
Leon de Boer wrote:
> 
> I have found while using Leonardo spectrum and Baseline for an Altera design
> that when I get to 10-15K gates the design leaves bits out of the synthesis.
> I have had this sort of behaviour with Actel licenses where they have a gate
> limit. I can't seem to get anyone at Altera or exemplar to be able to tell
> me absolutely if the free baseline, Leonardo version is gate limited. 

They are separate releases so it's reasonable to
asuume that the bug set is also different.

Since the full version costs big bucks, it's
also reasonable to assume that something
is left out of the Altera-oem version.

One thing the Altera version does have
is support for both VHDL and Verilog
in the same design. This is a high-cost
option in the full version of leo.

 -- Mike Treseler

Article: 39572
Subject: Re: Xilinx ISE 3.3 upgrade to 4.1
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 13 Feb 2002 17:33:43 +0000
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> The Virtex-E speed files are still changing. The 4.1i service pack 3
> release has v1.65 of the Virtex-E speed files, and there's some more
> slow downs in those (CLB RAM setup time, from memory). A previous
> version slowed down some block RAM control inputs. The 3.3 service
> pack 8 speed files doubled the block RAM clock-to-out delay.
>
>

Is it possible to use 4.1i speed files when building with 3.3i ? e.g. for an
XCV600E I could just copy over the %XILINX%/virtexe/data/v600e.spd from my 4.1i
installation to my 3.3i one ?





Article: 39573
Subject: Re: Help on bus interface needed.
From: kayrock66@yahoo.com (Jay)
Date: 13 Feb 2002 10:06:23 -0800
Links: << >>  << T >>  << A >>
Weren't you originally going to run your external memory interface at
1/2 the uP clock?  If so, then that div2 output is PERFECT to clock
your FPGA.  But either way, using that clock output from the uP is
really a much better solution than trying to design a fully bullet
proof asynch interface with its associated delay and complexity.  The
Spartan DLL can be used to de-skew the 2 clock domains and you should
have it made in the shade.

Regards


Richard Meester <rme@quest-innovations.com> wrote in message news:<3C6A1628.2BBC50FA@quest-innovations.com>...
> Hi Jay,
> 
> Why is it not possible, to me these look like two asynchronous systems?
> 
> We have another option. The PLL puts out div2 or div4 or div8 clock i.e. 50Mhz clock, we could feed this clock into a spartanII
> dll which puts out a times2/4/8 clock to get it to 100Mhz. Do you think this will work?
> 
> Thanks,
> 
> Richard
> 
> Jay wrote:
> 
> > Wow, thats a messy clock scheme.  I think you're either going to have
> > to find a way to get the high frequency output of the uP PLL onto your
> > PCB or find a way to bypass the PLL altogether on your uP and feed in
> > an external clock.  The clocking scheme you have described does not
> > seem to be realizable by conventional digital techniques.
> >
> > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C69673E.14128675@quest-innovations.com>...
> > > Hi Jay,
> > >
> > > Jay wrote:
> > >
> > > > If all your clocks are derived from the same reference and phase
> > > > locked then your do not need to worry about metastability other than
> > > > the conventional set-up and hold requirements required of your
> > > > receiving flip flops common to all standard synchronous designs.  Be
> > > > aware that the static timing checks done by typical FPGA tools do not
> > > > handle multi-clock relationships very well, but a timing back
> > > > annotated gate level sim should give you meaningful checks.
> > > >
> > > > To say it another way, you do not need to do the cascaded flip flip
> > > > thing that you would do when you have signals coming in from an
> > > > ASYNCHRONOUS clock domain.
> > > >
> > >
> > > The FPGA is not driven by the same clock that drives the CPU, the CPU has an external 10 Mhz and an internal PLL, the FPGA
> > > has an external 100Mhz clock, or a 10Mhz clock and uses the spartanII dll's. Having said this it seems that the signals doe
> > > come from an asynchronous clock domain right?
> > >
> > > Since my design is pipelined can i see this pipeline as the cascaded flip flop thing if i check the signals at the end of
> > > my pipe?
> > >
> > > Thanks.
> > >
> > > Richard
> > >
> > > >
> > > > Regards
> > > >
> > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C68C144.A80A47AE@quest-innovations.com>...
> > > > > Hi Jay,
> > > > >
> > > > > Yes, we have an external CPU and external memory. We develop the FPGA to be a DMA controller and some more activity.
> > > > > We have internal registers inside the FPGA which need to be addressed as a memory device. After this the FPGA can
> > > > > become bus master.
> > > > >
> > > > > What i have done now is that i clock the FPGA at 100Mhz, scan the lines and check for the appropriate signals and go
> > > > > from there. I have 4 clock cycles at 100Mhz at the moment, but in future will advance to 2 clock cycles to respond.
> > > > > Once the FPGA becomes a bus-master i add a pipeline stage which will allow 1 clock cycle addresses and delayed data
> > > > > lines when it comes to a read. Also bus turnaround will have a 4 cycle latency. I will transfer chunks of 16/32 words
> > > > > so the benefit of the pipeline is definately there. Now my problem is do i need to synchronize and concern about
> > > > > metastability on the incomming lines when the FPGA is a memory device for the external processor?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Richard
> > > > >
> > > > > Jay wrote:
> > > > >
> > > > > > I think I misunderstood your configuration.  Do you have a uP chip
> > > > > > that you've purchased talking to your FPGA as a memory device?
> > > > > >
> > > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C64E594.9060200@quest-innovations.com>...
> > > > > > > Hi Jay,
> > > > > > > Thanks for the response,
> > > > > > >
> > > > > > > Jay wrote:
> > > > > > >
> > > > > > > > I'm going to make some assumptions because I'm not sure if I
> > > > > > > > understand your description, correct me if I'm wrong.
> > > > > > > >
> > > > > > > > Like you suggested, go ahead and run your internal processor at twice
> > > > > > > > the external interface.  Enable the data capture and data launch flops
> > > > > > > > on every other clock.  Clock every flip/flop in your design on the
> > > > > > > > higher 2X clock.
> > > > > > >
> > > > > > >
> > > > > > > What do you meen by every other clock, clock the lines, and than wait
> > > > > > > one clock, and then clock again for the next complete cycle?
> > > > > > >
> > > > > > > Don't i have a metastability problem with the asynchronous read/write/cs
> > > > > > > lines
> > > > > > >
> > > > > > > the problem is that the signal below is i.e. the r/w signal. it is
> > > > > > > asynchronous. if i sample this at twice the frequency i will at
> > > > > > > somepoint get the correct valie that i need to trigger on.
> > > > > > >
> > > > > > > ---\________/------
> > > > > > >
> > > > > > >       ^     ^        samples at one of these points at 100 Mhz.
> > > > > > >           ^ DATA must be stable at this point
> > > > > > >
> > > > > > > However i need to have the data stable before the rising edge of this
> > > > > > > signal, which is one clock cycle wide @ 100 Mhz. so i have one clock
> > > > > > > cycle to put the data on the bus.
> > > > > > > I see how to design this, but i am worried about metastability on the
> > > > > > > asynchronous lines. If i need to take care of this i need to add 2 flops
> > > > > > > behind it, and after that start making the data available. Overall this
> > > > > > > will take me at least 3 clock cycles.
> > > > > > >
> > > > > > >
> > > > > > > Richard
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Don't try to have a 66MHz mem interface and 100MHz internal clock.
> > > > > > > > Maintain that 2/1 ratio.  Run the memory at 50 and the processor at
> > > > > > > > 100 or run the memory at 66, and run the processor at 133MHz.  Your
> > > > > > > > life will be much easier.
> > > > > > > >
> > > > > > > > Hope this help,
> > > > > > > > Regards
> > > > > > > > Richard Meester <rme@quest-innovations.com> wrote in message news:<3C63F9C2.6CBF3BE7@quest-innovations.com>...
> > > > > > > >
> > > > > > > >>Hi All,
> > > > > > > >>
> > > > > > > >>I have some problems finding a good design practice for a bus-interface.
> > > > > > > >>
> > > > > > > >>We have a processor running internally at 100Mhz, and externally at
> > > > > > > >>50Mhz (2 internal bus cycles used for 1 complete external bus cycle).
> > > > > > > >>Now the addresses are set, the cs lines are set, the re_n and we_n
> > > > > > > >>signals are set and the data is set or read. I know all the timing
> > > > > > > >>variables on these lines.
> > > > > > > >>
> > > > > > > >>Now i need to design a bus interface, but i want the internal clock to
> > > > > > > >>run at least at 66 Mhz because i need to access ram at this speed and
> > > > > > > >>want to keep the internal clock speeds at the same speed.
> > > > > > > >>
> > > > > > > >>Now how can i best trigger my internal signals, the we_n line goes
> > > > > > > >>active low after 8 nsecs of valid data, should i use this signal and
> > > > > > > >>feed it into a fflop to trigger on, or should i let the flop trigger at
> > > > > > > >>the internal clock speed and detect that the line has changed state and
> > > > > > > >>take action from there, or should i make the desing completely
> > > > > > > >>combinatorial?
> > > > > > > >>
> > > > > > > >>Thanks in advance,
> > > > > > > >>
> > > > > > > >>Richard
> > > > > > > >>

Article: 39574
Subject: Re: Newbie SpartanII Block Ram question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 13 Feb 2002 21:09:23 +0100
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag
news:3C698327.2923A1E2@mail.com...
> Requirement:  two sets of 8 memories, 265x8bits.
>
> The eight 4096 bit rams can be configured as two sets of four RAMs
configured
> as 2048x2 bits allowing the memory bank select (3 bits) and the address (8
> bits) to give the 2084 addresses in this configuration.
>
> No muxing required.

Uuups, I forgot that. You are right.

--
MfG
Falk







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