EDK : FSL macros defined by Xilinx are wrong

Ray,

I'm not the best person to talk further on this topic, so I'll direct
you to:

http://www.xilinx.com/publications/xcellonline/xcell_55/xc_pdf/xcell55_all.pdf

and read Steve Lass' article, specifically thru page 8.

For those who don't want to download the whole issue of Xcell:

http://www.xilinx.com/publications/xcellonline/xcell_55/xc_timing55.htm

and not have to deal with pdf, either.

You will miss the lovely artwork, but the content is the same.

He details the new Xplorer tool which (I think) finds the optimal we
used to find, and then creates the proper constraints and command file
so that subsequent compiles do not have to start from scratch.

http://www.xilinx.com/publications/xcellonline/xcell_55/xc_xplorer55.htm

for the details, courtesy of Hitesh Patel.

He also mentions PlanAhead, as well.

Thanks to Steve & Hitesh for the timely appearance of this!

And thanks to you Ray for the opportunity to post these useful links ...

Austin
 
I think you can find it in the altera website,also you can ask the
sales for help.
 
Hi Reza!


I will recommend two readings that will save you a lot of headache:

The first one is an expensive, but invaluable book (sorry, don't know
if it exists in a Verilog version): "VHDL for Logic Synthesis"


And the second one is a free PDF downloadable from Actel homepage:
"Actel HDL Coding"

(I am sure the other players have their own HDL coding style guides
too, but this one looks the best).

They will show you how synthesizers work internally.

good luck!
(and happy new year)



PS. for some reason some people one the newsgroups waste a lot of their
own time and our time by giving non-answers. If you dont have an
answer, dont post!!
 
Hi,
I have implemented a I2C bus core by myself.

When reading, a multiple source 'error' would happen if your code
assertes the acknowledge bit slightly earlier than the target deasserts
the bus from the last read data bit or when writing, if your code
deasserts the acknowledge bit slightly later than the target asserts
the acknowledge bit on the bus.

You may ignore them totally without any problem.

Weng
 
<wtxwtx@gmail.com> schrieb im Newsbeitrag
news:1135593905.451170.291220@f14g2000cwb.googlegroups.com...
Hi,
I have implemented a I2C bus core by myself.

When reading, a multiple source 'error' would happen if your code
assertes the acknowledge bit slightly earlier than the target deasserts
the bus from the last read data bit or when writing, if your code
deasserts the acknowledge bit slightly later than the target asserts
the acknowledge bit on the bus.

You may ignore them totally without any problem.

Weng

http://xilant.com/content/view/31/55/
Click to expand...

Weng, the multipy source error is usually fatal synthesis error and prevents
the bitstream generation until fixed.

the OP has problem wiring up the processor data bus, not the SDA/SCL lines
IMHO

Antti
 
Hi Antti,
Thank you for indicating my wrong answer.

I misunderstood the problem.

One of errors is multi-source data_bus(7 downto 0) are assigned in more
than one processes!

It is easy to correct it:
Use search key to search signal 'data_bus' through the module source
file and see how many times the data_bus are assigned. Put all
assignments in one process only.

Weng
 
<wtxwtx@gmail.com> schrieb im Newsbeitrag
news:1135599779.396787.40140@g14g2000cwa.googlegroups.com...
Hi Antti,
Thank you for indicating my wrong answer.

I misunderstood the problem.

One of errors is multi-source data_bus(7 downto 0) are assigned in more
than one processes!

It is easy to correct it:
Use search key to search signal 'data_bus' through the module source
file and see how many times the data_bus are assigned. Put all
assignments in one process only.

Weng

Weng you are a bit mistaken again the data_bus is assigned once outside
Click to expand...
process

data_bus <= data_out when (r_w = '1' and dtack_oe = '1') else (others =>
'Z');

in the uc_interface.vhd

so the ip-core is 100% proper for its intended function - controller for
external microcontroller.

for on-chip soc bus, the uc_interface module should be replaced, or
modified.

antti
 
Hi Rob,

Thanks for the moral support.

There is a jumper to make these bank 7 inputs 2.5V instead of 3.3V which I
switched. No effect.

I ran the inputs into a second camera jack available on my daughter board,
to see if I had some solder problems on the first jack. That resulted in the
same issues.

My scope is old so I am just looking at the tiniest wiggles but again they
seem to be OK. In fact I can see the LVAL in the original signal making it
wiggle higher than the rest of the signal.

Are you using IDELAY to control the timing?

Brad


"Rob" <robnstef@frontiernet.net> wrote in message
news:1Y_rf.430$qg.31@news02.roc.ny...
I know on Altera parts you have to tell the tool to turn on the on-chip
termination resistors: it may be the same with Xilinx. Also, I know on
V2PRO parts the banks running differenital I/O must be operated with a 2.5V
VCCIO.

Also, I would look at the inputs at the connector to make sure that they
are acting as expected. If you don't have a differential probe you can
get a reasonable look with a single ended one. This is just to make sure
that you're not chasing the wrong problem.

I've done many designs with Camera Link so let me know if you need
anything else.

Let us know what you find.


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11r0jedsghr3me0@corp.supernews.com...
Hello,

Having trouble with some LVDS signals coming from a Camera Link
interface. I expect to see from steady signals coming from this line
camera. DVAL=1. But it's not there. And the LVAL, line valid, only comes
on for maybe one clock, and I expect it to come on for 2K clocks.

I am using IBUFDS as inputs. The UCF file loc the pins but that is all.
Do I need something more to drop the 100 ohm termination resitance?

Brad Smallridge
aivision.com
Click to expand...
 
Cédric Jeanneret <cedric.jeanneret@epfl.ch> writes:

But I've a problem. How to initialize Microblaze's BRAM without
generating the bitstream of my submodule ?
Click to expand...
You can do this with the "bitinit" program. Here's an extract from the
makefile I've made for this purpose (under Linux with PPC rather than
MB):

$(CHIP)-fpga-ppc.bit: $(CHIP)-fpga.bit ../system/TestApp/executable.elf
bitinit ../system/system.mhs -bm ../system/implementation/system_stub_bd.bmm \
-pe ppc405_0 ../system/TestApp/executable.elf -bt $< -o $@

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Mike,

Frequency does not matter. It is all about rise time.

A fast rise time will create reflections. Reflections will create
multiple edges. Multiple edges will cause double clocking. Double
clocking will cause the device to be confused, and not configure.

If you simulate the entire trace for CCLK, with the actual dimensions,
and impedances, and loads and drivers (such as using Mentor's Hyperlynx
SI tool), you will see what I am referring to.

Also, if you simulate the run, you may find how to do this without a
termination.

It is so much simpler if we just tell you to do this as a best practice,
rather than require you to simulate the trace, and design the net such
that it has no reflections.

Typically CCLK runs to many devices, so making such a net have no
reflections is not possible without a parallel termination at the end of
the run.

Austin

shogmic wrote:

Hello all,

I am new to this group, but it has already been a great resource..
thanks to all who post advice and suggestions! Good stuff.

My current issue involves the Virtex-4 configuration pin called CCLK,
which according to the V-4 Configuration Guide, "is different from
previous Xilinx FPGAs" and requires parallel Thevenin termination.
Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled
up to Vcco and a 100 ohm pulled down to GND. Two questions:

1) Is this REALLY necessary, or just a good thing to have when
configuring a device at higher CCLK frequencies? What if I just clock
the bitstream at, say, 1 MHz?

2) What should I do since I want to have the option of using both
Master Serial and Slave Serial? The CCLK signal will potentially
terminate at either side, so where should the termination resistor(s)
be placed?

Thanks in advance,
-mike.
Click to expand...
 
I have replaced the ISERDES with an inferred serial to parallel converter
and so I believe my problem was not with the ISERDES but with the input pin
not being able to see a sustained high. Do the differential LVDS inputs need
pullups? Below is the new code:

xclk_delay_process: process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_xclk_serial_bit(0) <= cam1_xclk;
cam1_xclk_serial_bit(1) <= cam1_xclk_serial_bit(0);
cam1_xclk_serial_bit(2) <= cam1_xclk_serial_bit(1);
cam1_xclk_serial_bit(3) <= cam1_xclk_serial_bit(2);
cam1_xclk_serial_bit(4) <= cam1_xclk_serial_bit(3);
cam1_xclk_serial_bit(5) <= cam1_xclk_serial_bit(4);
cam1_xclk_serial_bit(6) <= cam1_xclk_serial_bit(5);
if( cam1_xclk_serial_bit(2)='1' and cam1_xclk_serial_bit(1)='0' ) then
cam1_x0_en <= '1';
cam1_x1_en <= '1';
cam1_x2_en <= '1';
cam1_x3_en <= '1';
else
cam1_x0_en <= '0';
cam1_x1_en <= '0';
cam1_x2_en <= '0';
cam1_x3_en <= '0';
end if;
end if;
end process;


--------------------------------------------------------------------------
-- Camera Link Deserializers
--
-- Each of the four serial streams X0 X1 X2 and X3
-- have a pair of differential inputs _n and _p
-- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 )
-- that must be reconciled with an IBUFDS (Input BUFfer Differential Swing)

cam1_x0_ibufd_inst : IBUFDS
port map (
O => cam1_x0,
I => cam1_in(1),
IB => cam1_in(0) );

cam1_x0_serial_process : process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_x0_serial_bit(0) <= cam1_x0;
cam1_x0_serial_bit(1) <= cam1_x0_serial_bit(0);
cam1_x0_serial_bit(2) <= cam1_x0_serial_bit(1);
cam1_x0_serial_bit(3) <= cam1_x0_serial_bit(2);
cam1_x0_serial_bit(4) <= cam1_x0_serial_bit(3);
cam1_x0_serial_bit(5) <= cam1_x0_serial_bit(4);
cam1_x0_serial_bit(6) <= cam1_x0_serial_bit(5);
if( cam1_x0_en='1' ) then
cam1_x0_bit(0) <= cam1_x0_serial_bit(0);
cam1_x0_bit(1) <= cam1_x0_serial_bit(1);
cam1_x0_bit(2) <= cam1_x0_serial_bit(2);
cam1_x0_bit(3) <= cam1_x0_serial_bit(3);
cam1_x0_bit(4) <= cam1_x0_serial_bit(4);
cam1_x0_bit(5) <= cam1_x0_serial_bit(5);
cam1_x0_bit(6) <= cam1_x0_serial_bit(6);
end if;
end if;
end process;
 
I would suggest doing whatever they say. I have had trouble designing a
Spartan board downloading at 5Mhz. Adding the resistors helped quite a bit
but still I have some flyby taps at about 10mm that still give me trouble.
It also helps if you can turn off the other clocks during your download
periods.

Don't know about your master/slave problem. Perhaps you can add a series
resistance and get by with that as, as you say, you want to clock at 1 MHz.

"shogmic" <shogmic@iit.edu> wrote in message
news:1135721828.251908.18690@g47g2000cwa.googlegroups.com...
Hello all,

I am new to this group, but it has already been a great resource..
thanks to all who post advice and suggestions! Good stuff.

My current issue involves the Virtex-4 configuration pin called CCLK,
which according to the V-4 Configuration Guide, "is different from
previous Xilinx FPGAs" and requires parallel Thevenin termination.
Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled
up to Vcco and a 100 ohm pulled down to GND. Two questions:

1) Is this REALLY necessary, or just a good thing to have when
configuring a device at higher CCLK frequencies? What if I just clock
the bitstream at, say, 1 MHz?

2) What should I do since I want to have the option of using both
Master Serial and Slave Serial? The CCLK signal will potentially
terminate at either side, so where should the termination resistor(s)
be placed?

Thanks in advance,
-mike.
Click to expand...
 
Antti -

Yes, I've found several serious bugs so far, hence the desire for a
testbench.

If I can't find anything and what I write is not too ugly, I'll
probably post it.

John Providenza
 
As Austin wrote, the frequency does not matter, the rise/fll time does,
and it is really not under your control.
So, make sure that the CCLK distribution is one serial "worm". not a
tree with many branches. then terminate it at the very end. Your enemy
are the reflections that result in double-triggering.
If everything else fails, you can load the clock with 100 pF, but that
is just a dirty emergency repair. Another dirty trick is to put 10 Ohm
in series with the CCLK driver, and then decouple the downstream side
of that resistor with 100 pF. Austin would never recommend this, but I
sense your desperation...
Peter Alfke

shogmic wrote:
Hello all,

I am new to this group, but it has already been a great resource..
thanks to all who post advice and suggestions! Good stuff.

My current issue involves the Virtex-4 configuration pin called CCLK,
which according to the V-4 Configuration Guide, "is different from
previous Xilinx FPGAs" and requires parallel Thevenin termination.
Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled
up to Vcco and a 100 ohm pulled down to GND. Two questions:

1) Is this REALLY necessary, or just a good thing to have when
configuring a device at higher CCLK frequencies? What if I just clock
the bitstream at, say, 1 MHz?

2) What should I do since I want to have the option of using both
Master Serial and Slave Serial? The CCLK signal will potentially
terminate at either side, so where should the termination resistor(s)
be placed?

Thanks in advance,
-mike.
Click to expand...
 
My CL work has always been done within Altera parts. I use their PLL and
timing constraints to get the timing I need to pick off the data correctly.

One thing that has always helped me in debuging this type of design is to,
if possible, turn off the video while still allowing the control signals to
go through. Perhaps you have the abilty to generate a test pattern.
Setting the test pattern to all 0's will enable you not to confuse the
control bits with a video signal. And then I usually pick lsync and tune
the timing until it is coming out in the correct position. Do you have the
ability to look at the parallel data: perhaps you can send the parallel data
to test points?

Have you verified that the termination resistors are getting turned on? Or
do you have on-board discrete resistors?

My experience with CL problems has always been FPGA timing. What is your
clock speed? I've run with 66MHz clocks (x7 462Mbps) and one must be very
careful not to have too much skew between the high speed clock and your
input shift registers.

Rob



"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11r1sjkjnoccp44@corp.supernews.com...
Hi Rob,

Thanks for the moral support.

There is a jumper to make these bank 7 inputs 2.5V instead of 3.3V which I
switched. No effect.

I ran the inputs into a second camera jack available on my daughter board,
to see if I had some solder problems on the first jack. That resulted in
the same issues.

My scope is old so I am just looking at the tiniest wiggles but again they
seem to be OK. In fact I can see the LVAL in the original signal making it
wiggle higher than the rest of the signal.

Are you using IDELAY to control the timing?

Brad


"Rob" <robnstef@frontiernet.net> wrote in message
news:1Y_rf.430$qg.31@news02.roc.ny...
I know on Altera parts you have to tell the tool to turn on the on-chip
termination resistors: it may be the same with Xilinx. Also, I know on
V2PRO parts the banks running differenital I/O must be operated with a
2.5V VCCIO.

Also, I would look at the inputs at the connector to make sure that they
are acting as expected. If you don't have a differential probe you can
get a reasonable look with a single ended one. This is just to make sure
that you're not chasing the wrong problem.

I've done many designs with Camera Link so let me know if you need
anything else.

Let us know what you find.


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11r0jedsghr3me0@corp.supernews.com...
Hello,

Having trouble with some LVDS signals coming from a Camera Link
interface. I expect to see from steady signals coming from this line
camera. DVAL=1. But it's not there. And the LVAL, line valid, only comes
on for maybe one clock, and I expect it to come on for 2K clocks.

I am using IBUFDS as inputs. The UCF file loc the pins but that is all.
Do I need something more to drop the 100 ohm termination resitance?

Brad Smallridge
aivision.com
Click to expand...
 
"Peter Alfke" <alfke@sbcglobal.net> wrote in message

If everything else fails, you can load the clock with 100 pF, but that
is just a dirty emergency repair.
Click to expand...
Wow, I'm so relieved to see that someone else has done this. The real trick,
however, is to make sure that this hack works long enough, in production, so
that your stock options are vested, exercised, and sold.

I guess it's safe for me to come out-of-the-closet, now. Thanks for your
honesty, Peter.

Bob
 
I've never needed to pull-up LVDS signals that were being driven. I've
driven as far as 10feet, too. Remember, the voltage genereated is a result
of the current passing through the termination resistor.

Are you saying that the inferred serial to parallel code works and the
ISERDES doesn't? Do you have both the negative and the postive signals
called out in your designs UCF file?


"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:11r3s94o15o8q6a@corp.supernews.com...
I have replaced the ISERDES with an inferred serial to parallel converter
and so I believe my problem was not with the ISERDES but with the input pin
not being able to see a sustained high. Do the differential LVDS inputs
need pullups? Below is the new code:

xclk_delay_process: process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_xclk_serial_bit(0) <= cam1_xclk;
cam1_xclk_serial_bit(1) <= cam1_xclk_serial_bit(0);
cam1_xclk_serial_bit(2) <= cam1_xclk_serial_bit(1);
cam1_xclk_serial_bit(3) <= cam1_xclk_serial_bit(2);
cam1_xclk_serial_bit(4) <= cam1_xclk_serial_bit(3);
cam1_xclk_serial_bit(5) <= cam1_xclk_serial_bit(4);
cam1_xclk_serial_bit(6) <= cam1_xclk_serial_bit(5);
if( cam1_xclk_serial_bit(2)='1' and cam1_xclk_serial_bit(1)='0' ) then
cam1_x0_en <= '1';
cam1_x1_en <= '1';
cam1_x2_en <= '1';
cam1_x3_en <= '1';
else
cam1_x0_en <= '0';
cam1_x1_en <= '0';
cam1_x2_en <= '0';
cam1_x3_en <= '0';
end if;
end if;
end process;


--------------------------------------------------------------------------
-- Camera Link Deserializers
--
-- Each of the four serial streams X0 X1 X2 and X3
-- have a pair of differential inputs _n and _p
-- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 )
-- that must be reconciled with an IBUFDS (Input BUFfer Differential
Swing)

cam1_x0_ibufd_inst : IBUFDS
port map (
O => cam1_x0,
I => cam1_in(1),
IB => cam1_in(0) );

cam1_x0_serial_process : process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_x0_serial_bit(0) <= cam1_x0;
cam1_x0_serial_bit(1) <= cam1_x0_serial_bit(0);
cam1_x0_serial_bit(2) <= cam1_x0_serial_bit(1);
cam1_x0_serial_bit(3) <= cam1_x0_serial_bit(2);
cam1_x0_serial_bit(4) <= cam1_x0_serial_bit(3);
cam1_x0_serial_bit(5) <= cam1_x0_serial_bit(4);
cam1_x0_serial_bit(6) <= cam1_x0_serial_bit(5);
if( cam1_x0_en='1' ) then
cam1_x0_bit(0) <= cam1_x0_serial_bit(0);
cam1_x0_bit(1) <= cam1_x0_serial_bit(1);
cam1_x0_bit(2) <= cam1_x0_serial_bit(2);
cam1_x0_bit(3) <= cam1_x0_serial_bit(3);
cam1_x0_bit(4) <= cam1_x0_serial_bit(4);
cam1_x0_bit(5) <= cam1_x0_serial_bit(5);
cam1_x0_bit(6) <= cam1_x0_serial_bit(6);
end if;
end if;
end process;
Click to expand...
 
Bob wrote:
I guess it's safe for me to come out-of-the-closet, now. Thanks for your
honesty, Peter.

My suggestion is like a band-aid or an aspirin.
Click to expand...
Perhaps effective, but really just camouflaging the true problem.
The true problem is improper lay-out or wrong termination, generating
double-pulses from the fast transitions. The CCLK frequency itself is
irrelevant.
Peter Alfke
 
"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1135743326.126840.299580@g47g2000cwa.googlegroups.com...
Bob wrote:
I guess it's safe for me to come out-of-the-closet, now. Thanks for your
honesty, Peter.

My suggestion is like a band-aid or an aspirin.
Perhaps effective, but really just camouflaging the true problem.
The true problem is improper lay-out or wrong termination, generating
double-pulses from the fast transitions. The CCLK frequency itself is
irrelevant.
Peter Alfke
Click to expand...
Yep, that's a common misconception that it's the frequency that causes
reflections.

We did a board that had a "double-pulse" problem on a 1MHz JTAG test port
(one TCK buffer output driving multiple JTAG ports). Now, we distribute TCK
like any other clock, and source terminate each buffer output.

It all seems so easy, now, but it's taken a couple of 'ahshits' to get
there.

Bob
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top