Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, > To do this, just add your executable.elf file to the ISE project as a > source. When you do, ISE will ask you how you want the file assigned, > you should choose the top level file (top_level I believe you called > it). This will initialize the Block RAM in the .ncd file and therefore > will be in the simulation model for the post-par simulation. I've tried this several times but it doesn't work. I don't know still why. What I do is to configurate the CPU in XMDSTUB mode so that XMD can work, but I it fails when connecting. Any ideas? Regards, Arkaitz.Article: 65276
Hi, I have compiled with Quartus II 3.0 SP2s a project that fills a Cyclone C12 for 89%. Quartus ends the work later around 2.30 hours (Pentium 4 - 2.8Ghz). If I try to compile the same project on a PC with processor Intel Pentium 4 with Hypertheading technology, Quartus doesn't succeed in ending the fitting, after 24 hours it is I still stop to the 80%. In the same PC I succeed in quickly compiling less binding projects for the fitting. Is there someone other of you that has had the same problem? Does a way exist for resolving this? I have tried to disable from the PC BIOS, the Hypertheading, also this doesn't resolve the problem . SalvoArticle: 65277
Wow, a real flame war at comp.arch.fpga. Rudi: I guess from your asic design experience you can guess, why the timing for routing is not well defined before the routing is done. But mostly I am posting as a response to Peter: Success of a product does not actually contradict overly optimistic marketing claims. At least short time success should be able to be improved by marketing lies, don't you think? You should not be offended personally. You now that the information from you and austin is always better and more detailed and often very different from what's in datsheets let alone the press releases. So if a lot of people dislike the press releases, this does not mean, they do not respect you. And many of them use Xilinx, so they do not think to bad of the product either. But there is reason not to like Xilinx marketing. Remember the press release that claimed prices that are valid NOW but not before Q4/2004? I do not use "now" that way. Or Insight who send me spam that told me I could get XC3S200 in volume now but at the phone told me I could not even get samples? The problem for us engineers is, that our customers read the press releases. And we always look like idiots when we have to explain them, that we can not do that what Xilinx suggests. Or not yet. Or only at 20x the price. Or only if they buy a million parts. Regards, Kolja Peter Alfke <peter@xilinx.com> wrote in message news:<401011AA.9D090355@xilinx.com>... > Strong words, Rudi ! > But unless you can substantiate your claims, we will ignore them as your > kind of BS. > I am an engineer, and I do not make marketing claims, and neither do I > publish 80% nonsense and 15% lies. > For some reason the world is rapidly converting to FPGA. Last year there > were less than 1500 new ASIC designs and probably 100 000 new designs > using FPGAs. Many of us in this ng are aware of the ASIC advantages, but > they come with a hefty price tag, long manufacturing time, risk and > inflexibility. That's why most of us prefer FPGAs. It is also reflected > in the name of this ng. > > So, Rudi, if you want to post here, say something meaningful, and do not > just blurt out unsubstantiated insults. Hurts your reputation more than mine... > > Peter Alfke, > ============================================ > Rudolf Usselmann wrote: > > > > This BS marketing from FPGA companies is 80% nonsenseand > > 5% Truth. The remaining 15% are pure lies. > > > > Regards, > > rudi > > ======================================================== > > ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: > > ..............::: FPGAs * Full Custom ICs * IP Cores ::: > > FREE IP Cores -> http://www.asics.ws/ <- FREE EDA ToolsArticle: 65278
As much as i know ATT never made their own software for Xilinx compatible chips. Why? Do they considered it too costly or got only rights to deal with silicon, not the soft? It seems to me that in this case software problems were reasons why ATT droped this product line. As soon as Xilinx ceased to support 3000 series, ATT chips also became useless. Interesting to know what happened first: ATT deciding that 3000 is too oldfashioned to make profit of it or Xilinx droping non-A series support and so making ATT chips useless? Raivo Peter Alfke <peter@xilinx.com> wrote in message news:<40108AB0.D7471363@xilinx.com>... > Xilinx selected ATT as a legitimate second source for XC3000 ( such > things seemed to be important in those days), with the hope of speeding > up the XC4000 project. > When this did not work out and relationships soured, ATT came out with > ORCA in competition with XC4000. All this later ended up with Lattice. > > Another lesson: > FPGAs do not transplant well from one manufacturer to the other > ( see Altera-to-Cypress, Actel-to-T.I., Xilinx-to-MMI, before it got > swallowed by AMD, Xilinx-to-ATT. The judgement is still out on > AMD-to-Lattice, and ATT-to-Lattice ) > > Lots of blood on the battlefield.. > And fast progress and happy customers ! > > Peter Alfke. > ================== > Raivo Nael wrote: > > > > There is one untypical case in the history of FPGAs that no one > > mentioned so far. ATT sold aproximately ten years ago Xilinx > > compatible chips! Theyr datasheet said that these are pin-to-pin > > replacements. Those were marked with ATT prefix and were clones of > > XC3000 series chips. Afterwards Lucent Technologyes made also those > > chips. Does anyone know more about the story? > > > > I have also heard that NEC was one of those who tryed to make FPGAs... > > > > RaivoArticle: 65279
Austin Lesea <austin@xilinx.com> wrote: : Lest anyone spread rumors, : Spirit used a 4K QPRO part for the squibs that fired for the parachute, : the inflatable bag, etc for the Lander. The Moessbauer Spectrometer has a Quicklogic QL30XX... If I remember right, the APX has an Altera ... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 65280
On Tue, 20 Jan 2004 08:52:20 GMT, "Jean Nicolle"
<j.nicolle@sbcglobal.net> wrote:
>Thanks for the *detailed* answer.
>I used 3.3V IOs, so I need an 1:1.3 transformer to meet both amplitude and
>return loss.
>I guess that if I want to use common 1:1 transformers, I need 5V IOs and
>50ohms resistors.
Yes, that would also give a good output level and return loss. The
FPGA pin current would be 25mA, which would probably be possible
without needing to double-up output drivers.
There is a direct tradeoff between current and voltage at the FPGA
pins which is determined by the transformer ratio.
(ASIC) PHYs often drive into a centre tapped transformer. The centre
tap is connected to VCC (or sometimes GND). The outputs only pull
down (one at a time), and the transformer action makes the voltage at
the other output rise above the supply rail. This allows more voltage
swing from a given supply voltage, but can't be done in an FPGA due to
restrictions in the voltages that can be applied to output pins. (Or
can it? You might get lucky with some 5V compliant parts running from
lower voltages.)
>For the equalization and harmonic requirements, couldn't I use a filter?
>27dB is pretty sharp though, doesn't seem easy.
It's not easy. You'd also need a buffer amp after the filter,
otherwise the line impedance will affect the filter response and it
will also be difficult to get a good (wideband) return loss.
>Looking at some PHY/transformer schematics doesn't show any filter. Is it
>usually provided inside the PHY?
The (FIR) filter is implemented digitally inside the PHY.
You can also think of this as "pulse shaping" rather than filtering.
This sort of thing just isn't feasible inside an FPGA, unless you use
some sort of DAC on the output. ("Some sort of DAC" could be as
simple as a small number of resistors though.)
This sci.electronics.design thread:
http://groups.google.com/groups?threadm=fntrju0uphuno94gbe0qeue5859v3t5b38%404ax.com
discusses the design of a pulse shaping filter for an ASIC. The
designer ended up with a combination of an FIR filter (implemented
with a weighted resistor network) inside the ASIC and a single pole LP
filter outside the ASIC to achieve the required pulse shape (and hence
frequency response).
Regards,
Allan.
Article: 65281Hi everyone!!! I'm actually doing my thesis wich consists in implementing an algorithm in a FPGA. I've done the desing and works right in all the simulations except in Post Place and Route simulation. In fact, the results are right but betwen every 2 data appears valid data that shouldn't appear. What should I do? How can I fix it ? Should I have to manipulate the set up time of the elements ? How can I do that? I'm using ISE 5.1 and ModelSim XE II v5.6e. ThanksArticle: 65282
But it doesn't include any instances ? "Mike Treseler" <mike.treseler@flukenetworks.com> ?????? ??? ?????? news:40101925.7020100@flukenetworks.com... > chris wrote: > > > My problem is that when i try to compile a package in Quartus which has only > > components i receive the error : node instance instantiates undefined entity > > float_pkg. > > A package may contain component declarations, but not instances. > > -- Mike Treseler >Article: 65283
Hi , does anybody know how to compile systemc without sccom for modelsim simulation (win32)? kind regards, thomasArticle: 65284
Jake, No, you are correct about SRAMs, I am wrong there. My only point is that SRAMs can not all be tested at LANSCE in the beam, and when they do get around to it, there have been some spectacular single event latch up problems (ie instant destruction of the device). Austin Jake Janovetz wrote: > You're saying that FPGAs enjoy higher volumes than SRAMs? Interesting... > > > Austin Lesea <austin@xilinx.com> wrote in message news:<bup6dl$8dl2@cliff.xsj.xilinx.com>... > >>The reason for the failure of other parts could be that they are NOT >>FPGAs. FPGAs are manufactured in huge volumes, and are all tested in >>the qualification for latch up under irradiation. Many SRAM,s and other >>products do not have the volume to afford such testing, and in fact >>recent shrinks of common parts are known to latch up with a single >>event, and destroy themselves. >> >>AustinArticle: 65285
Uwe, Thank you. Very interesting. This is the kind of info that is useful to know. Austin Uwe Bonnes wrote: > Austin Lesea <austin@xilinx.com> wrote: > : Lest anyone spread rumors, > > : Spirit used a 4K QPRO part for the squibs that fired for the parachute, > : the inflatable bag, etc for the Lander. > > The Moessbauer Spectrometer has a Quicklogic QL30XX... > > If I remember right, the APX has an Altera ... > > ByeArticle: 65286
hi folks ... when using the Cyclones with the EPCS4 flash configuration chip and active serial mode ... I'd like to use the extra memory space to store a memory image ... so all I need to do is read or write it in a big block .. so yes i have done this with Nios but this is too much overhead in a small cyclone device simply to copy an image from the flash to an external ram .. anyone know how to read the flash without using nios ? kbArticle: 65287
In article <bup6dl$8dl2@cliff.xsj.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: >The reason for the failure of other parts could be that they are NOT >FPGAs. FPGAs are manufactured in huge volumes, and are all tested in >the qualification for latch up under irradiation. Many SRAM,s and other >products do not have the volume to afford such testing, and in fact >recent shrinks of common parts are known to latch up with a single >event, and destroy themselves. I seriously doubt the paranoid EEs at JPL would allow any device which couldn't stand the radiation load, and wasn't batch-tested for the radiation load, onto the rover. My personal bet would be software fault or a nontransient hardware fault in non-memory. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 65288
Hi, Now I am doing some programming on Openrisc processor on FPGA. with Xilinx tools set we can upload the makefile to it and run. the problem is how can I complie the c file to makefile which I can upload it to fpga and processor. example, if we get hello.c. how to compile it to makefile.c? Many Thanks, it is great if you can also send me a email to notice me.:) scr106@york.ac.ukArticle: 65289
Pablo, Thanks for the opportunity to let us brag a bit: Test We test all technologies as part of the qualification in the proton beam at UC Davis, and then at LANSCE in the neutron beam (the industry only gets a few days a year to do tests at LANSCE which is the only facility in the world with a HESS spectrum neutron beam). Hot, Hot, Hot! Can not take them home after the tests till they "cool off" as they are radioactive after spending so much time in the beam. Oh, and none of them ever suffer any damage -- they power on and meet all specs after hundred and hundreds of rads. Real Tests We also do atmospheric testing. We call this the "Rosetta" experiments, as they are intended to help us decipher the meaning of the LANSCE tests which are, after all, just an arbitrary test that has only a correlation to real performance. Sea Level, 5100 Feet, 12,500 Feet, 13,200 Feet We have 100 2VP50's here in San Jose, 100 2V6000's here in San Jose, 100 2V6000's in Albuquerque NM, 100 2V6000's on White Mountain, California (outside of Bishop, Ca), 100 3s1500's due to go online soon here in San Jose, and 100 2VP30's also here in San Jose. Another 110 2V6000's go to Mauna Kea Hawaii next week to the Caltech Submillimeter Observatory. All of them our monitored every 2 hours for any single cosmic ray induced upset. Analysis This is a standard procedure, and we are the ONLY company that actually KNOWS how our parts are affected by cosmic neutron showers, alpha particles, etc in REAL applications from sea level to 60,000 feet (I can't talk about the programs we have for mil/aerospace until you sign an NDA). Competitors Other companies out there are in a state of "blissful ignorance" and when (not if) they start to have customers complain of failures, they will be saying, "gee, we don't see anything (because we can't), must be something you are doing." Why can't they see anything when a customer complains? Xilinx Advanced Technology Our advanced readback and internal access configuration port allows us to actually check all memory cell states to see if anything anywhere has flipped. We can then locate the exact cell that flipped (ie LUT, BRAM, config latch, etc. and from than know what the susceptibility of each one really is). We can identify if that bit is used in the customer's design, and what it does. Because we have had to do this for the military/aerospace community for years, we are able to do this for everyone else who may suspect that they have soft errors. Reality Customers are unlikely to see the problem as anything but a background annoying return rate of "no problems found" as powering down and up, or reconfiguring makes the "problem" go away! At least we have been working on this for 5+ years, have patents pending, making improvements, and understanding exactly how things happen (upsets do happen....most people are totally unaware of this fact). How We Assure Reliability In addition to design techniques in silicon, we also have application design techniques to reduce the probability of soft error causing failure to 0 (ie Spirit and Opportunity, not to mention the hundreds of military and aerospace applications we "fly" in). We are presenting papers at conferences (MAPLD 2003, for example) detailing our results for .5u, .35u, .22u. .18u, .15u, .13u and 90 nanometer. If interested, email me directly, and I will send you the MAPLD ppt presentation. Call or Write for More Information Or better yet, contact your Xilinx FAE for a full technical presentation! Austin PS: many have asked me if the information I present here is unique (proprietary) in any way. It is not. All information posted is published already (ie in the public domain). It is just that I do see all Xilinx press releases, and see all marketing communications, so I am aware of what we can (and are able to) post. Pablo Bleyer wrote: > "Austin Lesea" <austin@xilinx.com> escribió en el mensaje > news:bup6dl$8dl2@cliff.xsj.xilinx.com... > >>The reason for the failure of other parts could be that they are NOT >>FPGAs. FPGAs are manufactured in huge volumes, and are all tested in >>the qualification for latch up under irradiation. Many SRAM,s and other >>products do not have the volume to afford such testing, and in fact >>recent shrinks of common parts are known to latch up with a single >>event, and destroy themselves. > > > Interesting. Under what conditions and what kind of tests are Xilinx > rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed > information about rad parameters... > > Regards. > > > >Article: 65290
chris wrote: > But it doesn't include any instances http://www.altera.com/support/spt-index.html -- Mike TreselerArticle: 65291
everthing is fine - now :-) thomas "T. Irmen" <tirmen@gmx.net> schrieb im Newsbeitrag news:buorks$9dn$1@nets3.rz.RWTH-Aachen.DE... > Hi, > > I tried to register at www.systemc.org . > > There is no email to confirm . > > Does all the OSCI members delete the O in their name? > > Does anybody know whats going on there? > > kind regards, > thomas > >Article: 65292
> Ralph Malph wrote:
>>logic cell count. The last time I checked, counting involved actually
>>counting things. Xilinx seems to think that counting logic cells
>>involves counting and then multiplying by 1.125.
Why would an engineer be concerned
about such estimates when he can run a
synthesis on his design and
get the *exact utilization* ?
-- Mike Treseler
Article: 65293John, It's working well for me so far! Beware of the requirement that the I/O bank that uses the 'DT' input must be powered from VCCO = 2.5V. Pain in the fecking arse if you've got lots of 3.3V I/O as well! Why didn't Xilinx make this termination like the rest of the LVDS input circuit and power it from VCCAUX (which is 2.5V)? Grrr. I tried a couple of times on here to get answers about what happens when the bank is powered from 3.3V, but didn't get very far. Anyway, sorry about that rant, apart from that, it works on my board! cheers, Syms. johnp3+nospam@probo.com (John Providenza) wrote in message news:<349ef8f4.0401221405.36b58977@posting.google.com>... > I'm doing a high speed design with 800 MHz LVDS data input into > a Virtex2-Pro V2P7 part. I've looked at the new 'DT' input > termination mode for the LVDS standard and looked at the > Xilinx Answer Record 17244 for further info. > > It sounds like this mode may not have the issues that DCI had. > > Does anyone know of any issues with using this input termination > mode? > > Thanks! > > John ProvidenzaArticle: 65294
Arkaitz, As a sanity check through this flow (only), you can simply open FPGA Editor and look at the contents of the i-side BRAM to make sure that some of them are non-zero. To do this, open the design in FPGA Editor, find instruction-side BRAM, view it (select then double-click on it), then hit the button that looks like "F=" and it'll bring up its attributes in the window. If they're all zero then something went wrong in updating the BRAM through implementation. If there are some init values that are non-zero then you've got some code in the BRAMs so you need to look elsewhere for another problem. Since you're going to simulation, you can also check the init values for the BRAM in Modelsim. Just select the BRAM in the hierarchy window and look at the signals window for that BRAM. You should then see init values in the signal window - make sure some of them are non-zero as well. As for XMDSTUB mode, I suggest that you make your life easier and use the MDM. If you do, you can then go through the flow for executable mode and still use the debugger when it's all said and done. That's just what I'd suggest from my experience, there may be compelling reasons that you're using xmdstub. If you are still unable to get anything to happen in simulation and/or connect to XMD, it'd probably be a good idea to open a case with customer support. Best regards, Ryan Laity Xilinx Applications arkaitz wrote: > Hi, > > >>To do this, just add your executable.elf file to the ISE project as a >>source. When you do, ISE will ask you how you want the file assigned, >>you should choose the top level file (top_level I believe you called >>it). This will initialize the Block RAM in the .ncd file and therefore >>will be in the simulation model for the post-par simulation. > > > I've tried this several times but it doesn't work. I don't know still > why. > > What I do is to configurate the CPU in XMDSTUB mode so that XMD can > work, but I it fails when connecting. > > Any ideas? > > Regards, > > Arkaitz.Article: 65295
"SDL" <S.DeLuca_No_Spam@USA.NET> wrote in message news:<xx5Qb.6304444$Id.1022160@news.easynews.com>... > Hi, > I have compiled with Quartus II 3.0 SP2s a project that fills a Cyclone C12 > for 89%. > Quartus ends the work later around 2.30 hours (Pentium 4 - 2.8Ghz). > If I try to compile the same project on a PC with processor Intel Pentium 4 > with Hypertheading technology, Quartus doesn't succeed in ending the > fitting, after 24 hours it is I still stop to the 80%. > In the same PC I succeed in quickly compiling less binding projects for the > fitting. > > Is there someone other of you that has had the same problem? > > Does a way exist for resolving this? I have tried to disable from the PC > BIOS, the Hypertheading, also this doesn't resolve the problem . > > Salvo Hi Salvo, The Quartus compiler applications do not make use of hyperthreading. The compiler executables (quartus_map, quartus_fit, quartus_tan, quartus_asm) are all single threaded applications. Based on our experiments the absence or presence of hyperthreading has not had an effect on Quartus compile times or results. One way to eliminate if the problem you are seeing is being caused by hyperthtrading is to run the compiler executables in command line mode. If I have a design called stor and the compiler action point name is stor_flex10k the instructions to compile would be as follows from the DOS command prompt: quartus_map --import_settings_files=on --export_settings_files=off stor -c stor_flex10k quartus_fit --import_settings_files=off --export_settings_files=off stor -c stor_flex10k quartus_asm --import_settings_files=off --export_settings_files=off stor -c stor_flex10k quartus_tan --import_settings_files=off --export_settings_files=off stor -c stor_flex10k --timing_analysis_only quartus_eda --import_settings_files=off --export_settings_files=off stor -c stor_flex10k According to your description there were two different PC's used, one a Pentium 4 2.8 Ghz and the other a Pentium 4 with hyperthtrading. Do they have the same amount of RAM? If you can do send me your machine specs and email me the qar file, and the specs of the computer which is taking a long time to compile. We would definitely like to investigate this further. Thanks - Subroto Datta Altera Corp.Article: 65296
On a sunny day (Thu, 22 Jan 2004 10:56:52 -0800) it happened Austin Lesea <austin@xilinx.com> wrote in <bup6dl$8dl2@cliff.xsj.xilinx.com>: > >Hope those folks figure it out, as it is a tradegy for everyone to lose >the ability to gain knowledge of our solar system. It is obvious whodidit: http://www.home.zonnet.nl/panteltje/mars/easthills-bunny.jpgArticle: 65297
Jim, Thanks for the reference. Pretty nice. I dont want to sound like a sales person for Synplify, but it does an incredible (better than me) job with logic optimization and also timing driven optimization. The problem I reported was a bug in the way I was pipelining the multiplier. Synplify will infer if and only if the output of the multiply is directly connected to the pipeline. I want to create a family of multipliers from the same HDL code by inferring bit widths without loss of performance. And I think Synplicity is pretty good at breaking the multiply based on pipeline stages I provide. I could get a 16x16 multiply to run at 85 MHz on a VirtexE chip. If I wanted to run the same code at 150 MHz, I think I will switch to Virtex-II and still let the synplify infer and map the multiply to a block multiplier in Virtex-II or Spartans. I dont want to sound like a software guy but for creating scalable and portable designs I like inferring as much as possible (with minimal performance degradation). I am interested on your thoughts on it. Sandeep Jim Lewis <Jim@SynthWorks.com> wrote in message news:<1010sdfo3fmcb6d@corp.supernews.com>... > Sandeep, > Check out my paper on, "Coding a 40 x 40 Multipler". > The paper explores coding styles for coding a pipelined > multiplier. > > You can find it at: > http://www.synthworks.com/papers/index.htm > > Also Ray Andraka has some great papers on implementing > math in FPGAs. See: http://www.andraka.com/multipli.htm > > Cheers, > Jim > > Sandeep wrote: > > Does anyone have experience with synthesizing multipliers using "*" > > operator in Synplify ? To pipleline the multiplier has anyone tried > > the piplelining feature in Synplify and/or by attaching attributes to > > output registers ? I know it works on a multiplier by itself. But in a > > larger design the pipleline stages are reduced to 1 or 2 even though I > > attached 4-5 registers to the multiplier output. > > > > Sandeep > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jim Lewis > Director of Training mailto:Jim@SynthWorks.com > SynthWorks Design Inc. http://www.SynthWorks.com > 1-503-590-4787 > > Expert VHDL Training for Hardware Design and Verification > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 65298
ok, so the PHY has some analog job to do.
If I make some experiments, I'll look for a solution with a low pin count.
Maybe an R-L filter.
It might be interesting to put all this info available on my site, even if
that's more analog than digital.
In any case, thanks for all this info, I didn't suspect there was so much
analog work involved.
Jean
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:a1t110pt27vg5b69uq8vbiopul59eh75o2@4ax.com...
> On Tue, 20 Jan 2004 08:52:20 GMT, "Jean Nicolle"
> <j.nicolle@sbcglobal.net> wrote:
>
> >Thanks for the *detailed* answer.
> >I used 3.3V IOs, so I need an 1:1.3 transformer to meet both amplitude
and
> >return loss.
> >I guess that if I want to use common 1:1 transformers, I need 5V IOs and
> >50ohms resistors.
>
> Yes, that would also give a good output level and return loss. The
> FPGA pin current would be 25mA, which would probably be possible
> without needing to double-up output drivers.
>
> There is a direct tradeoff between current and voltage at the FPGA
> pins which is determined by the transformer ratio.
>
> (ASIC) PHYs often drive into a centre tapped transformer. The centre
> tap is connected to VCC (or sometimes GND). The outputs only pull
> down (one at a time), and the transformer action makes the voltage at
> the other output rise above the supply rail. This allows more voltage
> swing from a given supply voltage, but can't be done in an FPGA due to
> restrictions in the voltages that can be applied to output pins. (Or
> can it? You might get lucky with some 5V compliant parts running from
> lower voltages.)
>
> >For the equalization and harmonic requirements, couldn't I use a filter?
> >27dB is pretty sharp though, doesn't seem easy.
>
> It's not easy. You'd also need a buffer amp after the filter,
> otherwise the line impedance will affect the filter response and it
> will also be difficult to get a good (wideband) return loss.
>
> >Looking at some PHY/transformer schematics doesn't show any filter. Is it
> >usually provided inside the PHY?
>
> The (FIR) filter is implemented digitally inside the PHY.
> You can also think of this as "pulse shaping" rather than filtering.
>
> This sort of thing just isn't feasible inside an FPGA, unless you use
> some sort of DAC on the output. ("Some sort of DAC" could be as
> simple as a small number of resistors though.)
>
> This sci.electronics.design thread:
>
http://groups.google.com/groups?threadm=fntrju0uphuno94gbe0qeue5859v3t5b38%404ax.com
> discusses the design of a pulse shaping filter for an ASIC. The
> designer ended up with a combination of an FIR filter (implemented
> with a weighted resistor network) inside the ASIC and a single pole LP
> filter outside the ASIC to achieve the required pulse shape (and hence
> frequency response).
>
> Regards,
> Allan.
Article: 65299
Inference is great as long as you can live with the results. 85 MHz is trivial on a VirtexE, we
typically ran VirtexE at 160+ MHz, including multipliers bigger than 16x16, but you won't get
there very often with just inference. We get scalability by building our macros for things like
placed multipliers to automatically size to the connected bus sizes, and/or to use generics to
set up parameters. Much of my work (re)uses placed macros that are structurally instantiated
primitives. The generate statement with the ability to put loop variables in the constant
definitions (for the RLOC strings) is essential. It is one of those things that VHDL does well,
that even with the 2001 enhancements verilog still can't do.
Granted, I do give up some portability, but much of that can be recovered by changing the
library of lower level macros or even just the primitives. My xilinx libraries have, for the
most part, been updated with a "virtex" generic which causes the RLOCs to be for
virtex/virtexE/spartan2, virtexII, virtex3/spartan3,or unplaced. I have ported some of these
designs to Altera, but the bigger issue there is that the differences in chip features usually
means some high level archiectural changes in order to get a near optimal design. This is true
whether you infer or instantiate.
Sandeep wrote:
> Jim,
> Thanks for the reference. Pretty nice. I dont want to sound like a
> sales person for Synplify, but it does an incredible (better than me)
> job with logic optimization and also timing driven optimization. The
> problem I reported was a bug in the way I was pipelining the
> multiplier. Synplify will infer if and only if the output of the
> multiply is directly connected to the pipeline. I want to create a
> family of multipliers from the same HDL code by inferring bit widths
> without loss of performance. And I think Synplicity is pretty good at
> breaking the multiply based on pipeline stages I provide. I could get
> a 16x16 multiply to run at 85 MHz on a VirtexE chip. If I wanted to
> run the same code at 150 MHz, I think I will switch to Virtex-II and
> still let the synplify infer and map the multiply to a block
> multiplier in Virtex-II or Spartans. I dont want to sound like a
> software guy but for creating scalable and portable designs I like
> inferring as much as possible (with minimal performance degradation).
> I am interested on your thoughts on it.
>
> Sandeep
> Jim Lewis <Jim@SynthWorks.com> wrote in message news:<1010sdfo3fmcb6d@corp.supernews.com>...
> > Sandeep,
> > Check out my paper on, "Coding a 40 x 40 Multipler".
> > The paper explores coding styles for coding a pipelined
> > multiplier.
> >
> > You can find it at:
> > http://www.synthworks.com/papers/index.htm
> >
> > Also Ray Andraka has some great papers on implementing
> > math in FPGAs. See: http://www.andraka.com/multipli.htm
> >
> > Cheers,
> > Jim
> >
> > Sandeep wrote:
> > > Does anyone have experience with synthesizing multipliers using "*"
> > > operator in Synplify ? To pipleline the multiplier has anyone tried
> > > the piplelining feature in Synplify and/or by attaching attributes to
> > > output registers ? I know it works on a multiplier by itself. But in a
> > > larger design the pipleline stages are reduced to 1 or 2 even though I
> > > attached 4-5 registers to the multiplier output.
> > >
> > > Sandeep
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Jim Lewis
> > Director of Training mailto:Jim@SynthWorks.com
> > SynthWorks Design Inc. http://www.SynthWorks.com
> > 1-503-590-4787
> >
> > Expert VHDL Training for Hardware Design and Verification
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
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