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
I've installed sp3, but still can't work. error info: ld.so.1: promgen: fatal: libBs_Bitstream.so: open failed: No such file or directory and the file is there: ls -l /SW/xilinx/bin/sol/libBs_Bitstream.so -r-xr-xr-x 1 xilinx sw 149088 Nov 17 16:52 /SW/xilinx/bin/sol/libBs_Bitstream.so Is it a bug?Article: 63151
"Jay" <yuhaiwen@hotmail.com> wrote in message news:bpa4cc$1lsdcn$1@ID-195883.news.uni-berlin.de... > I've installed sp3, but still can't work. > > error info: > ld.so.1: promgen: fatal: libBs_Bitstream.so: open failed: No such file or > directory > > and the file is there: > ls -l /SW/xilinx/bin/sol/libBs_Bitstream.so > -r-xr-xr-x 1 xilinx sw 149088 Nov 17 16:52 > /SW/xilinx/bin/sol/libBs_Bitstream.so > > Is it a bug? > > Check that you have /SW/xilinx/bin/sol in your LD_LIBRARY_PATH variable, regards Alan -- Alan Fitch Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: alan.fitch@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 63153
So I confess it was me that made the macros in XAPP223 and I made a mistake or at least an assumption. The serial input to the Rx is of course asynchronous to the clock and therefore should be synchronised to the internal clock domain before it is distributed. My macro did not do this. Unfortunately, I always use the input flip-flops in the I/O blocks whenever possible in all designs and as such all my testing never showed up an error. Occasional reports of errors have always been cleared up by using a flip-flop in the serial line and of course putting it in the IOB makes it free. Other than this issue, I have had only happy reports by the thousand (plus requests for parity support of course!). I have learnt from my mistake and have now re-implemented the UART macros which are currently bundled with PicoBlaze (www.xilinx.com/picoblaze) since this is where they get the most use and where the micro controller is an ideal partner. These macros have included input synchronising flip-flops so that they don't rely on I/O flip-flops. I guess I had to give up an additional slice of logic to make things easier to use :-) Ken ChapmanArticle: 63154
Anders Hellerup Madsen wrote: > > Yep, and apperently this is the way things are expected to be done. I > was also considering a kind of dithering where I would use, fx. four > adjectant pixels of different colors, to give the illusion that the four > pixels together were a mixed shade of another color. But this would > halve the resolution and generally look very ugly. > > But still I am very puzzled about this display. It's a Hitachi SX16H003 > display which can display up to 65000 different colors according to this > site: > > http://www.hitachi-displays.com/catalog/skg-225-e.html > > However according to the datasheet it seems there is only 3 bits per > pixels. I am still puzzled. The datasheet can be found here: > > http://www.hitachi-displays-eu.com/pdf/sx16h003.pdf > Remember that you have time as a third dimension for dithering. STN displays are slow to respond, so dithering in time, between frames, can give you more color resolution. Comercial STN display chips use a combination between spacial and temporal dither to achieve the claimed 65000 colors. Look up how floyd-steinberg dithering is done and extend it to three dimensions. It's a starting point. Kind regards, IwoArticle: 63155
Hi, Does anyone know how much Aldec Active-HDL 6.1 costs? I emailed Aldec, but they didn't bother to reply. Regards, Allan.Article: 63156
On Mon, 17 Nov 2003 22:24:06 +1100, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: >Hi, > >Does anyone know how much Aldec Active-HDL 6.1 costs? >I emailed Aldec, but they didn't bother to reply. haha! http://www.eedesign.com/story/OEG20031022S0026 "Active-HDL pricing starts at $5,900."Article: 63157
In article <q1chrvkpa2kejv3ttbidg2fv3ach5hd9bu@4ax.com>, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> writes >On Mon, 17 Nov 2003 22:24:06 +1100, Allan Herriman ><allan.herriman.hates.spam@ctam.com.au.invalid> wrote: > >>Hi, >> >>Does anyone know how much Aldec Active-HDL 6.1 costs? >>I emailed Aldec, but they didn't bother to reply. > >haha! http://www.eedesign.com/story/OEG20031022S0026 > >"Active-HDL pricing starts at $5,900." > Was about to give you a link to the UK distis, but then noticed you're no longer there. Couldn't really imagine agilent jumping ship from Modelsim anyway ;-) -- fredArticle: 63158
Mark, Thanks a lot for your help. I had the same problem: the leads to the board were to long (I made a PC3 on my own). So I shortened it (to about 10cm), took a parallel port extension cable and it works fine. Thank you and the other supporters once more... Kay "Mark van de Belt" <mark@nijenrode.nospam.demon.nl> schrieb im Newsbeitrag news:vr7vhgsvi4ue27@corp.supernews.com... > Hello, > > I had the same problem with the same two chips. There were 13 devices on the > my board. I used long leads (20 cm) from the PC3 to the board. After > shortening both the parallel port cable (I used a 1.5 M 1:1 extension cable > between the parallel port and the PC3 cable) and the leads to the board (to > 5 cm) the problem was solved. > > Mark > > > "Kay Schubert" <kaytastroph@gmx.de> schreef in bericht > news:3fb3a20d$1@news.uni-rostock.de... > > Hi, > > > > I designed a FPGA prototyping board with a Spartan XC2S200E and a XC18V02 > > PROM. > > To configure these devices I put a JTAG header on the board and routed it > as > > described in > > the following Xilinx datasheet: > > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/designing7.html > > > > At the software-side I use impact and the PC3 from Xilinx. When I start > > impact in boundary-scan mode, > > the PC3 will be detected (as PC3@200kHz) and the boundary-scan chain will > > be identified. But there's the problem: > > impact always detects 11 devices in the chain, but there are only two. > > And: Even though the two devices are original Xilinx parts, no ID codes > were > > returned (or better: the returned codes > > don't match with Xilinx parts). > > > > I checked the configuration connections and the power supply, but > > everything seems to be o.k. Has anybody of you an idea what the problem > > could be? > > > > thanks, Kay > > > > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.538 / Virus Database: 333 - Release Date: 10-11-2003 > >Article: 63159
Dear Sir or Madame, I have the following problem: In a clocked process I made the following registered signal assignments: ------------------------------------------------------------ ------------------------------------------------------------ entity xy is port( addr_to_send : in std_logic_vector(6 downto 0); ep_to_send : in std_logic_vector(3 downto 0); addr_rec : in std_logic_vector(6 downto 0); ep_rec : in std_logic_vector(3 downto 0); direction_to_send : in std_logic; cam_ram_entry_valid : in std_logic; ... ); end xy; architecture ... process(write_clock) begin if rising_edge(write_clock) then l_data_addr_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(2 downto 0) ); l_data_addr_rec <= ( addr_rec(6 downto 0) & ep_rec(2 downto 0) ); l_data_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(3 downto 0) & direction_to_send & cam_ram_entry_valid); end if; end process; -------------------------------------------------------------- -------------------------------------------------------------- When I open the NodeFinder in the AlteraQuartusII software (after Synthesis)I see that - l_data_addr_to_send are registered nodes : OK - only l_data_rec[0], l_data_rec[4] are registered nodes the other bits of l_data_rec are not shown at all ??? - only l_data_to_send[0], l_data_to_send[1], l_data_to_send[5] are registered nodes the other bits of l_data_to_send are not shown at all ??? So my question: Why did the synthesis tool not recognize all bits to be registered ? Thank you very much. Kind regards Andrés VázquezArticle: 63160
What does this generic means? I am wondering if I am missing out on a possible memory optimization. Altera's docs are decidedly vague and a search on their website brings up nothing. -- PeteArticle: 63161
Hello folks, I have quoted (at the end) an extract from the xilinx 5.2.03i trce command which shows the worst path in my design. The path is a carry chain within an adder but mid-way through the chain, it jumps to another column (X45 to X39) leading to a big delay! The VHDL was synthesised using Synplify Pro. Sometimes, for other filters with the same style of VHDL, the tools don't do this and maintain the carry chain in the same column which is clearly faster. Question is: Is it Synplify optimisations that are causing this or perhaps the ISE map/par stages and is there any way to avoid it? Thanks in advance for your time, Ken Extract: SLICE_X45Y5.CIN net (fanout=1) 0.000 AdderChain.tap27_sub_v648_1_cry_8/O SLICE_X45Y5.COUT Tbyp 0.092 tap27_sub_v648_1_s_9_n AdderChain.tap27_sub_v648_1_cry_9 AdderChain.tap27_sub_v648_1_cry_10 SLICE_X45Y6.CIN net (fanout=1) 0.000 AdderChain.tap27_sub_v648_1_cry_10/O SLICE_X45Y6.X Tcinx 1.107 tap27_sub_v648_1_s_11_n AdderChain.tap27_sub_v648_1_s_11 SLICE_X39Y18.F3 net (fanout=1) 0.910 tap27_sub_v648_1_s_11_n SLICE_X39Y18.COUT Topcyf 0.668 tap27_sub_v648(11) tap27_sub_v648_1_s_11_n_rt AdderChain.tap27_sub_v648_1_cry_11_0 AdderChain.tap27_sub_v648_1_cry_12_0 SLICE_X39Y19.CIN net (fanout=1) 0.000 AdderChain.tap27_sub_v648_1_cry_12_0/O SLICE_X39Y19.COUT Tbyp 0.092 tap27_sub_v648(13) AdderChain.tap27_sub_v648_1_cry_13_0 AdderChain.tap27_sub_v648_1_cry_14_0 -- To reply by email, please remove the _MENOWANTSPAM from my email address.Article: 63162
You really need a reset assignment on this for starters.... "Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0311170507.4495f94d@posting.google.com... > Dear Sir or Madame, > > I have the following problem: > > In a clocked process I made the following registered signal > assignments: > > ------------------------------------------------------------ > ------------------------------------------------------------ > entity xy is > port( addr_to_send : in std_logic_vector(6 downto 0); > ep_to_send : in std_logic_vector(3 downto 0); > addr_rec : in std_logic_vector(6 downto 0); > ep_rec : in std_logic_vector(3 downto 0); > direction_to_send : in std_logic; > cam_ram_entry_valid : in std_logic; > ... > ); > end xy; > > architecture ... > > process(write_clock) > begin > if rising_edge(write_clock) then > > l_data_addr_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(2 > downto 0) ); > > l_data_addr_rec <= ( addr_rec(6 downto 0) & ep_rec(2 downto > 0) ); > > l_data_to_send <= ( addr_to_send(6 downto 0) & ep_to_send(3 > downto 0) & direction_to_send & cam_ram_entry_valid); > > end if; > end process; > > -------------------------------------------------------------- > -------------------------------------------------------------- > > When I open the NodeFinder in the AlteraQuartusII software (after > Synthesis)I > see that > - l_data_addr_to_send are registered nodes : OK > > - only l_data_rec[0], l_data_rec[4] are registered nodes > the other bits of l_data_rec are not shown at all ??? > > - only l_data_to_send[0], l_data_to_send[1], l_data_to_send[5] are > registered nodes > the other bits of l_data_to_send are not shown at all ??? > > So my question: Why did the synthesis tool not recognize all bits > to be registered ? > > Thank you very much. > > Kind regards > > Andrés VázquezArticle: 63163
Would you mind me asking why considering Aldec? "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:q1chrvkpa2kejv3ttbidg2fv3ach5hd9bu@4ax.com... > On Mon, 17 Nov 2003 22:24:06 +1100, Allan Herriman > <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: > > >Hi, > > > >Does anyone know how much Aldec Active-HDL 6.1 costs? > >I emailed Aldec, but they didn't bother to reply. > > haha! http://www.eedesign.com/story/OEG20031022S0026 > > "Active-HDL pricing starts at $5,900." >Article: 63164
Hello I need help on using serializer and deserializer in an electornic card. The serializer and deserializer are from national DS90CR287 and DS90CR288 I'm working with an electronic card that use a serializer of 4 channels where the input clock is 40Mhz. when the data in the inputs of the serializer changes in a slow rate the deserializer and FPGA in the other card can decode the data properly. when the data in the inputs of the serializer changes in a high rate ( every 50ns ) the data after the deserializer and the FPGA in the other card can't decode the data. The thing is that there are some cards the work and some others that doesn't work. When I look for a diference I found that the 3.3v supply to the serializer is stable where the card works O.K and when the 3.3v supply has noise the card doesn't work . This card is a part of a system. the power supply to the system is from a power card. When I say that some card works and some don't I meen that I use the same system but change only the card with the serializer on it. Hope to get help soon . Thank you claudia B.Article: 63165
Topweaver v2.0 A GUI-based tool for connecting HDL modules, also called structural integration. You can use it in ASIC, FPGA or CPLD designs. FEATURES Extract ports from cell modules automatically Full mixed Verilog, Verilog 2001 and VHDL supported Automatically language recognition Connect ports in graph interface Great visual aid while connecting Smart Link technology enable you to connect ports automatically Bus combination and inout construction Generate Verilog/VHDL connection module automatically Output detailed module summary in HTML format Output formatted file list DelayGen ... Homepage: http://www.topweaver.com Download: http://www.topweaver.com/download.htm Quick Demo: http://www.topweaver.com/demo.htm Topweaver.comArticle: 63166
Jan, Yes, they are all internally connected on the die (once the IOB is programmed as a Vref). Since these are also general purpose IOBs, there is no bypass cap in the package, nor on the internal Vref line, so all external Vref pins must be externally individually bypassed to ground with bypass caps as close as possible to the Vref pins AND connected to the Vref supply to get the lowest noise Vref possible. Austin Jan Panteltje wrote: > Spartan 2 datasheet says Vrefs are internally connected, but must also be > externally connected. > Is this really needed if you only use one input?Article: 63167
<50 ms. We do not test outside of 250 us to 50 ms, so do not use the part there unless you wish to chaacterize it's behavior. There is no high current behavior on Virtex II, II Pro, II Pro-X (10 Gbs Virtex II Pro announced today), Spartan III. Austin etrac wrote: > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F93E4A8.C68E3142@yahoo.com>... > > etrac wrote: > > > > > > Jim Granville <jim.granville@designtools.co.nz> wrote in message news:<3F8DBF2B.2595@designtools.co.nz>... > > > > etrac wrote: > > > > > > > > > > Hi, > > > > > We have found the problem and this might interest somebody here so I > > > > > explain the reasons of the voltage falling : It was simply because we > > > > > put too many bypassing capacitors around the FPGA ! The virtex II > > > > > datasheet is asking for many capacitors to have good linearity in the > > > > > fpga voltages, but our power supply was not enough strong to support > > > > > the current when we power on the board. > > > > > > > > > > Etrac. > > > > > > > etrac wrote: > > > > > > > > > > > > > > > We want to power on a Virtex II xc2v3000 FPGA (Xilinx). The core power > > > > > > > > seems to work correctly (VccInt = 1.5V ; I<100mA), but VccAux and VccO > > > > > > > > are asking too much current (> 1.5A) for a long time. This occurs > > > > > > > > approximatively 1 second after the power is on. > > > > > > > > We have a current limitation power supply, so the VccAux/VccO voltage > > > > > > > > fall at nearly 1.5V, that is to say that the FPGA needs very much than > > > > > > > > 1.5A .. > > > > > > > > This does not quite 'gel' - you are saying lowering the Total C alone > > > > solved the issue ? > > > > > > > > That suggests a dV/dT limit, but times in the order of 1 second ? > > > > It may be a power-sequencing effect, which total C would affect. > > > > > > > > -jg > > > > > > Our power supply is current limited (2 Amps), and at poweron > > > capacitors were asking too many current for the power supply. So we > > > were in overcurrent mode. That was the same problem with our > > > laboratory power supplies, with a current limitation .. > > > > > > Etrac > > > > Isn't that a common mode during power on? Exactly what problem does > > this cause? Are you saying that the current causes a voltage foldback > > so that the rise is not monotonic? If so, your problem is not the > > capacitors, it is the foldback current limiting. I find it hard to > > imagine the caps on a board having more total capacitance than a power > > supply. But I guess you may be working with an on board DC/DC with 100 > > uF or less. > > > > -- > > > > Rick "rickman" Collins > > We use Motorola QuiccSupply products to power the FPGA, they have two > protections : overcurrent protection and undervoltage lockout. The > first limits the current, the second disables the power if the voltage > is not in the good range (checked every 100ms). That's why if C is big > the power supply can't raise the voltage quickly and the QuiccSupply > goes in undervoltage lockout. > > That's true that if the Power supply doesn't have any undervoltage > lockout capability we did not have such problems .. Nevertheless > Virtex II documentation says that at power on, each supply line (VCCO > VCCAUX and VCCINT) has to be stable quickly (< 200 ms if I remember > well), otherwise the component will need more current to power on. > So I think that having too many bypassing capacitors may affect the > power on. Of course this event depends on the power supply used .. > > EtracArticle: 63168
> I am using windows 2000, the two PCI card I am about to use is a > Display card and a FPGA based DSP card, they both have workable > driver, what I wonder is if a PCI-Bridge based slot expansion card can > make these two only ocupy one main PCI-bus slot, with out any change > of driver. It should work without any problem albeit performance might degrade somewhat. > Do you know if there are any product card can do this? or any > available design for this? There are tons of cards with bridges. One example is a Bittware Hammerhead DSP card. You can also find PMC carrier cards with bridges but to be able to use them you would need to have your 2 cards in the PMC form factor or use additional adapters. An example of such a card can be found here: http://www.technobox.com/pic3673.htm /MikhailArticle: 63169
Hello, I have installed an old release of ISE (4.2 sp3) on a SMP sparc32 workstation. But, when I try to load a project, I always receive : "no device data files etc.". I have verified that all reduired data files are installed (spartan2e and virtex2 in my case). The XILINX environment variable is set. Any idea ? Thanx in advance, JKBArticle: 63170
Hi Ken, One way to find out is to wade through the EDIF file and see what Synplify has made. I suspect you'll find that the fault lies with the map/par stages though. This happened to me when one of my designs started to fill up the part, i.e. Slice % went to 100%, LUT % was maybe 70%. There were a lot of long carry chains in it, and the Xilinx tools would break the chains to make it fit. Floorplanning fixed the problem, I didn't try using RLOC (see constraints guide) to fix the relative placement of the chain elements, although this should work too. Good luck mate, Syms. "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk> wrote in message news:bpak1v$bcb$1@dennis.cc.strath.ac.uk... > > Hello folks, > > I have quoted (at the end) an extract from the xilinx 5.2.03i trce command > which shows the worst path in my design. > > The path is a carry chain within an adder but mid-way through the chain, it > jumps to another column (X45 to X39) leading to a big delay! > > The VHDL was synthesised using Synplify Pro. > > Sometimes, for other filters with the same style of VHDL, the tools don't do > this and maintain the carry chain in the same column which is clearly > faster. > > Question is: > > Is it Synplify optimisations that are causing this or perhaps the ISE > map/par stages and is there any way to avoid it? > > Thanks in advance for your time, > > Ken > > > Extract: > > > > SLICE_X45Y5.CIN net (fanout=1) 0.000 > AdderChain.tap27_sub_v648_1_cry_8/O > SLICE_X45Y5.COUT Tbyp 0.092 tap27_sub_v648_1_s_9_n > > AdderChain.tap27_sub_v648_1_cry_9 > > AdderChain.tap27_sub_v648_1_cry_10 > > SLICE_X45Y6.CIN net (fanout=1) 0.000 > AdderChain.tap27_sub_v648_1_cry_10/O > SLICE_X45Y6.X Tcinx 1.107 > tap27_sub_v648_1_s_11_n > > AdderChain.tap27_sub_v648_1_s_11 > > SLICE_X39Y18.F3 net (fanout=1) 0.910 > tap27_sub_v648_1_s_11_n > SLICE_X39Y18.COUT Topcyf 0.668 tap27_sub_v648(11) > > tap27_sub_v648_1_s_11_n_rt > > AdderChain.tap27_sub_v648_1_cry_11_0 > > AdderChain.tap27_sub_v648_1_cry_12_0 > > SLICE_X39Y19.CIN net (fanout=1) 0.000 > AdderChain.tap27_sub_v648_1_cry_12_0/O > SLICE_X39Y19.COUT Tbyp 0.092 tap27_sub_v648(13) > > AdderChain.tap27_sub_v648_1_cry_13_0 > > AdderChain.tap27_sub_v648_1_cry_14_0 > > > > > > > > -- > To reply by email, please remove the _MENOWANTSPAM from my email address. > >Article: 63171
Hi Hans-Juergen, Try a search on Google groups "metastability srl". Top answer is a discussion we had here called "Should I worry about metastability". Xilinx's expert, Peter Alfke, said :- I will not guarantee that SRL16s recover as fast from metastability as the "normal" flip-flops that I documented, since SRLs are implemented in a different circuit design. (Different might mean better or worse). Ray Andraka replied:- Actually, the SRL's are probably no good for that. They have a considerably longer minimum pulse width than the regular flip-flops. I'm not privy to the actual construction, but I'd be it is more akin to latches than to real flip-flops. Your best resynchronizer will use the regular flip-flops, floorplanned to use adjacent slices within a CLB and using the fast direct connect route between the flip-flops. Which makes a lot of sense to me, the question is whether the latch type construction of the SRL FFs is compensated for by the short routing delay between the latch elements, they're in the same LUT structure, after all. My guess is not, so until someone can be bothered to do the experiment, I'm gonna stick with the regular FFs as Peter has tested this to death and so we have hard data to work with. I don't suppose you'd like to do the experiments?? So, rereading your post, it IS possible to use the SRLs to do the resync, how well it works w.r.t metastability see above! Post some frequencies, and you may get a better answer. cheers, Syms. "Hans-Juergen Dorn" <hjdorn@freenet.de> wrote in message news:1lugrv0l01tsje6qbbvtnepoa9q7he4u6e@4ax.com... > Hello All, > > I'm wondering, if it's possible to use SRL16s to synchronize > external signals to your clock. > > If I do the standard thing in VHDL, e.g. a couple of assignments in > a clocked process, then XST gives me a SRL anyway. > > Mabe I could just leave it that way, without having to > instantiate FDEs manually? > > Is there any difference w.r.t metastability in using SRLs > compared to FDs? > > Regards Hans Dorn > >Article: 63172
Hans-Juergen Dorn wrote: > I'm wondering, if it's possible to use SRL16s to synchronize > external signals to your clock. If not having a reset is ok, then yes. > If I do the standard thing in VHDL, e.g. a couple of assignments in > a clocked process, then XST gives me a SRL anyway. That's what I would expect. > Mabe I could just leave it that way, without having to > instantiate FDEs manually? That's an excellent idea. Easier to sim and more portable. > Is there any difference w.r.t metastability in using SRLs > compared to FDs? Don't know. Check the data sheet. Or check fmax, with and without a reset. -- Mike TreselerArticle: 63173
I concur. The SRL16 structure is different from a conventional flip-flop. Although it is only the Master latch in a flip-flop that is reponsible for metastability (the Slave just does the read-out), this might imply that there is no difference. But I still would be leary to venture into untested territory. Also, if you use the SRL16 for more than one bit of depth, you pick up latency. I prefer erring on the side of solid conservatism. (Technically, not politically). It's too late for my hair color, but it's nice to be able to sleep at night. :-) Peter Alfke =========================== Symon wrote: > > Hi Hans-Juergen, > Try a search on Google groups "metastability srl". Top answer is a > discussion we had here called "Should I worry about metastability". Xilinx's > expert, Peter Alfke, said :- > > I will not guarantee that SRL16s recover as fast from metastability as > the "normal" flip-flops that I documented, since SRLs are implemented in > a different circuit design. (Different might mean better or worse). > > Ray Andraka replied:- > > Actually, the SRL's are probably no good for that. They have a considerably > longer minimum pulse width than the regular flip-flops. I'm not privy to > the > actual construction, but I'd be it is more akin to latches than to real > flip-flops. Your best resynchronizer will use the regular flip-flops, > floorplanned to use adjacent slices within a CLB and using the fast direct > connect route between the flip-flops. > > Which makes a lot of sense to me, the question is whether the latch type > construction of the SRL FFs is compensated for by the short routing delay > between the latch elements, they're in the same LUT structure, after all. My > guess is not, so until someone can be bothered to do the experiment, I'm > gonna stick with the regular FFs as Peter has tested this to death and so we > have hard data to work with. I don't suppose you'd like to do the > experiments?? > So, rereading your post, it IS possible to use the SRLs to do the > resync, how well it works w.r.t metastability see above! Post some > frequencies, and you may get a better answer. > cheers, Syms. > > "Hans-Juergen Dorn" <hjdorn@freenet.de> wrote in message > news:1lugrv0l01tsje6qbbvtnepoa9q7he4u6e@4ax.com... > > Hello All, > > > > I'm wondering, if it's possible to use SRL16s to synchronize > > external signals to your clock. > > > > If I do the standard thing in VHDL, e.g. a couple of assignments in > > a clocked process, then XST gives me a SRL anyway. > > > > Mabe I could just leave it that way, without having to > > instantiate FDEs manually? > > > > Is there any difference w.r.t metastability in using SRLs > > compared to FDs? > > > > Regards Hans Dorn > > > >Article: 63174
Hi Peter, > I am wondering if I am missing out on a possible memory optimization. yes you do. Quartus allocates memory by depth first, 512x8bit therefore uses two M4Ks in 512x4 mode. If your memory width and depth is a power of two, allocation order doesn't matter except for some speed details. But a 700x8bit memory is much better allocated by width than by depth (because only 3 M4Ks are needed for the first compared to 4 for the latter). (see http://www.altera.com/support/kdb/rd03292002_9305.html for further details) MAXIMUM_DEPTH should help you to force Quartus not to waste this addtional memory block. Unfortunately it doesn't work. Not even the way Altera thinks it should work. I had a long (and somewhat bizarre) service request the last entry being the following one: -- Altera wrote This is to let you know that a software problem request has been filed in order to reflect this issue. I will let you know as soon the software group gets back to me with any infomation or when a resolution is made. -- Altera wrote much more, but [snip] This was written the 25th of august and the service request was closed without further comment. I have posted an additional request asking for the actual state of the problem request about one month ago and did not receive any answer. Either Altera doesn't care or they don't want to state that this is an issue at present before they are able to ship the new Quartus 4.0 (hopefully fixing this and a lot of other things) - who knows? If anyone in the group thinks he can help on this topic or has further details I would be thankful to hear about it as Quartus wastes a lot of my memory and this has to change! I have to say that life with Altera mySupport is very ambiguous to me. Answers are generally quick and friendly (which is already a lot) but generally only helpful when problems are simple. Whenever the problem gets more complex or there is a bug thinks get very slow (or even stop). Regards, Manfred BTW: "Release notes for Service Pack 2 will be released on Friday, October 24, 2003." (seen on https://www.altera.com/support/software/download/service_packs/quartus/dnl- qii30sp2.jsp the 17th november) ======= Service Request Detail (reordered for your convenience) Request #: 10363308 Status: Closed Date Opened (PDT): 8/19/03 9:03 AM Date Closed (PDT): 9/4/03 6:52 PM Inquiry Type: Product Question Device Family: CYCLONE Device: Title: FIFO implementation size Description: I have created a 1300word by 8bit FIFO (sfifo). The implementation of this needs 16384 memory bits. Why? The FIFO-size should result in about 1300x8=10400 memory bits. As the blocksize of the embedded ram in Cyclone is 4096bits which can be organized 512x8 I expect Quartus to use three M4K's resulting in 4096*3=12288bits. Obviously it uses a fourth block, why? Regards, Manfred ------ 8/19/03 3:17 PM To Customer Hello Manfred, This is to let you know that I am currently looking into this. I will let you know as soon as I am able to verify the problem as you have described and come into a resolution. ------ 8/19/03 4:20 PM To Customer Hello Manfred, Since 1300 is larger than 1k, it'll use 2kx2 mode for best performance. To get the x8 mode you'll need 4 M4Ks. Click custom on (page 6 out of 8 of the megawizard), then you get an option to set Maximum depth option and if you set 512 then it'll use that mode and should only need 3 M4Ks. For more information on this, you may refer to the following link: http://www.altera.com/support/kdb/rd03292002_9305.html ------ 8/20/03 12:36 AM From Customer Hello Marlon, thanks for your quick and helpful reply. Now the behaviour of Quartus is clear to me. Unfortunately setting the parameter max. block depth to 512 in the Megawizard Plug-In Manager as you proposed does not result in a smaller memory consumption. I have attached the packed project for your convenience. Setting this parameter adds the following line in the scfifo instantiation code: maximum_depth => 512, however this parameter is not described in the Quartus II help page for the scfifo-Megafunction. Why? Regards, Manfred ------ 8/20/03 9:47 AM To Customer Hello Manfred, The MAXIMUM_DEPTH parameter is an internal parameter so there won't be any information on this in the Quartus II Help or Megawizard. ------ 8/20/03 11:26 PM From Customer Hello Marlon, again: Unfortunately setting the parameter max. block depth to 512 in the Megawizard Plug-In Manager as you proposed does NOT result in a smaller memory consumption. Why? Please check with the attached project file. Regards, Manfred ------ 8/21/03 5:08 PM To Customer Hello Manfred, Sorry for the inconvenience, but actually, in order to get the x8 mode you'll need 4 M4Ks. ------ 8/21/03 11:49 PM From Customer Hello Marlon, could you please specify why it is not possible to implement a 1300x8 FIFO in 3 M4K Blocks as this information is the opposite of both your first advice and the mentioned support database page (http://www.altera.com/support/kdb/rd03292002_9305.html). What exactly is the parameter maximal block depth for then? Regards, Manfred ------ 8/25/03 6:50 PM To Customer Hello Manfred, This is to let you know that a software problem request has been filed in order to reflect this issue. I will let you know as soon the software group gets back to me with any infomation or when a resolution is made.
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