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 31675

Article: 31675
Subject: Re: Spartan2 PCI-IP Core @ power-up
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 02 Jun 2001 12:14:47 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma <kolja@sulimma.de> writes:

> Austin Franklin wrote:
> 
> > The PCI core itself, as far as PCI accessibility, is really only
> > configuration space.  I don't believe there's really anything to access
> > there for a "driver"...  If you mean access the resources that are behind
> > the BARs etc. of course, that makes sense...but there isn't anything in the
> > core it self that requires a driver, per se, I don't believe, and they would
> > be particular to the application the back end is designed for, not the core.
> >
> > I don't understand what would be particular to "the PCI core", as opposed to
> > any PCI device...the real particulars for a driver are what's in the memory
> > and I/O space, and that's outside the core.


> Ahh. At least you need a driver to find out to what address your PCI
> device was mapped.  This would pretty much concern the core.

No, it concerns the result of the PCi-discover routine, which is not
deopendant upon the PCI core, but a part of the main OS, and dependent
on the main PCI board.

> Also you would like to enable and disble memory ranges,

See above.

> enable interupts, burst
> mode, ....
> Core functions too.

Is there interrupts in the Xilinx PCI core? Interrupts tend to be
system dependent.

> When all this is done, all there is left to do to access you card is to map the
> memory ranges to user space.
> (Ooops, another core related function)

Not done by any driver. See above.

Depends on what you mean by a driver. You need SW for the above tasks,
but finding out the memory range, mapping and so on is not dependant
on the PCI card/core, but of the OS on the main board.
 
> After that, you can start using the functionality that you connected to the
> core.

Sure. But the above tasks does not require a driver.

The core is a part of a complete PCI function, and there is no point
in writing a driver for it, as it cannot do anything useful by itself.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 31676
Subject: Re: Spartan2 PCI-IP Core @ power-up
From: Kolja Sulimma <kolja@sulimma.de>
Date: Sat, 02 Jun 2001 12:44:32 +0200
Links: << >>  << T >>  << A >>
I do not know to much about driver development outside a Linux system.
Therefore your information could be very helpful for me.
(My customers just won't switch to Linux, damn)


> > Ahh. At least you need a driver to find out to what address your PCI
> > device was mapped.  This would pretty much concern the core.
>
> No, it concerns the result of the PCi-discover routine, which is not
> deopendant upon the PCI core, but a part of the main OS, and dependent
> on the main PCI board.

What you are saying is, that I can write a user mode programm without the use of a
DDK to ask where my board was mapped? Let's say with win2k, winNT, ...

> > Also you would like to enable and disble memory ranges,
>
> See above.
>
> > enable interupts, burst
> > mode, ....
> > Core functions too.
>
> Is there interrupts in the Xilinx PCI core? Interrupts tend to be
> system dependent.

They are part of the  PCI standard as far as the core is concerned.(Section 2.2.6)
The handling, routing, etc. of the interupt are system dependant, but the core could
not care less.

> > When all this is done, all there is left to do to access you card is to map the
> > memory ranges to user space.
> > (Ooops, another core related function)
>
> Not done by any driver. See above.

Again: I really, really would like to do this from a user mode program without a
driver.
Please tell me how.

> Depends on what you mean by a driver. You need SW for the above tasks,
> but finding out the memory range, mapping and so on is not dependant
> on the PCI card/core, but of the OS on the main board.

That is right. It will be the same problem for any kind of card regardless of
functionality.
But it needs to be done, and as far as I know it is usually done within the driver.

> The core is a part of a complete PCI function, and there is no point
> in writing a driver for it, as it cannot do anything useful by itself.

But know it will take me a week to figure out how to map my memory ranges to user
space under win2k.
If you give me source code for that I will implement the functionality in an hour or
two.
Therefore from my point of view, the above functions are 90% of the driver.
(Remember, I am not talking about directX8 drivers, but about something as parallel
port cards, 4 channel data aquistion circuits, and so on. The driver functionality is
close to NIL)

Kolja Sulimma


Article: 31677
Subject: Re: Xilinx webpack and modelsim
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Sat, 02 Jun 2001 21:40:15 +1000
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > > > Simple question!
> > > >
> > > > My design simulates with modelsim and fits OK with webpack.
> > > >
> > > > My question is how do I re-import my design into modelsim to check it
> > > still
> > > > works?
> > > >
> > > > Cheers
> > > > Dave
> > >
> > > Why would you want to do that?
> > >
> > > There should be no need for timed stand-alone simulations provided you
> used
> > > TIMESPECs, and your TIMESPECs are accurate.
> >
> > ... and the tools don't have bugs.
> >
> > ... and the speed files accurately reflect the operation of the silicon.
> >
> > Bitten by both on my last project.  Ouch.
> >
> > In the speed file case, a gate level simulation won't help, as the back
> > annotated VHDL (or Verilog, etc.) will have the values from the speed
> > files, not the values from the silicon.  The only way to catch these is
> > to try them in the lab, over temperature and voltage variations.
> >
> > The gate level simulation was useful for picking up some of the tool
> > bugs.  Others bugs were more amenable to inspections using FPGA Editor,
> > or netlist browsing.

Hi Austin,
 
> Please name the tools and tool bugs you found doing timed simulations, as
> well as the bugs you found using FPGA editor.  I know MANY designers who do
> exactly as I stated and have never had a problem.

You do test your designs, don't you?  ;-)

Offhand, I can't think of a project I've worked on recently where I
*haven't* found an undocumented tool bug.  Mostly they are minor things
though.

Using *untimed* gate level simulations, I only found one serious tool
bug in my last project, in Synplify 6.0.0.  It was getting the initial
state of flip flops wrong.

In VHDL:

process(clk, gsr)
begin
  if gsr = '1' then
    ff <= '1';
  elsif rising_edge(clk) then
    ff <= something else;
  end if;
end process;

Synplify would recognise that the async reset on the ff was actually the
Xilinx GSR net, so it wouldn't bother to explicitly put the reset info
in the EDIF output, and so the fact that the reset state was '1' (and
not the default '0') was lost.

I believe that this has been fixed in more recent versions.  It took
some weeks to get Synplify support to understand this problem, even when
it was expressed in very simple terms.

Another favourite (not in Synplify) was this assignment to a top level
output port:

x <= 'Z';

You would think that this would make the output tristate.  Instead, it
turned into:

x <= '0';

That synthesis tool (which shall remain nameless) has also been fixed,
and now generates the correct code.

These bugs were found by running the back annotated gate level VHDL
through my regular VHDL test bench for the chip.  The test bench would
tell me that there was a problem.  Then I needed FPGA editor to work out
where the problem was in the chip (although the gate level VHDL source
and a text editor would have been just as good, if a little cumbersome).

> If you do a back annotated simulation, you do not have to run this as a
> timed simulation, you can still do it as unit delay.

Yes, this is the way I normally do them.  I'm a big believer in
functional simulation and static timing analysis.  (Although care is
needed to ensure the correctness of multicycle paths.)
I should point out that I don't normally do gate level simulation,
except when I suspect that there is a tool problem.
 
> As you said, the speedfile issue is a non-issue, simply because you are
> using the speedfiles TO generate the timing information for the back
> annotated simulation.  So, why even bring that up?

I wanted to point out that there are limitations of timed, gate level
simulations.
I should have also brought up silicon bugs (again, bitten on my last
project) as another example of something that can't be found in a gate
level simulation.

Regards,
Allan.

Article: 31678
Subject: Re: Spartan2 PCI-IP Core @ power-up
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 02 Jun 2001 16:26:16 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma <kolja@sulimma.de> writes:


> > > Ahh. At least you need a driver to find out to what address your PCI
> > > device was mapped.  This would pretty much concern the core.
> >
> > No, it concerns the result of the PCi-discover routine, which is not
> > deopendant upon the PCI core, but a part of the main OS, and dependent
> > on the main PCI board.
> 
> What you are saying is, that I can write a user mode programm
> without the use of a DDK to ask where my board was mapped? Let's say
> with win2k, winNT, ...

No, what I'm saying is that it's the responsibility of the OS to
discover and map the PCI boards, and then call the vendor supplied -
board specific! - driver.

If your board can't do anything, there is no point in having a driver.

What you need is an OS specific development toolkit.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 31679
Subject: Re: Xilinx webpack and modelsim
From: "Austin Franklin" <austin@dar54kroom.com>
Date: Sat, 2 Jun 2001 11:28:38 -0400
Links: << >>  << T >>  << A >>
> Hi Austin,
>
> > Please name the tools and tool bugs you found doing timed simulations,
as
> > well as the bugs you found using FPGA editor.  I know MANY designers who
do
> > exactly as I stated and have never had a problem.
>
> You do test your designs, don't you?  ;-)

Naw, we just throw them over the wall and tell them if it doesn't work, it
must be software.

> > If you do a back annotated simulation, you do not have to run this as a
> > timed simulation, you can still do it as unit delay.
>
> Yes, this is the way I normally do them.  I'm a big believer in
> functional simulation and static timing analysis.

Er, then what's the fuss?

>  (Although care is
> needed to ensure the correctness of multicycle paths.)

Why?

> I should point out that I don't normally do gate level simulation,
> except when I suspect that there is a tool problem.

I have not run into the problems you cited, but I don't use VHDL...ever
think that might be the problem ;-)

You are right, that certainly is an acceptable "excuse" for doing back
annotated simulations...but, given your lead, they would be equally, if not
more, error prone.  I found more bugs in the back annotation tools than in
the front end tools.




Article: 31680
Subject: Re: bitstream compression in Xilinx
From: Alan Nishioka <alann@accom.com>
Date: Sat, 02 Jun 2001 08:38:04 -0700
Links: << >>  << T >>  << A >>
Mike wrote:

> Bitstream compression uses something called MultiFrame writes.  This means that if two (or more) configuration frames have the
> same data, they can all be written with one command.

Do you know what the file format is?

I am currently reading .bit files, but I would like to save a few bytes (to reduce disk space and file transfer time)

Alan Nishioka
alann@accom.com



Article: 31681
Subject: Re: My80-- i8080A instruction compatible processor core
From: Iouri Besperstov <iouri@interlog.com>
Date: Sat, 02 Jun 2001 11:43:49 -0400
Links: << >>  << T >>  << A >>
No, I didn't find on Zilog.com, I think Zilog doesn't provide open microprocessor core
any different idea where I can get core fore Z180 or Z182

Thanks

Iouri


CBFalconer wrote:

> Iouri Besperstov wrote:
> >
> > CBFalconer wrote:
> >
> > > Richard Erlacher wrote:
> > > >
> > > > On Tue, 29 May 2001 13:06:57 GMT, "Mark Walter" <maw@nospam.com>
> > > > wrote:
> > > >
> > > > >It appears that the tools for the SFL language support conversion to Verilog
> > > > >or VHDL.  Is it possible someone can convert this 8080 processor core into
> > > > >Verilog or VHDL.  Then it could be used with the Xilinx tools for creating a
> > > > >8080 clone...
> > > >
> > > > Since there are still V40 and V50 devices available, albeit with some
> > > > difficulty, but at a small fraction of the cost of a major FPGA, it
> > > > might be well to examine one of those processors for use of its
> > > > built-in 8080 core.  You can, if you like, use the 8086-compatible
> > > > instruction set to execute what will probably have to be an original
> > > > BIOS, yet use the internal 8080 to execute the CP/M code.  Of course
> > > > it's not Z-80 compatible, but who cares?
> > >
> > > That only makes sense if you want the 8086 instruction set also.
> > > Otherwise why not just use a Z180?  All Z80's execute the 8080
> > > instruction set, with the exception being some parity bit
> > > settings, and nobody in their right mind ever wrote code that ran
> > > into that after the first z80's came out.
> >
> > How or where I can get Z180 or Z182 core???
>
> Try zilog.  http://www.zilog.com  Or almost any distributor.
>
> --
> Chuck F (cbfalconer@my-deja.com) (cbfalconer@XXXXworldnet.att.net)
> http://www.qwikpages.com/backstreets/cbfalconer :=(down for now)
>    (Remove "NOSPAM." from reply address. my-deja works unmodified)
>    mailto:uce@ftc.gov  (for spambots to harvest)


Article: 31682
Subject: Re: [Q]setup-time violation
From: Paul Campbell <paul@verifarm.com>
Date: Sat, 2 Jun 2001 16:18:26 +0000
Links: << >>  << T >>  << A >>
Ben wrote:

> It is very interesting that they have a special cell for synchrnonizers
> though I don't find any special cell in my ASIC library.

that may well be true not every library has one - usually you would map the 
cells you know are synchronisers to the special cell in your library and 
mark it dont_touch (tm :-) so that it doesn;t get remapped to something else

> Fortunately, I could just avoid this timing error during verilog prelayout
> simulation by using characteristics of the two clocks.
> One clock domain of my design was synthesized barely fit into 30ns (33MHz
> PCI clock) and the other was 40 ns.
> Thus if I use two clocks of period 30ns and 40ns each, and make the
> initial rising edge of each clock to coincide, then I have 10ns margin for
> any neighboring rising edge of the two clocks.
> This blew out my agony.

be VERY carefull - in real life those edges wont perfectly overlap - if 
anything you need to toss some clock skew in the mix. Of course you are 
using this trick to avoid the setup/hold issues on the clock domain 
crossing paths - but what happens if there are other paths you are unaware 
of? my personal preference to to declare false paths on only the paths that 
I've determined to be synchronised (ie have synchronisers etc etc) and set 
up the rest so that any unknown paths jump out with timing errors so that I 
can pay attention to them.

Because you are using DW you are kind of forced to work with mutiple clocks 
- I have found that a better design style for multiple clock domain work is 
to write each clock domain seperately, each in its own hierarchy (you 
should probably put domains that synchronous wrt each other together) and 
then create a top level verilog module that brings the clock domains 
together - that way any wires that go between modules at this top level are 
by definition domain crossing and should be synchronised. The other great 
thing about this way of doing things is that you can synthesise each of the 
sub-blocks with a single clock (synopsys runs faster!) and resolve all the 
timing issues there - when you've synthesised the sub modules you then read 
them into synopsys along with the top level verilog, ungroup them then 
write the result out (without compiling) this gives you the netlist with 
all the clock domains in it but without any timing having been done between 
them (after all by definition there is  no timing between asynchronous 
domains)

        Paul

Article: 31683
Subject: Exact URL for ordering Webpack ISE CDROM?
From: "Dave Feustel" <dfeustel@mindspring.com>
Date: Sat, 2 Jun 2001 13:29:58 -0500
Links: << >>  << T >>  << A >>
I've been poking around the Xilinx website trying to find a
URL from which I can order the Webpack ISE cdrom.
So far no joy.

Does anyone know the exact Xilinx url for ordering the Webpack
ISE CDROM?

Thanks,

Dave Feustel



Article: 31684
Subject: Re: Exact URL for ordering Webpack ISE CDROM?
From: Simon <simon@unique-id.com>
Date: Sat, 02 Jun 2001 21:03:38 +0100
Links: << >>  << T >>  << A >>
Dave Feustel wrote:
> 
> I've been poking around the Xilinx website trying to find a
> URL from which I can order the Webpack ISE cdrom.
> So far no joy.
> 
> Does anyone know the exact Xilinx url for ordering the Webpack
> ISE CDROM?

If you get no joy, I can send you the one that came free
with my Burch kit. It's only a 'cd single' size, but I
think it's got everything on it. (I had already d/l'd all
the software :-)

ATB,
	Simon.
-- 
Freedom ? What's that ? (see http://www.domesday.co.uk/ )

Article: 31685
Subject: Which Tools Work with ATMEL FPSLIC?
From: "Dave Feustel" <dfeustel@mindspring.com>
Date: Sat, 2 Jun 2001 15:27:19 -0500
Links: << >>  << T >>  << A >>
I now have the Open Tech 1.1.0 CDROM set
Can any of the tools on this cdrom set generate
FPGA configuration bitstreamss for Atmel Parts?
(Particularly the Atmel FPSLIC)

How about for Xilinx parts (Spartan-2, Virtex)?

Which parts (Atmel, Xilinx, other) are best for
implementing open cores?

Thanks,

df





Article: 31686
Subject: Re: Exact URL for ordering Webpack ISE CDROM?
From: "Dave Feustel" <dfeustel@mindspring.com>
Date: Sat, 2 Jun 2001 15:41:30 -0500
Links: << >>  << T >>  << A >>
What is the FPGA kit?

"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message news:3B1439AE.D684F26@jetnet.ab.ca...
> Simon wrote:
> > If you get no joy, I can send you the one that came free
> > with my Burch kit. It's only a 'cd single' size, but I
> > think it's got everything on it. (I had already d/l'd all
> > the software :-)
>
> Hmm another good point for the FPGA kit!



Article: 31687
Subject: QuickLogic programming HW for sale
From: jesse@jumboprawn.net (jesse)
Date: 2 Jun 2001 14:44:23 -0700
Links: << >>  << T >>  << A >>
We have some excess materials left over from a project.
This includes some remaning parts to program QuickLogic
devices. Please visit and make offer at:
http://www.jumboprawn.net/forsale/ql_100144.html
http://www.jumboprawn.net/forsale/ql_base.html

Article: 31688
Subject: Re: bitstream compression in Xilinx
From: Mike <none@null.net>
Date: Sat, 2 Jun 2001 15:20:15 -0700
Links: << >>  << T >>  << A >>
Alan,

The decompression is done at the hardware level.  Virtex 
bitstreams are really just a sequence of reads and writes to 
registers- it's a very processor-like interface.  When a compression
bitstream is created, this file just has some different commands in it.  It's not compression like zip or tar compression (software level
compression/decompression).  The bit file will be the smallest
file you can get for configuration.

Mike

Article: 31689
Subject: Re: simulation of Viewdraw schematics containing VirtexII flip flops.
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 02 Jun 2001 16:35:00 -0700
Links: << >>  << T >>  << A >>

Hi Pete,

This looks more like a library error than a VSM/Viewbase error.

Can you send me a design fragment that has this problem, including the
viewdraw.ini file, and tell me which version of the viewdraw libraries
you are using, and which instalation kit they came from.

Hope to help,

Philip Freidin

On Fri, 1 Jun 2001 13:09:04 -0600, "Pete Dudley" <padudle@sandia.gov> wrote:
>Hello All,
>I have just encountered a problem simulating my Viewdraw schematics that
>contain VirtexII flip flop symbols. It appears that the viewdraw symbols use
>the @INIT parameterized attributes to control the initial state of flip
>flops but the simulation netlister VSM does not parse them correctly. I get
>the following error from VSM.
>
>ER Error: viewbase: Error 338: Undefined variable(s) encountered
>(FLOATVAL=@INIT).
>|        Occurred on net instance $1I1\$1I15\GSR_INIT0
>I realize that it is unfashionable to use schematic entry but I have some
>large blocks of IP that I want to carry forward from an old Virtex design.
>If anyone knows a workaround for this one I would appreciate a hint.
>
>Thanks,

===================
Philip Freidin
philip@fliptronics.com
Host for WWW.FPGA-FAQ.COM

Article: 31690
Subject: Re: My80-- i8080A instruction compatible processor core
From: edick@hotmail.com (Richard Erlacher)
Date: Sun, 03 Jun 2001 01:32:24 GMT
Links: << >>  << T >>  << A >>
There are some not-so-obvious advantages, e.g. use of
ISA-board-resident EPROM code to operate an ISA card in lieu of
building a replacement for a common ISA circuit, e.g. a SCSI adapter,
or the like.  building an ISA adapter to a V40/V50 is dirt simple.
Using adapter-resident ROM code requires, of course, that you know how
to use that code, but given that it's not a secret ... 

The other thing is that you can, at your option, run CP/M-86 as well.
The V50, for example has a 16-bit bus and makes IDE interfacing quite
simple.  Moreover, development tools for the 8086 instruction set are
in everybody's hands these days, while Z180/Z280, or ARM tools are
not.  I'd suspect that a 16 MHz V50, which has serial I/O, DMA,
interrupt, and counter/timer logic on board, would be pretty fast,
too.

It's just a thought, after all.  Using an 8086-code BIOS is not a bad
idea, though.

Dick


On Fri, 01 Jun 2001 04:34:01 GMT, CBFalconer <cbfalconer@my-deja.com>
wrote:

>Richard Erlacher wrote:
>> 
>> On Tue, 29 May 2001 13:06:57 GMT, "Mark Walter" <maw@nospam.com>
>> wrote:
>> 
>> >It appears that the tools for the SFL language support conversion to Verilog
>> >or VHDL.  Is it possible someone can convert this 8080 processor core into
>> >Verilog or VHDL.  Then it could be used with the Xilinx tools for creating a
>> >8080 clone...
>> 
>> Since there are still V40 and V50 devices available, albeit with some
>> difficulty, but at a small fraction of the cost of a major FPGA, it
>> might be well to examine one of those processors for use of its
>> built-in 8080 core.  You can, if you like, use the 8086-compatible
>> instruction set to execute what will probably have to be an original
>> BIOS, yet use the internal 8080 to execute the CP/M code.  Of course
>> it's not Z-80 compatible, but who cares?
>
>That only makes sense if you want the 8086 instruction set also. 
>Otherwise why not just use a Z180?  All Z80's execute the 8080
>instruction set, with the exception being some parity bit
>settings, and nobody in their right mind ever wrote code that ran
>into that after the first z80's came out.
>
>-- 
>Chuck F (cbfalconer@my-deja.com) (cbfalconer@XXXXworldnet.att.net)
>http://www.qwikpages.com/backstreets/cbfalconer :=(down for now)
>   (Remove "NOSPAM." from reply address. my-deja works unmodified)
>   mailto:uce@ftc.gov  (for spambots to harvest)
>
>


Article: 31691
Subject: Re: bitstream compression in Xilinx
From: Alan Nishioka <alann@accom.com>
Date: Sat, 02 Jun 2001 20:10:44 -0700
Links: << >>  << T >>  << A >>
Mike wrote:

> The decompression is done at the hardware level.  Virtex
> bitstreams are really just a sequence of reads and writes to
> registers- it's a very processor-like interface.  When a compression
> bitstream is created, this file just has some different commands in it.  It's not compression like zip or tar compression (software level
> compression/decompression).  The bit file will be the smallest
> file you can get for configuration.

I assumed that compression meant software compression, so I didn't even try it.
Now that I try it, it works fine. It saves me about 10 percent.

Thank you very much for your help

Alan Nishioka
alann@accom.com


Article: 31692
Subject: XtremeDSP Ready for prime time?
From: cybin <cybin@home.com>
Date: Sun, 03 Jun 2001 04:33:09 GMT
Links: << >>  << T >>  << A >>
I've been using system Generator for three months since it's release and
have found somewhat erratic performance. I would be interested in
sharing my experience with other System Generator users in hopes of
finding and sharing solutions that would be of benefit to all. Perhaps a
data base could be constructed outside the Xilinx infrastructure for
this purpose.

Regards,

Article: 31693
Subject: Re: Spartan2 PCI-IP Core @ power-up
From: "Austin Franklin" <austin@dar54kroom.com>
Date: Sun, 3 Jun 2001 00:56:47 -0400
Links: << >>  << T >>  << A >>
> > > > Ahh. At least you need a driver to find out to what address your PCI
> > > > device was mapped.  This would pretty much concern the core.
> > >
> > > No, it concerns the result of the PCi-discover routine, which is not
> > > deopendant upon the PCI core, but a part of the main OS, and dependent
> > > on the main PCI board.
> >
> > What you are saying is, that I can write a user mode programm
> > without the use of a DDK to ask where my board was mapped? Let's say
> > with win2k, winNT, ...
>
> No, what I'm saying is that it's the responsibility of the OS to
> discover and map the PCI boards, and then call the vendor supplied -
> board specific! - driver.
>
> If your board can't do anything, there is no point in having a driver.
>
> What you need is an OS specific development toolkit.
>
> Homann

Thank you, of course, for chiming in.  My other point was that a driver is
NOT PCI "core" dependant.  Whether you use the Xilinx PCI core, or any other
core that provides PCI configuration, and target/master function support,
the driver will not be different...if the back end is the same.





Article: 31694
Subject: Re: [Q]setup-time violation
From: bknpk@hotmail.com (pini)
Date: 3 Jun 2001 00:15:07 -0700
Links: << >>  << T >>  << A >>
Hi 
I suggest the following:
1. Use special names for the synchronized FF. Special means something to be 
   easily found with a PERL/c-shell/... in the SDF file.
2. Write a PERL scripts that looks in the SDF file for the offending FF devices.
   Set the setup check off.

"Ben" <ejhong@future.co.kr> wrote in message news:<3VkR6.218$by4.4024@news2.bora.net>...
> Hi,
> 
> I use two independent clocks and an asynchronous fifo from synopsys
> DesignWare in my design.
> This means there is frequent data transfer between the clock domains.
> During the simulation, a fliflop which gets signal from another flipflop of
> different clock domain generated setup time violation error.
> The flipflop must be some kind of synchronizer for internal control of fifo.
> I think this kind of error is ubiquitous for 2-clock design or any design
> that has synchronizer for asynchronus signal in it, and believe that there
> is some technique which will prevent or bypass timing error during
> simulation.
> Please help me out of this problem.
> 
> Thanks,
> 
> Ben

Article: 31695
Subject: Re: [Q]setup-time violation
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 03 Jun 2001 11:10:07 +0100
Links: << >>  << T >>  << A >>


pini wrote:

> Hi
> I suggest the following:
> 1. Use special names for the synchronized FF. Special means something to be
>    easily found with a PERL/c-shell/... in the SDF file.
> 2. Write a PERL scripts that looks in the SDF file for the offending FF devices.
>    Set the setup check off.
>
>

I personally feel that a metastab error can ruin your day so badly that you should *not*
disable them in simulation. To this end I've generated modified versions of the Xilinx X_FF
& X_SFF simprims primitives that:

o Set the output to `X' for a - parametrizable - period of time after a su/hld violation.

o Then randomly set the output to 0 or 1.

I then use the tricks 1 & 2 + a perl script to change the instantiations of the
synchronisers to the hacked version.

I'll put the stuff on our FTP if anyone's interested.

Note that using 1. above also makes it easy to pick out the synchronisers in the .ucf file &
apply special timing constraints.




Article: 31696
Subject: PCI Config Register Space
From: T-Online <Mario.Heike.Niklas@t-online.de>
Date: Sun, 03 Jun 2001 12:11:58 +0200
Links: << >>  << T >>  << A >>
Who can help me ?
Is it right, that the PCI Configuratins Register Space of an PCI -
Device access with a Config Adress Register (0CF8h) and Config Data on
=CFAh ? How can i use this register, and what have done this with the
Configurations Register Space ?

Thanks!
Mario


Article: 31697
Subject: Re: Virtex LUT4 problems in FPGA Express
From: Kent Orthner <korthner@hotmail.nospam.com>
Date: 03 Jun 2001 21:25:24 +0900
Links: << >>  << T >>  << A >>
Michael Dales <michael@dcs.gla.ac.uk> writes:
> I'm trying to implement an algorithm using the LUT4 on Virtex. I have
> numerous variations on the following:
> 
>  lut_0:  LUT4 generic map (INIT => X"0E6E")
>    port map (res(0), val(0), val(1), val(2), val(3));
> 
> This simulated fine using the Alliance libraries compiled for Cadence
> Leapfrog, but when I tried to run it through FPGA Express it barfs on
> my generic map, with the following error:
> 
> "Bad formal part - port names in entity and component declarations do
> not match."
> 
> I checked the unisim vcomponents file and the component declaration
> seems to be correct.

Hi, Michael.

I would suggest posting more of your VHDL code here, especially the
component declaration, since that's where you got the error.

My guess is that you didn't include the INIT generic in the declaration?

You might also try explicitly naming on all the ports in your port map. 
(Shouldn't make a difference, but it looks clearer to those of us trying 
to figure out what you're doing.)

For example:

  lut_0:  LUT4 generic map (INIT => X"0E6E")
    port map (O =>res(0), I0=>val(0), I1=>val(1), I2=>val(2), I3=>val(3));


Hope this helps,
-Kent

Article: 31698
Subject: one state machine
From: finishf@yahoo.com (finish)
Date: 3 Jun 2001 05:37:45 -0700
Links: << >>  << T >>  << A >>
hello,

i can't find the clue on how to solve optimally this problem in
vhdl,(or verilog), any help please!!!
i want to design an irregular counter
say acound modulo 8 but with these outputs
[4,7,2,3,0,1,6,5]

someone suggests me to design a counter and later add such similair
code
CASE counter IS
    WHEN 0 => output <= 4;
    WHEN 1 => output <= 7;
.....

i expect that the synthesizer will do it in 2 logic levels, whereas
one logic level is feasible ?

thanks

Article: 31699
Subject: Re: Looking for free (try) xc4000e software ?
From: Dave Vanden Bout <devb@xess.com>
Date: Sun, 03 Jun 2001 09:12:39 -0400
Links: << >>  << T >>  << A >>
Wisut Hantanong wrote:

> I mean of  pub license like some linux software or demo or shareware.
>
> thank you.

There is no freeware that supports the XC4000E family.  You can buy the
Xilinx Student Edition 2.1i for $55 and it supports the smaller devices
up to the XC4013.


--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||





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