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 137550

Article: 137550
Subject: Re: FPGA granularity
From: rickman <gnuarm@gmail.com>
Date: Wed, 21 Jan 2009 22:35:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 1:00=A0am, whygee <why...@yg.yg> wrote:
> Hi :-)
>
> rickman wrote:
> > On Jan 21, 6:24 pm, whygee <why...@yg.yg> wrote:
> >> rickman wrote:
> >>> They do offer adders. =A0Each bit uses one LUT. =A0That seems pretty =
cheap to me...
> >> I meant 16-bit or 32-bit adders.
> >> How many 4-LUTs does it take to add 32 bits _fast_ ?
> >> Not 32...
>
> > I don't know just how fast a 32 bit adder from 32 LUTs will run and I
> > don't know how fast a 32 bit hard adder will run. =A0I do know that the
> > long path is the carry chain and this has been highly optimized in
> > most FPGAs. =A0Do you know numbers?
>
> I don't, and the fact that Actel uses a completely different system
> does not help me. I have struggled to get a decently fast 32-bit add/sub
> unit on A3P. There is no "fast carry chain" so the price in logic
> "tiles" is quite high. This makes me regret that no dedicated
> addition "blocks" are included. Along with some SRAM and glue
> (latch/registers and Muxes), addition is certainly the function
> that I use most.
>
> I'm interested to read and compare numbers from different FPGA families
> for 8, 16 and 32-bit wide adders (latency, area cost etc.).

Xilinx used to publish numbers for a few basic functions in their data
sheets, but I don't see that in the current ones.  But I can tell you
that the propagation delay for the carry chain is on the order of 0.1
to 0.2 ns per bit.  The input to the carry chain and carry output take
a few ns, but the incremental delay per bit is very low.  Odd that
they don't even publish that number in the current data sheet.  Altera
and Lattice are comparable.  In fact, the Lattice parts use a *very*
similar design as they have the rights to many of the Xilinx basic
patents from buying the Lucent Orca line which used the patent rights
Lucent bought from Xilinx as part of a second source agreement.

Rick

Article: 137551
Subject: Re: FPGA granularity
From: Antti <Antti.Lukats@googlemail.com>
Date: Wed, 21 Jan 2009 22:59:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 2:43=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 21 Jan 2009 11:09:45 -0800 (PST), Antti
>
> <Antti.Luk...@googlemail.com> wrote:
> >On Jan 21, 8:14=A0pm, whygee <why...@yg.yg> wrote:
> >> Brian Drummond wrote:
> >> > The other fine grained one was of course Xilinx's own XC6200, origin=
ally
> >> > developed in Edinburgh by Algotronics (bought out by Xilinx).
>
> >hm,
>
> >maybe i should sell my
>
> >ERA6000 ICE pod on ebay?
>
> >yes that the plessey/pilkington sea of gates FPGA
>
> >Antti
>
> Heh, the Plessey ERA. I was introduced to that about the end of the
> Rekursiv project; and it started me thinking about reconfigurable
> computing.
>
> Until then, I had dismissed SRAM based FPGAs as a dumb idea (like a PAL
> or Altera EPLD that forgets what it is when the power fails; and SLOOOW
> besides!)
>
> Pilkington (a glassware company!) sold it to Plessey, and Motorola, and
> who else? I thought the Algotronics/Xilinx was an independent
> development but I can't be certain...
>
> Don't sell the ICE pod ... I expect my Inmos T800 eval board is worth
> even more... (I never did get a Rekursiv though)
>
> - Brian

Hi Brian

thanks for clarifying, I assumed the ERA6000 product was from PLESSEY
and that Pilkington was responsible for the SOFTWARE for it.

ok, i actually did not think about the roots of the design/
architecture.

what i was sure back then, and what i still think today is that even
the ERA6000 (sea of nand gates) could have survived and have its
market,
but the lack of the tools an their ridiculous price did make it die.
they did doom it to die.

I got a full development tools system, it included 2 lpt dongles,
disks
manuals, the ICE pod, and passwords to part of the tools, the password
to the rest was supposed to be known later, if it well the software
never
got ready.

the dev pacage did cost i think 57.000 Finnish Mark, what was hell
of a lot of money back then. And no, i did not pay that amount, i just
got it for free. i helped to clean the office by taking it away...

making the sea of gates chips cheap as dirt and publishing full
fabric specifation (very simle actually) and i think there would
habe been some group/company doing own tools and using that silicon.

eh, well the sea of gates FPGA may get a secon life in optical form?
who knows.

and no, i am not selling my ERA6000 pod ;)
its pretty nice looking thing

Antti

















Article: 137552
Subject: Re: How to add some SDRAM to a FPGA board ?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 22 Jan 2009 07:11:30 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip, someone wrote)

>> adding capacity and reducing impedance is not an issue,
>> I can use larger diameter wires at will
>> and my collection of capacitors is still growing :-)
 
> The wire diameter has very little to do with the impedance.  

Wire diameter is related to inductance, though.
And inductance is related to impedance...

> Any capacitor you use has impedance.  You can see this 
> very clearly if you look at the impedance-frequency 
> curves for the parts.  The resonant frequency tells you the 
> frequency at which the capacitive and inductive impedance 
> are equal.  As the frequency continues to increase
> the impedance rises.  For a high speed design the impedance of the cap
> becomes significant at frequencies that are important.  That is why
> power planes are used.  They provide a low impedance at frequencies
> into the GHz range.

-- glen

Article: 137553
Subject: Re: config prob with spartan3
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Thu, 22 Jan 2009 08:14:07 +0100
Links: << >>  << T >>  << A >>

"Jan Bruns":
>> Everything looks like I'm just missing the startup to start
>> (DONE stays low, according to these status-registers).
>> .. 
>> There's an Answer record in the xilinx database telling
>> this problem was a known issue with ISE9.4 (but for 
>> Spartan3a/an), but I'm also not fully sure if I was
>> probably using some bitgen-switch when the problem 
>> disappeared.
 
> http://www.xilinx.com/support/answers/22255.htm
 
> Does anyone have the same problem with the actual
> IMPACT 10.1.03 ?

Luckily, my fpga board exports a combination of (M0+M2) MODE
signals to the programmer, so I only needed to put
a soldering iron on the programmer board to put the
fpga into jtag-only mode. This solved the problem.

Gruss

Jan Bruns



Article: 137554
Subject: Re: ML505 - How to read/write SRAM?
From: Matthias Alles <REMOVEallesCAPITALS@NOeit.SPAMuni-kl.de>
Date: Thu, 22 Jan 2009 08:45:20 +0100
Links: << >>  << T >>  << A >>
Hi!

You just have to look where in the processor's memory map the SRAM is
located (in the EDK GUI). Then you just have to write or read from
addresses in that range. The address decoder will tell the SRAM
controller, that these accesses are meant for the SRAM memory.

Matthias

charlie78 schrieb:
> Hi all,
> I'm an Italian student, I'm new in fpga and Microblaze implementation.
> I saw many starting tutorials about ML505 Xilinx Platform and usa of
> Xilinx Platform Studio 10.1 and EDK.
> In these tutorials I did not found any example of reading and writing
> operation of the SRAM.
> My code reside in BRAM and I would like to try to store some values in
> SRAM.
> By BSB I implemented SRAM in my system connected to microblaze by SPLB and
> xps_mch_emc.
> Now:
> What are the instructions to read and write this memory?
> It's a simply question but I can't find any answer... please help me.
> Thanks (I apologize for my bad english)
> 
> Daniele
> 
> 

Article: 137555
Subject: Re: ML505 - How to read/write SRAM?
From: secureasm@gmail.com
Date: Thu, 22 Jan 2009 00:11:08 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Daniele,

> What are the instructions to read and write this memory ?

There are 2 simple instructions to read / write directly to a memory
address:

Read:  "XIo_In32".
Write: "XIo_Out32".

check "..\EDK project\microblaze_0\include\xio.h".

Also controls the API of SRAM (XPS Multi-Channel External Memory in
"IP Catalog"), with the right button on the block in SRAM EDK.
"Driver" -> "View API Documentation".

I'm Italian.

Kappa.


Article: 137556
Subject: Re: How to add some SDRAM to a FPGA board ?
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 22 Jan 2009 01:16:39 -0800 (PST)
Links: << >>  << T >>  << A >>
I'm not sure if you just want a module with 2.54mm pins or a
development board with SDRAM but we can offer both.

For a module we dil header style SDRAM modules. These are out of stock
just now but should be available in a few weeks. These modules are
aimed at our Raggedstone range range of boards.

In the development board area we have Darnaw1 http://www.enterpoint.co.uk/m=
oelbryn/darnaw1.html
which currently has 128Mbit SDRAM on as standard but we have a batch
going through shortly where we are looking at increasing the SDRAM and
SPI Flash sizes on the XC3S1600E versions.

There is also a new product coming that is very much aimed at
microprocessor applications based in FPGA and that will have 256Mbit
SDRAM in a X32 organisation and has capability to go to 512Mbit. I'm
expecting to announce this properly in 3-4 weeks time when have run
some tests on it.

John Adair
Enterpoint td.


On 22 Jan, 02:15, whygee <why...@yg.yg> wrote:
> Hi Rick !
>
> this is the rest of the discussion from comp.arch.embedded.
>
> rickman wrote:
> > Have you considered a different family? =A0There is a $40 Xilinx eval
> > board available from Avnet. =A0But it still does not have ram. =A0That
> > will likely be a $200 or higher board.
>
> I'm already satisfied with what I got from Actel
> ("it works and has what i want")
> and I bet that any issue I'll have with SDRAMs
> will not be related to the FPGA family itself,
> but rather, come from my misunderstanding of the
> SDRAM's datasheets or something stupid like that...
>
> I have a 2nd hand Altera (NIOS) board (without support tools)
> and a pair of XCV400 waiting for a suitable PCB, and I look around
> for other vendors. But I don't want to be diverted/distracted from
> actual development itself : either I spend my time and money
> evaluating vendors, or I do something with what I already have...
> Guess which one eventually brings money home :-)
>
> > The only hard part is the wiring. =A0A decoupling cap will need to be
> > wired directly between the power and ground pins.
>
> of course. I just got some really cool ultra-miniature high-capacity cera=
mic
> capacitors and that's where they are suitable :-)
>
> > =A0Actually, this may
> > be a show stopper. =A0The low impedance of the ground plane and its
> > capacitance helps a lot to reduce the high freq spikes on the power
> > bus. =A0By wiring power it is possible to add too much inductance and
> > the cap may not be able to provide a low enough impedance.
>
> adding capacity and reducing impedance is not an issue,
> I can use larger diameter wires at will
> and my collection of capacitors is still growing :-)
>
> > As long as your wires are very short (both on board and off board),
> > less than 2" for example, the SI and clock timing will not be
> > significant issues. =A0To mitigate the output delays on the FPGA you
> > should register all signals in the IOBs.
>
> of course. I always latch outputs.
>
> >> Also my designs don't clock faster than 100MHz, and I thought
> >> that it's possible to downclock SDRAM chips, provided the cycles
> >> are adjusted.
>
> > That will work. =A0You can clock an SDRAM as slow as you want to some
> > point. =A0You do have to provide a periodic refresh cycle unless you ar=
e
> > doing that in software. =A0But the clock speed won't have much to do
> > with the SI and power decoupling issues.
>
> My fear is that my dear 475 'scope is limited to 200MHz so I could
> miss things. But that will come later, when going "high speed" on PCB,
> since the SDRAM initialisation dance in itself looks scary...
> I'll probably have to finish my small CPU core before I go further,
> since a programmed sequence will spare me the effort to design
> a (scary) FSM.
>
> <afterthought>
>
> And if the SDRAM can be clocked as slowly as one wants,
> then I could even "prototype" the SDRAM interface
> with "bitbang"-like software, and then move slowly from
> soft to VHDL as it starts to work...
>
> >>> You also need an SDRAM controller inside the FPGA, parameterised to y=
our
> >>> particular SDRAM chips.
> >> Sure, I'm looking at datasheets and VHDL "cores" too.
>
> >> Should this discussion continue on comp.arch.fpga ?
>
> > That would be a good venue.
>
> so here we go.
>
> > I have not found a good venue for discussing FPGA CPU cores.
>
> Note that the request is (was) independent of YASEP,
> I've just unearthed some /old/ DSP projects that were
> still out of my reach 6 months ago.
> However it seems that I'll need at least a small CPU
> to get the thing working (both the SDRAM and the DSP).
> This encourages me to continue with YASEP :-)
>
> > If you are interested in MISC processors,
> > comp.lang.forth is a good place.
>
> :-)
> However YASEP is not MISC, it's just "small" :-)
> But Forth and the likes are definitely worth caring.
>
> >> Furthermore, I believe that since I'll have to use SDRAM anyway
> >> one day, then I should hit the bullet and go forward.
> > You can get the Altera softare for free just like the Xilinx software.
>
> I'm investigating that but I don't give Altera high priority,
> since they force me on Windows. Unless someone thinks that
> "or else pay $2500 for your linux license" means something else.
>
> OK I confess that I use Actel's suite under Vista (ouch)
> but at least there is still the possibility to use the
> Linux version (in some ... way). I'm investigating it now...
>
> > =A0The programming cable is not a lot of money.
>
> I consider making my own,
> once I have time and all the SW issues solved.
>
> > =A0I would bite
> > the bullet and use that for a first pass. =A0Wiring an SDRAM chip is
> > likely to delay you some considerable time.
>
> I have to balance several things :
> =A0 - the time and cost of acquiring, installing, configuring, using, mas=
tering
> =A0 =A0 yet another vendor's tools, and getting around its specific gotch=
as
> =A0 - the potential dangers of using a single vendor's products
> =A0 - the actual usefulness, price, and reward of each particular project
> =A0 =A0 =A0(and the SDRAM is not a necessity now).
>
> It looks like a "dirty hack" with 25mil wires from IDE cables
> is the fastest, cheapest and easiest way now.
> Maybe it won't work but it will probably help me
> understand and get a first foot in the sh^Wmatter...
>
> Regards,> Rick
>
> yg
>
> --http://ygdes.com/http://yasep.org


Article: 137557
Subject: Re: Image enhancement on FPGA
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 22 Jan 2009 09:30:31 +0000
Links: << >>  << T >>  << A >>
Mark McDougall <markm@vl.com.au> writes:

> Martin Thompson wrote:
>
>> Don't decide FPGAs are the answer too soon!  
>
> Don't waste your breath. It's obviously an assignment/project as the
> poster has way too little clue what's going on and hasn't done any
> research what-so-ever. 'F'.

Yes, it did have that ring about it :)  However, I was waiting for
Modelsim to do its stuff, and occasionally an interesting thread comes
of these things!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 137558
Subject: Re: How to add some SDRAM to a FPGA board ?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 22 Jan 2009 09:38:32 +0000
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> writes:

> On Jan 21, 9:15 pm, whygee <why...@yg.yg> wrote:
>> Hi Rick !
>>
>> this is the rest of the discussion from comp.arch.embedded.
>>
>> My fear is that my dear 475 'scope is limited to 200MHz so I could
>> miss things. But that will come later, when going "high speed" on PCB,
>> since the SDRAM initialisation dance in itself looks scary...
>> I'll probably have to finish my small CPU core before I go further,
>> since a programmed sequence will spare me the effort to design
>> a (scary) FSM.

If it helps descarify things, my first SDRAM controller (in an Altera
10KE) worked first time at 100MHz (on a PCB admittedly, which I also
designed).  No scope required - although I had lots of testpoints on,
which always reduces the chance of needing them :).  

I did spend quite a while in Modelsim before heading benchwards
though!

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 137559
Subject: Running 32 bit ISE on 64 bit linux
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 22 Jan 2009 09:48:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
I am trying to install the linux webpack ISE (either 9.2 or 10.1)
on a 64 bit linux (ScientificLinux 5.2) system.

It seems designed not to install.  I tried it with the linux32 command,
and even with /bin/csh copied from a 32 bit system.

64 bit processors are cheap enough now (this one with the motherboard
was less than $200) that it doesn't make sense to disallow it.

One post I saw mentions libuuid.so, but mine seems to have
the that library, so I don't believe that is the problem.

-- glen

Article: 137560
Subject: Re: FPGA granularity
From: Florian Stock <stock@esa.informatik.tu-darmstadt.de>
Date: Thu, 22 Jan 2009 11:14:37 +0100
Links: << >>  << T >>  << A >>
whygee <whygee@yg.yg> writes:

> rickman wrote:
>> On Jan 21, 12:45 pm, whygee <why...@yg.yg> wrote:
>>> OTOH has anybody read about the "upcoming" memristor-based FPGA ?
>> No, I have not read about this.  But the stuff I have read about
>> memristors indicates they are some years away from commercial
>
> Xilinx seems to use to buy things and swallow companies,
> maybe they'll get a hint and speed things up this way ?

Xilinx is maybe big, but the memristor stuff came from HP, I think they
cant buy them (maybe they cooperate). Another  big thing HP announced
was "field programmable nanowire interconnect" - nanowire crossbar to
connect everything, would reduce the size by 95% (but also no commercial
application up to now).

Florian

Article: 137561
Subject: Re: Running 32 bit ISE on 64 bit linux
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Thu, 22 Jan 2009 02:18:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 10:48=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> I am trying to install the linux webpack ISE (either 9.2 or 10.1)
> on a 64 bit linux (ScientificLinux 5.2) system.
>
> It seems designed not to install. =A0I tried it with the linux32 command,
> and even with /bin/csh copied from a 32 bit system.
>
> 64 bit processors are cheap enough now (this one with the motherboard
> was less than $200) that it doesn't make sense to disallow it.

Check if your distribution has 32-bit compatibility packages which can
be installed.

--
svenn

Article: 137562
Subject: xst: Multiple drivers but one is dangling, how to ignore?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Thu, 22 Jan 2009 02:33:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
I have a bundle (bus) defined as an array of records.
record is
address : std_logic_vector
data : std_logic_vector
en : std_logic
end record;

This bundle is routed to several instances on the toplevel but each
index of the array is only used by one of the instances. This means
that xst reports dangling nets on all the other instances and ties
them to '0' which leads to multiple drivers. This is a situation that
xst does not handle and exits.

I have tried as a quick hack to define an OPEN_DRAIN property on the
bundle, but OPEN_DRAIN is not supported by the Spartan-3A architecture
that I am using, so OPEN_DRAIN does not prevent xst from tying the
dangling bundle instances to '0'.

I guess the optimizer or mapper would later remove those "dangling"
nets since they are connected to '0', but xst seems to be really picky
on this.

What would be the appropriate work-around to such a problem? Xilinx
suggest removing whatever lead to the condition, but that means
creating separate buses instead of an array of records which would
mean rewrite of code.

--
Svenn

Article: 137563
Subject: Readback CRC, CFGLUT5 and Scrubbing
From: Mikel Azkarate-askasua <Azkarate@gmail.com>
Date: Thu, 22 Jan 2009 03:13:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Dear all,

A couple of questions about SEU detection/mitigation mechanism in the
Xilinx Virtex familly:

1) The Readback CRC feature available in Virtex-5 claims to mask
dinamically changeable memory as BRAMs, SRLs or Distributed RAM;

Are the V5 CFGLUT5 primitives also masked?

2) In order to test the detection, we are thinking about introducing
random bit flips through scrubbing in the configuration memory;

Could the FPGA substract (the silicon) be damaged by this random error
insertion (e.g. through short-circuit)?

Is any protection against this fact?

Thanks for your time!

Best regards,

Mikel A-a


Article: 137564
Subject: Re: rank beginner here, need to know where to start to get RS232 comm's working, and ...
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 22 Jan 2009 05:22:00 -0600
Links: << >>  << T >>  << A >>

>> If you are not aware of why you need to synchronize an input signal you
>> could read a longer post I wrote at the following URL:http://groups.google.se/group/comp.arch.fpga/browse_thread/thread/6b6...
>>
>> Or you could of course look it up in some textbook on digital design.
>>
>> /Andreas
>
>yes, I remember that thread, I have to admit, I didn't quite follow
>that part so well.  I will be re-visiting
>this shortcoming of this implementation of the RS232 but for now lets
>just get our feet wet.

You really really really want to understand that area.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137565
Subject: Re: FPGA granularity
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 22 Jan 2009 05:28:10 -0600
Links: << >>  << T >>  << A >>

>I'm interested to read and compare numbers from different FPGA families
>for 8, 16 and 32-bit wide adders (latency, area cost etc.).

You could build your own.  Just make a list of whatever you want
and make a design with an example.  Try it on any family you are
curious enough about to invest the time.

I think the reason that stuff dropped out of advertising is that
dedicated carry logic makes them faster than lots of other logic
so who cares.  The hard/slow part is probably routing the data
over to the adder.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 137566
Subject: Re: Running 32 bit ISE on 64 bit linux
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 22 Jan 2009 12:27:19 +0000
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2009 09:48:25 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>I am trying to install the linux webpack ISE (either 9.2 or 10.1)
>on a 64 bit linux (ScientificLinux 5.2) system.
>
>It seems designed not to install.  I tried it with the linux32 command,
>and even with /bin/csh copied from a 32 bit system.
>
>64 bit processors are cheap enough now (this one with the motherboard
>was less than $200) that it doesn't make sense to disallow it.
>
>One post I saw mentions libuuid.so, but mine seems to have
>the that library, so I don't believe that is the problem.

I successfully installed Webpack 10.1 on OpenSuse 11 64-bit.
Two things required for success: (well, possibly 3)

(1) 32-bit compatibility libraries. I think the thing that sold me on
OpenSuse 11 was the installation process: it asked me if I wanted the
32-bit compat libs. Forewarned about Webpack, all I had to do was say
yes. If they aren't available on your dist, you may have to use another
dist. (OpenSuse 11 isn't supported but that hasn't been a problem; even
opening webcases that are pretty clearly not OS-dependent)

(2) I edited the setup script. Where it detected installing on a 64-bit
system, it would error and exit if the 64-bit version was missing. Now
it warns and installs the 32-bit version instead.

--------------- Original: ------------------------
	# 64 bit
        if [ -f $setuploc/bin/lin64/setup ]
        then
            $setuploc/bin/lin64/setup 
        else
            echo "Product is not supported on \"$platform $machineType\"
platform."
        fi
-------------- As revised: -----------------------
	# 64 bit
        if [ -f $setuploc/bin/lin64/setup ]
        then
            $setuploc/bin/lin64/setup 
        else
            echo "Product is not officially supported on \"$platform
$machineType\" platform."
            $setuploc/bin/lin/setup 
        fi
--------------------------------------------------

(3) Not tested because I upgraded to the full ISE first:
You probably need to install the libusb driver from
http://www.rmdir.de/~michael/xilinx/
to run Impact and drive the parallel (or USB) to JTAG cable.

- Brian

Article: 137567
Subject: Re: xst: Multiple drivers but one is dangling, how to ignore?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 22 Jan 2009 12:43:15 +0000
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2009 02:33:19 -0800 (PST), Svenn Are Bjerkem
<svenn.bjerkem@googlemail.com> wrote:

>Hi,
>I have a bundle (bus) defined as an array of records.
>record is
>address : std_logic_vector
>data : std_logic_vector
>en : std_logic
>end record;
>
>This bundle is routed to several instances on the toplevel but each
>index of the array is only used by one of the instances. This means
>that xst reports dangling nets on all the other instances and ties
>them to '0' which leads to multiple drivers. This is a situation that
>xst does not handle and exits.

I presume you mean "each index of the array is only DRIVEN by one of the
instances" but the array as a whole is connected to the instance via a
single large Out (or InOut) port.

(I presume this because there should be no problem with unused Input
ports)

Then the problem is really that the instance has to drive the whole Out
port; including the bits it isn't using. And that, with multiple
instances, causes multiple drivers.

The simple solution is for the instance to drive (others => 'Z') 
or for the whole record, (others => (others => 'Z')) for every index it
isn't using.

You will get WARNINGS which can be safely ignored, that tristates
internal to the FPGA are unsupported; XST will build an equivalent MUX
structure. Then strip it all out again in the optimisation stage and
replace it with the simple point-to-point wiring scheme you probably
intended in the first place. 

There may be a better way to accomplish this. Possibly connect the whole
bus to an IN port on each instance, and connect a separate Out port to
only a single bus member (i.e. record)

- Brian


Article: 137568
Subject: Re: rank beginner here, need to know where to start to get RS232
From: jleslie48 <jon@jonathanleslie.com>
Date: Thu, 22 Jan 2009 04:55:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 21, 7:59 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

> Your choice. But once you get used to hardware the PPC will seem
> painfully slow.
>
> - Brian


That's half the reason I have to abandon my TI6713 DSP platform and
move to a FPGA only environment.



Article: 137569
Subject: Re: xst: Multiple drivers but one is dangling, how to ignore?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Thu, 22 Jan 2009 05:41:27 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 1:43=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 22 Jan 2009 02:33:19 -0800 (PST), Svenn Are Bjerkem
>
> <svenn.bjer...@googlemail.com> wrote:
> >Hi,
> >I have a bundle (bus) defined as an array of records.
> >record is
> >address : std_logic_vector
> >data : std_logic_vector
> >en : std_logic
> >end record;
>
> >This bundle is routed to several instances on the toplevel but each
> >index of the array is only used by one of the instances. This means
> >that xst reports dangling nets on all the other instances and ties
> >them to '0' which leads to multiple drivers. This is a situation that
> >xst does not handle and exits.
>
> I presume you mean "each index of the array is only DRIVEN by one of the
> instances" but the array as a whole is connected to the instance via a
> single large Out (or InOut) port.

Yes, that is correct.

> (I presume this because there should be no problem with unused Input
> ports)

That's why it worked until today when I suddenly needed some OUT ports
also.

>
> Then the problem is really that the instance has to drive the whole Out
> port; including the bits it isn't using. And that, with multiple
> instances, causes multiple drivers.
>
> The simple solution is for the instance to drive (others =3D> 'Z')
> or for the whole record, (others =3D> (others =3D> 'Z')) for every index =
it
> isn't using.

This looks like the solution I am looking for. My thinking was kind of
locked by a statement in a document that the FPGA we use don't support
tristate buses.

>
> You will get WARNINGS which can be safely ignored, that tristates
> internal to the FPGA are unsupported; XST will build an equivalent MUX
> structure. Then strip it all out again in the optimisation stage and
> replace it with the simple point-to-point wiring scheme you probably
> intended in the first place.

Nice explanation, exactly what I hoped would happen

>
> There may be a better way to accomplish this. Possibly connect the whole
> bus to an IN port on each instance, and connect a separate Out port to
> only a single bus member (i.e. record)

That would have been the next step to try out

Thanks a lot,
--
Svenn

Article: 137570
Subject: Re: testing a processor
From: Alex Colvin <alexc@TheWorld.com>
Date: Thu, 22 Jan 2009 15:22:53 +0000 (UTC)
Links: << >>  << T >>  << A >>
Andreas Ehliar <ehliar-nospam@isy.liu.se> writes:

>On 2009-01-22, akshay <akshayvreddy@gmail.com> wrote:
>> Hi,
>> i am trying to implement a small SIMD machine on and fpga vertex-2 chip.To
>> test this unit i have to load a user defined RAM with data. i have an
>> assembler that generates hex code. I have to get this hex code into the RAM
>> so that i can test the data flow.

>Finally, the most elegant solution is probably to write a small bootloader
>in ROM which you can use to download your program via a serial port or so.

Or arrange to execute the program from (initialized) ROM instead of RAM.
-- 
	mac the naf

Article: 137571
Subject: Re: converting floating point number to integer and vice versa
From: "olliH" <oollii21@yahoo.de>
Date: Thu, 22 Jan 2009 10:33:40 -0600
Links: << >>  << T >>  << A >>
>I want to write a function to
>1) convert single precision 32 bit floating point number to integer
>and return integer
>2) convert integer to single precision floating point number and
>return 32 bit floating point
>
>What are the parameters I should give to each functions and what logic
>do I use for both the functions.
>
>Do i need to write seperate function for signed and unsigned numbers?
>
>Your help would be appreciated
>

You can use the Xilinx floating point operator.

http://www.xilinx.com/products/ipcenter/FLOATING_PT.htm



Article: 137572
Subject: Re: How to add some SDRAM to a FPGA board ?
From: rickman <gnuarm@gmail.com>
Date: Thu, 22 Jan 2009 08:40:03 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 2:11=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, someone wrote)
>
> >> adding capacity and reducing impedance is not an issue,
> >> I can use larger diameter wires at will
> >> and my collection of capacitors is still growing :-)
> > The wire diameter has very little to do with the impedance. =A0
>
> Wire diameter is related to inductance, though.
> And inductance is related to impedance...

Just don't even go there.  For all practical purposes, changing the
diameter will have no noticeable effect in this situation.  Don't
encourage the guy!


> > Any capacitor you use has impedance. =A0You can see this
> > very clearly if you look at the impedance-frequency
> > curves for the parts. =A0The resonant frequency tells you the
> > frequency at which the capacitive and inductive impedance
> > are equal. =A0As the frequency continues to increase
> > the impedance rises. =A0For a high speed design the impedance of the ca=
p
> > becomes significant at frequencies that are important. =A0That is why
> > power planes are used. =A0They provide a low impedance at frequencies
> > into the GHz range.
>
> -- glen


Article: 137573
Subject: Re: Brushing up on theory: Butterworth LCR filter design?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 22 Jan 2009 08:47:26 -0800
Links: << >>  << T >>  << A >>
On Thu, 22 Jan 2009 07:29:49 -0600, krw <krw@att.zzzzzzzzz> wrote:

>In article <srlfn4hhf7qmgv30aa9ccbq0g0pusueg56@4ax.com>, 
>jjlarkin@highNOTlandTHIStechnologyPART.com says...> 
>> On Wed, 21 Jan 2009 18:52:34 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:
>> 
>> >On Wed, 21 Jan 2009 12:39:43 -0800, John Larkin
>> ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>> >
>> >>
>> >>
>> >>Not to change the subject (who, me?) but we just bought a heap of
>> >>samples of 0805-size integrated passive lowpass filters, TDK and some
>> >>others, and they are very impressive so far. Some are 3-pole, L-C-L
>> >>for some reason, and some are more.
>> >>
>> >We're using some of those (don't believer they're TDK) to isolate RF
>> >buzz (from frequency hopping) from the power supply on some
>> >replacement[*] headphone drivers.  They've been known to cause as many
>> >problems as they solve.  The footprint isn't exactly an 0805 (center
>> >ground stripe) so bridging across them can be a problem.
>> >
>> >[*] Replacement part required because of ROHS, of course. 
>> 
>> The Brat is just now creating the footprint; we'll be careful about
>> the bridging situation. The TDK recommended footprint uses weird outer
>> pads, sort of pointy towards the middle.
>
>The ones we use are from MuRata (NFL18ST).
>
>> Two of our frequency synthesizer boards are leaking strange rf things.
>> An FPGA is clocked at 128 MHz, and we're seeing lines coming out at
>> all sorts of bizarre frequencies, with no obvious numerical relation
>> to any clocks, from around 130 MHz up to a GHz maybe (160.34,
>> 175.89...) They seem to be coming from inside the FPGA, and are dead
>> stable in frequency so aren't analog oscillations. The 0805 filters,
>> right at our output connectors, whack things very nicely. Our max
>> signal frequency is 32 MHz, so they don't affect normal operation.
>
>When you say it's coming "out of" the FPGA...  How?  Power?  Signal 
>pins? Air?  In any case it is weird.  Did you ask Xilinx about it? 

We're not really sure how it gets out. The FPGA feeds dacs clocked at
128, which feed lowpass filters, output amps, and the connectors.
We're seeing lines as big as -45 dBm coming out the connectors. If you
wave a spectrum analyzer probe around the board, the junk is most
intense just over the FPGA. Some weird points: the lines are at
different frequencies on the two different boards, even though the
fpga's are very similar; one board tends to have lines in pairs, a
couple of MHz apart; we can almost swear that once we saw the whole
spectral forest shift around, in one instant on one board, when
nothing else was going on.

It would be fun to really investigate the cause of this, but all we
have time to do is fix it.
 
>
>The filters were making my output driver (LM7171 DSL driver used in 
>a Howland current pump) oscillate at 160MHz and suck gobs of power.  
>Bridging them with a zero ohm resistor eliminated the problem, but 
>as I said, it can be tricky with the ground stripe in the middle.

Luckily, we have a 50 ohm resistor between our output amp and the
filter+connector.

John



Article: 137574
Subject: Re: rank beginner here, need to know where to start to get RS232
From: jleslie48 <jon@jonathanleslie.com>
Date: Thu, 22 Jan 2009 08:49:46 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 22, 6:22 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:
> >> If you are not aware of why you need to synchronize an input signal you
> >> could read a longer post I wrote at the following URL:http://groups.google.se/group/comp.arch.fpga/browse_thread/thread/6b6...
>
> >> Or you could of course look it up in some textbook on digital design.
>
> >> /Andreas
>
> >yes, I remember that thread, I have to admit, I didn't quite follow
> >that part so well.  I will be re-visiting
> >this shortcoming of this implementation of the RS232 but for now lets
> >just get our feet wet.
>
> You really really really want to understand that area.
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.

I fully expect to fall into that hole.  I think the best way to learn
that lesson will be to crawl out of it.

meantime, here is the latest of my build:


ERROR:ConstraintSystem:59 - Constraint <NET "RS232_DSR_OUT" LOC =
"AD10";>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_CTS_OUT" LOC =
"AE8";>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_RTS_IN"  LOC =
"AK8";>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_DSR_OUT" IOSTANDARD
=
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_CTS_OUT" IOSTANDARD
=
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_RTS_IN"  IOSTANDARD
=
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_DSR_OUT" DRIVE =
8;>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_CTS_OUT" DRIVE =
8;>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_DSR_OUT" SLEW =
SLOW;>
ERROR:ConstraintSystem:59 - Constraint <NET "RS232_CTS_OUT" SLEW =
SLOW;>


\notes\screen05_firstucferrors.png

I don't know why it's just not ignoring the unused signals  and now I
realized that the UCF file
uses the # as a comment out character instead of the the "--"
grrrrrrr.....

yup that's it.
 \notes\screen06_ucffixed.png
 \notes\screen07_pinoutrpt.png

Ok, this looks like a I successfully completed 'implement design'

added clocks.ucf to move clock to AJ15.  all implimented still here's
clocks.ucf:

NET "clk" LOC = "AJ15";
NET "clk" IOSTANDARD = LVCMOS25;
NET "clk" TNM_NET = "clk";
TIMESPEC "TS_clk" = PERIOD "clk" 10.00 ns HIGH 50 %;

whatever this means.

now for the button,reset, and leds:

   btn_db_unit: entity work.debounce(fsmd_arch)
      port map(clk=>clk, reset=>reset, sw=>btn(0),
               db_level=>open, db_tick=>btn_tick);
   -- incremented data loop back
   rec_data1 <= std_logic_vector(unsigned(rec_data)+1);
   --  led display
   led <= rec_data;
   an <= "1110";
   sseg <= '1' & (not tx_full) & "11" & (not rx_empty) & "111";


these are all S3 Board specific yes?
  btn(0) is one of the 4 buttons of the S3 board and I have to
  find mutatis mutandis on my Digilent board?
led(0-7) an(0-3) and sseg(0-7) are what exactly?

for functionality I think I only need btn(0) yes?

then comes the clk, where is the speed and the divisor value fit in?
  - I'm guessing its somewhere in those oodles of pdf's that came with
te
    board, I remember ug069.pdf being useful...

and for this project reset is just a placeholder yes?














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