Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 123475

Article: 123475
Subject: Re: DDR2 controller V4 vs V5 differences ?
From: "John Schmitz" <john.schmitz@noemail-xilinx.com>
Date: Tue, 28 Aug 2007 12:23:13 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Tue, 28 Aug 2007 12:29:11 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 19:34:06 -0000
Links: << >>  << T >>  << A >>
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: 123478
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Tue, 28 Aug 2007 12:49:34 -0700
Links: << >>  << T >>  << A >>
Andy,
> 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,
Jim

Article: 123479
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 12:54:02 -0700
Links: << >>  << T >>  << A >>
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.

Weng


Article: 123480
Subject: Re: PCB Layers
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Tue, 28 Aug 2007 13:11:07 -0700
Links: << >>  << T >>  << A >>
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



Article: 123481
Subject: Re: Null statement in VHDL
From: Andy <jonesandy@comcast.net>
Date: Tue, 28 Aug 2007 13:18:00 -0700
Links: << >>  << T >>  << A >>
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.

Andy


Article: 123482
Subject: Re: New keyword 'orif' and its implications
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 28 Aug 2007 13:52:01 -0700
Links: << >>  << T >>  << A >>
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: 123483
Subject: VGA controller in the EDK ?
From: Simon <google@gornall.net>
Date: Tue, 28 Aug 2007 14:07:50 -0700
Links: << >>  << T >>  << A >>
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]

Cheers,

S.


Article: 123484
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Tue, 28 Aug 2007 14:38:58 -0700
Links: << >>  << T >>  << A >>
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.

Andy


Article: 123485
Subject: Re: PCB Layers
From: Ben Jackson <ben@ben.com>
Date: Tue, 28 Aug 2007 18:00:34 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: VGA controller in the EDK ?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Wed, 29 Aug 2007 09:37:09 +1000
Links: << >>  << T >>  << A >>
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,

John

Article: 123487
Subject: Re: VGA controller in the EDK ?
From: Simon <google@gornall.net>
Date: Wed, 29 Aug 2007 00:42:18 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: VGA controller in the EDK ?
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 29 Aug 2007 10:48:06 +1000
Links: << >>  << T >>  << A >>
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-3266

Article: 123489
Subject: Problems with PLB_DDR2 core and soft reset
From: JimboD2@gmail.com
Date: Tue, 28 Aug 2007 19:43:00 -0700
Links: << >>  << T >>  << A >>
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
Subject: altera's USB byteblaster cable: anyone has the mindford one?
From: "Rodo" <dsp1024@yahoo.com>
Date: Wed, 29 Aug 2007 03:14:31 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: VGA controller in the EDK ?
From: Simon <google@gornall.net>
Date: Wed, 29 Aug 2007 03:47:45 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Problems with PLB_DDR2 core and soft reset
From: "vsurducan@gmail.com" <vsurducan@gmail.com>
Date: Wed, 29 Aug 2007 06:25:54 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: PCB Layers
From: "vsurducan@gmail.com" <vsurducan@gmail.com>
Date: Wed, 29 Aug 2007 06:31:10 -0000
Links: << >>  << T >>  << A >>
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,
Vasile




Article: 123494
Subject: Re: altera's USB byteblaster cable: anyone has the mindford one?
From: Fredrik <fredrik_he_lang@hotmail.com>
Date: Wed, 29 Aug 2007 00:04:08 -0700
Links: << >>  << T >>  << A >>
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
Fredrik


Article: 123495
Subject: VHDL core to read/write to Bram_Block.
From: Pablo <pbantunez@gmail.com>
Date: Wed, 29 Aug 2007 00:51:11 -0700
Links: << >>  << T >>  << A >>
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 Regards


Article: 123496
Subject: Re: DDR2 controller V4 vs V5 differences ?
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Wed, 29 Aug 2007 07:55:38 -0000
Links: << >>  << T >>  << A >>

> 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 ...


Sylvain


Article: 123497
Subject: Re: bidirectional pin help
From: Zorjak <Zorjak@gmail.com>
Date: Wed, 29 Aug 2007 08:51:17 -0000
Links: << >>  << T >>  << A >>
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 Treseler


Article: 123498
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Aug 2007 10:07:37 +0100
Links: << >>  << T >>  << A >>
>
> 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
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Aug 2007 10:12:25 +0100
Links: << >>  << T >>  << A >>

"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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search