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 all,
I'm using a Spartan-3 XC3S400 with cascaded DCMs.
1st DCM is configured as variable phase shift with 27MHz clock from an
external VCXO in CLKIN. It is fedback (1X) from CLK0 through an IOB
(run out of BUFG). This IOB's output feeds second DCM's CLKIN. First
DCM's CLKFX output is also used for other tasks (multiplied by 4).
2nd DCM simply uses CLK0 and CLKFX (multiplied by 10) outputs with
BUFG for both of them and the proper feedback 1X from CLK0.
Attributes for both DCMs:
FACTORY_JF =3D> X"8080"
STARTUP_WAIT =3D> FALSE
This structure above is instantiated twice, so I use the 4 DCM of my
FPGA. Both instantiations are identical.
The result of this is that one instantiation works perfectly, but the
other one not. This one successes to set most phase-shift values, but
fails just to set negative phase-shifts (PSINCDEC=3D0) in the range
between 20 and 28 (nr. of pulses of PSCLK while PSEN is high). The
rest of the phase-shifts are achieved OK. When it fails the DCM's lock
and status bits do not indicate any error situation but ALL the clocks
generated within the FPGA from the VCXO start to move their edges of
the clock pulses pretty much (even clocks not generated by DCM).
I reset DCMs as Xilinx advises (waiting the lock of the 1st DCM to
reset the second one). Has any of you experienced some similar
behaviour?
Regards,
C=E9sar
Article: 126651> But now I'm getting an error (while implementation stage - don't know > exactly at the moment). Ok, the error occured while translation in implementation phase. > I can't post the exact error message at the moment, but it will be given > later if it's necessary. Here is the exact error message from the translation report: Reading NGO file "/home/schrl/ise/virtex2p/reconf_rs232/top.ngc" ... Applying constraints in "top.ucf" to the design... ERROR:NgdBuild:753 - "top.ucf" Line 27: Could not find instance(s) stat_r' in the design. To suppress this error specify the correct instance name or remove the constraint. I'm trying these first suggestions from M. Hicks and MH. thxArticle: 126652
Nial I would expect from our experience that the DDR could be routed in 3 layers assuming you are attaching to a FPGA and a sensible pinout is chosen. Our product Tarfessock1 achieves the connection of a DDR2 chip in principally 2 layers with a couple of straggler signals on a 3rd layer. If this product was a less compoonent dense product we certainly would do it all in the 2 layers. Taking that as a starting point you could use one of your tracking layers as a localised ground layer using a polygon fill and you can have a fairly good electrical setup for high speed signals. We use some of the recomendations in Xilinx XAPP693 for layer structure and never had an issue.We don't use all the recomendations of this applications note as they are impractical to achieve on a cost sensitive board. Signal integrity tools are a nice toy but they are only as good as the information fed into them. There are generally also expensive although you can argue that against the cost of a failed board. Even if you know your pcb manufacturer at this point, and the materials they use specifically, then at best things like the dielectric constants and layer spacing vary a lot over product batches unless you pay a lot to get boards made to an exact specification and get them tested with resultant yield drop and cost implications. I doubt that any PC motherboard manufactures ever do that and they make an awful lot of boards. Those boards also tend to be 4 layers or sometimes 6 layers. John Adair Enterpoint Ltd. - Home of Darnaw1. The PGA FPGA solution. On 28 Nov, 10:06, "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: 126653
> Nial, > Get a Signal Integrity Tool. > The money you spend on that is recovered by NOT having to respin your > pcb and first assembly run ONE TIME. > For something that has guaranteed payback, for the cost of a respin in > materials alone (does not even include your time, the pcb designer's > time, your cost of lost opportunity being late to market...) why do > people choose to suffer? Thanks for the constructive suggestions Austin, in reply to... > Are you a masochist? Do you enjoy pain? Or are you a sadist? Do you > enjoy causing pain to others? ..I'm tempted to say "Yes, I have used Xilinx devices in the past". But that's just me being cheeky. > I suppose if I wanted revenge on a horrible boss, I would just follow > their directions, but what is the fun in that? Go work for someone who > has a brain. I am the boss. It's easy enough to spout off when you've all the resources of Xilinx behind you, the situation in a small (2 man) company is a bit different. In the UK we generally pay the same price in GBP that you guys pay in dollars for tools. That makes them twice the price, not so cheap. We'd then be starting the (presmably long if they're any good) learning curve to produce useful results for something that we're possibly only going to be doing once in a blue moon. I doubt we'd be getting any results defore Christmas. As others have said this is an almost run of the mill routing/termination problem, I'm confident we'll get it right with a bit of thought. Nial.Article: 126654
> 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 David, I too am skeptical about the amount of decoupling that close GND/PWR plane coupling can provice. In that atricle above they quote 560pF/sq inch. Most BGAs are smaller than that. The article suggests that this sort of capacitance is useful for 'random' logic where there's little synchronisation between gates drawing power. We're using FPGAs that tend to be largely synchronous. Page 24 says... > Memory IC’s: Memory IC’s generally are assembled in synchronous arrays. > When these arrays are clocked, a large amount of switching current is required to > drive the output interfaces and charge the internal memory array’s. These > devices require a large amount of high speed current which is larger than BC > layers can provide. Additional discrete decoupling capacitors will be required. ? I think I'll rely on my decouplers, the X2Y devices Symon pointed out (again) seem useful. Nial.Article: 126655
Hi Symon, I was hoping you'd stick your oar in! > Also, 16-20 layer boards? I guess it'll work, but I'm glad I'm not paying for it. Indeed, this is self funded so I'd like ot keep costs down where possible (with the proviso things should work). > Good answers you got are, 'use two more layers' 8 Layers is the brute force answer to the problem. It should definitely work, but it would be good to find a more elegant solution to the problem. > , 'simulate', 'SI-LIST', and 'use as few vias as possible'. Oh, and don't cross gaps in planes, > but we all know that, right? To use a Belfast expression "Do you think I came up the Lagan in a bubble?". No (adjacent) plane splits will be crossed. > 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 think you've said before that you've got away with routing power in like this with no problems. > I'd use X2Y caps backside of the FPGA for bypassing. (Google X2Y FPGA) They look good, and as they're available from Digikey they might be a goer. The downside is that we're currently using 0402's with round pads on the back of the board so they fit neatly just at the PWR/GND pins. The X2Ys would have to be round the edges, but it could be worth adding a few in. > 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. The idea was to create a localised GND plane on the PWR layer with vias to the 'real' GND layer and a matching linking via beside any point at which a trace goes from the bottom layer to top layer. > 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. But as others have said, 120MHz is almost DC these days! > p.s. You did search back through CAF for previous threads, right? ;-) Oh aye, there wasn't too much about routing to DDRs specifically but as usual all advice was conflicting as here! :-) Thansk, Nial.Article: 126656
> I would never split a plane except as a last resort (unless you can sandwich it between two solid > planes - I often use a four layer GND, split power, split power, GND sandwich in the middle of > 16-20 layer boards), because of the issues with traces crossing the split. As you say below signals can use the PWR plane as a 'pseudo gnd'. By using this stack are you not loosing the ability to route two internal signal layers adjacent to the GND planes, and the additional use of the PWR planes as pseudo grounds? > If you must stick to six layers then you need to make the power plane look like a ground plane by > ensuring that there are adequate decoupling capacitors spread uniformly across the board, such > that no point on the board is more than some short distance from a capacitor. The AC return > current can flow along the power plane and through the capacitor to ground. Of course, you want to > reduce the inductance so use 0402 or 0603 parts with vias very close to the pads. That's a thought. The bank of the FPGA driving the DDR and the device itself are on the same unbroken power plane. There's also plenty of decoupling round both devices so we might be OK. Nial.Article: 126657
> I've had good results with : > sig1 > sig2 > GND > PWR > sig3 > sig4 Are you not missing out on one layer closely coupling to the GND and using the PWR as a pseudo GND like this? > 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. Indeed. Nial.Article: 126658
> I did 6 layers as well, but my stackup is: > > signal > GND > PWR > PWR > GND > signal >:-0 That's not very routing efficient. > 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... :-) Thanks for this info. We've been working from a Micron app note which suggests 8 mil min clearances between data lines. On the other hand this is a short point to point connection so we can probably get away with a lot more than others with more onerous topologies. > 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). Thanks for an alternative viewpoint. > Again, 120 MHz is nearly DC nowadays. You don't need any > fancy SI tools to do it. Hopefully. Nial.Article: 126659
> Power and ground are not going to be forming a very good capacitor to > supply power so you're making a big compromise right there, it won't > be a really low inductance pathway to deliver power to the parts on > the board. As below, I'm not convinced this is a problem. Good _enough_ supply paths with sufficient local decoupling should do? > Ideally you'd like to have two more layers, move PWR up to > be underneath GND and then mirror that on the bottom side (i.e. sig1, > GND, PWR, sig2, sig3, PWR, GND, sig4). Whether your 6 layer bites you > or not will depend entirely on how much switching is going on and how > demanding the parts are. I recently consulted on a design that had > the above type of stackup and the PCB was unable to deliver enough > 3.3V to the FPGA and would cause it to functionally upset, the board > failed. Might it not have been due to bad signal return path integrity or insufficient grounding? (I'm not arguing here, just posing the question). > If you can't spring for si tools, then I'd suggest the following > resources that you should peruse in besides just this particular > newsgroup > 1. "Right the First Time: A Practical Handbook on High Speed PCB > Design and System Design". Volumes 1 and 2, by Lee W. Ritchey. Each > will set you back about $90USD I think but they are both well worth > it. Can be purchased from speedingedge.com (I have no financial or > other interest in the book or the Speeding Edge company, this is just > a recommendation for what I've found to be an excellent resource). Alan (if you're reading this), guess what you're getting for Christmas! Thanks for the pointers Kevin, Nial.Article: 126660
> 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! We've been following one of the Micron app notes here, especially wrt the clocks. It's a fairly short pt to pt connection so hopefully we should be OK. Thanks, Nial.Article: 126661
> I would expect from our experience that the DDR could be routed in 3 > layers assuming you are attaching to a FPGA and a sensible pinout is > chosen. Our product Tarfessock1 achieves the connection of a DDR2 chip > in principally 2 layers with a couple of straggler signals on a 3rd > layer. If this product was a less compoonent dense product we > certainly would do it all in the 2 layers. I'm not doing the routing but I think it'll all come out on 3 layers. We have a few spare pins in the banks we're using so should be able to shuffle things about. > Taking that as a starting point you could use one of your tracking > layers as a localised ground layer using a polygon fill and you can > have a fairly good electrical setup for high speed signals. We use > some of the recomendations in Xilinx XAPP693 for layer structure and > never had an issue.We don't use all the recomendations of this > applications note as they are impractical to achieve on a cost > sensitive board. We'll have a look at that, although I think we've been overly paranoid. Top and layer 3 are tightly coupled to the GND plane, the bottom layer should be coupled to the PWR plane if we make sure it's sufficiently decoupled (as elsewhere in the thread). > I doubt that any PC > motherboard manufactures ever do that and they make an awful lot of > boards. Those boards also tend to be 4 layers or sometimes 6 layers. Aye, but they are purveyors of magic! Looking at the complexity/density/performance of a typical PC motherboard I'm still impressed at the price they knock them out for. Thanks John. Nial.Article: 126662
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_H Thanks John, yes the hardware side should be fine, I have correctly connected all the pins and as I mentioned I can see one device but the FPGA is missing. I am using ISE 7.1, probably there are issues with using the Multilinx cable? Can anyone from the Xilinx guys give an answer to that if the Multilinx cable works alright with the 7.1 version?Article: 126663
Have you checked to see if ISE hasnt optimised the logic connected to those signals away (like you said, often caused by an unconnected clock)? Use a post synthesis RTL and Technology veiw to have a look. Quartus has them, Im sure ISE must have them too.Article: 126664
> > I did 6 layers as well, but my stackup is: > > > signal > > GND > > PWR > > PWR > > GND > > signal > >:-0 > > That's not very routing efficient. > Well at first sight it is not indeed. But take into account the fact, that you have no hidden signal layers and related nightmares for errors to fix on the prototype board there (which does not save you the nightmares of misconnected power planes... so far I have had the only the latter, thankfully never to come true :-) ), then think that at the 6/4 mil rules you can do a lot of things (I forgot to mention it, I do 0.3 or 0.2mm drilling for vias/BGA pads), and it becomes a lot more attractive. Especially if you cannot afford a respin of the prototype (usually the case with me, and thanfully never needed one - although typically my second or third revision is 100% error free). Actually here is one prototype (recent shot of a 5-6 years old prototype, the CPU cooler got unstuck and I took the opportunity): http://tgi-sci.com/misc/PICT3084.JPG Routed using the same technique, not much free area left (especially if you count the 5 SDRAM chips on the bottom, 1 of which - the ECC - is routed but left empty). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ On Nov 29, 11:37 am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > I did 6 layers as well, but my stackup is: > > > signal > > GND > > PWR > > PWR > > GND > > signal > >:-0 > > That's not very routing efficient. > > > > > 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... :-) > > Thanks for this info. > > We've been working from a Micron app note which suggests 8 mil > min clearances between data lines. > > On the other hand this is a short point to point connection so > we can probably get away with a lot more than others with more > onerous topologies. > > > 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). > > Thanks for an alternative viewpoint. > > > Again, 120 MHz is nearly DC nowadays. You don't need any > > fancy SI tools to do it. > > Hopefully. > > Nial.Article: 126665
Hi, we are using an asynchronous FIFO to bridge two clock domains. Both domains have "the same" clock speed but different clock oscillators. We shift data phits in the FIFO which always form a data packet. In between a packet data is shifted in continously without a break. Breaks (no shift in) are only allowed in between packets. On the output side of the FIFO we need a steady data stream during a data packet. The packet may not be interrupted. As the input side may be slower we start shift-out data if at least two data phits are in the FIFO. As the 2 clocks have almost the same frequency this guarantees that we never have a buffer underflow. The problem we found is that the almost empty flag is only asserted if the FIFO is beeing emptied and not if it is beeing filled. So if the FIFO was empty and we get a shift in the almost empty is not asserted although we set the treshold to one. Is this a bug? We tried to solve that problem by generating a delay-empty signal at the output which guarantees that if the FIFO was emtpy and than receives a shift in we still wait another cycle so we get another shift in to avoid underflow. This solution however does not solve the problem if the FIFO exactly had one entry when starting to shift out a packet. In this case neither delayed-empty nor almost empty is asserted, hence we get an underflow. Why isn't the almost empty signal asserted every time there is a single packet in the FIFO? Ideas?Article: 126666
About Andrew comment "global routing networks are expensive, clearly they are justified for clocks, but reset?" Yes, reset! Lets say I have a computational block, that must be cleared after computaion and I must save older values. I won=B4t reprogram the FPGA every time. Or let me say that one can use partial reconfiguration. The other parts of the system are always allowed to keep an unkown state? But some will say: "use a sync reset". And I tell: same problem. I wish it global! And how about a global enable signal? Or somekind of global control? I still find that the lack of global lines for logic is even a serious flaw, worst then the reset one. Regarding to Erics comments, as follow: > I don't think anyone was proposing adding additional global nets. The > question is how expensive would it be to add either: Agreed. And even if its expensive, global generic nets would be useful. Be for reset or not. Like I said, I'd like to use a global enable too. > 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-itisamyththatxilinxhasnolowkprodu..= . But I=B4m still looking for a FPGA that has global generic nets.Article: 126667
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5r7fsuF13c7e4U1@mid.individual.net... >> Power and ground are not going to be forming a very good capacitor to >> supply power so you're making a big compromise right there, it won't >> be a really low inductance pathway to deliver power to the parts on >> the board. > > As below, I'm not convinced this is a problem. > > Good _enough_ supply paths with sufficient local decoupling should do? The problem is determining what is 'good enough'. Putting planes (or even the voltage supply puddles and ground plane as Symon suggests) close together gets you a very low inductance pathway for delivering the power to the part. What your stackup had is widely separated power and ground which is not 'good', but depending on your needs might be 'good enough'. The other suggestion that someone posted to put the power/ground together in the middle accomplishes the same thing and saves you two layers at the cost of having fewer routing layers directly adjacent to the return plane. Whether that is enough or not depends very much on your particular design. > >> Ideally you'd like to have two more layers, move PWR up to >> be underneath GND and then mirror that on the bottom side (i.e. sig1, >> GND, PWR, sig2, sig3, PWR, GND, sig4). Whether your 6 layer bites you >> or not will depend entirely on how much switching is going on and how >> demanding the parts are. I recently consulted on a design that had >> the above type of stackup and the PCB was unable to deliver enough >> 3.3V to the FPGA and would cause it to functionally upset, the board >> failed. > > Might it not have been due to bad signal return path integrity or > insufficient grounding? > > (I'm not arguing here, just posing the question). > No. In fact to try to prove to the designer that it had to do with anything other than power (there was natural skepticism), I programmed the FPGA to simply toggle outputs every clock cycle and the failure condition would be when the internal phase locked loop lost lock so the only thing the PCB had to deliver was core voltage, I/O voltage and a single input clock that went into a PLL in the FPGA. He tried different 'filtering' on the PLL supply voltage, we played with I/O drive strengths and limiting certain pins to toggling at lower clock rates and it would always fail. The board only functioned somewhat when toggling all but a handful of I/O at a lower clock rate (1/4 of the higher speed ones). When the new board arrived, poof! suddenly all I/O could toggle at the full clock rate, could be driven at the full I/O current drive strength and not lose lock. The lowered inductance (impedance) in the power delivery network that comes with the better stackup was left as the only viable hypothesis for the failure. If you read Ritchey's book, you'll gain a better appreciation for the PCB's role in power delivery. The fundamental flaw that the designer I was working with had was treating the stackup as something only to connect all the points together and trying to minimize layers for cost reasons and being completely lost on what you need for good power delivery. The inductance/impedance in the path from the regulator to each load over the entire frequency range of interest is critical. > > Thanks for the pointers Kevin, > > You're welcome. Good luck on your design. With a bit of thought and understanding about what is going on for delivering power and signal terminations and image return planes (which you seem to have a basic grasp on already) it should all work out just fine. Kevin JenningsArticle: 126668
"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in message news:5r7d87F1326q5U1@mid.individual.net... >> 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 > > David, > > I too am skeptical about the amount of decoupling that close GND/PWR plane > coupling can provice. > > In that atricle above they quote 560pF/sq inch. Most BGAs are smaller > than that. > It's not so much the capacitance as it is the lowered inductance that the closely spaced planes brings you. Having a fire hydrant near a burning house doesn't help much if you only have a garden hose to deliver the water. The inductance of the power delivery network is the thing that delivers the power from the source to the load. KJArticle: 126669
On Nov 27, 6:26 pm, "psihode...@googlemail.com" <psihode...@googlemail.com> wrote: > Hello all, > can you please tell us what tools you prefer? Please give some > arguments, why you like them. > > I currently use very intensively Linux shell and GHDL compiler for > simulations and XST for synthesis. > > GHDL is very fast and powerful. You can for example colorize your > files directly into HTML, call foreign functions (e.g. from C > library), and many more. > > My VHDL projects have typical Linux-way directory tree structure: > ./bin/ for binaries > ./include/ for includes > ./work/ for generated modules > ./src/ for sources > > inside src directory is a Makefile, which is automatically generated > by GHDL. In order to build a binary, I use "make sim" command. If I > need to create some additional component in other language (C or > Python), I use "foreign" declarations in VHDL code and link them using > GHDL, just like with well-known GCC. For example if you need to verify > your VGA-Controller Design, you can create a special C-function which > will create JPG file with the current frame. > > For synthesis I use XST from Xilinx ISE. It is very simple to type: > "make syn; make load" and bitfile will be uploaded into an FPGA. For > communication with FPGA board, real-time visualization, and so on, I > use small Python scripts. > > I use VIM as a text editor. It also helps me to be very productive and > to work remotely using SSH (e.g. it's nice thing to use VIM on your > cell phone like Nokia N200 which has Linux onboard). > > So, this are my tools: > GHDL, XST, GNU Tools(make, bintools, bash, libc, etc.), VIM, Python, > GCC > and of course Linux itself. > > Frankly, only XST is not under Open Source license and it mostly slow- > downs hole development flow because of XST's bugs and its poor > performance. All other programs I use are previously compiled using > optimization flags targeted my server's hardware. > > What tools do you prefer? Why ? NC-VHDL or modelsim, both have top-notch performance, and have excellent source level debuggers, object "watchers", etc. (which I tend to use more than waveforms for debugging). For synthesis, I have been disappointed with XST compared to Symplify- pro. Synplify covers the language better, and generally gives better results. It's schematic generation and viewing/filtering are top- notch, and works at both the "RTL" level (showing you higher level objects than primitives) and the technology level, which shows the luts, flops, etc. at the lowest level. It is also vendor independent, so you can evaluate other targets very easily. I've used jGrasp, Ultra-edit, and xemacs with vhdl-mode. I had to upgrade the UE vhdl syntax description to get it to do a better job on formatting. JGrasp has excellent formatting, etc. and displays graphical structural cues in the LH whitespace. However, nothing compares to the shortcuts, or formatting and beautification capabilities, of vhdl-mode for xemacs. Getting past some of the keyboard acrobatics is a pain though. I mostly use xemacs now. Somehow I can't see being productive writing/editing vhdl on a cell phone... AndyArticle: 126670
Hi *, just stumbled across this opensource-thingy and thought it might be useful to others as well: http://drawtiming.sourceforge.net/ I've been looking for something just like this... cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 126671
Mike wrote: > 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_H > > Thanks John, yes the hardware side should be fine, I have correctly > connected all the pins and as I mentioned I can see one device but > the FPGA is missing. I am using ISE 7.1, probably there are issues with > using the Multilinx cable? Can anyone from the Xilinx guys give an > answer to that if the Multilinx cable works alright with the 7.1 version? To see only the CPLD, the FPGA must be IDENTIFIED and put into bypass. The problem you've identified screams that something is very wrong, not simply a matter of the cable. Are you using Impact? Chipscope? Synplicity's Identify? If you have anything else that does JTAG, get a second opinion. Help us help you - please specify what board and what software.Article: 126672
On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1981@gmail.com> wrote: >I understood. And thanks for all for the replies. > >So, I can't use a global line for reset and like all Xilinx guys say, >I shouldn't use it. >IMHO the lack of reset circuitry is a serious flaw. >I have a global enable too, that must get everypart of the design. >Again, no way to use it as global. This is even a more serious flaw, >since enable is the best design pratice regarding FPGAs. > >I think I'll have to prey that PAR meet my timing constraints, as they >are somewhat tight... Does anyone have a better idea than using low >skew lines? If you control your design from some central state machine, add several states between the "reset" state and the central despatcher state (e.g. "idle" where you wait for inputs to react to and depatch to states that do the work). That guarantees that nothing else in your design will be active for those several cycles; therefore reset to anything OUTSIDE these states can be constrained as a multicycle path. - BrianArticle: 126673
Hi all, I'm working on a hardware implementation (FPGA) of a lossless compression algorithm for a real-time application. The data will be fed in to the system, will then be compressed on-the-fly and then transmitted further. The average compression ratio is 3:1, so I'm gonna use some FIFOs of a certain size and start reading data out of the FIFO after a fixed startup-time. The readout rate will be 1/3 of the input data rate The size of the FIFOs is determined by the experimental variance of the mean compression ratio. Nonetheless there are possible circumstances in which no compression can be achieved. Since the overall system does not support variable bitrates a faster transmission is no solution here. So my idea was to put the question to all of you what to do in case of uncompressibility? Any ideas? Denkedran JoeArticle: 126674
Hi all, I've just finished constructing a new site that has web videos of soldering techniques, including how to hand solder quad flat packs. Very handy for prototyping. You can go and get a free membership there, which lets you see 5 videos on how to hand solder quad flat packs. Watch me hand solder a Spartan 2E in a PQ208 package onto a board:) http://supersolderingsecrets.com/ The upgraded membership covers lots of other soldering techniques such as "toaster-oven soldering", "frying pan solder pot soldering", etc., but if you just wanted to know how to hand solder that FPGA on your prototype, then the free membership reveals all:) Cheers, Tony Burch http://supersolderingsecrets.com/
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