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
On Feb 9, 3:15=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Symon <symon_bre...@hotmail.com> wrote: > > (snip) > > > Sure Rick, let's go through it together with some cheap tools (free!) > > from t'internet. OK, you can get a nice copy of Spice from here. maybe > > you already have it. > >http://www.linear.com/designtools/software/ > > At the bottom of this post you will find a model of a PCB with a power > > plane bypass. I've used lumped components to model it. If you > > cut'n'paste the text into an editor and save it as 'planes.asc' or > > somesuch, you should be able to load it into the simulator you download= ed. > > (really big snip) > > I think you really need a model of the radial transmission line, > which I don't see (but could have missed). > > See the papers I mentioned in previous posts. I think I have figured out why you *don't* need to consider a radial transmission line in models of the PDS. The transmission line model is only effective if the length of the line is longer than about 1/6th of the rising edge of the signal. For a 0.5 ns rise time pulse the rising edge is about 3 inches in length on the PWB. So if you keep your caps within a half inch of the power pins of the chip, the transmission line effects are spread over the entire path (or averaged if you will). In other words, for adequately short paths, the electrical path between the power pins and decoupling caps appears as a lumped capacitance and does not need to be analyzed as a transmission line. Does that sound right? RickArticle: 145626
On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > Hi > > my co-worker has a problem with EDK (used on w7, 32bit) > OLD project can be built but any new projexcts created stop > during implementation > > xilinx claims that the following tablehttp://www.xilinx.com/ise/ossupport= /index.htm > > is UPTODATE OS support list for Xilinx tools, in that table win7 is > missing > > so what is wrong? is there something wrong with the installation, but > hey > why then old projects pass full flow? > > any ideas? > > Antti Win7 isn't a supported OS for ISE tools and it is not listed in the table. The tools may work under some conditions, but they likely will not under all conditions as your co-worker found out. Ed McGettigan -- Xilinx Inc.Article: 145627
On Feb 15, 2:08=A0pm, "msegura" <ms_...@usc.edu> wrote: > Hi, I'm workng with MGT as GT_CUSTOM. > I use the MGT for transmiting to pulses of .66ns(1/15Ghg). > I check all the delays with FPGA editor and all was ok, but I mesure the > pulses at the SATA conector and there are a delay between SATA0 and SATA1 > of 500ps. > I simplified the program as much as posible and this delay is always > present. > The mesurment was made with the same cable lenght. > > Same ideas? > Thansk > Marcelo > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com The lane-to-lane skew isn't zero and the maximum value is listed in the device datasheet. For instance with Virtex-5 the GTP value is 855ps. Ed McGettigan -- Xilinx Inc.Article: 145628
Have you tried running ISE using Windows 7 compatibilty mode. I found that some of the programs that I used to run in XP wouldnt run in 7 unless I used the compatibility mode. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145629
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> I think you really need a model of the radial transmission line, >> which I don't see (but could have missed). >> See the papers I mentioned in previous posts. > I think I have figured out why you *don't* need to consider a radial > transmission line in models of the PDS. The transmission line model > is only effective if the length of the line is longer than about 1/6th > of the rising edge of the signal. For a 0.5 ns rise time pulse the > rising edge is about 3 inches in length on the PWB. So if you keep > your caps within a half inch of the power pins of the chip, the > transmission line effects are spread over the entire path (or averaged > if you will). In other words, for adequately short paths, the > electrical path between the power pins and decoupling caps appears as > a lumped capacitance and does not need to be analyzed as a > transmission line. It does seem that the previously mentioned papers analyze them in ways that I wouldn't think would matter. One even considers the reflection of other vias. But, there are a few things that I think should be considered. The inductance of the via, and the input impedance of the radial transmission line are proportional to 1/r. Big vias are better. A group of vias close enough together, though, should act like a large via. (The fields couple such that it isn't the same as parallel inductors.) It would seem that one should also be careful not to put the FPGA right in the center of a large ground plane, such the the edge reflections come back in phase. That would be especially bad for a large circular ground plane. If the decoupling capacitors were regularly spaced, that could also cause in-phase reflections. > Does that sound right? It doesn't seem so far off. It still seems that radial transmission line theory isn't taught much at all. -- glenArticle: 145630
On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > I finally understand the reason when a flip-flops can be replaced by a > latch. > I saw the circuits before, but not realized what the basic reason was. > With the above paper, I now know that the technology is not a new, it > originated in 1980s. Even earlier than that. Just look at the relative sales volumes of the venerable 74373 vs 74374. In all those cases, the latch is used to buy some extra setup time. Anywhere you find an ALE pin, you find this principle, and that goes back a LONG way. -jgArticle: 145631
On Feb 16, 12:36=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > Hi, > > I finally understand the reason when a flip-flops can be replaced by a > > latch. > > I saw the circuits before, but not realized what the basic reason was. > > With the above paper, I now know that the technology is not a new, it > > originated in 1980s. > > Even earlier than that. > > =A0Just look at the relative sales volumes of the venerable 74373 vs > 74374. > =A0In all those cases, the latch is used to buy some extra setup time. > > =A0Anywhere you find an ALE pin, you find this principle, and that goes > back a LONG way. > > -jg jg, I checked SN74LV374 TI's manual and couldn't find what you said: ALE pin. For time borrowing through a pipelined stages, Intel uses Domino Logic which was not available until 2000. WengArticle: 145632
Weng Tianxiang <wtxwtx@gmail.com> wrote: > On Feb 16, 12:36?pm, -jg <jim.granvi...@gmail.com> wrote: >> Even earlier than that. >> ?Just look at the relative sales volumes of the venerable 74373 vs >> | 74374. In all those cases, the latch is used to buy some extra >> | setup time. >> ?Anywhere you find an ALE pin, you find this principle, and that >> | goes back a LONG way. > I checked SN74LV374 TI's manual and couldn't find what you > said: ALE pin. ALE is an output on, for example, many Intel processors. Address Latch Enable, such that the address can be latched while the pins are used for other purposes. The 8085 shares the data bus with part of the address bus, for example. With a 74S373 the address is available for decoding long before ALE goes low. -- glenArticle: 145633
On Feb 16, 3:17 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip, I wrote) > > >> I think you really need a model of the radial transmission line, > >> which I don't see (but could have missed). > >> See the papers I mentioned in previous posts. > > I think I have figured out why you *don't* need to consider a radial > > transmission line in models of the PDS. The transmission line model > > is only effective if the length of the line is longer than about 1/6th > > of the rising edge of the signal. For a 0.5 ns rise time pulse the > > rising edge is about 3 inches in length on the PWB. So if you keep > > your caps within a half inch of the power pins of the chip, the > > transmission line effects are spread over the entire path (or averaged > > if you will). In other words, for adequately short paths, the > > electrical path between the power pins and decoupling caps appears as > > a lumped capacitance and does not need to be analyzed as a > > transmission line. > > It does seem that the previously mentioned papers analyze them > in ways that I wouldn't think would matter. One even considers > the reflection of other vias. > > But, there are a few things that I think should be considered. > The inductance of the via, and the input impedance of the radial > transmission line are proportional to 1/r. Big vias are better. > A group of vias close enough together, though, should act like > a large via. (The fields couple such that it isn't the same > as parallel inductors.) > > It would seem that one should also be careful not to put the FPGA > right in the center of a large ground plane, such the the edge > reflections come back in phase. That would be especially bad for > a large circular ground plane. If the decoupling capacitors were > regularly spaced, that could also cause in-phase reflections. > > > Does that sound right? > > It doesn't seem so far off. It still seems that radial transmission > line theory isn't taught much at all. I am confused. You say that my analysis is not far off and the whole (hole) point of my analysis is to show that the radial transmission line effect is not important. Then you say you still think the radial transmission line effect *is* important. I am pretty sure that the effects of the decoupling caps swamps out the effect of the reflections. This is not very scientific and so may be totally wrong, but it would seem to me that the caps will "mute" the voltage transitions on the plane as the wave moves by. If it were a linear transmission line, the cap would "smear" out the edge of the wave front. In the PCB power plane the same thing happens, but it is likely strongest at the cap and is a weaker effect further away from the cap. In the case of a transient, smearing it out reduces the amplitude which is exactly what it is supposed to do. So I expect the wave front never reaches a board edge to cause a significant reflection. I will say that when the impedance of a PDS is measured the very high frequencies often have a sawtooth shape which is likely due to standing waves on the board. So there must be some of the transient that is reflected. But if you can verify your analysis method by measuring the impedance of the PDS to be below your requirements at all frequencies, what does it matter if the power planes form a "radial transmission line"? You only need to do enough analysis to get a "good enough" result. I would think that if this were an important effect, that would have been discovered by now. RickArticle: 145634
On Feb 16, 7:07=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Feb 16, 12:36=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > > > On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > Hi, > > > I finally understand the reason when a flip-flops can be replaced by = a > > > latch. > > > I saw the circuits before, but not realized what the basic reason was= . > > > With the above paper, I now know that the technology is not a new, it > > > originated in 1980s. > > > Even earlier than that. > > > =A0Just look at the relative sales volumes of the venerable 74373 vs > > 74374. > > =A0In all those cases, the latch is used to buy some extra setup time. > > > =A0Anywhere you find an ALE pin, you find this principle, and that goes > > back a LONG way. > > > -jg > > jg, > I checked SN74LV374 TI's manual and couldn't find what you said: ALE > pin. > > For time borrowing through a pipelined stages, Intel uses Domino Logic > which was not available until 2000. The reason twofold. One is that the pin was not called ALE on the latch, it was called C or G or LE or something similar. ALE is from the Intel CPUs that require the latch to hold the address bits. The other reason is that you are looking at the wrong part. The 373 part is the latch and the 374 part is the register. I am pretty sure the only difference is the function of the clock input. The latch is used with these processors for the exact reason you are looking at latches. It allows the output of the latch to output a stable value from the input before the clock edge rather than after. This was used to speed memory accesses. RickArticle: 145635
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> But, there are a few things that I think should be considered. >> The inductance of the via, and the input impedance of the radial >> transmission line are proportional to 1/r. Big vias are better. >> A group of vias close enough together, though, should act like >> a large via. (The fields couple such that it isn't the same >> as parallel inductors.) >> It would seem that one should also be careful not to put the FPGA >> right in the center of a large ground plane, such the the edge >> reflections come back in phase. That would be especially bad for >> a large circular ground plane. If the decoupling capacitors were >> regularly spaced, that could also cause in-phase reflections. >> > Does that sound right? >> It doesn't seem so far off. It still seems that radial transmission >> line theory isn't taught much at all. > I am confused. You say that my analysis is not far off and the whole > (hole) point of my analysis is to show that the radial transmission > line effect is not important. Then you say you still think the radial > transmission line effect *is* important. > I am pretty sure that the effects of the decoupling caps swamps out > the effect of the reflections. This is not very scientific and so may > be totally wrong, but it would seem to me that the caps will "mute" > the voltage transitions on the plane as the wave moves by. If it works right, the capacitor should be an AC short between the planes. If, for example, you had a ring of capacitors around a constant radius from a via, then the reflection off those should come back in phase. That is pretty much the same as a microwave cavity resonator. > If it were > a linear transmission line, the cap would "smear" out the edge of the > wave front. A capacitor across a linear transmission line should make a nice reflection. A capacitor and series resistor should absorb some of the AC signal, but ignore the DC voltage. Though that assumes ideal capacitors. > In the PCB power plane the same thing happens, but it is > likely strongest at the cap and is a weaker effect further away from > the cap. In the case of a transient, smearing it out reduces the > amplitude which is exactly what it is supposed to do. So I expect the > wave front never reaches a board edge to cause a significant > reflection. I will say that when the impedance of a PDS is measured > the very high frequencies often have a sawtooth shape which is likely > due to standing waves on the board. So there must be some of the > transient that is reflected. In a real board with lots of ICs, vias, and bypass capacitors, you would hope that the reflections are rarely in phase. If parts are placed too regularly on the board, it would seem possible for some strong resonance to form. > But if you can verify your analysis method by measuring the impedance > of the PDS to be below your requirements at all frequencies, what does > it matter if the power planes form a "radial transmission line"? I think it only really matters for a very short distance. For that distance, though, it should be computed as a radial transmission line. > You only need to do enough analysis to get a "good enough" result. > I would think that if this were an important effect, that would have > been discovered by now. There have been plenty of cases where effects when unnoticed for way too long. If, for example, a board resonance turned out to be the same as an on-board frequency it could easily be very significant. Then an unrelated change would move the resonance, and the problem would go away without ever being found. -- glenArticle: 145636
rickman <gnuarm@gmail.com> wrote: (snip) > The latch is used with these processors for the exact reason you are > looking at latches. It allows the output of the latch to output a > stable value from the input before the clock edge rather than after. > This was used to speed memory accesses. I still remember latches from when I first started learning about TTL from Popular Electronics. It was usual to connect a 7490 counter, a 7475 latch and 7447 BCD to 7 segment decoder together. You run the counter, the display counts (maybe too fast to see), and then latches at the appropriate time. Sort of like a lap timer in a race, which counts up, the latch holds the value while the counter continues on. After a short time the count continues on for the next lap. (I think they do this on olympics races.) -- glenArticle: 145637
On Tue, 16 Feb 2010 13:50:02 +0000, Symon <symon_brewer@hotmail.com> wrote: >On 2/16/2010 12:45 PM, he wrote: >> First you should constrain the used BRAMs to fixed locations, so you >> don't have to recreate a new bmm file after each P&R run. >> Most probably, you will have to write the BMM file "by hand" (see the >> link posted by Symon, tell me if theres an automated way ;) > >I dimly recall analysing the RBT format, and then writing a perl script >that searched through the RBT file for a BRAM with contents beginning >"DEADBEEF", or whatever I'd tagged the BRAM with, to automatically >update the BMM after a PAR. However, as you point out, constraining the >placement was much easier. Bitgen (at least I think it's Bitgen and not PAR) will update a BMM file for you, with the latest placements - IF you sing the right incantations first. The first step is to write a myfile.bmm file without the placements - using one generated by EDK as an example is a good idea. The second step is to feed it into "Translate" (if using the GUI) or ngdbuild (command line) with the right options ... -bd myfile.bmm if I remember correctly. Check the ".bld" report file to see if the BMM file was read correctly; if not, it's not going to report an error via the GUI or console! Then the BMM magic disappears into the tool flow without trace. But if the myfile.bmm is still there when Bitgen runs, the earlier magic reappears and you might see a new myfile_bd.bmm file, annotated with the correct BRAM placements. There is documentation on this. But it's so well hidden that the Webcase tech support team submitted a change request to get some written when I complained I couldn't find any, even though it was apparently already in existence by then... - BrianArticle: 145638
Some great stuff here. Let me add my re-implementation of a New England Digital Able, the first commercial single-instruction processor. <http://sites.google.com/site/macthenaief/Home/retro/able> <http://sites.google.com/site/macthenaief/Home/retro/fab>Article: 145639
Symon wrote: > > I dimly recall analysing the RBT format, and then writing a perl script > that searched through the RBT file for a BRAM with contents beginning > I've noticed a more recent ncd -> bmm generation perl script in the OpenFire distribution that might be useful: http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download OpenFire_release/utils/openfire_bram.pl " "This program creates a BMM file from an NCD and uses this to read and "write initial BRAM contents from a bitstream. " "NOTE: XDL and DATA2MEM must be installed and in the user's path. " "usage: $0 [-h] [-n NCD_FILE -o BMM_FILE] [-r ROM_FILE -b BITSTREAM] " " -h : this (help) message " -n NCD_FILE : NCD_FILE containing placed BRAMs (default = implementation/system.ncd) " -o BMM_FILE : BMM_FILE to create (default = implementation/ openfire.bmm) " -t top-level module : name of the top-level OpenFire module (default = openfire) " -f ELF_FILE : ELF file to place in OpenFire memory (optional) " -b BITSTREAM : bitstream to update with BRAM contents " (default = "implementation/download.bit) " -x XDL_FILE : use specified XDL file (w/o flag, generates own from NCD_FILE) " -p # : number of processors in design; named top- level_module0, top-level_module1, etc. " (default = 1) " "example: $0 -n system.ncd -o system.bmm -f openfire.elf -b download.bit "example: $0 -o system.bmm -p 4 -t vtmb_ " BrianArticle: 145640
On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > Hi > > > my co-worker has a problem with EDK (used on w7, 32bit) > > OLD project can be built but any new projexcts created stop > > during implementation > > > xilinx claims that the following tablehttp://www.xilinx.com/ise/ossuppo= rt/index.htm > > > is UPTODATE OS support list for Xilinx tools, in that table win7 is > > missing > > > so what is wrong? is there something wrong with the installation, but > > hey > > why then old projects pass full flow? > > > any ideas? > > > Antti > > Win7 isn't a supported OS for ISE tools and it is not listed in the > table. > > The tools may work under some conditions, but they likely will not > under all conditions as your co-worker found out. > > Ed McGettigan > -- > Xilinx Inc. Hi and thanks for clarification, I could not belive the table to be accurate as of today everybody DOES support w7 already ;) ok maybe not all companies do, but most other software does run nicely on w7 AnttiArticle: 145641
On Feb 16, 8:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip, I wrote) > > > > >> But, there are a few things that I think should be considered. > >> The inductance of the via, and the input impedance of the radial > >> transmission line are proportional to 1/r. =A0Big vias are better. > >> A group of vias close enough together, though, should act like > >> a large via. =A0(The fields couple such that it isn't the same > >> as parallel inductors.) > >> It would seem that one should also be careful not to put the FPGA > >> right in the center of a large ground plane, such the the edge > >> reflections come back in phase. =A0That would be especially bad for > >> a large circular ground plane. =A0If the decoupling capacitors were > >> regularly spaced, that could also cause in-phase reflections. > >> > Does that sound right? > >> It doesn't seem so far off. =A0It still seems that radial transmission > >> line theory isn't taught much at all. > > I am confused. =A0You say that my analysis is not far off and the whole > > (hole) point of my analysis is to show that the radial transmission > > line effect is not important. =A0Then you say you still think the radia= l > > transmission line effect *is* important. > > I am pretty sure that the effects of the decoupling caps swamps out > > the effect of the reflections. =A0This is not very scientific and so ma= y > > be totally wrong, but it would seem to me that the caps will "mute" > > the voltage transitions on the plane as the wave moves by. =A0 > > If it works right, the capacitor should be an AC short between the > planes. =A0If, for example, you had a ring of capacitors around > a constant radius from a via, then the reflection off those should > come back in phase. =A0That is pretty much the same as a microwave > cavity resonator. =A0 You are still talking about the reflections from the caps and I have already shown that the caps don't cause reflections as long as they are very close to the vias connecting the power pins. The wavelength of the transients are too long so that only a portion of the edge is ever distributed across the transmission line between the via and the cap. The result is that the reflection is insignificant and the cap acts to suppress the wavefront and not let it pass beyond the region around the cap. > > If it were > > a linear transmission line, the cap would "smear" out the edge of the > > wave front. =A0 > > A capacitor across a linear transmission line should make a nice > reflection. =A0A capacitor and series resistor should absorb some > of the AC signal, but ignore the DC voltage. =A0Though that assumes > ideal capacitors. But not if the transition time of the edge is slow compared to the transit time to the cap. The reflection would be the opposite phase, but much, much smaller in amplitude than the full transient. Meanwhile the amount of the transient passing the cap would also be very small because most of the energy is reflected. > > In the PCB power plane the same thing happens, but it is > > likely strongest at the cap and is a weaker effect further away from > > the cap. =A0In the case of a transient, smearing it out reduces the > > amplitude which is exactly what it is supposed to do. =A0So I expect th= e > > wave front never reaches a board edge to cause a significant > > reflection. =A0I will say that when the impedance of a PDS is measured > > the very high frequencies often have a sawtooth shape which is likely > > due to standing waves on the board. =A0So there must be some of the > > transient that is reflected. > > In a real board with lots of ICs, vias, and bypass capacitors, > you would hope that the reflections are rarely in phase. =A0If parts > are placed too regularly on the board, it would seem possible for > some strong resonance to form. =A0 I don't mean to repeat myself endlessly, but I don't think you will see much of the reflections. The wave front does not pass the area around the cap since it is absorbed by the cap. The reflection from the cap is opposite in phase as the original transient and is only displaced a fraction of the width of the transient so it nearly cancels out in all directions. The degree to which it cancels out depends on the time offset of the reflection which is determined by the spacing between the cap and the power via and the strength of the reflection which in turn depends on the impedance of the cap at that frequency. The reflection is a good thing, not a bad thing. That is what reduces the transient! > > But if you can verify your analysis method by measuring the impedance > > of the PDS to be below your requirements at all frequencies, what does > > it matter if the power planes form a "radial transmission line"? =A0 > > I think it only really matters for a very short distance. For that > distance, though, it should be computed as a radial transmission line. I t would seem to me to make more of a difference over a larger distance where the impedance seen varies much more. If you think of it as an impedance that reduces with distance from the power via, it would create a continuous reflection back to the via, in effect reducing the amplitude of the transient. Imagine many, small reflections with only a very slight difference in phase summing up. In effect, it would be a lot like a lumped capacitance right at the via I think. > > You only need to do enough analysis to get a "good enough" result. > > I would think that if this were an important effect, that would have > > been discovered by now. > > There have been plenty of cases where effects when unnoticed for > way too long. =A0If, for example, a board resonance turned out to > be the same as an on-board frequency it could easily be very > significant. =A0Then an unrelated change would move the resonance, > and the problem would go away without ever being found. If that resonance were causing a problem, I would expect that it would be noticed and recognized at some point. Any given board might have some change made which will cause the problem to "go away", but I can't believe at this point in time no one would have ever seen this and recognized it for what it was. Why make up problems if they don't exist? RickArticle: 145642
On Feb 16, 9:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > Hi > > > > my co-worker has a problem with EDK (used on w7, 32bit) > > > OLD project can be built but any new projexcts created stop > > > during implementation > > > > xilinx claims that the following tablehttp://www.xilinx.com/ise/ossup= port/index.htm > > > > is UPTODATE OS support list for Xilinx tools, in that table win7 is > > > missing > > > > so what is wrong? is there something wrong with the installation, but > > > hey > > > why then old projects pass full flow? > > > > any ideas? > > > > Antti > > > Win7 isn't a supported OS for ISE tools and it is not listed in the > > table. > > > The tools may work under some conditions, but they likely will not > > under all conditions as your co-worker found out. > > > Ed McGettigan > > -- > > Xilinx Inc. > > Hi > > and thanks for clarification, I could not belive the table to be > accurate > as of today everybody DOES support w7 already ;) ok maybe not > all companies do, but most other software does run nicely on w7 > > Antti- Hide quoted text - > > - Show quoted text - ISE 11.1 was released in April while Windows 7 wasn't released until October. While smaller companies and academia tend to move faster with Windows OS upgrades as the tend to use the OS sold with the PC/Laptop larger companies in constrast don't rapidly upgrade the OS and prefer to stay with older, stable versions. A quick survey of other EDA tools shows Synopsys Synplify Pro - Win XP, Win Vista, Linux, Solaris Mentor ModelSim PE - Win XP, Win Vista (32) Mentor ModelSim SE - Win XP, Win Vista (32), Linux (32) Mentor ModelSim DE - Win XP, Win Vista (32/64), Linux (32/64), Solaris (32/64) Altera Quatrus II 9.1 - Win XP, Win Vista, Red Hat 4/5, Suse 9/10, CentOS 4/5 Lattice ispLever - Win 2K, Win XP, Win Vista (32), Red hat 3/4, Suse 10, Solaris 2.8/10 Actel Libero - Win XP, Win Vista, Red Hat WS 4/5.2 Ed McGettigan -- Xilinx Inc.Article: 145643
On Feb 17, 9:47=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Feb 16, 9:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > > > On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote: > > > > > Hi > > > > > my co-worker has a problem with EDK (used on w7, 32bit) > > > > OLD project can be built but any new projexcts created stop > > > > during implementation > > > > > xilinx claims that the following tablehttp://www.xilinx.com/ise/oss= upport/index.htm > > > > > is UPTODATE OS support list for Xilinx tools, in that table win7 is > > > > missing > > > > > so what is wrong? is there something wrong with the installation, b= ut > > > > hey > > > > why then old projects pass full flow? > > > > > any ideas? > > > > > Antti > > > > Win7 isn't a supported OS for ISE tools and it is not listed in the > > > table. > > > > The tools may work under some conditions, but they likely will not > > > under all conditions as your co-worker found out. > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Hi > > > and thanks for clarification, I could not belive the table to be > > accurate > > as of today everybody DOES support w7 already ;) ok maybe not > > all companies do, but most other software does run nicely on w7 > > > Antti- Hide quoted text - > > > - Show quoted text - > > ISE 11.1 was released in April while Windows 7 wasn't released until > October. > > While smaller companies and academia tend to move faster with Windows > OS upgrades as the tend to use the OS sold with the PC/Laptop larger > companies in constrast don't rapidly upgrade the OS and prefer to stay > with older, stable versions. > > A quick survey of other EDA tools shows > > Synopsys Synplify Pro - Win XP, Win Vista, Linux, Solaris > Mentor ModelSim PE - Win XP, Win Vista (32) > Mentor ModelSim SE - Win XP, Win Vista (32), Linux (32) > Mentor ModelSim DE - Win XP, Win Vista (32/64), Linux (32/64), Solaris > (32/64) > Altera Quatrus II 9.1 - Win XP, Win Vista, Red Hat 4/5, Suse 9/10, > CentOS 4/5 > Lattice ispLever - Win 2K, Win XP, Win Vista (32), Red hat 3/4, Suse > 10, Solaris 2.8/10 > Actel Libero - Win XP, Win Vista, Red Hat WS 4/5.2 > > Ed McGettigan > -- > Xilinx Inc. We already have 11.4 tools ok, the situation is not that bad, EDK 11.3 failed on W7/64 but worked somewhat on W7/32 (after some tweaking) we still may need another vista machine as the client reqests EDK 10.x AnttiArticle: 145644
library ieee; library work; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity delay_line_interleaved is generic( numtaps : integer := 18; wordlength_in : integer := 14; coefflen : integer := 20 ); port( -- INPUT PORTS -- clkin : in std_logic; rst : in std_logic; ena : in std_logic; in_pddc : in std_logic_vector(wordlength_in-1 downto 0); --enough bits here and other places to handle number of adds? -- OUTPUT PORTS -- dv_out : out std_logic; x_delay_line : out array (0 to coefflen-1) of std_logic_vector(wordlength_in-1 downto 0) ); end entity; --------------------------------------- Posted through http://www.FPGARelated.comArticle: 145645
Hi,
Sometimes, when an if statement misses a "else" statement part in a
two-process
method for a state machine, a latch-type state machine would be built.
I always wondering how the state machine is built: using all latches
for the state machine
or using only one latch for the state which misses a "else" statement
part.
Here is the code.
Process_1 : process(RESET, CLK)
begin
if RESET = '1' then
State_A <= S0;
elsif CLK'event and CLK = '1' then
State_A <= State_NS;
end if;
end process;
Process_2 : process(...)
begin
case State_A is
when S0 =>
if C01 = '1' then
State_NS <= S1;
elsif C02 = '1' then
State_NS <= S2; -- missing a "else" part
-- a latch is generated
end if;
when S1 => -- the followings are normal coding
...;
when others =>
...;
end case;
end process
I ask how the state latch S0 is generated.
Here is latch logic equation:
Latch_S0_Data <= '1';
Latch_S0_E <=
Weng
Article: 145646On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi, > Sometimes, when an if statement misses a "else" statement part in a > two-process > method for a state machine, a latch-type state machine would be built. > > I always wondering how the state machine is built: using all latches > for the state machine > or using only one latch for the state which misses a "else" statement > part. A latch type state machine is not built; the latch is only inserted into the next state logic. A flip-flop still holds the current state. I know the following is not the point of your post, but your example implies that missing "else" statements generate latches. This is not true. Missing assignments generate latches. If a driven signal in a combinatorial process is not assigned a value in a given execution of the process, then the simulator has to remember what the last assignment was. The synthesis tool generates a latch to create that memory. Similarly for a variable in a combinatorial process, if the variable is read before it has been written in any given execution of that process, a latch is created to remember the last assignment. If I use a combinatorial process (extremely rarely in RTL), I make a default assignment to every signal & variable driven by the process, right up front, where it is always executed (and before any variables are read). In the case of the next state logic, it would simply be "state_ns <=3D state_a;". That way there is no need to code useless else statements everywhere (and all the assignments that must otherwise be included in them). AndyArticle: 145647
On Feb 17, 3:01=A0am, Brian Davis <brimda...@aol.com> wrote:
> I've noticed a more recent ncd -> bmm generation perl script
> in the OpenFire distribution that might be useful:
>
> http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download
>
> OpenFire_release/utils/openfire_bram.pl
I've recently ran into this problem, trying to avoid hard placement so
the tools are less constrained.
Brian Drummond has the right way to do it, I think -- I wish proper
documentation on how to make this happen in commandline existed. The
tools, as they do, do not tell you what's wrong on fail, so it's
mostly guesswork ("right incantations" indeed). The user guide Symon
points to doesn't deal with that type of usage directly. I ran into
trouble particularly when trying to make map accept multiple BRAM
definitions (when/if I iron all the kinks, I'll post a how-to).
Before seeing the above OpenFire script, I've also written a similar
script to do the same...
NCD -> XDL
Extract coordinates(s) of BRAMs by name from XDL
Use data2mem to insert BRAM data into bitstream
...but I consider it a hack.
saar.
Article: 145648On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote: > On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > Hi, > > Sometimes, when an if statement misses a "else" statement part in a > > two-process > > method for a state machine, a latch-type state machine would be built. > > > I always wondering how the state machine is built: using all latches > > for the state machine > > or using only one latch for the state which misses a "else" statement > > part. > > A latch type state machine is not built; the latch is only inserted > into the next state logic. A flip-flop still holds the current state. > > I know the following is not the point of your post, but your example > implies that missing "else" statements generate latches. > > This is not true. > > Missing assignments generate latches. If a driven signal in a > combinatorial process is not assigned a value in a given execution of > the process, then the simulator has to remember what the last > assignment was. The synthesis tool generates a latch to create that > memory. > > Similarly for a variable in a combinatorial process, if the variable > is read before it has been written in any given execution of that > process, a latch is created to remember the last assignment. > > If I use a combinatorial process (extremely rarely in RTL), I make a > default assignment to every signal & variable driven by the process, > right up front, where it is always executed (and before any variables > are read). In the case of the next state logic, it would simply be > "state_ns <=3D state_a;". That way there is no need to code useless else > statements everywhere (and all the assignments that must otherwise be > included in them). > > Andy Andy, Good point ! Now I ask how the next state latch is generated. WengArticle: 145649
VHDL doesn't allow explicitly 2-dimensional arrays as entity ports. Why? Because! You will have to define a 2-D type in a package, and use that instead. BTW, "library work;" is redundant. HTH! --------------------------------------- Posted through http://www.FPGARelated.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