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
Dear Jens, Finally, I can use the ISE 8.1i. But, there is a problem, that is I can only found the ISE SP3 version. And after I update to SP3, I can not install the partial reconfiguration implementation tools any more :((. Do you have ISE SP1 for ISE 8.1i? Thank you very much, Thang NguyenArticle: 110251
In article <1160689402.959973.55670@k70g2000cwa.googlegroups.com>, "jacko" <jackokring@gmail.com> wrote: > i would be interested in construction contractors, who build to design > and ship. didn't try the distributors list, as i have no built design > yet. does such a service exsist? I might be able to get some ideas for you, but I would need to know a little more about what it is you want to build, and what the contractor would need to do (i.e. what they are given, and what do they produce). Thanks, Patrick Webmaster http://www.ElectronicDesignNet.comArticle: 110252
Manny wrote:
> Actually static timing did pass. As far as I could infer, these
> glitches are due to long routing propagation delays and only consitute
> negligible time (1ns) relative to the clock period. So they are pretty
> much clock independent.
Maybe, but it might be worth a sim run to check it.
Are the glitches on a registered output?
Are all tb and uut clock inputs on exactly the same signal?
> In my testbench, I added an explicit intertial
> delay (2ns) when assigning my output signal. Now everything is ok but I
> still get warning messages in simulation. Was wondering whether it'll
> have any noticeable impact when running in hardware?
If it does, the problem is confirmed.
If it doesn't, nothing is confirmed.
-- Mike Treseler
Article: 110253Manny, you claim that your design is fully synchronous. I take it that all flip-flops are clocked by a common clock. On the signals between these flip-flops you can (and probably will) have glitches as a result of logically combining signals with different routing delays. That is perfectly ok, as long as you manage to met all set-up time requirements. When you use a combinatorially decoded signal as output, you will see the glitch, and you either can live with it, or you need to synchronize the output with a flip-flop. That will definitely eliminate the glictch (at the expense of a one-clock-period delay). peter Alfke, Xilinx Applications. ==================== Manny wrote: > Actually static timing did pass. As far as I could infer, these > glitches are due to long routing propagation delays and only consitute > negligible time (1ns) relative to the clock period. So they are pretty > much clock independent. In my testbench, I added an explicit intertial > delay (2ns) when assigning my output signal. Now everything is ok but I > still get warning messages in simulation. Was wondering whether it'll > have any noticeable impact when running in hardware? > > Cheers, > -Manny > > Mike Treseler wrote: > > Manny wrote: > > > Anyway, it > > > seems that when running post-PAR simulation I end up having a periodic > > > pattern of 1ns wide glitches in my output signal every like 4 or > > > slightly less sampling periods. My design is fully synchronous. > > > > What happens if you slow down the clock? > > Did static timing pass? > > > > -- Mike TreselerArticle: 110254
Dear Comrades, I am trying to implement a large design on a Xilnx FPGA (over 500,000 gates). Spartan 3E seems like the best bet, but I wanted to ask around before I ordered a board. I am considering a board by digilent (http://www.digilentinc.com/). Can you please suggest: - A good starter board - A good FPGA with lotsa real estate for my big design My budget is about $500 Thanks a bunch, RohitArticle: 110255
As a matter of fact, it's a registered output. This is the weird thing
about it. There should be not glitches. My testbench is:
real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
-- *** Test Bench - User Defined Section ***
tb : PROCESS
BEGIN
wait until (reset = '1');
for i IN 0 TO 2091 loop
filter_in <= real2hex(filter_in_force(i), 16.0);
real_in <= hex2real(filter_in, 16.0);
table_in <= filter_in_force(i);
table_out <= filter_out_expected(i);
wait until (clk_sampling = '0');
end loop;
END PROCESS;
-- *** End Test Bench - User Defined Section ***
filter_out is an already registered output. Is it because I've taken
real_out outside of the main testbench process? In my output assignment
process, I've defined a temp variable in which I'm storing the
glitching signal. I then wait for a handshaking signal before assigning
temp to the output (synchronously). Still with all this, 1ns-wide
glitches are visible on my output signal.
Thanks a lot,
-Manny
Article: 110256rohit.nadig@gmail.com wrote: > I am trying to implement a large design on a Xilnx FPGA (over 500,000 > gates). Spartan 3E seems like the best bet, but I wanted to ask around > before I ordered a board. I am considering a board by digilent > (http://www.digilentinc.com/). > > Can you please suggest: > > - A good starter board > - A good FPGA with lotsa real estate for my big design > > My budget is about $500 Your request is like asking what is the best cheese (a question of taste). ML401 exceeds your specs at the target price: http://xilinx.com/ml401 The most complete list is on http://fpga-faq.org/FPGA_Boards.shtml TommyArticle: 110257
On a clocked flip-flop (without any strange asynchronous inputs) there can never be a 1 ns glitch. You have either done something very strange, or you have a defective part (unlikely) Flip-flop outputs do not glitch, if clocked correctly. Could it be that you have a bad clock with glitching edges? Peter Alfke =============== Manny wrote: > As a matter of fact, it's a registered output. This is the weird thing > about it. There should be not glitches. My testbench is: > > real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns; > -- *** Test Bench - User Defined Section *** > tb : PROCESS > BEGIN > wait until (reset = '1'); > > for i IN 0 TO 2091 loop > filter_in <= real2hex(filter_in_force(i), 16.0); > real_in <= hex2real(filter_in, 16.0); > > table_in <= filter_in_force(i); > table_out <= filter_out_expected(i); > > wait until (clk_sampling = '0'); > end loop; > END PROCESS; > -- *** End Test Bench - User Defined Section *** > > filter_out is an already registered output. Is it because I've taken > real_out outside of the main testbench process? In my output assignment > process, I've defined a temp variable in which I'm storing the > glitching signal. I then wait for a handshaking signal before assigning > temp to the output (synchronously). Still with all this, 1ns-wide > glitches are visible on my output signal. > > Thanks a lot, > -MannyArticle: 110258
Manny wrote:
> As a matter of fact, it's a registered output. This is the weird thing
> about it. There should be not glitches. My testbench is:
Your testbench should be generating
a constant clock, say clk_s, and
waiting on the same clock *edges* like this:
wait until rising_edge(clk_s);
Your uut clock should be port mapped to
the same clk_s.
See the testbench here for details:
http://home.comcast.net/~mike_treseler/
-- Mike Treseler
Article: 110259Ok. I've just checked the netlist 'cause you guys got me worried. Everything is alright. That is, my output port is being clocked by the system's clock properly. The best explanation I could come up with is that individual output port bits have sort of delay mismatch and this is basically what's being manifested as glitches. I presume that after constraining things a bit tighter now, the glitches should be gone. What I meant to ask after all is the following: though post-PAR simulation shows glitches on the output, it doesn't necessarily mean that running design in hardware will fail? isn't it the case? Thanks a lot, -MannyArticle: 110260
Hi guys, I am currently in the process of looking for an internship position that will potentially start in May and end on Sept the following yr (16 months, but can be 12 months or 8 months). Now I am not asking you guys to do anything at all really. I am living in the Toronto, Ontario, Canada area and would like to stay there since I don't think I could stomach the costs of relocating temporarily (that is if I manage to secure a position, also its not fun living off Kraft Dinner either!). I am currently assembling a list of companies that I will "cold call" or e-mail to inquire about what opportunities they have. I am simply asking you if you work with a company that does embedded design (or some other technical stuff) work in Toronto or know of a company in Toronto that does this kind of work and would let me know? Thanks, IsaacArticle: 110261
Manny, you said that the output was registered. Now you imply that there might be gating between the register and the real output. A registered output will not glitch. A combinatorial output is very likely to glitch. Make up your mind... Peter Alfke ============== Manny wrote: > Ok. I've just checked the netlist 'cause you guys got me worried. > Everything is alright. That is, my output port is being clocked by the > system's clock properly. The best explanation I could come up with is > that individual output port bits have sort of delay mismatch and this > is basically what's being manifested as glitches. I presume that after > constraining things a bit tighter now, the glitches should be gone. > What I meant to ask after all is the following: though post-PAR > simulation shows glitches on the output, it doesn't necessarily mean > that running design in hardware will fail? isn't it the case? > > Thanks a lot, > -MannyArticle: 110262
Peter, from now on I should stop using the word glitch. There is no
gating and the design is synchronous. What I meant to say is the
following: starting from the flipflops, there are non-uniform delays
among the output of flipflops until reaching the output buffer pad
(routing-caused). Now I figured it out. I shouldn't be reading my
output as:
real_out <= hex2real(filter_out, 16.0)*4.0 after 2 ns;
I should even "synchronize" my testbench i.e. sampling my output from
within a process rather than allowing instantaneous propagation to be
reflected in simulation.
Thanks a lot for reasoning with me.
-Manny
Article: 110263
I've just did this:
tb : PROCESS
BEGIN
wait until (reset = '1');
for i IN 0 TO 2091 loop
filter_in <= real2hex(filter_in_force(i), 16.0);
real_in <= hex2real(filter_in, 16.0);
real_out <= hex2real(filter_out, 16.0)*4.0;
table_in <= filter_in_force(i);
table_out <= filter_out_expected(i);
hex_out <= real2hex(filter_out_expected(i),
16.0);
wait until (clk_sampling = '0');
end loop;
END PROCESS;
Basically, I relocated my "real_out <= hex2real(filter_out, 16.0)*4.0"
and everything is working smoothly now.
On a different note, is there a chance that I'd be able to fit a whole
RAKE receiver on a fusion device?
Thanks a lot,
Cheers,
-Manny
Article: 110264Manny, I have nothing to do with Actel. They are our competitor. I just helped you as a Good Samaritan. Peter ====================== Manny wrote: > I've just did this: > > tb : PROCESS > BEGIN > wait until (reset = '1'); > > for i IN 0 TO 2091 loop > filter_in <= real2hex(filter_in_force(i), 16.0); > real_in <= hex2real(filter_in, 16.0); > real_out <= hex2real(filter_out, 16.0)*4.0; > > table_in <= filter_in_force(i); > table_out <= filter_out_expected(i); > hex_out <= real2hex(filter_out_expected(i), > 16.0); > > wait until (clk_sampling = '0'); > end loop; > END PROCESS; > > Basically, I relocated my "real_out <= hex2real(filter_out, 16.0)*4.0" > and everything is working smoothly now. > > On a different note, is there a chance that I'd be able to fit a whole > RAKE receiver on a fusion device? > > Thanks a lot, > Cheers, > -MannyArticle: 110265
Peter, don't worry. I'd most probably end up supplementing a fusion with a spartan-3L. I think there is a no way in the world to fit complex DSP operations solely in soft fabric. It would be nice to boot up the spartan from the fusion's embedded flash and probably use their ADC also. It's just that the application is power critical and I'm not sure about how well spartan-3L would perform as a battery-powered device. Cheers, -MannyArticle: 110266
As mentioned by Antti, its not issue of uncompressing tar.gz or zip files, i am unable to get anything downloaded. just read the mesage that i get whenever i click on any link. i even wrote to webmaster, but its about a month ,and with 2 reminds, still no response from webmaster. Jon Beniston wrote: > avionion@gmail.com wrote: > > Hi Antti > > i am unable to get any download from lattice website and get the > > following message: > > "The file you have attempted to retrieve is not available at this time. > > > > We apologize for the inconvenience. > > > > If you continue to experience this difficulty, please contact the > > Webmaster" > > i have an account with lattice website as well. i am unable to download > > any zip or exe file but pdf files open correctly. anyone else facing > > this problem? any solution to it? > > The file you download is a tar.bz2, not zip or exe. You need to extract > it with: > > tar xjf src.tar.bz2 > > Cheers, > JonArticle: 110267
Isaac, you have made it clear that you do not want to relocate, but you have said nothing about your education, experience, or skills. Don't you think that matters? Peter Alfke, from home Isaac Bosompem wrote: > Hi guys, > > I am currently in the process of looking for an internship position > that will potentially start in May and end on Sept the following yr (16 > months, but can be 12 months or 8 months). Now I am not asking you guys > to do anything at all really. I am living in the Toronto, Ontario, > Canada area and would like to stay there since I don't think I could > stomach the costs of relocating temporarily (that is if I manage to > secure a position, also its not fun living off Kraft Dinner either!). > > I am currently assembling a list of companies that I will "cold call" > or e-mail to inquire about what opportunities they have. > > I am simply asking you if you work with a company that does embedded > design (or some other technical stuff) work in Toronto or know of a > company in Toronto that does this kind of work and would let me know? > > > Thanks, > > IsaacArticle: 110268
Peter Alfke wrote: > Isaac, you have made it clear that you do not want to relocate, but you > have said nothing about your education, experience, or skills. Don't > you think that matters? > Peter Alfke, from home > > Isaac Bosompem wrote: >> * snip * Hi Peter, Yes that is important information. I apologize for not including it. I am currently in my 3rd year of Electrical Engineering undergrad at Ryerson University in Toronto, Ontario, Canada. The internship (if acquired) is slated to start right after this academic year. This effectively delays my graduation by 1 yr, but I think that is a really small price to pay for the experience. Here is a rudimentary list of my skills, a more thorough one will be submitted w/ my resume: Programming Languages: C, Java, Visual Basic, Assembly, Win32 programming, Python Compilers/Environment: GNU tools, Microsoft Visual Studio Microprocessors/Microcontrollers: M680x0, Z80, x86, 8051, PIC, MSP430, ARM7, HC11, Renesas SuperH series proemulator.sf.net I ported my Z80 emulator to this app some time ago. My M68000 emulator is working and is tested to be quite accurate, but the author no longer maintains it or updates it so I decided against porting it (even though I can still get into the CVS). Programmable Logic: Xilinx Spartan3 series FPGA w/ Xilinx ISE WebPack I designed a simple VGA frambuffer 320x240x2-bit and a simplistic 16-bit CPU in VHDL. Electronics: Basic analog electronics (FET's, OpAmps, BJT's, etc.) Here all I did was some school projects. Simple stuff: VCO's, FET amps, etc. Operating Systems: Linux, MS-DOS, Windows (effective w/ all). Been doing installs on all OS's for quite some time now. Used MS-DOS while I was growing up (had it first running on a 16Mhz 386SX). Most the stuff I have learned was from buying products containing the previously mentioned items and playing around with them and their associated tools and reading my dads old college books (he studied electronics engineering technology at NAIT. They did extensive course work in digital electronics). I really do not have any related engineering experience. I did work for GO Transit this past summer, a major transportation company here in Ontario, as general help. I was called on one day to look over some computer scans of microfilm schematics of the trains (and electrical systems) to make sure they were up to par. I would like to shadow some teams in the engineering sector to get a feel of what you guys do in the industry. I would like to see how you guys solve problems, tackle issues or shortcomings you come up in development and the like. I'd also like to learn from the people working in this industry in general since they have a wealth of knowledge and experience. Sometthing I think can be invaluable to me in my career. They have some listings at my school, but they are not exactly what I am interested in. Thanks for listening to my story! Any companys you know of in Toronto? I know Altera has some offices here. Might try and get a hold of them later on. -IsaacArticle: 110269
Isaac Bosompem wrote: > ... snip ... > > I am currently in my 3rd year of Electrical Engineering undergrad > at Ryerson University in Toronto, Ontario, Canada. The internship > (if acquired) is slated to start right after this academic year. > This effectively delays my graduation by 1 yr, but I think that is > a really small price to pay for the experience. I am surprised to see Ryerson classified as a university. In my student days it was a first class technical school, but definitely not a university. No deprecation intended, my student days preceded transistors. ... snip impressive list of student achievements ... -- Some informative links: <news:news.announce.newusers <http://www.geocities.com/nnqweb/> <http://www.catb.org/~esr/faqs/smart-questions.html> <http://www.caliburn.nl/topposting.html> <http://www.netmeister.org/news/learn2quote.html> <http://cfaj.freeshell.org/google/>Article: 110270
Manny, I think I have already shown that am not too parochial... For complex DSP you are better off with Virtex-4 or -5 devices that have many poweful and fast multiplier-accumulator blocks. All high-performance FPGAs have fairly high leakage current, so make sure that you use the smallest possible device = least leakage. Peter Alfke, from home. On Oct 12, 6:07 pm, "Manny" <mlou...@hotmail.com> wrote: > Peter, don't worry. I'd most probably end up supplementing a fusion > with a spartan-3L. I think there is a no way in the world to fit > complex DSP operations solely in soft fabric. It would be nice to boot > up the spartan from the fusion's embedded flash and probably use their > ADC also. It's just that the application is power critical and I'm not > sure about how well spartan-3L would perform as a battery-powered > device. > > Cheers, > -MannyArticle: 110271
> You can try: > http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html This calculator is very good. Thanks for it. Also do you have any idea for polarization???Article: 110272
Rojit I will of course suggest one of our boards - Raggedstone1 - either RS1-400 (400,000) circa $95 or RS1-1500 (1,500,000) circa $270 ($165 student). If want to run this board on the bench then add the PCI I/O adaptor to give 50 5V tolerant I/O at $30 (with board purchase). Shipping is $19 (low cost) or if you are in a hurry FEDEX (usually next day to the US, EEC etc if we get order by about 10.00am GMT) $38. The RS1-1500 has a XC3S1500 which is about the biggest Spartan device supported under ISE Webpack except perhaps a XC3S1600E but that's a close call. Other things we have to consider is our OVERCOAT option where for your budget we can might just about do a small array of Raggedstone1's. This can increase your effective size of the logic you have available but of course is split between several devices. This a build to order option and does have a lead time although we are looking at having a small stock of these on the next build run within the next few weeks. There are other offerings in our product range that will probably reach into your price bracket and do brouse our website for their details. If you are are a student look at our University Access Program (UAP) webpage for details on board discounts. Big green button on our index page is the way in. John Adair Enterpoint Ltd. rohit.nadig@gmail.com wrote: > Dear Comrades, > > I am trying to implement a large design on a Xilnx FPGA (over 500,000 > gates). Spartan 3E seems like the best bet, but I wanted to ask around > before I ordered a board. I am considering a board by digilent > (http://www.digilentinc.com/). > > Can you please suggest: > > - A good starter board > - A good FPGA with lotsa real estate for my big design > > My budget is about $500 > > Thanks a bunch, > RohitArticle: 110273
Analog_Guy wrote: > > > >Eli Bendersky wrote: > > > > What does this technique lack to be the perfect solution for resets in > > FPGA designs ? It seems that it evades all the common disadvantages of > > conventional sync and async resets. > > > > > The only thing I see that this technique lacks is the ability to filter > (for noise, glitches) > the incoming reset signal. This approach can filter on the LO-HI > transition of reset, > but not on the HI-LO assertion. > > So, if there is any noise or glitching on the reset input resulting in > a HI-LO transition, all > logic in the FPGA is instantly reset (i.e. asynchronous reset). Most > designs I work with > use some form of analog circuitry to provide the main reset to the > FPGA. > > I do like the fact that reset will be applied even in the absence of a > clock. However, I have not yet implemented this technique because I am > not sure how to provide filtering on the HI-LO transition of the input > reset signal without requiring a clock. Can anyone help with this? > What are your ideas? This isn't different from the "normal" async reset, however, where the reset signal isn'f filtered. The solution usually used is an external reset circuit (they come packed in nice tiny ICs these days) that provides a clean reset signal of 200 ms (or whatever you set it to) whenever there's a problem with the supplies, and as a byproduct, when the power is going up. EliArticle: 110274
Jim Unfortunately we haven't purchased the jtag debugger option where you can manually tri-state and read the state of pins so injecting my own levels is not easy. However your quite right, it is fast coming to this and I am going to end up with adding a couple of 0R resistors so that I can remove them and drive the net myself. Colin Jim Granville wrote: > colin wrote: > > > Jim > > > > I'm using a coolrunner II (which I said in my first email). > > I think they are the only CPLDs that support SSTL but if anyone knows > > of another familly then I'd love to take a look. > > > > I'm fairly certain that the IO config isn't removed during boundary > > scan because I can read the functional state of pins using JTAG and so > > can chipscope for FPGAs. > > Failing a definitive reply from Xilinx, you could always just test it ? > IP threshold is a fairly easy thing to check, especially if you have > all the read-pathway working. > > -jg
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