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
> After the question "How is the great complexity handled?" You answered with "The switch fabric is in charge to connect those > different devices and perform the necessary conversion" This is generally not quite the case. It is up to the Avalon slave > design to perform the necessary conversions (I mmh, as far as I understand it you can provide any master or slave implementation that follows the rule of Avalon: From a very simple asynchronous device to a pipelining device. The generated switch fabric will provide the adaption. > proprietary Altera design, or are there open source implementations available?" The switch fabric itself can easily be written, > it is on the order of six lines of code per interface for a point to point connection, there is nothing really magic in what > Altera spits out of SOPC Builder based I think that this is actually the power of SOPC builder. It will do all your glue logic stuff for the interconnect (address decoding, byte order managing, byte enable on write,...). And that's a lot more than 6 lines of code ;-) > an open source version of this connection logic, but whether simple use of the Avalon bus without also targetting an Altera device > (even if no Altera software is involved) is violating anything is an open legal question as you've pointed out (I'm guessing that > it might but not really sure). AFAIK the bus definition is kind of open-source - free. However, I'm sure you're not allowed to use the SOPC builder generated VHDL code on a Xilinx device ;-) BTW: I asked Altera Austria about a related topic: Is it allowed to 'use' the DRAM controller in an open-source environment (means can I upload the VHDL code to a web server). However, they had no real answare to this. They sayed that the SDRAM controller does is part of NIOS and does only work with NIOS. Therefore, one has to buy a NIOS license. But it works quite well with JOP too ;-) > Section 2 > In the paragraph starting "The third issue is..." you ask the question "Why not force the slaves to hold the data on the output > registers as long as there is no new transaction?" A couple follow up questions to that though would be > - What is a SimpCon slave to do if there IS a new transaction before the old one has been acknowledged? good question ;-) It depends on the pipeline level. It can accept it. But this is not directly related on the request to 'just' keep the data valid until a newer one is available (and was requested). > - Does the SimpCon fabric prevent this from happening? (I think it does, but not exactly sure) It is the master who decides when to issue a new request and when to leave the slave with the last data. > Personally, I'm still a bit confused about just exactly which pipeline on the master side is 'released' when rdy_cnt hits the > magic number and how that differs from releasing the Avalon master address/command pipeline via waitrequest and releasing the > Avalon master readdata pipeline via From the pure pipelining point of view there is not so much difference between Avalon and SimpCon. Both can do pipelining when the slave supports it. The pipeline level in Avalon is not restricted (and not so obvious to see). In SimpCon with the 2 bit rdy_cnt the pipeline level is restricted. > it's not totally the master address/command that is being released but 'something' on the JOP master for kick starting the data > processing pipeline based on the read data actually becoming available (and getting 'early' notice of this). the early notice is the little thing I like on my design: It helps a pipelined master waiting on data *and* performs the flow control for the pipelining. Perhaps too much information for a singel 2 bit signal. However, I like less signals. See the OPB spec. for the extreme different way to do it: They have way too many signals defined - I don't like to read so many signal definitions ;-) > having the master 'know' the latency about the 'slave' would seem to be cheating (since this wasn't required by the SimpCon > implementation as I had thought) but I guess I'll fall back to what Tommy mentioned earlier that since JOP was optomized for > SimpCon in the first place it implies that an Avalon/SimpCon bridge must be built and such bridges can tend to be either about cheating and bridge: I'm allready cheating on the Avalon interface (as mentioned in an earlier post) to generate the address/control/data holding in the master - I switch between the original single cycle register at the first cycle and a hold register on the following cycles - that's not allowed in the original spec. Bridges are a difficult topic: In the general case you add latency cycles. > be). Had JOP been optomized for Avalon to begin with would the numbers be any better without any cheating? That's sort of the > open question and I'm not necessarily expecting an answer. Mmh, hard to say. I implemented the memory interface without any SoC interconnect in mind - just tried to get the best performance on SRAMs. The bus thing came very late in the design. So it looks like I'm now defining a bus that 'fits' to the way the original memory interface of JOP was. However, perhaps that's not that bad as a new idea for a differnt bus comes up ;-) > My main interest in the thread was in understanding what sort of bottlenecks might be lurking in Avalon that I'm not aware of. A > couple areas of 'possible' weakness for Avalon that I am aware of are: > - It can hang (there is no requirement for a max time for a cycle). Something to be aware of, but generally not an issue since > whoever is designing the slave components had better address this and not allow for a hang to occur. > - No notion of a 'retry'. Again, given the environment of being on a chip, the slave design shouldn't be allowe to say 'try again > later please' so I don't think this should be an actual design issue, just something to be aware of. Implementing those two features makes your bus (and interfacing) way more complicated. AFAIK OPB does it, but you end up with so many signals... > - Can't have pending reads from multiple slaves. I suppose this could be important to some, it hasn't for me. That's more an issue of the interconnect logic and not the bus definition. > > Just curious, Figure 7 shows pipelined reads from a static RAM where a new address is presented on every other clock cycle which > matches the performance of the actual SRAM. If the device had been an external DRAM/DDR That's just the 2 clock access time SRAM example. > or such, you can clock out a new read command on every clock cycle even before you get the first data item back. After the data > from that first You can do single cycle pipelined read with a latency of two cycles (compared to just a single one in AMBA AHB). Perhaps I should provide that example too. When the slave supports it you can issue a new read request when rdy_cnt is 2. When you do it than rdy_cnt will stay at 2 - the 2 cycle pipelining. > Like I said, nothing major just minor things. SimpCon can be the answer to certain bus issues, Avalon, Wishbone, VSIA may be the > answer to others. It's good to have choices. yep ;-) BTW: I don't know VSIA. Any link to it? > Fine by me...by the way, I wouldn't consider the exchanges in the thread to be either 'heated' (as mentioned by Tommy) or > 'controversial' (since I don't see what the controversy was). It was interesting and civil, the large number of back and forth > that remained on topic would seem to indicate that.....'heated' and 'controversial' seems to occur when mention of 'asynchronous > resets' or 'coding style of state machines' is the topic. Completely agree - will remove this 'controversal' as this thread is more 'constructive'. Cheers, MartinArticle: 107551
Most of what you said goes against what was taught in the class I just took. This information was presented in theory, demonstrated in simulation and then proven with measurements. Symon wrote: > So, here's my thoughts. > > If we have two caps of different values, but the same package/inductance, > there's a frequency between the SRF of the caps that has a parallel > resonance which leads to a peak in the impedance. For example, C1, a 1uF > 0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10 MHz > and 25MHz, C1 looks inductive and C2 capacitive. This means there's a peak > in the impedance. So, the stragegy of using different values to 'even out' > the impedance gives us peaks (bad) and troughs (good) in the impedance > across the frequency spectrum. Having a peak is not bad if it is still below the max impedance you are trying to achieve. > However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q of > the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance is > 0.01R, giving a Q of 2. These values of Q are so low as to make the self > resonance problem/advantage make bugger all difference. Note that a 10nF > 0402 cap has a Q of about 3 at its SRF of 70MHz. Yes, this is why you need to use lossy caps and not low ESR caps. This is very important. But if you use just one value of cap such as 0.1 uF, you will likely see a much higher peak than you can tolerate. The peak will be reduced by using more of them, or you can use a second or third value of capacitance to end up with a series of closely spaced peaks and troughs that are much lower than you will get with a single value of cap. You can also use a lot fewer parts. > BTW, I got the cap data from here http://www.murata.com/designlib/mcsil.html > > (Also, note that the vias/traces to connect these caps probably double the > inductance, reducing the SRF by 30%) You should have data to back this up, not speculation and BTW, what traces? If you are connecting the caps with traces you have already lost the battle. The experimental data shows the added inductance of the via is not a significant factor in the overall picture when you use multiple values to even out the inpedance over frequency. > As for the 'plane capacitance', it starts to have an effect at frequencies > > 1GHz which is a fat lot of good when our vias and BGA balls have inductances > in the nH region. Remember, we're not trying to bypass the power plane, > we're trying to bypass the IC. Again you should have data on hand before you speculate. In the Ritchey book data is provided to show that the impedance of a closely spaced power/ground plane pair is lower than the typical capacitors around 100 MHz. Of course this depends on the size and construction of the board. But clearly the region of importance is much lower than 1 GHz. In addition, the impedance of your package leads has no bearing on the power decoupling. No amount of capacitace external or internal to the device will have any impact on the bounce that will be caused by power lead inductance. The only cure for that is a new package. > In conclusion, mixing different values of ceramic caps in the same packages > might help a little but might hurt a little in a real system with FPGAs. I > maintain that using the biggest value in the size you choose is the best, if > nothing else because they have the crappest Q and this avoids BOM bloat. If > we do use a range, bully for us, we probably won't notice any difference, > but we have more chances for resonance and EMI failures. This is not borne out by the facts. If you can get your hands on Richey's book I would suggest that it is a valuable addition to any library on SI and EMI. His volume 2 will cover EMI in more detail and I am looking forward to it. > Finally, I agree that the positioning of the cap is of lesser importance. > However, some of us prefer not to waste layers in our stacks on power > planes, we prefer to have decent grounds and route our FPGA power on layers > used for signals in other places. The HF plane capacitance is pissed away by > the chip mounting interconnect anyway, and its high Q might lead to evil > resonances. (As you mention in your posts, Rick.) In this case, with little > mini-planes for power routing, capacitor placement is crucial. (Note. With > FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are > getting very expensive with planes for every supply.) Wow! If your design is not high speed and the edge rates are not very fast, then power distribution is not a big deal. But nearly everything in this paragraph is incorrect. Yes, power planes cost money, that is true. Now that I understand how simple it is to figure out how power distribution works, I would never use any of these ideas on a board where I needed good noise margin or had high speed signals. BTW, I never said a high Q power plane pair is bad. Yes, it can create impedance holes at very high frequencies, but the alternative for your approach would raise the floor, not lower the ceiling. > In conclusion, for FPGA PCBs, > Lots of ground layers, one for every two signal layers. > One value of cap per size. > Use lots of caps. It means less impedance. > Power planes only need extend as far as the bypass caps. So, closer the caps > to the target device, the less plane needed. > > IMHO, YMMV, HTH, Syms. > > p.s. It's easy to simulate this stuff, try the excellent and free LTSpice > from > http://www.linear.com/company/software.jsp > (as recommended by Bob, thanks!) > p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this > methodology, and I don't think other solutions work noticeable better. Have you tried simulating any of this? I would like to know what results your methods produce. The question is not so much if a method has worked a few times for you, but do you *know* it is going to work before you build the board. Ritchey's method lets you *know* it will work right the first time.Article: 107552
I can take your word for your results as I don't understand any of the code you posted. But this simulation is not of a power distribution system. Try adding a power plane and just one value of cap (the 0.1uF is what you suggested IIRC) and simulate up to 200 MHz or so. I think you will find that you get a *huge* parallel resonance peak from the two. If you add a few 0.01 uF caps this peak will be split in two and the highest will be much smaller. Then add a few more 0.001 uF caps and you will see the peaks reduced further. It also helps if you use caps with a low Q factor or high ESR (relatively speaking). But then at 0.1 uF, I don't think you will find a C0G so X7R should be fine. Symon wrote: > OK, here's a LTSpice file that shows a resonance between disimilar cap > values. The circuit sweeps from 5MHz to 45MHz back and forth. The first > three sweeps are done with two 1uF caps, the second three with a 1uF and a > 0.1uF cap. Notice the big resonance at about 10MHz for the second set of > sweeps. The performance of the second circuit is slightly better at 45MHz, > worse at 5MHz, MUCH worse at 10MHz. > HTH, Syms. > > Version 4 > SHEET 1 1516 904 > WIRE 1040 432 800 432 ....snip...Article: 107553
"rickman" <gnuarm@gmail.com> wrote in message news:1156900315.566413.232720@p79g2000cwp.googlegroups.com... > Most of what you said goes against what was taught in the class I just > took. This information was presented in theory, demonstrated in > simulation and then proven with measurements. > > > Symon wrote: > > So, here's my thoughts. > > > > If we have two caps of different values, but the same package/inductance, > > there's a frequency between the SRF of the caps that has a parallel > > resonance which leads to a peak in the impedance. For example, C1, a 1uF > > 0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10 MHz > > and 25MHz, C1 looks inductive and C2 capacitive. This means there's a peak > > in the impedance. So, the stragegy of using different values to 'even out' > > the impedance gives us peaks (bad) and troughs (good) in the impedance > > across the frequency spectrum. > > Having a peak is not bad if it is still below the max impedance you are > trying to achieve. > But it's better not to have it, right? > > > However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q of > > the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance is > > 0.01R, giving a Q of 2. These values of Q are so low as to make the self > > resonance problem/advantage make bugger all difference. Note that a 10nF > > 0402 cap has a Q of about 3 at its SRF of 70MHz. > > Yes, this is why you need to use lossy caps and not low ESR caps. This > is very important. But if you use just one value of cap such as 0.1 > uF, you will likely see a much higher peak than you can tolerate. The > peak will be reduced by using more of them, or you can use a second or > third value of capacitance to end up with a series of closely spaced > peaks and troughs that are much lower than you will get with a single > value of cap. You can also use a lot fewer parts. > > > BTW, I got the cap data from here http://www.murata.com/designlib/mcsil.html > > > > (Also, note that the vias/traces to connect these caps probably double the > > inductance, reducing the SRF by 30%) > > You should have data to back this up, not speculation and BTW, what > traces? If you are connecting the caps with traces you have already > lost the battle. The experimental data shows the added inductance of > the via is not a significant factor in the overall picture when you use > multiple values to even out the inpedance over frequency. > So, you loaded up the LTSpice simulations I posted, right? That's not speculation. And no, you haven't lost the battle with a few tiny traces, the vias are the bad guys as they give you loop area. > > > As for the 'plane capacitance', it starts to have an effect at frequencies > > > 1GHz which is a fat lot of good when our vias and BGA balls have inductances > > in the nH region. Remember, we're not trying to bypass the power plane, > > we're trying to bypass the IC. > > Again you should have data on hand before you speculate. In the > Ritchey book data is provided to show that the impedance of a closely > spaced power/ground plane pair is lower than the typical capacitors > around 100 MHz. Of course this depends on the size and construction of > the board. But clearly the region of importance is much lower than 1 > GHz. > > In addition, the impedance of your package leads has no bearing on the > power decoupling. No amount of capacitace external or internal to the > device will have any impact on the bounce that will be caused by power > lead inductance. The only cure for that is a new package. > So, you advocate decoupling the power plane without considering what effect this has on the IC? Why would you go to all that effort if the package you're stuck with prevents your efforts making any difference? > > > In conclusion, mixing different values of ceramic caps in the same packages > > might help a little but might hurt a little in a real system with FPGAs. I > > maintain that using the biggest value in the size you choose is the best, if > > nothing else because they have the crappest Q and this avoids BOM bloat. If > > we do use a range, bully for us, we probably won't notice any difference, > > but we have more chances for resonance and EMI failures. > > This is not borne out by the facts. If you can get your hands on > Richey's book I would suggest that it is a valuable addition to any > library on SI and EMI. His volume 2 will cover EMI in more detail and > I am looking forward to it. > I have different facts, look at the sims I posted. > > > Finally, I agree that the positioning of the cap is of lesser importance. > > However, some of us prefer not to waste layers in our stacks on power > > planes, we prefer to have decent grounds and route our FPGA power on layers > > used for signals in other places. The HF plane capacitance is pissed away by > > the chip mounting interconnect anyway, and its high Q might lead to evil > > resonances. (As you mention in your posts, Rick.) In this case, with little > > mini-planes for power routing, capacitor placement is crucial. (Note. With > > FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are > > getting very expensive with planes for every supply.) > > Wow! If your design is not high speed and the edge rates are not very > fast, then power distribution is not a big deal. But nearly everything > in this paragraph is incorrect. Yes, power planes cost money, that is > true. Now that I understand how simple it is to figure out how power > distribution works, I would never use any of these ideas on a board > where I needed good noise margin or had high speed signals. > I see from this paragraph you may not have grasped the effect that the BGA package connections are having on the PDS design. As I said, the whole point of the exercise is to get good supplies on the IC, not the power plane. The plane capacitance has such high Q it's good to severel GHz, I reiterate that you can't benefit from this on the device. I suggest you look at how Xilinx themselves route the power to their Rocket I/Os on their demo boards. The power supplies aren't on planes. The connection between the PCB and the IC mean it's a waste of time, I suspect for these Gbit circuits they embed caps on the FBGA. > > BTW, I never said a high Q power plane pair is bad. Yes, it can create > impedance holes at very high frequencies, but the alternative for your > approach would raise the floor, not lower the ceiling. > I'm not saying it's necessarily bad. But it's not a great deal of help ON THE SILICON. You've gotta get that HF energy through vias, bga balls, traces(maybe) to the device. > > > In conclusion, for FPGA PCBs, > > Lots of ground layers, one for every two signal layers. > > One value of cap per size. > > Use lots of caps. It means less impedance. > > Power planes only need extend as far as the bypass caps. So, closer the caps > > to the target device, the less plane needed. > > > > IMHO, YMMV, HTH, Syms. > > > > p.s. It's easy to simulate this stuff, try the excellent and free LTSpice > > from > > http://www.linear.com/company/software.jsp > > (as recommended by Bob, thanks!) > > p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this > > methodology, and I don't think other solutions work noticeable better. > > Have you tried simulating any of this? I would like to know what > results your methods produce. The question is not so much if a method > has worked a few times for you, but do you *know* it is going to work > before you build the board. Ritchey's method lets you *know* it will > work right the first time. > Only a nutter would do this without thinking about it and running some simulations. So, take a look at my LTSpice sim posts. HTH, Syms.Article: 107554
"rickman" <gnuarm@gmail.com> wrote in message news:1156900847.672642.116440@b28g2000cwb.googlegroups.com... > I can take your word for your results as I don't understand any of the > code you posted. But this simulation is not of a power distribution > system. Try adding a power plane and just one value of cap (the 0.1uF > is what you suggested IIRC) and simulate up to 200 MHz or so. I think > you will find that you get a *huge* parallel resonance peak from the > two. If you add a few 0.01 uF caps this peak will be split in two and > the highest will be much smaller. Then add a few more 0.001 uF caps > and you will see the peaks reduced further. It also helps if you use > caps with a low Q factor or high ESR (relatively speaking). But then > at 0.1 uF, I don't think you will find a C0G so X7R should be fine. > > Symon wrote: > > OK, here's a LTSpice file that shows a resonance between disimilar cap > > values. The circuit sweeps from 5MHz to 45MHz back and forth. The first > > three sweeps are done with two 1uF caps, the second three with a 1uF and a > > 0.1uF cap. Notice the big resonance at about 10MHz for the second set of > > sweeps. The performance of the second circuit is slightly better at 45MHz, > > worse at 5MHz, MUCH worse at 10MHz. > > HTH, Syms. > > > > Version 4 > > SHEET 1 1516 904 > > WIRE 1040 432 800 432 > > ....snip... > Tell you what, why don't YOU download the simulator from Linear Tech's website and learn how to simulate what you suggest? Then you can prove stuff to yourself without having to go to expensive classes. :-) You might even want to simulate the stuff you learned at your class with a real world situation and see how much benefit you get. Let us know how you get on. Good luck, Syms.Article: 107555
So, here's a LTSpice ( http://www.linear.com/company/software.jsp ) SIM up to 200MHz with a 100pF plane and two combinations of bypass capacitors. (Cap data here:- http://www.murata.com/designlib/mcsil.html ) If there's anyone out there who has both the time and ability to run a simulation, I'd appreciate some thoughts as to why my simulation doesn't match up with Rick's classes. I'm trying to find a *huge* parallel resonance! :-) I'm also looking for the benefits of different valued caps, as opposed to just using the biggest value you can get in the package you use. Thanks, Syms. Version 4 SHEET 1 1756 904 WIRE 1280 432 800 432 WIRE 0 464 -208 464 WIRE 208 496 144 496 WIRE 384 496 288 496 WIRE 448 496 384 496 WIRE 656 496 448 496 WIRE 1136 496 656 496 WIRE -208 512 -208 464 WIRE 656 512 656 496 WIRE 1136 512 1136 496 WIRE 736 528 704 528 WIRE 1280 528 1280 432 WIRE 1280 528 1184 528 WIRE 448 560 448 496 WIRE 800 576 800 432 WIRE 800 576 704 576 WIRE 1216 576 1184 576 WIRE 0 592 0 560 WIRE 768 592 656 592 WIRE 832 592 768 592 WIRE 880 592 832 592 WIRE 1024 592 976 592 WIRE 1072 592 1024 592 WIRE 1136 592 1072 592 WIRE -208 624 -208 592 WIRE 656 624 656 592 WIRE 768 624 768 592 WIRE 832 624 832 592 WIRE 880 624 880 592 WIRE 976 624 976 592 WIRE 1024 624 1024 592 WIRE 1072 624 1072 592 WIRE 1136 624 1136 592 WIRE 1280 624 1280 528 WIRE 656 720 656 688 WIRE 736 720 736 528 WIRE 736 720 656 720 WIRE 768 720 768 688 WIRE 768 720 736 720 WIRE 832 720 832 688 WIRE 832 720 768 720 WIRE 880 720 880 688 WIRE 880 720 832 720 WIRE 976 720 976 688 WIRE 1024 720 1024 688 WIRE 1024 720 976 720 WIRE 1072 720 1072 688 WIRE 1072 720 1024 720 WIRE 1136 720 1136 688 WIRE 1136 720 1072 720 WIRE 1216 720 1216 576 WIRE 1216 720 1136 720 WIRE 448 736 448 624 WIRE 656 736 656 720 WIRE 1136 736 1136 720 WIRE 1280 736 1280 704 FLAG 0 592 0 FLAG -208 624 0 FLAG 384 496 Vcap FLAG 448 736 0 FLAG 656 736 0 FLAG 1136 736 0 FLAG 1280 736 0 SYMBOL SpecialFunctions\\modulate 0 464 R0 WINDOW 3 0 0 Invisible 0 SYMATTR InstName A1 SYMATTR Value MARK=205000000 SPACE= 5000000 SYMBOL voltage -208 496 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V1 SYMATTR Value PULSE(0 1 100ns 10us 10us 1us 22us) SYMBOL res 304 480 R90 WINDOW 0 0 56 VBottom 0 WINDOW 3 32 56 VTop 0 SYMATTR InstName R2 SYMATTR Value 0.1 SYMBOL cap 432 560 R0 SYMATTR InstName C5 SYMATTR Value 100pf SYMATTR SpiceLine V=10 Irms=10.541 Rser=0 MTBF=0 Lser=0 ppPkg=1 SYMBOL sw 656 608 R180 SYMATTR InstName S1 SYMATTR Value MYSW SYMBOL cap 640 624 R0 SYMATTR InstName C1 SYMATTR Value 0.1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1 SYMBOL cap 1120 624 R0 SYMATTR InstName C3 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL sw 1136 608 R180 SYMATTR InstName S2 SYMATTR Value MYSW SYMBOL voltage 1280 608 R0 WINDOW 123 0 0 Left 0 WINDOW 39 0 0 Left 0 SYMATTR InstName V3 SYMATTR Value PULSE(1 -1 44us 1ns 1ns 44us 88us) SYMBOL cap 1056 624 R0 SYMATTR InstName C2 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL cap 1008 624 R0 SYMATTR InstName C4 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL cap 960 624 R0 SYMATTR InstName C6 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL cap 864 624 R0 SYMATTR InstName C7 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL cap 816 624 R0 SYMATTR InstName C8 SYMATTR Value 1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1 SYMBOL cap 752 624 R0 SYMATTR InstName C9 SYMATTR Value 0.1µ SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1 TEXT 144 344 Left 0 !.tran 88us TEXT 296 888 Left 0 !.model MYSW SW(Ron=0.0001 Roff=10Meg Vt=.5 Vh=-.4)Article: 107556
"Symon" <symon_brewer@hotmail.com> wrote in message news:44f4f16b$1_3@x-privat.org... > So, here's a LTSpice ( http://www.linear.com/company/software.jsp ) SIM up > to 200MHz with a 100pF plane and two combinations of bypass capacitors. (Cap > data here:- http://www.murata.com/designlib/mcsil.html ) > > If there's anyone out there who has both the time and ability to run a > simulation, I'd appreciate some thoughts as to why my simulation doesn't > match up with Rick's classes. I'm trying to find a *huge* parallel > resonance! :-) I'm also looking for the benefits of different valued caps, > as opposed to just using the biggest value you can get in the package you > use. > Thanks, Syms. > > OK, so I've found the resonance, I needed a giant plane of 10nF, and only 4 caps. The resonance went away once I put a decent number of caps in the circuit. Who has only 4 caps on a board 30cm by 20cm? I'm still looking for a design where mixing the caps is better than not. Cheers, Syms.Article: 107557
Hi David,
It is decided by the MPD file of the IP. Refer to the MPD of FSL you should
see that the default connections of clock and reset are left blank.
-Feilx
"David" <simianfever@gmail.com> wrote in message
news:1156891272.252770.135520@b28g2000cwb.googlegroups.com...
Thanks for your help guys, that fixed it. Interesting that the EDK
system assembly GUI doesn't hook up clock and reset by default...
Cheers,
David
Göran Bilski wrote:
> David wrote:
> > Göran Bilski wrote:
> >
> >
> >>David wrote:
> >>
> >>>Hi all,
> >>>
> >>>I'm trying to implement a correlator as a coprocessor on the FSL bus.
> >>>The first thing I've done is generate the FSL example using the create
> >>>peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
> >>>I do a blocking write or read the MB stalls - my understanding is that
> >>>this will happen if the FSL FIFO is full or empty respectively, but it
> >>>happens the first time I write to it, so the FIFO should not be full.
> >>>
> >>>If I use non-blocking reads and writes and check the error and invalid
> >>>flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> >>>below - everything seems normal but the output is always zero. Am I
> >>>implementing the error checking macros correctly?
> >>>
> >>>
> >>>#define write_into_fsl(val, id) nputfsl(val, id)
> >>>#define read_from_fsl(val, id) ngetfsl(val, id)
> >>>
> >>>#define WRITE_FSL_TEST_0(val) write_into_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> >>>#define READ_FSL_TEST_0(val) read_from_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >>>
> >>>
> >>>void fsl_test_app(
> >>> unsigned int* input_0, /* Array size = 2 */
> >>> unsigned int* output_0 /* Array size = 2 */
> >>> )
> >>>{
> >>> int i;
> >>> Xuint8 is_error = 0;
> >>> Xuint8 is_valid = 0;
> >>>
> >>> print("Entering fsl_test_app \r\n");
> >>>
> >>> //Start writing into the FSL bus
> >>> for (i=0; i<2; i++)
> >>> {
> >>>
> >>> WRITE_FSL_TEST_0(input_0[i]);
> >>> fsl_iserror(is_error);
> >>> xil_printf("error post: %d \r\n", is_error);
> >>> fsl_isinvalid(is_valid);
> >>> xil_printf("valid post: %d \r\n", is_valid);
> >>> }
> >>> print("Finished Write \r\n");
> >>>
> >>> is_error = 0;
> >>> is_valid = 0;
> >>>
> >>> //Start reading from the FSL bus
> >>> for (i=0; i<2; i++)
> >>> {
> >>> READ_FSL_TEST_0(output_0[i]);
> >>> fsl_iserror(is_error);
> >>> xil_printf("error post: %d \r\n", is_error);
> >>> fsl_isinvalid(is_valid);
> >>> xil_printf("valid post: %d \r\n", is_valid);
> >>> }
> >>>}
> >>>
> >>>I added external ports to the FSL core to check the reset polarity and
> >>>monitor the state machine - the core is not being held at reset, but
> >>>always sits in the Idle state. This, coupled with the blocking
> >>>instruction problems seems to indicate an issue with the FSL FIFO
> >>>perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> >>>If anyone has any ideas on what might be going wrong your help would be
> >>>much appreciated...
> >>>
> >>>
> >>>Cheers,
> >>>
> >>>David
> >>>
> >>
> >>Hi,
> >>
> >>Can you show the .mhs where you have connected your FSL core with
> >>Microblaze?
> >>
> >>Göran Bilski
> >
> >
> >
> > Hi Göran,
> >
> > Thanks for your reply, here are the relevant parts of the .mhs file:
> >
> > BEGIN microblaze
> > PARAMETER INSTANCE = microblaze_0
> > PARAMETER HW_VER = 4.00.a
> > PARAMETER C_USE_FPU = 0
> > PARAMETER C_DEBUG_ENABLED = 1
> > PARAMETER C_NUMBER_OF_PC_BRK = 2
> > PARAMETER C_FSL_LINKS = 1
> > BUS_INTERFACE DLMB = dlmb
> > BUS_INTERFACE ILMB = ilmb
> > BUS_INTERFACE DOPB = mb_opb
> > BUS_INTERFACE IOPB = mb_opb
> > BUS_INTERFACE SFSL0 = fsl_v20_0
> > BUS_INTERFACE MFSL0 = fsl_v20_1
> > PORT CLK = sys_clk_s
> > PORT DBG_CAPTURE = DBG_CAPTURE_s
> > PORT DBG_CLK = DBG_CLK_s
> > PORT DBG_REG_EN = DBG_REG_EN_s
> > PORT DBG_TDI = DBG_TDI_s
> > PORT DBG_TDO = DBG_TDO_s
> > PORT DBG_UPDATE = DBG_UPDATE_s
> > END
> >
> >
> > BEGIN fsl_v20
> > PARAMETER INSTANCE = fsl_v20_0
> > PARAMETER HW_VER = 2.00.a
> > PARAMETER C_EXT_RESET_HIGH = 0
> > PARAMETER C_IMPL_STYLE = 1
> > END
> >
> > BEGIN fsl_v20
> > PARAMETER INSTANCE = fsl_v20_1
> > PARAMETER HW_VER = 2.00.a
> > PARAMETER C_EXT_RESET_HIGH = 0
> > PARAMETER C_IMPL_STYLE = 1
> > END
> >
> > BEGIN fsl_test
> > PARAMETER INSTANCE = fsl_test_0
> > PARAMETER HW_VER = 1.00.c
> > BUS_INTERFACE MFSL = fsl_v20_0
> > BUS_INTERFACE SFSL = fsl_v20_1
> > PORT reset_out = fsl_test_0_reset_out
> > PORT state_debug = fsl_test_0_state_debug
> > END
> >
> > Cheers,
> >
> > David
> >
>
> Hi,
>
> You need to connect the system clock to the fsl_v20 modules.
> They are non clocked right now.
>
> One good trick is always to look at the top level vhdl file in the hdl
> directory. It's called system.vhd
>
> In that file you will see what signals are connected to what and it this
> case you should be able to see that the fsl bus doesn't have any clock
> connected.
>
> Göran Bilski
Article: 107558Suzie, you might want to try replacing R70 and R71 on the board with 1K resistors (currently 10K). While we are still looking into this issue it looks like the pull-up resistors are too weak resulting in a long rise time of SCL (and SDA). - Peter Suzie wrote: > I'm developing on an ML403 evaluation board with a Virtex-4 device. > I'm calling Xilinx's Level 0 I2C driver routines (XIic_Send, _Recv) > from a PPC405 program running under the QNX OS. I'm connecting to an > external I2C device, a temp sensor/ADC, via the J3 header on the ML403. > > When scoping the I2C SDA and SCL lines, I often notice a missing bit > within the 8-bit address word. Obviously, when this happens, the > addressed device does not ACK the transfer. > > I believe that my physical I2C connection is correct because I can > successfully and consistently use the GPIO-I2C bit-banging approach (as > implemented in Xilinx's iic_eeprom test program) to communicate with my > external device. > > I'm not sure how my operating environment or the driver could cause > this problem. The address is supplied by a single byte-write to the > OPB_IIC core's Tx FIFO register; that seems atomic to me. My gut > feeling is that there is a problem with the core. > > Anyone seen this problem, or know what I might be doing wrong?? >Article: 107559
Not sure if you got a solution to the issue. Did you mix up Windows and Linux by any chance. It typically happens because the system_incl.make file has a macro defined called XILINX_EDK_DIR which may not have the right value. You might want to delete the *.make file in the EDK project directory to make sure they are regenerated. Amit zwsdotcom@gmail.com wrote: >Grrrrr! Has anyone got ISE 7.1 working with EDK in Windows? Ever seen >this error before? > >I installed ISE/EDK per instructions, and got the titular error as soon >as I tried to generate a netlist inside Platform Studio. I assumed it >was something stupid I did/forgot to do, so I followed the tutorial at ><http://direct.xilinx.com/direct/ise7_tutorials/EDK7.1_ML403.pdf>. When >I click OK on the step at page 21 where a netlist is generated, I get >the exact same error: > >Xilinx Platform Studio >Xilinx EDK 7.1.2 Build EDK_H.12.5.1 >Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. > >XPS% Evaluating file >c:/xilprj/myproject/project_navigator/__projnav/system.synth.tcl >system.make:171: *** target pattern contains no `%'. Stop >ERROR:MDT - Error while running "make -f system.make netlist" >No changes to be saved in MSS file >No changes to be saved in XMP file > >It's hard to imagine a more vanilla installation than the one I'm >using, it's a WinXP install with everything defaulted. However I have a >spare unused laptop in its box here, with NOTHING but WinXP on it - so >I'm going to while away the hours installing the Xilinx software on >that machine. > >By the way, line 171 of system.make is the @mkdir line in the following >stanza: > >################################################################# ># BOOTLOOP ELF FILES >################################################################# > >$(PPC405_0_BOOTLOOP): $(PPC405_BOOTLOOP) > @mkdir -p $(BOOTLOOP_DIR) > cp -f $(PPC405_BOOTLOOP) $(PPC405_0_BOOTLOOP) > >Xilinx is well on the way to being my least favorite semiconductor >vendor of all time. Apart from their obnoxious software licensing, >there's a one business day delay in merely signing up for the privilege >of asking a question, let alone actually receiving an answer. And they >apparently never test their development software. I remember hating >Altera's tools when I last used them (I can still see the gray hairs >from that battle every time I look in a mirror), but at least their >tutorials worked! > >Anyhow - if anyone has seen this error before (Google found nothing >relevant), hints would be appreciated! > > >Article: 107560
rickman wrote: > In addition, the impedance of your package leads has no bearing on the > power decoupling. No amount of capacitace external or internal to the > device will have any impact on the bounce that will be caused by power > lead inductance. The only cure for that is a new package. I pretty much came to this realization with the XCV2000E parts in the BG560 package for high density reconfigurable computing needs. There was nothing I could do to overcome the BG560 packages small via, trace and bonding wire inductance to make the parts stable. Only choice was to seriously derate them.Article: 107561
matteo wrote: >OK I figured it out. This was my own ignorance of VHDL. I'm a Verilog >user. > >The Component declaration must go below the architecture of __ is line >and the Port Map is below begin > >matteo wrote: > > >>I'm having problems instantiating my EDK file within an ISE project. >> >>I have a top level VHDL that looks like: >> >>library IEEE; >>use IEEE.STD_LOGIC_1164.ALL; >>use IEEE.STD_LOGIC_ARITH.ALL; >>use IEEE.STD_LOGIC_UNSIGNED.ALL; >> >>---- Uncomment the following library declaration if instantiating >>---- any Xilinx primitives in this code. >>library UNISIM; >>use UNISIM.VComponents.all; >> >>entity topnew is >>end topnew; >> >>architecture RTL of topnew is >> >>begin >> >>COMPONENT system >> PORT( >> fpga_0_RS232_Uart_RX_pin : IN std_logic; >> fpga_0_DDR_CLK_FB : IN std_logic; >> sys_clk_pin : IN std_logic; >> sys_rst_pin : IN std_logic; >> PortName : IN std_logic; >> fpga_0_LEDs_4Bit_GPIO_IO_pin : INOUT std_logic_vector(0 to 3); >> fpga_0_LEDs_Positions_GPIO_IO_pin : INOUT std_logic_vector(0 to 4); >> fpga_0_Push_Buttons_Position_GPIO_IO_pin : INOUT std_logic_vector(0 >>to 4); >> fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin : INOUT std_logic_vector(0 to 3); >> fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin : INOUT std_logic_vector(0 to 31); >> fpga_0_SRAM_256Kx32_Mem_DQ_pin : INOUT std_logic_vector(0 to 31); >> >> fpga_0_RS232_Uart_TX_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin : OUT std_logic_vector(0 to 12); >> fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin : OUT std_logic_vector(0 to >>1); >> fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin : OUT std_logic; >> fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin : OUT std_logic_vector(0 to 3); >> fpga_0_SRAM_256Kx32_Mem_A_pin : OUT std_logic_vector(9 to 29); >> fpga_0_SRAM_256Kx32_Mem_BEN_pin : OUT std_logic_vector(0 to 3); >> fpga_0_SRAM_256Kx32_Mem_WEN_pin : OUT std_logic; >> fpga_0_SRAM_256Kx32_Mem_OEN_pin : OUT std_logic_vector(0 to 0); >> fpga_0_SRAM_256Kx32_Mem_CEN_pin : OUT std_logic_vector(0 to 0); >> fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin : OUT std_logic; >> fpga_0_SRAM_CLOCK : OUT std_logic >> ); >> END COMPONENT; >> >> Inst_system: system PORT MAP( >> fpga_0_RS232_Uart_RX_pin => , >> fpga_0_RS232_Uart_TX_pin => , >> fpga_0_LEDs_4Bit_GPIO_IO_pin => , >> fpga_0_LEDs_Positions_GPIO_IO_pin => , >> fpga_0_Push_Buttons_Position_GPIO_IO_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_Clk_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_Clkn_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_Addr_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_BankAddr_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_CASn_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_CKE_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_CSn_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_RASn_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_WEn_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_DM_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_DQS_pin => , >> fpga_0_DDR_SDRAM_64Mx32_DDR_DQ_pin => , >> fpga_0_SRAM_256Kx32_Mem_A_pin => , >> fpga_0_SRAM_256Kx32_Mem_BEN_pin => , >> fpga_0_SRAM_256Kx32_Mem_WEN_pin => , >> fpga_0_SRAM_256Kx32_Mem_DQ_pin => , >> fpga_0_SRAM_256Kx32_Mem_OEN_pin => , >> fpga_0_SRAM_256Kx32_Mem_CEN_pin => , >> fpga_0_SRAM_256Kx32_Mem_ADV_LDN_pin => , >> fpga_0_SRAM_CLOCK => , >> fpga_0_DDR_CLK_FB => , >> sys_clk_pin => , >> sys_rst_pin => , >> PortName => >> ); >> >> >>end architecture RTL; >> >> >>----------- >> >>But I get these errors: >> >>Compiling vhdl file "D:/comp8_xmp_ise/comp8/topnew.vhd" in Library >>work. >>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 37. >>parse error, unexpected COMPONENT >>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 40. >>parse error, unexpected IN >>ERROR:HDLParsers:164 - "D:/comp8_xmp_ise/comp8/topnew.vhd" Line 41. >>parse error, unexpected IN >> >> > > > You can also generate a verilog instantiation template for the XMP module in ISE. AmitArticle: 107562
Hi guys, Currently in my experiments I'm using an FF1152 Development Board originally by Memec. The FPGA chip on the board is XC2VP20 and the board is Revision 3. If any of you guys have worked with this board I'd be very thankful if you could advise me how I can solve the following problem that I have: I'm trying to measure the power of the FPGA chip and I know that the 1.5V power supply feeds just FPGA chip (At least this is my impression from the data sheet). So if I can measure the current on that supplier I should logically be able to measure the power. On the board there are two sets of pins besides which it has written CURRENT MEASURE on the board. One set of the pins which are connected with a jumper is JP39 and JP12, and JP14 which doesn't have a jumper and it has written SHUTDOWN next to it on the board. Exactly the same thing is for pins JP38 and JP7 and JP8 respectively. In the data sheet of the board I could find nothing related to these pins or if they are related to what I want to do which is measuring the current on power supply of the chip. So could you please let me know how I can measure the power of the chip? I have another question too. Is there any way for me to measure the power of the external memory? Actually I'm just interested to measure the power of FPGA chip and External Memory not other peripherals on the board. Do you know any solution for that? I really appreciate your response and thank you beforehand, AmirArticle: 107563
Hi guys, I'm trying to measure the power consumption on the board instead of using XPower. From the previous posts I know that if I can in a way measure the current on Vccint I can measure the power consumption of the chip (not the board). Is that correct? Is there any similar way for me to be able to measure the power on External Memory on the board? thanks, AmirArticle: 107564
Tony schreef: > Hi everyon, hope someone can give me a pointer or help. > > I lowered the system clock in the Altera stratix example design > (standard) from 50 to 35 Mhz. Is it necessary to change the time shift > of the sdram clock?? (-3.5ns by default) > > because, a time shift of -3.5 ns seems to work fine until i fixed a > huge (around 10k LE) jpeg decompression unit on to the system. Does > anyone know do i need a new time shift or not? > I tried a several delay from -1.0 to -8ns, but the system is still not > stable, my c program can be downloaded to the board but at times fails > to verification. > > (It sometimes passes verification, but the program doesn't run > properly. To simplify debugging, I only put a printf statment in my > main(), but it doesn't print) > > ps. I put my program and all data memory in sdram > Thanks Hi Tony, At the end of this chapter there is some information on your question: SDRAM Controller Core with Avalon Interface Datasheet: http://altera.com/literature/hb/nios2/n2cpu_nii51005.pdf Good luck, Karl.Article: 107565
Hi I have several questions powering the AVCCAUXRX/TX MGT power supply: -Are switching regulators allowed or should linears be used. An application note says switcher will work up to 3.125 with extensive filtering some say you should use linears. We want to work with the MGTs at 6.5. -How much power (amps) do unused MGTs consume? -Do unused MGTs generate lots of noise on the power supply so other components can be affected? My plan was to supply the unused MGTs from the same source than the 1.2 FPGA core without filtering caps. This would consume less space on the PCB, however it is crucial to know how much amps unused MGTs consume and if they generate noise on the power supply. thanks, Heiner LitzArticle: 107566
fpga_toys@yahoo.com writes: > > The doc's are available under the Doc page, which are Beta-2 docs. > Current work in progress will be always SVN. I try update the doc's as > we check things in, so it's not a frenzy at the next beta freeze. > Ahh, I see where they are - I was looking for them off the http://fpgac.sourceforge.net/ page. There's a sentence in there about docs, which might benefit from a hyperlink to the actual docs? <snip> > Martin Thompson wrote: > > Have you considered doing a higher-level technology independent > > VHDL/Verilog backend, which could then be thrown into a normal > > synthesizer and let it ifugre out the best adders and such like - > > they've been practising that for a number of years now :-) > > There is a VHDL output, fully functional I believe in Beta-1 ... it got > broke in Beta-2, and will be fixed at Beta-3 again (which should be > very soon). > I think that's also low-level though, LUTs and wiring? I was thinking of something higher-level, where if you have an adder, you put a<=b+1 in the VHDL and let the synth sort it out. Or are there benefits to optimising across the great sea of LUTs that a normal synth doesn't get to? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 107567
Jan Panteltje <pNaonStpealmtje@yahoo.com> writes: > On a sunny day (29 Aug 2006 11:42:00 +0100) it happened Martin Thompson > <martin.j.thompson@trw.com> wrote in <uk64rzuvb.fsf@trw.com>: > > > >Neal Stephenson wrote "in the beginning was the command line" > >http://www.cryptonomicon.com/beginning.html > > I have just read part of that, he really gets out there.... :-) > Yeah :-) > For me, one thing the 'command line' interface does, is allow me to speak > normal language to a computer. > This is important in interfacing to computers with speech. > > For example I have a script (Linux Bash) called 'show', and a PCI satellite > card in the PC. > http://panteltje.com/panteltje/satellite/show > When I _type_ 'show BBC2' at the command prompt, then it will steer the dish > to one of the Astra satellites and start mplayer. > Yep, get it done once and it's easy all the other times! I've often thought that good engineers are fundamentally lazy - they only want to do something once, do it well, then get on with the next thing, having made the first thing so easy that they don't have to think about it! When I can make that less waffley (sp?), it might become a .sig... > And when I _say_ 'show bbc2' it will do the same, using perlbox voice. > Neat- I shall have to play with that! > The ability to make commands that are simply spelled as English words is > perhaps the most powerful thing. > 'Random access'. > > You often _know_ what program or action you want the computer to do, and > going via many menus to dig deeper and deeper is a barrier, takes time. > It's OK the first time when you are exploring something new, the guidance can be a boon. But when you have to do it every time, it gets a bit annoying. <snip> > Same in FPGA, use makefiles, scripts. > Ahh, back on topic :-) Ditto for me. I wouldn't be without python now! > To pester MS windows users I say sometimes: 'My PC speaks English'. > How do they respond to "goading" like that? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 107568
Nico Coesel wrote: > "Antti" <Antti.Lukats@xilant.com> wrote: > >> >>in any case - I can not and do not want to belive that Xilinx designed >>boards with features knowing not to work (at the time of the board >>design). >> > > Lets say Xilinx is a bit too optimistic about their devices every now > and then. > Just like Micro$oft is about its OS software. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens.  --SchillerArticle: 107569
rickman wrote: > John_H wrote: >> "rickman" <gnuarm@gmail.com> wrote in message >> Won't any higher inductance result in the same above-SRF slope? That is, >> given the total inductance, it won't matter what the capacitance is once >> above an ohm in the impedance vs freq plot. > > I'm not sure what you are asking. A different capacitance will not > change the inductive part of the impedance curve and a different > inductance will not change the capacitive part of the curve. What > changes in both cases is the SRF. So you put a few 0.1 uF caps on the > board and a number more of 0.01 uF caps and even more of the 0.001 uF > caps. Each capacitance value needs to have sufficient quantity to > bring the impedance near the SRF low enough to be effective. Then the > capacitive effect of the smaller caps keep the overall impedance low in > spite of the larger caps being inductive. Finally the impedance of the > ground planes keep the impedance low for the highest frequency. Doing > a simulation is always a good thing to be able to see how the parallel > resonances affect the impedance. > I've not any high speed boards - the last board I made had internal frequencies at 150 MHz, and an external bus at 75 MHz (overclocked in testing to about 240/120 MHz), so maybe I'm missing something that happens at higher frequencies. Using a simple tool such as Murata's software, I looked at the impedances for different capacitors at different frequencies. To a fair extent, the inductance is determined by the package size (and the board vias and traces), while the capacitance obviously goes up with the cap's value. So choosing a 0.01 uF instead of a 0.1 uF cap increases the capacitance side of the impedance curve by a factor of 10, and leaves the inductive side unchanged. It changes the peak frequency, but I fail to see why that should make a real difference - it has the same or higher impedance across the frequency range. Given that the 0.1 uF type has lower ESR (being made of more parallel plates), I can't find any way in which the 0.01 uF is better. So as Symon says (unless I'm misinterpreting him), the best arrangement is to pick the smallest size package you can conveniently mount (0603 for us), then the largest capacitance value you can conveniently and economically get in that size (100 nF), and use as many as needed for the board. Placement should be close to the device where possible, but is not very critical as long as it is within the range of the mini power plane (i.e., polygon on a signal layer). It works for me - but then again, I'm not doing really high-end cards.Article: 107570
I know this topic has been discussed before, but i am looking for some ideas. My design is synchronous, I use ISE8.2.02 XST and ModelSim, I have a lot of signed logic; I get different results from behavioral and post-Route simulations. I paid attention to the reset condition, in fact the data are ok after the first stage of the circuit. I tried to delay the data compared to the clock with no success. I noticed that at the first rising edge of the clock most signals are x in the post-P&R simulation, while they are defined in the behavioral simulation. Any advice before bringing out every meaningful signal in the implementation process ? Any known bug in the simulation models of the xilinx primitives (multipliers, BRAMs, etc) ? TullioArticle: 107571
mikegurche@yahoo.com writes: <snip commentary on variables> > > In synthesis, the problem is normally the abuse of sequential > statements, rather than the use of variable. I have seen people trying > to convert C segment into a VHDL process (you can have variables, for > loop, while loop, if, case, and even break inside a process) and > expecting synthesis software to figure out everything. > Why not do this? Synthesis software is good at figuring all this out. If it does what you need it to and meets timing, you're done. Move on to the next problem. Personally, I have seen people spend far too long doing very explicit coding of detailed stuff, giving the synth tool very little to do, which for a relatively low-performance (still in the 10s of MHz though) design, was a waste of effort. The so-called "naive" approach of writing code in a natural "softwary" way and letting the synth sort it out would have left us more time to sort out the one nitty-gritty bit of code which did have a performance problem. Sure, if you are pushing the performance envelope, you're going to have to put more work in. If you are doing a high-volume design then you might get in a smaller part and save some money by putting the effort in. But that's just an engineering-tradeoff like any other. Softies do it all the time, optimising their hardcore interrupt handlers, leave the rest to the tools. I assume civil engineers do similar things with their bridges as well :-) > My 2 cents. > My tuppence :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 107572
Ben, Does this 'Cyclix' mean a CYCLone with mIXed signal - or flash based Cyclone, or just a typo for Cyclone3 Regards, Luc On Wed, 30 Aug 2006 00:11:33 +0200, Ben Twijnstra <btwijnstra@gmail.com> wrote: >Jim Granville wrote: > >> Any info out yet on what MAX3 looks like ? >> Does it improve Static Icc, and lack of memory of MAX II, for example ? >> Smallest devices / largest devices ? > >Nope - Altera's silicon design team is quite busy with Cyclix III. If you >have any good suggestions on specs outside the hobby sphere, now might be a >good time to post them... > >BenArticle: 107573
Hi All, as I had guessed for long time the PMV primitive is actually the on-chip oscillator, most likely it is the same oscillator that is used for configuration. And it can be used from user designs as well. PMV is present in all recent FPGAs. http://xilant.com/index.php?option=com_content&task=view&id=29&Itemid=32 When I opened webcase about the issue that Xilinx tools made fatal failure when I tried to use the PMV from an hard macro the response was that, "you dont need to know" - well now I know :) AnttiArticle: 107574
lb.edc@telenet.be wrote:
>Ben,
>
>Does this 'Cyclix' mean a CYCLone with mIXed signal - or flash based
>Cyclone, or just a typo for Cyclone3
>
>Regards,
>
>Luc
>
>
>
Luc,
I think is more like "spartex" or "virtan" in X-world. ;-)
Aurash
>On Wed, 30 Aug 2006 00:11:33 +0200, Ben Twijnstra
><btwijnstra@gmail.com> wrote:
>
>
>
>>Jim Granville wrote:
>>
>>
>>
>>>Any info out yet on what MAX3 looks like ?
>>>Does it improve Static Icc, and lack of memory of MAX II, for example ?
>>>Smallest devices / largest devices ?
>>>
>>>
>>Nope - Altera's silicon design team is quite busy with Cyclix III. If you
>>have any good suggestions on specs outside the hobby sphere, now might be a
>>good time to post them...
>>
>>Ben
>>
>>
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
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