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
John_H, Aye, that is the rub: success. AustinArticle: 129926
> If you consider SiliconBlue to be a younger (newer) PLD company than > Xilinx, the issue is just one of success. Antti's point seems to be > that their tool development wouldn't be hampered by the legacy of any > successful PLD company that's 20 years or more in age. > > I love Xilinx. And I often fight with arcane tools. It doesn't > change the lure of the silicon and raw capabilities. > > I appreciate small company mentality, but there's only so much that > can be done against the history of millions of lines of code. > > - John_H When we say that (almost 25-year-old) Xilinx is the youngest successful PLD company, we are looking back on decades of exciting announcements by start-ups and also big companies getting into this business. Here is the gist of a slide that I have used for over a year: "A Maturing Industry... The two leaders have a combined market share of 86% leaving 14% for Lattice, Actel, Quicklogic, Atmel... All broad-based suppliers have given up: Intel, T.I., AMD, ATT, Philips, Cypress, NSC, Motorola "FPGAs demand too much management attention" Most start-ups vanished: Dynachip, PlusLogic, Triscend, Siliconspice (absorbed) Chameleon, Quicksilver, Morphics, Adaptive Silicon (failed) Fab-less might make it easy, but there are strong barriers to entry: Tool familiarity, design re-use, risk avoidance by the users, Economy of scale, patents, technical support, availability of sales channels Where is the next successful FPGA start-up?" End of quote. I do not necessarily expect this situation to last another 20 years, and it gives us no reason for complacency or arrogance. But it is a sobering thought whenever listening to the newest announcements... Peter Alfke, Xilinx ApplicationsArticle: 129927
On Mar 7, 8:25=A0am, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de> wrote: > John_H <newsgr...@johnhandwork.com> wrote: > > ... > > > The mating connector is the QSE-060-01-L-D-A where Digikey also has stoc= k. > > Thanks, > > seems I had tomatoes on my eyes... > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-darm= stadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- For more information on the EXP expansion system, see www.em.avnet.com/exp BryanArticle: 129928
Hi Austin, I will check connected pins and come back. The worst thing is I am not very familiar with FPGA and I am trying to fix everything from hardware side, since software is accepted as working one... 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, no termination on it. There is no change from the last build. Strange thing is some boards work, some not, and some switching from time to time. Since the boys build the device, put two Atmega microcontrollers and FPGA on same external reset circuit, I doubt that FPGA trying to start before 24MHz oscillator is up completely, and that lead to these 6MHz... These 8MHz going from from FPGA through 51ohm to clock input of Atmega. Hope it is not sound as complete mess... -- Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/ More information at http://www.talkaboutelectronicequipment.com/faq.htmlArticle: 129929
Hi Austin, I will check connected pins and come back. The worst thing is I am not very familiar with FPGA and I am trying to fix everything from hardware side, since software is accepted as working one... 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, no termination on it. There is no change from the last build. Strange thing is some boards work, some not, and some switching from time to time. Since the boys build the device, put two Atmega microcontrollers and FPGA on same external reset circuit, I doubt that FPGA trying to start before 24MHz oscillator is up completely, and that lead to these 6MHz... These 8MHz going from from FPGA through 51ohm to clock input of Atmega. Hope it is not sound as complete mess... -- Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/ More information at http://www.talkaboutelectronicequipment.com/faq.htmlArticle: 129930
Here is more - 24MHz coming from the oscillator through 68ohm terminating resistor and goes to pin B10 and 8MHz goes out from T17 through 51 ohms to clock input of Atmega. This track is less than half inch. Hope this helps, somehow. Clock for configuration memory (17fxxx series, serial Flash) also going out through 51 ohm resistor - and there are also problems sometimes. Probably you are talking me about internal connections, but I don't know much about them. Will check and read about these, too. Thanks again reading my looong explanations. -- Message posted using http://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/ More information at http://www.talkaboutelectronicequipment.com/faq.htmlArticle: 129931
Grubi, Since some parts work, and some don't: -check when the DCM is reset(too soon, and that may be the issue) -look at the clock in pin on passing and failing units (is there a difference)? Debugging this without looking inside is going to be extremely difficult. I suggest you look at how you can observe the DCM reset signal first. AustinArticle: 129932
On Mar 10, 11:19=A0am, "Grubi" <dko...@hotmail.com> wrote: > Hi Austin, > I will check connected pins and come back. The worst thing is I am not > very familiar with FPGA and I am trying to fix everything from hardware > side, since software is accepted as working one... > 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data > for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, > no termination on it. There is no change from the last build. > Strange thing is some boards work, some not, and some switching from time > to time. > Since the boys build the device, put two Atmega microcontrollers and FPGA > on same external reset circuit, I doubt that FPGA trying to start before > 24MHz oscillator is up completely, and that lead to these 6MHz... > These 8MHz going from from FPGA through 51ohm to clock input of Atmega. > Hope it is not sound as complete mess... > > -- > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp= .arch.fpga/ > More information athttp://www.talkaboutelectronicequipment.com/faq.html If you are completely in the dark: Change the temperature with hairdryer and cold-spray, and note any different behavior. change the Vccint 10 percent up and down ( used to be simple, but more tricky nowadays) Load the oscillator frequency input with a 50 ohm resistor to either ground or Vcco. Put your finger or a small capacitor on the oscillator input. Those were the "debugging methods" used decades ago, before logic analyzers and sampling scopes. The idea is to increase the likelihood of failure, and then deduce the most likely cause. Good luck Peter AlfkeArticle: 129933
On Mar 10, 2:48=A0pm, Peter Alfke <pe...@xilinx.com> wrote: > On Mar 10, 11:19=A0am, "Grubi" <dko...@hotmail.com> wrote: > > > > > Hi Austin, > > I will check connected pins and come back. The worst thing is I am not > > very familiar with FPGA and I am trying to fix everything from hardware > > side, since software is accepted as working one... > > 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data > > for start up but it is usual 1-10ms). Trace on PCB is around 3inch long,= > > no termination on it. There is no change from the last build. > > Strange thing is some boards work, some not, and some switching from tim= e > > to time. > > Since the boys build the device, put two Atmega microcontrollers and FPG= A > > on same external reset circuit, I doubt that FPGA trying to start before= > > 24MHz oscillator is up completely, and that lead to these 6MHz... > > These 8MHz going from from FPGA through 51ohm to clock input of Atmega. > > Hope it is not sound as complete mess... > > > -- > > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/co= mp.arch.fpga/ > > More information athttp://www.talkaboutelectronicequipment.com/faq.html > > If you are completely in the dark: > Change the temperature with hairdryer and cold-spray, and note any > different behavior. > change the Vccint 10 percent up and down ( used to be simple, but more > tricky nowadays) > Load the oscillator frequency input with a 50 ohm resistor to either > ground or Vcco. > Put your finger or a small capacitor on the oscillator input. > Those were the "debugging methods" used decades ago, before logic > analyzers and sampling scopes. > The idea is to increase the likelihood of failure, and then deduce the > most likely cause. > Good luck > Peter Alfke Another "trick": Make sure the oscillator is running before the FPGA is being turned on. That eliminates some reset timing problems. Peter AlfkeArticle: 129934
On Mar 11, 4:11 am, Peter Alfke <pe...@xilinx.com> wrote: > On Mar 10, 2:48 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > > > On Mar 10, 11:19 am, "Grubi" <dko...@hotmail.com> wrote: > > > > Hi Austin, > > > I will check connected pins and come back. The worst thing is I am not > > > very familiar with FPGA and I am trying to fix everything from hardware > > > side, since software is accepted as working one... > > > 24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data > > > for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, > > > no termination on it. There is no change from the last build. > > > Strange thing is some boards work, some not, and some switching from time > > > to time. > > > Since the boys build the device, put two Atmega microcontrollers and FPGA > > > on same external reset circuit, I doubt that FPGA trying to start before > > > 24MHz oscillator is up completely, and that lead to these 6MHz... > > > These 8MHz going from from FPGA through 51ohm to clock input of Atmega. > > > Hope it is not sound as complete mess... > > > > -- > > > Message posted usinghttp://www.talkaboutelectronicequipment.com/group/comp.arch.fpga/ > > > More information athttp://www.talkaboutelectronicequipment.com/faq.html > > > If you are completely in the dark: > > Change the temperature with hairdryer and cold-spray, and note any > > different behavior. > > change the Vccint 10 percent up and down ( used to be simple, but more > > tricky nowadays) > > Load the oscillator frequency input with a 50 ohm resistor to either > > ground or Vcco. > > Put your finger or a small capacitor on the oscillator input. > > Those were the "debugging methods" used decades ago, before logic > > analyzers and sampling scopes. > > The idea is to increase the likelihood of failure, and then deduce the > > most likely cause. > > Good luck > > Peter Alfke > > Another "trick": > Make sure the oscillator is running before the FPGA is being turned > on. > That eliminates some reset timing problems. > Peter Alfke Hi Austin, This discussion triggers a question in my mind about an issue related to DCM that I faced a few years ago. I was working with Xilinx Spartan-3 Kit employing XC3S1500 FPGA for interfacing on PCI-Bus using a custom core. I used a DCM (connected to PCI-clock) in my design and the logic always stopped working after running for a few minutes due to unavailability of clock. I contacted Xilinx support but could not get any satisfactory answer to the issue. I thought that perhaps PCI-clock does not allow any phase locked loop to be attached to it. I then tried the on board oscillator, and even though I had three clocks in my logic and I had to address some minor issues related to multiple clock domains, the logic seems to be working so far. Does PCI-clock allow Xilinx DCM to be attached (as clock multiplier) ? Again, as posted by the original poster, Can a DCM get halted after some time due to excessive internal errors ? /MHArticle: 129935
Hi everyone, I have a issue with fpga design optimization. Can any body explain me What is called "reorder path"? with any nice example with hardware realization. As per some book reference it says tht: The data flow which minimize the critical path,..or more mean into: whenever multiple paths combine with critical paths, and combined path can be reorderd such tht the critical path can be moved closer to the destination register. Hope to expect some good answers,.. sreeni, Moog,IncArticle: 129936
Hello Antti, Peter and ..., yep, meanwhile many, many months later - the same question... V5-FX? Thanks and greetings UdoArticle: 129937
On Mar 10, 11:26 pm, mh <moazzamhuss...@gmail.com> wrote: <snip> > Hi Austin, > This discussion triggers a question in my mind about an issue related > to DCM that I faced a few years ago. > > I was working with Xilinx Spartan-3 Kit employing XC3S1500 FPGA for > interfacing on PCI-Bus > using a custom core. I used a DCM (connected to PCI-clock) in my > design and the logic always stopped working after running for a few > minutes due to unavailability of clock. I contacted Xilinx support but > could not get any satisfactory > answer to the issue. > > I thought that perhaps PCI-clock does not allow any phase locked loop > to be attached to it. > > I then tried the on board oscillator, and even though I had three > clocks in my logic and I had to address some minor issues related to > multiple clock domains, the logic seems to be working so far. > > Does PCI-clock allow Xilinx DCM to be attached (as clock multiplier) ? > Again, as posted by the original poster, > Can a DCM get halted after some time due to excessive internal > errors ? > > /MH The PCI spec is not compatible with the DCMs. If you control the entire bus, you can make it compatible. If you are designing a PCI card to go into any PCI system, you need to avoid using the PCI clock as an input to a DCM. The PCI spec allows the PCI clock frequency to be changed. I do not know what percentage of systems actually do this, but the DCMs would not be able to stay locked if this happened. The PCI spec also allows the clock to be a spread spectrum clock to help with EMI compliance. I do not have the PCI spec with me now, but I think that the the amount and rate of frequency change was within the DCM spec on the Virtex-II and Virtex-4 FPGAs that I have implemented PCI on. I do not know if it is within spec for the Spartan series. However, even if the spread spectrum clocking is compatible with the DCM, it reduces your jitter tolerance and jitter can cause a DCM to lose lock. On a Virtex-II 3000, we were able to just run the PCI clock through a BUFG and use that directly for a 66MHz PCI interface. On a Virtex-4 FX 40/60/100, we use the BUFIO and BUFR clocks for the PCI clock domain for a 66 MHz PCI interface. From your post, I get the impression that you wanted to use the PCI clock as the main clock in your design. I would suggest that you only use IO clocks for IO, and have your own clock source for your main clock. Regards, John McCaskill www.FasterTechnology.comArticle: 129938
I just noticed a very weird if not outright scary behavior from the
par and trce tools in ISE.
For an example of what I mean, try to synthesize the following very
simple design for a xc4vlx80-12. You will have to turn off "Shift
register extraction" under synthesize/HDL options though. You might
also have to change place & route effort level to high as that is what
I had it set to when trying this out.
//////////////////////////////////////////////////////////////////////
module argh (input wire clk,
input wire [17:0] a_i,b_i,
output reg [47:0] result_mul);
reg [17:0] a1,a2,op_a,b1,b2,op_b;
reg [47:0] r1,r2;
wire [47:0] r;
always @(posedge clk) begin
a1 <= a_i; a2 <= a1; op_a <= a2;
b1 <= b_i; b2 <= b1; op_b <= b2;
r1 <= r; r2 <= r1; result_mul <= r2;
end
DSP48 #( .AREG(1), .BREG(1), .B_INPUT("DIRECT"), .CARRYINREG(1),
.CARRYINSELREG(1), .CREG(0), .LEGACY_MODE("MULT18X18"),
.MREG(0), .OPMODEREG(0), .PREG(1), .SUBTRACTREG(0) )
dsp48_test
( .CLK(clk), .BCOUT(), .P(r), .PCOUT(), .A(op_a),
.B(op_b), .BCIN(), .C(48'b0), .CARRYIN(1'b0),
.CARRYINSEL(2'b00), .CEA(1'b1), .CEB(1'b1),
.CEC(1'b1), .CECARRYIN(1'b1),
.CECINSUB(1'b1), .CECTRL(1'b1), .CEM(1'b1),
.CEP(1'b1), .OPMODE(7'b0000101), .PCIN(),
.RSTA(1'b0), .RSTB(1'b0), .RSTC(1'b0),
.RSTCARRYIN(1'b0), .RSTCTRL(1'b0),
.RSTM(1'b0), .RSTP(1'b0), .SUBTRACT(1'b0) );
endmodule
//////////////////////////////////////////////////////////////////////
Anyway, when synthesizing this design I got the following in the place
& route logfile, indicating that this design will run at around 539
MHz. This is very odd as the DSP48 block should not be able to operate
at more than around 317 MHz in this configuration if I understand the
datasheet correctly. But there is no error or warning message in
argh.par or argh.twr.
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: Constraint | Check | Worst Case | Best Case | Timing | Timing
argh.par: | | Slack | Achievable | Errors | Score
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: Autotimespec constraint for clock net clk | SETUP | N/A| 1.853ns| N/A| 0
argh.par: _BUFGP | HOLD | 0.255ns| | 0| 0
argh.par: ------------------------------------------------------------------------------------------------------
argh.par:
argh.par:
argh.par: All constraints were met.
argh.par: INFO:Timing:2761 - N/A entries in the Constraints list may indicate that the
argh.par: constraint does not cover any paths or that it has no requested value.
After this I add a constraint file with a 2.5ns constraint on the
period and get the following in the bottom of argh.par:
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: Constraint | Check | Worst Case | Best Case | Timing | Timing
argh.par: | | Slack | Achievable | Errors | Score
argh.par: ------------------------------------------------------------------------------------------------------
argh.par: TS_clk = PERIOD TIMEGRP "clk" 2.5 ns HIGH | SETUP | 0.000ns| 2.500ns| 0| 0
argh.par: 50% | HOLD | 0.545ns| | 0| 0
argh.par: ------------------------------------------------------------------------------------------------------
argh.par:
argh.par:
argh.par: All constraints were met.
Note that the tool says that all constraints are met, even though the
following warning is located at the top of this file:
argh.par: WARNING:Timing:3232 - Timing Constraint
argh.par: "TS_clk = PERIOD TIMEGRP "clk" 2.5 ns HIGH 50%;"
argh.par: fails the minimum period check for clock clk_BUFGP because the period constraint value (2500 ps) is less than the
argh.par: minimum internal period limit of 3150 ps. Please increase the period of the constraint to remove this timing
argh.par: failure.
This warning message annoys me quite a bit because there is no
indication as to why the minimum internal period limit is 3150 ps. It
took me quite some time to find that the real cause of the error was
the DSP block. At first I thoguht there was some limit on the type of
clock bufer I was using or something similar before turning my
attention to the DSP48 block.
Similar behavior is shown by the trce tool in the argh.twr timing
report file; A warning at the top of the file even though the text at
the bottom says that all constraints were met.
I'm basically posting this so that people who google for "minimum
internal period limit" might be able to find this message and possibly
be helped by it if this is indeed their problem.
/Andreas
Article: 129939Hi, I want to interface matlab with the Xilinx Virtex-II pro board. Intent is to give input from matlab to the FPGA and to read the ouput of FPGA in matlab. Problem is in interfacing speed. I need high speed interface, of the order of 2 mega bits per second (Mbps). Seems RS-232 will be inadequate for my purpose. From Documents interface through ethernet seems to be a viable option but I am not sure. To summarize I want answers and suggestions on following: 1). FPGA to PC communication by ethernet ? 2). What can be the maximum speed ? 3). How to transfer data on ethernet by matlab ? 4). Is it possible to write inputs (60 Mega bits) to some memory on FPGA board and then read it from there to do the computation ? Please let me know if you have any suggestion for me. Thank You. StYmArticle: 129940
Hi everyone, While trying to build a simple VGA driver, I'm running into trouble getting my video-ram (actually, sample ram) to be synthesized as a dual port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried to describe the BRAM as instructed in the xst.pdf documentation, but as soon as I try to read out the BRAM, the Synthesizer turns it into distributed RAM. I wonder if anyone would be so kind as to help me understand why? The circuit consists of an 8 bit sampler which produces 2's complement data. It is connected to my Spartan-3 kit and I want the data to be displayed by the VGA port, as a primitive oscilloscope - just to verify that I'm getting valid data from the sampler. The display is generated by comparing the current vertical position against the sample ram contents for the current horizontal position, and drawing a pixel if they match - repeat for every position as the VGA display is scanned. This would undoubtedly benefit from more advanced concepts like double-buffering, but I'm slowly working my way up to that. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity main is Port (clk: in STD_LOGIC; sample: in STD_LOGIC_VECTOR(7 downto 0) red, green, blue: out STD_LOGIC)); ... end main; architecture Behavioural of main is type bram_type is array (511 downto 0) of signed (7 downto 0); signal BRAM: bram_type; signal BRAM_addra: unsigned (8 downto 0) := "000000000"; signal BRAM_addrb: unsigned (8 downto 0) := "000000000"; signal vert: unsigned (9 downto 0) := "0000000000"; process(clk) -- Read data from the sampler begin if(clk'event and clk='1') then ... BRAM(to_integer(BRAM_addra)) <= signed(sample); end if; end process; process(clk) -- Display VGA image begin if (clk'event and clk = '1') ... -- vert runs form 40 to 520, vert - 200 should center signed(0). if(BRAM(to_integer(BRAM_addrb)) = signed (vert - 200)) then red <= '1'; green <= '1'; blue <= '1'; else red <='0'; green <= '0'; blue <= '0'; end if; BRAM_addrb <= BRAM_addrb + 1; (increment/reset BRAM_addrb and vert as appropriate to scan) end if; end process; The code above gives me this warning: XST:2664 HDL ADVISOR - Unit <main> : The RAM <Mram_BRAM> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features. If you have described an asynchronous read, making it synchronous would allow you to take advantage of available block RAM resources, for optimized device usage and improved timings. Please refer to your documentation for coding guidelines. I don't see (and would welcome any suggestions) why this is an asynchronous read, as it only happens during 'clk' transitions. If one would rather see the full vhd file, please see http://www.xs4all.nl/~epboven/main.vhd Now in order to sidestep this problem, I've introduced a signal bram_buffer: signal bram_buffer: signed(7 downto 0) ... if(bram_buffer = signed(vert - 200) then red <= '1'; green <= '1'; blue <= '1'; ... bram_buffer <= BRAM(to_integer(BRAM_addrb)); This does result in an implementation that uses a block ram, but curiously the output from XST suggests that the buffer isn't actually used at all: INFO:Xst:2691 - Unit <main> : The RAM <Mram_BRAM> will be implemented as a BLOCK RAM, absorbing the following register(s): <bram_buffer>. So hooray, but as I just pipelined the BRAM output, my assumption was that I would now be getting my samples one pixel 'late' and would need to compensate for that - with the above message thrown in, I'm not sure of that anymore. Any comments welcome (please be gentle...) Regards, Paul Boven.Article: 129941
Paul Boven wrote:
> While trying to build a simple VGA driver, I'm running into trouble
> getting my video-ram (actually, sample ram) to be synthesized as a dual
> port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried
...
> Any comments welcome
Consider a fifo.
-- Mike Treseler
Article: 129942On Mar 11, 9:55 am, Paul Boven <bo...@jive.nl> wrote: > Hi everyone, > > While trying to build a simple VGA driver, I'm running into trouble > getting my video-ram (actually, sample ram) to be synthesized as a dual > port block-ram - it keeps wanting to use up 25% of my LUTs. I've tried > to describe the BRAM as instructed in the xst.pdf documentation, but as > soon as I try to read out the BRAM, the Synthesizer turns it into > distributed RAM. I wonder if anyone would be so kind as to help me > understand why? > > The circuit consists of an 8 bit sampler which produces 2's complement > data. It is connected to my Spartan-3 kit and I want the data to be > displayed by the VGA port, as a primitive oscilloscope - just to verify > that I'm getting valid data from the sampler. > The display is generated by comparing the current vertical position > against the sample ram contents for the current horizontal position, and > drawing a pixel if they match - repeat for every position as the VGA > display is scanned. This would undoubtedly benefit from more advanced > concepts like double-buffering, but I'm slowly working my way up to that. > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.NUMERIC_STD.ALL; > > entity main is > Port (clk: in STD_LOGIC; > sample: in STD_LOGIC_VECTOR(7 downto 0) > red, green, blue: out STD_LOGIC)); > ... > end main; > > architecture Behavioural of main is > > type bram_type is array (511 downto 0) of signed (7 downto 0); > signal BRAM: bram_type; > signal BRAM_addra: unsigned (8 downto 0) := "000000000"; > signal BRAM_addrb: unsigned (8 downto 0) := "000000000"; > signal vert: unsigned (9 downto 0) := "0000000000"; > > process(clk) -- Read data from the sampler > begin > if(clk'event and clk='1') then > ... > BRAM(to_integer(BRAM_addra)) <= signed(sample); > end if; > end process; > > process(clk) -- Display VGA image > begin > if (clk'event and clk = '1') > ... > -- vert runs form 40 to 520, vert - 200 should center signed(0). > if(BRAM(to_integer(BRAM_addrb)) = signed (vert - 200)) then > red <= '1'; green <= '1'; blue <= '1'; > else > red <='0'; green <= '0'; blue <= '0'; > end if; > BRAM_addrb <= BRAM_addrb + 1; > (increment/reset BRAM_addrb and vert as appropriate to scan) > end if; > end process; > > The code above gives me this warning: XST:2664 HDL ADVISOR - Unit <main> > : The RAM <Mram_BRAM> will be implemented on LUTs either because you > have described an asynchronous read or because of currently unsupported > block RAM features. If you have described an asynchronous read, making > it synchronous would allow you to take advantage of available block RAM > resources, for optimized device usage and improved timings. Please refer > to your documentation for coding guidelines. > > I don't see (and would welcome any suggestions) why this is an > asynchronous read, as it only happens during 'clk' transitions. > If one would rather see the full vhd file, please seehttp://www.xs4all.nl/~epboven/main.vhd > > Now in order to sidestep this problem, I've introduced a signal bram_buffer: > > signal bram_buffer: signed(7 downto 0) > ... > if(bram_buffer = signed(vert - 200) then > red <= '1'; green <= '1'; blue <= '1'; > ... > bram_buffer <= BRAM(to_integer(BRAM_addrb)); > > This does result in an implementation that uses a block ram, but > curiously the output from XST suggests that the buffer isn't actually > used at all: > INFO:Xst:2691 - Unit <main> : The RAM <Mram_BRAM> will be implemented as > a BLOCK RAM, absorbing the following register(s): <bram_buffer>. > > So hooray, but as I just pipelined the BRAM output, my assumption was > that I would now be getting my samples one pixel 'late' and would need > to compensate for that - with the above message thrown in, I'm not sure > of that anymore. > > Any comments welcome (please be gentle...) > > Regards, Paul Boven. The read operation from a BRAM needs to be clocked. Either feed the read address through a register before using it to index the RAM, or register the output of the RAM. Either of these result in a 1 clock delay between the read address and the output data. There are code templates online in the XST users guide. Hope this helps.Article: 129943
Hi all, I have just released a new online Video guide called "The BurchED Getting Started with Xilinx FPGAs Video Guide" http://www.BurchED.com It is an easy step-by-step guide for FPGA beginners. I go all the way through from "What is an FPGA?" right up to compiling designs and downloading to your FPGA board. You can log in to the site whenever you want and watch the videos, including any additional ones that I will put up over time. There's a Free Membership area where you can watch some videos for free. * FPGAs for Beginners - the Top 6 Questions answered * How to choose an FPGA board * An independent review of available FPGA boards * What to do when you first get your FPGA board * How to download and install the free Xilinx design software There's also an introductory offer on the full video guide, which includes 18 videos on getting started with Xilinx FPGAs. Some of the benefits are: * Save time and effort when getting started with FPGAs * Avoid the big mistakes that often derail first time FPGA users * Save money - advice to lower your cost when getting an FPGA board * Expand your design options by putting FPGAs in your toolbox * Achieve the satisfaction and fun of designing your own FPGA circuits * Amaze your colleagues with your new FPGA skills * Gain the skills and confidence needed to go on and make more complex designs I look forward to seeing you over there. Grab the Free membership & have a look at the introductory offer on the full video guide http://www.BurchED.com Kind regards, Anthony Burch BurchED - Making it easy to get started with FPGAs PS. A note for University Lecturers: University & company site licenses are available. Minimise the amount of lecture time that you spend teaching FPGA basics. Let your students do this video course at home. Please email me for details about great value site licenses.Article: 129944
jshrini.vasu@gmail.com wrote:
> I have a issue with fpga design optimization. Can any body explain me
> What is called "reorder path"? with any nice example with hardware
> realization.
It is nice that I tell synthesis
what Fmax is, and synthesis does a fine job
wiring up the LUTs and optimizing the paths for me.
-- Mike Treseler
http://home.comcast.net/~mike_treseler/count_enable.pdf
http://home.comcast.net/~mike_treseler/count_enable_map.pdf
Article: 129945On Mar 11, 9:49 am, satyam <satyam.dwiv...@gmail.com> wrote: > Hi, > > I want to interface matlab with the Xilinx Virtex-II pro board. Intent > is to give input from matlab to the FPGA and to read the ouput of FPGA > in matlab. > > Problem is in interfacing speed. I need high speed interface, of the > order of 2 mega bits per second (Mbps). Seems RS-232 will be > inadequate for my purpose. From Documents interface through ethernet > seems to be a viable option but I am not sure. To summarize I want > answers and suggestions on following: > > 1). FPGA to PC communication by ethernet ? > 2). What can be the maximum speed ? > 3). How to transfer data on ethernet by matlab ? > 4). Is it possible to write inputs (60 Mega bits) to some memory on > FPGA board and then read it from there to do the computation ? > > Please let me know if you have any suggestion for me. > > Thank You. > > StYm These may help: http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=345&objectType=File http://www.mathworks.com/products/instrument/supportedio13782.html All hail the power of google!Article: 129946
Hi Paul, Yeah, if you look at your code, you're trying to do an asynchronous read. I suggest you try simulating your design and also a design where you instantiate a block ram. You'll be able to compare and see clearly what the block ram does. HTH., Syms.Article: 129947
I found Chipscope is too difficult to learn for college students, it has too much options. I want to develop a simple gui software and using it in a 8086/8088 FPGA embedded system. For example, students can understand a bus transaction with just a simple mouse click in this software, instead of setting so much options in the tranditional Chipscope software. Can anyone give me some information about this work? Thank you! Best Regards, WickyArticle: 129948
mh, John has answered your question of PCI<>DCM. -snip- > Can a DCM get halted after some time due to excessive internal > errors ? > > /MH The DCM "stops" and drops the LOCKED signal if the tap address runs over, or under, the length of the delay line. That happens when the clock changes frequency, or has drop-outs (missing pulses). A PLL would "tolerate" such clocks, but the DCM being a digital state machine, does not. If the clock stops altogether, LOCKED will not drop (it is synchronous with CLKIN), thus we have a CLOCK_STOPPED status bit that has to be monitored (to know what is going on). This status bit is asynchronously set, so no CLKIN is required. AustinArticle: 129949
wicky wrote: > I found Chipscope is too difficult to learn for college students, it Yes but isn't college supposed to prepare them for the real world? > has too much options. I want to develop a simple gui software and > using it in a 8086/8088 FPGA embedded system. For example, students > can understand a bus transaction with just a simple mouse click in > this software, instead of setting so much options in the tranditional > Chipscope software. Can anyone give me some information about this > work? Thank you! Couldn't the instructor set up chipscope and then save all the options? Then the student would just have to reload the saved project file, and the bus transaction would be there all optimally displayed for understanding. -Jeff
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