Custom Search
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
Some comments. Algorithm analysis 101 tells us that to determine the largest item of n items requires at least n-1 2-input "greater than" comparisons. You might build other circuit structures, e.g. using 3-input or 4-input max-functions, of course, but I doubt they are as area efficient -- although I can't prove that off the top of my head. In the worst case, each comparison must consider each bit of its two arguments, although there is a possibility (a probability) of "early out" if some MSBs are different. If you wish to take advantage of early-out, you will have to design for the worst case (no early-outs occurred) or for failure in the improbable case. As you suggest, you can do the n-1 comparisons sequentially, in parallel, pipelined, etc., depending upon your performance requirements. Consider using dedicated carry chains (if available) to make your comparators small and fast. For example, an n-bit comparator requires approximately n/2 XC4000 CLBs + approx 1/2 CLB to establish carry-in[0] as 0. If the data arrives a byte at a time you could perform 1 load and n-1 comparison cycles using a single comparator and load-enabled register (e.g. 4.5 XC4000 CLBs, 1+15 cycles at ~10 ns/cycle). If the 16 bytes of data arrive all at once, the pipelined tree of comparators and muxes should do nicely (15*(4.5+4) = ~130 CLBs, 10 ns/cycle). Hybrids: e.g. if you have 50 ns you can reduce the problem to a first step where you iteratively find 4 largest of 4 subsets of 4, followed by 3 comparators+muxes, in area 4*4.5 +3*(4.5+4) = ~45 CLBs). Jan GrayArticle: 11976
Hello all:
I have a FPGA design in ALTERA 10K20, and now I want to
translate it into ASIC, would you tell me what is important about
translation? does timing will change? how to keep the result current?
Thanks
John Huang
Article: 11977Hi everyone. I would like to know if there is a way to eliminate ringing/ground bounce from a signal that is being output by the FPGA. The design that our research team has built requires the use of a divided clock (1/8 generated via VHDL code) that must be fed to a bit error rate test system through a physical cable. The problem we see at the divided clock output is a lot of ringing (with a negative spike of 2V). We are not sure if the problem is directly related to any form of ground bounce, but any suggestions for configuring the FPGA (either by configuring the IOBs or adding external capacitors or an RC network) that could reduce these unwanted oscillations are greatly welcome. We have tried both TTL and CMOS outputs and the results are just as bad in both cases. Our FPGA is a Xilinx 4028E-3HQ240, and the divided clock can be chosen directly from a header or an SMB connector. Our input clock is TTL (0-5V) and is quite clean. Thanks in advance for any help. -- Nestor Caouras nestor@ece.concordia.caArticle: 11978
FPGA `99: Call for Papers
Seventh ACM International Symposium on
Field-Programmable Gate Arrays
DoubleTree Hotel, Monterey, California
February 21-23, 1999
As we reach the end of the 1990s, rapidly increasing speed and capacity have
made FPGAs a standard implementation target for digital logic. Advancements
in FPGA architectures proceeds unabated, and larger, faster devices enable
new, innovative applications that continue to stress designers and
their tools. For FPGA `99, we are soliciting submissions describing novel
research and development in the following (and related) areas of interest:
FPGA Architecture: Logic block & routing architectures, I/O structures and
circuits, new commercial architectures, Field-Programmable Interconnect
Chips and Devices (FPIC/FPID), Field-Programmable Analog Arrays (FPAA).
CAD for FPGAs: Placement, routing, logic optimization, technology mapping,
system-level partitioning, logic generators, testing and verification.
CAD for FPGA-based accelerators.
Interactions: between CAD, architecture, applications, and programming
technology.
Applications: Innovative use of FPGAs, exploitation of FPGA features,
novel circuits, high-performance and low-power/mission-critical
applications, DSP techniques, uses of reconfiguration, FPGA-based cores.
FPGA-based computing engines: Compiled accelerators, reconfigurable
computing, adaptive computing devices, systems and software.
Fast prototyping for system level design, Multi-Chip Modules (MCMs), logic
emulation.
Authors are invited to submit PDF (preferred) or postscript of their paper
(12 pages maximum) by October 2, 1998 via E-mail to fpga99@xilinx.com.
Alternatively, authors may submit a 3.5" floppy disk containing the pdf
or postscript file or 22 copies of their paper to the program chair.
Notification of acceptance will be sent by December 1, 1998. The authors of
the accepted papers will be required to submit the final camera-ready copy by
December 15, 1998. A proceedings of the accepted papers will be published by
ACM, and included in the Annual ACM/SIGDA CD-ROM Compendium publication.
Address questions to:
Steve Trimberger
Program Chair, FPGA `99
Xilinx, Inc.
2100 Logic Dr.
San Jose, CA 95124-3450 USA
phone: (408) 879-5061
fax: (408) 559-7114
fpga99@xilinx.com
General Chair: Sinan Kaptanoglu, Actel
Finance Chair: Jason Cong, UCLA
Program Chair: Steve Trimberger, Xilinx
Publicity Chair: Scott Hauck, Northwestern U.
Program Committee
Om Agrawal, Vantis Ray Andraka, Andraka Consulting
Michael Butts, Quickturn Jason Cong, UCLA
Eugene Ding, Lucent Carl Ebeling, U. of Washington
Scott Hauck, Northwestern U. Brad Hutchings, BYU
Sinan Kaptanoglu, Actel David Lewis, U. of Toronto
Fabrizio Lombardi, Texas A&M Wayne Luk, Imperial College
Margaret Marek-Sadowska, UCSB Peter Moceyunas, Synopsys
Jonathan Rose, U. of Toronto Gabriele Saucier, INPG
Martine Schlag, UCSC Herman Schmit, CMU
Tim Southgate, Altera Steve Trimberger, Xilinx
John Wawrzynek, UCB Martin Wong, UT at Austin
Sponsored by ACM SIGDA, with support from Xilinx, Altera, Lucent and Actel.
Please visit <http://www.ece.nwu.edu/~hauck/fpga99> for more information.
Article: 11979In article <01bde60e$0d8e4480$4428a8c0@haddock.chil.ndsuk.com>, John Funnell <j.funnell@dmv.co.uk> writes > >Hi, > >I'm trying to think of an efficient implementation of an max-function that >finds the largest from 16 unsigned 8-bit numbers. The input format is not >specified (I decide parallel binary, serial LSB first, serial MSB first). >The max-function must signal which of its inputs was the largest and the >value of that input. What can I do to mimise FPGA area used and maintain a >continuous flow of input data? Is there anything clever I can do? At the >moment I'm thinking in terms of a tree of two-input comparators and muxes >perhaps pipelined. This may be too big. > >Does anyone have any ideas? > >Thanks, > >John Funnell Well if speed was an issue, you would not be suggesting that you could use a serial imput - So try this; Take an 8 bit latch - I used an 'HC273. Feed this with the result of an 8 bit comparator - I used a suitably programmed 27C512 EPROM, but a comparator followed by a mux would do the same job. The comparator gives as an output the highest value of its two inputs. One of those inputs is the output from the 'HC273, the other is the value for comparason. Clear the '273 before you start and then feed in your 16 values, one on each clk. The result will be the highest value. This should be straight forward to convert to an FPGA. -- Kindest Regards | gerry@devantech | We manufacture Pic programmers, 8031, Gerald Coe | .demon.co.uk | 68302, 64180, 80C188EB cpu modules. http://www.devantech.demon.co.uk | Full custom uP control systems designed.Article: 11980
Hi, I'm thinking of using a Xilinx Spartan XL FPGA to interface a 3.3V PCI bus to a 5V local bus using the PCI logicore provided by Xilinx. Problem is that once the PCI logicore is used it configures the device to switch on diodes on all the I/O's to clamp to the 3.3V supply (as per the PCI spec) but this causes the device to loose its 5V tolerance on all the I/O's although otherwise the device is 5V tolerant. Any ideas? Thanks, Jai.Article: 11981
We need more details:
- What is your design about (schematics, RTL, netlist, etc.)
- Can you simulate it?
- Do you have a test bench? (Test vectors)
John Huang wrote in message <6u8ue8$92b$1@news.seed.net.tw>...
>Hello all:
> I have a FPGA design in ALTERA 10K20, and now I want to
>translate it into ASIC, would you tell me what is important about
>translation? does timing will change? how to keep the result current?
>
>Thanks
> John Huang
>
>
Article: 11982I got my Alliance 1.5 basic version about 3 weeks age and standard version last week. I guess you need to ask them for it again. Howard Bob Myers wrote in message <6u88n0$ppn@sf18.dseg.ti.com>... >We haven't received M1.5 from Xilinx yet. Seems that the local >Avnet/Hamilton-Hallmark & Xilinx office had received theirs about >a week or two ago.... > >Any inputs? > >Thanks, >Bob > >Article: 11983
Hi! Has anybody success in configuring a Xilinx Spartan chip using JTAG method? So far I have this strange result that all the combinatorial logic is fine but none of the Flip-flop works. The chip I used is Spartan XCS30 in PQFP 208 package and programming tool is jtagpgmr.exe from Xilinx Alliance version 1.5 Thanks! HowardArticle: 11984
Could anyone point me in the right direction as to where I could get some broad information about FPGAs? I have searched the web to no avail and require information such as performance, software, gate length, number of metal levels, density, I/O, speed, turn time and cost. Any help on this matter would be sincerely appreciated.Article: 11985
John Funnell wrote: > > Hi, > > I'm trying to think of an efficient implementation of an max-function that > finds the largest from 16 unsigned 8-bit numbers. The input format is not > specified (I decide parallel binary, serial LSB first, serial MSB first). > The max-function must signal which of its inputs was the largest and the > value of that input. What can I do to mimise FPGA area used and maintain a > continuous flow of input data? Is there anything clever I can do? At the > moment I'm thinking in terms of a tree of two-input comparators and muxes > perhaps pipelined. This may be too big. > > Does anyone have any ideas? > > Thanks, > > John Funnell This is not a complex operation, but I am not sure I understand how the data is presented. It sounds like you have not made that determination yet. Regardless, the circuit can operate in parallel (only useful if your data is presented all at once) or in serial (greatly reduces the design area if the data is presented one sample at a time). If the data is presented one bit at a time you can design a bit serial circuit which will save even more space and will run faster. The operation of the parallel circuit is not too complex. You need 15 comparators of 8 bits. The first stage will use 8 comparators with each comparator driving a mux to select the result to be fed to the next stage. The next stage will repeat this operation to feed a stage with two comparators and finally a single comparator to select the largest operand. A similar mux can be used to build an number which will indicate the item number of the selected operand. The word serial circuit will have a single comparator along with a max value and max index registers. The input operand will be compared to the register. When the input is larger than the register value, both registers are updated with the input value and the value of an input counter. This can work for any number of inputs. Of course the max value register must be zeroed (or set to max negative) before the first compare. The bit serial circuit will work like the word serial circuit but the compare operation will be done with a one bit compare and a FSM to perform the word compare. There will also need to be a shift register to accumulate the input value to load into the max value register when the input is greater than the current max value. For an 8 bit circuit, I doubt that this will be much smaller than the word serial circuit. But the bit serial will not have a carry chain and will therefore run faster. -- Rick Collins Don't hit that reply button!!! redsp@XYusa.net remove the XY to email me.Article: 11986
Nestor Caouras wrote: > > Hi everyone. > > I would like to know if there is a way to eliminate ringing/ground bounce > from a signal that is being output by the FPGA. > > The design that our research team has built requires the use of a divided > clock (1/8 generated via VHDL code) that must be fed to a bit error rate > test system through a physical cable. The problem we see at the divided > clock output is a lot of ringing (with a negative spike of 2V). We are not > sure if the problem is directly related to any form of ground bounce, but > any suggestions for configuring the FPGA (either by configuring the IOBs > or adding external capacitors or an RC network) that could reduce these > unwanted oscillations are greatly welcome. We have tried both TTL and > CMOS outputs and the results are just as bad in both cases. > > Our FPGA is a Xilinx 4028E-3HQ240, and the divided clock can be chosen > directly from a header or an SMB connector. Our input clock is TTL > (0-5V) and is quite clean. > > Thanks in advance for any help. > -- > Nestor Caouras > nestor@ece.concordia.ca I may get an argument from some people about this since it is partly a matter of semantics, but ground bounce is not likely the cause of your problem. Ground bounce can not produce negative spikes on an output. Ground bounce is due to resistance or inductance in a ground path which causes a positive voltage at the chip's internal ground. This will raise the voltage at the output pins either directly or by causing an input to be falsely interpreted as a low when it should be a high. One way to reduce ground bounce in the Xilnx parts is to not use them in the FAST mode. The default is SLOW, so unless you are setting it to FAST, you are already running it SLOW. What you are seeing is most likely transmission line effects from mismatched impedances or edge reflections. You should try termination of your clock line and/or examine the routing of the trace on your circuit board. Also look for capacitive coupling to other signals. The design of clock distribution is a whole chapter of digital logic design so that I can't tell you everything here. But I don't think this is a problem with your Xilinx outputs. If you think the Xilinx outputs are not up to the task of driving your clock line, why not try inserting a clock driver? -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 11987
I wrote in message <6u8s8g$l5s$1@news-1.news.gte.net>...
>Algorithm analysis 101 tells us that to determine the largest item of n
>items requires at least n-1 2-input "greater than" comparisons. ...
SEGUE
Algorithm analysis 101 also teaches us to carefully choose a model (e.g.
elements and a 2-element comparison function) and a goal (e.g. minimize no.
of comparisons to determine the largest element) to represent the problem.
Only then can we compare algorithms or study optimal lower bounds on
algorithms.
For example, using a comparison based model, it can be shown that any
sorting algorithm on n elements must perform at least ceil lg n!
comparisons. But there are other sorting algorithms which do not perform
any elementwise comparisons. They assume a different model with different
operations on the elements. Consider radix sort, in which we distribute the
n elements into r buckets, according to increasingly significant digits in
their base r representation, and then regather them and repeat. (Remember
the old IBM punch card sorters?)
So, as radix sort is to a comparison-based sort, is there an analogous
"radix max" to our comparison-based max?
"PARALLEL BITWISE MAX"
Yes. Here's a 'digit'al method for finding the max of n k-bit words.
We scan the n inputs as n serial bit streams, all clocked together, msbs
first. One bit stream is the maximum if it is never observed to be less
than some other bit stream. For any two bit streams A and B,
"A < B" iff ~msb(A)&msb(B) | (msb(A)==msb(B) & "lsbs(A) < lsbs(B)").
Design: we keep n candidate-for-max state bits, one for each bit stream.
All are initialized to 1, as each stream is initially a candidate to be the
maximum. A candidate stream is still a candidate if it has a current 1
input bit. A stream with a current 0 input bit loses its candidacy if there
is some other remaining candidate stream that has a current 1 bit. After
all input bits have been clocked past, the remaining candidate is the
maximum bit stream. If duplicate input bit streams are possible, there can
be more than one remaining candidate, each of which corresponds to the same
maximum value.
// pidgin netlist generator source:
input reset; // 1 during the reset cycle
input stream[n]; // current bit of each of the n input streams
reg cand[n]; // 1 if the i'th stream is still a candidate for maximum.
net some1; // 1 if some remaining candidate stream input bit is currently
1
output answer; // result, the index of max input stream
some1 = cand[0]&stream[0] | cand[1]&stream[1] | ... |
cand[n-1]&stream[n-1];
for (i = 0; i < n; i++)
cand[i] := reset | cand[i]&(stream[i] | ~stream[i]&~some1);
If we know the input words are never two alike, then bitcount(cand)=1 and we
can use
answer = encode(cand);
otherwise,
answer = priority_encode(cand);
Implemented in an XC4000 FPGA, for n=16, requires approximately
4.5 CLBs for some1
8 CLBs for cand[16]
12.5 CLBs for a 16-to-4 priority encoder
----
~25 CLBs, result every 9 clocks for 8-bit input data, at perhaps 10
ns/clock.
Radix 4 (2 bits/clock) is also possible but probably unwieldly and slow.
The nice thing about this approach is it is readily scalable to many inputs;
the slowest part of the design would be the 'some1' or-reduction circuit,
and even with 36 input streams this is only three CLB delays and mostly
local interconnect.
Jan Gray
Article: 11988Personally, I always put a resistor as near as I can to the clock source. If it is a long trace, I also leave pads for Rs and Cs at the end (one to + and one to ground). High speed clock lines should not be T routed, and therefore should be point to point, with equal length traces between loads. Austin Franklin darkroom@ix.netcom.com Nestor Caouras <nestor@macbeth.ece.concordia.ca> wrote in article <6u91pe$b9o$2@newsflash.concordia.ca>... > Hi everyone. > > I would like to know if there is a way to eliminate ringing/ground bounce > from a signal that is being output by the FPGA. > > The design that our research team has built requires the use of a divided > clock (1/8 generated via VHDL code) that must be fed to a bit error rate > test system through a physical cable. The problem we see at the divided > clock output is a lot of ringing (with a negative spike of 2V). We are not > sure if the problem is directly related to any form of ground bounce, but > any suggestions for configuring the FPGA (either by configuring the IOBs > or adding external capacitors or an RC network) that could reduce these > unwanted oscillations are greatly welcome. We have tried both TTL and > CMOS outputs and the results are just as bad in both cases. > > Our FPGA is a Xilinx 4028E-3HQ240, and the divided clock can be chosen > directly from a header or an SMB connector. Our input clock is TTL > (0-5V) and is quite clean. > > Thanks in advance for any help. > -- > Nestor Caouras > nestor@ece.concordia.ca > > > >Article: 11989
I use VHDL for this design, and I don't have Test vectors, you know, the simulator of maxplus2 is poor, I don't like it, I use SpeedWave to do functional verify, but I can't check the timing,, because my viewlogic WORKVIEW Office is bundled with Cypress Warp3, it doesn't include Altera chips, One more question, I'm interest in Accolade's Peak Suite, Do someone use it before, how about it, can you give me a recommand, thanks John Huang Flor Netsmar >We need more details: > > - What is your design about (schematics, RTL, netlist, etc.) > - Can you simulate it? > - Do you have a test bench? (Test vectors) > > >John Huang wrote in message <6u8ue8$92b$1@news.seed.net.tw>... >>Hello all: >> I have a FPGA design in ALTERA 10K20, and now I want to >>translate it into ASIC, would you tell me what is important about >>translation? does timing will change? how to keep the result current? >> >>Thanks >> John Huang >> >> > >Article: 11990
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDE6F2.A1DD2491 Content-Type: text/plain; charset="koi8-r" Was Foundation 1.5 released? Has anybody received it? ------_=_NextPart_001_01BDE6F2.A1DD2491 Content-Type: text/html; charset="koi8-r" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2232.0"> <TITLE>Anyone received Xilinx Foundation 1.5 ?</TITLE> </HEAD> <BODY> <P><FONT SIZE=2>Was Foundation 1.5 released?</FONT> <BR><FONT SIZE=2>Has anybody received it?</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01BDE6F2.A1DD2491--Article: 11991
Rickman <spamgoeshere4@yahoo.com> writes:
>Nestor Caouras wrote:
>>
>> Hi everyone.
>>
>> I would like to know if there is a way to eliminate ringing/ground bounce
>> from a signal that is being output by the FPGA.
>>
>> The design that our research team has built requires the use of a divided
>> clock (1/8 generated via VHDL code) that must be fed to a bit error rate
>> test system through a physical cable. The problem we see at the divided
>> clock output is a lot of ringing (with a negative spike of 2V). We are not
>> sure if the problem is directly related to any form of ground bounce, but
>> any suggestions for configuring the FPGA (either by configuring the IOBs
>> or adding external capacitors or an RC network) that could reduce these
>> unwanted oscillations are greatly welcome. We have tried both TTL and
>> CMOS outputs and the results are just as bad in both cases.
>>
>> Our FPGA is a Xilinx 4028E-3HQ240, and the divided clock can be chosen
>> directly from a header or an SMB connector. Our input clock is TTL
>> (0-5V) and is quite clean.
>>
>> Thanks in advance for any help.
>> --
>> Nestor Caouras
>> nestor@ece.concordia.ca
<snipped stuff>
>What you are seeing is most likely transmission line effects from
>mismatched impedances or edge reflections. You should try termination of
>your clock line and/or examine the routing of the trace on your circuit
>board. Also look for capacitive coupling to other signals. The design of
>clock distribution is a whole chapter of digital logic design so that I
>can't tell you everything here. But I don't think this is a problem with
>your Xilinx outputs.
>If you think the Xilinx outputs are not up to the task of driving your
>clock line, why not try inserting a clock driver?
I would agree with this. I've found standard outputs (CMOS/TTL) not
very capable of driving a physical line. This all depends on the
characteristics, of course, but a clock driver or just a line driver
may be necessary. A simple transistor (BJT or FET) may work, too as
long as you do impedance matching on each end (and with the line).
Cheers,
Jake
--
janovetz@uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have been,
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 11992Nestor Caouras <nestor@macbeth.ece.concordia.ca> wrote: > The design that our research team has built requires the use of a divided > clock (1/8 generated via VHDL code) that must be fed to a bit error rate > test system through a physical cable. It would help to use the slowest output mode and also to insert ~20 Ohms series resistance near the driver pin. Since you're going across a cable, it would help greatly to use a coax or twisted pair that has its ground connection very close to the driving pin. If you have a spare pin, you could create an inverted version of the clock and transmit both versions on a twisted pair with a termination of 100-200 ohms at the end. The inverted pin should be as close to the "true" driving pin as possible.Article: 11993
Nestor Caouras wrote:
>
> Hi everyone.
>
> I would like to know if there is a way to eliminate ringing/ground bounce
> from a signal that is being output by the FPGA.
>
> The design that our research team has built requires the use of a divided
> clock (1/8 generated via VHDL code) that must be fed to a bit error rate
> test system through a physical cable. The problem we see at the divided
> clock output is a lot of ringing (with a negative spike of 2V). We are not
> sure if the problem is directly related to any form of ground bounce, but
It is not ground bounce. It is a transmission line reflection and may
even be
bigger than 2V in amplitude (observation error due to limited frequency
response and loading of your scope probe).
> any suggestions for configuring the FPGA (either by configuring the IOBs
> or adding external capacitors or an RC network) that could reduce these
> unwanted oscillations are greatly welcome.
You can try using the SLOW outputs (be careful regarding the definition
Synopsys and Xilinx use opposite terminology). What this buys you is
that with a slower rising edge on your waveform, you can propagate a
wave a greater distance before you suffer transmission line effects.
However, if you are running a length of co-ax I suspect that you will
also be too long even for the Slew Rate limited (slow) outputs.
> We have tried both TTL and
> CMOS outputs and the results are just as bad in both cases.
TTL waveforms and CMOS waveform are both more than happy to ring.
BTW As I understand it, the output stages in the 4028E are very
similair regardless of TTL or CMOS ouput selection. The data book give
the classic Voh min values as different, but I recall being told by an
FAE that they are the same (which makes sense). Input hardware is the
same across the TTL/CMOS selection but they simply change (shift) the
threshold.
>
> Our FPGA is a Xilinx 4028E-3HQ240, and the divided clock can be chosen
> directly from a header or an SMB connector. Our input clock is TTL
> (0-5V) and is quite clean.
>
I would suggest trying a termination. Two possibilites.
1) As you have one destination (drop on the line) insert a source
termination series resistor (17-25 ohm) close to the Xilinx output. This
has the effect of cutting the incident wave by 1/2 then you get 100%
reflection at the far end, reconstructing the waveform. Then the line is
matched for the returning wave and the oscillation (undershoot) is
damped.
2) Try putting an end parallel AC termination at the far end (at the
instrument). (BTW check to see if the input to the test instrument is a
50 ohm or TTL input). You can try a 50 ohm and 180-220 pF series network
to ground in parallel with the instrument input. The only problem here
is that the Xilinx output )-1/12 mA is not really strong enough to drive
the term, so you may have to fiddle (lower) the Cap value.
Good luck,
Brian
-----------------------------------------------------------------------
Brian Lehman, P.Eng. Nortel Wireless Phone: (613) 763-7786
P.O. Box 3511, Station C, Ottawa, FAX: (613) 765-2592
Ontario, Canada K1Y 4H7 M/S 565 Internet:
bjlehman@nortel.ca
-----------------------------------------------------------------------
> Thanks in advance for any help.
> --
> Nestor Caouras
> nestor@ece.concordia.ca
Article: 11994First of all, thanks a lot to everybody who gave me advice on this topic. It helped a lot for my fundamental understanding of the matter. Meanwhile I've gathered data on Micron ZBT SRAMs, and I intend to use this type. For this reason, Ray, if you happen to come across those notes you mentioned, I'd still be interested in information on a problem with using ZBT. Presently, I don't see any. Thanks again, Stefan Ray Andraka wrote: > > When I last looked at the ZBT's for an application where I had interleaved read > writes there was an issue on the timing. I don't recall for sure, but I think > there was a dead cycle caused by the way I needed to access it. I'll look into > my notes and let you know what the issue was. Whatever it was, in that > particular case it was an expensive solution that didn't quite fix the > problem. (I was looking at the IDT parts, and that was right after they were > introduced). > > Stefan Ludwig wrote: > > > You can use ZBT (zero bus turnaround) sync SRAMs. They have no dead cycles > > and are just wonderful. Micron, Motorola and IDT make them. -- Stefan Rave Dept. of Computer Science University of Dortmund, Germany rave@LS12.cs.uni-dortmund.deArticle: 11995
Hi, Trying to test some PCI cards - it's not easy to probe signals etc when the card is stuck inside a normal PC with other PCI cards alongside ... Anybody found a better prototype PCI card test system set-up - i.e. one that allows easy access to both sides of the card being tested? Thanks for any pointers ... Andy Phillips Supercomputing Systems AG Zurich, SwitzerlandArticle: 11996
I had looked at the IDT71V508 when it was just announced. I thought there was an issue with timing of data in a certain sequence of reads and writes, but I sure don't see it now looking at the data sheet. I can't find the reason I rejected the part in my notes either. Now I'm wondering if it was just an availability or real-estate problem (I needed two banks of 64kx16 on each of 4 FPGAs). I wound up using 12ns 64Kx16 SRAMs running at 42 MHz interleaved read/write with a 4025E-2 in that application. It's possible I was recalling the original sync SRAMs that required a dead cycle. I must be getting old! In any event, looking again at the ZBT data sheet, I see no reason not to use them if you speed requirements justify the extra expense. You will have to be careful about clock skew because of the relatively fast clock to Q of the memory (you may need to turn on the input delay on xilinx, which will diminish the performance advantage). Stefan Rave wrote: > First of all, thanks a lot to everybody who gave me advice on this > topic. It helped a lot for my fundamental understanding of the matter. > > Meanwhile I've gathered data on Micron ZBT SRAMs, and I intend to use > this type. For this reason, Ray, if you happen to come across those > notes you mentioned, I'd still be interested in information on a problem > with using ZBT. Presently, I don't see any. > > Thanks again, > Stefan -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 11997
Andrew Phillips wrote: > > Hi, > > Trying to test some PCI cards - it's not easy to probe signals etc when > the card is stuck inside a normal PC with other PCI cards alongside ... > > Anybody found a better prototype PCI card test system set-up - i.e. one > that allows easy access to both sides of the card being tested? > > Thanks for any pointers ... > > Andy Phillips > Supercomputing Systems AG > Zurich, Switzerland Hi Andy, I have not had a need to do much card development lately, but when I was building/testing ISA card regularly, I really liked the card extenders that Digikey/Jameco and many others sell. These simply raise the card in the slot above the height of the others. In fact, the best arrangement came by simply chopping a slot in the side/top of the case and surrounding it with nonconductive edge guards so the case could be closed but my development slot was still accessible. Simple... but it worked. I am sure that PCI extender cards are available somewhere. Check Vector Electronics product line (Digikey is a distributer). Cheers, DanArticle: 11998
Hello, I am having a great deal of trouble with Viewlogic's EXPT1076 utility, a program which generates structural VHDL from a schematic. I cannot seem to make it generate legal VHDL for all types of schematic. One thing I do a lot in FPGA designs, is use arrayed components (attaching a $array attribute to a component, akin to a VHDL 'generate' statement). If I array a component, and then attach a bus to a pin (ie. data[3:0]), then the VHDL contains the individual components connected to nets data3, data2, data1, data0, (Viewlogic naming convention) but obviously, this should really be data(3), data(2), etc... There is an option to expand busses to individual nets, but this causes trouble when connecting a bus to a component with bussed i/o. Is arraying incompatible with expt1076, or does anyone have any past experience with this problem? Thanks, Matthew Robinson. mpQr@dolGby.com -- ----------------------- Sorry, but...remove the Q and G to reply to meArticle: 11999
Oops, forgot one thing. If I have a bus, and break off signals to connecto to components, the generated VHDL is as if I had done an array on the component. Ie. the labels are data0, data1, data2, etc... Thanks, Matthew mpQr@dolGby.com ------------------------- Sorry, but...remove the Q and G to reply to me Matthew Robinson wrote in message <6ubc3c$kf2$1@supernews.com>... >Hello, > >I am having a great deal of trouble with Viewlogic's EXPT1076 utility, a >program which generates structural VHDL from a schematic. I cannot seem to >make it generate legal VHDL for all types of schematic. > >One thing I do a lot in FPGA designs, is use arrayed components (attaching a >$array attribute to a component, akin to a VHDL 'generate' statement). If I >array a component, and then attach a bus to a pin (ie. data[3:0]), then the >VHDL contains the individual components connected to nets data3, data2, >data1, data0, (Viewlogic naming convention) but obviously, this should >really be data(3), data(2), etc... There is an option to expand busses to >individual nets, but this causes trouble when connecting a bus to a >component with bussed i/o. > >Is arraying incompatible with expt1076, or does anyone have any past >experience with this problem? > >Thanks, >Matthew Robinson. >mpQr@dolGby.com > >-- >----------------------- >Sorry, but...remove the Q and G to reply to me > >
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