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 Kris Kris Heyrman wrote: > I have been working off and on trying to use the Xilinx XUP board on > Linux Fedora Core 3 with EDK 7.1 and ISE 7.1. I have been fairly > succesful with the software, but downloading the bitstream over the USB > cable has got me baffled. It has worked a few times, but most of the > time there seem to be errors in transmission and this makes the board > trying to do this: So you are more successfull than i. I asked Xilinx about it 2 month ago and the answer was that in a later revision the usb adapter of the XUP will work. But it seems as if ise71sp4 still doesn't do the trick for me. But in my case i am not able to upload some code since the three chips are marked as unkown. Digging around i found that this seems to be a special version of the ez-usb device which needs a firmware loaded via fxload (take a look at the /etc/hotplug/usb/xusbdfwu xusbdfwu.fw files). My suspection is that this XUP doesn't work with the standard firmware distributed with ise71 (bin/lin/xusbdfwu.hex). Probably there is a way to extract this hex from a windows driver version. But at a first glance i found no hexfile in the windows ise. > Date: Apr 26 2005. Xilinx patches for ISE and EDK have been applied. ise xinfo tells you the exact version. Could you give me your version number? I would be interested which firmware is loaded into your board. does diff /etc/hotplug/xusbdfwu.fw/xusbdfwu.hex $XILINX/xusbdfwu.hex give some output? > Is there a good way to determine what is causing this unreliability? > Are there any tests I can perform? I would be very grateful for any > suggestions. The easiest way is to use an good old paralell cable V and connect with this cable. But i would also be really interested in a real usb solution :-( Hope this helps S.T. Hey Xilinx are you listening?Article: 89351
On Tue, 13 Sep 2005 00:00:43 -0700, Paul Gentieu wrote: > Here's a benchmark for PAR (high effort level) running on two different CPUs. The design utilized about 40% of an XC2V4000-5 and had some difficult-to-meet timing constraints. PAR's peak memory usage was ~500 MB. > > Intel Pentium D 830 (3.0 GHz), 2 GB RAM: Total CPU time to PAR completion: 2 hours 32 mins > > AMD Athlon 64 4000+ (2.4 GHz), 2 GB RAM: Total CPU time to PAR completion: 1 hour 2 mins > > I was blown away by the result. I was expecting a modest speed increase with the AMD- maybe 1.3x, if you go by the model number- but certainly not 2.5x. Based on this benchmark, the AMD CPU should actually be called a 7500+. :) > > The Pentium is a dual core and the AMD is a single, but the Xilinx software utilizes only one core so this is a fair comparison of raw processor speed. > > The Pentium probably gets killed by its deep pipelines. I'd guess that PAR, like most real-world apps, consists mainly of spaghetti code rather than regular loops processing masses of similar data. So the Pentium spends a lot of its time flushing pipelines because of mispredicted branches and such. It probably suffers from its higher memory access latency as well. > > It sure would be nice if Xilinx could made their software multithreaded... then an Athlon X2 4800+ would really scream. As it is, I'd guess that an Athlon FX-57 (2.8 GHz) will give the fastest PAR performance currently possible. > > -Paul That's consistent with what I've seen. Note the 4000+ has a 1M cache which is critical for the performance of EDA codes. For NCVerilog I've found that when recordvars is off there is a 2 to 1 difference between an A64 with a 1M cache vs one with a 1/2M cache. I now have a 4400+ in addition to the 3400+ and the 3800+ shown on this page, http://www.polybus.com/linux_hardware/index.htm I haven't updated my benchmark page with the the 4400+ results but they are consistent with the other results. The 4400+ is about 10% faster then the 3400+ on single threaded jobs like NC or Xilinx place and results which is exactly what you would given that each core in the 4400+ runs at the same clock speed and has the same cache size (1M) as the 3400+ but it has dual memory channels vs a single channel on the 3400+.Article: 89352
The post route verilog (it starts as follow the following) // Xilinx Verilog netlist produced by netgen application (version G.30) // Command : -sim -ofmt verilog -sdf_anno true -w -s 8 FIOS_with_FSM_out // Input file : FIOS_with_FSM_out.ncd // Output file : FIOS_with_FSM_out.v // Design name : FIOS_with_FSM // # of Modules : 1 // Xilinx : /mentor/software/xilinx // Device : v300efg456-8 (PRODUCTION 1.69 2003-12-13) // This verilog netlist is a simulation model and uses simulation // primitives which may not represent the true implementation of the // device, however the netlist is functionally correct and should not // be modified. This file cannot be synthesized and should only be used // with supported simulation tools. `timescale 1 ns/1 ps module FIOS_with_FSM ( CLK, READY, RESET, S_parameter );Article: 89353
The post place and route module is:
module FIOS_with_FSM ( CLK, READY, RESET, S_parameter);
and the testbench is as follows:
`resetall
`timescale 1ns/10ps
module test_FIOS_with_FSM ;
// Inputs
reg CLK;
reg RESET;
reg [7:0]S_parameter;
// Outputs
wire READY;
// Instantiate the Unit Under Test (UUT)
FIOS_with_FSM uut (
.CLK(CLK),
.RESET(RESET),
.READY(READY),
.S_parameter(S_parameter)
);
////////////////////////////////////////////////////////////////////////////////
initial
CLK = 1'b0; //set clk to 0
always
#25 CLK = ~CLK; //toggle clk every 5 time units
////////////////////////////////////////////////////////////////////////////////
initial begin
// Initialize Inputs
RESET = 1;
S_parameter = 8'b00001100;
#100;
RESET = 0;
S_parameter = 8'b00001100;
#100;
end
endmodule
It seems to me that it is correct but if you note something wrong let
me know
Article: 89354On Tue, 13 Sep 2005 11:18:59 +0000, Ram wrote: > Hello, > > Adrian, Duane, Jim: > > Thanks for the info. So far the unofficial word is 2:1, Windows code Reg ID > will work on Linux. > > To Xilinx guys here: Any official response? > > The Registration ID that I was given by the Xilinx FAE DOES work on Windows, > but continues to fail with Linux. The FAE says the Windows codes should > work on Linux but has no official experience with the Linux version. > > Any other things people suggest I look at? I'm using Kubuntu Linux (Ubuntu) > with a custom 2.6.12.2 kernel with SMP. > > Thank you all. > Ram. The Xilinx installer is very distribution sensitive although the tools aren't. I keep Whitebox Linux 3 (RHEL3) on one of my older machines and do by Xilinx installs there, once the install is done I rsync the Xilinx directory to by other machines.Article: 89355
logjam wrote: > I've had success reading the fuse map! :) It took 200x and a decent > microscope. Still holding the cheap digital camera to the eye piece, > but hey...it works. :) > > You can see in the images below that a HAL has all the fuses, but some > have been cut. So my guess would be rather than them being > manufactured with a pattern, they are manufactured 100% connected and > then mechanically cut later? I was under the impression that HALs were chaper than PALs. Therefore it would be unlikely that such a process would be used. While the gap at the "blown fuse" is small, it does not look significantly different than other gaps in the metalization pattern. I think a mechanical process would have left some sort of recognizable "scar" at the cut. The other method used commonly to remove metalization, "laser trimming", would also leave some visible mark. More likely the HAL started from the same mask set as the PAL, but the cuts were added to the mask. Also it is likely that to save more on processing, the "fuse" metallization is actually the standard aluminum used in the rest of the chip rather than the alloys used for a fusible link. All of the cuts would be in a single mask layer, allowing the factory to pre-build most of the chip and do quick turns for new patterns. Just my 2 cents, GaborArticle: 89356
Regarding the PC RAM issue, is anything being overclocked? That seems really odd that they would mostly all fail... on all the PC's for that matter. I would try the RAM in another PC and see what happens. But regarding your issue, I highly doubt signal integrity would be a problem at 66 MHz, unless you have seriously long trace-lengths. I have seen SDRAM working on 2 layer boards without any controlled impedance whatsoever, as long as lengths are kept relatively short.Article: 89357
Ram wrote: > Hello Adrian, and Göran, > > >>If the system is running at 75 MHz, you need a transfer every 425 clock >>cycle. >> >>I doubt that the memory transfers gonna be your bottleneck in the system. > > > Agreed. > > >>More important is where is the processing done, in MB or in HW? >>What kind of processing of the audio data are you planning to do? > > > The current idea is completely in HW. Simple IIR filtering of each channel > and programmable summing (similar to the mixer idea Adrian mentioned). MB > is only involved in managing base memory pointers to audio streams, so if > an audio stream is to be changed over, MB controls this. Some logic (DMA > process?) monitors the base address and continues to fetch and fill the > FIFOs. > > The main purpose of MB though is to make it easy to control/alter the > coefficients and do other house keeping chores (display, control, etc). > > Getting uCLinux would be great as this adds a network stack and a whole host > of possibilities. > > >>If you would need more bandwidth, I would go for the MCH(FSL) that >>exists on our memory controller now. It's basically a pipe from your >>module to the external memory. MicroBlaze is using 2 of these for >>getting faster cachelines accesses. > > > As you pointed out, the bandwidth is probably not the critical issue. > Really what I was getting at is, with a MB, OPB_Memory_Controller (SDRAM or > DDR), how should I shuffle data from the external memory to my logic? > > At first glance, I did not see any traditional DMA type of logic which could > be used to transfer from the external memory (via OPB_Memory_Controller) to > internal FIFOs. Have I missed something? > > Thank you! > Ram. Hi, I would connect the filtering modules as FSL modules to MicroBlaze. It makes the movement of data much easier. If the data don't need to be touch/modified after your filtering it can pipe the data directly to your audio interface with more FSL channels. This allows you to build a pipe where MicroBlaze reads data from memory, does some mangling with them before sending them to your HW modules over FSL connections. Your HW modules would receive data and process them before sending them to the FSL based audio module. This will create a pipe where MB could fetch more data, while the HW modules process other data and while your audio module outputs the data. It also makes it easier to test and debug since you can connect your audio module directly to MB and let MB send some test sound to verify the functionality. You can also connect your HW processing modules output back to MB to verify that it also functions correctly. This is exactly what I did for a MP3 player application. Göran GöranArticle: 89358
Hi S.T., You don't mention which specific OS version or windrvr you are trying to use. As you probably know, only RHEL is officially supported. Various folks--including myself--have played around and gotten FC and other Linux distros to work. However, the further from RHEL the more likely you are to have issues. Just making sure you have seen Xilinx solution records 18612 and 20762. Note that you certainly have to recompile the drivers as described for any other version of Linux you are using. The problem with the version numbers is discussed in SR2150 and has indeed been fixed in the latest service packs. Paul "S.T." wrote: > > Hi Kris > > Kris Heyrman wrote: > > I have been working off and on trying to use the Xilinx XUP board on > > Linux Fedora Core 3 with EDK 7.1 and ISE 7.1. I have been fairly > > succesful with the software, but downloading the bitstream over the USB > > cable has got me baffled. It has worked a few times, but most of the > > time there seem to be errors in transmission and this makes the board > > trying to do this: > So you are more successfull than i. I asked Xilinx about it 2 month ago and > the answer was that in a later revision the usb adapter of the XUP will > work. But it seems as if ise71sp4 still doesn't do the trick for me. But in > my case i am not able to upload some code since the three chips are marked > as unkown. Digging around i found that this seems to be a special version > of the ez-usb device which needs a firmware loaded via fxload (take a look > at the /etc/hotplug/usb/xusbdfwu xusbdfwu.fw files). My suspection is that > this XUP doesn't work with the standard firmware distributed with ise71 > (bin/lin/xusbdfwu.hex). Probably there is a way to extract this hex from a > windows driver version. But at a first glance i found no hexfile in the > windows ise. > > > Date: Apr 26 2005. Xilinx patches for ISE and EDK have been applied. > ise xinfo tells you the exact version. Could you give me your version > number? I would be interested which firmware is loaded into your board. > does > diff /etc/hotplug/xusbdfwu.fw/xusbdfwu.hex $XILINX/xusbdfwu.hex > give some output? > > > Is there a good way to determine what is causing this unreliability? > > Are there any tests I can perform? I would be very grateful for any > > suggestions. > The easiest way is to use an good old paralell cable V and connect with this > cable. But i would also be really interested in a real usb solution :-( > > Hope this helps > S.T. > > Hey Xilinx are you listening?Article: 89359
That's really weird--I cannot remember the last time I installed and don't have the CDs anywhere around. In all this, don't forget that the XUPV2P EDK support files "requires EDK v7.1 with SP2 and ISE v7.1 with SP3." Good Luck! Paul "zoinks@mytrashmail.com" wrote: > > Yes it's weird. I had three CD's: two of them said CD 1, and one said > CD 2. > The "second" CD1 was said to be the "international" version. However, > it gave "missing file" errors when it started to install a certain part > (can't remember what), but as far as I could see it was installing > exactly the same things that the "other" CD1 already installed. > > So I only installed from the first CD1 and CD2. I'll try to reinstall > when I have time. For the moment I gave up on 7.1 and I'm still working > with the 6.3 version. > > Stupid that I didn't realize this before....ugh....got a lot on my mind > lately :) > > Anyone else had this problem too? (Or at least could give me some info > about those weird two CD1's) > > I would appreciate it.Article: 89360
Gabor is correct. PAL's are programmed by blowing fuses or storing injecting charge like a flash device. You can get factory programmed PAL's but they are still PAL's and are no different than the ones you buy. Programming is a relatively expensive process. HAL's are 'Hard Array Logic'. They are programmed with a mask (the final, metal mask) during manufacturing. They are generally ordered only in large volume because the cost of the mask, testing and marking must be spread over the end volume. Also, sometimes they can be made on smaller die, though for the case of a 16X8 I doubt anyone bothers today. Marc Reinig System Solutions "Gabor" <gabor@alacron.com> wrote in message news:1126617095.796923.239650@g43g2000cwa.googlegroups.com... > logjam wrote: >> I've had success reading the fuse map! :) It took 200x and a decent >> microscope. Still holding the cheap digital camera to the eye piece, >> but hey...it works. :) >> >> You can see in the images below that a HAL has all the fuses, but some >> have been cut. So my guess would be rather than them being >> manufactured with a pattern, they are manufactured 100% connected and >> then mechanically cut later? > > I was under the impression that HALs were chaper than PALs. Therefore > it would be unlikely that such a process would be used. While the > gap at the "blown fuse" is small, it does not look significantly > different than other gaps in the metalization pattern. I think > a mechanical process would have left some sort of recognizable > "scar" at the cut. The other method used commonly to remove > metalization, "laser trimming", would also leave some visible > mark. > > More likely the HAL started from the same mask set as the PAL, but > the cuts were added to the mask. Also it is likely that to save > more on processing, the "fuse" metallization is actually the > standard aluminum used in the rest of the chip rather than the > alloys used for a fusible link. All of the cuts would be in > a single mask layer, allowing the factory to pre-build most of > the chip and do quick turns for new patterns. > > Just my 2 cents, > Gabor >Article: 89361
Hello everyone, I am a totally newbie with FPGA, I really need some help for our project. We have 24 simple digital signals, and we want to build a FPGA-Board to take count of the pulses of each digital signal, so it runs just like 24 counters, and the results should be transfered to PC with a USB-Interface. I have found pretty much information about FPGA, but I really don't know which is suitable for this job. Could someone give me some suggestions (e.g which type, which mark, the price and so on)? I very appreciate for any help. Le P.S: What we need is a design-kit, because maybe we could program more functions on it in the future.Article: 89362
"Le.Wang" <lewang@weh.rwth-aachen.de> wrote: >Hello everyone, > >I am a totally newbie with FPGA, I really need some help for our project. > >We have 24 simple digital signals, and we want to build a FPGA-Board to take >count of the pulses of each digital >signal, so it runs just like 24 counters, and the results should be >transfered to PC with a USB-Interface. > >I have found pretty much information about FPGA, but I really don't know >which is suitable for this job. Could someone give me some suggestions (e.g >which type, which mark, the price and so on)? I very appreciate for any >help. Most any modern ram based (Xilinx or Altera, others) FPGA should handle 24 counters at frequencies up to 100 MHz or more. >P.S: What we need is a design-kit, because maybe we could program more >functions on it in the future. I plugged some likely words into a search engine (www.google.com) and quickly found this: http://www.opalkelly.com/products/xem3001.html I've never done business with this company. You might find something cheaper, larger, closer to home, easier to use, etc. Spending some time searching the web would be worthwhile. -- Phil Hays to reply solve: phil_hays at not(coldmail) dot com If not cold then hotArticle: 89363
Hi All, I'm looking for a fpga/vhdl implementation for a simple floppy-controller. Has someone an idea or adress or code :-) Thanx for any help SoenkeArticle: 89364
Ram, What's more than likely going on is that you were given either: 1. An evaluation Registration ID 2. A Foundation Simulator Registration ID Since both of these configurations are not currently supported on Linux, then the Registration ID you were given would not work for Linux, only Windows. However, if you were given a Foundation Registration ID, it would work across all supported platforms. Hope this helps. Best Regards, Kamal Patel Xilinx AppsArticle: 89365
When I say a P&R soft I mean replace Xilinx P&R. For doing this I need to undestand what is contained in the binary files produced by Xilinx P&R ;) This job is really impossible ? If very difficult ... any start points ?Article: 89366
logjam wrote: <snip> > > Those pictures were of the ASG, Apple Sound Generator, in the 128k to > Plus macintosh. I'm going to write a program to visually read the > fusemap so that I don't have to. > Pretty cheap, $45 for a chemical decap and then a few hours writing > down 1s and 0s. ;) You could have reversed engineered this with a Vector testing programmer, original circuit, and a text editor, but probably not as much fun... You can verify your logic, when done fusemap extracting, with vector testing and even create a new device - this sounds like a std 20 in 16x8 device ? (Also watch that some devices have pin polarity fuses) -jgArticle: 89367
Hi Josh, B. Joshua Rosen wrote: > The Xilinx installer is very distribution sensitive although the tools > aren't. I keep Whitebox Linux 3 (RHEL3) on one of my older machines and do > by Xilinx installs there, once the install is done I rsync the Xilinx > directory to by other machines. Yes, seems like it! Which directories do you end up having to rsync? Just one installation directory? I might go this route if I have to. Thanks, Ram.Article: 89368
Le.Wang wrote: > Hello everyone, > > I am a totally newbie with FPGA, I really need some help for our project. > > We have 24 simple digital signals, and we want to build a FPGA-Board to take > count of the pulses of each digital > signal, so it runs just like 24 counters, and the results should be > transfered to PC with a USB-Interface. > > I have found pretty much information about FPGA, but I really don't know > which is suitable for this job. Could someone give me some suggestions (e.g > which type, which mark, the price and so on)? I very appreciate for any > help. > > Le > P.S: What we need is a design-kit, because maybe we could program more > functions on it in the future. You need to specify the width ( how many bits ) in each counter and the expected MAX pulse rate. That tells you how much resource you need for the front end, at a minimum. Then, you might want to buffer this, so a read captures the whole counter into another latch - this avoids counter-change-during-read problems. This might fit in larger CPLDs like Altera MAXII or Lattice MachXO. [The MachXO can support their Mico8 small CPU ] For the back end (USB) you could use a small uC with USB, or a USB-Serial chip (FDTI, SiLabs etc). Maxim have posted data on a nice MAX 3420 SPI-USB bridge device, that needs minimal SW support, and is much faster than the RS232 ones. -jgArticle: 89369
Does anyone know what the current delivery situation is for XC3S1000-5FT256C. On Xilinx's website they say 3-4 weeks, but from Memec they say more than 8 weeks. Does anyone know the truth here.. Austin ? FinnArticle: 89370
Hi Göran: > I would connect the filtering modules as FSL modules to MicroBlaze. > It makes the movement of data much easier. > If the data don't need to be touch/modified after your filtering it can > pipe the data directly to your audio interface with more FSL channels. Would this not end up using 100% of the CPU for simple memory move operations? Ideally MB should be able to continue executing out of cache (while memory transfers are occurring) and resume when memory becomes available, no? The concern is long-term, if more audio channels are added that MB simply becomes an expensive memory controller. I am still thinking what other possibilities exist. Thanks. Ram.Article: 89371
Hi all We've set up a simple FIFO on a Spartan3 FPGA using the free code from Xilinx XApp258 (FifoCTLR_IC_V2.vhd) Initially this mechanism was tied to a DMA and we were having a hard time figuring out what was going on. By process of elimination, we tied the FIFO to an address and used the read/write strobed to read and write to the fifo. We can scribble data and read it back. The weird thing we're seeing is that the "empty" does not become true until data is read for the first time. It also becomes untrue with data left in the FIFO (usually 2 longs remaining). Has anyone seen this before? Or do we need to pay for the libary to get it fixed :) TIA RemcoArticle: 89372
impossible ... no very difficult ... yes i needed round about 3 month to understand approximate 70 percent of the configurationdata for the virtex-II pro architecture (i mean the real binary, which is stored in the configurationmemory of the fpga). the problem is the realy big complexity of the routing resources and so the programming of the switch-boxes. a start-point :) ?!? analyse the binarys from very simple designs, which use just few configureable resources (connections, LUTs, FFs, etc.) of an configureable element (clb, bram interconnect, etc.) GaLaKtIkUs=99 wrote: > When I say a P&R soft I mean replace Xilinx P&R. > For doing this I need to undestand what is contained in the binary > files produced by Xilinx P&R ;) > This job is really impossible ? > If very difficult ... any start points ?Article: 89373
Why? What do you hope to accomplish with this knowledge? I am curious. Austin GaLaKtIkUs™ wrote: > When I say a P&R soft I mean replace Xilinx P&R. > For doing this I need to undestand what is contained in the binary > files produced by Xilinx P&R ;) > This job is really impossible ? > If very difficult ... any start points ? >Article: 89374
"Remco" <whybcuz@yahoo.com> wrote in message news:1126643665.621179.25160@g44g2000cwa.googlegroups.com... > Hi all > We've set up a simple FIFO on a Spartan3 FPGA using the free code from > Xilinx XApp258 (FifoCTLR_IC_V2.vhd) > Initially this mechanism was tied to a DMA and we were having a hard > time figuring out what was going on. > By process of elimination, we tied the FIFO to an address and used the > read/write strobed to read and write to the fifo. > > We can scribble data and read it back. > The weird thing we're seeing is that the "empty" does not become true > until data is read for the first time. It also becomes untrue with data > left in the FIFO (usually 2 longs remaining). > > Has anyone seen this before? Or do we need to pay for the libary to get > it fixed :) > > TIA > Remco Or you could use the Xilinx FIFO Generator v2.2 Logicore for a more fully specified interface. The user guide has timing diagrams and signal descriptions that are probably much better than the XAPP258.
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