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 34525

Article: 34525
(removed)


Article: 34526
(removed)


Article: 34527
Subject: Re: FPGA : USB in an FPGA, has anyone done it before?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Tue, 28 Aug 2001 14:34:12 -0700
Links: << >>  << T >>  << A >>
"Dave Feustel" <dfeustel@mindspring.com> wrote:

>Felix,
>
>I've been looking for a 32/16/8 bit peripheral parallel interface using USB 2.0.
>I haven't found any at all. All I've been able to find is ATA IDE interfaces
>which I don't think I can twist into what I want. An FPGA implementation
>would be very handy.

You can check this url for such a part:
http://www.softmixedsignal.com/usb2.html

Muzaffer

Article: 34528
Subject: Re: FPGA : USB in an FPGA, has anyone done it before?
From: "Dave Feustel" <dfeustel@mindspring.com>
Date: Tue, 28 Aug 2001 22:13:51 GMT
Links: << >>  << T >>  << A >>
I've used products with Cypress USB 1.x parts and as a result Cypress
was my first choice for USB 2.0 peripheral chips. But Cypress doesn't seem
to be delivering chips - they have never answered my email requests
for availability info. Also, One person was still waiting for his chips
4 months after order. The situation may have improved but I haven't
heard about the improvement if it has actually ocurred.

"Glen Atkins" <glen_atkins@agilent.com> wrote in message news:999015054.562597@cswreg.cos.agilent.com...
> Dave,
>
> if you are looking for a stand-alone USB 2.0 device that interfaces to a
> parallel bus, you might check Cypress.  Their FX-2 and SX-2 both interface
> over a parallel bus.  You could also look into NetChips, they have a couple
> of parts out that interface over a parallel bus too.
>
> Cheers,
> Glen Atkins
>
> "Dave Feustel" <dfeustel@mindspring.com> wrote in message
> news:8%Ni7.7405$xb.5269943@news1.mntp1.il.home.com...
> > Felix,
> >
> > I've been looking for a 32/16/8 bit peripheral parallel interface using
> USB 2.0.
> > I haven't found any at all. All I've been able to find is ATA IDE
> interfaces
> > which I don't think I can twist into what I want. An FPGA implementation
> > would be very handy.
> >
> > Dave Feustel
> >
> > "Felix Bertram" <fbertram@gmx.net> wrote in message
> news:9mg6rl$23oi6$1@ID-31589.news.dfncis.de...
> > > Dave,
> > >
> > > ----- Original Message -----
> > > From: "Dave Feustel" <dfeustel@mindspring.com>
> > > Newsgroups: comp.arch.fpga
> > > Sent: Tuesday, August 28, 2001 1:07 PM
> > > Subject: Re: FPGA : USB in an FPGA, has anyone done it before?
> > >
> > > > Felix,
> > > >
> > > > Have you any plans to implement USB 2.0 in FPGA?
> > >
> > > yes, definitely. The transaction & protocol layer are more or less the
> same
> > > as USB 1.1, so this is not too critical. However, as reconstruction of
> the
> > > 480Mbps clock inside the FPGA is not feasable, we will use a UTMI
> compliant
> > > transceiver to do so.
> > >
> > > If you have any plans regarding USB 2.0 that we could be part of, please
> let
> > > me know.
> > >
> > > Best regards
> > >
> > > Felix
> > > _____
> > > Dipl.-Ing. Felix Bertram
> > > Trenz Electronic
> > > Duenner Kirchweg 77
> > > D - 32257 Buende
> > > Tel.: +49 (0) 5223 49 39 755
> > > Fax.: +49 (0) 5223 48 945
> > > Mailto:f.bertram@trenz-electronic.de
> > > http://www.trenz-electronic.de
> > >
> > >
> > >
> >
> >
> >
>
>



Article: 34529
Subject: Re: Defending Austin Franklin
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 28 Aug 2001 23:28:37 +0100
Links: << >>  << T >>  << A >>


Don Husby wrote:

> Philip Freidin ranted:
> > [Much valid ranting deleted]
> > For each of the optimizations that the P&R tools perform, there
> > are cases where the result is disastrous. One of the still most
> > compelling reasons to still use schematics, is that there are
> > reasonably easy ways to inhibit this behaviour.
>
> Take, for instance, Exemplar/Leonardo synthesizing Verilog for
> Virtex-2.  It screws up on even the simplest of logic minimization.
>
> For example, if you give it:
>   always @(posedge K) Q <= A^B^C^D;  // no minimization required
>
> Leonardo will "optimize" this as two 4-input LUTS and an FDS.  Not only
> does this use twice as many luts as needed, it increases cycle time,
> increases routing congestion, and makes the FDS unable to share a
> slice with a related flip flop.
>
> This is not an isolated case.  Just about any logic that can be
> "de-optimized" in this manner will be.  Take another example:
>
>   always @(posedge K) Q[63:0] <= S ? X[63:0] : Y[63:0];
>
> This will synthesize to 128 LUTs and 64 FDS.  (The correct
> answer is 64 LUTS and 64 FD.)  I would be far better off using
> a schematic.  With Leonardo, any logic in the critical path has
> to be instantiated as LUT symbols.  If using schematics is like
> programming in assembly language, then instantiating LUTs is like
> writing microcode.
>
> The people at Exemplar had no clue that this was happening
> (so they said).  They apparently have no clue how to fix it
> since I submitted the bug report over a month ago.
>
> Bottom line: Leonardo is currently un-usable for Virtex-2
> designs

Below the bottom line: Try Synplify, it gets both these cases right, no
problem. However even Synplify does some strange things e.g. for a simple
N-bit adder with no overflow or carry-in:

o width 1-4 it uses LUTs - o.k.

o width >= 6 it uses the Xilinx CLB's arithmetic logic - o.k.

o width 5 it uses LUTs - ??

Seriously this does raise the point that with logic synth tools you are at
the mercy of the tool Vendor for bug fixing and/or getting logic
optimisation right whereas with schems all the bugs are down to the user
(?!).

Against this it might be said that I only notice this sort of thing when
the timing goes awry - if it meets it it doesn't matter until I get onto a
device size squeeze.

Just to add a little bit more fuel to the Schem vs. HDL flame wars: I'm not
sure I've ever heard a proponent of schems give a convincing answer to the
question of version control. This is not just a question of archiving
different snapshots but also being able to do a meaningful "diff" between
revisions.


Article: 34530
Subject: Re: System Requirements
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 28 Aug 2001 23:36:44 +0100
Links: << >>  << T >>  << A >>


Nial Stewart wrote:

> Hakon Lislebo wrote:
> >
> > I also use a 1 GHz with 512Mbytes of RAM. The RAM is very important so that
> > the software doesn't have to use the hard-disk. ( About all my 512 Mbytes is
> > occupied during a routing).
> >
> > Hakon
>
> Has anyone reading this had any experience with DDR Ram
> with PAR tools?
>
> The thought of a 1.4G Athlon with >512M DDR Ram appeals :-).
>
> Nial.

I'm writing this on one right now - well 1.3G anyway. Its about 40% faster for
both simulation [ModelSim-PE] and Xilinx P&R than my old PIII-650-PC100. The only
problem with the one I've got is that it only has 2 DDR stick slots - its all we
could find at the time but I think you can do better now that fast Athlon boxes
have become more mainstream.



Article: 34531
Subject: Re: Level sensitive latches in Xilinx Virtex
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 28 Aug 2001 23:58:11 +0100
Links: << >>  << T >>  << A >>


Chris Softley wrote:

> Hi -
>         we're seeing some 'interesting' behaviour in post-synthesis simulations
> of our design for a Xilinx Virtex XCV2000E. We synthesised witout
> problems with Synplify 6.3 then fed it to Alliance 3.3.
>
>         When we look in the vhdl netlist, we see that the latch in question is
> instantiated as 'X_LATCH' components, connected up as you'd expect. The
> problem is that when we run the simulation (VHDL netlist with SDF timing
> info), after a while everything falls over because of the following
> chain of events:
>
>         1./ On a rising system clock edge, a controlling state machine changes
> state and generates an active enable ('pass') input to the latch (on
> it's CLK input). Due to the logic in the state machine, this glitches
> low briefly but then comes high again. In other words, after the clock
> edge, it goes high, glitches low briefly, then remains at it's intended
> high level.
>
>         2./ On that same edge, new data are fed to a fairly lengthy
> combinational part of the circuit. The outputs of this are used as the
> inputs to the bank of latches driven by that enable signal. So after a
> while, the latch inputs settle at new values.
>
>         3./ Ultimately the situation is this. The latch enable input is active,
> and the latch inputs have valid, new values. BUT the outputs of the
> latch are undefined (VHDL 'X'), and have been so since shortly after the
> glitch on the latch enable. And remain so forevermore.
>
> Incidentally, the X_LATCHes are also connected to a global set/reset
> signal, but this is inactive throughout.
>
>         This is pretty odd behaviour. The latch is enabled and should therefore
> be passing the (perfecly good) values appearing at its inputs.
>
>         We've been able to view the .ncd and have a look at one of the slices
> containing the offending latches, and it appears perfectly okay. The
> enable signal is wired into the clock of one of the slice storage
> elements, the data is wired into the data input OK, and the output is
> also wired up ok. The storage element is set to be of type latch.
>
>         When we put the design into FPGA and try it that way, as far as we can
> tell, it's behaviour agrees with that in the PS simulation, in that test
> sets that run ok on the PS sim also run ok on the prototype, whilst test
> sets that fail on the prototype also fail on the ps sim.
>         Things only fail when the signals in the system are such that the state
> machine generates that glitch - but this should not be a problem for a
> true level sensititive latch since the enable signal is always back on
> in plenty of time.
>
>         So - what's going on? Is the bitfile not properly configuring the
> storage element as a latch type? Is the implementation of a latch in
> Virtex-E some odd kludge of an edge triggered cell which in some
> circumstances can show odd synchronous behaviour? Are we missing
> something really obvious?
>
>         Any light anyone can shed on this would be greatly appreciated.....
> it's pretty disconcerting when you feed a standard component sensible
> signals and it doesn't do what you expect...
>
> ----------------------------------------------------------------------
> chris softley,                phone: +44 (0)191 2225775
> dept of electrical &          email: c.i.softley@ncl.ac.uk
> electronic engineering,       computer arith/digital design/vhdl/dsp/
> newcastle university, uk.     approximation/perl/c++/asic/fpga/lns...
>    high speed logarithmic arithmetic: http://napier.ncl.ac.uk/hsla

One thing you might want to consider is that, looking at the Verilog simprims
model, it appears to have a min pulse width check for both high *and* low pulses.
For simulation your glitch is probably triggering the timing check & sending the
output to `X'. Only a data input change would then allow it to recover.

Now why a latch should need a PW-low check is an interesting question and might
represent something physical.


Article: 34532
Subject: Re: Level sensitive latches in Xilinx Virtex
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Tue, 28 Aug 2001 16:42:41 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> wrote:
>
>Chris Softley wrote:
>
>> Hi -
>>         we're seeing some 'interesting' behaviour in post-synthesis simulations
>> of our design for a Xilinx Virtex XCV2000E. We synthesised witout
>> problems with Synplify 6.3 then fed it to Alliance 3.3.
>...
>One thing you might want to consider is that, looking at the Verilog simprims
>model, it appears to have a min pulse width check for both high *and* low pulses.
>For simulation your glitch is probably triggering the timing check & sending the
>output to `X'. Only a data input change would then allow it to recover.
>
>Now why a latch should need a PW-low check is an interesting question and might
>represent something physical.

Depends on the physical design of the latch but it is possible that a
very short PW-low is causing the transmission gate transistors at the
input to stay at linear region for too long which could be changing
the charge stored at the feedback loop to an unknown value. It is a
stretch but it is the only one this dsp guy can see.

Muzaffer


Article: 34533
Subject: Re: new to fpga
From: Ray Andraka <ray@andraka.com>
Date: Wed, 29 Aug 2001 00:52:02 GMT
Links: << >>  << T >>  << A >>
If you want the board to operate stand-alone, you'll need a prom.  However, if
you are just experimenting and can have a download cable connected, you can
just load from the PC each time you start up.  Many of the boards have
provisions for a prom but are not supplied with one.  Others use a parallel
ROM and a CPLD, and a few depend on a host system to program the board.

Felix Bertram wrote:

> Daniel,
>
> to store an XC2S200 design in non-volatile memory, you could either use
> Atmel's serial EEPROMs (AT17LVxx), or Xilinx' Flash PROMs (XC18V02). Price
> is about the same, but the latter are fully supported by the Xilinx tools.
>
> Typically, you will program the Flash PROM using JTAG, while the PROM
> configures the FPGA in Master Serial mode. Refer to the Xilinx Product
> Specification "XC18V00 Series of in-System Programmable Configuration
> PROMs".
>
> If you are looking for a Spartan-II Development System that is already
> providing Flash PROM, please refer to:
> http://www.trenz-electronic.de/prod/proden6.htm
>
> Hope this helps,
> best regards
>
> Felix Bertram
> _____
> Dipl.-Ing. Felix Bertram
> Trenz Electronic
> Duenner Kirchweg 77
> D - 32257 Buende
> Tel.: +49 (0) 5223 49 39 755
> Fax.: +49 (0) 5223 48 945
> Mailto:f.bertram@trenz-electronic.de
> http://www.trenz-electronic.de
>
> "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se> wrote in
> message news:9mdha9$cpg$1@eol.dd.chalmers.se...
> > Hi.
> > I am not entirely new to pld's, but I have never worked with any kind of
> > fpga, and I wonder:
> >
> > I want to use something in the range XC2S200 in my design, I have seen
> > experiment boards equipped with this chip, that are programmed by xilinx
> > programmer cable, but these fpga:s don't store the bitfile internally
> AFAIK,
> > so some EEPROM has to be added? how is this done? how does programming
> then
> > work (and erase)?

--
-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



Article: 34534
Subject: Re: Defending Austin Franklin
From: "Austin Franklin" <austin@dark55room.com>
Date: Tue, 28 Aug 2001 21:11:49 -0400
Links: << >>  << T >>  << A >>
> Seriously this does raise the point that with logic synth tools you are at
> the mercy of the tool Vendor for bug fixing and/or getting logic
> optimisation right whereas with schems all the bugs are down to the user
> (?!).

And you are at their mercy for changing the results of the synthesis between
tool revisions!

> Just to add a little bit more fuel to the Schem vs. HDL flame wars: I'm
not
> sure I've ever heard a proponent of schems give a convincing answer to the
> question of version control. This is not just a question of archiving
> different snapshots but also being able to do a meaningful "diff" between
> revisions.

I don't see the issue.  Schematics are just files, like Verilog or C code
is.  People do revision/version control of board level schematics all the
time.  Why is that different than schematics for FPGAs?




Article: 34535
Subject: Re: Slowing PCI for FPGA
From: Phil Hays <spampostmaster@home.com>
Date: Wed, 29 Aug 2001 02:38:39 GMT
Links: << >>  << T >>  << A >>
Kolja Sulimma wrote:

> Errr...
> If I do schematic entry, I expect from a good tool chain, that it
> performs at least the following optimizations:
> 
> - logic minimization
> - redundancy elimination
> - retiming
> - logic replication for speed-up
> - technology mapping

And I expect that I can turn off any or all of these optimizations in a good
tool chain.  If not, then I will be very very unhappy in specific cases:  For
example, logic may need to be duplicated under designer control: if I add a
redundant gate on purpose I want to be able to force it to stay in the design,
and not to be ripped out by optimizations.  For example, I have in my current
design a set of signals crossing the FPGA, which are combined in a circuit (fits
in a LUT) and then input into six block RAMs.  If I let the synthesis tool do
what it wants, it will make exactly one copy of this circuit, and then route the
result to six block RAM:  This is over a nanosecond slower than making six
copies of this circuit in six LUTs and placing these near the inputs to the
block RAMs.  This is redundant logic for speed-up, but I don't expect any tool
to find this on it's own.  Perhaps someday I'll be surprised...

Retiming could do some really evil things with multiple clock domains, as does
logic replication for speed-up, for an example see the thread starting at:

http://groups.google.com/groups?selm=3B7A2172.B1CA5834%40yahoo.com


The point to synthesis tools isn't that they can do a better job in all cases,
but that they can do a good enough job for enough cases to be quite useful. 
They are not a replacement for designer care, or experience, or knowledge.


-- 
Phil Hays

Article: 34536
Subject: Re: download bitstream to FPGA
From: <khtsoi@pc90026.cse.cuhk.edu.hk>
Date: 29 Aug 2001 03:07:42 GMT
Links: << >>  << T >>  << A >>
> OK, this isn't exactly what you asked for, but perhaps it's of some use:
> [Xilinx FPGA Download Adapter & Linux-Software]
> http://members.surfeu.de/matthias.prinke/archives/xck.tar.gz

> Fred

Thanks for the info. I am still looking for a way to download the bit file.
I just wondering if the file format is not open. And nobody can do this
except Xilinx and the licenced parties. So sad. It's not possible to require
the client to have a copy of download program and the bit file can be
changed s.t. cannot stored in ROM.

---- Brittle

Article: 34537
Subject: Re: Slowing PCI for FPGA
From: Ray Andraka <ray@andraka.com>
Date: Wed, 29 Aug 2001 03:46:38 GMT
Links: << >>  << T >>  << A >>
You can do easily followed state machines in schematics.  For one-hot style
machines, the trick is to put wrappers around the state machine primitives to make
the assembled state machine appear as a flow chart.  The basic elements are the
state box, which contains a flip-flop, a decision diamond, which contains a pair
of and gates with the decision variable complemented on one, and the junction,
which contains an or gate.  In my schematic designs I did a number of pretty
complicated state machines using this style, and my customers found them to be
very easy to follow.  For encoded state machines, you can use a mux with constants
on the inputs for each state, and the state vector connected to the mux select
lines.  The mapper does a decent job of reducing the logic.

Russell Shaw wrote:

> How do you do compicated state machines with schematics? The circuit
> would look quite messy and non-intuitive wouldn't it?
>
> Austin Franklin wrote:
> >
> > I believe you were not using schematics correctly if you were not able to do
> > anything but a small design.  Some of the largest/fastest/densist chips in
> > the world, that I know of, are done with schematics.  Even our beloved FPGAs
> > are designed with schematics (oh the horror!)!  The Xilinx PCI core is done
> > in Viewdraw schematics.
> >
> > Personally, I find reading through a bunch of text quite tedious and time
> > consuming.  Most everyone I know, when they first get a block of HDL code in
> > front of them, that they have not seen, draw a block diagram.  Why bother if
> > the function of the HDL is so obvious and clear to understand?
> >
> > I believe people just don't know how to use schematics correctly.  It's that
> > simple.  There never were any substantial libraries available from any major
> > vendor, and I certainly wasn't going to just give away my years and years of
> > libraries to anyone.  They couldn't be protected, so anyone could just copy
> > them.  I worked with Viewlogic and other vendors for years trying to get
> > this concept into their heads, but they, from a business standpoint,
> > couldn't figure out how to make any money with it to pay for the
> > development.
> >
>
> --
>    ___                                           ___
>   /  /\                                         /  /\
>  /  /__\ Russell Shaw, B.Eng, M.Eng(Research)  /  /\/\
> /__/   / Victoria, Australia, Down-Under      /__/\/\/
> \  \  /  http://home.iprimus.com.au/rjshaw    \  \/\/
>  \__\/                                         \__\/

--
-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



Article: 34538
Subject: Re: download bitstream to FPGA
From: Lasse Langwadt Christensen <langwadt@ieee.org>
Date: Wed, 29 Aug 2001 05:09:13 GMT
Links: << >>  << T >>  << A >>
khtsoi@pc90026.cse.cuhk.edu.hk wrote:
> 
> > OK, this isn't exactly what you asked for, but perhaps it's of some use:
> > [Xilinx FPGA Download Adapter & Linux-Software]
> > http://members.surfeu.de/matthias.prinke/archives/xck.tar.gz
> 
> > Fred
> 
> Thanks for the info. I am still looking for a way to download the bit file.
> I just wondering if the file format is not open. And nobody can do this
> except Xilinx and the licenced parties. So sad. It's not possible to require
> the client to have a copy of download program and the bit file can be
> changed s.t. cannot stored in ROM.
> 
> ---- Brittle

The xilinx can convert the bit file to several different formats, they
even have 
a app. note on how to use a cpu via a few GPIOs to configure an FPGA,
and I think 
even c sourcecode. Or just look at the datasheet for a configuration
prom, and 
simulate that,   

-Lasse
-- Lasse Langwadt Christensen, 
-- A Dane in Phoenix, Arizona

Article: 34539
Subject: Re: FPGA : USB in an FPGA, has anyone done it before?
From: "Felix Bertram" <fbertram@gmx.net>
Date: Wed, 29 Aug 2001 08:22:25 +0200
Links: << >>  << T >>  << A >>
Dave,

> I've used products with Cypress USB 1.x parts and as a result Cypress
> was my first choice for USB 2.0 peripheral chips. But Cypress doesn't seem
> to be delivering chips - they have never answered my email requests
> for availability info. Also, One person was still waiting for his chips
> 4 months after order. The situation may have improved but I haven't
> heard about the improvement if it has actually ocurred.

we are waiting for a Cypress FX2 development kit since february- nothing
happened so far. There is a press release on USB compliance testing, maybe
the situation really improves:
http://www.cypress.com/press/releases/210726.html

The Net2290 may be an option. However, there are (according to tech support)
*no* application notes on isochronous transfers available- which I would
translate into: If isochronous works, it is at least not tested.

Best regards

Felix
_____
Dipl.-Ing. Felix Bertram
Trenz Electronic
Duenner Kirchweg 77
D - 32257 Buende
Tel.: +49 (0) 5223 49 39 755
Fax.: +49 (0) 5223 48 945
Mailto:f.bertram@trenz-electronic.de
http://www.trenz-electronic.de




Article: 34540
Subject: Any body used ACEX1K series for testing the design??
From: k1sadik@hotmail.com (sadik khan)
Date: 28 Aug 2001 23:34:48 -0700
Links: << >>  << T >>  << A >>
My design is very big(200k gate count) and i am porting it into the
four ACEX chips. In simulation i am getting correct output but
whenever i am porting i am not getting correct output.
  In my design external SRAM interface is there but it is working
fine.
Any suggest the exact solution for that.

Article: 34541
Subject: Re: Defending Austin Franklin
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Aug 2001 08:03:58 +0100
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> > Seriously this does raise the point that with logic synth tools you are at
> > the mercy of the tool Vendor for bug fixing and/or getting logic
> > optimisation right whereas with schems all the bugs are down to the user
> > (?!).
>
> And you are at their mercy for changing the results of the synthesis between
> tool revisions!
>

Again I would say that I don't really care if the result meets timing & fits in
my chosen device. The trick here is not to change tool versions unless you have
to i.e. to fix a really critical bug. I always keep the last version available
[and the last 3 in the pre-install .exe file form] so I can always go back just
by pointing the make file at it.

>
> > Just to add a little bit more fuel to the Schem vs. HDL flame wars: I'm
> not
> > sure I've ever heard a proponent of schems give a convincing answer to the
> > question of version control. This is not just a question of archiving
> > different snapshots but also being able to do a meaningful "diff" between
> > revisions.
>
> I don't see the issue.  Schematics are just files, like Verilog or C code
> is.  People do revision/version control of board level schematics all the
> time.  Why is that different than schematics for FPGAs?

In my experience there are 2 problems:

(1) Schems are usually binary which means that the standard text based rev
control tools can't do much more than keep copies.

(2) Doing a "diff", even if its possible, will drown the logic changes in a
morass of irrelevant graphical changes. This is true even for those schem
packages that have "text" versions of schematics.



Article: 34542
Subject: Gate Count Definition
From: kahhean <kahhean@bigfoot.com>
Date: Wed, 29 Aug 2001 00:52:41 -0700
Links: << >>  << T >>  << A >>
Hi,

What is the Xilinx's Definition of System Count and Logic Gate?

E.g. the XCV400E (virtex-e) is documented to have 569,952 system gates and 129,600 logic gates.  What is the difference between system gate and logic gate?

When somebody says "I am working on a million gate design", is he referring to system gate or logic gate?

Thanks in advance.

TA TA
kahhean

Article: 34543
Subject: X-HDL translation tool now available in Europe from EuroEDA
From: "EuroEDA Information" <info@euro-eda.com>
Date: Wed, 29 Aug 2001 09:06:05 +0100
Links: << >>  << T >>  << A >>
X-Tek Corporation's VHDL/Verilog bi-directional translation tool, X-HDL3, is
now distributed exclusively in Europe by EuroEDA Limited.

Full details & product information on-line:
www.euro-eda.com
www.x-tekcorp.com

---
EuroEDA Limited

Phone: +44 (0)1933 676373
Fax: +44 (0)1933 676372
Email: info@euro-eda.com
Web: http://www.euro-eda.com













Article: 34544
Subject: Re: SmartMedia
From: Edwin Naroska <edwin@ds.e-technik.uni-dortmund.de>
Date: Wed, 29 Aug 2001 10:21:21 +0200
Links: << >>  << T >>  << A >>
Hi,

Bram van de Kerkhof wrote:

> Cant you read the file byte by byte ??
>
> Yours B
>
> "Martin Roenne" <mar@tcelectronic.com> wrote in message
> news:c62dc1e0.0108232346.7aa0ff9@posting.google.com...
> > From VHDL you can only read files that you can specify as a path in
> > your filesystem. So - to read a file from a Smartmedia card, requires
> > a Smartmedia cardreader with a driver that supports your operating
> > systems file system. If you can read the Smartmedia files from your
> > file browser, you should also be able to read it from a VHDL file by
> > specifying the same path as shown in your browser. Hope this helps.
> >
> > regards Martin
> >
> > "Andrew Gray" <andrew@tuks.co.za> wrote in message
> news:<998576679.227273@nntp.up.ac.za>...
> > > Hi
> > >
> > > Does anyone know how to read a file from a SmartMedia card in VHDL?
> > >
> > > Andrew

Actually, this is a little bit tricky as file formats for binary files
read or written by VHDL are not standardized.

To read raw binary files (e.g. bitmaps) a solution was suggested by
Edward Moore which should work at least with Modelsim: Open a
file of type 'character', which in Modelsim translates to one byte
of i/o. Use the READ procedure to read each character and the
'VAL and 'POS attributes to convert from character to integer. Note,
this technique does not work with simulators that use only 7
bits to represent characters.   (extracted from the FAQ)

--
Edwin



Article: 34545
Subject: Re: Gate Count Definition
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Aug 2001 09:34:18 +0100
Links: << >>  << T >>  << A >>


kahhean wrote:

> Hi,
>
> What is the Xilinx's Definition of System Count and Logic Gate?
>
> E.g. the XCV400E (virtex-e) is documented to have 569,952 system gates and 129,600 logic gates.  What is the difference between system gate and logic gate?
>

The realistic answer is that on this NG at least these are generally known as ``marketing gates'' whose connection to reality is tenuous at best.

>
> When somebody says "I am working on a million gate design", is he referring to system gate or logic gate?
>
>

Most likely the person would be referring to an ASIC gate count. An experienced FPGA designer would probably quote a device type & percent utilisation [unless
they'd been got at by the Xilinx marketing dept.].




Article: 34546
Subject: Re: download bitstream to FPGA
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 29 Aug 2001 03:52:07 -0700
Links: << >>  << T >>  << A >>
On 29 Aug 2001 03:07:42 GMT, <khtsoi@pc90026.cse.cuhk.edu.hk> wrote:
>Thanks for the info. I am still looking for a way to download the bit file.

This is documented in Xilinx data sheets, in Xilinx App Notes, and in
the Xilinx on-line documentation. You couldn't ask for more. (well maybe
you could, but I dont know why)

>I just wondering if the file format is not open.

While the exact details of what each bit in the bitstream represents is
proprietory, you do not need this information to download a design into
your FPGA. The bitstream is created by the P&R tools, and the resulting
file can be copied into a serial or parallel EPROM/EEPROM, or saved
on disk, or stored any other way. The documentation clearly describes
the format of the data, and how it should be presented to the FPGA.

>And nobody can do this except Xilinx and the licenced parties.

Hardly !   All of Xilinx's tens of thousands of customers do this every day.

>So sad. It's not possible to require the client to have a copy of
>download program and the bit file can be changed s.t. cannot
>stored in ROM.

Well, this is just plain wrong. ( ? s.t. ?)

>---- Brittle

Philip
Philip Freidin
Fliptronics

Article: 34547
Subject: Re: Version Control
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 29 Aug 2001 22:54:42 +1200
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Austin Franklin wrote:
> 
> > > Seriously this does raise the point that with logic synth tools you are at
> > > the mercy of the tool Vendor for bug fixing and/or getting logic
> > > optimisation right whereas with schems all the bugs are down to the user
> > > (?!).
> >
> > And you are at their mercy for changing the results of the synthesis between
> > tool revisions!
> >
> 
> Again I would say that I don't really care if the result meets timing & fits in
> my chosen device. 

 And works, too ? :-)

> The trick here is not to change tool versions unless you have
> to i.e. to fix a really critical bug. I always keep the last version available
> [and the last 3 in the pre-install .exe file form] so I can always go back just
> by pointing the make file at it.

 Some designers also archive the tools used, with the design, so a build
in 
XX months uses minimal changes.
 This is the safest way to manage revisions, but does put some pressure
on 
those offering timelocked SW.


> 
> >
> > > Just to add a little bit more fuel to the Schem vs. HDL flame wars: I'm
> > not
> > > sure I've ever heard a proponent of schems give a convincing answer to the
> > > question of version control. This is not just a question of archiving
> > > different snapshots but also being able to do a meaningful "diff" between
> > > revisions.
> >
> > I don't see the issue.  Schematics are just files, like Verilog or C code
> > is.  People do revision/version control of board level schematics all the
> > time.  Why is that different than schematics for FPGAs?
> 
> In my experience there are 2 problems:
> 
> (1) Schems are usually binary which means that the standard text based rev
> control tools can't do much more than keep copies.
> 
> (2) Doing a "diff", even if its possible, will drown the logic changes in a
> morass of irrelevant graphical changes. This is true even for those schem
> packages that have "text" versions of schematics.

 I don't use Schem for Logic Entry, ( as lack of conditional compile 
is a 'killer', as well as poor handling of Table, Condition and State
designs ), but do use it a lot for PCB design.

 There are methods for compares:

a) Export netlists, and compare those. This is version portable, and
compares
only the necessary info ( avoids Graphics )

b) Use the packages ECO tool, typically this asks for 'OldVersion' to
compare
with, and a choice of compare detail, then creates an ASCII delta file.

c) Use the packages script tools, to do your own compare filters.

 Of course, these do not 'undo' the changes, but do let you see what
they are.

-jg

Article: 34548
Subject: Re: Defending Austin Franklin
From: "Austin Franklin" <austin@dar98kroom.com>
Date: Wed, 29 Aug 2001 06:59:42 -0400
Links: << >>  << T >>  << A >>
> > > Seriously this does raise the point that with logic synth tools you
are at
> > > the mercy of the tool Vendor for bug fixing and/or getting logic
> > > optimisation right whereas with schems all the bugs are down to the
user
> > > (?!).
> >
> > And you are at their mercy for changing the results of the synthesis
between
> > tool revisions!
> >
>
> Again I would say that I don't really care if the result meets timing &
fits in
> my chosen device. The trick here is not to change tool versions unless you
have
> to i.e. to fix a really critical bug. I always keep the last version
available
> [and the last 3 in the pre-install .exe file form] so I can always go back
just
> by pointing the make file at it.

What if you upgraded the synthesis tools for one project, but it changed
something for you in another project, and now you don't make timing?  You
can't always go back, unless you uninstall the new tools and re-install the
old tools...especially if they use environment variables or registry
settings.

I'll repeat.  The KEY to "correct" synthesis is to have a document that
states precisely what the output of the synthesis tool is for any given
input.  This makes the process deterministic.  That is what schematics
offer, synthesis does not.

> > > Just to add a little bit more fuel to the Schem vs. HDL flame wars:
I'm
> > not
> > > sure I've ever heard a proponent of schems give a convincing answer to
the
> > > question of version control. This is not just a question of archiving
> > > different snapshots but also being able to do a meaningful "diff"
between
> > > revisions.
> >
> > I don't see the issue.  Schematics are just files, like Verilog or C
code
> > is.  People do revision/version control of board level schematics all
the
> > time.  Why is that different than schematics for FPGAs?
>
> In my experience there are 2 problems:
>
> (1) Schems are usually binary which means that the standard text based rev
> control tools can't do much more than keep copies.

Not Viewlogic.  Also, I see no problem rev controling binaries.

> (2) Doing a "diff", even if its possible, will drown the logic changes in
a
> morass of irrelevant graphical changes. This is true even for those schem
> packages that have "text" versions of schematics.

Who diff's schematic files?  Anyway, in the over 20 years I've been drawing
schematics, this just hasn't been a problem.  It sounds more like something
that you may believe would be useful, but, in reality, isn't.

I am hearing that something that I (and a number of others) have been doing
quite successfully is somehow believed to be a major problem for others.
Also, that there are major "holes" in schematic tools, yet these purported
holes don't exist, at least to those of us who actually use the tools.  It
sounds more to me like some people have been convinced, IMO wrongly so, that
HDLs are the "correct" way to do logic design, and any other way is, at
best, wrong.  What scares me about this isn't engineering.  Engineering is
about evaluating alternatives...not about being glued to one "method" simply
for comfort and security.

I am curious if quite a number of HDL coders came from a software
background, instead of a hardware engineering background, and an HDL feels
more "familiar" to them, so it is good (to them, that is).  It feels that
way.  Obviously, the HDL companies have done their marketing job well to
convince so many people that (in a monotonic chant) "synthesis is best, all
else is evil".  I am not saying there is anything wrong with synthesis, I
own Synplify, and use it...it is a very good tool, but the lack of
flexibility and understanding (and good engineering sense) simply amazes me.




Article: 34549
Subject: Re: Version Control
From: "Austin Franklin" <austin@dar98kroom.com>
Date: Wed, 29 Aug 2001 07:02:10 -0400
Links: << >>  << T >>  << A >>
>  I don't use Schem for Logic Entry, ( as lack of conditional compile
> is a 'killer', as well as poor handling of Table, Condition and State
> designs ), but do use it a lot for PCB design.

I've never missed "conditional compile", so it's hardly been a "killer" for
me...but what problem do you have with tables, condition and state designs?
Perhaps you can give an example.  I do table driven stuff all the time.






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