EDK : FSL macros defined by Xilinx are wrong

[Waage]

Thanks Sylvain.

I am not having much luck myself and am also a bit miffed!!

What Linux Kernel are you running?

Thanks, Chris

 

[Jim Granville]

Peter Alfke wrote:

Let me correct this:
The addressing depth of Virtex-4 FIFOs is 512, 1024, 2048, or 4096
locations. The word "byte" is meaningful only for the 2048 x 9
configuration.
The FULL flag goes active one write clock cycle after the FIFO has been
filled. That means, in a continuous write situation, the last written
entry will be lost. That's why I recommend using the ALMOST FULL flag
instead of the FULL flag.
EMPTY does not have this problem. It goes active on the same read clock
edge that is reading the last piece of data out of the FIFO. EMPTY
then goes inactive again after a data entry has been written into the
FIFO and the internal signal hes been re-synchronized to the read
clock, which takes a few read clock cycles.

Interesting - so for sustained thru-put on these, you are best to avoid
going empty, which probably means two operating modes : fastest, and
clean-out-the-last-byte(s)
I see some uarts have WDOGs in their fifos, that allow simpler streaming
code, and they generate a time-content interrupt, as well as the normal
threshold one.
Timeout is normally some multiple CHAR times, so the end of message
chars are dealt to without needing polling.

-jg

 

[Dave Pollum]

Jim Granville wrote:
<Peter's stuff snipped>

Interesting - so for sustained thru-put on these, you are best to avoid
going empty, which probably means two operating modes : fastest, and
clean-out-the-last-byte(s)
I see some uarts have WDOGs in their fifos, that allow simpler streaming
code, and they generate a time-content interrupt, as well as the normal
threshold one.
Timeout is normally some multiple CHAR times, so the end of message
chars are dealt to without needing polling.

-jg
We upgraded a Zilog Z8530 serial port to a Z85230 serial port, because

the Z85230 has deeper FIFOs. The 85230's recv port has an 8-byte FIFO
vs the 8530's 3-byte FIFO. I had hoped that the CPU would be
interrupted a lot less using the 85230. The 85230 can be set-up to
interrupt when 1 char is recv'd or when there are 4 bytes in the recv
FIFO (half full). This sounded really great and even worked quite
well, until I discovered that when there _3_ bytes in the FIFO and the
chip is set-up to interrupt when half-full, that the chip does not
interrupt until another byte is received, even if that's minutes later.
ARGH, WIPA!

BTW what's a "WDOG"?

-Dave

 

[Jim Granville]

Peter Alfke wrote:

Jim, you wrote:
"Interesting - so for sustained thru-put on these, you are best to
avoid
going empty, which probably means two operating modes : fastest, and
clean-out-the-last-byte(s)"

I don't get it. Are you referring to the fact that you effectively lose
a few read clock cycles after having gone EMPTY? Why would that be a
problem? I think it helps the state of the FIFO, so that it does not go
empty so often....
Although that is no problem, as demonstarated by our 200MHz/500 MHz
test.

I do not see any problem. You seem to. Let me know the reason.

Now I have to think carefully....
You are right, that going empty infers spare capacity, but I was
looking at it as extra channel latency, and tend to be averse to any
extra latency.
Such latency only happens on EMPTY, and the effect is to make the
FIFO slightly more full next time, which tends to then avoid the
latency... so it is self correcting, and FIFOs are by nature
elastic.

If you were using the FIFO for rate smoothing, then the latency
could be a gotcha, as it introduces a step-pause in the delivery ?

-jg

 

[Peter Alfke]

If you are emptying slightly faster than you fill it, you will go empty
(sooner or later). The penalty is then that you loose not one clock
tick,but perhaps three. That will delay the next going empty longer
than it would be if you had lost only one clock tick.
if you are concerned, you can run against ALMOST EMPTY and
"voluntarily" sacrifice one single clock tick.
Whatever you do, you cannot read out more than you put in .
Peter

 

[Jeremy Stringer]

Kunal wrote:

Let me elaborate a bit more.
My understanding:

False Paths: Paths that are not timming critical but show up in the
timming report with a -ve slack. Can't think of an example.

multi-cycle paths : Paths which can take 2 or more cycle to complete.
But this would mean you gate the clock of the output/second resgiter in
a multi cycle path so that it resgisters the right input after x clock
cycles. Wouldn't that violate the sync design rules byt gating the
clock and thus introducing skew? Aren't you better off pipelining it
anyway, so that you get a result after every clock cycle after the
inital pipeline latency.

Or use a clock enable.

False paths are paths that you (as the designer) know aren't timing
critical. (Such as a an output pin clocked on a 50 Mhz clock that
drives an led).

Multicycle paths are paths that you (as the designer) know are allowed
to take multiple cycles to resolve. For instance, if you have a section
of logic running off a 100Mhz clock, but clock enables running to every
flip-flop in that section of logic, then you know that every signal has
two cycles to resolve before it will be sampled by the next stage.

Jeremy

 

[Symon]

"Kunal" <kunal.shenoy@gmail.com> wrote in message
news:1129583827.348591.276200@g43g2000cwa.googlegroups.com...

Let me elaborate a bit more.
My understanding:

False Paths: Paths that are not timming critical but show up in the
timming report with a -ve slack. Can't think of an example.

multi-cycle paths : Paths which can take 2 or more cycle to complete.
But this would mean you gate the clock of the output/second resgiter in
a multi cycle path so that it resgisters the right input after x clock
cycles. Wouldn't that violate the sync design rules byt gating the
clock and thus introducing skew? Aren't you better off pipelining it
anyway, so that you get a result after every clock cycle after the
inital pipeline latency.

 

[Symon]

Hey Kunal,
So, I have two questions.
A) If you're posting from Xilinx's IP address, why not ask the local
populace?
B) How did you hack into Xilinx's server to post?
C) Why can I neither count or use a touchpad without multi-posting?
Cheers, Syms.
;-)
"Kunal" <kunal.shenoy@gmail.com> wrote in message
news:1129583827.348591.276200@g43g2000cwa.googlegroups.com...

Let me elaborate a bit more.
My understanding:

False Paths: Paths that are not timming critical but show up in the
timming report with a -ve slack. Can't think of an example.

multi-cycle paths : Paths which can take 2 or more cycle to complete.
But this would mean you gate the clock of the output/second resgiter in
a multi cycle path so that it resgisters the right input after x clock
cycles. Wouldn't that violate the sync design rules byt gating the
clock and thus introducing skew? Aren't you better off pipelining it
anyway, so that you get a result after every clock cycle after the
inital pipeline latency.

 

[Symon]

Hello CMOS,
Sadly, I've spent the last fortnight following your advice.
http://tinyurl.com/76ovq
Trouble is, my eyesight has been badly affected. Could you post in a bigger
font? That would.... omigod, what's s/he going to do with THAT?
Cheers, Syms.
p.s. So, normally from an FPGA clock is an output, try searching for OBUF in
the libraries guide. Data is bi-directional (like a large percentage of the
folks on those sites you recommended) so look for OBUFT and IBUF. ;-)


"CMOS" <manusha@millenniumit.com> wrote in message
news:1129562457.464856.260830@g43g2000cwa.googlegroups.com...

hi,
im trying to use i2c open source core available from opensorces.org and
having problems with cofiguring the "scl" and "sda" from the top level
design with the use of IO buffers. if anyone got experience on how to
correctly configure these two ports from a top level hierachy, pls let
me know.

thank you.
CMOS

 

[Symon]

...and, you cheeky bugger, posting from Intel.com is not a good idea if
you're slagging off people's arithmetic! ;-)
http://www.maa.org/mathland/mathland_5_12.html

Cheers, Syms.

"Luke" <lvalenty@gmail.com> wrote in message
news:1129592997.709631.130560@g43g2000cwa.googlegroups.com...

You can't count?

 

[Bevan Weiss]

CMOS wrote:

here we go again...showing off stupidity....

Well he has been your only reply, so perhaps you should just humor him
some and leave his comments be.

Other than that, he wasn't far off. I2C is a shared interface, usually
using open drain/collector pull-down connections. So it will require
the use of a tri-state output buffer. You will simply set the output
value to always be a low value (ie always pulling low) and the only
signal that will be controlled for the pin is the output enable.
Both pins should be bi-directional, to be capable of operating in either
master/slave mode, and to tolerate clock stretching.

So as long as you assign the output signals from your I2C module to
tri-statable pins everything should be ok.

Is that what you're after?

 

Austin,
seems that Xilinx is always one step in advance!
I'm impressed to see how many people in this newsgroup uses Xilinx.
well done,
Francesco


Austin Lesea wrote:

All,

http://tinyurl.com/clzqh

Details the latest readouts for actual single event upsets for Virtex 4,
and Spartan 3.

The improvements (6 times fewer upsets for Virtex 4, and 2.4 times fewer
upsets for Spartan 3 as compared to Virtex II) shows our commitment to
making this a non-issue for our customers.

Make sure you demand from you ASIC/ASSP/FPGA vendor reports on their SEU
susceptibility! This is not an area where you should take this for
granted. Reducing SEU susceptibility is not something the foundry
builds in to their process; it is something that takes time and effort
on the part of IC designers to implement, and more time and effort to
verify.

For a vendor to claim "oh, we do what Xilinx does..." is completely
insufficient. We certainly are not telling anyone how we did this (6X
improvement): just that we have done this.

The only other company that we are aware of with a "Rosetta"-like
program (work with foundry on process; design, simulation, and analysis
by IC designers; measurements in neutron and proton beams; actual
atmospheric testing in multiple locations at multiple altitudes) is Cypress.

Imitation is the sincerest form of flattery.

Additionally, Cypress has a good book on the effects of cosmic ray
neutrons and protons on memories.

http://tinyurl.com/72mvw

For more details, contact your FAE. They have materials accessible to
them for customer presentations on this issue.

Austin

 

[Dave Pollum]

Jim Granville wrote:

Dave Pollum wrote:
Jim Granville wrote:
Peter's stuff snipped

Interesting - so for sustained thru-put on these, you are best to avoid
going empty, which probably means two operating modes : fastest, and
clean-out-the-last-byte(s)
I see some uarts have WDOGs in their fifos, that allow simpler streaming
code, and they generate a time-content interrupt, as well as the normal
threshold one.
Timeout is normally some multiple CHAR times, so the end of message
chars are dealt to without needing polling.

-jg

We upgraded a Zilog Z8530 serial port to a Z85230 serial port, because
the Z85230 has deeper FIFOs. The 85230's recv port has an 8-byte FIFO
vs the 8530's 3-byte FIFO. I had hoped that the CPU would be
interrupted a lot less using the 85230. The 85230 can be set-up to
interrupt when 1 char is recv'd or when there are 4 bytes in the recv
FIFO (half full). This sounded really great and even worked quite
well, until I discovered that when there _3_ bytes in the FIFO and the
chip is set-up to interrupt when half-full, that the chip does not
interrupt until another byte is received, even if that's minutes later.
ARGH, WIPA!

BTW what's a "WDOG"?

Sorry, cryptic mode... WDOG = WatchDog = monostable timer, that
retriggers on every incomming CHAR, and times-out after some user
defined CHAR pauses.
Purpose is to catch exactly the PITA you describe

-jg

"Watch Dog" - I sorta thought that's what you meant, but I wasn't sure.
Thanks for the explanation. And "WIPA" was a brain fart. I meant
PITA. Good grief!
-Dave

 

[John B]

Jerry - we've designed (are designing) several LSI RapidChips.
Here's some comments on your posting:

- Costs are pretty out there. You need to get to a Rapid Ready Netlist
using the LSI tool flow (LSI RapidWorx). Depends where you are coming
from on how hard that is. If it's an FPGA design, expect to re-map
the memories, re-do the I/Os, maybe change some IP, re-verify. If
it's a clean design it's a case of designing for the technology.
- You'll pay; LSI NRE ($50-200K depending on chip chosen) for Netlist
to chip. Synplicity tool costs ($20K or so) and that should be it.
RapidWorx is free. You'll need Synopsis primetime for STA - if you
haven't got it that can be pricey, or you can pay someone to do it
for you on an hourly rate
- Layout is easy as long as you follow the rules - so, one iteration.
The rules cover things like max speed (typically 250MHz) and getting
the RTL through the design rule checker (Tera Systems, Teraform tool).
The rules can be broken, but that's when physical becomes trickier
and you can expect to pay some additional NRE
- Device delivery schedule.....won't lie to you here, LSI is still
putting chips through a new tool flow and we've run into several
gotcha's that delayed things. By now hopefully things are cleaned up
(they've done about 50 chips). But don't believe their 'as easy
as an FPGA' hype - it isn't. Learning the tools takes
sometime.....the tools still have some bugs. Working with someone
who's done it before is a huge benefit.
- Synplicity does a 'placed netlist' synthesis with pretty accurate
timing.....except, one design we did had a massive fan out on the AMBA
bus. We warned the end customer but he went ahead anyway. The final
layout tool threw in a whole bunch of buffers and that screwed things
up compared to Synplicity results. Otherwise the match has been very
accurate.
- Detailed place and route time - very dependent on the size /
complexity of the chip. But very fast compared to an ASIC 6-8 weeks is
a good rule of thumb
- Test scan is built into the chip by LSI so you should have no worries
there. You hand off RTL, they add clocks, scan chains etc. No need to
worry about test coverage, signal integrity (as long as you follow the
rules)
- Paying distributor - LSI uses Arrow (in North America) to deal
with most customers who aren't Cisco etc. Arrow has a design center
and will do most (not all) of the post Netlist engineering. So yes, you
pay them. But they are highly professional and experienced. Unless
you're a high volume big guy in which case you might deal direct.

From experience I'd rather deal with Arrow any day. LSI ARE sticklers
and can be a real pain to work with.

Feel free to Email me with any questions or you can talk directly to
one of our engineers (within reason, we have to make a living to!)

 

[Austin Lesea]

Francesco,

Thank you.

The level of activity on this board is a good indicator of the number of
engineers that are designing with our chips at any given time. This
group is also invaluable for us to get feedback on how well we are
treating our customers. I would prefer that feedback be directed to our
hotline; but, for those who are not getting the service they feel they
deserve, I have also encouraged people to contact me (or Peter) directly.

Many people read this board like a stockbroker reads the morning news:
it is where folks go to see "what's happening."

Austin


francesco_poderico@yahoo.com wrote:

Austin,
seems that Xilinx is always one step in advance!
I'm impressed to see how many people in this newsgroup uses Xilinx.
well done,
Francesco


Austin Lesea wrote:

All,

http://tinyurl.com/clzqh

Details the latest readouts for actual single event upsets for Virtex 4,
and Spartan 3.

The improvements (6 times fewer upsets for Virtex 4, and 2.4 times fewer
upsets for Spartan 3 as compared to Virtex II) shows our commitment to
making this a non-issue for our customers.

Make sure you demand from you ASIC/ASSP/FPGA vendor reports on their SEU
susceptibility! This is not an area where you should take this for
granted. Reducing SEU susceptibility is not something the foundry
builds in to their process; it is something that takes time and effort
on the part of IC designers to implement, and more time and effort to
verify.

For a vendor to claim "oh, we do what Xilinx does..." is completely
insufficient. We certainly are not telling anyone how we did this (6X
improvement): just that we have done this.

The only other company that we are aware of with a "Rosetta"-like
program (work with foundry on process; design, simulation, and analysis
by IC designers; measurements in neutron and proton beams; actual
atmospheric testing in multiple locations at multiple altitudes) is Cypress.

Imitation is the sincerest form of flattery.

Additionally, Cypress has a good book on the effects of cosmic ray
neutrons and protons on memories.

http://tinyurl.com/72mvw

For more details, contact your FAE. They have materials accessible to
them for customer presentations on this issue.

Austin

 

[John B]

Sorry just read through that and realised I didn't do a very good job
on the flow:
1) Enter the design in LSI RapidWorx
2) Check the design in TeraSystems Teraform
3) Synthesize the design in Synplicity Amplify
4) Check STA in Synopsis primetime
5) Hand off netlist to LSI or 3rd party.
John (john.burton@octera.com)

 

[Brannon]

Try using the -u param on ngdbuild. It should at least make it to the
mapper at that point. Do you have a file named fpmulIE24mw_8ew.ngc (or
..edf or .edn or .ngo)? Can you determine what type of block it is by
digging into the code? It should match something here if it is a
built-in block:

http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/lib/lib0024_10.html

Otherwise, there should be code for it in one of the files Xilinx gave
you for the multiplier. It's possible you did not get all the necessary
files from Xilinx.

 

[Kunal]

If you are looking for a basic tutorial on creating an OPB peripheral
look at "Designing a Custom Processor Peripheral Using Xilinx EDK" by
Richard Griffin on the Xilinx website under TechXclusives.
After that you could use the "Create - Import Peripheral wizard" tool
included with Xilinx EDK to easily create your custom peripherals. It
also has documentation on OPB/PLB IPIF specs.

Kunal

 

[Simon Heinzle]

Thanks for the push in the right direction -- there is a file
"fpmul24mw_8ew.ngc" somewhere in the Coregen directory hierarchy, but the
"IE" is missing. Hm, strange problem, I have to examine the installation --
perhaps something went wrong when updating.

Best,
Simon


"Brannon" <brannonking@yahoo.com> wrote in message
news:1129649568.948234.12370@o13g2000cwo.googlegroups.com...

Try using the -u param on ngdbuild. It should at least make it to the
mapper at that point. Do you have a file named fpmulIE24mw_8ew.ngc (or
.edf or .edn or .ngo)? Can you determine what type of block it is by
digging into the code? It should match something here if it is a
built-in block:

http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/lib/lib0024_10.html

Otherwise, there should be code for it in one of the files Xilinx gave
you for the multiplier. It's possible you did not get all the necessary
files from Xilinx.

 

[John_H]

Carry chain compares are done all the time. They work great. Your
definition is how they're implemented
If your single bit "a" and single bit "b" are considered:
if( a<b ) force b (which is high) onto the chain
if( a>b ) force b (which is low) onto the chain
if( a==b ) pass the carry in to carry out.
A comparison is just a subtraction.


"Brannon" &lt;brannonking@yahoo.com&gt; wrote in message
news:1129648479.566094.268650@z14g2000cwz.googlegroups.com...

The carry chains in current Xilinx FPGAs are insufficient for
comparison logic. I propose some changes for future chip designs:

First, if this can be done on a Stratix 2 carry chain, please state
how.

We are going to do a LT or GT comparison. The plan for LT:

chop the thing into 2 bit chunks
for the most significant chunk:
if (a &lt; b) switch the chain high
if (a &gt; b) switch the chain low
if (a == b) passthrough
repeat for next most significant chunk
tie the bottom of the chain low

So you see the problem? I can't force the chain high or low at run time
and still allow for passthrough. I can only do one or the other.