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 127325

Article: 127325
Subject: Re: sampling error between 2 clocks
From: Sean Durkin <news_dec07@durkin.de>
Date: Tue, 18 Dec 2007 15:51:09 +0100
Links: << >>  << T >>  << A >>
wxy0624@gmail.com wrote:

> That is exactly what I am doing now, and the FPGA is working properly
> under lab condition.
> It just a warning during simulation.
> I just worry about when the environment, for example, the voltage
> changes, the temperature changes,
> or something like that.
Usually, the timing analysis that is done by the tools uses a worst case
scenario, like 85 °C temperature and a very low VCCINT.

When you look at the logfile "par" produces (it's a text file with the
ending .par in your project directory), there are lines like this at the
beginning:

"Initializing temperature to 85.000 Celsius. (default - Range: -40.000
to 100.000 Celsius)
Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260
Volts)"

You can even put the setting in you UCF:

TEMPERATURE = 75 C;

sets the temperature to 75 °C (pure magic!). I assume there's a similar
setting for the core voltage.

So unless your real-life environment isn't worse than that, you should
be safe.

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: 127326
Subject: Re: Xilinx DCM outputs for DDR
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 18 Dec 2007 15:11:24 GMT
Links: << >>  << T >>  << A >>
BobW wrote:
> 
> Using the CLK0 and CLK180 DCM outputs into two BUFGs produces less duty 
> cycle distortion than using one clock at the IOB plus the IOB's locally 
> inverted clock, when doing DDR stuff. This makes sense because the locally 
> inverted clock will always have some delay with respect to its source clock. 
> The Xilinx documentation for high speed RAM interfaces should confirm this.
> 
> I believe that Virtex5 is the first family to use differential clocks 
> internally, and this will further reduce duty cycle distortion when using 
> DDR techniques.
> 
> Bob

What about clock skew due to different loading of the two clocks?  If 
there's 1.482 ns on one and 1.876 ns on the other, doesn't the 396 ps 
swamp out any duty cycle distortion?

I'm hoping to find something more certain than "gut feel" for this 
issue.  If anyone has produced results saying one way *is* better than 
the other, I'd love to know.

If the clock routing produced the same delays, I'd agree that duty cycle 
distortion - different propagation delays for rising versus falling 
edges - would be a reason to go with clk180.  Since the clock routing 
doesn't produce the same delays (as far as I know there's no way to get 
them to match) I'm still not sure what the best method is.

- John_H

Article: 127327
Subject: Re: VCCIO issue on Xilinx Spartan3E !
From: austin <austin@xilinx.com>
Date: Tue, 18 Dec 2007 07:27:22 -0800
Links: << >>  << T >>  << A >>
Larry,

The FPGA is not a battery.  If there is that high a voltage on
unconnected banks, well, they are obviously connected to something,
aren't they?

It could be that you have a 5V CMOS driver driving an input in that
(those) bank(s), which causes the upper protection diode(s) to be
forward biased.

The voltages you have reported are greater than the abs max in the data
sheet, so you risk blowing out the gates/junctions on the IO transistors
in those banks -- DON'T DO THAT!

Austin

Article: 127328
Subject: Re: multidimensional arrays in VHDL?
From: Anuja <thakkar.anuja@gmail.com>
Date: Tue, 18 Dec 2007 07:36:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 8:50 am, "RCIngham" <robert.ing...@gmail.com> wrote:
>   <snip />
>
>
>
> >My problem was solved by using the package
> >IEEE.std_logic_unsigned.ALL; and I used the function conv_integer
> >which directly converts the std_logic_vector to integer. In this case
> >i do not have to convert the vector to unsigned.
>
> >Thank you all for your help
>
> >Anuja
>
> If you ever go on a VHDL course, I am sure that you will be told that use
> of the 'std_logic_arith', 'std_logic_signed', 'std_logic_unsigned'
> packages is DEPRECATED, and that you should only use the IEEE Standard
> 1076.3-1997 'numeric_std' (or 'numeric_bit' if not using 9-level logic)
> package. I strongly advise you to get into this good habit now.

Thank you very much for your advise

Article: 127329
Subject: Re: MGT Transciever
From: shakith.fernando@gmail.com
Date: Tue, 18 Dec 2007 08:17:02 -0800 (PST)
Links: << >>  << T >>  << A >>
hmm, Played around with it a bit more...Removed the RX and enabled the
loop back mode in a single MGT. The parallel mode gives the correct
output while the serial mode has misalignment issue. Seems like it's
nothing to do with clock correction i guess then...

Thanks,

Shakith

Article: 127330
Subject: Re: MGT Transciever
From: austin <austin@xilinx.com>
Date: Tue, 18 Dec 2007 08:32:39 -0800
Links: << >>  << T >>  << A >>
Shakith,

Generally speaking, if you turn off the encoding (8b10b or 64/66b), then
you are responsible for aligning bytes, and frames (as the MGT now just
sends bits, and gets bits, and has no knowledge of what to do with them).

A major advantage of the encoding is it defines the beginning and end of
bytes (allows for byte synchronization), and it also enforces a 1's
density such that whatever data you decide to send is unaffected by long
strings of 0's or 1's (with no encoding, serial channels will eventually
lose sync if there are no transitions from 1 to 0 or - to 1 -- this is
known as the "run length" and is something else you have to worry about
if you turn off the encoding).

My advice:  leave 8b10b on, and do it the easy way.

Austin

Article: 127331
Subject: Virtex BRAM Configuration
From: RK <sun.radha@gmail.com>
Date: Tue, 18 Dec 2007 08:41:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Folks,

I am totally new to FPGA design, so excuse me if this doesn't make
sense. Is it possible to configure the 18K Bram in Virtex II in a
different way. For example as four different 512 deep blocks of 8-
bits. What I want is FIFOs that are 512 deep and 8-bits wide, for my
convolution core.

I read through the Xilinx application note xapp258 where FIFOs for
16k, 8k, 4k, 2k and 511 are mentioned and from that it is not clear if
we can build FIFOs of different sizes.

And also are there any resources where i can get information about
building FIFOs with BRAMs or distributed RAMS.

Thanks and regards
Ramc

Article: 127332
Subject: Re: Virtex BRAM Configuration
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 18 Dec 2007 10:01:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 8:41 am, RK <sun.ra...@gmail.com> wrote:
> Hi Folks,
>
> I am totally new to FPGA design, so excuse me if this doesn't make
> sense. Is it possible to configure the 18K Bram in Virtex II in a
> different way. For example as four different 512 deep blocks of 8-
> bits. What I want is FIFOs that are 512 deep and 8-bits wide, for my
> convolution core.
>
> I read through the Xilinx application note xapp258 where FIFOs for
> 16k, 8k, 4k, 2k and 511 are mentioned and from that it is not clear if
> we can build FIFOs of different sizes.
>
> And also are there any resources where i can get information about
> building FIFOs with BRAMs or distributed RAMS.
>
> Thanks and regards
> Ramc

http://www.google.com/search?hl=en&q=site%3Axilinx.com+fifos

First hit is an spp note that can take you through much of what you
need to know.

The BRAM memories are dual-port memories meaning you could change 1
18kbit dual-port memory into two independent 9kbit single-port
memories but the only way to decompose into four independent 4k
memories is to time-multiplex your access to the memory array.
There's no way to turn one memory into 4 memories since that would
require a four-port configuration; since FIFOs normally use both ports
of a memory, an 8-port memory would even be needed.  Yikes!

Typically FIFOs are built as one FIFO per BRAM.

- John_H

Article: 127333
Subject: Re: Virtex BRAM Configuration
From: Eric Smith <eric@brouhaha.com>
Date: Tue, 18 Dec 2007 10:20:26 -0800
Links: << >>  << T >>  << A >>
RK wrote:
> I am totally new to FPGA design, so excuse me if this doesn't make
> sense. Is it possible to configure the 18K Bram in Virtex II in a
> different way. For example as four different 512 deep blocks of 8-
> bits.

No, the BRAMs only have two ports, so you can use them as two independent
1K*8 blocks.

Or you can add logic to time-multiplex them, to get more ports.  You
could effectively get four 512*8 blocks by using both ports and 2:1 
time multiplexing.

Eric

Article: 127334
Subject: Re: VCCIO issue on Xilinx Spartan3E !
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 19 Dec 2007 07:47:25 +1300
Links: << >>  << T >>  << A >>
Amontec, Larry wrote:
> Hi All,
> 
> We are on a new board with on-board XC3S250E-VQ100.
> 
> All VCCint are 1.2V
> All VCCaux are 2.5V
> Bank0 VCCio are 3.3V
> Bank2 VCCio are 3.3V
> 
> Bank1 VCCio are un-driven (not powered)
> Bank3 VCCio are un-driven (not powered)
> Bank1 VCCio and Bank3 VCCio are connected together
> 
> We can see a strange issue on VCCio of bank1 and Bank3 if they stay 
> un-driven (not powered). We can see a voltage of 4.64V on Bank1 VCCio 
> and Bank3 VCCio.
> 
> Now if we charge a 200ohm resistor on Bank1 VCCio we can see a voltage 
> of 4.05V on Bank1 VCCio and Bank3 VCCio.
> 
> Are there something wrong with our Spartan3E!
> Why this 4.64V ?
> 
> Please help to understand.

I don't think the chip cannot manufacture voltages, so you need
some simple tests
* Check the voltmeter is correct
* Find any higher voltages on the board - it is really is correct
it must be coming from somewhere else.

That's also quite a low impedance, you have pulled 24mA from the pin,
and only dropped 600mV

-jg



Article: 127335
Subject: Altera USB-Blaster on RHEL 5?
From: hess <ke9lc@yahoo.com>
Date: Tue, 18 Dec 2007 10:49:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Has anyone worked out a hack to get the USB-Blaster to work with Red
Hat 5? I need to put DE1 project boards in a lab with linux boxes that
have already been upgraded to RHEL 5. If anyone has figured it out,
I'd appreciate hearing about it; otherwise, I'll have to dig into the
USB driver stuff myself.

Article: 127336
Subject: BGA reflow soldering using vapor phase
From: kislo <kislo02@student.sdu.dk>
Date: Tue, 18 Dec 2007 11:07:53 -0800 (PST)
Links: << >>  << T >>  << A >>
I am doing some initial research regarding PCB design process with a
Spartan3E (FT256) .. Have i understood it correctly that avnet are the
only distributor of xilinx FPGA=B4s ? .. in that case, i can order a
Spartan3E witch is not lead free .. and here comes the problem -> we
have vapor phase equipment to solder the BGA on the PCB. This vapor
phase machine uses liquid which reach 240degrees (Pb-free soldering),
will this damage the non-Pb-free FPGA? If it does, i have to convince
some ppl to buy some other liquid with lower vapor temperature :/

I have read the Device Package Userguide (ug112), regarding the Reflow
soldering process .. it dosent address the vapor phase process but i
guess its the same as for a normal oven process? .. is it critical to
obey the ramp temperature requirements?

Regards
Kim

Article: 127337
Subject: Glitch warnings in Modelsim with Lattice ispLever 7.0
From: Sbreheny <sean.breheny@gmail.com>
Date: Tue, 18 Dec 2007 11:44:13 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all,

I'm having trouble trying to figure out why this VHDL synthesizes to
something which generates glitches when post-route simulated in
Modelsim.

Regardless of what I do, I always get tons of warnings from
VitalGlitch in Modelsim about glitches on slices involving "count". I
am using Precision to synthesize. These tools are all part of Lattice
ispLever v7.0. The clock is 1MHz. This is supposed to be a simple
divide by 100 counter.

I don't actually see any glitches as written (although they are
reported by modelsim). However, if I remove the range restriction on
count, I do see some glitches (this is all in sim...I have not checked
for glitches in the actual HW).

Please help!

Thanks,

Sean


Here's the code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

entity Tester is
PORT (

CLK: IN std_logic;
RESET: IN std_logic;
CS: IN std_logic;
OUTP: OUT std_logic;
QA0_d: OUT std_logic;
QA1_d: OUT std_logic);
end;

architecture RTL of Tester is

COMPONENT clock IS --Divides 1MHz clock down to 10KHz
PORT (
--Inputs
CLK1M: IN std_logic; --1MHz clock
RESET: IN std_logic; --Active Low
--Outputs
CLK10K: OUT std_logic); --10KHz clock
END COMPONENT;
begin
div: clock PORT MAP (
CLK1M => CLK,
RESET => RESET,
CLK10K => OUTP);
QA0_d <= '0';
QA1_d <= '0';
end RTL;



Now the code for the module clock:

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.ALL;
USE ieee.std_logic_arith.ALL;

ENTITY clock IS
PORT (
--Inputs
CLK1M: IN std_logic; --1MHz clock
RESET: IN std_logic; --Active Low
--Outputs
CLK10K: OUT std_logic); --10KHz clock
END clock;

ARCHITECTURE Behavioral OF clock IS
BEGIN
PROCESS(CLK1M, RESET)
variable count: integer range 0 to 255;
BEGIN
IF RESET='0' THEN
count := 0;
CLK10K <= '0';
ELSIF rising_edge(CLK1M) THEN
count := (count+1);
IF count = 51 then
clk10k <= '1';
elsif count = 100 then
count := 0;
clk10k <='0';
else null;
end if;
END IF;
END PROCESS;
END Behavioral;

Article: 127338
Subject: Re: Xilinx MAC experience ?
From: Ben Jackson <ben@ben.com>
Date: Tue, 18 Dec 2007 15:40:47 -0600
Links: << >>  << T >>  << A >>
On 2007-12-17, Robert Lacoste <> wrote:
>
> We are going to start a project in which we will need to use the hardware 
> MAC Ethernet module in a Virtex 5 for high speed transferrs (around 400KB/s) 
> through 1000BT. I'm looking for experience feedbacks : Anyone who has used 
> tihs module without a third-party TCP/IP stack (as we have in mind to 

We generated data by writing directly to a V4 hard_temac.  We didn't
configure it manually, though, there was other passthrough traffic from
a plb_temac.  The Linux driver configured the MAC (but there aren't that
many host bus registers to set if you want to use only hard_temac).
Remember you need a valid header, and an OS network stack is doing a lot
behind the scenes to handle routing, arping, etc.  If this is going off-
board, you will need something to configure your PHY, too.

It's actually easy to inject data into a hard_temac that's also being
driven by a plb_temac because the interface lets the hard_temac (or your
wedge) flow control the upstream.  So you can block the plb_temac (as
if you were a slow interface, or experiencing collisions) while you drive
the hard_temac with your data.

> Difficulties ? Quality of the documentation ? Virtex 4 
> vs 5 ? Reference designs or good sources of information ?

There are appnotes covering all of it.  If you avoid 10/100 (and go 1000
only) things are simpler (MII vs GMII reverses some of the clock flow).

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 127339
Subject: Re: Xilinx DCM outputs for DDR
From: Gabor <gabor@alacron.com>
Date: Tue, 18 Dec 2007 13:43:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 10:11 am, John_H <newsgr...@johnhandwork.com> wrote:
> BobW wrote:
>
> > Using the CLK0 and CLK180 DCM outputs into two BUFGs produces less duty
> > cycle distortion than using one clock at the IOB plus the IOB's locally
> > inverted clock, when doing DDR stuff. This makes sense because the locally
> > inverted clock will always have some delay with respect to its source clock.
> > The Xilinx documentation for high speed RAM interfaces should confirm this.
>
> > I believe that Virtex5 is the first family to use differential clocks
> > internally, and this will further reduce duty cycle distortion when using
> > DDR techniques.
>
> > Bob
>
> What about clock skew due to different loading of the two clocks?  If
> there's 1.482 ns on one and 1.876 ns on the other, doesn't the 396 ps
> swamp out any duty cycle distortion?
>
> I'm hoping to find something more certain than "gut feel" for this
> issue.  If anyone has produced results saying one way *is* better than
> the other, I'd love to know.
>
> If the clock routing produced the same delays, I'd agree that duty cycle
> distortion - different propagation delays for rising versus falling
> edges - would be a reason to go with clk180.  Since the clock routing
> doesn't produce the same delays (as far as I know there's no way to get
> them to match) I'm still not sure what the best method is.
>
> - John_H

I would tend to agree with you, but this should be easily measurable.
Using
a DDR flop with D1 high and D0 low (like a clock driver) you just need
to
look at the duty cycle.  Run the design both ways and check it out...

Article: 127340
Subject: Re: Xilinx DCM outputs for DDR
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 18 Dec 2007 15:02:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 1:43 pm, Gabor <ga...@alacron.com> wrote:
>
> I would tend to agree with you, but this should be easily measurable.
> Using
> a DDR flop with D1 high and D0 low (like a clock driver) you just need
> to
> look at the duty cycle.  Run the design both ways and check it out...-

I'm more concerned with the input side, actually.  I was thinking the
output duty cycle could get distorted just by the nature of the output
drivers but I figure LVDS would do a decent job of balancing the line.

Would a 1-up measurement really give an idea of what works better
overall?  I've read some of the Xilinx info (some a bit old) that
suggests the duty cycle distortion can add from 90 ps (Virtex-II many
years ago) to 400ps (Spartan-3, more recent) but the "DCD" timing
numbers referred to no longer show up in the DC&Switching section of
the data sheet.

For any one design, different clock loading will result in different
clock skew between a CLKFX and CLKFX180 signal unless the I/O happen
to be unaffected by clock loading elsewhere on the chip.

Measurements may start to give me an idea of what's going on in the
silicon but I would sure appreciate some concrete information.  At
least in parts with differential clocks (assuming it propagates past
one family) won't have duty cycle distortion issues.

Bleah.
- John_H

Article: 127341
Subject: Re: sampling error between 2 clocks
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 19 Dec 2007 00:28:21 GMT
Links: << >>  << T >>  << A >>

<wxy0624@gmail.com> wrote in message 
news:e43ec1f2-8d3b-47c2-b9a2-1a6fc17c7d8c@b1g2000pra.googlegroups.com...
On 12月17日, 下午6时13分, "Symon" <symon_bre...@hotmail.com> wrote:
> <wxy0...@gmail.com> wrote in message
>
> news:58990fd1-be0d-410e-85ad-37765935953b@e6g2000prf.googlegroups.com...
>
>
>
>
>
> > Xilinx V4SX35
> > ISE 8.2.03
> > Modelsim
>
> > I got CLKI(300MHz), CLKI_DIV(150MHz) generated through a counter(just
> > a flip_flop) clocked by CLKI, both clocks connect to BUFG. Then I use
> > CLKI to  sample data generated byCLKI_DIV(width=160bit), simulation
> > result in some warnings which said setuptime is not enough during
> > sampling. How can  I constraint PAR to get enough setuptime?
>
>
> Dear Whoever,
> Use CLKI to clock _all_ the synchronous elements. Use CLKI_DIV as the 
> clock
> enable for all the synchronous elements you were going to clock with
> CLKI_DIV.
> HTH., Syms.- 隐藏被引用文字 -
>
> - 显示引用的文字 -

> Thanks!
>
> That is exactly what I am doing now, and the FPGA is working properly
> under lab condition.

Read Symon's suggestion again....what you've described is NOT what he 
suggested.

> It just a warning during simulation.

And that 'warning' will turn into an intermittent functional failure for you 
eventually.

> I just worry about when the environment, for example, the voltage
> changes, the temperature changes,
> or something like that.

Temp will do it.  Try cold spraying or heat gunning your 'working properly 
under lab condition' FPGA and is likely that it will fail.

> I move the flipflop which generate CLKI_DIV to change the phase
> relationship between the two clocks,
> but it's time consuming and not effective.

That's because the correct approach is to have one clock in your design and 
have your the divided down clock be used as a clock enable.  Example:

process(CLKI)
begin
  if rising_edge(CLKI) then
     if (CLKI_DIV = '0') then
        -- Whatever you have that is currently clocked
        -- by 'CLKI_DIV' goes here.
     end if;
  end if;
end process;

> Is there some other methods to achieve the setup time?
Yes, see above and get rid of all of your processes that are clocked by 
'CLKI_DIV'

> Some kind of constraints in the UCF file?
Only if you want to have a flaky design

Kevin Jennings 



Article: 127342
Subject: Re: multidimensional arrays in VHDL?
From: JK <krishna.janumanchi@gmail.com>
Date: Tue, 18 Dec 2007 16:52:55 -0800 (PST)
Links: << >>  << T >>  << A >>
I posted code to your message in comp.lang.vhdl.
Have a look at it.

Regards,
JK

Article: 127343
Subject: Re: Xilinx DCM outputs for DDR
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 18 Dec 2007 17:29:39 -0800 (PST)
Links: << >>  << T >>  << A >>
John_H wrote:
>
> What's the best way to clock DDR flops from a DCM?
>
 In V2, the two clock net scheme works best.

 When doing this, I've avoided the DCM jitter by running
the clock into a DIFF_OUT global buffer variant without
using a DCM.

 I haven't measured this in S3E.

>
> Much of the early DDR information suggested using the 0 and 180 degree
> outputs from the DCM.  I never considered this a good design practice
> because the outputs are going through different BUFGs with different
> clock loads on each net resulting in a designed-in skew that would
> compromise the DDR sampling windows.

 I've used isolated clock nets for just the DDR I/O, with a different
net for the global logic clock, in my past V2 designs; this requires
intentional LOCing of the global buffers to the clock sites having
shared routing resources.

I posted about this a while back on the "DIFF_OUT Buffer Example"
thread, see this thread and the comments in the code example:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/367adf3537689ded

>
> Is there any real evidence one way or the other to suggest that one of
> these approaches is better than the other?
>

 I measured V2 clock duty cycle and DDR setup/hold, without
any DCM involvement, by using a two channel HP8133A and
forwarding the clock and DDR data output back out another
LVDS pair to a 20 GHz sampler.

>
> Don't newer parts route differential clocks for single global clock
> nets now?  Or is that just the Virtex series?  My designs are

 V4 and V5 have differential global routes, but in V4 some of the
regional resources are still single ended ( and because V4 can't
directly clock a global spline from a local clock input having the
best DDR I/O performance, some creative clocking workarounds are
required to avoid needing the same clock on a global & local input)

Brian

Article: 127344
Subject: Re: sampling error between 2 clocks
From: wxy0624@gmail.com
Date: Tue, 18 Dec 2007 18:46:38 -0800 (PST)
Links: << >>  << T >>  << A >>
> Yes, see above and get rid of all of your processes that are clocked by
> 'CLKI_DIV'


Thanks!

But do you mean to let all logic clocked by CLKI,
meanwhile use CLKI_DIV as a clk_enable?

That would make all the logic run at 300MHz.
I want to use concurrent logic to achieve lower clock frequency,
that is why I am using  CLKI_DIV.

Even if V4SX55 can run at 300MHz,
I don't think it's a good idea.

 And I still have to worry about the skew of CLKI_DIV,
 and the phase relationship beteen the 2 clocks,
which is the main problem.
You know, if use BUFG to drive CLKI_DIV,
the phase relationship is hard to control,
If not, the skew will be a huge problem.
These 2 problems are all I got right now,
and they are still there!

I really wanna know your solution in detail.





Article: 127345
Subject: Re: Darnaw module
From: aravind <aramosfet@gmail.com>
Date: Tue, 18 Dec 2007 21:05:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Dec 18, 3:31 pm, John Adair <g...@enterpoint.co.uk> wrote:
> Aravind
>
> Most people that has these modules only got them with the new revision
> release in the last few weeks. The first revison batch was snapped up
> very rapidly by only 2 or 3 customers taking numbers of units. Those
> modules ended up in some interesting projects. A lot of modules have
> shipped in the last few weeks so the same question in a few weeks
> should get a better response.
>
> If you have any questions in the meantime I'll be happy to answer then
> in the newsgroup or you can place a query with my team on our
> "support" email - @enterpoint.co.uk.
>
> We should be adding some applications and related information over the
> coming months as soon as we get a little less busy. We have launched a
> lot of things this month and January will bring some more. The FAQ
> page on this product will appear soon although most questions so far
> have been on the I/O available on the PGA (220 from my memory) and on
> MicroBlaze applications.
>
> John Adair
> Enterpoint Ltd.
>
> On 18 Dec, 06:18, aravind <aramos...@gmail.com> wrote:
>
>
>
> > Hi,
> >        I'm planning to purchase the Darnaw1 PGA module (http://www.enterpoint.co.uk/moelbryn/darnaw1.html). for my audio console
> > project. Has anyone worked on this module?
>
> > About my audio console project.
> > It basically consists of a system controller (ARM7/ARM9) and an FPGA.
> > The FPGA contains all the periperals like, S/PDIF receiver, ATA HDD
> > interface, FTDI Vinculum USB host interface, multichannel audio codec,
> > STA013 mp3 player interface etc. The FPGA will be connected to the
> > ARM7/9 through External Bus Interface (EBI).All the peripherals on the
> > FPGA will be mapped to some address on the EBI of ARM. Since there are
> > a lot of peripherals on the FPGA i'll require a lot of logic and I/O
> > too. I cannot afford to design/fabricate 6 layer + boards required for
> > such an FPGA. Darnaw looks like the perfect solution.
>
> > Aravind.- Hide quoted text -
>
> - Show quoted text -

Hi,
     I visited your web shop (http://www.enterpoint.co.uk/store/
erol.html#1X0), I can't seem to find the darnaw module in it and also
can u give details on shipping and payment modes. the shipping, tax
etc pages are all blank. Thanks

Aravind.

Article: 127346
Subject: Changes to use lwip 1.2.0 with Xilinx EDK 9.1 or earlier
From: Alan Nishioka <alan@nishioka.com>
Date: Tue, 18 Dec 2007 23:12:05 -0800 (PST)
Links: << >>  << T >>  << A >>
Below and at http://nishioka.com/misc/lwip-1.2.0.patch are the changes
to use lwip 1.2.0 with Xilinx EDK 9.1 or earlier
It seems the lwip api has changed slightly.
I don't have EDK 9.2 so I don't know what version of lwip is included,
but EDK 9.1 uses lwip 0.7.2.

Alan Nishioka
alan@nishioka.com


$ diff -Naur xemacif.c-orig xemacif.c
--- xemacif.c-orig      2007-12-18 22:59:57.893585600 -0800
+++ xemacif.c   2007-12-18 12:01:08.242739200 -0800
@@ -305,9 +305,12 @@
                             struct pbuf *p,
                             struct ip_addr *ipaddr)
 {
+   err_t status;
+
    XEmacIf_Config *xemacif_ptr = xemacif_ptr = netif_ptr->state;

-   p = etharp_output(netif_ptr, ipaddr, p);
+   status = etharp_output(netif_ptr, ipaddr, p);
+   if( status != ERR_OK ) return status;

    if (p != NULL) {
       /* send the frame */
@@ -329,7 +332,7 @@
    struct netif * netif_ptr = (struct netif *) CallBackRef;
    XEmacIf_Config * xemacif_ptr;
    struct eth_hdr * ethernet_header;
-   struct pbuf *p, *q;
+   struct pbuf *p;

    xemacif_ptr = netif_ptr->state;

@@ -338,25 +341,19 @@
    if (p != NULL) {
       ethernet_header = p->payload;

-      q = NULL;
       switch (htons(ethernet_header->type)) {
       case ETHTYPE_IP:
-         q = etharp_ip_input(netif_ptr, p);
+         etharp_ip_input(netif_ptr, p);
          pbuf_header(p, -14);
          netif_ptr->input(p, netif_ptr);
          break;
       case ETHTYPE_ARP:
-         q = etharp_arp_input(netif_ptr, &(xemacif_ptr->ethaddr), p);
+         etharp_arp_input(netif_ptr, &(xemacif_ptr->ethaddr), p);
          break;
       default:
          pbuf_free(p);
          break;
       }
-
-      if (q != NULL) {
-         low_level_output(netif_ptr, q);
-         pbuf_free(q);
-      }
    }

    return ERR_OK;

Article: 127347
Subject: Re: Ethernet data rates using Spartan-3 FPGA
From: tmpstr <tmpstrbox@yahoo.com>
Date: Tue, 18 Dec 2007 23:28:18 -0800 (PST)
Links: << >>  << T >>  << A >>
 Hi All,
Our current board already uses a spartan-3.
 Thats is the reason for trying to fit this in spartan-3.
 Vertex will involve more cost (211 $ or so for XC4VFX25) hence the
reluctance.

 external add on boards can also be considered. but i did not find any
suitable one

Thanks all
 -m.p

Article: 127348
Subject: Re: Xilinx MAC experience ?
From: "Robert Lacoste" <use-contact-at-www-alciom-com-for-email>
Date: Wed, 19 Dec 2007 08:28:40 +0100
Links: << >>  << T >>  << A >>
Many thanks Ben, and all others,  for these feedbacks !
Robert

"Ben Jackson" <ben@ben.com> a 閏rit dans le message de news: 
slrnfmgfiv.2jbv.ben@saturn.home.ben.com...
> On 2007-12-17, Robert Lacoste <> wrote:
>>
>> We are going to start a project in which we will need to use the hardware
>> MAC Ethernet module in a Virtex 5 for high speed transferrs (around 
>> 400KB/s)
>> through 1000BT. I'm looking for experience feedbacks : Anyone who has 
>> used
>> tihs module without a third-party TCP/IP stack (as we have in mind to
>
> We generated data by writing directly to a V4 hard_temac.  We didn't
> configure it manually, though, there was other passthrough traffic from
> a plb_temac.  The Linux driver configured the MAC (but there aren't that
> many host bus registers to set if you want to use only hard_temac).
> Remember you need a valid header, and an OS network stack is doing a lot
> behind the scenes to handle routing, arping, etc.  If this is going off-
> board, you will need something to configure your PHY, too.
>
> It's actually easy to inject data into a hard_temac that's also being
> driven by a plb_temac because the interface lets the hard_temac (or your
> wedge) flow control the upstream.  So you can block the plb_temac (as
> if you were a slow interface, or experiencing collisions) while you drive
> the hard_temac with your data.
>
>> Difficulties ? Quality of the documentation ? Virtex 4
>> vs 5 ? Reference designs or good sources of information ?
>
> There are appnotes covering all of it.  If you avoid 10/100 (and go 1000
> only) things are simpler (MII vs GMII reverses some of the clock flow).
>
> -- 
> Ben Jackson AD7GD
> <ben@ben.com>
> http://www.ben.com/ 



Article: 127349
Subject: Re: Darnaw module
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 19 Dec 2007 01:06:34 -0800 (PST)
Links: << >>  << T >>  << A >>
Aravind

It should be on the shop website soon but meantime the way to order is
to email the sales team at "boardsales" email - @enterpoint.co.uk.

2 options on international postage (1) Low cost international
(national postal services)  GBP=A310+ VAT (if applicable) for most
countries =A315 a few of the more distant countries like Australia. (2)
FEDEX usually between GBP=A322-35 + VAT depending on country.

With christmas post rush option (1) may be slow at the moment.
Normally about 1 week ship time.

FEDEX to US and Europe is usually next day, or day after if we miss
ship cutoff time. Other countires vary a little. I think the worst was
a ship to India of about 5 days.

Pricing of the DW1-1200EC-128M-16M (XC3S1200E, commercial temp, GBP=A370
+ VAT) in a one off quantity. That's in stock currently. There was a
newsletter offer running but I think that finished at the end of last
week and we have a different offer running now.

The DW1-1600EC-128M-16M version I think our stock flew off the shelf
very quickly and is currently out of stock. we are trying to schedule
another batch in assembly for mid-end January but that's subject to
finding some assembly capacity(our line is already very loaded for
Jan) and silicon arriving when it should.

Please note that Friday this week is the last shipping day for 2007.
Our planned first ship in January is on the 7th although we may start
shipping a couple of days better than that as there will be people in
the office but allocated to a stock check activity.

John Adair
Enterpoint Ltd.

On 19 Dec, 05:05, aravind <aramos...@gmail.com> wrote:
> On Dec 18, 3:31 pm, John Adair <g...@enterpoint.co.uk> wrote:
>
>
>
>
>
> > Aravind
>
> > Most people that has these modules only got them with the new revision
> > release in the last few weeks. The first revison batch was snapped up
> > very rapidly by only 2 or 3 customers taking numbers of units. Those
> > modules ended up in some interesting projects. A lot of modules have
> > shipped in the last few weeks so the same question in a few weeks
> > should get a better response.
>
> > If you have any questions in the meantime I'll be happy to answer then
> > in the newsgroup or you can place a query with my team on our
> > "support" email - @enterpoint.co.uk.
>
> > We should be adding some applications and related information over the
> > coming months as soon as we get a little less busy. We have launched a
> > lot of things this month and January will bring some more. The FAQ
> > page on this product will appear soon although most questions so far
> > have been on the I/O available on the PGA (220 from my memory) and on
> > MicroBlaze applications.
>
> > John Adair
> > Enterpoint Ltd.
>
> > On 18 Dec, 06:18, aravind <aramos...@gmail.com> wrote:
>
> > > Hi,
> > >        I'm planning to purchase the Darnaw1 PGA module (http://www.ent=
erpoint.co.uk/moelbryn/darnaw1.html). for my audio console
> > > project. Has anyone worked on this module?
>
> > > About my audio console project.
> > > It basically consists of a system controller (ARM7/ARM9) and an FPGA.
> > > The FPGA contains all the periperals like, S/PDIF receiver, ATA HDD
> > > interface, FTDI Vinculum USB host interface, multichannel audio codec,=

> > > STA013 mp3 player interface etc. The FPGA will be connected to the
> > > ARM7/9 through External Bus Interface (EBI).All the peripherals on the=

> > > FPGA will be mapped to some address on the EBI of ARM. Since there are=

> > > a lot of peripherals on the FPGA i'll require a lot of logic and I/O
> > > too. I cannot afford to design/fabricate 6 layer + boards required for=

> > > such an FPGA. Darnaw looks like the perfect solution.
>
> > > Aravind.- Hide quoted text -
>
> > - Show quoted text -
>
> Hi,
>      I visited your web shop (http://www.enterpoint.co.uk/store/
> erol.html#1X0), I can't seem to find the darnaw module in it and also
> can u give details on shipping and payment modes. the shipping, tax
> etc pages are all blank. Thanks
>
> Aravind.- Hide quoted text -
>
> - Show quoted text -




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