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 35375

Article: 35375
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 02 Oct 2001 02:52:22 GMT
Links: << >>  << T >>  << A >>


Ray Andraka wrote:

> The multipliers in virtexII do indeed work as a shifter, but they are quite
> slow compared to what you can do in the fabric.

If you just look at the multiplier spec, it does indeed seem slow. But that is
mainly due to the internal carry delay. Since a shifter does not have any carry
delay ( methinks ), it should be much faster than a real multiplication.
I have already asked our folks to characterize the multiplier as a shifter, but no
results yet.
I would bet that the shift delay is half the multiply delay.

Peter Alfke


Article: 35376
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Ray Andraka <ray@andraka.com>
Date: Tue, 02 Oct 2001 03:03:31 GMT
Links: << >>  << T >>  << A >>
Good point.  Of course it does depend on the exact implementation of the multiplier.
It would be interesting to see the timing results for a shift.  Thing is, doing real
world designs, we need to be able to show conclusively that it meets timing.  Since
the timing analysis uses the multiplier timing numbers, any speed gains by being 'just
a shift' would not show in the analysis anyway, so in most cases are meaningless.  If
you do characterize it for a shift, will those characterizations make it into the
speedfiles?  In order to be able to use them, I think a separate library element or
attribute would have to be used and passed into the xilinx tools so that after PAR,
the tool would know that a particular multiplier is being used only for a shift.

Peter Alfke wrote:

> Ray Andraka wrote:
>
> > The multipliers in virtexII do indeed work as a shifter, but they are quite
> > slow compared to what you can do in the fabric.
>
> If you just look at the multiplier spec, it does indeed seem slow. But that is
> mainly due to the internal carry delay. Since a shifter does not have any carry
> delay ( methinks ), it should be much faster than a real multiplication.
> I have already asked our folks to characterize the multiplier as a shifter, but no
> results yet.
> I would bet that the shift delay is half the multiply delay.
>
> Peter Alfke

--
--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: 35377
Subject: Re: future Xilinx products wish list ...
From: Eric <erv_NO_SPAM@sympatico.ca>
Date: Mon, 01 Oct 2001 23:26:15 -0400
Links: << >>  << T >>  << A >>
Hi,

John Larkin wrote:

> I commonly hang a Xilinx FPGA right on my uP's data bus, and configure
> it serially in bit-bang mode after the proccessor is up and running,
> using three parallel port pins. The FPGA config pattern data is just
> built into the processor's EPROM code. The FPGA is tristated until
> it's configured... this works fine.

Yes, it's a good way to go, but it only works if the FPGA is not part of the
processor's data / address / memory selection or management path.

My app uses a 16 bits data bus processor connected to a 8 bit Ram/Flash combo
chip (FYI, the processor is Intel 80L186EB16, the combochip is SST's 31LF041
and the FPGA is XC2S50 / XC2S100 in TQ144 package).

Since the Combomemory is much faster than the processor, I can keep the
board space / EMI / cost down by implementing a 8 / 16 bits bus translator
(properly realigns data in single byte read/writes and does 2 successive read/
writes for word accesses) in the spartan II chip that would be
transparent to the processor, and benefit from the added speed (compared to
the 8 bit external bus version of the processor) at virtually no cost
(uses very few CLBs and 11 additional IOPads).

However, there is a chicken and egg situation here since the processor can't
access it's pogram memory until the FPGA is configured, and the FPGA needs the
processor to be configured.

Same situation is also true in designs that use a SDRAM as the processor's main
memory and implement the SDRAM controller in the FPGA. In these apps (generally
32 bits), you typically need a 32 bits (or at least 16 with some of them) boot rom to
feed the processor.

A CPLD can be used to "patch" the sitution, but it's much less elegant than if
the FPGA itself could generate the address bits (and you need an expensive
Coolrunner unless loosing 20 mA to power a CPLD that's useless most of the time
is ok).

This compromise CPLD does not even save FPGA pins, since all the Flash pins must
be connected to the FPGA to allow initial flash In system Programming (programming
the boot software before memory is mounted using a device programmer with these
tiny 0.5mm lead pitch TSOP chips is asking for trouble)

In this particular design, I'll probably end up with either a XCR3032 or a PIC16C55
processor used as an address counter configuring the FPGA in parallel slave mode
but that's an inelegant quick fix that I would gladly remove in a next version if, let's
say Spartan III, includes the Master Parallel mode just like it was in the old 2000 and
3000 series.

regards,

Eric.



Article: 35378
Subject: Re: future Xilinx products wish list ...
From: Eric <erv_NO_SPAM@sympatico.ca>
Date: Tue, 02 Oct 2001 01:27:35 -0400
Links: << >>  << T >>  << A >>
Hi,

These chips are interresting to say the least, however, I need 16 bit x86
architecture compatibility. 8051/ARM users who also need a small / medium
FPGA certainly should explore them.

The more you integrate different unrelated devices on the same chip, the more
variants you need to have to fit most users needs in a cost effective way.
Whenever the limits for such all-in-one chips are exceeded, I believe there
certainly also is a huge market for standard "FPGA only" chips that are optimized
for a direct (without any glue logic) connection to commonly used processors
that can share the nonvolatile memory to form highly featured cost effective trios.

All the little changes that were in my wish list are oriented toward that goal.

On a non technical point of view, this "intrusion" of FPGAs closer to commonly
used microcontrollers would certainly attract many designers who still see them
as exotic & hard to use high end parts.

regards,

Eric.

"Steven K. Knapp" wrote:

> Just FYI.  If you are using a processor plus FPGA or CPLD, you also
> might be interested in the Triscend Configurable System-on-Chip (CSoC)
> devices.  The Triscend CSoC parts embed an industry-standard
> processor, peripherals, memory, a high-speed bus, and a block of
> LUT-based programmable logic, all in a single device.
>
> The CSoC device boots from a single external memory device, per your
> request.  The boot PROM holds the configuration data for the embedded
> programmable logic plus the application program for the embedded
> processor.  You can also download and debug the device directly via a
> JTAG port.
>
> There are two Triscend CSoC families available today--one based around
> the 8-bit 8051/8052 microcontroller and another based around the
> 32-bit ARM7TDMI RISC processor.  There is more information at the
> following link.
> http://www.triscend.com/products
>
> The E5 family--based around the 8051--has both an internal ring
> oscillator and a crystal-oscillator amplifier that operates up to 40
> MHz.
>
> The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to
> synthesize system clock frequencies between 1 and 60 MHz.  It too has
> an internal ring oscillator.


Article: 35379
Subject: Linux tools
From: Zoltan Kocsi <root@127.0.0.1>
Date: 02 Oct 2001 16:20:17 +1000
Links: << >>  << T >>  << A >>
I was away for a while from the NG, is there any word on FPGA
vendors offering (or planning to) Linux toolchains (in the same 
config and pricing as their Win tools) ?

Thanks,

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 35380
Subject: Re: Barrel Shifter
From: Duane Hague <dhague@neo.rr.com>
Date: Tue, 02 Oct 2001 07:14:09 GMT
Links: << >>  << T >>  << A >>
Greetings,

Warning:  This is not intended to start Altera vs Xilinx wars.
	   This is intended to suggest a point of schematic vs HDL entry.

	By chance, I happened to have just tried designing a 32-bit barrel 
shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry 
as two stages of 4:1 muxes followed by a final stage of registered 2:1 
mux.  The first stage does shifts of 0,1,2,3.  The second stage does 
shifts of 0,4,8,12.  The final stage doing shifts of 0,16.  I selected 
this structure after considering the logic element structure and cascade 
chain.  It compiled nicely on an ACEX-1K device selection to a three-
level structure consisting of about 164 LEs.  Simulation tool indicates 
desired function and timing analysis tool indicates latency of under 
nine nanoseconds.

Conclusion:  Could this be a nice example of why a designer should have 
more than "one arrow in his quiver"?  Just a suggestion.

Cheery Bye

Article: 35381
Subject: QPSK BER QUESTION
From: dottavio@ised.it (Antonio)
Date: 2 Oct 2001 00:26:00 -0700
Links: << >>  << T >>  << A >>
Good Morning,
I've delivered the following Matlab implementation of a QPSK
modulator, to test it I also arrange a
simple QPSK demodulator, the problems I have are the following :

1) For the noise introduced by the channel I use the relations
    SNR_x_bit_dB = 6 ;
    SNR_dB = SNR_x_bit_dB -10*log10(0.5) - 10*log10(f_clk / (data_rate)) ;
	QPSK_et_noise = awgn( (QPSK_I + QPSK_Q) , SNR_dB, 'measured' , [],'dB' );
   
   I'm not sure about these, especially for the second one, could you confirm 
   to me it's validity ?? In the simulation I found   BER = 0.01234  while the 
   theoretical one is    BER = 0.00238829

2) The same following code could work also for data rate of 82.5Mbps
   or 110Mbps but respect to the same simulation at 55Mbps the result are 
   really bad, for example having SNR_x_bit_dB = 6   I have
    BER = 0.0354462 at 82.5Mbps    and     BER = 0.079483 at 110Mbps.
    How you explain this ??

3) When the noise grows it is normal I think that the eye close, if
    you run the following code you'll see the eye diagram at the output of 
    the SRRC filter that isreally dirty, you think is normal for a
    SNR_x_bit = 6dB ??

4) I use to demap the Matlab function demodmap :
    simboli = demodmap(data_rx , [symbol_rate 0] , f_clk , 'qask', 4) ;
   this is a 4-PSK demodulator and it's equivalent to a 4-QAM demodulator but 
   why these two matlab constellations have a phase difference of pi/4 ?? 
   For the 4-PSK in fact the constellation that matlab expect have all symbols 
   on the axis. Why this ?? How can I use 4-PSK demap ??

And finally here it is the Matlab code, I hope you'll test it and
suggest me how to solve these
problems and enhance it. Thanks ...

				Antonio D'Ottavio 







clear all ;
close all ;
clc       ;


f_clk	    = 165e6 ;
data_rate   = 55e6  ;
n_bits	    = 12000 ;	

symbol_rate = data_rate / 2                 ;
SpS         = f_clk / symbol_rate           ;
n_symb      = n_bits / 2                    ;
n_sample    = n_symb * SpS                  ;

bit_tx = randint(n_bits, 1, [0 1] )         ;

bit_I = bit_tx(1 : 2 : n_bits)              ;   
bit_Q = bit_tx(2 : 2 : n_bits)              ;

data_in_SRRC_tx_I = -2*bit_I + 1            ;
data_in_SRRC_tx_Q = -2*bit_Q + 1            ;




%**********************************  SRRC DESIGN
delay              = 3              ;       
roll_off           = 0.35           ;       
input_rate_SRRC    = symbol_rate    ;       
output_rate_SRRC   = f_clk          ;       


num_fir=rcosine(input_rate_SRRC, output_rate_SRRC, 'fir/sqrt', roll_off, delay);



% **********************************************
% ************************************   QPSK MODULATOR  
% **********************************************





% ********************************   CARRIER FREQUENCY = f_clk/4 

t_clk    = 1 / f_clk                         ;        
t        = 0 : t_clk : (n_sample-1)*t_clk    ;        
theta    = 2*pi*(f_clk/4)*t                  ;        
coseno   = [cos(theta)]                      ;        
  seno   = [sin(theta)]                      ;        


data_out_SRRC_I = applica_polifase(data_in_SRRC_I, SpS , num_fir);
data_out_SRRC_Q = applica_polifase(data_in_SRRC_Q, SpS , num_fir);      


QPSK_I =   [coseno  .* data_out_SRRC_tx_I(1:length(coseno)]   ; 
QPSK_Q = - [seno    .* data_out_SRRC_tx_Q(1:length(coseno)]   ;


 
[Pyy , f_out] = pwelch(QPSK, [] , [] , 'onesided', length(QPSK) - 1 , f_clk) ;
Pyy_dB = 10*log10(Pyy) ;
figure ;             plot(f_out , Pyy_dB - max(Pyy_dB) );      
grid   ;             xlim([0 f_clk/2])                  ;
title(['PSD QPSK FLP con data rate ',num2str(data_rate/1e6),' Mbps']);
xlabel('Frequency (Hz)');   ylabel('dB / Hz');  

 
 
% *****************************************************
% ***************************************  CHANNEL EFFECT
% *****************************************************

SNR_x_bit_dB = 6 ;
SNR_dB = SNR_x_bit_dB -10*log10(0.5) - 10*log10(f_clk / (data_rate) );
QPSK_et_noise = awgn( (QPSK_I + QPSK_Q) , SNR_dB, 'measured' , [] ,'dB' );





% *****************************************************
% *********************************   QPSK DEMODULATOR 
% *****************************************************

data_in_SRRC_rx_I  =  coseno  .* QPSK_et_noise ;
data_in_SRRC_rx_Q  = -seno    .* QPSK_et_noise ;


data_out_SRRC_rx_I = filter(num_fir, 1 , data_in_SRRC_rx_I);
data_out_SRRC_rx_Q = filter(num_fir, 1 , data_in_SRRC_rx_Q);


data_rx = [data_out_SRRC_rx_I' data_out_SRRC_rx_Q'];

scatterplot(data_rx , SpS , 18) ;
  
eyediagram(data_out_SRRC_rx_I(601:2400) , SpS , 1/symbol_rate , 0);


simboli = demodmap(data_rx , [symbol_rate 0] , f_clk , 'qask' , 4) ;



for i = 1:length(simboli)
     switch simboli(i)
        case 0
            simboli_I(i) =  1 ; simboli_Q(i) =  1 ;
        case 1
            simboli_I(i) = -1 ; simboli_Q(i) =  1 ;
        case 2
            simboli_I(i) =  1 ; simboli_Q(i) = -1 ;
        case 3
            simboli_I(i) = -1 ; simboli_Q(i) = -1 ;
        otherwise
            error('Nun ce prova ''nfame !!! ')
     end
end



bit_rx_I = ( simboli_I - 1) / (-2) ;
bit_rx_Q = ( simboli_Q - 1) / (-2) ;



bit_rx = 4*ones(1,n_bits) ;
bit_rx(1 : 2 : n_bits) = bit_rx_I              ;   
bit_rx(2 : 2 : n_bits) = bit_rx_Q              ;




delta = 10 ;   

[wrong BER]=biterr(bit_tx(1:(n_bits-delta)),bit_rx((delta+1):n_bits)')


expBER_matlab = 0.5 .* erfc( sqrt ( 10.^ (SNR_x_bit_dB(:) .* 0.1) ) )














THE FOLLOWING CODE HAVE TO BE IN A FILE NAMED   applica_polifase.m







% MODULE NAME 	: applica_polifase.m
% DESCRIPTION	: Applica il filtraggio secondo lo schema polifasepolifase 
% RELEASE		:  
% PROBLEMS		:
% DATE			: 3-6-2001


function data_out_polifase = applica_polifase(data_in_polifase, SpS , coefficienti)

n_fir          = SpS                            ;  
n_symb         = length(data_in_polifase)       ;
n_coefficienti = length(coefficienti)           ;  
max_dim_fir    = ceil( n_coefficienti / n_fir)  ;  



matrice_dei_fir = zeros(n_fir, max_dim_fir)          ;  
for i = 1 : n_fir                                       
    fir_i = coefficienti(i : n_fir : n_coefficienti) ;  
    matrice_dei_fir(i , 1:length(fir_i) ) = fir_i    ;  
end



matrice_fir_out = zeros( n_fir , n_symb ) ; 
for i = 1 : n_fir
    matrice_fir_out(i,:) = filter(matrice_dei_fir(i,:) , 1 , data_in_polifase');
end


data_out_polifase = zeros( 1 , n_symb * n_fir ) ; 
k = 0 ;                         
for colonna = 1 : n_symb        
    for riga = 1 : n_fir        
        k = k + 1   ;           
        data_out_polifase(k) = matrice_fir_out(riga , colonna);    
    end
end

Article: 35382
Subject: Re: Xchecker and NT???
From: "peterc" <peterc@hmgcc.gov.uk>
Date: Tue, 2 Oct 2001 09:53:52 +0100
Links: << >>  << T >>  << A >>

"Austin Franklin" <austin@dark98room.com> wrote in message
news:trfaei9bl4l223@corp.supernews.com...
> Does anyone know if xchecker works with NT?  I tried it, and it doesn't
seem
> to work correctly...

That's the serial download cable isn't it? If so yes it will work as I use
one.



Article: 35383
Subject: Which Cable for the Xilinx 3064XL ?
From: "Martin Fischer" <Martin.Fischer@fzi.de>
Date: Tue, 2 Oct 2001 16:40:53 +0200
Links: << >>  << T >>  << A >>
Please help me,

I want to program an Xilinx 3064XL,
but I have different download Cable Datasheets.
Which one of the selfmade Parallel Cable works with
which Software ?

If you could send me the Datasheets from the Cable you built
and the Software I would be happy.

Thanks

Martin.Fischer@fzi.de



Article: 35384
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 02 Oct 2001 14:58:29 GMT
Links: << >>  << T >>  << A >>
Absolutely. I agree 100%. I have predicted that, due to their abundance, more multipliers
will be used as shifters than as multipliers.

Peter Alfke, Xilinx Applications
=======================================
Ray Andraka wrote:

> Good point.  Of course it does depend on the exact implementation of the multiplier.
> It would be interesting to see the timing results for a shift.  Thing is, doing real
> world designs, we need to be able to show conclusively that it meets timing.  Since
> the timing analysis uses the multiplier timing numbers, any speed gains by being 'just
> a shift' would not show in the analysis anyway, so in most cases are meaningless.  If
> you do characterize it for a shift, will those characterizations make it into the
> speedfiles?  In order to be able to use them, I think a separate library element or
> attribute would have to be used and passed into the xilinx tools so that after PAR,
> the tool would know that a particular multiplier is being used only for a shift.
>
> Peter Alfke wrote:
>
> > Ray Andraka wrote:
> >
> > > The multipliers in virtexII do indeed work as a shifter, but they are quite
> > > slow compared to what you can do in the fabric.
> >
> > If you just look at the multiplier spec, it does indeed seem slow. But that is
> > mainly due to the internal carry delay. Since a shifter does not have any carry
> > delay ( methinks ), it should be much faster than a real multiplication.
> > I have already asked our folks to characterize the multiplier as a shifter, but no
> > results yet.
> > I would bet that the shift delay is half the multiply delay.
> >
> > Peter Alfke
>
> --
> --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: 35385
Subject: Re: Barrel Shifter
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 02 Oct 2001 09:18:15 -0700
Links: << >>  << T >>  << A >>
Duane Hague wrote:

>         By chance, I happened to have just tried designing a 32-bit barrel
> shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry
. . .

> Conclusion:  Could this be a nice example of why a designer should have
> more than "one arrow in his quiver"? 

Certainly you can't beat packing your own primitives 
for speed and gate count.

But consider that a barrel shifter might be less
than 1% of a large design.

And you might want to reuse the design in 2 years
on newer devices.

       -- Mike Treseler

Article: 35386
Subject: Webpack V4 && IBUFG
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Tue, 2 Oct 2001 18:15:43 +0100
Links: << >>  << T >>  << A >>
Anyone,

Prior to upgrading to webpack 4 I believe I was able to use IBUFG to route a
IO pin onto the global clock.
After all global clock routes were used, any other clock pin would have been
routed using the normal resources.


How I just get the usual "wrong pin" error!!!, and have had to use the
normal routing resource for all.

Am I just plain wrong or has this been changed?
Is there another way to do this?

Thanks

Dave



Article: 35387
Subject: Re: barrel shifter in Xilinx Virtex-E
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Tue, 2 Oct 2001 18:23:04 +0100
Links: << >>  << T >>  << A >>
Hi,
I have done something like this and seem to remember it worked ok,

module barrel_up (datain, bs, dataout);

   // port definitions
   input[31:0]    datain;     // data in
   input[4:0]     bs;         // barrel shift value
   output[31:0]   dataout; // barrel shift out data

   reg[31:0]      output_reg;

   always @(datain or bs)
      begin
            dataout = datain << bs;
    end

PS: The syntax may need a "tweak"

Dave


"Nate Goldshlag" <nateg@pobox.com> wrote in message
news:nateg-EB2FEA.21151701102001@news.fu-berlin.de...
> Hi,
>
> I have implemented a barrel shifter in a Virtex-E part as:

<SNIP>
>
> This synthesizes to 5 logic levels, which seems like a lot to me.  I tried
> doing it another way but it was also 5 levels.  Anybody have any ideas on
how
> to make it less, or is that just the way it is?
>
> I am using Synplify for synthesis.
>
> Nate
>
> ----------------------------------------------------
> Nate Goldshlag      nateg@pobox.com
> Arlington, MA       http://www.pobox.com/~nateg



Article: 35388
Subject: Re: barrel shifter in Xilinx Virtex-E
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Tue, 02 Oct 2001 19:29:23 +0200
Links: << >>  << T >>  << A >>
Peter "FlipFlops-are-cheap" Alfke schrieb:

> Absolutely. I agree 100%. I have predicted that, due to their abundance, more multipliers
> will be used as shifters than as multipliers.

What are the lottery numbers for next week?

SCNR ;-))

-- 
MFG
Falk



Article: 35389
Subject: Re: Barrel Shifter
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Tue, 02 Oct 2001 19:32:11 +0200
Links: << >>  << T >>  << A >>
Mike Treseler schrieb:
> 
> Duane Hague wrote:
> 
> >         By chance, I happened to have just tried designing a 32-bit barrel
> > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry
> . . .
> 
> > Conclusion:  Could this be a nice example of why a designer should have
> > more than "one arrow in his quiver"?

AFAIK there is nothing that stops you to describe the structure in
VHDL(Verilog). Or even the hard way down to the silly-cone ;-) by just
instanciating primitives.

-- 
MFG
Falk



Article: 35390
Subject: Re: Which Cable for the Xilinx 3064XL ?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Tue, 02 Oct 2001 19:34:40 +0200
Links: << >>  << T >>  << A >>
Martin Fischer schrieb:
> 
> Please help me,
> 
> I want to program an Xilinx 3064XL,
> but I have different download Cable Datasheets.
> Which one of the selfmade Parallel Cable works with
> which Software ?

Hmm, AFAIK the parallel cable (Datasheet+Schematics on Xilinx webpage)
provide JTAG and serial slave download capability.
Software is simply the Webpack JTAG Prgrammer (which is AFAIK a
combination of the "old" JTAG programmer and Hardware debugger)
 
> If you could send me the Datasheets from the Cable you built
> and the Software I would be happy.

Have a look on the Xilinx site, its not that hard to find.

-- 
MFG
Falk


Article: 35391
Subject: Implementation of Quartus Megafunctions in Mentor HDS???
From: rafael plonka <rafael.plonka@gmx.de>
Date: Tue, 02 Oct 2001 20:04:42 +0200
Links: << >>  << T >>  << A >>
Hi everyone,

I tried to implement some megafunctions with the Altera Quartus
Megafunction Wizard to use them in my HDL Designer Series block view.
Some of them work (LVDS receiver, Fifo...) but some don't (Fifo+, FF).
Instead there appears the Message "Could not import generated file
c:\mydir\temp\megawizard\rtl.vhd"
Anyone encountered this problem too or has an idea, what the reason is
for this???

Thanks,

Rafael


Article: 35392
Subject: Re: future Xilinx products wish list ...
From: sknapp@triscend.com (Steven K. Knapp)
Date: 2 Oct 2001 11:11:11 -0700
Links: << >>  << T >>  << A >>
You are correct that the Triscend CSoC devices are "system heavy"
rather than "programmable logic heavy."  These devices focus on on
integrating a complete system, leveraging programmable logic as the
flexible interface to the rest of the world.

In no way do CSoC devices replace high-end FPGAs unless you plan on
creating a sophisticated processor-based system, complete with
peripherals.  In fact, some CSoC users also have one or more large
FPGAs on each board.

The largest commercially available Triscend CSoC device has 2,048
cells with 3,200 cells coming soon.  Each cell is a 4-input LUT plus
flip-flop.  The primary difference between a Triscend CSoC logic cell
and FPGA or CPLD logic is that the CSoC logic cell intimately connects
to the internal system bus, with predicatable timing.  Similarly there
is built-in address decoding and DMA services within the CSoC logic
matrix.  Furthermore, every LUT and flip-flop output can be probed in
real-time via JTAG for easy debugging.

CSoC are best in applciations that currently use a processor +
programmable logic, a common combination in many embedded
applications.  There are a variety of problems that are solved much
easier with a processor than attempting to implement it in hardware. 
The opposite is also certainly true.  CSoC devices provide the
designer with the opportunity to easily optimize the hardware/software
trade-off.

To answer your question about "top of the line", the currently
available top of the line is the TA7S20 which has the following
features.  Larger devices are due out next year.

* ARM7TDMI 32-bit RISC CPU
* 8K-byte unified cache
* 16K-byte internal single-cycle RAM (8K available as trace buffer)
* Split bus architecture supporting up to 455 MB/s transfers  
* 4-channel DMA supporting linked-list, fly-by performance
* Two 16C450/550-style UARTs
* Two 16-bit timers
* 32-bit watchdog timer
* Hardware breakpoint, tracepoint
* JTAG debugger interface
* Flash memory interface
* SDRAM memory interface
* 16-input interrupt controller
* 2,048 logic cells (approximately 25K gates)
* Up to 190 user-defined I/O pins
http://www.triscend.com/products/indexA7.html

Ray Andraka <ray@andraka.com> wrote in message news:<3BB89E0E.D76A3B31@andraka.com>...
> Steve,
> 
> How big is your FPGA fabric these days (ie how many CLBs).  Last I looked, you were using a
> rough equivalent of the xilinx 4K architecture.  IIRC the equivalent device size was not very
> big, so it didn't meet the needs of something that needed alot of FPGA plus some
> microprocessor.  What is the top of your line now?
> 
> "Steven K. Knapp" wrote:
> 
> > Just FYI.  If you are using a processor plus FPGA or CPLD, you also
> > might be interested in the Triscend Configurable System-on-Chip (CSoC)
> > devices.  The Triscend CSoC parts embed an industry-standard
> > processor, peripherals, memory, a high-speed bus, and a block of
> > LUT-based programmable logic, all in a single device.
> >
> > The CSoC device boots from a single external memory device, per your
> > request.  The boot PROM holds the configuration data for the embedded
> > programmable logic plus the application program for the embedded
> > processor.  You can also download and debug the device directly via a
> > JTAG port.
> >
> > There are two Triscend CSoC families available today--one based around
> > the 8-bit 8051/8052 microcontroller and another based around the
> > 32-bit ARM7TDMI RISC processor.  There is more information at the
> > following link.
> > http://www.triscend.com/products
> >
> > The E5 family--based around the 8051--has both an internal ring
> > oscillator and a crystal-oscillator amplifier that operates up to 40
> > MHz.
> >
> > The A7 family--ARM7TDMI-based--uses a 32.768 kHz watch crystal to
> > synthesize system clock frequencies between 1 and 60 MHz.  It too has
> > an internal ring oscillator.
> >
> >
> 
> --
> --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: 35393
Subject: Re: Webpack V4 && IBUFG
From: "Speedy Zero Two" <david@manorsway.freeserve.co.uk>
Date: Tue, 2 Oct 2001 19:19:15 +0100
Links: << >>  << T >>  << A >>
Or was it BUFG........





Article: 35394
Subject: Re: Which Cable for the Xilinx 3064XL ?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 02 Oct 2001 11:47:29 -0700
Links: << >>  << T >>  << A >>
Before anybody wastes time looking for the part number:
There never was an XC3064XL. But there is/was an XC3064L, a 3.3-V version of the
XC3064A. This was introduced about ten years ago.
You can treat the XC3064L as if it were an XC3064A ( logically identical ) or
even an XC3064 ( a logical subset ), as long as you observe the lower supply
voltage.

Peter Alfke, Xilinx historian (archaeologist?)

Falk Brunner wrote:

> Martin Fischer schrieb:
> >
> > Please help me,
> >
> > I want to program an Xilinx 3064XL,
> > but I have different download Cable Datasheets.
> > Which one of the selfmade Parallel Cable works with
> > which Software ?
>
> Hmm, AFAIK the parallel cable (Datasheet+Schematics on Xilinx webpage)
> provide JTAG and serial slave download capability.
> Software is simply the Webpack JTAG Prgrammer (which is AFAIK a
> combination of the "old" JTAG programmer and Hardware debugger)
>
> > If you could send me the Datasheets from the Cable you built
> > and the Software I would be happy.
>
> Have a look on the Xilinx site, its not that hard to find.
>
> --
> MFG
> Falk


Article: 35395
Subject: Re: Barrel Shifter
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 2 Oct 2001 19:50:31 GMT
Links: << >>  << T >>  << A >>
Mike Treseler <mike.treseler@flukenetworks.com> writes:

>Duane Hague wrote:

>>         By chance, I happened to have just tried designing a 32-bit barrel
>> shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry
>. . .

>> Conclusion:  Could this be a nice example of why a designer 
>>should have  more than "one arrow in his quiver"? 

>Certainly you can't beat packing your own primitives for speed 
>and gate count.  But consider that a barrel shifter might be less
>than 1% of a large design.

If that design is a floating point ALU, it might be more.

I will suggest again that base 16 floating point needs a much smaller
barrel shifter, and might be better for FPGA implementation.
(I don't know what the OP wanted it for.)

-- glen

Article: 35396
Subject: Re: Barrel Shifter
From: Duane Hague <dhague@neo.rr.com>
Date: Tue, 02 Oct 2001 20:59:00 GMT
Links: << >>  << T >>  << A >>
In article <3BB9E8C7.4CA8327D@flukenetworks.com>, 
mike.treseler@flukenetworks.com says...
> Duane Hague wrote:
> 
> >         By chance, I happened to have just tried designing a 32-bit barrel
> > shifter (0-31 shift, 5-bit shift index) in MaxPlus with schematic entry
> . . .
> 
> > Conclusion:  Could this be a nice example of why a designer should have
> > more than "one arrow in his quiver"? 
> 
> Certainly you can't beat packing your own primitives 
> for speed and gate count.
> 
> But consider that a barrel shifter might be less
> than 1% of a large design.
> 
> And you might want to reuse the design in 2 years
> on newer devices.
> 
>        -- Mike Treseler
> 
To be a bit less subtle, my point was that IMO schematic entry should 
remain part of the designers tool kit.  HDL synthesizers use an "N-bit" 
modular translation approach because it would be too complex to include 
optimization for all cases of "input width" versus "architecture element 
width".  I would suggest that the designer needs to be aware of the 
advantages and disadvantages of each entry method and to select the 
method most appropriate to each portion of the design.  Over many years 
of experience, I have lost trust in anyone who proposes "the magic 
answer where one size fits all" (i.e. certain HDL True Believers).

With regards to "reuse":  If your EDA tools do not support both HDL and 
schematic entry as well as mixed entry modes; I would argue that you 
need to consider the use of other EDA tools!  I would not be happy with 
any EDA tools that did not allow more than one mode of design entry.

Respectfully,
Duane Hague

Article: 35397
Subject: Re: Barrel Shifter
From: Ray Andraka <ray@andraka.com>
Date: Tue, 02 Oct 2001 22:47:05 GMT
Links: << >>  << T >>  << A >>
I have been using VHDL for about 2 years now, and this is for some very high speed
designs (eg. our FFT module, which is the fastest single thread FFT available for
FPGAs is done in VHDL).  VHDL does let you structurally instantiate primitives, so
that you can do anything you can do with schematics, plus it has the advantage of
a generate statement, so one design can cover many uses.  For example, our adder
macro creates a fully RLOC'd adder that is automatically sized to the the width of
the bus connected to its output.  When we did schematics, this required a separate
schematic for each bit width (we had ways of doing that quickly too, but the
generate is even better).  We were a relatively late adopter of VHDL because we
didn't start using it heavily until we could put placement in the hierarchical
source (the tools did not allow it until roughly 2nd qtr 1999).

One thing that I won't do is use more than one entry tool on a particular
project.  Most customers wouldn't tolerate having to buy seats of two different
tools in order to maintain a design that could have been done with just one tool.


Duane Hague wrote:

> To be a bit less subtle, my point was that IMO schematic entry should
> remain part of the designers tool kit.  HDL synthesizers use an "N-bit"
> modular translation approach because it would be too complex to include
> optimization for all cases of "input width" versus "architecture element
> width".  I would suggest that the designer needs to be aware of the
> advantages and disadvantages of each entry method and to select the
> method most appropriate to each portion of the design.  Over many years
> of experience, I have lost trust in anyone who proposes "the magic
> answer where one size fits all" (i.e. certain HDL True Believers).
>
> With regards to "reuse":  If your EDA tools do not support both HDL and
> schematic entry as well as mixed entry modes; I would argue that you
> need to consider the use of other EDA tools!  I would not be happy with
> any EDA tools that did not allow more than one mode of design entry.
>
> Respectfully,
> Duane Hague

--
--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: 35398
(removed)


Article: 35399
Subject: Re: Spartan II use of GCK[0:3] pins as general inputs
From: lucienmp_antispam@yahoo.com (Lucien Murray-Pitts)
Date: 2 Oct 2001 17:46:57 -0700
Links: << >>  << T >>  << A >>
Dave Colson <dscolson@rcn.com> wrote in message news:<3B995EC4.4F5EA95B@rcn.com>...
> Hello,
> Can the GCK pins on the Spartan II be use for general inputs
> if not used for clocks input?
> 
> I get an error when I try to use pin 185 as a normal input signal
> 
> Thanks
> 
> David Colson

Yes you can you have to link to a IBUFG to route if from the Global
Clock network.

Here is an artile from Xilinx;

http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=9177



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