Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi All. Having a module with input signal of my own type, described in package (which is simply "type MYTYPE is array in 0 to n of std_logic_vector(k downto 0)"), i am facing the following problem: in post-place&route(PPR) model this type is substituted on "std_logic_vector2(n downto,k downto 0)" :-/ so ModelSim obviously argues "Default binding had errors for entity "my_comp" on the component declaration". I generate the model in ISE 6.3 Sorry if the question is stupid, but is there any way to fix such situation rather than manually change the PPR model file. As I can see my package is simply ignored. Thank you for help. AlexArticle: 84801
Hallo, I have a Spartan 3 Starter Board. I should use a BRAM as a SRAM. I have read that BRAM_if_controller should do it. I would know if it is possible to connect a dual port ram to the controller. In this way I could access BRAM as 1MB RAM on board though C software and I could also make a sequential reading (hardware, with a counter which generates addresses) on the same BRAM to send data to board pins indipendently from which I am writing or reading though software. If it is possbile, there is someone who know how? Many Thanks Marco ToschiArticle: 84802
Nicolas, http://tinyurl.com/4mvcw Details the definitions of jitter, and some common causes, and measurement issues. AustinArticle: 84803
I plan to combine my own embedded processor and HW logic into Spartan3. EDK just supports MicroBlaze or PowerPC, right?How can I make the embedded system by using my own embedded processor and HW IP on it?I know how to make HW ip on it by using ISE. Any suggestions or any links? Thanks, EthanArticle: 84804
<yijun_lily@yahoo.com> wrote in message news:1117205800.585842.149140@z14g2000cwz.googlegroups.com... > I plan to combine my own embedded processor and HW logic into Spartan3. > EDK just supports MicroBlaze or PowerPC, right?How can I make the > embedded system by using my own embedded processor and HW IP on it?I > know how to make HW ip on it by using ISE. > > Any suggestions or any links? > > Thanks, > > Ethan > You could use the OPB IPIF to have your processor in OPB Master configuration. You can do it with the Create/Import Peripheral Wizard that comes with EDK. MarcoArticle: 84805
Hi, I am trying to use V4 FX's hard EMAC core. (EDK's opb_ethernet_0 is soft core.) Has anyone ever made hard EMAC working for V4 FX12? Does Xilinx provide any ref design? ThanksArticle: 84806
"Peter Alfke" <peter@xilinx.com> wrote in message news:1117229140.816601.128360@g44g2000cwa.googlegroups.com... > Marco, I see that nobody sent you an answer. That may be because it is > difficult to understand what you really need. > I doubt that you have megabytes of RAM on a small Spartan eval board. > The BlockRAM is a static RAM. It has two totally independent ports, > each with their own addressing, control, and timing. And you can even > have different widt/depth ratios on the two ports. > Note that you need a clock to access the BlockRAM. Just changing the > address does nothing, you need a clock, even for a read operation. > Think about it, and tell us (or me) what your real problem is. > Peter Alfke, Xilinx Applications > (On the starter board there is 1 MByte of RAM) I would access the BlockRam through software as I can access the 1MB RAM of starter board: I would create variables, etc... into BlockRam. I have read about the opb bram controller, but I don't have found information about the way to use it through software. I hope it is more clear... Thanks MarcoArticle: 84807
The result of Manchester coding is that in the "high" part of the clock you send the data bit and in the "low" part of the clock you send the opposite Therefore if you want to send the data 0 and your period is 100n than for 50n you will send 0 and for the next 50n you will send 1. This is why from frequency point of view you have double the frequency however from "effective" data you have the same throughput. How to extract the clock from any serial stream whether it have Manchester or not usually mean you have some sort of PLL (might be digital not necessarily analog but to make life easier I will simple use the word PLL for all) which get reference clock from probably an on board oscillator and than use to to recover the clock of the incoming data. In order to be able to find the right place to put the edge of the clock as well as the right frequency you need "enough" changes as just imagine you send only 0 how the receive side can tell what freq and what is the phase. This is by the way one of the reason there is preamble because the receive side need some data to be able to align itself. In FastEth the Phy don't really need so much preamble/sfd however recall that in Eth (10M) the media was quite most of the time (in FastEth there is constantly transmission of idle even when there is no data to send to the receive Phy is constantly in sync) As for how to find the best position for the clock in Manchester that once the CDR recover the clock you have double the clock so divide by two will give the right frequency as for the phase take the ....001... as the sync point than knowing that the last 01 was due to 0 if the clock move from 0 to 1 the 01 pattern and go to zero after the 1 and so on you have now the clock in the middle of your data and than you can sample this data with the new clock and you are back in business. Have fun.Article: 84808
Jim- > I have tried to instantiate the Asynchronous FIFO core (v6) from > Coregen, and it's been giving me trouble. First, I can't get it to > produce a FIFO using distributed RAM (I wanted a 31-deep FIFO). When I > try, it tells me there is a block RAM in the usage summary. We have often dealt with the same issue. You can have distributed Ram selected, but it still uses block ram. Our solution has been to always click the dist ram button before generating - even if it is already selected. Also always check "view core footprint" to see if it used block ram or dist ram. If block ram, try again. Silly, but this issue has been there since at least version 4, and is still there in v6.1. Luckily you only have to get it to generate properly once... Jason Daughenbaugh http://www.advanced.proArticle: 84809
Hi, I've recently upgraded to Quartus 4.2 and discovered the Incremental Compilation feature. Has anyone had any problems using this feature, anything I should know before trying it out? If anyone has anything to share please let me know. I'm using Quartus 4.2 for my Stratix design. Thanks, joeArticle: 84810
Peter Alfke wrote: >You wrote: >"But, there's some stuff that is just so much more concise in VHDL. > One >example is a Gray-binary or binary-Gray code converter. In schematic, >it is a >string of FFs and XORs. In VHDL, it is a parameterizable one-line >statement, with >the parameter being the # of bits." > >This is correct, but: >I have seen people converting a binary counter output to Gray code, >believing that this would allow glitchless decoding. Of course it does >not: The delay differences on the binary side go straight through to >the Gray side. >If you are a Schemtosaurus, you easily see a solution: Re-synchronize >the Gray output. >And if you are clever, you drive the conversion not from the binary >counter's Q outputs but from its D inputs. That keeps the two counters >in step. > > Yup, I figured this out about halfway through that project. But, the customer was real wary of synchronizing to any system clock. False logic, of course, but you are quite right. It could have been done totally without the binary-Gray and back again. Hmmm, now I don't remember, but I think the counter clock strobed the Gray code into a Gray-code register, which would then be free of any glitches. It was then sampled safely by a clock from a different domain. A hell of a lot of logic to synchronize 48 signals when only one signal really needed to be synchronized. JonArticle: 84811
Marco, I see that nobody sent you an answer. That may be because it is difficult to understand what you really need. I doubt that you have megabytes of RAM on a small Spartan eval board. The BlockRAM is a static RAM. It has two totally independent ports, each with their own addressing, control, and timing. And you can even have different widt/depth ratios on the two ports. Note that you need a clock to access the BlockRAM. Just changing the address does nothing, you need a clock, even for a read operation. Think about it, and tell us (or me) what your real problem is. Peter Alfke, Xilinx ApplicationsArticle: 84812
In FIFOs that use uncorrelated clocks for read and write, you need to use Gray counters for glichless compare. If you also want to detect programmable "almost empty" (dipstick) you really need binary addresses to do the math on. Since counting is so much easier in binary, it seems best to start with binary address counters, and then create a Gray version of it. But the Gray version must be registered, otherwise you move the binary glitches to the Gray lines. My trick is to derive the Gray logic from the binary D inputs. That way the binary and Gray count values are in sync, not offset. Minor point, but I like it... Peter Alfke, Xilinx ApplicationsArticle: 84813
Hi,
Recently we are considering switching from Virtex II to Stratix II.
We have evaluated both Synplify 8.1+ISE 7.1i with Virtex 4, and
Synplify 8.1+Quartus II 5.0 with Stratix II.
Synplify reports consistent results for several designs.
The large one is around 200K gate count (in ASIC), and the smaller
ones are CORDIC divider and a SRT R4 divider.
Quartus often gives amazing results. Yes, I mean that. Very amazing.
For example, when synplify shows that several muxes and two 26-bit
additions in series can only run at 66MHz in Startix II, the
post-Quartus results show that this design can run at 160MHz.
When synplify shows that a SRT Radix-4 divider can run at 160Mhz,
the Quartus results show that it can only run at 87MHz.
I have very few experience of using Quartus. Is it because synplify
did a poor job estimating the results for Stratix II device, or
Quartus II 5.0 did a very good job on physical synthesis?
In the past, we always feel that Synplify's results, though not
accurate, are always consistent with ISE's. For the above two cases,
SRT and CORDIC, theoretical analysis would favor Synplify's results.
Can someone familiar with Quartus and Stratix II device comment
on this? How reliable is the report from Quartus?
Any comment is appreciated!
Thanks!
Regards,
wenchang
Article: 84814The report from Quartus is always reliable, as it is based on timing calculated from the final place and route information for your design. We always ask customers to base their performance decisions based on the Quartus timing report and not on estimates given by the HDL synthesis tools. Synthesis tools can at best estimate what the final place and route look like, and given the more advanced architectures today they may not be accurate unless they have the actual place and route engine built into their product. Also Quartus has the capability to perform physical synthesis optimizations as part of the fitting process, whose benefits cannot be estimated by the HDL synthesis tool. Having said that, Quartus II 5.0 also has a feature called the Early Timing Estimator that provides timing information without doing a complete place and route. The accuracy of the results can be controlled by choosing one of three choices, Realistic, Optimistic or Pessimistic. This command takes less time than doing a full place and route. This feature can be accessed through the Process->Start->Start Early Timing Estimate menu. More details can be found in the Timing Analysis section of the Quartus Handbook at http://answers.altera.com/altera/resultDisplay.do?page=http%3A%2F%2Fwww.altera.com%2Fliterature%2Fmanual%2Fintro_to_quartus2.pdf&result=0&responseid=b0b5a30041c7c737%3A1381e7%3A104216579b2%3A-7771&groupid=1&contextid=966%3A54913.54934%2C14175.14214%2C33446.33489&clusterName=DefaultCluster&doctype=1002&excerpt=early_timing_estimate#Goto54913 Hope this helps, Subroto Datta Altera Corp. "Wenchang" <wcyeh_nospam@seed.net.tw> wrote in message news:d78obk$t5q$1@news.seed.net.tw... > Hi, > > Recently we are considering switching from Virtex II to Stratix II. > We have evaluated both Synplify 8.1+ISE 7.1i with Virtex 4, and > Synplify 8.1+Quartus II 5.0 with Stratix II. > > Synplify reports consistent results for several designs. > The large one is around 200K gate count (in ASIC), and the smaller > ones are CORDIC divider and a SRT R4 divider. > > Quartus often gives amazing results. Yes, I mean that. Very amazing. > For example, when synplify shows that several muxes and two 26-bit > additions in series can only run at 66MHz in Startix II, the > post-Quartus results show that this design can run at 160MHz. > When synplify shows that a SRT Radix-4 divider can run at 160Mhz, > the Quartus results show that it can only run at 87MHz. > > I have very few experience of using Quartus. Is it because synplify > did a poor job estimating the results for Stratix II device, or > Quartus II 5.0 did a very good job on physical synthesis? > In the past, we always feel that Synplify's results, though not > accurate, are always consistent with ISE's. For the above two cases, > SRT and CORDIC, theoretical analysis would favor Synplify's results. > > Can someone familiar with Quartus and Stratix II device comment > on this? How reliable is the report from Quartus? > > Any comment is appreciated! > > Thanks! > > Regards, > > wenchangArticle: 84815
On Fri, 27 May 2005 16:42:31 +0200, "Marco" <marcotoschi_no_spam@email.it> wrote: >Hallo, Hello, >I have a Spartan 3 Starter Board. > >I should use a BRAM as a SRAM. I have read that BRAM_if_controller should do >it. This might make sense if you are implementing a soft processor in the FPGA. If you are instead building logic without a processor in the FPGA, then this is unneeded. Just connect the BRAM up to your logic. >I would know if it is possible to connect a dual port ram to the controller. Depends on why you think you need a controller. It usually only makes sense to use controllers like this if there is a CPU in the FPGA. >In this way I could access BRAM as 1MB RAM on board though C software and I This does not make sense. The amount of BRAM in the FPGA is not 1MB. The XC3S200 FPGA has 12 blocks of 2K bytes (9 bit bytes) for a total of 221184 bits. There is 1MB of SRAM on the board outside the FPGA, but this is not called BRAM. Reading and writing this SRAM is "just a matter of hardware design". Where do you think this C code is running? inside the fpga, or on your host computer? How are you planning to talk to your board from your host computer? >could also make a sequential reading (hardware, with a counter which >generates addresses) on the same BRAM to send data to board pins >indipendently from which I am writing or reading though software. Again, the issue is where you think this software is running. FPGAs do not run C code, unless you have designed (or got it from somewhere else) a CPU and loaded it into the FPGA. You may want to learn about Microblaze and Picoblaze on the Xilinx website. >If it is possbile, there is someone who know how? I don't think you understand the environment well enough yet. When you can answer alll my above questions, then you can get more help. Philip >Many Thanks >Marco Toschi > =================== Philip Freidin philip.freidin@fpga-faq.org Host for WWW.FPGA-FAQ.ORGArticle: 84816
"Philip Freidin" <philip@fliptronics.com> wrote in message news:045g91ls6djblmpdt86mjcmg2tfvvu2k4a@4ax.com... > On Fri, 27 May 2005 16:42:31 +0200, "Marco" <marcotoschi_no_spam@email.it> wrote: > >Hallo, > > Hello, > > >I have a Spartan 3 Starter Board. > > > >I should use a BRAM as a SRAM. I have read that BRAM_if_controller should do > >it. > > This might make sense if you are implementing a soft processor in > the FPGA. If you are instead building logic without a processor in > the FPGA, then this is unneeded. Just connect the BRAM up to your logic. I'm developing a microcontroller based on microblaze. > > >I would know if it is possible to connect a dual port ram to the controller. > > Depends on why you think you need a controller. It usually only makes > sense to use controllers like this if there is a CPU in the FPGA. > > >In this way I could access BRAM as 1MB RAM on board though C software and I > > This does not make sense. The amount of BRAM in the FPGA is not 1MB. > The XC3S200 FPGA has 12 blocks of 2K bytes (9 bit bytes) for a total > of 221184 bits. There is 1MB of SRAM on the board outside the FPGA, > but this is not called BRAM. Reading and writing this SRAM is "just a matter > of hardware design". I know that BRAM is not 1MByte. I understand also to have written something not understandable, sorry! I need only 32KByes of BRAM to make a video memory for a black/white lcd display. > > Where do you think this C code is running? inside the fpga, or on your > host computer? How are you planning to talk to your board from your > host computer? Inside FPGA, loaded from flash with boot support and copied into 1MByte RAM > > >could also make a sequential reading (hardware, with a counter which > >generates addresses) on the same BRAM to send data to board pins > >indipendently from which I am writing or reading though software. > > Again, the issue is where you think this software is running. FPGAs > do not run C code, unless you have designed (or got it from somewhere else) > a CPU and loaded it into the FPGA. You may want to learn about Microblaze > and Picoblaze on the Xilinx website. I must develop a lcd display controller. The other parts are ready for running (some taken by edk ip cores, some mades by me) I hope now my trouble is more clear. Thanks MarcoArticle: 84817
I need only 20 Kbit into BRAM... I made a mistake into previous message.Article: 84818
Thanks Piotr Do you have sample code or scheme? I think I use ethernet controller and M16C 62P group processor.Article: 84819
Link to a good selection of FPGA based boards: http://www.hitechglobal.com/Boards/allboards.htm as well as IP Cores for FPGA and ASIC http://www.hitechglobal.com/ipcores/default.htmArticle: 84820
On Sat, 28 May 2005 09:47:28 +0200, "Marco" <marcotoschi_no_spam@email.it> wrote:
>"Philip Freidin" <philip@fliptronics.com> wrote in message
>news:045g91ls6djblmpdt86mjcmg2tfvvu2k4a@4ax.com...
>> On Fri, 27 May 2005 16:42:31 +0200, "Marco" <marcotoschi_no_spam@email.it>
>wrote:
>> >Hallo,
>>
>> Hello,
>>
>> >I have a Spartan 3 Starter Board.
>> >
>> >I should use a BRAM as a SRAM. I have read that BRAM_if_controller should
>do
>> >it.
>>
>> This might make sense if you are implementing a soft processor in
>> the FPGA. If you are instead building logic without a processor in
>> the FPGA, then this is unneeded. Just connect the BRAM up to your logic.
>
>I'm developing a microcontroller based on microblaze.
Ok, now it makes more sense. As you have written, you should probably
be using "OPB BRAM Controller", which is described in the Xilinx document
DS468 at:
http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=OPB_BRAM_Controller&iLanguageID=1
>>
>> >I would know if it is possible to connect a dual port ram to the
>controller.
Yes you can do this. The BRAM is described in the Libraries guide at:
http://toolbox.xilinx.com/docsan/xilinx7/books/manuals.htm
and the specific item you need to look for is RAMB16_Sm_Sn
>> Depends on why you think you need a controller. It usually only makes
>> sense to use controllers like this if there is a CPU in the FPGA.
>>
>> >In this way I could access BRAM as 1MB RAM on board though C software and
>I
>>
>> This does not make sense. The amount of BRAM in the FPGA is not 1MB.
>> The XC3S200 FPGA has 12 blocks of 2K bytes (9 bit bytes) for a total
>> of 221184 bits. There is 1MB of SRAM on the board outside the FPGA,
>> but this is not called BRAM. Reading and writing this SRAM is "just a
>> matter of hardware design".
>
>
>I know that BRAM is not 1MByte. I understand also to have written something
>not understandable, sorry!
>
>I need only 32KByes of BRAM to make a video memory for a black/white lcd
>display.
Later: I need only 20 Kbit into BRAM... I made a mistake into previous message.
A BRAM is either 16K bits (for widths 1, 2, 4 bits) or 18K bits (width 9, 18, 36).
From a performance point of view, you get to move more data per cycle with
wider transfers. But the BRAM interface to microblaze only supports up to
32 bits. This would suggest (but it is not mandatory) that you would set
up the BRAM in a by 36 bit width, and just not use 4 bits of the data path
from the BRAM. This would give you 16K bits (RAMB16_S36_S36).
Since you need a total of 20K bits, then you need to have 2 BRAMs. If you
set them both for 18 bits wide (1K deep), and addressed them at the same time,
you would have 36 bits wide by 1K, of which you would use 32 bits by 1K,
for a total useable size of 32K bits. All of the above would apply to just
1 of the two ports of each BRAM. The other port is addressed by what ever
hardware you design to read the data out and send it to your LCD.
The BRAM instantiation would be 2 x RAMB16_S18_S18
Note: 1) The BRAM will have to be instantiated.
2) The second port can be a different width than the first port,
but the complexities of how that affects addressing may be
something you dont want to deal with initially.
>> Where do you think this C code is running? inside the fpga, or on your
>> host computer? How are you planning to talk to your board from your
>> host computer?
>
>Inside FPGA, loaded from flash with boot support and copied into 1MByte RAM
Ok. The interface from the external SRAM to microblaze for code fetch
is separate from all the stuff that I have written above. You should
get this working first (as a confidence booster) befor you start on adding
the BRAM and LCD interface.
>>
>> >could also make a sequential reading (hardware, with a counter which
>> >generates addresses) on the same BRAM to send data to board pins
>> >indipendently from which I am writing or reading though software.
>>
>> Again, the issue is where you think this software is running. FPGAs
>> do not run C code, unless you have designed (or got it from somewhere
>else)
>> a CPU and loaded it into the FPGA. You may want to learn about Microblaze
>> and Picoblaze on the Xilinx website.
>
>
>I must develop a lcd display controller.
Right.
>The other parts are ready for >running (some taken by edk ip cores, some mades by me)
Good.
>I hope now my trouble is more clear.
I think so. I hope my notes are of help to you.
>Thanks
>Marco
Good luck,
Philip
===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
Article: 84821Hello, I've an Virtex II (later it'll be a Spartan 3) witch is connected to external asynchronous SRAM. Now I would like to access it in the same way as a synchronous SRAM (like a BRAM for example). I think reading should work in the same way as with an synchronous SRAM (set address and /oe and read data at the next clock) as long the SRAM is fast enough. But I've no idea how to implement a write access in an efficient way. I could set address, data and /wr and create some logic that clears the /wr signal at the falling edge of the clocksignal. But so I could only use half the speed of the SRAM because the /wr signal would only high for half the clock period. Please let me know if there is any better way to implement this. MichaelArticle: 84822
"Michael Dreschmann" <michaeldre@gmx.de> wrote > ... external asynchronous SRAM. ... > But I've no idea how to implement a write access in an > efficient way. Search for discussions of this in the past (fpga-faq.com). Also, here's how I did this long ago -- too clever by half, I'm afraid: http://groups.yahoo.com/group/fpga-cpu/message/539. Jan GrayArticle: 84823
Please use the URL http://www.altera.com/literature/hb/qts/qts_qii53004.pdf to find out about Early Timing Estimate details. The one I pasted was based on a answer search on "Early Timing Estimate", and clicking on the URL in my previous post will not work. Hope this helps, Subroto Datta "Subroto Datta" <sdatta@altera.com> wrote in message news:rbSle.2375$2u1.2145@newssvr19.news.prodigy.com... > The report from Quartus is always reliable, as it is based on timing > calculated from the final place and route information for your design. We > always ask customers to base their performance decisions based on the > Quartus timing report and not on estimates given by the HDL synthesis > tools. Synthesis tools can at best estimate what the final place and route > look like, and given the more advanced architectures today they may not be > accurate unless they have the actual place and route engine built into > their product. Also Quartus has the capability to perform physical > synthesis optimizations as part of the fitting process, whose benefits > cannot be estimated by the HDL synthesis tool. > > Having said that, Quartus II 5.0 also has a feature called the Early > Timing Estimator that provides timing information without doing a complete > place and route. The accuracy of the results can be controlled by choosing > one of three choices, Realistic, Optimistic or Pessimistic. This command > takes less time than doing a full place and route. > > This feature can be accessed through the Process->Start->Start Early > Timing Estimate menu. More details can be found in the Timing Analysis > section of the Quartus Handbook at > http://answers.altera.com/altera/resultDisplay.do?page=http%3A%2F%2Fwww.altera.com%2Fliterature%2Fmanual%2Fintro_to_quartus2.pdf&result=0&responseid=b0b5a30041c7c737%3A1381e7%3A104216579b2%3A-7771&groupid=1&contextid=966%3A54913.54934%2C14175.14214%2C33446.33489&clusterName=DefaultCluster&doctype=1002&excerpt=early_timing_estimate#Goto54913 > > Hope this helps, > Subroto Datta > Altera Corp. > > "Wenchang" <wcyeh_nospam@seed.net.tw> wrote in message > news:d78obk$t5q$1@news.seed.net.tw... >> Hi, >> >> Recently we are considering switching from Virtex II to Stratix II. >> We have evaluated both Synplify 8.1+ISE 7.1i with Virtex 4, and >> Synplify 8.1+Quartus II 5.0 with Stratix II. >> >> Synplify reports consistent results for several designs. >> The large one is around 200K gate count (in ASIC), and the smaller >> ones are CORDIC divider and a SRT R4 divider. >> >> Quartus often gives amazing results. Yes, I mean that. Very amazing. >> For example, when synplify shows that several muxes and two 26-bit >> additions in series can only run at 66MHz in Startix II, the >> post-Quartus results show that this design can run at 160MHz. >> When synplify shows that a SRT Radix-4 divider can run at 160Mhz, >> the Quartus results show that it can only run at 87MHz. >> >> I have very few experience of using Quartus. Is it because synplify >> did a poor job estimating the results for Stratix II device, or >> Quartus II 5.0 did a very good job on physical synthesis? >> In the past, we always feel that Synplify's results, though not >> accurate, are always consistent with ISE's. For the above two cases, >> SRT and CORDIC, theoretical analysis would favor Synplify's results. >> >> Can someone familiar with Quartus and Stratix II device comment >> on this? How reliable is the report from Quartus? >> >> Any comment is appreciated! >> >> Thanks! >> >> Regards, >> >> wenchang > >Article: 84824
> > I have very few experience of using Quartus. Is it because synplify > did a poor job estimating the results for Stratix II device, or > Quartus II 5.0 did a very good job on physical synthesis? > In the past, we always feel that Synplify's results, though not > accurate, are always consistent with ISE's. For the above two cases, > SRT and CORDIC, theoretical analysis would favor Synplify's results. I've always found Synplify to be over optimisitic for Xilinx and underoptimisitic for Altera. Maybe Xilinx slipped em a few quid? :) Cheers, Jon
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