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 Mar 29, 2:33 am, Randy Yates <ya...@ieee.org> wrote: > Michael S <already5cho...@yahoo.com> writes: > > On Mar 28, 9:27 pm, Symon <symon_bre...@hotmail.com> wrote: > >> On 3/28/2010 5:51 PM, Michael S wrote:> On Mar 28, 2:31 pm, Randy Yates<ya...@ieee.org> wrote: > >> >> I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator > >> >> that already has a high (baseband) sample rate - around 40-80 MHz. > > >> > That's a very bad idea. > >> > For your sort of application homemade delta-sigma DAC can't match > >> > combination of price, SNR, SFDR and power provided by something like > >> > AD9754. > > >> I'm pretty sure on price and power (I assume efficiency?) his solution > >> does match your suggested alternative given that, from details in his > >> previous postings on this newsgroup, the FPGA/CPLD device is a sunk > >> cost. I agree with your other acronyms though! > >> Cheers, Syms. > > > At what rate do you have to generate pulses to build, say 12-bit 80 > > MSPS? I don't know the exact answer but pretty sure that the required > > rate is way above capabilities of CPLDs and likely above what's > > possible with smallest FPGAs. > > You would need FPGA with the serializer implemented in hardware So, > > still on the digital side, you are pushed from something like $4 up to > > something like $30 or more. The difference already pays for several > > AD9754s both in money and in power consumption. Now, consider all the > > analog parts that you need to filter you pulse train into nice analog > > signal. Since, even with mid-range FPGA you will have relatively > > modest oversampling (factor of 15 or something like that) the analog > > filter will have to be rather sharp and probably high order. It would > > cost you more money and more power. > > > As I said above, implementing high speed DAC in programmable logic > > device is very bad idea. > > Implementing voice-grade (voice, not audio) DAC sounds less crazy but > > from point of view of economics, power and board real estate even that > > is more often than not a losing proposition. > > Michael, > > "Bad" is relative to your criteria. Hint: in my application, cost and > power are not important. Size is very important. The AD9754 is 700 mils > long, not a small part, and you'd need two of them. Not as small part in SOIC, but pretty small in TSSO packet. Anyway, AD9754 is just an example of the sort of external DAC we compare against. For practical IQ application you are likely to pick AD9116/ AD9117. And don't forget the analog components required by delta-sigma take space too. However if the power and cost is less important but the size is paramount, may be, direct conversion to IF with really fast DAC is a better idea? > > But I do agree it is not a good idea unless you really need it. > > By the way, I have designed a production-quality delta sigma D/A. It > went in over 17M Sony Ericsson phones. But it was implemented in > software on a TMS320C54x, not FPGA. You can see a presentation I > made on it at the first comp.dsp conference here: > > http://www.digitalsignallabs.com/presentation.pdf It's not clear from presentation but I suppose that you are talking about voice-grade DAC or may be something a little worse than the classic 100 to 3200 Hz voice grade that was considered acceptable in 10 y.o. wireless phones. Not much of relationship with bandwidth and phase linearity requirements of 20 Mbps QPSK transmitter. > -- > Randy Yates % "I met someone who looks alot like you, > Digital Signal Labs % she does the things you do, > mailto://ya...@ieee.org % but she is an IBM."http://www.digitalsignallabs.com% 'Yours Truly, 2095', *Time*, ELOArticle: 146801
Hello, Could someone please clarify if Webpack v11.4 is available for download. I am trying to download Webpack from the following link http://www.xilinx.com/tools/webpack.htm However it seems like v11.1 is the latest version available on Xilinx's wesite. Thanks in advance. Regards, Vikram. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146802
I need to start using ISE 11.4 instead of 10.1 Copy a full project using explorer and open with 10.1, all paths are relative and you have a "new project" Copy a full project with explorer and open with 11.4 and you need to upgrade the project. Start editing stuff and then discover that the project upgrade used absolute pathnames and I've been editing the original files. Hello XILINX this is the real world calling........... is anyone there?..........................Article: 146803
On Mar 28, 2:38=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/26/2010 9:13 PM, radarman wrote: > > > > > I've only done one other "high speed" design, with a Gig-E PHY, but I > > was able to get all of the signals to within +/- 5 mils on that board. > > When you did this, you took into account the different flight times in > the packages themselves, I hope! For sure the leadframes don't have > matched lengths on the signals from the die to the PCB pad. > > In summary, what the other guys said, 6 inches a ns! > > Cheers, Syms. No, because I wasn't aware that the internal wire bond lengths would be that dramatically different in a QFP. Those are big packages, and I had assumed that all of the wire bond points on the die would be around the periphery of the die. I've seen x-ray images of QFP's in the past, and the bond wires looked pretty much like you would expect - end launched from the die to an internal ring. Thus, I figured that it would be sufficient to make sure all the critical signals in a bundle were in the same bank, and on the same physical side. For that design, I used an EP3C16E144C7, and the GMII port fit nicely along one side in banks 7 and 8. If the pin pitch had been the same on both parts, it would have looked like a straight bus between the two chips.Article: 146804
>I need to start using ISE 11.4 instead of 10.1 > ------------------------- I just switched to 11.1 and thought I was up to date. I now see that 11.5 is available. Looks like its time to do another 2.5 Gig download John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146805
On 3/29/2010 3:56 PM, radarman wrote: > On Mar 28, 2:38 pm, Symon<symon_bre...@hotmail.com> wrote: >> On 3/26/2010 9:13 PM, radarman wrote: >> >> >> >>> I've only done one other "high speed" design, with a Gig-E PHY, but I >>> was able to get all of the signals to within +/- 5 mils on that board. >> >> When you did this, you took into account the different flight times in >> the packages themselves, I hope! For sure the leadframes don't have >> matched lengths on the signals from the die to the PCB pad. >> > > No, because I wasn't aware that the internal wire bond lengths would > be that dramatically different in a QFP. Those are big packages, and I > had assumed that all of the wire bond points on the die would be > around the periphery of the die. I've seen x-ray images of QFP's in > the past, and the bond wires looked pretty much like you would expect > - end launched from the die to an internal ring. > http://commons.wikimedia.org/wiki/File:TQFP_Leadframe.jpgArticle: 146806
On Mar 29, 7:14=A0am, "vragukumar" <vragukumar@n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > Could someone please clarify if Webpack v11.4 is available for download. = I > am trying to download Webpack from the following link > > http://www.xilinx.com/tools/webpack.htm > > However it seems like v11.1 is the latest version available on Xilinx's > wesite. > > Thanks in advance. > Regards, > Vikram. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com ISE 11.5 is a combination of ISE 11.1 + Updates, so the first step is to install ISE 11.1 and then to use the Xilinx Update tool upgrade to 11.5. I wish that this was easier, but unfortunately this is current installation flow for 11.x tools. Ed McGettigan -- Xilinx Inc.Article: 146807
I think it was a high level language feature first. Are you talking of indexed indirect addressing mode (reg+#immediate) or the link unlink instruction sets for setting the stack pointer? Would the 6502 8 bit micro (ZZ),Y mode count? Or are you more PDP-11?Article: 146808
On Mar 28, 2:42=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/28/2010 10:28 PM, John_H wrote: > > > > > > > On Mar 28, 3:38 pm, Symon<symon_bre...@hotmail.com> =A0wrote: > >> On 3/26/2010 9:13 PM, radarman wrote: > > >>> I've only done one other "high speed" design, with a Gig-E PHY, but I > >>> was able to get all of the signals to within +/- 5 mils on that board= . > > >> When you did this, you took into account the different flight times in > >> the packages themselves, I hope! For sure the leadframes don't have > >> matched lengths on the signals from the die to the PCB pad. > > >> In summary, what the other guys said, 6 inches a ns! > > >> Cheers, Syms. > > > The flight times in the package shouldn't hit the timing budget at > > all. =A0The timing for both the SRAM and FPGA will be worst case for an= y > > pin. =A0And what's a few 10s of picoseconds? > > Well, I agree, but did you read his post? He's making trace lengths > match to within 5 mils! That's what I'm trying to suggest may be a waste > of effort. > > Cheers, Syms. > > p.s. FWIW, you can get the flight times of BGA packages from Xilinx, if > you ask nicely.- Hide quoted text - > > - Show quoted text - You don't need to ask Xilinx for this information for the flipchip packages because it is available from the ISE partgen tool. Example: partgen -v xc6slx240tff1156 This command will generate a PKG file that includes the tracelength in um (microns). Where 1000 microns =3D 1.0 mm. Multiplying the trace length by 6.0-7.1ps/mm will give the flight time within the package. Ed McGettigan -- Xilinx Inc.Article: 146809
On Mar 29, 10:38=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 28, 2:42=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > > > On 3/28/2010 10:28 PM, John_H wrote: > > > > On Mar 28, 3:38 pm, Symon<symon_bre...@hotmail.com> =A0wrote: > > >> On 3/26/2010 9:13 PM, radarman wrote: > > > >>> I've only done one other "high speed" design, with a Gig-E PHY, but= I > > >>> was able to get all of the signals to within +/- 5 mils on that boa= rd. > > > >> When you did this, you took into account the different flight times = in > > >> the packages themselves, I hope! For sure the leadframes don't have > > >> matched lengths on the signals from the die to the PCB pad. > > > >> In summary, what the other guys said, 6 inches a ns! > > > >> Cheers, Syms. > > > > The flight times in the package shouldn't hit the timing budget at > > > all. =A0The timing for both the SRAM and FPGA will be worst case for = any > > > pin. =A0And what's a few 10s of picoseconds? > > > Well, I agree, but did you read his post? He's making trace lengths > > match to within 5 mils! That's what I'm trying to suggest may be a wast= e > > of effort. > > > Cheers, Syms. > > > p.s. FWIW, you can get the flight times of BGA packages from Xilinx, if > > you ask nicely.- Hide quoted text - > > > - Show quoted text - > > You don't need to ask Xilinx for this information for the flipchip > packages because it is available from the ISE partgen tool. > > Example: partgen -v xc6slx240tff1156 > > This command will generate a PKG file that includes the tracelength in > um (microns). Where 1000 microns =3D 1.0 mm. =A0Multiplying the trace > length by 6.0-7.1ps/mm will give the flight time within the package. > > Ed McGettigan > -- > Xilinx Inc. Altera has a page with the relevant data as well: http://www.altera.com/technology/signal/board-design-guidelines/sgl-bdg-ind= ex.html Apparently I was wrong, there is a small, but significant, difference between pins even on the same physical side of the chip. I also failed to notice that Vref pins used as I/O affect timing. However, the whole point of this exercise was to learn, and I'm doing plenty of that. Perhaps it's time to throw together a spreadsheet with all the timing figure in it, and do a proper budget.Article: 146810
On Mar 29, 7:30=A0am, colin <colin_toog...@yahoo.com> wrote: > I need to start using ISE 11.4 instead of 10.1 That's one scary statement. I have found a couple of modules that "just don't" synthesize properly with version 11. No error message(s), no warning(s), just a dead FPGA. I think that phone is disconnected. RKArticle: 146811
On Mar 29, 4:37=A0am, Matthieu Michon <prenom....@gmail.com> wrote: > On Sun, 28 Mar 2010 21:29:31 -0400 > > Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > > (...) > > > > > I should have mentioned that I have tried all the iterations of keep > > that I could think of, the gates are still being optimized out. I tried > > both placing the keep attribute in the code, and using the xcf file, > > neither have worked. I think part of the problem is I don't know hte > > exact name of the nets being optimized out, since XST doesn't tell me > > this information in the reports. > > Altough it is not universal, I use the "S" (save net flag) attribute for = keeping signals from being optimized (typically for displaying them in Chip= scope). > > The "S" attribute is described in the Constraint Guide (cgd.pdf). > > -- > Matthieu Michon <prenom....@gmail.com> I'm having problems with my main machine, so I'm posting this from google groups, I'm the OP. I have some gates defined in a verilog file like this: AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); INVX1 gate2 (.A(net3) , .B(net4)); etc.. The entities, AND2X1 and INVX1 are defined in a library, so they synthesize just fine. The final gate I have: OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); This gate, gate15 shows up in manual place and route, but the others connected to it do not. Why is that? I'll look into the 'S' flag, thanks.Article: 146812
Hello, I want to tell XST that uses block RAM for my FIFO, but I couldn't till now. can you please take a look at my code and tell me what should I do ? http://openpaste.org/en/20191/ thanksArticle: 146813
On Mon, 29 Mar 2010 09:40:40 -0700 (PDT), Jason Thibodeau <jbloudg20@gmail.com> wrote: >On Mar 29, 4:37 am, Matthieu Michon <prenom....@gmail.com> wrote: >> On Sun, 28 Mar 2010 21:29:31 -0400 >> >> Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: >> >> (...) >> >> >> >> > I should have mentioned that I have tried all the iterations of keep >> > that I could think of, the gates are still being optimized out. I tried >> > both placing the keep attribute in the code, and using the xcf file, >> > neither have worked. I think part of the problem is I don't know hte >> > exact name of the nets being optimized out, since XST doesn't tell me >> > this information in the reports. >> >> Altough it is not universal, I use the "S" (save net flag) attribute for keeping signals from being optimized (typically for displaying them in Chipscope). >> >> The "S" attribute is described in the Constraint Guide (cgd.pdf). >> >> -- >> Matthieu Michon <prenom....@gmail.com> > >I'm having problems with my main machine, so I'm posting this from >google groups, I'm the OP. > >I have some gates defined in a verilog file like this: > >AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); >INVX1 gate2 (.A(net3) , .B(net4)); > >etc.. > >The entities, AND2X1 and INVX1 are defined in a library, so they >synthesize just fine. > >The final gate I have: >OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); > >This gate, gate15 shows up in manual place and route, but the others >connected to it do not. Why is that? > >I'll look into the 'S' flag, thanks. My first take would be to simulate the design. If it does what you need in simulation, then you might investigate if your design is minimal in its specification. The synthesis is pretty accurate in what it thinks the unnecessary parts of logic are so I'd check the design very carefully before trying to keep gates which are really not necessary for logic (as you seem to be mentioning mostly logic and not buffers, inverters which might look unnecessaary but might be needed.) -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146814
On 03/29/2010 01:03 PM, Muzaffer Kal wrote: > On Mon, 29 Mar 2010 09:40:40 -0700 (PDT), Jason Thibodeau > <jbloudg20@gmail.com> wrote: > >> On Mar 29, 4:37 am, Matthieu Michon<prenom....@gmail.com> wrote: >>> On Sun, 28 Mar 2010 21:29:31 -0400 >>> >>> Jason Thibodeau<jason.p.thibod...@gmail.com> wrote: >>> >>> (...) >>> >>> >>> >>>> I should have mentioned that I have tried all the iterations of keep >>>> that I could think of, the gates are still being optimized out. I tried >>>> both placing the keep attribute in the code, and using the xcf file, >>>> neither have worked. I think part of the problem is I don't know hte >>>> exact name of the nets being optimized out, since XST doesn't tell me >>>> this information in the reports. >>> >>> Altough it is not universal, I use the "S" (save net flag) attribute for keeping signals from being optimized (typically for displaying them in Chipscope). >>> >>> The "S" attribute is described in the Constraint Guide (cgd.pdf). >>> >>> -- >>> Matthieu Michon<prenom....@gmail.com> >> >> I'm having problems with my main machine, so I'm posting this from >> google groups, I'm the OP. >> >> I have some gates defined in a verilog file like this: >> >> AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); >> INVX1 gate2 (.A(net3) , .B(net4)); >> >> etc.. >> >> The entities, AND2X1 and INVX1 are defined in a library, so they >> synthesize just fine. >> >> The final gate I have: >> OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); >> >> This gate, gate15 shows up in manual place and route, but the others >> connected to it do not. Why is that? >> >> I'll look into the 'S' flag, thanks. > > My first take would be to simulate the design. If it does what you > need in simulation, then you might investigate if your design is > minimal in its specification. The synthesis is pretty accurate in what > it thinks the unnecessary parts of logic are so I'd check the design > very carefully before trying to keep gates which are really not > necessary for logic (as you seem to be mentioning mostly logic and not > buffers, inverters which might look unnecessaary but might be needed.) I know the design intimately, and I know for a fact the gates it is optimizing out are necessary for proper operation. I'm trying to figure out WHY this is happening. FWIW, this is not just a problem with Xilinx's optimization. Synopsys does the same thing during synthesis, but I can tell it to not optimize. The branches it is optimizing have a VERY (<.000001%) low probability of activation, but I need the gates to remain, anyway. -- Jason ThibodeauArticle: 146815
On 3/29/2010 5:09 PM, radarman wrote: > > Apparently I was wrong, there is a small, but significant, difference > between pins even on the same physical side of the chip. I also failed > to notice that Vref pins used as I/O affect timing. > Well, kinda. I would say that there is a small and (almost always) negligible difference between the pins' flight time. The fact that only Xilinx Ed pointed out where to find the flight times indicates that very few posters on CAF have ever worried about them. Similarly, small differences on the PCB are also insignificant, and trying to eliminate them is an unnecessary task. FWIW, with QFPs you will never have to worry about these data, as the packages are rubbish for high-speed signals. > However, the whole point of this exercise was to learn, and I'm doing > plenty of that. Perhaps it's time to throw together a spreadsheet with > all the timing figure in it, and do a proper budget. Right, you'll get no disagreement from me on that one. From that, you will be able to judge how much length matching effort you need to do on your PCB. Cheers, Syms.Article: 146816
Hi Michael, Your points are well-taken. Thank you very much for your input and information. --Randy Michael S <already5chosen@yahoo.com> writes: > On Mar 29, 2:33 am, Randy Yates <ya...@ieee.org> wrote: >> Michael S <already5cho...@yahoo.com> writes: >> > On Mar 28, 9:27 pm, Symon <symon_bre...@hotmail.com> wrote: >> >> On 3/28/2010 5:51 PM, Michael S wrote:> On Mar 28, 2:31 pm, Randy Yates<ya...@ieee.org> wrote: >> >> >> I'm thinking of implementing a delta-sigma D/A for the SOQPSK modulator >> >> >> that already has a high (baseband) sample rate - around 40-80 MHz. >> >> >> > That's a very bad idea. >> >> > For your sort of application homemade delta-sigma DAC can't match >> >> > combination of price, SNR, SFDR and power provided by something like >> >> > AD9754. >> >> >> I'm pretty sure on price and power (I assume efficiency?) his solution >> >> does match your suggested alternative given that, from details in his >> >> previous postings on this newsgroup, the FPGA/CPLD device is a sunk >> >> cost. I agree with your other acronyms though! >> >> Cheers, Syms. >> >> > At what rate do you have to generate pulses to build, say 12-bit 80 >> > MSPS? I don't know the exact answer but pretty sure that the required >> > rate is way above capabilities of CPLDs and likely above what's >> > possible with smallest FPGAs. >> > You would need FPGA with the serializer implemented in hardware So, >> > still on the digital side, you are pushed from something like $4 up to >> > something like $30 or more. The difference already pays for several >> > AD9754s both in money and in power consumption. Now, consider all the >> > analog parts that you need to filter you pulse train into nice analog >> > signal. Since, even with mid-range FPGA you will have relatively >> > modest oversampling (factor of 15 or something like that) the analog >> > filter will have to be rather sharp and probably high order. It would >> > cost you more money and more power. >> >> > As I said above, implementing high speed DAC in programmable logic >> > device is very bad idea. >> > Implementing voice-grade (voice, not audio) DAC sounds less crazy but >> > from point of view of economics, power and board real estate even that >> > is more often than not a losing proposition. >> >> Michael, >> >> "Bad" is relative to your criteria. Hint: in my application, cost and >> power are not important. Size is very important. The AD9754 is 700 mils >> long, not a small part, and you'd need two of them. > > Not as small part in SOIC, but pretty small in TSSO packet. Anyway, > AD9754 is just an example of the sort of external DAC we compare > against. For practical IQ application you are likely to pick AD9116/ > AD9117. And don't forget the analog components required by delta-sigma > take space too. > However if the power and cost is less important but the size is > paramount, may be, direct conversion to IF with really fast DAC is a > better idea? > >> >> But I do agree it is not a good idea unless you really need it. >> >> By the way, I have designed a production-quality delta sigma D/A. It >> went in over 17M Sony Ericsson phones. But it was implemented in >> software on a TMS320C54x, not FPGA. You can see a presentation I >> made on it at the first comp.dsp conference here: >> >> http://www.digitalsignallabs.com/presentation.pdf > > It's not clear from presentation but I suppose that you are talking > about voice-grade DAC or may be something a little worse than the > classic 100 to 3200 Hz voice grade that was considered acceptable in > 10 y.o. wireless phones. > Not much of relationship with bandwidth and phase linearity > requirements of 20 Mbps QPSK transmitter. > >> -- >> Randy Yates % "I met someone who looks alot like you, >> Digital Signal Labs % she does the things you do, >> mailto://ya...@ieee.org % but she is an IBM."http://www.digitalsignallabs.com% 'Yours Truly, 2095', *Time*, ELO > -- Randy Yates % "The dreamer, the unwoken fool - Digital Signal Labs % in dreams, no pain will kiss the brow..." mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Eldorado Overture', *Eldorado*, ELOArticle: 146817
On Mar 29, 10:15=A0am, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > On 03/29/2010 01:03 PM, Muzaffer Kal wrote: > > > > > > > On Mon, 29 Mar 2010 09:40:40 -0700 (PDT), Jason Thibodeau > > <jbloud...@gmail.com> =A0wrote: > > >> On Mar 29, 4:37 am, Matthieu Michon<prenom....@gmail.com> =A0wrote: > >>> On Sun, 28 Mar 2010 21:29:31 -0400 > > >>> Jason Thibodeau<jason.p.thibod...@gmail.com> =A0wrote: > > >>> (...) > > >>>> I should have mentioned that I have tried all the iterations of keep > >>>> that I could think of, the gates are still being optimized out. I tr= ied > >>>> both placing the keep attribute in the code, and using the xcf file, > >>>> neither have worked. I think part of the problem is I don't know hte > >>>> exact name of the nets being optimized out, since XST doesn't tell m= e > >>>> this information in the reports. > > >>> Altough it is not universal, I use the "S" (save net flag) attribute = for keeping signals from being optimized (typically for displaying them in = Chipscope). > > >>> The "S" attribute is described in the Constraint Guide (cgd.pdf). > > >>> -- > >>> Matthieu Michon<prenom....@gmail.com> > > >> I'm having problems with my main machine, so I'm posting this from > >> google groups, I'm the OP. > > >> I have some gates defined in a verilog file like this: > > >> AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); > >> INVX1 gate2 (.A(net3) , .B(net4)); > > >> etc.. > > >> The entities, AND2X1 and INVX1 are defined in a library, so they > >> synthesize just fine. > > >> The final gate I have: > >> OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); > > >> This gate, gate15 shows up in manual place and route, but the others > >> connected to it do not. Why is that? > > >> I'll look into the 'S' flag, thanks. > > > My first take would be to simulate the design. If it does what you > > need in simulation, then you might investigate if your design is > > minimal in its specification. The synthesis is pretty accurate in what > > it thinks the unnecessary parts of logic are so I'd check the design > > very carefully before trying to keep gates which are really not > > necessary for logic (as you seem to be mentioning mostly logic and not > > buffers, inverters which might look unnecessaary but might be needed.) > > I know the design intimately, and I know for a fact the gates it is > optimizing out are necessary for proper operation. I'm trying to figure > out WHY this is happening. > > FWIW, this is not just a problem with Xilinx's optimization. Synopsys > does the same thing during synthesis, but I can tell it to not optimize. > The branches it is optimizing have a VERY (<.000001%) low probability of > activation, but I need the gates to remain, anyway. > > -- > Jason Thibodeau- Hide quoted text - > > - Show quoted text - The raison d'=EAtre of HDL synthesizers is to produce an optimized design that matches the HDL input code. If the tools didn't do this then they no one would use or buy them. If the gate/net was optimized away then it wasn't needed. Either the input (registers and IO pads) equation cone had redundancies or there was a redundancy to the final output (registers or IO pads). The synthesizer will also move the equations around to optimize timing. A signal that you have coded to appear early in an multi-level logic cone may be pushed to later in the logic cone to improve the timing. If the synthesizer changed the logic then it would be a bug. Since you have said that this happens in two different tools it is very unlikely to be a bug. I think that you mentioned that you had OR'ed all of the outputs together to keep all of the logic from being trimmed. I would suggest instead that you register all of the outputs and then OR the registers outputs to keep the logic. Optimizing across the register boundaries is available in some synthesizers, but there is usually an option to enable/disable the feature. Ed McGettigan -- Xilinx Inc.Article: 146818
On Fri, 26 Mar 2010 12:00:31 -0400 Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote: > On 03/25/2010 11:24 PM, David Wiltshire wrote: > > On Mar 26, 6:06 am, Jason Thibodeau<jason.p.thibod...@gmail.com> > > wrote: > >> Is it possible to get a detailed report out of XST, listing the > >> gates it has optimized out of a design? XST is removing some gates > >> that I specifically put into a design, and I want to prevent this. > >> I can use the XST constraints file, but I'd like to see exactly > >> what it is doing. > >> > >> Googling hasn't turned up much, yet. > >> > >> Thanks > >> -- > >> Jason Thibodeau > > > > Not that I'm experienced but whenever I've seen a similar question > > (missing logic) it's been optomised out because you haven't > > connected the output to anything. Try connecting it to a pin out > > (even if that's not where you want it eventually) and see if it > > turns up. > > > > Dave > > Yes, I ran across that and I connected the output. Only the last gate > in the design is being synthesized. All the other gates, which > connect to it, are being optimized out. > This may be a silly question, but exactly what does the logic that's being optimized out do? -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146819
On 03/29/2010 02:38 PM, Ed McGettigan wrote: > On Mar 29, 10:15 am, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> On 03/29/2010 01:03 PM, Muzaffer Kal wrote: >> >> >> >> >> >>> On Mon, 29 Mar 2010 09:40:40 -0700 (PDT), Jason Thibodeau >>> <jbloud...@gmail.com> wrote: >> >>>> On Mar 29, 4:37 am, Matthieu Michon<prenom....@gmail.com> wrote: >>>>> On Sun, 28 Mar 2010 21:29:31 -0400 >> >>>>> Jason Thibodeau<jason.p.thibod...@gmail.com> wrote: >> >>>>> (...) >> >>>>>> I should have mentioned that I have tried all the iterations of keep >>>>>> that I could think of, the gates are still being optimized out. I tried >>>>>> both placing the keep attribute in the code, and using the xcf file, >>>>>> neither have worked. I think part of the problem is I don't know hte >>>>>> exact name of the nets being optimized out, since XST doesn't tell me >>>>>> this information in the reports. >> >>>>> Altough it is not universal, I use the "S" (save net flag) attribute for keeping signals from being optimized (typically for displaying them in Chipscope). >> >>>>> The "S" attribute is described in the Constraint Guide (cgd.pdf). >> >>>>> -- >>>>> Matthieu Michon<prenom....@gmail.com> >> >>>> I'm having problems with my main machine, so I'm posting this from >>>> google groups, I'm the OP. >> >>>> I have some gates defined in a verilog file like this: >> >>>> AND2X1 Gate1 (.A(net1) , .B(net2), .Y(net3)); >>>> INVX1 gate2 (.A(net3) , .B(net4)); >> >>>> etc.. >> >>>> The entities, AND2X1 and INVX1 are defined in a library, so they >>>> synthesize just fine. >> >>>> The final gate I have: >>>> OR2X1 gate15 (.A(bla bla), .B(...), .Y(...)); >> >>>> This gate, gate15 shows up in manual place and route, but the others >>>> connected to it do not. Why is that? >> >>>> I'll look into the 'S' flag, thanks. >> >>> My first take would be to simulate the design. If it does what you >>> need in simulation, then you might investigate if your design is >>> minimal in its specification. The synthesis is pretty accurate in what >>> it thinks the unnecessary parts of logic are so I'd check the design >>> very carefully before trying to keep gates which are really not >>> necessary for logic (as you seem to be mentioning mostly logic and not >>> buffers, inverters which might look unnecessaary but might be needed.) >> >> I know the design intimately, and I know for a fact the gates it is >> optimizing out are necessary for proper operation. I'm trying to figure >> out WHY this is happening. >> >> FWIW, this is not just a problem with Xilinx's optimization. Synopsys >> does the same thing during synthesis, but I can tell it to not optimize. >> The branches it is optimizing have a VERY (<.000001%) low probability of >> activation, but I need the gates to remain, anyway. >> >> -- >> Jason Thibodeau- Hide quoted text - >> >> - Show quoted text - > > The raison d'être of HDL synthesizers is to produce an optimized > design that matches the HDL input code. If the tools didn't do this > then they no one would use or buy them. > > If the gate/net was optimized away then it wasn't needed. Either the > input (registers and IO pads) equation cone had redundancies or there > was a redundancy to the final output (registers or IO pads). The > synthesizer will also move the equations around to optimize timing. A > signal that you have coded to appear early in an multi-level logic > cone may be pushed to later in the logic cone to improve the timing. > > If the synthesizer changed the logic then it would be a bug. Since > you have said that this happens in two different tools it is very > unlikely to be a bug. > > I think that you mentioned that you had OR'ed all of the outputs > together to keep all of the logic from being trimmed. I would suggest > instead that you register all of the outputs and then OR the registers > outputs to keep the logic. Optimizing across the register boundaries > is available in some synthesizers, but there is usually an option to > enable/disable the feature. > > Ed McGettigan > -- > Xilinx Inc. > The logic that is being optimized out is a simple comparator. And gates in roughly a tree structure, with a final or gate to feed it back into the 'main' circuit. The or gate was not implemented to keep the tool from trimming the logic, rather it was necessary for proper function of the circuit. What I'm working on, I need to be able to place these gates into specific portions of the chip. This is why I cannot have them optimized or absorbed into other CLB's. I'm really just trying to figure out if it is possible to place an attribute before an instantiation so it will not be trimmed. I realize what I want may not be a standard request, but I just want to make it work. Thanks for all your help, everyone. -- Jason ThibodeauArticle: 146820
Hi, Altera's Quartus II does not include a free simulator. Is there a free VHDL or Verilog simulator that is reasonalbly good? Google shows a few but I would prefer a recommendation. Thanks, GaryArticle: 146821
Hello, I'm trying to figure out how much delay variance I can achieve using the variable phase shifter on a Spartan 3E device. I may change the input frequency if that helps me, and use the CLKFX output as target clock, so basically I need to figure out how to choose CLKIN wisely to get an adequate phase shift. The datasheet and user guide seem to agree on If CLKIN < 60 MHz: MAX_STEPS =3D =C2=B1[INTEGER(10 =E2=80=A2(TCLKIN =E2=80= =93 3))] If CLKIN > 60 MHz: MAX_STEPS =3D =C2=B1[INTEGER(15 =E2=80=A2(TCLKIN =E2=80= =93 3))] which is a pretty weird relationship, if I may say so. I can't see why the clock's frequency would matter at all, since the delay line steps don't depend on the frequency. The fact that this equation is discontinuous at 60 MHz doesn't make it look better. What looks even more weird is that since the minimal input frequency is 5 MHz, we get MAX_STEPS of =C2=B1(10 =E2=80=A2(200 =E2=80=93 3)) which is =C2=B11970 step= s, or with a 20ps step size, =C2=B139.4 ns of delay! That is four times longer than the delay line dedicated for a fixed phase shifting. Or eight times? I'm lost. But I'm in good company, it seems. Reading the XAPP 485's attached sample code, auto_phase_align_s3s.v header comment says "Note counters are long enough (13-bit) for operation down to 5 MHz assuming 25 pS per tap. (200,000/25=3D8000)". Looks like someone thought that the FPGA has a 200 ns delay line. It's getting even more impressive. The ug331 Spartan 3E user guide offers a hint: Table 3-32 says what happens in different situations. Among others, there's this situation labeled "=E2=89=A5 +Limit and < +255" which is commented as "end of delay line". So maybe this sums up to that effectively MAX_STEPS could never exceed =C2=B1255 steps? That would guarantee a minimal delay swing of =C2=B15.12 n= s (if each delay tap is 20ps) which sounds pretty familiar (the maximal delay of other Xilinx FPGAs is 5ns, I believe). But sensible as this sounds to me, I've not been able to find a conclusive statement about this. Can anyone shed some light on this? Thanks in advance, BillArticle: 146822
On Mar 29, 3:42=C2=A0pm, Bill Valores <bill.valo...@gmail.com> wrote: > Hello, > > I'm trying to figure out how much delay variance I can achieve using > the variable phase shifter on a Spartan 3E device. I may change the > input frequency if that helps me, and use the CLKFX output as target > clock, so basically I need to figure out how to choose CLKIN wisely to > get an adequate phase shift. > > The datasheet and user guide seem to agree on > > If CLKIN < 60 MHz: MAX_STEPS =3D =C2=B1[INTEGER(10 =E2=80=A2(TCLKIN =E2= =80=93 3))] > If CLKIN > 60 MHz: MAX_STEPS =3D =C2=B1[INTEGER(15 =E2=80=A2(TCLKIN =E2= =80=93 3))] > > which is a pretty weird relationship, if I may say so. I can't see why > the clock's frequency would matter at all, since the delay line steps > don't depend on the frequency. The fact that this equation is > discontinuous at 60 MHz doesn't make it look better. What looks even > more weird is that since the minimal input frequency is 5 MHz, we get > MAX_STEPS of =C2=B1(10 =E2=80=A2(200 =E2=80=93 3)) which is =C2=B11970 st= eps, or with a 20ps > step size, =C2=B139.4 ns of delay! That is four times longer than the del= ay > line dedicated for a fixed phase shifting. Or eight times? I'm lost. > > But I'm in good company, it seems. Reading the XAPP 485's attached > sample code, auto_phase_align_s3s.v header comment says "Note counters > are long enough (13-bit) for operation down to 5 MHz assuming 25 pS > per tap. (200,000/25=3D8000)". Looks like someone thought that the FPGA > has a 200 ns delay line. It's getting even more impressive. > > The ug331 Spartan 3E user guide offers a hint: Table 3-32 says what > happens in different situations. Among others, there's this situation > labeled "=E2=89=A5 +Limit and < +255" which is commented as "end of delay > line". > > So maybe this sums up to that effectively MAX_STEPS could never exceed > =C2=B1255 steps? That would guarantee a minimal delay swing of =C2=B15.12= ns (if > each delay tap is 20ps) which sounds pretty familiar (the maximal > delay of other Xilinx FPGAs is 5ns, I believe). But sensible as this > sounds to me, I've not been able to find a conclusive statement about > this. > > Can anyone shed some light on this? > > Thanks in advance, > Bill About a year ago, I had to do some fairly fine-grained phase-shifting to poke at a hardware problem on a chip we build. I used a Nexys2 board (S3E), used Xilinx's equation, and on an 8.192 MHz clock (which their equation says ought to be able to go +/- 1190 steps, if I read it right, I just did the "nearest power of two" thing and went +/- 1024 steps. IIRC, the actual step size I measured in the lab was around 25 ps, and it seemed to be not only monotonic, but also to have very little variance in the steps. I had an external PLL creating a 98 MHz clock from the 8.192 MHz by multiplying by 12, and I could cycle through several periods of the 98 MHz clock with no problem. My test jig worked flawlessly with no discontinuities. I have no idea what they do or how they do it, but I have no complaints about that portion of the datasheet. No, pretty much all my Xilinx complaints have to do with software rather than hardware, but you don't have enough time for that... Regards, PatArticle: 146823
On Mar 29, 3:22=A0pm, "Abby Brown" <abbybr...@charter.net> wrote: > Hi, > > Altera's Quartus II does not include a free simulator. =A0Is there > a free VHDL or Verilog simulator that is reasonalbly good? > Google shows a few but I would prefer a recommendation. > > Thanks, > Gary Icarus is great. Also, if you have heavy-duty sims that take a lot of time, and don't mind doing a little test jig coding in C or C++, verilator is great and fast (but it is only a 2 state simulator, not a 4 state simulator). Regards, PatArticle: 146824
On Mar 29, 2:36=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > What I'm working on, I need to be able to place these gates into > specific portions of the chip. This is why I cannot have them optimized > or absorbed into other CLB's. I have no idea why you would want to do this, but I would build the design as discrete units. At the top, you can stitch them together using xilinx's "black box" stuff, and then the synthesizer won't be smart enough to optimize things out. Also, doing it this way makes it easy to constrain placement. HOWEVER, the map has gotten a lot smarter lately, so you'll probably need to set some options on that to keep it from resynthesizing the chip when it sees the full picture. Regards, Pat
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