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 123450

Article: 123450
Subject: Re: Null statement in VHDL
From: Tricky <Trickyhead@gmail.com>
Date: Tue, 28 Aug 2007 07:11:19 -0700
Links: << >>  << T >>  << A >>
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.


Article: 123451
Subject: Re: PCB Layers
From: vt2001cpe <vt2001cpe@gmail.com>
Date: Tue, 28 Aug 2007 14:14:00 -0000
Links: << >>  << T >>  << A >>
Jon,
In my experiance I have found that the answer to your question
is....it depends :)

The total number of PCB layers is dependent on all components,
voltages, and signaling types utilized on the board. If you have
strict requirements on isolation and noise then the count goes up.
Looking at it from a signal layer count for supporting of the FPGA
only, I have found that n/2 is a good approximation, where n is the
number of rows to get to that center point of the package. I guess you
could say the total number of rows for the package divided by 4. That
is most likely your minimum number of signal planes. Again, the whole
thing is academic, because each design is different. If you have not
utilized 100% of the I/O, then your count might be lower. If you have
used 50% of the I/O, but it is all in a few banks, then you will need
to use more layers than if the I/O had been spread over the entire
package. Finally, look at the requirements for your other components.
Analog devices usually have different voltages, or multiple ground
requirements that can greatly influence your stackup.

Good luck,
vt2001cpe


On Aug 28, 9:23 am, "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?
>
> Cheers
>
> Jon



Article: 123452
Subject: Re: Synthesizing fixed_pkg in ISE 9.2
From: Andreas Schwarz <usenet@andreas-s.net>
Date: Tue, 28 Aug 2007 07:25:35 -0700
Links: << >>  << T >>  << A >>
I installed the ISE service pack 2, and the error message became more
specific:
ERROR:Xst:2744 - "C:/Dokumente und Einstellungen/A/Eigene Dateien/FPGA/
fixpt-test/vhdl200x/fixed_pkg_c.vhdl" line 1026: alias of a function
is not supported.
ERROR:Xst:2683 - Unexpected error found while building hierarchy.

So I commented out the function aliases cleaned up the project files
(otherwise I would get "ERROR:HDLParsers:333 - Binary file "xst/
ieee_proposed/sub00/vhpl02" is corrupted. Recompile unit
fixed_pkg.fixed_pkg."), and everything compiles just fine.

Only division does not work:
ERROR:Xst:769 - "C:/Dokumente und Einstellungen/A/Eigene Dateien/FPGA/
fixpt-test/vhdl200x/fixed_pkg_c.vhdl" line 2599: Operator <INVALID
OPERATOR> must have constant operands or first operand must be power
of 2

Andreas


Article: 123453
Subject: Re: Null statement in VHDL
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: Tue, 28 Aug 2007 14:26:59 -0000
Links: << >>  << T >>  << A >>
On 28 Aug., 16:09, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
>
> Perhaps because they are too lazy to implement features which
> customers can easily be led to believe are frills?
I would say that they do not question decisions that were made by
synopsys 20 years ago.

> E.g. Jonathan
> Bromley posted on 2007 March 5th:
Hmm. I just have to counter that post here.

> [..] The majority of
> hardware platforms do not offer reliable power-up
> initialisation of internal state.
True. But the vast majority of design starts are on platforms that do
support it.

>  Consequently it is appropriate
> to code explicitly some reset behaviour.
At extra hardware cost on my platform.

> For exactly this
> reason, the hardware-oriented data types in VHDL (std_logic,
> etc) have a specific undefined value as the leftmost value
> of their value-set, so that initialisation oversights are
> more likely to be detected.

So, when I explicitly assign an initial value of '1' and then start
synthesis for a platform that supports initial values the synthesis
tool
should synthesize to an initial value of '0'? How does that detect
initialization oversight?
It is an implementation error. Plain and simple.

Leaving the initial value unassigned makes formal verification a PITA.

> This issue is
> one of those things that hardware designers are required
> to be aware of,
Surely the OP meant "ASIC designres".

> and failure to attend to it is usually a good
> identifying mark of a beginner, or a dyed-in-the-wool
> programmer assuming that hardware design is easy.

Well it isn't. But it could if tools would catch up. We spend easily
25% of the design time
of the last project debugging the tools.
(Deciphering such great synthesis guidelines as the statement that
arrays should not be used.
Instead std_logic_vector should be used. But that is an array. Hmm.)

Kolja Sulimma


Article: 123454
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 28 Aug 2007 07:41:47 -0700
Links: << >>  << T >>  << A >>
eli.billauer@gmail.com wrote:

> Now to my suggestion: The problem is that paths which end up in the
> flip-flops' CE pin are taken for multi-cycle paths.

I don't follow this.
A clock enable is just a synchronous input.
Which tool automatically constrains timing for these?

          -- Mike Treseler

Article: 123455
Subject: Re: New keyword 'orif' and its implications
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 28 Aug 2007 07:51:31 -0700
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:

> I open a new topics from previous one to try to stir another round to
> introduce a new keyword 'orif'.

The old bait and switch.
I've been trolled again.

   -- Mike Treseler

Article: 123456
Subject: Re: PCB Layers
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 28 Aug 2007 08:11:07 -0700
Links: << >>  << T >>  << A >>
On Tue, 28 Aug 2007 08:23:56 -0500, "maxascent"
<maxascent@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?
>
>Cheers
>
>Jon

We've done Spartan3 FG456 chips on 6 layers, so you'll probably need 8
or 10. Start sketching!

John


Article: 123457
Subject: Re: PCB Layers
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Tue, 28 Aug 2007 10:35:27 -0500
Links: << >>  << T >>  << A >>
Thanks for all the info. I think I may be able to get away with using 8 as
not all of the banks are fully utilised.

Jon


Article: 123458
Subject: Re: Partial reconfiguration using ICAP
From: Sean Durkin <news_aug07@durkin.de>
Date: Tue, 28 Aug 2007 18:20:20 +0200
Links: << >>  << T >>  << A >>
ajith.thamara@gmail.com wrote:
> 1. So when i try doing this the program is not completely get written
> and gets hanged in between. But when i generated raw bit files (using
> - b option in bitgen) i am able to transfer the whole content , but
> after downloading, the system is not functioning as expected ( no
> change in the display).
> The other thing is that the size of original .bit file is 158kB,
> and .rbt file is 1356kB - so what makes the .rbt fle so big.
Open it in a text editor and you'll see. The .rbt is a text file
containing the ASCII characters '0' and '1' for all the bits. This you
cannot send through ICAP, it is meant to be used to do very simple
bit-banging with a uC (you just read in the rbt byte by byte and set an
IO according to the byte to toggle the external serial data input).
For use with ICAP, you have to use the bit-file, not the rbt. If you
transfer the rbt, the configuration logic detects that this is not a
valid bitstream, and that might be what hangs your program (not sure,
I've never tried sending an invalid bitstream).

If you do send a valid bitstream (the .bit-file) and it doesn't change
the system's behaviour, it could be several things:

- The new partial bitstream isn't really different from the original
- It's not a valid partial bitstream (wrong startup clock, CRC incorrect...)

Have you tried loading the partial bitstream with iMPACT over JTAG
instead of using ICAP? If it doesn't work then, there's something wrong
with the bitstream.

> 2. I tried downloading .bin file (generated using - g binary : yes
> option in bitgen)  again the whole data is not getting transfered but
> gets stuck up in between. but the size of this file is only 157kB with
> header removed.
Hmm, the bin should be loaded completely... the only thing I can think
of why it would not be is that the configuration logic requires some
clock cycles after the configuration data to empty it's internal
pipeline. At least when I'm loading a bitstream via the external
interface, I always have to generate several clock cycles after the
configuration data before the done pin goes high.

Not sure, but maybe it is the same with ICAP.

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: 123459
Subject: Re: Xilinx Virtex IOB Regiters and Noise???
From: "John Retta" <jretta@rtc-inc.com>
Date: Tue, 28 Aug 2007 10:30:58 -0600
Links: << >>  << T >>  << A >>

> I will have to get a scope, but for the time being ... the data bus coming 
> in
> does not change state, yet some bits are registered at the opposite
> state for 1 clock cycle (@ 60 MHz).

So this seems critical ... during a period where data is supposed to be 
quiesent,
you are detecting spurious false states.  So this sounds not like a timing 
problem,
but some "noise problem"/power supply/misc gremlin problem.

To answer your original question, I have been using Xilinx devices for 10 
years,
and before they are released for general use, they are pretty bullet proof.
However, there are lots of pwb/power supply device interconnect issues that
can cause related problems.

Here are some things to do :

[1] Take a look at the input signal with a scope .... make sure HI/LO 
voltage
levels match what FPGA expects.  [Look at the .pad file in synthesis 
directory.
This defines the electrical interface for the input signal.  Adjust the 
trigger, and
see if there are spurious events on signal input.

[2]  Verify the Bank Voltage on the device is correct.

[3] Are single clock events permissible?  If not, use something like the 
following
snippet as a "debug trigger".

wire debug_trigger = signal[2] & ~signal[1] & signal[0]  |  ~signal[2] & 
signal[1] & ~signal[0];
always @ (posedge clk)
  begin
     signal_q <= {signal[1:0],  input };
   end

Then bring the debug_trigger to an FPGA output which can be monitored
with a test point.  Use this as a trigger to oscope and look at the actual
input signal on its pin at FPGA.  A few clocks before you will see the 
offending
event.

-- 
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant


email : jretta@rtc-inc.com
web :  www.rtc-inc.com


"Analog_Guy" <analog_guy@hotmail.com> wrote in message 
news:1188309687.062604.84880@i13g2000prf.googlegroups.com...
> Thank you for your responses.
>
> On Aug 28, 9:07 am, Gabor <ga...@alacron.com> wrote:
>>
>> If you suspect ringing or glitches I'd look with a scope instead
>> of the logic analyzer.  When you say the bus is stable, do you mean
>> a bit that hasn't changed state is registered at the opposite state?
>>
> I will have to get a scope, but for the time being ... the data bus
> coming in
> does not change state, yet some bits are registered at the opposite
> state
> for 1 clock cycle (@ 60 MHz).
>
>> What about hold time?  Are the input registers using the built-in
>> delay path?  What does the post P&R timing report show for hold
>> time requirement on these inputs?
> The data sheet report shows that the setup times for all data bus bits
> are 1.958 ns, and
> the hold times are -1.006 ns.
>
>>
>> All Virtex registers are fast in terms of capturing glitches.  Another
>> thing to look at with a scope is the rise / fall time of the input
>> signal.  Logic analyzers tend to mask this.  Maybe you don't have
>> as much setup time as you think if the Virtex and logic analyzer
>> don't use the same threshold levels.
>>
>> HTH,
>> Gabor
> I will have to instrument a scope to look at the rise times ... thank
> you.
> 



Article: 123460
Subject: Re: New keyword 'orif' and its implications
From: KJ <Kevin.Jennings@Unisys.com>
Date: Tue, 28 Aug 2007 09:32:35 -0700
Links: << >>  << T >>  << A >>
On Aug 27, 9:11 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> I open a new topics from previous one to try to stir another round to
> introduce a new keyword 'orif'.
>
>
> > > One thing I miss a lot is 'orif' keyword compared to 'elsif'.
>
> > > 'orif' introduces a group of conditions that are mutually exclusive.
>
> > > On any output buses or input buses, all data running on the buses are
> > > mutually exclusive.
>
> > > I couldn't persuade James to change his mind.
>
Jim Lewis doesn't own the VHDL language standard nor is he a
gatekeeper that prevents suggestions from being submitted.  His clout
kicks in more after the submission....but that's off on a tangent.

> Keyword 'orif' has the same language grammar definition as 'elsif'
> with one exception: conditional signal contained in leading 'if' or
> 'elsif' segment and conditional signals contained in the subsequent
> and contiguous 'orif' segment in an 'if' statement are mutually
> exclusive. Where keyword 'elsif' can be used in a VHDL code, there
> keyword 'orif' can be used.
>
> Here is an example on how to use keyword 'orif':
>
> 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
> ...
>
Doesn't grab me much but I don't find it offensive either, just
different.

> It has two mutually exclusive signal groups: signals E0, E1 and E2 are
> mutually exclusive. So are signals E3, E4 and E5.
Only because you say they are mutually exclusive though.  I can
guarantee exclusivity by using existing VHDL enumerated types and a
single signal.

>
> The implementation benefits with FPGA are huge !!!
>
Might want to consider less use of the exclamation point in the
future.

> For example:
>
> OutBus has 64-bit width.
>
> OutBusA : process(RESET, CLK)
> begin
>    if(RESET = '1') then
>       OutBus <= (others=>'0');
>    elsif(CLK'event and CLK = '1') then
>       If(E0 = '1') then
>          OutBus <= Data0;
>       orif(E1 = '1') then
>          OutBus <= Data1;
>       orif(E2 = '1') then
>          OutBus <= Data2;
>       orif(E3 = '1') then
>          OutBus <= Data3;
>       orif(E4 = '1') then
>          OutBus <= Data4;
>       orif(E5 = '1') then
>          OutBus <= Data5;
>       end if;
>    end if
> end process;
>
> 1. If the keyword 'orif' is adopted as a VHDL standard, the above
> equation would be executed in FPGA chips not by mux, not by case
> statement implementation method, but by the most efficient method:
> carry chain in Xilinx chips !!!
>
> It would be executed like a sum of products: In assembly language for
> shortness:
> OutBus = E0*Data0 + E1*Data1 + ... + E5*Data5;

You seem to be forgetting the multiply operation in your above
equation it's not 'just' adding Data0, Data1, etc.  Also, if I were
faced with this situation and today's syntax I would probably code it
as...

OutBus = F(E0, Data0) + F(E1, Data1) + ... + F(E5, Data5);

where F() is a function that returned either the second argument or 0
based on how the first argument is set...in other words a simple
couple line function that accomplishes a specific task.  If the number
of 'Data' elements was parameterized I might decide to embed that into
the function as well and pass in an array of 'Data' instead of
'Data0'...'Data5'....but that's just me.

> Please check Xilinx application note about how to implement sum of the
> products (I failed to find it)
Hmmm....don't think you gain much credibility with that statement.

>
> In other words, if keyword 'orif' is introduced into VHDL standard,
> Xilinx carry chain structure would become part of VHDL standard in a
> natural way. 'orif' will be refered to carry chain in FPGA
> structure !!!
You seem to be forgetting something very basic....if it can be
implemented with a carry chain at all, it can be done with today's
syntax as well.

> 2. If the keyword 'orif' is adopted as a VHDL standard, it can specify
> that during simulation, if a simulator detects two signals being
> active in a mutually exclusive group on current cycle, simulator
> issues a fatal error and stops without any user's interference !!!
Hmmm....but you said that they were mutually exclusive but now you're
alluding to the possibility that they might not.  So what would happen
in the implemented hardware?  No assertions there, just logic
implemented as LUT (FPGA), and/or (CPLD), gates (ASIC).  The hardware
will do something and it probably will do something inappropriate
without a language guarantee that the collection is mutually exclusive
as it is supposed to be....which is precisely what enumerated types do
for you.

>
> Simple and reliable !!!
You haven't sold me on the 'reliable' part.  The 'simple' part is OK,
but it's not much simpler than what can be done today so the relative
measure of 'simple' is pretty low in this case in my opinion.  Having
to wonder about how exclusivity is guaranteed, how can I mess it up
and things like that don't excite me.

>
> 3. I expect Xilinx would be the first company to implement the new
> keyword 'orif', because its fastest carry chain feature would be best
> used in the situations without users' efforts to change its writing
> patterns.
Gosh I hope not....implement the language standard not somebody's
extensions.

> You may imagine 64-bit data bus would occupy a lot of space
> and resources if not the best carry chains are referenced. And the
> routine timing will be hugely saved and running frequency will hugely
> boosted.
Got anything to back up those claims?  The language extension that
you're proposing will do absolutely nothing to the final hardware,
there will be no savings of any kind.  What you're proposing is (at
best) a designer productivity improvement (i.e. lines of working code
per unit of time).  To suggest that a new language keyword would
result in better resource usage is suspect.  Have you benchmarked
exactly how things get implemented today using functionally equivalent
logic?  Boolean logic does not require language keywords beyond 'and',
'or' and 'not'.  Designer productivity increases with higher level
abstractions but I'm not seeing much, if any, improvement to be gained
by 'orif'.

>
> 4. 'orif' name is very appropriate. It means if above conditional
> equation is not met, or try this one, or try next, or try the
> last, ... it meets the equation above in assembly.
'elsif' on an enumerated type signal does that as well and is just as
descriptive as 'orif'.

>
> 5. Most of programmers never use mutually exclusive property in their
> designs and they fear the property would be violated some times.
Got any basis for that statement?  Programmers?  Doing VHDL?  I'd
guess that they would catch on to either enumerated types or functions
pretty quickly though.

> But
> here are some hints the violation situation will never happen if it is
> appropriate.
>
> a. Data buses are always mutually exclusive !!!
Does that even mean anything?
>
> If two data conditions on a data bus may be active at the same cycle,
> add minimum additional conditions to make them mutually exclusive.
And how do those conditions get satisfied and guaranteed?  Hmmm...

>
> 7. Mutually exclusiveness is ubiquitout in logic design and I am very
> sorry for VHDL without a special keyword to deal with it.
What is it about enumerated types in VHDL that you find so hard?

KJ


Article: 123461
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 09:57:59 -0700
Links: << >>  << T >>  << A >>
On Aug 28, 3:59 am, "Symon" <symon_bre...@hotmail.com> wrote:
> "Weng Tianxiang" <wtx...@gmail.com> wrote in message
>
> news:1188263507.145095.110420@q3g2000prf.googlegroups.com...
>
>
>
> > It has two mutually exclusive signal groups: signals E0, E1 and E2 are
> > mutually exclusive. So are signals E3, E4 and E5.
>
> > The implementation benefits with FPGA are huge !!!
>
> > For example:
>
> > OutBus has 64-bit width.
>
> > OutBusA : process(RESET, CLK)
> > begin
> >   if(RESET = '1') then
> >      OutBus <= (others=>'0');
> >   elsif(CLK'event and CLK = '1') then
> >      If(E0 = '1') then
> >         OutBus <= Data0;
> >      orif(E1 = '1') then
> >         OutBus <= Data1;
> >      orif(E2 = '1') then
> >         OutBus <= Data2;
> >      orif(E3 = '1') then
> >         OutBus <= Data3;
> >      orif(E4 = '1') then
> >         OutBus <= Data4;
> >      orif(E5 = '1') then
> >         OutBus <= Data5;
> >      end if;
> >   end if
> > end process;
>
> Hi,
>
> I don't want to get involved in a language crusade, and I don't like to
> crosspost so you'll need to read this on CAF, but why not just do something
> like this? :-
>
> OutBusA : process(RESET, CLK)
> begin
>   if(RESET = '1') then
>      OutBus  <= (others=>'0');
>      OutBus1 <= (others=>'0');
>      OutBus2 <= (others=>'0');
>      OutBus3 <= (others=>'0');
>      OutBus4 <= (others=>'0');
>      OutBus5 <= (others=>'0');
>   elsif rising_edge(CLK) then
>     if (E1 = '1') then OutBus1 <= Data1; else OutBus1 <= (others=>'0'); end
> if;
>     if (E2 = '1') then OutBus2 <= Data2; else OutBus2 <= (others=>'0'); end
> if;
>     if (E3 = '1') then OutBus3 <= Data3; else OutBus3 <= (others=>'0'); end
> if;
>     if (E4 = '1') then OutBus4 <= Data4; else OutBus4 <= (others=>'0'); end
> if;
>     if (E5 = '1') then OutBus5 <= Data5; else OutBus5 <= (others=>'0'); end
> if;
>     OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5;
>   end if
> end process;
>
> Google comp.arch.fpga for a thread subject  :-
>
> Multidimensional Register in Modul Port List
>
> and read Mr. Bromley's posts.
> HTH., Syms.- Hide quoted text -
>
> - Show quoted text -

Hi Syms,
Your code timing is fundamantally inferior to my code timing.

In your code, you specify 6 groups of data registers, then each bit of
its output registers gets a combinational bit output.

In my code, all 5 groups of signals are combinational signals and
through a carry chain structure in FPGA, the output registers get the
fastest clock-to-output timing result.

Weng


Article: 123462
Subject: Re: bidirectional pin help
From: Mike Treseler <mike_treseler@comcast.net>
Date: Tue, 28 Aug 2007 10:06:39 -0700
Links: << >>  << T >>  << A >>
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: 123463
Subject: Re: Null statement in VHDL
From: Jim Lewis <jim@synthworks.com>
Date: Tue, 28 Aug 2007 10:15:20 -0700
Links: << >>  << T >>  << A >>
Andy and Mike,
 >> From Mike
>> I get really frustrated when I try to implement something using 
>> standard VHDL and find that it is incorrectly or incompletely 
>> supported. I wish more people would have higher standards with the 
>> software they use. The way I see it, it's false advertising to 
>> advertise something as a VHDL synthesizer if it doesn't completely 
>> implement the VHDL standard, but not many seem to agree with me. 
>>
>> I think it comes down to the difference between engineers and 
>> scientists. Scientists prefer theory, and deviations from the ideal 
>> grate on us. Engineers prefer practicality, and will tend to solder on 
>> (pun intended) through crappy software, more interested in the end 
>> result than the process. I have grounding in both, so I complain as I
>> implement, and depend less on crappy software whenever the chance
>> presents itself. Life's too short for bad software.

I think the status-quo is more complex than you state.
Vendors don't implement standards just because just because they
have neat features.  It is about marketing and investing.  A vendor
invests in features that will make them money and/or differentiate
their software from a competitors.

If you want change, you need to focus on communicating to them what
features you require.  They listen best to the people with $$$, so
you may wish to file bug reports with both your vendor and with the
person paying for the tools (or at least let the person paying for
tools know about open bugs on a regular basis).   Short of this,
we would all have to pool together and talk to them collectively.


 > from Andy
> There is an ieee standard for the "minimum" synthesizable subset of
> vhdl, but its creation was dominated by the big player(s) in
> synthesis, and focused on what they had already implemented. 
Actually most big players did not participate.  At the time there
were concerns with loosing patents due to standards participation.

The theory behind the minimum was so a IP supplier would have a
standard to claim compliance to.  The second standard actually was
started as soon as the first one was done, so I still believe it
was the best decision.


> Since then, updates to the standard have been few and far between, 
The first revision was 1076.6-1999 and 1076.6-2004.
While that is slow, standards are a volunteer effort.
You get what you invest.  We need more user companies
who are interested in this to invest the time.

 > and the standard has also migrated from a template based approach,
 > to a behavioral approach.
An idea put forward by tool vendors.  At the time it seemed to be
a good way to avoid having a huge set of templates and leaving a
few critical ones behind.

At this point, the standard is due for revision by 2009.
Since vendors have not implemented all of it, it would be
an opportune time to change the approach if it is appropriate
to do so.  Myself, I am tied up with the general language revision,
however, it is a good "starter" place for participating in standards.
Particularly for experienced designers who regularly voice an
opinion here (like Andy J, Mike T, Jon B, KJ, ... not meaning to leave
any interested party out).

Quit bitching, get the vendors involved and make it a standard
you can live with and a standard the vendors will implement.

Cheers,
Jim

Article: 123464
Subject: Re: New keyword 'orif' and its implications
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 28 Aug 2007 18:17:33 +0100
Links: << >>  << T >>  << A >>
>
> Hi Syms,
> Your code timing is fundamantally inferior to my code timing.
>
> In your code, you specify 6 groups of data registers, then each bit of
> its output registers gets a combinational bit output.
>
> In my code, all 5 groups of signals are combinational signals and
> through a carry chain structure in FPGA, the output registers get the
> fastest clock-to-output timing result.
>
> Weng
>
I knew this would happen...

Is this 'fundamentally inferior'?

OutBus1 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0');
OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0');
OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0');
OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0');
OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0');

OutBus : process(RESET, CLK)
begin
  if(RESET = '1') then
     OutBus  <= (others=>'0');
  elsif rising_edge(CLK) then
    OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5;
  end if
end process;

I think Mike's comment sums it up...

HTH., Syms.



Article: 123465
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Tue, 28 Aug 2007 10:21:53 -0700
Links: << >>  << T >>  << A >>
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


Article: 123466
Subject: Re: Xilinx / ISE multi-cycle path constraint pitfall
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 28 Aug 2007 18:25:27 +0100
Links: << >>  << T >>  << A >>

"Mike Treseler" <mike_treseler@comcast.net> wrote in message 
news:5jiqhcF3ubforU1@mid.individual.net...
> eli.billauer@gmail.com wrote:
>
>> Now to my suggestion: The problem is that paths which end up in the
>> flip-flops' CE pin are taken for multi-cycle paths.
>
> I don't follow this.
> A clock enable is just a synchronous input.
> Which tool automatically constrains timing for these?
>
>          -- Mike Treseler
Hi Mike,
He's trying to ensure the enable signal gets to all the FFs in time. This 
should happen anyway as long as he keeps the instance 'en' out of his 
timegroup 'tgrp_en' which he may or may not have done.
I think there's a flaw in his logic, in that the enable doesn't necessarily 
attach to the .CE pins. It can go to regular logic depending on the 
synthesisers 'day_of_week' input. :-) Also, CE pins get used for other 
things the synthesiser decides on.
Cheers, Syms. 



Article: 123467
Subject: Re: PCB Layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 28 Aug 2007 18:41:41 +0100
Links: << >>  << T >>  << A >>

"maxascent" <maxascent@yahoo.co.uk> wrote in message 
news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com...
>
> 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?
>
> Cheers
>
> Jon

Use laser drilled microvias. You'll save the extra money they cost on by 
reducing the number of layers by 4. You only need them on the same side as 
the BGA. Layer 1 <-> Layer 2. All the other vias can be through.
HTH., Syms. 



Article: 123468
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 18:10:13 -0000
Links: << >>  << T >>  << A >>
On Aug 28, 10:17 am, "Symon" <symon_bre...@hotmail.com> wrote:
> > Hi Syms,
> > Your code timing is fundamantally inferior to my code timing.
>
> > In your code, you specify 6 groups of data registers, then each bit of
> > its output registers gets a combinational bit output.
>
> > In my code, all 5 groups of signals are combinational signals and
> > through a carry chain structure in FPGA, the output registers get the
> > fastest clock-to-output timing result.
>
> > Weng
>
> I knew this would happen...
>
> Is this 'fundamentally inferior'?
>
> OutBus1 <= Data1 when (E1 = '1') else OutBus1 <= (others=>'0');
> OutBus2 <= Data2 when (E1 = '1') else OutBus2 <= (others=>'0');
> OutBus3 <= Data3 when (E1 = '1') else OutBus3 <= (others=>'0');
> OutBus4 <= Data4 when (E1 = '1') else OutBus4 <= (others=>'0');
> OutBus5 <= Data5 when (E1 = '1') else OutBus5 <= (others=>'0');
>
> OutBus : process(RESET, CLK)
> begin
>   if(RESET = '1') then
>      OutBus  <= (others=>'0');
>   elsif rising_edge(CLK) then
>     OutBus <= OutBus1 or OutBus2 or OutBus3 or OutBus4 or OutBus5;
>   end if
> end process;
>
> I think Mike's comment sums it up...
>
> HTH., Syms.

Hi Syms,
1. Are you sure that Xilinx FPGA compiler will generate a carry chain
structure to meet your design requirements? You must pray they would
do so, but with new keyword 'orif' Xilinx FPGA compiler will be
mandated to map 'orif' structure into a carry chain structure without
doubt.

That will be the benefit everyone would enjoy.

Letting a special VHDL language structure refer to a carry chain
implementation in FPGA is a wonderful thing.

2. Which writing pattern between ours is better, more concise and more
impressive with the price of a new keyword 'orif' introduction?

I know that anything can be written in one way or the other in VHDL,
but mutually exclusiveness is an ubiquitous phenomenon and it should
be reflected in VHDL language structure. Its referring to carry chain
in FPGA is really a God's gift, why don't we accept it?

Weng


Article: 123469
Subject: Re: PCB Layers
From: "vsurducan@gmail.com" <vsurducan@gmail.com>
Date: Tue, 28 Aug 2007 18:21:12 -0000
Links: << >>  << T >>  << A >>
On Aug 28, 8:35 am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> Thanks for all the info. I think I may be able to get away with using 8 as
> not all of the banks are fully utilised.
>
> Jon

If do you have to route GTPIO transcievers and you'll probably want
stripline then 8 layers could be at limit.


Vasile


Article: 123470
Subject: Re: PCB Layers
From: "vsurducan@gmail.com" <vsurducan@gmail.com>
Date: Tue, 28 Aug 2007 18:26:14 -0000
Links: << >>  << T >>  << A >>
On Aug 28, 6:41 am, Gabor <ga...@alacron.com> wrote:
> On Aug 28, 9:23 am, "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?
>
> > Cheers
>
> > Jon
>
> In the Virtex 2 users guide there are suggested breakout routings
> for each package.  There should be similar documentation for V4.
> Note that your layer count will depend on the design rules you
> choose for pcb manufacture.  At 1mm spacing, you may need to
> reduce your via drill size to 10 mils (gotta love mixed units
> of measure) and leave out unused pads on inner layers to allow
> more routes between adjacent pads.  With 5 mil width and spacing
> and 12/25 mil via drill/pad you can only run 1 line between pads.
>
> We've made boards using similar dense packages using from
> 8 to 12 layers depending on design rules.  For at least the
> suppliers we use, saving layer count reduces price significantly
> even if you need to use fine (10 mil) drills.
>
> Suggested breakout patterns also require dogbone removal
> on the outer two rings of pads.

Hi Gabor,
Could you point to a picture showing this tehnique ? I don't
understand what exactly means "dogbone removal".

thx,
Vasile

 Be sure to run unconnected
> outer pads to a test point since you won't be able to access
> them without the dogbone / via.
>
> After you look at the breakout drawings, don't forget to add the
> appropriate number of plane layers to deliver all of your
> supply voltages.  You may need more than 1 ground plane
> depending on your I/O switching rates.
>
> Good Luck,
> Gabor



Article: 123471
Subject: Re: New keyword 'orif' and its implications
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 28 Aug 2007 19:30:20 +0100
Links: << >>  << T >>  << A >>
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.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 123472
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 28 Aug 2007 11:30:44 -0700
Links: << >>  << T >>  << A >>
On Aug 28, 4:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 28 Aug 2007 01:11:47 -0000,
>
> Weng Tianxiang <wtx...@gmail.com> wrote:
> >I open a new topics from previous one to try to stir another round to
> >introduce a new keyword 'orif'.
>
> Weng,
>
> It seems to me that what you are trying to do is very similar
> to SystemVerilog's "unique" and "priority" keywords.  It is
> not completely clear from your posts exactly what the semantics
> of "orif" should be, but as I understand it you intend that
> "orif" should have exactly the same behaviour as "elsif",
> together with a mutual-exclusivity check so that it is an
> error if more than one of the "if" conditions is true.
> I agree that this is a desirable thing to be able to say.
>
> I do not fully understand how your combinations of "orif"
> and "elsif" are intended to work.
>
> It is also desirable to be able to specify that *at least*
> one of the conditions is true.  And then you can combine
> the "at-least-one" and "at-most-one" tests to guarantee
> that there is EXACTLY one condition true.  Note that
> SystemVerilog got this wrong, in my opinion: "unique"
> enforces exactly-one, and "priority" enforces at-least-one,
> so there is no easy way to specify at-most-one.
>
> It is easier in VHDL than Verilog, because the test
> expressions cannot have side-effects.
> --
> 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,
1. How 'elsif' and 'orif' work together?

See the following example:

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

'if', 'elsif' and 'else' play a role like brackets, putting together a
group of signals that are grouped with 'orif' between them to specify
mutually exclusiveness : there are two groups: (E0, E1, E2), (E3, E4,
E5) and signals in each group are mutually exclusive. Other grammar
meanings remain unchanged: It also means that if one of (E0, E1, E2)
is true, then 'if' statement is finished, otherwise try to test (E3,
E4, E5), like an usual 'if' statement.

The keyword 'orif' only adds the meaning that all signals in the group
are mutually exclusive, no more meaning is added. But it is enough for
compiler to do a smart job with the extra information.

For example, in the above example, two parallel carry chains can be
generated, then another LUT to put them together or more efficient LUT
allocations.

What I want is to transfer to a VHDL compiler the information that
there is mutually exclusive information about them and use them in
best interest of timing.

3. "It is also desirable to be able to specify that *at least*
one of the conditions is true. "

No such requirement is needed based on the fact that any 'if'
statement is complete: it means there is at least one hit, no more
than 2.
For example, the following example :
if(..) then
   ...
orif(...)
   ...
orif(...)
   ...
else
   ... <--- default hit
end if;

if(..) then
   ...
orif(...)
   ...
orif(...)
   ...
end if;

Above example is logically equivalent to the following one:
if(..) then
   ...
orif(...)
   ...
orif(...)
   ...
else
   null; <--- default hit
end if;

It likes the following example with 'elsif'
if(..) then
   ...
elsif(...)
   ...
elsif(...)
   ...
else
   null; <--- default hit
end if;

3. I am not fimiliar with Verilog, but from Marcus posting, I know
there is a definitive advantage of my method over Verilog's:
You have never to specify "at-least-one" and "at-most-one" tests. No.
'if' statement structure in sequential process has already null
statement as its default value as following examples show.

A2 : process(RESET, CLK)
begin
   if(RESET = '1') then
      State_A <= State_0_S;
   elsif(CLK'event and CLK = '1') then
      case State_A is
         when State_0_S =>
            if(A = '1') then
               State_A <= State_1_S;
            else
               null;
            end if;
         ...
            ...
      end case;
   end if;
end process;


A3 : process(RESET, CLK)
begin
   if(RESET = '1') then
      State_A <= State_0_S;
   elsif(CLK'event and CLK = '1') then
      case State_A is
         when State_0_S =>
            if(A = '1') then
               State_A <= State_1_S;
            end if;
         ...
            ...
      end case;
   end if;
end process;


Jonathan, I would like to address any concern you will rise.

Thank you.

Weng


Article: 123473
Subject: Re: PCB Layers
From: Gabor <gabor@alacron.com>
Date: Tue, 28 Aug 2007 11:38:07 -0700
Links: << >>  << T >>  << A >>
On Aug 28, 1:41 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "maxascent" <maxasc...@yahoo.co.uk> wrote in message
>
> news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com...
>
>
>
> > 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?
>
> > Cheers
>
> > Jon
>
> Use laser drilled microvias. You'll save the extra money they cost on by
> reducing the number of layers by 4. You only need them on the same side as
> the BGA. Layer 1 <-> Layer 2. All the other vias can be through.
> HTH., Syms.


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


Article: 123474
Subject: Re: PCB Layers
From: vasile <piclist9@gmail.com>
Date: Tue, 28 Aug 2007 19:19:29 -0000
Links: << >>  << T >>  << A >>
On Aug 28, 11:38 am, Gabor <ga...@alacron.com> wrote:
> On Aug 28, 1:41 pm, "Symon" <symon_bre...@hotmail.com> wrote:
>
>
>
>
>
> > "maxascent" <maxasc...@yahoo.co.uk> wrote in message
>
> >news:Tridnc8MvtlxvEnb4p2dnAA@giganews.com...
>
> > > 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?
>
> > > Cheers
>
> > > Jon
>
> > Use laser drilled microvias. You'll save the extra money they cost on by
> > reducing the number of layers by 4. You only need them on the same side as
> > the BGA. Layer 1 <-> Layer 2. All the other vias can be through.
> > HTH., Syms.
>
> 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?

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




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