EDK : FSL macros defined by Xilinx are wrong

Thanks.

But the problem of FIFO16 is that
I couldn't prevent simultaneous read and write.

When the process tries to read and write FIFO at the same time by chance,
the output is distorted.
The 'empty' signal doesn't much help, because the speed difference of input
and output clk
is large(about 10 times).

How do I prevent it?

"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1143007400.912744.78060@i39g2000cwa.googlegroups.com...
The simplest solution is to make the whole asynchronous FIFO 16-bit
wide, and build a simple synchronous "pre-assembler" that composes a
16-bit input from two successive 8-bit inputs. CoreGen does the rest
for you.

Peter Alfke, Xilinx (from home)
 
But the problem of the asynch-FIFO 16 is that
I couldn't prevent simultaneous read and write.
When the process tries to read and write at the same time by chance,
the output is distorted.
You are sure you are using an async fifo from the core generator?
And you connected the right clocks?


bye,
Michael
 
Thanks to both of you.

That's what we were thinking and it's what we're investigating ...
indeed that development board seems to have a 'weak' power supply ...
 
You are using Virtez-2Pro CoreGen.
Simultaneous read/write operations on the dual-ported Block-RAM are no
problem whatsoever.
Peter Alfke, Xilinx Applications
 
Rather than relying on perfect alignment (and risking race conditions
if it is not met), I would deliberately offset the two clock domains.
Obviously, this lowers the max frequency of operation, but it really
makes things safe, if you have the timing margin.
Peter Alfke, Xilinx Applications
 
CoreGen assumes that the read and write clock (can be totally
asynchronous) are free-running, and you control the writing and reading
with the Enable signals.
It also assumes that you stop writing when Full and stop reading when
empty.
If that does not work for you, you have done something wrong. Check
your design.
Peter Alfke
 
Morten Leikvoll wrote:

Got a DCM (spartan3),
CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the
incoming clk)
CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase
with CLK1X)

How safe is it to sample a signal coming from the CLK1X domain, into the
CLK2X domain (and maybe back)?
Does this create a race condition or will this always be safe? (I know it
isnt when using modelsim, but when implementing?)
I have problems matching simulation result with real life.
My understanding was that with an appropriate input clock JITTER
constraint given to the Xilinx tools, the timing between the two domains
would be guaranteed.

I've maintained the asynchronous handshakes across the odd domains (such
as 2x to 3x domains) when I cross the 1X and 2X for safety so I haven't
had a chance to find out first hand whether the tools deliver the real
deal now that they have hold time analysis internal to the device.
 
langwadt@ieee.org wrote:

Peter Alfke skrev:


Rather than relying on perfect alignment (and risking race conditions
if it is not met), I would deliberately offset the two clock domains.
Obviously, this lowers the max frequency of operation, but it really
makes things safe, if you have the timing margin.
Peter Alfke, Xilinx Applications


I think I remember Ray saying perfect alignment could not be relied
upon
especially if the load on the two net were very different

-Lasse
I was burnt with Virtex I on relying on the 1x and 2x clock alignment.
Ever since I have been careful to avoid direct transfers from one to the
other on the same edge.

In my case, it turned out that a combination of a heavily loaded 2x
clock tree, a lightly loaded 1x clock tree, and jitter on the input
clock conspired to push the 1x and 2x clocks apart by over 500ps, which
was enough to cause the design to fail. In that case, the input clock
jitter was not from the clock source either, which made it a real bear
to find; it was coming from the input clock buffer thresholds being
modulated by outputs switching on the same bank as the clock input.

The bottom line is that jitter on the input to the DLL or DCM can cause
the 1x and 2x output edges to become misaligned, even when the loads are
perfectly balanced.
 
??

I wonder if there is any reason why it would be useful to compile the
verilog for a FPGA?

Austin

Pablo Bleyer Kocik wrote:

For those who are interested, SUN released Open SPARC today:

http://opensparc-t1.sunsource.net/download_hw.html

Verilog RTL, verification and simulation tools included.

Cheers.

--
PabloBleyerKocik /"Person who say it cannot be done
pablo / should not interrupt person doing it."
@bleyer.org / -- Chinese proverb
 
"Raymond" <raybakk@yahoo.no> wrote in message
news:1143058869.018478.68900@g10g2000cwb.googlegroups.com...
I am trying to make a webserver on my ML401 development card and I use
BSB to generate my hardware.

When I try to "Generate libraries and BSPs" I get the error:
////////////////////////////////////
ERROR:MDT - ERROR FROM TCL:- lwip () - child process exited abnormally
while executing
"exec bash -c "cd src;make all \"COMPILER_FLAGS=$compiler_flags\"
\"EXTRA_COMPILER_FLAGS=$extra_compiler_flags\" >& logs""
(procedure "::sw_lwip_v2_00_a::execs_generate" line 51)
invoked from within
"::sw_lwip_v2_00_a::execs_generate 40121220"
//////////////////////////////////////

My version on EDK is 8.101 and ISE is 8.102

My Ethernet component looks like this in my MHS FILE:
/////////////////////////////////
BEGIN opb_ethernet
PARAMETER INSTANCE = Ethernet_MAC
PARAMETER HW_VER = 1.02.a
PARAMETER C_DMA_PRESENT = 1
PARAMETER C_IPIF_RDFIFO_DEPTH = 32768
PARAMETER C_IPIF_WRFIFO_DEPTH = 32768
PARAMETER C_OPB_CLK_PERIOD_PS = 10000
PARAMETER C_BASEADDR = 0x40c00000
PARAMETER C_HIGHADDR = 0x40c0ffff
BUS_INTERFACE SOPB = mb_opb
PORT OPB_Clk = sys_clk_s
PORT PHY_rst_n = fpga_0_Ethernet_MAC_PHY_rst_n
PORT PHY_crs = fpga_0_Ethernet_MAC_PHY_crs
PORT PHY_col = fpga_0_Ethernet_MAC_PHY_col
PORT PHY_tx_data = fpga_0_Ethernet_MAC_PHY_tx_data
PORT PHY_tx_en = fpga_0_Ethernet_MAC_PHY_tx_en
PORT PHY_tx_clk = fpga_0_Ethernet_MAC_PHY_tx_clk
PORT PHY_tx_er = fpga_0_Ethernet_MAC_PHY_tx_er
PORT PHY_rx_er = fpga_0_Ethernet_MAC_PHY_rx_er
PORT PHY_rx_clk = fpga_0_Ethernet_MAC_PHY_rx_clk
PORT PHY_dv = fpga_0_Ethernet_MAC_PHY_dv
PORT PHY_rx_data = fpga_0_Ethernet_MAC_PHY_rx_data
PORT PHY_Mii_clk = fpga_0_Ethernet_MAC_PHY_Mii_clk
PORT PHY_Mii_data = fpga_0_Ethernet_MAC_PHY_Mii_data
END
///////////////////////////////////////////////

Is there anyone that can have an idea what might be the problem?

Raymond
It should be a path trouble. The compiler doesn't find the files. I had it
in a custom version of lwip: 1.01.a
But if you use lwip 2.00.a with eternet or ethernet lite core it should not
appear.
Check lwip configuration into:

Software Platform Setting
OS and Libraries
expand lwip tree

Marco
 
Hi Marco.

And thanks for answering :)

I can't find any path options here? (It maybe that I overlook
something).
What should I look for in the configuration settings?

Is it possible to download a new version of LwIP (like a custom LwIP)
and use that in stead?
By the way, I use lwip 2.00.a

Raymond
 
"bachimanchi@gmail.com" <bachimanchi@gmail.com> writes:

/opt3/synopsys/v-2003.12-sp1/pce/sparcoS5/syn/bin//design_analyzer:
line 10: 32
50 Segmentation Fault (core dumped) ${exec_name} -r
${synopsys_root} "$@"

does anyone have any idea over these kind of errors
Try to contact Synopsys. If you are on a maintenance contract you
should be able to get an upgrade.

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?
 
"Raymond" <raybakk@yahoo.no> wrote in message
news:1143116151.447290.42460@t31g2000cwb.googlegroups.com...
Hi Marco.

And thanks for answering :)

I can't find any path options here? (It maybe that I overlook
something).
What should I look for in the configuration settings?

Is it possible to download a new version of LwIP (like a custom LwIP)
and use that in stead?
By the way, I use lwip 2.00.a

Raymond
There aren't newer version of lwip.
I use a custom version because ll_temac is not supported by xilinx official
version 1.00.a and 2.00.a.

Which ethernet core are you using? Ethernet and ethernet lite cores are
fully supported.

In any case it seems a configuration trouble. Check if you have configured
every parameter into: Software Platform Setting -> OS and Libraries -> lwip
tree (expand it)
You can compare all parameters into oslib_rm.pdf

If you environment varaible Xilinx_EDK is set to C:\EDK try changing it to
C:\EDK\

Marco
 
Sylvain Munaut wrote:
Morten Leikvoll wrote:
Got a DCM (spartan3),
CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the
incoming clk)
CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase
with CLK1X)

How safe is it to sample a signal coming from the CLK1X domain, into the
CLK2X domain (and maybe back)?
Does this create a race condition or will this always be safe? (I know it
isnt when using modelsim, but when implementing?)
I have problems matching simulation result with real life.

I did this recently and it worked fine for me, both in real life and in
the simulation (note that in simulation, i generated the clock myself, I
didn't simulate the DCM). I'm working on Virtex4 with ISE7.1 & 8.1

When looking at the timing analyzing, I clearly see the path between 1x
and 2x being analyzed, taking the skew and clock uncertainty into account.

Note that I still tried to minimize the logic between the 1x reg and the
2x reg, basically I just have a mux so this part can run way faster than
the 200 MHz I ask for ;) To be sure, you can add a maxdelay constraint
in your vhdl file I think and constraint it to be < x% of your clock
period for e.g. that should give you some margin.



Sylvain
Maybe I've gotten overly conservative, but I always treat clock
boundaries as asynchronous, no matter how closely they may appear to
line up on a scope. For example, I worked on a board where the FPGA had
control of a off-chip digital signal generator, which produced the
clock for the 4th clock domain. (that clock also fed downstream A/D
converters, and the controls to the converters had to be synchronous to
that clock)

Even though the system requirements indicated that the logic should
only operate when the external PLL clock was locked to the primary
clock, and accuracy could be maintained to within +/-500 ps, I still
took all the usual precautions for clock boundaries.

Even if I were using to derivative clocks from the same oscillator, I
would *STILL* treat them as asynchronous - because they are. Don't
count on DCM's to make them "close enough".

There are plenty of tricks for crossing clock domains, but you need to
know the relative phase relationship of the clocks, the frequency
delta, and the latency tolerance of your application.
 
Hi -

The original poster was concerned with Spartan 3, so this is slightly
OT, but does anyone have experience with the V4 phase-matched clock
dividers (PCMDs)? Is is safe to transfer data between domains clocked
by two outputs of a PCMD without resorting to resynchronization?

Bob Perlman
Cambrian Design Works
 
Bob,

We designed the PMCD so that the outputs all all matched within tens of
picoseconds across P-V-T. From there, you get onto the BUFGs, and you
end up with the usual +/-100ps rule for match between BUFgs.

Austin

Bob Perlman wrote:

Hi -

The original poster was concerned with Spartan 3, so this is slightly
OT, but does anyone have experience with the V4 phase-matched clock
dividers (PCMDs)? Is is safe to transfer data between domains clocked
by two outputs of a PCMD without resorting to resynchronization?

Bob Perlman
Cambrian Design Works
 
Ralf,
First of all, thanks a lot.

yeah, it finall does get synthesized. But the time differnce is too
large.

And how do I synthesize the components seperately and then finally
"merger" them together? We work in XPS. Is it possible to do it in XPS
itself directly?

Thanks once again.

-- DotNetters
 
Personally I think the best textbook on logic design is AMD
PAL Device Handbook. All my logic training was based on the book, read
by myself, not taught at any classes.

I bought 5 VHDL books, but only the AMD book really teaches me how to
program in logic.

The open CPU source code is an excellent contributions to the
generations of logic designers by Sun Microsystem.

It would be much wonderful If there is an retired engineer from Sun who
deeply invovled in the code making writes a book with the opened source
code. It would be more valuable than any Verilog books available in the
market.

Teaching by example is the best way to teach a language and related
technique.

Real design examples give you really deep insights on what the
designers were thinking about and how nicely they handle the difficult
situations.

I appreciate Sun's efforts to open its source code.

Thank you, Sun Microsystem.

Weng
 

Welcome to EDABoard.com

Sponsor

Back
Top