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
Hi,
There seems to be an endless numbers of way to mess up CRC calculations!
Has anyone come up with the right way to match a software calculated CRC
with whay comes out of either the 'easics' core or the 'outputlogic' core
(both yielding the same result in simulation).
Here are questions:
-should I reverse or inverse the input data? What order?
-should I reverse or inverse the output data? What order?
Here is a great online tool, but I cannot match the output with the core,
ever:
http://www.zorc.breitbandkatze.de/crc.html
I'm using
CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 +
x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
Thanks
Diego
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 145276dlopez <d@n_o_s_p_a_m.designgame.ca> wrote: > There seems to be an endless numbers of way to mess up CRC calculations! > Has anyone come up with the right way to match a software calculated CRC > with whay comes out of either the 'easics' core or the 'outputlogic' core > (both yielding the same result in simulation). > Here are questions: > -should I reverse or inverse the input data? What order? > -should I reverse or inverse the output data? What order? Initialize the shift register with what value? When processing bytes, LSB or MSB first? > Here is a great online tool, but I cannot match the output with the core, > ever: > http://www.zorc.breitbandkatze.de/crc.html > I'm using > CRC-32: 0x04C11DB7 = x32 + x26 + x23 + x22 + x16 + x12 + > x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 I have done the ethernet CRC (CCITT CRC32) and verified that it agreed with what it should do. -- glenArticle: 145277
First picture of Prog3, our USB programming solution for Xilinx, is now available on our website http://www.enterpoint.co.uk/programming_solutions/prog3.html. We are awaiting a delivery of cases before any more will ship to customers but that should be sorted out before the end of the month. Prog3 operates with Xilinx software and does not need anything else to use this programmer. John Adair Enterpoint Ltd.Article: 145278
Steve I'll start by pointing you at Raggedstone1 http://www.enterpoint.co.uk/moelbryn/raggedstone1.html as an example of what can be done in 4 layers with a 456 pin BGA. At speeds of 10-25Mhz I generally just about count that as DC and don't really do anything other that what we do normally and that is hand route. Handrouting, using your brain, gives much better results - less vias, shorter tracks and so on and contributes a lot to a good result. Frightening as might seem even our Merrick1 product with about circa 18,000 routes is done that way. If you can get away with just the outer 2 rows of ball you should be able to use a "slack" technology of maybe 6mil/0.150mm track and gap and that will save you money at manufacture. On power split planes is a good technique if used very carefully but using polygon fills on tracking layers will also help. On the Raggedstone1 mentioned above there are something like 7 different power rails under BGA and that was one the major difficulties with that design so it's all possible. Later FPGA families do help by reducing the need for so many rails. On buses versus individual interfaces I would do buses at 25MHz. At 100MHz+ I would go the other way usually. John Adair Enterpoint Ltd. - Home of Drigmorn3. The Spartan-6 Starter Board. On 4 Feb, 05:22, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > Hi guys.. I'm getting ready to start working on my first board layout > with a BGA package (FG456). First will be a prototype for sure. > I was just wondering a few things... > > Probably the critical part of my design will be interface to a few > asynchronous SRAMs. > > In a relatively low speed design (buses at 10-25MHz) do I need to > worry about things like termination and trace length on the RAM buses? > Should I dedicate address/data pins to each chip in a shared memory > space, or is it better to daisy chain them on a bus? (It seems to me > that routing will be a little easier if each chip gets its own > lines..) > > If I won't be using the innermost IO pins, can I get away with a 4- > layer design, two signal layers and power/ground? > > Looking at a Xilinx app note with a suggested escape route for this > package, they have three signal layers with 5 mil width traces, the > third of which I believe I can do without... > And lastly, I guess that I will be needing 1.8 and 2.5V supplies, as > well as 3.3V for all of my I/O supplies.. should these all be routed > in the dedicated power layer? If the layer is mostly covered a plane, > which voltage is supposed to be the plane? 3.3V? > > And lastly, when connecting I/Os, is there any sensible approach? My > tendency is to want to choose the I/Os so that everything lines up > nicely, but I find it to be a hassle in this case, that in Eagle we > have to connect nets in the schematic first and can't back-annotate > from the board. > > Anything else I should be worrying about? > > Cheers, > > SteveArticle: 145279
> Try to make room for bypass caps on the back of the board from the FPGA. You can use 0402 resistors with 0.6mm round pads on 1mm centres. This allows thm to be placed on the back of the BGA 'matching' the BGA pads, and allows almost one cap per power & gnd pair. Check with your assembly house that they're happy with this, mine does it no problem (they built a couple of boards with 0.5mm pads before telling me to make them bigger). NialArticle: 145280
On 19 Jan, 19:14, moogyd <moo...@yahoo.co.uk> wrote: > Hello, > > I am seeing a problem using ISE. I have a verilog top level with pins > including N0, N1, N2, N3, N4 (similar for PX, SX and MX) > > I add a LOC constraint in the UCF file for all pins. For some reason, > the tool seems to be confused by N1, N2, N3 and N4 (but not N0, or any > of PX, SX, MX) > > WARNING:NgdBuild:483 - Attribute "LOC" on "N1" is on the wrong type of > object. > =A0 =A0Please see the Constraints Guide for more information on this > attribute. > > When I report the pinout at the end of the P&R, pins N1..N4 have > disappeared, and I have some new pins (N31, N18, N21, N18) > > My *guess* is that Xilinx uses Nx (x>0) for internal netnames, and it > is getting confused. > > Can anyone confirm and suggest a workaround? (I don't want to change > the pin names) > > Thanks, > > Steven Hi, FYI, this problem seems to be fixed with ISE 11.1 StevenArticle: 145281
> >Prog3 operates with Xilinx software and does not need anything else to >use this programmer. > >John Adair >Enterpoint Ltd. > Does it run under linux? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145282
It's not been tried on a Linux system here as yet but as it is driver compatible with the Xilinx cable there is a good chance it will work anywhere their cable or software works (with the usual Linux restrictions). John Adair Enterpoint Ltd. On 4 Feb, 16:40, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com> wrote: > >Prog3 operates with Xilinx software and does not need anything else to > >use this programmer. > > >John Adair > >Enterpoint Ltd. > > Does it run under linux? > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.comArticle: 145283
Hello, I have a design based on a EP2SGX30 FPGA, with a CFI Flash connected to it, in order to store the functional program. I'm trying in vain to program this Flash (Numonyx TE28F320J3D75) using the Altera flash programmer. I followed the instructions given in the User's Guide, and the programmer is reading the CFI table correctly, but when it comes to actual programming, it stops at 0%, with the following message : Program failed Error code : 4 in .....nios2flashprogrammer.exe .... In parallel, we have been running read and write tests on the flash and they are passing. Thus we suspect that something is wrong with the flash programmer... would you have any idea of what we need to check and what we can do to have a bit more visibility of what's going on within this soft ? Thanks in advance for your help, Pascal.Article: 145284
Hi *, I recently designed a board with a Virtex 5 on it, which I got back from the assembly line a few days ago. This is not the first board I've designed, and I've used many FPGA-boards from others before, but I've never come across this problem: FPGA configuration via JTAG will only work if the bitfile is generated with the DONE_cycle=6 option set. If I leave the default setting of 4, iMPACT will happily download the bitstream and will claim everything was successful. I can read back the bitstream, read out device ID and usercode, but the device itself is dead, i.e. none of the IOs are responding and so on. With ChipScope you can read out the internal configuration status register, and as it turns out it seems that using the default bitgen settings, FPGA configuration stops in cycle 4 when done goes high, but does not reach the states where the IOs are enabled and so on. The question is: Why is that? Is it a bug in iMPACT? Does it stop clocking the configuration logic too soon? If so, why doesn't this happen on any other boards? The board itself works flawlessly, I just want to make sure there's no underlying design issue I'm missing that can cause this. Does anyone have any insight into this? cu, SeanArticle: 145285
Hey folks, Just updated my web page for a new little DSP/Audio FPGA project I've got going: http://members.cox.net/ebrombaugh1/synth/dsPIC_fpga/index.html It's a little 3"x3" 2-layer board with a dsPIC and Spartan 3A part, along with a Micro-SD card (for storing the FPGA bitstream and other data), analog input circuits and an audio DAC. Target application is voltage-controlled audio synthesis, but there are a lot of opportunities for other projects because I've got lots of uncommitted I/O. Some of the things I'm trying out with this one: * dsPIC access to FAT filesystem on SD flash (works pretty well) * Spartan 3A with only 2 supplies (seems to work OK so far) * dsPIC control of an FPGA via SPI or parallel * SPI Flash interfacing to an FPGA for wavetable storage. Initial hardware checkout is done and I'm going to start working on some audio synthesis circuits next. Comments/questions invited! EricArticle: 145286
>Thank you. I've checked it with the dealers and you have right, it is >for the educational institutions. > >However - if anyone is interested - i've found a cheaper alternative: >Digilent XUP USB-JTAG Programming Cable has the same capabilities and >works with the iMPACT software. > >have a nice day, > >Dave The Digilent device emulates Xilinx Platform Cable (DLC9G, or HW-USB-G), not the Platform Cable II (DLC10, or HW-USB-II-G). The biggest differences, AFAICT, are: 2mm (DLC10) vs 0.1 inch (DLC9) signal header on the pod ability to assert *PROG pin on FPGA while programming SPI directly (DLC10 only) - Bob --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145287
I'm using the MegaWizard plugin manager on Quartus II 9.1 on linux and I can't get it to generate any Verilog files for me. It does generate VHDL files. There is an option to generate Verilog but it generates VHDL as far as I can see.Article: 145288
Sean, Do you have the "wait for DCM's to lock before releasing DONE" option set? Sometimes this gets in the way, as the part is waiting for LOCKED before it even releases GTS, and GSR. Easier is to force the DCM's to reset after DONE goes high by driving reset with a startup signal that you generate. By moving DONE till after GTS, you are getting the DCM's to start up ... or that is my best guess. AustinArticle: 145289
On 2/4/2010 1:41 PM, Nial Stewart wrote: >> Try to make room for bypass caps on the back of the board from the FPGA. > > > You can use 0402 resistors with 0.6mm round pads on 1mm centres. > > This allows thm to be placed on the back of the BGA 'matching' the > BGA pads, and allows almost one cap per power& gnd pair. > > Check with your assembly house that they're happy with this, mine does it > no problem (they built a couple of boards with 0.5mm pads before telling > me to make them bigger). > > > > Nial > I'll second that. It works for me. Make the pad size the limit of the PCB fab's spec. Cheers, Syms.Article: 145290
Awesome, thanks for the good information! John, I don't think I can get away with only the outer two rows of balls, I'll probably need the two inside of that as well-- I was thinking of breaking out the outer two on one signal layer and the inner two in another, as suggested in the Xilinx app note I saw. It was a tight squeeze but they wrote .127mm traces, and .3/.6mm on the vias, which is the standard offering of the board house we're using.. it's possible to ask for smaller, for an extra chunk of change. Are there any examples out there of how to route memory chips on a bus? I'm kind of new to routing and don't really know what the strategy is for this kind of thing. I was thinking about this when designing a board to interface to expansion headers on a dev board for a first prototype, but I couldn't think of a way to do it with just two layers, so I gave each chip its own lines in that case since I had plenty of I/O. I can imagine a scheme in which there are vias on each line going into the first chip, connecting to wires on another layer to carry the lines to the other chip where they are brought back to the component side with more vias, but that's all I can come up with off the top of my head RCIngham, thanks for the heads-up on the EEPROM. I guess that the idea is to have non-volatile data in it, and copy it to a section of SRAM on power-up and then just read from SRAM during normal operation, but I will still probably have to think about the time to 'Z' when designing that data transfer part of the software. cheers, SteveArticle: 145291
> > Are there any examples out there of how to route memory chips on a > bus? I'm kind of new to routing and don't really know what the > strategy is for this kind of thing. I was thinking about this when > designing a board to interface to expansion headers on a dev board for > a first prototype, but I couldn't think of a way to do it with just > two layers, so I gave each chip its own lines in that case since I had > plenty of I/O. Now that I think of it, I suppose I could make the bus connection job a little simpler if I take advantage of the fact that RAM is "random access," so the address/data line numbers from chip to chip don't necessarily have to match up. Then the address/data lines could be connected in whatever order is easiest and cleanest, since on the FPGA side the data would go in and come out in the desired order either way. Would this for any reason be a bad design practice? SteveArticle: 145292
Xilinx claims:
We recommend the use of IBIS models whenever possible. IBIS models for
many devices are often available as free downloads. Using IBIS
provides the following:
* Faster simulation speed.
* Elimination of non-convergence.
* Strong support from virtually all EDA vendors.
Well, when I use ltspice for the simple things I check, simulation
speed and non-convergence are non-issues. And the claimed "Strong
support from virtually all EDA vendors" isn't really a reason to
*prefer* IBIS (as is implied) but is really more of a rationalization
about why IBIS really isn't that much worse than spice.
Now, I know that the statement is probably quite factual, especially
since ltspice doesn't actually come from an EDA vendor. But, ltspice
is my preferred analog simulation tool, and I would love to have a
Xilinx Spartan 3A pin model that works with it.
Alas, I see IBIS models for all the FPGAs, but spice models for only a
few. If there weren't any IBIS models for the Spartan 3A, I might
think that one of the Virtex spice models would suffice, but the
disparity between the IBIS model list and the spice model list at
http://www.xilinx.com/support/download/index.htm gives me pause.
Any thoughts?
Thanks,
Pat
Article: 145293What version of the programmer are you using? When Numonyx took over from Intel they changed the programming. If you download the latest programmer from Altera, I think 9.1 you should be all set. Pascal_Olive wrote: > Hello, > > I have a design based on a EP2SGX30 FPGA, with a CFI Flash connected > to it, in order to store the functional program. > > I'm trying in vain to program this Flash (Numonyx TE28F320J3D75) using > the Altera flash programmer. > > I followed the instructions given in the User's Guide, and the > programmer is reading the CFI table correctly, but when it comes to > actual programming, it stops at 0%, with the following message : > > Program failed > Error code : 4 in .....nios2flashprogrammer.exe .... > > In parallel, we have been running read and write tests on the flash > and they are passing. > > Thus we suspect that something is wrong with the flash programmer... > would you have any idea of what we need to check and what we can do to > have a bit more visibility of what's going on within this soft ? > > Thanks in advance for your help, > > Pascal.Article: 145294
On Feb 4, 4:04=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > Thanks for the input so far, guys! > > I will have two SRAM chips and one parallel EEPROM in one memory > space, and one additional RAM chip in a separate memory space so I > know for sure that that one gets its own dedicated address/control/ > data lines. > I was just wondering if the signal integrity would be hurt by extra > loading in chaining up the ones that are on the same bus, but I had a > hunch that at these speeds it wouldn't be such a big problem. Signal integrity is not normally a direct result of the "loading" of the parts. On most boards the effect of a pin on a bus is minimal. If you split a run, like a fork in a river, it results in an impedance mismatch and causes a reflection. The end of a trace is a high impedance which also is an impedance mismatch and causes a reflection. Three chips can be added to the board with trances as short as maybe 2 inches. This is 4 inches round trip or about half a ns. To avoid effects of reflection, the edge transition time should be at least 3 ns. That is a *slow* edge. So expect noticeable ringing. As has been said, on the data and address lines, you just need to extend the setup times to wait it out to sample the bus when it has quieted down. Figure three round trips or 1.5 ns extra. But the write enable signal should be clean. The best way I know to do that is to provide a separate write enable driver for each chip. Then you can use series impedance matching in a point to point wiring so that the receiver does not see any effects from reflection. Of course this is assuming the write enable is the controlling pin when doing writes. Some designs use the chip select to control the write timing. > And probably I will be using 10ns RAMs (I haven't looked at the rise/ > fall times though) and keeping them physically as close as I can get > them to the FPGA.. maybe about a centimeter away, tops. > Looking at this old Digilent Spartan 3 board I have kicking around, I > don't see any termination between the FPGA and the ISSI SRAMs on > there, but each chip has its own address and data lines.. I dunno if > that's good enough to use as an example or not though. Are you going to try to use them as fast as possible? That can be hard. If you can give each chip separate drivers for all signals, may be able to keep the traces short enough to not see any reflection effects. I may have muffed the math on this. That's the trouble with rules of thumb. If you recall them incorrectly, it can be hard to spot the error. Looking at this document, http://techcircuits.net/docs/CriticalLength.pdf It looks like I was overly pessimistic on the length. The rule of thumb seems to be 1/3 instead of 1/6 so a 1 ns rise time won't cause significant reflections, but I'm not sure about that. On page 7 they use an analysis that I don't agree with. Basically, they are saying this is the critical edge of timing and I don't think it is that clear cut. I say use 1/6, but you can choose your own poison. > As for the supply voltages, I'll be using a Virtex II, but this is the > first time I have started to think about implementing my own board and > thus needing to worry about power supplies, and I seemed to remember > some of my dev boards in the past having a couple or three different > regulators on board, but I didn't really think much about it. Looking > at the datasheet though, you're right, Rick, it appears that I just > need a single 1.5V supply for core voltage, and 3.3V for VCC_aux and > all of my I/O. I should have checked that and had the numbers right > before asking, sorry about that. I would pick a newer family myself, but there is nothing wrong with a Virtex II device. However, a newer family will be faster, lower power and you will likely get better support. Of course you can overdo that too. If you try to use the newest family, you may not get parts for months and the tools may be a bit buggy... But Virtex 2??? Why not Virtex 5 or even Virtex 4? The Spartan 3 chips are pretty good and have been updated quite a bit although I don't recall which are the latest and greatest. I know the S3 parts are FAPP not recommended for new designs (at least by those of us here I expect) and the S3A parts are pretty old at this point. Anyone, what are the newer S3x parts? If you want to keep the power supply simple, Lattice has XP and perhaps XP2 parts that use a single 3.3 volt supply and internally drop it to the core voltage. > So if I need power planes for both of these voltages, do they each > need their own layer or can I arrange it carefully in one layer? Yes, you can use one layer. I have a very tiny board <1" x 4.5" with no less than four power planes on one layer, +12, +5, +3.3 and an audio 3.3. There is another 1.8 volt plane in case I want to use an FPGA with separate core voltage inputs, but that plane is on a different layer shared with signal traces. I can't stress enough the importance of power planes in keeping switching noise down. It is not just a matter of adding a high frequency capacitor to the power rail, it acts as a very low impedance transmission line connecting the capacitors to the power pins of the chip. It is counter intuitive, but it actually is not so important to keep the caps so close to the chip if you are using good power planes. BTW, to maximize the effectiveness of the power planes (read that as minimum impedance) you want to have the power and ground plane as close together as possible. 5 mils spacing should be practical and will go a long way to doing a good job. I found doing layout to be fun, but very intense! Most design requires you to go back and forth between specs and data sheets and the schematic capture package. Layout has some up front work getting all the inputs and making the footprints, but then it just becomes a really complex rubics cube with many possible solutions. Your job is to find one that is pretty good without spending tons of time on it. When I did my first layout, I contacted a couple of colleges and asked them to do a design review with me. I was willing to pay them consulting rates, but I was turned down. It turned out ok in the end, but there were a couple of things that likely would have been caught in a review. I am not very busy right now. If you would like and when you are ready, I'd be willing to go through a design review with you without charge. I'm pretty bored and would enjoy it. RickArticle: 145295
On Feb 4, 5:28 am, Symon <symon_bre...@hotmail.com> wrote: > On 2/4/2010 8:23 AM, David Brown wrote: > > > > > > > You have a lot more experience at this sort of thing than me, Rick, so > > I'm a little wary of disagreeing with you. But I'm sure you'll tell me > > if I get something wrong! > > > I don't see that you have to worry about any termination here. With fast > > enough signal edges, you can get ringing - but that typically will not > > matter because you don't sample the signals until the ringing has > > subsided. > > > Ringing can cause a few problems - the overshoot/undershoot can go > > outside the voltage range of the pins on the line, it can cause > > interference for neighbouring signals, you can't read the signal while > > it is ringing, and it can cause big trouble when connected to > > edge-sensitive inputs. But most of these are not going to be a problem > > in your case, I think. > > Dear David, Steve, > > Going "outside the voltage range of the pins on the line" can break the > device. IIRC there are Xilinx appnotes which go into this problem in > some detail; powering 3.3V with 3V was something I think they suggested! > (See XAPP653) > Also, the thing will probably fail any sort on electromagnetic > compliance test that you would need to do before you sell this. And you > are unlikely to be able to listen to 'The Archers' while this thing is > in the room. > > To the OP, in the absence of micro-vias, I would recommend a 6 layer > board. Maybe like this:- > > signal > signal > ground > ground > power/signal > signal > > Keep all the layers as close together as your PCB manufacturer allows > and make up the board thickness with the core between the two ground > layers. Xilinx on the top. Route the powers, or use copper pours. Try to > make room for bypass caps on the back of the board from the FPGA. This > stack up will make it very difficult for a beginner to go wrong from an > SI point of view, as ground is always near. This is particularly true if > you have a nice spread of ground vias tying the two ground planes > together. That doesn't mean you shouldn't simulate it with Hyperlynx, > but I bet that won't happen! Always examine your ground plane pair at > the end of the routing process to make sure you haven't cut any big > slots in it with string of vias. > > Finally, _real_ engineers use DRAMs! ;-) > > HTH., Syms. > > p.s. Did I make it clear that the ground is important? Everyone has their own way of doing things, but I would ask, why the two ground planes? I would have a ground plane and a power plane in the center with a minimum thickness between them. The spacing between the ground/power plane and the signal plane is not so important. What is important is the characteristic impedance. The lower the impedance, the less it will radiate. Of course, with thin traces you have to have the signal plane to power/ground plane very small to get a low impedance. But if you have wide traces, you can open up the plane spacing. Since the outer layers are on the outside of the board, they won't be very close to inside power/ground planes. BTW, you are aware that the power plane is just as effective as the ground plane for determining the impedance. RickArticle: 145296
On Feb 4, 9:43=A0pm, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > > Are there any examples out there of how to route memory chips on a > > bus? I'm kind of new to routing and don't really know what the > > strategy is for this kind of thing. I was thinking about this when > > designing a board to interface to expansion headers on a dev board for > > a first prototype, but I couldn't think of a way to do it with just > > two layers, so I gave each chip its own lines in that case since I had > > plenty of I/O. > > Now that I think of it, I suppose I could make the bus connection job > a little simpler if I take advantage of the fact that RAM is "random > access," so the address/data line numbers from chip to chip don't > necessarily have to match up. Then the address/data lines could be > connected in whatever order is easiest and cleanest, since on the FPGA > side the data would go in and come out in the desired order either > way. > Would this for any reason be a bad design practice? > > Steve In response to your other post about the bus timing, async memories are the hardest to design I have found. Sync memories like SDRAM are a snap really, you just meet the setup and hold times and you are done! The rest is all just a state machine. Async busses require all sorts of timing numbers to be checked, I bet you will have over 30 numbers you will need to validate while doing this. If you don't push the timing to the max it can be much easier. As to the randomization of the address/data lines, I have never done that, but others have. On the RAMs it shouldn't be a problem. It can even be worked around on the EEPROM if you have a program to remap all the bits in the memory map, but that is such a PITA. Getting your schematic to optimize the layout without randomization of the lines shouldn't be a real problem. RickArticle: 145297
On Feb 5, 2:26=A0pm, rickman <gnu...@gmail.com> wrote: > On Feb 4, 4:04=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > > > Thanks for the input so far, guys! > > > I will have two SRAM chips and one parallel EEPROM in one memory > > space, and one additional RAM chip in a separate memory space so I > > know for sure that that one gets its own dedicated address/control/ > > data lines. > > I was just wondering if the signal integrity would be hurt by extra > > loading in chaining up the ones that are on the same bus, but I had a > > hunch that at these speeds it wouldn't be such a big problem. > > Signal integrity is not normally a direct result of the "loading" of > the parts. =A0On most boards the effect of a pin on a bus is minimal. > If you split a run, like a fork in a river, it results in an impedance > mismatch and causes a reflection. =A0The end of a trace is a high > impedance which also is an impedance mismatch and causes a > reflection. =A0Three chips can be added to the board with trances as > short as maybe 2 inches. =A0This is 4 inches round trip or about half a > ns. =A0To avoid effects of reflection, the edge transition time should > be at least 3 ns. =A0That is a *slow* edge. =A0So expect noticeable > ringing. =A0As has been said, on the data and address lines, you just > need to extend the setup times to wait it out to sample the bus when > it has quieted down. =A0Figure three round trips or 1.5 ns extra. =A0But > the write enable signal should be clean. =A0The best way I know to do > that is to provide a separate write enable driver for each chip. =A0Then > you can use series impedance matching in a point to point wiring so > that the receiver does not see any effects from reflection. =A0Of course > this is assuming the write enable is the controlling pin when doing > writes. =A0Some designs use the chip select to control the write > timing. > > > And probably I will be using 10ns RAMs (I haven't looked at the rise/ > > fall times though) and keeping them physically as close as I can get > > them to the FPGA.. maybe about a centimeter away, tops. > > Looking at this old Digilent Spartan 3 board I have kicking around, I > > don't see any termination between the FPGA and the ISSI SRAMs on > > there, but each chip has its own address and data lines.. I dunno if > > that's good enough to use as an example or not though. > > Are you going to try to use them as fast as possible? =A0That can be > hard. =A0If you can give each chip separate drivers for all signals, may > be able to keep the traces short enough to not see any reflection > effects. =A0I may have muffed the math on this. =A0That's the trouble wit= h > rules of thumb. =A0If you recall them incorrectly, it can be hard to > spot the error. =A0Looking at this document, > > http://techcircuits.net/docs/CriticalLength.pdf > > It looks like I was overly pessimistic on the length. =A0The rule of > thumb seems to be 1/3 instead of 1/6 so a 1 ns rise time won't cause > significant reflections, but I'm not sure about that. =A0On page 7 they > use an analysis that I don't agree with. =A0Basically, they are saying > this is the critical edge of timing and I don't think it is that clear > cut. =A0I say use 1/6, but you can choose your own poison. > > > As for the supply voltages, I'll be using a Virtex II, but this is the > > first time I have started to think about implementing my own board and > > thus needing to worry about power supplies, and I seemed to remember > > some of my dev boards in the past having a couple or three different > > regulators on board, but I didn't really think much about it. Looking > > at the datasheet though, you're right, Rick, it appears that I just > > need a single 1.5V supply for core voltage, and 3.3V for VCC_aux and > > all of my I/O. I should have checked that and had the numbers right > > before asking, sorry about that. > > I would pick a newer family myself, but there is nothing wrong with a > Virtex II device. =A0However, a newer family will be faster, lower power > and you will likely get better support. =A0Of course you can overdo that > too. =A0If you try to use the newest family, you may not get parts for > months and the tools may be a bit buggy... =A0But Virtex 2??? =A0Why not > Virtex 5 or even Virtex 4? =A0The Spartan 3 chips are pretty good and > have been updated quite a bit although =A0I don't recall which are the > latest and greatest. =A0I know the S3 parts are FAPP not recommended for > new designs (at least by those of us here I expect) and the S3A parts > are pretty old at this point. =A0Anyone, what are the newer S3x parts? > > If you want to keep the power supply simple, Lattice has XP and > perhaps XP2 parts that use a single 3.3 volt supply and internally > drop it to the core voltage. > > > So if I need power planes for both of these voltages, do they each > > need their own layer or can I arrange it carefully in one layer? > > Yes, you can use one layer. =A0I have a very tiny board <1" x 4.5" with > no less than four power planes on one layer, +12, +5, +3.3 and an > audio 3.3. =A0There is another 1.8 volt plane in case I want to use an > FPGA with separate core voltage inputs, but that plane is on a > different layer shared with signal traces. =A0I can't stress enough the > importance of power planes in keeping switching noise down. =A0It is not > just a matter of adding a high frequency capacitor to the power rail, > it acts as a very low impedance transmission line connecting the > capacitors to the power pins of the chip. =A0It is counter intuitive, > but it actually is not so important to keep the caps so close to the > chip if you are using good power planes. =A0BTW, to maximize the > effectiveness of the power planes (read that as minimum impedance) you > want to have the power and ground plane as close together as > possible. =A05 mils spacing should be practical and will go a long way > to doing a good job. > > I found doing layout to be fun, but very intense! =A0Most design > requires you to go back and forth between specs and data sheets and > the schematic capture package. =A0Layout has some up front work getting > all the inputs and making the footprints, but then it just becomes a > really complex rubics cube with many possible solutions. =A0Your job is > to find one that is pretty good without spending tons of time on it. > > When I did my first layout, I contacted a couple of colleges and asked > them to do a design review with me. =A0I was willing to pay them > consulting rates, but I was turned down. =A0It turned out ok in the end, > but there were a couple of things that likely would have been caught > in a review. =A0I am not very busy right now. =A0If you would like and > when you are ready, I'd be willing to go through a design review with > you without charge. =A0I'm pretty bored and would enjoy it. > > Rick Rick, thanks for all the help, and I appreciate the offer! I might take you up on it. If you send me an e-mail to the address displayed here, I can reply with a more useful e-mail address.. I use a kind of junk-ish secondary address to access google groups because of all the spam. I'd like not to be on google groups but I don't have a news server at the moment, and don't know where to go for one.. I have some other things to do (including programming and testing the first iteration on an already made dev board) so it's going to be a little while before my layout is ready to go. I have some reasons why Virtex-II and not something newer, and why SRAM and all that, and there is a little bit more to the overall system than I've mentioned though. As for remapping the EEPROM, I'm not too worried about that because I was going to whip up a second FPGA configuration just to write the contents of the EEPROM, so the addresses and bit orders will come out the same. But yeah I'd rather keep all the address lines as they are. I probably won't be pushing timing to the max.. the critical thing is that I can write continuously to RAM on a ~25MHz clock (or maybe I can afford to go with half that) for a certain period. SteveArticle: 145298
On Feb 4, 5:08=A0am, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > rickman <gnu...@gmail.com> wrote: > >... > > I'm not clear about your problem exactly. =A0It looks like your system > > meets the setup time of the FT2232H chip. =A0The hold time requirement > > is 0, so that is met for sure unless you have clock routing problems. > > If your clock is on the wrong input, there is not much you can do > > about that. =A0I am pretty sure you will not find a real way to meet a > > half clock time hold and not blow the setup time. =A0In fact, I don't > > really see where you are headed with this. > > While the idea of half a clock hold time at the output was not my brighte= st, > the question of specifying hold time requirements in general remains. > > > BTW, where did you get the 5.24 ns value? =A0 > > It's the value form the ds529 datasheet. > > > My concern is that the > > calculation of this time is a bit messy requiring you go add more than > > one offset to a base value as determined by the I/O modes. =A0Did you d= o > > all of that? > > The post layout timing uses this value too (and some adders for IO voltag= e, > rate and drive) =A0 I guess I was hoping for a little more detail than just "it's from the data sheet". Like I said, to get a clock to output timing requires you to add several numbers depending on the IO types you are using. Exactly what part are you using and what IO types and configuation? The post layout timing will only be as accurate as the information it is provided with. I'm not trying to be a pain, but I noticed that this number exactly matches the base number for clock to output timing, XC3S200A, DCM not in use -4 speed grade. This value is only valid if you are using LVCMOS25 on both the clock port and the output with 12 mA drive. Of course, it is possible that this same value came from some other combination of chip and configuration. As to specifying hold time, I don't recall. I know you can specify a max clock to output delay, but a hold time would in essence be a minimum clock to output delay. I would think they would allow for that. On I/Os it can be important since not all devices have 0 hold times. There is a guide for timing constraints. Have you found that? RickArticle: 145299
austin wrote: > Sean, > > Do you have the "wait for DCM's to lock before releasing DONE" option > set? Nope. In fact, I'm not even using any DCMs in my test-design. For first tests in the lab, I'm just driving some LEDs statically. No clock, no reset. The problem is that in fact "done" IS released, but GTS and GSR aren't disabled. It looks like configuration stops in the middle of the startup cycle, i.e. after "DONE", but before GTS and GSR are disabled. But iMPACT claims everything's fine, and configuration was successful. > Sometimes this gets in the way, as the part is waiting for LOCKED > before it even releases GTS, and GSR. Easier is to force the DCM's to > reset after DONE goes high by driving reset with a startup signal that > you generate. Hmm, how can the DCMs even lock if GTS is still active, i.e. clock inputs are still disabled? > By moving DONE till after GTS, you are getting the DCM's to start > up ... or that is my best guess. What I don't get is that iMPACT claims it's done. Seems to me that it just watches for "DONE", and then stops, even though the startup sequence isn't finished yet. If it were waiting for DCMs to lock or something else, I'd expect it would get stuck at 99% or stop after a timeout with a "failed" message or something. This just had me stuck for 2 days, measuring ripple on my supply, checking my clocks, checking the layout and so on. I probably would've sent the board out for x-rays to check for soldering issues next, hadn't I by chance run across a colleague in the corridor who had the same problem 5 years ago. cu, Sean -- Replace "MONTH" with the three-letter abbreviation of the current month and the two-digit code for the current year (simple, eh?).
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