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
<steve.lass@xilinx.com> wrote in message news:etubki$kv11@cnn.xsj.xilinx.com... > > There seems to be an infinite number of things our users can implement > in an FPGA so it's impossible to find every bug. It might be impossible to find every bug, but surely you can at least make error messages more informative. Also, I am not necessarily talking about bugs. IMHO there is a problem with the underlying algorithms as well.... > However, less than 15% > of the map and par bugs are found by customers and we continue to try to > lower that number. I am afraid other 85% simply don't get reported. Ask your users how many of the fatal or portability errors that they experienced they have actually reported? > In 7.1i, we replaced our database and took a hit for map and par quality. > Since then, we have improved considerably, and have made quality the > highest priority for 9.1i and future releases. Other priorities for map > and > par are new device support, QOR, runtime, incremental design and > partial reconfiguration. In my experience until the device is approximately 50% full the tools work more or less OK. If they crash I can usually pretty quickly find a different combiantion of options, which will make the design pass. However, as the device gets more and more full the issues with the tools become increasingly more difficult to deal with. I guess in part it is simply a function of the compile time. But in part it is definitely the tools behave less predictable. I think I won't be the first to say postpone any GUI work, any work on new features and concentrate on giving us truly robust and efficient back-end tools. /MikhailArticle: 117076
I forgot to comment on the ISE Simulator question. We have a very close partnership with the Mentor Modelsim group and the plan is to continue to OEM Modelsim XE as long as people keep buying it. Our focus for the ISE Simulator is to have world class language support, to improve the robustness of the simulator, and to support the hard IP in Xilinx devices (like PPC and MGT) which are currently only supported by much higher priced simulators. The target right now is for simulation of WebPACK-size devices, but the size limitation will go away over time. Steve <steve.lass@xilinx.com> wrote in message news:etubki$kv11@cnn.xsj.xilinx.com... > > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:46020799$1@clear.net.nz... >> Thanks Steve, - can you comment on the relative effort/quality of the HDL >> branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST >> Simulator (relative to Modelsim et al ) ? >> >> -jg > > The effort going into VHDL and Verilog is about the same. ABEL is in > maintenance mode so only gets attention when serious bugs are reported. > > "MM" <mbmsv@yahoo.com> wrote in message > news:56fnqfF28iph7U1@mid.individual.net... >> Hello Steve, >> >> Would you now be willing to comment on the MAP and PAR quality? To me >> this is a much bigger problem than XST not supporting certain aspects of >> VHDL. Based on experience I have learned to write my code using only a >> small subset of the language, which is supported for sure. >> >> Thanks, >> /Mikhail >> > > There seems to be an infinite number of things our users can implement > in an FPGA so it's impossible to find every bug. However, less than 15% > of the map and par bugs are found by customers and we continue to try to > lower that number. > > In 7.1i, we replaced our database and took a hit for map and par quality. > Since then, we have improved considerably, and have made quality the > highest priority for 9.1i and future releases. Other priorities for map > and > par are new device support, QOR, runtime, incremental design and > partial reconfiguration. > > Steve > > >Article: 117077
> I would not be the one to throw mud at the other (on power estimation)! If there is any mud you'd like to throw at the EPE, please feel free. Our goal is to make the best tool we can, that is as accurate as possible. Any specific criticism that helps us get closer to that goal is appreciated. If my comments result in a corrected FF model and the addition of a clock model to the XPE, this will help improve the fairness of comparisons between XPE and EPE. And it will help Xilinx customers avoid bad power surprises. Seems like a win-win situation to me. > It has been clear (to me, by using your tools for S2, using actual > measurements on the 'Battle-Board') that your policy is different. Our typical static power value represents the typical device we ship. That the median of a distribution didn't match the couple sample points you have should not surprise you. I'm sure you don't need a lesson in statistics from me. > I also agree that dynamic power does not vary hardly at all with process > or temperature. I will say that estimating dynamic power is also very > difficult, as the customer not only has to have a vector file from his > simulations, but that vector file has to be faithful to their > application, and cover actual intended operating situations. The number > of customers with the patience to run extensive simulations and check to > see how "real" they are is not a large number. Most will find the > initial estimate from the spreadsheet adequate for their first guess at > power supply and heatsink. After their prototype pcb is built, there is > the opportunity to fine tune the power supplies and cooling (if needed). There are three separable sources of error here: (1) Transition densities and signal probabilities (simulation, hand entered, etc.) (2) Design implementation details (synthesis, placement, routing) (3) Quality of the underlying models (1) is pretty much in the hands of the users. All we (FPGA vendors) can do is give them many ways to get the toggle rates into our tools. In the end, if the user grossly mispredicts the toggling of their design, there's nothing we can do for them. (2) is somewhere in-between. Quartus/ISE should know everything to make this a non-factor. But in an EPE/XPE tool, its a combination of user entry (things like I/O standards, RAM modes, etc) and reasonable guesses on our part. This is where things like representing reasonable routing power is important -- the user has no idea what their design will use, so we must make the best guess we can for them. (3) is completely under our control. Given perfect entry for (1) and (2), our goal is to minimize the error between our estimates and silicon measurements. If supplied with perfect information a tool still can't estimate power correctly, then what hope does a user have? > I wish engineers were more disciplined, and spent more time on > simulation, but FPGA devices are marketed as "fast to market" and many > sometimes take that as "not much risk to skip a few steps..." Yes, it is unfortunate. Most vectors users have lying around are targeted at corner-case coverage, and do not represent typical steady- state operation. Paul Leventis Altera Corp.Article: 117078
On Mar 22, 2:45 pm, <steve.l...@xilinx.com> wrote:
> I forgot to comment on the ISE Simulator question.
>
> We have a very close partnership with the Mentor Modelsim group and the
> plan is to continue to OEM Modelsim XE as long as people keep buying it.
>
> Our focus for the ISE Simulator is to have world class language support,
> to improve the robustness of the simulator, and to support the hard IP in
> Xilinx devices (like PPC and MGT) which are currently only supported by
> much higher priced simulators.
>
Wow, this is the best news I've seen in 2007. I've always wanted to
play with the "neat" high-end xilinx components, but the cost of the
high-end simulators has always been a turn-off -- especially if you
use linux as your primary development environment, the per-seat fees
can become unreal. I do a lot of FPGA/embedded consulting for small
university spin-off companies, and saying "before we get started you
have to spend $40k on tools" is often a deal-breaker.
Thanks again, xilinx!
...Eric
Article: 117079Paul, OK, we will again go back to our respective corners, and work harder to add value to our customer's systems. I hope this thread was educational, and entertaining to all. I still wonder how you got such an odd fruit basket: chokeberry, loquat, fig...Almost seems like there is a hidden message in there. The lemons and the prunes? Medlar? Raspberry? Wow. I had to find the pictures on line to identify some of this stuff. Ah, now I get it! I see currants! Lots of lots of currants. It's a fruit 'pun' basket! Excessive "currants." Very funny! I'll figure the other ones out later. AustinArticle: 117080
Luzerne <luzerne.ganhir@gmail.com> wrote: > On 25 fév, 02:22, Michael Gernoth <m...@gernoth.net> wrote: ... > > [...] > > Please report back if this library is useful and works for you. > > [...] Just to add another positive feedback : * It works like a charm for me ! * I find it very usefull ! My configuration : * OS : Suse 10.2 * cable : Home brewed parallel cable III derivat * Xilinx Tool : ISE Webpack 9.1 SP02 * programmed chip : XC95XL72 Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 117081
Have you looked at ActiveHDL? It is a very powerful tool and certainly costs a few times less than $40K even with swift model support (required for PPC/MGT simulation). Haven't looked at linux support though. Again, IMHO Xilinx should only then allow themselves getting into simulator business when they have brought MAP and PAR to the point of perfection. This has to be the main focus of their software development team (well maybe EDK as well) simply because with everything else we have at least some choice... /Mikhail <jonas@mit.edu> wrote in message news:1174592350.630766.248140@e65g2000hsc.googlegroups.com... > On Mar 22, 2:45 pm, <steve.l...@xilinx.com> wrote: > > Wow, this is the best news I've seen in 2007. I've always wanted to > play with the "neat" high-end xilinx components, but the cost of the > high-end simulators has always been a turn-off -- especially if you > use linux as your primary development environment, the per-seat fees > can become unreal. I do a lot of FPGA/embedded consulting for small > university spin-off companies, and saying "before we get started you > have to spend $40k on tools" is often a deal-breaker. > > Thanks again, xilinx! > ...Eric >Article: 117082
Herbert Kleebauer wrote: > cs_posting@hotmail.com wrote: > >>On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote: > > > >>Is this an engineering major's course or some sort of survey thing? > > > These are not electrical engineering but computer science students. > Their job will be to design software and not hardware systems. But > in order to do a proper software design, you need to understand the > principles of the underlying hardware so you get a feeling what a > few lines of HL code can mean for the hardware. Ah - CS students. I can understand that Schematics look more like HW, and importantly, to a CS student, it does not look like Software. (even tho is is, long before it hits the FPGA) I've also seen CS tutors use 8 bit Microcontroller simulators/ICE systems to teach the basics. Little devices like 8051/PIC, where you can see each opcode and port pin change. For 'real iron' stuff, that is cheap and easy to 'see the opcodes', try this http://www2.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/USBToolStick.htm > > I don't know if all the supporters of VHDL/Verilog/HandleC here have > done low level logic development using a graphical representation and > just don't recognize how important that is to become a good designer > at VHDL level or if they have never done this and still think they > are good developers because the VHDL compiler is good enough and > therefore they don't need to know anything about lower levels. That was why I suggested a _lower_ level language, such as CUPL or ABEL, and a CPLD. Think of these as the assemblers of the HDL world. > Again the city map is a good example: If you want to drive from > A to B, you call a taxi, the driver enters the target into the > navigation system and this system mostly does a much better job > you could do with the city map on your lap. So this is the best > you can do if you know nothing about the city. But if you know > the layout of the city and you know that there is a river with > only two bridges where you have to wait a long time because of > the high traffic and you also know that there is a small bridge > which could only be passed by foot, then you could do a much > better job by driving to the small bridge, cross the river by foot > and use an other taxi on the other side. > > The same is true for software: if you know how the hardware > works you maybe can choose a different approach to solve the > problem which is much more appropriate for the hardware. The > compiler can do local optimizations extremely good, but the > best global strategy has to be chosen by the programmer. > And I think the same is true for hardware design. Just writing > down VHDL statements without understanding the consequences > for the generated hardware is not the way to go. Absolutely agreed. If you do not know how the design maps onto the HW, you are only doing half a job. Which is why the .FIT reports are so important. You can see every gate, and product term _actually used_ in these, and we have given Atmel much feedback to make these reports clearer, and more useful to the design process. > > The purpose of Universities is not to teach the students the > use of tools but to teach them how to recognize, analyze and > solve problems. The tools you use to solve the problems change > rapidly but the ability to understand the source of a problem > and analyze it from all angeles without using blinders is an > essential requirement for the whole life. > > And as I said in the original posting, replacing the schematic > entry by VHDL/Verilg isn't an alternative. All I wanted to know > is, if somebody already was able to run the old Vielogic (DOS) > on an actual OS (using a virtual machine). Or, whether there > exists new FPGA's with a development system which is as easy > to use as Viewlogic/DOS [*] _AND_ where the chips are available > in a package which could be soldered with a normal soldering > iron on a self made non-multilayer PCP. I think there are > both things available, but I didn't find the _AND_ combination. [*] Even this first one could be a struggle! - see other threads on XST, and users experiences with the SCH flows of that. You could also get a copy of this http://www.diodes.com/anachip/winplace/index.php and see if that is Graphical/Schematic enough for your needs. I'd call it quasi-sch in form, in some areas of operation, not a full SCH, but it looks more like HW than SW in some views. -jgArticle: 117083
Hello, I am trying to get the Virtex-4 Ethernet MAC Wrapper IP Core up and running on my Avnet Virtex-4 FX12 Mini Module (http://tinyurl.com/ yqc6ah), and I am having all sorts of problems. One of the main problems right now seems to be my understanding of the UCF file and what to edit or not to edit, since the rest of the design should be already set up fine from what I have read in the user guide. I am trying to run the example design that was generated,so that I may send the board a packet and it send me one back to make sure everything is working correctly, but so far no luck. Has anyone used this ip core before with some successes , no matter what version? Please let me know if so... it would be greatly appreciated! -Mark (I can post or upload as many details/files as requested, but I didnt want to just spam all that stuff up here on the first post)Article: 117084
Here are a few more details about the project of getting this core up and running: Using the GMII Interface, in trimode I am trying to keep this project inside of ISE , and not use EDK for anything at the moment. The only changed I made to the UCF so far would be the LOC assignments of the RX/TX Signals and with the IDELAYCTRL location. I am still looking more into the IDELAYCTRL location that I should be using since this part is still pretty new to me and I haven't done much work with constraints past basic pin assignment. As well, if anyone know any good sites that go over the constraints used in these UCF files, please let me know. I do already know about Xilinx's scattered PDF files on their site which for me at least do not always tend to be that clear, so anything other than those (such as some .edu site with lab handouts, etc) would be great! Thanks again, -Mark On Mar 22, 5:31 pm, mwiesb...@gmail.com wrote: > Hello, > > I am trying to get the Virtex-4 Ethernet MAC Wrapper IP Core up and > running on my Avnet Virtex-4 FX12 Mini Module (http://tinyurl.com/ > yqc6ah), and I am having all sorts of problems. One of the main > problems right now seems to be my understanding of the UCF file and > what to edit or not to edit, since the rest of the design should be > already set up fine from what I have read in the user guide. > > I am trying to run the example design that was generated,so that I may > send the board a packet and it send me one back to make sure > everything is working correctly, but so far no luck. > > Has anyone used this ip core before with some successes , no matter > what version? Please let me know if so... it would be greatly > appreciated! > > -Mark > (I can post or upload as many details/files as requested, but I didnt > want to just spam all that stuff up here on the first post)Article: 117085
"Ken Soon" <csoon@xilinx.com> writes: > "Duane Clark" <junkmail@junkmail.com> wrote in message > news:aITLh.15$rO7.4@newssvr25.news.prodigy.net... > > Ken Soon wrote: > > > ... > > > Yeh for the hardware multipliers, I guessed it automatically changed the > > > DSP48s to the multipliers, but alas, shortage problems again. 60 > mulitpliers > > > needed for 36 available. > > > > Analyze the design a bit; 60 multipliers sounds like a lot, though I > > have not done video work. Maybe you don't need all of them, or maybe > > some are being used to multiply small numbers that could be handled in > > LUTs. If some of the multipliers are only doing a multiply every 2 or 3 > > or 4 clocks, maybe some could be shared. > > That's a good idea of sharing the multipliers. Hmm I just have to figured > out though. > > I will be using the DRAM controller found on the Xilinx website > since I am working on the Spartan 3E, make things a little less > tricky, ya. <snip> Could you provide a pointer to that DRAM controller? thuttArticle: 117086
"Paul Leventis" <paul.leventis@gmail.com> wrote in message news:1174582679.963800.214550@p15g2000hsd.googlegroups.com... > Hi John, > > I'm no RAM designer, but I'll give it a shot... <snip very decent description> > Hope this helps, > > Paul Leventis > Altera Corp. Thanks for taking the time, Paul. I've gotten down to the gate level for many things in my past but I guess I never had the need to look deep enough into SRAMs and I certainly didn't get it in my college work. Though I know about the half-voltage precharge for bit lines, I though that was for non-SRAM technologies and never saw a need to delve into it. Async SRAMs needed both read and write *strobes* didn't they? My mindset was along the lines of the cute little distributed RAMs in the other FPGAs - nice multiplexed outputs - no bit lines to worry about and instant output change for an address change. I managed to find a couple nice presentations googling for "6 transistor cell" to get the SRAM details. I'm just sad it took me this long to know the innards! - John_HArticle: 117087
On Thu, 22 Mar 2007, John_H wrote:
> I know the EXCEPT can be used to define timing groups but I'm not sure about
> the TNM_NET. I'd be interested to see if
>
> NET myclk TNM_NET = EXCEPT PADS(*) myclk;
> or
> NET myclk TNM_NET = ALL EXCEPT PADS(*) myclk;
>
> works. I think ALL may be a proper keyword but I forget the details.
Tried both of the above - no go:
ERROR:NgdBuild:765 - "foo.ucf" Line 40: A parsing error has occurred while
reading the constraint file. The value 'EXCEPT' at column 22 is
invalid.
> Personally, I don't push my clocks directly out onto pads (I'll run them
> though an ODDR2 primitive first) so I don't end up seeing the warnings.
My constraint is on an input clock. The differential inputs go directly
into a clock control module which instantiates IBUFDS and feeds it to some
DCMs. So at the top level the input pad signal is the only one which will
propagate the constraint through the DCMs.
> The syntax
>
> NET myclk TNM_NET = FFS(*) LATCHES(*) MULTS(*) RAMS(*) myclk;
>
> (and any othere synchronous elements I've forgotten) is another approach
> that should work.
No such luck:
ERROR:NgdBuild:765 - "foo.ucf" Line 40: A parsing error has occurred while
reading the constraint file. The value 'LATCHES' at column 30 is invalid.
So it seems that the only way to get rid of the warnings would be to pull
the IBUFDS to the top level and place the TNM_NET on its output.
--
Dmitry Teytelman
Article: 117088On Mar 22, 5:55 am, "Xuan Binh" <xbinhdt4...@gmail.com> wrote: > when I download bitstream to Xsa3s1000 board by impact (I load > p3jtag.svf file to CPLD by GLoad and setting jump as the instruction > fromXessbefore) it run ok.But when i plug Xsa3s1000 to XST3.0 > extent board , i can't download the bitstream by impact, the error is > "CRC check error".is there any one can help me to solve this > problem.Thanks a lot! Are you downloading the same bitstream in both cases? With iMPACT, you can repeatedly read the IDCODE of the FPGA chip. Does this read back the correct IDCODE for the Spartan3 FPGA on the XSA-3S1000 (IDCODE = 11428093)? Is the IDCODE always the same value? If so, this would appear to rule out a hardware problem with the JTAG interface. There are more users to help you with this if you post your question at the xsboard users forum. You can sign-up for the forum at www.xess.com.Article: 117089
Austin Lesea wrote: > Paul, > > OK, we will again go back to our respective corners, and work harder to > add value to our customer's systems. > > I hope this thread was educational, and entertaining to all. > > > I still wonder how you got such an odd fruit basket: chokeberry, loquat, > fig...Almost seems like there is a hidden message in there. > > The lemons and the prunes? Medlar? Raspberry? Wow. I had to find the > pictures on line to identify some of this stuff. > > Ah, now I get it! I see currants! Lots of lots of currants. It's a > fruit 'pun' basket! > > Excessive "currants." > > Very funny! > > I'll figure the other ones out later. > > Austin Don't forget to thank Ricky Sticky, whose suggestion made this all possible !! :)Article: 117090
Mark, Which core exactly are you talking about? I have successfully used ll_temac EDK core, although I had to tweak it somewhat to implement RGMII interface. This might be already done in the latest revision though. Also, my design was based on the GSRD reference design. /Mikhail <mwiesbock@gmail.com> wrote in message news:1174600404.051325.276560@p15g2000hsd.googlegroups.com... > Here are a few more details about the project of getting this core up > and running: > > Using the GMII Interface, in trimode > I am trying to keep this project inside of ISE , and not use EDK for > anything at the moment. > The only changed I made to the UCF so far would be the LOC assignments > of the RX/TX Signals and with the IDELAYCTRL location. I am still > looking more into the IDELAYCTRL location that I should be using since > this part is still pretty new to me and I haven't done much work with > constraints past basic pin assignment. > > As well, if anyone know any good sites that go over the constraints > used in these UCF files, please let me know. I do already know about > Xilinx's scattered PDF files on their site which for me at least do > not always tend to be that clear, so anything other than those (such > as some .edu site with lab handouts, etc) would be great! > > Thanks again, > -Mark >Article: 117091
On Mar 16, 10:07 am, "Bob Golenda" <bgoli...@nospam.net> wrote: > > > This is using XSVFPlayer? How many M Bytes is the file? Don't you have > > > to > > > actually do an output of the file and record that, and then use > > > XSVFPlayer? > > > We don't really care much about how big is the file as it gets downloaded > > from an external server when needed and the whole purpose of this is a > rare > > in-field hardware upgrade. > > Ah, OK. Unfortunately, we care about: > > 1) how big the code it self is...so it fits in the XCF > 2) how big the data is, as it has to fit in available memory > 3) programming speed > > So, it doesn't seem like the XSVF player solution will work for us. That's > why I asked about straight JTAG programming, which it seems like no one has > actually done and gotten working. > > Thanks! I've done it! You don't have to implement the whole xsvfplayer. If you want to support only xcf devices in a fixed environment, the programming is fairly simple. It can be implemented from a tiny uC, or the softcore uBlaze through GPIO! ZoltanArticle: 117092
steve.lass@xilinx.com wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message > news:46020799$1@clear.net.nz... > >>Thanks Steve, - can you comment on the relative effort/quality of the HDL >>branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST >>Simulator (relative to Modelsim et al ) ? >> >>-jg > > > The effort going into VHDL and Verilog is about the same. ABEL is in > maintenance mode so only gets attention when serious bugs are reported. Thanks. I should have queries Schematic flow as well ? as some still use that (see another thread..) - is that in maintenance mode as well ? Of course, maintenance mode can be a good thing, because it means the code-base is very stable, with no surprises lurking in the next updates.... :) -jgArticle: 117093
Dmitry Teytelman wrote: > Hello Daniel, > > On Thu, 22 Mar 2007, Daniel S. wrote: > >> Would the unimportant warnings in question happen to be the one about >> PAR/MAP getting confused between PAD and IOB FFs timing constraints? I >> am glad I saw this thread because I was about to make the very same >> mistake to get rid of those warnings too! > > I added FFS(*) to the constraint to get rid of the following warning in > the translation report: > > WARNING:XdmHelpers:662 - Period specification "TS_clk_ctrl_aclk4_dcm" > references the TNM group "clk_ctrl_aclk4_dcm", which contains both pads > and synchronous elements. The timing analyzer will ignore the pads for > this specification. You might want to use a qualifier (e.g. "FFS") on > the TNM property to remove the pads from this group. Yup, that is the annoying warning I was thinking about. I wish there was a simple timespec for everything except pads... everything synchronous. From other replies in this thread, it seems like the only way is exhaustive enumeration.Article: 117094
here ya http://www.xilinx.com/products/design_resources/mem_corner/resource/xaw_dram_ddr.htm "Taylor Hutt" <thutt151@comcast.net> wrote in message news:m3hcsdos3x.fsf@localhost.localdomain... > "Ken Soon" <csoon@xilinx.com> writes: > > > "Duane Clark" <junkmail@junkmail.com> wrote in message > > news:aITLh.15$rO7.4@newssvr25.news.prodigy.net... > > > Ken Soon wrote: > > > > ... > > > > Yeh for the hardware multipliers, I guessed it automatically changed the > > > > DSP48s to the multipliers, but alas, shortage problems again. 60 > > mulitpliers > > > > needed for 36 available. > > > > > > Analyze the design a bit; 60 multipliers sounds like a lot, though I > > > have not done video work. Maybe you don't need all of them, or maybe > > > some are being used to multiply small numbers that could be handled in > > > LUTs. If some of the multipliers are only doing a multiply every 2 or 3 > > > or 4 clocks, maybe some could be shared. > > > > That's a good idea of sharing the multipliers. Hmm I just have to figured > > out though. > > > > I will be using the DRAM controller found on the Xilinx website > > since I am working on the Spartan 3E, make things a little less > > tricky, ya. > > <snip> > > Could you provide a pointer to that DRAM controller? > > thuttArticle: 117095
Hi John, > Async SRAMs needed both read and write *strobes* didn't they? Sounds familiar, but then again, we're well past my knowledge of RAMs too :-) > My mindset was along the > lines of the cute little distributed RAMs in the other FPGAs - nice > multiplexed outputs - no bit lines to worry about and instant output change > for an address change. Distributed RAM architectures are interesting. A LUT is after all just an asynchronous ROM, so you get your read-path for free when you want to use a LUT as a memory. The problem is the write path. Specifically, where do you get your write data and address from (since you're using the normal LUT inputs as the read address)? How much hardware do you need to add to the LUT to make the bits dynamically writeable? If you want to have registered access, where do you get the registers from? Stratix III introduces the capability to convert some LABs (collections of LEs) into simple dual-port (1R/1W) 10x64 or 20x32 bit RAMs. Half the LABs (the "MLABs") have this capability. Why do we convert an entire LAB? The main reason is to ammortize the overhead of some of the extra circuitry and write address logic over more LEs. Plus it is rare for people to need many independent narrow (x1, etc) RAMs, so in practice converting an entire LAB isn't a big deal. The extra inputs on the Stratix III ALM (8 inputs) meant we didn't need to add more routing area to get the extra RAM signals into the block, which was kind of nice. One downside of all distributed RAM architectures is that when you assemble larger (logcial) RAMs out of smaller (physical) RAMs, you are using the programmable routing and other circuitry to do so. This can increase the power per bit when compared to a dedicated RAM block. Regards, Paul Leventis Altera Corp.Article: 117096
Few doubts I would like to get clarified, 1. Weather synchronizers are required for control signals only or for data signals also? 2. Internal to FPGA, suppose 2 different clock domains are there - do signals crossing from one clock domain to another need synchronizers? or can we avoid synchronizers by applying some constraints? If yes, what are these contraints(in xilinx)? 3. How can we decide on a false path? suppose one signal is crossing from one clock domain to another can be declared as a false path? 4. Is it OK to have negative hold time(<1 ns) in timing report? can we ignore this timing violation safely? 5. What is the difference between clock jitter & clock skew? With Xilinx DCMs, I need Clk2x, Clk2x<180, Clk2x<270 & Clk4x. So, with no other option, I am going for cascaded DCMs. In this kind of situations, what best we can do to avoid/minimize clock skew problems? Regards, JKArticle: 117097
MM wrote: > <steve.lass@xilinx.com> wrote in message > news:etubki$kv11@cnn.xsj.xilinx.com... > >>There seems to be an infinite number of things our users can implement >>in an FPGA so it's impossible to find every bug. > > > It might be impossible to find every bug, but surely you can at least make > error messages more informative. Also, I am not necessarily talking about > bugs. IMHO there is a problem with the underlying algorithms as well.... > > >>However, less than 15% >>of the map and par bugs are found by customers and we continue to try to >>lower that number. > > > I am afraid other 85% simply don't get reported. Ask your users how many of > the fatal or portability errors that they experienced they have actually > reported? > > >>In 7.1i, we replaced our database and took a hit for map and par quality. >>Since then, we have improved considerably, and have made quality the >>highest priority for 9.1i and future releases. Other priorities for map >>and >>par are new device support, QOR, runtime, incremental design and >>partial reconfiguration. > > > In my experience until the device is approximately 50% full the tools work > more or less OK. If they crash I can usually pretty quickly find a different > combiantion of options, which will make the design pass. However, as the > device gets more and more full the issues with the tools become increasingly > more difficult to deal with. I guess in part it is simply a function of the > compile time. But in part it is definitely the tools behave less > predictable. > > I think I won't be the first to say postpone any GUI work, any work on new > features and concentrate on giving us truly robust and efficient back-end > tools. > > > /Mikhail > > > > > > I would second the comment on the gui work. The progress has been downhill since 6.3. They seem to use the new programmers on the gui to get experience. There also seem to be a lot of changes for the sake of change. It would be nice to get the bugs out before going after a lot of new features. I know that the software guys like putting in new features and hate fixing bugs but, those of us on the firing line would prefer the bug fixes.Article: 117098
Hi everybody!
I felt in a very strange situation: I'm working with an FPGA BOARD:
-2 Virtex-4LX
-1 Quick LVDS bus between the 2 FPGAs.
-1 INPUT from an external board.
-1OUTPUT to the same external board.
I use for these quick interfaces ChipSync (Local clocking ressources
+ISERDES+OSERDES).
When I make my tests for the internal bus (the connection between the
2 FPGAs) I have no problems: >1Gb/s for each LVDS line.
Since the external board is not yet ready to use, I use a small
loopback board to connect the output of my board to the input of the
same boad (the FPGA board). This board INVERTS LVDS PAIRS ie: if I
have an output {XP,XN} I get the input {XN,XP}. ({A,B}=A on P pin and
B on N pin).
When I make the same tests it doesn't work even on small frequencies.
and the use of IDELAY DOESN'T HELP.
Please help me
Mehdi
Article: 117099
When I am sending some frame from the PC to MAC implemented in the
ML-402 board, It receives the whole frame with proper data, but not
able to calculate FCS properly and generate a error signal for it.
Same thing happen in case of Transmission also.
can anyone suggest how to impletement CRC and generate a FCS, and
in what order we have to send frame to calculate it?
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