EDK : FSL macros defined by Xilinx are wrong

[MM]

Run the Flash programmer under debugger and see what the problem is.
Alternatively you can see what's going on with the ChipScope.

/Mikhail


"Goli" <togoli@gmail.com> wrote in message
news:436789c8-d38d-49a3-b09f-79acb2fa684c@a18g2000pra.googlegroups.com...

Hi,

I am using EDK10.1, and I have Atmel 32MB flash on my board,
(AT49BV322D). But whenever I try to program the flash through the
Device configuration, Program Flash tab it says, Unable to query part
layout using CFI.

I have checked all the connections and even probed the signals, they
all seem to be fine.

Is there anything special that I have to do?

--
Goli

 

[Joseph H Allen]

There are a number of ways to do this. Here is one way:

What you usually want is for the clock at the pin of the SRAM chip to rise
at the same time as the FPGA internal global clock driving the output pads.

A way to do this is to route the clock from the second PLL to two output
pins (right next to each other). One pin goes to the SSRAM. The other pin
goes to the feedback input of the PLL. The trace length for this feedback
line should be the same as the one which goes to the RAM. You have to use a
dedicated PLL feedback input pin for this to work. This way is nice because
you can usually leave the PLL phase shift setting at 0.

You have to use an "enhanced" PLL with external feedback pin and set it to
use external feedback pin mode.

In article <11ffca10-bec7-4cb7-bed4-458a3a8743dd@v13g2000pro.googlegroups.com>,
Tommy Thorn <tommy.thorn@gmail.com> wrote:

I wrote a little controller + tester app for the SSRAM on Terasic's
DE2-70 which is rated for 200 MHz. I have gotten it working @ 170 MHz,
but I'm a little uneasy about the SSRAM clock. Being a non-EE I
suspect I'm missing something fundamental here.

First, all output are fully registered (and constrained to guarantee
they stay registered). The main logic is clocked by a PLL. A second
but identically configured output on this PLL drives the SSRAM. The
SSRAM datasheet lists the setup and hold times for the inputs as 1.4
ns / 0.4 ns respectively. What is the correct way to achieve this?
Phase-shift the SSRAM clock? Specify it as a timing constraint? Do
timing constraints influence the output buffer or are they purely for
checking?

Keeping the clock in phase with the main clock led to errors showing
up (once beyond 100 MHz), but shifting it a few degrees made it
perfectly stable again. However, what is the appropriate engineering
approach to this source synchronous problem?

Any help would be much appreciated.

Thanks,
Tommy


FWIW, these are the constraints I'm currently using:

# timing constraints for SSRAM
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to oSRAM*
set_instance_assignment -name FAST_OUTPUT_REGISTER ON -to SRAM_*
set_instance_assignment -name FAST_OUTPUT_ENABLE_REGISTER ON -to
SRAM_*
set_instance_assignment -name TCO_REQUIREMENT "3 ns" -to oSRAM*
set_instance_assignment -name TCO_REQUIREMENT "3 ns" -to SRAM*
set_instance_assignment -name TSU_REQUIREMENT "2.2 ns" -to SRAM*

# other default timings
set_global_assignment -name TSU_REQUIREMENT "5 ns"
set_global_assignment -name TCO_REQUIREMENT "10 ns"

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0%79-77?1:0<1659?79:0>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 

[Symon]

Gael Paul wrote:

Symon,

It would seems we fully agree:

Hi Gael,
Thanks for your reply, that's the way I think also. I guess we're no good at
this usenet thing! Two people actually agreeing? What is the internet coming
to?
Best, Syms.

p.s. Another little trick I discovered is to force the synthesis tool to use
connect the clock enable directly to the purpose built CE pins on the slice.
Synplify has something like this:-
attribute direct_enable of clken :signal is true;
The CE pin has less setup time than using the F or G logic LUTs, and so
helps the timing. It seems from experience that the synthesis tool doesn't
do this by default, indeed it's possible that some FFs may have more than
enable, and so the tool needs to be told which is the mutli-cycle enable to
be used on the CE pin.

 

[Nico Coesel]

uraniumore238@gmail.com wrote:

I am using a XILINX Spartan II XC2S50 board and would like to know
what the maximum clock rating for the chip is and if I can clock it
with an in-coming clock osc. at 150 MHz...

Downloading the datasheet from Xilinx is a good start. If you can
actually use this frequency depends on your design. I expect 150MHz is
a bit too much for a Spartan II to do something usefull.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Kappa]

Hi Jerzy Gbur.

I'm not sure I understood. But what I propose is, for narrow band set,
for example [0 - 511 Data] [512 - 1535 Nul] [1536 - 2047 Data], It
depend what band you exactly want.
Lenght of IFFT transform should stay the same.

I still do not understand ... how can I reduce the number of carriers if I
have to maintain a "Standard" ?

On DVB-T 2K mode the carriers is 1705. This carriers with IFFT 2048 obtain
the time domain. If output data at the clock of 7/64e-6 obtain of 8 MHz
band.

How clock with this sample at 1/8e-6 with same clock of 64 MHz for obtain a
7 MHz of band ???

IMHO it's most simple way to filfull your requirements.

How ???

Thanks.

Kappa.

 

[KJ]

<langwadt@fonz.dk> wrote in message
news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9@w7g2000hsa.googlegroups.com...

with a three step wave, e.g. high, tristate,low, two resistors and the
right timing it
should be possible to get no 3rd harmonic

That third (and other) harmonics will still be there.

KJ

 

[Symon]

Symon wrote:

have more than enable, and so the tool needs to be told which is the

more than _one_ enable

 

[Allan Herriman]

"KJ" <kkjennings@sbcglobal.net> wrote in news:Y8wDk.1655$Ws1.508
@nlpi064.nbdc.sbc.com:

langwadt@fonz.dk> wrote in message
news:d976369a-b3a5-4cc2-ac41-c5811e83dbe9
@w7g2000hsa.googlegroups.com...

with a three step wave, e.g. high, tristate,low, two resistors and the
right timing it
should be possible to get no 3rd harmonic


That third (and other) harmonics will still be there.

KJ

Indeed!

However, using two outputs with different weighting resistors it is
(more or less) possible to eliminate the troublesome 3rd and 5th
harmonics.

Here is the output pattern for each cycle of the "sine wave":

AB
10
11
11
10
01
00
00
01

The A output is weighted more strongly than the B output by a factor of
(1 + sqrt(2)).

Regards,
Allan

 

[Nico Coesel]

jhallen@TheWorld.com (Joseph H Allen) wrote:

There are a number of ways to do this. Here is one way:

What you usually want is for the clock at the pin of the SRAM chip to rise
at the same time as the FPGA internal global clock driving the output pads.

A way to do this is to route the clock from the second PLL to two output
pins (right next to each other). One pin goes to the SSRAM. The other pin
goes to the feedback input of the PLL. The trace length for this feedback
line should be the same as the one which goes to the RAM. You have to use a
dedicated PLL feedback input pin for this to work. This way is nice because
you can usually leave the PLL phase shift setting at 0.

This is quite cumbersome and the PLL will add extra jitter (clock
uncertainty). An easier way without the extra jitter is to use an
output flipflop (aka DDR flipflop) which can be clocked using 2
clocks. The first clock sets the output, the second clock (inverted
first clock) resets the output. And presto, you'll have a clock output
which is (within pin-to-pin skew) perfectly synchronous to the other
outputs.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[KJ]

"Nico Coesel" <nico@puntnl.niks> wrote in message
news:48dfe4ee.168426254@news.planet.nl...

jhallen@TheWorld.com (Joseph H Allen) wrote:

An easier way without the extra jitter is to use an
output flipflop (aka DDR flipflop) which can be clocked using 2
clocks. The first clock sets the output, the second clock (inverted
first clock) resets the output. And presto, you'll have a clock output
which is (within pin-to-pin skew) perfectly synchronous to the other
outputs.

Hold time requirements (like the .4ns in the OP) will be impossible to
guarantee with this method though.

KJ

 

[Symon]

vlodiya@gmail.com wrote:

Guys,

I am designing a conventional Digital down converter on virtex
-4 Sx55 FPGA for GSM applications.

The Input clock frequency is above 160 Mhz for the initial CIC
decimation filter. After decimation , the data is fed to low pass
filter at a very low rate of ~1 Mhz

The issue is ,I am not able to generate this low frequency clcok with
Virtex -4 DCM , obviously the min output frequency is 32 Mhz.

Hi Vijay,

You don't need to generate a 1MHz clock, instead you should generate a 1MHz
clock enable for the parts of your design that run at 1MHz. The whole design
is clocked at 160MHz, but the slow part is only enabled for one cycle in
160. This makes it a trivial task to pass data between the domains of the
design.
Cheers, Syms.

 

[Symon]

Fred wrote:

I've been tasked to write some code for an FPGA to interface to
10BASE- T Ethernet using differential drivers and receivers.

http://www.fpga4fun.com/10BASE-T.html

 

[Nico Coesel]

Benjamin Krill <ben@codiert.org> wrote:

Hi,

On Mon, 2008-09-29 at 08:10 -0700, Fred wrote:
Do I require any ARP or any other protocol? Will it just work, with
the destination PC receiving UDP packets?

You have to include the FPGA host (mac and ip) into the ARP table of the
host PC. Then you didn't need to implement the ARP protocol.

That won't be necessary. You don't even have to know the IP & MAC
address of the destination if you broadcast the data.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Nico Coesel]

Benjamin Krill <ben@codiert.org> wrote:

On Mon, 2008-09-29 at 08:34 -0700, cs_posting@hotmail.com wrote:

I don't think that will be needed, since the PC is not expected to
reply.

I suppose there might be software on the PC that would consider this
"traffic from nowhere" suspicious and possibly forged, but that's a
configuration problem, not a fundamental one.

Sure, software which listen on a port and capture/evaluate the sent
data are also needed. But the host pc needs to arp entry to recognize
the FPGA (the other host).

That is only required when sending data, not when receiving it.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Nico Coesel]

"KJ" <kkjennings@sbcglobal.net> wrote:

"Nico Coesel" <nico@puntnl.niks> wrote in message
news:48dfe4ee.168426254@news.planet.nl...
jhallen@TheWorld.com (Joseph H Allen) wrote:

An easier way without the extra jitter is to use an
output flipflop (aka DDR flipflop) which can be clocked using 2
clocks. The first clock sets the output, the second clock (inverted
first clock) resets the output. And presto, you'll have a clock output
which is (within pin-to-pin skew) perfectly synchronous to the other
outputs.


Hold time requirements (like the .4ns in the OP) will be impossible to
guarantee with this method though.

A slightly longer PCB track will do that for you. But that won't work
on a pre-made board because you can't alter the PCB. Still, if the OP
uses an off the shelf board the designer should have thought about
these sort of things... Perhaps the OP could ask them.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

 

[Rick Jones]

In comp.protocols.tcp-ip glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

(comp.protocols.tcp-ip added)

Fred wrote:

I've been tasked to write some code for an FPGA to interface to
10BASE- T Ethernet using differential drivers and receivers.

The information is one way, transmit only! I will have an IP
address within the network range, give myself a MAC number and
know the MAC and IP address of the destination PC.

Do I require any ARP or any other protocol? Will it just work,
with the destination PC receiving UDP packets?

Normally you would use ARP to find the destination MAC given the IP
address. Since you seem to already know it, you shouldn't need ARP.
If you don't need to receive, or the sender already knows your MAC
address then you don't need to receive and reply to ARP. (Most will
add you to the ARP table on receiving your data. The entry will
eventually time out, though.)

Is the destination "always" going to be in the same broadcast domain
as the FPGA? If so, then why bother with IP and UDP? The only value
IP adds in this case would seem to be fragmentation and reassembly,
but then only if you implement fragmentation in your FPGA.

If the destination can be "remote" (on the other side of an IP router)
then there are a rather large host (as it were) of things expected of
an IP implementation besides just "slap a header on there and go"
described in a number of the RFC's one can find at places such as
www.ietf.org.

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

 

[Vernon Schryver]

In article <gbribf$q3i$6@usenet01.boi.hp.com>,
Rick Jones <rick.jones2@hp.com> wrote:

Is the destination "always" going to be in the same broadcast domain
as the FPGA? If so, then why bother with IP and UDP? The only value
IP adds in this case would seem to be fragmentation and reassembly,
but then only if you implement fragmentation in your FPGA.

If the destination can be "remote" (on the other side of an IP router)
then there are a rather large host (as it were) of things expected of
an IP implementation besides just "slap a header on there and go"
described in a number of the RFC's one can find at places such as
www.ietf.org.

My answer to the question at the start is that in the real world
there are *always* situations where the absolutely guaranteed
for certain always and forever promise that there will never be
a router is broken. Therefore the low the costs of slapping fake
but servicable UDP/IP headers in front of the payload are so low that
you can't afford not to pay them. There are always test networks if
the promises about no routers are always and forever met when the
application is deployed...and the promises usually are broken in some
deployed case.


Vernon Schryver vjs@rhyolite.com

 

[RCIngham]

Hi All,

I have one basic doubt what will happen if the data throughput is
greater than the Clock Speed. What are the possible violations.

In summary, lost data.

If clock has higher speed than the Data Throughput.

If the clock is not synchronised to the data, the clock frequency must be
more than twice the maximum data rate.
http://www.google.com/search?hl=en&q=nyquist+sampling+theory

 

[Vernon Schryver]

In article <PvGdnWVRAIdVE3_VnZ2dnUVZ_sninZ2d@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Also, you can't accept route redirect or source quench,
two others that would seem useful in some cases.

ICMP Redirect might be useful, but might involve a lot of machinery
given the target situations of no routers.
I think ICMP Source has been deprecated for more than 20 years. See
http://www.google.com/search?q=icmp+source+quench+deprecated

For an application like this that might otherwise use raw Ethernet
packets, Source Quench is obviously useless. In general, Source Quench
is of little use, because transport protocols that real networks can
tolerate have their own congestion avoidance and recovery machinery.
Even if your UDP or other datagram application doesn't have official
congestion management stuff, it ought to have some sort of pacing
machinery that responds to losses caused by losses, which tends to make
ICMP Source Quench irrelevant.

Besides, ICMP Source Quench uses bandwidth, which can make a merely
marginal situation into a bad situation. So we get things like TCP
Explicit Congestion Notification http://www.google.com/search?q=tcp+ecn


Vernon Schryver vjs@rhyolite.com

 

[Kappasm]

Thanks Jerzy Gbur,

I'm sorry. You can't maintain a standard that way,
I thougt you are building own system, undependly of standards.
You have to switch clock.

I imagined that it was not possible ...

Kappa.