Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 30575

Article: 30575
Subject: Re: Download Cable Mystery Solved
From: Greg Neff <gregeneff@yahoo.com>
Date: Tue, 17 Apr 2001 16:40:50 -0400
Links: << >>  << T >>  << A >>
On Tue, 17 Apr 2001 19:10:01 +0200, Kolja Sulimma
<kolja@prowokulta.org> wrote:

(snip)
>Here is the schematic of the xilinx parallel download cable.
>http://toolbox.xilinx.com/docsan/3_1i/data/common/hug/chap01/hug01007.htm
>
>It has never been very reliable.
>It has been reported that some combinations of cables, mainboards and
>parallel board settings did not work.
>Also dongles and long cables have been a problem.
>
(snip)

We have built the equivalent of the Xilinx parallel cable into a
couple of manufacturing test fixtures.  We experienced problems with
reliability that you described.  

The main problem that we found is that there are glitches on the
signal edges, including the clock signal.  This is hardly a surprise,
since the parallel port signals have slow edge times, are noisy, and
are being buffered by 74HC125 that have no input hysteresis.  

As a quick fix we put a 470pF cap from the clock signal (pin 3 on the
D connector) to ground.  This cleaned up the noise and eliminated the
extra transitions on the CCLK/TCK signal.  In the future we will add a
Schmitt trigger to the clock input.


===================================
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Article: 30576
Subject: Re: compression
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 18 Apr 2001 09:21:47 +1200
Links: << >>  << T >>  << A >>
Frode Vatvedt Fjeld wrote:
> 
> I'm interested in encoding and decoding of variable bit-length
> codewords (as typically used in (de)compression applications) using
> PLDs. Does anyone have any pointers to information on this subject?
> 
> Thanks,
> --
> Frode Vatvedt Fjeld

 We are doing work on Run-Length compression using CPLD, for
two areas

- Increasing apparent bandwidth 
- Reducing storage requirements

What do you want to know ?

-- 
======= 80x51 Tools & PLD IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 30577
Subject: Re: Clean Frequency Division
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 17 Apr 2001 15:23:11 -0700
Links: << >>  << T >>  << A >>


VR wrote:

> Hello.
>
> I am interested in some tried and true methods to do divide a square wave
> of a given frequency by an integer n -- the duty cycle in this case does
> not have to be 50% but 50% solutions are interesting too.
>
> However the Altera simulator results show there is a decent amount of skew
> between the clock rising edge and my output rising edge(6 ns for a fast
> CPLD). I was looking for something that might work for both CPLDs and
> FPGAs, but obviously one could make clever use of look-up tables and such.
>
>

The fastest reponse would be from a flip-flop directly triggered by your clock
input. But even that will always take a few ns to get off-chip, and there is no
solution to that problem, except a DLL or PLL, and they have their own
idiosyncracies...
The popular method is to count down towards zero. You camouflage the output
decoder delay by decoding one state early and resynchronizing to the incoming
clock. That might give you a problem in the most extreme case of dividing by 2,
but it woeks great for larger numbers.

Inside an FPGA, you can use the dedicated carry and thus work with clock rates
up to several hundred MHz.  Why do you want to go off-chip?

Peter Alfke, Xilinx Applications



Article: 30578
Subject: Re: Getting license for Modelsim in Xilinx webpack?
From: Jean-Marie Bussat <JMBussat@lbl.gov>
Date: Tue, 17 Apr 2001 16:52:25 -0700
Links: << >>  << T >>  << A >>

Hi,

I had the same problem. It seems that their e-mail "robot" is
not working as announced. I had to install webpack on a computer
not connected to the internet.

Finally, when I saw that things were working fine from a connected
computer, I took the web address generated when you click on
"submit license request" from windows start menu. The address
should be like the following

http://www.xilinx.com/cgi-bin/mxe_license.cgi?pr=STARTER&key=ea&$%ff%12ei=<modelsim_number>&<your_hardware_address>&hn=<your_hostname>&ds=<your_disk_serial_number>&in=<your_ethernet_address>&

This will bring you a window where you will have to enter some
registration information. You will then receive the license
file at the e-mail address you gave.

To get the web address, you need at least an internet browser
even if you are not connected (this shouldn't be a problem
since you are under Windows). It will complain about not being
able to reach the server but you will see the address (in some
cases, you may have to reload the page to see the address).

Once you have the address, you just have to find a way to
copy it without making mistakes on your unix web browser.

Hope this helps,

Jean-Marie

-- 
  _______________________________________
 |                                       | 
 | Jean-Marie Bussat                     |
 | Lawrence Berkeley National Laboratory |
 | 1 Cyclotron Road - MS 50A-6134        |
 | BERKELEY, CA 94720 - USA              |
 | Email: JMBussat@lbl.gov               |
 | Phone: (510)-486-5687                 |
 | Fax:   (510)-486-5977                 |
 |_______________________________________|

Article: 30579
Subject: Re: Clean Frequency Division
From: V R <vvrrvrr@rrvvrrvvrrvvrrrvvvv.com>
Date: Wed, 18 Apr 2001 02:22:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thanks for the response Peter.

Peter A.
<wedon'tdontspamthosewhohelpus_peter.alastnamegoeshere@xilinx.com> wrote:

> The popular method is to count down towards zero. You camouflage the output
> decoder delay by decoding one state early and resynchronizing to the incoming
> clock. That might give you a problem in the most extreme case of dividing by
> 2, but it woeks great for larger numbers.

Actually, I thought of that one too and tried it. My skew was worse! 6.1ns
with a decode @ 1 and resynched as opposed to 6ns with no re-synching and
decoding at 0(ok, so it wasn't that much worse)(I'm dividing by 12160). I
suspect this has to do with the counter architecture & decoding; I took a
regular 14-bit LPM_COUNTER, set it to count up, and looked at the Q
outputs. I saw a skew of 3ns between any counter bit change at the rising
edge of the clock(auto-targeted for a MAX7K CPLD). 3ns for a decoder isn't
an obnormally high delay, so 6ns does make sense. How do Xilinx FPGAs and
CPLDs compare for a simliar exercises?

> Inside an FPGA, you can use the dedicated carry and thus work with clock 
> rates up to several hundred MHz.  Why do you want to go off-chip?

I'm not sure I understand. Are you asking why would I want to take my
divided outputs and use them externally? Or suggesting using this
scheme[down counter to divide clocks] on chip works because we can clock
counters fast?

Thanks,
VR.

Article: 30580
Subject: Re: Getting license for Modelsim in Xilinx webpack?
From: Rick Collins <spamgoeshere4@yahoo.com>
Date: Wed, 18 Apr 2001 00:28:20 -0400
Links: << >>  << T >>  << A >>
How about the Modelsim from Altera? I want to run some simulations and I
can't get that to work. I don't even see anything on how to get a
license file. 



Jean-Marie Bussat wrote:
> 
> Hi,
> 
> I had the same problem. It seems that their e-mail "robot" is
> not working as announced. I had to install webpack on a computer
> not connected to the internet.
> 
> Finally, when I saw that things were working fine from a connected
> computer, I took the web address generated when you click on
> "submit license request" from windows start menu. The address
> should be like the following
> 
> http://www.xilinx.com/cgi-bin/mxe_license.cgi?pr=STARTER&key=ea&$%ff%12ei=<modelsim_number>&<your_hardware_address>&hn=<your_hostname>&ds=<your_disk_serial_number>&in=<your_ethernet_address>&
> 
> This will bring you a window where you will have to enter some
> registration information. You will then receive the license
> file at the e-mail address you gave.
> 
> To get the web address, you need at least an internet browser
> even if you are not connected (this shouldn't be a problem
> since you are under Windows). It will complain about not being
> able to reach the server but you will see the address (in some
> cases, you may have to reload the page to see the address).
> 
> Once you have the address, you just have to find a way to
> copy it without making mistakes on your unix web browser.
> 
> Hope this helps,
> 
> Jean-Marie
> 
> --
>   _______________________________________
>  |                                       |
>  | Jean-Marie Bussat                     |
>  | Lawrence Berkeley National Laboratory |
>  | 1 Cyclotron Road - MS 50A-6134        |
>  | BERKELEY, CA 94720 - USA              |
>  | Email: JMBussat@lbl.gov               |
>  | Phone: (510)-486-5687                 |
>  | Fax:   (510)-486-5977                 |
>  |_______________________________________|


-- 

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: 30581
Subject: PAR single pass vs multi-pass differences
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Wed, 18 Apr 2001 14:54:39 +1000
Links: << >>  << T >>  << A >>
Hi,

I'm routing a Virtex-E part, and I find that I get different routing
results for a particular cost table depending on whether I use single
pass or multi pass (the -n MPPR option) on par.

E.g. for my current design, on cost table #1, I get a 5.830ns result
with single pass, but 5.925ns with multi pass, also using cost table #1.

Question: what does par do differently, so that it gets different
results even though the cost table is the same?

Which result should I believe?

BTW, the 5.925ns route (MPPR) works when downloaded, and the 5.830ns
(SPPR) one doesn't.

I'm using Alliance Release 3.3.07i (par D.26), with speed files ver
1.56, but I've also seen this issue on other versions.

I've read Xilinx answer 8746, which describes a bug with similar
symptoms, but it says that it was fixed in version 3.1i about a year
ago.
It also says "Each MPPR result should be identical to an equivalent
single pass result for the same cost table."

TIA,
Allan.

Article: 30582
Subject: Re: Clean Frequency Division
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 18 Apr 2001 05:30:16 GMT
Links: << >>  << T >>  << A >>


V R wrote:

> Thanks for the response Peter.
>

If you want to get an output after N clock pulses, you either preload a counter to
N and coun down, or you reset a counter and detect code N ( or N-1 )
The decoder has a certain delay, and if you use the decoder to drive the output,
you get the counter flip-flop delay plus the decoder delay plus the output delay.
By pre-decoding and resynchronizing you eliminate the decoder delay. That's all.

If you really only have to perform such a trivial function and then drive the
outside world, 4 to 6 ns is not so bad, 3 ns may be possible with the fastest
devices.
If, however, you can keep the output inside the FPGA chip to do further work, then
it might be available 1 ns after the internal clock, ready to do further work.

Peter Alfke


Article: 30583
Subject: testing
From: Fredrik Theander <fredrik.theander@emw.ericsson.se>
Date: Wed, 18 Apr 2001 07:35:03 +0200
Links: << >>  << T >>  << A >>
 

Article: 30584
Subject: Re: XC9500XL Internal Noise Immunity
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 18 Apr 2001 05:42:17 GMT
Links: << >>  << T >>  << A >>
Here is a wild guess:
The latch outputs follow the D input whenever the latch is enabled. So if
you have noise on D, it will reflect on Q whenever enabled.
If you use a flip-flop, the master latch inside the flip-flop behaves the
same way, but you don't see it. You only see on Q, the slave output, a
snapshot of the final data in the master latch, right before the end of
the latch enable = rising edge of the clock.

So, noise disturbs at Q only when it occurs right before the rising clock
edge. All other noise is supressed.
(This assumes a clean clock)

Hope I did not offend anybody with such a basic explanation.

Peter Alfke
====================
Greg Neff wrote:

> We just completed a prototype design using an XC95144XL-7TQ144C.  This
> device provides glue logic for three processors, all of which are
> asynchronous to each other.  Included in the design was an 8-bit latch
> for the address LSB of one of the processors.  We found that this
> latch was being corrupted at the point in time when a group of address
> lines from one of the other processors transitioned.  As a work
> around, when we changed the LD8 to an FD8 the problem went away.
>
> All signals entering the CPLD are glitch free.  The CPLD is sitting on
> a liberally decoupled set of power and ground planes.
>
> We have done many high-speed logic designs with Xilinx FPGAs and
> CPLDs, and we have never experienced a problem like this before.
>
> Has anyone else experienced apparent internal noise sensitivity
> problems like this with XC9500XL CPLDs?
>
> ===================================
> Greg Neff
> VP Engineering
> *Microsym* Computers Inc.
> greg@guesswhichwordgoeshere.com


Article: 30585
Subject: Re: Download Cable Mystery Solved
From: Eric <erv_NoSpam@sympatico.ca>
Date: Wed, 18 Apr 2001 07:12:39 GMT
Links: << >>  << T >>  << A >>
Hi,

I also had similar problems with a custom made passive parallel port cable
(for serial slave Spartan, but should apply to all Xilinx FPGAs).
Problem was not software related (as with the problem you discovered), but
with crosstalk and noise in the cable itself.

Sometimes it did not configure the FPGA at all, sometimes the FPGA
stopped working for no apparent reason at random times.

As in your case, it happened only with certain motherboards, cable length
and moon phase (well, almost).

I started by inserting "quiet" ( "0" during config) port signals interleaved
with active ones and using a flat cable (twisted pairs cable with grounded
returns would also work).

CCLK / DIN crosstalk improved a lot and it nearly solved the problem
with short cables, but still hanged with longer ones.

The problem disappeared when I added  a 1K resistor in serie on the
"PROGRAM" pin, and a 2.2 nf to Ground (both on the FPGA board).

Crosstalk between signals and PROGRAM pin caused short glitches
that restarted the configuration sequence, either during programming
itself or while the application was using the interface.
Glitches (that are way shorter than the RC delay) are completely eliminated .

It now reliably works with 30 feet cables with nearly all ports (including
laptops if port is slowed down a bit).

When possible, buffering the lines using 74xx14 Schmitt triggers close to the
FPGA should be even better (but was not practical for my app).

hope this helps.

Eric.





Article: 30586
Subject: FPGAs & Combinatorial Chew
From: V R <havingtelemarketersisbad@enoughsowhydoweneedmoreidiots.com>
Date: Wed, 18 Apr 2001 07:14:07 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello.

I am working on a project that targets an Altera 10K10LC84-4. My design
consists of a many simple blocks; each block has three 8-bit registers
which drive the D-inputs of three 8-bit counters. Also in the small block
is a 2x4 decoder that drives enables for each 8-bit register. So the block
=~ three 8-bit counters + three 8-bit registers + one 2x4 decoder.

When I compiled my sub-block for an Altera CPLD, it ate 50 LCELLs. When
this same design was targeted for the above stated FPGA, 80 LCELLs were
eaten. After looking at the synthesis + P&R results from Max+Plus II, I
saw that each gate(AND2, OR2, etc) of the decoder structure chewed up one
LCELL each, thus accounting for more LCELLs.

The bad part is that this sub-block was replicated 6 times in a higher
level design -- that means what would have chewed up 300 LCELLs in a CPLD
took up 480 LCELLs in the 10K10. The reality is that the 10K10 has 576
LCELLs, so my part was pretty full with a relatively "simple" design.

The question is then what techniques can I use to avoid the penalty of a
simple 2x4 decoder/basic asynchronous logic(eating LCELLs)? Should I
instantiate a ROM or a LUT and load my 2x4 data there? The 10K10 has three
EABs which each have 2048 bits of RAM, should I make use of these?

I would like to try this design in a Xilinx part too, but I did my design
in Altera schematics, so I doubt without a lot of effort I could make a
similar comparison(i.e. schematics to EDIF, etc). Yes, I do know VHDL, but
my development time for this was relatively small compared to what it
would have taken with(me) VHDL so(please no VHDL would have been better
comments)...

Thanks!
VR.

Article: 30587
Subject: MICRO-34 Call for Papers
From: "Dan Connors" <dconnors@colorado.edu>
Date: Wed, 18 Apr 2001 01:14:29 -0600
Links: << >>  << T >>  << A >>

---------------------------------------------------------------------
                    MICRO-34  Call for Papers

      The 34th International Symposium on Microarchitecture

                   Austin, Texas, Dec. 1-5 2001
---------------------------------------------------------------------

IMPORTANT DEADLINES:

  Paper submission:               June 15, 2001
  One-week extension              June 22 (Midnight EST, USA), 2001
  Workshop/Tutorial Proposals:    June 15, 2001
  Author Notification:            August 13, 2001


The International Symposium on Microarchitecture continues to be the
premier technical forum for presenting the latest developments in
microarchitecture research.  The 34th Microarchitecture (MICRO-34)
Symposium will be held in Austin, Texas from Dec. 1 to Dec. 5, 2001.
Authors are invited to submit full papers on microarchitecture
research and related topics.

Areas of interest include:

 * ILP architectures and designs: Superscalar, VLIW, EPIC
 * Compiler techniques for instruction-level parallelism
 * Multithreaded processors and compilation
 * Architectures and compilers for embedded processors
   (imaging, graphics, speech recognition, low power, etc.)
 * Dynamic optimization, emulation, and code translation
 * Advanced software and hardware speculation and prediction
 * Hardware/compiler techniques for improving memory performance
 * Hardware/software techniques for efficient SOC designs
 * Hardware/software techniques for fine-grain parallel processing


You will find all information related to the conference at the
official MICRO-34 web site:

        http://www.microarch.org/micro34

SUBMISSION INFORMATION:

Please check the Micro-34 web site for upcoming paper submission
procedures.  Paper submissions should not exceed 6,000 words. Papers
that exceed the length limit may not be reviewed. The official
submission receipt deadline is June 15, 2001.  An automatic extension
of one week, until June 22, 2001 (Midnight EST, USA) will be given
without request.  However, no further extensions will be given. Papers
may be submitted for blind review at the option of the authors. Please
indicate whether the paper is a student paper for best student paper
nominations.


WORKSHOP INFORMATION:

The MICRO-34 symposium is currently taking Workshop/Tutorial
proposals.  Information on workshop/tutorial proposals can be found at
the Micro-34 web site:

        http://www.microarch.org/micro34/Workshops/


       MICRO-34 Call For Workshop/Tutorial Proposals
               Dec 1-2, 2001, Austin, TX
       --------------------------------------------

Due the popularity and success of the workshops/tutorials at last
years MICRO, this year at MICRO-34 we are planning to expand from 1
day to 2 days of pre-conference workshops and tutorials.  They will
take place in Austin, TX on Saturday and Sunday, Dec 1 and 2, 2001
before the main conference on Dec 3-5, 2001.

Last year, there were 4 workshops and 1 tutorial:
    o 3rd ACM Workshop on Feedback Directed and Dynamic Optimization
    o 2nd Workshop on Media Processors and DSPs
    o Workshop on Multithreaded Execution, Architecture and Compilation
    o Kool Chips Workshop
    o Tutorial on Dynamic Binary Translation and Optimization

With the expansion to 2 days, we invite proposals from those
interested in organizing a new tutorial or workshop to be held in
conjunction with the conference.  They may be either a half day or a
full day.  The range of interesting topics includes most areas of
computer architecture, microarchitecture, and compilers, but use the
MICRO-34 call for papers as a rough guide.  While we are especially
interested in complementing the existing workshops with new tutorials
of interest to the MICRO community, we will also consider proposals
for new workshops.

Those who are interested in submitting a proposal, please send email
to the workshop/tutorial chair (Scott Mahlke, mahlke@hpl.hp.com).  The
proposal should include:

    o Title
    o Short description or abstract
    o List of organizers
    o Contact name, email address, and telephone number
    o Preferred length (half or full day)

Submission deadline is June 15, 2001.  Note that there is a limited
amount of time/space and we hope to devise a broad program of interest
to the MICRO community, so the number of accepted proposals will
depend on these issues.


GENERAL INFORMATION:

      GENERAL CHAIR
         Yale Patt,  University of Texas at Austin

      PROGRAM CHAIRS
         Josh Fisher, HP Labs
         Paolo Faraboschi, HP Labs

      WORKSHOP CHAIR
         Scott Mahlke, HP Labs

      LOCAL ARRANGEMENTS
         Steve Keckler, University of Texas at Austin

      PUBLICITY CHAIR
         Dan Connors, University of Colorado

      PUBLICATION CHAIR
         Kevin Skadron, University of Virginia

      STEERING COMMITTEE
         Richard Belgard, Consultant, Chairman
         Tom Conte, NC State
         Kemal Ebcioglu, IBM
         Matt Farrens, UC-Davis
         Wen-mei Hwu, University of Illinois
         Yale Patt, University of Texas at Austin
         Ronny Ronen, Intel
         Mike Schlansker, HP Labs
         Andy Wolfe, SONICblue

      PROGRAM COMMITTEE CHAIR
         Saman Amarasinghe, MIT
         Krste Asanovic, MIT
         David Bernstein, IBM Israel
         Geoff Brown, Ironbridge
         Francky Catthoor, IMEC
         Bob Colwell, Intel
         Tom Conte, NCSU
         Henk Corporaal, TU Delft
         Kemal Ebcioglu, IBM
         Antonio Gonzalez, UPC
         Jim Goodman, U.Wisconsin/Intel
         Thomas Gross, ETH
         Rajiv Gupta, University of Arizona
         Wen-Mei Hwu, University of Illinois
         David Kaeli, Northeastern
         Steve Keckler, University of Texas at Austin
         Geoff Lowney, Compaq
         Bill Mangione-Smith, UCLA
         Hans Mulder, Intel
         Walid Najjar, UC at Riverside
         CJ Newburn, Intel
         Bob Rau, HP Labs
         Andre Seznec, IRISA/INRIA
         Carol Thompson, HP
         Nigel Topham, Siroyan
         Mateo Valero, UPC
         Andy Wolfe, SONICblue
         Donald Yeung, Univeristy of Maryland
         Cliff Young, Lucent Bell Labs


Thank you for your time in reading this message.

Dan Connors
Micro-34 Publicity Chair
University of Colorado, Boulder, CO
dconnors@colorado.edu





Article: 30588
Subject: clocking on both edges
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Wed, 18 Apr 2001 09:07:08 GMT
Links: << >>  << T >>  << A >>
Hi!
The main clock of a system is a 50 MHz, 50% duty cycle (+/-10%)
signal.
I have to synchronize some activities of a PLD on the rising edge
of this signal, some on falling edge and many on both edges.
For example, the data transfers occur on both edges and
I have to count it, calculate CRCs, and so on.

I'm tempted to do a little asynchronous trick inside the PLD to
make a 4-6 nS pulse for each main clock edge, and use this pulse
to clock the FFs, but I'm scared of the Peters Alfke words:
"Asynchronous design methods may ruin your project, your
career and your health". =:-/

Which alternatives there are?
Thanks in advance!

Luigi






Article: 30589
Subject: Re: compression
From: Frode Vatvedt Fjeld <frodef@acm.org>
Date: 18 Apr 2001 11:37:30 +0200
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> writes:

>  We are doing work on Run-Length compression using CPLD, for
> two areas
> 
> - Increasing apparent bandwidth 
> - Reducing storage requirements

This is exactly what I'm interested in.
 
> What do you want to know ?

I'd just like to know in general terms about the standard (if any)
techniques or "algorithms" used for implementing such things in
programmable logic.

-- 
Frode Vatvedt Fjeld

Article: 30590
Subject: Re: Getting license for Modelsim in Xilinx webpack?
From: Nial Stewart <nials@sqf.hp.com>
Date: Wed, 18 Apr 2001 10:43:30 +0100
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> How about the Modelsim from Altera? I want to run some simulations and I
> can't get that to work. I don't even see anything on how to get a
> license file.


I think the Altera version of Modelsim's only available if you
take out an Altera subscription ($2K). 


Nial.

Article: 30591
Subject: Acces of JTAG port of the FPGA (XSV Board)
From: almerima <almerima@cobalt.et.tudelft.nl>
Date: Wed, 18 Apr 2001 02:24:20 -0800
Links: << >>  << T >>  << A >>
When attempting to start ChipScope or JTAG Programmer on an XSV Board 
I get the error: 
Checking boundary-scan chain integrity...ERROR:JTag - Boundary-scan 
chain test failed at bit position '3' on instance 'testbrd_virtex 
(Device1)'. A problem may exist in the hardware configuration. Check 
that the cable, scan chain, and power connections are intact,that the 
specified scan chain configuration matches the actual hardware, and 
that the power supply is adequate and delivering the correct voltage. 
ERROR:JTag - Boundary scan chain has been improperly specified. 
Please check your configuration and re-enter the boundary-scan chain 
information. 
Boundary-scan chain validated unsuccessfully. 
ERROR:JTag - : The boundary-scan chain has not been declared 
correctly. Verify the syntax and correctness of the device BSDL 
files, correct the files, reset the cable and retry this command. 

  
I know that the Xilinx Virtex XSV Board support Boundary-scan mode. 
To use this mode I must interface to the XSV Board through the 
Xchecker port. To do this I have to reprogram the 95108CPLD. 
I have already look on page 32 of XSV V1.0 Manual and I have tried to generate the VHDL-code that route the signal through the
CPLD but this code is not working. 
Can I get some examples about this problem because at page 33 it is explained but not with an example en that is a difficulty for me.

Article: 30592
Subject: Re: PAR single pass vs multi-pass differences
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 18 Apr 2001 14:03:43 +0300
Links: << >>  << T >>  << A >>
Allan Herriman wrote:
> 
> Hi,
> 
> I'm routing a Virtex-E part, and I find that I get different routing
> results for a particular cost table depending on whether I use single
> pass or multi pass (the -n MPPR option) on par.
> 
> E.g. for my current design, on cost table #1, I get a 5.830ns result
> with single pass, but 5.925ns with multi pass, also using cost table #1.
> 
> Question: what does par do differently, so that it gets different
> results even though the cost table is the same?

  Program includes heuristic algorithms, ie. it doesn't find the optimal
  but close result. Therefore at every try it might finish with different
  result. Placer and router algorithms are NP-Complete, because P&R itself
  is NP-Complete therefore you will never find the optimal (the only one)
  result in a reasonable time, that's why program might cease operation
  after a definite threshold. Decision is non-deterministic to the user.

> Which result should I believe?

  I think each is correct.
 
> BTW, the 5.925ns route (MPPR) works when downloaded, and the 5.830ns
> (SPPR) one doesn't.

  SPPR by default must have used default cost table 1, but MPPR might
  use a different cost table.
 
> I'm using Alliance Release 3.3.07i (par D.26), with speed files ver
> 1.56, but I've also seen this issue on other versions.
> 
> I've read Xilinx answer 8746, which describes a bug with similar
> symptoms, but it says that it was fixed in version 3.1i about a year
> ago.
> It also says "Each MPPR result should be identical to an equivalent
> single pass result for the same cost table."

  We must pay attention to what it has been implied with "identical".
  Say, for example, if you get two results 4.32 ns and 3.95 ns for the
  same initial parameters (ie. cost table) then we might say the
  results for all those runs are identical in a definite percent
  region (statistically).
 
> TIA,
> Allan.

Article: 30593
Subject: Re: PAR single pass vs multi-pass differences
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 18 Apr 2001 14:08:24 +0300
Links: << >>  << T >>  << A >>

BTW, from a designer point of view, I would recommend Xilinx should
give more information what impacts for each cost table value are on
the design. It is not declared anywhere. Ie. are cost tables from 1
to 50 for speed and 51 till 1000 for area? It would have been
superb. Cost table number doesn't mean anything. Therefore it would
be the best way to run for all cost tables, ie. at least 100 runs
for each design load.

Utku

Article: 30594
Subject: gay 7019
From: xkkdkx@webnetsolutions.it
Date: 18 Apr 2001 11:26:32 GMT
Links: << >>  << T >>  << A >>
WebNet Solutions s.n.c.
una soluzione adeguata per ogni esigenza informatica
visita il nostro sito ora!!!!!
http://www.webnetsolutions.it
email: info@webnetsolutions.it
Tel/Fax +39 (0175) 257363
ejvkgrpfotimsnnqjovt


Article: 30595
Subject: ALTERA Nios software examples?
From: =?ISO-8859-1?Q?L=E4hteenm=E4ki?= Jussi <jusa@cc.tut.fi>
Date: 18 Apr 2001 12:49:20 GMT
Links: << >>  << T >>  << A >>
Im developing a Nios based system with the development kit  and although 
familiar with c-style programming, Im more of a HW designner. Thus, I 
would appreciate any web resources with Nios programming examples 
(preferably in c and c++). Thanks alot in advance.

-- 
Juza

Article: 30596
Subject: looking for comment on implementation
From: "Paul Teagle" <pteagle@chariot.net.au>
Date: Wed, 18 Apr 2001 23:21:58 +0930
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a very rough back-of-the-envelope estimate on the
feasibility of implementing a complex DDS & modulator component in a FPGA.
The relevant specs are:

- operating at 240 mega complex samples/sec

- 16 bit I & Q inputs to the modulator

- phase accumulator 32 bits

- 18 bit sine/cosine look-up accuracy, 20 bit result

- 5 bit phase dither (selectable) on lsb's

Assume the data is sourced on-chip and goes to other destinations on-chip.

A reasonable amount of pipeling can be tolerated.

We have no preference of Altera/Xilinx at the moment. SRAM based is
required, though, as is having a fair amount of other FPGA area for other
functions.

There are several other aspects of the design (interpolators, multipliers
etc) that I haven't mentioned, but its the DDS that I think is the most
complicated.

Any of you contractors out there want to hazard a rough order of magnitude
of cost for developing this sort of thing, maybe in terms of hours &
dollars, and amount of area it would consume on device XYZ ?

regards,

Paul Teagle
Systems Engineer
CAE Electronics






Article: 30597
Subject: Re: FPGAs & Combinatorial Chew
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 18 Apr 2001 07:38:32 -0700
Links: << >>  << T >>  << A >>
V R wrote:
> 
> Hello.
> 
> I am working on a project that targets an Altera 10K10LC84-4. My design
> consists of a many simple blocks; each block has three 8-bit registers
> which drive the D-inputs of three 8-bit counters. Also in the small block
> is a 2x4 decoder that drives enables for each 8-bit register. So the block
> =~ three 8-bit counters + three 8-bit registers + one 2x4 decoder.
. . .
> The question is then what techniques can I use to avoid the penalty of a
> simple 2x4 decoder/basic asynchronous logic(eating LCELLs)? 

If the register update period is uS or mS then you might
be able to use one or more shift register chains to
hold the settings. That would eliminate all or most of
the register selection.

> I would like to try this design in a Xilinx part too, but I did my design
> in Altera schematics, so I doubt without a lot of effort I could make a
> similar comparison(i.e. schematics to EDIF, etc).

I think you're right. Spend your time making it fit in a 10Kx.
It takes unhurried time to learn an HDL language and tools.

 -Mike Treseler

Article: 30598
Subject: Re: looking for comment on implementation
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 18 Apr 2001 07:42:21 -0700
Links: << >>  << T >>  << A >>
Paul,

The DDS is probably the simplest part of your design.  It is a adder followed
by a a latch, to the sine lookup table.  The look up table fits nicely in
BRAM's (intialized on configuration to be a ROM), and in Virtex II (the choice
for all of the 3 and 4 G wireless base stations), there are 8 FF's per slice,
so a 32 bit DDS takes four +  slices.  I think that with the same BRAM's,
since it is dual port, you can do the I and Q reads to get the I and Q
outputs, but I haven't really thought that through all the way.  The accuracy
seems to great for the lookup: I would look at your system budget and see if
you really need those bits as the spurious free dynamic range may be only 14
bits at best from the best A/D converters out there.  In Virtex II the 18 X 18
multipliers would be useful.

The SRL16's (serial shift registers made from the LUT's) are the favorite of
the Extreme DSP folks in Virtex, as you can make a variable length shift
register (2-128 bits long) that is very fast, and uses very little area and
resource which is useful for all kinds of DSP functions.

Also, if you don't want to start from scratch, there are cores (IP) for a lot
of what you need, as well as outside services experts, and development
methodologies:

 http://www.xilinx.com/prs_rls/xtremedsptools.htm

 http://www.xilinx.com/company/consultants/dsp.htm

 http://www.xilinx.com/prs_rls/mathworksx.htm

 http://www.xilinx.com/products/logicore/tbl_dsp.htm

In addition to the outside services we partner with (as detailed above), we
now have RF, wireless, and DSP industry experts as full time employees to
support these markets inside.

Austin

Paul Teagle wrote:

> Hi,
>
> I'm looking for a very rough back-of-the-envelope estimate on the
> feasibility of implementing a complex DDS & modulator component in a FPGA.
> The relevant specs are:
>
> - operating at 240 mega complex samples/sec
>
> - 16 bit I & Q inputs to the modulator
>
> - phase accumulator 32 bits
>
> - 18 bit sine/cosine look-up accuracy, 20 bit result
>
> - 5 bit phase dither (selectable) on lsb's
>
> Assume the data is sourced on-chip and goes to other destinations on-chip.
>
> A reasonable amount of pipeling can be tolerated.
>
> We have no preference of Altera/Xilinx at the moment. SRAM based is
> required, though, as is having a fair amount of other FPGA area for other
> functions.
>
> There are several other aspects of the design (interpolators, multipliers
> etc) that I haven't mentioned, but its the DDS that I think is the most
> complicated.
>
> Any of you contractors out there want to hazard a rough order of magnitude
> of cost for developing this sort of thing, maybe in terms of hours &
> dollars, and amount of area it would consume on device XYZ ?
>
> regards,
>
> Paul Teagle
> Systems Engineer
> CAE Electronics


Article: 30599
Subject: Re: XC9500XL Internal Noise Immunity
From: Greg Neff <gregeneff@yahoo.com>
Date: Wed, 18 Apr 2001 13:10:53 -0400
Links: << >>  << T >>  << A >>
On Wed, 18 Apr 2001 05:42:17 GMT, Peter Alfke <palfke@earthlink.net>
wrote:

>Here is a wild guess:
>The latch outputs follow the D input whenever the latch is enabled. So if
>you have noise on D, it will reflect on Q whenever enabled.
>If you use a flip-flop, the master latch inside the flip-flop behaves the
>same way, but you don't see it. You only see on Q, the slave output, a
>snapshot of the final data in the master latch, right before the end of
>the latch enable = rising edge of the clock.
>
(snip)

The corruption that I observed was while the latch enable was negated
(while the latch was in the latched state).  The latch contents were
disturbed coincident with transitions on an address bus not connected
to the latch.  Using a 2.5GS/s DSO with a 1GHz active probe at the
CPLD pin I could not detect any glitches on the latch enable input
signal.


===================================
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search