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
Hi it seems that almost all resources from old memec RDC restricted access area are now available for anyone without restriction, also design files and documentation for Avnet kits. There is still registration required to gain access, but that is very simple and memec board serial # isnt required. eg anyone who just enters email, etc, will gain access to the files from memec RDC and to avnet boards schematics docs and ref designs. finding stuff is now little bit more complicated as it is requried to select the board product and then the 'reference design' button, it will bring up the download page for that eval board. There seems to be no single page with overview links (or I did not find it) AnttiArticle: 106776
Jim,
Thanks for the input.
Can you get your code to go through MAP , Place & Route ? My code gives
a fatal error when it tries to MAP under ISE. I copied the the code I
am using from the language template of ISE so I don't think its a
problem with the template.
Jim Wu wrote:
> 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: 106777
A.D. schrieb:
> 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?!?
In VHDL std_logic ist just an enumeration. So '-' does neither equal '0'
nor '1'.
There are special library function that have the behaviour that you
intend ('-' being equal to both '0' and '1'.)
There is another area where this can hurt you. The often used formulation
if clock'event and clock='1' then ...
to describe a rising edge triggered flip flop will misbehave in
simulation because it will trigger on a change from 'U', 'X', '-' or 'H'
to '1' (whicht it should not) but it won't trigger on a transition
from '0' to 'H' or 'L' to 'H' (which it should).
For simulation you really must use
if rising_edge(clock) then ...
instead.
Kolja Sulimma
Article: 106778Many thanks for your reply, Erik. How would the VGA module function if the processor is removed? I remember there's a C function running on the processor that initiates the display... Erik Widding wrote: > > > 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: 106779
I would like to be able to send and receive data on the fly to a Xilinx V4 BRAM. I would communicate to the A port while the design under test would use the B port. (Or the other way around is OK to). A minimum of hardware would be nice. On this dev board there is an RS232 UART port, a USB2 port that goes through the Cypress part, an Ethernet port, the JTAG port, all of which seem to be OK fine candidates for an interface. Can somebody tell me what is the easiest non-EDK path for me? Brad Smallridge aivisionArticle: 106780
Yes, it runs through par w/o problem. Below is the map report:
Slice Logic Distribution:
Either LUT or Flip Flop pair used: 0 out of 28,800 0%
Both LUT and Flip Flop pair used: 0 out of 28,800 0%
IO Utilization:
Number of bonded IOBs: 64 out of 440 14%
Specific Feature Utilization:
Number of DSP48Es: 1 out of 48 2%
HTH,
Jim
http://home.comcast.net/~jimwu88/tools/
jeffnewcomb@nci-usa.com wrote:
> Jim,
>
> Thanks for the input.
> Can you get your code to go through MAP , Place & Route ? My code gives
> a fatal error when it tries to MAP under ISE. I copied the the code I
> am using from the language template of ISE so I don't think its a
> problem with the template.
>
> Jim Wu wrote:
> > 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: 106781fpganovice wrote: > Many thanks for your reply, Erik. How would the VGA module function if > the processor is removed? I remember there's a C function running on > the processor that initiates the display... For a simple single video buffer (i.e. no shadow or ping-pong like buffering), you can go into the source code for the VGA module and modify the reset assignment to the registers that you care about. If I wanted to get something working fast I would do (and have done) such things. This address could be written over some external interface that has a bus master connection to the OPB (i.e. PCI). But with the ML401 board, there is no easy way to do this. Our processorless FPGAs usually have a port such as this. In more complicated systems, where we have circular buffers of frames being processed, we set up each IP module in the sequence to read the address of the last completed buffer from its predecessor. Given that you will be using somebody else's VGA module, you could simply have your module write the address of the next frame to the VGA instead. Or, rather than distributing intelligence into all of your modules... You could have a simple state machine that is an OPB master that does some of the setup/housekeeping tasks. It might be as simple as a 32bit wide blockram (as a ROM) where portA is used to present an address on the bus and portB is used to present the data. A subrange of portA could store the microcode for your statemachine as well. It would only take a few extra gates to handshake with the bus, and sequence through the microcode. It might take as input a single interrupt that tells it the next frame has been processed. EDK can be used as a framework to do cool stuff like this. In many systems there is a desire for a processor of some sort, as it just makes life easier to deal with the setup and housekeeping, as you point out. Sometimes a state machine is good enough, and much smaller. It has been 4 or 5 years since we have put a discrete processor on a board next to an FPGA, as EDK lets us do all kind of interesting "what if" architectural trade-offs in real hardware without having to rev physical hardware. EDK is an excellent tool for setting up, and modifying the dataflow in an FPGA - whther or not a processor (Microblaze, PPC, something else, etc) is present. I had not meant to suggest that a processor was not a smart choice for your application. I only meant to suggest that it wasn't the ONLY choice. Your question to me demonstrates that you are clearly thinking through your options. Makes me feel that spending an extra few minutes writing out a more detailed answer is worth while. Nice way to end a friday - feeling appreciated. Good luck as you continue with your project. 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: 106782
Hi Patrick, Thank you for your help. Actually, I patched Answer #23011 before going through the flow in EDK 8.1i. I'll try to use uc2.vhd instead of uc2.ngc. Regards, louis "Patrick Dubois" <prdubois@gmail.com> :1155922197.062518.72270@75g2000cwc.googlegroups.com... > 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, > > louis >Article: 106783
In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka <ray@andraka.com> wrote: > 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. Does anybody do the following thing?: At each step, the adders check for whether the high order bit of any result is set. (Just an N-way OR gate). If so, then the next step includes a right-shift (for all elements), otherwise there is no right-shift. In the end, you get an FFT result which must be scaled by 2^number-of-right-shifts, but has as much resolution as is possible given the number of bits (for the largest-magnitude components). Sort of similar to floating point, except that there is only one exponent for all components. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 106784
David M. Palmer schrieb: > In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka > <ray@andraka.com> wrote: > Does anybody do the following thing?: At each step, the adders check > for whether the high order bit of any result is set. (Just an N-way OR > gate). If so, then the next step includes a right-shift (for all > elements), otherwise there is no right-shift. In the end, you get an > FFT result which must be scaled by 2^number-of-right-shifts, but has as > much resolution as is possible given the number of bits (for the > largest-magnitude components). See my previous post. For the last half of inputs you loose M-1 bits of resolution. This is not much better than just shifting all inputs by M-1 bits to the right at the beginning. Floating point with S bits in the significand is not better for summing up many small values than S bit fixed point. Kolja SulimmaArticle: 106785
Nico Coesel schrieb: > 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). Addition on a log scale is rather difficult. Kolja SulimmaArticle: 106786
Hmm, If this is the small S3 starter board that you program via USB?? Err, I got it from memec for about 100$ a while ago, I don't remember the exact name (alas it resides in a cupboard somewhere now), anyways in my case the combined flash-processor-usb packed up after about a week using it, the documentation was useless, and it looked like a real beast to debug. I had the same sort of problem meaning I coundn't get a bitstream into the flash without it becoming corrupt, then of course the S3 programming wouldn't verify. It would work by JTAG, directly into the FPGA, but that was it. I'll have a look see if I can find the board - itmight be a batch fault... Ben "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:44e4dd6b$1@clear.net.nz... > burn.sir@gmail.com wrote: > >> Well, I really had enough of this last night (with Impact crashing >> every 5 minutes instead of the usual every 20 minutes). Was so -><- >> close to trash the board and pretend it was bricked :) >> >> >> Somehow, I forced myself to go back to it when I got home right after >> work, and tried to read from flash after configuration. I got >> mismatches like this in few places (above: read, below: original mcs): >> >> >> 7485,7490c7485,7490 >> < :10D3A000000000000000000000000000FFFFFFFF81 >> < :10D3B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D >> < :10D3C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF6D >> < :10D3D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D >> < :10D3E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D >> < :10D3F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D >> --- >> >>>:10D3A000000000000000000000000000000000007D >>>:10D3B000000000000000000000000000000000006D >>>:10D3C000000000000000000000000000000000005D >>>:10D3D000000000000000000000000000000000004D >>>:10D3E000000000000000000000000000000000003D >>>:10D3F000000000000000000000000000000000002D >> >> >> >> The error rate is something like 2-3%. The board is new*, the cable is >> new. Hell, even the computer I ran this from is shiny new. Everything >> works just fine when programming the FPGA directly. >> >> Does Anyone know what the problem is? Is xilinx flash this unreliable, >> or am I doing something wrong? >> >> >> regards >> - Burns >> >> >> >> * actually its really old, but totally unused. I just haven't cared >> enough to play with my xilinx boards. Very much thanks to a scary first >> encounter with ISE... > > That looks like it just stopped writing 0's ? > > If you read 30 times, do you get the matching 30 results ? - that checks > read integrity. > Can you get the Flash into a device programmer, that can read it. > That gives a second verify of contents. > > Are these errors always at start/finish. ? > I have seen other devices flash-error on preamble or post-amble > timing errors. > > -jg > >Article: 106787
Kolja Sulimma <news@sulimma.de> wrote: >Nico Coesel schrieb: >> 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). > >Addition on a log scale is rather difficult. You don't have to. Use a conversion table or bit shifting (like u-law / a-law) to convert from lin to log. The fft won't mind the signal it is processing is converted to a log scale. After fft convert the result back to linear if required. The scheme is very simple: in -> lin to log -> fft -> log to lin -> out -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106788
Nico Coesel schrieb: > Kolja Sulimma <news@sulimma.de> wrote: > > >>Nico Coesel schrieb: >> >>>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). >> >>Addition on a log scale is rather difficult. > > > You don't have to. Use a conversion table or bit shifting (like u-law > / a-law) to convert from lin to log. The fft won't mind the signal it > is processing is converted to a log scale. After fft convert the > result back to linear if required. > > The scheme is very simple: > > in -> lin to log -> fft -> log to lin -> out Definitely not. Log is not linear. log(a+b) <> log a + log b The spectrum of log(sin(x)) constains frequencies that sin(x) does not because sin is not an eigenfunction of log. Scaling the spectrum will not make these extra frequencies vanish. Kolja SulimmaArticle: 106789
Kolja Sulimma <news@sulimma.de> wrote: >Nico Coesel schrieb: >> Kolja Sulimma <news@sulimma.de> wrote: >> >> >>>Nico Coesel schrieb: >>> >>>>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). >>> >>>Addition on a log scale is rather difficult. >> >> >> You don't have to. Use a conversion table or bit shifting (like u-law >> / a-law) to convert from lin to log. The fft won't mind the signal it >> is processing is converted to a log scale. After fft convert the >> result back to linear if required. >> >> The scheme is very simple: >> >> in -> lin to log -> fft -> log to lin -> out > >Definitely not. Log is not linear. > >log(a+b) <> log a + log b > >The spectrum of log(sin(x)) constains frequencies that sin(x) does not >because sin is not an eigenfunction of log. > >Scaling the spectrum will not make these extra frequencies vanish. Just run some numbers on the error being introduced versus the savings in logic. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106790
I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is not on the list in Project Properties. Should I have any library? I can't find it. Thanks, WojtekArticle: 106791
"zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl> schrieb im Newsbeitrag news:1156001058.926841@pdp... > I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is not > on the list in Project Properties. Should I have any library? I can't find > it. > > Thanks, > Wojtek > you are not trying with WebPack? this part is not supported by the free tools anttiArticle: 106792
Użytkownik "Antti Lukats" <antti@openchip.org> napisał w wiadomości news:ec7fe6$fum$1@online.de... > "zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl> schrieb im Newsbeitrag > news:1156001058.926841@pdp... >> I'd like to use Virtex IIP xc2vp30-6ff1152 in Xilinx 8.1i but there is >> not on the list in Project Properties. Should I have any library? I can't >> find it. >> >> Thanks, >> Wojtek >> > you are not trying with WebPack? this part is not supported by the free > tools > ok, thanks... and do you know if ucf file is the same for all V2P family? I have error: "LOC constraint W32 on P_IO_DQ<10> is invalid: No such site on the device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'." I used xc2vp2-6ff672 Is it possible to be correct for xc2vp30-6ff1152 ? zlotawyArticle: 106793
I'm trying to use xc3sprog to program a XCF3s1500fg456 using a parallel cable III. I get the following error: $ ./xc3sprog pci_7seg.bit Release 0.5 Cannot find device having IDCODE=05045093 I noticed the following line in devlist.txt: 05045093 8 XCF02S I get the following fro bitparse: Created from NCD file: pci_7seg.ncd Target device: 3s1500fg456 Created: 2006/ 8/11 13:49:16 Bitstream length: 5214784 bits I sent an email to the author of xc3sprog several days ago, but I've not heard anything back... PhilArticle: 106794
In article <44e6e7e0$0$6994$9b4e6d93@newsspool1.arcor-online.net>, Kolja Sulimma <news@sulimma.de> wrote: > David M. Palmer schrieb: > > In article <SmjFg.4549$SZ3.3956@dukeread04>, Ray Andraka > > <ray@andraka.com> wrote: > > > Does anybody do the following thing?: At each step, the adders check > > for whether the high order bit of any result is set. (Just an N-way OR > > gate). If so, then the next step includes a right-shift (for all > > elements), otherwise there is no right-shift. In the end, you get an > > FFT result which must be scaled by 2^number-of-right-shifts, but has as > > much resolution as is possible given the number of bits (for the > > largest-magnitude components). > > > See my previous post. > For the last half of inputs you loose M-1 bits of resolution. This > is not much better than just shifting all inputs by M-1 bits to the > right at the beginning. You only lose low order bits if you need high-order bits. > Floating point with S bits in the significand is not better for summing > up many small values than S bit fixed point. It all depends on what you are doing. If you are searching for tones in noisy data, where the strengths of the tones and the noise aren't determined at design time, then shift-if-you-need-it is a good strategy because you don't care about the noise in frequency space, only the strongest signal. It gives you overall dynamic range between, but not within, measurements. If you are trying to filter out an interfering frequency to see what's underneath it, then losing everything below 2^-n of the largest frequency tone is sub-optimal. If you use floating point with too few bits in the significand, then there will be significance loss in a complicated pattern in frequency space. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 106795
Hi! I'm a newbie at designing circuits on FPGA and I have found out something I cannot understand very well. I've written the VHDL description of some Linear Feedback Shift Registers and I have synthesised them with Xilinx's xst using different optimisations: for Speed and for Area. I've noticed that, even if the Speed optimisation leads in many cases to a faster circuit, sometimes it produces a slower circuit than the Area optimisation. Though, this is quite infrequent. The real problem, is with the Area optimisation, that, according to xst's Synthesis Report, often produces a circuit with more flipflops, used slices, and bonded IOBs than Speed optimisation. The only unchanged or lower values are the number of BELs and LUTs used. How can this be? Am I looking at the wrong values to see whether the area has been reduced or not? Or is it a problem with some XST parameter? Thanks in advance to everyone who will answer! FlyingPenguinArticle: 106796
FlyingPenguin wrote:
> The real problem, is with the Area optimisation, that, according to
> xst's Synthesis Report, often produces a circuit with more flipflops,
> used slices, and bonded IOBs than Speed optimisation. The only
> unchanged or lower values are the number of BELs and LUTs used.
This is a gray area.
Maybe some otherwise unused flops were
called up to save some more valuable LUTs.
Area/Speed settings are hints rather
than constraints and as you have seen,
they don't always work.
I have found that the effect of changing
this setting is small and the the default
AUTO setting is as good as any
on the average.
-- Mike Treseler
Article: 106797KJ wrote: > > Many hands make light work. Get a couple of dozen of > > experienced designers, a bunch of proof reading fact > > checkers and one decent editor and you got yourself > > an open source book writing project. > > > > Put it out on sourceforge for free and make it useful for any > > digital designer at any stage in their career or hobby.Do > > a really good job and it can become the "bible" of the > > industry that everyone has in the library. > > > Certainly an interesting idea. > > > > Do we have the critical mass to pull something like this off? > > > Always a big question...the other important question is finding the > 'leader' to prod this along to get it going in the first place. > > KJ A few months ago a similar Idea was posted on an ASIC and Digital design community at Orkut. The basic Idea was a) To collect class notes/Presentation on a particular topic and expand it to a book or b) A person will come up with the book outline and others will submit articles on specific topics and flesh it out The final goal being to get a set of books on hardware design. You can check the details at http://edaindia.com/books/ Regards H.H.I Tracy ....Article: 106798
Hi there
When I synthesis my design I get some warning messages.
A strange on is this: <<WARNING:Xst:647 - Input <clk> is never used.>>
It is declared in the Entity:
entity RS232 is
Port (
reset : in std_logic;
clk : in STD_LOGIC;
rx : in STD_LOGIC;
PData : out STD_LOGIC_VECTOR (7 downto 0);
PDataAcc : out STD_LOGIC);
end RS232;
It is used in a process:
SmallClkPros : process(clk, reset)
begin
...
...
end process SmallClkPros;
Why do I get this warning?
Raymond
Article: 106799Benjamin Todd wrote: > Hmm, If this is the small S3 starter board that you program via USB?? Err, I > got it from memec for about 100$ a while ago, I don't remember the exact > name (alas it resides in a cupboard somewhere now), anyways in my case the > combined flash-processor-usb packed up after about a week using it, the > documentation was useless, and it looked like a real beast to debug. I had > the same sort of problem meaning I coundn't get a bitstream into the flash > without it becoming corrupt, then of course the S3 programming wouldn't > verify. It would work by JTAG, directly into the FPGA, but that was it. > I'll have a look see if I can find the board - itmight be a batch fault... sounds fairly similar to the OP's - here is one idea : do Xilinx publish any FLASH cycle limit guarantees, on these ? - could just be a small number.... [ The OP could just live with a 2-3% failure.... :) ] -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