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
John_H wrote: > "PeteS" <axkz70@dsl.pipex.com> wrote in message > news:A_ydnSr8fcvE7kXbnZ2dnUVZ8sqjnZ2d@pipex.net... >> John_H wrote: > <snip> > >>> Thanks to everyone for devining what PeteS means. >>> I understand skin effect. >>> I understand the confinement of return current for high frequencies. >>> I don't understand the statement that "there is no such thing as >>> 'ground'." >>> >>> I was hoping Pete could conjecture what Pete meant. >>> >>> - John_H >> Hi John >> >> Let's first define what 'ground' means. For power, it's the 'zero >> potential' path for return currents. For RF radiation, it's literally the >> ground (where we get the name) which has a nominal '0' potential. >> >> For high speed signalling, there isn't really a thing that has zero >> potential across it's length, be it signal or reference. The return >> currents in a nominal ground plane for high speed returns will induce >> significant potential gradients across the plane. As a 'ground plane' is >> usually used as a description of an area of equipotential, the term ceases >> to have meaning when it is no longer equipotential - as is the case when >> it is a high speed signal reference/return path. >> >> That's really what I mean by the comment that at high speeds, ground >> doesn't really exist. >> >> Cheers >> >> PeteS > > The fact that return current is confined tightly around the signal for high > frequencies doesn't make the ground plane cease to be nearly equipotential. > The confined return current will not raise the voltage of the ground plane > significantly but instead flow the current through a low impedance path due > to any induced voltage. If the voltage changes under the high frequency > trace due to the return current and the finite HF plane impedance, the > current will flow out around that area to the lower potential - a voltage > difference on a ground plane doesn't last long; this is why the return > current path is several widths of the distance to the conductor above. If > the ground reference were not a ground but a strip that was the same width > we identified for the return current, the characteristics would probably be > a bit different since the voltage difference from under the signal to the > edge of this region isn't tied down to the same potential as the rest of a > plane, but isolated. Current and voltage are two parts of the power flow. > Impedance (resistance, capacitance, inductance) affects the overall picture. > The confinement of the return path the way we've defined it is because of > the planes - because of the impedances involved - in addition to the other > high frequency issues such as skin depth. > > I'd love to see the difference between a plane reference and a strip > reference that *should* contain the entire return current. It may be the > two solutions are the same. But it may present very different results. I > haven't done studies on the return current issue, but my gut says that if we > ditch the ground plane, the assumptions we make at high frequency also go > out the window. > > - John_H > > From my experience, a strip reference is the same as a plane. There are a number of issues here, not least that we are returning low speed high currents on the same plane that we are returning high speed currents. For low speed (DC or close to it) currents, the entire plane is the return path. As the speeds increase, the return path becomes more and more constrained, primarily due to inductance of the return path. The return path would be identical [in width] to the signal path at infinite frequencies, for the above postulate. For reasonably high speed signals (at 1.25GHz fundamental, for instance) 90% or so is constrained within those bounds. When looking at a plane, one must ask what the reference problem is; for a 1/4 wave antenna, the entire zone is required to make the reflected antenna operate properly (because it is reflected - it's not really the antenna); for a signal return, a plane is not necessary. This is borne out (when one thinks about it) by the principle of coplanar waveguide. So - is a plane necessary? Usually, yes; and it's usually a very good idea, but at high speed it's not a 'plane' in the ordinary sense. Cheers PeteSArticle: 123676
On Aug 31, 11:42 am, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > Does anybody have VHDL code to > run the mouse port on an ML40x dev board? > > Brad Smallridge > Ai Vision You do know that the mouse port is a PS/2 port? A google for "ps2 vhdl" gets three different sources in the 1st four hits. G.Article: 123677
Just as a follow-up --- the problem went away when I switched from Ubuntu to Fedora Core 5. Bob Bob Smith wrote: > Downloaded ISE 9.2i day before yesterday. Installed t9_2_02i_lin update > and am just going through the counter example in the "ISE 9.1i Quick Start > Tutorial" that is in .../doc/usenglish/books/docs/qst/qst.pdf > > Everything works until I try to enter the timing constraints. Double- > clicking "Create Timing Constraints" runs the implement_design function > which ends with the error: Process "Translate" failed. > > This seems similar to a posting by Matthias Alles about "xst fails..." > and I did a process_cleanup_files as suggested in that thread. > > My output is given below. > > Any ideas how to get past this?Article: 123678
Wei Wang wrote: > I thought the bit files generated by Xilinx ISE should be in plain > binary format, but actually the .bit file is unreadable when opened in > XEmacs, just wondering whether it is possible to make these bit files > readable? Many thanks, -Wei Xilinx used to have either BIT files or RBT files. The BIT files use all bits of each byte, the RBT files are an ASCII image, with each byte being an ASCII 0 or 1 character, and so are eight times larger. It is pretty easy to write a C program to convert between them. -- glenArticle: 123679
"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message news:1188331867.465434.221240@22g2000hsm.googlegroups.com... > On 28 Aug., 15:23, "maxascent" <maxasc...@yahoo.co.uk> wrote: >> Hi >> >> I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a >> general rule of how many layers the pcb will need to route out all the >> pins? > > Most other posts are focussing on signal routing. But for FX this > really is > the least of your problems. The answer depends a lot on the MGT > performance > you are looking at. The MGTs need many supply voltages. Each of them > should > be filtered individually for high data rates. This means you either > need many islands, > which reduce plane capacitance and increase plane inductance. Or you > need many, > many planes. > For lower data rates (1.25gbps) you should be able to combine supplies > that have > the same voltage. This is not recommended by Xilinx, so your milage > might vary. > > Also, the MGTs pretty much prevent routing out signals on the top > layers. > As a result, an FX that uses all MGTs will need more layers than an > LX. > We use 14 layers for an FX60-FF1152 with 12 MGTs at 5gbps. > > Kolja Sulimma > Hi Kolja, Although your suggestions will result in a working solution, I respectfully think you're overengineering this. The power supplies to the MGTs don't need islands or a plane. A 0402 cap right by the ball, fed from a ferrite is as good bypassing as you're going to get. The ferrite can be on the reverse side or far away from the device. All the stuff you read about plane capacitance is over-rated for bypassing ICs, including BGAs. The inductance of the BGA's balls and connections to the die stuff means that the admittedly ultra high Q of the plane capacitance is not much use at all, so why bother even trying? In this situation, with the power pins neear the edge of the part, it's much more useful to keep the ground plane as close to the surface as possible, than to worry about power planes. The microvia solution works perfectly for MGTs as these vias are more or less transparent to very high speeds indeed. Anyway, that's my experience. HTH., Symon.Article: 123680
Guys, I saw this on Slashdot. http://nsa.unaligned.org/ Interesting article about a guy who used some rescued FPGA boards to do some number crunching. Also, there's a cool JTAG tool. Cheers, Syms.Article: 123681
>"comp.arch.fpga" <ksulimma@googlemail.com> wrote in message >news:1188331867.465434.221240@22g2000hsm.googlegroups.com... >> On 28 Aug., 15:23, "maxascent" <maxasc...@yahoo.co.uk> wrote: >>> Hi >>> >>> I am designing a pcb with a Virtex 4 FX in a FF672 package. Is there a >>> general rule of how many layers the pcb will need to route out all the >>> pins? >> >> Most other posts are focussing on signal routing. But for FX this >> really is >> the least of your problems. The answer depends a lot on the MGT >> performance >> you are looking at. The MGTs need many supply voltages. Each of them >> should >> be filtered individually for high data rates. This means you either >> need many islands, >> which reduce plane capacitance and increase plane inductance. Or you >> need many, >> many planes. >> For lower data rates (1.25gbps) you should be able to combine supplies >> that have >> the same voltage. This is not recommended by Xilinx, so your milage >> might vary. >> >> Also, the MGTs pretty much prevent routing out signals on the top >> layers. >> As a result, an FX that uses all MGTs will need more layers than an >> LX. >> We use 14 layers for an FX60-FF1152 with 12 MGTs at 5gbps. >> >> Kolja Sulimma >> >Hi Kolja, > >Although your suggestions will result in a working solution, I respectfully >think you're overengineering this. The power supplies to the MGTs don't need >islands or a plane. A 0402 cap right by the ball, fed from a ferrite is as >good bypassing as you're going to get. The ferrite can be on the reverse >side or far away from the device. All the stuff you read about plane >capacitance is over-rated for bypassing ICs, including BGAs. The inductance >of the BGA's balls and connections to the die stuff means that the >admittedly ultra high Q of the plane capacitance is not much use at all, so >why bother even trying? In this situation, with the power pins neear the >edge of the part, it's much more useful to keep the ground plane as close to >the surface as possible, than to worry about power planes. > >The microvia solution works perfectly for MGTs as these vias are more or >less transparent to very high speeds indeed. > >Anyway, that's my experience. > >HTH., Symon. > > > > Symon, do you follow the recommended filtering from the Xilinx MGT guide i.e. caps and ferrites next to the BGA for all the supplies? JonArticle: 123682
On Thu, 30 Aug 2007 15:36:04 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"maxascent" <maxascent@yahoo.co.uk> wrote in message >news:ifidnQIYxf3YUUvbRVn_vw@giganews.com... >> >> Hi >> >> If I am designing a pcb using impedance controlled layers can I treat the >> power planes as a reference layer as well as the gnd layers? >> >> Cheers >> >> Jon > >Hi Jon, >Yes. But with a caveat. When your signals switch reference layers, make sure >there is a path for the reference current. > >E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal goes >from layer 1 to 6 through a via, you should have a bypass cap bewteen power >and ground near this via. That's not necessary. There's already so much plane-plane capacitance that the planes are already equipotential as far as the tiny charge injected by the signal trace can affect them. Really, on a board with, say, 3000 vias, are you going to put a bypass via near every signal via? I've heard of people asking for two! JohnArticle: 123683
On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi Kolja, > My opinion is when VHDL compilers get more information about mutually > exclusive information, what you can do, the VHDL compilers can do > better. Yes. But mutual exclusiveness is only a small, special case of input don't cares (unreachable input combinations). The tools shoul dhave ways to specify these, not only mutual exclusiveness. For example there might a vernier input that only has the valid combinations "0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not provide this hint, assertions can. Because of this the assertion based approach is allready part of VHDL2006. It is a very general approach, and of course there are special cases for which a special keyword makes live easier, but you still need to solve the general case. (Imaging how much simpler the design of a polynomial interpolation would be, if VHDL had a polynomial type and an interpolation keyword) Because the formulation of these inputs sets can be a little cumbersome, and because there might be sequential depencies on these (and for a couple of other reasons) PSL was included as a way to specify assertion constraints. > The above equation would be implemented in Xilinx chip with carry > chain with initial input data to the carry chain being OutBus. It will be synthesized to a gated or netlist. This is very the VHDL- specific part ends. The technology mapper will than select an appropriate implementation for the or gate that might be based on a carry chain implementation. > The > following enable equation would be eliminated from Jim's coding: > (E0 or E1 or E2 or E3 or E4 or E5) = '1' Yes. The formulation is redundant, even without knowledge of the input don't cares. > The above two example show that with mixed 'elsif' and 'orif' > language branch statement structure, HDL will provide more powerful and > concise way to deal with mutually ... But nothing else but that. That is not enough. > You are a doubtor of the technology, How is that? I am the one that is telling you that your approach is to limited and does not utilize the power of logic synthesis to the possible extend. Handling of input don't cares is solved since the days of ATPG based synthesis. As far as coding style goes: I prefer prefer to explicitly code that the result is a don't care for certain input conditions as to have this as an implicit side effect of an operation. Kolja Sulimma P.S.: Here is another coding style, assuming the inputs and Es are in arrays: output := (others =>'-'); -- this line allows the compiler to do the optimization, most compilers DECIDE against it for i in input'range loop if e = (i=>'1', others=>'0') then output := intput(i); end loop; if you know the optimization and want to force it: for i in input'range loop if e(i) = '1' then output := output or intput(i); end loop;Article: 123684
mmihai wrote:
> On Aug 23, 8:33 am, mmihai <iia...@yahoo.com> wrote:
>> On Aug 23, 3:34 am, Frank Buss <f...@frank-buss.de> wrote:
>>
>>> bhb wrote:
>>>> for (j = 1; j<=1000; j++)
>>>> {
>>>> for (k = 1; k<=1000; k=k+1)
>>>> {
>>>> result=k*k*a+j*b+c;
>>>> }
>>>> }
>>> You can improve the speed of this code by a factor of 1 million:
>>> result=1000*1000*a+1000*b+c
>> Yes, you can, but your reduction of the sum of sum it is not
>> correct ...
>> Try again :-)
>
> My bad, I've read result+=...
>
> --
> mmihai
Actually, even if it was +=, as long as the boundaries are fixed, the two
loops can be reduced by pre-calculating the sums of j and k^2...
1) sum of j over 1..1000 = 500500
Rewrite after eliminating the 'j' loop:
>>>> for (k = 1; k<=1000; k=k+1)
>>>> result += 1000*k*k*a + 500500*b + 1000*c;
2) sum of k^2 over 1..1000 = 333833500
Rewrite after eliminating the 'k' loop:
>>>> result = 333833500000*a + 500500000*b + 1000000*c;
There you are, the result of even += through the two loops without any loops.
Article: 123685ajith.thamara@gmail.com wrote: > Can you explain how to do this. > What modification should I do in the code. Probably just send a few bytes after the bitstream (just send some zeroes). At least that's what I often have to do if I load bitstreams from the outside (using a microcontroller on the FPGA's slave serial interface). HTH, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123686
"Symon" <symon_brewer@hotmail.com> wrote in message news:fbbii8$l8l$1@aioe.org... > "comp.arch.fpga" <ksulimma@googlemail.com> wrote in message > news:1188331867.465434.221240@22g2000hsm.googlegroups.com... > A 0402 cap right by the ball, fed from a ferrite is as good bypassing as > you're going to get. The ferrite can be on the reverse side or far away > from the device. It can also be non-existent (i.e. tie right to the power plane instead of putting the series ferrite in). The ferrites are a band aid to not having a low impedance voltage source feeding the IC in the first place. Design the planes to have the proper impedance to deliver the required current over the operating frequency range in the first place and the voltage ripple will be within spec and you'll rightly start to question just what the ferrites bring to the table. But if you insist on ferrites, don't forget that they are basically inductive (by intent) and then be careful about your bypassing caps since those Ls and Cs do form a resonant structure that is more likely to cause a problem with a poor choice of C then the plane was in the first place. In other words, the 'output side' of the ferrites need to have the same set of low/mid/high frequency range bypass caps as you (hopefully) already provided on that supposedly nasty, noisy 'input side'. > All the stuff you read about plane capacitance is over-rated for bypassing > ICs, including BGAs. It provides a low inductance current source but is not a relatively deep bucket of charge to draw from due to the low C/area. In any case, whether a full plane or strip it has some L and C and therefore Z that contributes to the IC's view of the voltage source...along with the bypass C and the PCB stackup, etc. > The inductance of the BGA's balls and connections to the die stuff means > that the admittedly ultra high Q of the plane capacitance is not much use > at all, so why bother even trying? I'd say, bother to analyze it first to determine what the Z requirements of the PCB need to be to source the power than to just blindly say why bother trying....but from earlier posts I also know you've done this as well so probably have a better grasp of the issues and tradeoffs in the first place. KJArticle: 123687
On 31 Aug., 16:39, Simon <goo...@gornall.net> wrote: > Antti, did you ever get a feel for what memory bandwidth you actually > get with this setup ? For example, if you had a blockram being > constantly filled from DDR2 ram, how many MB/sec you can actually pull > over the bus ? > > Wondering whether to buy (yet another) starterkit ... [grin] > > Cheers, > S. sorry, no :( i wanted the s3a kit just to test the new s3a features like multiboot have plenty of kits so can choose something for more performance if needed so cant help AnttiArticle: 123688
On 31 Aug., 22:27, "John_H" <newsgr...@johnhandwork.com> wrote: > Is this a legitimate post? It comes across as an intelligent phrase > generator that has some sense of electronics but in general the phrases > don't come across as cohesive concepts. > > If it is legit, robin, please consider what you're trying to communicate. > Maybe rereading the post will make you realize your phrasing leaves too m= uch > to the readers' imagination. > > "robin" <robinhood...@gmail.com> wrote in message > > news:1188589451.821393.49110@i38g2000prf.googlegroups.com... > > > > > Chip Designing Made easy To Understand the "World of Miniaturization" > > and Appreciate the "Art of Chip Design" a senior citizen in the field > > of Chip Design Industy Shares his Design Expertise. > > > Explains to Understand in a Birds Eye View point analogy of VLSI Chip > > Architecture with an Building Construction Architecture, Detailed VLSI > > Chip Design Flow, Enables Architectural Discussions and Thoughts in > > Us, by querying ourselves if we are playing a role of a Chief > > Architect, Best Design Practices in Front end & Backend world, > > Discusses Todays hot topics and design issues, Checklists and lessons > > learnt, > > > Learn the concepts of chip designing by visiting for free > >http://www.vlsichipdesign.com/knowledgehome.html > > > I found this link, > >http://www.microchip.com/wiki/- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - hahaah very funny - ASIC design website with "H1B visa FAQ" =EDn the main page main menu!! AnttiArticle: 123689
On Sep 1, 9:24 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 1 Sep., 02:13, Weng Tianxiang <wtx...@gmail.com> wrote:> Hi Kolja,
> > My opinion is when VHDL compilers get more information about mutually
> > exclusive information, what you can do, the VHDL compilers can do
> > better.
>
> Yes. But mutual exclusiveness is only a small, special case of input
> don't cares
> (unreachable input combinations). The tools shoul dhave ways to
> specify these,
> not only mutual exclusiveness.
> For example there might a vernier input that only has the valid
> combinations
> "0000", "0001", "0011", "0111", "1111". Mutual exclusiveness can not
> provide this hint,
> assertions can. Because of this the assertion based approach is
> allready part of VHDL2006.
> It is a very general approach, and of course there are special cases
> for which a special
> keyword makes live easier, but you still need to solve the general
> case.
> (Imaging how much simpler the design of a polynomial interpolation
> would be, if VHDL had a
> polynomial type and an interpolation keyword)
>
> Because the formulation of these inputs sets can be a little
> cumbersome, and because there
> might be sequential depencies on these (and for a couple of other
> reasons) PSL was included
> as a way to specify assertion constraints.
>
> > The above equation would be implemented in Xilinx chip with carry
> > chain with initial input data to the carry chain being OutBus.
>
> It will be synthesized to a gated or netlist. This is very the VHDL-
> specific part ends.
> The technology mapper will than select an appropriate implementation
> for the or gate that
> might be based on a carry chain implementation.
>
> > The
> > following enable equation would be eliminated from Jim's coding:
> > (E0 or E1 or E2 or E3 or E4 or E5) = '1'
>
> Yes. The formulation is redundant, even without knowledge of the input
> don't cares.
>
> > The above two example show that with mixed 'elsif' and 'orif'
> > language branch statement structure, HDL will provide more powerful and
> > concise way to deal with mutually ...
>
> But nothing else but that. That is not enough.
>
> > You are a doubtor of the technology,
>
> How is that? I am the one that is telling you that your approach is to
> limited and
> does not utilize the power of logic synthesis to the possible extend.
> Handling of
> input don't cares is solved since the days of ATPG based synthesis.
>
> As far as coding style goes: I prefer prefer to explicitly code that
> the result is a don't care
> for certain input conditions as to have this as an implicit side
> effect of an operation.
>
> Kolja Sulimma
>
> P.S.: Here is another coding style, assuming the inputs and Es are in
> arrays:
>
> output := (others =>'-'); -- this line allows the compiler to do the
> optimization, most compilers DECIDE against it
> for i in input'range loop
> if e = (i=>'1', others=>'0') then output := intput(i);
> end loop;
>
> if you know the optimization and want to force it:
> for i in input'range loop
> if e(i) = '1' then output := output or intput(i);
> end loop;
Hi Kolja,
> The
> following enable equation would be eliminated from Jim's coding:
> (E0 or E1 or E2 or E3 or E4 or E5) = '1'
Yes. The formulation is redundant, even without knowledge of the
input
don't cares.
No, Jim's coding is the best coding we can do now. The equation is
never redundant !
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;
I write his type of coding everywhere in my design. It is really not a
high level language, but a ASM language writing at flip-flop levels in
name of high level language.
But if 'orif' is a new keyword, the situation may change, at least
from paper and theory. There is no FPGA VHDL compiler today that can
generate better code than Jim's coding.
That is the reason:
What you can do, VHDL compiler can do it better if it gets all
information about mutual exclusiveness.
As far as "don't care" situation is concerned, VHDL compile ignores it
at all. It is not a VHDL problem, it is a compiler problem. You must
distinguish VHDL language problem from compiler capability problem.
Thank you.
Weng
Article: 123690On Aug 30, 2:44 pm, markus.j...@gmx.de wrote: > Hello, > > I am working with xilinx (Spartan 2E). The DSP is off chip. > > I hope I found the problem today. You are right. It was > a timing issue. I have an Input to the state machine that doesn't met > the timing > requirements. > > It is a ready signal that is generated from a device. > After the read strobe the device asserts a ready signal. I > doublechecked the > timing of this pin again and found out that it is difficult to met > timing from > the clock cycle (where read strobe goes low) to the max delay of the > activated > ready signal within a clock cycle. I thought the ready signal is > stable long befor the next > rising clock edge occurs (bit it isn'nt). > > Now I do synchronisation and put some sync states in the state machine > to get a > synchronous ready signal. > > I let you know about the result. > > Thanks a lot for your help. Hi, Just out of curiosity, what do you mean by _sync states_? (I'm a noob as you can probably see, but at least I'm curious.... ) KunalArticle: 123691
Hi, Really sorry for not snipping stuff off...... KunalArticle: 123692
Hi everyone,
I'm experiencing something weird in my code implementation that leaded
me to question which is the correct way to enable a flip-flop.
Assuming I have a clocked output of a FF one cycle long (*en*) which
will enable two different sequential logics according to the value of
a signal *sel*, so *en1* and *en2* will be produced.
Which is the best way to produce *en1* and *en2*?
When I designed the logic the first time I was doing something like
this:
process (clk, nrst)
begin
if nrst = '0' then
en1 <= '0';
en2 <= '0';
elsif rising_edge (clk) then
if sel = '0' then
en1 <= en;
en2 <= '0';
else
en1 <= '0';
en2 <= en;
end if;
end if;
end process;
but then I thought it would have been as good as if I wrote (i didn't
care about the timing so it doesn't matter if *en1* and *en2* occur
earlier than what was in the previous implementation):
en1 <= en when sel = '0' else
'0';
en2 <= en when sel = '1' else
'0';
but unfortunately this shows some timing problem on my device because
sometimes the test vectors work and sometimes they look like the *en1*
or *en2* signal are not there (as if they where not one clock cycle
long).
I know the difference in the implementation of these two sets of logic
and i would consider the first one the best one a priori but I would
like someone could explain me if it is possible that the second
solution does not guarantee the signals *en1* and *en2* to be one
clock cycle long (or at least respect setup and hold time for the
driven FF)?
I had the thought that maybe the thresholds variation may effect the
phase of a signal but I don't think this is enough to explain the
problem.
Thanks for your attention.
Al
Article: 123693al.basili@gmail.com schrieb: > process (clk, nrst) > begin > if nrst = '0' then > en1 <= '0'; > en2 <= '0'; > elsif rising_edge (clk) then > if sel = '0' then > en1 <= en; > en2 <= '0'; > else > en1 <= '0'; > en2 <= en; > end if; > end if; > end process; ... > en1 <= en when sel = '0' else > '0'; > > en2 <= en when sel = '1' else > '0'; ... > I know the difference in the implementation of these two sets of logic > and i would consider the first one the best one a priori but I would > like someone could explain me if it is possible that the second > solution does not guarantee the signals *en1* and *en2* to be one > clock cycle long (or at least respect setup and hold time for the > driven FF)? With the 1st solution you sample the signals en and sel. The outputs of the flipflops en1 and en2 are stable from the rising edge of clk to the next rising edge. Meanwhile en and sel may be hazarderous. With the flipflop solution these hazards are no problem, but for the 2nd combinational solution this may be a problem. Furthermore: If you use flipflops, then you break a timing path from the points where en and sel are driven to the points where en1 and en2 are read. With the flipflops you split this path into to paths. RalfArticle: 123694
On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote: > As far as "don't care" situation is concerned, VHDL compile ignores it > at all. It is not a VHDL problem, it is a compiler problem. You must > distinguish VHDL language problem from compiler capability problem. Finally you get my point. There is no need to change the language, you only need to change the compiler to support the existing language features: - interpretation of assertions to deduce reachability don't cares. - honoring output observability don't cares coded as '-' during optimization Again: The existing language features can do a lot more than mutual exclusiveness. You only need compilers that use them. Adding a keyword for a special case to the language will only delay adoption of the general case. Kolja SulimmaArticle: 123695
On Sep 2, 3:23 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 2 Sep., 02:14, Weng Tianxiang <wtx...@gmail.com> wrote: > > As far as "don't care" situation is concerned, VHDL compile ignores > it > > > at all. It is not a VHDL problem, it is a compiler problem. You must > > distinguish VHDL language problem from compiler capability problem. > > Finally you get my point. There is no need to change the language, you > only > need to change the compiler to support the existing language features: > - interpretation of assertions to deduce reachability don't cares. > - honoring output observability don't cares coded as '-' during > optimization > > Again: The existing language features can do a lot more than mutual > exclusiveness. > You only need compilers that use them. Adding a keyword for a special > case to the > language will only delay adoption of the general case. > > Kolja Sulimma Hi Kolja, "at all. It is not a VHDL problem, it is a compiler problem. You must distinguish VHDL language problem from compiler capability problem. " In above sentence, what I had refered to is the case of 'dont' care' you mentioned in your example, not the 'orif' case. Verilog introduction of 'unique' and other related functions has showed that mutually exclusiveness in HDL needed to be added and improved. WengArticle: 123696
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:oduid31vs6ln11b62visqug6ql7rostl1f@4ax.com... >> >>Hi Jon, >>Yes. But with a caveat. When your signals switch reference layers, make >>sure >>there is a path for the reference current. >> >>E.g. Take a 6 layer board, layer 2 ground, layer 5 power. If the signal >>goes >>from layer 1 to 6 through a via, you should have a bypass cap bewteen >>power >>and ground near this via. > > > That's not necessary. There's already so much plane-plane capacitance > that the planes are already equipotential as far as the tiny charge > injected by the signal trace can affect them. > > Really, on a board with, say, 3000 vias, are you going to put a bypass > via near every signal via? I've heard of people asking for two! > > John > Hi John, I wish that was always the case! There are problems relying solely on the interplane capacitance. There will be an impedance discontinuity at the via no matter what, but using solely the interplane capacitance increases this discontinuity. Clearly the inductance of the signal in this case is higher. Also, if a bus does the transistion, all the even mode effects add up. Finally, the high Q of the planes means you are vulnerable to plane resonances. http://www.sigrity.com/papers/epep2000/QC-JZ-EPEP2000-Final.pdf http://www.hottconsultants.com/techtips/pcb-stack-up-6.html http://dspace.kaist.ac.kr/bitstream/10203/664/1/effectof.pdf Clearly putting a bypass cap at every via is impractical, and if you re-read my post, that is not what I suggested. However, I stand by my recommendation that in places where many nets and/or critial nets change reference planes, a bypass capacitor nearby is important. Clearly, a single capacitor, perhaps connected with multiple vias to the planes, can be shared by many signal vias, as it will have a lot more capacitance than, for example, the planes can provide. HTH., Syms.Article: 123697
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:2vqdnfKs0-uR7UTb4p2dnAA@giganews.com... > > Symon, do you follow the recommended filtering from the Xilinx MGT guide > i.e. caps and ferrites next to the BGA for all the supplies? > > Jon Hi Jon, Yes for the caps and ferrite. I disagree with their recommendation for linear regulators to filter the supplies as these regulators do not have sufficient bandwidth to control noise > a few 100kHz. I use passive filtering also to cover the range from the linear regs up until the ferrites work. HTH., Syms.Article: 123698
On 31 avg., 14:31, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 30 Aug 2007 01:59:33 -0700, Guru <ales.gor...@email.si> wrote: > >Hi all, > > >We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB > >x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as > >possible the DDR termination presents a problem. Since the Spartan3E > >does not have DCI, termination on chip is not possible. This means > >that 44 termination resistors should be added and maybe a VTT power > >source. The other problem is that according to MIG we should connect > >DDR to two banks. > > >Any good suggestions? > >Is it possible to eliminate termination resistors? > > As Gabor suggests, it may be possible to eliminate the series > terminations if traces are kept short enough. > > If you also want to eliminate the parallel terminations to VTT, consider > moving to DDR-II, where you can use the On-Die Termination (ODT) > instead. It means a little extra design complexity, and 1.8V supplies, > but if space is important enough it may be worth considering. > > - Brian We already considered using a DDR2 since it enables ODT. The only thing I am afraid of is the minimal frequency of 125MHz. This means that carefull FPGA pinout selection is a must (e.g MIG layout). The other problem are huge memory controllers; MCH_OPB_DDR2 takes approx 1500 slices. What about 8 bit DDR2? This way I can get away with only one FPGA bank and layout to MIG rules. Did anyone used it with MPMC2 (x8 is not supported by MCH_OPB_DDR2)? Cheers, GuruArticle: 123699
Hi, some comments in line... "KJ" <kkjennings@sbcglobal.net> wrote in message news:RxhCi.4629$JD.252@newssvr21.news.prodigy.net... > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:fbbii8$l8l$1@aioe.org... >> "comp.arch.fpga" <ksulimma@googlemail.com> wrote in message >> news:1188331867.465434.221240@22g2000hsm.googlegroups.com... >> A 0402 cap right by the ball, fed from a ferrite is as good bypassing as >> you're going to get. The ferrite can be on the reverse side or far away >> from the device. > It can also be non-existent (i.e. tie right to the power plane instead of > putting the series ferrite in). The ferrites are a band aid to not having > a low impedance voltage source feeding the IC in the first place. Design > the planes to have the proper impedance to deliver the required current > over the operating frequency range in the first place and the voltage > ripple will be within spec and you'll rightly start to question just what > the ferrites bring to the table. > Remember that the ferrites are useful in both directions. Not only to they stop noise getting to the MGT, but prevent the noise from the MGT getting back to the supply and interfering with other stuff powered from it. > > But if you insist on ferrites, don't forget that they are basically > inductive (by intent) and then be careful about your bypassing caps since > those Ls and Cs do form a resonant structure that is more likely to cause > a problem with a poor choice of C then the plane was in the first place. > In other words, the 'output side' of the ferrites need to have the same > set of low/mid/high frequency range bypass caps as you (hopefully) already > provided on that supposedly nasty, noisy 'input side'. > OK, but ferrites are deliberately lossy. A useful model is an indcutor in series with a resistor. This means bad resonances don't happen with ferrites. Cheers, Syms.
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