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 43100

Article: 43100
Subject: Re: Architecture for high-level reconfigurable computing
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 14 May 2002 12:28:00 +1200
Links: << >>  << T >>  << A >>
Tim wrote:
> 
> Nicholas Weaver wrote
> 
> > Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key
> > is then loaded (through JTAG) into a distinct register on the part,
> > which has a separate power pin to maintain state.
> 
> All together, for the umpteenth time:
>     "Please can we have these few register bits as flash"

 Not until FLASH can be placed in the corner of a CMOS process,
without needing the rules/mask sets across the whole die.

 That said, there are companies claiming to have NV RAM 
processes,  supposedly CMOS FAB compatible - these are 
small size memories, but certainly OK for Keys / IDs / etc, 

 Then there's also MRAM...

-jg

Article: 43101
Subject: 50 mA sink
From: emanuel stiebler <emu@ecubics.com>
Date: Mon, 13 May 2002 18:45:57 -0600
Links: << >>  << T >>  << A >>
Hi all,
anybody out here knows a CPLD/FPGA which can sink at least 50 mA
on a 5V TTL compatible output ?

cheers & thanks

Article: 43102
Subject: Re: Neverending ISA bus interface drama, Spartan-II
From: Ray Andraka <ray@andraka.com>
Date: Tue, 14 May 2002 00:52:16 GMT
Links: << >>  << T >>  << A >>
Clamping diode?

Rick Filipkiewicz wrote:

> Peter Alfke wrote:
>
> >
> >
> > These circuits do not mysteriously work or don't work. ...
>
> ... unless they're being eaten by the great metastability beast. Maybe the
> work/!work is related to seasonal variation in lab temperature :-).

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 43103
Subject: Re: Architecture for high-level reconfigurable computing
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 14 May 2002 03:41:23 GMT
Links: << >>  << T >>  << A >>


Tim wrote:

>
> All together, for the umpteenth time:
>     "Please can we have these few register bits as flash"

Same answer for the umpteenth time:
        "No, as long as that would mean sacrificing the standard,
high-volume and high-performance CMOS logic/microprocessor process". Tell
us how it can be done without significant impact on fab availability,
performance, and cost, and we will really listen. We are convinced these
conditions cannot be met today. Hope is eternal!

Peter Alfke


Article: 43104
Subject: Re: Architecture for high-level reconfigurable computing
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 14 May 2002 03:43:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1021334482.2332.0.nnrp-07.9e9832fa@news.demon.co.uk>,
Tim <tim@rockylogic.com.nooospam.com> wrote:
>All together, for the umpteenth time:
>    "Please can we have these few register bits as flash"

All together, for the umpteenth time:
    "Flash slows the process down, and anyway, damnit, being properly
    paranoid, I prefer battery backed SRAM, its harder to probe."


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 43105
Subject: Re: Neverending ISA bus interface drama, Spartan-II
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 14 May 2002 03:46:54 GMT
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

>
> ... unless they're being eaten by the great metastability beast. Maybe the
> work/!work is related to seasonal variation in lab temperature :-).

Sure, but then I am looking for:
"Works mostly, but not al low Vcc or at hot, or at cold, or..."
Or: "works in some devices, but not in all..."
Or" works only when I put 100 pF across the clock line..."

"Does not work" is like going to the doctor and saying "I am sick".
Complete lack of information...

Peter Alfke



Article: 43106
Subject: Re: Architecture for high-level reconfigurable computing
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Tue, 14 May 2002 03:59:36 GMT
Links: << >>  << T >>  << A >>
Steve Casselman wrote:
 
> > >  A key weakness of C, is the sequential nature of all descriptions,
> 
> This is not really correct. C has lots of parallelism. It always amazes me
> when people say there is no parallelism. Here is a line of very parallel C
> code.
> 
> a = b+c, d= e+f, Myfunc();
> 
> According to the C specs the above line can be executed in parallel. The
> problem is if you can get different  answers since the specs don't say what
> order they must executed in if you do them one at a time.
> example
> 
> a = b , b = a ;
> 
> Could be "a" and "b" have the value of "a" or they have the value of "b" or
> "a" and "b" swap values. It's one of the reasons Java only has lists for
> initializations.

Useful parallelism would need to define what happens.  Perhaps it would
be better to state that C has no useful parallelism.  Suppose I wanted
to swap a and b in parallel, how could I do this in C?  I can in other
parallel languages.

For example, in HandelC:

par
{
  a = b;
  b = a;
}

"a" and "b" will swap values.

Or in VHDL:

process (clk) begin
  if rising_edge(clk) then
     a <= b;
     b <= a;
  end if;
end process;

"a" and "b" will again swap values.


-- 
Phil Hays

Article: 43107
Subject: Re: Architecture for high-level reconfigurable computing
From: Buddy Smith <nullset@dookie.net>
Date: Tue, 14 May 2002 04:20:15 +0000 (UTC)
Links: << >>  << T >>  << A >>
Phil Hays <SpamPostmaster@attbi.com> wrote:

> Or in VHDL:
> 
> process (clk) begin
>  if rising_edge(clk) then
>     a <= b;
>     b <= a;
>  end if;
> end process;
> 
> "a" and "b" will again swap values.
> 

Correct me if i'm wrong, but aren't processes in VHDL sequential?

if you did this outside of a process, then they will swap values...but 
inside a process, you just made both a and b have the value of b.

--buddy

Article: 43108
Subject: Re: Architecture for high-level reconfigurable computing
From: "news.bellatlantic.net" <vze3qgji@verizon.net>
Date: Tue, 14 May 2002 04:32:25 GMT
Links: << >>  << T >>  << A >>
There's a big difference between having the programmer specify the
parallelism, vs. hoping someday someone will figure out algorithms so that a
compiler that can find it.  Many man-years have been spent trying to make
compilers that can find the inherent parallelism in a program, and so far
only some loop-level parallelism can be exploited.  Adding features to a
language like fork and join with explicitly stated synchronization will get
you to useful parallelism far sooner than waiting for the compiler that does
it automatically.  -Stan


"Steve Casselman" <sc.nospam@vcc.com> wrote in message
news:dAWD8.870$q67.72741089@newssvr14.news.prodigy.com...
> > >  A key weakness of C, is the sequential nature of all descriptions,
>
>
> This is not really correct. C has lots of parallelism. It always amazes me
> when people say there is no parallelism. Here is a line of very parallel C
> code.
>
> a = b+c, d= e+f, Myfunc();
>
> According to the C specs the above line can be executed in parallel. The
> problem is if you can get different  answers since the specs don't say
what
> order they must executed in if you do them one at a time.
> example
>
> a = b , b = a ;
>
> Could be "a" and "b" have the value of "a" or they have the value of "b"
or
> "a" and "b" swap values. It's one of the reasons Java only has lists for
> initializations.
>
> If you write a compiler you'll see what I mean.
>
> Steve
>
>



Article: 43109
Subject: Re: Opinions on FPGA cores - best for a commercial project?
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 14 May 2002 09:01:11 +0200
Links: << >>  << T >>  << A >>
"Phil Connor" <philip_john_connor@hotmail.com> writes:

> "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message
> news:m3u1pjrl1t.fsf@scimul.dolphinics.no
> 
>  
> > For volumes like that I would go for an ASIC using a PCI core where
> > you can get the HDL source (Synopsys, RaviCAD etc.). You can of course
> > make a FPGA prototype using the same core which will let you test your
> > design with all the various host bridges available.
> > 
> > Petter
> 
> 
> Hi Petter,
> 
> Would you have any links for info on the host bridges or other test
> techniques?

Most likely you will have to sign lots of NDA's (ServerWorks etc.) in
order to get information on the various host bridges.


Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 43110
Subject: Re: Architecture for high-level reconfigurable computing
From: Johann Glaser <Johann.Glaser@gmx.at>
Date: Tue, 14 May 2002 10:26:47 +0200
Links: << >>  << T >>  << A >>
Hi!

>> process (clk) begin
>>  if rising_edge(clk) then
>>     a <= b;
>>     b <= a;
>>  end if;
>> end process;
>> 
>> "a" and "b" will again swap values.
>> 
>> 
> Correct me if i'm wrong, but aren't processes in VHDL sequential?
> 
> if you did this outside of a process, then they will swap values...but
> inside a process, you just made both a and b have the value of b.

I'm a VHDL newbee, so I have problems understanding the statement
"processes are sequential" too. We were told that, but when thinking of
the synthesized process, I can't imagine, that the FPGA then "executes"
the statements after each other, waiting until the previous has finished
and then continuing with the next.

But, one thing we were told too is, that in processes, all _signals_ are
updated _at the end_. So, you can assign as many values as you want, only
the last value will be assigned to the signal at the "end process" line.
And: the signal will hold it's initial value in the hole process, i.e. "a"
in the above example will hold the value it had when "entereing" the
process in the "b <= a;" statement. Think of a D-Flipflop. It holds the
initial value during the hole process, and only when clk rises, it feeds
through its input value to the output.

Variables behave different, they will get the value immediately. So, the
above example (which uses signals because of the "<=" assignment) really
swaps a and b. If it would be written with variables (assignment with
":=") a and b will have the value of b afterwards.

Now my question: How true is the statement "processes are sequential" with
regard to synthesis. E.g. if there are several "if" statements after each
other (not nested!), a "case" statement, ... aren't they synthesized
parallel? How are variables synthesized inside a process? Will they get a
register (D-FF) like signals within a "if rising_edge(clk) then" clause?

Thanks
  Hansi

Article: 43111
Subject: Bus arbiter with low latency
From: jetmarc@hotmail.com (jetmarc)
Date: 14 May 2002 04:49:54 -0700
Links: << >>  << T >>  << A >>
Hi.  I'm fairly new to programmable logic.  Now I'm working
on a bus arbiter, but can't come up with a good solution.

My first design works like this:

Clock cycle 1:  peripherial requests bus (REQ=1).
Clock cycle 2:  arbiter makes decision and gives bus (ACK=1).
Clock cycle 3:  peripherial releases request (REQ=0) and
                does a non-waitstate access with the bus.

The problem is about latency.  A single access takes 3 cycles.
Peripherials that react on an external WAITSTATE signal do not
know how long the access takes, and can not release REQ in
advance.  They waste yet another cycle by requesting more bus
slots than necessary.

But how can I speed this up?  I thought about clocking the
ACK signal on the opposite clock edge than the rest of the
system. That would make ACK arrive before the end of the
REQuest.  A single access reduces to 2 clock cycles instead
of 3.

But doesn't this reduce the whole design speed?  To make
signals arrive okay in 1/2 clock period, I have to reduce
the total system clock to 1/2 of its otherwise possible
maximum.  Right or wrong?

And isn't this almost as bad as using a non-clocked ACK,
with combinatorial logic only?   I made bad experience
already with non-clocked signals.  Simply removing the
clock made a previous design flakey, although the signals
were very simple.  My toolchain seems to definately
prefer clocked signals.

Can you please give advice on how to reduce the REQ/ACK
latency in bus arbiters, and/or point me to appnotes and
papers about this topic?

Thank you very much!

Marc

Article: 43112
Subject: Re: Architecture for high-level reconfigurable computing
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 14 May 2002 13:16:56 +0100
Links: << >>  << T >>  << A >>


Nicholas Weaver wrote:

> Virtex 2: Bitfiles can be encrypted with a 3DES key, and the 3DES key
> is then loaded (through JTAG) into a distinct register on the part,
> which has a separate power pin to maintain state.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

The problem comes when, for some reason, the battery fails and the user's
board is now dead [User "No I really really didn't try to change the battery
with the board powered down, honest"]. To avoid being faked the only real way
to deal with this is to offer a free ``return-to-base'' service.

There was a long thread on this subject some time ago discussing the battery
endurance necessary to maintain the 3DES keys.

Peter/Austin: Do you have any real life experience on the VBATT current drain
now the V-2's have been characterised ? Any recommendations or apps notes on
battery types &  circuits ?

Is there, for example, any way of detecting the battery state from inside the
chip to see if its dropped below 1V + some margin ? It might be worth a nA or
2 to have this feature.




Article: 43113
Subject: Re: Architecture for high-level reconfigurable computing
From: Keith R. Williams <krw@btv.ibm.com>
Date: Tue, 14 May 2002 08:41:13 -0400
Links: << >>  << T >>  << A >>
In article <3CE0874C.C18C852@earthlink.net>, palfke@earthlink.net 
says...
> 
> 
> Tim wrote:
> 
> >
> > All together, for the umpteenth time:
> >     "Please can we have these few register bits as flash"
> 
> Same answer for the umpteenth time:
>         "No, as long as that would mean sacrificing the standard,
> high-volume and high-performance CMOS logic/microprocessor process". Tell
> us how it can be done without significant impact on fab availability,
> performance, and cost, and we will really listen. We are convinced these
> conditions cannot be met today. Hope is eternal!

Fuses?  The problem then moves to test, but it's been done.

----
  Keith 

Article: 43114
Subject: LGPL 32bits RISC CPU Core
From: e8johan@will-not.work.se (Johan Eriksson Thelin)
Date: 14 May 2002 13:25:04 GMT
Links: << >>  << T >>  << A >>
I would like to announce an LGPLed RISC CPU core written
in 100% VHDL. It is available for download from:


http://www.etek.chalmers.se/~e8johan/concert02/index.html

Please try it out, and give feedback!

Best Regards!

/Johan



Article: 43115
Subject: Driving high speed external devices from an FPGA
From: mr_bert_wibble@hotmail.com (Bert Wibble)
Date: 14 May 2002 07:23:57 -0700
Links: << >>  << T >>  << A >>
Hello all,

Does anyone have any experience in driving external high speed devices
from an
FPGA, in particular a DAC ?
To put some flesh around this, I am attempting to drive a 10bit DAC
from an
FPGA at 160MHz. The DAC and the FPGA share a common clock - but at
this speed
their exact phase allignment is not known.
Internal to the FPGA (Xilinx), I am using a DLL/clock net to lock the
internal
clock to the external one.
I am also happy with the idea that there will be a delay spread of the
data through the FPGA IOB/pad combo.

My question is - does anyone have any useful ideas on how I can
guarantee to
meet the setup and hold times of my DAC given the uncertainties of the
clock
delays ?
There seems to be very little information around on this topic - is
this
another "black art" area ?

Thanks in advance,
Bert

Article: 43116
Subject: Re: Neverending ISA bus interface drama, Spartan-II
From: creon100@yahoo.com (Sean)
Date: 14 May 2002 07:27:07 -0700
Links: << >>  << T >>  << A >>
I'm convinced there is an anti-electical engineering field that passes
through the lab at regular intervals :)

Anyway, here's a little history.  When I at first couldn't even get
the bus working the PCI33_5 standard to work it appeared we had no
problems with voltage levels.  Everything was at 3.3V which should
have been enough for the ISA bus, but our erros clearly indicated we
were getting stuck at zero errors beause all of our erroneous data was
values that could be derived from the input simply by dropping some of
the 1's to 0's.  However, we could never see these ourselves.  This is
why I decided to add the 4.7k ohm pull-up resistors so the bus would
go to a full 5V.  This worked, and the bus began to operate.  Last
week (well, two weeks ago now), I had finished the project but was
messing around with it some more and discovered that now it worked
without the pull-up resistors.  I haven't bothered to look at it with
a scope lately since the last time I did it we couldn't see anything
that should have been causing abnormal operation in the first place.

Two weeks ago I also discovered that LVTTL doesn't work at all.  I had
originally switched from LVTTL to PCI33_5 because I was basing my core
off of one from a part at Mesa Electronics, in which they used
PCI33_5.  (They were also trying to assign slew rate and drive current
via the contraint file, but I don't think that's possible with
PCI33_5, only with the LVTTL io buffers).  Anyway, I just stuck with
the PCI33_5 since I knew someone else had gotten the bus working using
it.

The LVTTL not working is a mystery to me though.  The behavior it
exhibits is this.  I have a C++ programming writing and reading a
value into the FPGA.  It reports the success or failure of each write
and read (whether it read the same thing it just wrote into the FPGA)
into a file along with the the value of each write and read
transaction.  I'm doing 8-bit transactions at the moment so I
basically just have a counter that counts from 0 - 255 and writes and
reads the value.  As I said, the implementation using PCI33_5 works
fine, success every time.  However, the LVTTL log file is a string of
all failures except for the first one.  This is because the LVTTL port
always gives me a value of zero on a read, and the first test value is
always a zero so it says it is correct.  Of course, it doesn't help to
have a port that only lets the PC read in a zero regardless of the
actual data value.  Occasionlly, no more than once through each run, I
will see something other than a zero on one of the PC reads, but it's
never the correct value anyway, so it still results in an error. 
These are just noteworthy merely because it's not just a zero.

This occurs even when I have the pull-up resistors to 5V on the bus so
it can't be merely a voltage level issue.  I wouldn't expect that
anyway since it's for the most part a consistant zero on the port and
not some random derivative of the input value with some random stuck
at zero faults.

I also know it's not my logic as I use the same VHDL and C++ code for
both tests, I just synthesize one using PCI33_5 and one using LVTTL.

I guess my only other course of action is to try and delve in with the
oscilloscope again.  It didn't really tell me anything useful last
time so I have my doubts.

If I knew the drive current that PCI33_5 uses though I may not even
have to worry about the LVTTL though.  So if anyone knows what the
standard drive current on a PCI33_5 output buffer is I'd be grateful,
since I can't seem to find it anywhere :)



Peter Alfke <palfke@earthlink.net> wrote in message news:<3CE088A5.5CE49203@earthlink.net>...
> Rick Filipkiewicz wrote:
> 
> >
> > ... unless they're being eaten by the great metastability beast. Maybe the
> > work/!work is related to seasonal variation in lab temperature :-).
> 
> Sure, but then I am looking for:
> "Works mostly, but not al low Vcc or at hot, or at cold, or..."
> Or: "works in some devices, but not in all..."
> Or" works only when I put 100 pF across the clock line..."
> 
> "Does not work" is like going to the doctor and saying "I am sick".
> Complete lack of information...
> 
> Peter Alfke

Article: 43117
Subject: Re: Issue with X_SUH (using 4.1 sp 3)
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Tue, 14 May 2002 08:57:12 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------9817F37E2EE05A8A19E8E907
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Venu,

   If you have not done so already, please create a case with our
hotline for this so that it can be properly investigated.  If there is a
problem with the way we are creating our simulation models, we would
like to know the details about it so that this can be fixed for future
revisions of the software.

   The best work-around I can offer you without knowing more about your
specific problem is to disable the X_SUH generation in the netlist.  To
do this, set the following environment variable to 1 and re-run the
ngdanno and ngd2ver portions of the design run:

XIL_ANNO_DISABLE_GSUH

If this environment variable is enabled, no X_SUH components will be
created in the netlist.  This would mean that possible setup or hold
conditions for signals entering the design may not be detected by the
simulation so careful static timing analysis for the input paths of the
design becomes that much more important however you should no longer see
any warnings from these signals during simulation.

--  Brian


Venu wrote:

> Hi,
>
>   I am having a problem in verilog back-annotated simulations as
> described below.Many thanks to anyone who can suggest a workaround.
> Everything was O.K
> with earlier versions of Xilinx SW and hence design issues are ruled
> out.
>
>   In my design , I take Clk_66 as input and internally generate
> Clk_132 using
>   DCM and external feedback.
>   Some of the I/O's of FPGA are driven by logic running at Clk_66
> while
>   some other by logic running at Clk_132. My problem is that
>   Xilinx verilog writer has added X_SUH elements for all the I/O's
> with clk as
>   Clk_66..This is resulting in a setup violation being reported for
> all Clk_133
>   inputs. The PAR does not report any static timing violations.
>
>   Please let me know if anyone has encountered something similar.
>
> Thanks
> Venu



Article: 43118
Subject: Re: State machine synthesis
From: Renaud Pacalet <pacalet@enst.fr>
Date: Tue, 14 May 2002 17:20:21 +0200
Links: << >>  << T >>  << A >>
John Williams a écrit :

> 
> "Robert O. Taniman" wrote:
>> 
> [snip]
>  
>> To John, I'm interested in your 'self memo' about registering the
>> counter. Is it possible for you to show your revised code here?
> 
> Hi Robert,
> 
> Sure.  I also make use of the idea from swier about default output
> values at the top of the case statement, you'll see what i mean
> from the
> attached code.  It's still pretty long but you'll see quickly what
> it's
> doing.  Ask if you'd like some clarification.
> 
> Cheers,
> 
> John
> 

Hi John,

May I suggest that you add D_in, data and pointer to the sensitivity
list of your state_update process?

Regards,

Renaud.
-- 
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pacalet@enst.fr
###### Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/ ######

Article: 43119
Subject: Re: RocketIO simulations, ISE 4.2iSP2 GT_SWIFT simulation
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Tue, 14 May 2002 09:38:03 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------64CA60687ADA50298019B0EC
Content-Type: multipart/alternative;
 boundary="------------E63CB36E349C785E6CBF002A"


--------------E63CB36E349C785E6CBF002A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Petter,

   I am not an expert on SmartModels but I believe I can answer most of your
questions below.


Petter Gustad wrote:

> I'm trying to figure out where to locate the RocketIO swift models to
> simulate RocketIO using Synopsys VCS or Cadence Verilog under SPARC
> Solaris 8.
>
> Answers Database #14019 mentiones the Virtex-II Pro Developers kit
> (V2PRO). However, the ISE 4.2iSP2 appears to have a GT_SWIFT
> installation under
> verilog/smartmodel/sol/wrappers/vcs/GT_SWIFT.swift.v
>
> The problem is that I can't find any instructions on how to use it,
> i.e. which object file can I link into my simulator.
>
> AD#14019 specifies a library file in the V2PRO under
> verilog/smartmodel/sol/installed/lib/sun4Solaris.lib, but this file
> does not seem to exist under ISE 4.2iSP2.
>
> 1) Is the Virtex-II Pro Developers kit required to simulate the
>    RocketIO interfaces?

Unless I am mistaken, you do not need the Developers kit for this if you
have 4.2i installed.  The intention of the Developers kit was to support
people using the V-II Pro devices before the 4.2i release was available.



> 2) If not, which library/object file supplied with ISE 4.2iSP2 do I
>    use?

You must install the simulations files.  To find the instructions to do so,
look at:
Answer Record # 14595: 4.2i SmartModel installation - How do I install the
PPC and MGT SmartModels that are included in the 4.2i Implementation Tools?

This will instruct you how to run the Logic Modeling sl_admin tool and
properly install the models.  After running this, you should see the
verilog/smartmodel/sol/installed/lib/sun4Solaris.lib library you were
missing before.


> 3) Further there is a x86_linux directory containing som Linux X86
>    binaries under verilog/smartmodel/sol/image. Is, or will Linux X86
>    swift models be supplied so I can run my simulations on Synopsys
>    VCS or Cadence Verilog under Linux X86?

We do not supply a Linux model (yet).  I believe that directory is a part of
the Logic Modeling tool and not a part of the Xilinx software itself.  If
you are interested in using a Linux OS simulator, let me know which
simulator you are interested in.  I can not make any promises, however if
there is enough demand, we may be able to provide these in the future but
for now, there is no plan to provide a Linux version anytime soon.  We are
supporting MTI on Windows and the Solaris versions of MTI, Cadence NC and
Verilog-XL, and Synopsys VCS.  Since models and wrapper files need to be
specially made and tested for each simulator / OS version, we sould not
support them all.


> BTW. I'm familiar with swift models since I have used VMC to generate
> swift models of my own ASIC designs.

Good.  Then hopefully the information above is enough to get you going.
Using these SWIFT models is certainly not as easy to use as standard HDL but
once you get it installed and running, things go pretty smooth.


--  Brian




>
>
> Petter
> --
> ________________________________________________________________________
> Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog  http://gustad.com




Article: 43120
Subject: Re: Driving high speed external devices from an FPGA
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 14 May 2002 08:55:03 -0700
Links: << >>  << T >>  << A >>
Bert Wibble wrote:

> Hello all,
> 
> Does anyone have any experience in driving external high speed devices
> from an
> FPGA, in particular a DAC ?
> To put some flesh around this, I am attempting to drive a 10bit DAC
> from an
> FPGA at 160MHz. The DAC and the FPGA share a common clock - but at
> this speed
> their exact phase allignment is not known.


Do a google search on

[ differential driver ]

and on

[ phase lock loop clock ]





      -- Mike Treseler




Article: 43121
Subject: Re: 50 mA sink
From: John_H <johnhandwork@mail.com>
Date: Tue, 14 May 2002 15:56:29 GMT
Links: << >>  << T >>  << A >>
Use multiple outputs with the same driver.
Keep output skew to a minimum with adjecent IOBs or Macrocells.


emanuel stiebler wrote:

> Hi all,
> anybody out here knows a CPLD/FPGA which can sink at least 50 mA
> on a 5V TTL compatible output ?
>
> cheers & thanks


Article: 43122
Subject: Virtex2 placement problem
From: Marcus Bednara <bednara@date.upb.de>
Date: Tue, 14 May 2002 18:30:37 +0200
Links: << >>  << T >>  << A >>
Hi,

a question about place and route.

I have tried to bring a small design (300 LUTs, 500 FFs)
to a Virtex-2-6000 FPGA using Alliance 4.1 tools on
Solaris. The design shold be placed in an rectangular
area of the slice array, so I specified a bounding box
of sufficient size in the ucf file (using the LOC constraint).

During PAR, there is no error message at all, but it
seems PAR is not interested in the LOC constraint. A
handful of the slices is placed in the bounding box,
but the majority is placed somewhere on the chip.
If I add -pl 5 -xe 2 to the PAR command line,
the results become better, but some slices are still
missplaced, although the size of the bounding box is
sufficient. (If the box is to small, PAR generates an
error message).

When I used placement constraints for a Virtex1000
in the 3.1i software, I had none of these problems.

Any Idea?
Thanks,
Marcus.


--
--------------------------------------------
Marcus Bednara (mailto:bednara@date.upb.de)
Computer Engineering Lab  (AG Datentechnik)
University of Paderborn, Germany
Phone ++49-(0)5251-60-3921
URL: http://www-date.upb.de/~bednara
--------------------------------------------




Article: 43123
Subject: Re: Driving high speed external devices from an FPGA
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 14 May 2002 16:32:41 -0000
Links: << >>  << T >>  << A >>
>To put some flesh around this, I am attempting to drive a 10bit DAC
>from an FPGA at 160MHz. The DAC and the FPGA share a common clock
> - but at this speed their exact phase allignment is not known.

I think you are going to be in trouble until you constrain
the timing on the two clocks.

I know of two ways to attack this problem.

One is to make both clocks in the same clock generator
chip (low skew to start with) and then adjust the data
out of the FPGA to meet setup/hold.  You have to account
for the lengths of the two clock traces, but you can use
that to shift your clock by making one trace longer/shorter
than the other.  (PCBs are reasonably stable.)  You also
have to consider the length of the data traces from FPGA to
DAC.

The other way is to make the DAC clock in the FPGA.  If the
clock and data traces from FPGA to DAC are the same length the
delay doesn't change the setup/hold.  Note that this adds
the DLL jitter to your DAC clock which will probably add too
much distortion to your final signal.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43124
Subject: Re: 50 mA sink
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Tue, 14 May 2002 09:33:39 -0700
Links: << >>  << T >>  << A >>
If you parallel outputs for high current sink (!), then it is best to
configure all outputs as "open collector". This avoids contention during
the very short time that the outputs might disagree.

Peter Alfke
============================
John_H wrote:

> Use multiple outputs with the same driver.
> Keep output skew to a minimum with adjecent IOBs or Macrocells.
>
> emanuel stiebler wrote:
>
> > Hi all,
> > anybody out here knows a CPLD/FPGA which can sink at least 50 mA
> > on a 5V TTL compatible output ?
> >
> > cheers & thanks




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