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
u_stadler@yahoo.de schrieb: Hi, > i still get the "Initializing lwIP" output but then the programm never > come back from the lwip_init() function. > where is the funcion defined anyway? (what source file) EDK\sw\ThirdParty\sw_services\lwip_v2_00_a\src\contrib\ports\v2pro\netif\xemacliteif_intr_xmk.c (EDK 8.1 SP2) Regards, AndreasArticle: 109051
Sumesh, I will look into your complaints. It hurts everyone if our parts are presented poorly by a distributor on their demo pcbs. I am sorry for your experience with this board. If anyone else has had a poor experience with a pcb (any pcb from us, or one of our authorized distributors), please let me know. I would prefer email to me directly. I will offer no excuses, as there are none: to showcase a new part, only the best effort is acceptable. AustinArticle: 109052
All, Virtex 2V6000 had a mask change, late in its production life (maybe 18 months after it went to production). It sped up the global clock resources, which made source synchronous IOs have much more timing amrgin, but it broke CLK2X feedback to the DCM. This was documented (somewhere, I can't seem to find it on-line now, perhaps it was later fixed...). And, there was (is?) an order code to purchase the old mask set parts. This mistake, was in part, my fault. In my haste to get the global clocks performing better (less jitter, less delay), the DCM team failed to re-simulate the CLK2X feedback case (the team I was part of, and the team where it was also my responsibility to simulate changes -- I only verified the CLK0 CLKFB case). Using the CLK0 feedback allowed the DCM to still work (still get a 2X output), but at the expense of using a BUFG from CLK0 to CLKFB (if there was no BUFG on CLK0). All told, we had three or four customers affected at that time who were unable to find an unused BUFG, and had to fall back to using the old mask set. Generally, the change was largely a success, as SPI 4.2 cores now worked with plenty of margin. If this was (is) your issue, I apologize. Since then, even small changes must undergo a complete review, of all blocks, and how they might be affected. I would contact your Xilinx FAE, who can help you with issue like this quickly and effectively (as we had a solution in place immediately). AustinArticle: 109053
FPGA is not a MicroController? .=2E.or is it !? MicroFpga makes an FPGA to look like an MCU, and makes it programmable as it would be a normal MCU without requiring any HDL knowledge or FPGA implementation tools. More details will be available from the product website http://www.microfpga.com .=2Esoon Availability =3D=3D=3D=3D=3D=3D=3D=3D MicroFpga is currently only available for selected EAP members - please contact eap@microfpga.com if you are interested to gain early access. MicroFpga is available NOW for the following devices =B7 XC3S200-FT256 =B7 XC3S200-VQ100 =B7 XC3S1000-FT256 Requirement for EAP/Beta testing is the availability at the test site of some FPGA hardware with any of the supported devices and possibility to configure that FPGA by some means. It doesn't matter on what board those FPGA's are mounted as long as there are some peripherals that can be used for visual confirmation, single LED is sufficient already. Software requirements =B7 MicroBlaze GNU Tools (get there http://www.xilant.com/downloads/mb_gnu_8.2.zip) =B7 Installed Xilinx ISE WebPack (only data2mem is used) =B7 JTAG Programming tool and cable (or other means to configure the FPGA) Antti Lukats Xilant TechnologiesArticle: 109054
I'm running a Spartan3E (100e, vq100) with the VHDL below.
It's connected to an LED display. The CLOCK_OUT, for some reason, is
bouncing before settling. When I connect an audio meter to the line, I
can hear it ringing on and off very quickly before settling back to
off. This is causing my DATA_OUT to be clocked many more times than
once. The VHDL below is a trimmed down version of what will be a more
complex project -- I'm just starting simple to assert that everything
works.
I have the large divider on it so that I can visually see each byte
getting clocked onto the LED panel. The behavior I am seeing is the
entire panel filled with each byte (because of the bouncing CLOCK_OUT).
The panel should be counting across.
My CLOCK_OUT pin is defined as the following in my UCF file:
NET "CLOCK_OUT" LOC = "P3" ;
I have tried, to no success:
NET "CLOCK_OUT" LOC = "P3" | PULLUP;
Thank you for any help!
entity driver is
Port ( CLOCK : in STD_LOGIC;
ACTIVE : in STD_LOGIC;
CLOCK_IN : in STD_LOGIC;
LATCH_IN : in STD_LOGIC;
DATA_IN : in STD_LOGIC_VECTOR (7 downto 0);
ADDRESS_IN : in STD_LOGIC_VECTOR (4 downto 0);
DATA_CLOCK_OUT : out STD_LOGIC;
CLOCK_OUT : out STD_LOGIC;
LATCH_OUT : out STD_LOGIC;
DATA_OUT : out STD_LOGIC_VECTOR (7 downto 0) );
end driver;
architecture Behavioral of driver is
signal mode : STD_LOGIC := '0';
signal divider : STD_LOGIC_VECTOR(23 downto 0) :=
"000000000000000000000000";
signal output : STD_LOGIC_VECTOR(7 downto 0) := "00000000";
begin
process( CLOCK )
begin
if( rising_edge( CLOCK ) ) then
if divider="000000000000000000000000" then
if mode='0' then
CLOCK_OUT <= '0';
LATCH_OUT <= '0';
elsif mode='1' then
DATA_OUT <= output;
CLOCK_OUT <= '1';
LATCH_OUT <= '1';
output <= output + 1;
end if;
mode <= not mode;
end if;
divider <= divider + 1;
end if;
end process;
end Behavioral;
Article: 109055Great list Kevin! > 4. Transform operations that depend on two operands into one that > depends on a single operand and a constant. This is somewhat of a more > specific example of a 'better algorithm'. An example of this would be > let's say you have a counter that needs to count up to a programmable > number of counts and then reset. One way to do this would be to > provide a writable register that contains the 'stop count'. Reset the > counter to 0 and count up until you get to 'stop count'. If you do > that you'll find the critical path to be the statement "if Count = > Stop_Count then....". If 'Count' and 'Stop_Count' are 10 bit numbers > then the '=' function will take as input 20 signals. A different > approach would be to preload the counter with 'stop count' and then > count down until you get to 0. Now you will be comparing count to a > hardcoded number (i.e. 0) which means the '=' function will only take > as input 10 signals. Most likely fewer logic resources and better > timing. There's an even better way (cf. Peter Alfke): widen the counter with one more bit (if necessary), and start the count one below the original value. When the original counter reached 0, the new counter will roll around to all ones, thus you only have to check the top bit. Since I saw this brilliant trick, I've used it everywhere. (It is of course yet another trade-of, but it's saving many LUTs at the expense of one cheap FF and one fast carry chain). In general the "Decide what to do..." boils down to fully understanding: the target resources (their strengths and limitations), what you are trying to achieve, and what potential trade-ofs can be made. Generally there's no "quick fix", only hard work. TommyArticle: 109056
Hi Andreas/Roger, I am afraid that SuSe is not an officially supported Linux distribution by Xilinx currently. We are evaluating the need for support of SuSe for future releases of Xilinx Tools though. Right now RH3.0 and 4.0 are the only oficiallly supported Linux Distributions. if you would like to request the priority raised on the SuSe support, please contact your nearest FAE and let them know. Thanks Duth Roger wrote: > "gauckler" <gauckler@fh-furtwangen.de> wrote in message > news:1158562165.368801.101410@i3g2000cwc.googlegroups.com... > > Hi, > > > > i tried to simulate a small vhdl design with xilinx ISE (8.1 - 8.2 > > spxx, Webpack or foundation) running SuSE 10.1 linux, unfortunately > > there is an error. Because the VHDL code simulates with SuSE 9.2 I > > assume the code is fine and there are no spaces in the file path. > > > > Started : "Check Syntax". > > Running vhpcomp > > Compiling vhdl file "/home/PBuser2/parity/parity.vhd" in Library > > isim_temp. > > Entity <parity> compiled. > > Entity <parity> (Architecture <behavior>) compiled. > > Compiling vhdl file "/home/PBuser2/parity/tb_parity.vhd" in Library > > isim_temp. > > Entity <tb_parity_vhd> compiled. > > Entity <tb_parity_vhd> (Architecture <behavior>) compiled. > > Parsing "tb_parity_vhd_stx.prj": 0.03 > > > > Process "Check Syntax" completed successfully > > > > Running Fuse ... > > Parsing "tb_parity_vhd_beh.prj": 0.00 > > Building tb_parity_vhd_isim_beh.exe > > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > > > > Has anybody simulated ISE isim under SuSE 10.1. Any hint is > > appreciated. > > > > Andreas > > > > Same thing with just ISE - no solution. Sorry. This really is something > Xilinx should be sorting. > > Rog.Article: 109057
Peter Kampmann wrote: > Hmm I don't understand how this can work, can you explain it to me? > The Peripheral runs at, say 120 Mhz, the Bus delivers data at 100 Mhz. How many bits is the data? If it's 8 bits, can you gang 4 together to make 32 bit chunks? Or 2 16 bit chunks to make 32? If your data bandwidth can't fit in the bus capacity, what can you do? Go back to the drawing board. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109058
Jon Beniston schrieb: > > I worked before with the NIOSII and a price tag was on the tool. As I > > can see it here there is not much difference with the Lattice approach. > > Even if someone finds later a 3rd party low cost board and debugger you > > still need to buy the ispLEVER software for $595. > > Or is there a complete free solution with the LatticeMico32? > > Lattice give you the RTL for free and you are allowed to use it on any > device, including non-Lattice devices. i.e. you don't have to buy > ispLEVER or any Lattice FPGAs. > > In contrast, the NIOS and MicroBlaze RTL costs tens of thousands of > dollars, and I believe you are only able to use it either in an ASIC or > on their devices. > > Cheers, > Jon MicroBlaze source code license costs 19 KUSD the Mico32 RTL is free, but... it is too advanced verilog for Xilinx XST so synplify is needed for synthesis :( AnttiArticle: 109059
Alex wrote: > if( rising_edge( CLOCK ) ) then > if divider="000000000000000000000000" then > if mode='0' then > CLOCK_OUT <= '0'; > LATCH_OUT <= '0'; > elsif mode='1' then > DATA_OUT <= output; > CLOCK_OUT <= '1'; > LATCH_OUT <= '1'; > output <= output + 1; > end if; > > mode <= not mode; > end if; > > divider <= divider + 1; > end if; It's probably unrelated but you're putting data up on the lines and at the same time telling the panel to latch/clock in the data. Why not put the "DATA_OUT <= output" in the mode = '0' region to give some setup time? I'm assuming the panel clocks in data on rising edge of clock. Speculation: Perhaps lowering the drive strength on the clock pin might reduce the ringing? I've not played around with such constraints but I've seen reference to them. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109060
Is it possible to generate a XXXMHz clock with hardware, and connect the OPB BUS CLK to that pin? Or is the OPB BUS limited at 100MHz? Regards, KyleArticle: 109061
> > MicroBlaze source code license costs 19 KUSD Source yes, but not RTL. My guess it's lots of instantiated primitives, thus not portable. Last time I asked about ASIC licensing, they wanted 150k. Funnily enough, I went elsewhere ;-) Cheers, JonArticle: 109062
Kyle H. schrieb: > Is it possible to generate a XXXMHz clock with hardware, and connect > the OPB BUS CLK to that pin? Or is the OPB BUS limited at 100MHz? > > Regards, > Kyle the OPB (and PLB) bus clocks must be phase aligned on rising edges with the PPC proc clock. So when PPC clock is 300 max bus clock would be 100MHz AnttiArticle: 109063
Is this not similar to Xilinx's PPC and MicroBlaze cores using EDK? Possibly a much cheaper solution? Regards, KyleArticle: 109064
eric schrieb: > Hi, > how can I make a MPMC2 and a MontaVista Linux on ML403 from Xilinx work > together? > > Is there a howtoguide for that problem or has anybody experiences with > that stuff? > > Thanks a lot :-) > > Eric get it working with normal flow without MPMC2 first then make the MPMC2 design to much the normal system as much as possible then proceed changing the linux kernel to boot on MPMC2 based system AnttiArticle: 109065
I'm just curious and it might not be applicable to application but did you try targeting a Stratix II? If you did what kind of fMax's where you able to achieve? Derek rickman wrote: > I was updating a CPU design I did a few years ago and I was a bit > disappointed in the results I see. The CPU was originally targeted to > an Altera ACEX part which is 5 volt compatible (to give you an idea of > its age). I did my own CPU because Altera does not support their NIOS > for that family. I spent a fair amount of time optimizing the > architecture to be easy to implement in 4 input LUTs and other basic > elements found in FPGAs. I coded it up for the ACEX async memories and > got it running. If memory serves me, it clocked in at 55 MHz max and I > used it at 40 MHz. > > Currently I wanted to look at how fast it might run if I redid it for a > current FPGA architecture using synchronous memories. I compiled it > for a Spartan 3 and got the speed up to 77 MHz using less than 10% of > an XC3S400 (315 slices). I am not impressed with the speed. I > expected a much larger increase and had hoped for operation at over 100 > MHz. I checked the timing analyzer output and the signal paths are > pretty much what I expected, no oddball logic generation and I got > carry chains where I wanted them. The slow paths have a few long route > times, so although it may approach 100 MHz with careful floorplanning, > I don't think this is worth the effort compared to the >> 100 MHz CPU > cores you can get from the FPGA vendors. > > I was wondering if this small speed up is typical of improvements from > one or two generations difference in FPGAs? The ACEX parts are > designed for economy, not for speed, just like the Spartans. When I > did the initial design 3 or 4 years ago, the ACEX parts were old news > then! Given that there was nothing in the design that is tailored for > one FPGA family over another, I guess I expected more like a 2X speedup > in the current technology chip. Isn't that reasonable given the vast > difference in the timing specs in the data sheets?Article: 109066
Göran Bilski wrote:
> Doing an "OR" is done like this
>
> MUXCY_I : MUXCY_L
> port map (
> DI => '1',
> CI => Subtract_carry_out,
> S => Inverted signal_to_or_with,
> LO => oring_result);
>
> Here the oring result is high if either the subtract_carry_out is high
> or the inverted signal_to_or_with is high.
Why is the inverter needed, can't you just switch the order of
inputs:
MUXCY_I : MUXCY_L
port map (
DI => Subtract_carry_out,
CI => '1',
S => signal_to_or_with,
LO => oring_result);
2nd point, wouldn't the synthesizer be expected to make this
optimization automatically? On the face of it this sounds
like vendor lock-in. If you take advantage of this you're tied
to xilinx parts...
-Dave
--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Article: 109067Kyle H. schrieb: > Is this not similar to Xilinx's PPC and MicroBlaze cores using EDK? > > Possibly a much cheaper solution? > > Regards, > Kyle Hi Kyle, using PPC or MicroBlaze usually requires both ISE and EDK and usually some hardware (HDL) knowledge as well - isnt that so? using MicroFpga requires only 1) FPGA 2) C compiler it does *NOT* require 1) FPGA vendor provided tools 2) any HDL knoweldge there is a difference I think ;) AnttiArticle: 109068
> > using PPC or MicroBlaze usually requires both ISE and EDK and usually > some hardware (HDL) knowledge as well - isnt that so? > > using MicroFpga requires only > 1) FPGA > 2) C compiler > > it does *NOT* require > 1) FPGA vendor provided tools > 2) any HDL knoweldge > > there is a difference I think ;) Ok, I'll bite... So why is it better than using an MCU? Cheers, JonArticle: 109069
Jon Beniston schrieb: > > > > using PPC or MicroBlaze usually requires both ISE and EDK and usually > > some hardware (HDL) knowledge as well - isnt that so? > > > > using MicroFpga requires only > > 1) FPGA > > 2) C compiler > > > > it does *NOT* require > > 1) FPGA vendor provided tools > > 2) any HDL knoweldge > > > > there is a difference I think ;) > > Ok, I'll bite... > > So why is it better than using an MCU? > > Cheers, > Jon Jon, have you seen a MCU with 1700+ pins? :) MicroFgpa makes FPGA to look like MCU that can access ALL FPGA pins available on a given package. It does not require any external components, no proper ext reset signal or any external clocks. I am not saying it is somehow better - its just an option, an option to run normal C programs on any FPGA, can be really useful for board testing, in education, doing funny things...? setting up an FPGA project for initial PCB board bringup takes time right? with MicroFpga you can INSTANTLY test the PCB using test programs written in plain C not a minute wasted with synthesis or P&R. if I count the minutes, hours and days I have spent with board bringup and test FPGA designs - it could be come years of time that I could have be saved. Antti PS I just received email from our first MicroFpga EAP member who confirms the functionality on Digilent Spartan3 Starterkit. (as I dont have any boards with that FPGA then I had not tested it myself - but it was working!)Article: 109070
Hello, I've never heard of AHB or APB. I've heard about the Wishbone interface for I2C. Wishbone is basically an open source hardware computer bus intended to let the parts of an integrated circuit communicate with each other. The aim is to allow the connection of differing cores to each other inside of a chip. The Wishbone Bus is used by many designs in the OpenCores project. I'm assuming you got the I2C interface via Opencores.org? I've successfuly used the I2C interface from Opencores.org. Let me know what you are trying to do. If you have any questions about this particular I2C, I'd be more than happy to help you. -Markus vits wrote: > Hi, > I came across these buses i2c ,ahb,apb.What is the difference between > them. > I dont know about the ahb or apb .just started reading about i2c. > I have to test the i2c bus in verilog. In i2c bus DUT(design under > test) i saw something > like wishbone interface or ahb thing.what does it mean .please explain > me in detail. > or give some links.I am exploring them too. > Thanks, > VittalArticle: 109071
Hi All, I like to use the Spartan 3E Starter kit as audio capture/playback developping system as it has Linear Technology's DAC and ADC built in. Ideally I want to be able to connect it to a computer speaker and microphone just like a computer sound card. But I guess it requires some external analog circuit and also the line-in and line-out connector to interfac with the DAC and ADC. Is there any reference design avaialbe for this type of external circuit? Or if there is any commercial expansion/add-on card to support this purpose that works with Spartna 3E Starter Kit? Thanks a lot! WilliamArticle: 109072
it's my humble understanding that Mico32 is truly RTL, i.e. we do not use any library elements, so it should be portable. (although, of course, we'd like for you to buy our chips!) rgds, Bart Borosky, Lattice, online marketing manager > > Source yes, but not RTL. My guess it's lots of instantiated primitives, > thus not portable.Article: 109073
bart schrieb: > it's my humble understanding that Mico32 is truly RTL, i.e. we do not > use any library elements, so it should be portable. (although, of > course, we'd like for you to buy our chips!) > rgds, > Bart Borosky, Lattice, online marketing manager > > > > Source yes, but not RTL. My guess it's lots of instantiated primitives, > > thus not portable. Yes it is. but it uses verilog at such advanced level that is not supported by Xilinx XST synthesis, e.g. it is only useable with Synplify as synthesis tool AnttiArticle: 109074
bart schrieb: > it's my humble understanding that Mico32 is truly RTL, i.e. we do not > use any library elements, so it should be portable. (although, of > course, we'd like for you to buy our chips!) > rgds, > Bart Borosky, Lattice, online marketing manager > > > > Source yes, but not RTL. My guess it's lots of instantiated primitives, > > thus not portable. Yes it is. but it uses verilog at such advanced level that is not supported by Xilinx XST synthesis, e.g. it is only useable with Synplify as synthesis tool Antti
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