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
Gabor wrote: >>> http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf >> This looks like the circuit that Gabor posted last May. It should >> work just fine. > It is the same circuit ... Two people - one idea. Sorry, I did not know, that you posted a similar circuit - I have done it months ago, too. ;-) > , but why are two of the three XOR gates drawn > as 2-input multiplexers with an iverter? It is only because I think it is more readable and may help to understand the idea. I am certain the synthesis tool will choose the best way of implementation. RalfArticle: 100251
John, Thank you for your input. It has helped tremendously. Hopefully, just one more question. When I do this: BUS_INTERFACE SFSL0 = my_fsl_incoming BUS_INTERFACE MFSL0 = my_fsl_outgoing I get these two errors, which I think is at the root of the confusion. ERROR:MDT - fsl_v20 (my_fsl_incoming) - C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 197 - must have atleast 1 master assigned! ERROR:MDT - fsl_v20 (my_fsl_outgoing) - C:\Xil_Proj\Bal_Con\Current_Sense\PWM2\system.mhs line 210 - must have atleast 1 slave assigned! For now, to fix it, I've done this: BUS_INTERFACE MFSL0 = my_fsl_incoming BUS_INTERFACE SFSL0 = my_fsl_incoming BUS_INTERFACE SFSL1 = my_fsl_outgoing BUS_INTERFACE MFSL1 = my_fsl_outgoing Any comments on the errors or my solution? Thanks, DaleArticle: 100252
> What's more time efficient then going to your EDK and just adding an OPB_USB > peripheral? I was just asking why such a thing doesn't appear to exist. But, > yes, I agree I strayed off topic. hmm, I have created an OPB_USB peripheral a few years ago. This should answer the question if this is possible or not. In case you have special applications that utilize a lot of bandwidth, this might still be a good idea. Unfortunately, my solution was based on USB 1.1, i.e. 12Mbps. And in order to avoid any speculation on size, please refer to this site: http://homepage.mac.com/f.bertram/usb_core.html Regarding USB 2.0, i.e. 480Mbps, the structure looks a little different. The PHY will already include the clock recovery (which is one of the more critical parts of a USB core), and provide parallel data to the attached devices. In case you are wondering if the higher layers of a USB 1.1 controller could be reused: USB 2.0 defines a few more tokens, so the state machines would need to be extended to support these. Regarding firmware: To get a simple HID device recognized by Windows, you would need about 1kB of 8051 assembly code. This is not too critical, and there is plenty of good samples out there. Best regards, Felix -- Dipl.-Ing. Felix Bertram http://homepage.mac.com/f.bertramArticle: 100253
This is looking pretty cool, except for the price :( fpga_toys@yahoo.com wrote: > http://www.fpgajournal.com/articles_2006/20060404_nios.htm http://www.reed-electronics.com/electronicnews/article/CA6321594.html http://www.altera.com/corporate/news_room/releases/products/nr-niosII_c2h_compiler.html http://www.altera.com/literature/wp/C2H_Compiler_FAQ.pdf http://www.altera.com/literature/wp/C2H_backgrounder.pdfArticle: 100254
John Larkin schreef: > And if I had the Verilog, the first thing I'd do is grab a piece of > paper and sketch it out to understand what it does. > > Some people think verbally, some visually. > > John OK, so say I wanted a low pass, and wrote: /* 12.5 MHz clock chroma lowpass */ `define F0 0 `define F1 -2 `define F2 2 `define F3 8 `define F4 -3 `define F5 -21 `define F6 5 `define F7 80 `define F8 127 `define F9 80 `define F10 5 `define F11 -21 `define F12 -3 `define F13 8 `define F14 2 `define F15 -2 `define F16 0 module fir( clock, fir_in, fir_out); wire clock; input fir_in; output fir_out; wire [7:0] fir_in; reg [7:0] fir_out; reg [31:0] temp; reg [7:0] sm0; reg [7:0] sm1; reg [7:0] sm2; reg [7:0] sm3; reg [7:0] sm4; reg [7:0] sm5; reg [7:0] sm6; reg [7:0] sm7; reg [7:0] sm8; reg [7:0] sm9; reg [7:0] sm10; reg [7:0] sm11; reg [7:0] sm12; reg [7:0] sm13; reg [7:0] sm14; reg [7:0] sm15; reg [7:0] sm16; always @(posedge clock) begin sm16 = sm15; sm15 = sm14; sm14 = sm13; sm13 = sm12; sm12 = sm11; sm11 = sm10; sm10 = sm9; sm9 = sm8; sm8 = sm7; sm7 = sm6; sm6 = sm5; sm5 = sm4; sm4 = sm3; sm3 = sm2; sm2 = sm1; sm1 = sm0; sm0 = fir_in; temp = (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) + (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) + (`F7 * sm7) + (`F8 * sm8) + (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) + (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16 * sm16); fir_out = temp / 512; end ---------- How would you draw that? It is interesting to note that xst will synthesize this, and it works, and does not even take that much space...... But I am sure somebody will scream.... heheArticle: 100255
On Wed, 05 Apr 2006 10:07:12 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >And if I had the Verilog, the first thing I'd do is grab a piece of >paper and sketch it out to understand what it does. My problem with block diagrams is that I can never simplify an algebraic expression when all '+'s and '*'s are shown as blocks. I recently did a simplification on some complex arithmetic data-path which reduced the number of 32x32 multiplications from 33 to 26 which enabled me to use one less multiplier (over 16 cycles). I don't think it could've done it without first converting the schematic to text and then work out the algebra (if the design were in schematics to start with that is ;-)Article: 100256
Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > Jim Granville wrote: > >>Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > > > [ ... snip ...] > > >>>Spartan-3E FPGAs behave differently. >> >>Whilst we are on this subject, to this detail, >>can you give some info on how does Spartan 3E differ, and why ? >> >>-jg > > > The only difference is in the DLL phase shifter feature included with > the DCM. Most everything else is identical between Spartan-3 and > Spartan-3E DCMs. > > There's a summary of the differences in the following Answer Record, > but I'll follow up here with the abbreviated version. > http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004 > > In FIXED phase shift mode, the difference depends on which version ISE > that you are using, as described in the data sheet and the Answer > Record. Physically, the Spartan-3 DLL performs a fixed phase shift by > as much as a full clock cycle forward or backward. The Spartan-3E DLL > performs a fixed phase shift by as much as _half_ a clock cycle forward > or backward. For nearly all applications, the Spartan-3E half-clock > shift provides the same flexibility as the full clock shift, but with > significantly less silicon. > > In VARIABLE phase shift mode, the difference is that the Spartan-3 DLL > performs a variable phase shift in fractions of a clock period, 1/256th > of a full circle. Think degrees, angles, radians, using your favorite > angular unit. Extra logic within the Spartan-3 DLL calculates the > delay line change. The Spartan-3E DLL also performs a variable phase > shift using a delay line. However, in Spartan-3E, you have raw control > over the delay. The shift is always in time, not in some angular unit. Thanks, When you say time for 3E, do you mean 'calibrated time', or some multiple of a ~30-60ps delay chain ? I can see that the extra logic in the -3, (should?) track temp/Vcc changes - or does it grab the multiplier only when the DCM is reset ? How does the -3E manage temp/vcc/process variations, or does the user do that ? -jgArticle: 100257
Jim, The tap state machine is always trying to keep one entire period in one of the delay lines. This way, the unit is always self calibrating, it always "knows" how many taps equals one period. So when you ask for 23/256 of a period shift, the arithmetic unit solves for the closet tap (truncating). To make the silicon take up less space, the delay line itself is optimized to not change over the PVT (as much as it would otherwise). How this is done is the subject of issued patents, so for those that are curious, they can look these up. Austin Jim Granville wrote: > Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: > >> Jim Granville wrote: >> >>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: >> >> >> >> [ ... snip ...] >> >> >>>> Spartan-3E FPGAs behave differently. >>> >>> >>> Whilst we are on this subject, to this detail, >>> can you give some info on how does Spartan 3E differ, and why ? >>> >>> -jg >> >> >> >> The only difference is in the DLL phase shifter feature included with >> the DCM. Most everything else is identical between Spartan-3 and >> Spartan-3E DCMs. >> >> There's a summary of the differences in the following Answer Record, >> but I'll follow up here with the abbreviated version. >> http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=23004 >> >> In FIXED phase shift mode, the difference depends on which version ISE >> that you are using, as described in the data sheet and the Answer >> Record. Physically, the Spartan-3 DLL performs a fixed phase shift by >> as much as a full clock cycle forward or backward. The Spartan-3E DLL >> performs a fixed phase shift by as much as _half_ a clock cycle forward >> or backward. For nearly all applications, the Spartan-3E half-clock >> shift provides the same flexibility as the full clock shift, but with >> significantly less silicon. >> >> In VARIABLE phase shift mode, the difference is that the Spartan-3 DLL >> performs a variable phase shift in fractions of a clock period, 1/256th >> of a full circle. Think degrees, angles, radians, using your favorite >> angular unit. Extra logic within the Spartan-3 DLL calculates the >> delay line change. The Spartan-3E DLL also performs a variable phase >> shift using a delay line. However, in Spartan-3E, you have raw control >> over the delay. The shift is always in time, not in some angular unit. > > > Thanks, > When you say time for 3E, do you mean 'calibrated time', or some > multiple of a ~30-60ps delay chain ? > I can see that the extra logic in the -3, (should?) track temp/Vcc > changes - or does it grab the multiplier only when the DCM is reset ? > > How does the -3E manage temp/vcc/process variations, or does the > user do that ? > > -jg > >Article: 100258
Anonymous wrote: > Dumb question: Since USB is just a two wire serial interface and all the USB > solutions I've seen are simple, though speedy, microcontrollers why can't > the USB be inside the fpga? Seems like you can instantiate a small micro > running at 50 mhz or so with code in a couple block rams to do what the fx2, > for example, does. Apparently, doesn't exist so there must be some reason? It's a little more complex than simply two wires between two devices. USB signalling is half-duplex differential, and high-speed signalling is different than full-speed and low-speed. Also, there are some instances where single-ended signalling is used and the driver must be capable of doing this and the receiver has to be able to detect these states. -aArticle: 100259
Austin Lesea wrote: > Jim, > > The tap state machine is always trying to keep one entire period in one > of the delay lines. This way, the unit is always self calibrating, it > always "knows" how many taps equals one period. > > So when you ask for 23/256 of a period shift, the arithmetic unit solves > for the closet tap (truncating). > > To make the silicon take up less space, the delay line itself is > optimized to not change over the PVT (as much as it would otherwise). > > How this is done is the subject of issued patents, so for those that are > curious, they can look these up. Yes, I can follow that for the -3, but Steve was suggesting the 3E was slightly different, so I was wanting to clarify the deails. -jg >>>> Steve Knapp (Xilinx Spartan-3 Generation FPGAs) wrote: >>> The Spartan-3E DLL also performs a variable phase >>> shift using a delay line. However, in Spartan-3E, you have raw control >>> over the delay. The shift is always in time, not in some angular unit.Article: 100260
John- > XST may support the initial block: > initial > begin > reg_array[0] = 4'h1; > reg_array[1] = 4'h9; > ... > end > > They *do* support initial assignment to simple registers: > reg [3:0] RegArrA = 4'h1; > reg [3:0] RegArrB = 4'h9; Thanks for the reply. Yes single reg initialization works Ok. But I've not figured out yet how to init one or more that are part of an array declaration. I recall that in the past XST has referred to a register bit as something like reg_array_0, and that could be used in the INIT attribute, but I don't know XST's method for specifying an array element, or a bit within an array element. -JeffArticle: 100261
Thank you Brian - pointers to answer records and the past thread greatly appreciated.Article: 100262
Petter, Actually the new ieee1532 bsdl file does describe the programming algorithm. It is required when you use Xilinx JDrive software to program a device. Please view the file: "xc18v01_1532.bsd". Not only does it describe to programming algotithmn, but it also gives the codes for the ISC instructions used for programming. Dave Colson "Petter Gustad" <newsmailcomp6@gustad.com> wrote in message news:87d5g08dhp.fsf@gustad.com... > "David Colson" <dscolson@rcn.com> writes: > >> This is the ieee1532 bsdl file that describes the programming >> algorithm. for the xc18v00. Using this file and an understanding of >> the JTAG interface, you maybe able to decipher how to program your >> device. > > The BSDL file does not describe the programming algorithm. It just > describes the boundry scan registers (some which are used for > programming). > > I would not call this decipher, but using the SVF file and the JTAG > state machine you can extract how to program the device. The SVF file > describes how to select the programming registers and the contents of > these registers, the JTAG state machine describes how to shift data > into boundry-scan registers. > > e.g. if you toggle TMS and TDI according to this model: > > http://www.gustad.com/petter/18v01.v > > you should end up with what is described by the SVF given by the O.P. > > Petter > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail?Article: 100263
MK- On the other hand, Slurp's great-looking example was mostly data flow -- block diagrams are extremely good for depicting signal processing and other data-driven algorithms. You could take your optimized Verilog and go back to schematic form again and still be able to see what's going on. But not so for protocols, state machines, bus switching, and other "control flow". All control flow paths must be shown in a schematic, making it difficult to clearly recognize one path or another and either focus on it or ignore it -- something easy to do with an "if else" in code or a "decision block" in a flow diagram. -JeffArticle: 100264
John_H wrote: > > The Spartan3E should give great results for those signals in spite of the > capacitance issues that nag at other engineers. > Well, outputs don't have as much of a problem with Cpin as have inputs driven from a fast logic family; but you already know that :) IIRC, the Lattice ECP2 have current mode LVDS drivers and ~8pF Cin. I've been hoping that the removal of DCI from S3E has improved Cin; when Xilinx releases the S3E IBIS models, we can get a better idea. It's interesting to contrast the datasheet C values for the two families: Cyclone-II Cio 6 pF (typ) user I/O Clvds 6 pF (typ) user I/O with LVDS Cvref 21 pF (typ) user I/O with Vref function Cclk 5 pF (typ) global clock input Spartan-3E Cin 3 pF (min) 10 pF (max) Which makes no distinction between input only pins, I/O pins, global clock input pins, left/right side clock pins, dual mode config pins, Vref pins, dedicated config pins, etc. Other S3E notes: - the strangely low SSO limit (4) for the current mode drivers has reappeared for some of the S3E family, after improving in the latest S3 family SSO tables - no IBIS models !! - I haven't spotted any characterization data for the DT terminator accuracy; just the ~120 ohm number with no min or max limits BrianArticle: 100265
On 5 Apr 2006 14:00:24 -0700, panteltje@yahoo.com wrote: > >John Larkin schreef: > > >> And if I had the Verilog, the first thing I'd do is grab a piece of >> paper and sketch it out to understand what it does. >> >> Some people think verbally, some visually. >> >> John >OK, so say I wanted a low pass, and wrote: > >/* 12.5 MHz clock chroma lowpass */ >`define F0 0 >`define F1 -2 >`define F2 2 >`define F3 8 >`define F4 -3 >`define F5 -21 >`define F6 5 >`define F7 80 >`define F8 127 >`define F9 80 >`define F10 5 >`define F11 -21 >`define F12 -3 >`define F13 8 >`define F14 2 >`define F15 -2 >`define F16 0 > > >module fir( clock, fir_in, fir_out); >wire clock; >input fir_in; >output fir_out; > >wire [7:0] fir_in; >reg [7:0] fir_out; >reg [31:0] temp; > >reg [7:0] sm0; >reg [7:0] sm1; >reg [7:0] sm2; >reg [7:0] sm3; >reg [7:0] sm4; >reg [7:0] sm5; >reg [7:0] sm6; >reg [7:0] sm7; >reg [7:0] sm8; >reg [7:0] sm9; >reg [7:0] sm10; >reg [7:0] sm11; >reg [7:0] sm12; >reg [7:0] sm13; >reg [7:0] sm14; >reg [7:0] sm15; >reg [7:0] sm16; > > >always @(posedge clock) >begin > sm16 = sm15; > sm15 = sm14; > sm14 = sm13; > sm13 = sm12; > sm12 = sm11; > sm11 = sm10; > sm10 = sm9; > sm9 = sm8; > sm8 = sm7; > sm7 = sm6; > sm6 = sm5; > sm5 = sm4; > sm4 = sm3; > sm3 = sm2; > sm2 = sm1; > sm1 = sm0; > sm0 = fir_in; > >temp = > (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) + > (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) + (`F7 * sm7) + > (`F8 * sm8) + (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) + > (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16 >* sm16); > >fir_out = temp / 512; >end > >---------- >How would you draw that? > The same way people drew FIR filters before HDLs were invented. It's very simple and very intuitive... looks just like an analog transversal filter. JohnArticle: 100266
John_H wrote: > Hello folks, > > I may be starting my first Altera design in a few years but I was > disappointed to find that the Cyclone-II LVDS drivers aren't true > differential drives: an external resistor network is needed to produce > proper LVDS levels like in the "old days." > > Does anyone here have experience with the LVDS drivers? I imagine I'll end > up with 0603 resistors rather than a Bourns network, for instance. What > have others used? You could use the quad-smd's = 4 resistors in 1206 or 0805 ? -jgArticle: 100267
This may not be the correct method to do it; but why dont you look at the synthesized output (synthesizing is done with out including the INIT part) and find out the name of the registeres you want to initialise. And then use INIT in the code with that name. Try to use INIT in the ucf. Also you can use microsoft excel to generate INIT strings if the array is large. regards Sumesh V SArticle: 100268
ALuPin@web.de wrote: > Hi, > > I want to know what approach you would recommend to > compress an incoming DVI data stream (data width 24 bit, pixel clock > 25-165MHz) > from 24 bit colour depth to 16 bit colour depth. > > The DVI data are stored as 64 bit chunks into DDR memory at 133MHz. > For higher resolutions (fPIX > fDDR) I would like to reduce the colour > depth > so that performance (frame rate) at the read side of the DDR memory > (image > display) is not downgraded in such a way that moved images judder. > > Are there algorithms for parallel data processing (24bit/16bit) you > can recommend ? > > Any hints are appreciated. > > Rgds > André > Hi, You might consider converting the input (RGB?) data to YUV and downsampling the resulting chroma channels to either 4:2:0 (12 bits/pixel) or 4:2:2 (16 bits/pixel) format. The conversion can be implemented efficiently using distributed arithmetic (or directly if you have multipliers to spare), though you should think carefully about chroma buffering requirements when going back to RGB for display. This assumes you have a 24 bit display to drive and want good quality through the "compression" process. If not dropping bits as other posters have suggested is a nice simple solution. Cheers, Andy.Article: 100269
Is the audio codec on the virtex-ii pro board a good choice for real-time audio processing? I designed an application that reads the ac97 input in PPC, filters signals in the fpga, and then plays them back to speakers. I compared the real-tim performance between my design and having everything done in software(PPC), and it seems to me they have similar execution time. I was hoping that by using the fpga for the filtering computation, the overall speed would improve. This is true when I only measured the part where the computation is done, but not for the overall execution time (read/write ac97 and filter signals). Is it because ac97 I/O slows down the speed? Does this have anything to do with the limited bus speed (100Mhz) between PPC and fpga? I'd appreciate for any pointers. Thanks!Article: 100270
100 ns is the propagation delay after which the FDDRCPE output changes when inputs are applied. This is observed in the timing simulation in the Modelsim.. The output of FDDRCPE doesn't change for that initial delay (around 104 ns to b precise), eventhough valid inputs are applied..And all the subsequent changes at the inputs get reflected after that much delay.. I'm also openning a webcase to get the answer.. John_H wrote: > 100ns is 10 MHz. This isn't correct. What do you see that tells you "100 > ns?" ...tool, verbiage. > > "Milind" <milindt@gmail.com> wrote in message > news:1144248035.095781.142510@v46g2000cwv.googlegroups.com... > > Hi, > > > > I found that the delay value of the element FDDRCPE is 100 ns after > > running a timing simulation. > > > > Is it supposed to be so high? > > (to confirm it, I also ran a separate simulation of this single element > > and with different clk frequencies) > > > > FDDRCPE is "Dual Data Rate D Flip-Flop with Clock Enable and > > Asynchronous > > Preset and Clear", used when interfacing DDR with FPGA. It is present > > in the simlibs library. > > > > I'm using ISE 8.1 (and found the same thing in 7.1 too) > > > > If it is supposed to be that high, what may be the reason behind it? > > > > See a related post here: > > > > http://groups.google.co.in/group/comp.arch.fpga/browse_thread/thread/790b589a01726678/66426daa7240b82e?lnk=st&q=fddrcpe&rnum=3&hl=en#66426daa7240b82e > > > > Thanks and Regards, > > Milind > >Article: 100271
Sumesh- > This may not be the correct method to do it; but why dont you look at > the synthesized output (synthesizing is done with out including the > INIT part) and find out the name of the registeres you want to > initialise. And then use INIT in the code with that name. Try to use > INIT in the ucf. Also you can use microsoft excel to generate INIT > strings if the array is large. Thanks very much Sumesh, that was a good idea. I located the registers in the RTL schematic, and I found that I can do: reg [3:0] reg_array [3:0]; // synthesis attribute INIT of reg_array is 8'h17 which I'm hoping will initialize the first 2 registers in the array. But this: // synthesis attribute INIT of reg_array_0_0 is 1'b1 still gets the XST "ignored" message (I was hoping it might initialize the first bit in the first register). Questions for anyone: 1) Does XST allocate an array of registers starting with least-significant index? 2) Is there some Xilinx documentation on this that I'm just not finding? App notes? Something else? -JeffArticle: 100272
ptkwt@aracnet.com (Phil Tomson) writes: > I seem to recall that there are some open source bitstream downloaders > available for Linux... don't have any URL handy right at the moment, though. xc3sprog supports Spartan 3 parts: http://www.rogerstech.force9.co.uk/xc3sprog/ There are several other programs which are derived from an earlier program called ljp: JOLT: http://www.science-and-technology.nl/research/jolt/ xilinx-jtag: http://cas.et.tudelft.nl/~rene/xilinx-jtag.c Rudolf Usselmann's version of ljp: http://www.asics.ws/tools/ljp.c.gzArticle: 100273
Jim Granville wrote: > John_H wrote: > >> Hello folks, >> >> I may be starting my first Altera design in a few years but I was >> disappointed to find that the Cyclone-II LVDS drivers aren't true >> differential drives: an external resistor network is needed to produce >> proper LVDS levels like in the "old days." >> >> Does anyone here have experience with the LVDS drivers? I imagine >> I'll end up with 0603 resistors rather than a Bourns network, for >> instance. What have others used? > > > You could use the quad-smd's = 4 resistors in 1206 or 0805 ? > > -jg I could use "a Bourns network" or the like. I anticipate using 0603s because they're small, available, routable. Unless there's experience that says these tiny discretes should, indeed, be a resistor network instead. I could use the quad-smd's. Is there a reason I should? Shouldn't? I'm hoping more for tidbits of experience rather than good ideas. Thanks for the thoughts.Article: 100274
Brian Davis wrote: > - the strangely low SSO limit (4) for the current mode drivers has > reappeared for some of the S3E family, after improving in the > latest S3 family SSO tables I noticed the SSO numbers but they don't affect me this round. The specs are "per power/ground pair" which is ample on the BGA packages (7 effective pairs per bank?) but still allows 8 SSOs on the wireframe parts (2 pairs ber bank). I interpreted that as LVDS pairs, so 16 signal lines per bank. Oops. I just remembered - there are only 4 banks on the Spartan3E. Yikes! The pairs per bank are 1.4x-2x the Spartan3 values so it looks like they may be legit. I sure hope those SSOs get changed!!! ____ Larger Cyclone-IIs have 8 banks but they also have some strange single-ended / differential restrictions within a bank. Odd stuff. Maybe not a problem, but odd. The Lattice parts are looking *nice* but are a bit low on memory for what I want to prototype. I was looking seriously at the new devices until I realized the breadth of the memory disparity. I could use a larger part with more memory but then the costs go up.
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