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 does somebody know a distributor for Spartan3e 500 in a pq208 or a tq144 housing? thanks urbanArticle: 108601
u_stadler@yahoo.de <u_stadler@yahoo.de> wrote: > hi > does somebody know a distributor for Spartan3e 500 in a pq208 or a > tq144 housing? No. Even the Xilinx "Webshop" doesn't carry these parts. I wish, Xilinx would have a Availablity forecast, like TI does. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108602
On 2006-09-13, Christian Metzler <cpmetz@usenet.cnntp.org> wrote: > Anyone got an Idea? Please don't tell to switch to Windows (everything > works under XP 32bit, so no bad Cable), since we currently only have > XP-x64 for this machine which is not supported by the Xilinx-Tools... Unfortunately your experience in Linux mirrors mine. My workaround is to boot windows to download the cypress firmware and then reboot into Linux. But this won't work for you since you only have XP-x64... I'm guessing now but the following workaround might work for you: * Connect the cable to a powered USB hub. * Connect the USB hub to a Win XP 32bit machine. * Wait until the firmware is loaded. * Reconnect the USB hub to your Linux machine and hope that the firmware is still loaded. I haven't tried this myself so I don't know if it will work for you. I would be really interested in hearing someone from Xilinx saying that "Yes, the USB platform cable is really working in Linux even if you don't load Windows first." Because in that case I could try the same kernel version and same fxload version they are using to see if that is the problem we are having. /AndreasArticle: 108603
Vasanth, Can you please tell how do I apply this patch in Windows environment? Thank you, Yuri Shteinman Vasanth Asokan wrote: > Andreas, > > It is indeed a bug. Thanks for taking the time to track this. I have > attached a naive fix (which will not avoid starvation). > The fix should appear in EDK 9.1i. > > thanks, > Vasanth >Article: 108604
Marlboro a écrit : > Austin Lesea wrote: >> "DONE did not go high" >> In my case (old XC4010E) the first symptom was that M0, M1, M2, left floating, did not polarize high as expected. So the parts entered master parallel mode with address pins toggling. When I put external pull-ups, the parts entered slave serial as expected and DONE went high - I did check that DONE came high on due time and not before the configuration file had been completely sent. After that configuration, my board did not operate well, but I did not investigate further. Using good parts, I checked that those external pull_ups did not prevent my board from correct operation. JAGArticle: 108605
Hello, As any user of Xilinx Chipscope Pro probably already noticed, the GUI is not that great. Especially when it comes to handling buses. One has to manually group each buses by hand and this is time consuming, especially if you're like me and you have 3 FPGAs in the jtag chain, each with 20 different buses. So I created a small perl script to automate this process, it's called csptool. I'm releasing this small script as open-source on Google Code: http://code.google.com/p/csptool/ Here is the help from the script: -------------------------------------------------------------- Features: - Supports multiple FPGA devices and multiple ILA units per FPGA - Supports Chipscope Pro v7.1.04i and v8.1.03i (Windows). Should work with other OS and/or other Chipscope versions too. - Supports regular buses, i.e. bus<0>, bus<1>, but also "state machine style" buses such as State_Fdd1, StateFdd2, etc. Usage: - Create a new cpj projet with Chipscope Pro Analyzer (might not work if project is not "fresh"). - Import the .cdc files to get relevant signal names. - For each unit and each FPGA, make the waveform appear by clicking "Waveform" in the left project tree. - Save the project (you don't need to close Chipscope). - Run the tool like this: csptool your_project.cpj (I suggest to associate .cpj files to csptool.exe, so that you can just double-click a .cpj file) - Reload your Chipscope projet. -------------------------------------------------------------- To use it, you must install a perl interpreter such as the free ActivePerl. Once this is done and you know that perl.exe is in your path, juste type: perl csptool.pl your_project.cpj You can make it even easier by compiling the perl script into a .exe and associating .cpj files to that .exe. That way, you simply have to double-click on your project in windows explorer and voil=E0. I'm sorry that I can't release a .exe publicly, I don't have a license for a perl compiler. If you want to contribute some features to the script (check the comments in the script for a suggested todo list) feel free to send me an e-mail and I'll gladly give you commit rights. I hope it can be useful to someone. Patrick DuboisArticle: 108606
Yuri, The patch is against the file Andreas referred to in his previous posts. To avoid touching the EDK installation area, you should ideally create and use a local copy of the kernel. Here are the steps, 1. Copy <edk_install>/sw/lib/bsp/xilkernel_v3_00_a into <your edk project>/bsp/xilkernel_v3_00_a. This becomes your local copy of the kernel. 2. In an EDK bash shell, cd to <your edk project>/bsp/xilkernel_v3_00_a 3. Run, "patch -p0 < mutex.c.patch" 4. Regenerate libraries from within XPS Step 3 assumes you have "patch" utility installed. If you don't, you can make the change referred to in the patch file yourself. It is just a one word change in xilkernel_v3_00_a/src/src/ipc/mutex.c. Vasanth "Yuri" <shteinman@squarepeg.ca> wrote in message news:1158179842.784063.280080@p79g2000cwp.googlegroups.com... > Vasanth, > Can you please tell how do I apply this patch in Windows environment? > > Thank you, > Yuri Shteinman > > Vasanth Asokan wrote: >> Andreas, >> >> It is indeed a bug. Thanks for taking the time to track this. I have >> attached a naive fix (which will not avoid starvation). >> The fix should appear in EDK 9.1i. >> >> thanks, >> Vasanth >> >Article: 108607
> ok, I see while you are busy with paying clients you have no longer > interest to work on mb-uclinux improvement. Good point. That is > possible the reason why Xilinx did choose lynuxworks to deliver the > microblaze 2.6.x port. I'm speechless. You win.Article: 108608
Comments below, > In my case (old XC4010E) the first symptom was that > M0, M1, M2, left floating, did not polarize high as expected. That could be a completely empty case, too. No pullups. No nothing. > So the parts entered master parallel mode with address pins > toggling. Only what you expect a real part to do. An empty package would not do this. > When I put external pull-ups, the parts entered slave serial > as expected and DONE went high - I did check that DONE came > high on due time and not before the configuration file > had been completely sent. This is a good sign. It must be a Xilinx FPGA if DONE goes high, and does so exactly after the serial bitstream finishes entering the part! > After that configuration, my board did not operate well, but > I did not investigate further. OK. "Did not operate" in what way? Everything remains tristate? Did INIT go high indicating a bad bistream (CRC error)? > Using good parts, I checked that those external pull_ups > did not prevent my board from correct operation. Not sure what this tells us. On a good part, it will configure serially, and work? That seems to be what you are saying. Are you sure the parts are identical? There have been various "flavors" of 4K parts (4, 4E, 4X, 4XL, 4XLA, 4XLV...). They are not the same from a bit stream point of view.Article: 108609
Austin Lesea a écrit : > OK. "Did not operate" in what way? Everything remains tristate? Did > INIT go high indicating a bad bistream (CRC error)? > My board-level tests failed. I did not investigate further at chip-level. I'll do. >> Using good parts, I checked that those external pull_ups >> did not prevent my board from correct operation. > > Not sure what this tells us. On a good part, it will configure > serially, and work? That seems to be what you are saying. > All my board-level tests were OK. > Are you sure the parts are identical? There have been various "flavors" > of 4K parts (4, 4E, 4X, 4XL, 4XLA, 4XLV...). They are not the same from > a bit stream point of view. Sure (XC4010E-3PC84).Article: 108610
Hi all, Has anyone seen any examples of Synplify Pro inferred rams that implement a reset input to clear the RAM contents? All of the synplicity examples I've seen do not show this. I also turned up a white paper on their website that said it was not possible but the paper is almost 5 years old so I'm hoping things have improved a bit. Thx, Chris P.Article: 108611
Show me the silicon where RAM contents can be reset. There are memories that allow the synchronous output register to be reset but I'm not aware of any RAM reset, only register arrays used as memory. "chrispy35" <chris.peake@gmail.com> wrote in message news:1158191087.305983.286560@d34g2000cwd.googlegroups.com... > Hi all, > > Has anyone seen any examples of Synplify Pro inferred rams that > implement a reset input to clear the RAM contents? All of the > synplicity examples I've seen do not show this. I also turned up a > white paper on their website that said it was not possible but the > paper is almost 5 years old so I'm hoping things have improved a bit. > > Thx, > > Chris P. >Article: 108612
I'm at a critical point before I build up too much code. Which is the more preferred/forward thinking approach? library IEEE; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; -- then used to_integer, etc. or library IEEE; use ieee.std_logic_1164.all; use ieee.numeric_std.all; -- then use conv_integer, etc. Thanks! Hope this isn't a question of religion... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108613
u_stadler@yahoo.de wrote: > hi > > does somebody know a distributor for Spartan3e 500 in a pq208 or a > tq144 housing? > > thanks > urban Why, oh why, doesn't Xilinx offer these parts in *any* quantity? I can think of lots of neat projects for FPGA's, but finding non-BGA parts is next to impossible. As it is, I find ways to lash eval and demo boards together. Hey, Xilinx - how about offering some hacker friendly parts, or finding a distributor that's willing to sell small quantities?Article: 108614
radarman wrote: >>does somebody know a distributor for Spartan3e 500 in a pq208 or a >>tq144 housing? > Why, oh why, doesn't Xilinx offer these parts in *any* quantity? I can > think of lots of neat projects for FPGA's, but finding non-BGA parts is > next to impossible. As it is, I find ways to lash eval and demo boards > together. > > Hey, Xilinx - how about offering some hacker friendly parts, or finding > a distributor that's willing to sell small quantities? I've seen some ads in the back of Nuts & Volts magazine that seem to offer little add on PCB's that allow soldering a BGA to it, then you end up with a DIP or something...Can't be too expensive if it's N&V. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108615
Benedikt Wildenhain wrote: > Hello, > > On Mon, Sep 11, 2006 at 12:10:38PM -0700, funkrhythm wrote: > > PORT hard_temac_0_GMII_TX_EN_0_pin = hard_temac_0_GMII_TX_EN_0, DIR = > O > xst complained when trying to set the direction to output for mii, so I > set it to input. > hmmm... that particular signal (tx_en) is definitely an output, as are about half of the MII signals > Now I want to try sending some IP packets accross the wire, but both > xilnet and lwip insist on using either opb_ethernet or -lite. Are there > any adjusted versions for one of these? > don't know about that, i am running linux on the V4FX12 and the EDK generates an ethernet driver (xilinx_gige) that works with the PLB_TEMAC -rimasArticle: 108616
Hi
I am trying to programm a XC2S300E through a microcontroller using the
Slave p mode.
I make a ufp file ( which is just a hex file) of my program using
xilinx ISE 8.1 and then using the microcontroller and and slave mode
signals I send it to the fpga.
I have all this working for another design, which is exactly the same
micro but Xc2S150E FPGA. but I can not get this to work on XC2S300E.
here is what happens:
1. I pulsed the ~prog line low and then high. ( to start the clearing
configuration memory)
2. I see FPGA lowers INIT line ( it shows it is busy clearning the
memory)
3. INIT goes high
4. I am sending Clock along with 8bit data on D[7:0] and CCLK.
5. I see INIT stays high ( so I thought CRC check was okay)
6. DONE stays low, I never see it coming up.
after extensive search on the Xilinx website I read something that I
could have a timing problem and I should keep sending CCLK till DONE
goes high. so I tried just running CCLK for like a full SECOND after I
was done sending my real data, and I still never saw DONE going high.
I purposly changed my hex file to see if I the CRC error happens and
INIT goes low. but I never saw this. INIT was high the entire time
after the initial memory clearning process( FPGA pulled it low then)
so this means I am not as far as CRC test on the flow chart. I am
wondering If FPGA thinks that it is not at the end of the file yet or
if it is reading anything at all.
I also checked the number of bits on hex file and it matches the number
on the Xilinx Datasheet. so I know I build the correct hex file.
I have 3 different boards with XC2S300E that I have this problem with.
so I doubt I have a connectivity issue or anything like that.
I also double checked my pull up and downs like 100 times by now. they
all makes sense and match my board with XC2S150E( which I can configure
with no problem)
Do you guys have any ideas where the problem coming from?.. what other
things I should look at?
I appreciate you taking the time and reading my long email and helping
me
Ben
From nobody@nowhere.com Wed Sep 13 17:27:55 2006
Path: newssvr29.news.prodigy.net!newsdbm05.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!news.linkpendium.com!news.linkpendium.com!news.glorb.com!postnews.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 13 Sep 2006 19:27:55 -0500
From: nobody <nobody@nowhere.com>
Subject: Re: Problems with NIOS II PIO interrupt
Date: Wed, 13 Sep 2006 19:27:55 -0500
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2006.09.14.00.27.48.598285@nowhere.com>
Newsgroups: comp.arch.fpga
References: <1158164612.233455.68550@e63g2000cwd.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 51
X-Trace: sv3-ufSDtv7ZOkzr8C742md+7Xe8ehaxMly3Q9ezNIQxp0sKQk1wx3+RjqAWBX/Nee8NQYmnrC3cyyeklxp!ssepusnzBDnW2jIErPRQ1y3BeDWfOKXzzJnoqIc5kpJ+SnbgTgz62mpNenwgEwaot3g=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.32
Xref: prodigy.net comp.arch.fpga:119511
On Wed, 13 Sep 2006 09:23:32 -0700, horst wrote:
> Hi,
> I've some trouble with NIOS II PIO interrupts and need some help.
> The pio port is configured as follows:
> Width= 2 bits
> Both input and output ports (not tri-state)
> Synchronously capture: Rising Edge
> IRQ= edge sensitiv
>
> I dont want to use HAL to keep the code size small, that's why I use
> alt_main.
>
> static void AudioCodecInISR(void* context, alt_u32 id) {
> volatile int inChL = 0;
> inChL = IORD_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase);
> /* Reset the Button's edge capture register. */
> IOWR_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase, 0);
> }
>
> int main (void) __attribute__ ((weak, alias ("alt_main")));
> int alt_main (void)
> {
> void * context;
> alt_irq_init(ALT_IRQ_BASE);
> IOWR_ALTERA_AVALON_PIO_IRQ_MASK(CodecIRQRegBase, 0x3);
> /* Reset the Button's edge capture register. */
> IOWR_ALTERA_AVALON_PIO_EDGE_CAP(CodecIRQRegBase, 0x0);
> /* Register the interrupt handler. */
> alt_irq_register( CodecIRQRegBase, context, AudioCodecInISR );
The order of the calls after alt_irq_init() need to be reversed.
In particular, you want to register the ISR before enabling
interrupts.
>
> while (1)
> {
> }
> return 0;
> }
>
> Does anybody has any clue where the bug is?
Could you give more details on how the bug manifests?
The code posted here doesn't do much of anything even
if the interrupt occurs.
Mark
Article: 108617David Ashley wrote: > I'm at a critical point before I build up too much code. > > Which is the more preferred/forward thinking approach? > > library IEEE; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use ieee.std_logic_unsigned.all; > -- then used to_integer, etc. > > or > > library IEEE; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > -- then use conv_integer, etc. > > Thanks! Hope this isn't a question of religion... > > -Dave > > Historically, std_logic_unsigned/signed is vendor proprietary and there have been differences between vendors treatment of those libraries. ieee.numeric_std is an honest standard, and won't give you grief if you have a mix of signed and unsigned in the same entity, and behaves the same regardless of whose tools you use. Use that. btw, to_integer belongs with ieee.numeric_std, and conv_integer goes with std_logic_unsigned/signed.Article: 108618
chrispy35 wrote: > Hi all, > > Has anyone seen any examples of Synplify Pro inferred rams that > implement a reset input to clear the RAM contents? All of the > synplicity examples I've seen do not show this. I also turned up a > white paper on their website that said it was not possible but the > paper is almost 5 years old so I'm hoping things have improved a bit. > > Thx, > > Chris P. > How do you propose to reset the RAM? This isn't a limitation of synplicity, it is a limitation of the silicon. Some RAM has output registers, such as Xilinx's BRAM. The reset on those primitives only resets the output register, not the RAM contents.Article: 108619
> use ieee.std_logic_1164.all; > use ieee.numeric_std.all; These are the ones to use. -JeffArticle: 108620
In most cases the memory has to be of a certain size for the tool to infer a BlockRAM. Smaller memories are implemented as distributed RAM SandeepArticle: 108621
Hi all, i am beginner in FPGA and i have a query about downloading FPGAs. i have a module1 and downloaded on device. now my question is that a module2 can be downloaded on same device(if free space available), then how. also i want to see result of both module simultaneosly. Regards J.RamArticle: 108622
Ray Andraka wrote: > David Ashley wrote: > >> I'm at a critical point before I build up too much code. >> >> Which is the more preferred/forward thinking approach? >> >> library IEEE; >> use ieee.std_logic_1164.all; >> use ieee.std_logic_arith.all; >> use ieee.std_logic_unsigned.all; >> -- then used to_integer, etc. >> >> or >> >> library IEEE; >> use ieee.std_logic_1164.all; >> use ieee.numeric_std.all; >> -- then use conv_integer, etc. >> >> Thanks! Hope this isn't a question of religion... >> >> -Dave >> >> > Historically, std_logic_unsigned/signed is vendor proprietary and there > have been differences between vendors treatment of those libraries. > > ieee.numeric_std is an honest standard, and won't give you grief if you > have a mix of signed and unsigned in the same entity, and behaves the > same regardless of whose tools you use. Use that. > > btw, to_integer belongs with ieee.numeric_std, and conv_integer goes > with std_logic_unsigned/signed. Crap...I hate making little typos like that. Anyway thanks, I had thought the numeric_std was the way to go, and ghdl's author/community was pushing in that direction as well, I just wanted confirmation. Now I need to switch back to the numeric_std, since I had gone the other way just to get the projects integrated... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108623
jrgodara@gmail.com wrote: > Hi all, > i am beginner in FPGA and i have a query about downloading FPGAs. > i have a module1 and downloaded on device. now my question is that a > module2 can be downloaded > on same device(if free space available), then how. > also i want to see result of both module simultaneosly. > Regards > J.Ram > I think partial reconfiguration aside, you can only download one module at a time onto an fpga, and your module would have to be the merging of module1 and module2 together. However this is very easy, you just create module3 that instantiates module1 and module2. Regarding partial reconfiguration, I don't know firsthand, just theory. The idea is part of the fpga keeps its programming, and you can reprogram some other part. So the part that remains constant can be doing the critical system stuff, and the other part can be swapped in and out as needed for the task at hand. My impression partial reconfiguration is a relatively new development, and not all devices support it, but a whole lot of people want it. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108624
>>ieee.numeric_std is an honest standard, and won't give you grief if you >>have a mix of signed and unsigned in the same entity, and behaves the >>same regardless of whose tools you use. Use that. Help! The new code I'm working up uses: A) library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all fine. But when I try to integrate it with code that uses: B) library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; Everything goes to crap. I use unsigned in my new code, but the existing code's "unsigned" doesn't match, they don't link up. Meaning I can't port map entities from my code using (A) into the project that uses (B). There is a lot of existing code, such as a model for a ddr: mt46v16m16.vhd which I need for simulation. That all uses (B). How can I get around this problem? I tried converting the code that uses (B) into using (A), but it's over my head and was just creating one compile error after another... To get it to build I converted my code to (B) and that works fine (and is easy) but I don't want to start down the dark path... Thanks-- -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architecture
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