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
A UART in the PC takes (if I remember correctly) 16 samples per bit. I guess you should be safe if you sample at least at 16x the 115K2 bit time (equals >1.8Mhz)... you should be able to get this out of your CPLD... Mike "dima2882" <vadimv@ieee.org> wrote in message news:ee8dd7b.-1@webx.sUN8CHnE... > Hi all, > > If anyone can think of why this idea may NOT work, please let me know - I > want to try to build this. I need to make a serial signal breakout box, > and I can't afford the card... so I want to take RS-422/485 signals, > convert them to TTL with a converter chip, and use a CPLD as a Mux for the > several TTL signals connected to it. The TTL signal that passes based on > Mux setting is converted to RS-232 with a MAX232 chip, and goes to the PC. > Can a XC9500 CPLD be made fast enough to keep up, for baud rate of 115kbs? > > Thanks for all your suggestions.Article: 83326
Hi Petter, Chapter 9 of the MAX II handbook explains how to use the ALTUFM megafunction to add UFM data with mif or hex file. The user has to recompile if they want to change the hex file data, as this is how you convert it to POF. This can be found at http://www.altera.com/literature/hb/max2/max2_mii51010.pdf (page 9-34 thru 9-38.) Hope this helps. Subroto Datta Altera Corp. Petter Gustad wrote: > Is there an easy way to convert a plain ascii file of hex numbers etc. > into a SOF format or similar in order to program the UFM of the MAX > II? > > Petter > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail?Article: 83327
kevin@firebolt.com wrote:
>Please correct me if I'm wrong (probable), but aren't DSS's used just
>to create the numeric representation of a requested wave-shape. Sorry
>I didn't clarify in my original post, I only need to output a square
>wave (0/1) over the standard FPGA I/O. As I would still be clocking
>the DSS at 40 MHz, I wouldn't be able to get better
>resolution/granularity for frequencies between 500 to 700 kHz that
>would be able to be multiplied by 16 based on a 40 MHz clock Is there
>a way to make the DSS asynchronous? Sorry if I'm missing something
>obvious.
>
>Kevin
>
>
>
Not quite. You just need the phase accumulator portion of a DDS. the
most significant bit out is your square wave output. The output will
have a jitter of at most +/- 1 period of you master clock.
This is basically an accumulator to which you add a fixed increment on
each clock. A k bit accumulator with an increment value of N will
overflow (ie lap) N times in 2^k clocks. For example, if the
accumulator is 4 bits and it is incremented by 1, it takes 16 clocks to
overflow, so once in 16 clocks. If instead the increment value is 5 it
overflows 5 times in 16 clocks following this sequence:
0
5
10
15
4
9
14
3
8
13
2
7
12
1
6
11
0
Note that if you take only the MSB out, you get the equivalent of a
sampled squarewave.
Increasing the number of bits increases the frequency resolution.
Increasing the master clock frequency reduces the maximum jitter.
The output frequency is Fo= Fclk * N/(2^k). N is a 2's complement
value, so if the msb is set, you get negative frequency (ie the rotation
is in the opposite direction).
In the case of a classic DDS, some number of the MSBs from this phase
accumulator feed a phase to amplitude converter, which might be a ROM, a
cordic rotator, or some algorithmic hardware to convert the phase angle
(which is the fractional part of a revolution) to the desired waveshape,
which is typically sine and cosine.
Hope this helps.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 83328read what the OP asked! he wants to program the UFM from MIF or HEX __without__ recompiling! thats the all problem. dont suggest the obvious things. we all know that an MIF can be assigned to the UFM and it is merged to POF during compile. antti PS what you said certainly does not help the OP ! what would help is when Altera would document the JTAG commands to program the MAX2 and UFM ! even the BSCAN USER command seems to be big secret if looking at Altera web! well thats no big deal the instruction is 0x0E but ASFAIK that info is not to be found in any public documents from Altera! cyclone JTAG download is pretty simple (but also not documented) this no-docu-from-altera is the problem why our FPGA FrequencyMeter application doesnt support fully Cyclone, we simple have not fully mastered the JTAG download, yes I looked at the SVF files, etc.. but this type of JTAG command reverse engineering is stupid!!! would be better to document the obvious things. "Subroto Datta" <sdatta@altera.com> schrieb im Newsbeitrag news:1114636655.106746.211620@f14g2000cwb.googlegroups.com... > Hi Petter, > > Chapter 9 of the MAX II handbook explains how to use the ALTUFM > megafunction to add UFM data with mif or hex file. The user has to > recompile if they want to change the hex file data, as this is how you > convert it to POF. > > This can be found at > http://www.altera.com/literature/hb/max2/max2_mii51010.pdf > (page 9-34 thru 9-38.) > > Hope this helps. > Subroto Datta > Altera Corp. > > > > Petter Gustad wrote: > > Is there an easy way to convert a plain ascii file of hex numbers > etc. > > into a SOF format or similar in order to program the UFM of the MAX > > II? > > > > Petter > > > > -- > > A: Because it messes up the order in which people normally read text. > > Q: Why is top-posting such a bad thing? > > A: Top-posting. > > Q: What is the most annoying thing on usenet and in e-mail? >Article: 83329
Antti Lukats wrote:
>BTW, Atmel AT40K are claimed to be pin-compatible to xilinx XC4K,
>but if you can redesign to recent lowcost FPGA then thats possible
>preferable.
>
>antti
>
>
>
>
Pin compatible only in that the pin definitions matched so that you
could concievably put an equivalent design (different bit stream) in the
Atmel part and use it in a xilinx socket. That is where the
similarities ended. The AT40K has a completely different internal
architecture, and most notably does not have any fast carry logic, and
instead of using LUTs for memory have small 32 bit memories for every
couple of logic cells. If you compare architectures, you'll find that
many Xilinx designs will not fit in the resources supplied in the
"equivalent" Atmel part.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 83330Hi Ray, yes sure I forgot to mention those details.. its totally different thing internally. I was just looking at AT94 and AT40 in order to see if I could maybe have an application for them, the AT94S10 is $19, its true single chip, has onchip 25 MIPS RISC and can do dynamic reconfiguration. could be used as replacement (way more flexible) for SystemACE, that where my interest was. I still have the very secret document about all the bitstream cell bit info of the AT40K so still having ideas doing something that really benefits from dynamic reconfiguration. Antti "Ray Andraka" <ray@andraka.com> schrieb im Newsbeitrag news:poTbe.50$c83.49@lakeread07... > Antti Lukats wrote: > > >BTW, Atmel AT40K are claimed to be pin-compatible to xilinx XC4K, > >but if you can redesign to recent lowcost FPGA then thats possible > >preferable. > > > >antti > > > > > > > > > Pin compatible only in that the pin definitions matched so that you > could concievably put an equivalent design (different bit stream) in the > Atmel part and use it in a xilinx socket. That is where the > similarities ended. The AT40K has a completely different internal > architecture, and most notably does not have any fast carry logic, and > instead of using LUTs for memory have small 32 bit memories for every > couple of logic cells. If you compare architectures, you'll find that > many Xilinx designs will not fit in the resources supplied in the > "equivalent" Atmel part. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 83331
"Roger" <enquiries@rwconcepts.co.uk> wrote in message news:mrSbe.9072$WW5.3120@newsfe2-win.ntli.net... > The RIO User Guide (UG024) stipulates that the RIO supply pins need to be > filtered using a Ferrite bead and a capacitor. It's very specific about the > bead being either of 2 Murata parts and the capacitor being a 0.22uF 0603 > device. I'd guess that's because they didn't try any other parts, so they can't be sure they work. However, I seem to recall the latest advice was a 1uF cap. Are you sure you have the latest version of the user guide? You should know that above 50MHz, 0402 and 0805 caps (~0.4nH inductance) have slightly less impedance than 0603 ones (~0.5nH), and the uF value makes very little difference. The inductance of the package dominates the impedance. I use 0402 parts because they're smaller, so more space for other goodies! > > The ML300 board however doesn't adhere to the capacitor recommendations and > uses a larger device. How important is it to stick rigidly to the User's > Guide, does anyone have any relevant information on this? > That depends on whether you think you'll need support from Xilinx. If you go your own way, they may well say "come back when you follow the design guidelines" before they help. You can see their pov, there are a lot of designs to support, and an FAE who can support Gbit designs is expensive. > I'm having problems finding a supplier of the ferrite beads. Similar > question: is it really so important that I use either of the 2 parts stated > in the UG? > Almost certainly not, provided you find a close-ish equivalent. But I refer you to my previous comment about support. In a way, if only because you felt the need to ask the questions, I'd suggest you follow what the user guide says as best you can. When you've got it working that way, why not play about with different parts and values to get a feel for what is and isn't important? You could experiment with the ML300 board. I also recall that Xilinx reckon the ML310 board is a better example of what to do. "Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message news:4263EAFA.9070408@xilinx.com... > > We did a rewrite of this section in the user guide (page 110) to clarify > this, but when I reviewed it again today it's still not clear. What it > should state is 1.0 uF for every 2 MGTs that are used and these should be > placed near the ferrite beads, which should be placed near the FPGA. > > If you are looking for an example of how Xilinx created a board that > uses the RocketIO, the ML300 is not a good choice as this was done > very early and is missing some of the final design recommendations. > > The ML310, ML321, ML323 and ML325 are better examples in this area > http://www.xilinx.com/ml310 > http://www.xilinx.com/ml321 > > Ed Cheers, Syms.Article: 83332
Duane Clark ha scritto: > By the way, I should mention one more subtle gotcha. The addresses to > the DIMM need to be reversed, because this determines the DDR/DIMM > commands. Modified the core, but it didn't work... Unfortunately I discovered that I hadn't the Service Pack installed, so I had to modify manually the cores (two of them were older than the ones you used for the diff files...) and had to do some fine tuning... Tomorrow I'll ask to install the SP 2 on the lab's machine and check with it installed what I can do. Anyway, thanks for the help!!!Article: 83333
Berty wrote: > Peter, > While I understand your point I'm afraid this is why you see so many > Eng that know just about nothing except copy paste of IP module. > Of course Async FIFO is not as simple as shift register. And of course > it involve some thinking and I would strongly recommend anyone who want > to design such thing or for that matter any new design to have DR of > more experience Eng to see how he did what he did and see how to > improve or fix the wrong. > I'm fully aware of the Empty Full having designed several FIFO of all > type and flavor. > Except for the obvious of the advantage of knowing what you do and > example as for why you should know to design by yourself can be that > Some FIFO depend on the implementation when they have one last entry > will toggle the empty while other will not. > Sometime this toggle can be more useful however if you know Zilch about > how the FIFO was design you can do nothing and have to adapt yourself > to what ever the core give even if this is not the best for the design > you do. > And talking about synconizers and Gray counter etc while to use them > correctly is important this is not rocket science, Sure to give > complete and full explanation of what Metastable is and the effect of > it in clear way and not just using "wave hand" explanation can be > challenging but the actual implementation once you understand the > meaning of it is not so difficult that one have to pass it aside and > use other proven code. > I guess it all boil down to are you an Eng who want to be a copy/paste > one or are you an Eng who want to know how to do thing and yes ONCE you > know use other if they make sense, but even for this to tell if it make > sense you need to understand and not just be another copy/paste-Eng as > more and more I for one encounter. > > And all those who might give example on how they saved money, time etc > by using other FIFO and not learning how to do it the right way are > just an example as why you SHOULD learn and not just be copy paste one > and use this as example to why to use other code. > > Back to Math using your own logic is equivalent to say to Eng you > should learn how to do 1+1 however to do integral of X^2 from 0 to 2 is > to complex so use calculator, I do hope university will not go with > this logic and those that do well maybe from there we get all the > copy-paste Eng's. > > Remember that any minute you "Waste" today for learn how to do it > will pay thousands time in your future, when you have design which are > not simple and there is no IP and you need to draw from your own > experience, which if it involve only/mainly copy-paste without the > knowledge mean you will never become ASIC leader or Architect of new > complex designs and you will stay basic simple Designer, as no > knowledge mean poor capability. > Interesting post too... however... I sure am always extremely frustrated when I see people coding in HDL and not knowing the basics, calling their VHDL code a "program", not knowing what crossing clock domains is about, etc ! But on the other hand, we are in a competing world, and as a Project Manager I would be VERY unhappy to see one engineer spend a week trying to write his own dual clock Fifo and SOMEWHAT scared about the result (through a synthesis tool in particular). As of what he would learn in the process (no pun intended) I'm not very sure (verification of such a beast is not obvious either). And the customer wouldn't see any advantage vs a design using ready-made Fifo, but he WILL see a tangible advantage if we spent an extra week implementing new innovative features (for the same budget). But I sure taught my team all the many tricks I use when designing with FSMs. We designed our own FFTs, they used to be superior to the vendors' in many situations, but that's less and less the case, so we drop this know-how (for FPGA) and we more and more use the standard megafunction. I would say that there is room in-between these extremes (knowing nothing and knowing everything) In our courses, we do our best to teach really solid foundations and stay focused on the issues that will make a difference between good and poor design. To me it's safe enough if the engineer clearly understands the issues, & knows the principles of what the cores are made of and why, and knows which to use in each situation. I'm not sure it's so important anymore to fully understand the RISC instruction set in the context of SOPC. It's a long time I didn't code in assembly language. My opinion indeed... Thanks anyway for this exchange of views. Bert CuzeauArticle: 83334
Thanks for the follow-up. One of the "valid" reasons I didn't give details about was that these chips are running at an ambient temperature of 175 degrees Celsius :-) This customer won't qualify a new family every now and then as you can surely guess ;-) Any semi wiling to qualify the latest chips at this temp ?Article: 83335
Hi Austin,
I also tried using the power estimation tool on Xilinx' web site and
ran into pretty much the same results as Paul described earlier in the
thread.
Specifically, I tried >10 different configurations with a V4 LX80
part; varying the following parameters (all "utilization" parameters
were between low and medium values, Vccint was varied between 1.1V and
1.3V):
Vccint
CLB Usage
FIFO Usage
RAM usage
DSP block usage
Amount of air flow
What I found is that for every "configuration" I tried the ratio of
Vccint_new/Vccint_old was almost exactly equal (equal at least to the
precision of a mW) to the ratio of Power_new/Power_old (where the
Vccint
values are between 1.1 and 1.3 and Power_{new,old} refers to only the
power
reported as dissipated on the Vccint rail.
Could you please shed some light on the behaviour described above? Are
Paul and I simply doing something completely wrong with the power
estimator?
In order to avoid coming off as simple minded, I will refrain from any
speculation on my side.
Thanks,
Ljubisa Bajic
ATI Technologies
Austin Lesea <austin@xilinx.com> wrote in message news:<d4mfgm$7d53@cliff.xsj.xilinx.com>...
> Paul,
>
> It does change (with V), as is shown by the predictor.
>
> And yes, we do use Vccint. We also use Vccaux.
>
> Nothing is ever as simple as it first seems.
>
> The devil is in the details, and telling you how it works would just
> allow you to copy it, and improve your own estimator.
>
> Austin
>
> Paul Leventis wrote:
>
> > Hi Austin,
> >
> >
> >>Since we power the pass gates from Vccaux through a band gap
> >
> > referenced
> >
> >>supply for the entire interconnect, many simple minded formulas that
> >
> > you
> >
> >>may come up with will not apply.
> >
> >
> > Excuse my simple-mindedness, but I am having trouble understanding.
> > You have no circuitry powered off the actual VccInt rail? Your routing
> > buffers, LUTs, DSPs, RAMs and other hard-IP blocks do not use VccInt
> > but rather run off the regulated VccAux-driven supply?
> >
> > Yes, I will concur that simple rules-of-thumb are never quite true in
> > practice, and depend on exact circuits used. But are you suggesting
> > that your supply current doesn't change with voltage? At all?
> >
> > Paul Leventis
> > Altera Corp.
> >
Article: 83336
Hey Guys,
I'm running into this insane problem just trying to play some ordinary
wave file on a LM4550 audio codec on the XUP board
(http://www.digilentinc.com/info/XUPV2P.cfm) (I don't know if this
board is widely used yet, but I'm posting a link anyway). The problem
is that audio codec plays the pcm file cleanly (i.e. no static) but
certain parts of the file are repeated during playback (so if the wave
file contained someone saying "1 2 3", it playbacks "1 1 2 2 3 3") The
data resides on a SRAM module connected to the expansion headers on the
board. I'm certain that the data itself isn't corrupted. I have
verified my design several times in simulation and the address
generation to access audio data from the SRAM seems fine.
I guess what I'm wondering is, is there something werid about
configuring the LM4550 that I'm missing and that maybe causing this. I
configure the following registers on the LM4550 which are on the
playback path:
Register: 02h Value 00h (Line out, unmute)
Register: 04h Value 00h (Headphone, unmute)
18h Value 00h (PCM Gain, unmute)
20h value 80h (To bypass the 3D Sound Circuitry)
0Ah value 00h (to mute the PC Beep input)
Any insights to configuring/using the LM4550, would be really
appreciated.
Btw - the test file is something I recorded using the Windows Sound
Recorder setting the output format to PCM at 48000 KHZ, 16-bit Stereo.
Or is perhaps Sound Recorder screwing me?
Thanks.
Article: 83337Hi all, I have just upgraded from the 6.3 version of the EDK to the 7.1 version. For testing purposes i wanted to download the ML40x reference design onto my ML 401 board. Unfortunately, the new EDK (the par tool) seems unable to meet the timing constraints of the design. I dont know if this is a problem with the EDK or ISE 7.1. If anyone out there has found a work around or perhaps a solution I would love to hear about it. I have made no changes to the design. Thanks peterArticle: 83338
Is anybody able to tell me anything about working out the cycle-to-cycle jitter of a DCM output? The situation is that I want to forward a clock to a QDRII device, which has a cycle-to-cycle jitter tolerance of +-100 ps. The data I can find on the Virtex-II Pro DCMs only specs the period jitter (Which is the upper bound for the cycle-cycle jitter). In addition to that, the user guide states that DCMs cannot remove jitter. The period jitter introduced by the DCM is too high (CLK0 has +-100 ps period jitter), but the actual cycle-cycle jitter should be lower. Question is - can it be done? (XAPP750 doesn't seem to consider it as a problem), and the other question is how to spec the jitter characteristics for the clock source. I'd rather make the design correct-by-design, rather than trying it and characterising it (I don't have hardware yet anyway) - I'd appreciate any light anyone could throw on the matter. Thanks, JeremyArticle: 83339
"Hope this helps." It absolutely does! Thanks guys. Kevin Ray Andraka wrote: > kevin@firebolt.com wrote: > > >Please correct me if I'm wrong (probable), but aren't DSS's used just > >to create the numeric representation of a requested wave-shape. Sorry > >I didn't clarify in my original post, I only need to output a square > >wave (0/1) over the standard FPGA I/O. As I would still be clocking > >the DSS at 40 MHz, I wouldn't be able to get better > >resolution/granularity for frequencies between 500 to 700 kHz that > >would be able to be multiplied by 16 based on a 40 MHz clock Is there > >a way to make the DSS asynchronous? Sorry if I'm missing something > >obvious. > > > >Kevin > > > > > > > Not quite. You just need the phase accumulator portion of a DDS. the > most significant bit out is your square wave output. The output will > have a jitter of at most +/- 1 period of you master clock. > > This is basically an accumulator to which you add a fixed increment on > each clock. A k bit accumulator with an increment value of N will > overflow (ie lap) N times in 2^k clocks. For example, if the > accumulator is 4 bits and it is incremented by 1, it takes 16 clocks to > overflow, so once in 16 clocks. If instead the increment value is 5 it > overflows 5 times in 16 clocks following this sequence: > 0 > 5 > 10 > 15 > 4 > 9 > 14 > 3 > 8 > 13 > 2 > 7 > 12 > 1 > 6 > 11 > 0 > > Note that if you take only the MSB out, you get the equivalent of a > sampled squarewave. > > Increasing the number of bits increases the frequency resolution. > Increasing the master clock frequency reduces the maximum jitter. > > The output frequency is Fo= Fclk * N/(2^k). N is a 2's complement > value, so if the msb is set, you get negative frequency (ie the rotation > is in the opposite direction). > > In the case of a classic DDS, some number of the MSBs from this phase > accumulator feed a phase to amplitude converter, which might be a ROM, a > cordic rotator, or some algorithmic hardware to convert the phase angle > (which is the fractional part of a revolution) to the desired waveshape, > which is typically sine and cosine. > > Hope this helps. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759Article: 83340
> > Crazy talk. X11 runs fine in 128Mb of RAM on PowerPC. I'm building a > > demo embedded application around a PPC-Linux box (603e) with 64Mb of > > RAM (external video RAM), running X11. > > >>and I need to run some > >>other memory-extensive tasks on the background. > > and swap is very limited. Yes, but you didn't quantify that at all. If you're saying that what you meant to post was "Can I run X on a machine with 128Mb RAM and no swap, given that my application absolutely requires 127.5Mb of RAM to itself", then that's a different question. Simple test: free ; X & ; sleep 30 ; free ; killall X (or something like that).Article: 83341
"Ziggy" <Ziggy@TheCentre.com> wrote in message news:XLMbe.25668$NU4.19867@attbi_s22... > David wrote: > > On Wed, 27 Apr 2005 11:42:58 +0000, Uwe Bonnes wrote: > > > > > >>In comp.arch.fpga license_rant_master <none@nowhere.net> wrote: > >>: I am an ASIC engineer who frequently 'takes work home' with me. > >>: Recently, I began using ssh to remotely login to our company's > >>: servers to run some Verilog/VHDL simulations. Launching > >>: sims (from the UNIX command line) is fairly easy and painless, > >>: but any kind of interactive (GUI) operations are pitifully > >>: slow over an WAN/internet connection. In the past, I > >>: haven't needed to do much more than check on running jobs, > >>: restart them, then logout. Now, I find the need to do some > >>: interactive debugging work (waveform viewing, code editing, > >>: etc.) > >> > >>Look at NX. It what LBX (Low Bandwidth X ) promised, but NX > >>delivers. Probably not to easy to set yet, but worth a try. > >> > > > > > > It's easy enough to set up the server (either look at the commercial > > version from www.nomachine.com, or google for "freenx" or "nxserver") on > > linux, and clients are even easier (download free from nomachine). It is > > said to be usable over a modem connection - I have certainly found it > > works well over ADSL for most work. It's definitely faster than tightVnc > > (which is also okay for many things - and works well for pretending you > > are sitting at your office windows desktop). > > > > > > > >>Bye > > > > > > > > > Too bad its not easy to setup a server in FreeBSD ( i know, totaly OT ) > > Like others will most likely point out, something like TightVNC would > support compression, and is even easier to setup then NX.. With SSH, He is actually half way there, just forward port 5900 and install VNC.Article: 83342
Antti Lukats wrote:
>Hi Ray,
>
>yes sure I forgot to mention those details.. its totally different thing
>internally.
>I was just looking at AT94 and AT40 in order to see if I could maybe have
>an application for them, the AT94S10 is $19, its true single chip, has
>onchip
>25 MIPS RISC and can do dynamic reconfiguration. could be used as
>replacement (way more flexible) for SystemACE, that where my interest was.
>I still have the very secret document about all the bitstream cell bit info
>of
>the AT40K so still having ideas doing something that really benefits from
>dynamic reconfiguration.
>
>Antti
>
>
>
>
>
>
I got one of those around here somewhere too. The AT40K is getting
kinda long in the tooth though. The only advantage it has over the
Virtex parts is the fact that you can partially reconfigure down to the
cell level, where Virtex requires you to reconfig a whole column (or a a
whole column segment for V4). Regardless, the tools for partial config
have never really been developed far enough to make it much more than a
lab curiousity. I did make some forays into partial configuration years
ago, and it was painful. As far as I've been able to determine, the
design described in my dynamic video pipeline processor paper (on the
website) is the first application that attempted to do partial
configuration with the clock running. All the designs described in the
prior literature suspended the clock while reconfiguring. Running the
clock opened a whole new can of worms, and the Atmel architecture was
not well suited for it because you had to be careful what order you
removed and replaced wires to avoid damaging conflicts (shorts). In any
event, the place and route tools are far from what is really necessary
to reasonably handle dynamic partial reconfiguration.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 83343I remember that we shipped XC3000 and XC4000-type devices for down-hole (oil exploratory drilling) applications, where they were used for week-long operation at 175 degr C. We never guaranteed operation, and parameters do of course become much slower and leakier, but the customer had no functional problems. They ran into problems at 200 deg C. I doubt that any manufacturer will go to the trouble of qualifying parts at that temperature, for a very limited market. Well-designed Si should not have a serious short-time problem, but some plastic packages behave strangely above 140 degrees. Peter Alfke ==================== info_ wrote: > Thanks for the follow-up. > > One of the "valid" reasons I didn't give details about was that these > chips are running at an ambient temperature of 175 degrees Celsius :-) > This customer won't qualify a new family every now and then > as you can surely guess ;-) > > Any semi wiling to qualify the latest chips at this temp ?Article: 83344
Berty wrote: > Peter, > While I understand your point I'm afraid this is why you see so many > Eng that know just about nothing except copy paste of IP module. [...] > Back to Math using your own logic is equivalent to say to Eng you > should learn how to do 1+1 however to do integral of X^2 from 0 to 2 is > to complex so use calculator, I do hope university will not go with > this logic and those that do well maybe from there we get all the > copy-paste Eng's. [...] And where do you stop? By your own logic, they can't just stop at doing integrals. You need to know how to derive all the integral short-cuts that you use, for fear that someday while waiting for a bus, someone holds a gun to your head and makes you re-derive the integral of sin(x)dx. But you can't stop there either - you have to move on to differential calculus and partial differential equations. But that's not all, then you need to... (etc) Moving back to the electronics world, how about other components in the FPGA (or an ASIC)? Before I can use the PLL or CDR within the Rocket I/O, should I understand it so well that I could design one myself? What about the DCM? Do I need to be able to design my own latch-up resistant, ESD protected, discrete input and output buffers before I can use an ASIC vendors' IO cell? What about the optical transceiver that I connected to the Rocket I/O - do I need to know exactly how the pin diodes and laser drivers work before I can use an optical transceiver? Everyone is going to draw the line in different spots, based upon their needs. Not everyone wants or needs to specialize in FIFO design. If you can do it, great - it gives you a slight competitive advantage for a few jobs out there (or turn it into a life-long job, as Peter has). But that alone does not indicate Having said all this, however, I have to agree with some of the underlying points upon which you've placed your FIFO example... that engineers need a firm understanding of the basics so that when they are called upon to design something, they know where to start. Even more importantly, they understand the limits of their knowledge, and if necessary, know how to educate *themselves* further on the topic, without much outside help. That's the true sign of an engineer - not if they can design an async FIFO. Have fun, MarcArticle: 83345
On Wed, 27 Apr 2005 08:38:39 -0700, dima2882 wrote: > Hi all, > > If anyone can think of why this idea may NOT work, please let me know - > I want to try to build this. I need to make a serial signal breakout > box, and I can't afford the card... so I want to take RS-422/485 > signals, convert them to TTL with a converter chip, and use a CPLD as a > Mux for the several TTL signals connected to it. The TTL signal that > passes based on Mux setting is converted to RS-232 with a MAX232 chip, > and goes to the PC. Can a XC9500 CPLD be made fast enough to keep up, > for baud rate of 115kbs? > > Thanks for all your suggestions. It sounds to me like you don't need any programmable logic at all. Why can't you just use however many you need of the two kinds of converters (RS-232<->TTL and RS-422<->TTL) and use an analog or bidirectional mux or something on the logic level signals connecting them? If there is some reason why you want to use the programmable part, for example if the selection logic is more complicated than I am imagining, then I don't think you will run into any speed problems. I do not consider 115kbaud to be fast for a digital circuit. RS-232 and RS-422 are largely compatible, in that each device has an input and an output signal. However, there ARE some issues surrounding interfacing of RS-485 with RS-232. RS-485 is a shared bus architecture, meaning that the same pair of data lines is used for transmitting and receiving. This necessitates some kind of scheme to disable your drivers when they are not driving. Some converters (see B and B electronics) sense transitions on the RS-232 line, and automatically start driving data onto the RS-485 line for a certain amount of time after the last detected transition. Then they go back to tri-state mode. This additional logic would complicate your circuit quite a bit. Let me know if you want me to elaborate on any of these points. --MacArticle: 83346
Hi, Awhile back I tried having Nios II and a separate cygwin (from cygwin.com) on the same machine, but ran into big problems. I now want to install the latest Nios II eval kit but I'm not sure if Altera has fixed things so they can co-exist. Does anyone have a stand-alone Cygwin and Nios II tools running fine on the same machine? I thought I'd ask beforehand because I sure don't want to run into that situation again. -- PeteArticle: 83347
Well, I did design FIFOs,and in particular the asynchronous arbiter in the Virtex-4 BlockRAM FIFO ( and the test methodology for it), and I measured asynchronous behavior and metastable recovery. But these were major efforts, and were based on many decades of design experience. Xilinx can afford such exploration since we expect that many of our customers will eventually benefit from it... It's just not what you should entrust a junior engineer to do. Let them grow up with synchronous logic, and carefully graduate to data transfer across clock boundaries later. When you cannot simulate, you really need to be both experienced and confident Peter AlfkeArticle: 83348
Mohammed A Khader wrote: > Hello, > > When synthezing the design with Synplify Pro 8.0 it gave the > follwoing Warning. > > CL209 Input port bit <4> of spi_addrs(4 downto 0) is unsed. > CL209 Input port bit <3> of spi_addrs(4 downto 0) is unsed. > CL209 Input port bit <2> of spi_addrs(4 downto 0) is unsed. > CL209 Input port bit <1> of spi_addrs(4 downto 0) is unsed. > > > I am sure that I am using the slice (4 downto 1) as an input to the > mux. > > I tried by assigning this slice to an intermediate wire (signal) and > then to the mux input . But again it is giving the same error. > > Following is the relevant piece of code.... > ntity Ctrl_Ram is > port( > Ctrl_Data_In : in WORD; > Ctrl_Addrs : in unsigned(3 downto 0); > Spi_Addrs : in unsigned(4 downto 0); > Ctrl_Wr : in std_logic; > > Intl_Rst : in std_logic; > Clk : in std_logic; > > Reset : in std_logic; > > Data32_Out : out DWORD; > Data16_Out : out WORD > ); > end entity Ctrl_Ram; > > Architecture arch of Ctrl_Ram is > begin > spi_addrs_intl <= Spi_Addrs(4 downto 1); > Addrs_Mux:process(Ctrl_Addrs,spi_addrs_intl,Intl_Rst) > begin > case Intl_Rst is > when '0' => Addrs_In <= spi_addrs_intl; > when '1' => Addrs_In <= Ctrl_Addrs; > > when others => Addrs_In <= (others =>'X'); > end case; > end process Addrs_Mux; I don't see anything wrong with your code, other than being unnecessarily complex. This warning from Synplify usually comes from the optimization phase. It typically means that the signal referred to does not enter into the reduced equation of any output or stored internal state. This can be either because you have a logic error somewhere in your design, or because interaction with some other signal(s) causes the result to not depend on the flagged signal. In other words, you have to examine the total portion of the design that includes the entity in question. This type of warning is an extremely common in large and/or parameterized designs. It needs to be investigated to make sure the optimization is reasonable, but it isn't something to panic over. -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.comArticle: 83349
Jeremy, The reason why we don't specify the cycle to cycle jitter any longer is that it is hardly used by anyone anymore. Obviously, you have a a requirement. I may question how useful it is, but I won't (how does it know, or care what the previous cycle timing was?). The worst case cycle to cycle jitter (immediate cycle to the next one) is the tap value. That is ~50ps for V2, and 35 for V2 Pro, and ~25ps for V4. Add linearly to that value the cycle to cycle jitter on the input clock itself. So it the input is 20 ps, and the tap is 50 ps, then the total is 70 ps. Austin Jeremy Stringer wrote: > Is anybody able to tell me anything about working out the cycle-to-cycle > jitter of a DCM output? > > The situation is that I want to forward a clock to a QDRII device, which > has a cycle-to-cycle jitter tolerance of +-100 ps. The data I can find > on the Virtex-II Pro DCMs only specs the period jitter (Which is the > upper bound for the cycle-cycle jitter). In addition to that, the user > guide states that DCMs cannot remove jitter. > > The period jitter introduced by the DCM is too high (CLK0 has +-100 ps > period jitter), but the actual cycle-cycle jitter should be lower. > > Question is - can it be done? (XAPP750 doesn't seem to consider it as a > problem), and the other question is how to spec the jitter > characteristics for the clock source. > > I'd rather make the design correct-by-design, rather than trying it and > characterising it (I don't have hardware yet anyway) - I'd appreciate > any light anyone could throw on the matter. > > Thanks, > Jeremy
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