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
Hi Sylvain, The BUFIO delay is now up to about 600 ps longer. We haven't looked at workarounds for this, but it must be compensated for. I am sure you could find something. What frequency are your running your interface? What width and what speed grade do you use? The Virtex-5 DDR2 controller is getting some speed improvements shortly that might help your timing. I realize that it won't help with your modifications, so it may not be a reasonable alternative for you. Regards, John "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in message news:1188204443.755958.69530@50g2000hsm.googlegroups.com... > Hi, > > Thanks for the info, at least that gives some leads. > > > On Aug 27, 9:19 am, "John Schmitz" <john.schm...@noemail-xilinx.com> > wrote: >> In Virtex-5 the BUFIO delay is larger which alters the initial position >> of >> the DQ relative to the DQS. The existing Virtex-4 SERDES DDR2 algorithm >> (XAPP721/723) won't handle this. > > How much larger ? > How could that be adapted ? > Wouldn't changing the default value of the delay to the trick ? > >> What's the need for the half frequency design in Virtex-5? Could you use >> the full frequency design with a shim to conver the data to half speed? > > The thing is that we customized this controller to fit our needs and > we'd rather > stick to it. It also has a much easier time meeting timing that the V5 > controller > because a lot of the logic runs at half the frequency. > > > > Sylvain >Article: 123476
On Aug 28, 12:21 pm, Jim Lewis <j...@synthworks.com> wrote:
>
> I noted that in your code you mixed orif mixed with elsif (copied below),
> was this intentional? One hand, these could convey exactly what I want
> (because there are many cases like this), OTOH, it could be a mistake.
> Hence the intent is ambiguous and during a design review, one would have
> to pay particular attention to this and ask questions about your intent
> and its validation. A copy of your code is below.
>
> If(E0 = '1') then
> State_A <= E0_S;
> Orif(E1 = '1') then
> State_A <= E_S;
> Orif(E2 = '1') then
> State_A <= E2_S;
> elsIf(E3 = '1') then
> State_A <= E3_S;
> Orif(E4 = '1') then
> State_A <= E4_S;
> Orif(E5 = '1') then
> State_A <= E5_S;
> elsIf(E6 = '1') then
>
> On the other hand, with assertions, the following assertions
> allow the above code to be written using elsif. In addition,
> in this case, it is very clear about which I want to be
> mutually exclusive.
> assert zero_one_hot (E0, E1, E2) ;
> assert zero_one_hot (E3, E4, E5) ;
I would have (perhaps mistakenly?) interpreted the orif/elsif syntax
as:
also meaning:
assert zero_one_hot(E0, E1, E2, E4, E5);
My point (and Jim's) is that this is one very good reason why such a
seemingly simple language change is not a good idea when you look
under the hood.
Actually, would the correct syntax be:
assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument
or does the psl zero_one_hot() function actually accept a variable
number of arguments?
I would really like to see one_hot() and zero_one_hot() as standard
vhdl (not just psl) functions, usable in an assert statement for this
purpose. The reason is that I don't see synthesis vendors using PSL at
any point in the future (there's just way too much there that would
never be relevant to synthesis). But they could easily parse simple
vhdl assertions with specific, standard functions to extract
meaningful information about the description.
As to the use of enumerated types, that works fine, as long as you
have access to the source of the signals, where you can re-create them
as an enumerated type. If they are primary (chip level) inputs, you do
not have a choice. And you cannot "translate" them into an enumerated
type, since the translation will incorporate priority logic of some
sort.
There are many cases where the tools could do a better job of
inferring mutual exclusivity:
enable := (others => '0');
for i in enable'range loop
if address = i then
enable(i) := '1';
end if;
end loop;
Most synthesis tools can figure out that enable is zero_one_hot.
Where the problem comes in is that if you want to use enable in the
next clock cycle (or later). After all, if you only needed to use it
immediately, you would dispense with the enable vector, and just put
the action that "enable" enables in the if-then statement directly.
But as soon as you want to store the enables for a clock cycle or
more, every synthesis tool I've seen fails to realize that enable is
still mutually exclusive. So far, the only solutions that I've seen
include manually coding an and-or tree (unreadable), coding it as tri-
state logic (and letting the tool convert to multiplexers; misleading,
and does not handle zero_hot), or coding it in the same clock cycle,
and using register retiming to spread it back out (not entirely
reliable, and not generally extensible past one clock cycle).
Andy
Article: 123477
On Aug 28, 10:21 am, Jim Lewis <j...@synthworks.com> wrote:
> Weng,
>
> > Hi,
> > I open a new topics from previous one to try to stir another round to
> > introduce a new keyword 'orif'.
>
> My conclusion from our numerous previous discussions
> on this topic are that for simple cases it looks
> intuitive and makes the syntax look deceptively
> attractive, however, for more interesting conditions,
> it becomes difficult if not impossible to identify the
> mutually exclusive items and, hence, you will get
> little to no benefit from it. So I was tickled to see
> that SystemVerilog decided to implement something similar
> to this, however, I would suspect that they do not give
> you quite the flexibility that you want.
>
> On the other hand, as I mentioned previously and Andy
> pointed out in the thread you quoted (repeated below):
> "For dynamic mutex inputs, verification is best
> handled in an assertion. If a standardized one_hot() or zero_one_hot()
> function could be created (to operate on an unconstrained vector of
> booleans, for example), then synthesis could recognize their use in an
> assertion, and make the appropriate optimizations automatically,
> without affecting the syntax or structure of the language. The
> assertion (or other code) could also control what happens when, in
> fact, the conditions are not mutually exclusive (the same way the
> language handles indices out of bounds, etc.). In other words, in
> order to gain that level of control over what happens if mutex is not
> true, you'd have to use the same amount of code for either solution,
> and the latter solution does not require a change to the language."
>
> I also note that some synthesis tools have started to support assertions
> in synthesis. Synthesis support is a separate topic and is similar
> whether it is an assertion or a built-in language feature.
>
> For your code of the form:
> If(E0 = '1') then
> State_A <= E0_S;
> Orif(E1 = '1') then
> State_A <= E_S;
> Orif(E2 = '1') then
> State_A <= E2_S;
>
> The assertion that would allow this code to be written with only elsif is:
> assert zero_one_hot (E0, E1, E2) ;
>
> I noted that in your code you mixed orif mixed with elsif (copied below),
> was this intentional? One hand, these could convey exactly what I want
> (because there are many cases like this), OTOH, it could be a mistake.
> Hence the intent is ambiguous and during a design review, one would have
> to pay particular attention to this and ask questions about your intent
> and its validation. A copy of your code is below.
>
> If(E0 = '1') then
> State_A <= E0_S;
> Orif(E1 = '1') then
> State_A <= E_S;
> Orif(E2 = '1') then
> State_A <= E2_S;
> elsIf(E3 = '1') then
> State_A <= E3_S;
> Orif(E4 = '1') then
> State_A <= E4_S;
> Orif(E5 = '1') then
> State_A <= E5_S;
> elsIf(E6 = '1') then
>
> On the other hand, with assertions, the following assertions
> allow the above code to be written using elsif. In addition,
> in this case, it is very clear about which I want to be
> mutually exclusive.
> assert zero_one_hot (E0, E1, E2) ;
> assert zero_one_hot (E3, E4, E5) ;
>
> Also note that if you are using std_logic or bit types, with the
> Accellera VHDL-2006 revision you can write:
> 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;
>
> You can also leave out the = '1' in VHDL-2006:
> if E0 or E1 or E2 or E3 or E4 or E5 then
>
> I also note that SystemVerilog added the keywords priority and
> unique. The danger in adding new keywords is that they may
> conflict with a name (signal, ...) already used in someone's design
> and cause an old design to be a syntax error in the new language
> revision. This generally does not please people and means they
> have to add special handling for the file (compile flags).
>
> What we need in the future revisions of the language is capability.
> This does not necessarily mean adding new keywords.
>
> > 7. Mutually exclusiveness is ubiquitout in logic design ...
> I agree with this part. The language needs a capability to effectively
> handle mutual exclusion.
>
> The PSL extension brings us one_hot and zero_one_hot functions.
> These functions are visible within a PSL assert statement (but not
> a VHDL assert statement). As a result as long as you used a form
> of assert that is compatible with PSL, you can do this with any
> simulator or synthesis tool that supports Accellera VHDL-2006.
> If the tool does not support it, you can file a bug and/or
> enhancement against it to get the feature added.
>
> If you wish to continue this discussion, please re-post (from 1 year
> ago?) that show your more complex examples, identify the conditions
> that you want to be mutually exclusive, and explain how you think
> a tool should extract/determine those conditions.
>
> Best,
> Jim
Hi Jim,
"I agree with this part. The language needs a capability to
effectively
handle mutual exclusion."
1. This is a step forward from my point of view.
2. We have to admit that there are many ways to do it.
3. My example is right and intend to do that. See my answer to
Jonathan Bromley.
4. Keyword 'orif' can be inserted in any places in a 'if' statement to
specify any group of conditions having mutually exclusiveness.
5. Your method using
assert zero_one_hot (E0, E1, E2) ;
assert zero_one_hot (E3, E4, E5) ;
is OK.
Here is an example that shows your method's drawback you have to
admit:
if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);
orif(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
You have to write 5 more statements than mine:
signal A1 : boolean;
signal A2 : boolean;
assert zero_one_hot (A1, A2) ;
A1 <= TWindowLoad_E0_L_H and nC_BE_R0(3) = '0';
A2 <= TWindowLoad_E0_H_H and nC_BE_R0(7) = '0';
if(A1) then
TWindow_3(10 downto 8) <= AD_R0(26 downto 24);
elsif(A2) then
TWindow_3(10 downto 8) <= AD_R0(58 downto 56);
end if;
The more signals are invovled, the more statements are added, and more
likely it is possible to be wrong or missing something.
6. The keyword 'orif' is defined to refer to carry chain structure in
FPGA to get essential timing advantages over other competing methods.
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2 + OutBus;
Because 'else' and its null statement are defaulted.
Its carry chain bottom initial input data should be OutBus(i).
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
else
OutBus(63 downto 0) <= Zero_64;
end if;
It is logically defined as the following:
if(E0 = '1' or E1 = '1' or E2 = '1') then
if(E0 = '1') then
OutBus(63 downto 0) <= Data0(63 downto 0);
orif(E1 = '1') then
OutBus(63 downto 0) <= Data1(63 downto 0);
orif(E2 = '1') then
OutBus(63 downto 0) <= Data2(63 downto 0);
end if;
else
OutBus(63 downto 0) <= Zero_64;
end if;
Its implementation equation should look like this:
OutBus = E0*Data0 + E1*Data1 + E2*Data2;
Its carry chain bottom initial input data should be '0'.
How efficient it is to refer to carry chain in FPGA.
Weng
Article: 123478Andy, > On Aug 28, 12:21 pm, Jim Lewis <j...@synthworks.com> wrote: >> I noted that in your code you mixed orif mixed with elsif (copied below), >> was this intentional? One hand, these could convey exactly what I want >> (because there are many cases like this), OTOH, it could be a mistake. >> Hence the intent is ambiguous and during a design review, one would have >> to pay particular attention to this and ask questions about your intent >> and its validation. A copy of your code is below. >> >> If(E0 = '1') then >> State_A <= E0_S; >> Orif(E1 = '1') then >> State_A <= E_S; >> Orif(E2 = '1') then >> State_A <= E2_S; >> elsIf(E3 = '1') then >> State_A <= E3_S; >> Orif(E4 = '1') then >> State_A <= E4_S; >> Orif(E5 = '1') then >> State_A <= E5_S; >> elsIf(E6 = '1') then >> >> On the other hand, with assertions, the following assertions >> allow the above code to be written using elsif. In addition, >> in this case, it is very clear about which I want to be >> mutually exclusive. >> assert zero_one_hot (E0, E1, E2) ; >> assert zero_one_hot (E3, E4, E5) ; > > I would have (perhaps mistakenly?) interpreted the orif/elsif syntax > as: > also meaning: > > assert zero_one_hot(E0, E1, E2, E4, E5); > > My point (and Jim's) is that this is one very good reason why such a > seemingly simple language change is not a good idea when you look > under the hood. Sadly he did clarify his intent in a further post and he did mean to split the priority as I showed. I had an unfair advantage as I have reviewed this with him in the past. > Actually, would the correct syntax be: > > assert zero_one_hot((e0, e1, e2, e4, e5)); -- one array argument > > or does the psl zero_one_hot() function actually accept a variable > number of arguments? > > I would really like to see one_hot() and zero_one_hot() as standard > vhdl (not just psl) functions, usable in an assert statement for this > purpose. The reason is that I don't see synthesis vendors using PSL at > any point in the future (there's just way too much there that would > never be relevant to synthesis). But they could easily parse simple > vhdl assertions with specific, standard functions to extract > meaningful information about the description. Probably a good idea. Technically speaking, PSL is part of VHDL and synthesis tools tend to pick and choose what they implement, so they could just implement this construct. Cheers, JimArticle: 123479
On Aug 28, 11:30 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Weng, > > I was almost starting to agree with you, until you said this... > > > with new keyword 'orif' Xilinx FPGA compiler will be > >mandated to map 'orif' structure into a carry chain structure without > >doubt. > >... > >Letting a special VHDL language structure refer to a carry chain > >implementation in FPGA is a wonderful thing. > > This is the purest madness. If you want a language structure > that specifies a particular implementation, you have it already: > it's called a "primitive instance". I agree that a conditional > that is mutually-exclusive by design can readily be mapped to > specific hardware such as MUXCY or a tree of ORs, but the > precise mapping is NOT something we want in the language, > thanks very much. Tools must have the freedom to optimize > as they think best, and must compete (and succeed or fail) > on how effectively they do it. > > Language constructs that have built-in assertions for > things that are otherwise hard to describe, such as > mutual exclusivity, are something that is well worth > exploring. Especially now that we have the partially- > successful SystemVerilog example to study, it should be > possible to come up with some interesting ideas. But > please don't blast a hole in your own argument by > demanding that the language construct should have a > one-to-one mapping to some specific piece of technology. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Hi Jonathan, All statement structures in VHDL are to refer to a hardware structures. A sequential process is to refer to registers. If a combinational process doesn't get proper assignment, it would refer to a latch. A combinational signal in concurrent area refers to a combinational signal. Why can we refer a special language structure to a carry chain in FPGA while it also gives a means to deal with real situation? "Tools must have the freedom to optimize as they think best, and must compete (and succeed or fail) on how effectively they do it. " In FPGA, it gets best timing with carry chain structure, why don't we do it? Keyword 'orif' doesn't mean you cannot use other MUX/CASE method to do it. But referring to a carry chain is the best way to do things. There are 4 considerations: 1. Easy to write; 2. Be concise in doing it; 3. Have wider range of usage; 4. Performance benefit. Maybe 'mandated' word offends you. It should be changed to other word. WengArticle: 123480
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 SulimmaArticle: 123481
On Aug 28, 9:11 am, Tricky <Trickyh...@gmail.com> wrote: > States A2 and A3 will function exactly the same, but A1 will be > different. If you monitered State_A'transaction in a simulator you'd > get a response on every clock cycle with A1, but only when A='1' for > A2 and 3. It may mean the difference between synthesizing a register > with an enable (in the case of A2 and A3) and without (A1). > > the null statement can be very useful for specifically ignoring > certain cases. I agree, the null statement is usually built-in documentation that says either "I haven't gotten that far yet" or "Yes I did consider this, and am not doing anything here". Sometimes (i.e. case statements) it is necessary for completeness. AndyArticle: 123482
Andy wrote:
> enable := (others => '0');
> for i in enable'range loop
> if address = i then
> enable(i) := '1';
> end if;
> end loop;
>
> Most synthesis tools can figure out that enable is zero_one_hot.
>
> Where the problem comes in is that if you want to use enable in the
> next clock cycle (or later). After all, if you only needed to use it
> immediately, you would dispense with the enable vector, and just put
> the action that "enable" enables in the if-then statement directly.
>
> But as soon as you want to store the enables for a clock cycle or
> more, every synthesis tool I've seen fails to realize that enable is
> still mutually exclusive.
I'll bite.
Why not describe the decode to match the way we encoded it?
Start on one end and break on the first active bit.
-- Mike Treseler
Article: 123483Could some kind soul please tell me if there's a Xilinx-supplied VGA controller in the EDK ? Looking on http://www.xilinx.com/ise/embedded/edk_ip.htm doesn't mention one, but I've come across mentions of one while searching Usenet... All very confusing... If there is such a thing, could you point me at the specs for it ? I was hoping to get 1280x1024, and whereas any "freebie" is probably going to be a 640x480 display, hope springs eternal and all that... Otherwise it's off to the drawing-board [grin] Cheers, S.Article: 123484
Intermediate signals/variables can be avoided by just simply using the expressions in the call to zero_one_hot(); that's a non-issue. There are many more uses of mutual exclusivity than carry chains, and if mutual exclusivity's only specification is with "orif", some other uses are more difficult to functionally describe. Consider a circuit where, if accesses to an array are mutually exclusive, the array can be implemented as a RAM, with a multiplexer on the input. Sure you could code it that way, but I find it often easier to debug descriptions that are functionally more concise, and let the tool figure out the best implementation, with help (that does not detract from the functionality by forcing it to be re-written) from assertions if necessary. A similar occurrence is when trying to determine if expensive resources can be shared. Coding it such that mutual exclusivity is explicit (with or without "orif") is often less functionally clear to the reader, and therefore more likely to harbor functional errors. AndyArticle: 123485
On 2007-08-28, Gabor <gabor@alacron.com> wrote: > > Suggested breakout patterns also require dogbone removal > on the outer two rings of pads. Be sure to run unconnected > outer pads to a test point since you won't be able to access > them without the dogbone / via. And put something in the silk on the back because you will always forget this when you start counting off the vias to find a particular pin... -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 123486
Hi Simon, Simon wrote: > Could some kind soul please tell me if there's a Xilinx-supplied VGA > controller in the EDK ? Looking on http://www.xilinx.com/ise/embedded/edk_ip.htm > doesn't mention one, but I've come across mentions of one while > searching Usenet... All very confusing... > > If there is such a thing, could you point me at the specs for it ? I > was hoping to get 1280x1024, and whereas any "freebie" is probably > going to be a 640x480 display, hope springs eternal and all that... > Otherwise it's off to the drawing-board [grin] There's a PLB VGA controller distributed with the ML401/3/5 reference designs - just go to www.xilinx.com/ml403 and download the reference design, the controller is down in the pcores subdirectory. From memory it's 800x600, there's no option for dynamic resolution adjustment or anything like that, but it is somewhere to start. Regards, JohnArticle: 123487
On Aug 28, 4:37 pm, John Williams <jwilli...@itee.uq.edu.au> wrote: > There's a PLB VGA controller distributed with the ML401/3/5 reference > designs - just go towww.xilinx.com/ml403and download the reference > design, the controller is down in the pcores subdirectory. > > From memory it's 800x600, there's no option for dynamic resolution > adjustment or anything like that, but it is somewhere to start. Cheers John, it's 640x480, but as you say, it's a great start ;) S.Article: 123488
Simon wrote: > Cheers John, it's 640x480, but as you say, it's a great start ;) It should be trivial to extend it to 1024x768 - it's just a bunch of counters after all... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 123489
I'm developing an embedded PPC405 system on a Xilinx FPGA and Im hoping I can get some insight on this problem. I'm using the PLB_DDR2 xilinx ip core to interface two DDR2 memory. Currently I can read/write to DDR2 memory through the XMD/JTAG debug port. I then do a soft reset of the system by an "rst" command through the xmd command prompt. All my internal registers reset correctly and I can read/write to them. Hovvever, if i then try to read/write to DDR2, the system crashes and i get weird values back. A soft reset will bring back register access, but I have to reprogram the FPGA in order to get DDR2 read/write capability. It seems like for some reason the DDR2 controller is not being reset with the rest of the system. Thanks for any suggestions on this.Article: 123490
Hi all, I haven't used any altera stuff for a while. Last time I used the MAX3000A, I built the parallel port byteblaster cable from the info on the altera's web site. This is the original not the improved one they have now. It was like $10 in parts and did the trick. I still have it and works but my new laptop doesn't have a parallel port. The USB stuff is ridiculously priced ($300 at digikey). I found a substitute in Canada for about $80 (http://www.minford.ca/html/mf162.html) I was wondering if anyone has this one and could comment on it ? I think it is more reasonable price. Comments welcome. BTW I'm only using MAX3000A devices. Thanks.Article: 123491
On Aug 28, 5:48 pm, Mark McDougall <ma...@vl.com.au> wrote: > Simon wrote: > > Cheers John, it's 640x480, but as you say, it's a great start ;) > > It should be trivial to extend it to 1024x768 - it's just a bunch of > counters after all... [grin], that's what I'm hoping. Not having played with the EDK at all, it's useful to have an example of how it interfaces with the PLB though. I'm also a bit concerned it'll be sucking too much bandwidth - I only actually want 256 colours (@1280x1024,60), so I'll be altering it to use a local lookup table which ought to compensate. S.Article: 123492
On Aug 29, 5:43 am, Jimb...@gmail.com wrote: > I'm developing an embedded PPC405 system on a Xilinx FPGA and Im > hoping I can get some insight on this problem. > > I'm using the PLB_DDR2 xilinx ip core to interface two DDR2 memory. > Currently I can read/write to DDR2 memory through the XMD/JTAG debug > port. I then do a soft reset of the system by an "rst" command through > the xmd command prompt. All my internal registers reset correctly and > I can read/write to them. Hovvever, if i then try to read/write to > DDR2, the system crashes and i get weird values back. A soft reset > will bring back register access, but I have to reprogram the FPGA in > order to get DDR2 read/write capability. > > It seems like for some reason the DDR2 controller is not being reset > with the rest of the system. > > Thanks for any suggestions on this. Just asking: the DDR2 memories are properly routed ? What kind of terminators are onboard? If active terminators used are they programmed correctly in the FPGA ? Probably through the jtag the W/R sequence to DDR2 is slower and everything it's ok.Article: 123493
On Aug 28, 11:11 pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > 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. Have you do it only with through and blind holes without any backdrilling ? The MGT are using striplines for long routes and microstrip for escaping ? Have been used AC coupled or DC coupled MGTs ? thx, VasileArticle: 123494
Hi Rodo, Haven't used that particular one, but I do have used TerAsics clone. You can find that one at: www.terasic.com.tw (USB Blaster cable). Pricing 50$ works as good as the "real" one. Regards FredrikArticle: 123495
Hi, I have implemented a core to write/read to a Bram_Block (using one of the two ports). The another port is used by Microblaze with a lmb_bram_if_cntlr core to read those values which had been modified by my custom core. Of course, I use a lmb bus. Now, I want to create a design with PowerPC and I suppose I must use a plb bus to access to the bram_block. With this assumption, PowerPC would use a plb_bram_if_cntlr core to read from the bram (this works fine), but my custom core cannot modify the contents of the bram. What's wrong?. Is plb bus very different from lmb?. Could I use a lmb bus with PowerPC instead of Microblaze? Best RegardsArticle: 123496
> The BUFIO delay is now up to about 600 ps longer. We haven't looked at > workarounds for this, but it must be compensated for. I am sure you could > find something. I've just tried setting an initial delay of 600 ps on the DQ lines but without sucess ... > What frequency are your running your interface? I do my tests at 200 MHz currently. But in the final design it needs to run at 250. > What width and what speed > grade do you use? We are on the slowest speed grades. Currently we need a 8 bit width. But soon we'll need up to 64 bits. > The Virtex-5 DDR2 controller is getting some speed > improvements shortly that might help your timing. Do you have an estimated date ? > I realize that it won't > help with your modifications, so it may not be a reasonable alternative for > you. At least I get an explanation on why it might fail ... SylvainArticle: 123497
thanks ofr this links, Mike I'll shurly see it Thanks again Mike Treseler wrote: > Zorjak wrote: > > > I'll try to use input and output behavioral in diferent process. > > Here's a related example: > > http://home.comcast.net/~mike_treseler/oe_demo.vhd > http://home.comcast.net/~mike_treseler/oe_demo.pdf > > > -- Mike TreselerArticle: 123498
> > This sounds interesting. Are you using via-in-pad? Can you point > me to a good source showing how to use microvia's to improve BGA > routing? A quick Google search brought up lots of articles that > assume you already know the basic premise. Just at first glance > I would think that the inner portions of the BGA routing would > still require traditional techniques? > > Regards, > Gabor > Hi Gabor, Yes, I use via in pad. There's an article here all about it:- http://www.sanmina-sci.com/Solutions/pdfs/pcbres/Impact_of_Microvia-in-pad_Design_on_Void_Formation.pdf Void formation is seen as bad. My experience is otherwise. I've made boards with microvias dead centre of the pad, offset from the pad, and Cu filled microvias in pads. If there was a yield difference between these methods, my production team and service guys kept quiet about it. (They sure moaned like crazy when the QFNs had problems with pad size!) I posted about this three years back, Google for "PCBs for modern FPGAs" in CAF. Here's a link to a picture of board I did then :- http://www.fpga-faq.com/caf_pics/layer_1_2.gif (Thanks to Philip for keeping it there!) If you have 0.1 mm tracks 'n' gaps and make the BGA pad size 0.5mm, you can get the first 3 layers out on layer one. Then work back from there, layer 2 can take perhaps 4 traces/mm. That lets you go 7 balls deep from the edge without a through via. The powers and grounds use through vias. I try to keep the through vias on the 'corner' of the destination pad nearest the centre of the BGA, this facilitates the routing of the signal traces outwards. The backside of the board can be covered with bypass circuitry as there isn't the usual field of through vias filling this area. (BTW., I did once use slightly bigger pads, but made the outer balls oval to get the traces out. Again this made no detectable yield difference.) The gap between layers one and two is necessarily small for microvias. This is great news for SI; the laser drilled via has only a tiny inductance, and the reference plane for layer 2 is the same as layer 1. Except in a microvia board it isn't drilled with so many holes! I've done many boards with microvias on one side only. (Keep the BGAs on that side!) This way you can keep the price down. The stack up needs to be symmetrical, but the distribution of planes doesn't. See the post from three years ago for details. Also, you can get a lot more stuff on a given sized board. Through vias get in the way of mounting stuff on the backside of a board, the microvia alleviates this problem. And be prepared to swap pins on the FPGA when you do your layout. This saves time in layout, and I know that PADS has a magic feature to assist in this. In all, I find I get cheaper (fewer layers) and more compact boards, with better SI, by using this technology. HTH., Syms.Article: 123499
"vasile" <piclist9@gmail.com> wrote in message news:1188328769.110150.224990@o80g2000hse.googlegroups.com... > > At 1mm pitch, microvias in pad will not be a very good option. > I've used microvia in pad for 0.65mm pitch and it was very expensive. > There must be a low isolation thickness between layer 1-2 for > microvias, and usually the board is requesting simmetry (if you have > microvias on 1-2 then you may have on 7-8 but depends on stack). > > Vasile > Hi Vasile, I'm sorry you didn't have a good experince with the technology. Mine has been somewhat more positive. I spend more on the laser vias, but claw that back and more with the layer reduction. Also, I only need a symetrical stack to keep warpage low. The microvias do not need to be on both side of the PCB. I don't do that unless I have to. Finally, I find the "low isolation thickness between layer 1-2" is a very good thing for SI. GHz traces don't 'notice' microvias, and stay referred to the same plane. HTH., 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