Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 AlfkeArticle: 35376
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, 1759Article: 35377
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
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
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
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 ByeArticle: 35381
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 endArticle: 35382
"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
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.deArticle: 35384
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, 1759Article: 35385
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 TreselerArticle: 35386
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 DaveArticle: 35387
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/~nategArticle: 35388
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 FalkArticle: 35389
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 FalkArticle: 35390
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 FalkArticle: 35391
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, RafaelArticle: 35392
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, 1759Article: 35393
Or was it BUFG........Article: 35394
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 > FalkArticle: 35395
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.) -- glenArticle: 35396
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 HagueArticle: 35397
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, 1759Article: 35398
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:
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