Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. RickArticle: 137551
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 AnttiArticle: 137552
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. -- glenArticle: 137553
"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 BrunsArticle: 137554
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
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
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: 137557Mark 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.htmlArticle: 137558
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.htmlArticle: 137559
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. -- glenArticle: 137560
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). FlorianArticle: 137561
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. -- svennArticle: 137562
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. -- SvennArticle: 137563
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-aArticle: 137564
>> 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
>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
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: 137567On 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) - BrianArticle: 137568
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
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, -- SvennArticle: 137570
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 naïfArticle: 137571
>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.htmArticle: 137572
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. > > -- glenArticle: 137573
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. JohnArticle: 137574
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:
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