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

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 126200

Article: 126200
Subject: Re: simulating xilinx block ram with modelsim
From: Andrew Ganger <Andrew.G@yahoo.co.uk>
Date: Fri, 16 Nov 2007 19:43:27 +0000
Links: << >>  << T >>  << A >>
> Notice that it is important to register the read address. This is 
> required to infer block ram. If you don't do that, you will get LUT ram.

Hm so in other words, my block RAM wont be infered correctly because I 
made the process sensitive to the readaddress as below?


architecture Behavior of ram_data is

     type ram_type is array (0 to SIZE-1) of std_logic_vector (31 downto 0);
     signal ram : ram_type :=
     (   X"00000063",
         X"0000007c",
	....
	);

     begin
       PROC_ram : process (clk, rw_addr_cp0)
       begin
         if (rst = '0') then -- optional reset
           data_out_cp0 <= (others => '0');
         elsif (clk'event and clk = '1') then
           -- memory write:
           if (ew_cp0 = '1') then
             if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
SIZE-1) then
               ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
             end if;
           end if;
         end if;

         -- memory read:
         if (unsigned(rw_addr_cp0) >= 0 and unsigned(rw_addr_cp0) <= 
SIZE-1) then
           data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
         end if;
     end process PROC_ram;

end Behavior;


Article: 126201
Subject: Re: jitter-sensitive multi-output clk distribution for
From: Patrick Dubois <prdubois@gmail.com>
Date: Fri, 16 Nov 2007 12:03:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On 16 nov, 05:15, "Toni Merwec" <mistertorp...@freenet.de> wrote:
>
> I don't think that a regular low-jitter clock device (and it HAS to be
> low-jitter as for the reference for the MGTs) can drive 6 inputs over
> several centimeters. I already used the ICS843020 clock synthesizer in
> several other projects and wanted to use it again. Reason for the ICS is
> that it features a programmable output frequency in the range of 35 - 700
> MHz. Problem is, the ICS843020 has only two outputs. The Epson EG2121CA
> device that is proposed in the Virtex-4 MGT user guide is not suitable
> because these devices are restricted to one fixed frequency.

Check out ICS843001-21:
http://www.xilinx.com/products/boards/ml505/datasheets/ics843001-21.pdf

It's a frequency synthesizer with very low jitter. It's used on Xilinx
ML505 board for RocketIOs. Then I'm pretty sure that you can find a
low skew clock buffer to drive your 6 clocks.

Patrick

Article: 126202
Subject: Re: simulating xilinx block ram with modelsim
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 16 Nov 2007 20:08:42 GMT
Links: << >>  << T >>  << A >>
Andrew Ganger wrote:
>> Notice that it is important to register the read address. This is 
>> required to infer block ram. If you don't do that, you will get LUT ram.
> 
> Hm so in other words, my block RAM wont be infered correctly because I 
> made the process sensitive to the readaddress as below?
> 

That's right, unless rw_addr_cp0 is registered somewhere else. And even 
then, different versions of ISE can be somewhat finicky about exactly 
how the code is written. Other synthesis tools may have their own 
requirements, but a registered read address is universal. I consider it 
clearest to keep the register at the place where I am inferring the BRAM.

Article: 126203
Subject: Re: V4FX: Cannot access EMAC1 of Dual MAC system
From: JimboD2@gmail.com
Date: Fri, 16 Nov 2007 12:22:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 12:01 pm, Ben Jackson <b...@ben.com> wrote:
> On 2007-11-16, Jimb...@gmail.com <Jimb...@gmail.com> wrote:
>
>
>
> >> You probably forgot to set C_TEMAC_INST in the second PLB temac (in
> >> addition to C_TEMAC_BOTH_USED).
>
> > I guess the question now is, how can i override this value manually
> > and prevent the tools from doing this?
>
> Edit the MHS file in a text editor.
>
> --
> Ben Jackson AD7GD
> <b...@ben.com>http://www.ben.com/

Yeah, I actually tried that this morning. Here's my updated MHS file:
BEGIN plb_temac
 PARAMETER INSTANCE = plb_temac_1
 PARAMETER HW_VER = 3.00.a
 PARAMETER C_TEMAC_BOTH_USED = 1
# User Added parameter JPM 7/16/07
 PARAMETER C_TEMAC_INST = 1
# # END USER ADDED parameter
 PARAMETER C_PLB_CLK_PERIOD_PS = 10000


After re-running all I didnt see the message in platgen.log but still
saw the same message in system.log and libgen.log. It seems something
is overriding my parameter assignment.

Article: 126204
Subject: Re: simulating xilinx block ram with modelsim
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 16 Nov 2007 12:50:43 -0800
Links: << >>  << T >>  << A >>
u_stadler@yahoo.de wrote:

> but whatever i do to the ports of the memory they always stay 'x'.
> shouldn't at least the input port be '0' or '1' if i apply that
> signal?

Only if the testbench first does a write cycle
and then a read from the same address.
Otherwise x is probably the right answer.

        -- Mike Treseler

Article: 126205
Subject: Re: simulating xilinx block ram with modelsim
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 16 Nov 2007 13:47:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 12:50 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> u_stad...@yahoo.de wrote:
> > but whatever i do to the ports of the memory they always stay 'x'.
> > shouldn't at least the input port be '0' or '1' if i apply that
> > signal?
>
> Only if the testbench first does a write cycle
> and then a read from the same address.
> Otherwise x is probably the right answer.
>
>         -- Mike Treseler
Xilinx BlockRAMs must have a clock to perform any operation, even a
read. This is not intuitively obvious, but it is an absolute
requirement.
Peter Alfke, Xilinx

Article: 126206
Subject: Re: FPGA for hobby use
From: Dave <dhschetz@gmail.com>
Date: Fri, 16 Nov 2007 13:48:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 2:07 pm, Ray Andraka <r...@andraka.com> wrote:
> Andy wrote:
>
> > I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic
> > capture for xc2000/xc3000 designs, and I hated VHDL for a long time.
> > My old boss hung up a quote of mine about trying to design SW by
> > drawing pictures, while HW design was hell-bent-for-leather, headed
> > the other way. Previous poster notwithstanding, I used GED (precursor
> > to Concept) to build wonderful, intelligently parameterizable
> > functional blocks that could be interconnected in an easily
> > understood, structual way. Unless I needed to design a state
> > machine... That's when I started to design behaviorally, instead of
> > structurally. Now, design structure is mostly about managing
> > behavioral complexity, and a only little about managing physical
> > complexity. Once you make that thought shift, it's gravy from there
> > on.
>
> Andy, before I abandoned schematics, I had come up with a very workable
> graphical state machine entry for schematics.  The schematic looked just
> like a state diagram.  Basically, I made schematic wrappers that looked
> like state diagram elements so that putting together the state machine
> was much like drawing it out.  Of course it resulted in a decoded state
> machine, but that was OK since that was the style that generally yielded
> the best results in FPGAs of the time anyway.  The components were: a
> state bubble containing a flip-flop; a decision box, which contained a
> pair of AND gates with the decision input inverted into on and not into
> the other; and a wire junction, which wrapped around an OR gate.  I
> think there were a few other elements, but these were the major ones.
> It made for very fast entry, and very readable state machine schematics.
>   I also had a methodology for encoded state machines that made it easy
> to read the function.  I don't recall off the top of my head what I did
> there, but it basically involved a mux element with all the states shown.

I remember hearing the rumor that the Graychip (now TI) GC4014 quad
DDC chips were designed using schematic entry - quite a feat
considering the complexity of the chips. I'm sure the design involved
a library like the one Ray described, eventually building NCO's and
complex multipliers out of gates. Granted, that was an ASIC design,
and maybe it makes more sense there, but still... maybe DSP folks are
more biased to this design methodology than pure digital folks?

Article: 126207
Subject: Re: TI DSP soft core in Xilinx?
From: austin <austin@xilinx.com>
Date: Fri, 16 Nov 2007 13:56:25 -0800
Links: << >>  << T >>  << A >>
All,

That would make no sense at all (to have a TI DSP soft core) in an FPGA!

It is far less expensive to just buy the part from TI.

As for making TI 'uncomfortable', we consider TI a great partner:  they
sell their DSPs into many markets, and when they can't do something fast
enough, they sell their DSPs and our FPGAs.

If we sell our FPGA into a market, and there is a TI DSP that can do a
job where we are not competitive, we encourage the customer to use TI, too.

Are there some jobs that TI wins, or we win exclusively (the other is
just not needed)?  Sure.  That happens if we were partners, or not.

We sell, they sell.  It is not a "zero-sum" game where there can only be
one winner every time:  we are all winning (customer, Xilinx, TI)!

Customer knows that Xilinx and TI are working together to provide them
with the best solution to their problems.

Austin

Article: 126208
Subject: Re: FPGA for hobby use
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 16 Nov 2007 22:12:58 +0000
Links: << >>  << T >>  << A >>
On Fri, 16 Nov 2007 13:48:11 -0800 (PST), 
Dave <dhschetz@gmail.com> wrote:

>I remember hearing the rumor that the Graychip (now TI) GC4014 quad
>DDC chips were designed using schematic entry - quite a feat
>considering the complexity of the chips. I'm sure the design involved
>a library like the one Ray described, eventually building NCO's and
>complex multipliers out of gates. Granted, that was an ASIC design,
>and maybe it makes more sense there, but still... maybe DSP folks are
>more biased to this design methodology than pure digital folks?

When designing control logic, I generally very much prefer to
write - and think - in HDL because it helps me describe 
sequential flow of behaviour.  When designing datapath,
and especially when describing fixed-function (or nearly
fixed-function) DSP datapath, I still tend to use HDLs
nowadays but there's no doubt I'm thinking in block-level
schematic - adders, normalisers, MACs, that sort of thing.
Note that users of DSP simulation software generally use
block diagrams rather than procedural code, so I reckon
I'm in good company.

I guess the deal is roughly this:  When you have concurrently
executing blocks each of whose functions is nontrivial but
largely invariant (same behaviour on every clock tick), 
it's easier to think in block diagram terms.  When you 
have a complicated function whose behaviour varies
rapidly over time (state machine), it's easier to think
in terms of procedural code (at least, it is for me).
Ray Andraka's ingenious state-diagram-to-schematic
transformation, which I think he's described here in 
the past, is a good example of an alternative view.

*All* our design-capture tools and methodologies
are nothing more than steps on the way from 
design concept to implementation.  If a tool,
language, or diagram-methodology is to be useful,
it must:
- provide a convenient bridge between two points
  on the design refinement pathway that otherwise
  would be too far apart to link in a single step;
- provide a framework for thinking that is not
  too restrictive, but also is prescriptive enough
  to allow you to get started on a problem easily;
- be rigorous enough to allow you, and (ideally)
  automated tools, to reason about the design;
- be readily comprehensible by other practitioners.
Schematics, state diagrams, Boolean equations, 
HDLs and graphical DSP design tools have all 
proved their worth against these criteria.
Changes in technology, and changes in the scope
and difficulty of designs that you undertake,
will shift the balance in favour of some and
against others.  It's silly to be dismissive of
any of them out of context.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 126209
Subject: Re: V4FX: Cannot access EMAC1 of Dual MAC system
From: JimboD2@gmail.com
Date: Fri, 16 Nov 2007 14:16:26 -0800 (PST)
Links: << >>  << T >>  << A >>
I've just heard from Xilinx support that the second MAC does not work
with ISE/EDK 9.1. The solution is to upgrade to 9.2.

Ben, thanks again for your help.


Article: 126210
Subject: Re: simulating xilinx block ram with modelsim
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: Fri, 16 Nov 2007 15:14:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On 16 Nov., 22:47, Peter Alfke <pe...@xilinx.com> wrote:
> On Nov 16, 12:50 pm, Mike Treseler <mike_trese...@comcast.net> wrote:> u_stad...@yahoo.de wrote:
> > > but whatever i do to the ports of the memory they always stay 'x'.
> > > shouldn't at least the input port be '0' or '1' if i apply that
> > > signal?
>
> > Only if the testbench first does a write cycle
> > and then a read from the same address.
> > Otherwise x is probably the right answer.
>
> >         -- Mike Treseler
>
> Xilinx BlockRAMs must have a clock to perform any operation, even a
> read. This is not intuitively obvious, but it is an absolute
> requirement.
> Peter Alfke, Xilinx

well i used a clock of course..

urban

Article: 126211
Subject: Re: FPGA for hobby use
From: nico@puntnl.niks (Nico Coesel)
Date: Fri, 16 Nov 2007 23:57:46 GMT
Links: << >>  << T >>  << A >>
Herbert Kleebauer <klee@unibwm.de> wrote:

>A few month ago I asked for a recommendation for FPGA (not a ready to use demo board)
>which could be handled with simple home equipment. I got the link to:
>
>http://www.enterpoint.co.uk/moelbryn/darnaw1.html
>
>We ordered a few samples and did some experimenting. Here the documentation
>for a simple 16 bit CPU implemented on the DARNAW1. It includes also a step by
>step introduction which should allow anybody still unfamiliar with FPGA design
>to implement the demo in less than a hour.
>
>ftp://137.193.64.130/pub/mproz/mproz3_e.pdf  (documentation)
>ftp://137.193.64.130/pub/mproz/mproz3.zip    (documentation + schematics)
>
>Conclusion: 
>The board is great, not just an other demo board, but rather a package
>converter from the FPG ball grid to a pin grid array with the necessary
>voltage converters and program flash on board. Sadly the same can't be 
>said about the current Xilinx software (schematic editor + simulator), 
>so we will try to stay as long as possible with the X3000 chips and the
>old Xilinx DOS software (with ViewLogic schematic entry + simulator).

At this moment I think either Verilog or VHDL is the best route. And
it probably is for the next few years.
I have a customer which has a lot of legacy in schematics (Orcad/ XNF
format) which is totally useless with the newer ISE versions. Their
VHDL code however ports nicely between various ISE versions.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 126212
Subject: Re: FPGA for hobby use
From: Ray Andraka <ray@andraka.com>
Date: Fri, 16 Nov 2007 19:25:48 -0500
Links: << >>  << T >>  << A >>
Dave wrote:

> I remember hearing the rumor that the Graychip (now TI) GC4014 quad
> DDC chips were designed using schematic entry - quite a feat
> considering the complexity of the chips. I'm sure the design involved
> a library like the one Ray described, eventually building NCO's and
> complex multipliers out of gates. Granted, that was an ASIC design,
> and maybe it makes more sense there, but still... maybe DSP folks are
> more biased to this design methodology than pure digital folks?

I can tell you for fact that I designed systems considerably more 
complex than those DDC chips using schematics.  In fact many of those 
systems included DDCs that compared very favorably against the Graychip 
devices in terms of performance.  For example, the design described in 
my paper "An FPGA based processor yields a real time high fidelity radar 
environment simulator" (http://www.andraka.com/files/mapld.pdf) was a 
design done with schematics that involved more than a dozen unique 
XC4025 designs.  It would have been impossible to meet the density and 
performance requirements with the VHDL tools available at the time 
because of the floorplanning required to get it all to fit.

Article: 126213
Subject: New Laptop for work
From: rickman <gnuarm@gmail.com>
Date: Fri, 16 Nov 2007 17:22:34 -0800 (PST)
Links: << >>  << T >>  << A >>
I am looking at a low end Dell laptop, the Vostro 1500, as a new
computer for work.  I may supplement this later with a new desktop
unit for crunching FPGA designs, but I will also be using this laptop
for this sort of work.  I am looking for advice on the differences in
CPUs for FPGA work and anything else that is relevant.

I know that parallel ports are going the way of the serial port and
the dodo bird, but I can live with that.  Most tools are available as
USB devices now.

This particular computer comes with WindowsXP rather than Vista.  From
what I have heard, that is an advantage.  But I notice that the
internal bluetooth adapter is specific for XP and others from Dell are
specific for Vista.  Any idea what is up with that?  Is there any
significant advantage to using XP pro over XP home?

This machine also has the "Intel(R) Integrated Graphics Media
Accelerator X3100".  Is that just another way of saying "integrated
video"?  Several of my other machines have had integrated video and it
does seem to drag down the CPU noticeably.  Any idea if I will notice
the drag on the Core 2 Duo?  They also offer an Nvidia Gforce 8400 GS
adapter for $100 and an 8600 for $200 more.  Any idea if these are
worth it?  The 1500 says it has "VGA video output & S-Video".  Does
that mean I can connect two monitors for dual display?

The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various
processors for significant money.  The first stepup is to a T5470 (1.6
GHz) for $75 and others range up to $575!  I am thinking I can live
with the slower processor.  The memory is 2GB.

I was looking at the Vostro 1000 earlier this week with an AMD TK-53
processor (1.5 GHz, 512 KB cache) and a smaller hard drive.  It was
$50 more so the 1500 looks like the better deal.  Are there any
significant differences in the two CPUs for FPGA work?  I guess the
small cache of the TK-53 would make it significantly slower for FPGA
work.

I saw a thread from earlier this year discussing some of this.  I
wonder how much laptops have improved since then.



Article: 126214
Subject: Re: New Laptop for work
From: "evilkidder@googlemail.com" <evilkidder@googlemail.com>
Date: Fri, 16 Nov 2007 18:34:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 17, 1:22 am, rickman <gnu...@gmail.com> wrote:
> I am looking at a low end Dell laptop, the Vostro 1500, as a new
> computer for work.  I may supplement this later with a new desktop
> unit for crunching FPGA designs, but I will also be using this laptop
> for this sort of work.  I am looking for advice on the differences in
> CPUs for FPGA work and anything else that is relevant.
>
> I know that parallel ports are going the way of the serial port and
> the dodo bird, but I can live with that.  Most tools are available as
> USB devices now.
>
> This particular computer comes with WindowsXP rather than Vista.  From
> what I have heard, that is an advantage.  But I notice that the
> internal bluetooth adapter is specific for XP and others from Dell are
> specific for Vista.  Any idea what is up with that?  Is there any
> significant advantage to using XP pro over XP home?
>


I prefer xp-pro because it allows you to use it over remote desktop.
As to whether that feature is needed on a laptop is your choice.


> This machine also has the "Intel(R) Integrated Graphics Media
> Accelerator X3100".  Is that just another way of saying "integrated
> video"?  Several of my other machines have had integrated video and it
> does seem to drag down the CPU noticeably.  Any idea if I will notice
> the drag on the Core 2 Duo?  They also offer an Nvidia Gforce 8400 GS
> adapter for $100 and an 8600 for $200 more.  Any idea if these are


For the 2D realm it'll make no noticeable difference.  If 3D's your
bag (basically games) then integrated video is pretty hopeless.  On
the brightside integrated video will increase battery life which is
always a bonus.


> worth it?  The 1500 says it has "VGA video output & S-Video".  Does
> that mean I can connect two monitors for dual display?


Probably not.  I suspect it means you can connect the laptop to a VGA
monitor, or TV with S-Video input.  Note that while S-Video is OK for
watching a film, it's hopeless for actual work (unless you like
headaches).



> The CPU is a T5270 (1.4 GHz, 2 MB cache) with upgrades to various
> processors for significant money.  The first stepup is to a T5470 (1.6
> GHz) for $75 and others range up to $575!  I am thinking I can live
> with the slower processor.  The memory is 2GB.


Unless you can bump it up to a 4Mb cache version, I doubt the extra
$100's for a few MHz is going to make all that much difference.  2GB
memory is about the most that XP can reasonably handle anyway, unless
you fancy playing with 64bit linux which is always an option (hint -
repartition the drives and reinstall windows the second you get the
laptop if you are even considering this option).


> I was looking at the Vostro 1000 earlier this week with an AMD TK-53
> processor (1.5 GHz, 512 KB cache) and a smaller hard drive.  It was
> $50 more so the 1500 looks like the better deal.  Are there any
> significant differences in the two CPUs for FPGA work?  I guess the
> small cache of the TK-53 would make it significantly slower for FPGA
> work.


Dunno - the biggest difference I've found with a dual core machine is
that I can continue working thanks to the second processor.  Now I'm
not waiting for it to finish all the time, I care a good bit less
about how long it takes.

Cheers,

Andy



Article: 126215
Subject: Re: FPGA for hobby use
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Sat, 17 Nov 2007 02:37:18 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <473e2dbe.1233804717@news.planet.nl>,
Nico Coesel <nico@puntnl.niks> wrote:

>I have a customer which has a lot of legacy in schematics (Orcad/ XNF
>format) which is totally useless with the newer ISE versions. Their
>VHDL code however ports nicely between various ISE versions.

So is this DOS OrCAD or Windows OrCAD?  I have a very rough tool which
converts DOS OrCAD into Verilog.  If there's interest I'll post it.
-- 
/*  jhallen@world.std.com AB1GO */                        /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

Article: 126216
Subject: gate count calculation in xilinx.
From: subbu <subramanian.2k111@gmail.com>
Date: Fri, 16 Nov 2007 21:05:57 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
   can anybody help in providing a document or any site relating gate
count calculation in xilinx.

Thanks & regards
subbu

Article: 126217
Subject: Re: TI DSP soft core in Xilinx?
From: "cpope" <cepope@nc.rr.com>
Date: Sat, 17 Nov 2007 00:08:25 -0500
Links: << >>  << T >>  << A >>

"austin" <austin@xilinx.com> wrote in message
news:fhl3m9$19o1@cnn.xilinx.com...
> All,
>
> That would make no sense at all (to have a TI DSP soft core) in an FPGA!
>

That's like saying it makes no sense at all to have a powerpc or a
microblaze in an FPGA? I have a v4fx system, I'd like a dsp coprocessor. I
don't want to waste the board space or power consumption for a dedicated DSP
since not all applications will need/use it. For wideband signal processing
apps I can use the fpga fabric, for narrowband stuff I can use a softcore
with floating point DSP.

-Clark



Article: 126218
Subject: Gate count calculation in xilinx.
From: subbu <subramanian.2k111@gmail.com>
Date: Fri, 16 Nov 2007 21:10:59 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
   Can anybody help me in providing a document or site in gate count
calculation in Xillinx Spartan 3E.
thanks & regard
subbu

Article: 126219
Subject: Re: Gate count calculation in xilinx.
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 16 Nov 2007 21:38:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 16, 9:10 pm, subbu <subramanian.2k...@gmail.com> wrote:
> Hi,
>    Can anybody help me in providing a document or site in gate count
> calculation in Xillinx Spartan 3E.
> thanks & regard
> subbu

Gate-count is a meaningless metric for FPGAs, where functionality is
implemented in coarser chunks, like LUTs and BlockRAMs, DSP slices,
sophisticated I/O etc.
Marketing might be tempted to claim inflated numbers, which would
create howling comments from the user community. Just don't dive into
this rat-hole !
Count instead flip-flops = Logic Cells, and then evluate the more
dedicated functions, like memories and multipliers/accumulators.
Peter Alfke, Xilinx Applications

Article: 126220
Subject: Re: simulating xilinx block ram with modelsim
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: Fri, 16 Nov 2007 23:32:36 -0800 (PST)
Links: << >>  << T >>  << A >>
On 16 Nov., 19:04, Duane Clark <junkm...@junkmail.com> wrote:
> u_stad...@yahoo.de wrote:
> > hi
>
> > ich have a problem with a project in ise and modelsim. i used the core
> > generator to create a single port block memory and instantiated it in
> > my design. now i want to do a behavioral simulation to verify my
> > design. i followed the instructions from the core generator help file.
> > ( i used the *.vho file to instantiate the block memory in my design
> > and downloaded the latest libraries from xilinx for model sim).
>
> Hopefully it won't be too annoying if I avoid actually answering your
> question, and instead suggest that you not use core generator to
> instantiate simple memories. You really should infer them. For example,
> yours might look something like:
>
>     type mem_array is array(0 to 511) of std_logic_vector(31 downto 0);
>     signal ram           : mem_array;
>
>     -- infer block RAM
>     wr_p: process(CLK)
>     begin
>        if rising_edge(CLK) then
>           if s_write_Strobe = '1' then
>              ram(to_integer(Address)) <= Data_in;
>           end if;
>        end if;
>     end process wr_p;
>     rd_p: process(CLK)
>     begin
>        if rising_edge(CLK) then
>           rd_addr_ram <= Address;
>        end if;
>     end process rd_p;
>     Data_Out <= ram(to_integer(rd_addr_ram));
>
> Notice that it is important to register the read address. This is
> required to infer block ram. If you don't do that, you will get LUT ram.

thanks for the hint how to infer block ram. i will try that out!
(why istn't it a good idea to use the core generator for simple block
memory? just beauty reasons?)
i still would be curious though what's wrong the way i tried it?!? can
you give me a hint there?

thanks
urban

Article: 126221
Subject: Re: Low cost FPGA w/serdes
From: lb.edc@telenet.be
Date: Sat, 17 Nov 2007 08:24:41 GMT
Links: << >>  << T >>  << A >>
Austin,

Does that mean Xilinx has something in the pipeline?

Luc

On Fri, 16 Nov 2007 07:57:00 -0800, austin <austin@xilinx.com> wrote:

>Colin,
>
>If you email me directly what size ECP2M part you are considering, and
>if you work with a distributor or FAE (who is your contact for Xilinx),
>I will have someone get back to you.
>
>Austin

Article: 126222
Subject: Re: VHDL language is out of date! Why? I will explain.
From: "HT-Lab" <hans64@ht-lab.com>
Date: Sat, 17 Nov 2007 09:31:34 GMT
Links: << >>  << T >>  << A >>

<psihodelia@googlemail.com> wrote in message 
news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com...
> Just look at its syntax. It is so archaic that anyone who had any deal
> with Python will just laugh. Try, say, to create a simple VGA
> controller, which is simply readable.

Ok, in that case start writing your VGA controller in Python, then go to 
http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an 
FPGA prototype board and report back to us how incredible simple and quick 
it was.... :-)

> Conceptually VHDL is not bad at all, it supports a lot of things, well
> in theory. But in praxis ...

Praxis....isn't that a DIY store in Holland?

Hans
www.ht-lab.com



>
> VHDL's Ada syntax is also very error prone. Instead of having all this
> archaic constructions and surplus operators, it would be much more
> productive just to start thinking about to create another hi-level HDL
> that has absolutely another conceptual design and simple syntax.
>
> Any good language should be so simple as possible and any program in
> this language should be short and clear. Such language should support
> associative arrays, that should help designing large FSMs; should
> support simple mechanism of type conversions and so on...
>
> Conceptually VHDL is not bad at all, it supports a lot of things, well
> in theory. But in praxis ...
>
> And don't forget about future FPGAs, about future SoCs, which will
> have integrated MEMS arrays, and other stuff. Try to understand how
> much complexer they are to be designed in so unproductive way using so
> primitive languages. 



Article: 126223
Subject: Re: VHDL language is out of date! Why? I will explain.
From: Thomas Rouam <thomas.rouam@laposte.net>
Date: Sat, 17 Nov 2007 02:15:47 -0800 (PST)
Links: << >>  << T >>  << A >>
> Any good language should be so simple as possible and any program in
> this language should be short and clear.

A reminder : VHDL is not a programming language, thus implying you do
not write a program with VHDL.

Article: 126224
Subject: Re: VHDL language is out of date! Why? I will explain.
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: Sat, 17 Nov 2007 11:25:23 +0100 (CET)
Links: << >>  << T >>  << A >>
In
news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com
timestamped Fri, 16 Nov 2007 10:27:59 -0800 (PST),
"psihodelia@googlemail.com" <psihodelia@googlemail.com> posted:
|-----------------------------------------------------------------------|
|"Just look at its syntax. It is so archaic that anyone who had any deal|
|with Python will just laugh. [..]"                                     |
|-----------------------------------------------------------------------|

Nonsense.

|-----------------------------------------------------------------------|
|VHDL's Ada syntax is also very error prone. Instead of having all this |
|archaic constructions and surplus operators,"                          |
|-----------------------------------------------------------------------|

I disagree that any of VHDL and Ada has error-prone syntax. Please
provide examples.

|-----------------------------------------------------------------------|
|" it would be much more                                                |
|productive just to start thinking about to create another hi-level HDL |
|that has absolutely another conceptual design and simple syntax."      |
|-----------------------------------------------------------------------|

Does reFLect not fit your needs. What about Lava or Hawk or APL or
Confluence or Verischemelog or any of the other supposedly high-level
terse languages which have been proposed for hardware (not that APL
had originally been proposed for hardware, but at least one paper for
hardware with APL had been published).


|---------------------------------------------------------------------|
|"Any good language should be so simple as possible and any program in|
|this language should be short and clear. Such language should [..]   |
|should help designing large FSMs; [..]                               |
|                                                                     |
|[..]"                                                                |
|---------------------------------------------------------------------|

So despite your claim that VHDL is out of date and your mention of
Python earlier, should your advocacy of state machines be construed as
evidence that you oppose object orientation?



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

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