EDK : FSL macros defined by Xilinx are wrong

[Antti Lukats]

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag
news:439d69c8$0$11610$3b214f66@tunews.univie.ac.at...

Any recommendations for documentation describing MMC, SD, and their
differences. I have Googled, and got swamped with loads of links to
places selling such cards. The few techy links were fairly useless, along
the lines of "you can buy the full spec from...."

http://www.sdcard.org/sd_memorycard/index.html
http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf

BTW: will your MMC or SD card interface be open-source?
I am interested in the SD card interface, ?but don't find
the time to implement it.

Martin

Hi Martin,

your question was to whom?

if you want a SD card interface for your JOP, then firstly it can be done
100% in software (I guess you are talking about the host side).

the SW version can be painfully slow depending on the CPU and compiler being
used and coding style

for better speed one combo option could be that CMD line eg all
command-response is handled in sw bitbang and only the DAT (eg block
read/write) is implemented in hardware this would give very small FPGA core
and only have a minor penalty on the speed. for this purpose the LARK mmc
vhdl code archive actually contains allmost ready to use block (but I think
the crc16 is also wrong there), in any case its not a major issue to design
module that can rec-transmit the mmc style commands from-to block ram

Antti

 

[Antti Lukats]

"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag
news:OWXmf.4434$zt1.198@newsfe5-gui.ntli.net...

"Antti Lukats" <antti@openchip.org> wrote in message
news:dnhgmj$q4f$01$1@news.t-online.com...

http://gforge.openchip.org
I think there is small bug in CRC7 and maybe something else
as said its presented in the way I got it, and its completely untested


I hear SD is a superset of MMC.

SD has somewhat different command set meaning that some commands that are
present
in MMC are not there in SD like streaming read is only in MMC not in SD
also the initialization is different

Sigh. SD cards seem to be the best thing to buy for most consumer
electronics, they seem to be replacing MMC cards. Better data bus width
etc.

Any recommendations for documentation describing MMC, SD, and their
differences. I have Googled, and got swamped with loads of links to places
selling such cards. The few techy links were fairly useless, along the
lines of "you can buy the full spec from...."

there are enough specs to be find with DEEPgoogling

both MMC and SD can turn on 4 bit mode

http://www.howell1964.freeserve.co.uk/parts/sd_mm.htm
indicates MMC has only 7 pins, and only one of these for data.

additionally MMC (standard 4.1) can also support 8 bit mode and turbo
clock up to 52MHz !

Wow.

I thought most of the 'new features' work would be done on SD cards.
The Mini-format is just a repackaging.

both mmc and sd have new things

MMC has rs-mmc format, also microMMC
and the 8 bit mode and turbo speed

SD has miniSD and microSD (aga Transflash)

OMHO the only card to be used is microSD

Antti

 

[Martin Schoeberl]

Any recommendations for documentation describing MMC, SD, and their differences. I have Googled, and got swamped with loads of
links to places selling such cards. The few techy links were fairly useless, along the lines of "you can buy the full spec
from...."

http://www.sdcard.org/sd_memorycard/index.html
http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf

BTW: will your MMC or SD card interface be open-source?
I am interested in the SD card interface, ?but don't find
the time to implement it.

Martin

Hi Martin,

Hi Antti,

your question was to whom?

Who ever wants to provide it ;-)

if you want a SD card interface for your JOP, then firstly it can be done 100% in software (I guess you are talking about the host
side).

That's the way I (or everybody else) would implement it first.
And than when it works one usually 'forgets' to ove it to HW.

the SW version can be painfully slow depending on the CPU and compiler being used and coding style

for better speed one combo option could be that CMD line eg all command-response is handled in sw bitbang and only the DAT (eg
block read/write) is implemented in hardware this would give very small FPGA core and only have a minor penalty on the speed. for
this purpose the LARK mmc vhdl code archive actually contains allmost ready to use block (but I think the crc16 is also wrong
there), in any case its not a major issue to design module that can rec-transmit the mmc style commands from-to block ram

Yes, a practical idea.

Martin

 

[Jim Granville]

Antti Lukats wrote:

they talked about this producte for more than 3 years ago, now its finally
laucnhed

* ADC 12bit 600KS/S
* MOSFET drivers
* user Flash rom
* onchip 1% accurate 100MHz oscillator
* oscillator for 32KHz watch crhrystal
* single 3.3V power supply

http://xilant.com/content/view/22/2/

pretty nice features!

Well PA3 is just about shipping so we may have to wait to get hands on onto
Fusion silicon, but it really looks like cool true single chip.

hm,. if I think about it, this the silicon I have been waiting for, for the
last 10 years or so

Antti

- and large amounts of code flash, so much that the SRAM looks a bit
light.....

Key determinant will be the price, as you can get
ARM+FLASH+ADC+32KHz+Ethernet, for rather less than the same bundle will
be in the Fusion. That means the FPGA aspect has to be very important,
to the design, and the single chip more important than a much cheaper
CPLD/Small FPGA alongside the ARM+FLASH+ADC+32KHz+Ethernet....

Devices from the uC segment to compare this with, would be the
ADuC7xx series : 12 Bit ADC, 12 Bit DAC, ARM CPU, FLASH, in 40-80 pins,
and the 'comming' uPSD ARMs from ST, which have 32MC CPLDs, and
Ethernet/CAN/USB, 96K Bytes SRAM and 2MBytes FLASH.

Seems to me a smaller Fusion device, _and_ a "Well stacked" ARM Flash
Microcontroller, will be better value, than trying to roll it all
yourself in a bigger Fusion device. Time will tell, I guess.

-jg

 

[Jan Panteltje]

On a sunny day (Tue, 13 Dec 2005 10:03:38 +0100) it happened "Antti Lukats"
<antti@openchip.org> wrote in <dnm2pa$a0$00$1@news.t-online.com>:

they talked about this producte for more than 3 years ago, now its finally
laucnhed

* ADC 12bit 600KS/S
* MOSFET drivers
* user Flash rom
* onchip 1% accurate 100MHz oscillator
* oscillator for 32KHz watch crhrystal
* single 3.3V power supply

http://xilant.com/content/view/22/2/

pretty nice features!

Well PA3 is just about shipping so we may have to wait to get hands on onto
Fusion silicon, but it really looks like cool true single chip.

hm,. if I think about it, this the silicon I have been waiting for, for the
last 10 years or so

Antti


http://www.actel.com/products/fusion/

AFS600 has 30 analog inputs, amazing.
it is the Microchip philosophy, integrate everything.

 

[Mike Treseler]

Binary wrote:

I want to my chip to run as fast as possible but what is
the max value, which determines it?

fmax = 1/(Tcq+Tgate+Troute+Tsetup)
for the slowest path between registers.

A post-route static timing analysis
will measure this for your design.

--Mike Treseler

 

[John Adair]

You can do this in FPGA Editor. If you are working in Webpack I don't
believe that tool is included. You can either tweek the design after p&r or
alternative create a macro that you use over and over.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development
Board.
http://www.enterpoint.co.uk


"John" <jdc-rootbeer@hotmail.com> wrote in message
news:1134497157.471856.291020@o13g2000cwo.googlegroups.com...

Hi All
Is there anyway to directly stash bits into Xilinx (Spartan in this
case) LUTs ? I need to hand-build a very small part of my design.
Any suggestions?
Thanks. -jc

 

[Antti Lukats]

"John" <jdc-rootbeer@hotmail.com> schrieb im Newsbeitrag
news:1134497157.471856.291020@o13g2000cwo.googlegroups.com...

Hi All
Is there anyway to directly stash bits into Xilinx (Spartan in this
case) LUTs ? I need to hand-build a very small part of my design.
Any suggestions?
Thanks. -jc

http://www.rockylogic.com/freebies.html

its for virtex but should also work for others

antti

 

[HB]

I need a choice between 2 solutions :

first solution:
I can use a Freq=48MHz to create a 32MHz (multi *2, and div 3).
But the signal for this freq isn't locate at a clock PIN (old card, so I
can't change the PINOUT).
This signal is locate PIN number AA4 in a Virtex XCV300-FG456).
I have some problems to use DLL and BUF.
Is someone could help me (use DLL and/or BUF without dedicated clk pin) !!.

second solution:
I can use a Freq=32MHz to create a 48MHz (multi*3, and div 2).
But it very difficult to have this multi *3 !.

I need a clk with a good precision, and if possible with around 50/50 of
duty cycle.

THANKS LOT for your help. Any suggestion will appreciate.
Regards.

Benoit.


"Austin Lesea" <austin@xilinx.com> a écrit dans le message news:
dnl3hk$f6910@xco-news.xilinx.com...

So it is....

Looks like getting 48 MHz from 32 MHz is not going to be as easy as it
first appears!

What kind of output duty cycle and max jitter is needed?

Austin

Symon wrote:

"Austin Lesea" <austin@xilinx.com> wrote in message
news:dnku2g$f699@xco-news.xilinx.com...

HB,

In Virtex, the DLL may be used for mutliply by 2. That gets you to 64
MHz. Then a subsequent DLL may be used for divide by 1.5 to get 48 MHz.

Or, you may use a /1.5 circuit made out of FF's and a LUT.

http://www.xilinx.com/xcell/xl33/xl33_30.pdf

Austin


Would be a great solution, except that, sadly, 64MHz divided by 1.5 is
42.667 MHz, or thereabouts.
Cheers, Syms.

 

[Symon]

"HB" <bhb22l@yahoo.fr> wrote in message
news:dnn44o$lu5$1@s1.news.oleane.net...

I need a choice between 2 solutions :

first solution:
I can use a Freq=48MHz to create a 32MHz (multi *2, and div 3).
But the signal for this freq isn't locate at a clock PIN (old card, so I
can't change the PINOUT).
This signal is locate PIN number AA4 in a Virtex XCV300-FG456).
I have some problems to use DLL and BUF.
Is someone could help me (use DLL and/or BUF without dedicated clk pin)
!!.

Benoit,

This is the way to go. You can use any pin as an input clock. IIRC you may
need to instantiate an IBUF and the DLL/GBUF in your code. There must be
examples of this in previous postings here and in Xilinx's documentation.
Cheers, Syms.

 

[John_H]

"Antti Lukats" <antti@openchip.org> wrote in message
news:dnn395$tgl$1@online.de...

"John" <jdc-rootbeer@hotmail.com> schrieb im Newsbeitrag
news:1134497157.471856.291020@o13g2000cwo.googlegroups.com...
Hi All
Is there anyway to directly stash bits into Xilinx (Spartan in this
case) LUTs ? I need to hand-build a very small part of my design.
Any suggestions?
Thanks. -jc

http://www.rockylogic.com/freebies.html

its for virtex but should also work for others

antti

Nice VHDL example. It's pretty simple to do the LUT instantiation in
Verilog as well. The INIT parameter just needs the right value which can be
provided through localparam values where I0=16'haaaa, I1=16'hcccc,
I2=16'hf0f0, and I3=16'hff00. The instantiation is pretty straightforward;
one example starts off:

LUT3 #( I0 & I1 | ~I0 & I2 )
MyLut3Name[3:0] ( .O(myOut), .I0( ...

 

[Ray Andraka]

HB wrote:

Gee, that sounds a lot like the GV associates board I used for the Radar
project shown in the gallery page of my website (the one with the CPU
fans on the FPGAs). In that case, there was a 48MHz clock for a USB
interface chip that was also connected to the FPGA, but not through a
clock pin and we had a separate clock oscillator that came through
another pin (I think it was 66 MHz).

If you aren't worried about the relative phase of the 32 and 48 Mhz
clocks, you can bring the 48 Mhz clock in through the non-clock pin and
use general routing resources to get it to a DLL. From there you can do
the divide by 1.5 to get 32 MHz.

I'd have to do some digging through the archives to find the clock
module for that design, but the point is you don't necessarily have to
bring the clock in on a clock pin if you aren't worried about clock skew.

 

[Jon Elson]

Monica wrote:

Dear Mr.Alan,

I have changed my logic such mpegData is considered as a register
instead of combitional logic and kept them in IOBs(through help).The
output is not only good but also fast.Thanks a lot for your suggestion.


Ah, well, that explains the 7 ns lag. While mpegSync is prompt from the FF

(register) the combinatorial logic on mpegData following the last
register produced the
delay.

Jon

 

[kl31n]

Il Tue, 13 Dec 2005 16:40:06 GMT, mk ha scritto:

Before thinking about debugging, have you done any timing
verifications ? Look at your timing reports first. Even with the
slowest divider (at 30 cycle latency) and device (at around 200MHz) it
shouldn't take more than 150ns though. Are you aware that the divider
has a relatively large latency (30 Max apparently) ? How did you
configure your dividers, what's your reported latency ? Again read
your timing reports and pay attention to how you're feeding the
dividers.

The timing report tells me that I can run my block at 157MHz and I'm
running it at 100Mhz, so it has to be 330ns the latency(the core, being in
basic mode to take advantage of the handshaking, has a 33 cycles latency).

By parallelizing to n dividers I expected I could pretend to have a latency
of (ceil(33 / n) * T), while I cannot get under 260ns and this with
whatsoever the number of dividers.

Thanks,

kl31n

 

[Monica]

Hello all,

Thank you very much for explaining me everything clearly.The
suggestions and information is highly useful.I think I must more
homework to understand such problems.

Thanks alot,
Monica

 

[HB]

Hi Ray,

Thanks for your answer. I take an interest in your example. Can you send me
the file.vhd
with the clk rom your project.
My problem is :
I use with success the DLL in my project, but only for a free place and
route.
When I try to write a file.ucf with this dedicated pin "aa4" for my CLK, ISE
(Version7.1)
stop with error at the mapping.
(need to use IBUF or other...)

I aren't worried about the relative phase of the 32 and 48 Mhz clocks, but I
would like to have
duty cycle around 50% (40/60 max).

Thanks for your help.

Benoit.

"Ray Andraka" <ray@andraka.com> a écrit dans le message news:
ldHnf.5079$rB5.1219@dukeread01...

HB wrote:

Gee, that sounds a lot like the GV associates board I used for the Radar
project shown in the gallery page of my website (the one with the CPU
fans on the FPGAs). In that case, there was a 48MHz clock for a USB
interface chip that was also connected to the FPGA, but not through a
clock pin and we had a separate clock oscillator that came through
another pin (I think it was 66 MHz).

If you aren't worried about the relative phase of the 32 and 48 Mhz
clocks, you can bring the 48 Mhz clock in through the non-clock pin and
use general routing resources to get it to a DLL. From there you can do
the divide by 1.5 to get 32 MHz.

I'd have to do some digging through the archives to find the clock
module for that design, but the point is you don't necessarily have to
bring the clock in on a clock pin if you aren't worried about clock skew.

 

[Ray Andraka]

I don't have the vhdl handy at the moment. You need to change your
input buffer from an IBUFG to an IBUF to be able to place it on an
arbitrary pin. You probably don't need to place anything else, nor do
anything else special.

 

[rhnlogic]

kl31n wrote:

The timing report tells me that I can run my block at 157MHz and I'm
running it at 100Mhz, so it has to be 330ns the latency(the core, being in
basic mode to take advantage of the handshaking, has a 33 cycles latency).

By parallelizing to n dividers I expected I could pretend to have a latency
of (ceil(33 / n) * T), while I cannot get under 260ns and this with
whatsoever the number of dividers.

Parallelizing units only speeds up the latency of the completion
of multiple operations, but each operation still takes the same
latency of when using just a single unit, no matter how many units
are in parallel.

For instance, one divider would take 66 cycles for 2 divides (at an
average rate of 1 divide per 33 cycles), but 2 (or even 500) dividers
would take 33 cycles for 2 divides (for an average rate of 16.5
cycles per divide). But in either case you don't get the first
divide result in less than 33 cycles.

If anything parallelizing units might actually slow down max
single operation latency, due to wire load, muxing, buffering or
pipelining required to fan-out operands and control signals to
the multiple pipes, plus fan-in the results.

And running the clock faster than worse case timing allows might
only result in garbage.


IMHO. YMMV.
--
rhn A.T nicholson d.O.t C-o-M

 

[Symon]

Benoit,
You need to learn how to search Google groups! ;-)
Look here for example code:-
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/b2e060b33fd0a0a2/c1a2d891c6d6ca77
HTH, Syms

 

[Mike Treseler]

kl31n wrote:

That's what I did, but I don't have access to Xilinx cores internals to
really see what's going on and what I could do to fix the problem. The
behavioural model always works like expected, the Post-Translate instead
cannot work correctly with data entereing with a period smaller than 260n.

Maybe that's just the way it is.
You could open a case with Xilinx
or use a different core
or write your own code.

-- Mike Treseler