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
Does a ML301 has a video DAC? Opencores VGA/LCD controller needs three 8 bit DACs!!!!. Guru Guru wrote: > Oh yes, I forgot one more thing: > > FPGA->VGA OPB bus driver was included in the Spartan3 starter kit Xpong > project - opb_color_video_ctrl_v1_00_a. > > Cheers, > > Guru > > > fpganovice wrote: > > Hi all, > > > > I'm working on an FPGA implementation of an image processing algorithm. > > I'll be using the ML401 to do the job which has DDR memory and a VGA > > port to output the image directly on screen. Should I go with a > > microblaze solution? EDK comes with DDR and VGA controllers for this > > board, however I'm not at all familiar with it regarding the buses and > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the > > memory controller and I've also found a VGA/LCD display module on > > opencores.org. So both solutions seem viable to me (or do they not?), > > which path should I choose? Please comment. Thanks!Article: 106751
Sudhir.Singh@email.com wrote: > check out > http://www.itee.uq.edu.au/~peters/xsvboard/stack/stack.htm > > David wrote: > > hi > > i am new whit FPGA i just buy the spartan-3e starter kit, > > i am looking a tcp/ip stack to use whit the kit ( a free one) > > if any one have some info it will we great > > thanks > > David In Xilinx XPS, there is a free TCP/IP stack included, as far as I remember. You can simply add it by a few mouse clicks.Article: 106752
Microblaze is not so fast but why not to design microblaze plus some hardware accelerators. It could be fast enough and easy to design, I suppose. /Wayne Guru wrote: > Hi fpganovice, > > Forget about MicroBlaze, you will never get the desired speed. Image > processing should be done in logic ONLY. Try to figure out how you can > serialize your processing algorithm to work pixel-to-pixel. This way > you probably won't even need a DDR. > > There is also a Xilinx thing called Multi Port Memory Controller 2 > which has a fast interface to DDR, PowePC and GigaLAN. PLB_LCD (native > LCD) controller is also included in the project cores. The only > drawback is that it consumes a lot of logic, which you can use for > image processing. > > Cheers, > > Guru > > fpganovice wrote: > > Hi all, > > > > I'm working on an FPGA implementation of an image processing algorithm. > > I'll be using the ML401 to do the job which has DDR memory and a VGA > > port to output the image directly on screen. Should I go with a > > microblaze solution? EDK comes with DDR and VGA controllers for this > > board, however I'm not at all familiar with it regarding the buses and > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the > > memory controller and I've also found a VGA/LCD display module on > > opencores.org. So both solutions seem viable to me (or do they not?), > > which path should I choose? Please comment. Thanks!Article: 106753
Mark McDougall kirjoitti: > Martin Schoeberl wrote: > > > And for the SOPC builder all information > > is in the .ptf. > > Ah yes, indeed! However, we'll strategically overlook mentioning NIOS > IDE projects and the !@#*@&^#%$% workspace... ;) > > Regards, > > -- > Mark McDougall, Engineer I save these project files into repository. .cdtbuild .cdtproject .project application.stf My problem is related to Linked Resources, since I use variables to define location of some common files. And value of Linked Resources is hidden in user !@#*@&^#%$% workspace. AnttiArticle: 106754
Evan Lavelle wrote: > On Thu, 17 Aug 2006 11:04:44 -0500, "RCIngham" > <robert.ingham@smiths-aerospace.com> wrote: > > >>I suspect that the Xilinx core is fixed-point, and handles the data growth >>that happens during a FFT in some manner described in its documentation. If >>it doesn't, then don't use it. > > > It's fixed-point (vfft32 is, anyway). It does bit growth, but you have > to handle the extra bits yourself. > > >>You could use a number representation such as Q1.15 that handles numbers >>in the range -1.0 to +1.0, and do scaling at each pass of the FFT. > > > This is actually no better than an integer representation - if you > start with Q1.15, then you have to extend to Q1.18, or whatever, after > the first pass, and so on. > > Fixed-point FFTs are pretty useless. If you've got a small dynamic > range in the input, then you'll have a large dynamic range in the > output. Coding a floating-point adder and multiplier is probably a lot > easier than understanding the limitations of a fixed-point FFT and > using it effectively. > > Evan Fixed point FFTs are fine for many applications. Whether it is suitable for yours depends on many factors including the size of the FFT. There is a potential growth of N for an N point FFT. The FFT conserves energy, so if the input has frequency components that all fall in the same FFT bin, the output for that bin will be N times the input amplitude. If the input is wideband, then the output is spread over all the bins, so the output amplitude is closer to the input amplitude. Often, we know ahead of time the nature of the input signal, so we can do a fixed scaling of the FFT results and wind up with the same number of input bits and output bits. Other times, we know less about the application and need to handle the full range of possible inputs, or perhaps we are interested in the frequency bins that don't contain the dominant signal. In those cases we either need to accommodate a wider FFT output (fixed point), or need to resort to floating point. Make no bones about it, floating point arithmetic is expensive in terms of amount of logic. There are some shortcuts for FFTs that will increase the dynamic range without going to a full floating point implementation. The most common is to use block floating point which rescales the entire FFT result by a common power of 2 selected so that the largest signal does not overflow. Block floating point is typically applied after each FFT stage, and is an effective way to limit the word widths without resorting to floating point arithmetic. The generally available FFT cores are all fixed point. Technically speaking, fixed point is more accurate than floating point; the problem with fixed point is that you need a lot of bits to express a large dynamic range. Floating point is a compromise that dynamically rescales the data as it is processed in order to reduce the number of bits requried to represent a number, at the price of some accuracy. Fixed point design does require the designer to pay more attention in the system design to ensure the scaling is correct at each stage. In most cases however it is feasible and is less complexity than an equivalent floating point design. The windowing does not need floating point, but you do have to get familiar with fractional fixed point notation. (basically your window funtion is integers from 0 to say 65535 for 16 bit unsigned that represent 0 to 65535/65536 with an implied scaling of 2^-16. All you need is a multplier and a ROM to implement it.Article: 106755
I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not recognize the part as a device primitive. Primitives are normal shown in red text under ISE but when I block copy the part from the language template the DSP48E is shown in black text and ISE does not know it is a primitive. I have a V5LX50 selected as the device I am using. I have also had the same problem instantiating a RAMB36 and a PLL_ADV. Does anyone know how to do this successfully?Article: 106756
Ray Andraka schrieb: > Evan Lavelle wrote: > Fixed point FFTs are fine for many applications. Whether it is suitable > for yours depends on many factors including the size of the FFT. There > is a potential growth of N for an N point FFT. The FFT conserves > energy, so if the input has frequency components that all fall in the > same FFT bin, the output for that bin will be N times the input > amplitude. If the input is wideband, then the output is spread over all > the bins, so the output amplitude is closer to the input amplitude. > Often, we know ahead of time the nature of the input signal, so we can > do a fixed scaling of the FFT results and wind up with the same number > of input bits and output bits. Other times, we know less about the > application and need to handle the full range of possible inputs, or > perhaps we are interested in the frequency bins that don't contain the > dominant signal. In those cases we either need to accommodate a wider > FFT output (fixed point), or need to resort to floating point. Also, it is not clear whether you gain anything by floating point because you need the high dynamic range in the signifcand anyway. Lets say you have 2**N values of M bits that you sum up. (that is essentially what happens inside an FFT) It turns out that you need N+M bits to represent the result fixed point. Now assume that you think that N+M is to large and you want to get by with smaller multipliers by using floating point that has a significand resolution of S << N+M. Once you added up the first half of your values all subsequent values will be scaled down by a factor of N-1 before adding them to the result. This means that only the S-N+1 most significant bits of the inputs are used. To avoid that you need S>>N. As soon as S gets about as large as N+M you might as well use fixed point because a fixed point solution with N+M bits will get you all the dynamic range that you need and the N+M fixed point logic is included in the floating point solution as a building block anyway. Also note: A floating point unit with N+M bit signifiand needs a (N+M) by (N+M) multiplier. A fixed point FFT would only use a N by N multiplier with N+M accumulator. Kolja Sulimma (BTW: << means "much smaller than" and not a left shift)Article: 106757
Kolja Sulimma wrote: > Ray Andraka schrieb: > >>Evan Lavelle wrote: > > >>Fixed point FFTs are fine for many applications. Whether it is suitable >>for yours depends on many factors including the size of the FFT. There >>is a potential growth of N for an N point FFT. The FFT conserves >>energy, so if the input has frequency components that all fall in the >>same FFT bin, the output for that bin will be N times the input >>amplitude. If the input is wideband, then the output is spread over all >>the bins, so the output amplitude is closer to the input amplitude. >>Often, we know ahead of time the nature of the input signal, so we can >>do a fixed scaling of the FFT results and wind up with the same number >>of input bits and output bits. Other times, we know less about the >>application and need to handle the full range of possible inputs, or >>perhaps we are interested in the frequency bins that don't contain the >>dominant signal. In those cases we either need to accommodate a wider >>FFT output (fixed point), or need to resort to floating point. > > > Also, it is not clear whether you gain anything by floating point > because you need the high dynamic range in the signifcand anyway. > > Lets say you have 2**N values of M bits that you sum up. (that is > essentially what happens inside an FFT) > It turns out that you need N+M bits to represent the result fixed point. > > Now assume that you think that N+M is to large and you want to get by > with smaller multipliers by using floating point that has a significand > resolution of S << N+M. Once you added up the first half of your values > all subsequent values will be scaled down by a factor of N-1 before > adding them to the result. This means that only the S-N+1 most > significant bits of the inputs are used. > To avoid that you need S>>N. As soon as S gets about as large as N+M you > might as well use fixed point because a fixed point solution with N+M > bits will get you all the dynamic range that you need and the N+M fixed > point logic is included in the floating point solution as a building > block anyway. > > Also note: > A floating point unit with N+M bit signifiand needs a (N+M) by (N+M) > multiplier. > A fixed point FFT would only use a N by N multiplier with N+M accumulator. > > Kolja Sulimma > > (BTW: << means "much smaller than" and not a left shift) I tried to allude to that fact, but reading over my post I see I missed the point. Our floating point FFT takes advantage of this fact. It uses fixed a small fixed (4/8/16 point) point kernel and normalizes the input set to a common exponent before passing it through the kernel,and then denormalizes the intermediate result before storing it. In essence it has a coarser granularity of floating point operators. Accuracy matches a full floating point implementation but the implementation uses a fraction of the hardware of a full floating point implementation.Article: 106758
MM wrote: > I think his problem has more to do with some paths being unconstrained since > the reported frequency itself meets the constraint. You can get a timing report that includes unconstrained path analysis. In the properties for "generate post-place & route static timing" set "report uncovered paths" to some reasonably large number like 100. Then the timing report will have lots of lines like "unconstrained period for clock xxx", "unconstrained In Before for clock xxx", etc. This may shed some light on the problem you get in some builds. Also the OP mentioned Synplify. This can reduce your logic size significantly, especially if you're running an older version of XST. I've noticed that XST 8.1i is significantly better than XST 6.1i for meeting area constraints on some projects. This improvement can be quite significant if the source is not written with synthesis optimization in mind. Regards, GaborArticle: 106759
jeffnewcomb@nci-usa.com wrote:
>I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not
>recognize the part as a device primitive. Primitives are normal shown
>in red text under ISE but when I block copy the part from the language
>template the DSP48E is shown in black text and ISE does not know it is
>a primitive. I have a V5LX50 selected as the device I am using. I have
>also had the same problem instantiating a RAMB36 and a PLL_ADV. Does
>anyone know how to do this successfully?
>
>
>
try
LIBRARY UNISIM;
USE UNISIM.Vcomponents.ALL;
(assuming VHDL)
Aurash
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 106760Unfortunately I am using Verilog as my HDL. Aurelian Lazarut wrote: > jeffnewcomb@nci-usa.com wrote: > > >I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not > >recognize the part as a device primitive. Primitives are normal shown > >in red text under ISE but when I block copy the part from the language > >template the DSP48E is shown in black text and ISE does not know it is > >a primitive. I have a V5LX50 selected as the device I am using. I have > >also had the same problem instantiating a RAMB36 and a PLL_ADV. Does > >anyone know how to do this successfully? > > > > > > > try > LIBRARY UNISIM; > USE UNISIM.Vcomponents.ALL; > (assuming VHDL) > Aurash > > > -- > __ > / /\/\ Aurelian Lazarut > \ \ / System Verification Engineer > / / \ Xilinx Ireland > \_\/\/ > > phone: 353 01 4032639 > fax: 353 01 4640324Article: 106761
Ray Andraka <ray@andraka.com> wrote: >Evan Lavelle wrote: >> On Thu, 17 Aug 2006 11:04:44 -0500, "RCIngham" >> <robert.ingham@smiths-aerospace.com> wrote: >> >> >>>I suspect that the Xilinx core is fixed-point, and handles the data growth >>>that happens during a FFT in some manner described in its documentation. If >>>it doesn't, then don't use it. >> >> >> It's fixed-point (vfft32 is, anyway). It does bit growth, but you have >> to handle the extra bits yourself. >> >> >>>You could use a number representation such as Q1.15 that handles numbers >>>in the range -1.0 to +1.0, and do scaling at each pass of the FFT. >> >> >> This is actually no better than an integer representation - if you >> start with Q1.15, then you have to extend to Q1.18, or whatever, after >> the first pass, and so on. >> >> Fixed-point FFTs are pretty useless. If you've got a small dynamic >> range in the input, then you'll have a large dynamic range in the >> output. Coding a floating-point adder and multiplier is probably a lot >> easier than understanding the limitations of a fixed-point FFT and >> using it effectively. >> >> Evan > > >Fixed point FFTs are fine for many applications. Whether it is suitable >for yours depends on many factors including the size of the FFT. There >is a potential growth of N for an N point FFT. The FFT conserves >energy, so if the input has frequency components that all fall in the >same FFT bin, the output for that bin will be N times the input >amplitude. If the input is wideband, then the output is spread over all >the bins, so the output amplitude is closer to the input amplitude. >Often, we know ahead of time the nature of the input signal, so we can >do a fixed scaling of the FFT results and wind up with the same number >of input bits and output bits. Other times, we know less about the >application and need to handle the full range of possible inputs, or >perhaps we are interested in the frequency bins that don't contain the >dominant signal. In those cases we either need to accommodate a wider >FFT output (fixed point), or need to resort to floating point. > >Make no bones about it, floating point arithmetic is expensive in terms >of amount of logic. There are some shortcuts for FFTs that will >increase the dynamic range without going to a full floating point >implementation. The most common is to use block floating point which >rescales the entire FFT result by a common power of 2 selected so that >the largest signal does not overflow. Block floating point is typically >applied after each FFT stage, and is an effective way to limit the word >widths without resorting to floating point arithmetic. Depending on the use of the result, it may be an option to compress the input with a log function. This will decrease the number of bits considerably to achieve a certain dynamic range (more or less like ulaw / alaw compression used in digital telephony). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106762
"agou" <agou.win@gmail.com> wrote: >Hi, there > >We are using a XUP board to implement an algorithm on FPGA right now. >Our design is pretty big on the chip. The device utilization summary is >listed as follows: > >Logic Utilization: > Number of Slice Flip Flops: 15,413 out of 27,392 56% > Number of 4 input LUTs: 15,218 out of 27,392 55% >Logic Distribution: > Number of occupied Slices: 12,892 out of 13,696 94% > Number of Slices containing only related logic: 12,892 out of >12,892 100% > Number of Slices containing unrelated logic: 0 out of >12,892 0% > *See NOTES below for an explanation of the effects of unrelated >logic > >Ever since our design grew big, some weird results appeared. And if we >tried different Placer cost table in the fast_runtime.opt, we got >different results. Sometimes good ones. If we optimized the design, and >then shrinked it a little bit, then we could get good result without >trying difference cost tables. We defined the "good result" by seeing >when the maximum frequency reached 100MHz which is what we are running >at. > >But now, the frequency reached 101.843 MHz, the weird result still >appeared. Every time I run the code, we got different result. THe >simulation is just fine. > >I don't really know what to do next now. I thought we shrinked the >design as much as possible. > >So anyone has any idea? Is it possible to use Synplify which is said to >be better? Will it improve a lot? I have that problem every now and then. Sometimes it is due to unconnected logic, other times changing the optimisation helps to get the design routed. Very frustrating indeed. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106763
jeffnewcomb@nci-usa.com schrieb:
> I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not
> recognize the part as a device primitive. Primitives are normal shown
> in red text under ISE but when I block copy the part from the language
> template the DSP48E is shown in black text and ISE does not know it is
> a primitive. I have a V5LX50 selected as the device I am using. I have
> also had the same problem instantiating a RAMB36 and a PLL_ADV. Does
> anyone know how to do this successfully?
if you cant use in verilog then just open a new schematic, place the
DSP48E there
add wires make wrapper and use from verilog code! defenetly works
Device Utilization Summary:
Number of DSP48Es 1 out of 48 2%
Number of External IOBs 2 out of 220 1%
Number of LOCed IOBs 0 out of 2 0%
Number of Slice Flip Flops 0 out of 28800 0%
Number of Slice LUTS 0 out of 28800 0%
Number of Slice LUT-Flip Flop pairs 0 out of 28800 0%
well at least with 8.2 (no SP)
Antti
Article: 106764Hi Wayne, This is what I was originally thinking. I already have a VHDL module for image processing pixel-by-pixel. So I was thinking of integrating it with the microblaze and use the DDR and VGA controllers that come with the microblaze design. quickwayne@gmail.com wrote: > Microblaze is not so fast but why not to design microblaze plus some > hardware accelerators. It could be fast enough and easy to design, I > suppose. > > /Wayne > > Guru wrote: > > Hi fpganovice, > > > > Forget about MicroBlaze, you will never get the desired speed. Image > > processing should be done in logic ONLY. Try to figure out how you can > > serialize your processing algorithm to work pixel-to-pixel. This way > > you probably won't even need a DDR. > > > > There is also a Xilinx thing called Multi Port Memory Controller 2 > > which has a fast interface to DDR, PowePC and GigaLAN. PLB_LCD (native > > LCD) controller is also included in the project cores. The only > > drawback is that it consumes a lot of logic, which you can use for > > image processing. > > > > Cheers, > > > > Guru > > > > fpganovice wrote: > > > Hi all, > > > > > > I'm working on an FPGA implementation of an image processing algorithm. > > > I'll be using the ML401 to do the job which has DDR memory and a VGA > > > port to output the image directly on screen. Should I go with a > > > microblaze solution? EDK comes with DDR and VGA controllers for this > > > board, however I'm not at all familiar with it regarding the buses and > > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the > > > memory controller and I've also found a VGA/LCD display module on > > > opencores.org. So both solutions seem viable to me (or do they not?), > > > which path should I choose? Please comment. Thanks!Article: 106765
I'm using an ML401. It does have a DAC from analog device. Guru wrote: > Does a ML301 has a video DAC? Opencores VGA/LCD controller needs three > 8 bit DACs!!!!. > > Guru > > > > Guru wrote: > > Oh yes, I forgot one more thing: > > > > FPGA->VGA OPB bus driver was included in the Spartan3 starter kit Xpong > > project - opb_color_video_ctrl_v1_00_a. > > > > Cheers, > > > > Guru > > > > > > fpganovice wrote: > > > Hi all, > > > > > > I'm working on an FPGA implementation of an image processing algorithm. > > > I'll be using the ML401 to do the job which has DDR memory and a VGA > > > port to output the image directly on screen. Should I go with a > > > microblaze solution? EDK comes with DDR and VGA controllers for this > > > board, however I'm not at all familiar with it regarding the buses and > > > stuff. If I use ISE only, I'll probably use MIG 1.5 to generate the > > > memory controller and I've also found a VGA/LCD display module on > > > opencores.org. So both solutions seem viable to me (or do they not?), > > > which path should I choose? Please comment. Thanks!Article: 106766
Hi Louis, I'm also currently working with the UC2, but on a Virtex-II Pro. First of all, make sure to replace some files as indicated in Answer Record #23011: http://tinyurl.com/e7c2g I also just solved a bug with the UC2 design on the Virtex-II Pro (I spent a week on it). It turns out that the file uc2.ngc is buggy. There is no error given by Xilinx tools however (which made is quite hard to debug), but the resulting bit file cannot be programmed in the FPGA (programming fails in Impact). The solution is to not use uc2.ngc at all and instead use uc2.vhd, also provided in the reference design. I don't know if the reference design for the V4 has the same issue though... Best of luck, Patrick Dubois louis lin wrote: > Has anyone tried Ultracontroller PROM solution of V4 in EDK 8.1i? > > The reference example is built by EDK 7.1i. > I went through the flow again in ISE 8.1 SP3 + EDK 8.1i SP2. > However, the resultant MCS can't program the XC4VFX12 properly > (DONE LED didn't go high). > > After I got the reference, I only added the -nostartfiles compiler option to > fix > the multiple _start problem. > > Regards, > louisArticle: 106767
If you are using Xilinx tools, your should be able to produce .xsvf files,
and use them following the information in
http://direct.xilinx.com/bvdocs/appnotes/xapp058.pdf
I have usefully programmed Spartan-3s, but have not gotten to the xcf
programming part. Documentation says it should work.
JimT
"Evan Lavelle" <eml@nospam.uk> wrote in message
news:mq96e25imfqlfgotehqod50u2hkf4kmj23@4ax.com...
> Does anyone know of any open-source software which will program an
> XCF04S (Xilinx serial PROM) on JTAG? It also needs to issue a CONFIG
> command to start configuration.
>
> Thanks -
>
> Evan
Article: 106768Martin Schoeberl wrote: > JOP at 100MHz on the Altera DE2 using the 16-bit SRAM: > > Avalon: 11,322 > SimpCon: 14,760 > > So for the SRAM interface SimpCon is a clear winner ;-) > The 16-bit SRAM SimpCon solution is even faster than > the 32-bit SRAM Avalon solution. I'm not sure what your point is. It's hardly surprising that a JOP works better with the interface it was codesigned with, rather than some other one crafted on top. It says nothing is the relative merits of Avalon and SimpCon. I could code up a counter example quite easily. Altera has an App note on "Using Nios II Tightly Coupled Memory Tutorial" (http://altera.com/literature/tt/tt_nios2_tightly_coupled_memory_tutorial.pdf), but as far as I understand you, this is already how you use the memory. I noticed you didn't reply to how SimpCon doesn't scale. Does your silence mean that you see it now? :-) TommyArticle: 106769
I think this is just a display issue. If the backend tools know dsp48e is a primitive, why bother if the text is shown in red or black? HTH, Jim http://home.comcast.net/~jimwu88/tools/ jeffnewcomb@nci-usa.com wrote: > I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not > recognize the part as a device primitive. Primitives are normal shown > in red text under ISE but when I block copy the part from the language > template the DSP48E is shown in black text and ISE does not know it is > a primitive. I have a V5LX50 selected as the device I am using. I have > also had the same problem instantiating a RAMB36 and a PLL_ADV. Does > anyone know how to do this successfully?Article: 106770
Hi guys! I'm experiencing same problems with don't care conditions in VHDL (with ISE / ModelSim)... I'm wondering if using don't cares in VHDL is a safe practice, since it seems that different tools treat them in different ways! For example, if I test "1110 0010" against "---- 0010" (with if, case, when and so on...) I expect to obtain a match, since the four specified bits are the same. The ISE (and maybe Synplify) seems to behave as expected when synthesizing the design, but ModelSim (behavioral sim.) does not recognize the two strings as the same (they are both std_logic_vector signals or constants). Is there somthing wrong I'm doing? It is better to avoid using don't cares at all? Ther is some kind of "workaround" to obtain the expected behaviour with ModelSim?!? Thanks, AntonioArticle: 106771
I wish this was just a display issue but the ISE does not recognize this as a legal primitive and show a question mark in the sources window for the DSP48E. Synthesis will not complete without errors. Jim Wu wrote: > I think this is just a display issue. If the backend tools know dsp48e > is a primitive, why bother if the text is shown in red or black? > > HTH, > Jim > http://home.comcast.net/~jimwu88/tools/ > > jeffnewcomb@nci-usa.com wrote: > > I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not > > recognize the part as a device primitive. Primitives are normal shown > > in red text under ISE but when I block copy the part from the language > > template the DSP48E is shown in black text and ISE does not know it is > > a primitive. I have a V5LX50 selected as the device I am using. I have > > also had the same problem instantiating a RAMB36 and a PLL_ADV. Does > > anyone know how to do this successfully?Article: 106772
> > Guru wrote: > > > Forget about MicroBlaze, you will never get the desired speed. Image > > > processing should be done in logic ONLY. Try to figure out how you can > > > serialize your processing algorithm to work pixel-to-pixel. This way > > > you probably won't even need a DDR. Without any performance criteria, this is absolutely meaningless advice. fpganovice wrote: > quickwayne@gmail.com wrote: > > Microblaze is not so fast but why not to design microblaze plus some > > hardware accelerators. It could be fast enough and easy to design, I > > suppose. > > This is what I was originally thinking. I already have a VHDL module > for image processing pixel-by-pixel. So I was thinking of integrating > it with the microblaze and use the DDR and VGA controllers that come > with the microblaze design. Processors can be very useful. Don't overlook the fact that one can use the EDK without having a processor in the system. We do this with a lot of our image processing systems. The automation that this tool provides for mixing and matching IP modules with buses can be extremely useful in any data processing application. A reference design for this board employing the MicroBlaze processor can be used as a starting point. The processor can be removed, and an OPB bus master interface attached to your existing IP can be put in its place. Xilinx has gone to a lot of effort on the IPIF package, but it has been our experience here that if you start with CoreConnect documents from IBM it will be easier to just attach your IP directly to the OPB bus rather than through the IPIF. To start, just do single 32bit reads and single 32bit writes per bus transaction. Think of this as a sort of a "hello world", to prove that you have the basics of EDK, the PAO and MPD files and the OPB bus down. Then it will be only a minor effort to move to burst transfers. With single reads you moght find that you only get 25% bus utilization. With longer bursts you can easily get 90%+. The other sugggestion I would make relates to the architecture of your module. If you use a BlockRam with a 32bit port to attach to the OPB bus, and an 8bit (pixel width) port to attach to you IP, your IP and the bus can run asynchronously to each other (i.e. at arbitrary clock rates) and your IP does not need to know how to do anything other than handle one pixel at a time, even if you perform burst transfers. The state machines that run your OPB interface and you processing IP each need to pass a strobe to the other when it has written a burst of pixels it wants the other side to handle. Flow control is easily handled this way. The fifo mode of the Virtex4 BlockRam does not allow for different port sizes. I wish it did. I remember having a rather heated conversation with Peter regarding this at a Xilinx gathering a few years back. It would be particularly nice for all kinds of serial/parallel conversion from bit to pixel, pixel to word, or bit to many pixels in parallel, etc. While it might take less resource to do the width conversion and use the fifo, than to implement the burst counters and not use the fifo, the later does have one added benefit. One can fit two fifos, one in each direction, into a single blockram. Haven't yet looked at the blockrams in fifo mode in V5 yet - as all of our active designs are V4 for the rest of the year. Anybody care to comment if different port widths are supported? Regards, Erik. --- Erik Widding President Birger Engineering, Inc. (mail) 100 Boylston St #1070; Boston, MA 02116 (voice) 617.695.9233 (fax) 617.695.9234 (web) http://www.birger.comArticle: 106773
This is probably caused by something else as I just tried the code
below and it works fine. Try to check the file encoding and make sure
there is no weird characters in the file. I have seen problems with
copying templates from PDF file.
module top(a_in, b_in, p_out);
input [15:0] a_in;
input [15:0] b_in;
output [31:0] p_out;
DSP48E #(
.ACASCREG(1), // Number of pipeline registers between A/ACIN
input and ACOUT output, 0, 1, or 2
.ALUMODEREG(1), // Number of pipeline registers on ALUMODE
input, 0 or 1
.AREG(1), // Number of pipeline registers on the A input,
0, 1 or 2
.AUTORESET_PATTERN_DETECT("FALSE"), // Auto-reset upon pattern
detect, "TRUE" or "FALSE
.AUTORESET_PATTERN_DETECT_OPTINV("MATCH"), // Reset if "MATCH" or
"NOMATCH
.A_INPUT("DIRECT"), // Selects A input used, "DIRECT" (A port) or
"CASCADE" (ACIN port)
.BCASCREG(1), // Number of pipeline registers between B/BCIN
input and BCOUT output, 0, 1, or 2
.BREG(1), // Number of pipeline registers on the B input,
0, 1 or 2
.B_INPUT("DIRECT"), // Selects B input used, "DIRECT" (B port) or
"CASCADE" (BCIN port)
.CARRYINREG(1), // Number of pipeline registers for the CARRYIN
input, 0 or 1
.CARRYINSELREG(1), // Number of pipeline registers for the
CARRYINSEL input, 0 or 1
.CREG(1), // Number of pipeline registers on the C input,
0 or 1
.MASK(48'h3fffffffffff), // 48-bit Mask value for pattern detect
.MREG(1), // Number of multiplier pipeline registers, 0 or
1
.MULTCARRYINREG(1), // Number of pipeline registers for multiplier
carry in bit, 0 or 1
.OPMODEREG(1), // Number of pipeline registers on OPMODE input,
0 or 1
.PATTERN(48'h000000000000), // 48-bit Pattern match for pattern
detect
.PREG(1), // Number of pipeline registers on the P output,
0 or 1
.SEL_MASK("MASK"), // Select mask value between the "MASK" value or
the value on the "C" port
.SEL_PATTERN("PATTERN"), // Select pattern value between the
"PATTERN" value or the value on the "C" port
.SEL_ROUNDING_MASK("SEL_MASK"), // "SEL_MASK", "MODE1", "MODE2
.USE_MULT("MULT_S"), // Select multiplier usage, "MULT" (MREG => 0),
"MULT_S" (MREG => 1), "NONE" (no multiplier)
.USE_PATTERN_DETECT("NO_PATDET"), // Enable pattern detect,
"PATDET", "NO_PATDET
.USE_SIMD("ONE48") // SIMD selection, "ONE48", "TWO24", "FOUR12
) DSP48E_inst (
.ACOUT(ACOUT), // 30-bit A port cascade output
.BCOUT(BCOUT), // 18-bit B port cascade output
.CARRYCASCOUT(CARRYCASCOUT), // 1-bit cascade carry output
.CARRYOUT(CARRYOUT), // 4-bit carry output
.MULTSIGNOUT(MULTSIGNOUT), // 1-bit multiplier sign cascade output
.OVERFLOW(OVERFLOW), // 1-bit overflow in add/acc output
.P(p_out), // 48-bit output
.PATTERNBDETECT(PATTERNBDETECT), // 1-bit active high pattern bar
detect output
.PATTERNDETECT(PATTERNDETECT), // 1-bit active high pattern
detect output
.PCOUT(PCOUT), // 48-bit cascade output
.UNDERFLOW(UNDERFLOW), // 1-bit active high underflow in add/acc
output
.A(a_in), // 30-bit A data input
.ACIN(ACIN), // 30-bit A cascade data input
.ALUMODE(ALUMODE), // 4-bit ALU control input
.B(b_in), // 18-bit B data input
.BCIN(BCIN), // 18-bit B cascade input
.C(C), // 48-bit C data input
.CARRYCASCIN(CARRYCASCIN), // 1-bit cascade carry input
.CARRYIN(CARRYIN), // 1-bit carry input signal
.CARRYINSEL(CARRYINSEL), // 3-bit carry select input
.CEA1(CEA1), // 1-bit active high clock enable input for 1st stage A
registers
.CEA2(CEA2), // 1-bit active high clock enable input for 2nd stage A
registers
.CEALUMODE(CEALUMODE), // 1-bit active high clock enable input for
ALUMODE registers
.CEB1(CEB1), // 1-bit active high clock enable input for 1st stage B
registers
.CEB2(CEB2), // 1-bit active high clock enable input for 2nd stage B
registers
.CEC(CEC), // 1-bit active high clock enable input for C registers
.CECARRYIN(CECARRYIN), // 1-bit active high clock enable input for
CARRYIN register
.CECTRL(CECTRL), // 1-bit active high clock enable input for OPMODE
and carry registers
.CEM(CEM), // 1-bit active high clock enable input for multiplier
registers
.CEMULTCARRYIN(CEMULTCARRYIN), // 1-bit active high clock enable for
multiplier carry in register
.CEP(CEP), // 1-bit active high clock enable input for P registers
.CLK(CLK), // Clock input
.MULTSIGNIN(MULTSIGNIN), // 1-bit multiplier sign input
.OPMODE(OPMODE), // 7-bit operation mode input
.PCIN(PCIN), // 48-bit P cascade input
.RSTA(RSTA), // 1-bit reset input for A pipeline registers
.RSTALLCARRYIN(RSTALLCARRYIN), // 1-bit reset input for carry
pipeline registers
.RSTALUMODE(RSTALUMODE), // 1-bit reset input for ALUMODE pipeline
registers
.RSTB(RSTB), // 1-bit reset input for B pipeline registers
.RSTC(RSTC), // 1-bit reset input for C pipeline registers
.RSTCTRL(RSTCTRL), // 1-bit reset input for OPMODE pipeline
registers
.RSTM(RSTM), // 1-bit reset input for multiplier registers
.RSTP(RSTP) // 1-bit reset input for P pipeline registers
);
endmodule
HTH,
Jim
http://home.comcast.net/~jimwu88/tools/
jeffnewcomb@nci-usa.com wrote:
> I wish this was just a display issue but the ISE does not recognize
> this as a legal primitive and show a question mark in the sources
> window for the DSP48E. Synthesis will not complete without errors.
> Jim Wu wrote:
> > I think this is just a display issue. If the backend tools know dsp48e
> > is a primitive, why bother if the text is shown in red or black?
> >
> > HTH,
> > Jim
> > http://home.comcast.net/~jimwu88/tools/
> >
> > jeffnewcomb@nci-usa.com wrote:
> > > I have tried to instantiate a DSP48E under ISE 8.2 SP2 but ISE does not
> > > recognize the part as a device primitive. Primitives are normal shown
> > > in red text under ISE but when I block copy the part from the language
> > > template the DSP48E is shown in black text and ISE does not know it is
> > > a primitive. I have a V5LX50 selected as the device I am using. I have
> > > also had the same problem instantiating a RAMB36 and a PLL_ADV. Does
> > > anyone know how to do this successfully?
Article: 106774Hi Everyone, I would like to clarify something here. As said in the past two threads there is a solution record in Xilinx that talks about this message. This is what it says: Solution 1: This error message occurs when the ISE Simulator engine or compiler crashes. There are multiple reasons for this to occur, and currently we are investigating these issues and fixing them as we come across them. If you need further assistance with this problem, please open an online WebCase with Xilinx Customer Support at: http://www.xilinx.com/support/clearexpress/websupport.htm Solution 2: Issue 1: This has been seen if there are spaces in the installation of Xilinx. ISIM currently does not support spaces in Xilinx installation path. As you can see we realize that this is a frustrating problem when the tool just crashes and makes it seem like the tool is unstable. Although we want to fix the problems. This is why we are saying that as soon as you see the C++ error let us know about it. We are addressing each and everyone one of these issues. When we have workarounds for any of these issues we will update this solution record with that data. Always check back on this solution record for updates. If you do find a workaround that fixes the problem, then click on the feedback link and send the feedback to the author of the solution record. Also we want to hear from you. Xilinx has created this simulator for our customers. Hope this helps clarify that this is not a project that we tried out and gave up on. We are continously trying to improve our solutions. Thanks for working with Xilinx and for the very valuable feedback Duth ckingknowledge wrote: > I have been having the exact same problem today!!! When I click on the > 222 error it takes me to answers under the search "Simulator:222" to > answers: 23037, 23207, 21451. I translated the answers to say: ISE > simulator doesn't work and Xilinx is not going to fix it. > > I recommend using ModelSim XE (the free Xilinx version), which is on > the same download page as the Webpack... at the bottom of the page... > hiding. After you download it you have to request a license from > ModelSim to use it. They will email it to you in the form of an > license.dat file. > > Good luck. I'll check back for a solution from someone more > knowledgeable than I.
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