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 Jan 25, 10:37 pm, "Shenli" <zhushe...@gmail.com> wrote: > Hi all, > > I am reading "Coding Guidelines for Datapath Synthesis" from Synopsys. > > It says "The most important technique to improve the performance of a > datapath is to avoid expensive carry-propagations and to make use of > redundant representations instead (like carry-save or partial-product) > wherever possible." > > 1. Is there any article talk about what's "carry-propagation" and how > to avoid use it? > 2. What's "redundant representations" mean? > > Please recommend some readings about it, thanks in advance! > > Best regards, > Davy http://www.ecs.umass.edu/ece/koren/arith/ Happy reading,Article: 114926
Hi, I did something similar years ago to change the content of constant multipliers. You can use the LOC, RLOC and BEL constraints. Also, for reconfiguration I used JBits. Regards, Ivan On Jan 26, 11:42 am, "JustJohn" <john.l.sm...@l-3com.com> wrote: > On Jan 26, 7:34 am, "David" <dpmontm...@gmail.com> wrote: > > > > > Hi, > > > I'm trying to create a design that uses a LUT to control routing on a > > Virtex-II Pro. It's pretty easy to create the LUT in VHDL and feed > > it into a MUX to select the appropriate output based on the values in > > the LUT. I'm trying to use this in apartial reconfigurationdesign > > so that I can change the values in the LUT with a partial bitstream to > > change the routing. My problem is that the design is optimized and > > broken up in to multiple LUTs making it hard to determine what needs to > > be changed. > > > Is there any way to force the LUT to be left as a primitive and > > implement the equations (or initial value) that I set? I would also > > like to be able to force the LUT to be in known location so that I can > > find it easily in the NCD file. I've seen plenty of documentation > > staying this can be done, I can't find any exampled. I believe I can > > use an RLOC but I'm not sure where the RLOC constraint should be > > placed. > > > Thanks for your help, > > > David > > > Here's what I know so far: > > > library IEEE; > > use IEEE.STD_LOGIC_1164.ALL; > > use IEEE.STD_LOGIC_ARITH.ALL; > > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > > ---- Uncomment the following library declaration if instantiating > > ---- any Xilinx primitives in this code. > > library UNISIM; > > use UNISIM.VComponents.all; > > > entity lut_mod is > > Port ( SW_0 : in STD_LOGIC; --just some simple inputs and > > SW_1 : in STD_LOGIC; -- outputs for testing > > SW_3 : in STD_LOGIC; > > LED_0 : out STD_LOGIC; > > LED_2 : out STD_LOGIC; > > LED_3 : out STD_LOGIC); > > end lut_mod; > > > architecture Behavioral of lut_mod is > > > signal LUT_to_MUX : STD_LOGIC; > > > begin > > > LED_3 <= SW_1; > > LED_2 <= SW_0; > > > LUT4_L_inst : LUT4_L > > generic map ( > > INIT => X"1010") > > port map ( > > LO => LUT_to_MUX, -- LUT local output > > I0 => SW_3, -- LUT input > > I1 => SW_3, -- LUT input > > I2 => SW_3, -- LUT input > > I3 => SW_3 -- LUT input > > ); > > > MUXF5_inst : MUXF5 > > port map ( > > O => LED_0, -- Output of MUX to general routing > > I0 => SW_0, -- Input > > I1 => SW_1, -- Input > > S => LUT_to_MUX -- Input select to MUX > > ); > > > end Behavioral;Read The Fine Manual. > The Constraints Guide shows examples of RLOCs in both the architecture > declaration area for single components and in the declaration area of > for generate blocks for primitives created that way. > Just JohnArticle: 114927
The keywords are different for different synthesis tools. Look up the user guide of your synthesis tool for words like "keep", "preserve", "prune", etc. Once you find the right keyword, you can then attach it as an attribute to your instance. eg attribute SYN_NOPRUNE of my_lut : label is TRUE; Also the LOCK_PINS constraint may be useful. Cheers, Jim http://home.comcast.net/~jimwu88/tools/ On Jan 26, 10:34 am, "David" <dpmontm...@gmail.com> wrote: > Hi, > > I'm trying to create a design that uses a LUT to control routing on a > Virtex-II Pro. It's pretty easy to create the LUT in VHDL and feed > it into a MUX to select the appropriate output based on the values in > the LUT. I'm trying to use this in a partial reconfiguration design > so that I can change the values in the LUT with a partial bitstream to > change the routing. My problem is that the design is optimized and > broken up in to multiple LUTs making it hard to determine what needs to > be changed. > > Is there any way to force the LUT to be left as a primitive and > implement the equations (or initial value) that I set? I would also > like to be able to force the LUT to be in known location so that I can > find it easily in the NCD file. I've seen plenty of documentation > staying this can be done, I can't find any exampled. I believe I can > use an RLOC but I'm not sure where the RLOC constraint should be > placed. > > Thanks for your help, > > David > > Here's what I know so far: > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > ---- Uncomment the following library declaration if instantiating > ---- any Xilinx primitives in this code. > library UNISIM; > use UNISIM.VComponents.all; > > entity lut_mod is > Port ( SW_0 : in STD_LOGIC; --just some simple inputs and > SW_1 : in STD_LOGIC; -- outputs for testing > SW_3 : in STD_LOGIC; > LED_0 : out STD_LOGIC; > LED_2 : out STD_LOGIC; > LED_3 : out STD_LOGIC); > end lut_mod; > > architecture Behavioral of lut_mod is > > signal LUT_to_MUX : STD_LOGIC; > > begin > > LED_3 <= SW_1; > LED_2 <= SW_0; > > LUT4_L_inst : LUT4_L > generic map ( > INIT => X"1010") > port map ( > LO => LUT_to_MUX, -- LUT local output > I0 => SW_3, -- LUT input > I1 => SW_3, -- LUT input > I2 => SW_3, -- LUT input > I3 => SW_3 -- LUT input > ); > > MUXF5_inst : MUXF5 > port map ( > O => LED_0, -- Output of MUX to general routing > I0 => SW_0, -- Input > I1 => SW_1, -- Input > S => LUT_to_MUX -- Input select to MUX > ); > > end Behavioral;Article: 114928
I wrote: > I do my editing in Emacs, but I despise vhdl-mode. I normally use > the GUI for everything but editing. Martin Thompson <martin.j.thompson@trw.com> writes: > Interesting - could you say any more about what makes vhdl-mode so > bad? My experience has been more of people thinking Emacs sucks, but > they wish their editor did all that vhdl-mode does! Completion/templates get in the way of my typing. I know what I want to write, but if the editor starts inserting stuff for me, I have to think about the typing much more, so it slows me way down. EricArticle: 114929
On Jan 25, 9:18 pm, "any2letters" <any2wil...@letter.com> wrote: > Does anyone know a decent - FREE - timing diagram cad tool? > > Thanks I'm using a Visio timing stencil from Thomas Thorsen: http://kom.aau.dk/~ttho02/greyscale/TimingStencil/ Very good and free if you already have Visio... PatrickArticle: 114930
I downloaded Xilix webpack9.1 yesterday, now tonight had some chance to play with it. All works OK on my grml Linux system (Debian based, but with a thousand things added). Only thing I had to change was: export LANGUAGE=usenglish (Normally it shows 'us'). This to prevent endless warnings in command line mode. Have only tested a little bit so far. Nice work from Xilinx, install was much simpler then 8.1. It is possible to switch between the old and new with some simple scripting. It seems the old version uses libPds_Conv.so and the new one not.... Just relink the library path too, and run ldconfig.Article: 114931
Ben Jones wrote: > <ammonton@cc.full.stop.helsinki.fi> wrote in message > news:epb4ak$evj$1@oravannahka.helsinki.fi... > >>doug <doug@doug> wrote: >> >> >>>Memory leaks are due to sloppy or incompetent programmers. Not fixing >>>them is due to poor management. >> >>Obviously I can't speak for Xilinx, but IME some leaks are due to >>design errors that can require whole subsystems to be rewritten to fix >>properly. > > > Entering the conversation rather late, but as an (internal) user of the ISE > tools and someone else who has seen their fair share of these memory issues, > I thought I ought to chime in. I'm not going to leap to the defence of the > ISE programmers and pretend that there are no problems, but I wanted to draw > attention to what I see as an important distinction between two similar but > separate issues: > > (1) Memory leaks, and > (2) Excessive memory consumption. > > No-one will argue that problem (1) is acceptable in commercial production > software. However, a lot of the time what looks like a memory leak is really > just problem (2): an inefficient algorithm that consumes a massive amount of > memory when it runs, but is in fact perfectly well-behaved in terms of > returning memory to the system when it has finished with it. (Usually this > is a result of someone writing the simplest possible algorithm to get the > job done, not expecting it to become the critical section of code. I think > it's fair to say most of us have been guilty of that at one time or another! > :-)) > > Many times, I and other developers in my group have encountered excessive > runtimes and memory consumption for synthesizing quite simple pieces of HDL > code. Upon investigation, this has often turned out to be due to complexity > of coding style - for example, nested loops in VHDL function calls are a > common culprit. Usually there turns out to be a way to re-phrase the code in > question so that XST behaves better. > > Often what seems to happen is that problems in class (2) are deemed > "annoyances" rather than defects, and thus get a lower priority than "real" > bugs that cause crashes or data corruption. Nevertheless, the bottom line is > that the more people who report that they're having problems, the more > likely something is to get fixed. > > So please, carry on complaining... :-\ > > -Ben- > > Just to be clear in this case here are the differences in 7.1 and 8 or 9 for the same project. ISE 7.1 max memory useage about 120mB and 5 minutes ISE89 crashes at 2GB after an hour. This is definitely the memory leak category. The other question, of course is how they managed to write bad enough code to take 50 times as long (when 8 or 9 crashes, it is about 25% done). Even if it did not crash, this would be a major pain as it implies a xst process time of around four hours.Article: 114932
Peter Alfke wrote: >No, this is just history. On the old 7400 gates and MSI parts, Vcc and >GRND were diagonally opposed, for no good reason (it actually gave max >length to the bond wires, and thus max inductance.) >One of the "Original Sins" of this industry. But remember, rise and >fall times were >10 ns ! > > The "good reason" is it made it possible to use REAL bus bars to distribute power and ground on wire-wrap boards, and wide power/ground tracks between rows of chips on 2-sided boards. For 7400-series logic, the penalty was really small, with 10 ns Tr - Tf. As the move to faster and faster CMOS happened, it got to be a problem. JonArticle: 114933
I am not sure what you mean by two pass approach. The max (theoretical) bandwidth I have available to/from the SDRAM is about 16 bits * 100 Mhz = 1.6 Gbit/sec This is not an achievable estimate of course, even if I only did full page reads and writes, since there is overhead associated with each. I also have to refresh periodically. My pixel bit width could be brought down to 8 bits. That way I could store 2 pixels per address if need be. On Jan 25, 7:23 pm, "Pete Fraser" <pfra...@covad.net> wrote: > "wallge" <wal...@gmail.com> wrote in messagenews:1169766685.898182.155950@v45g2000cwv.googlegroups.com... > > > Can you write out the FIR filter coeffs for > > a bilinear interpolation "filter kernel"? > > How about a bicubic interpolator filter kernel > > what are its filter coeffs?I'm happy to, but we're getting away from FPGA stuff, > so let's do that off line. Let me know how many phases you > need, and the coefficient format you'd like. I usually > use a minor 4x4 variation on cubic, but it's all set up in > Mathematica, so I could do cubic also. > > > > > arguing semantics was not the purpose of my post. > > > I will probably wind up doing bilinear interpolation or > > "filtering". Which means I need 4 pixels of the input frame to > > determine > > 1 pixel of output warped frame.So you don't really need coefficient tables for this. > You can just use the fractional phase directly. > > > > > By the way what is the Freq response of the bilinear interpolation > > "filter"?It depends on the position of output relative to input pixel, but > for a central output pixel the frequency response would be > Cosusoidal. > > Getting back to FPGA stuff though, what are your off-chip > RAM bandwidth limitations, and could you consider a two-pass approach? > > >> I'm still not sure of your limitations on off-chip RAM. > >> You have a buffer on the input or output (or both?) > >> Do you have enough bandwidth to have an > >> intermediate buffer for a two-pass operation?Article: 114934
Sean, The first service pack is actually about 5 weeks after we freeze the DVD image and release the software to manufacturing. After we feeze it, we give it to the FAEs and train them on the new capabilities. Some customers may get it during this timeframe if they have a specific need that is addressed in that release. We also don't allow any changes in the two weeks prior to RTM to allow for full testing. So even though it looks like the first service pack comes out a couple of days after you get the software, it's about 7-8 weeks after we lock down the release. Regardless, because of these types of comments and the fact that we need to better coordinate the releases of the other Xilinx tools, expect some positive changes in 10.1 release cycle. Steve "Sean Durkin" <news_jan07@durkin.de> wrote in message news:51rd6fF1lppelU1@mid.individual.net... > Hi Steve, > > first of all, I appreciate your comments. I think I can say that actual > Xilinx employees with an insight reading and posting here is really a > "feature" most of us appreciate. :) > > steve.lass@xilinx.com wrote: >> Actually, for the 9.1i release, feature freeze was in June 2006 and the >> release to manufacturing was in December. We spend about 6 months fixing >> bugs >> and improving quality. > Then why do you release the first service pack days after the software? > Why not just push back the release for a few weeks and ship something > that is usable right away? > I can't comment on other customers, but in our case it's not like we're > desperately waiting for new ISE releases. It's not like we're waiting > for those new features (because we usually don't have any idea what > these new features might be, except the usual promised 30% increase in > speed). It's not like we're waiting for bugs to be fixed... we have our > workarounds, because we can't just wait until Xilinx fixes it, we need a > solution now. > It really is of no importance or relevance to us when a new ISE is > coming out. When it's there, it's there, and we'll give it a try to see > what's been changed/improved, hoping that some of the issues I had with > earlier versions are resolved. > As stated in my earlier post: I know of no other EDA software vendor who > handles the release cycle like Xilinx does (and Xilinx didn't always do > it like that either). And you really can't claim other vendors don't > have the same problems with dependencies between different products and > 3rd party software etc. > >> Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The >> database was created in 1990 and needed to be rewritten and so did the >> GUI. > I agree. The switch to QT (or whatever it is you're using now) was long > overdue and made the GUI finally usable under Linux (be gone, WindU!). > >> It's not as simple as saying we will release when its ready because of >> other >> dependencies. We need to make sure all of our other software products >> (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and >> 3rd party tools all work together. > Yes, you have to, but they don't. A new EDK version is usually not > released for weeks or months after the corresponding ISE, so in most > cases I can't use the latest ISE anyway because it won't work with my > older EDK. Same applies for some IP (like MiG, for example): Those > usually don't work right away as well, but they will be released > sometime later in a version compatible with the latest ISE (BTW, the > later IP-updates are a friggin' 600MB in size, helloooo?). So in what > way does the fixed (and too early, quality-wise) release date help the > integration of other products, IP and 3rd party tools? > >> Defining a release date and sticking to that >> date is the best way to accomplish this. So instead, we define a feature >> freeze date. If a feature can't be done by that date, it gets pushed to >> the next >> release. > I don't really understand this. Feature freeze date, yes. But why a > fixed release date? > Just to compare, look at the Debian Linux project (or any other bigger > open source project). There's a feature freeze date, and a projected > release date. At the feature freeze date, there's a certain number of > release-critical bugs, and a number of not-so critical bugs. The release > date usually will be pushed back until the number of release-critical > bugs drops below a certain threshold, or is 0. Only then is it more or > less guaranteed to work when it's released. > I had assumed it is similar at Xilinx, but with a release date fixed > well in advance, this can never work. > I realize that software can never be bug-free, but that's beside the > point. Why release a software that you *KNOW* has a bunch of critical > bugs (you already have the first service pack ready!), just so the > release date fits your regular release cycle? > 3rd party tools as well as your other products and IPs are being worked > on long before ISE is released, so the actual release date is of no > relevance to those either. > >> I agree with all of this. To be honest, no customers told us they were >> using >> partial reconfig in ISE 4 - 7, so we did not make it a priority. > Well, I did. John Williams initiated a whole separate mailing list just > for the topic. The subject regularly pops up in this very newsgroup. So > you can't say noone told you. But I guess noone "important" told you, > since all the people who used it until very recently were students or > researchers, not high-volume-customers. But I totally understand that, > this is not meant to be critizism. I guess it's pretty complicated to > implement it in the software, and you can't expect a huge company doing > all the work to fix it just for a handful of academic customers. Again, > this is not meant to be sarcastic, I wouldn't do it any other way if I > were in charge at Xilinx. > > The thing that bugs me is just that if it's not a priority for you to > fix, why not just tell people? From ISE4 through ISE7, I was told "This > is going to be fixed in the next service pack/release", but it never > was. And after every new release, I invested a couple of days "porting" > my designs to the new software, only to find out that it's still not > working. A lot of time I could've spent smelling the roses or hugging > trees or generally doing something useful if only I would've been told > what's up right away. > >> Don't be shy about reporting bugs to us and don't >> complain about bugs not being fixed if you don't report them. > Most of the time I run into known problems. I first check your website > and find that someone else has already reported it and "it will be fixed > in the next service pack". But if you say duplicate reports might help > prioritizing things, I'll start reporting. > >> Steve Lass >> One of those Marketing guys. > I apologize if my post read like I had something against marketing. :) > > It's just my experience that priorities and ways of thinking simply > differ between "techies" and "marketing". I see it in our projects, too. > Sometimes we have to implement features that are complete nonsense that > no customer will ever use, but it looks good in the brochure and the > competition has it in their brochures as well, so it's gotta be > implemented; just in case a crazy customer decides to check if the > brochure is totally accurate (which occasionally does happen)... > > I've had some interesting (and funny) chats with engineers from the > competition at trade shows about the very same subject, and it's the > same everywhere. The problem is that the people who decide which product > will be bought often aren't "techies" and hence rely only on the > brochures to compare, so it's gotta be in there. The question is who > started it in the first place, who put it in the first brochure. :) > > And I'm not so sure how many of the new features are actually things > customers need or want. I can't imagine any customer requesting the > format of the project files to be switched to binary, or requesting the > feature to send detailed information about my designs to Xilinx after > synthesis... And I don't think a lot of customers need the "feature" of > a new ISE release for christmas every year. > > cu, > Sean > > -- > My email address is only valid until the end of the month. > Go figure what the address is going to be after that...Article: 114935
aravind wrote: > > On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote: >> aravind wrote: >>> There is a 20 bit counter,with two inputs ,on the rising edge of one >>> input the counter must increment and on the rising edge of the other >>> input the counter must decrement. >>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using >>> Xilinx ISE tool.according to the xilinx tool you cannot have two >>> (rising_edge()) statements in a single process. >>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a >> FIFO). >> If not, such a circuit cannot be built. Consider what might happen when >> the two clock edges occur almost simultaneously: the circuit will >> certainly fail for some (small) delay between the clocks. >> The usual way to build a FIFO is to use a separate counter for each >> port. You can compare them to determine fullness. (Hint: use Gray-code >> counters, not straight binary). >> >> If the clocks are synchronised, it may be possible to re-work the >> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control >> input. That is feasible. > > Well the FIFO is not exactly asynchronous. Since i'm using a single > port SRAM that sits outside the FPGA, it cannot handle a simultaneous > read and write.I'm designing the state machine such that only one of > the signals is asserted to the 20 bit counter at once.If i redesign the > circuit to use a single clock with UP/HOLD/DOWN control ,i need to > waste another clock cycle.i'm already using 2 clocks for read and 2 > clocks for a write operation to satisfy the timing requirements of the > SRAM chip.The reason why chose to implement a counter instead of > comparing the RD,WR addresses is that, i can generate full, empty > signals and also know to size of the buffer at any instant. > Can you specify exactly what is meant by "not exactly asynchronous"? The whole thing may turn on that point: if there's a predictable relationship between those clocks, it can likely be exploited. But nobody is building FPGA elements with multiple clock inputs: everything ultimately reduces to simple D-flipflops.Article: 114936
On Jan 26, 3:15 pm, "wallge" <wal...@gmail.com> wrote: > I am not sure what you mean by two pass approach. > The max (theoretical) bandwidth I have available to/from the SDRAM > is about > 16 bits * 100 Mhz = 1.6 Gbit/sec > > This is not an achievable estimate of course, even if I only did full > page > reads and writes, since there is overhead associated with each. I also > have to refresh periodically. > > My pixel bit width could be brought down to 8 bits. That way I could > store 2 > pixels per address if need be. > You may be missing an important feature of SDRAM. You don't need to use full-page reads or writes to keep data streaming at 100% of the available bandwidth (if you don't change direction) or very nearly 100% (if you switch from read to write infrequently). This is due to the ability to set up another block operation on one bank while another bank is transferring data. When I use SDRAM for relatively random operations like this I like to think of the minimum data unit as one minimal burst (two words in a single-data-rate SDRAM) to each of the four banks. Any number of these data units can be strung one after another with no break in the data flow. Then if you wanted to internally buffer a square section of the image in internal blockRAM the width of the minimum block (allowing 100% data rate) would only be 16 8-bit pixels or 8 16-bit pixels in your case. If the area can cover the required computational core (4 x 4?) for several pixels at a time, you can reduce overall bandwidth. This was the point of suggesting an internal cache memory. HTH, GaborArticle: 114937
Hi, I think you are right. Do you have any advice on how to solve this? should I add some constraints on this path? thanks. On 1=D4=C226=C8=D5, =CF=C2=CE=E711=CA=B132=B7=D6, "Symon" <symon_bre...@hot= mail.com> wrote: > "skyworld" <chenyong20...@gmail.com> wrote in messagenews:1169822495.6112= 26.116970@k78g2000cwa.googlegroups.com... > > > -----------------------------------------------------------------------= --------- > > Slack: -0.443ns (requirement - (data path - clock path > > skew + uncertainty)) > > Source: u_datarecovery_a6_i/FF0 (FF) > > Destination: u_datarecovery_c5_i (FF) > > Requirement: 0.800ns > > Data Path Delay: 1.040ns (Levels of Logic =3D 0) > > Clock Path Skew: -0.003ns > > Source Clock: clk_180 rising at 0.000ns > > Destination Clock: clk_90 rising at 0.800ns > > Clock Uncertainty: 0.200ns > > > I am confused by the slack: (requirement - (data path - clock path skew > > + uncertainty)), Can any body help me to explain this? And how to > > reduce this data path dealy? Seems my design fails with this.You've got= a FF clocked by clk_180 feeding a FF clocked by clk_90. There's > only 800ps between these two edges, which is your clock period, 3.2ns * > (180 - 90)/360 degrees. That leaves you a slack of 0.800 - 1.040 - 0.003 - > 0.200ns. Just like it says. > HTH, Syms.Article: 114938
"skyworld" <chenyong20000@gmail.com> wrote in message news:1169860287.287589.165750@p10g2000cwp.googlegroups.com... > Hi, > I think you are right. Do you have any advice on how to solve this? Yes. Don't try and clock two FFs 800ps apart. > should I add some constraints on this path? thanks. No. Change the path to something that's easier to meet. HTH, Syms.Article: 114939
Sorry for the spam, but I wonder if there is anyone who has a fpga.nl Lancelot card they would consider parting with. Since they switched from Alearep to Microtronix, they have gotten very expensive... -hpaArticle: 114940
On Jan 27, 3:33 am, David R Brooks <daveb...@iinet.net.au> wrote: > aravind wrote: > > > On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote: > >> aravind wrote: > >>> There is a 20 bit counter,with two inputs ,on the rising edge of one > >>> input the counter must increment and on the rising edge of the other > >>> input the counter must decrement. > >>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using > >>> Xilinx ISE tool.according to the xilinx tool you cannot have two > >>> (rising_edge()) statements in a single process. > >>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a > >> FIFO). > >> If not, such a circuit cannot be built. Consider what might happen when > >> the two clock edges occur almost simultaneously: the circuit will > >> certainly fail for some (small) delay between the clocks. > >> The usual way to build a FIFO is to use a separate counter for each > >> port. You can compare them to determine fullness. (Hint: use Gray-code > >> counters, not straight binary). > > >> If the clocks are synchronised, it may be possible to re-work the > >> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control > >> input. That is feasible. > > > Well the FIFO is not exactly asynchronous. Since i'm using a single > > port SRAM that sits outside the FPGA, it cannot handle a simultaneous > > read and write.I'm designing the state machine such that only one of > > the signals is asserted to the 20 bit counter at once.If i redesign the > > circuit to use a single clock with UP/HOLD/DOWN control ,i need to > > waste another clock cycle.i'm already using 2 clocks for read and 2 > > clocks for a write operation to satisfy the timing requirements of the > > SRAM chip.The reason why chose to implement a counter instead of > > comparing the RD,WR addresses is that, i can generate full, empty > > signals and also know to size of the buffer at any instant.Can you specify exactly what is meant by "not exactly asynchronous"? The > whole thing may turn on that point: if there's a predictable > relationship between those clocks, it can likely be exploited. > But nobody is building FPGA elements with multiple clock inputs: > everything ultimately reduces to simple D-flipflops. The FIFO will be written by a UART which will get MP3 data from the PC.The uart will use its own clock so that it is easy to generate the standard baud rates.No matter whether the inputs to FIFO is synchronous or asynchronous, the state machine is designed to synchronize the wr and rd inputs and carry out a rd or wr operation.Hence the inputs to the 20 bit counter will never be asserted at once, They will be atleast (worstcase) 4 FIFO clocks apart.Thank youArticle: 114941
Ludwig Lenz wrote:
> Hi
>
> I am working with an xilinx xup board. 8.2 sp1 ise + 8.2 edk.
> I am starting creating a design with ppc running from ddr ram, sysace and
> uart for output. Starting the debugger with:
> xmd -xmp system.xmp -opt etc/xmd_ppc405_0.opt
> with example application works.
>
> Closing the project adding a new plb peripherial template with 4x32
> registers no interrupts. Reopening the project. Download bitstream.
> Starting the debugger again gives:
>
> JTAG chain configuration
> --------------------------------------------------
> Device ID Code IR Length Part Name
> 1 05059093 16 XCF32P
> 2 0a001093 8 System_ACE
> 3 0127e093 14 XC2VP30
>
>
> Unable to connect to PowerPC target. Invalid Processor Version No 0x00000000
>
> make -f system.make clean doesn't help.
>
> Any idea why the jtag autodetection fails after adding an core to the plb
> bus?
>
> Thanks
> Ludwig
I only get this error if there is no bitstream downloaded to the FPGA.
Look if the red LED (D4 - DONE) near config DIP-switches is on.
HTH
Thomas
Article: 114942I am curious if anyone has been able to make the drawtiming tool available on sourceforge at http://drawtiming.sourceforge.net/ and referenced in this thread, work on Cygwin. I downloaded the tar file from sourceforge, and although a configure script is reference, it is nowhere to be found. It isn't in CVS either. I tried creating it with autoconf and the configure.in provided, but although the configure script was created, it then failed. I have tried contacting the author, but no response as yet. The tool looks interesting. Terry Brown On Fri, 26 Jan 2007 13:59:18 +0100, Koen Van Renterghem wrote: > any2letters wrote: >> Does anyone know a decent - FREE - timing diagram cad tool? >> >> Thanks >> >> > > * Not free : > - http://www.syncad.com/ > - If you are looking for something that helps you write > documentation, you can check a shareware tool called TimeGen > (http://www.xfusionsoftware.com/). Easy to use & not too expensive. > > * Free tools : > - http://drawtiming.sourceforge.net/ > - A latex package to insert timing diagrams, called 'timing', also > exists. (http://www.ctan.org/tex-archive/macros/latex/contrib/timing/) > - Check the 'other timing diagram' section on > http://tdv.sourceforge.net/ for a couple of interesting links. -- C:\cygwin\home\tbrown\stickman_sig.txtArticle: 114943
Hi all experts, Does any body tell me about the well known institues for fpga/asic study in Europe where I can start my MS leading to Ph.D Thanks BegArticle: 114944
I put together some Verilog code to send in to the Xilinx hotline just the other day to demonstrate a problem with FPGA Editor. I digested my code down to the single LUT where I was having problems swapping pins. I manually instantiate the LUT whose function is to select the short routing path or the longer routing path for a fine-tuned delay. I had problems keeping the Xilinx tools from optimizing the LUT back to a single pass-through rather than my mux of 2 versions of the same signal until I hit upon the "right" constraint. LOCK_PINS as Jim Wu mentioned. In the Xilinx User Constraints File (.ucf) you can specify everything you need in one line to have an explicit location and not have your INIT values optimized for you. INST MyLut LOC = SLICE_X15Y34 | BEL = G | LOCK_PINS=ALL; The LOC and BEL give you explicit placement to the same LUT compile after compile. The LOCK_PINS=ALL keeps the optimizer from undoing your hand crafted details. I even go as far as to use a LUT4 to specify a LUT3 function and leave one input out of the INIT values allowing me to use G1, G3, and G4 pins without using the G2, for instance. I do my pin placement in the LUT instantiation rather than LOCK_PINS=A1:F2 type of syntax that gave me troubles early on. Keep in mind you can also change the LUT contents by defining an SRL instead. You still have fixed inputs (no LOCK_PINS required to keep the SRL in the right place) and you can reload the LUT over 16 clocks later on. I considered this approach to get up to 4 different delays "tuned" to the silicon for one LUT but ended up sticking with a MUX of 2 values because I couldn't handle the 16 clocks of configuration. An SRL with the same INIT as a LUT4 has the exact same function as the LUT4. - John_H David wrote: > Hi, > > I'm trying to create a design that uses a LUT to control routing on a > Virtex-II Pro. It's pretty easy to create the LUT in VHDL and feed > it into a MUX to select the appropriate output based on the values in > the LUT. I'm trying to use this in a partial reconfiguration design > so that I can change the values in the LUT with a partial bitstream to > change the routing. My problem is that the design is optimized and > broken up in to multiple LUTs making it hard to determine what needs to > be changed. > > Is there any way to force the LUT to be left as a primitive and > implement the equations (or initial value) that I set? I would also > like to be able to force the LUT to be in known location so that I can > find it easily in the NCD file. I've seen plenty of documentation > staying this can be done, I can't find any exampled. I believe I can > use an RLOC but I'm not sure where the RLOC constraint should be > placed. > > Thanks for your help, > > David > > Here's what I know so far: > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > ---- Uncomment the following library declaration if instantiating > ---- any Xilinx primitives in this code. > library UNISIM; > use UNISIM.VComponents.all; > > entity lut_mod is > Port ( SW_0 : in STD_LOGIC; --just some simple inputs and > SW_1 : in STD_LOGIC; -- outputs for testing > SW_3 : in STD_LOGIC; > LED_0 : out STD_LOGIC; > LED_2 : out STD_LOGIC; > LED_3 : out STD_LOGIC); > end lut_mod; > > architecture Behavioral of lut_mod is > > signal LUT_to_MUX : STD_LOGIC; > > begin > > LED_3 <= SW_1; > LED_2 <= SW_0; > > LUT4_L_inst : LUT4_L > generic map ( > INIT => X"1010") > port map ( > LO => LUT_to_MUX, -- LUT local output > I0 => SW_3, -- LUT input > I1 => SW_3, -- LUT input > I2 => SW_3, -- LUT input > I3 => SW_3 -- LUT input > ); > > MUXF5_inst : MUXF5 > port map ( > O => LED_0, -- Output of MUX to general routing > I0 => SW_0, -- Input > I1 => SW_1, -- Input > S => LUT_to_MUX -- Input select to MUX > ); > > end Behavioral;Article: 114945
Thank you all for your posts. John_h, the combination of LOC BEL and LOCK_PINS works great for my application.Article: 114946
aravind wrote: > > On Jan 27, 3:33 am, David R Brooks <daveb...@iinet.net.au> wrote: >> aravind wrote: >> >>> On Jan 26, 4:21 pm, David R Brooks <daveb...@iinet.net.au> wrote: >>>> aravind wrote: >>>>> There is a 20 bit counter,with two inputs ,on the rising edge of one >>>>> input the counter must increment and on the rising edge of the other >>>>> input the counter must decrement. >>>>> this is for a 1MB FIFO buffer using single port external SRAM,I'm using >>>>> Xilinx ISE tool.according to the xilinx tool you cannot have two >>>>> (rising_edge()) statements in a single process. >>>>> How do you code it?Are the two clocks synchronised? (I assume not, since you're building a >>>> FIFO). >>>> If not, such a circuit cannot be built. Consider what might happen when >>>> the two clock edges occur almost simultaneously: the circuit will >>>> certainly fail for some (small) delay between the clocks. >>>> The usual way to build a FIFO is to use a separate counter for each >>>> port. You can compare them to determine fullness. (Hint: use Gray-code >>>> counters, not straight binary). >>>> If the clocks are synchronised, it may be possible to re-work the >>>> circuit, so the counter sees a single clock, and an UP/HOLD/DOWN control >>>> input. That is feasible. >>> Well the FIFO is not exactly asynchronous. Since i'm using a single >>> port SRAM that sits outside the FPGA, it cannot handle a simultaneous >>> read and write.I'm designing the state machine such that only one of >>> the signals is asserted to the 20 bit counter at once.If i redesign the >>> circuit to use a single clock with UP/HOLD/DOWN control ,i need to >>> waste another clock cycle.i'm already using 2 clocks for read and 2 >>> clocks for a write operation to satisfy the timing requirements of the >>> SRAM chip.The reason why chose to implement a counter instead of >>> comparing the RD,WR addresses is that, i can generate full, empty >>> signals and also know to size of the buffer at any instant.Can you specify exactly what is meant by "not exactly asynchronous"? The >> whole thing may turn on that point: if there's a predictable >> relationship between those clocks, it can likely be exploited. >> But nobody is building FPGA elements with multiple clock inputs: >> everything ultimately reduces to simple D-flipflops. > The FIFO will be written by a UART which will get MP3 data from the > PC.The uart will use its own clock so that it is easy to generate the > standard baud rates.No matter whether the inputs to FIFO is synchronous > or asynchronous, the state machine is designed to synchronize the wr > and rd inputs and carry out a rd or wr operation.Hence the inputs to > the 20 bit counter will never be asserted at once, They will be atleast > (worstcase) 4 FIFO clocks apart.Thank you > So the write side of the FIFO cannot be running much faster than 115/8 kHz. How fast is the read-side clock? If it's dramatically faster, then just sample the UART outputs into the output clock domain, & do everything there. (ie re-synchronise the UART's ready line, & use the re-sampled edge to trigger a read of its data lines. Since RD & WR to most UARTs are asynchronous to the shift clock, the UART has done your work for you.Article: 114947
M Ihsan Baig wrote: > Hi all experts, > Does any body tell me about the well known institues for fpga/asic > study in Europe where I can start my MS leading to Ph.D > Thanks Beg I'd try the University of Louvain-la-Neuve in Belgium. They have very good contacts with IMEC, a major semiconductor research center. Plus, the beer in the area is just wonderful. Best regards, BenArticle: 114948
Have a look at the FPL conference proceedings and pic a research group that suits your interessest. Kolja Sulimma On Jan 27, 10:49 pm, Ben Twijnstra <btwijns...@gmail.com> wrote: > M Ihsan Baig wrote: > > Hi all experts, > > Does any body tell me about the well known institues for fpga/asic > > study in Europe where I can start my MS leading to Ph.D > > Thanks BegI'd try the University of Louvain-la-Neuve in Belgium. They have very good > contacts with IMEC, a major semiconductor research center. Plus, the beer > in the area is just wonderful. > > Best regards, > > BenArticle: 114949
Andy Peters <google@latke.net> wrote: >On Jan 25, 11:31 am, Markus Fras <f...@mppmu.mpg.de> wrote: >> Hello Ed McGettigan, >> >> that's sad to hear; we have three of the devices around at our company. >> So what do we do with them, throw them in the bin and by new ones? >Call your rep and demand that they supply you with supported >replacements, gratis. Another point why driver source is useful to have. (the adapters may be slow & expensive, but if you got a few of them..well..)
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