Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 89350

Article: 89350
Subject: Re: Followup: USB cable, Xilinx XUP, EDK/ISE 7.1, Fedora Core 3
From: "S.T." <st@iss.tu-darmstadt.de>
Date: Tue, 13 Sep 2005 14:00:43 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: CPU benchmark for Xilinx PAR
From: "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com>
Date: Tue, 13 Sep 2005 08:23:28 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Post synthesis simulation errors
From: "Giox" <giovanniparodi79@yahoo.it>
Date: 13 Sep 2005 05:27:39 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Post synthesis simulation errors
From: "Giox" <giovanniparodi79@yahoo.it>
Date: 13 Sep 2005 05:31:14 -0700
Links: << >>  << T >>  << A >>
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: 89354
Subject: Re: ISE 7.1i & Linux / reg code question
From: "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com>
Date: Tue, 13 Sep 2005 09:07:45 -0400
Links: << >>  << T >>  << A >>
On 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
Subject: Re: Reading a PAL fusemap with a microscope
From: "Gabor" <gabor@alacron.com>
Date: 13 Sep 2005 06:11:35 -0700
Links: << >>  << T >>  << A >>
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: 89356
Subject: Re: SDRAM quality
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 13 Sep 2005 06:14:42 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Microblaze & Memory DMA operation
From: =?UTF-8?B?R8O2cmFuIEJpbHNraQ==?= <goran.bilski@xilinx.com>
Date: Tue, 13 Sep 2005 15:31:01 +0200
Links: << >>  << T >>  << A >>
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öran

Article: 89358
Subject: Re: Followup: USB cable, Xilinx XUP, EDK/ISE 7.1, Fedora Core 3
From: Paul Hartke <phartke@Stanford.EDU>
Date: Tue, 13 Sep 2005 07:28:36 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: XUP Virtex-II Pro "invalid target architecture"
From: Paul Hartke <phartke@Stanford.EDU>
Date: Tue, 13 Sep 2005 07:34:01 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Reading a PAL fusemap with a microscope
From: "Marc Reinig" <nospam@nospam.com>
Date: Tue, 13 Sep 2005 14:36:26 GMT
Links: << >>  << T >>  << A >>
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
Subject: 24 Counters on one board
From: "Le.Wang" <lewang@weh.rwth-aachen.de>
Date: Tue, 13 Sep 2005 17:13:54 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: 24 Counters on one board
From: Phil Hays <Spampostmaster@comcast.net>
Date: Tue, 13 Sep 2005 08:46:52 -0700
Links: << >>  << T >>  << A >>
"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 hot


Article: 89363
Subject: floppycontroller
From: Soenke <reverse_engineer@web.de>
Date: Tue, 13 Sep 2005 18:32:00 +0200
Links: << >>  << T >>  << A >>
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

Soenke

Article: 89364
Subject: Re: ISE 7.1i & Linux / reg code question
From: "kmlpatel@gmail.com" <kmlpatel@gmail.com>
Date: 13 Sep 2005 10:45:11 -0700
Links: << >>  << T >>  << A >>
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 Apps


Article: 89365
Subject: Re: place and route
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 13 Sep 2005 11:16:36 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Reading a PAL fusemap with a microscope
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 14 Sep 2005 07:46:46 +1200
Links: << >>  << T >>  << A >>
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)

-jg



Article: 89367
Subject: Re: ISE 7.1i & Linux / reg code question
From: Ram <r_fpga_dev@yahoo.com>
Date: Tue, 13 Sep 2005 19:51:37 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: 24 Counters on one board
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 14 Sep 2005 07:58:04 +1200
Links: << >>  << T >>  << A >>
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.

-jg


Article: 89369
Subject: Spartan-3 1000 -5 availability
From: "Finn S. Nielsen" <removfinnstadel@tiscali.dk>
Date: Tue, 13 Sep 2005 21:59:23 +0200
Links: << >>  << T >>  << A >>
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 ?

Finn
 



Article: 89370
Subject: Re: Microblaze & Memory DMA operation
From: Ram <r_fpga_dev@yahoo.com>
Date: Tue, 13 Sep 2005 20:32:23 GMT
Links: << >>  << T >>  << A >>
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
Subject: FIFO design using Virtex-II block ram..
From: "Remco" <whybcuz@yahoo.com>
Date: 13 Sep 2005 13:34:25 -0700
Links: << >>  << T >>  << A >>
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


Article: 89372
Subject: Re: place and route
From: "Sven" <sven-habermann@gmx.de>
Date: 13 Sep 2005 13:53:24 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: place and route
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 13 Sep 2005 14:27:41 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: FIFO design using Virtex-II block ram..
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 13 Sep 2005 21:36:46 GMT
Links: << >>  << T >>  << A >>
"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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search