Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 10/16/2012 3:24 PM, Andrew Holme wrote: > I'm working on a Virtex 5 project containing a 13-stage pipeline clocked > at 200 MHz. The data path gets quite wide in the latter stages; but > only 11% of available slices are used; so the FPGA is relatively empty. > Every other step in the build process rips through quickly, except the > above named MAP stage, which accounts for 98% of total build time. > Routing is over in a flash, and the result meets timing. I would like > to reduce the build time and I was wondering how to go about it. One > idea was to create LOC constraints on logic, perhaps based on where the > tools themselves placed it after a previous optimization run. Any other > suggestions? > > TIA > For Virtex 5 and newer parts, Map always places the design as well as mapping into slices, so "PAR" really only routes. You should expect map to take the longest time of the processes. If your pipeline is not hand-optimized and requires register-balancing, then map may be spending a lot of time on that (physical synthesis), and using LOC constraints might not help much for execution time. An easy way to try the LOC idea without a lot of effort is to use "guided" placement. This normally works best when you make only small mods to the design between runs. It essentially tries to LOC everything where it was in the prior "golden" run. The problem is when you make enough changes that very little of the design keeps its prior instance names. -- GaborArticle: 154376
On 16/10/2012 18:39, Rob Gaddi wrote: > Alright, I've got to fess up. I'm lost as to the point of .do files. > They seem to suffer through all of Tcl's wacky syntax, but with the > added benefit of not giving you access to the standard Tcl commands. > > Am I missing something here? Yes, Tcl and do files are the same with the exception of some error (onerror/onbreak) and breakpoint handling. Hans www.ht-lab.com Or is the entire point of the exercise > that Tcl is considered to be intimidating, whereas a proprietary macro > language is not? >Article: 154377
On Tue, 16 Oct 2012 10:39:51 -0700, Rob Gaddi wrote:
> Alright, I've got to fess up. I'm lost as to the point of .do files.
> They seem to suffer through all of Tcl's wacky syntax, but with the
> added benefit of not giving you access to the standard Tcl commands.
>
> Am I missing something here? Or is the entire point of the exercise
> that Tcl is considered to be intimidating, whereas a proprietary macro
> language is not?
There is no difference between a .do and a .tcl file, in the sense
that Modelsim doesn't really care what the filename is.
Modelsim uses the one Tcl interpreter for everything.
(BTW, you should have access to all of Tcl's wacky commands, albeit
possibly an older version of Tcl.)
What matters is how you call it:
source filename
vs
do filename
There are a few differences that I have discovered in my
scripting travels:
- error (onerror/onbreak) and breakpoint handling
(as mentioned in Hans' post).
- [info script] returns a null string in a do script
whereas it does the normal thing (returning info about
the script) when "sourced".
The last point matters if you are writing "location idependent"
code, e.g.
# converts a path relative to the script being run into an absolute one.
proc file_rel2abs {path} {
if { [ string length [ info script ] ] > 0 } {
return [file normalize [file join [file dirname [info script]] $path ] ]
} else {
error "use source rather than do"
}
}
Regards,
Allan
Article: 154378On 14 Okt., 01:26, Frank Buss <f...@frank-buss.de> wrote: > Jon wrote: > > A red signal means you have an X - an unknown value. Probably > > something not being reset, or you have multiple drivers, driving > > different values to the same signal. > > Is it possible to synthesize multiple drivers? When I try this in VHDL, > it is an error and it doesn't synthesize the design. Maybe with some > "inout" or "buffer" ports? General spoken it is possible (and in rare cases intended) , as long as you use std_logic instead of std_ulogic. Wheter the technology or synthesis tool supports multiple drivers is another question. bye ThomasArticle: 154379
On 13 Okt., 18:48, Jon <j...@beniston.com> wrote: > A red signal means you have an X - an unknown value. Probably something not being reset, or you have multiple drivers, driving different values to the same signal. Red in modelsim for std_(u)logic and predefined setting means either U or X or W. U = uninitialised (signal not driven up to now, forgot reset?), X = Unknown (Eg two driver). W = weak unknown (if H and L drive the same signal, but no 1 or 0 driver). For vectors the vector will be red, if one bit is red. bye ThomasArticle: 154380
Rob Gaddi wrote: > > I'm lost as to the point of .do files. <snip> > Am I missing something here? > Mentor's .do file syntax predates tcl. I first used .do files on Apollo workstations running Mentor V6 simulators (Quicksim IIRC) in the mid-late 80's. ModelTech then adopted a similar (if not identical) command file syntax when they launched the low-budget V-System(?), well before they were acquired by Mentor. -BrianArticle: 154381
I have to connect a dual 12-bit ADC with serial LVDS outputs (2-lanes per converter) to a spartan 6 FPGA. It would be ideal if I can use a single HDMI connector for this. The converters I'd like to use are the ADS6224 or ADC12S105, running at 100 MHz sample rate. They have 6 data LVDS data outputs: 4 data lines, 1 frame clock and 1 bit clock. Since the HDMI connection only has 5 differential pairs (including the HEC data lines) I had the idea to not connect the bit clock, but instead use the FPGA's DCM to reconstruct the bit clock from the frame clock. Any comments on this idea? Could that work? Thanks, ThomasArticle: 154382
On Oct 18, 5:14=A0pm, Thomas Heller <thel...@ctypes.org> wrote: > I have to connect a dual 12-bit ADC with serial LVDS outputs (2-lanes > per converter) to a spartan 6 FPGA. =A0It would be ideal if I can use > a single HDMI connector for this. > > The converters I'd like to use are the ADS6224 or ADC12S105, running at > 100 MHz sample rate. =A0They have 6 data LVDS data outputs: 4 data lines, > 1 frame clock and 1 bit clock. > > Since the HDMI connection only has 5 differential pairs (including the > HEC data lines) I had the idea to not connect the bit clock, but instead > use the FPGA's DCM to reconstruct the bit clock from the frame clock. > > Any comments on this idea? =A0Could that work? > > Thanks, > Thomas I think it could work, it would be similar to camera-link -LasseArticle: 154383
Hi, I'm run out of M9K resources on a design while logic is less than 15% used... and I have a few components in the design with small pipelines etc that compiler infers RAM and I don't want to. What should I do to force QuartusII to use registers in those places where using m9K is not desirable ? Thanks. Luis C.Article: 154384
Hi, I would like to ask for some input. When this device is in JTAG reset state, how does it drive the outputs, hi-Z, 1'b0, 1'1b1, or unpredictable? Thx, Dtrang --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154385
Hello! I read that the MPMC memory controller sends automaticly (1us period) periodic read request to the DDR3 module to measure the phase detection. (http://www.xilinx.com/support/answers/36719.htm -> Disabling Periodic Reads During Writes) I don't understand, that if the module is red in every 1us, than why is a refresh logic implemented in the mpmc module? I think with every read the content of a memory cell is refreshed. In my work I want to measure memory retention time. I have modified the refresh logic of the MPMC module. I have set non JEDEC refresh times, to get memory data loss. However I tested my system on a Virtex 6 board, and at very large refresh period, the written data in the memory remains, without any loss. Thank you for the answers! Walter --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154386
>Hi, > >I'm run out of M9K resources on a design >while logic is less than 15% used... and I have a few components >in the design with small pipelines etc that compiler infers RAM and I >don't want to. > >What should I do to force QuartusII to use registers in those places where >using m9K is not desirable ? > >Thanks. > >Luis C. > > tell it by using keep attribute on those registers. Quartus gets really silly sometimes inferring ram for few registers. Kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154387
>>Hi, >> >>I'm run out of M9K resources on a design >>while logic is less than 15% used... and I have a few components >>in the design with small pipelines etc that compiler infers RAM and I >>don't want to. >> >>What should I do to force QuartusII to use registers in those places >where >>using m9K is not desirable ? >> >>Thanks. >> >>Luis C. >> >> >tell it by using keep attribute on those registers. Quartus gets really >silly sometimes inferring ram for few registers. > >Kaz > >--------------------------------------- or set auto ram inference for shift registers off in compiler settings kaz --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154388
Hello, Anybody have any idea how much longer the Spartan 3A will be in production? I'm hoping a good while, yet, as it appears to be the cheapest modest-size FPGA from Xilinx right now, about $8 for the XC3S50A in the TQFP144 package. Thanks much in advance, JonArticle: 154389
>>> >>> >> tell it by using keep attribute on those registers. Quartus gets really >> silly sometimes inferring ram for few registers. >> >> Kaz >> >> --------------------------------------- > > or set auto ram inference for shift registers off in compiler > settings > > kaz > Thanks, Kaz. I'll be using the keep attribute. No chance to switch it all off, there are places where I do need ram. Great help. tks. Luis C.Article: 154390
On Saturday, January 1, 2011 7:26:57 PM UTC+1, luudee wrote: > It seems this issue is coming up again and again, with each new ISE > release. > > I am running Fedora 14, x86_64, and installed ISE 12.4. > > And of course the platform USB cables stopped working ... > > libusb is installed, and the drivers are installed .... > > but impact is giving me this: > ....... > AutoDetecting cable. Please wait. > If you are using the Platform Cable USB, please refer to the USB Cable > Installation Guide (UG344) to install the libusb package. > Connecting to cable (Usb Port - USB21). > Checking cable driver. > Linux release = 2.6.36.2.RU1. > WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the > cable > drivers. See Answer Record 22648. > Cable connection failed. > Connecting to cable (Parallel Port - parport0). > Linux release = 2.6.36.2.RU1. > WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the > cable > drivers. See Answer Record 22648. > Linux release = 2.6.36.2.RU1. > WARNING:iMPACT - Module parport_pc is not loaded. Please reinstall > the cable > drivers. See Answer Record 22648. > Cable connection failed. > > > Any ideas or suggestions ??? > > Thanks, > rudi HI, System recognises th USB , and but whenever a want to do Cable AutoConnect it comes WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable drivers. See Answer Record 22648.Article: 154391
use strace to check where impact searches libusb.so (e.g. /lib or /lib64) you may also need to create symlinks from libusb-[version].so to libusb.so because the Xilinx tools only search for the libusb.so (without version). HTH rndhro On 10/22/2012 01:58 PM, adnan.kuleta@gmail.com wrote: > On Saturday, January 1, 2011 7:26:57 PM UTC+1, luudee wrote: >> It seems this issue is coming up again and again, with each new ISE >> release. >> >> I am running Fedora 14, x86_64, and installed ISE 12.4. >> >> And of course the platform USB cables stopped working ... >> >> libusb is installed, and the drivers are installed .... >> >> but impact is giving me this: >> ....... >> AutoDetecting cable. Please wait. >> If you are using the Platform Cable USB, please refer to the USB Cable >> Installation Guide (UG344) to install the libusb package. >> Connecting to cable (Usb Port - USB21). >> Checking cable driver. >> Linux release = 2.6.36.2.RU1. >> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the >> cable >> drivers. See Answer Record 22648. >> Cable connection failed. >> Connecting to cable (Parallel Port - parport0). >> Linux release = 2.6.36.2.RU1. >> WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the >> cable >> drivers. See Answer Record 22648. >> Linux release = 2.6.36.2.RU1. >> WARNING:iMPACT - Module parport_pc is not loaded. Please reinstall >> the cable >> drivers. See Answer Record 22648. >> Cable connection failed. >> >> >> Any ideas or suggestions ??? >> >> Thanks, >> rudi > > HI, > System recognises th USB , and but whenever a want to do Cable AutoConnect it comes > > WARNING:iMPACT - Module windrvr6 is not loaded. Please reinstall the cable drivers. See Answer Record 22648. >Article: 154392
Hello Marek, Can you explain what you exactly did in your design, so you succefully can compile a VHDL with an EDN file? I have an edn top design, created by presicion, and a UART VHDL core of Actel, which I need to complie them both in my design. Thank you in advanced, Moran. >Hello, Daniel, > >> There are some challenges in merging EDIF netlists with Designer upon >> import. I would let Synplify do the merging for you. Just have your >> netlist in VHDL format and add it as an other source file. You can use >> the edn2vhdl tool to create the VHDL netlist. > >thank you for your answer. This is the problem: I need to bypass >synthesis step, since I am afraid, that some evil optimization could >damage my design. Even if it would work one, I have no guarantee, that >in next Synplify release it will result in exactly the same output >netlist. > >However, I have been told the solution by Actel technical support, so >I am forwarding the reply: >----- >From Sagar.Gosavi@microsemi.com Tue Jan 4 10:51:54 2011 >Date: Tue, 4 Jan 2011 15:21:54 +0530 >From: "Gosavi, Sagar" <Sagar.Gosavi@microsemi.com> >To: Marek Peca >Subject: RE: Actel Designer: how to compile VHDL top & EDIF submodule >together?: >489394-344304373 > >Hi Marek, > >Thanks for contacting Actel Tech Support. > >Can you please send me the design files for this project so that I >can understand the scenario better? > >Between, if I understand the situation; are you observing some errors >like: > >Error: CMP002: Net: CNT_16[0] is not driven >Error: CMP002: Net: CNT_16[1] is not driven >Error: CMP002: Net: CNT_16[2] is not driven >Error: CMP002: Net: CNT_16[3] is not driven > >Also, if you find syn_black_box in your top level edn, kindly replace >it with the instance name of your subcircuit edn. > >Note: The library name, cell name and the view name of the lower >level cell/edn has to match in its instantiation in the upper (in >this case, the top level) level > >If above solution doesn't help, please send me your Project, so that >I can debug this issue better. > >Have a great day ahead! > >Thanks and Regards, >Sagar Gosavi >----- > >So I have changed the library name to "work" and view name to >"syn_black_box" and now it works as expected, the Designer now >produces reasonably looking composite netlist. The EDIF excerpt looks >like: > > (library work > (edifLevel 0) > (technology (numberDefinition)) > (cell my_strange_circuit > (cellType GENERIC) > (view syn_black_box (viewType NETLIST) > >...etc. > > >Greetings, >Marek > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154393
On Oct 20, 7:58=A0pm, Luis Cupido <cup...@ua.pt> wrote: > >> tell it by using keep attribute on those registers. Quartus gets reall= y > >> silly sometimes inferring ram for few registers. > > >> Kaz > > >> --------------------------------------- > > > or set auto ram inference for shift registers off in compiler > > settings > > > kaz > > Thanks, Kaz. > > I'll be using the keep attribute. > > No chance to switch it all off, there are places where I do need ram. > > Great help. tks. > > Luis C. Keep attribute will typically produce non-optimal result. May be, you don't care. But if you do care, then go to all paces where you do need RAM and infer it explicitly via altsyncram, dcfifo, scfifo or other appropriate Altera primitives. After that nothing will prevent you from switching off global "auto ram replacement" option. In .qsf file: set_global_assignment -name AUTO_RAM_RECOGNITION OFFArticle: 154394
On Thursday, October 18, 2012 10:14:05 AM UTC-5, Thomas Heller wrote: > I have to connect a dual 12-bit ADC with serial LVDS outputs (2-lanes per= converter) to a spartan 6 FPGA. It would be ideal if I can use a single HD= MI connector for this. The converters I'd like to use are the ADS6224 or AD= C12S105, running at 100 MHz sample rate. They have 6 data LVDS data outputs= : 4 data lines, 1 frame clock and 1 bit clock. Since the HDMI connection on= ly has 5 differential pairs (including the HEC data lines) I had the idea t= o not connect the bit clock, but instead use the FPGA's DCM to reconstruct = the bit clock from the frame clock. Any comments on this idea? Could that w= ork? Thanks, Thomas For that to work, the frame clock from the ADC must be continuous with no g= aps or phase changes between output words. Otherwise, the PLL will not be a= ble to lock on instantly to each word. You will also not be able to read th= e first several (tens/hundreds/thousands of?) words from the ADC while the = PLL locks onto the frame clock. AndyArticle: 154395
On Monday, October 22, 2012 12:41:40 PM UTC-5, Michael S wrote: > On Oct 20, 7:58=A0pm, Luis Cupido <cup...@ua.pt> wrote: > >> tell it by u= sing keep attribute on those registers. Quartus gets really > >> silly some= times inferring ram for few registers. > > >> Kaz > > >> ------------------= --------------------- > > > or set auto ram inference for shift registers o= ff in compiler > > settings > > > kaz > > Thanks, Kaz. > > I'll be using th= e keep attribute. > > No chance to switch it all off, there are places wher= e I do need ram. > > Great help. tks. > > Luis C. Keep attribute will typic= ally produce non-optimal result. May be, you don't care. But if you do care= , then go to all paces where you do need RAM and infer it explicitly via al= tsyncram, dcfifo, scfifo or other appropriate Altera primitives. After that= nothing will prevent you from switching off global "auto ram replacement" = option. In .qsf file: set_global_assignment -name AUTO_RAM_RECOGNITION OFF Synplify has a "syn_ramstyle" attribute, which can take a value of "registe= rs". Maybe Q has something similar? "keep" would also keep the syntesis tool from optimizing out any registers = that are always written with a constant. AndyArticle: 154396
Jon Elson wrote: > Hello, > > Anybody have any idea how much longer the Spartan 3A will be > in production? I'm hoping a good while, yet, as it appears to > be the cheapest modest-size FPGA from Xilinx right now, about > $8 for the XC3S50A in the TQFP144 package. So, nobody has any ideas for about how long the Spartan 3A will be available? I'm just redoing a board to move up from the Spartan 2E. The Spartan 6 gives me no advantages at all, costs more, and needs a (much) bigger config ROM. JonArticle: 154397
On Wed, 24 Oct 2012 14:08:39 -0500 Jon Elson <jmelson@wustl.edu> wrote: > Jon Elson wrote: > > > Hello, > > > > Anybody have any idea how much longer the Spartan 3A will be > > in production? I'm hoping a good while, yet, as it appears to > > be the cheapest modest-size FPGA from Xilinx right now, about > > $8 for the XC3S50A in the TQFP144 package. > So, nobody has any ideas for about how long the Spartan 3A > will be available? I'm just redoing a board to move up from > the Spartan 2E. The Spartan 6 gives me no advantages at all, > costs more, and needs a (much) bigger config ROM. > > Jon I don't know anything anyone else doesn't, but it seems to me like Xilinx has been pretty clear that the targetting of the S3A and the S6 are very different; the S6 is meant to be a fundamentally higher end product that won't be competing in the sorts of pseudo-CPLD arena that the S3A does. And so I'd be shocked if they phased out the S3A any time soon; it seems like it would royally tick off a lot of volume customers. All that said, I don't know what the realignment to 3 lines instead of 2 that they're doing with the -7 series stuff means for all that; they may be positioning something in the Artix-7 line as the S3A killer. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154398
On 10/24/2012 3:08 PM, Jon Elson wrote: > Jon Elson wrote: > >> Hello, >> >> Anybody have any idea how much longer the Spartan 3A will be >> in production? I'm hoping a good while, yet, as it appears to >> be the cheapest modest-size FPGA from Xilinx right now, about >> $8 for the XC3S50A in the TQFP144 package. > So, nobody has any ideas for about how long the Spartan 3A > will be available? I'm just redoing a board to move up from > the Spartan 2E. The Spartan 6 gives me no advantages at all, > costs more, and needs a (much) bigger config ROM. > > Jon Yeah, I don't like the direction Xilinx is headed. I would have thought they might see that the old school philosophy of "bigger, faster, more expensive" might be coming to an end. But in the short term, I guess not. If you are looking for something that small for a new design, check out the Lattice parts, especially the iCE40 devices. They are VERY cost competitive, at least if the iCE65 devices are indicative. I got quotes for them at about $3. They don't have all the bells and whistles, but they do have OTP config memory. As to the S3 parts, Xilinx does have a track record of keeping old devices in production nearly forever. After some years the price may rise, but you won't have to respin your design because you can't get them. RickArticle: 154399
rickman wrote: > On 10/24/2012 3:08 PM, Jon Elson wrote: >> Jon Elson wrote: >> >>> Hello, >>> >>> Anybody have any idea how much longer the Spartan 3A will be >>> in production? I'm hoping a good while, yet, as it appears to >>> be the cheapest modest-size FPGA from Xilinx right now, about >>> $8 for the XC3S50A in the TQFP144 package. >> So, nobody has any ideas for about how long the Spartan 3A >> will be available? I'm just redoing a board to move up from >> the Spartan 2E. The Spartan 6 gives me no advantages at all, >> costs more, and needs a (much) bigger config ROM. >> >> Jon > > Yeah, I don't like the direction Xilinx is headed. I would have thought > they might see that the old school philosophy of "bigger, faster, more > expensive" might be coming to an end. But in the short term, I guess not. > > If you are looking for something that small for a new design, check out > the Lattice parts, especially the iCE40 devices. They are VERY cost > competitive, at least if the iCE65 devices are indicative. I got quotes > for them at about $3. They don't have all the bells and whistles, but > they do have OTP config memory. > > As to the S3 parts, Xilinx does have a track record of keeping old > devices in production nearly forever. After some years the price may > rise, but you won't have to respin your design because you can't get them. > > Rick The problem with "nearly forever" is that the end date isn't actually set by Xilinx, but by the end-of life for the fab process. Xilinx at one point announced a general EOL for Spartan 2, then changed their mind. Not that long ago, Spartan 2e was actually the lowest priced Xilinx part per IOB. For many small applications the IOB count limits the device selection. So even after Spartan 3 came out with great fanfare as the lowest cost device (per LUT), Spartan 2e still had better per-IOB price. Lattice hasn't been in the FPGA business long enough to know its track record for length of product life. On the other hand their older CPLD lines are very long-lived (again EOL probably dictated by fab rather than Lattice). So if you're looking for long product life in a low- cost part you're probably best finding a part with the most recent fab process node that still fits your budget, as long as the FPGA vendor is one of the more stable companies (I would include Lattice in this group, as well as Xilinx, Altera and MicroSemi). -- Gabor
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