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
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5r4stdF12jom4U1@mid.individual.net... > Hopefully some of you guys who have gone through this can > comment... > > We're doing our first board with a couple of DDRs and have a > query with ground plane coupling when routing the signals out > of the FPGA. > > We're hoping to get away with a 6 layer board so the stack is.. > > sig1 > GND > sig2 > sig3 > PWR > sig4 > > Any signals that're routed from the FPBA ball to sig4 won't have > the same good GND return paths to the FPGA that those coming out > on sig1/sig2 will have. > > We're aiming to run the interface at ~2* 120MHz. > > We don't have any simulation tools so are having to design using best > practice. > > We can place a GND island in on the PWR layer under the FPGA/DDR > with plenty of vias stitching it up to the 'real' GND plane, but > this will make the PWR routing more difficult. > > Does this matter, will the difference in GND coupling be a problem? > > Some of the app notes we've read suggest that the track impedance > isn't too much of a problem. > > > Thanks for any pointers, > > > Nial > Hi Nial, Wow, you got some strange answers! (IMHO, natch.) The same old chestnuts about PWR and GND planes being used as bypass capacitance. Waste of time. The tiny capacitance is no use to you as you have to attach the FPGA to it _VIA_ inductance. This is why FPGA companies embed bypass caps in the package. BTW, what PWR is on the plane? VCCO for your DDR bank? VCCINT? Also, 16-20 layer boards? I guess it'll work, but I'm glad I'm not paying for it. Good answers you got are, 'use two more layers', 'simulate', 'SI-LIST', and 'use as few vias as possible'. Oh, and don't cross gaps in planes, but we all know that, right? I'd do something like this:- sig gnd sig sig gnd sig I'd route the powers on one or two of the internal layers. I'd use copper pours and/or little puddles of cu for each supply. I'd use X2Y caps backside of the FPGA for bypassing. (Google X2Y FPGA) If a fast signal changes its ground reference from one ground plane to another, I'd put a GND via nearby. Several fast signals can share a single ground via. Austin's right, if you're a beginner you should certainly use a simulator. Maybe you can borrow one from somewhere? Any universities nearby? However, the 'two ground planes' design makes it considerably harder to get it wrong, especially at 120MHz. HTH. Syms. p.s. You did search back through CAF for previous threads, right? ;-)Article: 126626
> IMHO the lack of reset circuitry is a serious flaw. Bold statement :) More likely we don't know or understand their reasons for not including it. Every new thing added has a cost. I can guess at some reasons: -global routing networks are expensive, clearly they are justified for clocks, but reset? -this is reconfigurable hardware so following power up the FPGA is put into a known state following configuration - so is reset really required? -Reset can be coded into your design where needed. Providing resets on the inputs and outputs, and waiting for the pipeline/intermediate registers to flush gives the appearance of, and has the same effect as a design wide reset. Regards AndrewArticle: 126627
Andrew FPGA wrote (in response to the inabilty to use global clock nets
to drive FF resets:
> Every new thing added has a cost. I can guess at some reasons:
> -global routing networks are expensive, clearly they are justified for
> clocks, but reset?
I don't think anyone was proposing adding additional global nets. The
question is how expensive would it be to add either:
1) Additional routing resources within the CLB to allow an existing
global clock net to drive the FF reset
2) Additional routing resources within the CLB to allow an existing
global clock net to drive local lines, which could then be used
for logic and/or to drive the FF reset
Apparently the Virtex 4 and 5 have done one of these, so the answer
is that the cost isn't too high to preclude doing it in high-end FPGAs.
Maybe the cost is too much for Spartan series FPGAs, or maybe it will
appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts
said we'd get in 2007. Time's running out, guys! :-)
http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkproduct-Asia.html
Article: 126628On Nov 27, 10:41 pm, J=FCrgen B=F6hm <jbo...@gmx.net> wrote: > Jim Granville wrote: > > > You could download the Lattice Mico32, and reality check against that, > > as that is open source. > > Most FPGAs these days have multiport RAM, so it makes sense to optimise > > your architecture to use that - in your case for registers, and maybe > > even for micocode storage. > > Thank your for your answer: > Indeed I use RAMB16_S36 for microcode-storage, the final design will > probably need four of them, as the microcode is more than 36 bit wide. > The idea from the other posters to change to Virtex FPGAs is currently > not an option for me, as I really want to develop for the cheaper > Spartan platform, for which a lot of affordable boards are offered - if > necessary I will buy a board with the next larger Spartan 3 on it. If you are trying to fit a given device, then you need to use the full map and place portions of the tools as well. Only then will you know for sure that your design won't fit. But what part is on your board? You are using about 75% of available resources. I can't say for sure about your design, but ALU logic can be very light if designed properly. So the rest of your design may fit easily in the part. I designed my own 16 bit CPU to have minimal size and it was about 500 LUTs, IIRC. Like you, most of the logic was from muxes, so I kept them as small as possible, even to the point of eliminating some instructions. Having an extra, unused select line makes them twice as large. BTW, any unused inputs will be optimized out by the tools. So if you don't connect the select input or data inputs, that logic will not be generated.Article: 126629
"Symon" <symon_brewer@hotmail.com> wrote in message news:fikd12$uf7$1@aioe.org... > Wow, you got some strange answers! (IMHO, natch.) The same old chestnuts > about PWR and GND planes being used as bypass capacitance. Waste of time. > The tiny capacitance is no use to you as you have to attach the FPGA to it > _VIA_ inductance. This is why FPGA companies embed bypass caps in the > package. BTW, what PWR is on the plane? VCCO for your DDR bank? VCCINT? > I disagree, as does most of the research done into the subject. The use of buried capacitance, typically by having adjacent power and ground planes separated by as small a distance as possible (2 thou is normal), has been shown to be very favorable when compared to discrete decoupling caps because although the capacitance is much lower the inductance is very much lower so the overall impedence is significantly lower. There is an article about it here: http://www.ddmconsulting.com/Design_Guides/bcguide.pdf The requirement for discrete capacitors on the BGA substrate itself is a different matter. That is to compensate for the inductance of the BGA ball and tracking and is necessary regardless of how the board level decoupling is implemented.Article: 126630
Hi, I've instantiated some quartus memory in VHDL using the init_file generic to specify an intel hex file. This works great for 8-bit wide memory. However, I can't work out how to initialise 16- or 32-bit wide memory using this method!?! Has anyone done it before? Any tips would be greatly appreciated! TIA Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 126631
On Nov 26, 1:05 pm, <steve.l...@xilinx.com> wrote: > "rickman" <gnu...@gmail.com> wrote in message > > news:d1662618-8529-41c6-a716-d83b5fc791ac@w28g2000hsf.googlegroups.com...> On Nov 20, 6:22 pm, <steve.l...@xilinx.com> wrote: > >> A substantial amount of work is required for each appication when we > >> move away from Wind/U. We have decided not to do that for FPGA > >> Editor. Instead, we are creating a new application that is a combination > >> of PACE, Floorplanner, FPI, FPE and FPGA Editor. That will be > >> available in 11.1 (March 2009). > > >> Steve > > > I read that correctly as a year and a half from now, right? > > Yes. We plan to keep FPGA Editor around for a while so if there are > issues, let us know. Hopefully the issue that started this thread is > solved by the answer record provided. > That seems like a loooooong way off. I remember once being told that > > supporting partial reconfigurationon the Spartan devices was a few > > months off and that Xilinx was committed to it. > > I don't remember a commitement on Spartan support. We have it working > internally, but it's a very difficult flow and not something we are > prepared to support. The big difference between Spartan and Virtex is > that Spartan glitches when reconfigured. That means you need to isolate > partial regions including IO, and static routes cannot cross parial > regions. We are commited to Partial Reconfig for Virtex. I dug around and found that the Xilinx web site seems to contradict itself in regards to support for partial reconfiguration for Spartan 3 parts. Although the "PlanAhead" web page lists several lines of Spartan 3 parts as being supported by the PlanAhead software, I found these comments in the "PlanAhead Software as a Platform for Partial Reconfiguration" web page. "Partial reconfiguration is supported in both the Virtex and Spartan(tm) families. In this article, we will focus on implementing the partial reconfiguration methodology as it applies to Virtex-II and Virtex-II Pro FPGAs." So they really do shy away from describing in any way, partial reconfiguration for Spartan devices. I guess I will stick with my original belief that, for all practical purposes, in contradiction to what the Xilinx web site says, partial reconfiguration is not supported on Spartan devices.... still. BTW, if you would like to see where I was told, more than once, that Xilinx was committed to supporting partial reconfiguration on the Spartan 3 parts, I can forward the emails to you.Article: 126632
Jürgen Böhm wrote: > Jon Elson wrote: > >> >>Yes, wide adders use a lot of LUTs. Multiplexers use up LUTs too. A >>single 4-input LUT could form a single bit of a 2-input mux, wasting one >>input. If you need more inputs, then you have to combine several LUTs >>to perform one bit's worth of multiplexer. >> > > > Currently I have predominantly three (5bit select) x (32bit data size) > muxes with 16 alternatives select actually used (I overdimensioned the > muxes, as I did not exactly knew before having written the microcode, > how many inputs would be necessary). Are these muxes realized by > cascaded LUTs, and does your above remark imply, that a 5-stages-deep > chain of LUTs (1 stage for every select bit) will be used? I think it probably does a little better than that. Really, it breaks it down into basic boolean equations, and then minimizes them. So, it may make much more efficient use than what you describe above, and it probably gets better the more inputs you have. I think three LUTs can do a 4-input MUX, you can almost do it with 2 but are one input short. If you had 5 separate select inputs (like if you were originally designing for 5 tri-state drivers on a bus) that might be less efficient than using a 3-bit binary address for the MUX. But, if a binary address is decoded somewhere in your logic to the 5 select lines, that will all fall out in the logic minimization. JonArticle: 126633
Jürgen Böhm wrote: > Indeed I use RAMB16_S36 for microcode-storage, the final design will > probably need four of them, as the microcode is more than 36 bit wide. > The idea from the other posters to change to Virtex FPGAs is currently > not an option for me, as I really want to develop for the cheaper > Spartan platform, for which a lot of affordable boards are offered - if > necessary I will buy a board with the next larger Spartan 3 on it. Yup, the low-cost Spartan was my choice for some designs, too, as I really had no need for the special structures that the Virtex features. JonArticle: 126634
Nial Stewart wrote: > Hopefully some of you guys who have gone through this can > comment... > > We're doing our first board with a couple of DDRs and have a > query with ground plane coupling when routing the signals out > of the FPGA. > > We're hoping to get away with a 6 layer board so the stack is.. > > sig1 > GND > sig2 > sig3 > PWR > sig4 > I've had good results with : sig1 sig2 GND PWR sig3 sig4 If you really need to, you can make the traces on sig1 and sig4 a little wider to keep the impedance near the right value. Keeping GND and PWR planes close together helps. If sig1 and sig2 are orthogonal, and same for sig3 and sig4, there should be minimal crosstalk. I have not done a DDR memory, but signal integrity is signal integrity. JonArticle: 126635
Jürgen Böhm wrote: > Indeed I use RAMB16_S36 for microcode-storage, the final design will > probably need four of them, as the microcode is more than 36 bit wide. You can use a single BRAM as a 72-bit wide single-ported RAM, if you only need half the "depth". For instance, normally the maximum width of a Spartan 3 BRAM would be 512x36, but you can combine the two ports to get 256x72. Obviously if you need greater depth or dual-port this won't help you. EricArticle: 126636
>I've instantiated some quartus memory in VHDL using the init_file generic >to specify an intel hex file. This works great for 8-bit wide memory. > >However, I can't work out how to initialise 16- or 32-bit wide memory >using this method!?! Here is an example of a .MIF (not Intel hex) file which initialises 36-bit wide memory: Width = 36; Address_radix = Hex; Data_radix = Hex; % Character shapes % Content BEGIN 0000 : 000000000; 0001 : 000000000; 0002 : 000000000; : : (bulk of this file omitted) : 01F6 : 0600C00C0; 01F7 : 380000000; 01F8 : 0000001E2; 01F9 : 37623C000; 01FA : 000000000; 01FB : 000000000; 01FC : 000000000; 01FD : 000000000; 01FE : 000000000; 01FF : 000000000; END;Article: 126637
MikeShepherd564@btinternet.com wrote: > Here is an example of a .MIF (not Intel hex) file which initialises > 36-bit wide memory: Thanks Mike, but I want to use intel hex, not MIF, mainly because the intel hex can be used for both synthesis and simulation in ModelSim. I think I've found the answer anyway. For now I create an 8-bit wide intel hex file, then open the hex file in Quartus and use the memory size wizard to change it to 32 bits, then re-save the file. I'm yet to confirm it produces the results I expect, but at least it builds now... Since I use my own utility to create intel hex files in the first place, I'll simply modify it to produce the same output as Quartus... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 126638
"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in message news:78b49268-a7ec-409c-b5c0-c61003164231@n20g2000hsh.googlegroups.com... > On Nov 27, 9:43 pm, fl <rxjw...@gmail.com> wrote: > - Code that's just _not_ syntesizable : > > process > begin > wait until reset='0'; > wait for 3 ns; > sig <= '1'; > end process; > The only reason the above code could be considered 'just _not_ syntesizable' is because the behaviour of 'sig' prior to getting to where it is assigned has not been defined and is a design error that one would fix while still in simulation. But given that code, if the synthesizer wants to assume that 'sig' defaults to 1 then it would synthesize to 'sig' always being '1'. If instead it assumed that 'sig' defaults to '0' then it is again synthesizable with an inverter and a 3 ns delay line. If market pressure causes the FPGA suppliers to start adding delay lines to their parts then the above code can be targeted to one of those devices, if not it can still be implemented with commercially availabe parts so it is not 'just _not_ syntesizable' it's just not supported by FPGA software at this time....but there are a whole slew of things that are not supported, and those are typically bugs/limitations/whatever with the software that result in web cases to the support lines when I run across them. The end result of that is they improve their tool. Things like delay lines would be added as functional blocks when (if) there is sufficient market demand for that function. > - Code that may / may not be (i.e. if the synthesizer was smart, he > could do it ... but it might not be ) > > a <= b / c; > Again, an example not of unsynthesizable code but of perfectly valid and synthesizable code that a particular supplier may not support for their own various reasons. > VHDL is a hardware description language. Meaning that you should _not_ > use it to describe what you want the hardware to do. But you should > use it to describe the hardware you want built. I want the tools to figure out the proper bitstream that needs to be loaded into a part so that a vast array of RAM look up tables, transistors and flip flops inside that device will implement what I want it to do. In order to do that I describe functionally what I want the hardware to do, I definitely do not describe the hardware that I want built (i.e. the look up table contents, transistor on/off states, etc....and I doubt I'm alone in that regard). KJArticle: 126639
xchecker was obsoleted in release 4.1i The last software version that supported xchecker was release 3.3i (about 8 years ago) Florian wrote: > Hi > > I have Xilinx ISE 7.1 and wanted to use the Xilinx XChecker cable to > connect to the JTAG interface. Unfortuantely this does not work when I > use autoconnect. When I try to manually configure the connection I cant > choose the XChecker cable. Is this not supported any more with ISE 7.1? > > Cheers!Article: 126640
On Nov 28, 3:16 pm, John_H <newsgr...@johnhandwork.com> wrote: > posedg...@yahoo.com wrote: > Are you designing a board with a production run of three that you'll be > assembling with the toaster-oven technique? > > If you're using a professional assembly house, there is post-assembly > testing that will test for shorts. If you have a production run too > small for a bed-of-nails tester, there are still flying-lead > manufacturing defect analyzers that can check your board for shorts. > > Why design in "protection" that limits your signal characteristics when > all you're protecting from is manufacturing faults? If you were cycling > connecting the FPGA in and out of a connector over and over to varying > equipment, I could understand some concern. But for soldered-on chips? It's for a test setup, where I will test different fpga <-> device setups. No production run at all, not even a prototype one. I have bought a 100 ohm series resistor net package. Which will limit any shorts to 33mA. And I think the rise times will be ok with this. t = RC = 100*10pF (worst case Sp3E) = 1ns. The sp3e datasheet says max 100mA, I hope this will protect the fpga for those minutes it takes to test the setup.Article: 126641
> We're aiming to run the interface at ~2* 120MHz. I understand that as 120 MHz clock, 240 MHz data rate during bursts. Recently I had a similar case - processor (not FPGA), which is in a 256 ball FPGA, 133 MHz clock/266 MHz data burst rate. However, I was much more conservatiive with my stackup. Instead of your > sig1 > GND > sig2 > sig3 > PWR > sig4 I did 6 layers as well, but my stackup is: signal GND PWR PWR GND signal Worked the first time, actually see the prototype (very first one assembled, design for an external customer) board here: http://tgi-sci.com/y2demo/PICT3007sc.JPG . The two DDRAMs (x16 each) are close to the board centre, easy to spot. Here is the bare board in some better detail: http://tgi-sci.com/misc/PICT0605.JPG . The board is routed at 6 mil most of the time which goes down to somewhat over 4 mil for the worst case angular ring and for traces between BGA pads (3 traces between a pair of 1.27mm spaced pads/vias. Have used these rules on other boards as well, have never failed me. Routing takes somewhat more head scratching (or is it hear teraing... :-) ), but has always been doable. Now what do I do with a 0.8mm BGA (soon to be routed here, never done so far) is yet to be seen... :-) At these low speeds, buying signal integrity tools/consultants will be a sheer waste. You need neither (although ask that on the SI list and you will be overwhelmed by suggestions to buy all things imaginable... make sure to ignore such advice, the SI tool writers and SI consultants are pretty active on that list). Buy a tool by the usual criterion, that is, only if you know exactly what you want the tool to do for you and if you understand how it will do it. Buying a software blindly expecting it to solve your problems will typically result in more, not less problems. Which does not mean most people nowadays are not doing exactly that, of course :-). Again, 120 MHz is nearly DC nowadays. You don't need any fancy SI tools to do it. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ On Nov 28, 12:06 pm, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > Hopefully some of you guys who have gone through this can > comment... > > We're doing our first board with a couple of DDRs and have a > query with ground plane coupling when routing the signals out > of the FPGA. > > We're hoping to get away with a 6 layer board so the stack is.. > > sig1 > GND > sig2 > sig3 > PWR > sig4 > > Any signals that're routed from the FPBA ball to sig4 won't have > the same good GND return paths to the FPGA that those coming out > on sig1/sig2 will have. > > We're aiming to run the interface at ~2* 120MHz. > > We don't have any simulation tools so are having to design using best > practice. > > We can place a GND island in on the PWR layer under the FPGA/DDR > with plenty of vias stitching it up to the 'real' GND plane, but > this will make the PWR routing more difficult. > > Does this matter, will the difference in GND coupling be a problem? > > Some of the app notes we've read suggest that the track impedance > isn't too much of a problem. > > Thanks for any pointers, > > NialArticle: 126642
Mike wrote: > Hi > > I am using Impact and Xilinx Multilinx cable to communicate to my FPGA > board. I was able that the connection to the board is established, but > somehow I just see a CPLD instead of a Virtex II FPGA board. Anyone an > idea how to have access to the FPGA that is hosted on the board? > > Cheers Connect your cable to the JTAG chain that the FPGA is hooked up to. You couldn't be much more vague. Whether it's a development board or your own board, you should be able to find schematics. These schematics may show the JTAG pins of the FPGA (TDI, TDO, TCLK, TRST or similar names) either unconnected or connected to a specific JTAG connector or JTAG chain. If you can identify which chain, you're on your way. If you are connected to the correct chain and you don't see the device, there's something wrong on the application side (not configuring things properly?) rather than the hardware side. - John_HArticle: 126643
Mark McDougall wrote: > MikeShepherd564@btinternet.com wrote: > >> Here is an example of a .MIF (not Intel hex) file which initialises >> 36-bit wide memory: > > Thanks Mike, but I want to use intel hex, not MIF, mainly because the > intel hex can be used for both synthesis and simulation in ModelSim. > > I think I've found the answer anyway. For now I create an 8-bit wide intel > hex file, then open the hex file in Quartus and use the memory size wizard > to change it to 32 bits, then re-save the file. I'm yet to confirm it > produces the results I expect, but at least it builds now... > > Since I use my own utility to create intel hex files in the first place, > I'll simply modify it to produce the same output as Quartus... > > Regards, > Mark- I've used 8-, 16-, 24-, and 32-bit wide Intel hex files with Quartus. The general format is (spaces for readability--not in file): - -- ---- -- ~~ -- -- -- : nn addr 00 ** cs <cr><lf> \ data records : 00 0000 01 ff <cr><lf> \ end record - -- ---- -- ~~ -- -- -- where nn = number of data bytes in memory word addr = 16-bit memory address 00, 01 = record type ** = nn data bytes cs = 100h - (byte.sum mod 256) The tools will complain if you don't initialize more OR less than the full memory. -JohnArticle: 126644
Hi, I have a design that works fine in Quartus. In the process of porting it to ISE, I'm getting a series of these warnings and can't for the life of me work out why... An example: WARNING:Xst:647 - Input <vblank> is never used. But it clearly _is_ being used!?! Same for all the other signals that it's complaining about. Normally I'd suspect a missing clock but that doesn't appear to be the case. (For the record the clock for this process isn't actually meeting all timing constraints at the moment.) Any tips would be appreciated - it's driving me (more) insane! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 126645
John Rible wrote: > I've used 8-, 16-, 24-, and 32-bit wide Intel hex files with Quartus. > The general format is (spaces for readability--not in file): > - -- ---- -- ~~ -- -- -- > : nn addr 00 ** cs <cr><lf> \ data records : 00 0000 > 01 ff <cr><lf> \ end record > - -- ---- -- ~~ -- -- -- > where nn = number of data bytes in memory word > addr = 16-bit memory address > 00, 01 = record type > ** = nn data bytes > cs = 100h - (byte.sum mod 256) > > The tools will complain if you don't initialize more OR less than the > full memory. The format I've been using for 8-bit data is 16 bytes/record. I tried all sorts of permutations of that for 32-bit wide memory some time back but never got it to work. In the end I settled for 4x 8-bit memory blocks. Now it's time to fix it properly. Using Quartus to re-size my 8-bit intel hex file did the trick. It basically spat out 1 word/line in the format you specify above. FYI it does let you initialise *less* than the full block, as long as the word size is correct... BTW I wish Xilinx memories were as easy to specify and initialise as Quartus... I'm porting some projects and it's a real PITA! Thanks for your assistance! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 126646
How can i interface the cyclone III with 2.5v LVDS to 3.3v LVDS adc & dac ? ThanksArticle: 126647
> Have used these rules on other boards as well, have never > failed me. Routing takes somewhat more head scratching (or is > it hear teraing... :-) ) Sorry for the typos above, it should read "or is it hair tearing"... On Nov 29, 4:33 am, Didi <didi...@gmail.com> wrote: > > We're aiming to run the interface at ~2* 120MHz. > > I understand that as 120 MHz clock, 240 MHz data rate > during bursts. > Recently I had a similar case - processor (not FPGA), > which is in a 256 ball FPGA, 133 MHz clock/266 MHz data burst > rate. > However, I was much more conservatiive with my stackup. > Instead of your > > > sig1 > > GND > > sig2 > > sig3 > > PWR > > sig4 > > I did 6 layers as well, but my stackup is: > > signal > GND > PWR > PWR > GND > signal > > Worked the first time, actually see the prototype > (very first one assembled, design for an external customer) > board here: > > http://tgi-sci.com/y2demo/PICT3007sc.JPG. > > The two DDRAMs (x16 each) are close to the board centre, easy > to spot. > > Here is the bare board in some better detail: > > http://tgi-sci.com/misc/PICT0605.JPG. > > The board is routed at 6 mil most of the time which goes > down to somewhat over 4 mil for the worst case angular > ring and for traces between BGA pads (3 traces between a > pair of 1.27mm spaced pads/vias. > Have used these rules on other boards as well, have never > failed me. Routing takes somewhat more head scratching (or is > it hear teraing... :-) ), but has always been doable. > Now what do I do with a 0.8mm BGA (soon to be routed here, > never done so far) is yet to be seen... :-) > > At these low speeds, buying signal integrity tools/consultants > will be a sheer waste. You need neither (although ask that on > the SI list and you will be overwhelmed by suggestions to > buy all things imaginable... make sure to ignore such advice, > the SI tool writers and SI consultants are pretty active on that > list). > Buy a tool by the usual criterion, that is, only if you know > exactly what you want the tool to do for you and if you > understand how it will do it. > Buying a software blindly expecting it to solve your problems > will typically result in more, not less problems. Which does > not mean most people nowadays are not doing exactly that, > of course :-). > > Again, 120 MHz is nearly DC nowadays. You don't need any > fancy SI tools to do it. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > > On Nov 28, 12:06 pm, "Nial Stewart" > > <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > Hopefully some of you guys who have gone through this can > > comment... > > > We're doing our first board with a couple of DDRs and have a > > query with ground plane coupling when routing the signals out > > of the FPGA. > > > We're hoping to get away with a 6 layer board so the stack is.. > > > sig1 > > GND > > sig2 > > sig3 > > PWR > > sig4 > > > Any signals that're routed from the FPBA ball to sig4 won't have > > the same good GND return paths to the FPGA that those coming out > > on sig1/sig2 will have. > > > We're aiming to run the interface at ~2* 120MHz. > > > We don't have any simulation tools so are having to design using best > > practice. > > > We can place a GND island in on the PWR layer under the FPGA/DDR > > with plenty of vias stitching it up to the 'real' GND plane, but > > this will make the PWR routing more difficult. > > > Does this matter, will the difference in GND coupling be a problem? > > > Some of the app notes we've read suggest that the track impedance > > isn't too much of a problem. > > > Thanks for any pointers, > > > NialArticle: 126648
On Nov 21, 4:55 am, Joseph Samson <u...@not.my.company> wrote: > spygam...@gmail.com wrote: > > Hi! > > > I am using Dual Port Block Memory in Virtex-II, V8.2. During > > simulation in Modelsim, i have encountered an error that reports to me > > is: > > > $recovery(posedge clk B: .... ps, posedge clk A &&& > > collision_posa_posb: ... ns, 1ns); > > > How can i cater this issue and how can i remove this error in my > > simulation??? > > What have you tried and and why didn't it work? > > Here's what I did: > > 1. Google "verilog $recovery" > > 2. Read the first citation > <http://toolbox.xilinx.com/docsan/xilinx5/data/docs/sim/sim0066_10.html> > > --- > Joe Samson > Pixel Velocity hi sir! thnx for your anticipation...........i am using dual port memory to receive data from camera and pass it onto DSP..........and during simulation in ModelSim there is an error like: # ** Error :C:/Xilinx/Verilog/mti_se/XilinxCoreLib_ver/ XilinxCoreLib_ver_source.v(27060):$recovery(posedge clk B: .... ps, posedge clk A &&& collision_posa_posb: ... ns, 1ns); # Time ... ps Iteration : 2 Instance/tb/dsp_inst0/memory_dp_inst0/inst and thats error repeated after every some time period delay and remained at the end of simulation...........plz guide me how can i get through from this error??? RegardsArticle: 126649
On Wed, 28 Nov 2007 10:06:22 -0000, "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote: >Hopefully some of you guys who have gone through this can >comment... > >We're doing our first board with a couple of DDRs and have a >query with ground plane coupling when routing the signals out >of the FPGA. > >We're hoping to get away with a 6 layer board so the stack is.. > >sig1 >GND >sig2 >sig3 >PWR >sig4 > >Any signals that're routed from the FPBA ball to sig4 won't have >the same good GND return paths to the FPGA that those coming out >on sig1/sig2 will have. > >We're aiming to run the interface at ~2* 120MHz. > >We don't have any simulation tools so are having to design using best >practice. > >We can place a GND island in on the PWR layer under the FPGA/DDR >with plenty of vias stitching it up to the 'real' GND plane, but >this will make the PWR routing more difficult. > >Does this matter, will the difference in GND coupling be a problem? > >Some of the app notes we've read suggest that the track impedance >isn't too much of a problem. > > >Thanks for any pointers, > > >Nial > > > As Jon suggests, putting power and ground adjacent is generally a bit better. But either stackup will work fine. As long as the power plane (or its split pours) is pretty well bypassed to ground, the signals can't tell the difference between them or ground as the "return" plane. If power and ground are adjacent layers, the increased plane-plane capacitance keeps them a bit more equipotential at very high frequencies. Don't worry about signals crossing small slits on a split power plane; that is simply not an issue in real life. You can barely resolve crossings like that on a 20 GHz TDR... it's down in the wiggles caused by the fiberglass weave. We've done pretty hairy stuff with Xilinx bga's on 6 layers, with no signal integrity problems. The thing to watch out for is signal-signal crosstalk, especially on clock lines. Clocks need especially serious signal integrity treatment these days. And "clocks" includes CCLK! I suppose I could post some layer pics... John
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