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 51525

Article: 51525
Subject: Re: Short FIFO in Verilog / Spartan IIE
From: Ray Andraka <ray@andraka.com>
Date: Wed, 15 Jan 2003 16:28:43 GMT
Links: << >>  << T >>  << A >>
Use SRL16's.  Write shifts the data in, read is accomplished with a simple
up-down counter that counts up for write, down for read.  Nice because only one
counter is needed, and that counter provides a count of how many words are in
the fifo too.

"BÝrge Strand" wrote:

> I'm working on a digital oversampling filter where I need some really small
> FIFOs (2 to 16 words long). The width is 16 to 24 bits.
>
> What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> probably need at least 8 of them. The FIFOs in the Core Generator are
> generally longer that what I need. Latency is no problem in my design, and
> the clock speed is rather low. Reads and writes to/from the FIFO will be
> synchronous to the clock.
>
> Any feedback wellcome!
>
> Regards,
>
> BÝrge

--
--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: 51526
Subject: Re: Short FIFO in Verilog / Spartan IIE
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 15 Jan 2003 09:04:22 -0800
Links: << >>  << T >>  << A >>
24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex.
With almost 400 bits, your best bet is using the dual-ported BlockRAM,
organized 16 bits wide and 256 deep ( since you cannot get 32 width)
Since your design is synchronous and slow, I would use both ports in parallel
in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you
time-multiplex the addresses for writing and reading ( only 4 bits!).
That still wastes 90% of the RAM, but seems to be the simplest and cheapest
approach.
An asynchronous or very fast design would have to be totally different.

Hilsen fra
Peter Alfke, Xilinx Applications
===============================
"BÝrge Strand" wrote:

> I'm working on a digital oversampling filter where I need some really small
> FIFOs (2 to 16 words long). The width is 16 to 24 bits.
>
> What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> probably need at least 8 of them. The FIFOs in the Core Generator are
> generally longer that what I need. Latency is no problem in my design, and
> the clock speed is rather low. Reads and writes to/from the FIFO will be
> synchronous to the clock.
>
> Any feedback wellcome!
>
> Regards,
>
> BÝrge


Article: 51527
Subject: Re: Short FIFO in Verilog / Spartan IIE
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 15 Jan 2003 09:11:34 -0800
Links: << >>  << T >>  << A >>
I think Ray Andraka's suggestion using SRL16s is better, it only needs about 30
LUTs.
But if you are short on LUTs and rich on BlockRAMs, my suggestion would be
better.
Peter

Peter Alfke wrote:

> 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex.
> With almost 400 bits, your best bet is using the dual-ported BlockRAM,
> organized 16 bits wide and 256 deep ( since you cannot get 32 width)
> Since your design is synchronous and slow, I would use both ports in parallel
> in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you
> time-multiplex the addresses for writing and reading ( only 4 bits!).
> That still wastes 90% of the RAM, but seems to be the simplest and cheapest
> approach.
> An asynchronous or very fast design would have to be totally different.
>
> Hilsen fra
> Peter Alfke, Xilinx Applications
> ===============================
> "BÝrge Strand" wrote:
>
> > I'm working on a digital oversampling filter where I need some really small
> > FIFOs (2 to 16 words long). The width is 16 to 24 bits.
> >
> > What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> > probably need at least 8 of them. The FIFOs in the Core Generator are
> > generally longer that what I need. Latency is no problem in my design, and
> > the clock speed is rather low. Reads and writes to/from the FIFO will be
> > synchronous to the clock.
> >
> > Any feedback wellcome!
> >
> > Regards,
> >
> > BÝrge


Article: 51528
Subject: Re: Open FPGA please!
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Jan 2003 09:42:05 +1300
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> No, the router actually takes considerably longer than it did under 3.3 if the timing
> constraints are tight.

 That was what I meant - I expected a faster completion on a router 
that followed the placement, so expected the older model to be faster.
- just checking that was the case.

 Seems to me, in this Open FPGA discussion, that it would be better to
have
Open Communication with the tools designers, than so called 'Open
Tools'.
 Modern SW design means the SW writers rarely use the tools, so the flow
of
information on how they fail, or worsen with revisions, is very
important.

 Often the test examples are selected to test the 'new' features, and 
it is easy to loose sight of degraded performance in other cases.

>  Unfortunately, one is forced to use the later versions for any of the
> virtex2 or spartan2E devices.

 To echo Peter A, here, a good question is WHY ?

 With such an apparent performance branch, perhaps Xilinx should 
a) add these devices to the older flows, 
or 
b) hook the order routers into the new flows.

 Looks like a classic version control creepage problem to me....

> 
> Jim Granville wrote: Since a 'heavily floorplanned designs' has most of placement 
> work done, one could expect the routers to finish much faster.
> >
> >  Do you see much difference in the completion times of the 3.3 tools, vs
> > 5.1 tools ?
> >
> >  It's a common problem, supposedly smarter tools being harder to
> > control, and/or
> > giving dumber results..
> >
> > -jg

Article: 51529
Subject: Re: SChematic design approach compared to VHDL entry approach
From: Keith R. Williams <krw@btv.ibm.com>
Date: Wed, 15 Jan 2003 16:17:51 -0500
Links: << >>  << T >>  << A >>
In article <e9486eb9.0301141538.3031355@posting.google.com>, 
spam_hater_7@email.com says...
> See earlier thread about signal (net, language) naming conventions.
> 
> There is a reason that we use them!

Sure.  There are strong naming conventions in use.  However, 
chip_unit_subunit_reg_b_out becomes chip_unit_subunit_mux_b_in and 
perhaps chip_unit_reg_a_out(62) may become chip_unit_subunit_cr_of (for 
example).  There are three names for the same register bit.  

The particular case I'm thinking about has two more names associated 
with the signal because the size of the physical registers (and muxes) 
is different than the size of the architected registers.  Confusing 
when reading the logic, sure. The names all have a purpose though.

> You may consider doing just that; pick a naming convention, and start
> cleaning up the code.  It will make it much easier for the -next- bug.

No, mucking with a working design wouldn't be a good idea at all. I did 
say it's a *big* design. It would be CLM (Career Limiting Move).
 
> Couple of perl scripts, emacs with vhdl-mode, and a fair amount of time.

Since the design is hundreds of man-years worth of effort, I guess it 
would take a fair amount of time to convert it to something *I* liked. 
;-)  

Note that I'm taking the schematic/HDL discussion beyond the realm of 
FPGA designs.  I'm interested in the general applicability of both. I'm 
currently working on a large custom chip, though I had much more fun 
when I was doing FPGAs (which is why I follow this NG). :-(
 
----
  Keith

Article: 51530
Subject: Re: SChematic design approach compared to VHDL entry approach
From: Keith R. Williams <krw@btv.ibm.com>
Date: Wed, 15 Jan 2003 16:17:51 -0500
Links: << >>  << T >>  << A >>
In article <v29ho8p9qj6u5d@corp.supernews.com>, austin@da98rkroom.com 
says...
> Keith,
> 
> > > Well, it depends.  If you have a schematic library that allows you to
> draw a
> > > flow diagram and makes it drag and drop, it's REALLY easy...and easy to
> > > do...and easy to read.
> >
> > Doesn't that make it more of an HDL rather than schematic?
> 
> How?  There's no HDL involved at all.  Symply schematic blocks and symbols.
> 
> > There is
> > some "synthesis" going on then.  Perhaps I don't understand your tool.
> 
> There is no synthesis.  Simply hierarchical symbols, and underneath those
> symbols are schematics, or other blocks.  The very bottom level is gates,
> but above that, it's functional blocks.  Like a single symbol for a counter,
> or a single symbol for a CRC generator...

I guess I don't quite see the process yet. The top level is a schematic 
block, and the bottom level is gates, but the intermediate hierarchical 
objects are flow charts?  

The mainframe logic designers I worked with ~ten years ago used flow 
charts for the entire design.  The designs certainly were synthesized 
(and simulated) from the flow charts.

> > > > The design is simply too large
> > > > to make it practical though.
> >
> > I believe that generating schematics from this VHDL would be
> > impractical.
> 
> Ah, yes.  I understood that to mean that using schematics FOR that design
> was impractical because of the size of the design.

That too.  The mainframes of the 70s-80's were designed using 
schematics.  The logic diagrams filled carts for a single system unit. 
Call me skeptical on designs this size.  

> > > Er, yeah.  That's why the fast PCI cores are done in schematics ;-)
> >
> > PCI is fast?!
> 
> In a 4k, getting it to run at 33MHz is fast, and getting PCI-X to run at
> 133MHz is fast as well.  So, yes, PCI IS fast.

For programmable logic, sure. I didn't mean PCI(-X) was an easy design. 
133MHz isn't fast at all for a custom design. 

I wuz just twitting ya' a tad. ;-)  
 
> > > Well, then...DON'T USE ORDAD!
> >
> > Ordad? Tell us how you really feel! Don't hold it in!
> 
> I can't believe that they actually have the nerve to charge for such a gross
> schematic package...as $9.99 shareware, it's pretty good, but as a real
> schematic tool, it just doesn't work well.  The PCB tools are excellent
> though...which I find kind of funny.

That's about what I felt when I was learning to use Orcad.  It is a 
pretty miserable interface. 
 
> >One of the best decisions I made was to go
> > with the Synplicity tools.
> 
> Yes, they, specifically, have come a LONG way and as far as for FPGA use,
> are exceptional, especially with the RTL viewer.  I am very happy with
> Synplicity.

I don't think I could have gotten anywhere with VHDL/FPGAs without the 
HDL Analyst.  It took me a couple of months to figure out what language 
constructs synthesized to the structure I wanted.

----
  Keith


Article: 51531
Subject: Problem with XST libraries.
From: Andrew Rogers <andrew@rogerstech.co.uk>
Date: Wed, 15 Jan 2003 22:01:36 +0000
Links: << >>  << T >>  << A >>
I am very new to Xilinx tools so I apologise for being vague.

I tried using the Project Navigator and got the following error:

Compiling vhdl file jc2_top.vhd in Library work.
ERROR:HDLParsers:3014 - jc2_top.vhd Line 2. Library unit std_logic_1164 
is not available in library ieee.

I then tried the XST synthesis tool from a command line using the 
following script:

run
-ifn jc2_top.vhd
-ifmt VHDL
-opt_mode SPEED
-opt_level 1
-ofn jc2.ngc
-p 2s15-tq144-5


I get the same error message.

Thanks
Andrew Rogers


Article: 51532
Subject: Re: Open FPGA please!
From: Ray Andraka <ray@andraka.com>
Date: Wed, 15 Jan 2003 22:46:50 GMT
Links: << >>  << T >>  << A >>
To be fair, Xilinx is looking into the problem.  There definitely is a problem industry
wide of the software designers not really knowing how their tools are used.  I don't think
there were heavily floorplanned designs in the test suite.  The claims I've heard was the
PAR ran faster and got better results in 80% or so of the test designs.  Unfortunately, my
designs seem to invariably fall in the other 20%.  I'm sure most of the test designs were
more of what is typically done by average FPGA designers...fat slow designs that are good
enough in applications that are not particularly piece-part cost sensitive.

Jim Granville wrote:

> Ray Andraka wrote:
> >
> > No, the router actually takes considerably longer than it did under 3.3 if the timing
> > constraints are tight.
>
>  That was what I meant - I expected a faster completion on a router
> that followed the placement, so expected the older model to be faster.
> - just checking that was the case.
>
>  Seems to me, in this Open FPGA discussion, that it would be better to
> have
> Open Communication with the tools designers, than so called 'Open
> Tools'.
>  Modern SW design means the SW writers rarely use the tools, so the flow
> of
> information on how they fail, or worsen with revisions, is very
> important.
>
>  Often the test examples are selected to test the 'new' features, and
> it is easy to loose sight of degraded performance in other cases.
>
> >  Unfortunately, one is forced to use the later versions for any of the
> > virtex2 or spartan2E devices.
>
>  To echo Peter A, here, a good question is WHY ?
>
>  With such an apparent performance branch, perhaps Xilinx should
> a) add these devices to the older flows,
> or
> b) hook the order routers into the new flows.
>
>  Looks like a classic version control creepage problem to me....
>
> >
> > Jim Granville wrote: Since a 'heavily floorplanned designs' has most of placement
> > work done, one could expect the routers to finish much faster.
> > >
> > >  Do you see much difference in the completion times of the 3.3 tools, vs
> > > 5.1 tools ?
> > >
> > >  It's a common problem, supposedly smarter tools being harder to
> > > control, and/or
> > > giving dumber results..
> > >
> > > -jg

--
--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: 51533
Subject: Re: Short FIFO in Verilog / Spartan IIE
From: Ray Andraka <ray@andraka.com>
Date: Wed, 15 Jan 2003 22:51:16 GMT
Links: << >>  << T >>  << A >>
If you are short enough on luts for the SRL16 to be too expensive, you are likely
also too short to construct the two address counters plus mux logic plus population
count using LUTs that are close enough to the BRAM to not be a timing problem.  In
that case, I wouls look at the entire design to determine what parts would get the
most bang for the buck for implementation in the block RAM instead of in LUTs.

Peter Alfke wrote:

> I think Ray Andraka's suggestion using SRL16s is better, it only needs about 30
> LUTs.
> But if you are short on LUTs and rich on BlockRAMs, my suggestion would be
> better.
> Peter
>
> Peter Alfke wrote:
>
> > 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex.
> > With almost 400 bits, your best bet is using the dual-ported BlockRAM,
> > organized 16 bits wide and 256 deep ( since you cannot get 32 width)
> > Since your design is synchronous and slow, I would use both ports in parallel
> > in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you
> > time-multiplex the addresses for writing and reading ( only 4 bits!).
> > That still wastes 90% of the RAM, but seems to be the simplest and cheapest
> > approach.
> > An asynchronous or very fast design would have to be totally different.
> >
> > Hilsen fra
> > Peter Alfke, Xilinx Applications
> > ===============================
> > "BÝrge Strand" wrote:
> >
> > > I'm working on a digital oversampling filter where I need some really small
> > > FIFOs (2 to 16 words long). The width is 16 to 24 bits.
> > >
> > > What is the recommended way to implement such FIFOs in a Spartan IIE? I will
> > > probably need at least 8 of them. The FIFOs in the Core Generator are
> > > generally longer that what I need. Latency is no problem in my design, and
> > > the clock speed is rather low. Reads and writes to/from the FIFO will be
> > > synchronous to the clock.
> > >
> > > Any feedback wellcome!
> > >
> > > Regards,
> > >
> > > BÝrge

--
--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: 51534
Subject: Re: Problem with XST libraries.
From: Andrew Rogers <andrew@rogerstech.co.uk>
Date: Thu, 16 Jan 2003 00:09:13 +0000
Links: << >>  << T >>  << A >>
Andrew Rogers wrote:
> I am very new to Xilinx tools so I apologise for being vague.
> 
> I tried using the Project Navigator and got the following error:
> 
> Compiling vhdl file jc2_top.vhd in Library work.
> ERROR:HDLParsers:3014 - jc2_top.vhd Line 2. Library unit std_logic_1164 
> is not available in library ieee.
> 
> I then tried the XST synthesis tool from a command line using the 
> following script:
> 
> run
> -ifn jc2_top.vhd
> -ifmt VHDL
> -opt_mode SPEED
> -opt_level 1
> -ofn jc2.ngc
> -p 2s15-tq144-5
> 
> 
> I get the same error message.
> 
> Thanks
> Andrew Rogers
> 

Answer to my own question!

It seems that my XILINX environment variable should not have a trailing 
slash or back-slash.

I discovered the problem when I ran XST on Linux using Wine. First I set 
the XILINX variable

export XILINX=/mnt/win_d/xilinx/

with the slash, based on the line in my Windows autoexec.bat

SET XILINX=D:\XILINX\

Anyway setting the env variable without the trailing slash solved the 
problem, at least while running XST from Linux using Wine. I'm sure that 
the solution will also work if applied to Windows autoexec.bat but 
haven't tried that yet.

Regards
Andrew Rogers


Article: 51535
Subject: Re: Schematic design approach compared to VHDL entry approach
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Wed, 15 Jan 2003 20:20:48 -0500
Links: << >>  << T >>  << A >>
Keith,

> I guess I don't quite see the process yet. The top level is a schematic
> block, and the bottom level is gates, but the intermediate hierarchical
> objects are flow charts?

The top level of the schematic is, well, the top level.  There are blocks on
it, and the blocks may or may not be attached, and by attached, I mean have
signals between them.  Below each block is another schematic or an HDL file,
or a "black box".  Etc.

You can create a hierarchy any number of blocks deep, with the last block
you can push down through being either gates, a black box, or some HDL.

A schematic is nothing but a page with symbols on it, and connections.  A
flow chart (done in schematics using libraries) is nothing but a bunch of
flow chart symbols, and their attachments.  Each flow chart symbol is just
like any other block, but it is used for a flow chart.  It is just a symbol
with an underlying schematic, HDL or black box.

> The mainframe logic designers I worked with ~ten years ago used flow
> charts for the entire design.  The designs certainly were synthesized
> (and simulated) from the flow charts.

Are you talking board level schematics, chip schematics or what?  I don't
know the tool you are talking about.

> > Ah, yes.  I understood that to mean that using schematics FOR that
design
> > was impractical because of the size of the design.
>
> That too.  The mainframes of the 70s-80's were designed using
> schematics.  The logic diagrams filled carts for a single system unit.
> Call me skeptical on designs this size.

That's why you use hierarchy.  The more abstract (to a point, of course) you
can define the functions, the better your hierarchy.

> For programmable logic, sure. I didn't mean PCI(-X) was an easy design.
> 133MHz isn't fast at all for a custom design.
>
> I wuz just twitting ya' a tad. ;-)

> Yeah, well "twit" me after you've implemented a PCI-X design and see how
"fast" it really is ;-)
> I don't think I could have gotten anywhere with VHDL/FPGAs without the
> HDL Analyst.  It took me a couple of months to figure out what language
> constructs synthesized to the structure I wanted.

A fundamental gripe I have with synthesis tools.  They SHOULD provide a
document that states EXACTLY what a construct gets synthesized to.  We used
to do that when I wrote compilers, and I believe it's even more important to
do for hardware...but for some reason, people like the "it's done by magic"
philosophy.  Sigh.

Regards,

Austin



Article: 51536
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 15 Jan 2003 17:50:40 -0800
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@da98rkroom.com> writes:
> A fundamental gripe I have with synthesis tools.  They SHOULD provide a
> document that states EXACTLY what a construct gets synthesized to.

They do.  It's in one of the report files.  I often look at it to make
sure that I'm getting something reasonable.



Article: 51537
Subject: Re: SChematic design approach compared to VHDL entry approach
From: Keith R. Williams <krw@attglobal.net>
Date: Wed, 15 Jan 2003 22:11:22 -0500
Links: << >>  << T >>  << A >>
In article <v28pgpdr4uo638@corp.supernews.com>, 
austin@da98rkroom.com says...
> Michael,
> 
> > Basically, schematic entry tools are still in use only because people
> > without a software background are still allowed into a FPGA design
> > field.
> 
> Your statement is just simply so foolish I have to believe you simply are
> not serious.  If you are in fact serious, please let me know, so I can
> 'splain to you just how foolish such a statement is, for so many, many
> reasons.

Lucy, you have some 'splainin' to do!

----
  Keith

Article: 51538
Subject: quality of software tools in general
From: Matt <matt@NOSPAMpeakfive.com>
Date: Thu, 16 Jan 2003 04:15:32 GMT
Links: << >>  << T >>  << A >>
Hi,

I'm not even a newbie with respect to fpgas (I spend most of my time on
supercomputers) but am curious as to how good the tools are for
developing fpgas. For example, if someone wrote a fixed point fft in C
(or vhdl using the C-like programming part) and fed it to current fpga
tools, how would the output compare to someone with several years of
experience doing whatever was needed to make it run as fast as possible?
Would it be half as fast? 1/100th? worse? And where are the worst
problems? Is it vhdl compilation? place and route? Something else?

Matt

Article: 51539
Subject: Re: Schematic design approach compared to VHDL entry approach
From: "Austin Franklin" <austin@da98rkroom.com>
Date: Thu, 16 Jan 2003 00:04:39 -0500
Links: << >>  << T >>  << A >>

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhlm1loob3.fsf@ruckus.brouhaha.com...
> "Austin Franklin" <austin@da98rkroom.com> writes:
> > A fundamental gripe I have with synthesis tools.  They SHOULD provide a
> > document that states EXACTLY what a construct gets synthesized to.
>
> They do.  It's in one of the report files.  I often look at it to make
> sure that I'm getting something reasonable.

Eric,

I don't think you understand what I am talking about.  What I am looking for
is a gate level description of what a construct will synthesize to.  It is
not a standard, so it can vary from tool to tool, and from release to
release...and can change for some unrelated reason, just because that's the
way synthesis tools work.

I don't want to run the tools and play guessing games with what the tool is
going to output.  It should be documented, so when I code, I KNOW what the
hardware will be.

Austin



Article: 51540
Subject: Virtex II pro architecture question
From: Kuan Zhou <zhouk@rpi.edu>
Date: Thu, 16 Jan 2003 00:40:28 -0500
Links: << >>  << T >>  << A >>
Hi,
   I looked at Virtex II pro architecture.What are the functions
of WG4, WG3, WG2 and WG1?I noticed there are 8 inputs to each LUT.
Are they forming a 2^8 by 1 LUT tables or two 16 by 1 LUTs indivisually?

   Thank you very much!

sincerely
-------------
Kuan Zhou
ECSE department



Article: 51541
Subject: Re: Schematic design approach compared to VHDL entry approach
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 15 Jan 2003 22:12:30 -0800
Links: << >>  << T >>  << A >>
"Austin Franklin" <austin@da98rkroom.com> writes:
> I don't want to run the tools and play guessing games with what the tool is
> going to output.  It should be documented, so when I code, I KNOW what the
> hardware will be.

The tool doesn't always output the same thing for a given construct.  A
lot of things can influence it.  A manual like you propose would be huge,
and would almost always be out of date.

Have you seen such a manual for a C compiler?  I haven't.  And that's an
easier problem, because there are few constraints on the compiler output.

If you care about what's generated, you should look at the reports produced
by the synthesizer.  That will tell you what you want to know.


Article: 51542
Subject: Re: SChematic design approach compared to VHDL entry approach
From: assaf_sarfati@yahoo.com (Assaf Sarfati)
Date: 15 Jan 2003 22:38:45 -0800
Links: << >>  << T >>  << A >>
bktan1974@netscape.net (John Tan) wrote in message news:<eb4dd21b.0301120804.6a2e6729@posting.google.com>...
> Hi, what is the merit & constraint of each of these design entry
> methods
> 
> - schematic design 
> - VHDL 
> 
> i have heard pple saying any changes in schematic entry, will cause
> all timing to be changed and you got to check your timing again; is
> this true ? ANd how about VHDL; is it really better?
> 
> 
> I have last done a uni. project to implement a convolutional codec
> using schematic entry method; and frankly i i can't imagine to program
> the design in VHDL ...it's just too enormous the codes!

I've been designing both H/W and S/W for far too many years (when I
started, gates  came 4 to a package, which was called a "bug"...).
I've used both schematics and HDL for designs of various sizes.

I am all for HDL, for the following reasons:

*  Schematics can make the design structure and data flow more
visible? sure, if your design flows data from one end to another.
Control signals, however, are usually a rat's-nest, which rather
spoils the pretty picture. For documenting the design, use a graphical
editor (I use Visio), and draw only the interesting stuff; I don't
have to bother with all the random signals which makes a schematic
functional (even clocks and resets!).

*  Documenting your design: of course you can document a schematic
design, but if you write in HDL you can (and I do) comment EVERYTHING:
each port, each decision, why I did it this way and not that way. The
comments are there near the design itself and not in a separate file
which I have to open as well, and which I will probably be too lazy to
update on every design change.

*  Entering a design: I can type much faster than I can drag lines
with a mouse. I can also create parameterized blocks and reuse them
with no changes; a 4-bit counter and a 32-bit counter are the same.
Will a schematic 4-bit counter be the same as a 32-bit counter?

*  Maintaining a design: say you need an up/down counter which counts
between 5 and 27. In your schematics it wil be a mess of gates and
FFs; after you haven't touched this part of the design for a few
months, you'll have to scratch your head quite a lot to understand
what it's supposed to do (been there, done that). In an HDL design,
even if it's uncommented, you can understand what it does in a glance.

*  Navigating the design: most schematic tools have very poor search
capabilities, compared to text editors. It's much easier to follow
signals, especially as the display is much denser: I can view
something like 100 lines of text at once, which can represent, for
example, a state machine which will require many schematic pages.

*  Version Control: you can save schematics in a VCS; but how do you
compare versions? once, long ago, I've thought of writing an
application to read graphic representation of a schematic (using
HP-GL, then used for most printing), and then overalying the output
graphics on a display. After some thought, I gave it up and returned
to the old method of overlaying the schematics on a light table - very
hard work.

In a text-based design, you can very easily compare version: aha! I've
added a pipeline register here! so THAT is the bug! all in a few
minutes.

* Simulation & verification: if your design is a schematic, how do you
simulate? usually you draw waveforms (or the text equivalent of
writing test-vectors) - more of the same hard work. When your design
is HDL, you can create an interactive test-bench (with the design,
sadly not with you) and automate the whole process; run it at night
and in the morning you see, before your first coffee, if it worked or
not.

All that said, I still belive that a person who has schematic design
experience will usually create better HDL designs, the same way that a
programmer who has Assembly code experience will usually write better
high-level language code.

Article: 51543
Subject: Re: How to add pins in ISE 4.2
From: amit_ashara@hotmail.com (Amit)
Date: 16 Jan 2003 00:07:50 -0800
Links: << >>  << T >>  << A >>
Hi Kuan,

 Which schematic tool are using in the ISE 4.2. For e.g. is it the
FPGA editor, etc..

Regards
Amit

Kuan Zhou <zhouk@rpi.edu> wrote in message news:<Pine.SOL.3.96.1030114211435.25313A-100000@vcmr-86.server.rpi.edu>...
> Hi,
>    I am using ISE 4.2 student version.But I can not find output pad in the 
> schematic tools.Does any one know how to add pins in the schematic design?
> The help says you can find "add pins" from the Add menu,but I can not find
> it.
> 
>    Thank you very much!
> 
> sincerely
> -------------
> Kuan Zhou
> ECSE department

Article: 51544
Subject: Re: Student development board
From: fba@free.fr (Frederic Bastenaire)
Date: 16 Jan 2003 00:19:03 -0800
Links: << >>  << T >>  << A >>
> > Does anyone know what is the best choice for an fpga developement kit?
> > Altera offers this kit for University student :
> > http://www.altera.com/education/univ/kits/unv-kits.html
> > I wonder if there are other supplier of boards like this (could be Xilinx
> > too) that could compete with this. Are there third party manufacturer that
> > are worth considering?
> > Thanks
> > David
> >
> 
 I use a Trenz-electronic Xilinx Spartan II board (TE-XC2S) with 200k
gates,
quite a nice device to learn this exciting technique (cf
http://www.trenz-electronic.de/prod/proden7.htm).
 Take also a look at http://www.fpga-faq.com/FPGA_Boards.htm 

Yours,

Frederic Bastenaire

Article: 51545
Subject: Re: Short FIFO in Verilog / Spartan IIE
From: "BÝrge Strand" <borge.strand.remove.if.not.spamming@sintef.no>
Date: Thu, 16 Jan 2003 09:45:10 +0100
Links: << >>  << T >>  << A >>
Thanks guys,

What is happening is that the digital oversampler presents four (or eight)
samples on consecutive positive clock edges. The oversampler itself decides
when this is about to happen. (I can count there, but I prefere not to.)
Then the oversampler stays silent for a while. However, the input samples to
the oversampler have to have delays between them.

The output from an oversampling filter is to be fed to the next oversampling
filter at a more steady rate (i.e. not four samples and then long delay, but
one sample - some delay - one sample -some delay, and so on). The output
from the final oversampler goes to a DAC at a completely steady rate. So you
see the need for FIFOs. In my prototype code I fill registers 0 through 3 or
7 and then read them at a later stage, but this makes timing pretty
complicated.

My filter will perhaps use 4 2x-oversamplers in 2 channels. That calls for 2
FIFOs which are 2 deep, 2 which are 4 deep, 2 which are 8 deep, and 2 which
are 16 deep. So that means there's a bunch of really small FIFOs. The last
one has to be 16 deep, the other ones can probably be trimmed down to depth
2, but I won't be able to reduce the count.

And if all this works I'll connect it to my CD player and play Bach on it!

--

BÝrge



"Peter Alfke" <peter@xilinx.com> wrote in message
news:3E259496.6D9D7A87@xilinx.com...
> 24 bit wide, 16 deep synchronous FIFO in Spartan-II or Virtex.
> With almost 400 bits, your best bet is using the dual-ported BlockRAM,
> organized 16 bits wide and 256 deep ( since you cannot get 32 width)
> Since your design is synchronous and slow, I would use both ports in
parallel
> in a single-port fashion, which gives you a 32-wide, 128 deep RAM, and you
> time-multiplex the addresses for writing and reading ( only 4 bits!).
> That still wastes 90% of the RAM, but seems to be the simplest and
cheapest
> approach.
> An asynchronous or very fast design would have to be totally different.
>
> Hilsen fra
> Peter Alfke, Xilinx Applications
> ===============================
> "BÝrge Strand" wrote:
>
> > I'm working on a digital oversampling filter where I need some really
small
> > FIFOs (2 to 16 words long). The width is 16 to 24 bits.
> >
> > What is the recommended way to implement such FIFOs in a Spartan IIE? I
will
> > probably need at least 8 of them. The FIFOs in the Core Generator are
> > generally longer that what I need. Latency is no problem in my design,
and
> > the clock speed is rather low. Reads and writes to/from the FIFO will be
> > synchronous to the clock.
> >
> > Any feedback wellcome!
> >
> > Regards,
> >
> > BÝrge
>



Article: 51546
Subject: Xilinx XST & multiple (source) libraries
From: David R Brooks <daveb@iinet.net.au>
Date: Thu, 16 Jan 2003 16:53:07 +0800
Links: << >>  << T >>  << A >>
The Xilinx docs. describe a command-line option to XST:
set -xsthdpini <file>
to be used to specify a "VHDL.INI" file, for use when a source project
spans several logical libraries (I do have this right?)

Q: Is there anywhere an example syntax of the VHDL.INI file? I can't
seen to find one.

TIA


Article: 51547
Subject: HSPICE simulator
From: "Skillwood" <skillwoodNOSPAM@hotmail.com>
Date: Thu, 16 Jan 2003 14:40:54 +0530
Links: << >>  << T >>  << A >>
Hi,
Is there any free HSPICE simulator available in the Web?

Thanks
Skillie



Article: 51548
Subject: Xilinx PCI core PCI-X compatible ?
From: "HJO" <H.Otten@spamblock.blockspam.Rohill.nl>
Date: Thu, 16 Jan 2003 10:30:05 +0100
Links: << >>  << T >>  << A >>
Hello,

We've got the following problem: Some time ago we finished a PCI interface
card using a Spartan II FPGA and the Xilinx PCI core (3.3V). The card has
been used in several computers since then and we have never had any problems
with it.
Recently we bought a new computer that also has to use this card, but it's
equiped with PCI-X expansion slots. According to the PC's documentation the
PCI-X slots are fully PCI 2.2 compliant. The Xilinx PCI core is also PCI 2.2
compliant so there should be no problem. Unfortunately it does not work ! As
far as we can see the problem is not PC related since several other
(ordinairy) PCI cards work well with the PCI-X slot.

Has anybody ever got this to work properly ? Or has anybody got any idea on
what might be wrong ?

Harjo.




Article: 51549
Subject: Re: SChematic design approach compared to VHDL entry approach
From: johnjakson@yahoo.com (john jakson)
Date: 16 Jan 2003 01:50:02 -0800
Links: << >>  << T >>  << A >>
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0301141000.6baec97c@posting.google.com>...
> Basically, schematic entry tools are still in use only because people
> without a software background are still allowed into a FPGA design
> field. The day management will finally realize how much money can be
> saved by keeping these people (a.k.a. hardware engineers) out of all
> but the simplest FPGA designs - the time of the schematics will be
> over.
> These HW guys can't spell "version control" !!! Enough said.
> 
> bktan1974@netscape.net (John Tan) wrote in message news:<


I wonder if you ever flew on a plane developed by SW engineers that
did't need to visualize all it's parts to check if it made any sense.

I wonder if you drive a car developed by SW engineers ....

I wonder if you live in a house developed by SW engineers ....

Why do Boing, GM,Ford, most all architects use 3d modelling SW to
visulize, I guess it beets me.

I surely hope that I never have to work for someone out of SW school
thinks he's a wiz at HW, yeck

I am remined of all the Bill Gates jokes , if MS ever designed a
car...

Please tell us what companies you have worked for so I can steer as
far away as possible!!


As a side note I would say the main reasons schematics are barely with
us are many,

Most of the EDA schematic tools were bloody awefull, non portable, no
free viewers, dongeled to hell & back, buggy as hell, & written by SW
twerps that never used their own tools, incompaible (until EDIF came
along), poor cousins of the bigger tools. But a few were gems,
(written by ASIC veterans).

Example, you want to run a new wire between distant blocks across the
hierarchy.

In any HDL its a few mins work to edit the port lists and add the
wires to all the intervening cells, but you'd have to compile it to
know for sure.

In VLSI/Compass, it was almost as easy but still took a few times
longer, and that tool had true edit in place symbols that changed as
you added the new ports & wires and it wasn't too dumb, interactive
DRC, errors flashed up quickly, very Macish, a pleasure to use. Many
ASICs were built with those tools but Cadence bought em out and junked
everthing except the cell libs.

In every other schematic tool I used since, the work load for such
simple tasks was 10x Compass, no edit in place, you had to rip out the
instances, go to symbol edit, change the symbol, reinstance into all
locations where ripped, fight multiple versions, add the wires, no
interactive DRC, even the redraw had to be used to clean up many draw
errors. I shudder at the thought of how much time was wasted fighting
the darn things.

Alas, I miss Compass, it will never be the same.

I also can still understand most all the schematics I ever worked on
over 2 decades, I can't say the same for HDL unless it is very
structural & quite recent. Wonder why?

It doesn't have to be like that, as I said before, if only I could
massage the auto generated sch output to make it more presentable,....



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