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 114150

Article: 114150
Subject: dynamically created blockRAM contents?
From: "matteo" <matt.fischler@gmail.com>
Date: 5 Jan 2007 11:00:29 -0800
Links: << >>  << T >>  << A >>
I have some Verilog code that generates an array of blockRAMs to any
dimensions that I want. For example, if I set LENGTH=3 and HEIGHT=4
then 12 blockRAMs get synthesized. I have a separate script written in
Ruby that creates the initial blockRAM contents according to the
position of each blockRAM in the array. What I'd like to do is be able
to pass in the blockRAM init parameters dynamically as each blockRAM is
generated.

I'm looking for suggestions on how to do this. Can XST execute and
interact with scripts from the command line?


Article: 114151
Subject: Re: iterative algorithms + tightly coupled CPU with cloud of logic in FPGA
From: "Derek Simmons" <dereks314@gmail.com>
Date: 5 Jan 2007 11:02:52 -0800
Links: << >>  << T >>  << A >>
It sounds like you have a software solution that you want to implement
in hardware. I don't think who should be too hung up on the iterative
nature of your algorithm but instead you need to rewrite your algorithm
targeting hardware or taking advantage of the VHDL. You should be
looking for things that can be done in parallel. Pipelining can reduce
the need for memory.

An example from your description is as areas of interest are
identified, instead of marking them, pass them onto the next stage in
the solution.

I evaluated a couple of different C-to-HDL compilers. Most times they
require you to rewrite code to work within their environment. To some
extent it is like learning a new or another language. Now don't get
me wrong, there are still advantages to using these tools but I found
the VHDL that they produce wasn't optimal but 'safe'. I instead
decided to spend my time becoming a better VHDL programmer.

My advice is start by implementing your solution as a state machine. In
your algorithm, break up compound statements into simple steps. Each
step becomes a state. I developed a technique for implementing for-next
loops that I could easily manage. What I found was, while my solutions
required a lot of cycles, I could achieve higher clock frequencies.
After I was able to get a working solution that matched my software
implementation I went back and identified things that I could implement
as parallel units and pipeline.

The other thing I wanted to do was reduce the number of multipliers I
was using. So, I recoded them as shared hardware instead. The amount of
combinational logic I was using went up but I was able to reduce the
number of multipliers to 4 from 36.


Article: 114152
Subject: Re: Virtex 4 FIFO question
From: "Peter Alfke" <peter@xilinx.com>
Date: 5 Jan 2007 11:10:22 -0800
Links: << >>  << T >>  << A >>
Brad, what you describe is true in FWFT (first-word-fall-through) mode.
In NORMAL mode, RE is required to even see the first word at the
output.

The difference between the two modes (available in all Virtex-4 and
Virtex-5 chips) is only relevant for reading the very first word that
had been written into an empty FIFO.
Afterwards, RE gives you the next available word, as you descibe it,
and this behavior is then independent of the mode setting.

I envision the read operation in FWFT as "push out" and NORMAL as "pull
out".
The difference is subtle, and important only for operation around the
EMPTY situation.
Peter Alfke, Xilinx Applications


On Jan 5, 10:08 am, "Brad Smallridge" <bradsmallri...@dslextreme.com>
wrote:
> That's not my recollection.  It seems to me as soon as you do your
> first write enable, data will be available at the output some
> clock cycles later. It's better to think of the RD_EN as a GET_NEXT
> signal, rather than a READ.
>
> Brad Smallridge
> AiVision
>
> "John" <n...@null.com> wrote in messagenews:eea1578.-1@webx.sUN8CHnE...
> > The read and write signals have to be set one clock cycle before the
> > action right? If I do the following, will it read the first FIFO byte?
> 
> > ... RD_EN <= '1'; TEST <= FIFO_OUT; ...


Article: 114153
Subject: Re: lead free bga pads
From: PeteS <peter.smith8380@ntlworld.com>
Date: Fri, 05 Jan 2007 19:21:19 GMT
Links: << >>  << T >>  << A >>
Symon wrote:
> "PeteS" <PeterSmith1954@googlemail.com> wrote in message 
> news:1167756610.915575.324880@42g2000cwt.googlegroups.com...
>> I'm facing that issue right now for a FT256 package, and I'll do what
>> I've done with all the other RoHS BGA parts I've had done leadfree (and
>> that's quite a few) - use non-SMD pads with the recommended sizes from
>> the leaded versions.
>>
>> Cheers
>>
>> PeteS
>>
> Hi Pete,
> I read somewhere* that engineers used solder mask defined (SMD) pads for 
> early BGAs because the parts were made of ceramic and could pull the pads 
> off the board during vibration testing. With a SMD pad I guess the pad area 
> can be larger to stop this. When lighter packages came along, the SMD pads 
> were no longer needed, but folks carried on with SMD pads maybe because** 
> "that's the way we've always done it". However, it turns out that SMD pads 
> have a proclivity for microvoids*** at the pad/solder boundary.
> So, I wonder, now that Xilinx BGAs have metal heat spreaders built in, 
> whether their mass has increased enough to make the SMD pad necessary once 
> again. What do you think?
> 
> Cheers, Syms.
> 
> * http://www.smta.org/knowledge/proceedings_abstract.cfm?PROC_ID=252
> ** http://www.ojar.com/view_2857.htm
> *** http://www.microvoids.org/ 
> 
> 

I've been bitten *very* hard from SMD pads on BGAs, especially fine 
pitch stuff. I've put down a lot of devices with heat spreaders on 
non-SMD and never had a failure due to reflow, but I've had a *lot* of 
failures (microvoids -> HiZ, and shorts pad to pad) using SMD whether 
they had heat spreaders or not.

Unless there is a compelling reason for SMD pads (some specialised 
manufacturers specify it and I *always* ask for the reason) I won't use 
them.

Cheers

PeteS

Article: 114154
Subject: WANTED: FPGA Development Board w/ Virtex-4 LX160/200 and 2 10/100 Ethernet PHYs
From: "Frank" <FrankTDai@gmail.com>
Date: 5 Jan 2007 11:39:28 -0800
Links: << >>  << T >>  << A >>
I've been looking all over for a board with a Xilinx V4 LX160 or 200
FPGA
and 2 10/100 Ethernet PHYs. Closest I got was a board from Avnet that
only had 1 PHY.

Know where to find one? Please let me know. 

Many thanks.


Article: 114155
Subject: Re: [XST 8.2.3] DSP48 inference multiply/add
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 05 Jan 2007 12:22:29 -0800
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On 4 Jan 2007 07:14:21 -0800, "Tim Verstraete"
> <tim.verstraete@barco.com> wrote:
> 
> [Also posted to comp.lang.vhdl]
> 
>> ok, your right, now i know why it works on this code and not mine, in
>> the template i used the following libraries:
>>
>> LIBRARY ieee;
>> USE ieee.std_logic_1164.ALL;
>> use ieee.std_logic_arith.all;
>> use ieee.std_logic_signed.all;
>>
>> and in mine i used
>>
>> library IEEE;
>> use IEEE.STD_LOGIC_1164.ALL;
>> use IEEE.STD_LOGIC_ARITH.ALL;
>> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> 
> And that is PRECISELY why I keep banging on about why 
> STD_LOGIC_(UN)SIGNED is such a very, very bad thing.
> 
> If you had used only STD_LOGIC_ARITH or (better) 
> NUMERIC_STD, then you would have been forced into
> declaring the objects as SIGNED or UNSIGNED, and you
> would know what you were doing.  Having an arbitrary
> numeric representation imposed on std_logic_vector
> by a use clause is IMO certifiably insane.
> 
> Thanks for providing more ammunition for my rant :-)

These newsgroups provide plenty
of this sort of ammunition.
The source, it seems to me,
is the training examples and
editor templates from brand X and brand S.

The result is that most designers of
VHDL synthesis code are convinced that
using signed and unsigned types is a waste of time,
and that only "purists" think otherwise.

This state of affairs is only a problem
for me when I use or supply entities to
other designers. My workaround in this case
is to declare [un]signed variables for use
in my entity and implicit type conversion
for port input and output assignments
from the omnipresent std_logic_vector type.

            -- Mike Treseler


Article: 114156
Subject: Re: DC timing violation, what to do first?
From: Jim Lewis <jim@synthworks.com>
Date: Fri, 05 Jan 2007 12:48:55 -0800
Links: << >>  << T >>  << A >>
Davy,
You really have not provided enough information to
make any judgment at this point.

What is the desired frequency of your design?
What frequency does your static timing analysis
say it will run at?
What did you set your clock constraints at?

With DC and ASIC libraries, it is very common to
overconstrain the clock by between 10 to 20%.
If you did not do this, I would do this first.

If you are using DC for FPGAs, you are using the
wrong tool, my first step in this case would be
to use the free versions of Xilinx and Altera and
see if that does not fix your issue.  If you
do use DC for FPGAs, expect it to be a wrestling
match - there are lots of coding and tool tricks.

Next I would look at the long timing paths.
What caused them?  Look at the logic created.
Is it what you expected?  If it is not what you
expected, then you need to re-write your code so
that it does create the hardware you want - this
can be a trial and error process.  Usually you
start with a picture of what you want and make
the code match it.  If that does not work, further
refine the picture until the code does give you
what you want.

Next I would look at potential false and multi-cycle
paths as the others suggested.  However, I do not
like doing this unless I have to because if you are
wrong, your final silicon will not work.

Your last alternative is pipelining, architecture
exploration, and changing the clock frequency.

Good Luck,
Jim






> Hi all,
> 
> I am new to Synopsys DC. And I have a basic problem. When I find timing
> violation in DC report, what shall I do first?
> 
> 1. Shall I change the script of DC? To let the tools do something like
> retiming?
> 2. Shall I change the RTL code? To pipeline the comb logic manually?
> 3. Other choice, please recommend.
> 
> What circumstance to do "1" or "2" or "1 and 2 at the same time"?
> 
> Best regards,
> Shenli
> 

Article: 114157
Subject: timing constraints properly setup
From: "axr0284" <axr0284@yahoo.com>
Date: 5 Jan 2007 13:25:26 -0800
Links: << >>  << T >>  << A >>
Hi,
 I am wondering if I wrote the timing constraint properly.
 I have 2 clocks (clk, phy_rx_clk) coming in from the outside. clk is
used to run part of my FF
phy_rx_clk goes in a dcm and I use CLK0 and CLK180 output of the dcm.
The data coming into the FPGA will have a minimum setup time 1.4 ns and
minimum hold time 1.2 ns. CLK0 and CLK180 are used on DDR clock inputs.
I need to make sure the setup and hold time will not be violated so i
setup the constraint file as follows. I was wondering if somebody could
check it out and let me know if I am doing anything wrong.

NET "clk" TNM_NET = "clk_grp";
TIMESPEC "TS_clk" = PERIOD "clk_grp" 8 ns HIGH 50 %;

NET "phy_rx_clk" TNM_NET = "phy_rx_clk_grp";
TIMESPEC "TS_phy_rx_clk" = PERIOD "phy_rx_clk_grp" 8 ns HIGH 50 %;

NET "CLK0_rx" TNM = "CLK0_rx_grp";
NET "CLK180_rx" TNM = "CLK180_rx_grp";

TIMEGRP "CLK0_rx_grp_ddr" = RISING "CLK0_rx_grp"; # Check wrt rising
edge
TIMEGRP "CLK180_rx_grp_ddr" = RISING "CLK180_rx_grp"; # Check wrt
rising edge

OFFSET = IN 1.4 ns BEFORE "phy_rx_clk" TIMEGRP "CLK0_rx_grp_ddr";
#1.4ns setup

OFFSET = IN 1.2 ns AFTER "phy_rx_clk" TIMEGRP "CLK0_rx_grp_ddr"; #1.2ns
hold

For some reason I get
WARNING:ConstraintSystem:65 - Constraint <OFFSET = IN 1.2 ns AFTER COMP
"phy_rx_clk" TIMEGRP CLK0_rx_grp_...>
   [.\ethernet.pcf(556)] overrides constraint <OFFSET = IN 1.4 ns
BEFORE COMP "phy_rx_clk" TIMEGRP CLK0_rx_grp...>
   [.\ethernet.pcf(554)].

I cannot figure out why. Anybody can enlighten me. I am using Xilinx
ISE 8.2


Article: 114158
Subject: Anyone seen eASIC?
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 05 Jan 2007 14:01:31 -0800
Links: << >>  << T >>  << A >>
Has anyone here seen (or better yet, used) eASIC? http://www.easic.com

It seems to be an FPGA programmed using a laser (so not really "F" PGA).
Of course, this means it isn't re-writeable.
Claims to be price competitive to FPGAs (even in small quantities).

Opinions?

Article: 114159
Subject: Re: Surface mount ic's
From: Philip Freidin <philip@fliptronics.com>
Date: Fri, 05 Jan 2007 22:28:21 GMT
Links: << >>  << T >>  << A >>
On Tue, 2 Jan 2007 10:14:21 -0000, "Symon" <symon_brewer@hotmail.com> wrote:
><smount> wrote in message news:4599cdbe$1_4@mk-nntp-2.news.uk.tiscali.com...
>> Does anyone know what is needed to work with surface mount
>> ic's, what sort of starting price tag are we talking about?
>> (Assuming I have ready made boards, i.e. only the soldering
>> phase is required)
>>
>Hi,
>Try this Google search:-
>solder group:comp.arch.fpga author:freidin
>
>Philip gives a list of links you'll find interesting.
>HTH, Syms.


  http://www.fpga-faq.com/archives/96550.html#96560


I recently bought this:   http://www.sra-solder.com/aoyue_2702.htm

and this:                 http://store.amscope.com/sm-3tz.html

and this:                 http://store.amscope.com/md600.html

I plan to create training movies on how to do SMT board assembly,
SMT rework, and SMT repair.  Any interest?

Philip



Philip Freidin
Fliptronics

Article: 114160
Subject: Problems with 7:1 LVDS Tx using OSEDES (Xilinx)
From: "rao" <raonpc@gmail.com>
Date: 5 Jan 2007 14:47:04 -0800
Links: << >>  << T >>  << A >>
Hi,
  I am trying to make 7:1 LVDS Tx for a display solution (XGA and SXGA)
and trying to use
  the approach as specified in xilinx app note XAPP704 (virtex-4 high
speed single data rate
  LVDS transceiver). The reference design that xilinx provided is for
4:1 (4 parallel data goes
  to 1 channel of LVDS) and it works fine but when I try to change the
parameters to operate
  as 7:1 the design doesn't work (the serial data output doesn't
correspond to parallel data input).

  As the maximum bit per channel for a xilinx OSERDES is 6 I have to
use two OSERDES in
  seires (as master and slave) to make a 7:1 channel.

  I would like to know if any worked on this aspect before and I do
appreciate if any one can
  provide some helpful info to proceed.

Regards
rao


Article: 114161
Subject: Re: Anyone seen eASIC?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 05 Jan 2007 14:54:45 -0800
Links: << >>  << T >>  << A >>
David,

Per their website, they have 5 members of their 90nm technology, with
basic fabric clock speed of 350 MHz.  They offer a version with embedded
ARM processor, too.

They do not have a 65nm product offering (yet).  The Xilinx 65nm V5 line
has a fabric which runs to 550 MHz (along with all the stuff that has to
run with it).

The V4 line has all 17 parts shipping.  The V5 line has all 6 LX parts
in ES now, and all 6 LXT ES is just starting.  That is 12 family members
in the logic specific family, alone.  Then you add the SX, SXT, FX, FXT...

They do not have the following hardened macros:
MGTs
DSP blocks
TEMACs
PCIe
PPCs (plural, as in two IBM Power PC's in the larger parts)
APU
etc.
I would think that they would have a huge line of hard blocks to spice
up their offering, but then that requires a massive support burden (so
they don't?).

They do not have domain specific families, such as logic, digital signal
processing, or high speed serial IO/embedded processors (basically the
LX, SX and FX mix we offer).

They do not offer a lower performance, cost reduced option line
(Spartan), nor is there any offering to immediately reduce costs (like
our EasyPath-tm).

They (claim) offer "ASIC" like power (as in very low static power, but
since I have to register to read their datasheet, I can't verify that).
 They do offer fast turnaround (once you know it works).  They do have
smaller die (fewer transistors, cost per die are low).

I would be concerned about their SEU tolerance, as 90nm ASIC are at
about 1000 FIT/Mb or M gates.  That puts their largest device at 10
years between failures from SEU's (compared with >50 times that number
for the comparable V5 part, or greater than 500 years MTBFF).

So, nice line, looks useful.  How does it compare/compete with a
re-programmable "latest and greatest" FPGA Family?  That is up to you,
the engineers who have the applications.

Austin



David R Brooks wrote:
> Has anyone here seen (or better yet, used) eASIC? http://www.easic.com
> 
> It seems to be an FPGA programmed using a laser (so not really "F" PGA).
> Of course, this means it isn't re-writeable.
> Claims to be price competitive to FPGAs (even in small quantities).
> 
> Opinions?

Article: 114162
Subject: Re: Anyone seen eASIC?
From: PeteS <peter.smith8380@ntlworld.com>
Date: Fri, 05 Jan 2007 23:21:00 GMT
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> David,
> 
> Per their website, they have 5 members of their 90nm technology, with
> basic fabric clock speed of 350 MHz.  They offer a version with embedded
> ARM processor, too.
> 
> They do not have a 65nm product offering (yet).  The Xilinx 65nm V5 line
> has a fabric which runs to 550 MHz (along with all the stuff that has to
> run with it).
> 
> The V4 line has all 17 parts shipping.  The V5 line has all 6 LX parts
> in ES now, and all 6 LXT ES is just starting.  That is 12 family members
> in the logic specific family, alone.  Then you add the SX, SXT, FX, FXT...
> 
> They do not have the following hardened macros:
> MGTs
> DSP blocks
> TEMACs
> PCIe
> PPCs (plural, as in two IBM Power PC's in the larger parts)
> APU
> etc.
> I would think that they would have a huge line of hard blocks to spice
> up their offering, but then that requires a massive support burden (so
> they don't?).
> 
> They do not have domain specific families, such as logic, digital signal
> processing, or high speed serial IO/embedded processors (basically the
> LX, SX and FX mix we offer).
> 
> They do not offer a lower performance, cost reduced option line
> (Spartan), nor is there any offering to immediately reduce costs (like
> our EasyPath-tm).
> 
> They (claim) offer "ASIC" like power (as in very low static power, but
> since I have to register to read their datasheet, I can't verify that).
>  They do offer fast turnaround (once you know it works).  They do have
> smaller die (fewer transistors, cost per die are low).
> 
> I would be concerned about their SEU tolerance, as 90nm ASIC are at
> about 1000 FIT/Mb or M gates.  That puts their largest device at 10
> years between failures from SEU's (compared with >50 times that number
> for the comparable V5 part, or greater than 500 years MTBFF).
> 
> So, nice line, looks useful.  How does it compare/compete with a
> re-programmable "latest and greatest" FPGA Family?  That is up to you,
> the engineers who have the applications.
> 
> Austin
> 
> 
> 
> David R Brooks wrote:
>> Has anyone here seen (or better yet, used) eASIC? http://www.easic.com
>>
>> It seems to be an FPGA programmed using a laser (so not really "F" PGA).
>> Of course, this means it isn't re-writeable.
>> Claims to be price competitive to FPGAs (even in small quantities).
>>
>> Opinions?

Without having seen the line information, but having seen such types of 
announcement in the past I would ask:

Is there true characterisation data?

a. IO
b. IOBuf delays
c. Pin details
d. (Most important) Icc vs. specific implementations.

I have yet to see one of these parts compete properly on power and cost 
against the two competitors -> FPGA for effective cost and flexibility 
-> true ASIC *or* controller for low power (no offense, but FPGAs just 
can't compete in the really low power domain).

I'll have a look tomorrow

Cheers

PeteS


Article: 114163
Subject: Xilinx 2-D DCT core (Where?).
From: "Pete Fraser" <pfraser@covad.net>
Date: Fri, 5 Jan 2007 15:37:53 -0800
Links: << >>  << T >>  << A >>
I'm running 8.2.03i, and expected to find the 2-D
DCT core when I fired up the core generator.

It either wasn't there, or I'm going blind.

Where might I find it?

Thanks 



Article: 114164
Subject: Re: Problems with 7:1 LVDS Tx using OSEDES (Xilinx)
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 5 Jan 2007 16:50:03 -0800
Links: << >>  << T >>  << A >>
> As the maximum bit per channel for a xilinx OSERDES is 6
> I have to use two OSERDES in
>  seires (as master and slave) to make a 7:1 channel.

I have been able to get the master/slave OSERDES going at 7:1 rates.
It's required for Camera Link interfaces, however, I used the single
clock edge rate. No amount of kludging allowed the double edge rate.

Perhaps the VHDL code below will give you some clues:

Brad Smallridge
AiVision


 signal shift1 : std_logic;
 signal shift2 : std_logic;

begin

   OSERDES_master : OSERDES
   generic map (
      DATA_RATE_OQ => "SDR",   -- Specify data rate to "DDR" or "SDR"
      DATA_RATE_TQ => "BUF",   -- Specify data rate to "DDR", "SDR", or 
"BUF"
      DATA_WIDTH   => 7,       -- DDR: 4,6,8,10  SDR BUF: 2,3,4,5,6,7, or 8
      INIT_OQ => '0',          -- INIT for Q1 register - '1' or '0'
      INIT_TQ => '0',          -- INIT for Q2 register - '1' or '0'
      SERDES_MODE => "MASTER", -- Set SERDES mode to "MASTER" or "SLAVE"
      SRVAL_OQ => '0',         -- Define Q1 output value upon SR assertion - 
'1' or '0'
      SRVAL_TQ => '0',         -- Define Q1 output value upon SR assertion - 
'1' or '0'
      TRISTATE_WIDTH => 1)     -- Specify parallel to serial converter width
                               -- When DATA_RATE_TQ = DDR: 2 or 4
                               -- When DATA_RATE_TQ = SDR or BUF: 1 "
   port map (
      OQ => q,                -- 1-bit output
      SHIFTOUT1 => open,      -- 1-bit output
      SHIFTOUT2 => open,      -- 1-bit output
      TQ => open,             -- 1-bit output
      CLK => clk,             -- 1-bit input
      CLKDIV => clkdiv,       -- 1-bit input
      D1 => data(0),          -- 1-bit input
      D2 => data(1),          -- 1-bit input
      D3 => data(2),          -- 1-bit input
      D4 => data(3),          -- 1-bit input
      D5 => data(4),          -- 1-bit input
      D6 => data(5),          -- 1-bit input
      OCE => '1',             -- 1-bit input
      REV => '0',             -- 1-bit input
      SHIFTIN1 => shift1,     -- 1-bit input
      SHIFTIN2 => shift2,     -- 1-bit input
      SR => '0',              -- 1-bit input
      T1 => '0',              -- 1-bit input
      T2 => '0',              -- 1-bit input
      T3 => '0',              -- 1-bit input
      T4 => '0',              -- 1-bit input
      TCE => '0' );           -- 1-bit input

   OSERDES_slave : OSERDES
   generic map (
      DATA_RATE_OQ => "SDR",   -- Specify data rate to "DDR" or "SDR"
      DATA_RATE_TQ => "BUF",   -- Specify data rate to "DDR", "SDR", or 
"BUF"
      DATA_WIDTH   => 7,       -- DDR: 4,6,8,10  SDR BUF: 2,3,4,5,6,7, or 8
      INIT_OQ => '0',          -- INIT for Q1 register - '1' or '0'
      INIT_TQ => '0',          -- INIT for Q2 register - '1' or '0'
      SERDES_MODE => "SLAVE",  -- Set SERDES mode to "MASTER" or "SLAVE"
      SRVAL_OQ => '0',         -- Define Q1 output value upon SR assertion - 
'1' or '0'
      SRVAL_TQ => '0',         -- Define Q1 output value upon SR assertion - 
'1' or '0'
      TRISTATE_WIDTH => 1)     -- Specify parallel to serial converter width
                               -- When DATA_RATE_TQ = DDR: 2 or 4
                               -- When DATA_RATE_TQ = SDR or BUF: 1 "
   port map (
      OQ => open,             -- 1-bit output
      SHIFTOUT1 => shift1,    -- 1-bit output
      SHIFTOUT2 => shift2,    -- 1-bit output
      TQ => open,             -- 1-bit output
      CLK => clk,             -- 1-bit input
      CLKDIV => clkdiv,       -- 1-bit input
      D1 => '0',              -- 1-bit input
      D2 => '0',              -- 1-bit input
      D3 => data(6),          -- 1-bit input
      D4 => '1',              -- 1-bit input
      D5 => '1',              -- 1-bit input
      D6 => '1',              -- 1-bit input
      OCE => '1',             -- 1-bit input
      REV => '0',             -- 1-bit input
      SHIFTIN1 => '0',        -- 1-bit input
      SHIFTIN2 => '0',        -- 1-bit input
      SR => '0',              -- 1-bit input
      T1 => '0',              -- 1-bit input
      T2 => '0',              -- 1-bit input
      T3 => '0',              -- 1-bit input
      T4 => '0',              -- 1-bit input
      TCE => '0' );           -- 1-bit input



Article: 114165
Subject: Help Implementing an 1000Base-T Ethernet on Stratix II GX
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: 5 Jan 2007 16:52:53 -0800
Links: << >>  << T >>  << A >>
Hello, I'm looking to implement an Ethernet Controller to support
1000Base-T on a Stratix II GX and would like to know if anyone could
suggest an IP Core? I've been looking over the Atlera IP web site and
have found some IP's, but I wanted to see what other people were using.

thanks,
joe


Article: 114166
Subject: Re: Surface mount ic's
From: Tim <simon@nooospam.roockyloogic.com>
Date: Sat, 06 Jan 2007 01:04:08 +0000
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> I recently bought this:   http://www.sra-solder.com/aoyue_2702.htm
> 
> and this:                 http://store.amscope.com/sm-3tz.html
> 
> and this:                 http://store.amscope.com/md600.html
> 
> I plan to create training movies on how to do SMT board assembly,
> SMT rework, and SMT repair.  Any interest?
> 
> Philip

Now all you need is a Gerber-driven solder paste dot printer! They 
exist, and news of an affordable unit for prototyping would be interesting.

Tim

Article: 114167
Subject: data transfer from fast APB clock domain.
From: "marco" <marcoa.castellon@gmail.com>
Date: 5 Jan 2007 17:11:40 -0800
Links: << >>  << T >>  << A >>
Hello.

I have a peripheral with an AMBA APB interface.
The issue that I am facing is that of clock domain crossing.
The processing logic in the peripheral is required to operate at a
relatively slow clock frequency, but the clock frequency of the APB
interface can be 4 to 5 times that of the slow clock domain.
I have been considering the two clock domains as asynchronous with
respect to each other, even though the faster clock is generated from
the slow clock by means of a PLL; therefore, the phase relationship
between the two clock should be constant.

My problems lies in the fact that APB has no signal to hold the bus in
the case where the data from a write cycle to the slow clock domain has
not yet been registered by the slow clock when a second write cycle
starts to happen.

I am considering to options:
1) Have the Configuration Registers clocked with the fast clock signal
and only have event signals generated by a write or a read cross the
clock domain boundary.

2) Buffer data with a FIFO and synchronize the control signals to the
slow clock domain.

Any suggestions would be appreciated.
Thank you in advance.
Best Regards,
Marco.


Article: 114168
Subject: Re: ISE Simulator radix question
From: "Duth" <premduth@gmail.com>
Date: 5 Jan 2007 17:38:27 -0800
Links: << >>  << T >>  << A >>
Hi Fred,

This was actually a bug in ISE Simulator in the 8.xi versions. We have
addressed this in ISE 9.1i. After doing some research we found out that
a majority of users like to see the values in HEX rather than decimal.
This is why in ISE 9.1i, ISE Simulator will always default to HEX in
the waveforms.

Also another feature we have added is to save the settings such as the
radix and the order of the signals once you have changed it. This is
now saved on a per project basis, so the next time you reopen the
simulation, if you had right clicked and selected that you wanted the
bus to be in ASCII for example, then it will maintain your preference.


Hope that this helps
Thanks
Duth


Fred wrote:
> The default radix on waveforms is decimal and although I can right click the
> waveforms and change the radix to hex, it reverts back to decimal if I
> resimulate the design.
>
> Is there any way in the test bench VHDL file, or anywhere else, I can force
> the radix to remain to be hexadecimal?


Article: 114169
Subject: Re: Problems with 7:1 LVDS Tx using OSEDES (Xilinx)
From: "rao" <raonpc@gmail.com>
Date: 5 Jan 2007 18:12:52 -0800
Links: << >>  << T >>  << A >>
Hi
  Thank you for your info.

  My design is in verilog and almost simular as you have shown
  ( except for the slave OSERDES my connections are

  >       D1 => open,              -- 1-bit input
  >       D2 => open,              -- 1-bit input
  >       D3 => data(6),           -- 1-bit input
  >       D4 => open,              -- 1-bit input
  >       D5 => open,              -- 1-bit input
  >       D6 => open,              -- 1-bit input    ).

  I tried your approach of 0 for D1 and D2, 1 for D4, D5 and D6 for
Slave.

  But I couldn't verify the serial Data of the channel w.r.to the
parallel data input to the
  channel.

  Suppose the parallel data is [ABDCEFG] then in next clkdiv cycle the
channel data
  output should be A-B-C-D-E-F-G per clk. I could n't verify the
process.

  // Master
      OSERDES TX_DAT_OUT_00  (.OQ(PREDATOUT[0]), .SHIFTOUT1(),
.SHIFTOUT2(),        .TQ(), .CLK(TXCLK), .CLKDIV(TXCLKDIV), .D1(DI[0]),
 .D2(DI[1]),  .D3(DI[2]),  .D4(DI[3]),  .D5(DI[4]),  .D6(DI[5]),
.OCE(OCE), .REV(1'b0), .SHIFTIN1(S2M1[0]), .SHIFTIN2(S2M2[0]),
.SR(ORST), .T1(), .T2(), .T3(), .T4(), .TCE());

  // Slave
      OSERDES TX_DAT_OUT_00S (.OQ(),             .SHIFTOUT1(S2M1[0]),
.SHIFTOUT2(S2M2[0]), .TQ(), .CLK(TXCLK), .CLKDIV(TXCLKDIV), .D1(1'b0),
 .D2(1'b0),   .D3(DI[6]),  .D4(1'b1),   .D5(1'b1),   .D6(1'b1),
.OCE(OCE), .REV(1'b0), .SHIFTIN1(),        .SHIFTIN2(),
.SR(ORST), .T1(), .T2(), .T3(), .T4(), .TCE());

Regards
rao

Brad Smallridge wrote:
> > As the maximum bit per channel for a xilinx OSERDES is 6
> > I have to use two OSERDES in
> >  seires (as master and slave) to make a 7:1 channel.
>
> I have been able to get the master/slave OSERDES going at 7:1 rates.
> It's required for Camera Link interfaces, however, I used the single
> clock edge rate. No amount of kludging allowed the double edge rate.
>
> Perhaps the VHDL code below will give you some clues:
>
> Brad Smallridge
> AiVision
>
>
>  signal shift1 : std_logic;
>  signal shift2 : std_logic;
>
> begin
>
>    OSERDES_master : OSERDES
>    generic map (
>       DATA_RATE_OQ => "SDR",   -- Specify data rate to "DDR" or "SDR"
>       DATA_RATE_TQ => "BUF",   -- Specify data rate to "DDR", "SDR", or
> "BUF"
>       DATA_WIDTH   => 7,       -- DDR: 4,6,8,10  SDR BUF: 2,3,4,5,6,7, or 8
>       INIT_OQ => '0',          -- INIT for Q1 register - '1' or '0'
>       INIT_TQ => '0',          -- INIT for Q2 register - '1' or '0'
>       SERDES_MODE => "MASTER", -- Set SERDES mode to "MASTER" or "SLAVE"
>       SRVAL_OQ => '0',         -- Define Q1 output value upon SR assertion -
> '1' or '0'
>       SRVAL_TQ => '0',         -- Define Q1 output value upon SR assertion -
> '1' or '0'
>       TRISTATE_WIDTH => 1)     -- Specify parallel to serial converter width
>                                -- When DATA_RATE_TQ = DDR: 2 or 4
>                                -- When DATA_RATE_TQ = SDR or BUF: 1 "
>    port map (
>       OQ => q,                -- 1-bit output
>       SHIFTOUT1 => open,      -- 1-bit output
>       SHIFTOUT2 => open,      -- 1-bit output
>       TQ => open,             -- 1-bit output
>       CLK => clk,             -- 1-bit input
>       CLKDIV => clkdiv,       -- 1-bit input
>       D1 => data(0),          -- 1-bit input
>       D2 => data(1),          -- 1-bit input
>       D3 => data(2),          -- 1-bit input
>       D4 => data(3),          -- 1-bit input
>       D5 => data(4),          -- 1-bit input
>       D6 => data(5),          -- 1-bit input
>       OCE => '1',             -- 1-bit input
>       REV => '0',             -- 1-bit input
>       SHIFTIN1 => shift1,     -- 1-bit input
>       SHIFTIN2 => shift2,     -- 1-bit input
>       SR => '0',              -- 1-bit input
>       T1 => '0',              -- 1-bit input
>       T2 => '0',              -- 1-bit input
>       T3 => '0',              -- 1-bit input
>       T4 => '0',              -- 1-bit input
>       TCE => '0' );           -- 1-bit input
>
>    OSERDES_slave : OSERDES
>    generic map (
>       DATA_RATE_OQ => "SDR",   -- Specify data rate to "DDR" or "SDR"
>       DATA_RATE_TQ => "BUF",   -- Specify data rate to "DDR", "SDR", or
> "BUF"
>       DATA_WIDTH   => 7,       -- DDR: 4,6,8,10  SDR BUF: 2,3,4,5,6,7, or 8
>       INIT_OQ => '0',          -- INIT for Q1 register - '1' or '0'
>       INIT_TQ => '0',          -- INIT for Q2 register - '1' or '0'
>       SERDES_MODE => "SLAVE",  -- Set SERDES mode to "MASTER" or "SLAVE"
>       SRVAL_OQ => '0',         -- Define Q1 output value upon SR assertion -
> '1' or '0'
>       SRVAL_TQ => '0',         -- Define Q1 output value upon SR assertion -
> '1' or '0'
>       TRISTATE_WIDTH => 1)     -- Specify parallel to serial converter width
>                                -- When DATA_RATE_TQ = DDR: 2 or 4
>                                -- When DATA_RATE_TQ = SDR or BUF: 1 "
>    port map (
>       OQ => open,             -- 1-bit output
>       SHIFTOUT1 => shift1,    -- 1-bit output
>       SHIFTOUT2 => shift2,    -- 1-bit output
>       TQ => open,             -- 1-bit output
>       CLK => clk,             -- 1-bit input
>       CLKDIV => clkdiv,       -- 1-bit input
>       D1 => '0',              -- 1-bit input
>       D2 => '0',              -- 1-bit input
>       D3 => data(6),          -- 1-bit input
>       D4 => '1',              -- 1-bit input
>       D5 => '1',              -- 1-bit input
>       D6 => '1',              -- 1-bit input
>       OCE => '1',             -- 1-bit input
>       REV => '0',             -- 1-bit input
>       SHIFTIN1 => '0',        -- 1-bit input
>       SHIFTIN2 => '0',        -- 1-bit input
>       SR => '0',              -- 1-bit input
>       T1 => '0',              -- 1-bit input
>       T2 => '0',              -- 1-bit input
>       T3 => '0',              -- 1-bit input
>       T4 => '0',              -- 1-bit input
>       TCE => '0' );           -- 1-bit input


Article: 114170
Subject: query
From: "premrajan" <premsundari@gmail.com>
Date: 5 Jan 2007 22:23:20 -0800
Links: << >>  << T >>  << A >>
iam using mentor graphics modelsim6.2d  for running verilog codes,can
anyone tell me how to use code coverage in batch


Article: 114171
Subject: Re: Spartan3E minimum clock-to-output (hold time)
From: nico@puntnl.niks (Nico Coesel)
Date: Sat, 06 Jan 2007 08:05:03 GMT
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote:

>On Jan 5, 9:19 am, n...@puntnl.niks (Nico Coesel) wrote:
>> "Lars" <lar...@gmail.com> wrote:
>> >I've been looking all over but have been unable to find any numbers for
>> >minimum clock-to-output propagation delay for Spartan3E. Anyone have a
>> >clue as to what can be expected. The design is very straight forward: A
>> >clock inut to a GCLK pin, a BUFG clock driver clocking an IO-block data
>> >and output enable flip-flop. Maximum clock-to-output delay is reported
>> >at some 6.8 ns. This matches fine the data in the Spartan3E data sheet
>> >tables 85, 90 and 93 (5.51 ns + 0.43 ns + 0.70 ns for LVTTL clock input
>> >and LVTTL 12 mA SLOW output).
>>
>> >But how can I find the minimum delay to satisfy the external component
>> >hold time requirement of 1.5 ns? My reasoning that the fetch loop
>> >clock-pad -> clock driver -> output ff -> output pad "ought" to be more
>> >than 1.5 ns under all conditions, but it would shure feel better if I
>> >could have it in writing!I have been looking for this also. Best thing to do is use the timing
>> analyzer on an existing design. The minimum clock to output delay is
>> used to calculate (IIRC) the hold timing.
>>

>The accepted definition is: 25% of the max value as it is specified for
>the fastest speed grade.
>(If the max delay for the fastest speed grad is 4 ns, then the min
>value of that parameter for all speed grades is "no shorter than 1.0
>ns")
>Assuming min to be "75% of max" is utter nonsense.
>Why the wide range?
>It covers temperature changes, Vcc changes, and processing variations,
>and also testing guardbands. All of this in the worst-case direction.
>Also; While max delays are tested, min delays are usually not testable,
>and must be "guaranteed by design, or by characterization".
>Luckily, a synchronous design is not concerned about min delays inside
>the chip.
>Memory interfaces often are sensitive, and ask for careful and creative
> design methodologies.

...and for more precise numbers on internal and external timing. Which
brings me to the question: how does the Xilinx timing analyzer
determine the minimum delay? Does it use 25% of fastest max. value or
does it use worst case delays obtained by measurements and simulation?

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 114172
Subject: Re: [XST 8.2.3] DSP48 inference multiply/add
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Sat, 06 Jan 2007 13:02:34 +0000
Links: << >>  << T >>  << A >>
On Fri, 05 Jan 2007 12:22:29 -0800, Mike Treseler
<mike_treseler@comcast.net> wrote:

>Jonathan Bromley wrote:
>> On 4 Jan 2007 07:14:21 -0800, "Tim Verstraete"
>> <tim.verstraete@barco.com> wrote:
>> 
>> [Also posted to comp.lang.vhdl]
>> 
>>> ok, your right, now i know why it works on this code and not mine, in
>>> the template i used the following libraries:
>>>
>>> LIBRARY ieee;
>>> USE ieee.std_logic_1164.ALL;
>>> use ieee.std_logic_arith.all;
>>> use ieee.std_logic_signed.all;

>> Thanks for providing more ammunition for my rant :-)
>
>These newsgroups provide plenty
>of this sort of ammunition.
>The source, it seems to me,
>is the training examples and
>editor templates from brand X and brand S.

Indeed. Furthermore, at least half the time, having included the
std_logic_arith type libraries, the code doesn't ever use them!

It is normal practice for me to comment out these "use" clauses;
normally the code just compiles without them, and I have one less thing
to worry about. (In the rare examples that actually use them, it's not
usually difficult to make them numeric_std clean, though I don't always
bother)

- Brian

Article: 114173
Subject: Re: data transfer from fast APB clock domain.
From: "Jon Beniston" <jon@beniston.com>
Date: 6 Jan 2007 06:00:07 -0800
Links: << >>  << T >>  << A >>

marco wrote:
> Hello.
>
> I have a peripheral with an AMBA APB interface.
> The issue that I am facing is that of clock domain crossing.
> The processing logic in the peripheral is required to operate at a
> relatively slow clock frequency, but the clock frequency of the APB
> interface can be 4 to 5 times that of the slow clock domain.
> I have been considering the two clock domains as asynchronous with
> respect to each other, even though the faster clock is generated from
> the slow clock by means of a PLL; therefore, the phase relationship
> between the two clock should be constant.
>
> My problems lies in the fact that APB has no signal to hold the bus in
> the case where the data from a write cycle to the slow clock domain has
> not yet been registered by the slow clock when a second write cycle
> starts to happen.

AMBA APB version 3 has such a signal I believe, pready.

Cheers,
Jon


Article: 114174
Subject: Re: lead free bga pads
From: "Symon" <symon_brewer@hotmail.com>
Date: Sat, 6 Jan 2007 15:23:18 -0000
Links: << >>  << T >>  << A >>

"PeteS" <peter.smith8380@ntlworld.com> wrote in message 
news:Pyxnh.53333$UC.34379@newsfe5-win.ntli.net...
>
> I've been bitten *very* hard from SMD pads on BGAs, especially fine pitch 
> stuff. I've put down a lot of devices with heat spreaders on non-SMD and 
> never had a failure due to reflow, but I've had a *lot* of failures 
> (microvoids -> HiZ, and shorts pad to pad) using SMD whether they had heat 
> spreaders or not.
>
> Unless there is a compelling reason for SMD pads (some specialised 
> manufacturers specify it and I *always* ask for the reason) I won't use 
> them.
>
> Cheers
>
> PeteS
>
Hi Pete,
Thanks for your comments. It more or less reflects my experiences, although 
I've not vibration tested an FPGA with heat-spreader design.

On a related subject, what do you think about via-in-pad. I've had great 
success with this, but recently people seem to be shying away from it.

http://www.pcblibraries.com/resources/GEN-docs.asp
Near the bottom, Solving the Metric Pitch BGA & Micro BGA Dilemma

On page 30, the guy says that the voids are no problem, which backs up my 
experience. I wondered if you have a view on this?

Thanks, 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