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 62975

Article: 62975
Subject: Re: Implementing a very fast counterin VirtexII
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 11 Nov 2003 14:57:02 -0800
Links: << >>  << T >>  << A >>
I hope it is understood by now that all these complicated suggestions
are unnecessary or counter-productive (pun intended).
The whole counter, including its front-end is (and behaves like) a
completely synchronous counter, with all outputs properly available
about a nanosecond after each count clock tick.
Let's keep simple things simple!  :-)
Peter Alfke, Xilinx
======================
Francisco Rodriguez wrote:
> 
> "Erez Birenzwig" <erez_birenzwig@hotmail.com> escribi en el mensaje
> news:x_bsb.1057$%o4.34282@news.xtra.co.nz...
> > "Jim Granville" <jim.granville@designtools.co.nz> wrote in message
> > news:3FB1470C.F22@designtools.co.nz...
> > >  I think item 4) was to cover capture of the counter at any
> > > instant, and to cover the carry ripple.
> > >  I'm with Peter in questioning 4).
> > > Carry ripple is certainly long, but this is on the .D side, and
> > > determines the NEXT Clock delay. However any Capture is on the .Q side,
> > > and all Q's will be fully sync (no ripple adders )
> > >  Capture of both the prescaler, and long counter, can be clock
> > > syncronous, and does not need any enables.
> >
> > 4) is to cover the fact that once you enable the +1 on the long carry
> chain
> > you can't
> > sample it at the next clock cycle (It won't be ready by then), so you have
> > to latch the
> > previous value which is the new count value.
> >
> > The problem is that I must be able to sample the counter on every arbitary
> > clock cycle
> > therefore it must be glitch free.
> >
> It wouldn't be easier to always latch the low part?
> That is, you build a circuit with a latency of 1 cycle to load a, and then
> you have new a+1 result on every cycle.
> 
> Something like this:
> 
> process (...)
> begin
>    if rising_edge(clk) then
>       a_low <= a_low + 1;
>       if (a_low = x"FFFF") then
>          enable_high <= '1';
>      else
>          enable_high <= '0';
>      end if;
>      if (enable_high = '1') then
>         a_high <= a_high + 1;
>      end if;
>      late_a_low <= a_low;
>    end if;
> end process;
> 
> And the output is
> a <= a_high & late_a_low;
> 
> Of course, additional logic is needed to load the counter with a predefined
> value.
> 
> Once you get a (correct) value on a (by the load operation, not shown
> above),
> a_low maintains the low part of the _next_ count, while a_high has the high
> part of the _current_ count.
> That is why you need to delay a_low by a clock period.
> 
> I've tested a similar approach for a 64 bit counter running >200MHz on a
> virtex2 -4 speed grade
> although in my case the counter was built from 8 8-bit blocks.
> 
> Regards
>     Francisco
> 
> > The counter that I need doesn't require a clear but thanks for the
> thought,
> > it needs a load though.
> >
> > >
> > >  Capture and Clear (can be more application usefull), can
> > > be done in a single clock with a little more .D side logic.
> > >
> > >  Capture of fractional clocks, to push the time resolve better than
> > > 1/clock speed, is challenging, but looks possible in modern FPGA.
> > >
> > > -jg
> >
> >

Article: 62976
Subject: Re: Home grown CPU core legal?
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 11 Nov 2003 15:12:43 -0800
Links: << >>  << T >>  << A >>
I am convinced that a generic version would inevitably be inferior in
performance and/or price, compared to the dedicated one. I know that Ken
and Gran used many Xilinx-specific features when they designed
PicoBlaze and MicroBlaze. And I assume that the Altera guys were
operating in a comparable way when they designed Nios.
The generic ones will be the "worst of both worlds", unless you really
believe in clairvoyant synthesis.

Peter Alfke, Xilinx

Article: 62977
Subject: Re: FPGAs and DRAM bandwidth
From: "Erik Widding" <widding@birger.com>
Date: Tue, 11 Nov 2003 23:29:02 GMT
Links: << >>  << T >>  << A >>
"Fernando" <fortiz80@tutopia.com> wrote...
> The problem I'm looking operates on data sets ~16GB.  Computation
> takes about 0.5 sec, compared with ~2 sec required to download
> (@100MHz).  BRAM is used as cache for bandwidth.

Have you considered compressing one or all of your data sets?  If you can
compress the data sets, you will both reduce the bandwidth to the memory and
the size of the memory buffer.

We have seen vision applications where the data sets were binary templates,
and simple compression schemes offered a 10x improvement in memory
size/bandwidth, and only required a small decompressor to implement in the
FPGA. The engineering cost for developing the compression algorithm and
associated fpga logic was MUCH lower than the cost to layout and model a
multi-DIMM pcb.

Whether compression will help, all depends on what the data looks like.

Also, if you are passing over the same data multiple times, as you would if
you were using the same data to compute multiple results, it might benefit
you to compute multiple sets of results per pass of the data.  Depending on
your problem, it might make sense to look at solution with the goal of
minimizing the dataflow, rather than simplifying the computation.

We have an engineering mantra here, "the pins are the most expensive part of
the fpga".  This is not only due to the fact that the number of pins on a
die are proportional to the square root of the number of gates in a given
device family, but also due to the fact that lots of traces on a board add
to the cost of layout, verification, and fabrication.


Regards,
Erik Widding.

---
Birger Engineering, Inc. -------------------------------- 617.695.9233
100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com



Article: 62978
Subject: Re: Reverse engineering an EDIF file?
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Wed, 12 Nov 2003 10:44:02 +1100
Links: << >>  << T >>  << A >>
On Tue, 11 Nov 2003 18:10:33 +0100, rasti123@eunet.yu wrote:

>Dear Allan,
>
>Thank you for your answer. When you say binary format, what precisely
>do you mean? On the other hand I was thinking of using Xilinx NGC
>netlist instead of EDIF. Do you think this would help? I have read
>that NGC is a encrypted netlist format, and if there is no easy way of
>converting NGC to EDIF, than maybe it would be a solution to my
>problem.

NGC would be better than EDIF.

You will probably also have to ship something that will allow your
customers to simulate the core.  This is typically done by shipping a
pre-compiled library (to suit whatever simulator your customers use)
with an NDA (non-disclosure agreement).

Regards,
Allan.

Article: 62979
Subject: Re: Home grown CPU core legal?
From: bpride@monad.net (Bruce P.)
Date: 11 Nov 2003 18:28:22 -0800
Links: << >>  << T >>  << A >>
> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. 

But, there's nothing like rolling your own for fun/educational
purposes and then having something useful at the end of it all.  I
think it would also be easier to add new features and enhancements to
your own design since the code was developed in your own way of
thinking and coding style.  In the end, maybe it will just be "yet
another RISC core" on opencores.org, but at least it's yours and
you'll have a good understanding of it's capabilities...even if all it
can do is blink an LED!

BP

Article: 62980
Subject: Re: 0.13u device with 5V I/O
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 12 Nov 2003 03:06:46 -0000
Links: << >>  << T >>  << A >>
>You can use Virtex or Spartan-II to interface with 5V PCI bus
>and retain full compliance per the specification.  You can use
>any of our devices, even Spartan3 and Virtex2Pro, with the 5V
>PCI bus, but you need some level translators.  This is certainly
>a functional solution (I've tested it personally) but it is not
>compliant with the letter of the specifications.

Do you have any suggested parts for the level translators?  I know
about the IDT QuickSwitchs.

>The specifications are pretty clear that you are allowed only
>one component, and that is your "PCI component" and all bus
>signals must attach directly to that one component.

I don't really care about the rules just to check off the
boxes.  I'm willing to cheat if I can convince myself (and
some friends?) that the total system will work solidly.

There are two parts to that.  One is in limited cases, say one
fewer card on the bus.  The other is in any configuration legal
under the specs.

How far did you bend the rules?  How much testing/Spicing did
you do?

Do modern FPGAs have a low enough pin capacitance so that the
added capacitance of something like a QuickSwitch fits the old
rules?  Or are they fast enough to go through an honest repeater
type chip so there is only one bus load?

Mostly, I'm just curious.  If/when I get enough time, I'd like
to build a hobby priced board that I can plug into something like
PCI.  For now, that's old 33 MHz 5V PCI.  Spartan-II seems like
the best bet.  But the clocking in newer chips is attractive.
If there is a solid way to connect them to old PCI, I'd add that
to my list of chips to consider.

Maybe if I wait a bit longer low cost systems will be readily
available that have real 3V PCI slots. :)

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


Article: 62981
Subject: Re: How to visit the files in CF cards
From: ramntn@yahoo.com (ram)
Date: 11 Nov 2003 21:18:56 -0800
Links: << >>  << T >>  << A >>
hi
 read the answer database record no: 17165 and 14456 from xilinx.
bye
Ram

Article: 62982
Subject: Re: Home grown CPU core legal?
From: H. Peter Anvin <hpa@zytor.com>
Date: 11 Nov 2003 21:33:17 -0800
Links: << >>  << T >>  << A >>
Followup to:  <3FB15BB3.5B87@designtools.co.nz>
By author:    jim.granville@designtools.co.nz
In newsgroup: comp.arch.fpga
>
> H. Peter Anvin wrote:
> > 
> > I have no way to know how this is turning out.  My current goal is to
> > make sure it implements in < 1000 LEs on Cyclone, without using
> > blockRAM for the register file.
> 
>  Isn't some form of BlockRAM a defacto standard on all 
> 'consider for new design' FPGAs - so not using that would 
> restrict your options ?
> 

Some form thereof, yes, but I tend to run out of blockram a lot faster
than running out of LUTs.  Note that it's not that I'm saying you
couldn't use it, I'm saying I want to be at < 1000 LE without using
blockram.  About 300-400 of that would be replacable with a blockram.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 62983
Subject: Re: Home grown CPU core legal?
From: H. Peter Anvin <hpa@zytor.com>
Date: 11 Nov 2003 21:34:11 -0800
Links: << >>  << T >>  << A >>
Followup to:  <3FB16CEB.C46327DE@xilinx.com>
By author:    Peter Alfke <peter@xilinx.com>
In newsgroup: comp.arch.fpga
>
> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. I know that Ken
> and Gran used many Xilinx-specific features when they designed
> PicoBlaze and MicroBlaze. And I assume that the Altera guys were
> operating in a comparable way when they designed Nios.
> The generic ones will be the "worst of both worlds", unless you really
> believe in clairvoyant synthesis.
> 

Of course.  But it would have the advantage that it could run on
either.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 62984
Subject: About the purchase of XCF01s
From: atif@kics.edu.pk (Atif)
Date: 11 Nov 2003 21:58:53 -0800
Links: << >>  << T >>  << A >>
I want to purchase fifty Xilinx Platform Flash XCF01S online. It is
not available at Avnet and NuHorizons and I am unable to find any
other sales representative to purchase it.
Can anyone please guide me from where can I purchase it? The order may
be shipped to Pakistan or America.
 
Regards
Atif 
Research Associate

Article: 62985
Subject: Re: Arithmetics with carry
From: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
Date: Wed, 12 Nov 2003 06:44:49 GMT
Links: << >>  << T >>  << A >>

"H. Peter Anvin" <hpa@zytor.com> wrote in message
news:borkpf$p7v$1@cesium.transmeta.com...
> Followup to:  <nZ%qb.101301$mZ5.680324@attbi_s54>
> By author:    "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu>
> In newsgroup: comp.arch.fpga
> >
> > This is true, except for generating the flags on the final add.  Well,
you
> > can either generate all the flags, or only the signed or unsigned flags.
> > For the intermediate adds only the carry, or lack of carry, from the
high
> > bit is important.  To detect signed overflow or underflow (more negative
> > than can be represented) requires comparing the carry into and out of
the
> > sign bit.

> It depends.  Some architectures define CF=0 to mean borrow-out from a
> subtraction.  Under that definition (used by the PDP-11, for example),
> SUB is equivalent to NEG + ADD (a desirable property in my opinion);
> under the "other" definition (as used by among others Intel processors
> ever since the 4004), SUB ends up producing the opposite carry from
> NEG+ADD.

For unsigned arithmetic, or all except the most significant word of
multiword signed arithmetic, yes, carry is the complement of borrow.
Somewhere back in the thread I wrote that.  For the most significant word or
only word for signed arithmetic overflow/underflow must be computed
differently.

-- glen




Article: 62986
Subject: Re: Logic implementation in SRAM/OTP FPGAs
From: Mario Trams <Mario.Trams@informatik.tu-chemnitz.de>
Date: Wed, 12 Nov 2003 08:25:28 +0100
Links: << >>  << T >>  << A >>
Hi Mark,

> I have a question concerning the logic implementation techniques of
> SRAM FPGAs and OTP FPGAs.
> 
> Logic in Xilinx FPGAs is implemented in LUTs. Logic in Quicklogic
> FPGAs is implemented in a multiplexer structure.
> 
> Why does these two programming technologies use different techniques
> to implement logic ?

You mean because Quicklogic uses an OTP-Solution and Xilinx devices
are reprogramable?

I don't know the Quicklogic devices in detail, but I guess they are
using so-called Antifuse Technology.

One reason for such solutions is speed. In an SRAM/EEPROM-based 
device the junctions of the interconnect are made by transfergates 
and/or multiplexers. This costs time. In antifuse technology, 
connections are created more or less statically during programming.

Another advantage of antifuse over the other technologies is that 
you do not need to have a memory cell that says whether some
switch is "on" or "off". That is, you save chip area which makes 
it cheaper for production. Less power is needed as well.

The reason why logic is implemented in a different manner might
be induced by the basic technology. In an SRAM-based device it
is perhaps more efficient to go the LUT-way. Another interesting
side-effect here is that one can use the LUTs as small RAM-blocks
in his design. 

While a LUT could be made well out of antifuse cells, a multiplexer
structure yields perhaps to better speed characteristics. But I'm
not the expert here.   

Regards,
Mario


Article: 62987
Subject: Re: Transforming vector position to binary value
From: andres.vazquez@gmx.de (Vazquez)
Date: 11 Nov 2003 23:30:46 -0800
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> wrote in message news:<3FB118A8.2B5D02BF@xilinx.com>...
> As I had posted a while ago, the Virtex-II BlockRAM is surprisingly
> efficient as a priority encoder.
> Use one BlockRAM as a dual-ported 4K x 4 ROM.
> Feed 12 inputs as address to one port, and the next 12 bits as address
> to the other port. That gives you two sets of 4 outputs defining the
> priority-encoded position in the two 12-bit inputs separately.No problem
> with multiple 1s!  Should work at 200+ MHz, but note that the BlockROM
> is a synchronous device, it operates on a clock edge!
> The remaining 8 inputs and the combining of the eight BlockROM outputs
> can be done the conventional way, but might also be done in another
> BlockROM (generating a second clock latency!)
> Peter Alfke, Xilinx Applications

Dear Mr Alfke,

thank you for your proposal.
Do you have some application note in which the connection of the ROMs is explained?
How many ROMs are used at all? As I understand you there are used four ROMs?
Do you mean with "to one port" the write address port and with "to other port"
the read address port?

Thank you for your help.

Best regards
A. Vazquez
G&D System Development

Article: 62988
Subject: Re: XILINX Foundation Series 3_1i Problem with installation...
From: " " <zlogic@udm.ru>
Date: Wed, 12 Nov 2003 11:32:39 +0400
Links: << >>  << T >>  << A >>

"Morten Leikvoll" <m-leik@online.nospam> /  
: news:d28sb.5758$mf2.78962@news4.e.nsc.no...
> " " <zlogic@udm.ru> skrev i melding
> news:boqoau$22r0$1@hq.mark-itt.ru...
> > Hi, ALL.
> >
> > Problem with installation subj.
> > In time installation  the program java.exe is under abnormal condition
> > finished.
> > It happens in WIN 98 and in WIN XP. Processor - CELERON 1700.
> > What to do, help me, please.
>
> My weak memory seem to remember something about java and this problem...
You
> needed the latest java runtime environment to install this?

Hello.
I have instslled JRE 1.3. All works. However only under WIN98.
And me is necessary that all worked under WIN XP.
Can I it make? And how?

Beforehand thank.



Article: 62989
Subject: Re: Layout examples
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 12 Nov 2003 07:37:55 -0000
Links: << >>  << T >>  << A >>
>Showing my age here....  when I was routinely designing PCBs
>around 8-10 years ago, I was often given a very hard time by
>assembly subcontractors if I put vias inside an SMD pad - they
>used to complain about solder hogging or some such manufacturing
>folklore.  What are the up-to-date design rules for putting vias
>in or very close to a pad?

That was the party line many years ago.  The problem is that
the solder dives into the via (surface tension) so you don't
have as much solder left to make contact with the part.

I think it's reasonably common now.  It's another tool in the
struggle to reduce the inductance on bypass caps.

Check with your assembly house.  Sometimes they fudge the
hole size in the stencil for the solder paste, or use a
thicker sheet to make the stencil.

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


Article: 62990
Subject: Re: XST Timing report
From: muthu_nano@yahoo.co.in (Muthu)
Date: 12 Nov 2003 00:43:17 -0800
Links: << >>  << T >>  << A >>
"Anil Khanna" <anil_khanna@mentor.com> wrote in message news:<3f906bdc$1@solnews.wv.mentorg.com>...
> Its all in the options.
> 
> Right Click "Post-PAR Static Timing" and choose your report options.
> 
> For analyzing specific paths - launch the "Timing Analyzer".
> 
> Its much better in 6.1!
> 
> "Muthu" <muthu_nano@yahoo.co.in> wrote in message
> news:28c66cd3.0310122152.8de177d@posting.google.com...
> > Hi,
> >
> > I am using ISE5.1i...XST synthesis tool.
> >
> > At the end of synthesis, XST generates defualt timing report for 1 or
> > 2 paths.
> >
> > How can i generate a timing report after synthesis for more than 100
> > paths?
> >
> > ie., as like .twr after Place and route.
> >
> > And How can i measure the time dealy between 2 specific points...
> > Points could be FF,mux or any logic
> >
> > Thanks in advance.
> >
> > Regards,
> > Muthu

Post PAR can only be run with the Map results Right. But i need to
take the report from XST itself?

Article: 62991
Subject: Re: Layout examples
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 12 Nov 2003 08:49:19 +0000
Links: << >>  << T >>  << A >>
"John_H" <johnhandwork@mail.com> writes:

> Great comments, Martin.
> 

Thanks!

> A point I'd add to the original poster's concerns about the "swiss cheese"
> ground and power planes you can get with too many vias, some numerical work
> has shown that - at least for closely spaced ground/power pairs - the added
> impedance from the swiss cheese under a BGA package (much worse than a QFP)
> is sub-nanohenry.  Don't worry so much about the holes in the plane, worry
> about the spacing between the planes (smaller is better, 4 mil perhaps?) and
> good decoupling cap attachment.  Two vias are often used on each end of the
> decoupling caps in high speed designs to halve the impedance to the ground
> and power planes.  The "*very* short tracks" is a noteworthy comment as
> well; it's easy to make a stiff decoupling cap a bit soft by adding a little
> track between the pad and via(s).
> 

Another trick I used that I forgot to mention is to populate groups of
caps in a line with one large "pad" connecting them all.  Through that
pad go 2-3 vias per capacitor to reduce inductance.  However, as the
illustrious Lee Ritchey would point out I have no science to back up
any claim that this is a "good" way of doing things... it feels
right.  At some point I intend to do some simulation and maybe even
(gasp!) some measurements...

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 62992
Subject: Re: Layout examples
From: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
Date: Wed, 12 Nov 2003 09:45:12 -0000
Links: << >>  << T >>  << A >>
> A point I'd add to the original poster's concerns about the "swiss cheese"
> ground and power planes you can get with too many vias, some numerical
work
> has shown that - at least for closely spaced ground/power pairs - the
added
> impedance from the swiss cheese under a BGA package (much worse than a
QFP)
> is sub-nanohenry.  Don't worry so much about the holes in the plane,

Although watch out for accidentally created slots in the ground plane.

If you're not sharing vias for decouplers to keep impedances down and you've
a lot of them you can end up creating slots in the ground plane if you've
many of them near each other. This can be easily done if your decouplers are
neatly arranged on the same X/Y coordinates per side.

Slots are very bad news for high speed signals.

Just something to be aware of.


Nial
------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk



Article: 62993
Subject: Re: FPGAs and DRAM bandwidth
From: fortiz80@tutopia.com (Fernando)
Date: 12 Nov 2003 02:53:22 -0800
Links: << >>  << T >>  << A >>
Hi, thanks for your reply.

> Have you considered compressing one or all of your data sets? 

I will use compression for the output stream (results).  

For main memory I'm using floating-point, so I'd need lossless
compression.  I've never implemented any compression modules myself,
but I don't think it can be done in realtime for the amount of data I
need. I will gladly accept opinions from the group on this.
 
> Also, if you are passing over the same data multiple times, as you would if
> you were using the same data to compute multiple results, it might benefit
> you to compute multiple sets of results per pass of the data.  

I am already doing something like that. Of course, limited by the
amount of RAM inside the chip.  There is also a fundamental time
dependence in my algorithm, but we got around that parallelizing each
step in between.

> We have an engineering mantra here, "the pins are the most expensive part of
> the fpga".  This is not only due to the fact that the number of pins on a
> die are proportional to the square root of the number of gates in a given
> device family, but also due to the fact that lots of traces on a board add
> to the cost of layout, verification, and fabrication.

I completely agree, that's why I'm a little inclined towards serial
solutions, but seems like those are not ready yet...at least for
memory.

Article: 62994
Subject: None
From: "#YU WEI#" <yuwei@pmail.ntu.edu.sg>
Date: Wed, 12 Nov 2003 20:03:16 +0800
Links: << >>  << T >>  << A >>
Thanks. However, I still have problems. The board can boot up with the =
generated .ACE file which is in CF card. But the other data files can =
still not be visited. How to let FPGA visit the data files in CF card?=20

Regards,
YUWEI

-----Original Message-----
From: ram [mailto:ramntn@yahoo.com]=20
Posted At: 2003=C4=EA11=D4=C212=C8=D5 13:31
Posted To: comp.arch.fpga
Conversation: How to visit the files in CF cards
Subject: Re: How to visit the files in CF cards

hi
 read the answer database record no: 17165 and 14456 from xilinx.
bye
Ram


Article: 62995
Subject: Re: Are modules that are not floorplanned still functional?
From: merlin_jiang@hotmail.com (Jiang)
Date: 12 Nov 2003 05:23:48 -0800
Links: << >>  << T >>  << A >>
Sorry, Erez and FPGA friends,

Thank you for your advices. After making sure that OBUFs were instantiated
properly, I further found out that I didn't check all my external pin
connectors on the FF1152 board, which were welded by some company. I was so
lucky (?) that I happened to use the specific external pin that was not
well-connected to the GCLK pad on the board. Hence my clock was fed to that
pad in vain. Everything went fine after I assigned the clock to another GCLK
pad.

Sorry for this result, but also thank you for your help :-)

Regards,
Merlin

"Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message news:<NYasb.998$%o4.33145@news.xtra.co.nz>...
> I found out that the DDR FF is optimized out if you do not connect
> it to a OBUF of some kind.
> If you use a synthesis tool you might want to declare the pin as output
> of some kind (Select IO), or just instantiate the OBUF directly in the HDL.
> 
> Erez.
> 
>

Article: 62996
Subject: Trying to digitize video with CTT differential input, but webpack wont't cooperate...:-)
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Wed, 12 Nov 2003 13:59:20 GMT
Links: << >>  << T >>  << A >>
I thought just for fun let me try to digitize some video
using the input comparator.
I am stuck with 3.3 V I/O on Spartan 2 because of the
proto board...
So then CTT works on 3.3 V and 1.5 V rteference, should do something
with 1.5 V signal...

But now the problem:

ERROR:Place:1747 - The IOB video_in is locked to site P110 in bank 3. This
true

   violates the SelectIO banking rules. Other incompatible IOBs may be locked to
   the same bank, or this IOB may be illegally locked to a Vref site. Please
? of cause they may be, but they are not...

   consult the SelectIO application node.
where would that be?

ERROR:Place:993 - Due to Virtex SelectIO banking constraints, the IOBs in your
   design cannot be automatically placed.
It's a Spartan 2, not a Virtex...!

I did:
// For the r2r ladder that drives the Vref is here:
OBUF_CTT da0(.I(da_output[0]), .O(da_out[0]) );
OBUF_CTT da1(.I(da_output[1]), .O(da_out[1]) );
OBUF_CTT da2(.I(da_output[2]), .O(da_out[2]) );
OBUF_CTT da3(.I(da_output[3]), .O(da_out[3]) );
OBUF_CTT da4(.I(da_output[4]), .O(da_out[4]) );
OBUF_CTT da5(.I(da_output[5]), .O(da_out[5]) );
OBUF_CTT da6(.I(da_output[6]), .O(da_out[6]) );
OBUF_CTT da7(.I(da_output[7]), .O(da_out[7]) );

// The video is on the other side of the comparator...
IBUF_CTT vidin(.I(video_in), .O(inbit) );

In the constraints file the ports are specified as normal.
All these pins (and no other) are on bank 3.
So what do I do wrong?

Must be some silly thing...
Simulation works fine, 8 bits video, 100 MHz clock, should at least do something..

Article: 62997
Subject: Need to verify an ATA/ATAPI-6 device
From: Fred <none@nowhere.no>
Date: Wed, 12 Nov 2003 14:18:52 GMT
Links: << >>  << T >>  << A >>
Hi

I'm looking for  way to verify an ata/atapi-6 design. I could write
one myself, but that would probably take a year or two, and that's not
woth the effort.

I need it to verify both functionality and timing of a device that
shall be plugged onto the IDE bus, between the host and the device.

So far I have found a solution from Yogitech (www.yogitech.com)
that more or less does what I want, but only for ATA/ATAPI-4.

I've searched the net, but haven't found much in addition to Yogitech.

Do any of you know of anything that could be of interest, please emali
me at frode at HOTEL DELTA DELTA dot NOVEMBER OMEGA, or
post your reply here. NB: Since I'm crossposting this accross many
groups, and haven't got a "reply-to" field, I'd of course be happy if
the replies got to me per email ;-)

-Frode, Norway.

Article: 62998
Subject: Re: Home grown CPU core legal?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 12 Nov 2003 10:02:03 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> I am convinced that a generic version would inevitably be inferior in
> performance and/or price, compared to the dedicated one. I know that Ken
> and Gran used many Xilinx-specific features when they designed
> PicoBlaze and MicroBlaze. And I assume that the Altera guys were
> operating in a comparable way when they designed Nios.
> The generic ones will be the "worst of both worlds", unless you really
> believe in clairvoyant synthesis.
> 
> Peter Alfke, Xilinx

"Clairvoyant Synthesis", now that sounds like a good product!  Is there
a startup somewhere working on that? 

I can see product announcements touting the new FPGA CS that eliminates
the need for product planners, designers and even testing as it would
already know that the design was ready for production!  No specs to
write, no coding to compile and even simulation could be skipped.  Just
think of the design you want and out pops a bit file.  Boy, what will
they think of next?  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 62999
Subject: Re: Home grown CPU core legal?
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 12 Nov 2003 10:06:11 -0500
Links: << >>  << T >>  << A >>
"Bruce P." wrote:
> 
> > I am convinced that a generic version would inevitably be inferior in
> > performance and/or price, compared to the dedicated one.
> 
> But, there's nothing like rolling your own for fun/educational
> purposes and then having something useful at the end of it all.  I
> think it would also be easier to add new features and enhancements to
> your own design since the code was developed in your own way of
> thinking and coding style.  In the end, maybe it will just be "yet
> another RISC core" on opencores.org, but at least it's yours and
> you'll have a good understanding of it's capabilities...even if all it
> can do is blink an LED!
> 
> BP

When I was in school we worked on a paper design of a microcoded
processor as a teaching tool.  We had homework on it and had to design
new features on our exams.  I even had a question about it on my Masters
comprehensive exam.  I approached my professor about designing a
simulation of it to run on the Univac mainframe for the undergrad
students to learn from.  But I guess I was ahead of my time as he did
not see the value in that.  Or maybe he had the foresight to see the
complications it might create :) 

I guess this is a pretty common thing at Universities now.  All they
have to do is get you a FPGA design package with a simulator.  


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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